Введение

Всем привет! С вами снова Антон Башарин, технический директор Swordfish Security. В предыдущих статьях мы рассказывали об обработке обнаруженных при сканировании уязвимостей – о дедубликации, автоматических правилах, приоритизации и других функциях инструмента класса ASOC, которые позволяют облегчить работу инженеру ИБ. А также о Shift-Left подходе к безопасности в разработке приложений. Сегодня мы хотим затронуть не менее важную тему в управлении ИБ. Поговорим об отслеживании технического риска информационной безопасности и его оценке для портфеля приложений. В этом мне поможет наш аналитик данных, Анастасия Арсеньева. В статье расскажем о различных метриках для оценки риска, об их сходствах и различиях, — и покажем это на дашборде, разработанном нами для модуля визуализации метрик DevSecOps в рамках развития платформы AppSec.Hub.

Зачем нужны метрики?

Риск ИБ обычно определяется как произведение вероятности атаки на потенциальный ущерб (Likelihood * Impact). Мы не можем заранее предсказать, как и когда будет атаковано приложение, но в наших силах уменьшить вероятность атаки – количество уязвимостей приложения / дефектов кода, приводящих к уязвимости.

Обнаружить и исправить проблемы ИБ — важная задача, и чем раньше в жизненном цикле разработки ПО она будет решена, тем лучше. В идеале, конечно, существования уязвимостей в готовом продукте лучше вообще не допускать, отследив их еще на этапе разработки. Но такое случается только в параллельной реальности — слишком затратно по времени и ресурсам. К тому же, в повсеместно используемом ПО на Open Source постоянно обнаруживаются новые проблемы ИБ, и в попытках исправить всё выход в ПРОМ может не состояться, так как Time-to-Market увеличится до бесконечности.

Совершенно безопасных приложений не существует, но можно и нужно оценивать степень риска ИБ разрабатываемых систем и подсистем в моменте. Для этого как раз и существуют метрики оценки риска ИБ (Software Security Risk). Также они могут помочь

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

Из множества метрик для оценки риска ИБ мы выделяем следующие:

• Технический долг

• Взвешенный индекс риска

• Плотность риска

• Подверженность риску

 Далее пройдем по каждой метрике более подробно.

Технический долг информационной безопасности

Технический долг ИБ, он же Security Technical Debt или STD – базовая и наиболее интуитивно понятная метрика для оценки риска ИБ приложения. Остальные так или иначе являются ее производными.

Как считаем:

Security Technical Debt равен количеству неисправленных уязвимостей приложения, доступных для эксплуатации в промышленной среде. STD измеряется на момент выпуска релиза. Производная метрика STDS (STD by Severity) - измерение технического долга в разрезе серьезности уязвимостей.

Что показывает:

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

Целевое значение:

STD должен быть равен нулю для критичных уязвимостей (critical&high severity). Необходимо, чтобы общий показатель уменьшался от релиза к релизу, поэтому важно измерять STD в динамике.

Кому интересна:

• Разработчикам

• Руководителю группы разработки

• Руководителю подразделения разработки

• Сотруднику ИБ, ответственному за приложение

• Руководителю ИБ

Анализ:

• Снижение объема технического долга в динамике говорит о том, что команда исправляет уязвимости безопасности быстрее, чем генерирует новые;

• Увеличение технического долга может сигнализировать как о снижении качества кода, так и о недостатке ресурсов для исправления выявленных уязвимостей;

• Информация об объёме критических уязвимостей в промышленной эксплуатации важна для настройки WAF (Web Application Firewall).

Не подходит:

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

Пример:

На дашборде STD по всем системам видно, что размер тех.долга резко увеличивается в июле. Однако на столбчатом графике в разрезе приложений мы обнаруживаем, что в большой степени это объясняется добавлением в контур DevSecOps очень уязвимого приложения Demo application. Отфильтровав данные по этому приложению, по изменению STD видно, что с июля 2023 было 2 релиза, и технический долг (STD) во втором релизе вырос более, чем в 2 раза (а STDS по критическим уязвимостям – в 1500 раз!)

Взвешенный индекс риска

Взвешенный индекс риска (Weighted Risk Index, WRI) углубляет метрику STD, позволяя одним числом показать подверженность риску, учитывая критичность (как уязвимостей, так и самих разрабатываемых приложений). Компания может разрабатывать десятки и сотни продуктов, и не все они имеют одинаковый уровень риска. Риск-профиль приложения зависит от величины финансовых, юридических, клиентских и репутационных потерь при успешной атаке. К примеру, AppSec.Hub предлагает определить профиль риска приложения по параметрам в настройках: открытость доступа к интернету, наличие чувствительных данных, количество внутренних и внешних пользователей, стадия разработки, и т. д.

Как считаем:

Weighted Risk Index - произведение суммы неисправленных уязвимостей приложения, доступных для эксплуатации в промышленной среде, взвешенных с учетом серьезности и индекса риска приложения.

Можно отобразить это в формуле: кол-во уязвимостей низкой серьезности * Multiplier_low(2) + кол-во уязвимостей средней серьезности * Multiplier_medium(5) + кол-во уязвимостей высокой серьезности * Multiplier_high(8) + кол-во уязвимостей высокой серьезности * Multiplier_critical(10)) x индекс риска приложения (RiskProfile).

WRI также измеряется на момент выпуска релиза. 

Что показывает:

WRI не только выявляет продукты, содержащие уязвимости в ПРОМ, устраняемые с недостаточной скоростью, но и позволяет сравнить их между собой по степени риска – чем выше серьезность уязвимостей, тем выше будет значение метрики. Здесь критичные для бизнеса системы будут иметь показатель выше, чем системы уровня office productivity при равном количестве вышедших в ПРОМ уязвимостей.

WRI можно использовать для отслеживания изменения риска по всему портфелю приложений.

Целевое значение:

Показатель WRI для всех систем и отдельных приложений должен уменьшаться от релиза к релизу. 

Кому интересна:

• Руководителю подразделения разработки

• Руководителю ИБ

Анализ:

• Метрика используется для определения наиболее уязвимых приложений с учетом их критичности для бизнеса, на ее основе формируется топ продуктов с наибольшим риском;

• Снижение WRI в динамике при неизменном STD говорит о верной расстановке приоритетов – несмотря на то, что команда исправляет столько же уязвимостей, сколько возникает новых, корректируются прежде всего те, что имеют критический и серьезный уровень, а генерируются low и medium;

• Соответственно, рост WRI при условии, что STD не меняется, говорит о том, что исправляются уязвимости низкой степени серьезности, а новые критические уязвимости уходят в ПРОМ;

• Также изменение WRI может свидетельствовать об обновлении риск-профиля приложения, о необходимости перераспределения ресурсов для обеспечения приемлемого уровня риска ИБ.

Не подходит:

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

Пример:

На дашборде сравниваются два приложения с почти одинаковым количеством уязвимостей (и одинаковым риск-профилем). Мы видим, что WRI выше у приложения Authentication Service, хотя количество уязвимостей в нем на 3 меньше, чем в Access Management System. Это потому, что у него больший процент уязвимостей высокой и критичной степеней серьезности. В динамике видно, что WRI приложения Authentication Service растет, в отличие от второго. Также в таблице указан размер приложения в SLOC (Source lines of code, количество значимых строк кода без пробелов и комментариев). Он не используется для расчета метрики, однако нужен для понимания того, насколько отличается размер анализируемых приложений.

Плотность риска безопасности

Плотность риска безопасности (Security Risk Density, SRD) – еще одна метрика, производная от Security Technical Debt. Risk Density нормирует объем технической задолженности безопасности на количество строк кода, позволяя оценить качество кода с точки зрения ИБ.

Как считаем:

Security Risk Density (SRD) – количество неисправленных уязвимостей приложения на 1000 строк кода (1000(K) Source lines of code, КSLOC). Учитываются только неисправленные проблемы в ПРОМ с учетом их серьезности, и значимые строки кода без пробелов и комментариев.

Что показывает:

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

Целевое значение:

Плотность риска должна уменьшаться от релиза к релизу.

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

Кому интересна:

• Руководителю группы разработки

• Руководителю подразделения разработки

• Руководителю ИБ

Анализ:

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

• Слишком низкая плотность риска может сигнализировать о недостаточном тестировании ИБ – возможно, часть уязвимостей в коде просто не находят, нужно обратить внимание на частоту сканирования и настройки сканеров ИБ.

Не подходит:

Для оценки риска приложений, для которых не применяется практика SAST, а сканируются только артефакты сборки и стенды (практики SCA, DAST). Например, для оценки риска решений подрядчиков, которые не передают исходники.  

Пример:

Резкое падение плотности риска приложения User Management System в феврале объясняется не уменьшением технического долга, а введением в контур DevSecOps большого объёма нового кода.

Подверженность риску безопасности

Коротко расскажем еще об одной метрике для оценки риска ИБ – основанной на подверженности риску ИБ (Software Security Risk Exposure, SSRE). Она не входит в базовый набор модуля аналитики AppSec.Hub, и относится к уровню менеджмента, а не к операционному.

Как считаем:

Software Security Risk Exposure (SSRE) – произведение количества неисправленных уязвимостей приложения, доступных для эксплуатации в промышленной среде, и их среднего возраста в днях. Измеряется от релиза к релизу. Метрика рассчитывается для уязвимостей критического и высокого уровня серьезности.

Что показывает:

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

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

Целевое значение:

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

Кому интересна:

• Руководителю разработки приложений

• Руководителю ИБ

Пример:

На дашборде есть разрезы для сравнения метрики между юнитами оргструктуры компании – по отделам, подразделениям, командам. Также возможно проводить оценку приложений, включая сравнение между юнитами в моменте, учитывая тенденцию изменения метрики в динамике. Отфильтровав данные, мы можем понять, чем объясняется показатель метрики для наиболее подверженных риску команд и приложений – генерацией новых уязвимостей или «зависанием» неисправленных проблем в течение многих релизов. К примеру, на дашборде растущий SSRE приложения Test Application объясняется увеличивающимся с каждым релизом возрастом неисправленных уязвимостей при неизменном объеме тех.долга.

Вывод

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

Что касается рассмотренных метрик риска ИБ, среди них нет «серебряной пули» — метрики, которая учитывала бы все аспекты одновременно, была бы универсальной для всех компаний, подразделений и команд. Но то же самое можно сказать и о других метриках в ИБ – как нет идеальной траектории построения и развития DevSecOps, так и нет идеальной метрики. Каждый выбирает набор инструментов для решения своих задач, а модуль аналитики AppSec.Hub помогает определиться с тем, что действительно необходимо именно вам. До новых встреч!