В октябре 2023 года Банк России поддержал инициативу АБР о применении безопасного цикла разработки ПО (БРПО). Департамент информационной безопасности (ДИБ) ЦБ, в частности, предложил придерживаться подхода, изложенного в Информационном письме Банка России от 02.02.2022 № ИН-017-56/5, для разработки и внедрения безопасных программных продуктов при сохранении гарантированного и достаточного уровня защищенности прикладного ПО автоматизированных систем и приложений.

Данные документы были ответом на ряд санкционных вызовов и базировались на имеющихся практиках поддержки процессов DevSecOps в банках, например в РСХБ и «Телекоме», группе МТС, включая МТС Банк. И хотя уход западных вендоров осложняет ситуацию, она находится на контроле. Что предлагается и что уже сделано вендорами и командами разработки финансовых организаций?

В чем суть БРПО?

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

С другой стороны, эти уязвимости разработчики кода, особенно в условиях постоянной борьбы за уменьшение time to market новых сервисов, обнаруживают и исправляют не сразу, поскольку они проявляют себя несколько позже. Вопрос в том, кто первым обнаружит «дыру» в ПО: служба безопасности или хакеры?

Самое печальное, по данным компании МТС RED, в том, что львиная доля (более 87%) всех уязвимостей создается на ранних стадиях разработки ПО. Более того, исправление таких ранних «дыр» на поздних этапах обходится в 95 раз дороже, чем при немедленной реакции. А чтобы обеспечить безопасность, необходимо интегрировать инструменты безопасности во все стадии жизненного цикла разработки софта. В настоящее время эта задача решена в рамках концепции, которая сочетает в себе лучшие практики разработки (Dev), безопасности (Sec) и операций (Ops) — DevSecOps; она предполагает внедрение автоматизированных проверок безопасности в DevOps, то есть в сам процесс разработки ПО. Причем, чтобы сократить затраты, стараются перенести основные проверки в левую сторону пайплайна (в начальные стадии процесса разработки). Именно на этом основана концепция Shift-left, о которой так любят говорить «безопасники».

В чести у них еще одна практика DevOps, ставшая особенно актуальной в связи с развитием облачных вычислений, — CI/CD, относящаяся к миру гибких методологий разработки (Agile). CI/CD представляет собой процесс непрерывной интеграции (Continuous Integration, CI) и непрерывной поставки ПО (Continuous Delivery, CD). По сути, это культура, набор принципов и практик, которые позволяют разработчикам чаще и надежнее развертывать изменения софта.

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

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

Что на практике?

Итак, бизнес-процессы, сопровождающие разработку ПО, описаны. Как же на практике банкиры обеспечивают их поддержку, а также достигают непрерывности процесса предоставления финансовых услуг, нормативы по которым жестко контролируются регулятором? Мировые практики и отечественные наработки содержат следующие практические рекомендации:

• автоматизация. Использование инструментов автоматизации помогает выявить и устранить уязвимости на ранних стадиях разработки, что позволяет снизить риски;
• интеграция функции безопасности среди участников команды. Коммуникации и сотрудничество между разработчиками и специалистами по ИБ крайне важны для успешной реализации DevSecOps. Все участники команды должны иметь понимание о способах предотвращения угроз и соблюдении политик безопасности;
• использование контейнеров и микросервисов, что обеспечивает изоляцию приложений друг от друга, уменьшает риски появления уязвимостей и облегчает управление безопасностью;
• регулярные обновления — это важнейшие меры, призванные избежать использования устаревших, а также уязвимых версий ПО;
• непрерывный мониторинг и анализ активности системы помогают выявить потенциальные угрозы и вредоносные действия в реальном режиме времени.

Для практической реализации этих рекомендаций, в первую очередь последней, все чаще используют ASOC (Application Security Operations Center) — операционный центр по обеспечению безопасности приложений. ASOC предлагает централизованный подход к управлению безопасностью и интегрирует все необходимые инструменты, процессы и экспертизу в единую платформу.

Платформенный подход допускает бесшовную интеграцию с DevSecOps-инструментами в рамках DevOps-цикла разработки. Это позволяет плавно внедрять механизмы ИБ в существующие процессы разработки приложений и минимизировать потенциальные конфликты между Agile-командами. Напомним, что люди продолжают оставаться самым слабым звеном ИБ.

Что и чем будем анализировать?

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

• SAST (static application security testing) — статический анализатор кода;
• SCA/OSA (software composition analysis / open-source analysis) — инструменты композитного анализа;
• DAST (dynamic application security testing) — динамический анализатор.

Каждый из приведенных процессов автоматизирован различными, во многих случаях западными, вендорами, но импортозамещение делает свое дело. В частности, как указывают эксперты портала anti-malware.ru, сегмент SCA — процесс определения компонентов (в особенности — с открытым исходным кодом), из которых состоит ПО, и проверки их безопасности.

C использованием SCA команды разработчиков могут быстро отслеживать и анализировать любой опенсорсный компонент, который был добавлен в проект.

Объем этого сегмента на 2020 год составил не более 6% общего размера российского рынка ИБ. И неудивительно, что сейчас он растет с огромной скоростью.

Но обеспечение ИБ — это все же комплексный процесс. Поэтому остро стояла проблема разработки отечественного ASOC, которая была успешно решена компанией МТС RED в ноябре 2023 года. Но это вовсе не означает, что ушел подход с использованием локальных SAST, DAST и т.д.

Михаил Синельников, DevSecOps Team Lead компании «РСХБ-Интех», в октябре 2023 года выступил с кейсом о том, как в Россельхозбанке построили ИБ-платформу с использованием open-source-инструментов и провели интеграцию проверок безопасности на всех этапах CI/CD. Помимо всего прочего эксперт доказал, что ASOC можно создать бесплатно и в кратчайшие сроки.

Проект пришлось начать после ухода из России таких вендоров, как Nexus, Netsparker, Chekmarx и т.д., что, по словам Михаила Синельникова, «обнулило» всю ИБ-архитектуру разработки ПО.

За два месяца новая система была построена, и это дало повод Михаилу Синельникову сделать вывод: «Хорошая система ИБ — это информативная и понятная система для бизнеса, разработчиков и специалистов ИБ. Такая система может быть запущена в кратчайшие сроки и обслуживаться небольшой командой инженеров».

Насколько с этой позицией согласны вендоры и аудиторы, покажет жизнь. МТС и РСХБ анонсировали свои подходы только к концу 2023 года. Теперь слово за экспертами широкого рынка ИБ, а также за Банком России.