Недостающие временные метрики CVSS v3 и v3.1 (Уровень зрелости кода эксплуатации и Уровень устранения) во всех CVE с использованием API NVD

Вопрос или проблема

Я работал с API NIST – NVD v2 и заметил, что временные метрики “remediationLevelType” и “exploitCodeMaturityType” отсутствуют во ВСЕХ CVE, которые я искал с помощью API NVD.

Хотя эти метрики существуют в схеме CVSS (https://csrc.nist.gov/schema/nvd/api/2.0/external/cvss-v3.1.json), они не появляются в ответе API. Вместо этого все они установлены на “не определено”, когда я ищу CVE и проверяю пример расчета:

https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?name=CVE-2023-0002

У меня также есть локальная копия базы данных NIST, но ни в одном из CVE в ней нет этих метрик.

Мой вопрос: предоставляет ли NIST информацию об этих значениях? Они должны быть доступны через API NVD или любой другой источник?

Буду признателен за любые идеи, объяснения или предложения о том, как решить эту проблему.

Заранее спасибо!

Я работаю с NVD (и локальными репликациями его базы данных для кастомного запроса) уже 7 лет и никогда не видел ни временной, ни экологической оценки.

Я понимаю, что хотя

  1. эти оценки, конечно, являются частью спецификации CVSS
    (https://www.first.org/cvss/specification-document),
  2. и некоторые ссылки на CVE могут быть помечены как ‘PoC’ или ‘Exploit’, а также ‘Mitigation’ или ‘Patch’,
  3. и в целом, анализ NVD по CVE имеет историю и может быть пересмотрен,

факт остается фактом: аналитики NVD никогда не устанавливают и не пересматривают эту оценку. Вероятно, как из-за нехватки достаточно надежной информации, так и из-за недостатка ресурсов. Особенно это требовало бы надежных источников информации о угрозах.

Обратите внимание, что по теме “надежные источники информации о угрозах” были некоторые успехи. Особенно, с ноября 2021 года появилось 2 новые организации. Сторона публичного сектора – CISA KEV (https://www.cisa.gov/known-exploited-vulnerabilities-catalog). CVE, входящее в этот каталог, явно обозначается как таковое в NVD, например https://nvd.nist.gov/vuln/detail/CVE-2014-0196. В частном секторе – InTheWild.io (https://inthewild.io/) от краудсорсинга.

Также обратите внимание, что вы можете иметь 2 разные оценки CVSS в NVD: одну от аналитиков NVD, и другую от сообщающего CNA. Ваш пример CVE-2023-0002 иллюстрирует это с помощью второй оценки CVSS от Palo Alto Networks, Inc. Red Hat систематически пересчитывает свои CVSS, смотрите https://www.redhat.com/en/blog/security-flaws-and-cvss-rescore-process-nvd. Это иллюстрирует тот факт, что вы можете оценивать и пересчитывать CVSS по своему усмотрению, при этом соблюдая спецификацию. Особенно вы и только вы можете рассчитывать экологическую оценку: она зависит от контекста продукта и его использования в вашей организации.

С общей точки зрения, CVSS является одной из тех вещей, которая как чрезмерно спроектирована, так и недоиспользуется в NVD (CPE – другой пример).

Для обзора причины, по которой следует относиться к CVSS с определенной долей скептицизма, я могу настоятельно порекомендовать эту блестящую статью (длинная, но стоит вашего времени): https://theoryof.predictable.software/articles/a-closer-look-at-cvss-scores/

Ответ или решение

Ваша проблема с отсутствием временных метрик CVSS, таких как "уровень зрелости эксплойта" (Exploit Code Maturity) и "уровень устранения" (Remediation Level), в результатах API NVD (National Vulnerability Database) возникает из-за особенностей, связанных с тем, как NVD обрабатывает и присваивает метрики.

  1. Отсутствие метрик: Как вы уже заметили, несмотря на то, что эти метрики указаны в спецификации CVSS (например, установленной FIRST), на сегодняшний день база данных NVD не публикует эти значения для CVE (Common Vulnerabilities and Exposures). Это довольно распространенное наблюдение среди пользователей NVD, поскольку, как правило, аналитики NVD не устанавливают и не пересматривают эти временные оценки. Ваша информация о том, что данные метрики всегда находятся в статусе "не определено", технически корректна.

  2. Недостаток информации: Основной причиной данного явления является отсутствие надежной информации от источников, способных предоставить данные, необходимые для назначения временных метрик. Без доступа к достаточным и актуальным данным по уязвимостям сложно установить уровень зрелости эксплойт-кода или уровень устранения. Поэтому отсутствие этих метрик также может быть связано с нехваткой ресурсов как со стороны аналитиков NVD, так и с ограничениями в доступности информации.

  3. Новые источники информации: В последние годы мы наблюдаем некоторые улучшения в этом направлении. Например, КATALOG KEV (Known Exploited Vulnerabilities) от CISA и платформы, такие как InTheWild.io, могут стать новыми источниками данных, которые помогут аналитикам NVD в процессе публикации более актуальной информации о уязвимостях.

  4. Различие в оценке: Также важно отметить, что NVD может приводить как свои собственные оценки CVSS, так и CVSS, разработанные другими организациями, такими как CNA (CVE Numbering Authorities). Как вы уже указали в вашем примере с CVE-2023-0002, разные организации могут применять свои методы оценки, в результате чего CVSS может варьироваться для одной и той же уязвимости.

  5. Контекстуальные оценки: Напоминаю, что оценка Environmental Metrics зависит от контекста, в котором продукт используется в вашей организации, и может быть рассчитана только вами. Поэтому важно понимать, что CVSS — это инструмент, который вы можете адаптировать под свои нужды, основываясь на конкретных обстоятельствах.

В заключение, рекомендуется учитывать специфику работы NVD и его текущие ограничения. Если вам требуется детальная оценка для конкретных уязвимостей, рассмотрите возможность использования данных из других источников или разработки своих методов оценки, основанных на доступной информации о контексте применения.

Оцените материал
Добавить комментарий

Капча загружается...