Регулятор задал конкретные дедлайны: критические уязвимости закрываются за 24 часа, высокого уровня – за 7 дней. Для большинства организаций это не ужесточение бумажной отчётности, а проверка реальной зрелости процессов. Команды, которые патчили инфраструктуру «в ближайшее окно обслуживания раз в месяц», в новые сроки физически не укладываются. Перестраивать нужно не регламент на бумаге, а цепочку от обнаружения уязвимости до подтверждённого устранения.

Где ломается классический процесс

Типичный сценарий: сканер находит критическую уязвимость в пятницу вечером, тикет попадает в общую очередь, в понедельник его смотрит дежурный, ищет владельца системы, согласует окно, ждёт регламентного простоя. Прошло пять дней – норматив в 24 часа нарушен ещё во вторник.

Три узких места повторяются почти везде:

  • Нет актуальной карты активов. Невозможно за сутки закрыть то, про что вы не знаете. Теневые серверы, забытые тестовые контуры, ПО без владельца – именно там уязвимость живёт месяцами.
  • Приоритизация вручную. Когда сканер выдаёт тысячи находок без привязки к критичности системы и реальной эксплуатируемости, инженер тонет в шуме и теряет те самые «24 часа».
  • Патчинг как ручная операция. Каждое обновление согласуют, выкатывают и проверяют люди. На десятках систем это не масштабируется в принципе.

Что перестроить в первую очередь

Начните с инвентаризации, а не с покупки нового сканера. Полная карта активов с владельцами, уровнем критичности и допустимым окном простоя – фундамент, без которого остальное не работает. Под каждый класс активов заранее зафиксируйте целевой срок: для систем, обрабатывающих значимые данные, – жёсткие 24 часа, для вспомогательных – норматив 7 дней.

Дальше – автоматическая приоритизация. Уязвимость ранжируется не по абстрактному CVSS, а по связке «критичность актива + наличие эксплойта в дикой природе + доступность извне». Это отсекает 80% шума и оставляет инженеру короткий список того, что действительно горит сегодня.

Третий шаг – конвейер патчинга. Тестовые и вспомогательные контуры обновляются автоматически с прогоном проверок, продуктивные – через заранее согласованные ускоренные окна с возможностью отката. Рутинные шаги – сбор находок, разбор логов, подготовку отчёта об устранении – стоит отдать автоматике: это ровно тот класс задач с проверяемым результатом и обратимыми последствиями, про который мы писали в разборе автономных ИИ-агентов. Человек принимает решение по спорным случаям, а не кликает каждое обновление вручную.

Регламент и доказуемость

Сроки нужно не только соблюдать, но и доказывать. Каждая находка получает отметку времени обнаружения, принятого решения и подтверждённого устранения – с автоматической эскалацией при приближении к дедлайну. Это та же дисциплина коротких циклов и измеримых результатов, что и при внедрении требований ФСТЭК по приказу № 117: процесс описан, шаги логируются, отчётность собирается из системы, а не вручную к проверке.

Отдельный вопрос – заказное и кастомизированное ПО. В коробочных продуктах патч приходит от вендора, в доработанных системах – например, заказной CRM – за устранение уязвимости в собственном коде отвечаете вы. Здесь критичны контракт на сопровождение и согласованный SLA на выпуск исправлений, иначе формальный 24-часовой норматив упрётся в очередь разработки.

Вывод

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