Средняя
- Теги: CVE, Anthropic, ФСТЭК, Управление уязвимостями
Привычный процесс управления уязвимостями построен вокруг обновлений. Производитель выпускает исправление, специалисты находят уязвимые системы, тестируют патч, согласуют окно работ и устанавливают его в промышленной среде.
Между публикацией исправления и его установкой остаётся patch gap — период, когда информация об уязвимости уже доступна атакующим, а часть систем продолжает работать без защиты.
Раньше этот промежуток мог измеряться неделями. Чтобы сравнить старую и новую версии продукта, найти исправленную ошибку и превратить её в рабочий эксплойт, требовались квалифицированные специалисты по реверс-инжинирингу. Теперь эта работа всё активнее автоматизируется.
В эксперименте Anthropic языковая модель самостоятельно создала восемь работающих эксплойтов для 18 изученных исправлений Firefox. При анализе 21 исправления ядра Windows модель построила восемь полноценных цепочек повышения привилегий до уровня SYSTEM. По оценке исследователей, один оператор теперь способен превратить месячный набор опубликованных патчей в рабочие эксплойты за один день — без большой команды узких специалистов. (anthropic.com)
Разработка эксплойта — не вся атака. Злоумышленнику ещё нужно найти уязвимую систему, доставить код, обойти защиту и закрепиться. Но один из наиболее дорогих этапов заметно ускоряется.
И это меняет главный вопрос для защитников.
Раньше он звучал так:
Насколько быстро мы можем установить исправление?
Теперь к нему добавляется второй:
Насколько быстро мы можем сделать уязвимый компонент недостижимым для атакующего?
Содержание
Патч может не успеть первым
Даже хорошо организованный процесс обновлений невозможно выполнить мгновенно.
Сначала нужно определить затронутые активы. Затем проверить совместимость исправления, подготовить резервную копию и откат, согласовать остановку сервиса и выбрать окно обслуживания. Для сетевого оборудования, промышленных систем, критичных бизнес-приложений и сертифицированных комплексов этот процесс может занимать дни или недели.
Если рабочий эксплойт появляется за несколько часов, патч всё чаще перестаёт быть первой мерой реагирования. Он остаётся окончательным решением, но организации требуется способ быстро выиграть время.
Таким способом становятся компенсирующие сетевые меры.
Их задача — не обязательно полностью отключить систему. Главное — уменьшить сетевую достижимость уязвимой функции:
- закрыть доступ из интернета;
- оставить только необходимые источники;
- убрать доступ из пользовательских сегментов;
- вынести администрирование в отдельную сеть;
- временно отключить уязвимый порт или протокол;
- разрешить соединение только через VPN или bastion host;
- применить сигнатуру IPS, WAF или NGFW как виртуальный патч;
- усилить мониторинг обращений к уязвимому сервису.
Правильная мера зависит от назначения системы. Где‑то допустима полная изоляция, а где‑то сервис должен продолжать работать для тысяч пользователей. Поэтому речь идёт не столько о жёстком «закрытии доступа», сколько о быстром выборе минимально достаточного сетевого ограничения.
Почему нельзя просто положиться на NGFW?
Возникает логичный вопрос: зачем запрещать соединение, если NGFW может анализировать трафик и блокировать только опасные пакеты?
Действительно, NGFW с IPS, WAF или отдельная система предотвращения вторжений могут стать эффективной компенсирующей мерой. Такие средства сочетают сигнатурный анализ, поиск аномалий и проверку состояния протокола. Они способны блокировать соединения, ограничивать трафик и изменять вредоносное содержимое.
Но интеллектуальная фильтрация и ограничение достижимости решают разные задачи.
NGFW пытается ответить на вопрос:
Выглядит ли это разрешённое соединение как атака?
Сетевое ограничение отвечает на другой:
Должен ли этот источник вообще иметь возможность установить соединение?
Во втором случае средство защиты не обязано распознавать эксплойт. Если пользовательской сети не нужен доступ к административному интерфейсу, соединение блокируется независимо от конкретной техники атаки.
У NGFW остаются объективные ограничения. Сигнатура может ещё не существовать или не учитывать новую модификацию эксплойта. Последовательность внешне допустимых запросов сложнее распознать, чем один явно вредоносный пакет. Зашифрованный трафик невозможно полноценно анализировать без расшифрования. Под высокой нагрузкой глубина проверки также может снижаться. Для сетевых IDPS характерны и ложные срабатывания, и пропущенные атаки, поэтому они требуют настройки под конкретную инфраструктуру.
Поэтому разумна следующая иерархия мер:
- Ненужную функцию — отключить.
- Доступный всем сервис — ограничить реальными потребителями.
- Административный доступ — вынести в защищённый контур.
- Сервис, который нельзя закрыть, — защитить виртуальным патчем средствами NGFW, IPS или WAF.
- Во всех случаях — установить исправление, когда оно будет готово.
NGFW здесь не альтернатива сегментации, а следующий защитный слой.
От списка CVE — к реальным путям атаки
Классический сканер отвечает на вопрос:
Какие уязвимости существуют в инфраструктуре?
Для срочного реагирования этого недостаточно. Требуется второй вопрос:
Откуда до уязвимого компонента можно добраться прямо сейчас?
Два сервера с одной CVE могут иметь совершенно разный риск.
Первый опубликован в интернете и доступен любому источнику. Второй находится во внутреннем сегменте, а обращаться к его уязвимому сервису могут только два прикладных сервера.
Формальная тяжесть уязвимости одинакова. Но вероятность атаки, количество потенциальных источников и срочность реагирования различаются.
Поэтому оценка должна учитывать несколько измерений:
- тяжесть последствий;
- вероятность эксплуатации;
- подтверждённое применение в атаках;
- критичность актива;
- сетевую достижимость;
- возможный путь дальнейшего перемещения по инфраструктуре.
CVSS описывает техническую тяжесть уязвимости. EPSS ежедневно оценивает вероятность того, что активность по эксплуатации конкретной CVE будет наблюдаться в течение следующих 30 дней. (FIRST)
Каталог CISA Known Exploited Vulnerabilities выделяет уязвимости, для которых уже подтверждена эксплуатация, и CISA рекомендует организациям приоритизировать их устранение. (CISA)
Но ни CVSS, ни EPSS, ни KEV сами по себе не знают, опубликован ли конкретный сервер в интернет, открыт ли уязвимый порт из пользовательской сети и через какие МЭ к нему проходит трафик.
Что рекомендует ФСТЭК?
Российская методика ФСТЭК от 30 июня 2025 года также движется от абстрактного рейтинга уязвимости к оценке её в контексте конкретной информационной системы.
В расчёте учитывается влияние уязвимого компонента на защищённость периметра. В примерах применения методики отдельно рассматривается ситуация, когда уязвимое средство доступно из интернета. Для уязвимостей критического уровня рекомендуется принять меры в течение нескольких часов, но не позднее 24 часов после оценки. (fstec.ru)
Важно и то, что устранение не сводится исключительно к установке обновления. ФСТЭК относит к возможным компенсирующим мерам:
- исключение доступа к уязвимым функциям;
- ограничение использования компонента;
- отключение уязвимых служб и сетевых протоколов;
- применение сигнатур и решающих правил средств защиты;
- мониторинг признаков возможной эксплуатации. (Судакт)
То есть жёсткое ограничение доступа и виртуальный патч средствами NGFW — не конкурирующие идеи. Это разные варианты компенсирующей защиты, которые выбираются с учётом архитектуры системы и способа эксплуатации уязвимости.
Рекомендация должна быть исполнимой
На практике совет «ограничить сетевой доступ» часто оказывается слишком общим.
Чтобы выполнить его, нужно выяснить:
- на каких активах установлен уязвимый компонент;
- какой порт и протокол связаны с уязвимостью;
- кто имеет доступ сейчас;
- через какие устройства проходит трафик;
- какие правила МЭ его разрешают;
- применяется ли NAT;
- какие легитимные взаимодействия будут нарушены;
- можно ли сузить доступ, не останавливая сервис.
Если поиск этих данных занимает сутки, компенсирующая мера может опоздать так же, как патч.
Поэтому полезная рекомендация должна выглядеть не так:
Обнаружена критическая CVE. Ограничьте сетевой доступ.
А так:
Уязвимый сервис CRM-API на TCP/443 доступен из интернета через FW-EDGE-01 по правилам 145 и 287. Для штатной работы соединение требуется только от балансировщиков WEB-LB. Рекомендуется заменить источник ANY на группу WEB-LB и включить IPS-сигнатуру для оставшегося трафика.
Такая рекомендация связывает уязвимость с топологией, маршрутами, правилами МЭ и реальными бизнес-взаимодействиями.
Новая последовательность реагирования
При появлении критической уязвимости два процесса должны запускаться параллельно.
Немедленное сдерживание:
- Найти уязвимые активы.
- Определить доступные сервисы и сетевые пути.
- Оценить реальные источники атаки.
- Выбрать меру: закрытие, сужение доступа или виртуальный патч.
- Проверить, что изменение действительно уменьшило достижимость.
Постоянное устранение:
- Получить и протестировать исправление.
- Установить патч.
- Проверить результат.
- Вернуть необходимые взаимодействия.
- Удалить временные ограничения и сигнатуры, если они больше не нужны.
Эксплойты создаются всё быстрее. Значит, защитникам недостаточно ускорять только обновления.
Нужно сокращать время между обнаружением уязвимости и изменением условий, в которых она может быть использована.
Патч устраняет ошибку. NGFW способен распознать и заблокировать часть атак. Но управление сетевой достижимостью решает более фундаментальную задачу: не даёт лишним источникам добраться до уязвимого компонента вообще.
Адрес:
121205, г. Москва, муниципальный округ Можайский, территория инновационного центра «Сколково», б-р Большой, д. 42, стр. 1, этаж 2, помещение № 162/№ 4
Телефон:
+7 (495) 255-35-82
Почта:
info@netopia.pro
Деятельность осуществляется компанией ООО «Нетопия» при грантовой поддержке Фонда «Сколково»
© Netopia.pro
