Средняя
Компании научились находить уязвимости. Сканеры регулярно приносят списки CVE, дашборды окрашиваются в красный, отчёты показывают критичность, владельцам систем уходят задачи на исправление. Процесс вроде бы есть: нашли, оценили, назначили, закрыли.
Но в какой‑то момент список уязвимостей перестаёт помогать. Их слишком много. Часть нельзя быстро исправить. Часть находится на системах, к которым никто не хочет прикасаться без отдельного проекта. Часть формально критична, но живёт в изолированном сегменте. А где‑то рядом есть уязвимость с более скромной оценкой, зато к ней ведёт прямой и давно забытый сетевой доступ.
И это уже не теоретическая проблема. В отчёте УЦСБ SOC «Ландшафт киберугроз 2025/2026: тренды, атаки, уязвимости» среди заметных тенденций названы атаки через цепочки поставок и подрядчиков, использование известных уязвимостей для первичного доступа, а также комплексный характер атак: от шифрования и кражи данных до Ransom DDoS. По данным публикаций по исследованию, не менее 30% атак в 2025 году были связаны с компрометацией ИТ-подрядчиков, а число инцидентов с первичным доступом через уже известные уязвимости выросло на 30%. [1][2]
И вот здесь появляется неприятный вопрос: мы правда понимаем, какие из найденных уязвимостей можно использовать в атаке прямо сейчас?
Содержание
- CVE — это ещё не атака
- Атакующий не читает отчет так, как его читаем мы
- Главный вопрос: есть ли путь?
- Подрядчики — отдельная зона риска
- Сетевые правила тоже стареют
- Высокая критичность не всегда означает первый приоритет
- От списка проблем к сценариям атаки
- Что стоит иметь в виду при анализе?
- Не всё можно исправить сразу, но можно исправлять умнее
- Вывод
CVE — это ещё не атака
CVE описывает техническую проблему. Это важно, но этого мало. Уязвимость существует не в вакууме, а внутри конкретной инфраструктуры: с её сегментами, правилами доступа, подрядческими VPN, NAT, устаревшими исключениями, временными разрешениями и человеческой привычкой «потом закроем».
Одна и та же CVE в разных компаниях может означать совершенно разный уровень риска.
Если уязвимый сервис находится в закрытом сегменте, доступен только с нескольких административных станций и дополнительно ограничен сетевыми правилами, это одна история. Да, проблему нужно исправлять. Но эксплуатация такой уязвимости требует от атакующего уже иметь серьёзную позицию внутри сети.
Совсем другое дело — если тот же или даже менее критичный сервис доступен из интернета, пользовательской сети, DMZ или подрядческого подключения. Тогда уязвимость превращается из строки в отчёте в реальную точку входа.
Поэтому вопрос «какой CVSS?» важен, но не должен быть единственным. Не менее важный вопрос: «кто может дотянуться до этого сервиса?»
Атакующий не читает отчёт так, как его читаем мы
Внутри компании уязвимости часто живут в таблицах: CVE, актив, критичность, владелец, срок устранения, статус. Это удобный формат для процесса, но не для понимания атаки.
Атакующий мыслит иначе. Его интересует маршрут.
- Откуда можно зайти?
- Какой сервис открыт?
- Есть ли на нем известная уязвимость?
- Что даст эксплуатация?
- Можно ли пойти дальше?
- Куда ведут правила доступа?
- Можно ли добраться до учётных данных, баз данных, систем управления, резервных копий?
Он не выбирает «самую красивую» CVE в отчёте. Он выбирает ту, до которой можно добраться и которую можно встроить в цепочку.
Именно поэтому управление уязвимостями без понимания сетевой достижимости похоже на изучение карты пожаров без карты дорог. Мы видим очаги, но не понимаем, куда огонь может распространиться.
Главный вопрос: есть ли путь?
Практический риск возникает не только из-за самой уязвимости. Он возникает, когда сходятся несколько условий:
- уязвимый сервис существует;
- он доступен по сети;
- к нему есть разрешённый маршрут;
- источник этого маршрута может быть скомпрометирован;
- эксплуатация даёт атакующему полезный результат.
Если убрать хотя бы один элемент этой цепочки, риск снижается. Иногда нельзя быстро установить патч, но можно закрыть лишний доступ. Иногда нельзя обновить систему сегодня, но можно ограничить источники подключения. Иногда нельзя остановить сервис, но можно вынести его из опасного маршрута, включить дополнительное логирование или убрать доступ для целой подсети, оставив только конкретные хосты.
Это не заменяет исправление уязвимости. Но это меняет разговор. Вместо абстрактного «у нас критичная CVE» появляется конкретное «у нас есть достижимый уязвимый сервис из зоны подрядчиков, и это надо закрывать первым».
Подрядчики — отдельная зона риска
Отдельного внимания заслуживают подрядчики. В обсуждении удалённого доступа обычно быстро вспоминают VPN, MFA, учётные записи, сроки действия договоров и контроль подключений. Все это правильно. Более того, среди практических мер противодействия атакам через подрядчиков как раз называют строгий контроль удалённого доступа, сегментирование сети и принцип наименьших привилегий. [3]
Но есть ещё один вопрос, который часто остаётся за кадром: что подрядчик видит после подключения?
Если подрядчику нужен доступ к одному серверу на один порт, а фактически ему доступен целый сегмент, это уже не просто техническая избыточность. Это будущий маршрут атаки.
Подрядческие доступы особенно опасны тем, что часто создаются под давлением проекта. Нужно срочно внедрить, настроить, починить, подключить, проверить. Временное правило открывается «на период работ». Потом работы заканчиваются, люди переключаются, заявка закрывается, а правило остаётся. Через полгода уже никто не помнит, зачем оно было нужно. Через год оно становится частью ландшафта. Через два — никто не решается его удалить.
А потом выясняется, что из этого сегмента доступен сервис с известной уязвимостью.
Поэтому анализ CVE без проверки подрядческих, сервисных и удалённых доступов почти всегда неполон. Вопрос не только в том, есть ли уязвимость. Вопрос в том, не оставили ли мы к ней удобную дорогу.
Сетевые правила тоже стареют
Уязвимости обычно воспринимаются как проблема программного обеспечения. Но в реальной атаке не меньшую роль играют правила доступа.
Широкие разрешения, старые исключения, доступы «сеть в сеть», правила без владельца, правила без срока действия, разрешения без ограничения портов, доступы к административным интерфейсам из пользовательских зон — всё это не CVE. В бюллетенях безопасности такие вещи не публикуют. У них нет красивого идентификатора и CVSS-оценки.
Но именно они часто превращают уязвимость в работающий сценарий атаки.
Плохое сетевое правило не является эксплойтом. Но оно может сделать эксплойт применимым.
Поэтому «гигиена» правил доступа — это не скучная эксплуатационная задача из мира сетевых инженеров. Это часть управления реальным риском. Чем меньше лишних маршрутов, тем меньше возможностей для первичного доступа и дальнейшего перемещения внутри сети.
Высокая критичность не всегда означает первый приоритет
Представим две уязвимости.
Первая — критичная, с высоким CVSS. Она находится на внутреннем сервере, который доступен только из административного сегмента. Доступ ограничен, сервис не опубликован, внешнего маршрута нет.
Вторая — средней критичности. Но она находится на сервисе, доступном из пользовательской сети или через подрядческий VPN. Эксплойт публичный, порт открыт, сервис активно используется.
Что исправлять первым?
Формальный подход скажет: первую. Практический подход, скорее всего, начнёт со второй. Потому что атакующий выбирает не самый высокий балл, а самый удобный путь.
Это не значит, что CVSS бесполезен. Он нужен. Но его нельзя использовать как единственный компас. Критичность уязвимости должна дополняться достижимостью, ролью актива, наличием эксплойта и возможным эффектом эксплуатации.
Иначе можно месяцами закрывать «красные» пункты в отчёте, пока реальный маршрут атаки остаётся открытым где‑то сбоку.
От списка проблем к сценариям атаки
Зрелый анализ начинается там, где список уязвимостей превращается в набор сценариев.
Не просто:
«На сервере X обнаружена CVE».
А так:
«Из подрядческого сегмента есть доступ к серверу X по порту Y. На этом сервисе есть уязвимость с публичным эксплойтом. После эксплуатации возможен доступ к данным или дальнейшее движение в серверный сегмент».
Или так:
«Сервис опубликован в DMZ. Уязвимость критичная, но за счёт сетевых ограничений нет маршрута к внутренним базам данных. Срочно обновляем, но риск распространения ограничен».
Или так:
«Уязвимость находится на внутреннем сервисе, который не должен быть доступен из пользовательской сети, но доступ есть из-за старого широкого правила. Первая мера — сузить доступ, вторая — исправить сервис».
Такой формат разговора гораздо полезнее для принятия решений. Он связывает уязвимость, сеть, бизнес-систему и конкретное действие.
Что стоит иметь в виду при анализе?
При разборе значимых CVE полезно каждый раз задавать несколько простых вопросов.
- Где находится уязвимый актив?
- Какой сервис уязвим?
- На каком порту он доступен?
- Из каких зон к нему можно обратиться?
- Есть ли доступ из интернета, DMZ, пользовательских сетей или подрядческих VPN?
- Через какие правила и устройства проходит маршрут?
- Есть ли NAT, VRF, пересекающиеся адресные пространства?
- Есть ли публичный эксплойт?
- Что получает атакующий после эксплуатации?
- Можно ли использовать этот актив как промежуточную точку?
- Есть ли быстрые компенсирующие меры до установки патча?
- Кто владелец доступа и почему он вообще открыт?
Эти вопросы не требуют менять саму идею управления уязвимостями. Они просто возвращают её к реальности. Потому что риск живёт не в таблице. Риск живёт в инфраструктуре.
Не всё можно исправить сразу, но можно исправлять умнее
В идеальном мире все критичные уязвимости закрываются мгновенно. В реальном мире есть окна обслуживания, устаревшие системы, зависимые бизнес-процессы, подрядчики, интеграции, регуляторные ограничения и вечная фраза «только не трогайте это до конца квартала».
Поэтому задача безопасности — не просто требовать исправить всё. Задача — помочь понять, что опаснее именно сейчас.
Если у компании есть 500 критичных уязвимостей, это проблема. Но для действия нужна другая формулировка: какие из них доступны из опасных зон, какие имеют эксплойт, какие ведут к критичным активам, какие можно временно закрыть сетевыми ограничениями, а какие действительно требуют немедленного обновления.
Так приоритизация становится не формальной, а инженерной.
Вывод
Знать CVE важно. Но сегодня этого недостаточно.
Уязвимость становится настоящим риском только в контексте: где она находится, кто может до неё добраться, какой маршрут к ней ведёт, что разрешают сетевые правила и что получит атакующий после эксплуатации.
Именно поэтому данные из исследований киберугроз важны не только как статистика. Они показывают, какие сценарии действительно работают: компрометация подрядчиков, эксплуатация известных уязвимостей, использование цепочек поставок, комбинированные атаки на инфраструктуру и данные. Но внутри каждой конкретной компании эти сценарии нужно переводить на язык собственной сети.
Поэтому стоит переходить от учёта уязвимостей к анализу маршрутов атаки. Не ограничиваться вопросом «что у нас уязвимо?», а задавать следующий: «какие из этих уязвимостей реально достижимы и могут стать частью атаки?»
Именно этот переход отделяет формальное управление уязвимостями от управления реальным риском.
Источники
[1] УЦСБ SOC. «Ландшафт киберугроз 2025/2026: тренды, атаки, уязвимости».
[2] Публикации по исследованию УЦСБ SOC: данные о росте инцидентов с первичным доступом через известные уязвимости и доле атак через подрядчиков.
[3] Публикации по исследованию УЦСБ SOC: рекомендации по контролю удалённого доступа подрядчиков, сегментированию сети и принципу наименьших привилегий.
Адрес:
121205, г. Москва, муниципальный округ Можайский, территория инновационного центра «Сколково», б-р Большой, д. 42, стр. 1, этаж 2, помещение № 162/№ 4
Телефон:
+7 (495) 255-35-82
Почта:
info@netopia.pro
Деятельность осуществляется компанией ООО «Нетопия» при грантовой поддержке Фонда «Сколково»
© Netopia.pro
