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

И еще раз (а может, еще и не раз) вернемся к вопросу о том, что такое "анализ уязвимостей в соответствии с требованиями ОУД4 ГОСТ 15408-3". А точнее, о том, что делать банкам с самостоятельно разработанными приложениями.

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

1. Оценщик должен изучить открытые источники и выяснить, нет ли в исследуемом продукте известных потенциальных уязвимостей. Очень часто это воспринимается как "давайте посмотрим в CVE, нет ли там известных уязвимостей для продукта", и это неверно. В методологии четко оговаривается, что речь идет об открытых материалах (книгах, статьях, материалах конференций), в которых описываются потенциально возможные уязвимости информационной технологии, реализованной в продукте. Так, если речь идет о веб-приложении (а к им относятся практически все фронтэнды ДБО и мобильного банкинга), то основным открытым источником для оценщика должен стать OWASP, а потенциальными уязвимостями - SQL-инъекции, XSS и весь прочий зверинец типовых уязвимостей веб-приложений. Т.е. речь на этом шаге оценки идет прежде всего о типовых уязвимостях и типовых ошибках разработки, характерных для технологии, а не только об отдельных идентификаторfх CVE.

2. Оценщик должен изучить весь объем проектной документации, которую ему обязан предоставить разработчик. При этом он должен убедиться, что в этой документации, как минимум - на бумаге, отсутствуют те самые типовые уязвимости и ошибки разработки, характерные для технологии. Уже на этом шаге оценки вполне нормально получить от оценщика замечание: "Парни, вы пишете, что данные передаются по простому HTTP - фу-фу-фу, это бяка, нельзя так делать!"

Кроме того, оценщик должен провести анализ исходного кода продукта (т.н. "представление реализации") в поисках зеродеев.

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

• демонстрацию того, что невозможно прямое несанкционированное вмешательство нарушителя в работу продукта;

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

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

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

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

К сожалению, ни ГОСТ 15408, ни ГОСТ 18045 ничего не говорят о том, в чем именно должен заключаться поиск зеродеев в исходных кодах - и это один из основных недостатков Общих Критериев. Отсутствие прямых указаний на эту тему побудило Банк России разработать дополнительные требования к анализу уязвимостей, включив их в проект профиля защиты для автоматизированных банковских систем и приложений. Но об этих требованиях - в следующий раз.

ОУД4 для банковских приложений

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

ГОСТ 15408 (он - же "Критерии оценки защищенности информационных технологий", он же - Общие Критерии или Common Criteria) предполагает, что разработчик защищенной информационной системы (или отдельного средства защиты - обычно этот стандарт используется только в их разработке) заявляет, что реализовал в ней определенный набор функций безопасности, что эти функции действительно работают и что нарушитель не может их отключить или обойти. В правдивости этого заявления разработчик пытается убедить потребителя, интересы которого представляет независимый оценщик (чаще всего - испытательная лаборатория системы сертификации, но необязательно).

"Убедительность" заявления разработчика - штука измеримая, она определяется "оценочным уровнем доверия" (ОУД) - комплексом мер, которые разработчик должен реализовать в своем жизненном цикле разработки, чтобы исключить ошибки, уязвимости и подлог со стороны своих сотрудников. На первом (низшем) уровне доверия разработчику достаточно мамой поклясться описать эти функции в пользовательской документации, на седьмом (наивысшем) ОУД разработчик должен, помимо прочего, описать работу всех заявленных функций безопасности в какой-то формальной нотации (в виде блок-схем, UML-диаграмм и т.п.) и доказать оценщику, что исходный код в точности соответствует этому описанию.

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

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

1. Разработчик должен описать архитектуру подсистемы безопасности своего продукта (мера доверия ADV_ARC.1). В описании архитектуры должно быть продемонстрировано, что функции безопасности его продукта невозможно обойти, т.е. что в нем нет архитектурных уязвимостей.
2. Разработчик должен написать функциональную спецификацию своего продукта (мера доверия ADV_FSP.4). В ней должен быть описан весь API, связанный с реализацией функций безопасности, назначение каждой функции API, способ ее использования, ее параметры, а также описание всех (вообще всех) ошибок, сообщения о которых могут появляться в интерфейсе или в логах, причем с разблюдовкой: вот эти ошибки - результат некорректного срабатывания функций безопасности, а вот эти - не связаны с безопасностью по вот такой причине.
3. Разработчик должен описать разделение своего продукта на подсистемы, а каждой подсистемы - на отдельные модули (мера доверия ADV_TDS.3). Для каждого модуля, в котором реализуются функции безопасности, должно быть описано, какие функции API он реализует. Для каждой функции безопасности должно быть расписано что-то вроде диаграммы взаимодействия UML - через какие модули и через какие функции API этих модулей идут пути исполнения кода при выполнении функций безопасности.
4. Разработчик должен передать оценщику всю эту документацию и исходный код продукта.
5. Оценщик должен убедиться, что документация полна и соответствует исходному коду.
6. Оценщик должен проверить, нет ли для этого продукта уже известных уязвимостей.
7. Оценщик должен провести анализ документации на предмет потенциальных архитектурных уязвимостей.
8. Оценщик должен провести анализ исходных кодов на предмет потенциальных зеродеев.
9. Оценщик должен верифицировать все найденные потенциальные уязвимости, проверив их эксплуатабельность.
10. Если оценщик обнаруживает эксплуатабельные уязвимости, продукт и документация отправляются на доработку и оценка повторяется после устранения уязвимостей.

Описанная процедура чем-то напоминает сертификацию по уровню контроля отсутствия недекларированых возможностей, которую когда-то практиковала ФСТЭК.

Как видно из описания, анализ уязвимостей - это довольно большой объем работы по анализу архитектурных уязвимостей и уязвимостей кода. Замечу, что при сертификации в системе ФСТЭК проводится точно такая же работа, но она - лишь часть сертификационных испытаний: анализ уязвимостей на ОУД4 - это примерно треть трудозатрат испытательной лаборатории на полноценную сертификацию продукта.

К чему я все это пишу. Как видно из описания, ГОСТ ничего не говорит о том, как именно должны выявляться уязвимости - например, нужно ли проводить для этого динамический анализ кода или достаточно только статики. Более того, сильно подозреваю, что авторы этой редакции Common Criteria вообще очень слабо представляли себе, что такое уязвимости и как их обычно отыскивают: не хочу обидеть парней из профильного комитета ISO, но только очень альтернативно одаренный человек мог назвать верификацию уже найденной уязвимости словосочетанием "penetration test".

Такая неопределенность в способах поиска потенциальных уязвимостей не устраивает ЦБ, поэтому "встроенные" требования ГОСТ 15408-3 по анализу уязвимостей расширены в проекте профиля защиты, который сейчас рассматривается в ТК122. Изменения существенны:

1. Анализ уязвимостей должен проводить разработчик. Оценщик проверяет, что анализ уязвимостей разработчиком действительно проводится, а также самостоятельно проводит независимый анализ уязвимостей, чтобы убедиться, что разработчик не халтурит. Такой дублирующий контроль не избавляет разработчика от обязанности самостоятельно проводить анализ уязвимостей.
2. Добавлены примечания, в которых подробно описано, какими именно способами должны выявляться уязвимости. В частности, прямо указана необходимость проведения статического и динамического анализа исходного кода.
3. Верификация уязвимостей (она обычно проводится в лабораторных условиях) заменена полноценным тестированием на проникновение в реальных условиях эксплуатации. Требования к тестированию на проникновение взяты из РС БР ИББС 2.6, тем самым переведя описанную там процедуру тестирования на проникновения из рекомендованной в обязательную.
4. Описаны требования к отчетам об анализе уязвимостей. Именно такими отчетами разработчик (или банк) будет подтверждать аудиторам самостоятельное проведение анализа уязвимостей.

В чем принципиальное отличие? "Чистый" ОУД4 позволял относится к анализу уязвимостей как работе, которую должен выполнить сторонний эксперт. С момента утверждения профиля защиты ЦБ усиливает требования ОУД4, заставляя разработчиков встраивать анализ уязвимостей в жизненный цикл разработки банковских приложений. Напрямую это касается только собственной разработки платежных приложений банками и некредитными финансовыми организациями, но косвенно это создает и потребительское давление на разработчиков АБС и систем ДБО: финансовая организация не может использовать в платежном процессе приложение, разработчик которого не проводит самостоятельный анализ уязвимостей.

Анализ уязвимостей и ОУД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 и заюлаговременная подготовка к вохможности проведения атак, а именно: анализ и устранения уязвимостей, которые могут использоваться в новых видах атак, и заготовка плейбуков для реагирования на ьтакие атаки.

Требования ЦБ по противодействию мошенническим денежным переводам

Внимательно посмотрел положение ЦБ №683-П "Об установлении обязательных для кредитных организаций требований к обеспечению защиты информации при осуществлении банковской деятельности в целях противодействия осуществлению переводов денежных средств без согласия клиента". Больше всего меня интересовали вопросы анализа уязвимостей.

Кредитные организации обязаны выполнять требования ГОСТ Р 57580.1-2017 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер". При этом значимые кредитные организации должны выполнять требования усиленного (т.е. высшего) уровня, остальные - стандартного (т.е. среднего) уровня. Требования стандарта предъявляются ко всем объектам информационной инфраструктуры, которые участвуют в обработке, передаче и хранении платежной информации. И это, наверное, хорошо. Правда, в стандарте нет требований по защите информации - он содержит просто перечень мер защиты, без детализации требований к ним. Например, стандарт говорит, что кредитная организация должна контролировать отсутствие и обеспечивать оперативное устранение известных уязвимостей (меры защиты ЦЗИ.1 - ЦЗИ.6), для чего нужно применять сканеры уязвимостей к объектам инфраструктуры (меры защиты ЦЗИ.7 - ЦЗИ.10). При этом он ничего не говорит о том, как часто нужно проводить анализ уязвимостей и что понимается под оперативностью их устранения.

OK, добросовестному банку этого достаточно: менеджмент известных уязвимостей уже описан много раз, и как его реализовывать - понятно. Остаются уязвимости нулевого дня - например, те же уязвимости веб-интерфейсов систем ДБО. В соответствии с положением, такие интерфейсы ("программное обеспечение, используемое для приема сообщений ... в сети Интернет") должно или сертифицироваться в системе сертификации ФСТЭК, или пройти анализ уязвимостей в объеме, соответствующем оценочному уровню доверия ОУД4 ГОСТ 15408-3. Альтернатива "сертифицировать или анализировать уязвимости" появилась еще год назад в положении Банка России 382-П (в редакции указания N 4793-У от 7 мая 2018 г.), и на тот момент логика авторов документа была понятна. Сертификация включает в себя проведение анализа уязвимостей, поэтому в теории подобное требование означало, что банки вынуждены будут так или иначе проводить работу по поиску и анализу уязвимостей нулевого дня в используемом программном обеспечении, при этом ОУД4 задает минимально-приемлемую глубину анализа. К сожалению, только в теории.

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

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

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

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

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

Как в этой ситуации поступать банкам? Ну, во-первых, стоит вспомнить о том, что есть рекомендации в области стандартизации РС БР ИББС-2.6-2014 "Обеспечение информационной безопасности организаций банковской системы Российской Федерации. Обеспечение информационной безопасности на стадиях жизненного цикла автоматизированных банковских систем»", где в приложении подробно расписано, что подразумевается под анализом уязвимостей компонентов информационных систем. Во-вторых, можно провести анализ уязвимостей в объеме все того же ОУД4, но только определенного не в ГОСТ 15408, а в "Методике выявления уязвимостей и недекларированных возможностей в программном обеспечении" ФСТЭК. Так как ГОСТ 15408 в действительности не содержит никаких требований к объему и методам анализа уязвимостей, любой из этих двух вариантов будет автоматически соответствовать требованиям этого ГОСТ.

Повторяемость инцидента при оценке ущерба объектам КИИ

При категорировании объектов критической инфраструктуры ущерб от возможных инцидентов можно разделить на моментальный и длящийся. Очевидные примеры моментального ущерба – прекращение работы систем жизнеобеспечения, транспорта или связи (показатели категорирования 2, 3 и 4): для выбора категории значимости важно только количество людей, которое потенциально может пострадать от инцидента, но неважна длительность их страданий. Длящийся ущерб актуален для показателей категорирования экономического блока: снижение доходов субъекта КИИ напрямую зависит от времени простоя его основных средств производства.

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

“5. Категорирование включает в себя: … д) оценку … масштаба возможных последствий в случае возникновения компьютерных инцидентов на объектах критической информационной инфраструктуры;”

“14. Комиссия по категорированию в ходе своей работы: … д) анализирует угрозы безопасности информации, которые могут привести к возникновению компьютерных инцидентов на объектах критической информационной инфраструктуры; е) оценивает … масштаб возможных последствий в случае возникновения компьютерных инцидентов на объектах критической информационной инфраструктуры …;”

“17. Субъект критической информационной инфраструктуры … направляет … сведения о результатах присвоения объекту критической информационной инфраструктуры одной из категорий значимости либо об отсутствии необходимости присвоения ему одной из таких категорий. Указанные сведения включают: … ж) возможные последствия в случае возникновения компьютерных инцидентов на объекте критической информационной инфраструктуры либо сведения об отсутствии таких последствий;”

Во всех случаях слова “последствия” и “инцидент” упоминаются только во множественном числе, поэтому из текста правил не следует, что речь идет о разблюдовке возможных инцидентов с оценкой последствий единичного инцидента каждого вида в отдельности. Недавние изменения, внесенные в правила категорирования, на мой взгляд, ставят точку в этом вопросе:

“14(1). При проведении работ, предусмотренных подпунктами "г" и "д" пункта 14 настоящих Правил, должны быть рассмотрены наихудшие сценарии, учитывающие проведение целенаправленных компьютерных атак на объекты критической информационной инфраструктуры, результатом которых являются прекращение или нарушение выполнения критических процессов и нанесение максимально возможного ущерба.”

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

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

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