Методологии построения систем безопасности

2.4 Метод построения решений для обеспечения безопасности (MASS, Method for Architecting Secure Solutions)

У IBM есть метод, который используется сотрудниками IBM Global Services (IGS) для создания систем безопасности. Он называется методом по разработке решений безопасности (MASS, Method for Architecting Secure Solutions). Он помогает проанализировать и разложить по категориям связанные с безопасностью проблемы и обсуждения в нынешнем электронном бизнесе, управляемом корпоративными ИТ-инфраструктурами. Содержание этого раздела изначально было вынесено в специальное издание журнала по системам IBM о сквозной безопасности (IBM Systems Journal on End-to-End Security, Volume 40, N 3). Эта статья находится по следующему адресу:

http://www.research.ibm.com/journal/sj/403/whitmore.html

2.4.1 Постановка задачи

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

В IBM Global Services требования к методу по дизайну решений безопасности обусловлены следующими моментами:

1. Необходимость "растить" сообщество ИТ-архитекторов с общей специализацией в области безопасности.
2. Необходимость создания успешного взаимодействия между несколькими техническими дисциплинами в пределах профессии ИТ-архитектора касательно вопросов безопасности.
3. Необходимость разработки совместимых дизайнов, поскольку многие сферы деятельности и организации имеют сходные требования к совместимости решений относительно безопасности и защиты собственности, основанные на законах, постановлениях и производственной необходимости; кроме того, многие корпорации являются многонациональными, разнесенными географически структурами, оперирующими одинаковыми методами и политиками безопасности.

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

Логичный и систематический метод для разработки решений безопасности имеет потенциальную ценность не только для IBM Global Services, но и для следующих категорий пользователей:

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

2.4.2 Анализ

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

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

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

1. Пространство задач безопасности нестабильно в том, что количество и вид угроз продолжает нарастать и видоизменяться.
2. У существующих систем готовых решений в сфере безопасности ограниченный взгляд на пространство задачи, как, например, в брандмауэрах [4] и безопасности сетевого уровня [5].
3. Методы для создания архитектур решений безопасности обычно ограничены предопределенным набором систем готовых решений. Для таких трудно определяемых пространств задач, как ИТ-безопасность, к пути взросления моделей и методов требуется иной подход.

Специфичные для безопасности таксономии, модели и методы

Стандарт ISO 7498-2[6] является широко используемым документом на тему дизайна решений ИТ-безопасности. Его цель состоит в том, чтобы расширить применимость семиуровневой системной модели OSI (Open Systems Interconnection, взаимодействие открытых систем) до возможностей безопасных коммуникаций между системами. Раздел 5 этого документа описывает набор служб и механизмов системы безопасности, который мог бы быть реализован на соответствующем уровне системной модели OSI в соответствующих сочетаниях для удовлетворения требованиям политики безопасности. В разделе 8 говорится о необходимости непрерывного управления службами и механизмами безопасности OSI, куда входит управление криптографическими функциями, маскирование сетевого трафика и обработка событий.

Многие специалисты в сфере безопасности используют службы безопасности OSI: аутентификацию, контроль доступа, конфиденциальность данных, целостность данных и невозможность отказа от авторства – как полную таксономию для требований безопасности ИТ-решений. Однако в преамбуле к ISO 7498-2 особо подчеркивается, что "система безопасности OSI не занимается мерами безопасности, которые требуются в конечных системах, установках и организациях, кроме тех случаев, когда подразумевается, что выбор и размещение служб безопасности видятся в OSI. Эти последние аспекты безопасности могут быть стандартизированы, но не в рамках рекомендаций OSI".

Критерии оценки безопасности. Агентства и комитеты по стандартам в правительствах нескольких стран разработали оценочные критерии для безопасности компьютерной технологии. В Соединенных Штатах этот документ называется "Критерии оценки безопасности надежных компьютерных систем" (TCSEC, Trusted Computer System Security Evaluation Criteria). Европейская Комиссия опубликовала Критерии оценки безопасности информационных технологий, известные как ITSEC (Information Technology Security Evaluation Criteria), а канадское правительство опубликовало Критерии оценки надежных канадских компьютерных продуктов, или CTCPEC (Canadian Trusted Computer Product Evaluation Criteria). В 1996 г. эти начинания были официально объединены в единый документ, известный как Общие критерии, или CC (Common Criteria) [7]. В 1999 г. данный документ был принят Международной организацией по стандартизации в качестве стандарта [7-9]. Этот шаг открывает дорогу взаимному пониманию результатов оценки продуктов во всем мире.

Общие критерии

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

В Общих критериях 11 функциональных классов требований:

• аудит системы безопасности;
• коммуникации;
• поддержка криптографии;
• защита пользовательских данных;
• идентификация и аутентификация;
• управление функциями безопасности;
• приватность;
• защита функций безопасности;
• использование ресурсов;
• доступ к компонентам;
• надежные пути и каналы.

Эти 11 функциональных классов далее разбиты еще на 66 семейств, каждая из которых содержит набор компонентных критериев. В настоящий момент задокументировано порядка 130 компонентных критериев с оглядкой на то, что дизайнеры могут добавить в конкретный дизайн какие-то дополнительные компонентные критерии. Для проведения компонентных критериев через административные органы Общих критериев существует формальная процедура, которую можно найти по адресу:

http://www.commoncriteria.org

Правительства и индустриальные группы при помощи Общих критериев разрабатывают функциональные описания для оборудования и программного обеспечения безопасности. Эти документы, известные как профили защиты [10], описывают группирование функций безопасности, соответствующих данному компоненту или технологии безопасности. Одна из основных мотиваций для разработки профилей защиты – желание поставщиков предоставить в своих продуктах безопасности стандартную функциональность и уменьшить риск при поставке информационной технологии. Вместе с работой по определению профилей защиты производители связанных с безопасностью компонентов компьютерного оборудования и программного обеспечения создают документацию, которая объясняет функциональность их продуктов относительно принятых профилей защиты. Эта документация называется "Цели безопасности". Производители могут передать свои продукты и цели безопасности на оценку независимым лицензированным организациям-тестировщикам для получения сертификатов совместимости.

Общие критерии как таксономия для требований/решений

Определенные в Общих критериях требования к безопасности имеют международную поддержку как "лучшие практики". Общие критерии предназначены в качестве стандарта для оценки функциональности безопасности в продуктах. Но у них есть ограничения в описании полной сквозной системы безопасности: поскольку функциональные требования применяются к конкретным продуктам, их использование в сложных ИТ-решениях неочевидно [11]. Профили защиты помогают при описании системы готовых решений, хотя каждый профиль защиты и ограничен пределами спецификации функций, находящихся в том или ином аппаратном или программном продукте.

Общие критерии как эталонная модель

Общие критерии вводят несколько архитектурных конструкций [8]: цель оценки (или TOE, Target Of Evaluation) представляет компонент в стадии разработки; документация по функциям безопасности TOE (или TSF, TOE Security Functions) представляет ту часть TOE, которая ответственна собственно за безопасность. По Общим критериям рассматриваемая система или компонент является "черным ящиком"; он демонстрирует только некоторую функциональность в плане безопасности и некоторые защитные механизмы для встроенных функций безопасности.

Резюме анализа

Для хорошо понятных пространств задач методы документируют предыдущую работу и обеспечивают лучшими практиками к последующему анализу. Для постоянно изменяющихся пространств задач, вроде ИТ-безопасности, методы могут только постулировать непротиворечивую систему отсчета для практикующих специалистов, чтобы сподвигнуть их на разработку будущих лучших практик. При наличии времени и опыта методы и модели, связанные с ИТ-безопасностью, будут выработаны.

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

Чтобы выработать гибкий метод для разработки решений безопасности, требуется дополнительная работа по выработке:

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