Привет! На связи Даниил Коновалов из CyberCodeReview.
Application Security Orchestration and Correlation (ASOC) – не самая тривиальная тема в реалиях отечественного подхода к обеспечению ИБ, но от этого не менее важная, и, что главное – не менее интересная. Поэтому, мне, кажется, мое мнение, как практикующего devsecops-инженера будет не лишним для развития appsec, пусть не в стране, но хотя бы в хабр-сообществе.
В ходе работы нам с командой пришлось прожить многие этапы внедрения ASOC, решить тысячу и одну проблему, дорабатывать фичи, устранять баги, и «допиливать» воркфлоу так, чтобы ASOC действительно работал, не только на бумаге, но и на практике. Постараюсь рассказать, как мы для себя видим качественный продукт. (Возможно из этого выльется цикл статей, кто его знает)
Как построить настоящий DevSecOps?
Наверное, стоит начать с базового выстраивания appsec-процессов в компании. И здесь нам не обойтись без следующих этапов:
-
Обучите команду: Проведите обучение сотрудников принципам безопасной разработки и организации безопасной разработки, чтобы все участники процесса понимали важность интеграции безопасности на каждом этапе.
-
Интегрируйте инструменты: Выберите и настройте инструменты для анализа безопасности приложений, такие как статический и динамический анализ кода, а также инструменты для управления уязвимостями.
-
Автоматизируйте процесс: Тестирование безопасности в CI/CD пайплайнах должно выполняться без участия devops’ов, безопасников, техлидов, или иных экспертов, чтобы обеспечить непрерывную проверку кода на наличие уязвимостей.
-
Настройте мониторинг и отчетность: разверните механизмы для сбора и анализа метрик, что позволит отслеживать динамику улучшения процесса безопасной разработки.
-
Обратная связь и улучшение: Проводите регулярный анализ полученных данных, так вы сможете вносить коррективы и улучшать процессы на основе полученной информации.
Когда в компании появляется обширный набор инструментов для Application Security, возникает вопрос: как эффективно интегрировать их в CI/CD процессы? С какими настройками работать для разных команд? Как собрать информацию в одном интерфейсе и отслеживать метрики и динамику улучшения? Для решения этих задач и оптимизации процессов внедрения безопасности существуют инструменты класса ASOC. Они помогают автоматизировать и координировать различные аспекты безопасности приложений, обеспечивая более эффективное управление рисками и уязвимостями.
Пара слов про сам ASOC
ASOC – это, по нашему субъективному мнению, мастхэв безопасной разработки ПО, классическая система управления уязвимостями и сканированиями, в которой есть все необходимое для:
-
понимания текущего положения дел и демонстрации топ-менеджменту слабых мест в разработке;
-
отправки и сохранении результатов сканирования как в виде отчетов, так с помощью API;
-
удобного сохранения данных о команде/ассетах/уязвимостях (этот момент разберем подробнее, потому как его важность сильно недооценена);
-
автоматической предобработке результатов для снижения "уровня шума" и минимизации количества false positives;
-
управления разовыми/регулярными сканированиями для актуализации метрик.
К необходимости появления ASOC в организации обычно приходят двумя путями:
Ситуация 1 - вы только собираетесь внедрять какие-то сканеры уязвимостей для выполнения, например, анализа исходного кода сервисов компании на безопасность. Вы знаете, что не существует "одного единственного идеального сканера" и сразу ищете решение для сбора и дедупликации данных, а также решение для управления сканированиями.
Ситуация 2 - у вас несколько сканеров и вы хотите систему, в которой можно объединить результаты сканирования для их дальнейшего анализа. При этом желательно иметь возможность дедупликации результатов между разными сканерами.
Итак, начнем решать задачу настройки процессов управления уязвимостями с помощью инструментов ASOC
Ассеты
Первое, что необходимо сделать для работы с ASOC - собрать внутри всю необходимую информацию о сервисах и ассетах, которые собираетесь сканировать.
Как правило, в компаниях для реализации задачи инвентаризации/управления инфраструктурой внедряются специальные системы, такие как Базы Данных управления конфигурациями (CMDB) или системы Service Discovery, с помощью которых в автоматическом режиме можно получать актуальную информацию о разрабатываемых сервисах и совмещать это с ассетами, которые они имеют (репозитории, хосты, ендпоинты, контейнеры). Соответственно первая задача любого инженера при внедрении ASOC - автоматизация обновления информации о сервисах и его ассетах внутри ASOC.
Никто не говорит, что сервисы и ассеты нельзя задать вручную, но это достаточно трудоемко.
Что делать, если нет возможности написать собственный сервис для инвентаризации сканируемых сервисов? В качественном ASOC вы можете создавать нужные продукты/ассеты прям из пайплайнов - каждый раз скрипты по API будут проверять существуют ли необходимые ассеты и, если да, отправлять отчет. Если нет - ассеты предварительно будут созданы.
Что должно быть у ASOC для решения задачи сохранения всей необходимой информации о сервисах и ассетах? Удобный UI со всеми необходимыми сущностями.
Первая базовая сущность - Продукт. У продукта может быть определенный "Тип" и различные "Теги".
Для продукта можно задать различные ассеты/активы - Репозитории, Docker-образы, Домены и Хосты.
Для каждого актива также можно определить различные "Теги".
Соответственно тут все просто - под Продуктом можно подразумевать некоторый сервис, который может состоять из нескольких репозиториев. Сервис может входить в некоторую бизнес-вертикаль/домен, что можно продемонстрировать указав его "Тип". Также для сервиса можно указать всю необходимую метаинформацию в тегах для фильтрации сервисов внутри ASOC. Что, как пример, удобно сохранять в виде тегов:
-
языки программирования, на которых написан сервис;
-
если у вас внедрена практика AppSec Бизнес Партнеров, то указать Бизнес Партнера, отвечающего за продуктовую безопасность сервиса;
-
команду разработки/поддержки, если в вашем случае одна команда разработки может быть причастна к разработке нескольких сервисов;
-
идентификаторы сервиса в других Информационных Системах.
В ASOC обычно есть возможность указать бизнес-критичность для продукта, что будет влиять на показатель наличия общего риска этого Продукта по результатам проведенных сканирований. Изменения показателей риска удобно отслеживать на общем дашборде с трендами.
Сканирования
Правильный ASOC способен выполнять сканирования сервисов и настраивать сканирования прямо из UI. Low Code CI во весь рост. Для конфигурирования определенного сканера необходимо создать определенное Задание (очень перекликается с джобой в GitLab CI) - задать образ, исполняемую команду, переменные окружения. Далее эти задания можно объединить в один пайплайн сканирования, так называемую Последовательность. Их можно объединять по типу или цели сканирования, например, full scan будет выполнять все типы сканирования - искать секреты с помощью gitleaks, искать уязвимости с помощью semgrep, а также выполнять композиционный анализ с помощью trivy. Отдельно можно собрать Последовательность SAST-Go, которая будет совмещать в себе Задания только с SAST анализаторами, например, тот же semgrep + gosec для семантического анализа Go.
Создав Последовательности вы можете переходить к сканированиям - выбрать один или несколько сервисов, "накликать" в них нужные ассеты – в данном случае – репозитории с кодом, и запустить сканирование. Результат сканирования наблюдать во вкладке Аудитов. Это удобно, чтобы понять в каком сканировании какие проблемы безопасности были найдены. Конечно, затем, эти же Результаты будут отображены в общей таблице с уязвимостями.
Важно подчеркнуть, что функция сканирования встроенная в ASOC не предназначена для интеграции в пайплайны разработки. Эта функция полезна для выполнения единоразовых сканирований или сканирований по расписанию.
Для чего удобно использовать функцию сканирования в ASOC:
-
тестирование новых правил;
-
выполнение долгих сканирования, которые нельзя внедрить в devsecops pipeline;
-
тесты новых инструментов.
Как можно загружать файндинги в ASOC:
-
отчетом, если есть готовый импортер. Идеальный ASOC должен уметь загружать отчеты от любых опен-сорс и коммерческих сканеров;
-
создавать файндинги по API;
-
через UI можно загрузить как отчет, так и вручную создавать файндинги.
Работа с результатами сканирования
Самое важное, что должен уметь 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-платформа. До новых встреч и новых полезных текстов на Хабре.
Автор: dani1ich