Сергей Попов
Администратор
- 30.12.2015
- 6 246
- 6 978
- Специализация
- OSINT
- Веб-безопасность
- Статус верификации
- ✓ Verified
По данным IBM X-Force Threat Intelligence Index 2025, среднее время между публикацией CVE и устранением в организации - 29 месяцев. Двадцать девять. А теперь обратная сторона: CVE-2020-1472 (Zerologon) имеет EPSS-скор 0.9951 - экстремальная вероятность эксплуатации. При этом NVD фиксирует CVSS 5.5 (MEDIUM, AV:L/PR:L), хотя сам Microsoft в бюллетене MSRC помечает уязвимость как Critical severity - расхождение между качественной оценкой вендора и числовым CVSS-скором показывает, почему нельзя ориентироваться только на цифру. Red Hat для Samba-реализации указывает 9.8 (Critical, AV:N, CWE-287) - разница с NVD объясняется тем, что Microsoft и Red Hat оценивали разные реализации протокола Netlogon (MS-NRPC у Microsoft vs. серверная реализация в Samba), что дало разные предположения о необходимых привилегиях (PR:L vs PR:N) и типе доступа (AV:L vs AV:N). Окно между обнаружением уязвимости атакующим и вашей реакцией схлопывается до часов, а ваш процесс патчинга рассчитан на месяцы. Эта статья - карта действий для тех, кто строит защиту в этом разрыве.
Навигация по теме: от обнаружения до устранения
Почему окно эксплуатации схлопнулось до часов и что это меняет для защиты
Ещё пять лет назад формула была простой: вендор выпускает бюллетень, SOC планирует Change Window, администраторы раскатывают патч в течение 30 дней. Сейчас эта формула мертва. И вот почему.По данным Mandiant M-Trends, эксплуатация уязвимостей стала одним из самых распространённых векторов первоначального проникновения - на уровне фишинга и кражи учётных данных. Среднее time-to-exploit для критических CVE, попадающих в CISA KEV, измеряется днями, а не неделями.
Три структурных сдвига, которые определяют текущую картину:
Софт собирается, а не пишется. Современное приложение тянет за собой сотни зависимостей. Публичные контейнерные образы могут содержать десятки и сотни известных CVE ещё до добавления прикладного кода. Zero-day в популярной библиотеке бьёт по всем, кто её включил - часто даже не зная об этом.
Атакующие сместились на периметр. VPN-аплайнсы, файрволы, решения для передачи файлов - edge-устройства стали главной целью zero-day атак. Они торчат в интернет, а циклы их обновления медленнее, чем у рабочих станций. Показательный пример - CVE-2021-20016 в SonicWall SMA100 (CVSS 9.8, CWE-89: SQL-инъекция): атака через SSLVPN позволяла неаутентифицированному удалённому злоумышленнику извлечь логины, пароли и данные сессий. Тренд не ослабевает: в 2026 году CVE-2026-35616 в FortiClient EMS версий 7.4.5-7.4.6 (CVSS 9.8, CWE-284) позволяла неаутентифицированному атакующему выполнить произвольный код или команды.
Регуляторы подтянулись. ФЗ-187 обязывает операторов КИИ обнаруживать компьютерные атаки, а ФЗ-152 требует обеспечивать безопасность ПДн. Неспособность ответить на вопрос "затронуты ли мы?" в течение часов после раскрытия CVE - это уже не только технический, но и комплаенс-риск.
Подробный разбор того, почему эксплуатация уязвимостей стала вектором номер один: Verizon DBIR 2026: эксплуатация уязвимостей - вектор номер один и что с этим делать пентестеру.
5 стадий жизненного цикла zero-day и где вы можете вмешаться
Каждый zero-day проходит определённый путь - от появления уязвимости в коде до выкатки патча на последний узел. Понимание стадий определяет, какие compensating controls применять на каждом этапе.
Стадия 1 - Уязвимость в коде. Защитник тут бессилен - уязвимость ещё не обнаружена. Но инвестиции в SAST/DAST и SCA на этапе CI/CD сокращают число дефектов, доходящих до продакшена. Это работа "в мирное время".
Стадия 2 - Обнаружение атакующим. Злоумышленник (или исследователь) находит дефект через реверс-инжиниринг, фаззинг, анализ diff'ов между патчами. В терминах MITRE ATT&CK - T1595.002 (Vulnerability Scanning) и T1588.006 (Vulnerabilities). Здесь начинает тикать ваш счётчик.
Стадия 3 - Разработка эксплойта. Создаётся рабочий код эксплуатации, нередко продаваемый через брокеров. MITRE ATT&CK: T1588.005 (Exploits). Для CVE-2025-54100 (command injection через cmdlet Invoke-WebRequest в PowerShell, CVSS 7.8 HIGH, эксплуатация требует взаимодействия пользователя - UI:R в CVSS-векторе) публичный PoC-репозиторий ThemeHackers/CVE-2025-54100 на GitHub. PoC есть - вопрос времени, когда его подхватят.
Стадия 4 - Активная эксплуатация. Атакующий применяет эксплойт против реальных целей - T1190 (Exploit Public-Facing Application), T1203 (Exploitation for Client Execution), T1068 (Exploitation for Privilege Escalation), T1210 (Exploitation of Remote Services). Именно здесь включаются ваши compensating controls.
Стадия 5 - Раскрытие, патч, развёртывание. Вендор узнаёт, выпускает бюллетень, присваивается CVE. Но проблема не решена: начинается гонка между развёртыванием патча и обратной разработкой самого патча атакующими. Diff патча - готовая подсказка для написания эксплойта.
Вы НЕ контролируете стадии 1-3. Ваша зона влияния - стадия 4 (обнаружение и сдерживание) и стадия 5 (скорость развёртывания). Всё, что ниже, - инструменты и процессы для этих двух стадий.
Детальный разбор жизненного цикла с реальными CVE: Уязвимость нулевого дня: жизненный цикл, реальные CVE и процесс патчинга.
Compensating controls: 7 уровней защиты без патча
Когда патча нет, защита строится из слоёв compensating controls. Каждый слой сам по себе не гарантирует остановку атаки, но в комбинации они дают SOC-команде время и видимость для принятия решений.Уровень 1: Сокращение поверхности атаки (Attack Surface Reduction)
Самый эффективный контроль - убрать то, чего атакующий не должен видеть. Каждая библиотека, каждый открытый порт, каждый сервис - это место, куда может приземлиться будущий zero-day. Чем меньше "посадочных площадок" - тем меньше поводов для паники в три часа ночи.Практический чеклист:
- Провести инвентаризацию всех публично доступных сервисов через ASM-инструменты (Shodan, Censys, Tenable.io)
- Отключить административные интерфейсы управления edge-устройствами (VPN-аплайнсов, файрволов) от прямого доступа из интернета
- Перевести контейнерные образы на минимальные base images (distroless) - меньше пакетов, меньше мест для будущих CVE
- Удалить неиспользуемые компоненты, отключить ненужные протоколы и сервисы
Уровень 2: Виртуальный патчинг через WAF и IPS
Виртуальный патчинг - правило на WAF или IPS, которое блокирует известный вектор эксплуатации без изменения кода приложения. Когда CERT публикует IoC или описание вектора атаки, конкретный паттерн можно закрыть за минуты.Где работает: веб-приложения за WAF (Cloudflare, F5, ModSecurity), сетевые сервисы за IPS/NGFW.
Где НЕ работает: уязвимости через легитимный зашифрованный трафик (TLS без терминации на WAF), binary-level exploits в десктопных приложениях, privilege escalation на уровне ядра ОС (WAF в принципе не видит локальный трафик).
Нюансы по вендорам: Cloudflare WAF поддерживает кастомные правила на уровне Enterprise-плана; ModSecurity работает с Apache/Nginx и позволяет гранулярную настройку, но требует ручного тюнинга (и это отдельная боль); F5 ASM/AWAF даёт виртуальный патчинг через iRules и bot defense, но лицензируется отдельно.
Уровень 3: Поведенческая детекция через EDR/XDR
Сигнатурная защита против zero-day бесполезна - сигнатур ещё не существует. Но эксплуатация оставляет поведенческие паттерны: неожиданные дочерние процессы, LDAP-запросы из процессов, которые обычно их не делают, запись в системные директории.Настройка EDR-политик под виртуальный патчинг - вот ключевые техники по вендорам:
- CrowdStrike Falcon: Custom IOA (Indicator of Attack) правила позволяют описать поведенческий паттерн эксплуатации -
cmd.exe, порождённый из процесса web-сервера, или PowerShell с обфусцированными аргументами. Falcon OverWatch добавляет managed threat hunting для обнаружения ранее неизвестных паттернов. - Microsoft Defender for Endpoint: ASR-правила (Attack Surface Reduction Rules) блокируют типичные поведенческие цепочки: запуск исполняемого контента из email-клиента, обфусцированные скрипты, создание процессов из Office-макросов. Custom detection rules через KQL в Advanced Hunting.
- Elastic Security 8.x+: Правила SIEM на основе ECS (Elastic Common Schema) + prebuilt detection rules для known exploitation patterns. Модуль ML-based anomaly detection для выявления аномального поведения процессов.
Уровень 4: Сетевая сегментация и микросегментация
Даже если атакующий получил начальный доступ через zero-day (T1190), сегментация ограничивает латеральное движение (T1210). На практике:- VLAN-сегментация между серверными сегментами, рабочими станциями и управляющими сетями
- Микросегментация на уровне хостов (software-defined segmentation) - конкретный сервер баз данных доступен только с конкретного application-сервера
- EDR Isolation - немедленная изоляция скомпрометированного хоста из сети одной кнопкой (поддерживается CrowdStrike, Microsoft Defender for Endpoint, SentinelOne)
Уровень 5: Усиление аутентификации и контроля доступа
Многие zero-day эксплуатации требуют определённого уровня привилегий для полной компрометации. Если минимальные привилегии соблюдены - радиус поражения ограничен.Чеклист:
- MFA на всех привилегированных аккаунтах без исключений
- PAM (Privileged Access Management) с just-in-time доступом
- Принцип наименьших привилегий - обычные пользователи без прав локального администратора
- Отключение NTLM-аутентификации где возможно (CVE-2019-1040 - NTLM MIC bypass, CVSS 5.3 MEDIUM - и CVE-2019-1019 - обход security feature через NETLOGON session key, CWE-200, CVSS 8.5 HIGH - обе эксплуатируют слабости в цепочке NTLM/NETLOGON-аутентификации, но с разной серьёзностью)
Уровень 6: SIEM-корреляция и Threat Intelligence интеграция
SIEM в контексте zero-day решает задачу "соединить точки": единичное аномальное событие EDR + необычный DNS-запрос + нетипичный сетевой поток = потенциальная компрометация. Без корреляции каждое событие - шум. С корреляцией - сигнал.Интеграция threat intelligence фидов (OTX AlienVault, CISA KEV, vendor-specific advisories) с SIEM позволяет автоматически поднимать приоритет алертов, связанных с активно эксплуатируемыми CVE. Для CVE-2025-62221, например, в OTX зафиксировано 50 пульсов с тегом
actively_exploited_kev.Уровень 7: Песочницы и динамический анализ
Sandbox-решения (детонационные камеры) запускают подозрительные файлы и URL в изолированной среде, наблюдая за поведением: попытки подключения к C2, шифрование файлов, эскалация привилегий. Песочница обнаруживает zero-day эксплойт по его действиям, а не по сигнатуре - но только для файловых и URL-векторов доставки.Ограничение: песочницы не помогают против server-side exploitation (T1190) - атакующий напрямую эксплуатирует сервис без доставки файла. Тут другая история.
Полное руководство по действиям SOC при zero-day: Защита от zero-day уязвимостей: playbook для SOC, когда патча ещё нет.
Playbook реагирования: первый час, первые сутки, первая неделя
Когда CERT или CISA публикует бюллетень об активно эксплуатируемом zero-day, ваш runbook определяет, станете ли вы жертвой или просто заполните строку в отчёте об инциденте. Ниже - фреймворк действий с конкретными таймингами.
Первый час (0-60 мин): определение экспозиции
Единственный вопрос: "Используем ли мы уязвимый компонент и где?"- Запросить SBOM (Software Bill of Materials) или запустить сканирование инвентаря активов
- Сопоставить затронутые версии продукта с вашим asset inventory
- Проверить, выставлен ли уязвимый сервис в интернет (ASM-дашборд, Shodan-запрос)
- Принять решение SSVC-типа: если exposure подтверждена и CISA SSVC = "Act" (как для CVE-2025-62221, где Automatable=no и требуется предварительный локальный доступ) - переходить к немедленной изоляции. Для сравнения: CVE-2025-54100 имеет SSVC-решение "Track" (мониторинг, без подтверждённой эксплуатации) - существенно меньшая срочность
Первые сутки (1-24 часа): сдерживание и детекция
- Развернуть виртуальный патч на WAF/IPS для известного вектора эксплуатации
- Создать и задеплоить custom detection rule на EDR/SIEM для поведенческих паттернов эксплуатации
- Изолировать наиболее критичные уязвимые узлы, если функциональный trade-off приемлем
- Запустить IoC-поиск по существующим логам: ретроспективный threat hunting за последние 30-90 дней
- Оповестить SOC-команду, выпустить внутренний advisory с чётким указанием scope и severity
Первая неделя (1-7 дней): стабилизация и remediation
- Установить патч вендора, если он вышел
- Если патча нет - оценить целесообразность отключения уязвимого функционала vs. усиление compensating controls
- Провести полный forensic-анализ любых подозрительных находок из IoC-поиска
- Обновить Sigma/YARA-правила на основе опубликованных IoC и собственных находок
- Документировать lessons learned и обновить runbook
Детальный таймлайн SOC-реагирования: Защита от zero-day уязвимостей: playbook для SOC, когда патча ещё нет.
Sigma и YARA: детект-логика для zero-day без сигнатур вендора
Пока вендор разрабатывает патч, SOC-команда может написать собственные правила обнаружения на основе опубликованного описания вектора атаки. Два основных формата: Sigma (для SIEM-систем) и YARA (для файлового анализа и endpoint-сканирования).
Подход к написанию Sigma-правил для zero-day:
- Изучить описание уязвимости: какой процесс эксплуатируется, какой тип активности генерируется (создание дочернего процесса, сетевое подключение, изменение файла).
- Описать «нормальное» поведение процесса - baseline.
- Описать отклонение, характерное для эксплуатации.
YAML:
title: Suspicious Child Process from VPN Appliance Service
status: experimental
logsource:
category: process_creation
product: windows
detection:
selection:
ParentImage|endswith:
- '\FortiClientEMS.exe' # FortiClient EMS Windows service process
- '\fcmDaemon.exe' # FortiClient EMS daemon process
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
- '\certutil.exe'
condition: selection
level: highОграничение: Sigma-правила эффективны только при наличии качественных логов. Если EventLog на endpoint не включает Sysmon или расширенный аудит - правило не сработает, потому что нечего анализировать. Правило без логов - как детектор дыма без батарейки.
Метрики, которые определяют вашу устойчивость к zero-day
Нельзя управлять тем, что не измеряешь. Три метрики определяют, насколько организация готова к zero-day:
| Метрика | Что измеряет | Целевое значение | Красная зона |
|---|---|---|---|
| MTTD (Mean Time to Detect exposure) | Время от публикации CVE до ответа "затронуты/не затронуты" | < 4 часа | > 24 часа |
| MTTP (Mean Time to Patch) - Critical | Время от выхода патча до установки на 95% активов | < 48 часов для CISA KEV | > 14 дней |
| Compensating Control Deployment Time | Время от решения о CC до его развёртывания | < 2 часа (WAF-правило), < 8 часов (EDR-правило) | > 24 часа |
MTTP для критических уязвимостей и MTTP для zero-day - разные процессы. Для zero-day из CISA KEV (SSVC decision = "Act") патчинг должен быть экстренным, вне плановых Change Windows. CISA устанавливает обязательные сроки - для CVE-2025-62221 дедлайн был 21 день (добавлена 2025-12-09, срок до 2025-12-30). Если ваш MTTP для Critical больше 14 дней - вы не укладываетесь даже в CISA-дедлайн. Стоит задуматься.
Подробный разбор метрик VM-программы: Метрики управления уязвимостями: MTTP, SLA по severity, coverage rate и реальная эффективность VM-программы.
CTEM: почему реактивный патчинг проигрывает zero-day гонку
Классический vulnerability management работает по схеме: сканер нашёл CVE -> SOC приоритизировал -> IT запатчил. Для zero-day этот конвейер слишком медленный, а для N-day - слишком неточный в приоритизации.CTEM (Continuous Threat Exposure Management) - подход Gartner, предлагающий пять фаз вместо реактивного цикла:
- Scoping - определение бизнес-критичных активов и процессов
- Discovery - непрерывное обнаружение экспозиции (не только CVE, но и misconfiguration, чрезмерные привилегии, exposed credentials)
- Prioritization - risk-based, с учётом exploit availability (EPSS), business context и exposure
- Validation - подтверждение, что уязвимость реально эксплуатируема в вашем контексте (не теоретический CVSS, а реальный path to impact)
- Mobilization - автоматизированное создание задач на remediation с SLA и эскалацией
Чем CTEM конкретно отличается от реактивного подхода: CTEM vs реактивный патчинг: от CVE-гонки к непрерывному управлению поверхностью атаки.
OSINT-конвейер: как узнать о zero-day раньше, чем он долетит до вас
Threat intelligence - не подписка на рассылку. Это конвейер, который превращает сырые данные в actionable alerts для вашего SOC.Источники ранней информации о zero-day:
- CISA KEV (Known Exploited Vulnerabilities) - каталог CVE, подтверждённо эксплуатируемых в дикой природе, с обязательными сроками патчинга для федеральных агентств США. Работает как фильтр приоритизации: если CVE попала в KEV - это не теоретический риск, а подтверждённая атака.
- OTX AlienVault пульсы - community-driven intelligence. Для CVE-2020-1472 (Zerologon) зафиксировано 50+ пульсов, включая связь с конкретными APT-кампаниями (например, пульс "From a Single Click: How Lunar Spider Enabled a Near Two-Month Intrusion" от DFIR Report).
- Vendor-advisories - MSRC для Microsoft, RHSA для Red Hat, USN для Ubuntu. Автоматизация парсинга этих источников сокращает MTTD.
- NCSC-UK, CERT-FR - национальные CERT выпускают advisories часто раньше, чем информация доходит до русскоязычных ресурсов.
- EPSS (Exploit Prediction Scoring System) - вероятностная модель, предсказывающая эксплуатацию CVE в ближайшие 30 дней. CVE-2020-1472 имеет EPSS 0.9951 (percentile 99.94%) - экстремальная вероятность. Это сигнал к немедленным действиям, даже если ваш сканер показывает CVSS "medium".
Реальные CVE, которые меняли правила игры: уроки для защиты
Каждый крупный zero-day инцидент оставляет после себя паттерны, которые можно использовать для подготовки к следующему. Разберём несколько показательных кейсов.
CVE-2020-1472 (Zerologon) - когда всё рушится за один запрос
Уязвимость в протоколе Netlogon (MS-NRPC) позволяла неаутентифицированному атакующему с сетевым доступом к контроллеру домена получить привилегии доменного администратора. EPSS: 0.9951. CISA KEV: "Act" с пометкой "ransomware-related".Урок для защиты: сегментация сети, ограничивающая прямой доступ к контроллерам домена из пользовательских сегментов, - единственный compensating control, который работал в первые дни после раскрытия. Организации с flat-network получали полную компрометацию домена за минуты. Flat network + Zerologon = game over.
Патчи: Microsoft - KB 4601319, KB 4601384. Red Hat (Samba) - RHSA-2020:5439, RHSA-2021:1647. Ubuntu - USN-4559-1, USN-4510-1, USN-4510-2.
CVE-2025-62221 - use-after-free в Windows, активная эксплуатация
Use-after-free в Windows Cloud Files Mini Filter Driver (CWE-416, CVSS 7.8). Требует авторизованного локального пользователя для повышения привилегий. CISA SSVC: "Act", добавлена в KEV 2025-12-09 с дедлайном 2025-12-30. Exploitation: active, Technical Impact: total.Урок для защиты: даже "локальная" уязвимость с CVSS 7.8 становится критической, когда атакующий уже получил начальный доступ через другой вектор - фишинг, другой zero-day, скомпрометированный VPN. Compensating control: ASR-правила Microsoft Defender, запрет на запуск неподписанных исполняемых файлов, мониторинг аномальных crash-событий от
cldflt.sys. Видите BSOD от этого драйвера - бегите проверять логи.CVE-2021-20016 - SonicWall VPN: SQL-инъекция без аутентификации
SQL-инъекция в SonicWall SSLVPN SMA100 (CWE-89, CVSS 9.8). Неаутентифицированный удалённый атакующий получал доступ к логинам, паролям и данным сессий. Эксплуатировалась в дикой природе с января 2021. CISA: Automatable=yes, что означает массовое сканирование и автоматизированную эксплуатацию - в отличие от CVE-2025-62221, где Automatable=no и требуется предварительный локальный доступ.Урок для защиты: VPN-аплайнсы - часть вашего периметра, но не часть вашей стандартной VM-программы. Многие их "забывают" в сканах - и это системная проблема. Она затрагивает разных вендоров: NCSC-UK в июне 2026 выпустил специальный алерт о глобальном таргетировании Fortinet firewalls и VPN gateways - другой вендор, но тот же паттерн атак на периметровые устройства. Ваш VPN-аплайнс - не "сетевое оборудование, которое само о себе позаботится". Это часть периметра, которая требует такого же VM-процесса, как и веб-приложение.
Разбор конкретного кейса Fortinet: CVE-2026-35616 FortiClient EMS: разбор уязвимости, вектор атаки и методы обнаружения.
Как раннее раскрытие kernel LPE уязвимостей открывает окно для атак: Kernel local privilege escalation: как преждевременное раскрытие открывает окно эксплуатации.
Цепочка поставок ПО и SBOM: подготовка к zero-day, которого ещё нет
Вопрос "затронуты ли мы?" - это вопрос инвентаризации, а не безопасности. Организации, которые не знают, какие библиотеки и компоненты содержатся в их продакшен-образах, обречены на многодневный hunting по Dockerfiles и Helm-чартам при каждом новом zero-day. Каждый раз - как в первый раз.
SBOM (Software Bill of Materials) решает эту проблему: индексированный список всех компонентов с версиями, привязанный к каждому deployed-артефакту. При появлении нового CVE - один запрос к SBOM-базе вместо недельного расследования.
Требования регуляторов подтягиваются: NIST SP 800-190 §4.1.4 требует SBOM-chain для федеральных контейнерных развёртываний. PCI DSS 4.0 и CMMC 2.0 вводят аналогичные требования в частный сектор. OWASP A06:2021 (Vulnerable and Outdated Components) напрямую описывает риск неконтролируемых зависимостей.
Для GNU/Linux-инфраструктуры критически важна проблема backport-патчей - когда дистрибутив бэкпортирует исправление безопасности без смены мажорной версии пакета, стандартные сканеры могут не обнаружить, что уязвимость уже закрыта (или наоборот - что она ещё открыта). Подробный разбор: Обнаружение CVE в ядре Linux: автоматизация поиска незакрытых уязвимостей в backport-патчах.
Отдельный кейс для WordPress-инфраструктуры: плагины как неконтролируемая цепочка поставок. Разбор эксплуатации и защиты: Уязвимость Ninja Forms RCE CVE-2026-0740: полный разбор эксплуатации и защиты WordPress.
Проактивная валидация: Red Team, Bug Bounty и пентест как щит от zero-day
Compensating controls и мониторинг - реактивная сторона защиты. Проактивная - поиск уязвимостей до злоумышленника.Red Team тестирует не отдельную уязвимость, а всю цепочку: от initial access (T1190) через privilege escalation (T1068) до lateral movement (T1210) и exfiltration. Red Team отвечает на вопрос: "Если атакующий найдёт zero-day в нашем edge-устройстве - насколько глубоко он пройдёт?"
Bug Bounty привлекает внешних исследователей для поиска уязвимостей в вашем периметре до того, как они попадут на теневой рынок. Responsible disclosure - механизм, который определяет, станет ли обнаруженная уязвимость zero-day или нет.
Пентест отличается от Red Team фокусом: пентест проверяет конкретные системы и компоненты, Red Team проверяет организацию. Для zero-day readiness оба подхода дополняют друг друга.
Все три подхода не предотвращают zero-day. Они сокращают поверхность атаки и выявляют слабости compensating controls до того, как реальный zero-day их проверит. Разница - между "мы знаем, что сегментация работает" и "мы надеемся, что сегментация работает".
Что изменится в ближайший год и что делать прямо сейчас
AI ускоряет обе стороны: атакующие используют ML для автоматизации фаззинга и генерации эксплойтов, защитники - для поведенческой детекции и приоритизации. Конвергенция IT и OT расширяет поверхность атаки за пределы традиционного периметра. Регуляторное давление (ФЗ-187 для КИИ, требования к SBOM в западных юрисдикциях) превращает vulnerability management из "хорошей практики" в обязательство с измеримыми SLA.Три действия, которые можно выполнить сегодня:
- Измерьте свой MTTD. Возьмите последнюю критическую CVE из CISA KEV и проверьте: сколько времени заняло определение, затронуты ли вы? Если больше 4 часов - проблема в asset inventory, не в процессе реагирования.
- Подготовьте один compensating control заранее. Выберите самый вероятный вектор атаки (VPN-аплайнс, web-приложение, edge-сервис) и настройте WAF-правила, EDR-политики и сетевую сегментацию сейчас, а не во время инцидента.
- Запустите OSINT-конвейер мониторинга. Автоматизированный парсинг CISA KEV + EPSS + vendor advisories с нотификацией в Slack/Teams при появлении CVE, затрагивающей ваш стек.
Практикуйтесь на реальных сценариях
Если вы строите SOC или развиваете навыки реагирования на инциденты, теория без практики - это чтение описания пожара вместо учебной тревоги. В Codeby Academy можно отработать сценарии обнаружения, сдерживания и реагирования на эксплуатацию уязвимостей в контролируемой среде - с обратной связью от действующих специалистов.Большинство команд безопасности, которых я наблюдал за последние годы, проигрывают zero-day не из-за отсутствия инструментов. EDR стоит, SIEM работает, WAF настроен. Проблема в другом - разрыв между "у нас есть инструмент" и "мы знаем, что делать в первые 60 минут после бюллетеня". На практике этот разрыв заполняется паникой: кто-то бежит в Slack, кто-то грепает Dockerfiles, кто-то звонит вендору. К пятнице первой недели экспозиция частично определена, к вторнику второй - hot-fix в CI. Две недели. Эксплойт тем временем публичный десять дней.
Что реально меняет картину - не новый продукт, а операционная готовность. Подписанный SBOM на каждый deployed-артефакт. Реестр, индексирующий каждый пакет по имени и версии. Pipeline, который пересобирает при upstream CVE disclosure. Runbook, который SOC-аналитик не видит впервые во время инцидента. Всё это - инженерная работа, которая делается в мирное время, а возвращает вложения в тот самый час, когда Slack загорается красным.
Тревожная тенденция - индустрия всё больше полагается на "zero-day detection" как на маркетинговую категорию. Вендоры продают обещание "мы обнаружим неизвестное», а покупатель перестаёт вкладываться в скучные вещи: asset inventory, сегментацию, минимизацию base images. По факту, самый эффективный "zero-day control" - не детекция, а уменьшение числа мест, куда zero-day может приземлиться. Каждая библиотека, которую вы не включили в образ, - это CVE, которую вам не придётся закрывать в три часа ночи. Каждый сервис, который вы не выставили в интернет, - это вектор, которого атакующий не увидит. Минимализм - не эстетика. Это стратегия выживания, когда окно эксплуатации измеряется часами.
Последнее редактирование модератором:
