Триаж CVE
Сканер вручает вам четыреста идентификаторов CVE и столбец серьёзности, который называет большинство из них критическими. Этот стол ранжирует список по тому, что действительно эксплуатируется: каталог KEV от CISA — для известной эксплуатации, оценки EPSS от FIRST — для вероятности эксплуатации, и CVSS — для воздействия; каждый вход напечатан рядом с приоритетом, который он породил, так что порядок можно проверить, а не принимать как магическое число.
В вводе пока не найдено идентификаторов CVE.
Каждую неделю работаете с очередью исправлений? Мониторьте свои сайты бесплатно с myeventwatch — оповещения об истечении срока и простоях, карта не нужна.
Как работает ранжирование
Каждый идентификатор ищется в трёх источниках и получает полосу приоритета по первому правилу, которому соответствует. P1 — это вхождение в каталог известных эксплуатируемых уязвимостей (KEV) CISA: это не прогнозы — CISA включает CVE только при наличии доказательств активной эксплуатации, — поэтому запись KEV превосходит всё остальное, а таблица показывает её срок исправления и отмечает ли CISA известное использование программ-вымогателей. P2 — это оценка EPSS 0,10 или выше: EPSS, поддерживаемый FIRST, моделирует вероятность того, что CVE будет эксплуатироваться в ближайшие 30 дней, и 0,10 — это высоко: подавляющее большинство оценённых CVE сидит ниже 0,01, поэтому столбец процентиля тоже показан, чтобы сырая оценка оставалась честной. P3 — это базовая оценка CVSS 7,0 или выше (Высокая или Критическая) без сигнала эксплуатации: серьёзно, если используют, но использования не известно. P4 — всё остальное, у чего есть данные. Внутри полосы строки сортируются по EPSS, затем по CVSS — и каждый заголовок столбца пересортировывает таблицу, потому что ваша очередь может законно отличаться от порядка по умолчанию. Чего полоса никогда не делает — не прячет свои входы: если вы не согласны с приоритетом строки, числа, из которых он взялся, находятся на той же строке.
Откуда берутся данные и насколько они свежи
Каталог KEV и оценки EPSS кэшируются ежедневно на сервере sysosx — оба издателя выпускают по одному массовому файлу в день, поэтому стол скачивает эти файлы раз в день, а ваш запрос читает локальные копии. Заголовок результата указывает собственную дату каждого канала (дату выпуска каталога, дату оценки EPSS) и время его получения, так что вы всегда знаете, данные какого дня ранжировали ваш список. CVSS — исключение: ни KEV, ни EPSS его не несут, поэтому оценки берутся из NVD — получаются один раз, при первом запросе CVE, и постоянно кэшируются на сервере, потому что опубликованная оценка CVSS не меняется. Очень свежая вставка поэтому может показывать несколько оценок как ожидающие: это значит, что кэш ещё не добрался до этих идентификаторов, а не что у них нет оценок — запустите список вскоре ещё раз, и они заполнятся. Свежие запросы ограничиваются по посетителю, как и другие серверные проверки, а повторение той же вставки обслуживается из короткого кэша. Под капотом страница вызывает GET /api/check/cve-triage на сервере sysosx с извлечёнными идентификаторами.
Чего этот стол не может вам сказать
Три честных ограничения. Во-первых, «Нет в кэшированных данных за сегодня» — это отсутствие в трёх наборах данных, а не вердикт: не известно об эксплуатации, нет оценки EPSS, и у NVD нет записи — он всё ещё может быть новым, спорным или оценённым под другим идентификатором, и он заслуживает ручного взгляда, а не пожимания плечами. Во-вторых, данные об эксплуатации касаются CVE в мире, а не вашего актива: P4 на сервере, обращённом в интернет, может превзойти P1 на изолированной тестовой машине, и только вы знаете, что есть что — триажируйте сначала партию, обращённую в интернет, поэтому стол и берёт по 200 идентификаторов за раз, а не притворяется, что одно ранжирование подходит всему парку. В-третьих, включение в KEV отстаёт от эксплуатации, а EPSS — модель, а не оракул; оба — куда лучшие доказательства, чем серьёзность сама по себе, и ни один не заменяет чтения рекомендаций поставщика для P1. Рассуждение за ранжированием — и разобранный пример — в статье триаж CVE по эксплуатации, а не только по серьёзности.
Связанные инструменты: сканер портов — какие службы хост действительно открывает (активная половина каждого решения по CVE), проверка здоровья сайта — сертификат, срок и записи того же хоста, и оценщик SSL, когда находка — конфигурация TLS, а не CVE.
Частые вопросы
Откуда берутся данные и насколько они свежи?
Три публичных источника, каждый помечен своей датой в результате. Каталог известных эксплуатируемых уязвимостей CISA и ежедневные оценки EPSS от FIRST скачиваются на сервер sysosx раз в день и кэшируются там — ваш запрос читает локальную копию, он не опрашивает CISA или FIRST вживую. Оценки CVSS берутся из NVD: первый запрос CVE получает её один раз и кэширует постоянно, потому что опубликованная оценка CVSS не меняется. Если оценка читается как «ожидающая», кэш ещё не добрался до этого CVE — запустите список через минуту, и она заполнится.
CVE из моего сканера отсутствует или показывает «нет в кэшированных данных за сегодня». Он безопасен?
Такого вывода не существует, и страница не будет притворяться обратным. «Не найдено» означает только, что идентификатор не встречается ни в одном из сегодняшних кэшированных источников — его нет в каталоге KEV, у него нет оценки EPSS в текущем файле, и у NVD нет для него записи CVSS. Новые CVE появляются ежедневно, EPSS оценивает только те CVE, которые смоделировал, и CVE может быть настоящим, серьёзным и просто слишком новым для любого из трёх. Относитесь к отсутствующим строкам как к «триажировать вручную», а не как к «игнорировать».
Почему CVSS 9,8 ранжирован ниже CVSS 7,5?
Потому что ранжирование идёт по эксплуатации, а не по воздействию. 7,5 находится в каталоге KEV: известно, что атакующие его используют, поэтому это P1. У 9,8 высокая оценка EPSS или её нет вовсе — серьёзно при эксплуатации, но нет доказательств, что кто-то уже его эксплуатирует. Серьёзность говорит, насколько плохим было бы нарушение; KEV и EPSS говорят, насколько вероятна попытка. Порядок исправлений должен сначала следовать вероятности и использовать серьёзность как решающий фактор при равенстве — именно это и кодируют полосы P1–P4. Статья по ссылке ниже полностью разбирает это рассуждение.
Что именно означают полосы приоритета?
P1: CVE находится в каталоге KEV CISA — известная эксплуатация, исправляйте сейчас и обратите внимание на столбец срока KEV. P2: не в KEV, но его оценка EPSS — 0,10 или выше — смоделированный шанс эксплуатации 10 % и выше в ближайшие 30 дней, очень разрежённый воздух (гораздо меньше 1 % оценённых CVE). P3: ни то ни другое, но базовая оценка CVSS 7,0 или выше (Высокая или Критическая). P4: данные есть, но ни один порог не выполнен — планируйте его как обычно. Каждый вход за полосой напечатан в собственном столбце; полоса — это порядок сортировки, а не оценка, которую нужно принимать на веру.
Могу ли я триажировать больше 200 CVE?
Стол принимает 200 идентификаторов за запрос — вставьте список двумя партиями. Этот предел не даёт одному запросу монополизировать проверяющий модуль, и на практике экспорт сканера в любом случае полезнее делить по группам активов: триажируйте сначала партию, обращённую в интернет, потому что один и тот же CVE — разная чрезвычайная ситуация на публичном сервере и на изолированной рабочей станции.