«Чем можно контролировать уязвимости? Подскажи, плиз», — обратился недавно знакомый. Вроде ничего странного. Но к концу обсуждения я вдруг понял, что человек ждет список инструментов, которые только находят и закрывают уязвимости.
Сел гуглить. Оказалось, что почти всегда работа с уязвимостями, судя по статьям в интернете, ограничивается только обнаружением и закрытием дыр. Хотя на практике это далеко не так — задач намного больше.
В общем, сегодня поговорим о том, какие системы помогают работать с уязвимостями комплексно, на всех этапах жизненного цикла — от обнаружения до устранения.
Дикслеймер: Решений для управления уязвимостями много. В статью вошли только opensource-инструменты. Причем далеко не все: я не стал рассматривать продукты, которые не коммитились более двух лет. Думаю, понятно почему.
Но сначала о терминах
Управление уязвимостями (vulnerability management) — непрерывный процесс выявления и устранения уязвимостей в инфраструктуре компании. И он требует инструментов, которые способны работать на всех этапах: от инвентаризации активов и выявления уязвимостей до их устранения и выработки рекомендаций.
Весь этот функционал несут в себе платформы управления уязвимостями (vulnerability management tools). Благодаря им можно работать централизованно. В одном интерфейсе пользователи видят данные об уязвимостях из разных систем, могут приоритизировать их, отслеживать жизненный цикл вплоть до контроля устранения.
Многие считают, что сканеры — это тоже vulnerability management tools. Как видите, нет — они только находят дыры. Vulnerability management tools делают больше. Они выполняют все задачи, которые только начинаются с обнаружения уязвимости.
На практике разница между классами инструментов колоссальная. Одно дело — когда раз в неделю вы получаете многостраничный отчет с найденными уязвимостями и пытаетесь понять, что с этим всем делать (чаще ничего не делается, кстати). Другое — вы открываете приложение, в котором видите всю картину разом. Причем тут же можно отфильтровать важные уязвимости, изучить какие-то подробнее, а заодно еще и отследить, когда и как именно они были закрыты.
Что этот «джанго» себе позволяет
Да много чего. Вообще django-DefectDojo заявлен как DevSecOps-платформа. Она, по описанию разработчика, позволяет управлять багами и уязвимостями на протяжении всего жизненного цикла проекта. Понятное дело, продукт интегрируется в CI/CD.
Из плюшек: есть интеграция с популярными решениями для динамического и статического тестирования безопасности приложений (DAST, SAST), анализа состава ПО (CSA) и моделирования угроз. В итоге все, что нужно для контроля уязвимостей и отслеживания их статусов, находится в одном месте.
У решения есть обе редакции — и community, и enterprise.
Чем заряжен Фарадей
Faraday позиционируется аналогично предыдущему продукту — как платформа управления уязвимостями с открытым исходным кодом. И тоже встраивается в CI/CD, в том числе через GitHub, Jenkins, TravisCI и Gitlab.
Что здесь интересного: Faraday не только обменивается данными об уязвимостях с большим списком систем. Он сам отдает команды на сканирование: разработчик написал плагины для интеграции с разными системами, которые используются для поиска уязвимостей. Из окна Faraday можно запустить базовые задачи по сканированию, причем без перехода в интерфейс сканера.
У продукта также есть коммерческая редакция.
VMC по уязвимостям
Еще один инструмент контроля уязвимостей — Vulnerability Management Center (VMC). Решение разработано и поддерживается под эгидой OWASP.
Плюсы: если нужно управлять инцидентами, можно интегрироваться с опенсорсным сервисдеском для ИБ-специалистов TheHive, если нужна инвентаризация ресурсов — с Ralph. В качестве интерфейса для визуализации используется привычная Kibana, а для сканирования уязвимостей — знакомые многим Nessus и OpenVAS.
К слову, у OWASP VMC есть белорусский конкурент — система управления уязвимостями Fenix-VM. В описании платформы указано: «ВАЖНО! Это не сканер уязвимостей!». Судя по двум восклицательным знакам и жирному шрифту, понятия путают не только в России :)
MetaHub и все-все-все
Если хотите полноценно управлять уязвимостями в среде AWS, рекомендую MetaHub. Решение интегрируется с AWS Security Hub.
Из важного: инструмент умеет рассчитывать критичность найденной уязвимости, полагаясь на известные данные о проекте. Критериями оценки можно управлять: использовать фильтры, сортировать, подгружать новые и т.д.
Бывают ситуации, когда нужно разобраться с уязвимостями в репозиториях. С этой задачей справляется Octovy со встроенным сканером Trivy.
И наконец, есть неплохой бесплатный инструмент PeCoReT. Он зашел на рынок с другой стороны — как решение для атакующих команд (RedTeam). Он автоматически генерирует отчеты о пентесте и помогает мониторить найденные уязвимости на всех стадиях работы с ними.
Платной версии PeCoReT нет — продукт абсолютно опенсорсный, можно подключать любое количество пользователей и проектов одновременно.
А теперь о главном
Казалось бы, вот они слева направо — все решения для комплексной работы с уязвимостями. Бесплатные, лежат на Гитхабе. Просто берешь и инсталлируешь.
Но на практике установки мало: инструментами для управления и самим процессом нужно управлять. Все важные решения по уязвимостям все равно определяет человек, пусть даже разово — при настройке правил. От знаний и опыта пользователя порой зависит намного больше, чем от функциональности инструмента.
К чему эти рассуждения? Да к тому, что иногда лучше передавать управление уязвимостями профессионалам. Особенно если голова и руки постоянно заняты другими, более срочными и важными, делами.
select26
Так все же чем их контролировать? Есть сотня-другая VMs. Как регулярно их проверять на наличие уязвимостей и получать "раз в неделю многостраничный отчет с найденными уязвимостями"?
Не идет речь об интеграции с CI/CD. Это совершенно другая тема и занимается этим команда разработки.
Нужны отчеты в т.ч. для PCI DSS. compliance.
avbykov Автор
Если задача просто получать отчет с уязвимостями, достаточно сканера, работающего по расписанию)
Но если говорить о всем процессе, то я бы начал с разложения задачи на этапы и выбора инструментария.
Могу рассказать на примере своей предпочитаемой связки: nmap, openvas, defectDojo, ZAP.
Инвентаризация активов.
Проводим discovery-сканирование openvas, получаем список хостов и хостнеймов в нашей сети. В качестве дополнительно инструмента можно использовать nmap.
Анализируем отчеты, если необходимо делим ресурсы на сегменты по критичности (пригодится на этапе 5).
Сканирование и обнаружение уязвимостей.
Проводим сетевое сканирование на уязвимости с помощью openvas. Веб-приложения сканируем с помощью ZAP. Отчеты загружаем в DefectDojo.
Классификация уязвимостей
У DefectDojo есть механизм скорринга уязвимостей. Но можем отдельно добавлять свои теги, например для более критичных сегментов или систем.
Анализ угроз.
Номера CVE и NVT (в случае openvas) есть в отчетах. Для большинства уязвимостей описание есть тут же в интерфейсе DefectDojo.
Приоритизация устранения.
Здесь я обычно тоже ориентируюсь на критичность уязвимостей (пункт 3) и бизнес-логику. Условно критичные системы с серьезными уязвимостями идут в приоритете.
Уязвимости, которые можно эксплуатировать извне, приоритетнее тех, что доступны только из внутреннего периметра.
Приоритеты стоит описать в политике.
Устранение уязвимостей.
Здесь в ход идут СЗИ для "виртуального патчинга" (WAF, NGFW, HIPS -- в зависимости от уязвимости) и процесс по обновлению уязимых служб и фиксу кодовой базы.
Отслеживать процесс можно тут же, в DefectDojo. Есть поля для описания каждого этапа.
Если необходимо, можно интегрироваться с Jira. Ну или распараллелить процесс со своим SD.
Отслеживание и мониторинг.
Повторяем все процедуры с регламентированной периодичностью и в случае необходимости.
Обучение и осведомленность.
Это чаще решается все же административными методами, но есть и платформы для обучения персонала.
Отчетность и документация.
Отчеты формируются в DefectDojo, процесс формализуется и документируется, видно в целом всю историю уязвимостей и работы с ними.
Для прохождения аудита по PCI DSS такой работы вполне достаточно. У аудиторов есть возможность проверить реализацию контроля уязвимостей и всю историю уязвимостей.
Хотя, по моему опыту, обычно достаточно подтверждения регулярности сканирования и зафиксированной в SD работы по их устранению.
По PCI DSS еще есть требование по ASV-сканированию. Но там никуда не денешься -- нужно идти к коммерческим сертифицированным партнерам.
select26
Спасибо большое!
Есть у нас всё. Есть полноценный SEIM. Хотим отказаться от AlienVault, который security team по привычке использует только для скан и формирования квартальных отчетов.