Требования безопасности

В 2007-2009 гг. в республике действовал предварительный стандарт СТБ П 34.101.27. В 2011 г. этот предстандарт был переведен в статус стандарта СТБ 34.101.27 «Информационные технологии и безопасность. Требования безопасности к программным средствам криптографической защиты информации».

Корректировка СТБ П 34.101.27 проводилась по следующим направлениям.

1. Требования безопасности к программным средствам криптографической защиты информации (ПСКЗИ) изложены не в виде профиля защиты согласно СТБ 34.101.1–3 (Общие критерии, ОК), а в более ясном для разработчиков и потребителей виде, который лучше подходит для криптографических средств.
2. В СТБ П 34.101.27 к ПСКЗИ отнесены программные средства, которые выполняются на компьютерах общего назначения (персональных компьютерах, серверах). В СТБ 34.101.27 класс программно-аппаратных платформ ПСКЗИ расширен, дополнительно учтены смарт-карты, токены, мобильные устройства.
3. Введено 2 класса ПСКЗИ. К средствам первого класса выдвигается базовый набор требований, к средствам второго – усиленный.
4. В СТБ П 34.101.27 для защиты объектов разрешается использовать только криптографические методы. При этом для защиты ключа требуется использовать другой ключ. Если последний ключ также нужно защищать, то для этого должен использоваться новый ключ и так далее. В СТБ 34.101.27 дополнительно к криптографическим методам защиты разрешено использовать аппаратные методы и методы разделения секрета, которые позволяют прервать цепочку защиты ключей защиты других ключей.
5. В СТБ 34.101.27 введена модель состояний ПСКЗИ, уточнены требования по аутентификации, генерации случайных чисел, защите от утечек по побочным каналам и по другим средствам безопасности.
6. В СТБ 34.101.27 определяется конкретное содержание функциональной спецификации ПСКЗИ и дается пример функциональной спецификации для гипотетического программного средства. Пример является достаточно информативным и позволит разработчикам упростить проектирование и описание средств безопасности своих продуктов.

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

Объясним причины нашего отступления от ОК.

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

Слишком общие критерии. Логика развития ОК, попытка учесть всевозможные случаи и максимально все формализовать привела к тому, что формулировки требований безопасности, точнее шаблонов требований, во 2- и 3-й частях ОК стали чересчур общими. При этом трудно сформулировать вполне понятные требования, используя шаблоны ОК. Приходится давать обширные комментарии, изменять шаблоны или вводить новые (отметим, что в ОК всякое изменение шаблона или добавление нового должно быть строго обосновано). Трудности увеличиваются из-за недостатков перевода ОК на русский язык.

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