Новая архитектура АСУ ТП: наблюдаемость, жизненный цикл и кибербезопасность

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

Что останется на полевом уровне? Разумеется, удалённый ввод-вывод. Ещё долгое время системы противоаварийной защиты будут локальными, так же, как и локальные системы управления, которые поставляются вместе с оборудованием, системы, которые требуют очень специализированного «железа». В мини-ЦОДы они не перейдут в ближайшие десятилетия. В остальном максимальная централизация всех систем управления должна совершиться. Это эффективнее и проще контролировать. Другими словами, мы движемся к форме «единого окна» – централизации. Нет причин, чтобы не начать распространять её на АСУ ТП.

Наблюдаемость как новая ценность
Наблюдаемость — логи, метрики, события безопасности, телеметрия ОС, гипервизоров и приложений — становится очень важным аспектом для будущей АСУ ТП. Первостепенно это связано с централизацией. Мы располагаем наши мощности в мини-ЦОДе – значит, нужно контролировать работу оборудования. Любая новая технология требует проверок, валидации – нельзя сразу всё поставить и забыть. Системы мониторинга могут показать: были ли проблемы с оборудованием или определённые задержки – такая система позволяет быстро реагировать на сбои. Сегодня такие системы есть у вендоров, однако у каждого вендора они свои и плохо интегрируются друг с другом. Часто возникают проблемы с интеграцией таких систем мониторинга, например, с централизованными хранилищами логов.

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

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

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

Кибербезопасность
Закрытые ПЛК-экосистемы часто воспринимались как более защищённые просто потому, что они изолированы. В новой архитектуре безопасность строится не на изоляции и на модели security through obscurity, а на управляемости, видимости и контролируемых изменениях.
Гарантировать кибербезопасность АСУ ТП на 100% невозможно. Её обеспечение – это всегда непрерывный процесс, гонка между атакующими и обороняющимися. Также нельзя забывать про развитие ИИ инструментов: появляются нейронные сети, обученные на пентесты и потенциально на взломы инфраструктур.

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

Уверен, что централизация и переход к программной автоматизации увеличат защищённость систем при должном подходе. Безусловно, риски есть, а цена риска растёт. Например, виртуализация становится «узким» местом: если её сломают, могут взломать всю инфраструктуру. Тут нужен грамотный подход к анализу рисков, важно делать акцент на скорости восстановления. Необходимо делать мониторинги для оперативного обнаружения вторжений. При их обнаружении – оперативно блокировать доступ. Если обнаружение запоздало, за счёт подхода «инфраструктура как код» можно быстро всё восстановить. В конечном итоге, это дешевле для заказчика.

Зависимость от вендоров решений для кибербезопасности на рынке АСУ ТП
Грамотные сотрудники служб безопасности всегда объединяют продукты разных вендоров. С одной стороны, это неудобно, с другой – больше вероятность обнаружить вредоносные моменты. Моновендорный подход в новых реалиях не очень правильная история. Нужно брать лучшее от вендоров и совмещать эти сильные аспекты. Другой вопрос: что делать с тем, если каждый вендор начнет строить свои платформы? Конечно, тогда в части интеграции это будет непростая задача, в первую очередь, для интеграторов, но, уверен, они справятся.

Открытость и vendor lock-in
Один из мотивов перехода к Software-Defined ICS — снижение зависимости от конкретного поставщика. Актуальный вопрос для многих заказчиков: реально ли это в промышленности, где сертификация, поддержка и ответственность играют огромную роль?

Начну про ответственность. Её часто используют как контраргумент применительно к Software-Defined АСУ ТП и открытой АСУ ТП в целом. Отмечу, что даже у вендоров закрытых АСУ ТП ответственность ограничена. Иногда заказчики говорят: «Как так? Мы большая компания и зависим от поставщика, выручка которого меньше, чем у нас за месяц?». Да, и это нормальная ситуация для всего мира, для того и существует специализация компаний. Ответственность компаний в сфере АСУ ТП, как правило, ограничивается рамками контракта. Это общемировая практика.

Я бы добавил ещё важный момент – ответственность конкретных людей перед конкретным предприятием или его представителями. Часто это важнее, чем ответственность, прописанная в договоре.

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

В мире ПЛК сегодня всё так и работает. В этом смысле ничего не меняется.