Поиск баланса между time-to-market и киберустойчивостью

В журнале Brics Magazine вышла статья Юры Сергеева — «Поиск баланса между 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 – это культура, которая соответствует принципу создания защищенных программных продуктов при гибких процессах разработки.

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

При реализации SSDL следует использовать как организационные, так и технологические меры. Внедрение лучших практик разработки защищенного программного обеспечения переходит, по сути, в непрерывное совершенствование процессов. Необходимо определить, задокументировать и измерять как количественные показатели кибербезопасности, так и ключевые показатели эффективности. Чтобы контролировать DevSecOps-процессы, необходимо собирать и анализировать ряд метрик, например, таких как среднее время обнаружения уязвимостей, среднее время устранения дефектов в коде, среднее время существования уязвимости в промышленной эксплуатации. Команде необходимо настроить процессы так, чтобы время обнаружения и время устранения было короче, чем при обычном двухнедельном спринте, что позволит разработчикам вовремя исправлять дефекты информационной безопасности и держать под контролем весь объем уязвимостей программного обеспечения с учетом критичности (так называемый технический долг).

Суммируя бизнес-ценность реализации DevSecOps-практик в контексте основных векторов (бизнес / IT / кибербезопасность), можно выделить четыре принципиальных направления:

1. Time-to-Market. Скорость фактической реализации новых бизнес-функций в ПО:
  • повышение скорости вывода на рынок защищенных программных продуктов;
  • наращивание объемов выпуска бизнес-функций при сохранении уровня качества и защищенности ПО на индустриальном уровне;
  • реализация прозрачного инженерного процесса оперативного и бесшовного внесения любых ИБ-изменений в программные продукты.
2. Software Engineering Maturity. Зрелость технологий и эффективность разработки защищенного ПО:
  • повышение продуктивности разработчиков при создании защищенного ПО;
  • интеграция непрерывного технологического процесса применения практик анализа защищенности в инженерный конвейер разработки ПО;
  • повышение уровня экспертизы разработчиков в области кибербезопасности;
  • снижение стоимости выявления и устранения уязвимостей.
3. Compliance. Соответствие программных продуктов и их компонент, а также технологических и бизнес-процессов внутренним политикам качества, требованиям регуляторов и индустриальным стандартам:
  • обеспечение контроля уровня соответствия процессов индустриальным стандартам;
  • обеспечение соответствия ПО регуляторным требованиям;
  • обеспечение контроля используемых компонент с открытым исходным кодом в части их лицензионной чистоты;
  • обеспечение контроля рисков кибербезопасности ПО.
4. Cyber-Resilience. Киберустойчивость цифрового бизнеса:
  • повышение защищенности и непрерывности функционирования программных продуктов и цифровых сервисов;
  • снижение уровня подверженности рискам безопасности ПО;
  • снижение плотности уязвимостей в коде программных продуктов;
  • проактивное выявление уязвимостей ПО на ранних стадиях разработки;
  • повышение скорости устранения технического долга дефектов ИБ.

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