Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Всем привет!
Меня зовут Анастасия Арсеньева, я аналитик данных в Swordfish Security. Продолжаем рассказывать вам о метриках безопасной разработки — и показывать их на дашбордах модуля визуализации метрик DevSecOps платформы AppSec.Hub. Напомню, мы уже писали об оценке рисков ИБ, о зрелости подхода Shift Left и об обработке найденных уязвимостей.
В предыдущей статье мы начали говорить о проверках ИБ в контексте принципов DORA, а сегодня разберем вторую часть дашборда по сканированиям ИБ и попробуем ответить на вопрос: «Как оценить покрытие практиками ИБ приложения/всех систем?»
Понятие AppSec Coverage
Нельзя интегрировать безопасность в DevOps и построить DevSecOps без регулярного автоматического сканирования безопасности при разработке приложений. Однако внедрение проверок ИБ не может произойти «по щелчку пальцев», вне зависимости от количества вложенных средств. Это сложный процесс, эффективность которого необходимо отслеживать, а значит, нужна метрика, которая позволит ответить на следующие вопросы: «Какое сейчас покрытие практиками ИБ всех систем? Каким оно было месяц назад или квартал назад? С какой скоростью мы внедряем эти практики? В какой момент мы достигнем целевого уровня зрелости?»
Метрики сканирования, о которых мы говорили, — «Частота сканирования», «Среднее время успешных сканирований, «Коэффициент пройденных контрольных точек» — важны для оценки эффективности процессов сканирования, но они не отражают полной картины покрытия систем и подсистем практиками ИБ.
Чтобы получать более полное представление о безопасности вашего продукта в любой момент времени, следить за общим прогрессом интеграции приложений и команд, оценивать уровень покрытия их практиками ИБ и регулярность применения практик, нужно использовать перечисленные выше метрики совместно с другими.
Решить эти задачи поможет метрика AppSec Coverage («Покрытие практиками ИБ»). Чтобы визуализировать ее в нашем модуле AppSec.Hub, потребовалось разделить понятие «покрытие практиками» на 2 части: «покрытие практиками ИБ» и «применение практик ИБ», и спроектировать «дашборд в дашборде».
Особенность расчета этих метрик в том, что одно приложение может содержать различные элементы: и несколько кодовых баз, и артефакты сборки, и стенды. Инструмент класса ASOC, такой как AppSec.Hub, может сканировать все эти элементы ПО одновременно различными сканерами в рамках различных практик ИБ, и на вопрос, какое же приложение считать покрытым практиками, сложно дать однозначный ответ. Расскажем, какие критерии применяем мы для расчета.
Процент покрытия практиками ИБ
Важная часть онбординга при использовании инструмента класса ASOC — настройка пайплайнов сканирования для различных элементов приложения: без этого запустить сканирование вообще не получится.
Мы считаем покрытыми практиками ИБ те элементы приложения, для которых на дату измерения был настроен пайплайн сканирования безопасности и проведено хотя бы одно сканирование.
Как считаем:
Считаем отношение количества элементов ПО, для которых была произведена настройка и запущено хотя бы одно сканирование, к общему количеству элементов ПО. Рассчитываем метрику по всему объему систем и в разрезе вида элементов: для кодовых баз, для артефактов сборки и для стендов отдельно.
Анализ:
Целевое значение для метрики рассчитывается исходя из уровня внедрения DevSecOps. Возможные значения: к концу первого года внедрения покрыто практиками 25% систем, к концу второго — 50%, к концу третьего – 100%.
На дашборде:
Мы видим, что покрыты практиками 87,6% от всех элементов ПО, причем выше всего показатель у кодовых баз. Из 35 артефактов сборки только для 80% произведена настройка пайплайнов сканирования ИБ, то есть онбординг не прошел успешно у 20% артефактов.
На графиках ниже мы можем оценить динамику покрытия практиками, включая как процентное соотношение, так и конкретное количество элементов ПО, охваченных и неохваченных практиками ИБ.
В нижней части страницы мы видим таблицу с информацией о каждом приложении. Возможность сортировки здесь позволяет определить, какие конкретно приложения или их компоненты не покрыты практиками ИБ.
Процент применения практик ИБ
Подключение сканера ИБ, настройка пайплайна, проведенное сканирование говорят лишь о том, что когда-то внедрение этой практики было выполнено, но с точки зрения процесса безопасной разработки этого мало. Только регулярное применение практик ИБ может дать сдвиг влево (Shift Left) и позволит отслеживать проблемы безопасности на всех этапах разработки, включая самые ранние.
Оценить качество применения практик поможет нам вторая часть метрики — и вторая часть дашборда.
Как измерить необходимую регулярность сканирования? С учетом того, что уровень зрелости DevOps у команд и релизный цикл у каждого приложения разный, регулярность сканирования тоже требуется разная: одно приложение обязательно нужно сканировать раз в неделю, другое — каждый день, третье — хотя бы раз в месяц.
Общий подход должен учитывать специфику каждого элемента и контекст его использования, обеспечивая баланс между безопасностью и оперативной эффективностью.
Как считаем:
Для каждого элемента приложения мы вычисляем количество запущенных сканирований в заранее установленный целевой период относительно даты измерения. Если в целевой период было начато хотя бы одно сканирование, мы считаем, что элемент сканируется вовремя.
Процент применения рассчитывается на текущую дату, отдельно по каждой практике ИБ, как отношение количества элементов ПО, сканируемых вовремя, к общему количеству элементов ПО, для которых настроены пайплайны ИБ.
Анализ:
Целевой процент применения практик ИБ при внедренном DevSecOps должен стремиться к 100% — все элементы приложений в контуре безопасной разработки должны сканироваться с заданной регулярностью. В переходный период целевой процент может определяться внутрикорпоративной политикой. К примеру, практикой SAST должны регулярно сканироваться не менее 80% кодовых баз, практикой SCA — не менее 90% кодовых баз и артефактов сборки, практикой DAST — не менее 20% стендов.
На дашборде:
Мы видим, что процент применения практик колеблется от 16 до 26%, что далеко от целевых показателей. Причем процент использования практики SCA меньше для артефактов сборки, чем для исходного кода (17% vs 23%).
Правая часть дашборда поможет проанализировать динамику изменения метрики в целом и для каждой практики отдельно. Накопительный красно-зеленый график отражает, как с течением времени меняется количество покрытых практиками программных элементов. Он показывает, какие из них сканируются вовремя, а какие – нет.
Мы видим, что хотя в целом количество покрытых практиками элементов растет, однако они не сканируются в заданное время. Иными словами, несмотря на высокий процент покрытия, практики безопасности фактически не применяются.
Внизу дашборда есть таблица с данными по каждому приложению. В ней отражены: заданный период для сканирования, количество элементов ПО в каждом приложении, количество выполненных сканирований за последний установленный период, а также показатели, связанные с покрытием и применением практик ИБ в каждом приложении.
Например, для приложения User Management System, элементы которого должны сканироваться ежемесячно, было запущено 8 сканирований за последний месяц. Отфильтровав дашборд по этому приложению, мы можем увидеть, что стенд этого продукта в целевом периоде не сканировался вообще, была проверена только треть кодовых баз, и лишь пятая часть артефактов сборки.
Выводы
При оценке эффективности покрытия практиками ИБ нужно подходить к вопросу комплексно. Их внедрение и применение – дорога из множества шагов, каждый из которых можно и нужно измерять. Пытаясь охватить множество аспектов безопасной разработки, мы создаем модуль визуализации метрик DevSecOps в рамках платформы безопасной разработки AppSec.Hub.
В частности, довольно сложную метрику «Покрытие практиками ИБ» мы разделили на две части, поскольку и процесс покрытия практиками состоит из двух частей:
Первая часть метрики «Покрытие практиками ИБ» позволяет оценить эффективность и прогресс внедрения практик ИБ для систем и приложений. Подключение сканеров ИБ, настройка пайплайнов безопасности в инструменте класса ASOC — это важная часть онбординга при построении DevSecOps и база для успешного применения практик ИБ. Без этого этапа проведение сканирований вовсе невозможно.
Вторая часть метрики — «Применение практик ИБ» — дает возможность оценить один из важнейших показателей DevSecOps — регулярность сканирования ИБ. За счет адаптивного подхода к определению «регулярности» мы можем одним числом показать эффективность процесса сканирования ИБ по всем системам и практикам ИБ, учитывая весь контекст, включая специфику приложений, зрелость DevSecOps и циклы разработки.
Таким образом, на одном дашборде мы можем оценить и эффективность внедрения практик, и регулярность проверок ИБ для обеспечения безопасности приложений, ведь построение DevSecOps — это постоянная динамическая работа, требующая внимания к множеству аспектов, начиная от конфигурации инструментов и заканчивая регулярностью и качеством применения практик ИБ на различных этапах разработки.
До новых встреч!
