ADG Оставить заявку
Блог Регуляторика 4 мин чтения

Итоги H1 2026 по КИИ: 73% нарушений - про мониторинг, не про железо

ФСТЭК публикует обезличенную статистику проверок КИИ за первое полугодие 2026. Разбираем цифры и делаем выводы для практики.

Контекст момента

ФСТЭК публикует обезличенную статистику проверок объектов КИИ за H1 2026 с распределением нарушений по категориям

На прошлой неделе ФСТЭК опубликовал обезличенную сводку по итогам проверок объектов КИИ за первое полугодие 2026. Это не пресс-релиз и не отчёт с громким заголовком - технический документ на сайте регулятора, который несложно пропустить. Мы его не пропустили, потому что занимаемся аудитом КИИ и эти цифры напрямую влияют на то, как мы строим работу с заказчиками.

Самое интересное - не в абсолютных числах проверок, а в распределении нарушений по категориям.

Что показывает статистика

Согласно публикации, 73% всех выявленных нарушений относятся к двум кластерам: организация мониторинга и реагирование на инциденты. Технические средства защиты - сертифицированные МЭ, антивирусы, системы обнаружения вторжений - дают оставшиеся 27%.

Иначе говоря: три четверти претензий регулятора - это не «у вас нет нужного железа» и не «версия прошивки устарела». Это «вы не видите, что происходит в вашей инфраструктуре» и «вы не умеете на это реагировать».

Для нас это не сюрприз - мы видели тот же паттерн на мартовских проверках Q1: инспекторы последовательно запрашивают выборки событий из SIEM, смотрят хронологию и задают вопрос про разрывы. Но то, что регулятор собрал это в статистику и опубликовал, - это сигнал уже системного уровня.

Что конкретно нарушают

Из описания в документе можно восстановить типовые картины. ФСТЭК не называет объекты, но группирует нарушения по признакам.

Неполное покрытие источников событий. Промышленные контроллеры, SCADA-системы, специализированное оборудование АСУТП - туда SIEM зачастую не дотягивается. Причины стандартные: нет стандартного интерфейса экспорта, производитель не поддерживает syslog, интеграция требует доработки под конкретную модель. В январских методрекомендациях регулятор сделал оговорку про компенсирующие меры для такого оборудования - но компенсация должна быть задокументирована, иначе это нарушение.

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

Реагирование без процедуры. Инцидент зафиксирован в SIEM - что дальше? Если ответ «ну, кто-то посмотрит», это не процедура реагирования. Регулятор спрашивает: есть ли документ, кто дежурный, каков порядок эскалации, есть ли журнал разбора инцидентов. Отсутствие этих артефактов - отдельная строчка в предписании.

Передача в ГосСОПКА не в реальном времени. Пакетный режим вместо потокового - нарушение для первой категории. Многие объекты настроили интеграцию давно, в пакетном режиме, и не переводили. Теперь это видно в проверках.

Почему технические средства дают только 27%

Отчасти это хорошая новость: отрасль в целом освоила базовый набор сертифицированных решений. Сертифицированный МЭ, антивирус, СЗИ НСД - это уже не редкость. Плохая новость в том, что технические средства сами по себе не работают без процессов вокруг них.

Это то, с чем мы сталкиваемся на практике регулярно. Заказчик потратил серьёзные деньги на SIEM, выстроил архитектуру сбора событий - а потом оказывается, что три сегмента ОТ не подключены, потому что «там сложный вендор, разберёмся потом». Или правила корреляции не обновлялись два года. Или дежурный аналитик SOC физически не успевает разбирать алерты, и они просто накапливаются.

Регулятор, похоже, это понял раньше многих объектов.

Что это значит для наших проектов

Статистика H1 подтверждает вектор, который мы и так видели в отдельных проверках. Но теперь у нас есть общий ориентир для разговора с заказчиками.

Первое: инвентаризация покрытия источников - это не разовая задача. После любого изменения инфраструктуры нужно проверять, все ли новые узлы передают события.

Второе: непрерывность мониторинга - это метрика, которую надо мерить. Если SIEM не получал событий от источника дольше N часов, это должен быть алерт, а не открытие при следующей проверке.

Третье: документ по реагированию на инциденты - это не формальность для папки. Инспектор будет спрашивать, как вы применяли его в последние полгода. Журнал разборов, служебные записки по аномалиям - вот что делает документ живым.

Четвёртое: передача в ГосСОПКА в реальном времени - для первой категории это теперь стандартный пункт в предписании, если не сделано. Лучше разобраться с сетевыми ограничениями до проверки, чем объяснять инспектору, почему пакетный режим.

Публикация ФСТЭК хороша тем, что даёт системный срез, а не просто впечатления от конкретных объектов. Цифра 73% - достаточно весомый аргумент для внутреннего разговора о приоритетах, когда бюджет ограничен, а купить ещё один сертифицированный продукт проще, чем выстроить процесс.

Контакт

Нужна такая же инженерная работа?

Опишите задачу и контекст. Ответим в течение рабочего дня, при необходимости подпишем NDA.