Анализ уязвимостей и ОУД4 ГОСТ 15408-3

"По заявкам радиослушателей". Заказчики уже несколько раз просили прокомментировать, что такое "анализ уязвимостей в соответствии с требованиями ОУД4". Я об этом уже писал, здесь - чуть подробнее.

Нормативные документы ЦБ обязывают организации финансовой сферы с 01.01.2020 проводить анализ уязвимостей прикладного ПО, которое используется в платежных и иных финансовых операциях. Навскидку вспомнил три документа, в которых это требование присутствует:

• положение Банка России от 9 июня 2012 г. № 382-П "О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств";
• положение Банка России от 17 апреля 2019 г. № 683-П "Об установлении обязательных для кредитных организаций требований к обеспечению защиты информации при осуществлении банковской деятельности в целях противодействия осуществлению переводов денежных средств без согласия клиента";
• положение Банка России от 17 апреля 2019 г. № 684-П "Об установлении обязательных для некредитных финансовых организаций требований к обеспечению защиты информации при осуществлении деятельности в сфере финансовых рынков в целях противодействия осуществлению незаконных финансовых операций".

В части анализа уязвимостей все три документа используют примерно одинаковые формулировки:

...обеспечить использование ... прикладного программного обеспечения автоматизированных систем и приложений, ... а также программного обеспечения, обрабатывающего защищаемую информацию ..., сертифицированных в системе сертификации Федеральной службы по техническому и экспортному контролю на соответствие требованиям по безопасности информации, в том числе на наличие уязвимостей или недекларированных возможностей (далее - сертификация), или в отношении которых проведен анализ уязвимостей по требованиям к оценочному уровню доверия (далее - ОУД) не ниже чем ОУД 4, предусмотренного пунктом 7.6 национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 15408-3-2013

C "обеспечить использование" все понятно. Организация не обязана непременно сама проводить сертификацию или анализ уязвимостей: достаточно, если банк закупит ПО, уже прошедшее такое исследование. Или обяжет провести это исследование разработчика ПО. А вот дальше начинаются нюансы.

Формулировка "сертификация на соответствие требованиям по безопасности информации, в том числе на наличие уязвимостей или недекларированных возможностей" была придумана, когда система сертификации ФСТЭК работала по старым правилам. Тогда анализ уязвимостей и недекларированных возможностей проводился в двух случаях: при сертификации в рамках ГОСТ 15408 на соответствие профилю защиты с оценочным уровнем доверия ОУД4 и при сертификации на соответствие "уровню контроля отсутствия недекларированных возможностей". В переводе на русский язык приведенная формулировка означает "годится любой софт, у которого есть сертификат ФСТЭК, в тексте которого присутствуют 'ОУД4' или 'контроль отсутствия НДВ'".

Однако, начиная с этого года система сертификации ФСТЭК работает по новым правилам:

• сертификация на контроль отсутствия НДВ прекращена;
• ГОСТ 15408-3 больше не является методическим документом ФСТЭК, а установленные в нем уровни доверия больше не используются при сертификации;
• сертификаты, в которых присутствуют буковки "НДВ" и "ОУД" до 01.01.2020 г. должны быть переоформлены по новым требованиям или будут аннулированы (подробнее см. информационное сообщение ФСТЭК).

Если для выполнения процитированного требования организация рассматривает вариант с сертифицированным ПО, то у меня для нее три новости: хорошая и две плохие:

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

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

Альтернативой является проведение анализа уязвимостей, и на самом деле именно этот вариант и является основным (вариант с сертификацией был включен в проект положения 382-П уже на стадии общественного обсуждения под предлогом "при сертификации тоже уязвимости анализируют"). ГОСТ 15408-3 определяет меры доверия, которые раньше применялись при сертификации средств защиты. Сейчас он не применяется, но пользоваться этим инструментом самостоятельно по-прежнему можно. В состав мер доверия входит анализ уязвимостей, требования к нему для ОУД4 определены в компоненте доверия AVA_VAN.3. В соответствии с этим компонентом доверия оценщик (лицо, которое проводит анализ уязвимостей) должен проделать следующую работу:

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

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

Самый интересный вопрос: имеет ли право банк или разработчик самостоятельно проводить анализ уязвимостей. В трех документах используются три разные формулировки:

• 382-П (в редакции указания 4793-У): "следует привлекать организацию, имеющую лицензию на осуществление деятельности по технической защите конфиденциальной информации";
• 683-П: "должны привлекать организации, имеющие лицензию на осуществление деятельности по технической защите конфиденциальной информации";
• 684-П: "анализ уязвимостей ... проводится самостоятельно или с привлечением проверяющей организации", требование о наличии у проверяющей организации лицензии ФСТЭК отсутствует.

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

1. "Анализ уязвимостей обязательно должен делать независимый лицензированный оценщик".
2. "Анализ уязвимостей требует подтверждения квалификации исследователей. Хотите делать сами - получите лицензию ФСТЭК.".
3. "В ходе разработки можно и нужно проводить анализ уязвимостей самостоятельно. Но при этом нужна контрольная проверка, для проведения которой нужно звать лицензиатf".
4. "Если для анализа уязвимостей банк привлекает стороннюю организацию, то он должен привлекать организацию-лицензиата".

Из них самой разумной кажется третья трактовка. Если проводить анализ уязвимостей только основных релизов, то в проверяемом релизе гарантированно будут уязвимости, и их устранение может затянуть релиз на неопределенный срок. При этом для проверки того, а хорошо ли мы сами анализируем уязвимости, разумно время от времени привлекать внешнего оценщика. Четвертая трактовка тоже возможна, но если выбbрать именно этот вариант, то лучше все же запросить разъяснения у ЦБ.

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

Upd. Как справедливо заметили коллеги, в информационном сообщении говорится, что ФСТЭК может приостанавливать действие сертификатов, если они не будут переоформллены. Это не значит, что ведомство будет это делать в обязательном порядке.

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

А вот госам придется хуже - с 01.01.2020 при создании и модернизации ГИС, являющихся значимыми объектами КИИ применять СЗИ с непереоформленными сертификатами нельзя даже если действие сертификата не приостановлено: эти СЗИ не будут соответствовать введенным в приказ 239 требованиям к уровням доверия. Но это уже совсем другая история.