Расследование аварии с цифровым следом: что фиксировать до того, как случится

В заметке про иллюзию воздушного зазора я согласился с замечанием автора статьи о киберустойчивости в энергетике о том, что в комиссии по расследованию аварий в электроэнергетике не включают в обязательном порядке ИТ- и ИБ-специалистов. С 1 января 2026 года Постановление 846, на которое он ссылался, заменено Постановлением 1489 от 29 сентября 2025 года. Я прочитал новые правила с одним вопросом: стало ли в них место для компьютерной причины аварии. Ответ короткий: нет.

Правила стали шире. Теперь расследуют не только аварии, но и инциденты двух категорий. Комиссия обязана сохранять осциллограммы аварийных событий, регистрограммы, файлы параметрирования и записи переговоров оперативного персонала. Электронные материалы хранятся не меньше семи лет, срок расследования 20 дней с продлением до 45 или 90. Среди причин, которые комиссия обязана рассмотреть, есть отказ средств диспетчерского и технологического управления и неправильная работа релейной защиты и автоматики. Но компьютерная атака, вредоносное ПО, изменённая конфигурация, подменённые данные на входе системы управления в правилах не упоминаются. ИТ- и ИБ-специалиста в обязательном составе комиссии по-прежнему нет.

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

Как расследование закрывается на операторе

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

Что в этой схеме не рассматривается. Почему показание на экране выглядело так, а не иначе. Совпадало ли оно с тем, что приходило с датчика. Менялась ли конфигурация контроллера за последний месяц и кто её менял. Была ли в момент аварии активна сессия удалённого доступа вендора. Какую версию прошивки нёс контроллер и совпадает ли она с той, что в паспорте. Если на линии стоит модель предиктивного обслуживания или оптимизации режима, какую рекомендацию она выдала и на каких входных данных.

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

Я писал про это с другой стороны в 2012 году, когда разбирал, кто принимает решения в первые 30 минут отказа: в первые полчаса все заняты восстановлением, и улики уничтожаются восстановлением же. NotPetya в 2017 году показал тот же эффект в масштабе корпорации: кибератака превратилась в чистый операционный убыток именно потому, что её долго не распознавали как атаку.

Три слоя следа, которые нужны комиссии

Если задача расследования найти причину, а не виноватого, на момент аварии должны быть доступны три слоя данных. Правила 1489 покрывают только первый.

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

Слой второй: в каком состоянии была система управления. Конфигурация контроллеров и SCADA на момент аварии и история её изменений. Версии прошивок с контрольными суммами. Журналы событий контроллеров, инженерных станций и серверов SCADA, включая входы в систему, изменения уставок, загрузки проектов. Журнал удалённого доступа: кто, когда, с какого адреса и что делал. Сетевые журналы на границе технологического сегмента. Этот слой в правилах не упоминается, и именно он отличает «отказ оборудования» от «кто-то поменял уставку в пятницу вечером».

Слой третий: на основании чего принимались решения. Для оператора это экран, который он видел, то есть история значений на HMI, а не только с датчиков. Для модели это версия модели, выборка, на которой она обучена, входные данные в момент решения и само решение с обоснованием. Для агента это пара «намерение и действие» и журнал вызовов инструментов, о котором я писал в заметке про наблюдаемость роя агентов. Этот слой нужен, чтобы отличить ошибку человека от ошибки модели, а ошибку модели от подменённых данных на её входе.

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

Что регулятор уже требует, даже если правила 1489 молчат

Пробел в правилах расследования не означает пробел в требованиях. Три документа его закрывают с других сторон, и с ними стоит сверить то, что у вас хранится.

Приказ ФСБ 547 от 25 декабря 2025 года, действующий с 30 января 2026 года, задаёт порядок информирования НКЦКИ о компьютерных инцидентах на объектах КИИ. Уведомление в пределах суток, для значимых объектов быстрее. Чтобы уведомить, инцидент нужно сначала увидеть, а чтобы по нему ответить на запросы НКЦКИ, его нужно описать: что, когда, на каком объекте, какие признаки. Это невозможно сделать по слою «что сломалось».

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

Статья 274.1 УК, о которой я писал в заметке 187-ФЗ девять лет спустя, применяется и к собственным сотрудникам за нарушение правил эксплуатации, повлёкшее вред. В ситуации, когда след не сохранён, именно оператор оказывается единственным, чьи действия задокументированы в записях переговоров. Сохранение второго и третьего слоёв защищает не только расследование, но и людей, которые работали на линии.

Что сделать до аварии: практический минимум

Список ниже я предлагаю заводам, у которых есть технологическая линия и пять человек в ИТ. Он не требует SIEM и штатного форензика.

1. Снимки конфигураций по расписанию. Раз в сутки, автоматически, выгрузка конфигураций контроллеров, проектов SCADA и уставок в хранилище с контрольными суммами и историей версий. Любое отличие между двумя снимками это событие, которое должно попасть в журнал с указанием, кто и когда менял. Для большинства платформ это скрипт и репозиторий, а не продукт.

2. Реестр прошивок с хэшами. Для каждого контроллера версия прошивки, контрольная сумма, дата установки, кто ставил. Проверка совпадения раз в месяц и после любого обслуживания вендором. Это закрывает вопрос «та ли прошивка стоит, что в паспорте».

3. Журналы наружу и надолго. События контроллеров, инженерных станций и SCADA уходят на отдельный сервер журналов за пределами технологического сегмента, где их не перезапишет кольцо и не сотрёт восстановление. Хранение год, для объектов КИИ сверьте с требованиями к вашей категории. Сюда же журнал удалённого доступа: каждая сессия вендора или подрядчика с началом, концом, адресом и перечнем действий.

4. История экрана, а не только датчиков. В историан пишутся значения, которые видел оператор на HMI, включая расчётные и отфильтрованные, с теми же метками времени, что и сырые показания. Расхождение между ними это главная улика при подменённой телеметрии.

5. Состояние модели на момент решения. Если на линии есть модель, при каждом решении, которое доходит до оператора или до уставки, сохраняется версия модели, идентификатор обучающей выборки, входной вектор и выход. Переобучение не затирает предыдущие версии, они хранятся с датами. Для агентов журнал вызовов инструментов с входом и выходом.

6. Кнопка «заморозить». Процедура на первые тридцать минут после аварии: кто нажимает, что именно замораживается. Снимок конфигураций и журналов снимается до начала восстановления, а не после. Это одна строка в плане реагирования и один человек, который знает, что она его.

7. ИБ-специалист в комиссии по внутреннему регламенту. Правила 1489 не обязывают, но ничто не мешает включить его локальным актом. На заводе, где своего ИБ нет, это внешний специалист по договору, которого вызывают по той же процедуре, что и представителя вендора.

Шаги с первого по третий это два-три месяца работы ИТ-отдела с внешней помощью на старте. Четвёртый и пятый зависят от того, есть ли на линии модель. Шестой и седьмой это бумага и одно совещание.

Кто подписывает

Отдельный вопрос, который в технических обсуждениях теряется: чьи это данные и кто отвечает за их наличие. Если за снимки конфигураций отвечает ИТ, за историан технологи, за журнал удалённого доступа служба безопасности, а за модель подрядчик, который её внедрял, то на момент аварии ответственного нет, и каждый из четырёх покажет на другого.

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

Честные оговорки

• Я прочитал Постановление 1489 как инженер, а не как юрист. Состав комиссий и перечень причин я взял из текста и обзоров, и если в отраслевых документах Минэнерго появятся требования к ИТ-компетенциям комиссий, буду рад это признать. На момент написания я их не нашёл.

• Цифровой след не заменяет расследование. Он делает его возможным. Комиссия со всеми тремя слоями данных может прийти к выводу «ошибка персонала», и это будет обоснованный вывод, а не единственно доступный.

• Хранить всё дорого, хранить нужное дёшево. Я не предлагаю полный захват трафика технологического сегмента. Снимки конфигураций, хэши прошивок, журналы событий и история экрана занимают гигабайты в год, а не терабайты. Дорого становится, когда это не спланировано.

• Для объектов КИИ с присвоенной категорией перечень шире. Там требования к журналированию и взаимодействию с НКЦКИ задаёт регулятор, и этот минимум нужно сверять с ними, а не заменять ими.

Если коротко

• С 1 января 2026 года аварии и инциденты в электроэнергетике расследуют по Постановлению 1489. Оно требует хранить осциллограммы и записи переговоров, но ИБ-специалиста в комиссии и кибератаки среди причин в нём нет.
• Расследование закрывается на операторе не из-за некомпетентности комиссии, а потому, что на момент аварии нечем ответить на вопросы «что изменилось» и «почему решение было таким».
• Нужны три слоя следа: что происходило с оборудованием, в каком состоянии была система управления, на основании чего принимались решения людьми и моделями.
• Второй и третий слои уже требуют приказ ФСБ 547 и методический документ ФСТЭК, пусть и с других сторон. Статья 274.1 УК делает их сохранение защитой для собственных людей.
• Практический минимум: снимки конфигураций, реестр прошивок с хэшами, журналы наружу на год, история экрана, состояние модели на момент решения, процедура заморозки, ИБ-специалист в комиссии по внутреннему регламенту.
• Один владелец цифрового следа на предприятии, обычно главный инженер, подписывает регламент и раз в квартал получает отчёт.

Если у вас была авария, по которой так и осталось непонятно, почему оператор увидел то, что увидел, или вы хотите, чтобы следующая такая авария расследовалась по данным, а не по показаниям, это ровно та задача, с которой я начинаю. Обсудить задачу можно через форму, первый разговор ни к чему вас не обязывает.