Представим промышленный объект.

Система управления доступна. Контроллеры выполняют программу. На операторском экране отображаются правдоподобные параметры.

При этом технологический процесс уже выходит из безопасного режима.

Такой инцидент сложно оценить обычными категориями ИБ. Формально система не остановлена, данные не уничтожены, массовой утечки нет. Но изменённая команда или ложный сигнал способны повлиять на давление, температуру, движение оборудования или химический состав.

В OT (Операционной Технологии) цифровая проблема может стать физической.

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

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

Техническая формулировка «скомпрометирована инженерная станция» недостаточна.

Нужна полная цепочка:

digital cause → affected control function → process deviation → safety barriers → physical consequence → decision window → accountable roles.

И здесь CISO не может действовать один.

ИБ понимает возможности атакующего и уровень доверия к цифровой среде.

Технолог понимает динамику процесса.

Эксплуатация знает, можно ли безопасно продолжать управление.

Промышленная безопасность определяет допустимые границы и последствия их нарушения.

Руководство принимает решение о риске и непрерывности.

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

ИБ требует изоляции. Производство сопротивляется остановке. Safety предупреждает о физических последствиях. Но заранее согласованного механизма решения нет.

Отдельно я бы проверял распространённое предположение, что safety system гарантированно спасёт ситуацию.

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

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

Немедленная остановка также не всегда безопасна. Иногда она снижает риск.

Иногда создаёт дополнительное отклонение или лишает операторов возможности провести управляемый shutdown.

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

NIST рассматривает OT как системы, непосредственно взаимодействующие с физической средой, и требует учитывать их особые требования к надёжности и safety. Начатый в январе 2026 года пересмотр SP 800-82 должен дополнительно связать OT security с CSF 2.0, ERM и современными технологиями. (NIST Computer Security Resource Center)

Моя позиция проста:

в промышленной среде защищать нужно не только цифровые активы. Защищать нужно способность организации удерживать физический процесс в безопасных границах.

CISO обязан понимать путь от киберсобытия до физического последствия. Но окончательная оценка такого риска должна формироваться совместно с производством и industrial safety.

При этом совместная ответственность должна заканчиваться конкретными фамилиями, полномочиями и критериями решения.

Кто, по вашему мнению, должен окончательно определять severity OT-инцидента: CISO, руководитель производства или промышленная безопасность?