Продолжаем рубрику про неочевидные возможности ASOC, которые могут улучшить пользовательский опыт. Почему неочевидные? Мало кто об этом задумывается за постоянным потоком модного нарратива про AI, LLM и прочего.
Вы когда-нибудь видели хорошие метрики и дашборды у коммерческих решений? Очень редко встречаются, можно по пальцам одной руки посчитать. Крайний пример - Mend/WhiteSource, который сейчас недоступен на российском рынке.
Мы конечно не сравниваемся с зарубежными техногигантами, но метрики CyberCodeReview могут быть для вас полезными.
Для чего вообще полезны метрики?
Если их правильно настроить, метрики будут отражать реальное текущее положение дел, как по отдельным продуктам, так и по всей компании в целом. Да, вам конечно придется поработать как минимум над инвентаризацией активов и их заведением внутри ASOC (желательно автоматизированно), что всегда не самая простая задача. Но тем не менее, если, как говорится, “запариться“, и один раз хорошо сделать метрики, вы получите:
- Уровень риска информационной безопасности исходя из найденных уязвимостей от сканеров различного класса.
- Метрики эффективности ИБ в целом и своей работы в частности.
Теперь про сами метрики
Первое, о чем стоит сказать - это о метрике степени критичности Продукта. Продукт - это базовая сущность, для которой заводятся различные ассеты, а для них файндинги/уязвимости. Так вот разные продукты могут обладать разной степенью критичности, что может зависеть от разных факторов - начиная от бизнес Value до, например, наличия опубликованных ручек сервиса наружу.
Степень критичности Продукта - это важный показатель для подсчета общего риска ИБ. Соответственно, в нашем ASOC вы можете указать степень критичности для каждого Продукта, обозначается она цифрой от 1 до 10. Степень критичности можно указать либо вручную, либо посредством опросника, в результате заполнения которого вы получите итоговую цифру критичности Продукта.
Далее, каждый файндинг, найденный и верифицированный автоматически или вручную, будет также влиять на общую оценку риска ИБ. Для каждой степени критичности файндинга/уязвимости вы можете выставить веса, например для уязвимостей высокого уровня критичности (high) выставим вес 5, а для низкого уровня критичности (low) - 2. Что с этим происходит дальше? С помощью данных весов, количества уязвимостей каждой степени критичности, а также критичности самого Продукта, мы получаем общую метрику общего риска по Продукту. А если сложить все риски Продуктов - общий риск по всей Компании.
Просто? Очень! И это будет работать, если с умом подойти к выставлению весов и степеней критичности Продуктов.
Хорошо, вот получили мы N-ую цифру, которая обозначает некоторый общий риск. А это много или мало? Для того, чтобы указать внутри ASOC “много это или мало“, у вас есть возможность указать пороговое значение риска, как для каждого Продукта, так и для всей Компании.
Теперь давайте соберем в кучу: есть некоторые метрики - критичность продукта, веса степеней критичности уязвимостей, пороговые значения критичности. А также есть формула подсчета общего риска исходя из количества подтвержденных уязвимостей. Если все это грамотно визуализировать, получатся наши дашборды, на которых вы увидите:
- Динамику общего риска как по Продукту, так и по всей Компании
- Текущий риск в процентах от приемлемого/порогового значения
- Среднее время перехода уязвимости из одного статуса, например, Создано, в другой, например, Проверено (SLA).
- Количественные показатели по сменам статусов уязвимости, выполненные как вручную, так и автоматизированно
Да, в перечне визуализаций на дашборде я упомянул SLA - действительно, это еще одна метрика, которая настраивается для каждого уровня критичности уязвимости, что добавляет информации AppSec-у о том, в каком приоритете стоит обрабатывать файндинги.
А ваш ASOC такое умеет? Если нет, тогда приходите к нам!
