Требования 719-П к оценке соответствия по уровню ОУД4

ГОСТ 15408 — российский стандарт, полученный в результате аутентичного перевода стандарта ISO/IEC 15408 Common Criteria for Information Technology Security Evaluation, разговорное название — Common Criteria (общие критерии). Стандарт ISO/IEC 15408 разрабатывается специалистами Великобритании, Германии, Канады, Нидерландов, США и Франции с 90-х годов. Стандарту предшествуют европейский стандарт ITSEC, канадский стандарт CTCPEC и американский стандарт TCSEC (также называемый Orange Book —оранжевая книга). На текущий момент действуют Common Criteria в редакции 5 версии 3.1, принятой в 2017 г. Сам стандарт состоит из трех частей: Introduction and general model, Security functional components и Security assurance components.

Действующий стандарт ГОСТ 15408 «Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий» также состоит из трех частей:

• ГОСТ Р ИСО/МЭК 15408-1-2012 «Введение и общая модель»;
• ГОСТ Р ИСО/МЭК 15408-2-2013 «Функциональные компоненты безопасности»;
• ГОСТ Р ИСО/МЭК 15408-3-2013 «Компоненты доверия к безопасности».

Как нетрудно заметить по обозначению частей, текущий ГОСТ 15408 не является переводом последней версии стандарта ISO/IEC 15408, а соответствует редакции 3 версии 3.1 общих критериев от 2008–2009 гг. При этом впервые в России перевод общих критериев версии 2.1 был принят в качестве ГОСТ в 2002 г. и был введен в действие в 2004 г. под обозначением ГОСТ Р ИСО/МЭК 15408-2002.

ГОСТ 15408 представляет собой описание ряда критериев оценки, при соответствии которым продукт или система информационных технологий (в терминологии ГОСТ — объект оценки) могут считаться безопасными. Совместно с этим стандартом предполагается использование:

• ГОСТ Р ИСО/МЭК 18045 «Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий» для методологии оценки;
• ГОСТ Р 57628-2017 «Информационная технология. Методы и средства обеспечения безопасности. Руководство по разработке профилей защиты и заданий по безопасности» для разработки профиля защиты и задания по безопасности — документов, необходимых для оценки в рамках ГОСТ 15408.

ГОСТ 15408 предназначен для использования потребителями, разработчиками и оценщиками.
Потребители, используя стандарт, могут решить, соответствует ли объект оценки их требованиям по безопасности.

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

Оценщики используют стандарт как список действий при оценке.
Под оценкой понимается два типа оценки: (1) оценка задания по безопасности (включая оценку среды функционирования) и собственно объекта оценки и (2) оценка профиля защиты.
Задание по безопасности разрабатывается разработчиком объекта оценки и представляет собой требования к конкретному продукту или системе. Профиль защиты предназначен для описания типа объекта оценки, то есть некоего класса продуктов или систем. Эти два документа похожи друг на друга, за исключением того, что профиль защиты предоставляет некий выбор для разработчика в части конкретных применяемых мер.

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

В третьей части ГОСТ 15408 требования доверия сгруппированы в 6 классов и 27 семейств. На практике применяются комбинации требований доверия, которые называются оценочными уровнями доверия (ОУД). В стандарте определены 7 комбинаций требований доверия, которым присвоены обозначения от ОУД1 (низкий уровень доверия) до ОУД7 (высокий уровень доверия). Каждый уровень доверия включает хотя бы одно требование доверия из каждого класса.

Рассматриваемый уровень ОУД4 включает, кроме требований из класса анализа уязвимостей, требования по документированию, процедурам безопасной разработки, приемки и поставки, требования по тестированию.

Хотя безопасная разработка не является темой статьи и заслуживает отдельного обсуждения, на этом вопросе хотелось бы остановиться подробнее. В ГОСТ 15408 безопасность разработки — отдельное семейство требований доверия (ALC_DVS), однако стандарт ограничивается требованиями к документации по безопасности разработки, которые должен предоставить разработчик. Оценщик должен подтвердить, что документация соответствует требованиям и меры, обозначенные в документации, действительно применяются разработчиком.

Стандартов и документов по безопасной разработке довольно много. Наиболее известна из них, пожалуй, методология Microsoft SDLC. Кроме этого, можно назвать методологии BSIMM, OWASP CLASP, Open SAMM, Cisco SDL. Также существует большое количество документов по безопасной разработке с конкретными рекомендациями по отдельным процессам разработки (например, NIST SSDF) или даже с рекомендациями для конкретных технологий, языков и фреймворков (например, OWASP Cheat Sheet Series). В России разрабатывается серия ГОСТ по безопасной разработке (совместимая с ГОСТ 15408). Из этой серии уже действуют ГОСТ Р 56939-2016 «Защита информации. Разработка безопасного программного обеспечения.
Общие требования» и ГОСТ Р 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке безопасного программного обеспечения».

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

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

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

Применение всех перечисленных мер позволяет снизить стоимость и сроки исправления уязвимостей или вообще исключить их возникновение.

Хотя содержавшееся в Положении № 382-П требование о проведении только анализа уязвимостей прикладного ПО в соответствии с ОУД4 ГОСТ 15408 было новым для разработчиков прикладного ПО, многие из разработчиков уже проводили такой анализ для своего программного обеспечения по своим внутренним методикам.

Некоторые сложности с проведением анализа уязвимостей по ОУД4 возникали у кредитных и некредитных финансовых организаций, самостоятельно разработавших прикладное ПО. Но в целом обнаруженные по итогам проектов уязвимости устранялись и прикладное ПО, разработанное профессиональной компанией-разработчиком или кредитной организацией, становилось более безопасным.

Отметим, что при проведении анализа уязвимостей по ОУД4 не оценивалась безопасность процесса разработки программного обеспечения, полнота документирования функций и процессов, выполнение функциональных требований безопасности из профиля защиты
от Банка России.

В ходе полной оценки по ОУД4 и должны проверяться выполнение требований доверия к безопасности и функциональных требований безопасности.

Для проведения оценки по ОУД4 требуется задание по безопасности. Как мы уже отмечали, оно должно быть разработано на основании профиля защиты, например профиля защиты от Банка России.

Задание по безопасности в части функциональных требований безопасности может соответствовать ГОСТ 15408-2 «Функциональные компоненты безопасности» или включать расширенные по отношению к ГОСТ 15408-2 функциональные требования.
В части требований доверия задание по безопасности может соответствовать ГОСТ 15408-3 или включать усиленные и расширенные по отношению к ГОСТ 15408-3 требования доверия. Расширение и усиление функциональных требований безопасности и требований доверия может быть заимствовано из профиля защиты, например профиля защиты от Банка России.

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

Как минимум разработчик ПО должен включить во внутреннюю распорядительную документацию и документацию к разрабатываемому ПО следующее:

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

Всю эту документацию разработчик ПО предоставляет оценщику.

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

• выборочное тестирование объекта оценки, чтобы перепроверить результаты тестирования, предоставленные разработчиком;
• выборочное тестирование объекта оценки, чтобы подтвердить работу функций безопасности объекта оценки;
• поиск информации об уязвимостях объекта оценки в общедоступных источниках;
• анализ уязвимостей с использованием полученной от разработчика документации, описания архитектуры объекта оценки и исходных кодов программного обеспечения;
• тестирование на проникновение, основанное на выявленных уязвимостях объекта оценки, для проверки возможности эксплуатации уязвимостей нарушителем с потенциалом нападения «Усиленный базовый» (по умолчанию в пакете ОУД4) или «Высокий» (согласно профилю защиты от Банка России).

В Положении № 719-П установлено требование о проведении оценки соответствия по ОУД4 ГОСТ 15408-3 компанией, имеющей лицензию ФСТЭК на проведение работ и услуг, предусмотренных подп. «б», «д» или «е» п. 4 Положения о лицензировании деятельности по технической защите конфиденциальной информации. То есть у оценщика должна быть лицензия ФСТЭК на техническую защиту конфиденциальной информации (ТЗКИ).
Согласно ч. 3 ст. 7 Закона № 184-ФЗ, оценка соответствия может быть проведена в форме испытания, регистрации, подтверждения соответствия и в иной форме. Добровольное подтверждение соответствия осуществляется в форме добровольной сертификации (ч. 2
ст. 20 Закона № 184-ФЗ).

В ноябре 2021 г. компания «БИФИТ» отправила в Банк России запрос: какая форма оценки соответствия прикладного ПО по требованиям ОУД4 ГОСТ 15408-3 устроит Банк России? В декабре 2021 г. мы получили ответ: конкретная форма оценки соответствия Положением № 719-П не установлена, единственное обязательное условие — оценку соответствия должна проводить компания с соответствующей лицензией ФСТЭК на ТЗКИ.

Из ответа Банка России сделан вывод, что проведение оценки соответствия по требованиям ОУД4 ГОСТ 15408-3 может подтверждаться любым соответствующим документом: техническим заключением, протоколом испытаний и сертификатом добровольной системы сертификации.