Новые методрекомендации ФСТЭК по КИИ на 2026 год: обязательный continuous monitoring для первой категории
ФСТЭК обновил методрекомендации по КИИ: для объектов 1-й категории вводится обязательный непрерывный мониторинг. Разбираем, что логировать и куда отправлять события.
ФСТЭК РФ публикует обновлённые методические рекомендации по КИИ на 2026 год с усиленными требованиями к мониторингу
В конце декабря ФСТЭК тихо опубликовал обновлённые методические рекомендации по обеспечению безопасности объектов КИИ на 2026 год. Документ вышел без пресс-релиза, нашли его через официальный сайт - скачали, почитали. Среди нескольких изменений одно выбивается из общего ряда по практическим последствиям: для объектов первой категории значимости вводится требование к непрерывному мониторингу событий безопасности.
Это не совсем новость - тренд на continuous monitoring зрел давно, и в итогах проверок за 2025 год ФСТЭК прямо указывал на неполноту журналов событий как на одно из лидирующих нарушений. Но теперь это оформлено методически: не «рекомендуется настроить», а конкретный перечень того, что должно отслеживаться, с какой периодичностью и куда отправляться.
Что изменилось в методрекомендациях
Структура документа осталась прежней - разделы по категорированию, защитным мерам, аттестации. Новое появилось в разделе по организационным мерам и оперативному контролю.
Ключевое изменение - обязательный перечень источников событий для объектов первой категории. Раньше документ говорил об «организации мониторинга» в общем виде, теперь приведён конкретный список классов систем, с которых события должны собираться непрерывно:
- средства защиты периметра (МЭ, IPS/IDS) - события блокировок и обнаружения аномалий;
- серверы и рабочие станции в критическом сегменте - входы/выходы, изменения привилегий, запуск процессов;
- прикладные системы, обеспечивающие технологический процесс, - специфические события отказов и нештатных состояний;
- системы управления доступом и аутентификации;
- оборудование АСУТП - там, где производитель предоставляет интерфейс экспорта событий.
По последнему пункту в документе сделана оговорка: если производитель АСУТП не предоставляет механизм экспорта событий, зафиксировать этот факт в документации системы защиты и применить компенсирующие меры на уровне сети. Разумный компромисс для тех случаев, где старое железо физически не умеет отдавать syslog.
Второе изменение - минимальная глубина хранения для объектов первой категории поднята до 180 дней. Раньше в методрекомендациях фигурировало «не менее 90 дней», теперь 180. Для тех, кто хранил ровно 90 дней, это прямая задача на расширение хранилища.
Третье - требование к передаче событий в ГосСОПКА. Это не новое требование само по себе, но теперь методрекомендации явно указывают, что для объектов первой категории передача должна быть настроена в режиме реального времени, а не по расписанию и не вручную по факту инцидента. У многих наших заказчиков интеграция с ГосСОПКА формально существует, но реально настроена в пакетном режиме - такая конфигурация больше не соответствует духу документа.
Как это выглядит на практике
У нас сейчас несколько активных аудитов объектов первой категории. Когда прочитали документ, сразу прикинули разрыв между тем, что есть у заказчиков, и тем, что теперь требуется.
Основная проблема не в SIEM и не в агентах на серверах - там как раз всё относительно решаемо. Реальная сложность в двух местах.
Первое - АСУТП. Часть оборудования действительно не умеет отдавать события никак, кроме проприетарного интерфейса. Мы разбирали это подробно в посте про интеграцию MaxPatrol SIEM: там нет универсального решения, нужно документировать каждый случай и выстраивать компенсацию на уровне сетевого мониторинга. Теперь это не просто хорошая практика - это то, что проверяющие будут искать в документации.
Второе - реальное время в ГосСОПКА. Переход с пакетного режима на потоковый - это не только техническая задача. У некоторых заказчиков есть ограничения на топологию сети: корпоративный сегмент и технологический изолированы, прямого пути до шлюза ГосСОПКА нет, приходится строить маршрут через промежуточные узлы. Это требует изменений в сетевой документации и согласования с СБ.
Что делать прямо сейчас
Если у вас объект первой категории - документ уже опубликован, и следующая плановая проверка будет смотреть именно на это. Несколько практических шагов, которые имеет смысл начать немедленно.
Провести инвентаризацию источников событий - составить список систем, которые входят в критический сегмент, и проверить, что каждая из них реально передаёт события в SIEM. Не «подключена» в интерфейсе, а именно передаёт - смотреть на последнее полученное событие, а не на статус подключения.
Проверить глубину хранения. Если сейчас меньше 180 дней - задача на расширение. Хорошо, если хранилище позволяет это сделать конфигурационно, без закупки. Если нет - лучше зафиксировать это сейчас, а не за неделю до проверки.
Проверить режим передачи в ГосСОПКА. Пакетный или реальное время - это видно в настройках коннектора. Если пакетный - посмотреть, что нужно изменить, и оценить сетевые ограничения.
Зафиксировать оборудование АСУТП без экспорта событий - отдельным разделом в документации системы защиты с описанием компенсирующих мер. Регулятор, судя по оговорке в документе, готов принять такую ситуацию - но только если она задокументирована, а не просто не упомянута.
Документ пока без чёткого срока введения в действие - методрекомендации обычно начинают применяться при ближайших плановых проверках, а не с конкретной даты. Но ждать плановой проверки, чтобы начать готовиться, - странная стратегия.