Индийский регулятор CERT-In ужесточил правила игры: на патчинг уязвимостей в интернет-доступных системах, если они уже эксплуатируются злоумышленниками, теперь отводится 12 часов, если это технически выполнимо. Для команд, у которых внешний периметр по-прежнему живет в ритме еженедельного change window, сигнал неприятный, но понятный: с ИИ у атакующих слишком короткий цикл, чтобы чинить «по удобному графику».
Новые рекомендации изложены в 38-страничном документе CERT-In, о чем сообщает The Hacker News. Логика у регулятора простая: AI-инструменты и большие языковые модели сокращают время между появлением уязвимости, ее анализом и реальной эксплуатацией. Если раньше у защитников еще был люфт на согласования, тесты и привычное «поставим в следующем окне», то теперь этот люфт сжимается до часов.
В документе перечислены сценарии, где ИИ помогает атакующим не на словах, а в операционке: поиск открытых сервисов, анализ эксплойтов, генерация правдоподобного фишинга, ускорение разработки вредоносного кода. Отдельно CERT-In указывает на слабые места, которые особенно опасны при таком темпе: небезопасные API, ошибочные конфигурации, слабые учетные записи и публично доступные сервисы. Иными словами, речь не только о «нулевых днях», а о старом наборе проблем, который теперь можно масштабировать быстрее и дешевле.
Самое практичное в новых рекомендациях — четкие сроки. Известно эксплуатируемые уязвимости в интернет-доступных и критичных системах предлагается устранять в течение 12 часов, где это применимо. Для критических внешних уязвимостей без подтвержденной эксплуатации ориентир — 1 день. Для известных эксплуатируемых уязвимостей во внутренних системах — тоже 1 день, если не введены и не задокументированы другие компенсирующие меры. Критические внутренние уязвимости в high-value системах — до 3 дней, уязвимости высокой степени тяжести — до 5 дней с учетом риск-приоритизации. Это уже не абстрактный «risk-based approach», а вполне конкретная линейка SLA, по которой удобно проверять зрелость процессов.
Если патча нет, CERT-In не предлагает делать вид, что проблемы нет. Вместо этого регулятор рекомендует временные меры: изоляцию системы, ограничение доступа, включение WAF или защиты API, усиленный мониторинг, отключение отдельных функций до выхода исправления. Для ИТ-руководителей здесь нет магии, но есть неприятный организационный вывод: патчинг уязвимостей перестает быть задачей только для инфраструктурной команды. Нужны заранее согласованные обходные сценарии с безопасниками, DevOps, владельцами продуктов и, в идеале, с бизнесом, который обычно первым спрашивает, почему «временно выключили половину интеграции».
Отдельный блок документа касается уже не классических ИТ-систем, а самих ИИ-платформ. CERT-In предупреждает о prompt injection, утечках данных, jailbreaking, манипуляции моделями, отравлении обучающих данных, краже моделей и компрометации orchestration-пайплайнов. Это важный сдвиг в риторике регуляторов: ИИ здесь рассматривается сразу в двух ролях. С одной стороны, как ускоритель атак на обычную инфраструктуру. С другой — как самостоятельная поверхность атаки, которую тоже нужно инвентаризировать, мониторить и защищать. Для компаний, которые уже подключили LLM к внутренним сервисам, поддержке или разработке, это неприятное напоминание: новый слой автоматизации приносит не только ROI в презентации, но и новый класс инцидентов.
Поэтому рекомендации не ограничиваются дедлайнами на исправления. CERT-In отдельно подчеркивает принципы, которые давно звучат как база, но теперь поданы без романтики: assume breach, Zero Trust, defense-in-depth, secure-by-design, защита данных на всем жизненном цикле, управление рисками цепочки поставок через SBOM и проверку происхождения компонентов, регулярные red teaming, pentest и независимые аудиты. В документе также есть акцент на формальное управление использованием ИИ и на видимость того, где именно в компании работают AI-системы, с чем они интегрированы и как ведут себя в проде. Для многих организаций именно эта часть окажется сложнее, чем сам патчинг уязвимостей: закрыть CVE за 12 часов трудно, но хотя бы понятно; построить реестр AI-интеграций и реальный контроль над ними часто еще труднее.
Контекст у этой истории тоже показательный. Месяцем ранее CERT-In уже выпускал предупреждение о растущих кибервозможностях frontier-моделей от Anthropic и OpenAI. Тогда регулятор прямо писал об их dual-use-природе: такие системы могут снижать порог входа для злоумышленников, автоматизировать эксплуатацию и масштабировать киберкампании. Новый документ выглядит как следующий логичный шаг: от общей тревоги по поводу ИИ к конкретным операционным требованиям. Не «будьте внимательны», а «вот ваши часы на исправление».
Для русскоязычной ИТ-аудитории эта история важна не потому, что речь идет об Индии. Важен сам вектор: регуляторы и корпоративная безопасность начинают пересобирать процессы под допущение, что атакующий больше не тратит дни на ручную разведку и сборку цепочки атаки. Если это допущение становится нормой, то патчинг уязвимостей, управление внешним периметром, инвентаризация API и контроль AI-интеграций неизбежно превращаются из фоновой гигиены в вопрос выживаемости. Следующий спор в отрасли, похоже, будет не о том, помогает ли ИИ атакующим, а о том, какая компания реально способна жить с 12-часовым окном, а какая пока только пишет это в политике безопасности.