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

2.4.3 Системная модель безопасности

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

Для целей нашего проекта тип рассматриваемых ИТ-решений совместим с сетевой информационной системой (NIS, Networked Information System). Более того, общая архитектура представлена архитектурой безопасности, находящейся внутри NIS, а архитектура безопасности представлена структурой системной модели безопасности. С обобщенной системной моделью для безопасности в NIS-окружении архитекторы могли бы создавать такие системные модели, которые основывались бы на детальных требованиях к управлению функциональностью и риском. Рехтин выделяет шаги для создания модели следующим образом:

1. Объединение тесно связанных функций.
2. Разделение или сведение модели к ее составным частям.
3. Подгонка или сбор компонентов и подсистем вместе в единую работающую систему.

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

В нашем проекте Общие критерии рассматривались как описание законченной функции модели системы безопасности. Классы и семейства в Общих критериях являются объединением требований; однако после тщательного рассмотрения было определено, что описанные в Общих критериях структуры классов и семейств не позволяют использовать себя как часть таксономии для всеохватывающей безопасности. Объединение больше подходит абстрактным вопросам безопасности, таким, как криптографические операции и защита данных, нежели безопасности в контексте работающей ИТ-функции. Для целей этого проекта функциональные критерии Общих критериев были пересмотрены и пересобраны, при этом были убраны структуры классов и семейств. Анализ 130 требований компонентного уровня по отношению к их функции в NIS-решении предполагает разбиение на пять операционных категорий: аудит, контроль доступа, контроль потока, подлинность и мандаты, целостность решения. Суммарная топография CC-классов по функциональным категориям приведена в табл. 2.1.

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

2.4.4 Подсистемы безопасности

Руководство по уровню компонентов Общих критериев документирует правила, критерии принятия решений, функции, действия и механизмы. Эта структура поддерживает утверждение, что пять категорий, описанных в табл. 2.1, представляют набор взаимосвязанных процессов, или подсистем, для системы безопасности. Идея подсистемы безопасности уже была предложена ранее; авторы книги "Доверие в киберпространстве" описали функции в компонентах контроля доступа в операционную систему как принадлежащие к подсистеме принятия решений или к правоприменительной подсистеме. Пять предложенных здесь и показанных на рис. 2.4 взаимосвязанных подсистем безопасности расширяют концепцию операционной системы и предполагают, что функция и взаимозависимость связанных с безопасностью функций, сверх централизованного контроля доступа, могут быть также смоделированы.

Рис. 2.4. Процессы и подсистемы системы ИТ-безопасности

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

Подсистема аудита безопасности

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

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

Замкнутый процесс подсистемы аудита безопасности представлен на рис. 2.5.

увеличить изображение
Рис. 2.5. Процессы подсистемы аудита безопасности

Подсистема целостности решения

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

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

Замкнутый процесс для подсистемы целостности решения представлен на рис. 2.6.

увеличить изображение
Рис. 2.6. Процессы подсистемы целостности

Подсистема контроля доступа

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

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

Замкнутый процесс для подсистемы контроля доступа представлен на рис. 2.7.

увеличить изображение
Рис. 2.7. Процессы подсистемы контроля доступа