Предисловие

Всем приветы! Меня зовут Антон, я Tech Lead DevSecOps в местной биг-тех компании. Хочу начать с кратенького предисловия, почему я решил написать что-нибудь про DevSecOps. Я довольно-таки часто сталкиваюсь с непониманием, что же автоматизируют и для чего нужны DevSecOps инженеры, где их место в компании и в современном ИБ. Да и что далеко ходить, многие коллеги DevOps, сами считают, что с добавлением trivy или sonarqube в пайплайны, ты уже носишь гордое звание DevSecOps.

Поэтому в этой статье поговорим о том, как должны выглядеть DevSecOps пайплайны, чтобы они трансформировались во что-то зрелое. В Security Gate!

Что дает Security Gate бизнесу

Давайте начнем, с чего-то серьезного, а что бизнесу может дать Security Gate?

Представьте, что вы продуктовая средне-крупная компания, диджитал банк или бигтех, и каждую неделю у вас появляются десятки новых сервисов в разных дирекциях, и в десятках различных команд. Количество сервисов неустанно растет и инженеры просто не успевают сканировать их по заявкам на уязвимости, потому что нужно:

• проверить депенденси/либы сервиса (SCA)

• сделать статический анализ кода (SAST)

• сделать динамический анализ кода (DAST)

• сканирование докер образ

• нарезать задачи на исправление

И тут у компаний возникает несколько вариантов развития событий..

1. Если ИБ исповедует демократию, то количество непросканированных сервисов на продакшене растет, что влечет за собой неконтролируемое увеличение площади атаки на сервисы. И эти риски не притянутые за уши, доводилось лично видеть ужасные вещи.. затерявшиеся сервисы на продакшене с 60-80-критами, самый старый крит которого, датировался 2006 годом в пакете nginx

2. Если ИБ исповедует диктатуру, то увеличиваются сроки на разработку и релизы, что в свою очередь влечет денежные убытки на разработку и недополученную прибыль от запуска фич. На очень крупных проектах, регулярное срывание сроков из-за длительных согласований, могут запросто стоить 2-10млн.$ в год. Ну а горящие сроки и неидеальные процессы, сказываются уже на настроении и мотивации внутри команд

3. Наращивать штат security engineers пропорционально нагрузке. Что в свою очередь добавит сложность в управлении, коммуникации, онбординге такого числа людей. Такой подход даже будет работать до определенного времени, пока в какой-то момент нагрузка не начнет расти в геометрической прогрессии, и двадцать человек уже не будут справляться с операционной нагрузкой. И дальше продолжать наращивать штат, становится уже бессмысленным.. Да и такой прямолинейный подход не позволяет отслеживать лайфсайкл уязвимостей: когда и где появилась; в каких еще сервисах присутствует; когда и кем была исправлена и т.д.

4. Позвать DevSecOps инженеров, которые вникнут в ваш cicd флоу и релиз циклы, постараются максимально безболезненно изменить этот флоу, а затем автоматизируют проверки и сбор отчетов в централизованном месте, тем самым создадут Security Gate.

Начинаем!

В качестве примера возьмем “классический” gitflow процесс разработки, потому что логика trunkbased выглядит сложнее и не так наглядна. На изображении сверху, можем пронаблюдать три ключевые ветки, которые связаны с тремя одноименными енвайроментами:

• Dev. В dev ветке ведется активная разработка, любой push ведет к билду и деплою сервиса в dev environment

• Stage. В stage ветке уже формируются кандидаты в релизы. Для этого нужно сделать PR из dev в stage, что приведет к билду и деплою сервиса в stage environment

• Master. В master у нас полноценный релиз/версия нашего приложения. Для этого нужно сделать PR из stage в master, что приведет к “promotion” докер образа из stage (билд стадии нет) и его дальнейшему деплою в prod environment

Разобравшись с процессом разработки, который мы берем в качестве примера, перейдем к  главной теме разговора. К Security Gate!

Security Gate это механизм, который помогает нам, благодаря разным типам сканеров, оценивать качество сервисов и их кода с точки зрения безопасности. А уже на основе этой оценки, принимать решение: разрешать или запрещать полноценную эксплуатацию сервиса в production.

На изображении сверху представлен Security Gate. Он состоит из следующих, хочу отметить OpenSource, компонентов:

• SOAR (StackStorm)

• ASPM (DefectDojo)

• SCA (OWASP dependency-check; Trivy)

• SAST (Sonarqube; Semgrep)

• DAST (Zap)

• Image Scanning (Stackrox)

Давайте разбираться, что это за аббревиатуры и какие функции каждая из них несет!

SOAR (Security Orchestration, Automation and Response) - это автоматизация реагирования на инциденты. SOAR принимает в себя payload информации, на основании которого запускается тот или иной, заранее нами подготовленный playbook/runbook.

ASPM (Application Security Posture Management) - это управление безопасностью приложения. Без преувеличения, ASPM можно назвать “сердцем” Security Gate. Упрощенно говоря, это хранилище для всех результатов сканов и репортов наших сервисов. Мы создаем в ASPM сущность, отождествляемую с нашим сервисом, допустим “billing-service”. Все когда-либо произведенные сканы-репорты сервиса  “billing-service”, будут связаны с этой сущностью. Но ASPM это не только хранилище, в нем должны быть интеграции со множеством известных сканеров, чтобы  понимать синтаксис всех репортов сканирования, а найденные уязвимости агрегировать, группировать и объединять по различным критериям.

SCA (Software Composition Analysis) - это анализ состава зависимостей исходного кода. Анализируются на предмет надежности, либы из цепочки зависимостей, в таких файлах, как: package.json, composer.json, requirements.txt, build.gradle, go.mod (для разных ЯП свои).

SAST (Static Application Security Testing) - это статический анализ исходного кода приложения, на предмет его безопасности и выявления потенциальных уязвимостей и проблем с качеством кода.

DAST (Dynamic Application Security Testing) - это динамический анализ безопасности, уже работающего приложения.

Image Scanning - это сканирование всех пакетов в докер образе, на предмет их уязвимости.

Теперь зная, из каких компонентов состоит Security Gate, давайте более детально разберем, что происходит в каждой ветке/енвайроменте на изображении.

При пуше в dev ветку, происходят следующие события:

• билд докер образа (только после build стадии идет сканирование, потому что, если образ не собрался или кто‑то отменил pipeline, нет смысла производить сканирование в холостую и занимать вычислительные ресурсы)

• асинхронно в фоне идет проверка зависимостей библиотек с помощью OWASP Dependency-Check

• асинхронно в фоне идет SAST проверка кода, с помощью SemGrep

• результаты сканирования (payloads), отправляются в наш SOAR (StackStorm), откуда попадают в ASPM “базу данных” уязвимостей DefectDojo

• ASPM видя уязвимости (findings) в коде или в библиотеках, триггерит SOAR (StackStorm), тот в свою очередь заводит Jira таски на исправление, а также результаты сканов отправляет в Slack канал команды

При мерже PR “dev → stage”, происходят следующие события:

• полное SAST сканирование SonarQube (SonarQube не вынесли в фон и у него есть возможность заблокировать пайплайн, потому что как правило этот инструмент активно используется и тестировщиками, для проверки качества кода. Хотя ничто не мешает и его тоже вынести в фон)

• после SonarQube идет долгожданный билд

• асинхронно в фоне идет сканирование докер образов, с помощью StackRox

• асинхронно в фоне идет проверка зависимостей библиотек, с помощью Trivy (Да, Trivy в этой схеме мы используем, как SCA инструмент, в сканировании образов предпочтение отдали Stackrox, по результатам найденных CVE, они плюс/минус показывают одинаковые результаты. В дальнейшем я думаю напишу отдельную статью по особенностям сканеров докер образов)

• результаты сканирования (payloads), отправляются в наш SOAR (StackStorm), откуда попадают в ASPM “базу данных” уязвимостей DefectDojo

• ASPM видя уязвимости в коде или в библиотеках, триггерит SOAR (StackStorm), тот в свою очередь заводит Jira таски на исправление, а также результаты сканов отправляет в Slack канал команды

При создании PR (!!не мерж!!) “stage → master”, происходят следующие события:

• при создании PullRequest у нас в фоновом режиме начинает производиться DAST сканирование, с помощью ZAP (Прошу обратить внимание, что сканирование сервиса производится на staging ендпоинте! DAST сканирование происходит, только при создании PR, когда кандидат в релизы готов. В staging ведется не такая активная разработка как в dev, но нередко подливаются коммиты-фиксы или что-то, что захотелось докинуть в последний вагон. Соответственно делать DAST сканирование, которое может занять ни один час, при каждом новом коммите нецелесообразно, потому что нет итогового кандидата в релизы)

• результаты сканирования (payloads), отправляются в наш SOAR (StackStorm), откуда попадают в ASPM “базу данных” уязвимостей DefectDojo

• ASPM видя уязвимости в коде или в библиотеках, триггерит SOAR (StackStorm), тот в свою очередь заводит Jira таски на исправление, а также результаты сканов отправляет в Slack канал команды

• когда мы дождались завершения DAST сканирования, идет следующий этап “Security Gate evaluating”. В этом шаге мы достаем результаты сканирования всех инструментов из DefectDojo. И допустим у нас правило, если в каждом из результатов не было Critical: “if sast_scan not critical and dast_scan not critical and ..”, то автоматически ставится “Approve” на Merge в master. Это будет означать, что контрольная точка/Gate пройден и сервис попадает в production

Pull Request в master, можно рассматривать нашим барьером. Нашей контрольной точкой Security Gate. Например, не апрувать Pull Requests, если результаты последнего сканирования, допустим имели Critical/High уязвимости или любое другое принятое условие.

Инцидент Менеджмент

В предыдущем разделе, мы постарались рассмотреть, максимально общую и упрощенную концепцию взаимодействия компонентов Security Gate друг с другом. Здесь давайте рассмотрим реальные сценарии автоматизации с помощью SOAR, чтобы на примерах лучше понять, какую автоматизацию вокруг Инцидент Менеджмента можно построить.

Сценарий 1. Мануальный Апрув Critical

Рассмотрим такой сценарий. При создании PR в master, ZAP сканер обнаружил Critical уязвимость:

• у нас завершилось DAST сканирование ZAP инструментом

• payload результата сканирования попадает в DefectDojo

• в результате сканирования у stage сервиса, были обнаружены Critical уязвимости

• DefectDojo автоматически триггерит в StackStorm runbook “ticket_creation” на заведение Jira тикета - “фикс CVE уязвимости”

• также одновременно, DefectDojo автоматически триггерит в StackStorm runbook “notification”, на отправку нотификации в Slack

• в канал инженеров ИБ в Slack, приходит нотификация. В ней описано: имя сервиса; имя команды; имя CVE ошибки; ссылка на Jira ticket; ссылка на PullRequest

• есть две кнопки “Approve” и “Decline/reject”. Допустим ИБ инженер, принимает решение и нажимает “Approve”

• кнопка “Approve” триггерит в StackStorm runbook “pr_approve”, что в свою очередь разрешает мерж в мастер и выкатку нового релиза в production

• также кнопка “Approve” триггерит в StackStorm runbook “waf_hard_mode”, что в свою очередь помещает настоящий продовский ендпоинт за усиленным режимом waf

Рассмотрели сценарий, когда при релизе сервиса, готовящегося выйти в production, имелись Critical уязвимости в DAST сканировании. Инженеру ИБ была дана возможность, проанализировать ситуацию и дать свой мануальный апрув/режект.

Сценарий 2. Сводка CVE за 30 дней / “Доска позора”

С помощью SOAR и ASPM, мы можем формировать отчеты о найденных уязвимостях. Как вариант, показать общую сводку уязвимостей за прошедшие 30 дней. Отметить 1-2 команды, которые имеют максимальное число Critical уязвимостей. Помещать команды на этакую “доску позора”, для дальнейшего стимулирования закрытия тикетов по устранению уязвимостей.

• в секьюрити менеджмент кластере есть cronjob, которая отрабатывает каждое 1-ое число нового месяца

• cronjob идет в StackStorm и получает все уязвимости за прошедший месяц из DefectDojo

• наша cronjob агрегирует полученную информацию

• сформировав отчет, мы через StackStorm публикуем его общей рассылкой по email

• зная имя команды с максимальным количеством уязвимостей за прошедший месяц, мы через SOAR (StackStorm) триггерим удаление учетных записей команды из Active Directory. Потому что нарушители нам не нужны !!

Сценарий 3. Блокировка сервиса

Также захотелось показать, что мы можем автоматизировать самые прямолинейные и не элегантные сценарии. Обычно, такое можно увидеть в ИБ, которое придерживается Zero Tolerance фреймворка.

Рассмотрим такой сценарий. При повторном ночном DAST сканировании production, был обнаружен сервис с Critical уязвимостями:

• payload результатов сканирования попадают в DefectDojo

• DefectDojo автоматически триггерит в StackStorm, runbook “notification”, чтобы отправить нотификацию дежурному security engineer

• также одновременно, DefectDojo автоматически триггерит в StackStorm, runbook “scale-down_deployment”, который в свою очередь идет в prod k8s кластер и там скейлит количество подов деплоймента сервиса до нуля, что приводит к тому, что сервис больше не будет отдаваться наружу

Подведем Итоги

Security Gate это механизм, который помогает нам оценивать качество сервисов и их кода с точки зрения безопасности. На основе этой оценки, разрешать или запрещать сервис к работе в важных для нас сред запуска, например production. А также за счет автоматизации множества процессов, выработать единый флоу обработки операционной нагрузки и реагирования, в качестве единого “Инцидент менеджера”.

У ИБ разных компаний может быть на вооружении Zero Tolerance или Implicit Trust фреймворки. Если ситуация не обусловлена какой-то спецификой, я же лично склоняюсь к чему-то гибридному от этих двух подходов: защиты много не бывает и нужно стремится сужать все вектора атаки, всеми механизмами, но при этом не забывать про диалог, здраво оценивать риски и помнить, что в первую очередь бизнес должен приносить прибыль!

На основе вышесказанных предпочтений, хочу перечислить бестпрактисы DevSecOps пайплайнов:

• Не замедлять скорость разработки. Не нужно усложнять пайплайны десятком шагов со сканерами. Особенно активные в разработке ветки, например dev/feature. Это замедляет разработку!

• Экономить вычислительные ресурсы. Для активных dev/feature веток, нужно включать быстрое сканирование, если такой режим имеется. На этой стадии не требуется полного отчета, так как за 30 минут, может смениться с десяток коммитов и на каждый будет идти полное сканирование. Это просто будет есть вычислительные ресурсы компании и создавать нагрузку на cicd. Очень заметна нагрузка станет на больших масштабах, когда единовременных пайплайнов переваливает за несколько сотен и придется уже изобретать что-то архитектурное, чтобы такая нагрузка обрабатывалась

• Фоновое асинхронное сканирование. Стараться по-возможности делать сканирование асинхронным и выносить в фон. Это позволяет быть независимым от шагов cicd пайплайна (и внутри одной компании, может быть можество разных видов cicd пайплайнов) и не завязываться на их результаты. А стараться реализовывать свою внешнюю логику обработки/реагирования на события, с помощью SOAR и ASPM

• Master чистейшая святая святых. В cicd master ветки, сканов не должно быть! Все проверки должны быть сделаны, до мержа PullRequest в master. Иначе весь смысл в контрольной точке Security Gate, в Рубиконе, который нужно преодолеть - теряется!

• Меньше блокирующей автоматизации. Стараться избегать автоматизации блокирующих действий с помощью SOAR. Все можно покрыть нотификацией и jira тасками. Но если, на то есть необходимость, можно автоматизировать сценарии мануального апрува, где можно все самому проанализировать и взвесить. Такой подход необходим, потому что за даунтайм критически важных сервисов, по голове точно не погладят

Post Scriptum

Еще одной из причин, которые сподвигли на написание этой статьи, потому что 80% инфографики про DevSecOps cicd пайплайны, выглядят как “MLG meme” из середины 2010-х годов.  Где в пайплайн понапихан весь винегрет и все что только возможно.. все знакомые слова инструментов сканирования.. пару десятков этапов и миллиард лет ожидания исполнения такого пайплайна!