суббота, 6 февраля 2010 г.

ISSP \ Домен 03. Архитектура и модель безопасности. Часть 9

В этой части рассмотрены следующие вопросы:
  • Сертификация vs. Аккредитация
  • Сертификация
  • Аккредитация
  • Открытые vs. Закрытые системы
  • Открытые системы
  • Закрытые системы
  • Корпоративная архитектура

Обновлено: 03.05.2010

Мы рассмотрели различные типы критериев оценки, позволяющие оценить систему для присвоения ей соответствующего рейтинга. Это очень формализованный процесс, следуя которому оцениваемой системе или продукту присваивается определенный рейтинг, после чего сведения об этой системе (продукте) размещаются в EPL. Покупатель может проверить этот список и сравнить различные продукты и системы, чтобы увидеть, как соотносятся их рейтинги возможностей защиты. Однако когда покупатель приобретает этот продукт и устанавливает его в свою среду, безопасность не гарантирована. Обеспечение безопасности включает в себя множество аспектов, среди которых администрирование системы, физическая безопасность, процесс установки и настройки механизмов непосредственно в среде, а также другие действия. Чтобы сказать, что система защищена, все эти аспекты должны быть учтены. Рейтинг – это только один из элементов в головоломке, называемой безопасностью.


Сертификация – это всесторонняя техническая оценка компонентов безопасности и их соответствия цели аккредитации. Процесс сертификации может использовать оценку мер безопасности, анализ рисков, проверку, тестирование и методы аудита для оценки пригодности конкретной системы. Предположим, что Дэн – офицер безопасности компании, который купил новые системы для использования в процессе обработки конфиденциальных данных. Он хочет знать, подходят ли эти системы для этих задач и предоставляют ли они необходимый уровень защиты. Он также хочет убедиться, что они совместимы с имеющимся окружением, не снизят производительность, не создадут новых угроз – по сути, он хочет знать, подходят ли эти системы его компании. Он может заплатить специализирующейся на этих вопросах компании, которая выполнит необходимые процедуры сертификации этих систем, либо он может это сделать своими силами. В рамках сертификации команда оценщиков анализирует оборудование, прошивки, тестирует конфигурации программного обеспечения, структуру, реализацию, системные процедуры, управление на физическом и коммуникационном уровнях.

Цель процесса сертификации – гарантировать, что сеть, продукт или система подходят задачам покупателя. Различные покупатели могут использовать один и тот же продукт по различным причинам, а их среда может имеет различный уровень угроз. Поэтому не каждый продукт хорошо подойдет каждому конкретному покупателю (хотя продавцы, конечно, будут пытаться убедить вас в обратном). Продукт предоставляет надлежащую функциональность и безопасность покупателям, цели которых соответствуют целям процесса сертификации.

Процесс сертификации и соответствующая документация могут показать продукт хорошим, плохим, ужасным, описать, как он работает в рамках данной среды. Далее, Дэн возьмет эти результаты и покажет своему руководству для проведения процесса аккредитации.


Аккредитация – это формальное принятие руководством адекватности безопасности системы в целом и ее функциональности. Руководству (или ответственному лицу) представляется информация сертификации, ответы на их вопросы, обзоры отчетов и исследований, чтобы руководство решило – принять ли продукт, и нужны ли какие-либо корректирующие действия. Если безопасность системы в целом руководство устраивает, оно формально принимает ее. Делая это, руководство утверждает, что оно понимает уровень защиты, предоставляемый системой в текущей среде компании, и понимает риски безопасности, связанные с установкой и поддержкой этой системы.
Не нужно больше ломать карандаши. Многие компании стали относиться к процессу аккредитации более серьезно, чем раньше. К сожалению, иногда после завершения процесса сертификации и передачи документации руководству для анализа и принятия решения, руководство просто не глядя подписывает необходимые документы, не понимая в действительности, что оно подписывает. Аккредитация означает, что руководство принимает риск, связанный с разрешением внедрить новый продукт в среду компании. Когда происходит серьезная проблема с безопасностью, последней инстанцией является человек, который подписал документ. Как только такие руководители понимают, что они несут ответственность за то, что они подписали, а также узнают, как много законов устанавливают персональную ответственность руководителя за безопасность, они гораздо реже ломают карандаши об аккредитационные бумаги. Хотя, увы, полностью исключить такие случаи все равно нельзя.
ПРИМЕЧАНИЕ. Сертификация – это технический обзор, обеспечивающий оценку механизмов безопасности и их эффективности. Аккредитация – это официальное принятие руководством информации, выявленной в процессе сертификации.
Поскольку программное обеспечение, системы и среды постоянно меняются и развиваются, сертификацию и аккредитацию следует также продолжать применять. При любом существенном дополнении в программном обеспечении, изменении в системе или изменении в среде следует инициировать новый цикл сертификации и аккредитации.


Компьютерные системы могут разрабатываться для легкой интеграции с другими системами и продуктами (открытые системы), либо могут разрабатываться как более закрытые по своей природе и работающие только с определенным подмножеством других систем и продуктов (закрытые системы). Следующие разделы описывают различия между этими подходами.


Системы, которые описываются как открытые, построены на основе стандартов, протоколов и интерфейсов, имеющих опубликованные спецификации, которые позволяют сторонним разработчикам разрабатывать дополнительные компоненты и устройства. Эта функциональная совместимость обеспечивается всеми разработчиками, которые следуют соответствующим стандартам и предоставляют интерфейсы, позволяющие любой системе без проблем взаимодействовать с другими системами, легко дополняя их.

Большинство систем, используемых в настоящее время, являются открытыми. Именно по этой причине администратор может обеспечить легкое взаимодействие в рамках одной сети компьютеров под управлением Windows NT 4, Windows 2000, Macintosh и Unix, так как их платформы являются открытыми. Если разработчик создает закрытую систему, это ограничивает ее потенциальные продажи, т.к. она пригодна только для проприетарных сред.
ПРИМЕЧАНИЕ. В Домене 09 мы рассмотрим стандарты взаимодействия, такие как CORBA, DCOM, J2EE и другие.

Системы, которые называют закрытыми, используют архитектуру не соблюдающую отраслевые стандарты. При этом функциональная совместимость не обеспечивается, стандартные интерфейсы не применяются, что не позволяет различными типам систем легко взаимодействовать между собой и дополнять возможности друг друга. Закрытая система проприетарна, что означает, что она может взаимодействовать только с такими же системами.

С другой стороны, закрытая архитектура может обеспечить более высокий уровень безопасности, т.к. она не имеет множества точек входа и функционирует в более ограниченной среде, чем открытые системы. Для закрытых систем не существует такого множества средств для обхода или нарушения механизмов безопасности, немногие люди понимают их структуру, язык, а также слабости защиты, чтобы воспользоваться ими.
Большинство современных систем построено на открытой архитектуре, что позволяет им работать с другими типами систем, легко совместно использовать информацию и получать расширенную функциональность за счет дополнений, разработанных сторонними разработчиками. Однако это открытая дверь для взлома и атак.


К настоящему моменту мы рассмотрели множество вопросов и концепций, относящихся к операционным системам и приложениям. Мы начали с архитектуры системы, прошли через различные компоненты, которые должны быть безопасным образом встроены в систему для обеспечения необходимого (требуемого от них) уровня защиты. Архитектура безопасности системы – это высокоуровневый проект, использующийся в качестве основы. Архитектура необходима для обеспечения соблюдения политики безопасности системы и требуемого уровня безопасности. Прекрасно, но что такое корпоративная архитектура безопасности?

Компания всегда имеет выбор, пытаясь защитить свою среду в целом. Она может решить просто внедрить отдельные продукты в различных частях среды (это называется точечными решениями) и надеяться, что такой подход будет прекрасно работать и обеспечит равномерную безопасность среды, закроет все уязвимости компании. Либо компания может потратить время, чтобы проанализировать свою среду, понять требования бизнеса в отношении безопасности и разработать полноценную платформу и стратегию, которые являются отображением друг друга. Большинство компаний выбирают первый вариант, занимаясь «тушением локальных пожаров». Это приводит к постоянным стрессам, несоблюдению требований безопасности, делает хаос нормой жизни.

Второй подход может использоваться для определения корпоративной архитектуры безопасности, применяя ее в качестве руководства при реализации решений, чтобы убедиться, что учтено все необходимое, обеспечена стандартная защита всей среды, минимизировано количество возможных сюрпризов безопасности для компании, когда она начнет реально использовать все это. Хотя реализация корпоративной архитектуры безопасности не обещает идеальную среду, она устраняет хаос, существенно увеличивает продуктивность работы сотрудников безопасности и компании в целом, позволяет мыслить более проактивно и зрело в отношении безопасности компании.

Корпоративная архитектура безопасности (enterprise security architecture) определяет стратегию информационной безопасности, которая состоит из уровней политики, стандартов, решений, процедур и способов, которыми они соединены стратегически, тактически и операционно. Это отличается от архитектуры инфраструктуры. Инфраструктура – это лежащие в основе технологии и аппаратное обеспечение, необходимые для поддержки корпоративной архитектуры безопасности. Просто иметь инфраструктуру (коммутаторы, кабели, маршрутизаторы, узлы и т.п.) недостаточно. Чтобы иметь корпоративную архитектуру безопасности необходимо обеспечить совместную работу всех элементов инфраструктуры взаимосвязанным и безопасным образом, для чего требуется программное обеспечение, люди и процессы. Помимо безопасности, этот тип архитектуры позволяет компаниям достигать лучшей совместимости, интеграции, легкости использования, стандартизации и управляемости.

Как вы можете узнать, что компания не имеет корпоративной архитектуры безопасности? Если вы ответите «да» на большинство следующих вопросов, значит такой архитектуры не существует.
  • Выявление новых уязвимостей и воздействий от них заняло более 15 дней?
  • Когда потребности пользователя в доступе возрастают в соответствии с потребностями бизнеса, администратор безопасности или сетевой администратор просто изменяет его права доступа без документально оформленного руководителем пользователя разрешения?
  • После внедрения нового продукта, неожиданно появляются проблемы несовместимости, которые требуют существенное количество времени и денег для своего исправления?
  • При возникновении проблем безопасности применяются индивидуальные, одноразовые, точечные решения, вместо следования стандартизированным процедурам?
  • Руководители бизнес-подразделений компании не осведомлены о своих обязанностях в области безопасности, в том числе обязанностях установленных законодательством и требованиями регуляторов?
  • Понятие «критичные данные» определено в политике, однако необходимые защитные меры не полностью внедрены, а их работа не отслеживается надлежащим образом?
  • Реализуются точечные решения вместо решений корпоративного уровня?
  • Продолжают происходить одни и те же дорогостоящие ошибки?
  • Отсутствует постоянный контакт между высшим руководством и персоналом безопасности?
  • Стратегическое управление безопасностью в настоящее время недоступно, поскольку безопасность компании не анализируется и не контролируется стандартными и всеобъемлющими способами?
  • Бизнес-решения принимаются без учета безопасности?
  • Персонал безопасности обычно «тушит пожары», не имея времени на разработку и внедрение стратегических подходов?
  • Все больше и больше сотрудников безопасности «сохнет» на работе, пьет антидепрессанты и успокоительное?
Большинство компаний имеют перечисленные выше проблемы, и при этом они фокусируются на каждой из этих проблем в отдельности, как будто они не связаны между собой. Разве CSO, CISO и/или администратор безопасности не понимает, что это просто симптомы опасной болезни? «Лечением» была бы разработка поэтапного плана внедрения корпоративной архитектуры безопасности. Основной целью этого плана является переход от процессов безопасности, ориентированных на технологии, к процессам безопасности, ориентированным на бизнес, связывающим административные, технические и физические защитные меры для надлежащего управления рисками и интегрирования этих процессов в ИТ-инфраструктуру, бизнес-процессы, организационную культуру компании.

Основная причина, по которой компании не разрабатывают и не внедряют корпоративную архитектуру безопасности, заключается в том, что они не полностью понимают что это такое, и это выглядит для них очень сложной задачей. Борьба с точечными «пожарами» более понятна и прямолинейна, поэтому многие компании остаются с этим простым подходом.

Если вы помните, в Домене 01 мы рассматривали внедрение программы безопасности, в которой описаны следующие задачи:
  • Планирование и Организация
    • Получение одобрения от руководства
    • Создание Руководящего комитета по надзору
    • Оценка бизнес-драйверов
    • Создание профиля угроз компании
    • Проведение оценки рисков
    • Разработка архитектуры безопасности на организационном, прикладном, сетевом и компонентном уровнях
    • Определение решений на каждом уровне архитектуры
    • Получение согласия руководства на дальнейшие действия
  • Функционирование и Поддержка
    • Соблюдение установленных процедур для обеспечения соблюдения базисных уровней в каждом реализованном проекте
    • Проведение внутренних и внешних аудитов
    • Выполнение задач, намеченных в каждом проекте
    • Управление соглашениями об уровне обслуживания по каждому проекту
  • Мониторинг и Оценка
    • Анализ лог-файлов, результатов аудита, собранных значений метрик и SLA по каждому проекту
    • Оценка достижения целей по каждому проекту
    • Проведение ежеквартальных встреч с руководящими комитетами
    • Совершенствование действий каждого этапа и их интеграция в фазу Планирования и Организации
Это является также и основными шагами внедрения корпоративной архитектуры безопасности, поскольку программа безопасности и архитектура безопасности должны следовать одной и той же модели. Программа безопасности часто основана на административных компонентах, также как и политики, стандарты, управление рисками, безопасность персонала, классификация данных и т.д. Обычно каждая основная концепция, рассмотренная в Домене 01, находит свое отражение в виде компонента программы безопасности. Корпоративная архитектура безопасности идет глубже, чем программа безопасности, и предоставляет больше деталей. Например, если политика безопасности требует, чтобы сетевое управление доступом было реализовано и внедрено, архитектура может рассматривать схему сети, отдельные зоны сети на основе уровня доверия и бизнес-потребностей, внешние подключения, механизмы безопасности, инструменты и роли, участвующие на каждом уровне. Архитектура работает от уровня политики до уровня компонентов.

В качестве аналогии скажем, что Шеннон говорит строителю, что он хочет дом в стиле ранчо с четырьмя спальнями общей площадью 2500 квадратных футов. Это высокоуровневое описание (политика) и строитель не собирается просто импровизировать и думать, что он сможет построить дом на основании такого наброска. Строитель будет следовать плану дома (архитектура), который предоставит более детализированные требования, которые должны быть учтены для выполнения запроса Шеннона.

Почти все хорошие корпоративные архитектуры безопасности работают тем или иным образом со структурой, предоставленной Моделью Захмана (Zachman Architecture Framework). Таблица 3-3 показывает состав этой модели (более полную информацию вы можете получить на сайте www.zifa.com). Модель Захмана на протяжении многих лет используется многими организациями для построения или лучшего определения своей бизнес-среды. Эта модель не является ориентированной на безопасность, но это хороший шаблон для использования, поскольку он дает направление, как понять реальное предприятие модульным способом.

Таблица 3-3. Модель Захмана для Корпоративной архитектуры

ПРИМЕЧАНИЕ. Модель Захмана используется в качестве модели для надежной архитектуры безопасности, т.е. работающей со многими компонентами всей организации. Многие люди знакомы с техническими архитектурами безопасности, которые имеют дело просто с сетями и системами в рамках этой сети. Это две совершенно разные вещи. Надежная архитектура безопасности включает в себя техническую архитектуру и многое другое, как вы можете видеть в Таблице 3-3.
Модель Захмана является двумерной, она использует шесть основных вопросов (communication interrogatives) (Что, Как, Где, Кто, Когда и Почему), пересекающихся с различными уровнями (Планировщик, Владелец, Конструктор (архитектор), Проектировщик, Разработчик и Сотрудник), чтобы дать целостное представление о предприятии. Эта модель была разработана в 1980-х годах, она основывается на принципах классической архитектуры бизнеса, которые содержат правила, управляющие упорядоченным множеством отношений.

Исходя из опыта автора, большинство технических людей негативно относятся к моделям, таким, как эта. Они считают, что здесь слишком много работы, очень много «воды», что это не имеет прямого отношения к их задачам и т.д. Они сфокусированы на технологиях и не понимают все остальные компоненты безопасности, которые являются не менее (а, возможно, более) важными, чем технологии.
SABSA. Независимо от Модели Захмана была разработала модель и методология SABSA (Sherwood Applied Business Security Architecture – Шервудская прикладная архитектура безопасности бизнеса). Она показана в следующей таблице. Вы можете посетить сайт www.sabsa-institute.org/home.aspx, чтобы узнать больше об этом подходе. На экзамене CISSP модель SABSA не рассматривается.
Работа на корпоративном уровне требует совершенно иного мышления, чем работа исключительно на системном или техническом уровне. Мало того, что решения должны применяться ко всей компании стандартизованным образом, они должны быть связаны с потребностями бизнеса. Например, когда вы думаете об управлении доступом, а не просто о Kerberos, контроллерах домена, ACL и полномочиях, вам нужно также принимать во внимание те требования регуляторов и законодательства, которые компания должна соблюдать. Если эта компания должна соблюдать требования SOX, она нуждается в том, чтобы многие из этих процессов (управления доступом) были документированы, а доступ предоставлялся только с разрешения руководителей. Это может потребовать внедрения полноценных решений по управлению идентификацией – доменной аутентификации, реализованной в продуктах Microsoft, может быть недостаточно.

В процессе разработки корпоративной архитектуры безопасности, должны быть поняты и учтены следующие вопросы: стратегическое выравнивание, обеспечение бизнеса, улучшение процессов, эффективность безопасности.

Стратегическое выравнивание (strategic alignment) относится к обеспечению соблюдения архитектурой безопасности требований бизнес-драйверов, регуляторов и законодательства. Текущее состояние безопасности должно быть понятно, для чего должна быть проведена оценка рисков, позволяющая компании понять свои актуальные угрозы, а также свои способности бороться с этими угрозами. Следует достичь консенсуса в отношении уязвимостей и угроз компании, приемлемый для компании уровень риска должен быть установлен на основе толерантности компании к рискам. Прекрасно, но что все это означает? Попробуем выразить это проще. Стратегическое выравнивание означает «Какие активы мы должны защищать?», «Насколько наши инициативы в области безопасности связаны с реальными потребностями бизнеса?», «Что подразумевается под "достаточной безопасностью"?», и «Высшее руководство участвует во всем этом?».

Результатом этих усилий является выработка согласованного текущего профиля рисков и желаемого профиля. Следует разработать трехлетний план безопасности, в котором должно быть определено, каким образом компания будет двигаться и достигать желаемого профиля. Также в этом плане следует детализировать поэтапный подход к построению безопасности (в целом) компании.
ПРИМЕЧАНИЕ. Хотя приведенная выше информация может показаться очевидной, это действительно то, что должно быть предпринято компанией в первую очередь. К сожалению, многие компании просто начинают подключать межсетевые экраны, настраивать ACL и внедрять решения по шифрованию без создания общего плана. Получается, что все заняты, но зачастую все идут различными путями, не согласовав между собой цели, над которыми должен работать каждый.
Несколькими другими вещами, которые нужно учесть на этом стратегическом этапе, являются:
  • Определить заинтересованных лиц и их потребности
  • Определить владельцев и ответственных за хранение, распределить ответственность
  • Определить и распределить обязанности, подотчетность и полномочия
Высшее руководство должно принимать активное участие на этом этапе и предоставлять необходимые ресурсы и поддержку. Без поддержки руководства, усилия будут вялыми, и никаких реальных успехов достичь не удастся.

Глядя на часть архитектуры, связанную с обеспечением бизнеса (business enablement), мы должны напомнить себе, что любая коммерческая компания находится в бизнесе, чтобы заработать деньги. Не существует коммерческих компаний, единственной целью которых является обеспечение своей безопасности. Безопасность не может стоять на пути бизнес-процессов, она должна быть реализована, чтобы обеспечивать потребности бизнеса, повышать его эффективность, участвовать в создании бизнес-продуктов. Многие из критически важных бизнес-процессов имеют дело с транзакциями, целостность которых должна быть обеспечена от начала до конца. В связи с этим безопасности уделяется повышенное внимание, т.к. именно обеспечение безопасности должно позволить осуществлять соответствующую бизнес-деятельность.

Обеспечение бизнеса означает, что ключевые бизнес-процессы интегрируются в операционную модель безопасности, они основываются на стандартах и учитывают критерии толерантности рисков. Что это означает в реальной жизни? Например, бухгалтерия компании рассчитала, что если компания организует работу на дому персонала обслуживания и поддержки клиентов, это позволит компании сэкономить существенные деньги на аренде офиса, коммунальных услугах и т.д., к тому же страхование работающих на дому сотрудников стоит дешевле. Компания может перейти в эту новую модель с использованием VPN, межсетевых экранов, контентной фильтрации и т.п. Другой пример – финансовая компания хочет позволить своим клиентам просматривать информацию о своих банковских счетах и осуществлять финансовые транзакции. Она может предложить такую услугу клиентам только в том случае, если будут внедрены все необходимые механизмы безопасности. Безопасность должна помогать компании процветать, предоставляя ей механизмы, позволяющие безопасно решать новые задачи.

Часть, связанная с улучшением процессов (process enhancement), может быть весьма полезной для компании, если она правильно использует эту возможность. Если компания серьезно относится к обеспечению безопасности своей среды, она должна пристально взглянуть на многие бизнес-процессы, выполняющиеся на постоянной основе. Хотя при этом бизнес-процессы рассматриваются через призму безопасности, это является также прекрасной возможностью для усовершенствования и улучшения этих процессов с целью повышения их эффективности. Если вы проанализируете бизнес-процессы, происходящие в компаниях любого типа, часто вы найдете факты дублирования одинаковых действий, выполняющиеся вручную операции, которые можно легко автоматизировать и т.п. Помимо обеспечения безопасности этих процессов, вы можете предложить пути повышения их эффективности, сокращения времени и ресурсов, необходимых для их выполнения. Это обычно называют реинжинирингом процессов.

Когда компания разрабатывает проекты по обеспечению своей безопасности, эти проекты должны интегрироваться в бизнес-процессы, чтобы быть эффективными. Это позволит интегрировать безопасность в жизненные циклы систем и ежедневные операции. Также это может позволить компании параллельно усовершенствовать и откалибровать управление процессами.

Эффективность безопасности (security effectiveness) связана с метриками, соблюдением требований SLA, возвратом инвестиций (ROI – return on investment), соблюдением набора базисов и предоставлением руководству отчетов с указанием всех основных показателей безопасности. Это позволяет определить, насколько полезны текущие решения по безопасности и архитектура безопасности при их комплексной работе.

Многие компании уже дошли до этой точки в своей архитектуре, поскольку существует необходимость в том, чтобы убедиться, что внедренные контрмеры обеспечивают необходимый уровень защиты, а ограниченный бюджет используется надлежащим образом. После установки базисов можно разработать метрики для проверки соответствия их требованиям. Затем эти метрики предоставляются руководству в формате, позволяющим ему понять текущее состояние безопасности компании и уровень ее соответствия требованиям. Также это должно предоставлять руководству компании дополнительную информацию для принятия бизнес-решений. Безопасность сегодня затрагивает почти все в бизнесе, поэтому эта информация должна быть доступна высшему руководству в форме, которую руководство может реально использовать.

Рисунок 3-20 показывает, как компании обычно развивают зрелость своей безопасности.

Рисунок 3-20. Управление ИТ-безопасностью и Модель зрелости функционирования ИТ

Все эти элементы (стратегическое выравнивание, обеспечение бизнеса, улучшение процессов и эффективность безопасности) могут существовать только при наличии прочного фундамента поддерживающих проектов по безопасности. Проекты намечают актуальные механизмы безопасности, которые будут использоваться для обеспечения необходимого компании уровня защиты. Среди таких проектов может быть управление доступом, управление идентификацией, управление активами, реагирование на инциденты, инфраструктура безопасности, безопасность приложений и т.п. Без прочного фундамента безопасности ни одна из целей реально не может быть достигнута. Это все равно, что пытаться построить дом на песке.
ПРИМЕЧАНИЕ. Фундамент корпоративной безопасности не может быть построен без установленных зон безопасности, которые предоставляют основанные на доверии границы, определяющие, что на самом деле должно быть защищено. Это позволяет реализовывать защиту и управление рисками стандартизированным образом в рамках всей компании.
Автор: eagle на 22:23
Ярлыки: ,
Подписаться на: Комментарии к сообщению (Atom)