Введение

Каталог проблем информационной безопасности

Система "Общие уязвимости и экспозиции" (CVE) предоставляет эталонный метод для общеизвестных уязвимостей и недостатков информационной безопасности. Поддержку системы осуществляет национальный исследовательский центр кибербезопасности США (FFRDC), управляемый корпорацией MITRE, при финансировании от отдела национальной кибербезопасности США в составе Министерства внутренней безопасности США. Система была официально представлена общественности в сентябре 1999 года. Протокол автоматизации контента безопасности (SCAP) использует CVE, а идентификаторы CVE указаны как в системе MITRE, так и в Национальной базе данных уязвимостей США.

Предыстория

Уязвимость — это слабость компьютерной программной системы, позволяющая получить несанкционированный доступ. Например, программное обеспечение для обработки кредитных карт не должно допускать чтения номеров кредитных карт, которые оно обрабатывает, однако злоумышленник может использовать уязвимость для получения доступа к этим номерам. Рассмотрение конкретной уязвимости по отдельности затруднено, поскольку существует множество программных продуктов, часто содержащих множество уязвимостей различных типов. Идентификаторы CVE присваивают каждой уязвимости уникальное формальное наименование, что позволяет установить единый язык описания.

Описание

Это стандартизированное текстовое описание проблемы. Одной из распространенных записей является: ** ЗАБРОНИРОВАН ** Этот кандидат забронирован организацией или частным лицом, которые будут использовать его при объявлении новой уязвимости. Когда информация об уязвимости будет опубликована, будут предоставлены подробности. Это означает, что номер забронирован Mitre для уязвимости или CNA забронировал этот номер. Например, когда CNA запрашивает блок номеров CVE заранее (например, Red Hat в настоящее время запрашивает CVE блоками по 500), номер CVE будет отмечен как забронированный, даже если сам CVE может быть назначен CNA не сразу. До тех пор, пока CVE не будет назначен, Mitre будет уведомлена об этом (то есть, истечет срок эмбарго и уязвимость станет публичной), и Mitre проведет исследование уязвимости и напишет ее описание, записи будут отображаться как "** ЗАБРОНИРОВАН **".

Дата создания записи

Это дата создания записи. Для CVE, присвоенных непосредственно Mitre, это дата создания записи CVE в Mitre. Для CVE, присвоенных CNA (например, Microsoft, Oracle, HP, Red Hat), это также дата создания записи в Mitre, а не дата, указанная CNA. Когда CNA запрашивает блок номеров CVE заранее (например, Red Hat в настоящее время запрашивает CVE блоками по 500), дата относится к моменту, когда CVE был назначен CNA.

Устаревшие поля

Следующие поля ранее использовались в записях CVE, но больше не используются. Фаза: стадия, на которой находится CVE (например, CAN, CVE). Голоса: ранее члены правления голосовали "за" или "против" принятия CAN и преобразования его в CVE. Комментарии: замечания по проблеме. Предложено: дата первого предложения по проблеме.

CVE SPLIT и MERGE

CVE стремится присваивать один CVE на каждую проблему безопасности; однако во многих случаях это привело бы к чрезмерно большому количеству CVE (например, когда в PHP-приложении обнаруживаются десятки уязвимостей межсайтового скриптинга из-за отсутствия использования htmlspecialchars или небезопасного создания файлов в /tmp). Для решения этой проблемы, руководства (которые могут изменяться) охватывают разделение и объединение проблем в отдельные номера CVE. В качестве общего правила, сначала следует рассмотреть возможность объединения проблем, затем проблемы следует разделять по типу уязвимости (например, переполнение буфера против переполнения стека), затем по затронутым версиям программного обеспечения (например, если одна проблема затрагивает версии от 1.3.4 до 2.5.4, а другая – от 1.3.4 до 2.5.8, они будут РАЗДЕЛЕНЫ), и затем по тому, кто сообщил об проблеме (например, если Алиса сообщает об одной проблеме, а Боб – о другой, проблемы будут РАЗДЕЛЕНЫ на отдельные номера CVE). Другой пример: Алиса сообщает об уязвимости создания файлов /tmp в версии 1.2.3 и более ранних версиях веб-браузера ExampleSoft; в дополнение к этой проблеме обнаружено несколько других проблем, связанных с созданием файлов /tmp. В некоторых случаях это может быть расценено как два сообщающих лица (и, следовательно, РАЗДЕЛИТЬ на два отдельных CVE), или, если Алиса работает в ExampleSoft, а внутренняя команда ExampleSoft обнаруживает остальные, их можно ОБЪЕДИНИТЬ в один CVE. И наоборот, проблемы могут быть объединены, например, если Боб обнаруживает 145 уязвимостей XSS в ExamplePlugin для ExampleFrameWork, независимо от затронутых версий и т.д., их можно объединить в один CVE.

Поиск идентификаторов CVE

В базе данных Mitre CVE можно выполнить поиск на странице CVE List Search, а в базе данных NVD CVE – на странице Search CVE and CCE Vulnerability Database.

Проблемы назначения CVE

Согласно разделу 7 Правил CNA, поставщик, получивший сообщение об уязвимости в системе безопасности, обладает полным усмотрением в отношении её обработки. Это может привести к конфликту интересов, поскольку поставщик может стремиться не устранять недостатки, изначально отказывая в присвоении CVE – решение, которое Mitre не может изменить. Проект "!CVE" (не CVE), анонсированный в 2023 году, призван собирать информацию об уязвимостях, в присвоении CVE которым было отказано поставщиками, при условии, что они признаны действительными экспертной группой проекта. Идентификаторы CVE присваивались и для ложных уязвимостей, и для проблем, не имеющих последствий для безопасности. В ответ на это ряд проектов с открытым исходным кодом сами подали заявки на получение статуса Авторитета присвоения номеров CVE (CNA) для своих проектов.