Индийский регулятор в сфере кибербезопасности предложил для части инцидентов почти аварийный режим: 12 часов на патч, временную защиту или полное снятие системы с внешней экспозиции. Для русскоязычных команд это важный сигнал: эпоха, когда на согласование окна обслуживания уходили недели, заканчивается там, где уязвимость уже эксплуатируют и сервис смотрит в интернет.
Об этом, как пишет The Register, говорится в новом руководстве CERT-In — индийской Computer Emergency Response Team. Речь не о всех дырах подряд, а о вполне конкретной категории: известных эксплуатируемых уязвимостях в internet-facing системах и в так называемых crown jewel systems, то есть в самых критичных активах компании. Для них рекомендация звучит предельно жестко: в разумно достижимых случаях закрыть уязвимость, поставить компенсирующую меру или убрать доступ извне в пределах половины суток.
Для остальных сценариев окно шире, но тоже без особой расслабленности. Если критическая уязвимость с оценкой CVSS 9.0 и выше затрагивает внутреннюю систему, либо известная эксплуатируемая уязвимость обнаружена во внутреннем контуре, CERT-In предлагает укладываться в 24 часа. На бумаге разница между 12 и 24 часами выглядит косметической, но на практике это две разные операционные модели. Первая требует заранее описанных playbook'ов, резервных схем, права быстро отключать публичный доступ и понятного владельца решения. Вторая еще оставляет шанс на согласования, тесты и более аккуратное развертывание.
Причина ужесточения понятна и в целом не нова: злоумышленники все активнее используют ИИ для ускорения разведки, поиска слабых мест, подготовки эксплуатации и дальнейшего перемещения по инфраструктуре. CERT-In прямо пишет, что AI-assisted cyber exploitation сокращает время, нужное атакующим для выявления и вооружения уязвимостей, поиска открытых сервисов, слабых учетных записей, небезопасных API и неверных конфигураций. Когда инфраструктура бизнеса завязана на облака, цепочки поставки ПО, операционные технологии и множество взаимосвязанных сервисов, даже одна дыра может быстро перестать быть локальной проблемой одного хоста.
Здесь особенно важна формулировка самой рекомендации. CERT-In не требует любой ценой накатывать полноценный продакшн-патч за 12 часов, как будто это кнопка Update в панели администратора. В руководстве есть развилка: patch, mitigate, or remove exposure. И вот это уже звучит реалистично. Не успеваешь протестировать обновление на критичном шлюзе, VPN, WAF или внешнем API-шлюзе — режь доступ, изолируй сегмент, отключай уязвимую функцию, ставь фильтр, меняй правила маршрутизации, переводи сервис в ограниченный режим. Для многих компаний именно такой сценарий и будет настоящим смыслом требования «12 часов на патч».
Опрошенные The Register специалисты по безопасности говорят примерно о том же. Старший менеджер по security operations в Huntress Дрей Агха поддержал подход CERT-In именно из-за оговорки про временные меры. По его оценке, когда команда явно разрешает не только патчить, но и срочно изолировать или ограничивать доступ, дедлайн превращается из недостижимого KPI в рабочую стратегию сдерживания. Это совпадает с тем, что многие практики и так советуют при критических инцидентах: сначала быстро вывести компанию из зоны немедленного риска, а уже потом доводить изменения до аккуратного, протестированного патча без лишнего ущерба для бизнеса.
Самое неприятное для ИТ-директоров и владельцев продуктов в этой истории даже не цифра 12. Неприятно то, что она бьет по старому компромиссу между безопасностью и доступностью. Долгие окна на тестирование, формальные CAB-согласования, зависимость от подрядчиков, ручные регламенты и отсутствие полномочий у дежурной смены больше не выглядят как «зрелый enterprise-процесс». В новой логике это, скорее, признак того, что компания не готова к скорости эксплуатации. Если уязвимость уже используется в атаках, вопрос стоит не в том, удобно ли вам обновляться, а в том, успеете ли вы выключить риск раньше, чем им воспользуются.
Для разработчиков и платформенных команд вывод тоже довольно приземленный. Требование 12 часов на патч невозможно выполнить, если безопасность начинается с письма в почте и заканчивается тикетом «обновить когда-нибудь». Нужны инвентаризация внешних активов, нормальная приоритизация crown jewel-систем, заранее утвержденные компенсирующие меры, автоматизация отката и хотя бы минимальная уверенность, что после отключения одного компонента у вас не сложится половина продукта. Иначе любая дискуссия про AI-assisted attacks останется красивой презентацией, а реальная реакция на эксплуатируемую уязвимость снова сведется к созвону на 40 человек и вопросу, кто вообще владеет этим сервисом.
Вероятно, именно в эту сторону и будет смещаться рынок: меньше разговоров про «патч-менеджмент по расписанию» и больше требований к непрерывной защитной готовности. Если рекомендации вроде индийских начнут копировать другие регуляторы и крупные заказчики, то главным конкурентным преимуществом окажется не самый красивый dashboard в SOC, а способность за часы, а не за дни, изолировать внешний риск без остановки бизнеса.