Положение 382п: путь от рекомендаций к требованиям

- kbrbank

Положение 382п: путь от рекомендаций к требованиям

Банк России проводит постепенную и целенаправленную работу по регулированию вопросов безопасности информации в денежном секторе.

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

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

В 2012-2013 годах начался резкий всплеск хакерских атак на российские и зарубежные банки. Анализ инцидентов говорит о том, что обстоятельством успешности действий преступников делается много типовых уязвимостей в вычислительной инфраструктуре и прикладном программном обеспечении банковских приложений, а также – в платежных приложениях.

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

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

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

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

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

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

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

Инициатива Банка России нацелена на закрытие уязвимостей банковской платёжных приложений и инфраструктуры, разрешающих  выводить миллиарды рублей

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

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

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

Вебинар. Защита информации в соответствии с положением Банка России № 382

Интересные записи

Похожие статьи, которые вам, наверника будут интересны: