Comments 17
затерявшиеся сервисы на продакшене с 60-80-критами, самый старый крит которого, датировался 2006 годом в пакете nginx
А кто-то таки залез внутрь этого всего "ужас-ужаса"? Или просто героически решили проблему, которой небыло?
Ну мы не стали дожидаться и ловить на живца )
Понятно, что часть наших рисков митигирует WAF поверх всего, но как показывает практика не все компании считают нужным его настраивать.
Да оно и понятно, из местных решений, не так уж и много выбора и они недешевые.
А те же CloudFlare или Imperva не подходят, как минимум потому что IP пулы могут быть в бане "сами знаете кого" и часть местных пользователей на которых ориентирован сервис, просто на просто не смогут его переодически получать, что ухудшит опыт и т.д.
Из известных случаев этой весной:
- местный хостинг ломанули через вывешенный не обновленный gitlab наружу
- еще одна местная компания, пострадала от nginx-nightmare
Никто не говорит, что критиклы в сервисах это максимальный риск и тем самым набивает себе цену )) Есть ряд других вещей, я бы даже сказал база, которые по-моему мнению более важны, та же сетевая сегментация и организация сетевого периметра.
Но этот риск от уязвимых сервисов на продакшене есть и насколько он велик зависит от ряда некоторых факторов:
- насколько прибыльный у вас бизнес (чем больше, тем лакомее добыча)
- используете ли вы WAF (если self-hosted решение, чтобы оно актуализировало CVE базы)
- насколько много у вас сервисов (чем больше, тем больше площадь поражения и сложнее за всеми следить. Вот тут Security Gate и должен спасти)
- насколько оперативно пересобираются и перераскатываются ваши сервисы, если в нем нашлись уязвимости
Никогда не понимал этого стремления слить воедино отделы эксплуатации, мониторинга и айтисеков. Каждому своё.
Сам танцую, сам пою, сам билеты продаю. Стремление как раз понятно. Зачем платить три зряплаты, когда можно платить одну?
Возможно я не так понял мысль.. а никто не соединяет. У каждого свои задачи.
Есть отдел мониторинга, который следит за метриками доступности сервиса, доступности серверов и состоянием сети. Это эксплуатация и инфровая часть.
Есть SIEM, который уже собирает со всех серверов события/events: системные вызовы в ядро; audit/auth логи; сетевая активность; данные с сетевых устройств и т.д.
А SOC уже в свою очередь "мониторинг" подозрительной активности.
Он должен понимать выше перечисленные потоки данных, которые собрал SIEM, чтобы создавать "рулы", нарушения которых детектировали бы подозрительную активность и создавали инцидент. Это уже ИБ, и их метрики не волнует доступность сервиса/сервера, главное чтобы не был задетектирован какой-либо секьюрити инцидент
А как вы видите на приведённых диаграммах Dependency Tracking (отслеживаение уязвимостей в уже использующися сборках и образах, которые были выявлены после прохождения Security Gate)?
Например, в ситуации, когда была найдена уязвимость в сторонней зависимости, которая используется в образе, задеплоенном несколько недель или месяцев назад, и о которой не было известно сканерам (той же Trivy) на момент прохождения Security Gate.
У нас очень много сервисов, их число уходит за несколько тысяч и сканировать их нон-стоп будет накладно. К тому же по каким критериям отправлять тот или иной сервис на дополнительный перескан, одни сервисы активно выкатываются и регулярно проходят security gate, другие могут месяцами не обновляться.
Поэтому было решено, пару раз в неделю парсить наше локальное докер реджестри, где находим сервисы, билд которых старше 30 дней. И автоматически заводим Jira таски на пересборку (прохождение Security Gate) и перевыкатку сервиса. Таким образом, есть правило, при котором не должно быть сервисов, билд которых был старше 30 дней.
При таком подходе, источником истины становиться докер реджестри, поэтому там должен быть наведен порядок, чтобы четко понимать, какие репозитории мы сканируем, а какие игнорируем, потому что к примеру нам не нужно отправлять на перескан образы экспериментал/тест/песочница.
Как альтернативный вариант, можно внедрить stackrox. У него есть image scanner, который сканирует только те образы что находятся прямо сейчас в k8s кластерах, то есть источник истины смещается с докер реджестри в k8s кластера. И мы не зависим от порядка и чистоты в нашем докер реджестри. Так же у него есть admission controller, который умеет отслеживать, такие сценарии как: "30/45/90 дней докер образу" и даже их блокировать, чтобы не запускались в кластерах.
кнопка “Approve” триггерит в StackStorm runbook “pr_approve”, что в свою очередь разрешает мерж в мастер и выкатку нового релиза в production
Что происходит под капотом, можете рассказать подробнее? Запускается интеграци по API с Git системой в части перезапуска скана, который по результату проходит SG со статусом ОК и это не блокирует завершение PR?
Прошу прощения, что пропал.. уезжал в отпуск и делал детоксикацию )
В ранбуке StackStorm "pr_approve", зашит API вызов допустим в bitbucket
curl -X POST
-H "Authorization: Bearer $OAUTH_TOKEN" https://api.bitbucket.org/2.0/repositories/myteam/myrepo/pullrequests/42/approve
В этом сценарии хотелось показать, что если по какому-то из критериев был не пройден SecurityGate, а значит не был поставлен автоматический approve на мерж PR, то приходит нотификация Security инженерам, которые смог ли бы ознакомиться/оценить и заблокировать/разрешить merge вручную
Поэтому было решено, пару раз в неделю парсить наше локальное докер реджестри, где находим сервисы, билд которых старше 30 дней. И автоматически заводим Jira таски на пересборку (прохождение Security Gate) и перевыкатку сервиса
Почему бы просто не дергать конвейер сборки? Который далее стриеррит конвейер деплоя?
Тут забыл уточнить, что нам важно чтобы в продакшене не было сервисов с образом, который старше 30/45 дней.
Продакшен, потому что как правило только там сервисы транслируются из приватной сети наружу, поэтому остальные енвы не так критичны.
Поэтому мы ищем докер образы сервисов, старше 30 дней с тэгом :"hash_commit"-master.
Просто прокатить сборки до мастера, мы не можем, так как разработчики могут готовить новый релиз в продакшен и он может быть не готов, так что пересборка на их усмотрение.
результаты сканирования (payloads), отправляются в наш SOAR (StackStorm), откуда попадают в ASPM “базу данных” уязвимостей DefectDojo
ASPM видя уязвимости (findings) в коде или в библиотеках, триггерит SOAR (StackStorm), тот в свою очередь заводит Jira таски на исправление, а также результаты сканов отправляет в Slack канал команды
Зачем при первой же уязвимости генерить таски в Jira если AppSec еще не выполнил триад, разве не AppSec должен принимать решение о генерации Task?
Да конечно, только AppSec имеет навыки интерпритировать результаты работы сканирования и выполнять триаж.
Но ситуация такая, что сервисов настолько много, что делать триаж всего, будет неподъемной задачей.
Поэтому принято, что: "все критикалы - зло", без оценки насколько эти уязвимости эксплуатируются, а если уже нет фикса уязвимости или разработчики не успевают пофиксить в срок, тогда уже начинается триаж таких уязвимостей.
При создании PR (!!не мерж!!) “stage → master”
Правильно понимаю, master статикой вообще не сканируете?
На схеме нарисовано, что идет "promote" тэга докер образа со stage енва в prod енв.
В свою очередь кодовая база в stage ветке уже была просканирована статикой и без изменений попадает в master(prod) ветку.
Как-будто результаты сканирования будут идентичными.
Получается никто не имеет права создавать PR в master кроме бота, который их делает только из stage?
PR в master могут создавать все
Но Aprove/Decline PullRequest (фактически мерж) в мастер, со стороны ИБ ставит бот
Если все хорошо автоматический Aprove на мерж в мастер, дальше разработчик мержит и новый релиз попадает в master
Если плохо по результатам сканирования, то режект/decline (заблокировать но не удалять) PR и уведомление секьюрити инженеров, где aprove будет решаться в частном порядке. Возможно договориться с командой, что уязвимость пофикситься через n дней и завезти задачу. Или AppSec возьмут эту уязвимость на триаж, чтобы оценить насколько страшный крит, и может пометить его false positive или скажут насколько можно ее отложить
Security Gate (DevSecOps cicd)