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