Yakushenko

Лекции/1.3.500_Банк_данных_угроз_от_НСД/yakushenko_1.md

@@ -0,0 +1,112 @@
+# Банк данных угроз безопасности информации
+
+## Что случилось с NVD и почему опираться на один источник уязвимостей больше нельзя
+
+Управление уязвимостями начинается с информации: о каких уязвимостях вообще нужно знать. Но за последние пару лет сама экосистема источников пережила настоящее землетрясение. То, что раньше казалось вечным и незыблемым (единая база CVE, заботливо обогащенная американским NVD), внезапно зашаталось. Разберем, откуда брать данные сегодня и почему опираться на один источник стало рискованно.
+Основные источники данных об уязвимостях для РФ рынка
+
+БДУ ФСТЭК (bdu.fstec.ru) - российский национальный банк данных угроз.
+
+Преимущества:
+
+- ориентированность на российский рынок и законодательство
+- официальные данные, признанные на государственном уровне
+- детальные описания и рекомендации по устранению
+- покрытие отечественного ПО, которого может не быть в западных базах
+
+На август 2026 года в БДУ более 92 тысяч уязвимостей [1]. Идентификаторы вида BDU:2024-01398. По уязвимостям здесь можно найти описание, последствия и рекомендации. Отдельно ФСТЭК ведет раздел наиболее опасных (трендовых) уязвимостей - российский аналог каталога эксплуатируемых уязвимостей.
+
+NVD (nvd.nist.gov) - американская национальная база данных об уязвимостях, которую ведет NIST.
+
+Преимущества: широкий охват, детальные описания, привязка к CVSS и CPE. Но именно с NVD случилась главная драма последних лет - о ней ниже.
+
+База CVE (cve.org), поддерживаемая MITRE, - международный реестр идентификаторов уязвимостей. CVE - это стандарт идентификации: один и тот же номер CVE-2021-44228 (Log4Shell) узнают по всему миру. На CVE опираются и NVD, и БДУ, и продукты вендоров.
+
+Сайты вендоров. Бюллетени безопасности производителей ПО: Microsoft, Cisco, ГК “Астра”, Positive Technologies и другие. Часто это самый ранний и самый точный источник: вендор знает о своем продукте больше всех. Классический пример - бюллетень Microsoft MS17-010 об уязвимости в SMB (EternalBlue), которую потом использовал WannaCry.
+
+Внутренние источники. Собственные исследователи компаний-вендоров находят уязвимости, в том числе в чужих и собственных продуктах, и вносят их в свои базы.
+
+Это новый раздел, которого не было и не могло быть в первых редакциях книги. Но без него картина была бы неполной.
+
+Кризис NVD (с февраля 2024). Американский NVD, на который десятилетиями опирался весь мир, в феврале 2024 года фактически прекратил массовое обогащение CVE: перестал вовремя добавлять оценки CVSS, привязки к продуктам (CPE), классификацию слабостей. Причина банальна - поток уязвимостей вырос на сотни процентов, а ресурсов аналитиков больше не стало. К концу 2025 года накопился backlog более чем в 27 тысяч необработанных уязвимостей - эту цифру подтвердил и аудит генерального инспектора Минторга США в мае 2026-го, добавив прогноз: более 60 тысяч новых уязвимостей за весь 2026 год. С апреля 2026 года NIST официально перешел на риск-ориентированный подход: в первую очередь обрабатываются только уязвимости из каталога эксплуатируемых и критически важное ПО (как похоже на то, что происходит с уязвимостями в инфраструктурах компаний, да?)) [2]. Проще говоря, привычная “бесплатная” аналитика NVD больше не покрывает все.
+
+Едва не остановившаяся программа CVE (апрель 2025). В апреле 2025 года истек контракт MITRE на ведение программы CVE, и на сутки мир оказался на грани того, что новые CVE перестанут выпускаться вообще. Контракт продлили в последний момент - на 11 месяцев, до марта 2026 года, - а энтузиасты создали независимую CVE Foundation на случай повторения [3]. Это был холодный душ: оказалось, что фундамент всей мировой кибербезопасности держится на одном ежегодном госконтракте. К началу 2026 года ситуацию частично стабилизировали: CISA перевела финансирование CVE-программы в статус базовой статьи бюджета вместо разовой дискреционной, что снижает риск повторения весеннего сценария. CVE Foundation при этом продолжает существовать как независимая структура, но управление программой на себя не взяла - острая необходимость в запасном варианте пока отступила.
+
+Запуск EUVD (май 2025). В ответ на нестабильность Евросоюз устами агентства ENISA запустил собственную европейскую базу уязвимостей - EUVD [4]. Она агрегирует данные из CVE, каталога эксплуатируемых уязвимостей и национальных CERT стран ЕС.
+
+Dbugs - витрина поверх конвейера. С июля 2025 года PT ведет открытый портал dbugs.ptsecurity.com: бесплатный агрегатор данных об уязвимостях без регистрации. На старте - более 300 тысяч записей и 45 тысяч исследователей, сейчас - уже свыше 410 тысяч записей и около 4 тысяч новых в неделю. Каждой уязвимости присваивается собственный ID вида PT-YYYY-XXXXX - внутренняя нумерация карточек портала, статус CNA (CVE Numbering Authority) за PT не закреплен. Описания генерируются с помощью LLM, трендовость считается по активности в соцсетях (X, Reddit, Telegram), ведутся профили исследователей. Мотивация запуска прямая - тот же кризис NVD и MITRE, который мы разбирали выше [10].
+
+Какой вывод из всего этого должен сделать практик? Эпоха единого источника закончилась. Раньше можно было считать NVD “истиной в последней инстанции”. Теперь приходится работать с несколькими источниками сразу: БДУ ФСТЭК для российской специфики и официального статуса, CVE для идентификации, EUVD и бюллетени вендоров для полноты, каталоги эксплуатируемых уязвимостей (CISA KEV, трендовые БДУ) для приоритизации. Для российских компаний эта фрагментация даже выгодна: БДУ ФСТЭК давно развивалась как самостоятельный источник и не зависит от перипетий американского NVD.
+Почему нельзя просто взять все из NVD
+
+Даже если бы NVD работал в штатном режиме, без всякого кризиса, полагаться на одну агрегированную базу было бы ошибкой - дело тут не в одной скорости обогащения.
+
+У каждой записи CVE в NVD есть applicability statement - формальное описание того, к каким продуктам и версиям привязана уязвимость. По сути это набор CPE Match Criteria: строки вида cpe:2.3:a:vendor:product:version и диапазоны версий, помеченные как уязвимые. Сам NIST честно пишет, что эта конструкция рассчитана на машины и человеку читается тяжело [5] - и это не преувеличение, если вы хоть раз пытались руками разобрать такую строку.
+
+Беда в том, что CPE-диапазоны регулярно промахиваются в обе стороны. То уязвимой помечена вся линейка версий продукта, хотя проблемная функция включена по умолчанию далеко не везде. То логические операторы внутри блока конфигураций (AND/OR между CPE) обрабатываются некорректно - и это ловят даже открытые сканеры вроде Grype, баг с такими операторами всплывает там не первый год [6].
+
+Но главная дыра не в этом. CPE ничего не говорит об условиях существования уязвимости: при каких настройках, включенных фичах или сочетаниях компонентов брешь реально работает. Какие версии затронуты - это одно. Что должно быть включено, доступно из сети или настроено, чтобы атака прошла, - совсем другое. NVD отвечает только на первый вопрос.
+
+Возьмем Log4Shell (CVE-2021-44228). В CPE уязвимыми числятся версии Log4j 2.0-beta9-2.14.1. Но условия эксплуатации и способ защиты сильно зависят от конкретной сборки: параметр log4j2.formatMsgNoLookups=true, который блокирует атаку, появился только в версии 2.10. Для более ранних веток он вообще не работает, и единственный выход - вручную выпилить класс JndiLookup из classpath [7]. В диапазоне версий из NVD об этом ни слова - знает только тот, кто читал бюллетень разработчика.
+
+Вот почему бюллетень вендора - не дублирующий, а часто более точный источник, чем агрегированные базы. Вендор пишет по-человечески: уязвимость касается только конфигураций с включенным таким-то модулем, для атаки нужен сетевой доступ к такому-то порту, начиная с такой-то версии есть обходной путь без обновления. Поэтому в 2025-2026 годах в VM-индустрии и наметился сдвиг: от “NVD как единственная правда” к модели, где первичным источником становится вендор или CNA, а NVD и агрегаторы остаются для сверки и приоритизации [8].
+
+Кстати, если рассмотреть все решения на отечественном рынке, которые отвечают за поиск уязвимостей, то вы очень сильно удивитесь когда узнаете, что условие существования уязвимостей учитывает только парочку старичков, а все остальные слепо берут CPE2CVE)) Сравнивайте решения правильно)
+А как же уязвимости нулевого дня
+
+Предположим, мы собираем данные из всех источников. Но есть уязвимости, о которых не знает ни один из них, - те самые zero-day. Чтобы ловить их, важно внедрять анализ кода еще на этапе разработки.
+
+Если компания разрабатывает собственное ПО, в процесс сборки должны быть встроены анализаторы кода (SAST, DAST, SCA). Но даже если вы ничего не разрабатываете, а просто держите сайт на WordPress или другой CMS, его все равно стоит регулярно проверять анализаторами - в популярных CMS и их плагинах уязвимости находят постоянно (вспомним, что больше всего CVE за 2025 год выпустили именно компании, занимающиеся безопасностью WordPress-плагинов).
+Почему процесс должен быть автоматизированным и быстрым
+
+Две причины:
+
+    Новые уязвимости появляются ежедневно - около 130 в день в 2025 году (48 185 CVE за год, на 20% больше, чем в 2024-м), и среди них есть критические. Скорость обнаружения критична.
+
+    Нужно быстро понять, где у вас эта уязвимость внутри инфраструктуры.
+
+Вручную это потребовало бы целой команды, которая круглосуточно мониторит источники и сопоставляет их с инфраструктурой. Дорого, медленно, ненадежно. Поэтому - специализированные инструменты, автоматизирующие процесс.
+Требования к ПО для детектирования уязвимостей
+
+Хороший инструмент детектирования должен отвечать семи требованиям:
+
+    Широкий охват источников. Чем больше источников покрыто, тем полнее картина угроз.
+
+    Быстрота получения информации. Данные должны попадать в систему максимально быстро.
+
+    Быстрота использования. Полученную информацию нужно сразу применять для поиска уязвимостей в инфраструктуре.
+
+    Продвинутые методики сканирования. Стандартный сканер проверяет наличие уязвимости только в момент сканирования - этого мало. Нужны продукты, которые собирают и хранят детальную информацию об активах, чтобы выявлять уязвимости сразу после обновления базы, без повторного сканирования.
+
+    Непрерывное обновление базы. Устранение должно начинаться как можно быстрее после обнаружения, особенно для трендовых уязвимостей. Напомним: по требованиям ФСТЭК на критические уязвимости отводится 24 часа.
+
+    Снижение времени реакции. Чем меньше времени между получением информации об уязвимости и реакцией, тем больше шансов закрыть ее до атаки. А времени мало: медианное время от публикации CVE до попадания в каталог эксплуатируемых уязвимостей CISA KEV сократилось до 5 дней, а почти каждая четвертая (29%) эксплуатируемая уязвимость атакуется в день публикации CVE или раньше [9].
+
+Помимо данных об уязвимостях, специалисту полезно знать источники данных об эксплойтах - чтобы понимать, что уже доступно злоумышленникам.
+
+    Дисклеймер. Все перечисленные ресурсы приводятся исключительно в образовательных целях - для понимания ландшафта угроз и построения защиты. Автор и площадка не призывают к использованию эксплойтов в противоправных целях. Любое тестирование на проникновение допустимо только с письменного разрешения владельца системы. Напомню, что в России деятельность по поиску уязвимостей до сих пор законодательно не урегулирована, а неправомерный доступ к компьютерной информации преследуется по статье 272 УК РФ.
+
+    Exploit Database (Exploit-DB) - открытая база эксплойтов от Offensive Security. Бесплатный доступ, широкий ассортимент, подробные описания. exploit-db.com
+
+    Metasploit Framework - мощный инструмент разработки и применения эксплойтов, используемый в легальном пентесте. Большая коллекция встроенных эксплойтов, автоматизация. metasploit.com
+
+    GitHub и репозитории кода - исследователи публикуют PoC-эксплойты и инструменты. Доступ к исходникам, переписка с автором. github.com
+
+    Профильные форумы и сообщества - Reddit (r/netsec), Security Stack Exchange и специализированные площадки. Обсуждение реальных кейсов, ответы опытных специалистов.
+
+Для российского контекста стоит добавить и легальные площадки исследователей: программы багбаунти (Standoff Bug Bounty, BI.ZONE Bug Bounty) и их публичные отчеты дают представление о реальных уязвимостях в отечественных продуктах.
+Как устроена доставка данных об уязвимостях у вендора
+
+Сейчас распишу как процесс должен быть реализован в решениях по анализу защищенности.
+
+Приоритизация ПО. Заказчики используют тысячи разных программ - покрыть все детектами сразу невозможно. Поэтому нужно приоритизировать: учитываем наличие эксплойтов, информацию от вендоров и из баз, анализируем популярность ПО по открытым источникам и делим его на целевое, ключевое и периметровое.
+
+Создание детектов. После приоритизации создаем детекты. Классический подход включает стендирование (установку ПО на стенд, анализ его параметров), разработку описания артефактов и их взаимосвязей, написание скриптов, тестирование и выпуск. Сложность сильно варьируется: для Windows версию можно взять из реестра, а для сложного ПО вроде Confluence, где база может быть разнесена на разные серверы, приходится изобретать обходные пути (например, искать файлы командой find на Linux). Для сбора данных используются транспорты: RPC, реестр, WMI, файловые системы для Windows, ODBC для баз данных, SSH для Linux.
+
+Сбор и обработка данных. Собранные должны систематизироваться: скрипты автоматически собирают информацию о версиях ПО, атрибуцируют уязвимости и формируют данные для продукта.
+
+SLA на обновления. Информацию о новых уязвимостях нужно доставлять как можно чаще, но минимум 1 раз в 24 часа (это пессимистичный вариант). Все трендовые уязвимости доложны быть выделены на отдельный дашборд или другой инфомрационный блок с датой обнаружения и деталями.
+
+Жизненный цикл и оценка трендовости. Уязвимость проходит путь от недостатка в коде до общеизвестной угрозы, о которой пишут СМИ. Задача вендора - анализировать, на каком этапе находится уязвимость, и по специальному плейбуку принимать решение о ее трендовости, опираясь на множество источников и собственную базу.
+
+Зачем нам этот закулисный рассказ? Чтобы вы понимали: выбирая VM-инструмент, вы выбираете сканер и вместе с ним весь невидимый конвейер аналитики за его базой уязвимостей. При нынешней фрагментации мировых источников качество этого конвейера становится решающим, да да, именно этот невидимый слой является решающим, а не “более красивый интерфейс”.