Некоторые выводы
"Общие критерии" - исключительно мощное, гибкое средство разработки требований безопасности для изделий информационных технологий. В частности, могут быть выделены общие требования к сервисам безопасности, а также учтена специфика конкретных сервисов, фигурирующих по отдельности или в различных комбинациях.
В то же время, сама гибкость "Общих критериев" - источник сложных проблем, в первую очередь относящихся к методологии разработки профилей защиты. Можно провести аналогию с языками и технологией программирования, когда владение передовым языком программирования вовсе не означает умения проектировать и создавать большие программные комплексы.
Вопросы технологии "программирования" профилей защиты носят разнообразный характер и затрагивают все этапы жизненного цикла ПЗ. Какой подход выбрать при разработке ПЗ: "снизу вверх" или "сверху вниз"? Сами "Общие критерии", имеющие библиотечную (не объектную) структуру, подталкивают к применению подхода "снизу вверх", от отдельных требований к общей функциональности. Однако, как показывает опыт разработчиков профиля [48] (равно как и технология программирования), наиболее предпочтителен подход "сверху вниз", от требуемой функциональности объекта оценки к базовым механизмам безопасности.
Еще один технологический аспект - модульность ПЗ. Выделение функциональных пакетов для составных частей объекта оценки, реализованное в [80], дает больше свободы и разработчикам, и интеграторам, способствует раннему выявлению и устранению проблем, облегчает деятельность оценщиков.
Следующий вопрос касается технологии сопровождения множества профилей защиты. Как соотносить между собой отдельные ПЗ? Как группировать их, выстраивать иерархии и т.п.? Пока зарегистрированных профилей относительно немного (что само по себе является проблемой, но, можно надеяться, временной), и все-таки очевидно, что их число будет расти, они станут поступать из различных источников, из разных стран, так что поддержание международного статуса "Общих критериев", несомненно, потребует специальных усилий, которые целесообразно планировать заранее (см. соглашение "О признании сертификатов по Общим критериям в области безопасности информационных технологий").
Очень серьезная проблема - неполнота функциональных требований "Общих критериев". Как показывают рассмотренные профили, авторам ПЗ приходится добавлять собственные нестандартные классы, семейства, компоненты и элементы, что ведет к несопоставимости разрабатываемых профилей, к усложнению процедур сертификации и взаимного признания сертификатов.
Принципиальный недостаток - отсутствие в "Общих критериях" архитектурных и технологических требований. Такие свойства, как распределенность архитектуры, следование подходу менеджер/агент и т.п., необходимы для успешной реализации функций объекта оценки, они критичны для его безопасности.
Таким образом, проведенный анализ позволяет наметить следующие направления дальнейших исследований и разработок:
- создание новых профилей защиты, охватывающих все сервисы безопасности;
- разработка методологии и соответствующих инструментальных средств создания ПЗ;
- разработка дисциплины и инструментальных средств для использования множества профилей защиты;
- развитие "Общих критериев", разработка новых стандартных требований безопасности, как "точечных", так и концептуальных, архитектурных;
- разработка дисциплины введения новых нестандартных требований с минимизацией проблем несопоставимости получающихся профилей защиты.
Для решения сформулированных проблем необходимо взаимодействие специалистов, независимо от их национальной и, тем более, ведомственной принадлежности.
<
