Патч-менеджмент после WannaCry: пересматриваем SLA с 30 до 7 дней для CVSS>=9

60 дней. MS17-010 вышел 14 марта, WannaCry ударил 12 мая. Двух месяцев оказалось недостаточно, чтобы патч добрался до сотен тысяч машин по всему миру. Это не технический сбой - это провал патч-менеджмента как процесса.

Мы занимаемся managed-обслуживанием инфраструктуры уже давно, и WannaCry стал моментом, когда стало неудобно смотреть на собственные SLA. Не потому что клиенты пострадали - не пострадали. Потому что мы сами задали вопрос: а за сколько дней мы гарантируем установку критического патча? И ответ оказался «до 30 дней», что после этой эпидемии звучит несколько иначе.

Почему 30 дней больше не работает

Стандартный корпоративный цикл патчей выглядит примерно так: вторая среда месяца - «Patch Tuesday», неделю-две тестирование на стейдже, потом раскатка по prod за несколько дней в согласованное окно. Итого - 3-4 недели от выпуска до боевой системы. Для большинства патчей это разумный баланс между скоростью и стабильностью.

Но MS17-010 - это не большинство патчей. CVSS 9.3, удалённое выполнение кода без аутентификации, эксплойт в открытом доступе с апреля. При таком профиле риска четыре недели на установку - это четыре недели открытой двери.

Из того, что мы видим в постмортемах и публичных разборах: типичная картина у пострадавших компаний - не злой умысел и не полное игнорирование обновлений. Чаще всего это нормальный по меркам компании процесс, который просто не делал различий между «CVE средней тяжести для корпоративных принтеров» и «публичный эксплойт для уязвимости уровня SYSTEM без аутентификации в протоколе, открытом на всех Windows-машинах сети».

Это два разных зверя, и обращаться с ними одинаково - ошибка.

Что меняем

Мы пересматриваем SLA для своих managed-клиентов. Не декларативно, а как жёсткое разграничение в договоре.

Патчи с CVSS < 9.0 - остаются на старом цикле. Тестирование, согласованные окна, стандартный ежемесячный ритм. Здесь торопиться незачем, риск деградации сервиса превышает риск эксплуатации в большинстве сценариев.

Патчи с CVSS >= 9.0 или с публичным эксплойтом в дикой природе - не более 7 рабочих дней. Это означает: сокращённый цикл тестирования, приоритизация над остальными задачами, установка в ближайшее доступное окно, а не в плановое. Для систем с исключительными ограничениями по доступности - компенсирующие меры (изоляция, WAF, отключение уязвимого компонента) параллельно с патчингом.

Нулевая терпимость к дырам на периметре. Если CVSS >= 9.0 и уязвимый сервис доступен из интернета - 48 часов или немедленная изоляция. Никаких согласований с «а вдруг что-то сломается».

На практике 7 дней для критического патча - это жёстко. Это означает пересмотр процедуры тестирования для критических обновлений: не полный регрессионный прогон, а целевое тестирование функционала, который обновление затрагивает. Это означает дежурных, которые физически доступны вне планового окна, если эксплойт уже в дикой природе. Это означает актуальный реестр всех установленных ОС и версий ПО - иначе сам факт уязвимости обнаружится не за семь дней, а за семь недель.

Инвентаризация как фундамент

Здесь мы столкнулись с неприятной правдой у нескольких клиентов. После 12 мая мы прошлись по инфраструктуре и спросили: покажи мне все Windows-хосты с версией ОС и статусом KB4012212. И оказалось, что не везде на это можно было ответить точно.

Не потому что кто-то халтурил. А потому что инвентарь вёлся в трёх разных местах, данные расходились, и «мы всё пропатчили» означало «мы прошлись по тому, что знали». Хосты в ОС-обновлениях через WSUS не появлялись по разным причинам: отключён агент, другой домен, изолированный сегмент без выхода к серверу обновлений.

WannaCry сделал видимой проблему, которую легко было не замечать в штатном режиме. Один пропущенный хост в правильном сегменте - и вся история с патчем и изоляцией SMBv1 теряет смысл.

Рабочий патч-менеджмент начинается с реестра. Не «у нас WSUS, и он всем управляет», а «у нас список каждого хоста, и мы знаем, что на нём стоит». Это скучно, это требует поддержки, и именно поэтому в большинстве компаний это не сделано нормально.

Где мы сейчас

Наши клиенты не пострадали - механику и почему именно мы разбирали раньше. Но этот инцидент показал: одно дело - не попасть под конкретную атаку, другое - иметь процесс, который гарантирует это системно.

Новые SLA мы внедряем прямо сейчас. Параллельно запускаем аудит реестров у действующих клиентов - смотрим, где инвентарь расходится с реальностью. Этот процесс неприятный, потому что он обнаруживает то, что никто особо не хотел видеть. Но лучше обнаружить сейчас, чем узнать в следующий раз, когда придёт очередной WannaCry.

А он придёт. MS17-010 - не единственная такая уязвимость, просто самая наглядная. Shadow Brokers ещё что-то придерживают, или не они одни знают такие вещи. Скорость патчинга - это не параметр комфорта, это параметр выживаемости.