Привет!
Меня зовут Антон Башарин, я работаю в компании Swordfish Security и занимаюсь построением и автоматизацией процессов разработки защищенного ПО, в том числе интеграцией практик информационной безопасности в DevOps. Вместе с моей коллегой Анастасией Арсеньевой мы собрали в один материал основные проблемы, чаще всего встречающиеся при обработке уязвимостей ИБ, и постарались разобраться, как можно оптимизировать этот процесс с помощью инструмента класса ASOC. Ниже описаны решения и «показана» эффективность их применения с помощью дашбордов, которые мы разработали для модуля визуализации метрик DevSecOps в рамках развития нашего продукта AppSec.Hub, реализующего практику ASOC. Мы взяли эту платформу лишь с той целью, чтобы с практической точки зрения раскрыть спектр возможностей решения класса ASOC. Итак, поехали!
В настоящее время стандартом IT-индустрии является методология DevOps (автоматизация технологических процессов сборки, настройки и развертывания ПО). Показатели производительности DevOps, согласно парадигме DORA, – три метрики, отвечающие за скорость поставки, и одна – за качество ПО (процент изменений кода, приводящих к сбоям, должен стремиться к нулю).
Если говорить о том, что команде или всей компании необходимо соответствовать требованиям регуляторов и корпоративным политикам ИБ, то без встраивания проверок ИБ в налаженные процессы DevOps не обойтись. Таким образом, реализация DevSecOps-подхода будет влиять на метрики DevOps, о которых говорили выше. Например, скорость сканирования с помощью инструментов ИБ может уменьшать скорость поставки, а неправильно организованный процесс обработки результатов, полученных из этих же инструментов, будет ухудшать качество ПО. Далее поговорим именно про обработку результатов и о том, как можно оптимизировать этот процесс, опираясь на цифры и графики.
При попытке интеграции инструментов анализа защищенности приложений в конвейер CI/CD многие компании сталкиваются с потерями в скорости разработки на нескольких этапах обработки уязвимостей. Ниже мы опишем основные ситуации и связанные с ними сложности:
Во-первых, сканеров ИБ, позволяющих обнаружить уязвимости различного вида на разных этапах разработки, довольно много, и у каждого – свой интерфейс, особенности работы и формат вывода результатов сканирования.
Одна и та же проблема безопасности может дублироваться, будучи обнаруженной различными сканерами или при повторной проверке. К тому же некоторые инструменты и практики ИБ могут выдавать большое количество ложных срабатываний. Разбор и сопоставление всех результатов проверок ИБ (триаж) для отсева повторных и ложных срабатываний отнимают немало времени у инженеров безопасности.
Во-вторых, мало обнаружить уязвимость, нужно еще ее устранить. Однако временнЫе, человеческие и финансовые ресурсы небезграничны, все выявленные дефекты убрать невозможно, да и не нужно. Рациональным решением будет сосредоточиться на ликвидации тех проблем, которые несут в себе больше всего риска.
А это значит, что перед передачей уязвимостей команде разработки необходимо приоритизировать результаты сканирований, определив, какие из ошибок наиболее серьезны и обязательны к устранению, какие – желательны, а какие из них (вместе с рисками) компания готова принять. Частично осуществлять такое ранжирование могут инструменты ИБ. Однако классификация уязвимостей может быть разной, а это значит, что бОльшая часть работы по приоритизации опять выполняется командой инженеров ИБ вручную.
Наконец, приоритизированные уязвимости нужно передать в разработку для исправления, и не всегда это происходит в удобном для разработчика виде. Некоторые инструменты управления позволяют выгрузить результаты сканирования напрямую в дефект-трекинговую систему. Однако тогда разбор и анализ однотипных проблем становятся ответственностью команды разработки, а значит, ее специалисты тратят время на ранжирование уязвимостей вместо того, чтобы их исправлять.
Практика показывает, что использование инструментов класса ASOC (Application Security Orchestration and Correlation) позволяет упростить тестирование и устранение уязвимостей за счет автоматизации рабочего процесса. Решения ASOC собирают и объединяют результаты сканирования из всех используемых инструментов ИБ, сопоставляют их, отдавая приоритет критически важным уязвимостям. Пройдя через все стадии автоматической и ручной обработки, анализа, приоритизации и корреляции, уязвимости преобразуются в дефекты, экспортируемые в дефект-трекинговую систему команды разработки для исправления.
Основные стадии обработки результатов сканирования:
Более подробно рассмотрим эти стадии и их эффективность на примере соответствующего дашборда:
Дашборд эффективности обработки уязвимостей после сканирования
Структурно дашборд делится на 3 части: центральная иллюстрирует поток обработки и корреляции в числовых и процентных показателях, верхняя панель отображает метрики производительности каждого этапа обработки, нижняя позволяет оценить эти показатели в различных разрезах.
Этапы обработки уязвимостей
Этапы обработки уязвимостей
На центральной части дашборда показаны этапы обработки, которые проходят результаты проверок ИБ, трансформируясь в нижней части воронки в дефекты, автоматически выгружаемые в дефект-трекинговую систему. Слева – показатели в количественном выражении (первые 5 этапов – уязвимости, шестой – дефекты), справа те же стадии – в процентах от первоначального числа результатов сканирования.
С каждым уровнем число уязвимостей уменьшается, и на финальной стадии обработки они трансформируются в дефекты, направляемые в команду разработки для устранения. Обработка производится как автоматически, так и посредством привлечения инженеров ИБ.
Переход от стадии к стадии в процентном соотношении показан на верхней панели.
Эффективность каждого этапа обработки
Чтобы оценить вклад каждого этапа и сделать выводы о его эффективности, расскажем подробнее о процессе обработки результатов сканирования.
Дедубликация – процесс автоматического анализа уязвимостей с выделением первично и повторно обнаруженных проблем.
Не каждой уязвимости, найденной при сканировании, присваивается уникальный номер –вначале система проводит анализ результатов проверки на предмет дубликатов/повторов. Если выясняется, что данные о проблеме уже есть, система обновляет существующую запись, не плодя новые сущности.
На графике воронки данный этап обозначен как число уязвимостей, оставшихся после исключения повторных срабатываний.
Количество уязвимостей после отсеивания дубликатов
Процент повторно выявленных уязвимостей
В панели метрик «Дубликаты, %» – отношение повторных срабатываний к общему количеству выявленных уязвимостей.
Низкий % дубликатов характерен для активно меняющегося кода (кардинально разные результаты от сканирования к сканированию). Чаще наблюдается при рефакторинге или изменении архитектуры системы.
Высокий % дубликатов говорит нам о небольшом количестве изменений в коде, его стабильности. Такая ситуация часто наблюдается в системах, которые еще эксплуатируются, но не развиваются (например, ведется разработка системы, которая должна заменить текущую).
Применение правил обработки уязвимостей – процесс автоматического отсеивания ложных срабатываний/принятия риска в соответствии с правилами, заранее настроенными инженером ИБ.
Здесь результаты сканирования проходят через «фильтр» автоматических правил обработки. Инженер ИБ может настроить их таким образом, чтобы часто встречающиеся ложные срабатывания, которые ранее приходилось обрабатывать вручную, еще до начала триажа автоматически получали статус False Positive. Аналогично можно настроить автоматические правила принятия риска.
На графике воронки данный этап обозначен как число уязвимостей, оставшихся после применения автоматических правил и требующих ручного разбора.
Количество уязвимостей после применения правил
Эффективность применения правил
В панели метрик «Применение rules, %» – отношение уязвимостей, автоматически помеченных False Positive или Accepted risk к уязвимостям (без учета дубликатов) по заранее настроенным инженером ИБ правилам.
Низкий % применения правил свидетельствует о том, что инженер редко использует функционал правил автоматической обработки и вынужден больше времени и сил тратить на ручной разбор уязвимостей.
Триаж – ручная обработка и анализа выявленных уязвимостей, который проводит инженер безопасности.
Уязвимости, к которым не были применены автоматические правила обработки, должны быть вручную разобраны инженером ИБ. Основываясь на данном показателе, можно видеть, насколько сотрудники подразделения безопасности, ответственные за обработку результатов сканирования, справляются с объемом работы. Фактически все выявленные на предыдущих этапах и не обработанные уязвимости являются техническим долгом для инженеров ИБ.
Количество обработанных уязвимостей вручную
Эффективность ручного ревью
«Триаж, %» рассчитывается как отношение рассмотренных инженером ИБ уязвимостей к количеству проблем, требующих обработки (результат после применения автоматических правил).
Данный показатель должен быть близок к 100% (особенно для уязвимостей высокой и критической серьезности). Низкий % может свидетельствовать о кадровом голоде или низком приоритете задач триажа инженеров ИБ. Если низкий % триажа сочетается с низким % применения автоматических правил, рекомендуется обратить внимание на настройку правил обработки, чтобы сэкономить время на ручном разборе, уменьшая таким образом размер технического долга.
Приоритизация – процесс анализа и оценки рисков инженером ИБ при обработке уязвимостей для выбора проблем, приоритетных для исправления.
На данном этапе инженер ИБ анализирует уязвимости, чтобы определить те, которые необходимо устранить в первую очередь.
Результат этапа – уязвимости, назначенные инженером ИБ для исправления, однако до отправки в дефект-трекинговую систему команды разработки они проходят еще одну трансформацию (корреляцию и группировку уязвимостей в дефекты).
Количество уязвимостей переданных в разработку
Эффективность приоритизации
«Приоритизация, %» – отношение приоритизированных уязвимостей, обработанных инженером ИБ, которые в дальнейшем объединяются в дефекты и направляются на устранение в команду разработки, к количеству всех проблем, рассмотренных специалистом по безопасности.
По данному показателю можно судить о том, какую часть выявленных проблем безопасности инженер ИБ выделяет для исправления и передачи в разработку. Низкий % говорит о большом числе ложных срабатываний (регулируется настройками сканеров ИБ и автоматических правил обработки) или большом % принятия рисков (может сигнализировать о формальном подходе или игнорировании требований безопасности, т. е. принятии риска вместо устранения уязвимостей).
Корреляция – процесс создания дефекта для отправки его в дефект-трекинговую систему команды разработки на базе приоритизированных уязвимостей. Критериями группировки могут являться: тип, CWE ID, имя файла, номер строки кода в файле, статус, категория, критичность уязвимости.
Этот процесс позволяет объединять однотипные/похожие/найденные рядом в коде уязвимости в значительно меньшее число дефектов, а значит, экономить время и ресурс команды разработки на их устранение.
Количество сформированных дефектов
Эффективности группировки уязвимостей
Корреляция, % – отношение количества дефектов к числу приоритизированных уязвимостей.
Разобрав этапы более подробно теперь можно сказать, что этот дашборда позволяет нам на одном экране увидеть поток обработки уязвимостей от результатов сканирования до передачи их в разработку в виде дефектов. Мы можем оценить эффективность процесса в целом и отдельно каждого его этапа: как применяется функционал инструмента класса ASOC по обработке уязвимостей (автоматическое исключение дубликатов, применения правил обработки, корреляция), как происходит ручная обработка сотрудниками команды ИБ (триаж, приоритизация). Это позволяет в том числе оценить технический долг по триажу (анализу) уязвимостей.
А понимая контекст, мы сможем принять решения, помогающие увеличить эффективность обработки уязвимостей командой инженеров ИБ – например, за счет уменьшения доли ручного труда инженеров ИБ по разбору и анализу через настройку автоматических правил.
Оценка процесса в разных контекстах
Нижняя часть дашборда позволяет нам оценить поток обработки уязвимостей и показатели эффективности каждого этапа в различных разрезах: в разбивке по серьезности уязвимостей, практикам и инструментам обнаружения, приложениям.
Структурно каждая вкладка состоит из двух частей: слева находится график «радар», который позволяет сравнивать между собой сущности сразу по нескольким показателям (в левой части – последовательные шаги количественной «воронки», справа на тех же уровнях – соответствующие показатели эффективности этапов). На графике «радар» хорошо видны максимальные значения, а выявить аутсайдеров по разным показателям помогут две таблицы, расположенные справа: отдельно количественные показатели, отдельно параметры эффективности прохождения этапов обработки.
Анализ процесса в разрезе по серьёзности уязвимостей
К примеру, мы видим, что чаще всего выявляются уязвимости низкого уровня серьезности (что вполне естественно), а автоматические правила обработки настроены в основном для проблем критической и высокой степени серьезности. % триажа тоже выше для критических уязвимостей.
Анализ процесса в контексте систем/приложений
На графиках мы видим, что одно приложение (User Management System) – явный лидер по количественным показателям, однако у него сильно отстает от других показатель эффективности приоритизации: направляются в работу только 5% проанализированных уязвимостей.
Давайте попробуем понять причину этого, отфильтровав данные, оставив только приложение User Management System, и оценив поток обработки в разрезе сканеров/практик ИБ.
Что касается показателей по практике и сканерам ИБ, есть небольшое отличие от других измерений. Поскольку система, отсеивая повторно выявленные уязвимости, не создает для каждой проблемы отдельную запись, мы можем с уверенностью говорить только об уязвимостях без учета дубликатов, обнаруженных с помощью каждой практики/сканера.
Анализ процесса в контексте применяемых практик
Фокус на используемые сканеры
Возвращаясь к обнаруженному «бутылочному горлышку» приоритизации уязвимостей: отфильтровав данные по приложению User Management System, мы видим, что наименьший показатель эффективности приоритизации у уязвимостей, выявленных практикой SAST. Только 3% от проанализированных уязвимостей направляется в работу, что лишний раз иллюстрирует большое количество ложных срабатываний у анализаторов кода, используемых «из коробки» (без дополнительной настройки под анализируемые системы). Ещё можно обратить внимание на то, что автоматические правила обработки почти не настроены. Менее 1% из выявленных уязвимостей обрабатываются автоматически – инженер ИБ тратит много времени на ручной анализ каждого срабатывания, тем временем накапливая технический долг по разбору остальных уязвимостей.
Фильтры
Разумеется, дашборд – это интерактивный инструмент, который можно гибко настроить для получения ответов на конкретные вопросы, применив фильтры. По умолчанию отображаются данные за все время использования инструментов ИБ в процессе безопасной разработки компании, однако можно выбрать период покороче (фильтр по дате сканирования) для анализа ситуации за текущий/прошлый месяц/год и т. д. Также вполне реально отфильтровать данные по каждому приложению, практике, сканеру ИБ и серьезности.
Мы рассмотрели один из аспектов DevSecOps – процесс обработки выявленных уязвимостей ИБ – на примере инструмента класса ASOC. Подведем итоги. Использование таких решений помогает упростить обработку результатов сканирования и увеличить скорость поставки ПО за счет автоматизации сразу нескольких важных процессов.
Во-первых, решения ASOC (в части, отвечающей за оркестрацию) позволяют подключать разные сканеры и практики ИБ и управлять запуском тестирований «из одного окна», собирая и автоматически анализируя результаты проверок: при повторном срабатывании система не будет создавать новую запись об обнаруженной уязвимости, а обновит запись найденной ранее проблемы. Настройка автоматических правил обработки позволяет значительно сократить время, которое затрачивается на ручной отсев ложных срабатываний, часто выдаваемых некоторыми сканерами ИБ. Автоматические правила можно настроить и для принятия риска.
Во-вторых, в сканерах ИБ может быть разное число степеней критичности уязвимостей, и обозначаться они могут тоже по-разному. – Инструмент класса ASOC позволяет ввести прозрачную систему классификации проблем по уровню серьезности (критический, высокий, средний, низкий). Это приводит к сокращению времени на анализ и приоритизацию уязвимостей для передачи наиболее важных на исправление в разработку.
И в-третьих, такие решения реализуют корреляцию. Приоритизированные уязвимости передаются для исправления в команду разработки не списком в виде отчета, а автоматически экспортируются в дефект-трекинговую систему в качестве сформированных дефектов. При этом инженер ИБ может объединить однотипные/похожие/найденные рядом в коде уязвимости в значительно меньшее число дефектов, добавив комментарии и рекомендации. Это улучшает взаимодействие команд безопасности и разработки и сокращает время на исправление проблем ИБ.
В целом внедрение практик ИБ в DevOps и реализация DevSecOps – задача с большой звездочкой. Единого подхода к ее решению пока нет, поэтому компании по-разному строят процесс безопасной разработки и зачастую сталкиваются с серьезными проблемами в части реализации и управления DevSecOps. В ответ на этот вызов продукты класса ASOC предоставляют универсальные возможности, позволяющие построить процесс безопасной разработки, применяя комплексный и централизованный подход.
Но реализовать DevSecOps – это всего лишь полдела. Важно оценивать, анализировать его в действии и на основе полученных данных направлять многочисленные процессы в нужные стороны, чтобы добиться желаемых показателей эффективности. Как раз для этого наша команда и разрабатывает в рамках AppSec.Hub модуль визуализации метрик DevSecOps. Мы продолжим делиться им с вами, рассматривая процессы и метрики безопасной разработки на графиках и дашбордах.
Так что до новых встреч, друзья!
Меня зовут Антон Башарин, я работаю в компании Swordfish Security и занимаюсь построением и автоматизацией процессов разработки защищенного ПО, в том числе интеграцией практик информационной безопасности в DevOps. Вместе с моей коллегой Анастасией Арсеньевой мы собрали в один материал основные проблемы, чаще всего встречающиеся при обработке уязвимостей ИБ, и постарались разобраться, как можно оптимизировать этот процесс с помощью инструмента класса ASOC. Ниже описаны решения и «показана» эффективность их применения с помощью дашбордов, которые мы разработали для модуля визуализации метрик DevSecOps в рамках развития нашего продукта AppSec.Hub, реализующего практику ASOC. Мы взяли эту платформу лишь с той целью, чтобы с практической точки зрения раскрыть спектр возможностей решения класса ASOC. Итак, поехали!
DevOps и DevSecOps
В настоящее время стандартом IT-индустрии является методология DevOps (автоматизация технологических процессов сборки, настройки и развертывания ПО). Показатели производительности DevOps, согласно парадигме DORA, – три метрики, отвечающие за скорость поставки, и одна – за качество ПО (процент изменений кода, приводящих к сбоям, должен стремиться к нулю).
Если говорить о том, что команде или всей компании необходимо соответствовать требованиям регуляторов и корпоративным политикам ИБ, то без встраивания проверок ИБ в налаженные процессы DevOps не обойтись. Таким образом, реализация DevSecOps-подхода будет влиять на метрики DevOps, о которых говорили выше. Например, скорость сканирования с помощью инструментов ИБ может уменьшать скорость поставки, а неправильно организованный процесс обработки результатов, полученных из этих же инструментов, будет ухудшать качество ПО. Далее поговорим именно про обработку результатов и о том, как можно оптимизировать этот процесс, опираясь на цифры и графики.
Узкие места в обработке результатов проверок ИБ
При попытке интеграции инструментов анализа защищенности приложений в конвейер CI/CD многие компании сталкиваются с потерями в скорости разработки на нескольких этапах обработки уязвимостей. Ниже мы опишем основные ситуации и связанные с ними сложности:
Во-первых, сканеров ИБ, позволяющих обнаружить уязвимости различного вида на разных этапах разработки, довольно много, и у каждого – свой интерфейс, особенности работы и формат вывода результатов сканирования.
Одна и та же проблема безопасности может дублироваться, будучи обнаруженной различными сканерами или при повторной проверке. К тому же некоторые инструменты и практики ИБ могут выдавать большое количество ложных срабатываний. Разбор и сопоставление всех результатов проверок ИБ (триаж) для отсева повторных и ложных срабатываний отнимают немало времени у инженеров безопасности.
Во-вторых, мало обнаружить уязвимость, нужно еще ее устранить. Однако временнЫе, человеческие и финансовые ресурсы небезграничны, все выявленные дефекты убрать невозможно, да и не нужно. Рациональным решением будет сосредоточиться на ликвидации тех проблем, которые несут в себе больше всего риска.
А это значит, что перед передачей уязвимостей команде разработки необходимо приоритизировать результаты сканирований, определив, какие из ошибок наиболее серьезны и обязательны к устранению, какие – желательны, а какие из них (вместе с рисками) компания готова принять. Частично осуществлять такое ранжирование могут инструменты ИБ. Однако классификация уязвимостей может быть разной, а это значит, что бОльшая часть работы по приоритизации опять выполняется командой инженеров ИБ вручную.
Наконец, приоритизированные уязвимости нужно передать в разработку для исправления, и не всегда это происходит в удобном для разработчика виде. Некоторые инструменты управления позволяют выгрузить результаты сканирования напрямую в дефект-трекинговую систему. Однако тогда разбор и анализ однотипных проблем становятся ответственностью команды разработки, а значит, ее специалисты тратят время на ранжирование уязвимостей вместо того, чтобы их исправлять.
ASOC как часть DevSecOps
Практика показывает, что использование инструментов класса ASOC (Application Security Orchestration and Correlation) позволяет упростить тестирование и устранение уязвимостей за счет автоматизации рабочего процесса. Решения ASOC собирают и объединяют результаты сканирования из всех используемых инструментов ИБ, сопоставляют их, отдавая приоритет критически важным уязвимостям. Пройдя через все стадии автоматической и ручной обработки, анализа, приоритизации и корреляции, уязвимости преобразуются в дефекты, экспортируемые в дефект-трекинговую систему команды разработки для исправления.
Основные стадии обработки результатов сканирования:
Дедубликация
Применение автоматических правил обработки
Триаж
Приоритизация
Корреляция
Более подробно рассмотрим эти стадии и их эффективность на примере соответствующего дашборда:
Структурно дашборд делится на 3 части: центральная иллюстрирует поток обработки и корреляции в числовых и процентных показателях, верхняя панель отображает метрики производительности каждого этапа обработки, нижняя позволяет оценить эти показатели в различных разрезах.
Этапы обработки уязвимостей
На центральной части дашборда показаны этапы обработки, которые проходят результаты проверок ИБ, трансформируясь в нижней части воронки в дефекты, автоматически выгружаемые в дефект-трекинговую систему. Слева – показатели в количественном выражении (первые 5 этапов – уязвимости, шестой – дефекты), справа те же стадии – в процентах от первоначального числа результатов сканирования.
С каждым уровнем число уязвимостей уменьшается, и на финальной стадии обработки они трансформируются в дефекты, направляемые в команду разработки для устранения. Обработка производится как автоматически, так и посредством привлечения инженеров ИБ.
Переход от стадии к стадии в процентном соотношении показан на верхней панели.
Чтобы оценить вклад каждого этапа и сделать выводы о его эффективности, расскажем подробнее о процессе обработки результатов сканирования.
Дедубликация
Дедубликация – процесс автоматического анализа уязвимостей с выделением первично и повторно обнаруженных проблем.
Не каждой уязвимости, найденной при сканировании, присваивается уникальный номер –вначале система проводит анализ результатов проверки на предмет дубликатов/повторов. Если выясняется, что данные о проблеме уже есть, система обновляет существующую запись, не плодя новые сущности.
На графике воронки данный этап обозначен как число уязвимостей, оставшихся после исключения повторных срабатываний.
В панели метрик «Дубликаты, %» – отношение повторных срабатываний к общему количеству выявленных уязвимостей.
Низкий % дубликатов характерен для активно меняющегося кода (кардинально разные результаты от сканирования к сканированию). Чаще наблюдается при рефакторинге или изменении архитектуры системы.
Высокий % дубликатов говорит нам о небольшом количестве изменений в коде, его стабильности. Такая ситуация часто наблюдается в системах, которые еще эксплуатируются, но не развиваются (например, ведется разработка системы, которая должна заменить текущую).
Применение автоматических правил обработки
Применение правил обработки уязвимостей – процесс автоматического отсеивания ложных срабатываний/принятия риска в соответствии с правилами, заранее настроенными инженером ИБ.
Здесь результаты сканирования проходят через «фильтр» автоматических правил обработки. Инженер ИБ может настроить их таким образом, чтобы часто встречающиеся ложные срабатывания, которые ранее приходилось обрабатывать вручную, еще до начала триажа автоматически получали статус False Positive. Аналогично можно настроить автоматические правила принятия риска.
На графике воронки данный этап обозначен как число уязвимостей, оставшихся после применения автоматических правил и требующих ручного разбора.
В панели метрик «Применение rules, %» – отношение уязвимостей, автоматически помеченных False Positive или Accepted risk к уязвимостям (без учета дубликатов) по заранее настроенным инженером ИБ правилам.
Низкий % применения правил свидетельствует о том, что инженер редко использует функционал правил автоматической обработки и вынужден больше времени и сил тратить на ручной разбор уязвимостей.
Триаж
Триаж – ручная обработка и анализа выявленных уязвимостей, который проводит инженер безопасности.
Уязвимости, к которым не были применены автоматические правила обработки, должны быть вручную разобраны инженером ИБ. Основываясь на данном показателе, можно видеть, насколько сотрудники подразделения безопасности, ответственные за обработку результатов сканирования, справляются с объемом работы. Фактически все выявленные на предыдущих этапах и не обработанные уязвимости являются техническим долгом для инженеров ИБ.
«Триаж, %» рассчитывается как отношение рассмотренных инженером ИБ уязвимостей к количеству проблем, требующих обработки (результат после применения автоматических правил).
Данный показатель должен быть близок к 100% (особенно для уязвимостей высокой и критической серьезности). Низкий % может свидетельствовать о кадровом голоде или низком приоритете задач триажа инженеров ИБ. Если низкий % триажа сочетается с низким % применения автоматических правил, рекомендуется обратить внимание на настройку правил обработки, чтобы сэкономить время на ручном разборе, уменьшая таким образом размер технического долга.
Приоритизация
Приоритизация – процесс анализа и оценки рисков инженером ИБ при обработке уязвимостей для выбора проблем, приоритетных для исправления.
На данном этапе инженер ИБ анализирует уязвимости, чтобы определить те, которые необходимо устранить в первую очередь.
Результат этапа – уязвимости, назначенные инженером ИБ для исправления, однако до отправки в дефект-трекинговую систему команды разработки они проходят еще одну трансформацию (корреляцию и группировку уязвимостей в дефекты).
«Приоритизация, %» – отношение приоритизированных уязвимостей, обработанных инженером ИБ, которые в дальнейшем объединяются в дефекты и направляются на устранение в команду разработки, к количеству всех проблем, рассмотренных специалистом по безопасности.
По данному показателю можно судить о том, какую часть выявленных проблем безопасности инженер ИБ выделяет для исправления и передачи в разработку. Низкий % говорит о большом числе ложных срабатываний (регулируется настройками сканеров ИБ и автоматических правил обработки) или большом % принятия рисков (может сигнализировать о формальном подходе или игнорировании требований безопасности, т. е. принятии риска вместо устранения уязвимостей).
Корреляция
Корреляция – процесс создания дефекта для отправки его в дефект-трекинговую систему команды разработки на базе приоритизированных уязвимостей. Критериями группировки могут являться: тип, CWE ID, имя файла, номер строки кода в файле, статус, категория, критичность уязвимости.
Этот процесс позволяет объединять однотипные/похожие/найденные рядом в коде уязвимости в значительно меньшее число дефектов, а значит, экономить время и ресурс команды разработки на их устранение.
Корреляция, % – отношение количества дефектов к числу приоритизированных уязвимостей.
Анализ эффективности этапов
Разобрав этапы более подробно теперь можно сказать, что этот дашборда позволяет нам на одном экране увидеть поток обработки уязвимостей от результатов сканирования до передачи их в разработку в виде дефектов. Мы можем оценить эффективность процесса в целом и отдельно каждого его этапа: как применяется функционал инструмента класса ASOC по обработке уязвимостей (автоматическое исключение дубликатов, применения правил обработки, корреляция), как происходит ручная обработка сотрудниками команды ИБ (триаж, приоритизация). Это позволяет в том числе оценить технический долг по триажу (анализу) уязвимостей.
А понимая контекст, мы сможем принять решения, помогающие увеличить эффективность обработки уязвимостей командой инженеров ИБ – например, за счет уменьшения доли ручного труда инженеров ИБ по разбору и анализу через настройку автоматических правил.
Оценка процесса в разных контекстах
Нижняя часть дашборда позволяет нам оценить поток обработки уязвимостей и показатели эффективности каждого этапа в различных разрезах: в разбивке по серьезности уязвимостей, практикам и инструментам обнаружения, приложениям.
Структурно каждая вкладка состоит из двух частей: слева находится график «радар», который позволяет сравнивать между собой сущности сразу по нескольким показателям (в левой части – последовательные шаги количественной «воронки», справа на тех же уровнях – соответствующие показатели эффективности этапов). На графике «радар» хорошо видны максимальные значения, а выявить аутсайдеров по разным показателям помогут две таблицы, расположенные справа: отдельно количественные показатели, отдельно параметры эффективности прохождения этапов обработки.
Серьезность уязвимости
К примеру, мы видим, что чаще всего выявляются уязвимости низкого уровня серьезности (что вполне естественно), а автоматические правила обработки настроены в основном для проблем критической и высокой степени серьезности. % триажа тоже выше для критических уязвимостей.
Приложение
На графиках мы видим, что одно приложение (User Management System) – явный лидер по количественным показателям, однако у него сильно отстает от других показатель эффективности приоритизации: направляются в работу только 5% проанализированных уязвимостей.
Давайте попробуем понять причину этого, отфильтровав данные, оставив только приложение User Management System, и оценив поток обработки в разрезе сканеров/практик ИБ.
Практика ИБ / сканеры ИБ
Что касается показателей по практике и сканерам ИБ, есть небольшое отличие от других измерений. Поскольку система, отсеивая повторно выявленные уязвимости, не создает для каждой проблемы отдельную запись, мы можем с уверенностью говорить только об уязвимостях без учета дубликатов, обнаруженных с помощью каждой практики/сканера.
Возвращаясь к обнаруженному «бутылочному горлышку» приоритизации уязвимостей: отфильтровав данные по приложению User Management System, мы видим, что наименьший показатель эффективности приоритизации у уязвимостей, выявленных практикой SAST. Только 3% от проанализированных уязвимостей направляется в работу, что лишний раз иллюстрирует большое количество ложных срабатываний у анализаторов кода, используемых «из коробки» (без дополнительной настройки под анализируемые системы). Ещё можно обратить внимание на то, что автоматические правила обработки почти не настроены. Менее 1% из выявленных уязвимостей обрабатываются автоматически – инженер ИБ тратит много времени на ручной анализ каждого срабатывания, тем временем накапливая технический долг по разбору остальных уязвимостей.
Фильтры
Разумеется, дашборд – это интерактивный инструмент, который можно гибко настроить для получения ответов на конкретные вопросы, применив фильтры. По умолчанию отображаются данные за все время использования инструментов ИБ в процессе безопасной разработки компании, однако можно выбрать период покороче (фильтр по дате сканирования) для анализа ситуации за текущий/прошлый месяц/год и т. д. Также вполне реально отфильтровать данные по каждому приложению, практике, сканеру ИБ и серьезности.
Заключение
Мы рассмотрели один из аспектов DevSecOps – процесс обработки выявленных уязвимостей ИБ – на примере инструмента класса ASOC. Подведем итоги. Использование таких решений помогает упростить обработку результатов сканирования и увеличить скорость поставки ПО за счет автоматизации сразу нескольких важных процессов.
Во-первых, решения ASOC (в части, отвечающей за оркестрацию) позволяют подключать разные сканеры и практики ИБ и управлять запуском тестирований «из одного окна», собирая и автоматически анализируя результаты проверок: при повторном срабатывании система не будет создавать новую запись об обнаруженной уязвимости, а обновит запись найденной ранее проблемы. Настройка автоматических правил обработки позволяет значительно сократить время, которое затрачивается на ручной отсев ложных срабатываний, часто выдаваемых некоторыми сканерами ИБ. Автоматические правила можно настроить и для принятия риска.
Во-вторых, в сканерах ИБ может быть разное число степеней критичности уязвимостей, и обозначаться они могут тоже по-разному. – Инструмент класса ASOC позволяет ввести прозрачную систему классификации проблем по уровню серьезности (критический, высокий, средний, низкий). Это приводит к сокращению времени на анализ и приоритизацию уязвимостей для передачи наиболее важных на исправление в разработку.
И в-третьих, такие решения реализуют корреляцию. Приоритизированные уязвимости передаются для исправления в команду разработки не списком в виде отчета, а автоматически экспортируются в дефект-трекинговую систему в качестве сформированных дефектов. При этом инженер ИБ может объединить однотипные/похожие/найденные рядом в коде уязвимости в значительно меньшее число дефектов, добавив комментарии и рекомендации. Это улучшает взаимодействие команд безопасности и разработки и сокращает время на исправление проблем ИБ.
В целом внедрение практик ИБ в DevOps и реализация DevSecOps – задача с большой звездочкой. Единого подхода к ее решению пока нет, поэтому компании по-разному строят процесс безопасной разработки и зачастую сталкиваются с серьезными проблемами в части реализации и управления DevSecOps. В ответ на этот вызов продукты класса ASOC предоставляют универсальные возможности, позволяющие построить процесс безопасной разработки, применяя комплексный и централизованный подход.
Но реализовать DevSecOps – это всего лишь полдела. Важно оценивать, анализировать его в действии и на основе полученных данных направлять многочисленные процессы в нужные стороны, чтобы добиться желаемых показателей эффективности. Как раз для этого наша команда и разрабатывает в рамках AppSec.Hub модуль визуализации метрик DevSecOps. Мы продолжим делиться им с вами, рассматривая процессы и метрики безопасной разработки на графиках и дашбордах.
Так что до новых встреч, друзья!
