ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 06.12.2020
Просмотров: 4106
Скачиваний: 24
средств СЗИ НСД, их периодическое обновление и контроль ра
ботоспособности .
Представленный перечень является тем минимумом требова
ний, которым необходимо следовать, чтобы обеспечить конфи
денциальность защищаемой информации.
19.4. Задание требований безопасности
информации и оценка соответствия им
согласно ГОСТ 15408—2002
В результате многолетней деятельности ряд развитых стран
выработал «Общие критерии оценки безопасности компьютерных
систем». Документ получил статус Международного стандарта
ISO/IEC в 1999 г. Гостехкомиссия приняла решение выполнить
аутентичный перевод этого стандарта и принять его в качестве
государственного, что и было сделано в 2002 г. С января 2004 г.
данный стандарт вступил в действие. (В дальнейшем изложении
мы используем для его обозначения аббревиатуру ОК.)
Разработчики стремились достичь универсальности в предъяв
лении критериев оценки безопасности информационных техно
логий, отсюда и название — «общие». Эта универсальность про
является в том, что объектом оценки (ОО) может быть изделие
информационных технологий ИТ, в качестве которого могут вы
ступать продукт ИТ и система ИТ, а также автоматизированная
система (АС). На рис. 19.2 приведены разновидности ОО соглас
но ОК.
Продукт ИТ — совокупность средств ИТ, предоставляющая
определенные функциональные возможности и предназначенная
для непосредственного использования или включения в различ
ные системы.
Возможны два сценария проведения оценки: оценка уже суще
ствующего ОО и создаваемого. В первом случае считается, что ОО
может быть доработан по результатам оценки (правда, при этом
Рис. 19.2. Разновидности ОО согласно ОК
опускаются важные моменты: кем и каким образом доработан).
На имеющийся 0 0 создается профиль защиты (ПЗ), содержащий
общие положения по безопасности, либо ПЗ выбирается из мно
жества существующих. Далее на основе ПЗ создается задание по
безопасности (ЗБ), в котором специфицируются эти положения.
Предназначение указанных документов двояко: помочь в оценке
0 0 и оказать помощь потребителю в выборе продукта ИТ.
Во втором случае к 0 0 предъявляются требования, на соответ
ствие которым он будет в дальнейшем проверяться. Как и в пер
вом случае, требования предъявляются в ПЗ и ЗБ. ЗБ должно раз
рабатываться перед проведением оценки 0 0 .
Для оценки 0 0 очень важно определить его границы. Все, что
окружает 0 0 , называется
средой безопасности,
и напрямую вли
яет на его безопасность.
В ы д ел я ю т
программно-техническую
сре
ду, а также
законодательную, административную
и
процедур
ные
среды. Среда не оценивается, но относительно ее свойств
делаются предположения. Отсюда следует, что, если она не удов
летворяет этим предположениям, оценка 0 0 теряет свое значе
ние и тогда объект небезопасен.
Можно выделить такие предположения о среде 0 0 :
• предположения безопасности, выделяющие объект оценки из
общего контекста, задающие границы рассмотрения; истинность
этих предположений принимается без доказательства, а из мно
жества возможных отбирается только то, что заведомо необходи
мо для обеспечения безопасности 0 0 ;
• угрозы безопасности 0 0 , наличие которых в рассматривае
мой среде установлено или предполагается; они характеризуются
несколькими параметрами: источником, методом воздействия,
опасными с точки зрения злонамеренного использования уязви
мостями, ресурсами (активами), потенциально подверженными
повреждению; при анализе рисков принимаются во внимание ве
роятность активизации угрозы и ее успешного осуществления, а
также размер возможного ущерба; по результатам анализа из мно
жества допустимых угроз отбираются только те, ущерб от которых
нуждается в уменьшении;
• положения политики безопасности, предназначенные для
применения к объекту оценки; для системы ИТ такие положения
могут быть описаны точно, для продукта — в общих чертах.
В настоящее время ФСТЭК планирует создать каталог угроз,
из которого разработчики могли бы выбирать актуальные для них
угрозы. В тексте стандарта приведены лишь отдельные угрозы.
На основании предположений о среде формулируются цели
безопасности для 0 0 , направленные на обеспечение противосто
яния угрозам и выполнение политики безопасности. В зависимо
сти от непосредственного отношения к 0 0 или к среде они под
разделяются на две группы. Часть целей для среды может дости
гаться нетехническими (процедурными) мерами. Все остальные
(для объекта и среды) носят программно-технический характер.
Для их достижения к объекту и среде предъявляются требования
безопасности.
«Общие критерии» в главной своей части (Часть 2) как раз и
являются каталогом требований безопасности. Всего перечислено
135 функциональных требований. Требования достаточно детали
зированы, что делает их конкретными и допускающими одно
значную проверку. Большинство требований параметризовано, т. е.
к ним применимы такие операции, как уточнение какого-либо
значения (например, требуемого количества символов в пароле),
выбор одной возможности из нескольких.
Кроме того, к 0 0 могут предъявляться и нестандартные, не
входящие в каталог требования, что тоже предусмотрено стандар
том.
Для структуризации пространства требований в «Общих кри
териях...» введена иерархия
класс—семейство—компонент—эле
мент.
Классы определяют наиболее общую (как правило, пред
метную) группировку требований. Семейства в пределах класса
различаются по строгости и другим характеристикам требований.
Компонент — минимальный набор требований, фигурирующий
как целое. Элемент — неделимое требование.
Между компонентами могут существовать зависимости. Они
возникают, когда компонент сам по себе недостаточен для дос
тижения цели безопасности. Соответственно при включении та
кого компонента необходимо добавить всю «гроздь» его зависи
мостей.
Как вспомогательный элемент, упрощающий создание ПЗ и
ЗБ, могут применяться функциональные пакеты (ФП) — неодно
кратно используемые совокупности компонентов, объединенных
для достижения установленных целей безопасности.
«Общие критерии...» содержат два основных вида требований
безопасности:
функциональные
и
требования доверия.
Требова
ния доверия предъявляются к технологии и процессу разработки
и эксплуатации 0 0 и представлены в Части 3 ОК. Сформулиро
вав функциональные требования, требования доверия и требова
ния к среде, можно приступать к оценке безопасности готового
изделия ИТ.
ОК предусматривают наличие нескольких уровней представле
ния проекта с его декомпозицией и детализацией. За требования
ми безопасности следует функциональная спецификация, затем
проект верхнего уровня, необходимое число промежуточных уров
ней, проект нижнего уровня, после этого, в зависимости от типа
изделия, исходный код или схемы аппаратуры и, наконец, реали
зация в виде исполняемых файлов, аппаратных продуктов и т. п.
Между уровнями представления должно демонстрироваться соот
ветствие, т. е. все сущности более высоких уровней обязаны фигу
рировать и «ниже, а «внизу» нет места лишним сущностям, не
обусловленным потребностями более высоких уровней.
При проведении оценки изделия ИТ проверяется соответствие
функций безопасности 0 0 функциональным требованиям и кор
ректность их реализации.
Для изделия ИТ составляется формализованный документ —
задание по безопасности. В этом многостраничном документе
подробно описывается не только функциональность изделия ИТ,
но и его среда функционирования, угрозы, предположения
безопасности, цели и требования безопасности, реализованные
в изделии механизмы безопасности. В документе выполняется
строгое обоснование необходимости всех реализованных меха
низмов. Также приводятся сведения о принятых мерах поддерж
ки доверия.
В зависимости от принятых мер поддержки доверия (но не от
набора механизмов безопасности) все изделия ИТ группируются
в семь оценочных уровней доверия (ОУД). Сертификация вы
полняется как раз на соответствие тому или иному уровню дове
рия.
Сертификация изделия ИТ двухступенчатая. Вначале оценива
ется задание по безопасности, затем само изделие — на соответ
ствие этому заданию. За последние три года в России сертифици
ровано несколько изделий на соответствие ГОСТ 15408 — 2002.
В основном это изделия иностранного производства.
19.5. Экспериментальный подход
Под экспериментальным подходом понимается организация
процесса определения эффективности существующих КСЗИ пу
тем попыток преодоления защитных механизмов системы специ
алистами, выступающими в роли злоумышленников — активный
аудит КСЗИ. Активный аудит может выполняться как своими
силами (при наличии специалистов), так и за счет привлечения
сторонней организации.
В настоящее время ФСТЭК разработан проект «Концепции
аудита информационной безопасности систем информационных
технологий и организаций». Данный проект документа содержит
следующие разделы:
1. Общая характеристика состояния аудиторской деятельности
в области информационной безопасности.
2. Основные виды и способы аудита информационной без
опасности.
3. Основные принципы аудита информационной безопасности.
4. Критерии аудита информационной безопасности.
5. Организационно-методологические основы проведения ауди
та информационной безопасности.
5.1. Взаимоотношение аудиторов с представителями проверяе
мой организации.
5.2. Управление программой аудита информационной безопас
ности.
5.3. Этапы проведения аудита информационной безопасности.
6. Инструментальное обеспечение аудита информационной
безопасности.
7. Требования к кадровому обеспечению аудиторской деятель
ности в области информационной безопасности.
8. Реализация первоочередных мероприятий по обеспечению
аудиторской деятельности в области информационной безопас
ности.
Согласно этому документу, под
аудитом информационной без
опасности организации
понимается периодический, незави
симый от объекта аудита и документированный процесс полу
чения свидетельств аудита и объективной их оценки с целью
установления степени выполнения в организациях установлен
ных требований по обеспечению информационной безопасно
сти.
По содержанию аудит И Б разделяется на следующие
виды
:
• аудит ИБ АС, эксплуатирующихся в организации;
• аудит ИБ организации.
Задачей аудита ИБ АС, эксплуатирующихся в организации,
является проверка состояния защищенности конфиденциальной
информации в организации от внутренних и внешних угроз, а
также программного и аппаратного обеспечения, от которого за
висит бесперебойное функционирование АС. Данный вид подра
зумевает как документальный, так и инструментальный аудит со
стояния защищенности информации при ее сборе, обработке,
хранении с использованием различных АС.
Задача аудита ИБ организации — проверка состояния защи
щенности интересов (целей) организации в процессе их реализа
ции в условиях внутренних и внешних угроз, а также предотвра
щение утечки защищаемой конфиденциальной информации, воз
можных несанкционированных и непреднамеренных воздействий
на защищаемую информацию.
Аудит ИБ АС, эксплуатирующихся в организации, может про
водиться как самостоятельный вид аудита, а также являться час
тью аудита И Б организации. При этом он может проводиться во
время проведения аудита ИБ организации или же при проведе
нии аудита ИБ организации могут использоваться результаты ра
нее проведенного аудита ИБ АС, эксплуатирующихся в организа
ции.