На старте импортозамещения многие компании столкнулись не столько с дефицитом самих решений, сколько с дефицитом привычного функционала. Формально продукт можно заменить, но на практике быстро выяснилось, что часть возможностей либо отсутствует, либо реализована иначе. Особенно заметно это было в системах мониторинга - от работы с IOC до специализированных функций для промышленной инфраструктуры, включая визуализацию кодов управления и проектов ПЛК.
Дополнительная проблема заключалась в зрелости самих решений: часть функций еще находилась в развитии или не прошла необходимые процедуры сертификации. Поэтому предприятиям пришлось пересматривать не только стек средств защиты, но и архитектуру мониторинга, правила анализа событий и подход к эксплуатации ИБ-систем.

Иван Бурмистров, пресейл-инженер компании UDV Group
Источник фото: UDV Group
Почему в АСУ ТП меняется сама модель защиты
В промышленном контуре быстро проявляются ограничения, которых нет или почти нет в корпоративной ИТ-среде. Во многих технологических сегментах нельзя устанавливать агентское ПО на рабочие станции, серверы и контроллеры. Поэтому решения, привычные для офисной инфраструктуры, например EDR или DLP, либо не применяются, либо используются в сильно ограниченном режиме.
Из-за этого центр тяжести защиты смещается с агентской модели на сетевую. Безопасность строится вокруг анализа трафика, пассивного мониторинга и наблюдения за технологическими протоколами. Для АСУ ТП критично не столько контролировать отдельную конечную точку, сколько видеть сетевые взаимодействия и понимать поведение устройств внутри сегмента.
Это напрямую влияет и на реагирование. Даже антивирус на ряде объектов работает только в режиме оповещения: автоматическая блокировка может затронуть технологический процесс. В итоге в приоритете оказывается не мгновенное действие, а своевременное обнаружение аномалий, нетипичных соединений и отклонений в поведении оборудования.
Полное замещение возможно, но без иллюзий
Полноценная замена зарубежных ИБ-решений в сегменте АСУ ТП в целом реальна, но без компромиссов - пока далеко не всегда. Причина не только в зрелости продуктов, но и в устройстве самого промышленного контура: высокой сегментации, длинном жизненном цикле систем, ограниченной допустимости изменений и жестких требованиях к эксплуатации.
Для ИТ-директора здесь важен не формальный факт импортозамещения, а сохранение управляемости после миграции. Поэтому решения нужно сравнивать не по принципу полного функционального совпадения, а по способности закрывать критические сценарии - обеспечивать видимость сети, выявлять аномалии, поддерживать расследование инцидентов, корректно работать в технологических сегментах и стабильно эксплуатироваться в производственном контуре.
Где предприятия ошибаются чаще всего
Первая ошибка - недооценка сроков и условий внедрения. В промышленной инфраструктуре любое вмешательство приходится синхронизировать с технологическим циклом, ремонтными окнами и допустимыми режимами простоя. При этом скорость перехода у разных классов решений будет разной: замена межсетевого экрана может занять один-два рабочих дня, если архитектура подготовлена заранее, а миграция системы мониторинга нередко растягивается на месяцы, потому что требует адаптации правил, проверки качества обнаружения и встраивания в существующие процессы эксплуатации. В промышленности импортозамещение измеряется не скоростью закупки, а тем, насколько аккуратно предприятие перестраивает архитектуру безопасности без потери стабильности основного производства.
Вторая ошибка - попытка использовать коробочные практики без адаптации к конкретному объекту. Правила корреляции, сценарии обнаружения и модели нормализации, которые поставляются вместе с продуктом, почти никогда не работают в промышленной среде без глубокой донастройки. Они отражают усредненный опыт, но не реальную структуру и нормы на конкретном предприятии. К этой же ошибке относится и ожидание, что после установки система мониторинга сразу начнет работать в полную силу. На практике без настройки правил отдел мониторинга «утонет» в шуме ложно-положительных срабатываний. Для ИТ-директора это означает, что бюджет миграции должен включать не только лицензии и внедрение, но и отдельный ресурс на адаптацию правил, аудита активов, формирование базовой линии нормального поведения и донастройку системы под конкретное предприятие.
Третья ошибка - экономия на обучении и эксплуатации. Многие заказчики закладывают бюджет на покупку ПО, но недооценивают стоимость продления, технической поддержки, пилотной эксплуатации и, главное, времени специалистов на изучение системы. Между тем в АСУ ТП именно дефицит внутренней экспертизы часто становится главным ограничением: решение установлено, но команда не умеет интерпретировать его данные, адаптировать политики и использовать систему как рабочий инструмент.
Четвертая ошибка - экономия на эксплуатации и обучении. Многие заказчики закладывают бюджет на покупку ПО, но недооценивают стоимость продления, технической поддержки, пилотной эксплуатации и времени специалистов на изучение системы. Между тем в АСУ ТП именно дефицит внутренней экспертизы часто становится главным ограничением: решение установлено, но команда не умеет интерпретировать его данные, адаптировать политики и использовать систему как рабочий инструмент.
Что замещать сложнее всего
Наиболее сложными для замещения в промышленной инфраструктуре оказываются не столько отдельные средства мониторинга, сколько те классы решений, которые требуют вмешательства в действующую сетевую и эксплуатационную модель. В первую очередь это сегментация сети и управление доступом.
Если сегментация изначально не была выстроена или за годы эксплуатации размывалась из-за временных подключений, подрядчиков и расширения технологических участков, ее пересборка неизбежно затрагивает действующие процессы и может потребовать остановки отдельных участков или перенастройки сетевого взаимодействия.
Поэтому сложность импортозамещения здесь связана не только с выбором продукта, но и с восстановлением управляемости - инвентаризацией подключений, пересмотром ролевой модели, внедрением журналирования и контролем привилегированных действий.
Как строить миграцию без сбоев
Техническая миграция в промышленности начинается не с выбора вендора, а с аудита. Предприятию нужно понимать, сколько у него объектов мониторинга, как устроены подсети и сегменты, какие версии операционных систем и сервисов используются, где уже есть критические ограничения, а где инфраструктура в принципе готова к переходу. Без этой инвентаризации любая миграция превращается в движение вслепую.
Следующий этап - выбор решений под конкретные регуляторные, эксплуатационные и функциональные требования. После этого нужна собственная пилотная зона, в которой можно быстро проверять разные решения на совместимость, устойчивость и полноту нужного функционала. Для крупных объектов миграция почти всегда идет поэтапно - с разделением на очереди, проверкой каждого этапа и возможностью отката.
Отдельной статьей нужно закладывать обучение и поддержку внутренних специалистов. В промышленной инфраструктуре риск возникает не только в момент внедрения, но и потом - в эксплуатации, донастройке, обновлении политик и разборе инцидентов. Если команда не понимает, как работает новое решение, предприятие получает не управляемую защиту, а новый источник операционных рисков.
Именно поэтому практический рецепт здесь довольно простой: сначала аудит и инвентаризация, чтобы предприятие понимало, что именно оно защищает и где находятся реальные ограничения; затем - выбор решений не по принципу формального аналога, а под конкретную архитектуру, режимы эксплуатации и требования технологического контура. После этого необходима пилотная проверка на совместимость и полноту функционала, а уже затем - поэтапная миграция с контролем каждого этапа и возможностью отката. Такая последовательность позволяет снижать риски для технологических процессов, сохранять управляемость во время перехода и не превращать импортозамещение в формальную замену одного продукта другим.