Для тех, кто управляет собственными сайтами или сервисами и хочет получать информацию об уязвимостях без постоянного просмотра лент. Эта статья рассказывает о том, что собирать, с чем сопоставлять и насколько можно доверять ИИ.
Что произошло: человек узнал первым, три раза подряд
За одну неделю на сайтах, которыми управляет оператор этого сайта, произошли три события. Во всех случаях оператор узнал о них первым, через социальные сети или электронную почту, а автоматическая система наблюдения к тому моменту ничего не сообщила.
Случай 1
Уязвимость PHP. Оператор узнал о ней первым. Автоматическая система наблюдения её не отметила.Случай 2
Вредоносный код, внедрённый в пакет Python. Оператор узнал о нём первым. Автоматическая система наблюдения его не отметила.Случай 3
Проблема в базовом образе контейнера. Оператор узнал о ней первым. Автоматическая система наблюдения её не отметила.
Первым предположением было «недостаточно источников». Единой причины не было: официальные источники могут отставать от того, что набирает популярность (подробнее ниже), и также не хватало данных, чтобы определить, что запись касается нашей системы. Слова «PHP» или «Python» встречаются в новостных текстах, но это не то же самое, что названия пакетов, которые вы реально запускаете.
Перестроенная система наблюдения
1. Сбор
Официальные уведомления / уведомления GitHub / списки вредоносных пакетов / KEV / новости / социальные сети
↓
Список A: технические слова, которые мы используем
Широкая сеть
Список B: реальные названия компонентов
Формируется из lock-файлов и пакетов ОС
↓
2. Правила отбирают совпадения (работают без ИИ)
↓
3. Недорогая ИИ-модель выполняет первичную сортировку
Она может повысить срочность. Понизить её она не может.
- Что собирается: официальные уведомления, уведомления GitHub, списки вредоносных пакетов, KEV агентства CISA, новости и социальные сети.
- Два списка для сопоставления: технические слова для широкого охвата и реальные названия компонентов для совпадений с высокой достоверностью. Список компонентов формируется из lock-файлов всех репозиториев и пакетов ОС.
- Сканирование всего образа: проверяется весь образ, включая базовый, а не только зависимости приложений.
- Отставание сред выполнения: измеряется, насколько среды выполнения, такие как Node, PHP и база данных, отстают от последних версий.
- Первичная сортировка ИИ: недорогая ИИ-модель первой отвечает на вопрос «затрагивает ли это нас?». ИИ может только повышать срочность.
Что показали измерения, в том числе то, что не совпало с ожиданиями
Первое допущение: официальных источников достаточно
Мы считали, что отслеживание официальных уведомлений и KEV поймает всё важное. На практике тема может набрать популярность до публикации уведомления. Одни только официальные источники проигрывают эту гонку.
После измерений: социальные сети как точка входа
Добавление социальных сетей позволило системе замечать события раньше, чем это делали одни только официальные источники. Но содержимое социальных сетей не считается фактом, пока официальный источник его не подтвердит. Широко на входе, осторожно при принятии решения.
- Проверка на пропуски: около 100 критических уязвимостей, собранных за 10 дней отдельной системой (созданной для поиска тем для статей), были сверены с этой системой. Пропусков среди тех, что затронули сайты оператора: 0.
- Исчерпание квоты ИИ: месячная квота закончилась, и ИИ-сортировка приостанавливалась примерно на 6 дней. Сопоставление по правилам без ИИ работало всё это время. В конструкции заранее задаётся дата окончания паузы, и часть с ИИ возобновляется автоматически с этой даты.
- Пробел для нового сервера: пакеты ОС недавно добавленного сервера отсутствовали в списке компонентов. Его обнаружила ежемесячная пересборка списка. Список заслуживает доверия, только если он регулярно пересоздаётся, а не составляется однажды.
Как построить это для вашей среды
Сформируйте список компонентов (SBOM) автоматически
Составляйте его и из lock-файлов всех репозиториев, и из пакетов ОС ваших серверов и контейнеров. CISA описывает SBOM как вложенный перечень, список ингредиентов, из которых состоят программные компоненты. Генераторы SBOM, например открытый инструмент Syft, читают пакеты ОС и зависимости основных языков из образов контейнеров и файловых систем и могут выводить результат в формате CycloneDX или SPDX.
Сопоставьте список с известными уязвимостями
Для сопоставления зависимостей открытый инструмент osv-scanner читает lock-файлы и контейнеры. Настройка и интеграция в CI описаны в статье osv-scanner: настройка и использование.
Расставьте приоритеты с помощью KEV и EPSS
Когда находок много, нельзя устранить их все с одинаковой срочностью. Начните с того, что подтверждённо эксплуатируется (KEV), и с того, что имеет высокую прогнозируемую вероятность эксплуатации (EPSS). Как их сочетать, описано в статье CVSS, EPSS и KEV: как использовать их вместе.
Если вы используете ИИ, применяйте его только для повышения срочности
Даже если ИИ говорит «не затронуто», не удаляйте запись, которую отобрало правило. ИИ может ошибочно сказать «не относится», и цена пропуска выше, чем цена ложной тревоги.
Определите, что делать, когда ИИ недоступен
Квоты заканчиваются, сервисы выходят из строя, провайдеры прекращают работу. До начала эксплуатации решите, что одни только правила без ИИ по-прежнему отправляют минимальный набор уведомлений, и задайте дату возобновления, чтобы часть с ИИ вернулась автоматически.
Регулярно пересоздавайте список
Пробелы возникают, когда сервер или репозиторий добавлен, а список не обновлён. Пересобирайте его не реже раза в месяц и проверяйте, что добавленное в него попало.
Не считайте информацию из социальных сетей фактом, пока её не подтвердит официальный источник
Социальные сети быстры, но в них смешаны ошибки и домыслы, которые поставщик не подтвердил. Используйте их как точку входа, но основывайте реагирование на проверяемых первоисточниках, таких как уведомление поставщика или KEV.
Взгляд этого сайта: широкий охват по техническим словам, сужение по названиям компонентов
По опыту оператора, переход к сопоставлению по реальным названиям компонентов уменьшил количество ложных срабатываний и пропусков. Но если список компонентов устарел, это напрямую ведёт к пропускам. Нужны оба элемента: широкий охват и точный список для его сужения. Эта статья описывает систему наблюдения, построенную для сайтов, которыми управляет оператор.
Источники (первичные и официальные)
- CISA — Known Exploited Vulnerabilities Catalog (уязвимости, подтверждённо эксплуатируемые)
- CISA — Software Bill of Materials (SBOM) (определение SBOM)
- FIRST — EPSS (прогнозируемая вероятность эксплуатации)
- OpenSSF — malicious-packages (репозиторий отчётов о вредоносных пакетах в формате OSV)
- Anchore — Syft (создаёт SBOM из образов контейнеров и файловых систем; вывод в CycloneDX и SPDX; пакеты ОС и основные языки)
Читайте далее
- Инструмент: osv-scanner: настройка и использование
- Приоритеты: CVSS, EPSS и KEV: как использовать их вместе
- Пример: Критическое обновление безопасности PHP
- Связанное: Защита от атак на цепочку поставок npm