Задание требований безопасности информации и оценка соответствия им согласно ГОСТ 15408—2002

В результате многолетней деятельности ряд развитых стран выработал «Общие критерии оценки безопасности компьютерных систем». Документ получил статус Международного стандарта 180/1ЕС в 1999 г. Гостехкомиссия приняла решение выполнить аутентичный перевод этого стандарта и принять его в качестве государственного, что и было сделано в 2002 г. С января 2004 г. данный стандарт вступил в действие. (В дальнейшем изложении мы используем для его обозначения аббревиатуру ОК.)

Разработчики стремились достичь универсальности в предъяв­лении критериев оценки безопасности информационных техно­логий, отсюда и название — «общие». Эта универсальность про­является в том, что объектом оценки (ОО) может быть изделие информационных технологий ИТ, в качестве которого могут вы­ступать продукт ИТ и система ИТ, а также автоматизированная система (АС). На рис. 19.2 приведены разновидности ОО соглас­но ОК.

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

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

Во втором случае к ОО предъявляются требования, на соответ­ствие которым он будет в дальнейшем проверяться. Как и в пер­вом случае, требования предъявляются в ПЗ и ЗБ. ЗБ должно раз­рабатываться перед проведением оценки ОО.

Рис. 19.2. Разновидности ОО согласно ОК

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

Можно выделить такие предположения о среде ОО:

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

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

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

В настоящее время ФСТЭК планирует создать каталог угроз, из которого разработчики могли бы выбирать актуальные для них угрозы. В тексте стандарта приведены лишь отдельные угрозы.

На основании предположений о среде формулируются цели безопасности для ОО, направленные на обеспечение противосто­яния угрозам и выполнение политики безопасности. В зависимо­сти от непосредственного отношения к ОО или к среде они под­разделяются на две группы. Часть целей для среды может дости­гаться нетехническими (процедурными) мерами. Все остальные (для объекта и среды) носят программно-технический характер. Для их достижения к объекту и среде предъявляются требования безопасности.

«Общие критерии» в главной своей части (Часть 2) как раз и являются каталогом требований безопасности. Всего перечислено 135 функциональных требований. Требования достаточно детали­зированы, что делает их конкретными и допускающими одно­значную проверку. Большинство требований параметризовано, т.е. к ним применимы такие операции, как уточнение какого-либо значения (например, требуемого количества символов в пароле), выбор одной возможности из нескольких.

Кроме того, к ОО могут предъявляться и нестандартные, не входящие в каталог требования, что тоже предусмотрено стандар­том.

Для структуризации пространства требований в «Общих кри­териях...» введена иерархия класс—семейство—компонент—эле­мент. Классы определяют наиболее общую (как правило, пред­метную) группировку требований. Семейства в пределах класса различаются по строгости и другим характеристикам требований. Компонент — минимальный набор требований, фигурирующий как целое. Элемент — неделимое требование.

Между компонентами могут существовать зависимости. Они возникают, когда компонент сам по себе недостаточен для дос­тижения цели безопасности. Соответственно при включении та­кого компонента необходимо добавить всю «гроздь» его зависи­мостей.

Как вспомогательный элемент, упрощающий создание ПЗ и ЗБ, могут применяться функциональные пакеты (ФП) — неодно­кратно используемые совокупности компонентов, объединенных для достижения установленных целей безопасности.

«Общие критерии...» содержат два основных вида требований безопасности: функциональные и требования доверия. Требова­ния доверия предъявляются к технологии и процессу разработки и эксплуатации ОО и представлены в Части 3 ОК. Сформулиро­вав функциональные требования, требования доверия и требова­ния к среде, можно приступать к оценке безопасности готового изделия ИТ.

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

При проведении оценки изделия ИТ проверяется соответствие функций безопасности ОО функциональным требованиям и кор­ректность их реализации.

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

В зависимости от принятых мер поддержки доверия (но не от набора механизмов безопасности) все изделия ИТ группируются в семь оценочных уровней доверия (ОУД). Сертификация вы­полняется как раз на соответствие тому или иному уровню дове­рия.

Сертификация изделия ИТ двухступенчатая. Вначале оценива­ется задание по безопасности, затем само изделие — на соответ­ствие этому заданию. За последние три года в России сертифици­ровано несколько изделий на соответствие ГОСТ 15408 — 2002. В основном это изделия иностранного производства.