Что такое nvd cvrf назначение ресурсов
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
NVD – это американское правительственное хранилище данных уязвимостей, основанное на стандартах правительства США. Данные, содержащиеся в этом хранилище, позволяют автоматизировать управление уязвимостями, оценку безопасности и соответствие требованиям. NVD включает в себя базы данных контрольных списков безопасности, недостатки программного обеспечения безопасности, неправильные конфигурации, названия продуктов и показатели воздействия. [Источник 1]
 | |
| Available in | English |
|---|---|
| Created by | NIST |
| Website | https://nvd.nist.gov/ |
| Launched | 2000: 20 years ago |
| Current status | Active |
Содержание
История
Описание
NVD базируется на стандартах данных управления уязвимостями, представленных с использованием протокола автоматизации содержимого безопасности (SCAP). Включает в себя базы данных контрольных списков безопасности, связанных с безопасностью дефектов программного обеспечения, неправильных конфигураций, названий продуктов и метрик воздействия. Эти данные позволяют автоматизировать управление уязвимостями, измерение безопасности и соответствие требованиям. NVD поддерживает программу автоматизации информационной безопасности (ISAP).
Помимо предоставления списка распространенных уязвимостей и рисков (CVEs), NVD оценивает уязвимости с помощью общей системы оценки уязвимостей (CVSS), которая основана на наборе уравнений с использованием таких показателей, как сложность доступа и доступность средства правовой защиты.
Идентификаторы CVE имеют формат CVE-YYYY-NNNN, отражая в первых четырех цифрах год регистрации уязвимости и в последующих четырех-шести цифрах – уникальный в рамках этого года номер уязвимости. Для каждой из обнаруженных уязвимостей запись в базе содержит краткое описание типа и причин уязвимости, уязвимые версии ПО, оценку критичности уязвимости в соответствии со стандартом CVSS (Common Vulnerability Scoring System) и ссылки на внешние источники с информацией об уязвимости – чаще всего, таковыми выступают информационные бюллетени на сайтах производителей программного обеспечения или исследовательских организаций. [Источник 2]
В базе NVD доступны продвинутые функции поиска уязвимостей по ключевым словам, временным диапазонам создания \ модификации записи, компонентам CVSS-метрики и т. п. Кроме того, доступны скачивание всех записей базы данных в XML, а также получение информации об обновлениях базы в виде RSS-подписки и JSON data feed. Пример поиска уязвимости изображен на рисунке 1.
Преимуществом базы данных NVD является ежедневное обновление реестров известных уязвимостей. При обнаружении новой уязвимости производителем ПО или исследовательской организацией (или подтверждении наличия уязвимости вендором ПО в ответ на сообщение от частных исследователей или организаций, не входящих в CVE Numbering Authorities) под нее оперативно регистрируется новый идентификатор CVE и создается запись в базе, после чего происходит периодическое обновление информации.
Национальная база данных уязвимостей (NVD) предоставляет оценки CVSS почти для всех известных уязвимостей. NVD поддерживает как общую систему оценки уязвимостей (CVSS) v2.0, так и v3.X стандарты. NVD предоставляет CVSS базовые оценки, которые представляют собой врожденные характеристики каждой уязвимости. [Источник 3]
Рейтинг особого назначения. Как киберразведка и Big Data помогают оценивать критичность уязвимостей и приоритизировать их устранение
BIS Journal №3(38)/2020
Рейтинг особого назначения. Как киберразведка и Big Data помогают оценивать критичность уязвимостей и приоритизировать их устранение
В статье рассматривается подход компании Tenable к оценке критичности вновь публикуемых уязвимостей до публикации CVE и метрик CVSS, а также подходы к изменению критичности уязвимостей в зависимости от изменения ландшафта угроз и активности злоумышленников.
Исследования аналитиков компании Tenable, разработчика решений по управлению уязвимостями, показывают, что злоумышленники зачастую используют уязвимости сразу же после их публичного раскрытия. В случае угроз нулевого дня уязвимости используются ещё до того, как о них становится известно широкому кругу специалистов. В этой статье мы рассмотрим, как VPR, или рейтинг приоритетности уязвимости, уникальная разработка Tenable, может использоваться для приоритизации устранения уязвимостей ещё до их официальной публикации в реестре National Vulnerability Database (NVD).
От обнаружения уязвимости до публикации CVEID
NVD – это репозиторий уязвимостей, состоящий из множества наборов данных, одним из которых является Common Vulnerabilities and Exposures (общеизвестные уязвимости, CVE). NVD является одним из основных источников информации об уязвимостях для исследователей и специалистов по информационной безопасности. Информация об уязвимости в базе NVD включает её идентификатор CVEID, описание, сведения о затронутых платформах, метрики CVSS (v2 и v3) и другие данные. Обычно организация, сообщающая об уязвимости (так называемая CNA), присваивает ей идентификатор CVE ID сразу же при обнаружении. Затем CNA начинает подготовку описания уязвимости для публикации в NVD, в том числе результаты анализа влияния уязвимости на защищённость. Готовое описание CVE отправляется для публикации в базе NVD.
Что такое «период до NVD»
Процесс публикации CVE, описанный выше, может привести к задержке между первоначальным публичным раскрытием уязвимости и её публикацией в NVD. NVD подтверждает существование такой задержки и указывает на следующее: «Дата ‘Date Entry Created’ в записи CVE указывает на день, когда идентификатор CVEID был присвоен CVE Numbering Authority (CNA) или запись CVE была опубликована в реестре CVE. Эта дата не указывает на то, когда уязвимость была обнаружена, когда о ней сообщили вендору, когда она была публично обнародована или была обновлена в CVE».
В качестве примера «периода до NVD» рассмотрим уязвимость CVE-2019-17026. Изначально она была опубликована в Mozilla Security Advisory 8 января 2020 года, в NVD появилась 2 марта 2020 года и два дня спустя получила метрики CVSS.В данном примере «период до NVD» длился с 8 января до 2 марта и составил целых 55 дней.
Серьёзность проблемы «Периода до NVD»
Промежуток до NVD не является редкостью – 71 000 CVE были раскрыты в бюллетенях вендоров до того, как были опубликованы в NVD, что составляет половину всех CVE. В 2019 году у 5 300 CVE наблюдалось наличие периода до NVD.
Рисунок 1. Количество CVE с периодом до NVD с 2006 года
В то время как «период до NVD» для некоторых CVE составляет один день, что приемлемо, анализ, проведённый Tenable, показывает, что для многих уязвимостей задержка существенна. На рисунке 1 приведено количество CVE с периодом до NVD с 2006 года, с разбивкой по годам и длительности задержки в публикации.
Из этого графика можно сделать следующие выводы:
Активность злоумышленников до публикации в NVD
Очевидно, что злоумышленники не ждут публикации CVE для начала активной эксплуатации уязвимости. Сравнение данных киберразведки со списком CVE с «периодом до NVD» показывает, что в отношении 5 400 из 43 000 CVE (12%), опубликованных с 2019 по 2020 год, наблюдалась активность злоумышленников ещё до публикации данных в NVD.
На рисунке 2 отражено распределение этих CVE по году публикации и «окну угрозы» до публикации в NVD. Значительное количество этих CVE активно использовалось злоумышленниками в течение как минимум 30 дней до их публикации в NVD. Поэтому любые системы, затронутые этими уязвимостями, оставались подвержены реальным атакам до того, как информация об уязвимости стала доступна в NVD.
Рисунок 2. Количество CVE с активными угрозами до публикации в NVD. Разбивка по длительности «окна угрозы»
Как приоритизировать устранение уязвимостей до NVD с помощью рейтинга VPR
Устранение активно эксплуатируемых уязвимостей необходимо начинать как можно раньше. Как показало исследование, CVE из реестра NVD не являются наиболее актуальным источником информации для организации проактивного управления уязвимостями. Tenable решает эту проблему, получая информацию об уязвимостях напрямую из бюллетеней более чем от 100 крупнейших вендоров. Для полученных таким образом уязвимостей Tenable рассчитывает рейтинг приоритетности уязвимости, или VPR.
Расчёт VPR для уязвимостей в «периоде до NVD» не является тривиальной задачей. Поскольку многие CNA не предоставляют метрики CVSS для уязвимости на стадии до NVD, оценка влияния уязвимости на их основе не всегда возможна. Для решения этой проблемы VPR комбинирует технологии машинного обучения и обработки натурального языка, что позволяет предсказать метрики CVSS.
Начиная с августа 2019 года Tenable проводит оценку критичности уязвимостей до их публикации в NVD с помощью модели VPR. Из 12 073 опубликованных уязвимостей 1 592 включали «период до NVD». По итогам анализа рейтинг VPR показал гораздо большую эффективность в оценке новых уязвимостей.
Количество уязвимостей с «периодом до VPR» будет уменьшаться и далее по мере того, как Tenable будет получать данные об уязвимостях из всё большего числа бюллетеней вендоров.
Практический пример: CVE-2019-1702
В качестве примера в этой статье используется CVE-2019-17026. Вот как развивались события с этой уязвимостью:
Выводы
В этой статье мы показали, что злоумышленники зачастую используют уязвимости ещё до публикации соответствующих CVE в реестре NVD. Учитывая имеющиеся задержки в публикации, специалисты ИБ не должны использовать NVD как единственный источник информации об уязвимостях. Рейтинг VPR, разработанный Tenable, оперативно оценивает новые уязвимости – 84% новых уязвимостей оцениваются алгоритмом VPR в течение одного дня с момента публичного раскрытия, и 93% оцениваются в течение одной недели.
Меряем уязвимости: классификаторы и метрики компьютерных брешей
Содержание статьи
Ежедневно сотнями хакеров обнаруживаются тысячи уязвимостей, – после чего
взламывается куча сайтов, и детали багов выкладываются в багтрак на всеобщее
обозрение. Наверняка, ты читал подобные обзоры и замечал, что каждый баг
определенным образом классифицируется. Что собой представляет измерение
уязвимости, по каким критериям производится и на кой черт это вообще нужно
знать? Ответы ты найдешь в этой статье.
«Общепринятых систем по классификации брешей в нашей стране не существует» –
эту фразу я поставлю во главу угла. Продвинутым государством в этом плане стали
США. Там ведут несколько классификаций и активно используют их как в
образовательном процессе, так и в технологиях. Одной из самых известных систем
классификации является CVE, которая курируется компанией NCSD (National Cyber
Security Division) при одном из Министерств США. Рассмотрим эту систему
подробнее.
СVE (Common Vulnerabilities and Exposures)
Общий вид записи CVE выглядит примерно так:
CVE ID, Reference и Description.
Как появилась идея ее создания? Многие компании занимаются поиском брешей в
различных продуктах на основе политики (не)разглашения информации и
взаимодействия с производителями. Как-то, при исследовании одного из продуктов
десятью различными компаниями, одной и той же уязвимости были присвоены
абсолютно разные названия. После выявления сей вопиющей несправедливости было
принято соглашение о едином стандарте. Тогда же компания MITRE Corporation (mitre.org)
предложила решение, независимое от различных производителей средств поиска
уязвимостей, и взяла на себя ответственность за его воплощение. Нельзя сказать,
что после этого все баги стали упорядоченными. Разработчики продолжают активно
развивать самостоятельные начинания. Часть из них имеют платную подписку, и
антивирусные компании частенько обращаются к ним и добавляют соответствующие
сигнатуры в свои продукты. Стоимость такой годовой подписки составляет около
$5000 и выше.
Эта классификация присутствует исключительно на портале Securityfocus
(используется в ленте
securityfocus.com/vulnerabilities). Одна из отличительных особенностей BID –
совместимость с CVE. Условно говоря, найденная уязвимость в BID имеет ссылку на
номер CVE и, соответственно, равнозначна по информации. У системы есть ряд
описательных свойств – например, класс, возможность локального или удаленного
исполнения и т.п. В будущем ты убедишься, что этих параметров недостаточно для
полной характеристики, но, тем не менее, BID дает разработчику вполне наглядную
информацию о выявленной бреши.
OSVDB
Название расшифровывается примерно как: «Открытая база данных уязвимостей«.
Все просто и со вкусом. Классификация создана тремя некоммерческими
организациями. Двести волонтеров со всего мира активно участвуют в ее
наполнении. Среди прочего присутствуют: локация эксплуатации (сетевой
доступ/локальный доступ) и импакт (ущерб от уязвимости, воздействие на
какую-либо часть целевой информационной системы).
Secunia
Эта датская компания, лента уязвимостей которой доступна по адресу
secunia.com, уже заработала
себе достаточно славы. Не сказать, чтобы их портал внес какую-то особую,
добавочную классификацию, но именно он предлагает услуги платной подписки на
базу уязвимостей.
ISS X-Force
Базовая метрика
Нередко на солидных порталах по безопасности можно увидеть фразу – «CVSS Base
Score = 9.2″. Как это понимать? Параметр вычисляется по специальной формуле:
– плюс еще несколько. Все эти формулы можно найти по адресу
first.org/cvss.
Чтобы все стало понятнее, рассмотрим пример. Задан вектор уязвимости базовой
метрики вида: «AV:N/AC:L/Au:N/C:N/I:N/A:C». Все красуется на странице описания,
но ты абсолютно не можешь расшифровать эти иероглифы! Я тебе помогу. Итак,
расшифровываем по порядку.
Authentication: None – для эксплуатации не нужна авторизация.
Например, если бы это был сервис, который требует предварительной авторизации по
какой-нибудь мудреной схеме (смарт-карты, ключи, токены), то значение этого
вектора было другим.
Временная метрика
На все эти вопросы отвечают временные метрики. Рассмотрим некоторые их
векторы.
Параметры всех указанных векторов градируются вариантами «да/нет/возможно».
Контекстная метрика
Эти группы векторов отражают влияние на среду пользователя и изучают
поведение после эксплуатации уязвимости. Как правило, метрика используется в
качестве дополнения к базовой.
Использование классификаторов в сканерах
Отдельные классификации
Подчас в Сети можно заметить абсолютно самопальные классификации, вроде
Common Criteria Web Application Security Scoring (CCWAPSS) 1.1. Естественно,
большого веса такая система не имеет, потому что составляться она должна
реальными экспертами, которые понимают суть проблемы.
Так ли оно все важно?
Безусловно, к делу следует подходить без фанатизма. В первую очередь,
подобные системы классификации нацелены на экспертное звено либо специалистов,
которые заботятся о своевременном устранении брешей. Но, на мой взгляд, каждый
уважающий себя хакер должен знать и понимать общепринятые классификации
уязвимостей, разбираться в метриках и их векторах, чтобы четко и ясно
представлять формулу оценки всех недавно взломанных им ресурсов.
Истинные корни создания единой классификации багов и их контроля – это
Unix Known Problem List, Internal Sun Microsystems Bug List, каталоги
служб реагирования на компьютерные инциденты CERT ранних версий.
Список «междоусобной» совместимости систем классификаций:
CVE: ISS, BID, Secunia, SecurityTracker, OSVDB
BID: CVE, Bugtraq, ISS, Secunia, SecurityTracker, OSVDB
ISS: CVE, BID, Secunia, SecurityTracker, OSVDB
Secunia: CVE, OSVDB
SecurityTracker: CVE, OSVDB, Nessus
Nessus: CVE, BID, OSVDB
OSVDB: CVE, BID, Secunia, SecurityTracker, ISS, Nessus, Snort
Политика разглашения информации об уязвимости
Это соглашение имеет ряд нюансов. Например, хакер, обнаружив уязвимость, ищет
контакты, чтобы направить соответствующий запрос производителю. Если по
истечении пяти дней производитель отмалчивается, вводит в заблуждение своих
пользователей какими-то способами или некорректно вступает в диалог, то ему
отправляется повторное письмо. Выжидаются еще пять рабочих дней, после чего
баг-хантер вправе помещать описание о баге на собственном ресурсе или в
публичные багтраки. При этом в письме требуется оговорить и согласовать дату
публикации, чтобы производитель успел выпустить обновление или советы по защите
от эксплуатации. Важно отметить, что если стороннее третье лицо опубликовало
данные об эксплуатации найденной тобой уязвимости, то ты можешь смело постить ее
подробности без согласования с кем-либо. Вот такая арифметика.
Недокументированные уязвимости
В настоящее время эксперты мозгуют над включением вектора
«недокументированные уязвимости» в одну из метрик. Этот параметр имеет высокое
значение. В недалеком будущем мы сможем лицезреть строку «undercover
vulnerabilities» – вероятно, возможные к исполнению. На сайте, посвященном
развитию метрик информационной безопасности (securitymetrics.org/content/Wiki.jsp)
вывешено публичное обращение по поводу того, как и каким образом исчислять этот
параметр. Все желающие могут отправить туда свои предложения.
Полную версию статьи
читай в апрельском номере
Хакера!
🦟 Топ-7 крупных баз уязвимостей для поиска и отслеживания новых
Уязвимость определяется как слабость, которая позволяет злоумышленнику войти и нанести вред, это может быть недостатком в дизайне или неправильной конфигурации.
Чтобы использовать уязвимость, злоумышленник должен иметь соответствующий инструмент или технику, которые связаны с уязвимостью системы.
Ниже приведены основные источники для отслеживания новых уязвимостей.
National Vulnerability Database
Common Vulnerabilities And Exposures
CERT Vulnerability Notes
VulnDB – Vulnerability Intelligence
Безопасность на основе рисков предлагает VulnDB для всестороннего анализа уязвимостей через постоянно обновляемый поток данных.
На основе самой обширной и полной базы данных об уязвимостях наша VulnDB позволяет организациям запрашивать самую последнюю информацию об уязвимостях безопасности программного обеспечения.
Предложение подписки на фид данных VulnDB предоставляет организациям своевременную, точную и полную информацию об уязвимостях.
DISA IAVA Database And STIGS
SecurityTracker
SecurityTracker – сторонняя библиотека баз данных об уязвимостях, которая обновляется ежедневно.
«Сайт имеет тенденцию фокусироваться на уязвимостях, не связанных с ОС, но они, безусловно, включены в фид», – говорит Мори Хабер, вице-президент по технологиям в BeyondTrust. «Инфраструктура и Интернет вещей, как правило, делают главную страницу максимально доступной, и этот сайт является хорошим сторонним справочником для новых недостатков».
Open Vulnerability And Assessment Language
VAL® International по своему охвату и бесплатности открыт для публичного использования.
OVAL – это сообщество разработчиков средств информационной безопасности, призванное стандартизировать методы оценки состояния компьютеров в компьютерных систем и составления отчетов.
OVAL включает язык для кодирования деталей системы и ассортимент репозиториев контента, которые хранятся в сообществе.
Инструменты и сервисы, которые используют OVAL для трех этапов оценки системы – представления системной информации, выражения конкретных состояний машины и отчета о результатах оценки – предоставляют предприятиям точную, согласованную и действенную информацию, чтобы они могли повысить свою безопасность.
Использование OVAL также обеспечивает надежные и воспроизводимые метрики обеспечения информации и обеспечивает совместимость и автоматизацию среди инструментов и служб безопасности.
National Council of ISACs
Специализированные отраслевые центры обмена и анализа информации (ISAC) – это некоммерческие, управляемые членами организации, созданные владельцами критически важных объектов инфраструктуры и операторами для обмена информацией между правительством и отраслью.
Основной целью ISAC является быстрое распространение физических и киберугрозных предупреждений и другой важной информации среди организаций-членов.
Если ваш бизнес работает в критически важном секторе инфраструктуры, рассмотрите возможность стать членом ISAC.
Статьи по теме: «Информационная безопасность»
Общий обзор реестров и классификаций уязвимостей (CVE, OSVDB, NVD, Secunia)
Содержание:
Введение
Создание реестров и баз данных с информацией об обнаруженных уязвимостях потребовало унифицированного (по крайней мере в рамках одной базы данных) способа их идентификации и классификации. Каждой обнаруженной уязвимости требовалось присвоить идентификатор, дать ей емкое и краткое описание, определить для нее список уязвимого ПО и его версий. Кроме того, требовалось оценить степень критичности данной уязвимости по ряду различных критериев: простоте обнаружения злоумышленником уязвимого ПО, легкости эксплуатации уязвимости и требуемым для этого привилегиям, а также потенциальным последствиям эксплуатации уязвимости для компьютерной системы. Эта информация могла впоследствии дополняться рекомендациями по устранению уязвимости или предотвращению ее эксплуатации и статусом уязвимости (присутствует ли она в актуальной версии ПО или была закрыта соответствующими обновлениями и патчами).
Данные об индивидуальных уязвимостях в совокупности с организованным хранением, функциями поиска по базе и автоматического получения уведомлений о новых обнаруженных уязвимостях могут быть полезны широкому кругу специалистов в области информационной безопасности – мы более подробно вернемся к этому вопросу в заключении статьи.
Пока же отметим, что конец 90-х и начало 2000-х годов характеризовались появлением целого ряда каталогов и баз данных уязвимостей, поддержкой которых занимались самые разные, независимые друг от друга, организации. Среди них можно можно выделить несколько основных типов:
Появление и развитие независимых друг от друга баз данных и реестров уязвимостей породило известную проблему синхронизации информации между ними, как в части однозначной идентификации уязвимостей (ссылаются ли эти две записи в разных источниках на одну и ту же или на разные уязвимости), так и в классификации и оценке уязвимостей, вызванных различиями в системах скорринга.
Это создало дополнительную головную боль как для администраторов самих реестров уязвимостей, так и неудобство для их пользователей, и в конечном итоге привело к инициативе MITRE CVE, о которой будет рассказано в одном из последующих разделов.
Реестр уязвимостей БДУ ФСТЭК России
На территории Российской Федерации одной из основных организаций, отвечающих за обеспечение информационной безопасности в ключевых системах информационной инфраструктуры, включая компьютерные сети органов государственной власти и компьютерные сети критичных объектов инфраструктуры и предприятий, является Федеральная служба по техническому и экспортному контролю – ФСТЭК России.
К полномочиям данной организации, в числе прочего, относится лицензирование деятельности различных организаций по осуществлению мероприятий или оказанию услуг в области защиты государственной тайны, по созданию средств защиты информации, по технической защите конфиденциальной информации, а также по разработке и производству средств защиты конфиденциальной информации. Кроме того ФСТЭК России выдает сертификаты на различные средства защиты информации (антивирусные средства, системы обнаружения вторжений, межсетевые экраны и аналогичные средства обеспечения информационной безопасности), которые прошли специальные проверки и допускаются для использования в информационных системах органов государственной власти и организаций с государственным участием.
Для обеспечения деятельности по сертификации средств защиты информации и обнаружения уязвимостей программного обеспечения, ФСТЭК России с 2014 года поддерживает собственный реестр известных угроз информационной безопасности и уязвимостей программного обеспечения – Банк данных угроз безопасности информации (БДУ ФСТЭК России, http://www.bdu.fstec.ru/).
Данный реестр уязвимостей в первую очередь ориентирован на сбор и хранение информации об угрозах и уязвимостях ПО, используемого в государственных организациях Российской Федерации, включая информационные системы и системы управления критичными производственными процессами. Пополняется реестр ФСТЭК России путем мониторинга общедоступных источников информации – информационных бюллетеней российских и иностранных компаний, производящих ПО, а также реестров и информационных бюллетеней исследовательских организаций и компаний, предоставляющих услуги в области информационной безопасности.
На конец августа 2018 года в базе данных БДУ ФСТЭК России содержалось чуть менее 19 тысяч записей, и реестр продолжает активно пополняться по мере публикации информации об уязвимостях в других общедоступных базах данных. Так, за последние два года в базу БДУ ФСТЭК России было добавлено порядка 4 тысяч новых записей.
Все хранящиеся в БДУ ФСТЭК России записи имеют единообразный формат и включают: текстовое описание уязвимости, дату обнаружения уязвимости, названия, версии и производителей уязвимого ПО, информацию о типе ошибки, классе уязвимости и текущем ее статусе (потенциально возможная либо подтвержденная производителями ПО или независимыми исследователями уязвимость, устранена ли уязвимость в новых версиях ПО). Также записи содержат оценку критичности уязвимости и сопутствующий вектор CVSS, пометку о наличии известных готовых сценариев эксплуатации уязвимости и возможного результата эксплуатации уязвимости, указание уязвимых аппаратных платформ или операционных систем, список возможных методов противодействия уязвимости и ссылки на источники дополнительной информации по уязвимости (включая идентификаторы данной уязвимости в иных реестрах и базах данных).
Следует отметить, что записи в базе данных БДУ ФСТЭК России предоставляют более подробную информацию о различных аспектах, связанных с уязвимостью, чем иностранные реестры уязвимостей CVE List и NVD, предоставляемые американскими некоммерческими и государственными организациями. Кроме того, пользовательский интерфейс для выборки из базы БДУ ФСТЭК России отличается большей гибкостью настроек поиска и фильтрации результатов в сравнении с интерфейсами указанных иностранных баз данных.
Все содержимое реестра БДУ ФСТЭК России предоставляется для скачивания в форматах XLSX и XML, что обеспечивает получение информации как виде, удобном для обработки человеком (посредством популярных офисных приложений семейства MS Excel), так и в машиночитаемом варианте для различных автоматизированных средств (например, сканеров безопасности и систем обнаружения атак). Для подписки на обновления базы данных доступны каналы RSS и Atom.
Отметим, что некоммерческое использование и распространение материалов из БДУ ФСТЭК России доступно без ограничений, а применение полученных данных для различных коммерческих систем и продуктов возможно при согласовании с федеральной службой.
Интересно, что на текущий момент реестр БДУ ФСТЭК России содержит порядка полутора сотен записей, не имеющих присвоенного им идентификатора CVE и, тем самым, не представленных в американских базах CVE List и NVD. Преимущественно данные записи описывают уязвимости ПО, созданного российскими компаниями, такими как, 1С или «Лаборатория Касперского» (но есть и исключения из этого правила).
Данное обстоятельство, а также удобный для человеческого восприятия формат и подробное описание различных аспектов уязвимости (статус, наличие эксплойтов и т.п.) являются сильными сторонами реестра ФСТЭК России, особенно для специалистов, работающих с ПО российского происхождения.
Кроме того, поскольку реестр БДУ ФСТЭК России ориентирован на сбор и хранение информации об уязвимостях ПО, используемого в российских организациях и компаниях (включая компании с государственным участием и бюджетные организации), отечественным производителям ПО и системным администраторам российских организаций разумно ориентироваться именно на данный реестр уязвимостей в процессах оценки информационной безопасности создаваемых программных продуктов и поддержания защищенного состояния своих компьютерных сетей.
К возможным недостаткам БДУ ФСТЭК России можно отнести меньшее общее количество покрытых реестром уязвимостей (в сравнении как с базами CVE List и NVD, так и с базами данных уязвимостей, созданных коммерческими компаниями), а также отсутствие какой-либо агрегации отдельных записей (которая характерна для такой базы данных, как Vulnerability Notes Database).
С другой стороны, следует понимать, что иностранные реестры известных уязвимостей зачастую содержат большое количество записей, мало полезных для практического применения, в частности: информацию об очень старых (более 15 лет) уязвимостях устаревшего ПО и информацию об уязвимостях редкого и мало распространенного (как в России, так и в мире в целом) программного обеспечения.
MITRE CVE и база данных NVD
Стандарт Common Vulnerabilities and Exposures (CVE, http://cve.mitre.org), разработанный американской некоммерческой исследовательской корпорацией MITRE Corporation в 1999 году, де-факто является на сегодняшний день основным стандартом в области унифицированного именования и регистрации обнаруженных уязвимостей программного обеспечения. Данный стандарт непосредственно определяет как формат идентификаторов и содержимого записей об отдельных обнаруженных уязвимостях, так и процесс резервирования идентификаторов для новых обнаруженных уязвимостей и пополнения соответствующих баз данных.
Уже в 2000 году инициатива MITRE по созданию единого стандарта для регистрации и идентификации обнаруженных уязвимостей ПО получила широкую поддержку со стороны ведущих производителей программного обеспечения и исследовательских организаций в области информационной безопасности. В настоящее время (по данным на март 2018 года) поддержкой и администрированием реестра уязвимостей CVE занимается группа из 84 организаций по всему миру, в число которых входят ведущие производители программного обеспечения, телекоммуникационного оборудования и интернет-сервисов, такие как Apple, Cisco, Facebook, Google, IBM, Intel, Microsoft, Oracle и ряд компаний, специализирующихся в области информационной безопасности, например, F5 Networks, McAfee, Symantec, «Лаборатория Касперского» и др.
В рамках поддержки проекта MITRE CVE основными задачами этих организаций (называемых CVE Numbering Authorities, CNAs), являются:
На текущий день базы уязвимостей MITRE CVE List и NVD содержат порядка 98 тысяч записей об отдельных уязвимостях, обнаруженных за период с 1999 года по настоящее время. При этом, хотя сами базы данных различаются на уровне функциональных возможностей, предоставляемых пользователям, сами списки записей об уязвимостях фактически идентичны друг другу. Формально CVE List выступает изначальным источником записей для базы данных NVD, а специалисты, отвечающие за поддержку базы NVD, производят уточненный анализ и сбор доступной информации по уязвимостям, зарегистрированным в CVE List (например, собирают ссылки на сторонние источники информации об уязвимости и мерах по ее устранению или предотвращению эксплуатации).
Идентификаторы CVE имеют формат CVE-YYYY-NNNN, отражая в первых четырех цифрах год регистрации уязвимости и в последующих четырех-шести цифрах – уникальный в рамках этого года номер уязвимости.
Для каждой из обнаруженных уязвимостей запись в базе содержит краткое описание типа и причин уязвимости, уязвимые версии ПО, оценку критичности уязвимости в соответствии со стандартом CVSS (Common Vulnerability Scoring System) и ссылки на внешние источники с информацией об уязвимости – чаще всего, таковыми выступают информационные бюллетени на сайтах производителей программного обеспечения или исследовательских организаций.
В плане пользовательского функционала в CVE List поддерживаются возможности простейшего поиска среди записей (по ключевым словам и CVE-идентификаторам) и скачивания архивов записей за любой выбранный год в различных форматах (HTML, XML, CVRF, CSV или Plain Text). Также возможно автоматическое получение обновлений в машиночитаемом виде через специальный data feed CVE Change Log (он позволяет как отслеживать появление новых идентификаторов CVE, так и изменения в записях для уже существующих).
Для базы NVD в свою очередь доступны продвинутые функции поиска уязвимостей по ключевым словам, временным диапазонам создания \ модификации записи, компонентам CVSS-метрики и т. п. Кроме того, доступны скачивание всех записей базы данных в XML, а также получение информации об обновлениях базы в виде RSS-подписки и JSON data feed.
Преимуществом баз данных MITRE CVE List и NVD является ежедневное обновление реестров известных уязвимостей. При обнаружении новой уязвимости производителем ПО или исследовательской организацией (или подтверждении наличия уязвимости вендором ПО в ответ на сообщение от частных исследователей или организаций, не входящих в CVE Numbering Authorities) под нее оперативно регистрируется новый идентификатор CVE и создается запись в базе, после чего происходит периодическое обновление информации.
В среднем, за сутки в базах CVE List и NVD регистрируется 13 новых записей об обнаруженных уязвимостях. При этом уникальность регистрируемого идентификатора обеспечивается иерархической структурой CNAs (как показано на рисунке), в которой корневые организации (Root CNA) делят и распределяют между подчиненными организациями (Sub CNA) диапазон доступных в этом году идентификаторов CVE. Каждая из соответствующих подчиненных организаций в свою очередь распоряжается предоставленным диапазоном идентификаторов для создания записей об обнаруженных уязвимостях в своих собственных продуктах, либо обнаруженных уязвимостях в продуктах третьей стороны, при условии, что она не является участником CVE Numbering Authorities.
Следует отметить, что в настоящее время среди участников CVE Numbering Authorities лишь две организации имеют статус корневых CNAs, находящихся под непосредственным администрированием Primary CNA (самой MITRE Corporation).
Сильной стороной самого стандарта CVE является его повсеместная поддержка в современных программных продуктах и сервисах, направленных на обеспечение информационной безопасности. Далеко не полный перечень видов этих продуктов и сервисов включает: базы данных и реестры уязвимостей (собственные записи в этих базах содержат в качестве внешних ссылок и CVE-идентификаторы уязвимостей, если для уязвимости вообще был присвоен CVE-идентификатор), системы обнаружения \ предотвращения атак, антивирусные средства (CVE-идентификаторы в сигнатурных правилах), сканеры безопасности и средства мониторинга и др.
Некоторым естественным ограничением баз данных CVE List и NVD является отсутствие в записях об уязвимостях какой-либо информации о точном месте локализации уязвимости в коде уязвимого ПО и возможных векторах атак, посредством которых возможна эксплуатация данной уязвимости. В некоторых случаях данная информация может быть найдена по ссылкам на внешние ресурсы, однако в большинстве случаев производители и вендоры ПО избегают публикации данной информации, причем не только на период разработки и внедрения патчей, закрывающих обнаруженную уязвимость, но и в последующем. Частично такая политика объясняется нежеланием участников CVE Numbering Authorities предоставлять подобную информацию потенциальным злоумышленникам, особенно в свете того, что уязвимое программное обеспечение может быть широко распространено по всему миру, а эксплуатирующие его организации часто не имеют возможностей или не придают должного значения своевременной установке обновлений.
OSVDB
Стандарту CVE и основанным на нем базам данных уязвимостей ПО удалось пройти проверку временем и достичь основных целей, заявленных в начале проекта. Иным же из подобных инициатив в области информационной безопасности, например, базе данных уязвимостей OSVDB (Open Sourced Vulnerability Database) – повезло гораздо меньше.
База OSVDB была запущена в 2004 году, по результатам конференций по компьютерной безопасности Blackhat и DEF CON и строилась вокруг ключевой идеи: организовать такой реестр уязвимостей, который содержал бы полную и подробную информацию обо всех обнаруженных уязвимостях, и поддержка которого не была бы аффилирована ни с одним из производителей программного обеспечения.
Одним из косвенных результатов деятельности коллектива исследователей, причастных к развитию базы OSVDB, стало основание в 2005 году организации Open Security Foundation. Ее специалисты занимались самостоятельным поиском уязвимостей и агрегацией публично доступной из различных источников информации об обнаруженных уязвимостях или сценариях их эксплуатации. Новые уязвимости специалисты регистрировали в базе, производили их классификацию и валидацию. При этом уточнялись списки уязвимого ПО и сведения о возможных способах устранения уязвимостей. В таком виде каждая запись, снабженная соответствующими ссылками на доступные источники информации, оставалась в базе данных.
Авторы OSVDB приняли решение о закрытии базы данных, которое произошло в 2016 году. В настоящее время продолжается эпизодическая поддержка блога проекта https://blog.osvdb.org, а сотрудничество организации Open Security Foundation и коммерческой компании Risk Based Security привело к созданию каталога уязвимостей VulnDB, как коммерческой реинкарнации OSVDB.
По состоянию на 2018 год доступная по платной подписке в виде сервиса база VulnDB (https://vulndb.cyberriskanalytics.com/) содержит информацию о 176 тыс. обнаруженных уязвимостях (включая почти 60 тыс. записей об уязвимостях, отсутствующих в базах CVE List и NVD), а поддерживающие базу специалисты отслеживают появление новых уязвимостей для 19 тыс. современных программных продуктов и 2 тыс. популярных библиотечных компонентов. Одним из возможных предназначений предлагаемого сервиса может быть риск-менеджмент и оценка уровня защищенности компьютерных сетей организаций.
Secunia Advisory and Vulnerability Database
Сходные услуги в области информационной безопасности предоставляются датской компанией Secunia Research, которая специализируется на исследованиях в области компьютерной и сетевой безопасности и в числе прочих сервисов предоставляет доступ к базе уязвимостей Secunia Advisory and Vulnerability Database.
Secunia Advisory and Vulnerability Database (https://secuniaresearch.flexerasoftware.com/community/advisories/) – это база данных с информационными бюллетенями (Secunia Advisories), содержащими сведения об обнаруженных угрозах и уязвимостях ПО. Бюллетени формируются на основе собственных исследований специалистов Secunia Research и агрегации информации об уязвимостях, полученных из иных публичных источников.
Как и в случае с базой VulnDB, бюллетени в базе данных Secunia зачастую публикуются еще до того, как соответствующие записи появляются в базе CVE List, и уже впоследствии размечаются ссылками на соответствующие CVE-идентификаторы. При этом нередки ситуации, когда никто из CVE Numbering Authorities так и не берется за регистрацию обнаруженной уязвимости, в результате чего соответствующая запись из базы Secunia Research так и остается без выделенного CVE-идентификатора и, соответственно, не попадает в базы CVE List и NVD.
По своей структуре записи в базе Secunia сходны с содержимым баз CVE List и NVD и содержат дату регистрации уязвимости, тип и краткую классификацию уязвимости, критичность уязвимости (описывается с помощью перечислимого типа Secunia Research Criticality Rating вместо скалярной оценки по стандарту CVSS), списки уязвимого ПО и его версий, ссылки на внешние источники информации и рекомендации по устранению угрозы (как правило, установку патчей от производителя ПО или апгрейд уязвимого ПО до безопасной версии – в этом случае бюллетень содержит упоминание минимального номера безопасной версии).
Характерно, что в бюллетенях Secunia Advisories принято агрегировать в одной записи информацию о множестве отдельных уязвимостей, одновременно обнаруженных в одном и том же программном обеспечении. Это означает, что одной записи из базы данных Secunia может соответствовать множество различных CVE-идентификаторов. В настоящее время база данных Secunia Research содержит приблизительно 75 тысяч записей об уязвимостях, обнаруженных начиная с 2003 года.
Бесплатный доступ к Secunia Advisories производится только на условиях некоммерческого использования предоставленной информации и только в формате html (по всей видимости, это делается для того, чтобы затруднить автоматизированное извлечение информации из базы).
Для коммерческого использования доступ к базе данных от Secunia Research предоставляется посредством специализированного средства Software Vulnerability Manager и соответствующей подписки на сервис компании Flexera, которой и принадлежит с 2015 года Secunia Research.
VND от CERT/CC
Примером иного подхода к организации базы уязвимостей является база VND (Vulnerability Notes Database, https://www.kb.cert.org/vuls), поддерживаемая центром реагирования CERT/CC при Институте программной инженерии в университете Карнеги-Меллона, США.
Каждая запись в базе VND агрегирует информацию о множестве сходных уязвимостей для какого-либо конкретного ПО, ссылаясь на множество соответствующих CVE идентификаторов. Данная агрегация является характерным отличием базы VND от баз CVE List и NVD, позволяя проверить целое множество уязвимостей сходной природы в конкретном уязвимом ПО или его компоненте.
Кроме этого, записи в базе VND зачастую содержат подробное и детальное руководство по устранению уязвимостей и \ или предотвращению их эксплуатации злоумышленником, а также обзор текущей ситуации с наличием или успешным закрытием обнаруженной уязвимости различными вендорами (в случае, когда уязвимым оказывается библиотечный компонент, используемый несколькими производителями ПО).
Данные характеристики базы VND относятся к числу ее сильных сторон и дополняются разрешением на бесплатное использование всех материалов базы для любых целей и возможностью полного скачивания всех записей базы в формате JSON с помощью специального бесплатно предоставляемого программного обеспечения.
Недостатками базы VND являются редкие обновления (единицы раз в месяц) и слабый охват всех существующих уязвимостей (в том числе даже зарегистрированных в CVE List), что существенно ограничивают полезность данного каталога уязвимостей для оперативного реагирования на новые уязвимости ПО. В частности, в настоящий момент в базе зарегистрировано лишь около 3,5 тысяч записей, и по состоянию на март 2018 года было опубликовано лишь пять новых записей.
Exploit Database
Альтернативным подходом к каталогизации информации об обнаруженных уязвимостях ПО является регистрация не самих уязвимостей, а сценариев их эксплуатации (эксплойтов, exploits) или примеров эксплуатации уязвимости (Proof of Concept). Примером реализации такого подхода является база Exploit Database (https://www.exploit-db.com/), сформированная организацией Offensive Security Team, специализирующейся на проведении тренингов в области информационной безопасности и тестирования компьютерных систем на проникновение.
База Exploit Database на настоящий момент содержит порядка 39 тысяч записей, разбитых на различные категории (эксплойты для веб-приложений, удаленной и локальной эксплуатации уязвимостей, примеры атак Denial of Service и исполнимые фрагменты кода shellcode для различных уязвимостей переполнения стека или доступа к памяти). Данные записи покрывают множество уязвимостей, обнаруженных с 2000 года по настоящее время.
Типичная запись в базе Exploit Database содержит краткое описание уязвимости, указание уязвимых версий приложений или их компонентов, уязвимую программную платформу (операционную систему или фреймворк веб-приложения), CVE-идентификатор, присвоенный данной уязвимости (при его наличии), и ссылки на сторонние источники информации об уязвимости. Однако самая важная и содержательная часть записи – это детальное описание самих причин возникновения уязвимости, места локализации уязвимости в коде (с непосредственной демонстрацией уязвимого фрагмента кода, если код приложения публично доступен) и описание работоспособных сценариев эксплуатации уязвимостей или сценариев Proof of Concept (PoC).
Кроме этого, поддерживается архив уязвимых версий приложений для того, чтобы исследователи, использующие базу Exploit Database, имели возможность воспроизвести наличие уязвимости и проверить работоспособность нацеленного на нее эксплойта.
Наибольшую пользу подобные базы с эксплойтами и PoC-сценариями могут принести специалистам, занятым тестированием компьютерных сетей на проникновение, в составе инструментальных средств проверки наличия уязвимостей в исследуемых сетях.
Также доступные в базе эксплойты могут быть использованы в качестве дидактического материала для начинающих исследователей и специалистов в области информационной безопасности в рамках образовательного процесса или повышения квалификации.
Наконец, подобная база с набором работоспособных сценариев эксплуатации уязвимостей для веб-приложений и удаленной эскалации привилегий могла бы быть полезна и в качестве источника информации для компаний, занятых разработкой сигнатурных систем обнаружения атак и подобных средств мониторинга трафика. Однако в этом случае использование информации может быть затруднено в силу отсутствия в Exploit Database интерфейса для получения обновлений базы, возможностей для скачивания рхива всех записей и, в некоторых случаях, соглашениями об использовании предоставляемых материалов.
Агрегаторы информации об уязвимостях
Разнообразие различных реестров и баз данных уязвимостей (их общее число в несколько раз больше, чем было рассмотрено в статье) вызывает у специалистов в области информационной безопасности (в первую очередь, разработчиков средств защиты, специалистов по тестированию на проникновение и исследователей, ищущих и изучающих новые уязвимости ПО) естественное желание использовать различного рода агрегаторы информации, которые бы обеспечивали автоматизированный сбор доступной информации об уязвимостях и дополнительные функции поиска и фильтрации интересующей информации.
Подобного рода агрегаторы информации об уязвимостях существуют и представлены различного рода сервисами, начиная от специализированного агрегатора CVE-релевантной информации и до агрегатора с интерфейсом полноценной поисковой машины, адаптированной под предметную область.
Примером сервисов первого типа является CVEDetails (https://www.cvedetails.com/) – простой специализированный агрегатор информации об уязвимостях, который собирает всю доступную из публичных реестров и баз данных уязвимостей информацию по конкретному CVE-идентификатору и объединяет ее в единую запись.
Фактическим функционалом данного сервиса является автоматизация поиска всей доступной информации по CVE-идентификатору с дополнительными функциями поиска по вендорам, типам уязвимостей, оценке критичности по метрикам CVSS и т. п. Также реализованы сбор и хранение различного рода статистики по уязвимостям, например, распределение уязвимостей по степени критичности (согласно метрике CVSS), распределение уязвимостей по вендорам ПО и др. – с удобным переходам к списку уязвимостей, удовлетворяющих выбранному критерию.
Что касается интерфейса, то CVEDetails в целом ориентирован на компактное и удобное для восприятия человеком табличное представление данных, а для автоматизированных систем поддерживает формирование RSS-подписки (в формате JSON) для получения обновленных данных об уязвимостях выбранных категорий, например, для всех новых уязвимостей класса SQL-инъекций или XSS.
Интересным примером другого подхода является Vulners – разработанный российскими специалистами и весьма популярный среди экспертов в области информационной безопасности сервис с собственной базой данных, предназначенный для поиска информации по самым разным материалам в области информационной безопасности (включая публикации на тематических ресурсах, бюллетени вендоров, информацию о мероприятиях Bug Hunting и специалистах, непосредственно обнаруживших уязвимости и др).
Фактически Vulners представляет собой поисковый движок с собственной базой данных, адаптированный под предметную область. Таким образом он покрывает гораздо более широкое множество сущностей, чем простые агрегаторы уязвимостей.
В настоящее время база данных Vulners агрегировала в себя порядка 870 тысяч записей об уязвимостях и примерно 170 тысяч записей об известных эксплойтах. По данному массиву информации возможны поиск по ключевым словам и фильтрация результатов как по источнику информации (организации, опубликовавшей запись об уязвимости), так и по дате публикации записи, CVSS-оценке критичности уязвимости и другим подобным параметрам.
Следует отметить, что Vulners не предоставляет некой единой сводки информации по конкретной уязвимости с заданным CVE-идентификатором (или иным внутренним идентификатором одного из альтернативных реестров), а возвращает множество записей, релевантных поисковому запросу в стиле классического поискового движка. При этом наличие фильтрации результатов по организации-источнику информации (например, type:cvelist) позволяет производить выборку записей только из указанной базы данных.
Все результаты поисковой выдачи из базы данных Vulners могут быть получены не только в удобном для человека, но и в машиночитаемом виде (в формате JSON) через соответствующий API поискового запроса.
Заключение
Базы данных и реестры уязвимостей полезны широкому кругу специалистов в области информационной безопасности. Сетевые администраторы или сотрудники, ответственные за безопасность компьютерных систем организации, могут своевременно узнать из баз и реестров о появлении новых угроз для защищаемых ими систем, определить приоритетные меры реагирования на эти угрозы (исходя из оценки критичности и распространенности в организации уязвимого ПО).
При этом для специалистов важны оперативность обновления баз данных уязвимостей, удобство получения этих обновлений и степень покрытия выбранным реестром уязвимостей как основных видов ПО защищаемой компьютерной системы, так и всего множества обнаруживаемых для этого ПО уязвимостей. Также значимыми характеристиками будут наличие рекомендаций по устранению уязвимостей и возможность определения потенциальных векторов атак на защищаемые компьютерные системы.
Специалистам в области информационной безопасности, сетевым администраторам и производителям ПО (как системного и прикладного ПО, так и программных продуктов защиты информации), работающим в интересах российских организаций и компаний Российской Федерации с государственным участием, рекомендуется периодический мониторинг реестра уязвимостей БДУ ФСТЭК России, как содержащего наиболее релевантную информацию по актуальным уязвимостям для компьютерных систем и программного обеспечения, применяемого именно в российских организациях.
Мониторинг реестра уязвимостей БДУ ФСТЭК России, с учетом его ориентированности на популярное и типичное именно для российских организаций ПО, а также регулярное обновление реестра и удобный интерфейс для поиска и выборки данных позволит разработчикам ПО, системным администраторам организаций и операторам средств защиты оставаться в курсе наиболее важных и критичных новостей в области информационной безопасности своей организации.
Дополнительным способом поддержания ситуационной осведомленности для данных специалистов является использование поисковых сервисов и агрегаторов информации об уязвимостях, подобных Vulners.
Коммерческие реестры уязвимостей (такие как VulnDB, Secunia Advisory and Vulnerability Database и их иные аналоги) в сочетании с поставляемыми вместе с ними проприетарными средствами мониторинга событий безопасности могли бы оказаться полезными крупным компаниям и организациям, бюджет которых позволяет приобретение подобных дорогостоящих решений.
Однако для большинства малых и средних организаций стоимость подобных средств может быть неоправданно высока, из-за чего их специалистам по информационной безопасности придется пользоваться информацией из общедоступных источников, таких как CVE List, NVD, Vulnerability Notes Database и их аналогов.
Публичные источники информации об уязвимостях, с другой стороны, либо не могут похвастать оперативностью информирования об обнаруженных уязвимостях (типичный пример, Vulnerability Notes Database), либо зачастую не предоставляют развернутой информации о векторах возможных атак на уязвимое ПО и детальных рекомендаций по устранению уязвимостей. А это снижает практическую полезность данных источников информации для оперативного реагирования на новые угрозы.
Специалисты, занятые аудитом защищенности компьютерных систем, благодаря мониторингу баз данных уязвимостей, получают возможность проверить наличие актуальных уязвимостей в тестируемой ими сети или убедиться в их отсутствии, руководствуясь структурированным списком известных уязвимостей и составом ПО в тестируемой сети. Как правило специалисты такого рода менее заинтересованы в оперативности обновления выбранного реестра уязвимостей, зато для них критичны охват и качество покрытия выбранной базой данных состава ПО тестируемой сети и всего множества потенциальных уязвимостей. В этой связи обязательный к использованию список для аудита включает официально признанные реестры уязвимостей, такие как БДУ ФСТЭК России и MITRE CVE List. А при тестировании на проникновение дополнительную пользу могут принести реестры известных Proof of Concept сценариев эксплуатации уязвимостей и готовых эксплойтов.
Разработчики средств и систем защиты компьютерных сетей (сканеров безопасности, систем обнаружения и предотвращения атак, межсетевых экранов, антивирусных средств и др.) получают благодаря мониторингу различных баз данных уязвимостей ценную информацию о новых возможных атаках на компьютерные системы. Эта информация включает сопроводительные данные, полезные для формирования отчетов оператору системы защиты. На основе этой информации можно определить степень критичности атаки, что важно и в момент принятия решения о реагировании, и на стадии формирования отчета. В некоторых случаях пользователям доступна и готовая информация о векторе атаки, позволяющая предположить как будет выглядеть атакующий трафик, какое приложение будет целью атаки и т. п.
Вместе с тем на использование данных из публичных или коммерческих реестров уязвимостей накладываются естественные правовые ограничения, препятствующие применению информации из них в соответствующих коммерческих продуктах. Таким образом, регулярное отслеживание обновлений в базах данных уязвимостей выступает для разработчиков средств мониторинга и защиты в первую очередь отправной точкой для начала собственных исследований обнаруженной уязвимости, а не готовым ресурсом для развития своих проектов.
Также исследователи, занятые поисками уязвимостей в ПО, и сами производители программного обеспечения, получают благодаря реестрам возможность оценить актуальное состояние дел для конкретного приложения и понять, какие уязвимости для этого приложения уже известны в настоящий момент, а какая из обнаруженных уязвимостей является новой и требует внимательного анализа и исправления.
В заключение отметим, что всем перечисленным категориям специалистов не следует ограничиваться использованием лишь одного из доступных реестра и одной базы данных уязвимостей. Разумно подписаться на регулярные обновления из реестра уязвимостей с самой высокой оперативностью для отслеживания наиболее критичных или релевантных для организации уязвимостей, а при обнаружении таковых рекомендуется детальное ознакомление с информацией, доступной в других базах данных, причем, на этом этапе полезными могут оказаться агрегаторы информации.