Что еще не предусмотрел руководитель производства

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

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

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

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

ФСТЭК в своих документах прямо говорит: для АСУ ТП приоритет — не конфиденциальность, а безопасность технологического процесса и жизни людей. Это меняет все. В офисной ИБ мы боремся с хакером. В промышленной ИБ мы боремся с физикой, которая сошла с ума из-за хакера.

И какие последствия становятся ключевыми?

Их четыре, и каждый страшнее предыдущего:

1. Экологическая катастрофа — когда производство убивает природу вокруг.
2. Травматизм и гибель людей — когда оборудование становится оружием.
3. Остановка производства — когда предприятие просто стоит и теряет деньги.
4. Порча основных фондов — когда уникальный станок стоимостью в миллиард превращается в металлолом.

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

1. Экологическая катастрофа (разлив, выброс)

Ситуация: атака на АСУ ТП химического производства. Злоумышленник меняет параметры работы задвижек, открывает аварийный сброс, меняет давление в реакторе. Последствие — тонны ядовитых веществ в реку или в воздух.

Неочевидное архитектурное решение: «Аварийный атом». Стандартный подход — защищать сеть, ставить межсетевые экраны. Но если атакующий уже внутри, это не поможет.

• Физически независимый контур остановки: в архитектуру закладывается система, которая не зависит от основной АСУ ТП вообще. Это отдельные датчики, отдельные контроллеры, отдельные кабели, отдельное питание. Они видят только критические параметры (давление выше крыши, температура за пределом) и имеют право физически разорвать цепь — перекрыть задвижку, отключить нагрев, открыть аварийный клапан. Даже если основная сеть полностью скомпрометирована, «аварийный атом» жив. Это дорого, это занимает место, это кажется избыточным. Но это единственное, что спасет при реальной катастрофе.

Но как заставить проектировщиков заложить это на этапе стройки?

Включать в техническое задание требование: «невозможность отмены аварийной остановки программными средствами». Любая команда из основной сети не должна иметь приоритет над физической защитой.

2. Травматизм и гибель людей (управление опасным оборудованием)

Ситуация: мостовой кран, управляемый с операторского пульта. Взломщик или вирус перехватывает управление и начинает двигать груз над людьми. Или пресс выдает команду на смыкание, когда руки оператора внутри.

Неочевидное архитектурное решение: «Обратный приоритет человека». Обычно мы думаем, что автоматика умнее человека. В безопасности опасных механизмов — наоборот.

• Аппаратный приоритет ручного режима: В архитектуру закладывается правило: любое ручное воздействие оператора имеет абсолютный приоритет над программным. Если оператор нажал «стоп», даже легитимная команда от контроллера не должна это отменить. Это реализуется на уровне релейных схем, а не программ.
• Зоны присутствия с геозонами: Внедрение системы, которая знает, где находятся люди (по брелокам, по каскам с трекерами, по видеоаналитике). Если в опасной зоне есть человек, система физически блокирует возможность подачи напряжения на механизм. Это не софт, это — отключение питания на уровне пускателя.

Внедряется поэтапно, начиная с самых опасных участков. И это не фантастика, это требования промышленной безопасности, просто оцифрованные и усиленные.

3. Остановка производства (простой)

Ситуация: атака шифровальщиком на серверы АСУ ТП. Данные зашифрованы, управление потеряно. Завод встает на неделю. Потери — миллионы в день.

Неочевидное архитектурное решение: «Бумажный двойник» и «ручной режим». Все говорят про цифровых двойников. Но нужен еще и аналоговый.

• Архитектура деградации: система проектируется так, чтобы при отказе цифры производство не останавливалось, а деградировало до более низкого уровня автоматизации. Это значит, что у каждого критического узла должен быть интерфейс для прямого ручного управления, не зависящий от сети. Кран можно включить кнопкой в кабине, задвижку — открыть вентилем, температуру — контролировать термометром.
• Автономный запас прочности: в каждом цеху должен быть комплект документации (бумажной!) и минимальный набор автоматики, позволяющий работать в «режиме острова». Это требует пересмотра архитектуры: сеть должна легко сегментироваться на автономные куски.

Но как заставить инженеров думать о ручном режиме, когда они привыкли к автоматике?

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

4. Порча/уничтожение основных фондов (убитый станок)

Ситуация: атака на прокатный стан или турбину. Изменение параметров работы приводит к тому, что оборудование разрушает само себя. Вал гнется, подшипники плавятся, ротор разносит корпус.

Неочевидное архитектурное решение: «Физический предохранитель». Самый страшный сценарий — когда атака заставляет оборудование работать в запредельных режимах, а система управления этому не препятствует, потому что скомпрометирована.

• Пассивные ограничители: в архитектуру закладываются физические ограничители, которые не зависят от софта. Механический клапан сброса давления, который открывается при превышении предела, даже если контроллер его закрыл. Плавкая вставка, которая разрывает цепь при перегрузке. Это — «последняя миля» защиты.
• Контроль целостности физического процесса: система поведенческого анализа, о которой мы говорили, должна сравнивать не только цифровые команды, но и физические показатели. Если станок потребляет 200 кВт, а должен 100 — это аварийный останов, даже если программа говорит «все ок». Алгоритм защиты должен быть зашит в неперезаписываемую память (ПЗУ) контроллера.

Игорь, все эти решения — дорогие и сложные. Но даже если мы их внедрим, кто будет ими управлять в момент ЧП? Ведь когда реально пошла утечка аммиака, читать инструкцию уже поздно.

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

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

Практические шаги:

1. Иммерсивные учения: раз в полгода мы проводим учения, где имитируется реальная авария. Не «компьютерная игра», а выезд на площадку, с дымом, с сиренами, с отключением автоматики. Оператор должен руками, на рефлексах, нажать ту самую кнопку аварийной остановки, которая не зависит от сети. Если он мнется или ищет бумажку — учения провалены.
2. Слепые тесты: внезапно, без предупреждения, мы имитируем инцидент. Например, отключаем питание одного контроллера и смотрим: через сколько минут технолог поймет, что это нештатная ситуация, и кому он позвонит? Норма — 2 минуты до звонка диспетчеру. Часто — 20 минут ковыряния в железе.
3. «Человеческий двойник»: у каждого критического узла должен быть не только цифровой двойник, но и живой ответственный, который знает его физическое устройство. Этот человек должен раз в год лично проверить работу аварийного клапана, а не просто поставить галочку в журнале.
4. Перевод знаний в байки и легенды: самое страшное забывается. Настаивайте процессы так, чтобы каждая учебная тревога заканчивалась разбором и созданием «истории», которую рассказывают новичкам. «Помните, как в 25-м году Петрович не нажал кнопку, и у нас чуть не сгорел цех?». Страх и уважение к железу должны передаваться устно.

Почему это не могут сделать внутренние службы?

Могут, но редко делают. Внутренние службы боятся остановок, боятся паники, боятся, что учения покажут их некомпетентность. Партнер со стороны приходит и говорит: «Давайте устроим пожар. По-настоящему. Чтобы знать, что вы не сгорите, когда придет настоящий». У нас нет страха за внутреннюю политику, у нас есть только цель: довести защиту до рефлекса.

Как измерить, что завод готов к самому страшному?

1. Время перехода в ручной режим: от момента обнаружения проблемы до начала управления человеком. Должно быть менее 60 секунд для критичных узлов.
2. Процент успешных учений: если на учениях люди действуют правильно в 95% случаев — отлично. Если меньше — учить заново.
3. Исправность физических предохранителей: каждый месяц проверка, что аварийные клапаны, рубильники, отсекатели работают механически, независимо от сети.
4. Знание номеров телефонов: опрос персонала. Знает ли оператор номер телефона главного инженера, дежурного ИБ-специалиста и аварийной службы наизусть, без гугла? Если нет — архитектура провалилась.

Игорь, спасибо. Напоследок: почему директора заводов должны вкладываться в эти неочевидные и дорогие решения?

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

Архитектура ИБ для производства — это не про защиту информации. Это про защиту физической реальности. И здесь не работают стандартные решения. Нужны «безумные» идеи: физические контуры, независимые от сети, ручные дублеры, обучение до рефлекса.

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