Скорость реакции на zero-day: уроки Log4Shell, MOVEit, Ivanti и Cisco для России

Аналитический обзор SLEM Partners Group. Методология Stanford STORM: кейсы разобраны через вопросы от лица CISO, вендора, open-source-сообщества и регулятора и заземлены на первичные advisory вендоров и нормативные акты. Хронологии и метрики выверены; спорные тезисы переформулированы из «модель разработки» в «контролируемость цепочки поставки».

Методология и ограничения

• Метод: Stanford STORM — разбор кейсов через перспективы CISO, вендора, open-source-сообщества и регулятора; хронологии сверены с первичными advisory.
• Период: кейсы 2021–2025 (Log4Shell, MOVEit, Ivanti, Cisco).
• Ограничения: выборка из нескольких кейсов статистически непредставительна; «средний TTP» не выводится; сравнение библиотеки и сетевого устройства методологически неоднородно.

Рис. 1. Диапазон TTP по кейсам и доступность исправлений для организаций в РФ. Источники: [2]–[8].

1. Почему скорость реакции критична

Zero-day — уязвимость, для которой на момент начала эксплуатации нет официального патча. Ключевая метрика — Time-to-Patch (TTP): время от публичного раскрытия до выхода исправления. До появления патча защита держится только на временных мерах (отключение функционала, сегментация, правила WAF/IPS).

Для российских организаций после 2022 года к технической проблеме добавилась организационная: уход западных вендоров сделал получение патчей и поддержки негарантированным. Поэтому центральный вопрос обзора — не «open source против проприетарного ПО» как таковой, а контролируемость цепочки поставки: способна ли организация получить и применить исправление в принципе.

2. Уточнение тезиса (важное методологическое замечание)

Распространённое упрощение «open source патчится на порядок быстрее проприетарного» некорректно как универсальный вывод и легко опровергается. Во-первых, сравнение библиотеки (где «патч» — это коммит) с сетевым устройством (где патч — это прошивка) методологически неоднородно. Во-вторых, у open source есть и медленные случаи. В-третьих, по данным VulnCheck за 1П2025, массовую эксплуатацию в большей степени двигает именно проприетарное ПО (CMS-платформы, сетевой периметр, серверное ПО), чем open source [1].

Поэтому в этом обзоре мы не утверждаем превосходство одной модели разработки. Мы показываем, что в условиях санкций решающим фактором становится контроль над цепочкой поставки — возможность независимо получить, проверить и применить исправление.

3. Кейс 1. Log4Shell (CVE-2021-44228) — open source

Хронология (выверенная):

• Apache уведомлён 24 ноября 2021 года; публичная огласка и PoC — 9–10 декабря 2021 года.
• Log4j 2.15.0 (первое исправление) — 10 декабря 2021 года.
• Из-за неполноты фикса последовали итерации: 2.16.0 (13 декабря), 2.17.0 (17 декабря, CVE-2021-45105), 2.17.1 (28 декабря) [2].

Корректный вывод: первое исправление вышло практически сразу (TTP ≈ 1 день), но полное закрытие потребовало нескольких итераций до конца декабря — то есть «менее суток» относится к первому патчу, а не к окончательному устранению. Доступность для РФ была полной: код и патчи распространялись через Maven Central без гео-ограничений, организации могли независимо верифицировать diff и применить митигацию log4j2.formatMsgNoLookups=true.

Главный урок Log4Shell — не скорость, а персистентность: библиотека встроена в тысячи приложений, поэтому интеграция исправления в конечные продукты (в том числе российские) заняла недели и месяцы. Это ровно та проблема цепочки поставки, что и у проприетарных продуктов.

4. Кейс 2. MOVEit Transfer (CVE-2023-34362) — проприетарное ПО

Хронология (выверенная):

• Эксплуатация группой Cl0p фиксируется как минимум с 27 мая 2023 года (Mandiant), с признаками тестирования ранее.
• Progress Software опубликовала advisory и выпустила патч 31 мая 2023 года — в день раскрытия [3].

Исправление частой ошибки: здесь TTP ≈ 0 дней (патч вышел вместе с раскрытием). Цифра «4 дня» в ранних версиях ошибочно называлась TTP — на самом деле это разрыв между первой замеченной эксплуатацией (27 мая) и раскрытием (31 мая), то есть окно zero-day до раскрытия, а не время до патча. Урок кейса в другом: даже мгновенный патч бесполезен, если уязвимость уже эксплуатируется массово до огласки.

5. Кейс 3. Ivanti Connect Secure (CVE-2023-46805, CVE-2024-21887) — проприетарное ПО

Хронология (выверенная):

• 10 января 2024 года — раскрытие двух уязвимостей и публикация временной митигации; эксплуатация in the wild началась ещё до раскрытия (наблюдения Volexity, декабрь 2023).
• Полноценные патчи начали выходить с 31 января 2024 года и устанавливались поэтапно в феврале; позднее раскрылись дополнительные уязвимости (CVE-2024-21888, CVE-2024-21893) [4].

TTP ≈ 21 день для VPN-шлюза, через который идёт удалённый доступ в корпоративную сеть. В течение этого окна митигации лишь повышали сложность атаки, но не закрывали уязвимость полностью.

6. Кейс 4. Cisco — проприетарное ПО плюс санкционный фактор

CVE-2023-20198 (Cisco IOS XE Web UI), CVSS 10.0:

• Раскрытие — 16 октября 2023 года; эксплуатация активна с сентября 2023-го (zero-day in the wild); патч — 22 октября 2023 года (TTP ≈ 6 дней) [5].

CVE-2025-20393 — исправление существенной фактической ошибки. Эта уязвимость относится не к Cisco Smart Licensing Utility, а к Cisco Secure Email Gateway / Secure Email and Web Manager (RCE через функцию Spam Quarantine, CVSS 10.0). Cisco узнала о кампании атак 10 декабря 2025 года и выпустила обновления, закрывающие уязвимость (вопреки тезису «патч не выпущен / бессрочная уязвимость») [6]. Уязвимости Smart Licensing Utility — это отдельные записи CVE-2024-20439 и CVE-2024-20440, и они также были закрыты обновлениями [7].

Корректный санкционный вывод: проблема для российских организаций здесь не в отсутствии патча как такового, а в том, что после ухода Cisco из РФ (2022) легальный доступ к обновлениям, поддержке и порталу загрузки для российских аккаунтов ограничен [8]. То есть патч существует, но получить и применить его в правовом поле затруднительно — это и есть проблема контролируемости цепочки поставки, а не «вечной дыры».

7. Сводка кейсов (без ложной точности)

Сознательно не приводим «средний TTP проприетарных вендоров»: выборка из нескольких кейсов статистически непредставительна, и усреднять её — значит вводить читателя в заблуждение. Кейсы иллюстрируют диапазон, а не дают «среднюю по больнице».

8. Российская регуляторная рамка: сроки против реальности

Рекомендуемые сроки устранения уязвимостей в РФ задаёт Методический документ ФСТЭК от 17.05.2023 «Руководство по организации процесса управления уязвимостями»: критический уровень — до 24 часов, высокий — до 7 дней, средний — до 4 недель, низкий — до 4 месяцев [9]. (Это именно методический документ 2023 года, а не «приказ № 17 от 2013 года», с которым тезис ошибочно связывали ранее.)

Возникает объективное напряжение: для уязвимости критического уровня рекомендован срок до 24 часов, тогда как у проприетарного продукта без поддержки вендора патч может быть недоступен в принципе. Документ ФСТЭК это учитывает: при невозможности оперативной установки обновления допускается применение компенсирующих мер (блокировка на МЭ, сигнатуры в СОВ, отключение уязвимой службы, усиление мониторинга) [9]. То есть конфликт «срок против отсутствия патча» снимается легально — через компенсирующие меры, а не через невыполнимое требование.

9. Сертифицированный open source в РФ

Российские дистрибутивы на базе open source проходят сертификацию регуляторов: Astra Linux Special Edition имеет сертификаты ФСТЭК и ФСБ; РЕД ОС и «Альт» применяются на значимых объектах [10]. Это показывает, что модель open source не препятствует регуляторному соответствию, а при наличии национального вендора обеспечивает и гарантированный доступ к обновлениям, и поддержку — то есть закрывает именно проблему контролируемости.

10. Выводы

1. Скорость реакции критична: окно между раскрытием и массовой эксплуатацией измеряется днями, а во всё большей доле случаев эксплуатация предшествует раскрытию.
2. Дело не в «модели разработки» как лозунге: массовую эксплуатацию в 2025 году в большей мере двигает проприетарное ПО, но и у open source есть медленные случаи [1].
3. Решающий фактор в условиях санкций — контролируемость цепочки поставки: способность получить, проверить и применить исправление. Где её нет, даже выпущенный вендором патч не помогает.
4. Регуляторное напряжение снимается легально — через компенсирующие меры, предусмотренные методическим документом ФСТЭК.
5. Стратегический ответ — миграция на контролируемые решения (национальные и/или с гарантированным доступом к обновлениям) и развитие компетенций независимого аудита.

11. Рекомендации

1. Инвентаризировать цепочку поставки ПО: для каждого критического компонента — источник патчей, SLA вендора, правовой статус доступа в РФ.
2. Заранее готовить playbooks компенсирующих мер для zero-day на периметре (VPN, файрволы, почтовые шлюзы) — до выхода патча.
3. При импортозамещении выбирать решения с гарантированным каналом обновлений (национальный вендор, сертификация ФСТЭК).
4. Для транзитивных зависимостей (Log4Shell-тип): SBOM, мониторинг CVE в цепочке, процесс экстренного обновления встроенных библиотек.
5. Независимый аудит цепочки поставки — до инцидента, а не после.

12. Открытые вопросы

• Как обеспечить доступность 99,999% при миграции критической инфраструктуры на контролируемые решения?
• Как выстроить устойчивую экономику поддержки open source в РФ (аналог модели Red Hat/SUSE)?
• Как ИИ-инструменты изменят TTP и для вендоров, и для атакующих?

Источники

[1] VulnCheck — «State of Exploitation: 1H-2025» (проприетарное ПО — CMS, сетевой периметр, серверное ПО — больший драйвер массовой эксплуатации, чем open source). https://www.vulncheck.com/blog/state-of-exploitation-1h-2025/

[2] Apache Logging Services — Log4j Security Vulnerabilities (хронология 2.15.0–2.17.1). https://logging.apache.org/log4j/2.x/security.html

[3] Progress Software — MOVEit Transfer Critical Vulnerability (CVE-2023-34362), advisory и патч от 31.05.2023; Mandiant — эксплуатация с 27.05.2023. https://www.progress.com/moveit ; https://cloud.google.com/blog/topics/threat-intelligence/zero-day-moveit-data-theft

[4] Ivanti — Security Advisory CVE-2023-46805 / CVE-2024-21887 (раскрытие 10.01.2024, патчи с 31.01.2024); Volexity — эксплуатация до раскрытия. https://forums.ivanti.com/s/article/KB-CVE-2023-46805-Authentication-Bypass

[5] Cisco — Security Advisory cisco-sa-iosxe-webui (CVE-2023-20198), раскрытие 16.10.2023, патч 22.10.2023. https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-iosxe-webui-privesc-j22SaA4z

[6] Cisco — Security Advisory cisco-sa-sma-attack-N9bf4 (CVE-2025-20393, Cisco Secure Email Gateway / Web Manager; обновления выпущены). https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sma-attack-N9bf4

[7] Cisco — Security Advisory cisco-sa-cslu (CVE-2024-20439 / CVE-2024-20440, Smart Licensing Utility; обновления выпущены). https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-cslu-7gHMzWmw

[8] Reuters — «Cisco suspends business in Russia», 03.03.2022. https://www.reuters.com/business/cisco-suspends-business-russia-2022-03-03/

[9] Методический документ ФСТЭК России от 17.05.2023 «Руководство по организации процесса управления уязвимостями» (сроки 24 ч / 7 дней / 4 недели / 4 месяца; компенсирующие меры). https://www.consultant.ru/document/cons_doc_LAW_449516/

[10] Astra Linux — сертификаты и соответствие. https://astralinux.ru/information/security-certificates/