Заключение

"Общие критерии" и профили защиты на их основе

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

Эта цель близка и понятна российским специалистам. В 2002 году был официально издан ГОСТ Р ИСО/МЭК 15408-2002 "Критерии оценки безопасности информационных технологий" с датой введения в действие первого января 2004 г. Таким образом, и Россия фактически живет по " Общим критериям " со всеми вытекающими из данного факта последствиями.

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

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

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

" Общие критерии " содержат два основных вида требований безопасности:

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

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

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

Рассматриваемые в курсе профили делятся на следующие категории:

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

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

• идентификация (FIA_UID) и аутентификация (FIA_UAU);
• определение атрибутов пользователя (FIA_ATD);
• связывание пользователь-субъект (FIA_USB);
• политика управления доступом (FDP_ACC);
• функции управления доступом (FDP_ACF);
• генерация данных аудита безопасности (FAU_GEN);
• анализ аудита безопасности (FAU_SAA);
• управление криптографическими ключами (FCS_CKM);
• криптографические операции (FCS_COP);
• базовая защита внутренней передачи (FDP_ITT);
• защита остаточной информации (FDP_RIP);
• целостность экспортируемых данных (FPT_ITI);
• управление отдельными функциями безопасности (FMT_MOF);
• управление данными функций безопасности (FMT_MTD);
• безопасность при сбое (FPT_FLS);
• надежное восстановление (FPT_RCV);
• посредничество при обращениях (FPT_RVM);
• разделение доменов (FPT_SEP);
• доверенный канал передачи между функциями безопасности (FTP_ITC);
• доверенный маршрут (FTP_TRP).

В качестве важнейших общих требований доверия безопасности выделяются:

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

Профили защиты и их проекты, рассматриваемые в курсе, применимы к следующим сервисам безопасности:

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

Изучаются также инфраструктурные элементы информационной безопасности:

• анонимизаторы;
• выпуск и управление сертификатами.

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

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

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

Важнейшей (и наиболее привычной) комбинацией сервисов безопасности являются операционные системы. Как таковые они содержат лишь небольшое число специфических требований, среди которых выделяются:

• максимальные квоты (FRU_RSA.1);
• дополнительный элемент FAU_GEN.1-CSPP.3, предписывающий предоставление прикладного программного интерфейса для добавления собственных данных к общему регистрационному журналу и/или для ведения приложениями собственных журналов;
• ряд дополнительных требований, направленных на обеспечение конфиденциальности (FPT_ITC.1.1-CSPP), целостности (FPT_ITI.1.1-CSPP), согласованности (FPT_SYN-CSPP.1.1) критичных данных функций безопасности в распределенных конфигурациях.

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

Весьма поучителен профиль защиты для смарт-карт, при его изучении можно усмотреть множество аналогий со стандартом FIPS 140-2 " Требования безопасности для криптографических модулей". И профиль, и стандарт - хорошие примеры систематического подхода к вопросам собственной защищенности средств безопасности.

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

• автоматическая реакция аудита безопасности (FAU_ARP);
• противодействие физическому нападению (FPT_PHP.3).

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

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

По результатам рассмотрения ОК можно наметить следующие направления дальнейших исследований и разработок:

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