Цифровой бизнес
Поиск баланса между time-to-market и киберустойчивостью
С начала пандемии коронавируса кибератаки вышли на первый план среди угроз бизнесу и обществу. В 2022 году ситуация только усугубилась. Между тем избежать большинства угроз можно, если встраивать процедуры кибербезопасности на самых ранних стадиях разработки IT-продуктов, например перейдя от технологии DevOps к DevSecOps.
В сегодняшней гиперконкурентной бизнес-среде успех
сильно зависит от способности предоставлять своим клиентам инновационные
цифровые услуги с высокой степенью надежности и защищенности.
В постоянной борьбе за долю рынка программные продукты становились
все более совершенными, а циклы выпуска обновлений сокращались
с месяцев до часов. В моменте бизнес сосредоточен на гибких
методологиях разработки программных продуктов (Agile), пытаясь при этом
сохранить их качество, отказоустойчивость, кибербезопасность
и соответствие регуляторным требованиям. Гибкая методология разработки
программного обеспечения, предусматривающая непрерывный процесс создания
добавленной стоимости, появилась в последние 20 лет. Она подразумевает
инкрементальное предоставление бизнес-функций клиентам с контролируемым
уровнем качества c реализацией в кратчайшие сроки.
Кибербезопасность и соответствие регуляторным
требованиям традиционно не считались частью Agile, поэтому многие компании
все еще продолжают исповедовать «водопадный» подход XX века
при разработке программного обеспечения. Тогда эксперты информационной
безопасности взаимодействовали с командами разработки всего лишь дважды
в рамках всего жизненного цикла создания программного продукта –
в самом начале проекта и непосредственно перед выпуском.
Без применения инструментов автоматизированного анализа защищенности ряд
проверок по-прежнему может выполняться вручную при помощи практики
тестирования на проникновение. В этой парадигме техника принятия
бизнесом технологических рисков лишь подтверждает тот факт, что далеко
не каждая версия программного продукта тщательно проверяется
и тестируется.
Традиционные IT-процессы изо всех сил стараются
сбалансировать потребность в более частом выпуске обновлений
ПО при сокращающихся сроках поставки с рисками несоответствия
регуляторным и индустриальным требованиям или даже технологических сбоев.
Причинами таких сбоев может служить множество факторов: человеческие ошибки,
ручные операции, нарушение технологических процессов или их полное отсутствие,
ошибочные алгоритмы, нечеткие требования, организационные ограничения,
несогласованные цели менеджеров, отвечающих за реализацию и внедрение
программных продуктов, и, наконец, несоответствие инженерных культур
в командах разработки.
Вопросы кибербезопасности адресуют опасения бизнеса
как в контексте публичных утечек данных, сбоев в цифровых
сервисах, так и задержек, вызванных внешними аудитами и регуляторными
проверками. В настоящее время всего одна уязвимость может иметь эффект
домино для компаний по всему миру благодаря широко используемым
компонентам с открытым исходным кодом или облачным технологиям.
Цифровые угрозы в современном мире эволюционируют
постоянно, схематично актуальный ландшафт векторов атак в контексте
безопасности программных продуктов представлен на схеме «Угрозы цепочки
поставок ПО».
В этой парадигме успех Agile зависит
от полноценной автоматизации полного спектра проверок
как информационной безопасности продукта, так и соответствия его
требованиям регуляторов со скоростью DevOps-процессов, которые сочетают
в себе разработку программного обеспечения (Dev) и эксплуатацию (Ops).
Постоянно ускоряющийся цикл разработки кардинально повлиял на вопросы
и подходы к обеспечению информационной безопасности программного
обеспечения.
В этом контексте можно рассмотреть индустриальные
вызовы с трех ключевых векторов.
1. Бизнес:
- необходимость повышения уровня защищенности ПО в рамках программ цифровизации;
- все больше атак приходится на уровень приложений;
- постоянное расширение регуляторных требований по информационной безопасности ПО;
- цифровые угрозы реализуются через все новые векторы атак, в том числе через атаки на цепочки поставок ПО.
2. IT:
- переход на модели гибкой разработки ПО – Agile;
- трансформация инженерных процессов в технологические конвейеры сервисов непрерывной интеграции и непрерывного развертывания;
- использование индустриальных DevOps стандартов производственного процесса ПО;
- код приложений становится все более динамичным (и более сложным для тестирования ИБ).
- Кибербезопасность:
- высокая стоимость внедрения и эксплуатации инфраструктуры и процессов разработки защищенного ПО;
- необходимость формирования внутренней экспертной группы с сильными компетенциями в области ИБ;
- ресурсные ограничения на рынке труда по необходимым компетенциям.
Для решения этой проблемы в последние годы были
реализованы инициативы DevSecOps. DevSecOps (сокр. Development, Security,
Operations) – это модель разработки программного обеспечения, в которой
все эти три команды работают синхронно в тесном сотрудничестве. Можно
сказать, что команда DevSecOps – это гибкая кросс-функциональная команда
DevOps, которая внедряет и использует методы обеспечения кибербезопасности
в своих процессах для создания действительно защищенных программных
продуктов и цифровых сервисов. Методология DevSecOps включает в себя
информационную безопасность приложений, данных и инфраструктуры.
Практики кибербезопасности, такие как анализ
технической архитектуры, проверка кода, анализ используемых компонент
с открытым исходным кодом, анализ защищенности контейнеров, динамический
анализ и тестирование на проникновение, должны быть реализованы
как неотъемлемая часть DevOps. DevOps-команды должны перенимать образ
мышления в отношении информационной безопасности и применять эти
принципы в своей повседневной деятельности. Сегодня программное
обеспечение выпускается короткими спринтами, и анализ защищенности
приложений становится просто необходимой практикой во время циклов разработки,
не замедляя инженерные процессы. В идеале активности
по обеспечению информационной безопасности должны начинаться
как можно раньше в рамках жизненного цикла программного
обеспечения – в так называемой парадигме shift-left. Команды
разработчиков и экспертов по кибербезопасности становятся более
эффективными и масштабируют DevSecOps за счет автоматизации,
интеграции и плотной совместной работы в процессе создания инновационных
приложений и цифровых сервисов. DevSecOps также подразумевает применение
полностью «программного подхода», который фокусируется на методах
непрерывного обеспечения кибербезопасности, органично интегрированных
в DevOps в виде автоматизированных конвейеров разработки защищенного
ПО.
Модель DevSecOps объединяет DevOps-процессы
и непрерывный контроль защищенности разрабатываемых программных продуктов.
Процесс разработки защищенного ПО (Secure Software Development Process,
SSDL) предполагает необходимые изменения и ограничения существующего
инженерного процесса. Процедуры, регламенты, требования и стандарты SSDL
должны быть задокументированы, опубликованы для всех ключевых вовлеченных
сторон и отражены в политиках компании.
Создание группы информационной безопасности программного
обеспечения (Software Security Group, SSG) – один из ключевых компонентов
организационной готовности к DevSecOps. SSG аккумулирует знания,
распространяет компетенции и определяет новые роли и обязанности
для руководства и технических экспертов в организации. Мировая
индустрия ощущает сильный кадровый дефицит экспертов в области
кибербезопасности для поддержки растущих масштабов разработки программного
обеспечения. Таким образом, поиск талантливых сотрудников внутри организации,
готовых сфокусировать свою карьеру в области информационной безопасности,
имеет решающее значение для успеха преобразования DevSecOps.
Существует большой пласт инструментов, процессов,
фреймворков и методологий, которые способны помочь даже большой корпорации
превратиться в DevSecOps-организацию. Однако в итоге DevSecOps – это
культура, которая соответствует принципу создания защищенных программных
продуктов при гибких процессах разработки.
- Ответственность за информационную безопасность продукта в первую очередь должна принадлежать команде разработчиков.
- Практики кибербезопасности должны быть встроены в существующий инженерный процесс и полностью интегрированы в ежедневный цикл разработки и тестирования.
При реализации SSDL следует использовать
как организационные, так и технологические меры. Внедрение лучших
практик разработки защищенного программного обеспечения переходит,
по сути, в непрерывное совершенствование процессов. Необходимо
определить, задокументировать и измерять как количественные
показатели кибербезопасности, так и ключевые показатели эффективности.
Чтобы контролировать DevSecOps-процессы, необходимо собирать
и анализировать ряд метрик, например, таких как среднее время
обнаружения уязвимостей, среднее время устранения дефектов в коде, среднее
время существования уязвимости в промышленной эксплуатации. Команде
необходимо настроить процессы так, чтобы время обнаружения и время
устранения было короче, чем при обычном двухнедельном спринте, что
позволит разработчикам вовремя исправлять дефекты информационной безопасности и держать
под контролем весь объем уязвимостей программного обеспечения с учетом
критичности (так называемый технический долг).
Суммируя бизнес-ценность реализации DevSecOps-практик
в контексте основных векторов (бизнес / IT / кибербезопасность), можно
выделить четыре принципиальных направления:
1. Time-to-Market. Скорость фактической реализации новых бизнес-функций в ПО:
- повышение скорости вывода на рынок защищенных программных продуктов;
- наращивание объемов выпуска бизнес-функций при сохранении уровня качества и защищенности ПО на индустриальном уровне;
- реализация прозрачного инженерного процесса оперативного и бесшовного внесения любых ИБ-изменений в программные продукты.
2. Software Engineering Maturity. Зрелость технологий и эффективность разработки защищенного ПО:
- повышение продуктивности разработчиков при создании защищенного ПО;
- интеграция непрерывного технологического процесса применения практик анализа защищенности в инженерный конвейер разработки ПО;
- повышение уровня экспертизы разработчиков в области кибербезопасности;
- снижение стоимости выявления и устранения уязвимостей.
3. Compliance. Соответствие программных продуктов и их компонент, а также технологических и бизнес-процессов внутренним политикам качества, требованиям регуляторов и индустриальным стандартам:
- обеспечение контроля уровня соответствия процессов индустриальным стандартам;
- обеспечение соответствия ПО регуляторным требованиям;
- обеспечение контроля используемых компонент с открытым исходным кодом в части их лицензионной чистоты;
- обеспечение контроля рисков кибербезопасности ПО.
4. Cyber-Resilience. Киберустойчивость цифрового бизнеса:
- повышение защищенности и непрерывности функционирования программных продуктов и цифровых сервисов;
- снижение уровня подверженности рискам безопасности ПО;
- снижение плотности уязвимостей в коде программных продуктов;
- проактивное выявление уязвимостей ПО на ранних стадиях разработки;
- повышение скорости устранения технического долга дефектов ИБ.
Хочу отметить, что при переходе от DevOps
к DevSecOps для организации нет необходимости изобретать ничего
нового. Индустриальные стратегии трансформации и дорожные карты уже
продуманы и проверены на практике. Что точно будет полезно
на начальных этапах – это определение метрик, которые обеспечивают хорошее
представление о существующих процессах разработки программного
обеспечения. Это станет отличной основой для анализа состояния
при трансформации в DevSecOps. После этого стоит воспользоваться
помощью экспертов, которые имеют сильные компетенции и индустриальную
экспертизу в области как построения стратегии перехода
к DevSecOps-процессам, так и их прикладного внедрения
в организациях, занимающихся разработкой программного обеспечения,
подобных вашей.