Экспериментальный подход

Задание требований безопасности информации и оценка соответствия им согласно ГОСТ 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