Привет, хабр! На связи Даниил Коновалов из CyberCodeReview.
Application Security Orchestration and Correlation (ASOC) – не самая тривиальная тема в реалиях отечественного подхода к обеспечению ИБ, но от этого не менее интересная, и, что главное – не менее важная.
В ходе работы нам с командой пришлось прожить многие этапы внедрения ASOC, решить тысячу и одну проблему, дорабатывать фичи, устранять баги, и «допиливать» воркфлоу так, чтобы ASOC действительно работал, не только на бумаге, но и на практике. Поэтому, мне кажется, мое мнение, как практикующего devsecops-инженера будет не лишним для развития appsec, пусть не в стране, но хотя бы в хабр-сообществе.Постараюсь рассказать, как мы для себя видим качественный продукт. (Возможно из этого выльется цикл статей - кто его знает)
Как построить настоящий DevSecOps?
Наверное, стоит начать с базового выстраивания appsec-процессов в компании. И здесь нам не обойтись без следующих этапов:
Подготовьте команду: проведите обучение сотрудников принципам безопасной разработки и организации безопасной разработки, чтобы все участники процесса понимали важность интеграции безопасности на каждом этапе.
Интегрируйте инструменты: выберите и настройте их для анализа безопасности приложений, такие как статический и динамический анализ кода, а также инструменты для управления уязвимостями.
Автоматизируйте процесс: тестирование безопасности в CI/CD пайплайнах должно выполняться без участия devops’ов, безопасников, техлидов, или иных экспертов, чтобы обеспечить непрерывную проверку кода на наличие уязвимостей.
Настройте мониторинг и отчетность: разверните механизмы для сбора и анализа метрик, что позволит отслеживать динамику улучшения процесса безопасной разработки.
Обратная связь и улучшение: проводите регулярный анализ полученных данных, так вы сможете вносить коррективы и улучшать процессы на основе полученной информации.
Когда в компании появляется обширный набор инструментов для Application security, возникает вопрос: как эффективно интегрировать их в CI/CD процессы? С какими настройками работать для разных команд? Как собрать информацию в одном интерфейсе и отслеживать метрики и динамику улучшения? Для решения этих задач и оптимизации процессов внедрения безопасности существуют инструменты класса ASOC. Они помогают автоматизировать и координировать различные аспекты безопасности приложений, обеспечивая более эффективное управление рисками и уязвимостями.
Пара слов про сам ASOC
Схема компании с рабочим ASOC
ASOC – это, по мнению нашей команды, мастхэв безопасной разработки ПО. ASOC - классическая система управления уязвимостями и сканированиями, в которой есть все необходимое для:
• понимания текущего положения дел и демонстрации топ-менеджменту слабых мест в разработке;
• отправки и сохранения результатов сканирования как в виде отчетов, так с помощью API;
• удобного сохранения данных о команде/ассетах/уязвимостях (этот момент разберем подробнее, потому как его важность сильно недооценена);
• автоматической предобработке результатов для снижения "уровня шума" и минимизации количества false positives;
• управления разовыми/регулярными сканированиями для актуализации метрик.
К необходимости появления ASOC в организации обычно приходят двумя путями:
Ситуация 1 - вы только собираетесь внедрять какие-то сканеры уязвимостей для выполнения, например, анализа исходного кода сервисов компании на безопасность; вы знаете, что не существует "одного единственного идеального сканера" и сразу ищете решение для сбора и дедупликации данных, а также решение для управления сканированиями.
Ситуация 2 - у вас несколько сканеров и вы хотите систему, в которой можно объединить результаты сканирования для их дальнейшего анализа; при этом желательно иметь возможность дедупликации результатов между разными сканерами.
Итак, начнем решать задачу настройки процессов управления уязвимостями с помощью инструментов ASOC
Ассеты
До перехода к работе в ASOC необходимо разобраться со сбором внутри организации всей необходимой информации о сервисах и ассетах, которые собираетесь сканировать.
Как правило, в компаниях для реализации задачи инвентаризации/управления инфраструктурой внедряются специальные системы, такие как Базы данных управления конфигурациями (CMDB) или системы Service discovery. С их помощью в автоматическом режиме можно получать актуальную информацию о разрабатываемых сервисах и совмещать это с ассетами, которые они имеют (репозитории, хосты, ендпоинты, контейнеры и пр.). Соответственно первая задача любого DevSecOps-инженера при внедрении ASOC - автоматизация обновления информации о сервисах и его ассетах внутри ASOC. Никто не говорит, что сервисы и ассеты нельзя задать вручную, но это достаточно трудоемко.
Что делать, если нет возможности написать собственный сервис для инвентаризации сканируемых сервисов? В качественном ASOC можно создавать нужные продукты/ассеты прям из пайплайнов - каждый раз скрипты по API будут проверять существуют ли необходимые ассеты и, если да, отправлять отчет. Если нет - ассеты предварительно будут созданы.
Что должно быть у ASOC для решения задачи сохранения всей необходимой информации о сервисах и ассетах? Конечно, удобный UI со всеми необходимыми сущностями.
Первая базовая сущность в ASOC - Продукт. Продукт в ASOC, как и на практике - это набор активов, из которых формируется проект. Это ассеты, принадлежащие одной логической структуре проекта, например, репозитории, где содержится непосредственно кодовая база проекта, docker-образы, хосты (конечные точки), где крутится развернутая система, или домен, который "прикручен" к ней. Удобной фишкой здесь можно добавить возможность указывать тип Продукта (внешний/внутренний, легаси, альфа/бета-версия и т.д.) или тегировать с помощью пользовательских обозначений для удобной группировки и фильтрации в случае большой базы Продуктов. Аналогично в высоконагруженных средах полезно указывать тип и теги и для самих ассетов.
Теги здесь - более универсальное (кастомное) поле, в которое можно записать информацию, перекликающуюся с Вашими бизнес-процессами, а не просто вшитую в ASOC-решение. Например, в виде тегов удобно сохранять:
языки программирования, на которых написан сервис;
если у вас внедрена практика AppSec бизнес-партнеров, то указать бизнес-партнера, отвечающего за продуктовую безопасность сервиса;
команду разработки/поддержки, если в вашем случае одна команда разработки может быть причастна к разработке нескольких сервисов;
идентификаторы сервиса в других Информационных Системах.
В продуманном ASOC должна быть возможность указать бизнес-критичность для Продукта, а также метрики допустимого совокупного уровня риска всех ассетов внутри Продукта - то есть моральный предел количества уязвимостей, обнаруженных по результатам проведенных сканирований. Здорово, если динамика риска отображается на общем дашборде с трендами - так видны и масштаб "недоработок" в части безопасности, и работа команды по устранению уязвимостей.
Сканирования
«Правильный» ASOC способен выполнять сканирования сервисов и настраивать сканирования прямо из UI (т.н. Low code CI). Выглядеть это может примерно как в Gitlab CI: выбирается образ определенного анализатора, для образа прописывается команда на исполнение и соответствующие переменные окружения, всё это упаковывается в одну сущность - Задание. Чтобы каждый раз не заниматься компоновкой Заданий для каждого Продукта по отдельности, полезным функционалом будет возможность объединять Задания в последовательности Заданий. Таким образом, например, для Продуктов со схожими типами ассетов, последовательности Заданий можно использовать одинаковые, что, опять же, унифицирует процесс и ускоряет работу с ASOC.
Например, full scan будет выполнять все типы сканирования - искать секреты с помощью gitleaks, искать уязвимости с помощью semgrep, а также выполнять композиционный анализ с помощью trivy. Его можно "раскатать" на все Продукты. Отдельно можно собрать последовательность Заданий под SAST-Golang, которая будет совмещать в себе Задания только с SAST анализаторами (например, Semgrep и Gosec).
Сформированные последовательности Заданий это уже, по сути, подготовленные инструменты для непосредственного проведения сканирований - выбираем последовательность, кликаем нужные ассеты и запускаем аудит. Удобно? Конечно, как и должно быть. Кстати, статус аудитов нужно отслеживать, чтобы DevSecOps-инженеры могли видеть, работают ли вообще сканирования. Обязательно должна быть предусмотрена возможность "провалиться" в работающий или уже завершенный аудит и проверить наличие ошибок, узких горлышек. Туда же можно положить результаты аудитов: найденные уязвимости, автоматически закрытые по результатам сравнения с предыдущим аудитом одного ассета и др. Оттуда, уже сформированный перечень уязвимостей, переезжает в свой раздел, где их будут триажить.
Важно подчеркнуть, что функция сканирования ASOC может и должна уметь интегрироваться в пайплайны разработки. Это, опять же, автоматизация процесса application security - постоянная работа по анализу и устранению.
Конечно, могут быть и кейсы, когда компании не готовы включить безопасную разработку на максимум, будь то опасения по замедлению процесса непосредственного написания кода, или увеличению нагрузки на разработчиков. Тогда должна быть возможность воспользоваться сканированиями единоразово или по расписанию. Такой подход актуален для:
тестирования новых правил;
выполнение долгих сканирований, которые нельзя внедрить в devsecops pipeline;
тестирования новых инструментов.
Допустим, ASOC у Вас появился не так давно, а инструменты сканирования уже проводили свои аудиты. Такое возможно? Конечно. И должен ли «правильный» ASOC уметь импортировать в себя результаты этих аудитов? Естественно. Супер фича - наличие кастомного импортера, когда не надо ждать нового релиза у вендора, обрушать на службу поддержки запросы по реализации, а просто взять отчет, распарсить, получить файндинги в ASOC. Загрузка через UI - отлично, через API - вообще сказка.
Работа с результатами сканирования
Самое важное, что должен уметь ASOC: удалять дубликаты, полученные от разных сканеров; помогать в триаже (т.н. анализе) файндингов с помощью автоматизации.
Дубликаты:
Стандартный ASOC даст Вам возможность дедупликации уязвимостей, но не позволит сконфигурировать этот процесс.
Более-чем-стандартный ASOC способен поддерживать базовую конфигурацию механизма дедупликации. Тут тоже все достаточно понятно:
Вы можете самостоятельно выбрать скоуп определения дубликата - искать дубликаты в рамках одного репозитория, одной ветки, одного хоста, домена и так далее или не учитывать этот критерий вовсе.
А можете выбрать более общий скоуп - искать дубликаты в рамках одного продукта, либо в рамках одной группы продуктов, либо вообще во всем ASOC без учета продукта и его группы.
А что же тогда в идеальном ASOC? А в идеальном ASOC вас будет ждать продвинутый механизм, который решит боль дедупликации между разными сканерами. Например, Вы внедрили 2 сканера - semgrep и gosec. Один для pattern-based анализа, другой - для семантического. Могут ли они разными способами обнаружить одну и ту же уязвимость? Конечно, да. Допустим, это и произошло - и semgrep и gosec нашли одну и ту же потенциальную уязвимость.
Для того, чтобы решить проблему дедупликации между двумя сканерами, Вы определяете, какой из двух сканеров вам милее (файндинг какого сканера будет считаться оригиналом, а какого дублем и будет исключен из общего пула), добавляете правило дедупликации. А уже внутри правила должны оказаться конкретные и очень специфичные условия, это могут быть:
название сканера;
заголовок, значение которого будет названием этой уязвимости;
критерии поиска дублей (самые актуальные, например: Продукт, путь к файлу с уязвимостью, и/или номер строки кода).
Если будет найдена одна и та же уязвимость, для которой Вы только что создали правило дедупликации, двумя сканерами, оригиналом будет считаться уязвимость, найденная Semgrep. То, что нашел gosec, будет исключено, либо помечено как дубль и показано только в дублях. То есть,«правильный» ASOC должен уметь не только обрабатывать новые файндинги, но и искать по уже наполненной базе.
Теперь про помощь в триаже.
Для того, чтобы помочь Вам обработать вновь и вновь появляющиеся файндинги для разных сервисов, у идеальной ASOC есть функция валидатора. Если Вам проще не конфигурировать сканеры, а разгребать файндинги внутри ASOC, не беда. Например, если Вы точно знаете, что файндинги сканера, найденные с помощью определенного правила, всегда false positives, Вы создаете правило, которое будет переводить эти файндинги в статус отклоненных.
Таким же образом можно поступить с файндингами, найденными, например, в тестовых директориях или любых других, потенциальные проблемы в которых Вы не хотите отслеживать. Либо наоборот - если определенные файндинги сканера всегда нужно сразу брать в работу, то Вы автоматически переводите их в статус подтвержденных.
Помимо возможности работы со статусами, теги должны добавляться в автоматическом режиме тем же валидатором. Это поможет кастомизировать поток работы с файндингами как Вам удобно, а также позволит добавлять необходимую информацию, если не хватает нужных полей.
Таким образом идеальная ASOC-платформа с помощью простых инструментов - дедупликатора и валидатора, и без какой-либо магии может наладить работу с большим объемом файндингов и автоматизировано сократить их число перед тем, как Вы будете с ними работать вручную. Да, на написание правил уйдет время, но работа с найденными уязвимостями – процесс непрерывный и постоянный, и рабочие правила сэкономят вам этого времени гораздо больше.
Таск-трекер как драйвер процессов
Вот вы завели ассеты, внедрили сканеры, получили результат, автоматически, а затем и вручную его провалидировали. Что делать дальше, если файндинг подтвержден как уязвимость? Поставить команде разработки задачу на устранение и отслеживать ее статус.
В нашей картине мира идеальная ASOC-платформа должна быть способна и на такое. Например, очень удобна двусторонняя интеграция с таск-трекером. Она позволяет актуализировать статусы, где бы они не менялись - если разработчик двигает задачу в трекере в Done, она закроется в ASOC. Точно также работает и наоборот - если задача будет закрыта в ASOC, она и в трекере закроется.
При этом классно, если сопоставление статусов можно кастомизировать - не обязательно закрывать задачу, если ее переводят в Done в трекере. Можете ее перепроверить и если не нашлась, то закрыть. Автоматическое закрытие/удаление уязвимости, если ее уже нет в новом отчете - это должно быть настраиваемое действие.
Интеграция с таск-трекером, помимо двусторонней связи, может давать следующие плюшки:
настройка дефолтного пространства и отдельных пространств для каждого продукта;
настройка одновременно двух отдельных пространств для двух групп участников процесса - отдельно для специалистов по ИБ и отдельно для разработчиков;
получение прямо в карточку с файндингом текста комментария, оставленного разработчиком.
После настройки таск-трекера наконец можно выдохнуть и налить себе чаю, потому что процесс управления уязвимостями базово настроен и им можно уже пользоваться.
Надеюсь, у меня получилось расширить ваши представления о том, на что может быть способна современная ASOC-платформа. До новых встреч и новых полезных текстов на хабре.
