Введение

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

В данной статье мы рассмотрим методы оценки соответствия СЗИ ОКИИ, основанные на принципах технического регулирования и стандартизации. Особое внимание будет уделено методам испытаний и приёмки, которые являются практически незаменимы для ЗОКИИ, роль средств защиты в которых выполняют встроенные механизмы защиты.

Терминология

Для начала давайте немного разберемся в терминологии. Основополагающими для нас в данном вопросе будут следующие нормативные документы:

• Федеральный закон № 184-ФЗ «О техническом регулировании»;
• Приказ ФСТЭК России № 239 «Об утверждении требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры»;
• ГОСТ 15408-1 «Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 1. Введение и общая модель»;
• ГОСТ 15408-2 «Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные компоненты безопасности»;
• ГОСТ 15408-3 «Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Компоненты доверия к безопасности».

В соответствии с ч. 4 ст. 5 Федерального закона 184-ФЗ «особенности оценки соответствия (прим. в отношении продукции, применяемой в целях защиты сведений относимых к охраняемым в соответствии с законодательством Российской Федерации или иной информации ограниченного доступа) устанавливаются Правительством Российской Федерации или уполномоченными им федеральными органами исполнительной власти».

В отношении объектов критической информационной инфраструктуры Приказ ФСТЭК России № 239 устанавливает: «28. Для обеспечения безопасности значимых объектов критической информационной инфраструктуры должны применяться средства защиты информации, прошедшие оценку на соответствие требованиям по безопасности в формах обязательной сертификации, испытаний или приемки».

При этом, важно сразу отметить, что только в форме обязательной сертификации оценка соответствия должна проводиться для случаев, установленных законом (как правило, это случаи применения криптографических средств защиты, защиты государственной тайны и другие, где явно указано, что средства защиты информации должны быть сертифицированы).

А также оценке соответствия в форме обязательной сертификации подлежат граничные маршрутизаторы, имеющие доступ к сети Интернет, применяемые в ЗОКИИ 1 категории (но с оговорками, что при отсутствии возможности применения сертифицированных — допускается оценку соответствия таких маршрутизаторов проводить в форме испытаний или приемки).

В тексте настоящей статьи мы хотим разобрать именно оценку соответствия в форме испытаний или приемки. И в этом нам как раз поможет ГОСТ 15408.

Что такое ГОСТ 15408 и как он нам может помочь

ГОСТ 15408 определяют основные подходы, концепцию и критерии оценки безопасности информационных технологий.

Сам ГОСТ 15408-1 дает нам следующее понимание:

«Настоящая часть ИСО/МЭК 15408 обеспечивает сопоставимость результатов независимых оценок безопасности. В ИСО/МЭК 15408 это достигается предоставлением единого набора требований к функциональным возможностям безопасности продуктов ИТ и к мерам доверия, применяемым к этим продуктам ИТ при оценке безопасности. Данные продукты ИТ могут быть реализованы в виде аппаратного, программно-аппаратного или программного обеспечения.

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

ИСО/МЭК 15408 (здесь и далее, если не указывается конкретная часть стандарта, то ссылка относится ко всем частям стандарта) полезен в качестве руководства при разработке, оценке и/или приобретении продуктов ИТ с функциональными возможностями безопасности.»

А также:

«5.3.4 Прочие

Хотя ИСО/МЭК 15408 ориентирован на определение и оценку характеристик безопасности ИТ для объектов оценки, он также может служить справочным материалом для всех, кто интересуется вопросами безопасности ИТ или несет ответственность за них. Среди них можно выделить, например, следующие группы, представители которых смогут извлечь пользу из информации, приведенной в ИСО/МЭК 15408:

a) лица, ответственные за техническое состояние оборудования, и сотрудники служб безопасности, ответственные за определение и выполнение политики и требований безопасности организации в области ИТ;

b) аудиторы как внутренние, так и внешние, ответственные за оценку адекватности безопасности ИТ-решения (которое может состоять из ОО или включать ОО);

c) проектировщики систем безопасности, ответственные за характеристики безопасности продуктов ИТ;

d) аттестующие, ответственные за приемку ИТ-решения в эксплуатацию в конкретной среде;

e) заявители, заказывающие оценку и обеспечивающие ее проведение;

f) органы оценки, ответственные за руководство и надзор за программами проведения оценок безопасности ИТ.»

При этом, именно в данном ГОСТ раскрывается понятие приемки:

«Существует несколько типов ситуаций приемки, некоторые из которых могут частично перекрывать друг друга:

a) первоначальная приемка элемента под управление системы управления конфигурацией, в частности включение в ОО компонентов программного, программно-аппаратного и аппаратного обеспечения разных производителей («интеграция»);

b) перевод элементов конфигурации на следующую стадию жизненного цикла на каждом этапе создания ОО (например, модуль, подсистема, контроль качества конечного ОО);

c) приемка после перемещения элементов конфигурации (например, частей ОО или «заготовок» продуктов) между различными местами разработки;

d) приемка после поставки ОО потребителю».

И именно в соответствии с данными ГОСТ ФСТЭК России разрабатывает Профили защиты, на соответствие которым уже проходят сертификацию средства защиты информации.

В международной практике эти стандарты известны, как «Common Criteria» имея идентификатор ISO 15408.

Как проводить оценку соответствия в форме испытаний или приемки по ГОСТ 15408

В соответствии с ГОСТ 15408 основным элементом оценки соответствия является функциональное требование безопасности (ФТБ). Функциональные требования безопасности определяются исходя из определения угроз безопасности и целей безопасности.

На практике я руководствуюсь следующим принципом, который соответствует общепринятому подходу к формированию требований по обеспечению информационной безопасности:

1. Проводим моделирование угроз и формируем перечень актуальных угроз безопасности.
2. Определяем требования по обеспечению информационной безопасности из совокупности: меры (здесь и далее — из Приказа ФСТЭК России № 239), требуемые к реализации на основе категории значимости, меры, требуемые к реализации с целью нейтрализации угроз безопасности, меры, дополнительно требуемые к реализации исходя из требований иных нормативных актов. Вот этот набор мер защиты информации, по сути, и будет основой для формирования Целей безопасности.
3. Исходя из набора мер защиты информации формируем цели безопасности. Цели безопасности формируем по отдельным решениям или по логическим подсистемам безопасности.
4. Отталкиваясь от целей безопасности уже формируем конкретные функциональные требования по безопасности для каждой подсистемы. Результаты включаем в Техническое задание на создание системы защиты информации.

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

Что из себя представляют требования по безопасности. ГОСТ 15408-2 дает четкое указание к кодировке каждого функционального требования безопасности. 

Например, это такое ФТБ — FAU_GEN.1.1, где первая часть «FAU» — это наименование класс функциональных требований (в данном случае класс FAU — «Аудит безопасности«), вторая часть «GEN» — наименование семейства (в данном случае семейство FAU_GEN — «Генерация данных аудита безопасности«) и третья численная часть — это идентификатор компонента (в данном случае, компонент FAU_GEN.1.1: «ФБО должны быть способны генерировать запись аудита для следующих событий, потенциально подвергаемых аудиту: a) запуск и завершение выполнения функций аудита; b) все события, потенциально подвергаемые аудиту, на [выбор (выбрать одно из): минимальный, базовый, детализированный, неопределенный**]**уровне аудита; c) [назначение: другие специально определенные события, потенциально подвергаемые аудиту**].**«).

Таким образом, в Техническое задание на создание системы защиты информации мы включаем перечень функциональных требований по безопасности.

Далее приступаем к оформлению Программы и методик проведения испытаний в рамках оценки соответствия. Программа и методики должна содержать для каждого функционального требования и в отношении каждого решения методику проведения испытаний и критерии успешности прохождения испытаний. Программа и методики может быть как на отдельное решение или компонент, так и на всю систему защиты в целом.

Например, вот как выглядит описание функционального требования безопасности, методика испытаний и критерий успешности для того же FAU_GEN.1.1 в отношении операционной системы Windows и Ubuntu:

«Описание требований функционального элемента:

ФБО должны быть способны генерировать запись аудита для следующих событий безопасности, потенциально подвергаемых аудиту:

— запуск и завершение выполнения функций аудита;

— события, связанные с истечением установленного администратором срока действия пароля;

— события, связанные с истечением установленного администратором срока действия идентификатора;

— блокирование учетной записи в результате превышения максимального числа неуспешных попыток входа в систему;

— любые модификации политики аудита;

— смена начальной аутентификационной информации пользователя, после однократного использования;

— смена аутентификационной информации пользователем;

-запуск/завершение процессов от имени пользователя и привилегированных команд.

Методика:

Для ОС семейства Windows:

1. В групповых политиках зайти в настройки аудита (Audit Policies, Advanced Security Audit

Policies) операционной системы, проверить наличие возможности выбора типа событий безопасности, подлежащих аудиту в соответствии с требованием функционального элемента;

2. Включить в настройках аудита регистрацию событий, подлежащих аудиту в соответствии с требованием функционального элемента;

3. Осуществить следующие действия для имитации записи данных аудита:

3.1 завести нового пользователя и установить начальные аутентификационные данные с требованием об их смене пользователем при первом входе в систему; зайти под учетной записью указанного пользователя, ввести первичные аутентификационные данные, получить сообщение о необходимости смены аутентификационных данных; ввести новые аутентификационные данные;

3.2 установить срок действия пароля пользователя; перевести системное время на установленный срок вперед; попытаться зайти под указанным пользователем; получить сообщение об истечении срока действия пароля;

3.3 выполнить аналогичные пункту 3.1 действия для срока действия идентификатора пользователя;

3.4 установить количество неуспешных попыток ввода пароля пользователем — 3; попытаться зайти в операционную систему под указанным пользователем, вводя трижды неверный пароль; получить на экране запись о блокировке учетной записи пользователя;

3.5 зайти в систему под учетной записью пользователя и сменить аутентификационную информацию;

3.6 зайти в систему под учетной записью пользователя и запустить и затем завершить любой процесс (программу);

4. Зайти в операционную систему под учетной записью администратора; открыть журнал аудита событий; проверить наличие записей в журнале, соответствующих требованиям функционального элемента.

Для ОС Ubuntu:

1. Войти в операционную систему под учетной записью администратора;

2. Открыть файл /etc/rsyslog.d/50-default.conf; убедиться, что включены объекты auth,authpriv.*, *.*;auth,authpriv.none;

3. Осуществить следующие действия для имитации записи данных аудита:

3.1 завести нового пользователя и установить начальные аутентификационные данные с требованием об их смене пользователем при первом входе в систему; зайти под учетной записью указанного пользователя, ввести первичные аутентификационные данные, получить сообщение о необходимости смены аутентификационных данных; ввести новые аутентификационные данные;

3.2 установить срок действия пароля пользователя; перевести системное время на установленный срок вперед; попытаться зайти под указанным пользователем; получить сообщение об истечении срока действия пароля;

3.3 выполнить аналогичные пункту 3.1 действия для срока действия идентификатора пользователя;

3.4 установить количество неуспешных попыток ввода пароля пользователем — 3; попытаться зайти в операционную систему под указанным пользователем, вводя трижды неверный пароль; получить на экране запись о блокировке учетной записи пользователя;

3.5 зайти в систему под учетной записью пользователя и сменить аутентификационную информацию;

3.6 зайти в систему под учетной записью пользователя и запустить и затем завершить любой процесс (программу);

4. Зайти в операционную систему под учетной записью администратора; в журналах событий (/var/log/auth.log, var/log/secure, var/log/syslog, var/log/messages) проверить наличие записей о событиях безопасности.

Ожидаемый результат: 

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

В журнале аудита событий безопасности осуществляется регистрация событий безопасности, подлежащих аудиту в соответствии с требованиями функционального элемента.»

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

Для каждого класса в ГОСТе описан состав семейств и иерархия компонентов и элементов. ГОСТ 15408-2 по сути являет собой довольно большой справочник возможных функциональных требований, однако он дает также и нам свободу в формировании своего функционального требования, в случае если мы не нашли того, что нам нужно в данном ГОСТ. Свои функциональные требования (придуманные нами для конкретного решения в конкретных целях) кодируются приставкой EXT (расшифровывается как external). Например, вот такое требование я задавал, как внешнее, при проведении оценки соответствия VMWare:

«FIA_VC_LOGIN_EXT.1 Запрет пользователям vCenter на вход в систему

Функциональный элемент: FIA_VC_LOGIN_EXT.1.1

Описание требований функционального элемента:

Сервер vCenter должен запросить идентификацию и аутентификацию из среды vCenter Server для пользователя vCenter Server и получить уведомление об успешном выполнении, прежде чем выполнить какие-либо другие действия при посредничестве ФБО от имени этого пользователя.

Методика:

1. Убедиться, что при доступе пользователя к vCenter Server пользователю необходимо пройти идентификацию и аутентификацию до разрешения ему любых действий.

Ожидаемый результат: 

Объект оценки не позволяет осуществлять действия с vCenter Server пользователям до прохождения пользователем процедуры идентификации.»

Почему это хорошая замена обязательной сертификации и для кого это может быть интересно

Оценка соответствия в форме испытаний и приемки предоставляет ряд преимуществ, которые делают её привлекательной особенно для владельцев объектов, в составе которых применяется довольно специфичное оборудование (например, различные АСУ ТП), для которых найти наложенные сертифицированные средства защиты довольно проблематично, но при этом возможно реализовать требования по безопасности встроенными механизмами защиты. В соответствии с требованиями законодательства для таких объектов есть всего два решения: это отправить данное оборудование индивидуально в испытательную лабораторию на сертификацию (что может стоить больших денег и занять много времени, не говоря уже о том, что иногда может быть в принципе невозможным) или провести как раз оценку соответствия методами испытаний приемки. В соответствии с Приказом ФСТЭК России № 239 оценку соответствия методами испытаний приемки может провести организация, имеющая лицензию ФСТЭК России на работы по защите информации.

Практические ошибки при применения данной формы оценки соответствия

На моем опыте я встречал два типа ситуаций, которые как я считаю являются грубыми нарушениями в порядке оценки соответствия:

1. Оценку соответствия как таковую не проводили и под оценкой соответствия понимали оценку эффективности в рамках аттестационных испытаний.
2. Оценку соответствия проводили с оформлением Программы и методик и Протокола, но делали ее не в соответствии с ГОСТ 15408: не детализировали функциональные требования по безопасности и, соответственно, не фиксировали их в ТЗ, ограничиваясь только описанием реализации мер защиты информации, по сути дублируя информацию из аттестационных испытаний или оценки эффективности.

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

Второй случай, по сути, похож на первый — сущностно там такой же недостаток, что и в первом случае — нарушено логика различий между оценкой соответствия и оценкой эффективности, хотя формально этот вариант, конечно, на «троечку с минусом». С точки зрения же формальности — недостаток такого варианта заключается в отсутствии четких функциональных требований по безопасности, закрепленных в техническом задании, как того требует Приказ ФСТЭК России № 239.

Заключение

Оценка соответствия средств защиты информации в форме испытаний и приемки является важным инструментом для обеспечения безопасности значимых объектов критической информационной инфраструктуры. Этот метод позволяет снизить затраты, а для некоторых случаев является единственным возможным вариантом обеспечить соответствие требованиям законодательства.

Однако важно соблюдать правильный с точки зрения закона, требований, стандартов (да и просто даже логики) порядок проведения оценки соответствия, который позволит избежать большого количества проблем, как с последующими проверками регуляторов, так и с точки зрения реального обеспечения безопасности ЗОКИИ.

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

В своей практике по описанном мной порядку я проводил оценку соответствия с последующим согласованием результатов с регулятором и последующей аттестацией объекта информатизации, в котором 90% мер было реализовано несертифицированными средствами защиты информации. Данный порядок является надежным подтверждением соответствия.

P.S. Полезные материалы для проведения оценки соответствия

Так как серию ГОСТ 15408 придумали не мы, а это довольно известный международный стандарт — во всем мире он известен под названием Common Criteria — большинство известных ИТ-решений уже проходили оценку по этому стандарту. Результаты оценки вендорами оформляются в подробный отчет (например, отчет Microsoft по Windows Server 2016 оформлен на более чем 1000 страниц), и эти отчеты в свою очередь выкладываются в свободный доступ — их можно найти как на сайте вендора, так и на сайте https://www.commoncriteriaportal.org/.

Конечно, дословно копировать эти отчеты и переносить их в Программу и методики оценки соответствия не стоит (да и не стоит забывать, что в этих отчетах может не хватать функциональных требований для испытаний), но использовать их в качестве дополнительной документации при формировании Программы и методики и проведении испытаний можно и даже нужно — по моему опыту именно в этих отчетах я находил детали реализации отдельных функций и описание архитектуры функций безопасности, которые больше ни в какой другой документации описаны не были.