Threat hunting в промышленной сети редко начинается с удобства. OT почти всегда встречает охотника ограничениями: агенты поставить нельзя, активное исследование сети нежелательно, изменения требуют согласования, а цена ошибки - простой, нарушения технологического режима и риски для безопасности. Поэтому в OT важна не гонка за полной видимостью, а умение работать аккуратно: собирать данные пассивно, фиксировать норму, искать отклонения и проверять гипотезы так, чтобы не навредить процессу.
Эта статья для OT‑security инженеров, аналитиков промышленного SOC и threat hunters, которым нужно охотиться в условиях неполных данных. Здесь практический подход: какие источники данных реально тянуть в SOC, как выстроить baseline, как формулировать hunting‑гипотезы под ICS и как общаться с технологами так, чтобы безопасность не стала фактором риска для производства.
1. Особенности threat hunting в OT
OT не про максимальную наблюдаемость, а про контролируемые изменения. В большинстве промышленных сегментов вы не получите тот же уровень хостовой телеметрии, что в IT: часть активов работает на устаревших ОС и в вендорных конфигурациях, где сторонний агент превращается в риск стабильности и поддержки. Поэтому охота в OT почти всегда опирается на внешние сигналы: сеть, события верхнего уровня, данные процесса, следы инженерных рабочих мест.Отсюда первый принцип: охота строится вокруг того, что можно собирать без вмешательства в критичные узлы. Второй принцип важнее любого детекта - доступность и безопасность выше исследовательского интереса. Любой сбор данных и любая перестройка мониторинга оцениваются не только по полезности для SOC, но и по риску для сети и процесса: нагрузка на коммутаторы, влияние зеркалирования, устойчивость каналов, последствия для диагностики и поддержки со стороны вендора. В OT охота должна быть предсказуемой, воспроизводимой и безопасной.
Третий принцип - коммуникация с производством не как формальность, а как часть методологии. Многие аномалии в OT объясняются режимом технологического цикла, обслуживанием, регламентами или особенностями конкретной линии. И наоборот: технологи иногда первыми видят странность в поведении процесса, а SOC способен подтвердить, что это совпадает с нетипичной сетевой активностью или событиями управления. Хорошая охота рождается там, где SOC приносит факты, технологи - контекст, а решение принимается с учётом последствий для технологического режима.
В статье «Охота на угрозы: Основа в деталях» - хороший разбор того, как мыслит threat hunter: от гипотез и источников данных до подтверждения находок и действий по результатам расследования.
2. Источники данных в OT
Неполная видимость в OT компенсируется не попыткой собрать всё, а сочетанием нескольких независимых источников. Каждый источник по отдельности может быть слаб: сеть не всегда даёт смысл управления, SCADA не всегда независима, historian может не содержать причин. Но вместе они дают устойчивую картину: сеть показывает взаимодействия, SCADA/HMI - управленческие действия, historian - реакцию процесса, инженерные станции - возможный механизм изменений.Network traffic (пассивно) обычно становится базовым слоем, потому что его можно собирать, не устанавливая ПО на контроллеры и не вмешиваясь в работу технологических узлов. Он отвечает на фундаментальные вопросы: какие узлы общаются, какие связи стабильны, какие появились впервые, как меняется частота и время активности, какие сервисы возникают в сегменте. Практическая сложность - выбрать точки наблюдения так, чтобы видеть не только периметр OT/IT, но и критичные взаимодействия внутри OT сегментов, где часто и разворачиваются самые важные истории.
Historian возвращает расследование к реальности процесса. Он помогает проверить, имела ли подозрительная активность физический эффект, когда началась динамика, как развивались параметры во времени, и совпадают ли изменения с событиями управления. В OT это критично: одна и та же сетовая странность может оказаться либо безвредным фоном, либо предвестником воздействия на технологический режим, и historian помогает выбрать правильный приоритет.
HMI/SCADA events дают слой ответственности и последовательности действий: входы пользователей, подтверждения тревог, переключения режимов, изменения уставок и прочие операции управления. Они особенно полезны, когда используются в корреляции: с трафиком (чтобы понять, как действие “дошло” до уровня управления) и с historian (чтобы понять, был ли эффект на процесс). Качество этого источника сильно зависит от настройки журналирования и дисциплины эксплуатации, поэтому его нужно “причесывать” заранее, а не в момент инцидента.
Engineering workstation logs - отдельная категория, потому что именно через инженерные станции и сервисные ноутбуки проходят операции конфигурирования и программирования оборудования. Даже при неполной сборке логов следы подключений к PLC, использования инженерного ПО и изменения проектов часто становятся ключом к расследованию, когда нужно объяснить управляющее изменение, неожиданную связь или смену поведения сегмента.
3. Инструменты мониторинга
Инструменты в OT удобнее рассматривать как роли в расследовании. Нужен слой, который превращает трафик в события для корреляции и baselining, нужен слой OT‑контекста активов и протоколов, и нужен слой, который позволяет быстро поднять доказательства, когда гипотеза уже сформулирована.Zeek часто используют как механизм событийности из трафика: он помогает описывать сетевое поведение, строить устойчивые паттерны и находить отклонения по связности и ритму взаимодействий. Даже если протокольная глубина неидеальна, в OT часто выигрывает анализ повторяемости и новизны: что изменилось относительно нормы.
Промышленные платформы мониторинга (в духе Claroty/Nozomi/Dragos) ценят за OT‑ориентированность: инвентаризацию активов, профилирование ролей, протокольный контекст и удобные представления изменений. Они обычно ускоряют путь от сетевого наблюдения к понятной производству формулировке: что именно изменилось, какой это актив и почему это важно.
Для расследований и проверки гипотез задним числом полезен слой работы с PCAP. Здесь уместен Arkime как подход к индексированному анализу сетевых дампов: когда нужно быстро найти сессии, восстановить контекст и подтвердить или опровергнуть гипотезу, не ограничиваясь коротким окном хранения метаданных. Для пассивного картирования сети и понимания структуры связей иногда используют GRASSMARLIN, когда нужно навести порядок в видимости без активных воздействий.
4. Построение baseline
Baseline в OT - это способ перестать реагировать на каждый одиночный сигнал и начать видеть изменения картины. Промышленная сеть обычно стабильнее IT: много повторяемости, расписаний и привычных связей. Поэтому baseline работает, если строится с учётом циклов и режимов: смены, batch‑процессы, окна обслуживания, плановые выгрузки.Первый слой baseline почти всегда про связность и роли. Кто с кем общается, какие пары считаются штатными, где проходят границы зон, какие узлы являются управляющими, какие - инженерными, какие - инфраструктурными. На этом же этапе важно договориться, что именно считается “новым”: новая пара взаимодействий, новый маршрут администрирования, новый тип сервиса, новый узел, который внезапно стал говорить с контроллером.
Второй слой baseline - про время и ритм. В OT отклонение часто выражается не фактом связи, а тем, что связь появилась не тогда, когда обычно, или с другой интенсивностью. Это особенно заметно на инженерных действиях: в норме они привязаны к окнам работ, и выход за окно сам по себе уже повод для проверки, даже если действие выглядит легитимным.
Третий слой baseline - про управленческие действия и ожидаемый эффект. В OT опасны не просто новые соединения, а нетипичные операции управления: изменения уставок, режимов, параметров тревог, конфигураций, логики. Зрелый baseline в этом месте не пытается перечислить все команды, а фиксирует типовые сценарии управления для конкретного участка и проверяет, совпадает ли наблюдаемое действие с типовым сценарием и есть ли след в historian.
В руководстве «ИИ в кибербезопасности: от хайпа к реальности - почему аналитики SOC эволюционируют, а не исчезают» полезно подсмотреть тезис: автоматизация снимает рутину, но качество результата упирается в качество данных и понимание контекста - то, ради чего в OT и строится baseline.
5. Hunting hypotheses
Хорошая hunting‑гипотеза в OT формулируется так, чтобы её можно было проверить имеющимися данными и без активного вмешательства. Удобно опираться на MITRE ATT&CK for ICS как на словарь поведения и целей атакующих, но реальную ценность даёт перевод техник в проверяемые вопросы к вашим данным.Reconnaissance в OT часто проявляется как попытка понять, что за сеть перед атакующим и где точки управления. На практике это может выглядеть как рост нетипичных попыток общения, появление новых связей и сервисов, неожиданные обращения к узлам, которые обычно молчат. В стабильных сегментах такие изменения заметны именно через baseline: не потому что они обязательно громкие, а потому что они новые.
Lateral movement в ICS обычно имеет прикладную цель: добраться до точки управления, конфигурации или инженерного доступа. В реальности охота ищет новые маршруты администрирования, новые связи к инженерным узлам и новые пути доступа к управляющим системам. Важно, что сам факт удалённого доступа не равен атаке; сигнал появляется, когда доступ перестаёт соответствовать норме по времени, роли источника, цели, объёму и сопутствующим событиям верхнего уровня.
Process manipulation опасна тем, что может быть растянутой во времени и внешне похожей на работу человека с правами. Поэтому здесь почти всегда нужна корреляция: след управления в SCADA/HMI и сетевом поведении плюс эффект или отсутствие эффекта в historian. Если корреляции нет, выводы должны быть осторожными: в OT “закрыть инцидент быстро” иногда хуже, чем “проверить инцидент правильно”.
В руководстве «Обзор матрицы MITTRE ATT&CK» есть понятное объяснение, как превращать “название техники” в практику: какие артефакты искать и как подступиться к матрице без перегруза
6. Практические сценарии
- Rogue device: появление нового узла или нового типа устройства в OT‑сегменте и его нетипичная связность, особенно с инженерными или управляющими ролями.
- Нетипичная инженерная активность: изменения профиля подключений инженерной станции к PLC по времени или интенсивности, не совпадающие с нормой.
- Подозрительные управляющие изменения: события SCADA/HMI по уставкам и режимам, которые проверяются по historian на эффект и по сети на контекст.
- Новые пути перемещения: появление новых удалённых сессий и маршрутов администрирования внутри OT, ведущих к точкам управления.
7. Incident response в OT
Реагирование в OT редко выигрывает скоростью; оно выигрывает подготовкой. В момент инцидента самая частая ошибка - действовать так, что вы теряете наблюдаемость или создаёте риск для технологического режима. Поэтому полезнее заранее договориться о сценариях: что можно изолировать сразу, что только в безопасном режиме, что требует участия вендора, как сохраняются доказательства, кто принимает решение при конфликте между скоростью и риском для производства.Зрелый промышленный SOC выстраивает IR так, чтобы не терять контекст процесса. Это означает: не отделять киберчасть от технологической, а постоянно сопоставлять сетевые наблюдения, события верхнего уровня и данные historian. Когда эта связка отработана, реагирование становится не набором нервных действий, а управляемым сценарием.
Заключение
Threat hunting в OT работает, когда вы принимаете неполную видимость как норму и строите процесс вокруг того, что реально доступно и безопасно собирать: пассивный трафик, события SCADA/HMI, historian и следы инженерных станций. Baseline превращает стабильность промышленной сети в преимущество: новое и нетипичное становится заметным. А гипотезы, привязанные к OT‑реальности, помогают не распыляться и проверять сценарии так, чтобы не навредить технологическому процессу.
Последнее редактирование:
