Анализ уязвимостей и ОУД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 требованиям к уровням доверия. Но это уже совсем другая история.

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

Принято постановление Правительства о порядке подготовки сетей электросвязи к функционированию объектов КИИ. Документ разрабатывался больше года, результат - "ну не шмогла я, не шмогла".

.

На что нужно обратить внимание:

1. Подключать объекты КИИ к сети Интернет, использовать для передачи данных сети операторов мобильной связи и т.п. можно только разрешения ФСТЭК. Да, каждый субъект КИИ должен согласовывать с ФСТЭК возможность подключения своих объктов КИИ к сетям общего доступа. Порядок такого согласования определяет ФСТЭК, и подозреваю, что оно будет требоваться только для значимых объектов. Тем не менее, тем, кто сейчас проводит категорирование объектов, стоит внимательно отнестись к этому моменту: если в акте категорирования будет написано, что информационная система не подключена к сетям электросвязи, а при инспекции выяснится, что она активно взаимодействует с внешним миром, это будет нарушением требований безопасности.
2. Операторы связи должны обеспечивать защиту информации, передаваемой по их сетям связи, в соответствии с требованиями, которые установит Минсвязи. Ух ты, Минсвязи наконец разработает требования по обеспечению тайны связи! С 2003 года все разрабатывает-разрабатывает, никак не разработает, но сейчас каааааак...
3. Операторы связи должны обеспечивать безопасность своих сетей, которые используются для организации взаимодействия значимых объектов КИИ. Минутку, и откуда же оператор связи узнает, что вот эта его сеть используется его клиентами для взаимодействия каких-то значимых объектов КИИ? В проекте документа был прописан механизм уведомления операторов связи владельцами значимых объектов, но в финальном тексте этого механизма нет. Забавная ситуация: надзорный орган (ФСТЭК) знает, что сети вот такого оператора используются вот таким значимым объектом КИИ - об этом владелец объекта сообщает при категорировании, а сам оператор связи этого не знает и никаким способом узнать не может.
4. Оператор связи отвечает только за выполнение требований Минсвязи и в случае сетевой атаки на информационные системы своих клиентов не обязан им помогать. В проекте был прописан механизм разделения обязанностей и совместного реагирования на атаки, но из финального текста он исчез.

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

Upd: чуть не забыл самое важное. Появилось понятие "требования доверия" применительно к оборудованию связи, которое используется для на стороне оператора для обслуживания значимых объектов КИИ. Эти требования Минсвязи устанавливает по согласованию с ФСТЭК. А ФСТЭК под обеспечением доверия понимает, помимо прочего, проведение анализа уязвимостей и недекларированных возможностей. Так что операторам связи стоит готовиться к тому, что со временем такой анализ придется проводить не только для средств защиты, но и для оборудования связи. Прецедент есть, это требование использовать сертифицированные маршрутизаторы на внешней границе объектов КИИ.

Требования к средствам ГосСОПКА

Утверждены требования к средствам ГосСОПКА

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

1. В статье ФЗ-187 говорится:

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

Из этого некоторые комментаторы делают вывод, что все технические средства, которые в силу своего назначения используются для обнаружения, предупреждения и далее по тексту, являются средствами ГосСОПКА. Из этого они делают вывод, что приказ распространяется на все средства защиты, используемые для обеспечения безопасности объектов КИИ.

Так вот, это не так. ГосСОПКА была создана на основании указа Президента №31с от от 15.01.2013 г., и все нормативные акты, регулирующие ее деятельность, принимались во исполнение этого указа. ФЗ "О безопасности критической информационной инфраструктуры Российской Федерации" ее деятельность не регулирует. Нормы ФЗ-187 говорят лишь о том, как ГосСОПКА, живущая по своим собственным правилам, используется при обеспечении безопасности объектов КИИ. В частности, когда в нормативных документах ГосСОПКА говорится о силах и средствах ГосСОПКА, речь идет именно о силах и средствах субъектов ГосСОПКА (термин, введенный в одном из ДСПшных нормативных документов ФСБ), а не о силах и средствах субъектов КИИ.

Подробно о разнице понятий "субъект ГосСОПКА" и "субъект КИИ" написано в статье на anti-malware, повторять здесь не буду. Но если коротко, то требования обсуждаемого нормативного документа ФСБ распространяются на субъекта КИИ только в том случае, если он заключил с ФСБ соглашение о подключении к ГосСОПКА в качестве центра ГосСОПКА. И эти требования касаются только тех технических средств, которые используются для выполнения функций центра ГосСОПКА. На средства защиты, используемые для выполнения требований ФСТЭК к системам защиты значимых объектов КИИ, эти требования не распространяются.

Проще всего проиллюстрировать это следующим примером. Есть холдинг из десятка предприятий. Для защиты холдинга создан SOC, который стал центром ГосСОПКА. На каждом предприятии в рамках выполнения требований 239 приказа ФСТЭК развернуты SIEM, которые накапливают события, проводят их первичную обработку. События, потенциально свидетельствующие о проведении компьютерной атаки, направляются в SIEM SOC'а для централизованного реагирования. Так вот, в этой схеме требования обсуждаемого нормативного документа ФСБ распространяются на SIEM SOC'а и не распространяются на SIEM'ы предприятий.

2. Хочу обратить внимание на то, что в обсуждаемом приказе ФСБ обнаружением компьютерных атак фактически назван анализ событий. Это принципиальная позиция регулятора, поэтому когда вы слышите от интегратора: "Для обнаружения атак в рамках ГосСОПКА достаточно развернуть вот такую систему сенсоров IDS с вот такой централизованной управлялкой", - нужно четко понимать, что вас обманывают.

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

В результате между документами двух регуляторов получилась терминологическая путаница, поэтому стоит запомнить:

• "средство обнаружения вторжений" в нормативных документах ФСТЭК - это IDS;
• "средства обнаружения компьютерных атак" в нормативных документах ФСБ - это совокупность SIEM и подключенных к нему источников событий.

3. Еще один аспект требований к обнаружению атак: они должны обнаруживаться не только в режиме реального времени, но и в ретроспективе. Для SOC, которые планируют стать центрами ГосСОПКа, это означает:

• если появилась новая сигнатура для IDS, SOC должен иметь возможность проверить, не мелькала ли подобная сигнатура трафике раньше;
• если антивирус обнаружил на узле зараженный файл, SOC должен суметь проследить, как этот файл и его копии "мигрировали" в инфраструктуре до обнаружения и т.п.

Предупреждая хайп на тему "повторения закона Яровой": речь не идет об обязательном хранении всего трафика и "слепков" всех файлов, передаваемых по сети. Требования к средствам ГосСОПКА нужно выполнять в контексте функций центров ГосСОПКА, описанных в методических рекомендациях. Там говорится, что центр ГосСОПКА должен концентрироваться на противодействии типовым атакам, пополняя свои знания о таких атаках на основе threat hunting'а. То есть, если SOC заявляет, что умеет справляться с атаками на веб-приложения, для ретроспективного анализа новых атак, которые для этого SOC становятся типовыми, можно записывать трафик строго определенных протоколов к строго определенным веб-серверам - а можно ограничиться хранением логов этих веб-серверов. Но независимо от того, какие данные используются для обнаружения типовой атаки в ретроспективе, SIEM должен обеспечивать техническую возможность ретроспективного анализа этих данных.

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