После атаки на промышленную сеть у команды ИБ нередко остаются не артефакты, а пустота: нет телеметрии, нет нормальных логов, нет истории действий злоумышленника. Именно поэтому киберобман в OT из экзотики для конференций быстро превращается в практический инструмент для тех, кто отвечает за заводы, энергетику, здания и другую инфраструктуру, где сбой стоит дороже инцидент-репорта.
Об этом как пишет Dark Reading, напомнил Скотт Хоук, VP & CISO компании Velaspan, в колонке от 28 августа 2026 года. Его тезис звучит без лишней драматургии: в сегменте operational technology защитник почти всегда расследует атаку вслепую. И проблема не в ленивой SOC-команде и не в плохой SIEM. Просто значительная часть OT-среды изначально не проектировалась так, чтобы оставлять удобные для ИБ следы.
В классическом IT-расследовании у специалистов обычно есть привычный набор вопросов. Кто вошел в систему? Какая учетная запись использовалась? Запускался ли PowerShell? Какой процесс был родительским? Было ли соединение с известным C2-адресом? Создавался ли новый сервис? Совпадает ли хэш файла с известным семейством малвари? Для корпоративной инфраструктуры все это звучит буднично. Для OT-среды часто нет. Программируемый логический контроллер не обязан сообщать, что кто-то его опрашивал. Удаленный терминальный блок не даст осмысленных логов аутентификации. Камеры, принтеры, контроллеры управления зданием и прочие «второстепенные» устройства либо пишут минимум, либо пишут локально, недолго и в формате, который SIEM переваривает без энтузиазма.
Отсюда и неприятная для бизнеса развилка. Компания уже понимает, что злоумышленник добрался до технологического сегмента, но доказательная база слабая. Сигнатурные средства мало помогают, потому что им просто не на чем срабатывать. Корреляция в SIEM не спасает, если события не были собраны. Лог-аналитика не восстанавливает путь атаки, если часть маршрута прошла через узлы, которые почти ничего не записывают. Для CISO, IT-директора и руководителя эксплуатации это означает простую вещь: чем ближе атака к физическому процессу, тем меньше у вас привычных источников правды.
Почему OT ломает привычную модель расследования
Хоук иллюстрирует проблему на давно известном, но до сих пор показательном кейсе: атаке на энергосистему Украины почти 12 лет назад. Это был переход из IT в OT. Сначала противник закрепился в корпоративной части сети, провел разведку, собрал учетные данные, нашел маршруты к операционным системам и затем пересек границу, за которой уже находятся средства управления критическими компонентами. Сам по себе этот сценарий для отрасли не новость. Новость в другом: даже спустя годы многие компании по-прежнему надеются расследовать такой переход теми же методами, что и компрометацию обычной офисной сети.
На практике граница между IT и OT остается любимым местом злоумышленника именно потому, что там падает качество наблюдаемости. В enterprise-сегменте его еще можно заметить по следам разведки, перемещению между хостами, подозрительным обращениям к документам, схемам сети и учетным данным. В OT-сегменте картина резко тускнеет. Если атакующий уже внутри инженерной рабочей станции, подсети PLC или смежной инфраструктуры, у защитников не прибавляется видимости, а наоборот, часто становится меньше. Для компаний с распределенными площадками, подрядчиками и удаленным доступом вендоров это особенно болезненно: решений по реагированию много, а уверенности в моменте атаки мало.
На этом фоне киберобман в OT выглядит не как модный эксперимент, а как способ компенсировать архитектурный дефицит. Идея проста: если реальные устройства не дают нужной телеметрии, защитник создает для злоумышленника убедительную ложную поверхность атаки. Это не только honeypot в старом школьном смысле. Речь о фальшивых учетных данных, поддельных схемах OT-сети, приманочных инженерных станциях, декой-устройствах и имитаторах PLC, которые выглядят достаточно правдоподобно, чтобы их стоило тронуть. Как только атакующий с ними взаимодействует, команда получает высокоточный сигнал и контекст: откуда пришли, чем интересовались, на каком этапе находятся.
Что меняется для защитников и бизнеса
Главная ценность такого подхода не в том, что он «видит все». Он как раз честно работает с ограничениями среды и ловит не саму каждую технику атаки, а намерение двигаться к операционной цели. Хоук описывает связанный сценарий: фальшивая учетная запись на IT-рабочем месте, приманочный документ со схемой OT-сегмента, ложная инженерная станция, к которой кто-то получил доступ с компрометированного узла, и симулированный PLC, который внезапно начали опрашивать. По отдельности это уже полезные события. Вместе это почти готовый маршрут вторжения через границу, которая для бизнеса важнее любой другой.
Для SOC и blue team это особенно удобно из-за качества сигнала. В IT-компаниях давно привыкли жить с шумом: множество алертов, часть из которых подозрительна только статистически. В OT цена ложного срабатывания выше. Заблокировать хост, разорвать удаленный туннель подрядчика, сбросить доступы, сегментировать подсеть или остановить рабочую станцию можно, но каждое такое действие может ударить по производству. Именно поэтому низкоуверенные сигналы часто превращаются в долгие обсуждения между ИБ и эксплуатацией. С декой-механиками ситуация меняется: если кто-то использовал honey credential, открыл поддельный OT-документ или пошел опрашивать ненастоящий PLC, это уже не «аномалия вообще», а конкретное нештатное действие. На такой сигнал проще опираться при решении о быстрых и точечных мерах.
Есть и организационный эффект, который российской аудитории хорошо знаком. Во многих компаниях IT и промышленная автоматизация до сих пор живут как соседи по лестничной клетке: общаются редко, интересы пересекаются в кризис. Киберобман в OT полезен тем, что заставляет смотреть на атаку сквозным образом, а не по ведомственным границам. Атакующий не уважает оргструктуру и не различает, кто у вас владелец сервера, контроллера или камеры. Он идет туда, где проще приблизиться к цели. Значит, и защита должна собирать историю движения через оба домена, а не спорить, чей это инцидент.
При этом колонка Dark Reading не обещает серебряную пулю, и это, пожалуй, ее сильная сторона. Декой-приманки не превращают старые контроллеры в современные endpoint-узлы и не отменяют сегментацию, контроль удаленного доступа, учет подрядчиков, бэкапы и базовую гигиену сети. Но они закрывают тот самый провал, который особенно заметен после атаки: когда нужно понять, что именно произошло, а среда отвечает молчанием. Для разработчиков систем промышленной автоматизации, архитекторов ИБ и руководителей инфраструктуры вывод неприятно практичный: если в OT по-прежнему мало собственных следов, эти следы придется создавать искусственно и заранее.
Следующий рубеж для отрасли уже виден: перестать воспринимать OT как пространство, где «нормальная» детекция невозможна, и начать строить защиту вокруг намерений атакующего, а не вокруг идеальной телеметрии, которой все равно не будет. Вопрос теперь не в том, приживется ли киберобман в OT, а в том, какие компании успеют встроить его в реальные сценарии реагирования до следующего перехода из офисной сети в технологическую.