UDV Group: ИБ АСУ ТП нельзя строить по ИТ-лекалам

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

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

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

Разница начинается с назначения систем. Корпоративная ИТ-инфраструктура обрабатывает данные, поддерживает бизнес-процессы и связывает пользователей с приложениями. АСУ ТП управляет оборудованием, которое взаимодействует с физическим миром. Здесь цифровая команда превращается в открытие клапана, запуск конвейера, изменение давления, регулировку температуры или остановку механизма.

Поэтому одинаковые меры безопасности дают разный эффект. В ИТ активное сканирование может быть приемлемым способом найти уязвимые узлы. В АСУ ТП оно способно создать лишнюю нагрузку на контроллер, вызвать нестандартную реакцию устройства или нарушить обмен в чувствительном сегменте. В ИТ автоматическое обновление закрывает риск уязвимости. В АСУ ТП обновление без проверки совместимости может вывести из строя связку ПЛК, SCADA, драйверов, OPC-сервера и прикладного ПО.

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

Для CISO это означает, что АСУ ТП нельзя защищать по принципу «как ИТ, только строже». Строже не всегда значит безопаснее. Иногда более жесткая мера создает больший риск для производства, чем сама уязвимость. Например, сложная многофакторная аутентификация может быть уместна для удаленного доступа администратора, но неудобна или опасна там, где оператор должен быстро выполнить действие в аварийной ситуации. Решение должно учитывать не только угрозу, но и технологический сценарий.

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

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

Мы в UDV Group видим, что эффективная ИБ АСУ ТП начинается с совместной работы, а не с внедрения инструмента. Руководитель СИБ должен понимать, какие процессы критичны, какие линии нельзя останавливать, какие изменения допустимы только в технологическое окно, какие ПЛК чувствительны к опросу, какие протоколы используются и какие действия могут повлиять на безопасность персонала. Без этих данных невозможно правильно выбрать меры защиты.

Со стороны производства тоже нужна вовлеченность. Инженеры АСУ ТП должны помогать службе ИБ понимать ограничения оборудования, нормальные сценарии обмена, состав технологических сегментов, критичные параметры и допустимые реакции на инцидент. Если эта экспертиза остается внутри службы автоматизации, ИБ не сможет оценить риск самостоятельно и будет видеть только технические события без производственного смысла.

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

Регуляторные требования здесь важны, но они не должны превращаться в формальную надстройку. 187-ФЗ, приказ ФСТЭК № 239 и стандарты серии ГОСТ Р МЭК 62443 задают рамку, но на предприятии эту рамку нужно перевести на язык конкретного производства. Нельзя ограничиться документом, где написано, что доступ контролируется. Нужно понимать, как он выдается, кто его согласует, где фиксируются действия, какие изменения разрешены и что происходит при отклонении.

Для CISO главный управленческий вывод простой по смыслу, но сложный в реализации: защита АСУ ТП начинается с признания ее отличий от ИТ. Здесь нельзя опираться только на привычные ИБ-практики, метрики и инструменты. Нужно учитывать физический процесс, производственные ограничения и позицию инженеров, которые отвечают за работу оборудования.

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