Привет Хабр! Меня зовут Татьяна Хуртина, и я программист в группе внутренней автоматизации ИБ VK. Недавно я выступала на киберфестивале PHDays c докладом про наш подход для мониторинга безопасности контейнеров. На примере опыта в inhouse-облаке Дзена я рассказала, как можно использовать Open Source решения, чтобы искать уязвимости в Runtime.
И сразу оговорюсь, что тут в понятие Runtime мы вкладываем мониторинг уязвимостей в запущенных в оркестраторе контейнерах в (почти что) реальном времени.
Если перед вами стоит похожая задача, возможно, вам пригодится наш практический опыт. Публикую здесь ключевые мысли и схемы.
Предпосылки
Большинство IT-компаний сейчас используют контейнеры для развертывания инфраструктуры своих продуктов, при этом образы контейнеров могут содержать ошибки и уязвимости, которые могут нанести ущерб работе всего сервиса.Что касается ситуации в мире? По статистике Sysdig: 87% контейнеров в prod имеют высокие и критические уязвимости. Только 15% из них используются в runtime, да и не все уязвимости можно проэксплуатировать в принципе. Поэтому если объединить несколько критериев уязвимости (наличие исправления, использование в Runtime и возможность эксплуатации), то для исправления остается всего 2% уязвимостей.
В разработке часто используются сторонние библиотеки, но ключевой вопрос безопасности – насколько им можно доверять?
К примеру, когда разработчик делает pip install, то не очевидно, какие зависимости будут установлены. К тому же, существует множество методов подмены пакетов – к примеру, создание поддельных с похожими названиями.
Также известно, что вредоносные зависимости наследуются из разных источников, и если не знать, где и какие библиотеки задействованы, то неясно, куда обратиться для устранения уязвимости. Мы не встраиваем проверки в pipeline, чтобы:
не замедлять разработку и доставку продукта;
критичность уязвимости должна определяться аналитиком, а не сканером (возможны ложные срабатывания);
база уязвимостей постоянно пополняется (сейчас уязвимости нет – завтра ее обнаружат).
Поэтому лучше регулярно сканировать уже запущенный сервис, чтобы иметь актуальную информацию об уязвимостях. И устранять критические. Все это подводит к логической необходимости сквозного мониторинга для поиска критически важных уязвимостей и обеспечение комплексной безопасности уже функционирующего приложения.
С чем мы столкнулись в Дзен?
В Дзен нестандартная инфраструктура, развернутая во внутреннем облаке с иерархической системой организации структур и сервисов. Дзен использует десятки тысяч контейнеров, из них тысячи уникальных образов с сотнями различных зависимостей, и регулярно появляются новые образы. Кроме того, существуют требования по соблюдению SLA по сканированию в больших объемах.
Для решения вопросов безопасности в Дзене реализована функция архитекторов ИБ – они проводят анализ продукта и формируют задания по безопасности, а в случае публикации уязвимости помогают быстро обнаружить проблему и предложить решение по исправлению. Поэтому нам надо было обеспечить архитекторов ИБ удобными инструментами контроля, которые позволяли бы закрыть задачи по инвентаризации – сколько и каких сервисов запущено, какие они имеют компоненты, какие лицензии компонентов; и задачи и по работе с уязвимостями – быстрому поиску, приоритезации и устранению.
Решение
Система для мониторинга безопасности контейнеров встраивается в классическую модель DevSecOps. С ее помощью мы работаем сразу на четырех этапах процесса.
На этапе Release происходит анализ контейнеров и пакетов, на этапе Deploy – отслеживание зависимостей, на этапе Operate – анализ уже запущенных контейнеров, что позволяет реализовать механизм оперативного обнаружения уязвимых зависимостей и контейнеров. И все это, по сути, добавляет возможность наблюдения на этапе Monitor.
Внедрение контролей информационной безопасности в pipeline может привести к замедлению процессов разработки и доставки продукта, что нежелательно для бизнеса. Поэтому мы избегали встраивания в сборки. И по возможности стараемся сделать так, чтобы контроли ИБ для пользователя оставались незаметными.
Мы сразу решили, что будем создавать собственное решение на базе Open Source. Основная причина – отсутствие на рынке подходящего решения, потому что у Дзена высокие нагрузки и своя нестандартная инфраструктура облаков. Кроме того, Open Source решение дает технологическую независимость разработки – мы не привязаны к определенному стеку и можем использовать различные связки, гибкость в корректировке ошибок по DPO, то есть выявленные баги можно править самому, а не ждать очередной патч от вендора.
Из чего собирали
Сперва мы взяли один из самых известных сканеров безопасности для поиска уязвимостей и ошибок в конфигурациях – Trivy. У него довольно широкий спектр задач, но нам он был больше интересен выявлением программных зависимостей из Docker-образов и выявлением уязвимостей.
К анализатору добавили платформу для управления безопасностью Dependency-Track, потому что ее дашборд позволяет увидеть общий обзор безопасности проекта, информацию о уязвимостях и рекомендации по их исправлению, список проектов и их текущий статус безопасности. Это удобный инструмент для аналитиков ИБ, который позволяет видеть актуальное состояние зависимостей и их уязвимости. Он помогает приоритизировать уязвимости и оперативно реагировать на критически важные.
Однако, по нашему опыту Trivy сканируют на уязвимости лучше, чем это делают другие сканеры, в том числе и встроенный в Dependency-Track. Поэтому мы решили доработать Dependency-Track, создав плагин Trivy-REST, чтобы он ходил для проверки на уязвимости не в свои встроенные сканеры, а в Trivy. Таким образом мы обеспечили возможность автоматизированного сканирования компонентов и получения результатов анализом.
К этому добавили собственный сканер, написанный на Go. Он содержит планировщик, который собирает информацию о запущенных Docker-образах в облаке. Этот сканер с помощью Trivy создает SBOM и сохраняет базу данных. Также сканер отправляет эти данные из SBOM в Dependency-Track для дальнейшего анализа на уязвимости.
SBOM является ключевым элементом процесса выявления уязвимости. Он представляет собой перечень зависимостей, файлов, библиотек и других элементов, имеющих отношение к конкретному сервису или инфраструктуре целиком. Его основная задача — это предоставить наиболее полную информацию о зависимости, типах лицензий.
Для хранения SBOM мы выбрали формат CycloneDX, потому что его поддерживает и Trivy и Dependency-Track. Он содержит в себе информацию о метаданных, компонентах, зависимостях и уязвимостях.
Механика процесса
1. Сканер периодически запрашивает список запущенных в облаке образов, обеспечивая актуальность данных мониторинга.
2. Сканер получает информацию по каждому образу из Registry. В качестве уникального идентификатора образов служит хеш-сумма (Digest)
3. Сканер посредством Trivy создает SBOM в формате CycloneDX и сохраняет его в базу данных.
4. Также сканер посредством другого планировщика создает проект в Dependency-Track и отправляет SBOM. Отправляются как новые SBOM, так и уже существующие. Поскольку база уязвимостей периодически обновляется, следует пересканировать уже существующие образы.
5. Dependency-Track, используя Trivy-REST, анализирует компоненты на уязвимости.
Почему мы выбрали анализаторы Trivy, а не Dependency-Track?
Dependency-Track имеет несколько сервисов для выявления уязвимости – Internal, OSS Index, VulnDBи Snyk. В качестве источников для анализа уязвимостей он использует: NVD, GitHub Advisories и OSV.
NVD матчится по CPE, и тут происходит много ложных срабатываний. Сопоставление происходит по вендору, продукту и версию, а вендор зачастую некорректно заполнялся. Поэтому остаются только поля product и version, то есть экосистема, в которой существовал пакет, полностью не учитывалась.
GitHub Advisories и OSV мэтчатся по PURL, но GitHub Advisories анализирует уязвимости только проектов на GitHub, и они совокупно поддерживают меньше экосистем, чем Trivy.
Поэтому анализатор Trivy с открытым репозиторием обладает большим набором преимуществ. Особенно, это поддержка большого количества дистрибутивов Linux. У дистрибутивов Linux существуют свои листы с уязвимостей, и все эти листы в виде больших XML Trivy скачивает и складывает в свою базу уязвимостей.
Вместо заключения
Конечно, внутри этого решения есть еще много шагов для улучшения. Нужно доработать отказоустойчивость, UX/UI и улучшить скорость работы. Но уже сейчас сканеры за 30 минут анализируют порядка 200 образов с минимальной нагрузкой на облако. Сканирование происходит на отдельных мощностях чтобы не аффектить на продуктовые сервисы. Пошли в оптимизацию и сканируем только запущенные образы. Также, с помощью этого решения мы полностью закрыли задачи по инвентаризации и работе с уязвимостями.
Данная система может легко и в любой момент быть интегрирована в процессы обеспечения безопасности на любой инфраструктуре – Docker, Compose, Nomad, Kubernetes, даже если это уже функционирующее приложение. Оно позволит повысить эффективность взаимодействия команды ИБ и разработки, особенно, в части приоритизации задач по устранению уязвимостей.
PS: полную версию моего доклада вы можете посмотреть здесь.