Послушал третий эпизод подкаста КиберДуршлаг про Трендовые Уязвимости. Гостями подкаста в этот раз были Юрий Шкодин и Егор Подмоков из PT Expert Secu­ri­ty Cen­ter (ESC). Для меня особенно интересный эпизод, т.к. ответ на вопрос куда именно в PT я вышел — вот конкретно к ним. 🙂 Выписал некоторые тезисы.

1. Трендовые уязвимости — уязвимости, которые эксплуатируются сейчас (на которые есть эксплоиты) или которые будут эксплуатироваться в ближайшее время. Это те уязвимости, на которые заказчики должны обратить внимание в первую очередь в своей инфраструктуре.
2. Трендовых уязвимостей не должно быть везде в инфраструктуре или только в DMZ? Дискуссионный вопрос, нужно исходить из модели рисков. Трендовая уязвимость на тестовом стенде внутри IT-инфраструктуры это не очень важная уязвимость.
3. Трендовость Уязвимости зависит от уязвимого продукта. Они могут быть очень специфичными: Church Man­age­ment система, управления автомобилями и т.п. Необходимо учитывать реальные возможности по детектированию. Продукты, которые неинтересны ни нам, ни заказчикам, мы добавляем в black list, который, при необходимости, пересматриваем.
4. Исходные данные для оценки трендовости собираем из баз уязвимостей, бюллетеней безопасности вендоров, социальных сетей и мессенджеров, баз эксплоитов, публичных репозиториев кода.
5. Фолзы детектов уязвимостей, отчего они? Например, в детекте уязвимостей Win­dows по KB-шкам. Могут быть ошибки роботов-сборщиков данных. Может быть задержка реагирования на изменение в контенте вендора. Может быть вендор ПО предоставляет информацию об обновлениях недостаточно прозрачно.
6. Форки Open Source продуктов, которые не фиксят и не сообщают об уязвимостях исходного продукта. Призываем вендоров за этим следить. И желательно, чтобы вендоры публиковали информацию о своих уязвимостях в одном месте, идеально в БДУ ФСТЭК.
7. Сложности с детектами. Версионные детекты: уязвимость в выключенной фиче или выключенном ПО это уязвимость? Детекты с эксплуатацией: проверка не сработала, а насколько этому можно верить? Насколько правильно проверки реализованы и на основе каких эксплоитов?
8. Пользовательские детекты для софтов и уязвимостей — крутая тема. Идём в эту сторону.
9. Для отладки детектов необходимы реальные стенды с уязвимыми продуктами. Здесь вопросы с оценкой популярности софта (невозможно поддерживать всё) и нотификациями о выпуске новых версий софта. В эти темы тоже идём.
10. Доставка трендовых уязвимостей в MP VM за 12 часов. Трендовые уязвимости, как правило, начинают эксплуатировать через 24 часа (плюс это требование ФСТЭК из методики оценки критичности). Из них 12 нужно VM вендору на реализацию проверки и 12 нужны клиенту на детекты и исправление. Для более быстрой доставки идём к тому, что в базе MP VM будут все уязвимости, не только те, для которых есть детекты. Нужно будет только быстро добавлять детекты (возможно силами самих клиентов). Ассетная модель позволяет получить сработки без пересканирования по имеющимся данным.
11. Bug­Boun­ty может использоваться для контроля известных уязвимостей сетевого периметра и выполнения SLA (например хантер может сдавать известные уязвимости старше 30 дней).
12. HCC PT Essen­tials это минимальный набор требований к конфигурациям, которые обязательно должны выполняться. Идём в сторону возможности реализовывать свои проверки.
13. Идеальный VM вендор. Прозрачность по текущим и будущим фичам (открытый roadmap). Улучшение покрытия продуктов. Самостоятельность заказчиков в плане наполнения базы знаний уязвимостей и детектов, возможность делиться этим контентом через маркетплейс. Метапродукты работающие с минимальным количеством людей. Автоматизированное исправление уязвимостей с аппрувом от IT.