За последние годы промышленность столкнулась с простым, но неочевидным фактом: привычные ИТ-подходы к безопасности плохо работают в технологической среде. АСУ ТП опираются на инженерные процессы и оборудование с долгим жизненным циклом, поэтому их невозможно защитить так же, как офисную сеть. Из-за этого предприятия продолжают повторять одну и ту же ошибку: покупают решения «по презентациям» и выполняют формальные требования регуляторов, не соотнося их с реальным техпроцессом и архитектурой. В результате защита превращается в набор разрозненных мер и решений, которые не связаны между собой и не учитывают архитектуру промышленной системы. Разберем наиболее типичные ошибки, которые совершают предприятия при построении защиты АСУ ТП, и покажем, какие шаги помогут предприятиям избежать их в будущем.
Ошибка № 1. Выбор технологий без привязки к контексту производства
Одна из самых типичных ошибок возникает уже на этапе выбора решений. Предприятие ориентируется на рейтинги или эффектные презентации сейлов, тогда как ключевым критерием должен быть реальный технологический контекст. Продукт может выглядеть убедительно на слайдах, но не учитывать особенности конкретного производства и не вписаться в существующую архитектуру. Инженерная специфика АСУ ТП предполагает учет того, как система взаимодействует с контроллерами, какие протоколы используются, какие ограничения имеет оборудование и какую нагрузку выдерживают рабочие станции. На практике решение, выглядящее идеально в брошюре, может при стопроцентной загрузке «положить» узел на устаревшей ОС или не поддерживать необходимые протоколы вроде Modbus или Profibus. В итоге такой продукт либо ляжет мертвым грузом, либо станет источником постоянных сбоев и падения эффективности.
Как соотнести технологию с моделью угроз? Логика должна идти не от продукта, а от угроз. Сначала определяются реальные угрозы конкретной системы, затем оценивается, может ли решение закрыть их инженерно, без ущерба для технологического процесса. Важно, чтобы требования формировались не только ИТ и ИБ, но и технологами. Именно команды, отвечающие за контроллеры, автоматику и промышленную часть, задают параметры отказоустойчивости, поддерживаемые протоколы и архитектурные ограничения. И обязательно — испытания на реальных стендах. Только тестирование в условиях, близких к рабочим, позволяет понять, как решение поведет себя в рамках конкретной АСУ ТП и не станет ли оно новым источником риска.
Ошибка № 2. Ожидание быстрых результатов
Даже если с выбором технологии всё сделано правильно, следующая ловушка ждёт уже на этапе внедрения. В промышленной среде проекты по защите АСУ ТП практически никогда не укладываются в короткие сроки. Главная причина в том, что предприятия стремятся сразу перейти к внедрению средств защиты, минуя обязательный этап инвентаризации и классификации активов. Без понимания реальной архитектуры невозможно спроектировать меры безопасности, а тем более определить приоритеты.
На практике ИТ-служба часто не имеет полной картины того, что происходит в цехах. Подрядчики или специалисты по ИБ вынуждены «ходить ногами» и фиксировать все элементы АСУ ТП вручную. Это занимает время, требует физического доступа и неизбежно зависит от технологических остановов. Еще одна специфика — невозможность вмешательства в систему в произвольный момент. Для аудита, обновлений и настройки приходится ждать технологических окон, и именно это растягивает реализацию проектов независимо от ресурсов и сроков, поставленных руководством.
Поэтому сокращать этап инвентаризации нельзя. Даже если кажется, что система типовая, в каждой АСУ ТП свои протоколы, особенности взаимодействия и нестандартные узлы. Без глубокого понимания реального контура внедрение защиты превращается в цепочку компромиссов и ошибок, которые потом приходится исправлять уже в процессе эксплуатации.
Ошибка № 3. Считать АСУ ТП «дополнением» к ИТ и не иметь владельца технологического риска
Исторически на многих предприятиях АСУ ТП воспринималась как часть ИТ. Информационную безопасность замыкали на ИТ-департамент, который считался наиболее компетентным. Но в результате технологический контур оказывался формально привязан к ИТ, а фактически — без реального владельца. ИТ редко погружены в архитектуру технологических систем, не управляют жизненным циклом оборудования и не несут ответственности за непрерывность техпроцесса, поэтому АСУ ТП нередко «зависает в воздухе», а безопасность сводится к документам и организационным мерам.
Отсюда возникает системный конфликт приоритетов. Для ИТ ключевыми критериями в функционировании инфраструктуры являются конфиденциальность и целостность данных, для технологов — доступность и недопущение остановов. Добавляется «языковой разрыв»: ИТ говорят о портах и уязвимостях, технологов волнуют уставки, контроллеры и непрерывность цикла. В итоге решения принимаются под разным углом, и любое изменение превращается в конфликт интересов.
Еще одно следствие отсутствия владельца — размывание технологических рисков. ИТ сфокусированы на своих КЦД, но риски остановки производства, повреждения оборудования, угрозы жизни и даже экологические последствия могут вообще не попадать в зону внимания. Ответственность расползается между инженерными службами, производством и ИТ, но фактически не принадлежит никому.
Владелец технологического риска должен быть один — руководитель производственного блока, чаще всего главный инженер. Он должен отвечать за непрерывность и безопасность процесса, понимать реальные угрозы и принимать решения с учетом технологической специфики. В его распоряжении должна находиться компетенция по ИБ АСУ ТП — либо как отдельная функция, либо в составе ИТ, но с четким технологическим фокусом.
Оптимальная модель — это тандем главного инженера и специалистов по АСУ ТП. Первый отвечает за технологическую целостность, второй — за методологию и архитектурную логику защиты. Такое взаимодействие позволяет формировать приемлемый уровень риска, исходя не из формальных регламентов, а из реальной технологической картины.
Дальше неизбежно проявляется еще один эффект отсутствия понятного владельца: финансовые решения также оказываются разбросаны между разными подразделениями. Когда у АСУ ТП нет человека или структуры, отвечающей за неё целиком, бюджеты расползаются между ИТ, производством и ИБ. Каждый оплачивает свою часть, но никто не берет на себя ответственность за общий результат. Отсюда возникают типичные сбои. Производство закупает оборудование самостоятельно, ИТ и ИБ об этом даже не знают, и новая рабочая станция появляется в сети без учета и сопровождения. Служба ИБ приобретает решения, но у цеха нет средств на внедрение и обучение, а у ИТ нет ресурсов на эксплуатацию и мониторинг. И наоборот: ИТ устанавливает межсетевой экран, но не согласовывает правила с технологами, что приводит к остановке обмена промышленными протоколами. Все эти примеры на самом деле не про ошибки выбора технологий, а про отсутствие единых финансовых и управленческих приоритетов.
Ошибка № 4. Разорванное реагирование между подразделениями
Когда в АСУ ТП происходит инцидент, ИТ-специалисты и технологи часто начинают действовать вразнобой, просто потому что по-разному видят ситуацию. Для ИТ важно спасти данные и быстро восстановить систему. Для технологов главное, чтобы не встал техпроцесс, не пострадало оборудование и не случилась авария. Из-за этого и появляется разрыв. ИТ пытаются закрыть свою часть, технологи защищают производство, и каждый движется в свою сторону. В итоге решения принимаются медленно, меры оказываются несогласованными, а время реагирования растягивается больше, чем могло бы.
На практике первым должен включаться именно технолог. Он лучше всех понимает, какие последствия могут быть для оборудования здесь и сейчас, и в состоянии оценить реальный риск для производства. Уже после такой оценки к работе подключаются ИТ и архитекторы АСУ ТП, чтобы вместе выбрать решение, безопасное и для технологического процесса, и для информационной части системы.
Сколько на это должно уходить времени, заранее сказать нельзя: в промышленности все зависит от конкретного оборудования и сценария. Но принцип остаётся одинаковым в любой ситуации: сначала реакция технолога, а затем совместный выбор дальнейших действий.
Ошибка № 5. Игнорирование жизненного цикла оборудования
Проекты по безопасности часто живут в своем календаре, а модернизация оборудования — в своем. В результате защита накладывается на технологию, которая уже близка к выводу из эксплуатации, либо наоборот, новая платформа приходит в момент, когда установленная система безопасности не может корректно с ней взаимодействовать. Средства защиты обычно ориентированы на конкретные версии операционных систем и промышленных контроллеров. Когда контроллеры или SCADA устаревают физически, а система безопасности настроена под их существующую конфигурацию, появляется архитектурный разрыв. Он требует компенсирующих мер и создает период повышенных рисков.
Особенно остро это проявляется при переходе между поколениями ОС. Например, когда технологические узлы работают на Windows XP, а предприятие переходит на Windows 7, установить защиту «по учебнику» зачастую невозможно. Любое вмешательство может нарушить технологический процесс, и приходится выбирать между риском остановки и временной изоляцией.
Чтобы такие ситуации не возникали внезапно, ЛПР должны заранее учитывать жизненный цикл оборудования. Прежде всего это единый реестр активов с плановыми датами вывода из эксплуатации. Графики модернизации и графики внедрения мер безопасности нужно синхронизировать, чтобы проекты не накладывались друг на друга и чтобы для устаревших систем можно было заранее подготовить компенсирующие меры. В отдельных случаях единственно безопасным вариантом действительно остается физическая изоляция, потому что попытка заменить оборудование способна привести к остановке производства или потребовать полной перестройки АСУ ТП.
Ошибка № 6. Уверенность в закрытом контуре
Распространенное заблуждение заключается в том, что технологическая сеть изолирована от внешнего мира. На практике АСУ ТП часто оказывается «полуоткрытой» из-за множества обходных подключений, о которых руководство даже не подозревает. Самый типичный канал — сервисный ноутбук инженера или ИТ-специалиста. Его подключают к контроллерам или рабочим станциям для обновлений, диагностики, загрузки программ, а затем используют в обычной офисной сети или выходят с него в Интернет. Фактически он становится переносным мостом между закрытым контуром и внешней средой, включая потенциально зараженные сегменты. Еще один источник риска — интеграция с MES и ERP для мониторинга производственных показателей. Система вроде бы отображает данные для руководства и не вмешивается в процесс, но реальная интеграция часто двусторонняя: через нее можно не только наблюдать, но и воздействовать на технологические объекты. При этом такие решения требуют регулярных обновлений, что само по себе создает дополнительное окно уязвимости.
Причина в том, что изоляция воспринимается как данность. Руководители видят архитектуру на схеме и считают контур закрытым, но реальная эксплуатация формирует множество теневых точек входа. Если эти каналы не контролировать, закрытая сеть существует только в документах, а фактически остается открытой для угроз.
Ошибка № 7. Ориентация на формальное соответствие требованиям вместо управления реальными рисками
На ряде предприятий защита АСУ ТП фактически ограничивается выполнением только тех требований, которые прописаны в обязательных документах. Но сама нормативная база, включая
Еще хуже, когда весь фокус смещается в сторону организационно-распорядительной документации, которая так и не доходит до реальных пользователей АСУ ТП и не применяется в ежедневной работе. Характерный симптом: безопасность воспринимается как отчетность. Документы есть, средства стоят, но персонал ничего не знает, не обучен и не понимает, зачем это нужно.
Как понять, что защита строится под галочку? Самый простой способ — выйти в цеха. Поговорить с инженерами и операторами: какие меры безопасности применяются, какие правила они знают, как работают с паролями, знакомы ли с инструкциями. То же касается реагирования на инциденты: проводятся ли реальные тренировки или все ограничивается отчетом о неком «плане отработано».
На практике именно внутренний аудит показывает реальное состояние защиты. Он позволяет увидеть, работает ли система или существует только в презентациях и регламентных отчетах.
Заключение
Защита АСУ ТП не может быть делом одного департамента. Это комплексный процесс, требующий участия ИТ, ИБ, технологов и производственных специалистов. Ответственность за устойчивость технологического контура невозможно переложить только на ИТ или только на инженеров по автоматике. Каждый уровень системы связан с другими, а значит, меры безопасности должны учитываться начиная с исполнительных устройств и заканчивая рабочими местами операторов. Синергия здесь не красивое слово, а обязательный принцип. Только совместная работа, единая архитектура, согласованное реагирование и общее понимание технологических рисков позволяют строить реальную, а не формальную защиту. Если предприятие не выстраивает этот процесс как непрерывный и межфункциональный, оно либо создает иллюзию безопасности, либо закладывает почву для будущих инцидентов.
