Source: The Hacker News — https://thehackernews.com/2026/05/cert-in-mandates-12-hour-patching-for.html
CERT-In сокращает время на исправления#
Индийский CERT-In выпустил новые рекомендации: известные эксплуатируемые уязвимости на системах, доступных из интернета, и на критичных системах нужно устранять в течение 12 часов там, где это возможно. Ведомство связывает такой срок с понятным фактором давления: эксплуатация с помощью AI может резко сократить время, которое атакующим нужно на поиск открытых сервисов, анализ багов, подготовку фишингового контента и масштабирование кампаний.
Формулировки важны. CERT-In не утверждает, что любой критичный баг в любой среде всегда можно исправить за полдня. В рекомендациях используется риск-ориентированный подход и оговорка «where feasible» — где это выполнимо. Но сигнал все равно жесткий: публично доступные системы с уже известной эксплуатацией больше нельзя держать в обычном бэклоге. Это срочная экспозиция.
38-страничный план CERT-In описывает AI как усилитель уже существующих киберопераций. Документ упоминает поиск поверхности атаки, анализ эксплойтов, злоупотребление слабыми учетными записями, атаки на небезопасные API, обнаружение ошибок конфигурации, генерацию вредоносного ПО и более убедительный фишинг. Это не новые категории атак. Меняются скорость и масштаб.
Практический вывод простой: AI не обязан изобретать новый класс уязвимостей, чтобы изменить работу защитников. Достаточно ускорить старый рабочий процесс.
Какие сроки исправления предлагает CERT-In#
Самая конкретная часть рекомендаций — сроки устранения уязвимостей. CERT-In советует вести непрерывное риск-ориентированное управление уязвимостями и патчами, а максимальный приоритет отдавать системам, которые доступны из интернета, критичны для бизнеса или уже затронуты известной эксплуатацией.
В отчете указаны такие целевые сроки:
- Известные эксплуатируемые уязвимости во внешних и критичных системах: в течение 12 часов, где применимо.
- Критичные уязвимости, доступные извне: в течение 1 дня.
- Известные эксплуатируемые уязвимости во внутренних системах: в течение 1 дня, если не внедрены и не задокументированы другие меры снижения риска.
- Критичные внутренние уязвимости в высокоценных системах: в течение 3 дней.
- Уязвимости высокой степени опасности: в течение 5 дней с учетом риск-приоритизации.
Для многих организаций именно 12 часов станут главным заголовком. Но сложнее не сам срок, а все зависимости за ним. Команда не сможет патчить за 12 часов, если не знает, чем владеет, что открыто наружу, какие системы критичны, кто согласует простой и какие компенсирующие меры уже доступны.
Поэтому это не только политика патч-менеджмента, а проверка операционной зрелости. Быстрое исправление зависит от инвентаризации активов, управления экспозицией, разведки уязвимостей, процесса изменений, уверенности в резервных копиях и координации инцидентов. Без этого срок превращается в лозунг.
Если патча нет, снижение риска тоже считается#
CERT-In отдельно разбирает частую ошибку при срочной работе с уязвимостями: команда ждет аккуратный патч от вендора, пока уязвимый сервис остается доступен. Если патчи недоступны сразу, ведомство рекомендует временные меры: изоляцию, ограничение доступа, WAF или защиту API, усиленный мониторинг либо отключение затронутых функций до выхода исправления.
Это полезное различие. Устранение риска не всегда означает обновление пакета. Иногда ближайшая цель — убрать путь эксплуатации. Если уязвимый интерфейс можно снять с публичного интернета, закрыть более строгим контролем доступа или поставить под более надежный мониторинг, риск можно снизить еще до постоянного исправления.
Слабая версия такого подхода звучит как «мы поставили это за WAF» — без проверки. Сильная версия задокументирована: что изменили, какой путь атаки это блокирует, что осталось доступным, когда ожидается постоянное исправление и кто отвечает за доведение до конца. Формулировка CERT-In о документированных мерах для внутренних эксплуатируемых уязвимостей указывает именно в эту сторону.
На этом ломаются многие программы патч-менеджмента. Команды закрывают тикет после обходного решения, а затем теряют нить. Акцент в плане на непрерывной переоценке напоминает: временные меры не списывают долг. Они покупают время.
AI-системы тоже входят в поверхность атаки#
Рекомендации рассматривают AI не только как инструмент атакующего. CERT-In предупреждает, что AI-системы сами становятся целями. Ведомство называет prompt injection, утечки данных, jailbreaking, манипуляцию моделями, отравление обучающих данных, кражу моделей и компрометацию orchestration pipeline как риски для конфиденциальности и целостности.
Это важно, потому что многие программы безопасности до сих пор выносят «AI-риск» в отдельное обсуждение по governance и не включают его в ежедневное управление экспозицией. Подход CERT-In шире. AI-интеграции, API, зависимости моделей, orchestration-слои, потоки данных и сторонние модели становятся частью операционной поверхности атаки.
Ведомство также выделяет риски цепочки поставок, связанные со сторонним ПО, AI-моделями и зависимостями. Среди рекомендуемых мер — использование SBOM, проверка происхождения и оценки. Эти меры не остановят каждую атаку, а SBOM сам по себе не делает систему безопасной. Но они помогают быстро ответить на базовый вопрос под давлением: затронуты ли мы и где именно?
Когда сроки эксплуатации сжимаются, такой ответ ценен.
Что защитникам стоит забрать в работу#
План повторяет несколько знакомых принципов безопасности: assume breach, Zero Trust, defense in depth, secure by design, защита чувствительных данных, операционная непрерывность, red teaming, оценка уязвимостей, penetration testing, независимые аудиты и формальное AI governance.
Список широкий. Полезнее всего порядок приоритетов, который следует из модели угроз. CERT-In предлагает в первую очередь защищать системы, доступные из интернета, критичные бизнес-приложения, учетные записи, облачные среды, API, чувствительные данные, AI-системы и операционную инфраструктуру.
Это разумная приоритизация. Атакующим обычно не нужен самый изящный путь. Им нужен достижимый путь. Внешние сервисы, слабые учетные записи, неуправляемые API и ошибочно настроенные облачные активы остаются целями с высокой отдачей, особенно когда автоматизация снижает стоимость поиска.
Практический ответ начинается с нескольких проверок:
- Может ли организация быстро выдать актуальный список активов, доступных из интернета?
- Сопоставляются ли известные эксплуатируемые уязвимости с этим списком ежедневно, а не раз в месяц?
- Помечены ли критичные системы достаточно ясно, чтобы ускорять действия?
- Есть ли утвержденный экстренный процесс изменений для эксплуатируемой внешней экспозиции?
- Документируются ли меры снижения риска, когда патчи нельзя применить сразу?
- Включены ли AI-системы и AI-интеграции в проверки активов, учетных записей, логирования и потоков данных?
Если ответ «нет», 12-часовая рекомендация все равно полезна. Она показывает разрыв.
Чего не стоит преувеличивать#
Рекомендации не доказывают, что каждый атакующий уже успешно использует frontier AI-модели против любой цели. Они также не означают, что одних патчей достаточно. Сам документ CERT-In связывает риски с учетными записями, API, облачными средами, цепочками поставок, операционными технологиями и AI-процессами.
Самый сильный вывод, который действительно подтверждает источник, уже и практичнее: защитникам стоит ожидать сокращения сроков эксплуатации, особенно для открытых и известных уязвимых систем, и настраивать процессы патчинга и снижения риска с учетом этого предположения.
Этого достаточно, чтобы менять политику. Уязвимость на внутренней системе с низкой ценностью может проходить через обычную риск-ориентированную обработку. Известный эксплуатируемый баг на публичной критичной системе не может ждать ближайшего удобного окна обслуживания, если у организации нет защищаемой и проверенной меры снижения риска.
Давление не теоретическое. Оно операционное. Публичный периметр нужно знать, наблюдать и уметь быстро чинить.