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

Начался резкий всплеск хакерских атак на российские и зарубежные банки

В 2012-2013 годах начался резкий всплеск хакерских атак на российские и зарубежные банки. Анализ инцидентов показывает, что причиной успешности действий преступников становится большое количество типовых уязвимостей в вычислительной инфраструктуре и прикладном программном обеспечении банковских приложений, в том числе – в платежных приложениях. Аналогичные результаты показывают и работы по анализу защищенности, которые мы проводим для российских банков – в аналитических отчетах видно, что не так много кредитных организаций способны эффективно противодействовать киберпреступникам. Например, если говорить только о ДБО, то чуть более чем в половине (55%) исследованных экспертами Positive Technologies систем ДБО нарушитель может получить контроль над СУБД и доступ к банковской тайне; в каждой четвертой системе — украсть денежные средства банка, обладая пользовательским доступом к клиентскому приложению, и еще в 5% случаев — сделать то же без каких-либо привилегий. Нарушитель может полностью вывести из строя систему ДБО, используя контроль над ОС сервера и другие уязвимости (в 40% обследованных случаев).

В результате в 2013 году Банк России поручил Positive Technologies, как экспертной организации, специализирующейся на вопросах защищенности банковских приложений и являющейся, к тому же, членом профильного технического комитета Росстандарта, разработать рекомендации по организации жизненного цикла защищенных банковских приложений. Документ был разработан, и в 2014 году вступил в силу. В его основу легла общемировая практика организации защищенной разработки (рекомендации PCI, NIST, MITRE, BSIMM и др.), которая, в частности, включает в себя в качестве обязательного элемента безопасности проведение анализа уязвимостей прикладного программного обеспечения при вводе информационных систем в эксплуатацию и периодически в ходе их эксплуатации.

Безопасность приложений приносится в жертву стремлению как можно быстрее завершить разработку и запустить новый банковский продукт

Двухлетний опыт применения этих рекомендаций показал, что немногие банки в полном объеме обеспечивают анализ и устранение уязвимостей в своих АБС: очень часто безопасность приложений приносится в жертву стремлению как можно быстрее завершить разработку и запустить новый банковский продукт. В частности, результаты исследований Positive Technologies показывают, что около 68% всех исследованных систем подвержены уязвимостям (как минимум средней степени риска, а подавляющее большинство из них могут быть охарактеризованы высокой степенью риска) на уровне кода.

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

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

  • провести анализ исходных кодов самостоятельно или с привлечением сторонних организаций (уровень доверия ОУД4, упомянутый в требовании, как раз и означает, помимо прочего, проведение целенаправленного поиска т.н. уязвимостей нулевого дня в исходном коде приложения);
  • потребовать у поставщика или разработчика провести такой анализ за свой счет и предоставить банку результаты анализа;
  • в случае, если закупаемое приложение уже проходило сертификацию, которая предусматривает поиск уязвимостей в исходном коде (сертификация ФСТЭК по ГОСТ 15408 с оценочным уровнем доверия ОУД4 или, с некоторыми оговорками, сертификация по уровню контроля недекларированных возможностей), ─ затребовать у поставщика сертификат.
Инициатива Банка России нацелена на закрытие уязвимостей банковской инфраструктуры и платежных приложений, позволяющих  выводить миллиарды рублей

Таким образом в реальности инициатива Банка России нацелена на закрытие уязвимостей банковской инфраструктуры и платежных приложений, позволяющих преступником выводить из банковской системы миллиарды рублей, – угроза государственного уровня. Наиболее рациональным решением для банков станет или использование средств анализа защищенности приложений при разработке и приемке информационных систем (прежде всего для банков, самостоятельно разрабатывающих банковские приложения, и для разработчиков банковских приложений) или использование услуг компаний, специализирующихся на проведении такого анализа. Для некоторых видов приложений (прежде всего – для веб-приложений) анализ уязвимостей можно заменить компенсационными мерами – например, применяя межсетевые экраны прикладного уровня (WAF), которые умеют самостоятельно обнаруживать типовые уязвимости веб-приложений и устранять их с помощью «виртуальных патчей». А вот вариант сертификации приложений в системе сертификации ФСТЭК возможен скорее лишь гипотетически: он потребует от заявителя гораздо больших затрат, в то время как испытательные лаборатории практически полностью загружены заказами от разработчиков средств защиты, для которых такая сертификация обязательна.

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