Comments 7
затерявшиеся сервисы на продакшене с 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 дней докер образу" и даже их блокировать, чтобы не запускались в кластерах.
Security Gate (DevSecOps cicd)