В свое время тогдашний безоговорочный лидер в разработке ПО компания Microsoft после череды инцидентов и разбирательств по поводу найденных в коде уязвимостей признала, что качество ее ПО не выдерживает никакой критики. Мало того, наложенные средства защиты, например антивирусы, далеко не всегда могли изменить ситуацию.

Ради спасения репутации инженеры Microsoft предложили подход SDLC (Security Development Lifecycle), который впоследствии стал каноническим. Основной смысл изменений заключался в том, что сочетание Application Security (раздел ИБ, отвечающий за безопасность приложений в целом) и SDLC развернуло вектор разработчиков с обнаружения уязвимостей на предотвращение их появления. Позже SDLC получил детализацию в различных методологиях — OpenSAMM (Open Software Assurance Maturity Model), BSIMM (Building Security in Maturity Model), OWASP (Open Web Application Security Project) и др.

Безопасность должна быть внутри

Казалось бы, с проблемой разобрались. Но развитие технологий привело к качественному изменению основанного на них бизнеса, например банковского. Финансисты довольно быстро осознали: чтобы получить дополнительные конкурентные преимущества требуется как можно быстрее отвечать на запросы рынка. Резко поднялась значимость такой метрики, как скорость вывода в эксплуатацию новых продуктов (time to market).

Это привело к тому, что стандартные решения вендоров перестали удовлетворять финансовые организации и они сами стали пытаться писать ПО, а также автоматизировать всевозможные внутренние процессы. Для достижения поставленных целей были взяты на вооружение гибкие методологии, например Agile.

Стала востребована и методология DevOps (development & operations) — методология автоматизации технологических процессов сборки, настройки и развертывания ПО, предполагающая активное взаимодействие программистов со специалистами по информационно-технологическому обслуживанию и взаимную интеграцию их технологических процессов для обеспечения высокого качества программного продукта.

Банкиры были далеко не единственными, кто активно двигался по этому пути. Поэтому неудивительно, что довольно много людей из различных отраслей вдруг обнаружили, что должного качества ПО добиться при использовании только DevOps не удается. В погоне за скоростью разработки и максимальным учетом пожеланий клиентов было утрачено то, для чего и создавался SDLC, — безопасность ПО, которая сегодня прочно ассоциируется с качеством кода и сервисов на его основе.

Весной 2020 года «Б.О» зафиксировал приход в отечественную практику разработки DevSecOps — развитие концепции DevOps, где помимо автоматизации затрагиваются вопросы обеспечения качества и надежности кода на всех этапах жизненного цикла ПО. Однако сейчас, весной 2023 года необходимо провести ревизию и переоценку ценностей в этой нише.

Три года — три удара

В ноябре 2022-го в ходе онлайн-конференции AM Live «Российский DevSecOps в условиях импортозамещения» ведущие ИБ-эксперты подробно обсудили, как изменились концепция и технологический стек безопасной разработки приложений в России в условиях новой реальности.

По мнению участников дискуссии, первым испытанием на прочность стали пандемия COVID-19 и уход в интернет поставщиков массовых сервисов для населения: банков, онлайн-магазинов, госструктур и т.д. Требовалось быстро переделать старые IT-системы и создать новые. Чем в ряде случаев это заканчивалось, многие помнят — недоступность сервисов и массовые утечки персональных данных.

Именно тогда стало понятно, что из аббревиатуры DevSecOps было изъята такая часть, как «Sec». Ее надеялись позже «прикрутить» к разным частям IT-систем, что специалисты не замедлили уничижительно окрестить как SecDevOps, DevOpsSec и т.д. Однако, как в той басне, куда бы вы ее ни «прикрутили», безопасности больше не станет. Причина заключается в том, что система должна быть безопасной от рождения в полном соответствии с манифестом международного сообщества DEVSECOPS (ИБ не должна накладываться сверху, а должна быть свойством кода) и архитектурным принципом «Security by Design».

Второй удар нанесли западные вендоры, покинувшие Россию после событий февраля 2022 года и унесшие с собой значительное количество средств автоматизации и контроля, разрабатываемых в парадигме DevSecOps-кода. Кроме того, был ограничен доступ к святая святых всех приверженцев DevOps GitHub — крупнейшему веб-сервису для хостинга IT-проектов и их совместной разработки, а также к магазинам приложений для мобильных устройств.

И, наконец, в условиях ограниченности иностранных средств контроля качества кода появились сообщения о закладках и преднамеренных диверсиях в open source.

Банк России в роли Microsoft

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

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

Этим вопросам была посвящена Первая межотраслевая конференция по регуляторике в сфере ИБ финансовой отрасли, прошедшая под эгидой АБИСС (Ассоциации пользователей стандартов по информационной безопасности) в конце прошлого года. DevSecOps была целиком посвящена сессия «Безопасность прикладного программного обеспечения». В ее рамках выступил Константин Стародубов, представитель департамента ИБ Банка России, который представил долгожданный методический документ «Профиль защиты прикладного ПО автоматизированных систем и приложений кредитных и некредитных финансовых организаций» с включенным в него разделом по безопасной разработке, одобренный ПК № 1 ТК № 122 и уже опубликованный на официальном сайте Банка России.

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

Вопросы концентрации компетенций и перехода к архитектуре «Security by Design» были подняты в феврале 2023 года на Уральском форуме «Кибербезопасность в финансах». В частности, Дмитрий Гадарь, директор департамента ИБ Тинькофф Банка, произвел большое впечатление на Ольгу Скоробогатову, первого заместителя председателя Банка России, своим докладом по данной проблеме. В итоге он был приглашен ею в ЦБ для проведения мастер-классов в качестве эксперта по этому процессу.

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