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

Читать тут

Во второй части:

Аналитика (Intelligence)

Технологии Искусственного Интеллекта в ASOC

Аналитика (Intelligence)

Платформа AppSec.Hub позволяет реализовать полноценный Data-Driven подход к управлению DevSecOps процессом. Мы разработали специальную структуру хранилища данных, которая позволяет собирать всю телеметрию процесса разработки защищенных программных продуктов. В хранилище агрегируются все данные о продуктах, артефактах ПО, их версиях, истории сканов, структуре и статусах выполнения задач в пайплайнах, результатах сканирований, результатах анализа уязвимостей, статусе и сути исправления дефектов ИБ и так далее, что дает возможность контролировать состояние защищенности разрабатываемого ПО, определять тренды процесса безопасной разработки, зрелости отдельных практик и производительности DevSecOps процесса в целом. В платформе реализован ряд отчетов, информационных панелей и дашбордов, которые помогают нашим клиентам выбирать правильный курс в повседневном DevSecOps-путешествии.

Кроме встроенных отчетов и графиков у AppSec.Hub есть возможность интеграции с системами класса Business Intelligence, в частности с Tableau. Работая с данными напрямую и имея базовые навыки создания дaшбордов, наши клиенты получают поистине неограниченные возможности для собственной визуализации параметров DevSecOps процесса в реальном времени.

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

Снижение времени на устранение обнаруженных дефектов ИБ;
Сокращение объема технического долга;
Снижение количества непройденных проверок ПО на разных стадиях разработки;
Снижение количества найденных уязвимостей во время аудитов безопасности/пентестов;
Увеличение покрытия проверками безопасности разрабатываемых приложений и кодовой базы;
Общее повышение качества и защищенности разрабатываемых продуктов;
Повышение зрелости и устойчивости DevSecOps процесса;

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

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

Software Engineering - реализовать бизнес-функциональность вовремя, согласно плану спринтов и релизов; cовершенствовать инженерный процесс для повышения качества ПО;
Security - повысить безопасность цифровых продуктов и обеспечить непрерывность их эксплуатации, обеспечить соответствие индустриальным требованиям и требованиям регуляторов;
Business - держать баланс между уровнем защищенности цифровых продуктов и затратами на обеспечение безопасности, сократить Time-to-Market;

В целях упрощения визуализации мы представляем нашу модель метрик в пирамиды метрик DevSecOps, состоящей из четырех уровней:

Уровень телеметрии (Telemetry) - слой простейших несвязных данных, которые могут быть получены из любых источников. Пример – данные индустриальных стандартов, время сканирования артефакта ПО, размер кодовой базы, количество задач в определенном пайплайне, количество уязвимостей, обнаруженных сканером в каком-либо артефакте в определенной версии конкретного программного продукта и т.д.
Операционный уровень (Operations) - информационный слой, являющийся производным от параметров телеметрии. Пример - объем технического долга, плотность дефектов, среднее время жизни дефекта и т.д. Параметры этого уровня, как правило, контролируются на уровне отдельных команд.
Управленческий уровень (Management) - слой обобщающих понятий, агрегирующий в себе параметры операционного уровня. Пример - Time-to-Market для определенного релиза, покрытие продуктовых команд практиками Application Security, устранение уязвимостей в программном продукте и т.д. Понятия на этом уровне, как правило, контролируются на уровне менеджмента организации.
Уровень Топ-менеджмента (Executive) - высший слой категоризации и абстракции. На данном уровне находятся обобщенные понятия, которые декомпозируются через связи с параметрами со всех низлежащих слоев. Это - Время Вывода Продукта на Рынок (Time-to-Market), Защищенность и Непрерывность Цифрового Бизнеса (Digital Business Continuity & Security), Соответствие Индустриальным и Регуляторным Требованиям (Compliance), Зрелость Процесса Разработки (Software Development Maturity). Достижение целей по всем этим направлениям и формирует общую ценность от внедрения DevSecOps для организации (DevSecOps Value).

Схематично, данная концепция может быть представлена в следующем виде:

Также мы предприняли попытку распределить метрики, параметры и понятия по уровням этой пирамиды, с учетом их наибольшего влияния на один из векторов (Business, Software Engineering, Security). Это представление - пока экспериментальный взгляд и наша команда постоянно уточняет данный концепт и продолжает над ним работать.

Удобно рассматривать взаимосвязи понятий / параметры / метрик на разных уровнях пирамиды в виде “дерева”.

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

Приведу примеры наиболее часто встречающихся вопросов:

Уровень	Вопросы
Уровень Топ-менеджмента (Executive)	1. Какое влияние на Time-to-Market оказывает внедрение практик ИБ? 2 . Как продемонстрировать, что Time-to-Market уменьшается, а продукт стал более защищенным? 3. Насколько безопасны наши цифровые продукты, сервисы и приложения? 4. Каков статус соответствия индустриальным и регуляторным стандартам? 5. Какова зрелость процессов ИБ в разработке? 6. Насколько эффективен наш DevSecOps процесс? 7. Как убедиться, что команды разработчиков внедряют практики ИБ? 8. Как мы можем продемонстрировать, что инициатива обеспечения ИБ программных продуктов (AppSec) создает ценность для бизнеса (действительно необходима и снижает риски)?
Управленческий уровень (Management)	1. Какие требования индустриальных стандартов и регуляторов нарушаются и почему? Насколько критичны эти нарушения? 2. Как нашу организацию можно оценить относительно других игроков в индустрии? 3. Как быстро разработчики исправляют дефекты, влияющие на нарушения политик? 4. Каков прогресс в улучшении зрелости процесса разработки защищенного ПО? 5. Существуют ли тенденции в определенных типах / категориях дефектов CWE / OWASP, на основе которых можно предложить улучшения в программе обучения? 6. Насколько эффективно работает наша инициатива обеспечения ИБ программных продуктов (AppSec)? 7. Когда технический долг дефектов ИБ (Security Technical Debt) будет устранен в соответствии с выделенными ресурсами в рамках инициативы AppSec? 8. Какова скорость устранения технического долга дефектов ИБ? 9. Применяются ли точки контроля качества ПО в пайплайнах поставки ПО? 10. Контролируется ли выполнение точек контроля качества ПО в пайплайнах поставки ПО? 11. Насколько эффективен процесс анализа и приоритизации уязвимостей ПО? 12. Насколько эффективны программы тестирования на проникновение (Red Team) и Bug Bounty в рамках инициативы DevSecOps по сравнению с автоматизированными практиками?
Операционный уровень (Operations)	1. Сколько было найдено нарушений каждой из политик ИБ? 2. Сколько дефектов ИБ находится за пределами установленного периода устранения? 3. Сколько программных продуктов охвачено на первоначальном этапе внедрения AppSec-инициативы? 4. Сколько программных продуктов было просканировано хотя бы один раз? 5. Сколько программных продуктов было включено в непрерывный процесс сканирования в периметре DevSecOps? 6. Включены ли точки контроля качества ПО в пайплайны поставки ПО? 7. Сколько практик ИБ внедрено в данной организации / подразделении / команде / продукте? 8. Установлена ли интеграция с системами управления дефектами и имеются ли данные о дефектах ИБ в бэклоге для данной организации / подразделении / команды / продукта? 9. Снижает ли тестирование ИБ на ранних этапах количество уязвимостей, обнаруженных на более поздних этапах? 10. Исправляем ли мы больше уязвимостей, чем находим? 11. Насколько быстро устраняются уязвимости? 12. Как часто применяются практики анализа защищенности для конкретных программных продуктов? 13. Каковы наиболее частые типы выявляемых дефектов по CWE / OWASP? 14. Сколько критичных уязвимостей перешло в промышленную эксплуатацию вместе с релизом программного продукта? 15. Каково соотношение объема разработки функционала ИБ / исправления дефектов ИБ к объему разработки бизнес-функционала для данного релиза программного продукта? 16. Является ли прохождение точек контроля качества ПО обязательным требованием для выпуска релиза? 17. Влияет ли прохождение точек контроля качества ПО на вывод программного продукта в промышленную эксплуатацию? 18. Какова емкость ресурсов с компетенциями ИБ для данной организации / подразделения / команды / продукта?

В контексте инженерного процесса мы можем выделить основные базовые метрики и показатели, которые должны поддерживаться решениями класса ASOC:

Метрика	Аббревиатура	Описание
Application Business Value	ABV	Определяется для программного продукта в рамках классификации по 4 категориям его ценности для бизнеса (Mission Critical, Business Critical, Business Operational, Office Productivity).
Software Security Coverage	SSC	Отношение количества программных продуктов, охваченных контуром DevSecOps, к общему количеству программных продуктов и приложений в организации
Source Lines of Code	SLOC	Количество строк кода в репозитории исходного кода программного продукта.
Source Lines of Code by Language	SLOCL	Количество строк кода в репозитории исходного кода программного продукта, написанных на каждом из используемых в организации языков программирования.
Source Lines of Code Change	SLOCC	Количество строк кода, измененных (новых или модифицированных) в репозитории исходного кода в конкретном релизе.
Security Technical Debt	STD	Общее количество неустраненных уязвимостей в промышленной эксплуатации.
Mean Vulnerability Age	MVA	Средний возраст всех неустраненных уязвимостей с момента обнаружения уязвимости до текущего момента.
Security Risk Exposure	SRE	Совокупный риск от присутствия уязвимостей в промышленной эксплуатации, который пропорционален количеству уязвимостей (STD) и общему сроку их наличия (MVA).
Security Risk Density	SRD	Количество уязвимостей, которые были выпущены в промышленную эксплуатацию, отнесенное к общему количеству строк кода.
Application Risk Score	ARS	Рассчитывается по формуле, которая учитывает размер программного продукта, его бизнес-ценность и ряд других аспектов. В результате может быть определен как низкий / средний / высокий / критический.
Weighted Risk Index	WRI	Измеряет бизнес-риск для портфеля приложений на основе количества уязвимостей, взвешенных по степени их критичности.
Security Technical Debt Change	STDC	Разница общего количества неустраненных уязвимостей в промышленной эксплуатации от релиза к релизу (изменение STD).
Vulnerability Open Rate	VOR	Количество новых уязвимостей, обнаруженных во время подготовки и выпуска релиза.
Vulnerability Escape Rate	VER	Количество новых уязвимостей, которые были обнаружены, но не исправлены и попали в промышленную эксплуатацию.
Vulnerability Resolved Rate	VRR	Количество уязвимостей, которые были устранены во время подготовки и выпуска релиза.
Opened To Resolved Ratio	OTRR	Количество всех открытых уязвимостей в релизе, отнесенное к количеству устраненных уязвимостей в релизе.
Re-Opened To Opened Ratio	RTOR	Количество всех повторно открытых уязвимостей, отнесенное к количеству всех открытых уязвимостей (включая повторно открытые) в релизе.
Passed Security Gates Ratio	PSGR	Количество сканирований с успешно пройденным критерием качества точек контроля качества ПО, отнесенное к общему количеству сканирований с проверкой качества ПО в релизе.
Mean Time In Production	MTIP	Среднее время, которое уязвимость находится в промышленной эксплуатации с момента попадания до момента устранения.
Mean Time To Detect	MTTD	Среднее время с момента внесения нового кода, содержащего уязвимость, до момента обнаружения этой уязвимости.
Mean Time to Resolve	MTTR	Среднее время с момента обнаружения уязвимости до момента ее устранения.
Shift-Left Detection Ratio	SLDR	Соотношение количества уязвимостей, обнаруженных в каждой среде (разработка, стейджинг, пре-продакшн, продакшн), к общему количеству уязвимостей, обнаруженных в релизе.
Failed Security Pipelines Ratio	FSPR	Количество неудачно завершившихся пайплайнов ИБ, отнесенное к общему количеству пайплайнов ИБ, выполненных в релизе.
Scans in Queue Time	SQT	Время ожидания задачи сканирования ИБ с момента ее добавления в очередь до момента начала выполнения этого сканирования.
Security Scan Time	SST	Продолжительность сканирования ИБ с момента инициации до момента успешного завершения.

Схематично, взаимосвязи метрик DevSecOps в рамках производственного процесса представлены на диаграмме ниже:

Технологии Искусственного Интеллекта в ASOC

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

Наличие такого хранилища стало необходимым условием для реализации базовых AI-функций в продукте, таким образом позиционируя AppSec.Hub как ASOC-решение, ориентированное на будущее. Первым шагом стало создание возможности интеллектуальной фильтрации и корреляции уязвимостей ПО.

В перспективе я вижу возможность применения ИИ для решения более сложных задач, а именно:

На текущий момент наша R&D команда прорабатывает детали для их реализации.
Давайте рассмотрим каждую из этих задач более подробно пока на концептуальном уровне.

1.Автоматизация точек контроля качества ПО (Quality Gates).

Для повышения скорости вывода новых версий продукта необходима полноценная автоматизация процессов принятия решений (т.н. Go / No Go Decision). ИИ формирует состав и критерии прохождения точек контроля артефактов ПО в зависимости от ряда факторов и принимает решения о продвижении артефактов ПО по этапам жизненного цикла программных продуктов (разработка - тестирование - эксплуатация) в автоматическом режиме.

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

ИИ динамически формирует состав и критерии для прохождения каждой из таких точек контроля в зависимости от:

бизнес-ценности разрабатываемого приложения;
опыта и экспертизы команды разработки;
накопленной статистики по дефектам ИБ за предыдущие периоды;
прогноза плотности уязвимостей в программном коде;

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

2.Автоматизация создания конвейеров CI/CD.

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

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

Для больших команд разработки автоматизированное управление самими конвейерами CI / CD является огромным преимуществом;
Применяя технологии ИИ, появляется возможность автоматической инвентаризации всех артефактов разрабатываемых программных продуктов и формирования под них необходимых элементов конвейера с интеллектуально определенными параметрами контроля качества и защищенности в рамках контрольных точек.

3.Управление требованиями ИБ и соответствия индустриальным стандартам в реальном времени.

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

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

4.Автоматизированное исправление дефектов ИБ.

Устранение уязвимостей вручную, безусловно, задерживает сроки поставки ПО и требует вовлечение дорогостоящих ресурсов как со стороны команды разработки, так и со стороны команды ИБ.

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

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

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

Как мы видим, возможности применения искусственного интеллекта в DevSecOps достаточно широки, но реализация возможна, на наш взгляд, только при наличии полноценной системы сбора и обработки всех данных процесса разработки защищенного ПО (DevSecOps Data Warehouse), которая, в свою очередь, является неотъемлемой частью промышленных решений класса ASOC.

Заключение

На этом все. Я попытался описать не столько конкретный продукт, а сколько проиллюстрировать практический подход к реализации процесса DevSecOps на базе решений класса ASOC. AppSec.Hub присутствует в повествовании больше с точки зрения подтверждения, что наше видение реализации ASOC не теоретические изыскания, а во многих аспектах готовая платформа, которая уже применяется для управления процессом DevSecOps в ряде крупных клиентов. Мы, в Swordfish Security, непрерывно улучшаем AppSec.Hub, согласно нашей дорожной карте развития, а также совершенствуем на базе поступающих отзывов.

Основная задача - показать, что реализация ASOC важная, но в то же время крайне нетривиальная задача, которую так или иначе придется решить всем, кто строит или планирует построить DevSecOps.

В ближайших планах, но уже в 2022 году, планируется к публикации более детальная статья, где я хотел бы подробно рассмотреть нашу модель DevSecOps-метрик.

Спасибо, что дочитали до конца.

С наступающим Новым Годом!

DevSecOps by Swordfish Security. Часть вторая