Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Всем привет!
Меня зовут Антон Башарин, я технический директор Swordfish Security, занимаюсь внедрением ИБ-практик в DevOps, построением и автоматизацией процессов безопасной разработки. В предыдущей статье мы с вами поговорили о роли инструмента класса ASOC в оптимизации работы с уязвимостями, а также проанализировали результативность его решений с помощью дашбордов, разработанных нами для модуля визуализации метрик DevSecOps в рамках развития платформы AppSec.Hub. Мы обещали вам продолжение: на этот раз покажем и расскажем, как наши графики позволяют оценить уровень зрелости подхода Shift Left и его эффективность с точки зрения информационной безопасности. Поехали!
Коротко о Shift Left
Для начала еще раз пару слов о понятии Shift Left (сдвиг влево) в контексте безопасной разработки. Суть подхода заключается в том, чтобы как можно раньше начать тестировать программный продукт на безопасность. Иными словами, ИБ-специалисты должны перенести часть проверок в начало жизненного цикла разработки ПО вместо того, чтобы проводить анализ, начиная с середины или позже (как многие делали раньше и продолжают кое-где до сих пор). Но, конечно, концепция не отменяет тестирований, которые обычно реализуются перед развертыванием. Они необходимы для выявления проблем, которые можно найти при анализе продукта целиком. То есть подход предусматривает расширение зоны конвейера CI/CD, охватываемой проверками безопасности.
Зачем это нужно? Прежде всего для того, чтобы эффективнее обрабатывать уязвимости. Концепция позволяет поддерживать оперативную обратную связь между подразделениями ИБ и разработки и выявлять проблемы на ранних стадиях в отдельных компонентах ПО по мере их завершенности или готовности к интеграции. В идеале в рамках подхода дыры устраняются сразу, а не гастролируют из сборки в сборку до тех пор, пока время и стоимость их устранения не вырастут до критических значений. Поэтому технический долг не накапливается, проверки, проводимые перед развертыванием, не оказывают негативного влияния на Time-to-Market, а в ПРОД выходят более защищенные продукты.
Реализации концепция Shift Left, как и построение процессов DevSecOps, нуждается в анализе, - только так можно совершить максимальный сдвиг влево. Дашборд, который мы разработали для модуля визуализации метрик процессов безопасной разработки, позволяет наглядно оценить зрелость Shift Left. Он включает в себя 4 раздела с графиками, раскрывающими релевантные показатели:
Среднее время обнаружения уязвимостей
Среднее время триажа проблем безопасности
Среднее время устранения ошибок
Средний возраст неустраненных проблем
Рассмотрим каждую часть дашборда. За временной отрезок возьмем период с апреля 2022 года по июнь 2023 года.
Среднее время обнаружения уязвимостей
Среднее время обнаружения уязвимостей (Mean Time to Discover, MTTD) — это период детектирования проблем безопасности с момента начала этапа/релиза. На дашборде представлен разрез по уязвимостям с разным уровнем критичности. Всего было найдено почти 18 тыс. проблем, значительная часть пришлась на ошибки уровня low. По всему портфелю систем, находящихся в контуре DevSecOps и задействованных в анализе, среднее время выявления уязвимостей составляет около 13,5 дней — и это не очень хороший показатель.
У нас много продуктов в контуре, и все они имеют свой релизный цикл. Чтобы не привязываться к конкретным временным периодам, мы учитываем при анализе квартили релизов. Считаем, что по окончании второго квартиля наступает середина цикла, далее всё движется к финальным этапам. Как видно на графике, основная масса уязвимостей обнаруживается во 2-м и 3-ем квартилях. Если говорить о соотношении проблем, поиск которых осуществляется с помощью разных инструментов, значительное преимущество на стороне ошибок, выявляемых с помощью статического анализа (SAST).
Помимо того, что уязвимости нужно обнаружить, необходимо еще иметь запас времени на триаж, исправление и повторные проверки. В идеале проблемы должны детектироваться в первом квартиле, триажиться — во втором, исправляться — в третьем, проверяться — ближе к четвертому. А в ситуации, продемонстрированной на графиках, многие сканирования, вероятно, запускаются только в середине релизного цикла, а значит, парадигма Shift-left не срабатывает. В результате специалистам остается слишком мало времени на остальные этапы работы с уязвимостями.
Рассматривая динамику обнаружения уязвимостей в контексте этапов цикла с учетом выбранного промежутка времени, можно сказать, что стабильных положительных изменений не наблюдается. Но «просветы» были, например, в ноябре-декабре 2022 года, когда часть уязвимостей всё-таки детектировалась в первом квартиле, а затем всё снова съехало вправо.
Обычно в первую очередь смотрят на проблемы уровней high и critical — добавим фильтры и изучим картину.
Ситуация не выглядит лучше, по всему портфелю систем среднее время обнаружения уязвимостей составляет чуть почти 16 дней от начала цикла. То есть, например, в рамках месячного релиза детектирование происходит примерно в середине. Здесь же (на графике в левом нижнем углу) мы видим, что наибольшее количество уязвимостей, обнаруживаемых практикой SCA, находится в самом конце релиза. Ситуация с практикой SAST лучше - проблемы уровня Critical/High чаще детектируются в первом квартиле, по сравнению с остальными.
Среднее время триажа проблем безопасности
Под средним временем триажа (Mean Time to Triage, MTT) понимается срок работы инженеров ИБ, Security Champions или разработчиков, которые проводят ручное ревью уязвимостей. В левом верхнем углу мы видим, что у специалистов уходит на это почти 84 дня. То есть с момента обнаружения проблем до того, как кто-то из сотрудников подтвердит их или отметит как false positive, примет риски или отправит уязвимости разработчикам на устранение, проходит практически три месяца.
Хорошим показателем считается период, укладывающийся в один квартиль. Если же срок растягивается до ¾ релиза и больше, значит, триаж происходит очень медленно, требуется оптимизация процессов. На графике мы видим, что подавляющая доля уязвимостей обрабатывается крайне долго. Учитывая то, что скорость детектирования проблем безопасности также хромает, скорее всего, специалисты не успевают даже посмотреть их в рамках релизного цикла, значит, уязвимости попадают в ПРОД. В случае с тем же самым месячным релизом это наверняка так и есть.
Среднее время устранения ошибок
В этой части дашборда при анализе учитываются уязвимости, которые были переданы в подразделение разработки и исправлены. В среднем на устранение проблем уходит 56 дней (Mean Time to Resolve, MTTR). А теперь прибавим к ним время детектирования (16 дней) и срок ревью (99 дня). Получается, что от обнаружения до исправления уязвимостей проходит примерно 177 дней, то есть около полугода. И это без учета техдолга.
На графике в левом нижнем углу также представлена градация по времени устранения проблем в контексте релизных циклов. Снова мы видим значительный перевес в сторону «очень медленно». Даже при трехмесячном релизе зафиксированный Lead Time находится далеко за парадигмой Shift Left. Анализируя исторический таймлайн (в правом нижнем углу), также можно утверждать, что положительная динамика отсутствует. При этом среднее время устранения уменьшается, старые уязвимости исправляются (см. верхний график справа).
Средний возраст неустраненных проблем
В рамках этого раздела дашборда рассматривается техдолг, то есть неисправленные уязвимости, которые находятся в продакшене. Их больше тысячи, четверть из них относятся к уровню critical. В среднем проблемы живут почти 196 дней (Mean Vulnerability Age, MVA) — это немного больше, чем время исправления.
Что касается динамики существования уязвимостей в рамках циклов (график в правом нижнем углу), наблюдается значительное преобладание проблем, которые живут дольше 1–2 релизов. Это говорит о том, что ошибки в основном исправляются не в текущей версии и даже не в следующей.
Как сдвинуть всё влево?
Обнаружение. Очевидно, что одномоментно реализовать серьезный сдвиг будет сложно, поэтому можно постепенно смещать детектирование с 4-го на 3-й, с 3-го на 2-й квартиль и так далее. Главная сложность этого смещения - во внедрении проверок в конвейер DevOps и в том, чтобы они выполнялись автоматически. Использование ASOC-инструментов облегчает этот процесс и позволяет в короткий срок добавить запуск SAST и SCA-проверок в рамках merge (pull) request, либо на каждый коммит (push) в интеграционную ветку.
Триаж. Как мы успели заметить, ручная обработка уязвимостей отнимает слишком много времени у специалистов, вдобавок часть проблем оказывается ложными срабатываниями, также среди ошибок нередко встречаются дубликаты. Согласно графикам, представленным выше, было обнаружено больше 3 тыс. уязвимостей уровней critical и high, а в триаж попали только 233, и их верификация при этом занимала в среднем 99,5 дней. Ускорить ревью и сократить объем рутинной работы помогают автоматизированные средства анализа: правила, машинное обучение и корреляция (группировка одинаковых уязвимостей). Более подробно о том, как инструмент класса ASOC упрощает работу с уязвимостями, можно почитать в нашей предыдущей статье.
Кроме этого, в целях оптимизации нужно перестроить процесс триажа. При этом важно, чтобы оперативная обратная связь от специалистов ИБ поступала сразу после сканирований, а не через несколько дней. Возможно дополнительно можно провести для специалистов обучающие тренинги/митапы, чтобы повысить их осведомленность о наиболее свежих (zero-day) уязвимостях, и, тем самым, сократить время на анализ.
Устранение. Основной массив уязвимостей в рамках парадигмы Shift Left должен устраняться до четвертого квартиля. Если это правило нарушается, и устранение происходит непосредственно перед релизом, то разработке приходится трудиться сверх нормы (на износ), что негативно сказывается на производительности в следующем релизе. Так же из-за недостатка времени на какие-то уязвимости, в том числе уровней critical и high, закрывают глаза. На представленных графиках видно, что в категорию исправленных попало только 52 уязвимости. В результате, технический долг разрастается и еще сильнее утяжеляет процессы.
И здесь помогут обучающие мероприятия для разработчиков, с помощью которых возможно повысить их осведомленность о способах устранения наиболее распространенных и типичных уязвимостей. Это позволит вносить исправления сразу после сканирования, не дожидаясь результатов триажа.
Подводя итог, скажу, что рецепт прост — нужно делать всё вовремя и оперативно. С первым помогут эффективная организация процессов и активности по развитию культуры безопасности в компании. Со вторым — автоматизированные инструменты.
На этом у меня всё. До новых встреч, друзья!
