2. Мониторинг взаимодействий

Регламентирует порядок взаимодействия между компонентами системы и прохождением информационных потоков через ЯЗ.

Реализация политики безопасности будет эффективна только в том случае, если все без исключения взаимодействий в системе, т. е. доступ к объектам, ресурсам и сервису осуществляются при обязательном посредничестве ТСВ. (Следовательно, требуется, чтобы ядро защиты представляло собой МБО).

3. Логическая защита яз

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

Необходимо заметить, что политика безопасности, мониторинг взаимодействий и логическая защита ЯЗ является обязательными компонентами всех профилей защиты вне зависимости от назначения и среды применения ПИТ.

4. Физическая защита яз

Она задает ограничение на физический доступ к компонентам ЯЗ, а также допустимые физические параметры среды функционирования АС.

5.  Самоконтроль ЯЗ 

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

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

6.  Инициализация и восстановление ЯЗ 

Эти требования устанавливают возможности ЯЗ по контролю за процессом собственной инициализации и способности к самовосстановлению после сбоев.

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

Восстановленное состояние ЯЗ должно соответствовать требованиям политики безопасности, мониторинга взаимодействий и самоконтроля целостности.

7.  Ограничение привилегий при работе с ЯЗ 

Эти требования устанавливают порядок назначения полномочий для работы с ЯЗ.

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

8.  Простота использования ЯЗ 

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

К этому классу требований относятся:

• порядок реагирования ЯЗ на ошибки в действиях пользователей и попытки нарушения безопасности;

• устанавливаемые по умолчанию полномочия;

• интерфейс пользователей и администратора. 

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

Ранжирование функциональных требований

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

• широта сферы применения;

• степень детализации;

• функциональный состав средств защиты;

• обеспечиваемый уровень безопасности.

Широта сферы применения определяется множеством сущностей, к которому могут быть применены данные требования, а именно:

• пользователи системы, субъекты и объекты доступа;

• функции ЯЗ и интерфейс взаимодействия с ЯЗ;

• аппаратные, программные и специальные технологии ЯЗ;

• множество параметров конфигурации ЯЗ.

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

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

Обеспечиваемый уровень безопасности определяется условиями, в которых функциональные компонента ЯЗ способны противостоять заданному множеству угроз; отказом и сбоем. Например, нормативное управление доступом обеспечивает более высокий уровень безопасности, чем произвольное.

Ранжирование всегда предполагает установление некоторого отношения порядка.

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

В связи с этим в «Федеральных критериях» отсутствуют рекомендации как по выбору к применению тех или иных функциональных требований, так и по определению их роли в системе обеспечения безопасности. Вместо жестких указаний этот документа содержит согласованный с предшествующими ему стандартами («Оранжевая книга», «Европейские критерии») ранжированный перечень функциональный требований и представляет разработчиком профиля защиты возможность самостоятельно сделать выбор необходимых методов и средств обеспечения безопасности, основанный на назначении специфике среды эксплуатации ПИТ.

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

Данный раздел регламентирует процесс содержания, тестирования, документирования и сопровождения ПИТ.

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

«Федеральные критерии» содержат ранжированный перечень типовых требований к технологии разработки ПИТ. Выполнение этих требований является необходимых условием для проведения процедуры сертификации.

Требования к процессу сертификации продукта информационных технологий

Раздел содержит три группы требований, регламентирующих анализ, контроль и тестирование ПИТ.

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

Выводы: «Федеральные критерии безопасности информационных технологий» являются первым стандартом в области безопасности систем обработки информации, в котором определены и рассмотрены три независимые группы требований:

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

• требования с технологии разработки ПИТ;

• требования к процессу сертификации.

Авторами этого документа предложена концепция профиля защиты – документа, содержащего полное описание всех требований безопасности к процессам разработки, сертификации и эксплуатации ПИТ.

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

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