По данным Dragos, за Q1 2025 - 708 ransomware-инцидентов в промышленном секторе. 68% пришлось на manufacturing. SANS 2025 State of ICS/OT Security Survey добавляет красок: 22% организаций пережили кибер-инцидент, затронувший ICS/OT-системы, и в 40% случаев это закончилось остановкой операций. Модель Purdue в чистом виде? Мертва. По данным SANS 2024, лишь 8,2% организаций поддерживают полностью изолированные OT-системы. Остальные живут в условиях конвергенции IT/OT, где корпоративный SIEM не парсит Modbus TCP, а EDR-агент на инженерной станции - скорее исключение, чем правило. Три платформы - Nozomi Networks, Claroty и Dragos - занимают лидерские позиции в обнаружении угроз в промышленных сетях, но архитектурно и операционно это три разных зверя. Разбираю конкретные отличия, ограничения и практику интеграции OT-мониторинга с SOC.
Чем OT-угрозы отличаются от IT на уровне защитных мер
Стандартные IT-инструменты неприменимы в OT-сегменте не из-за абстрактной "специфики", а из-за вполне конкретных технических стен. Подробнее - в нашем материале про кибербезопасность критической инфраструктуры.Инвертированные приоритеты. В IT - классическая триада: confidentiality, integrity, availability. В OT всё перевёрнуто: availability и safety на первом месте. Остановка ПЛК управления насосной станцией - это не потеря данных, а физическое событие с угрозой для оборудования и людей. Средство защиты, которое само может вызвать простой - уже проблема.
Протоколы без аутентификации. Modbus TCP, DNP3, Profinet, EtherNet/IP - промышленные протоколы, которые корпоративные IDS/IPS просто не понимают. Modbus не имеет встроенной аутентификации: любой хост в сегменте может отправить FC6 (Write Single Register) или FC16 (Write Multiple Registers) на ПЛК. Разница между легитимным опросом FC3 (Read Holding Registers) и потенциально деструктивной записью FC5 (Write Single Coil) видна только при глубоком разборе пакета с контекстом: кто, куда, в какое время, с каким значением. Именно так работал TRITON - синтаксически валидные команды к системам противоаварийной защиты несли деструктивную логику. Industroyer использовал легитимные ICS-протоколы для отключения подстанций в Украине в 2016 году. Корпоративный файрвол видит TCP-сессию. Что внутри - для него тёмный лес.
Устаревшее оборудование. Жизненный цикл в OT - 15-30 лет против 3-7 в IT (Gartner, NIST SP 800-82 Rev 3). Контроллер 2005 года работает до 2030-го, не поддерживает агенты EDR, не обновляется ежемесячно и был спроектирован до появления понятия "кибербезопасность". Ставить на него агент - всё равно что пытаться накатить Windows Defender на кассовый аппарат из девяностых.
Хрупкость устройств. Активное сканирование (Nessus,
nmap с агрессивными флагами) может вызвать fault ПЛК. В продуктивной среде это аварийная остановка. Поэтому OT-платформы используют пассивный мониторинг сетевого трафика OT и осторожный OT-aware active discovery, а не классическое сканирование.Попытка "расширить" корпоративный SIEM на промышленный сегмент без специализированной платформы даёт ложное чувство безопасности. SIEM видит TCP-пакет между двумя IP, но не понимает, что внутри - запись уставки давления в 47-й регистр.
Критерии отбора: почему Nozomi, Claroty и Dragos
В первом Magic Quadrant for CPS Protection Platforms (Gartner, февраль 2025) статус Leaders получили Claroty, Dragos, Microsoft и Nozomi Networks (по публичным пресс-релизам вендоров). Рассматриваю три из них по одной причине - специализация на OT с нуля.
Что осталось за рамками и почему:
- Microsoft Defender for IoT - надстройка над IT-стеком. Эффективна в Microsoft-центричных SOC, но глубина разбора промышленных протоколов ограничена. Если весь ваш стек - Azure Sentinel + Defender, имеет смысл посмотреть. Если нет - вряд ли.
- Armis - agentless-платформа с фокусом на IT/IoT/IoMT asset intelligence. OT - один из доменов, но не основной. В Gartner MQ 2025 вне категории Leaders.
- Tenable OT Security - vulnerability management-фокус, не полноценная платформа обнаружения угроз.
- TXOne Networks - OT-native endpoint protection и сегментация. Другая категория задач.
- PacketViper - единственный вендор с inline autonomous enforcement в OT. Но это prevention, не detection.
Архитектура и ключевые отличия платформ
Nozomi Networks: масштабная видимость OT и IoT
Nozomi строит решение вокруг Guardian (on-prem сенсор на SPAN-порт коммутатора) и Vantage (облачная консоль управления). Дополнительно - Guardian Air для беспроводных OT/IoT-устройств. Gartner MQ 2025 позиционирует Nozomi как лидера по масштабируемости.Сильная сторона - работа с крупными распределёнными инфраструктурами. AI-аналитика строит поведенческий baseline и алертит на отклонения. Платформа автоматически строит карту активов с деталями: IP, производитель, firmware, зона размещения - видимость активов (OT asset discovery), которую невозможно получить пассивными средствами IT-мониторинга. Если у вас 50+ площадок и тысячи устройств - Nozomi чувствует себя как дома.
Ограничения. Nozomi - платформа мониторинга и уведомления. Containment требует ручных действий администратора или интеграции с firewall/NAC. Как прямо пишет PacketViper (конкурент в категории inline enforcement): "Guardian and Guardian Air products are focused on monitoring and notification. Containment requires administrators to act on alerts.""Guardian и Guardian Air продукты сфокусированы на отслеживание и уведомление. Сдерживание локальных проблем требует действий администартора над оповещениями" Обнаружил - молодец. Заблокировал - сам, руками.
Claroty: широта покрытия cyber-physical систем
Claroty позиционируется как платформа защиты CPS в широком смысле - OT, IoT, IoMT, BMS. Продуктовая линейка: CTD (Continuous Threat Detection, on-prem) и xDome (cloud-native). Gartner MQ 2025 - Leader.Claroty выделяется глубиной asset discovery и vulnerability management. Отдельный модуль Secure Remote Access (SRA) контролирует удалённые подключения подрядчиков. По данным исследования Claroty, 55% OT-окружений содержат четыре и более инструмента удалённого доступа - SRA закрывает эту дыру.
Ограничения. Claroty - detection-first платформа. Response зависит от интеграции с SIEM/SOAR. Из опыта: Claroty генерирует богатую телеметрию, и без настроенной корреляции она превращается в шум. На тюнинг, чтобы отделить реальные аномалии от легитимных изменений конфигурации, уходит время. Иногда - много времени.
Dragos: threat intelligence и incident response для ICS
Dragos строит продукт вокруг threat intelligence. Платформа контекстуализирует алерты через собственную базу знаний об activity groups, атакующих промышленные системы. Для каждого алерта - playbook'и: пошаговые инструкции для incident response, написанные ICS-практиками, а не маркетологами. Gartner MQ 2025 - Leader.Ключевое отличие: Nozomi и Claroty сильны в asset discovery и поведенческом анализе аномалий АСУ ТП. Dragos даёт SOC-аналитику другое - контекст: "это TTP, характерный для группы X, атакующей сектор Y". Для SOC-команды, строящей detection на базе MITRE ATT&CK for ICS, Dragos - наиболее удобная платформа.
Ограничения. По отзывам из дискуссии на Reddit r/cybersecurity: "Dragos has excellent threat hunting and information regarding threat actors and intelligence. However, their platform lacks basic capabilities""Dragos обладает отличными возможностями для поиска угроз и предоставляет информацию об субъектах угроз и разведывательных данных. Однако их платформе не хватает базовых функций." - платформа может уступать Nozomi и Claroty в широте протокольной поддержки и скорости asset discovery на масштабных инфраструктурах. Автономного containment нет. Если вам нужно сначала понять, что вообще живёт в сети - Dragos не первый выбор.
ICS OT security платформы: сравнение фичей и ограничений
| Критерий | Nozomi Networks | Claroty | Dragos |
|---|---|---|---|
| Основной фокус | Масштабная OT/IoT видимость, AI-аналитика | CPS-платформа: OT, IoT, IoMT, BMS | OT Threat Intelligence, ICS IR |
| Развёртывание | Guardian (on-prem) + Vantage (cloud) | CTD (on-prem) + xDome (cloud) | Dragos Platform (on-prem, cloud-опции) |
| Asset Discovery | Глубокая, широкий протокольный охват | Глубокая + vulnerability management | Хорошая, но вторична по отношению к TI |
| Threat Intelligence | TI-фид, интеграция | Интегрирован, не core | Core-компонент, собственные activity groups |
| Playbooks для IR | Нет | Нет | Да, от ICS-практиков |
| Secure Remote Access | Через партнёров | Встроенный модуль SRA | Нет |
| Inline enforcement | Нет | Нет | Нет |
| SIEM-интеграция | Syslog, API, Splunk/QRadar/Sentinel | Syslog, API, SIEM/SOAR | Syslog, API, Splunk/Sentinel |
| Когда выбирать | Крупная распределённая OT/IoT-инфраструктура | Мультидоменная среда (OT + IoMT + BMS) | Зрелый SOC с фокусом на threat hunting |
| Когда НЕ выбирать | Нужен автономный enforcement | Маленькая OT-сеть (избыточен) | Нужен быстрый asset discovery тысяч устройств |
Все три платформы - detection-only. PacketViper формулирует точно: "Claroty, Dragos, and Nozomi are excellent at telling you what's happening. They detect, enrich, and alert - and they do this better than anyone.""Claroty, Dragos и Nozomi прекрасно расскажут вам что происходит. Они обнаруживают, обогащают, и сообщают - и они делают это лучше кого-либо" Но между "обнаружили" и "остановили" стоит временной зазор: SOAR-playbook, решение аналитика, интеграция с firewall. В OT этот зазор - метрика безопасности, а не SLA.
Интеграция OT-мониторинга с SOC: от алерта до корреляции в SIEM
Развернуть OT-платформу без интеграции - получить ещё один дашборд, на который никто не смотрит. Знакомая ситуация? Вот практическая архитектура, которая работает:- OT-сенсор (Guardian / CTD / Dragos) подключается к SPAN-порту промышленного коммутатора (Cisco IE, Hirschmann, Moxa)
- Сенсор анализирует трафик, строит baseline, генерирует алерты
- Алерты пересылаются через Syslog (CEF/LEEF) или API в корпоративный SIEM
- В SIEM настраиваются правила корреляции для OT-специфичных сценариев
- SOC-аналитик получает обогащённый алерт с OT-контекстом
Код:
index=ot_alerts sourcetype="cef"
| where protocol="modbus" AND function_code IN ("5","6","15","16")
| stats count AS write_count by src_ip, dst_ip, function_code, span=5m
| lookup ot_asset_baseline src_ip OUTPUT expected_writes
| where write_count > expected_writes * 3
| table _time src_ip dst_ip function_code write_count expected_writes
Код:
OTAlerts
| where Protocol == "modbus" and FunctionCode in ("5","6","15","16")
| summarize WriteCount=count() by SrcIP, DstIP, FunctionCode, bin(TimeGenerated, 5m)
| join kind=inner (OTAssetBaseline) on $left.SrcIP == $right.AssetIP
| where WriteCount > ExpectedWrites * 3Три сценария обнаружения угроз в промышленных сетях
Аномальный Modbus Write к критическому регистру
SCADA-сервер штатно опрашивает ПЛК управления насосом через FC3 (Read Holding Registers) каждые 2 секунды. Появляется FC6 (Write Single Register) к регистру уставки давления - с IP, который за весь baseline только читал.Все три платформы зафиксируют отклонение: новый function code с известного IP. Nozomi и Claroty покажут protocol anomaly. Dragos дополнительно маппит на Transmitted Data Manipulation (T1565.002, Impact).
Реакция SOC: проверить наличие change request на изменение уставки; авторизован ли IP на write-операции; попадает ли записанное значение в допустимый диапазон. При подтверждении инцидента - изоляция источника через firewall/NAC. Звучит просто. На практике - "проверить наличие change request" означает звонок OT-инженеру в 3 ночи.
Новое устройство в OT-сегменте без baseline
В сегменте DCS появляется устройство с новым MAC-адресом, начинает ARP-запросы и попытки TCP-сессий на порт 502 (Modbus TCP) к нескольким ПЛК.Asset discovery всех трёх платформ зафиксирует новый актив с тегом "unknown". Dragos маппит на Network Service Discovery (T1046, Discovery) и Network Sniffing (T1040, Credential Access / Discovery). Самая распространённая причина - подрядчик подключил ноутбук к промышленной сети для диагностики без согласования. Банально, но именно так выглядят 80% таких алертов. В инциденте Colonial Pipeline (2021) VPN-credential был скомпрометирован в IT-сегменте; OT-системы не были затронуты напрямую, но трубопровод остановили превентивно - потому что не было уверенности в изоляции IT от OT. Отсутствие видимости стоило 4,4 миллиона долларов выкупа.
Скомпрометированная инженерная станция
Инженерная станция, легитимно присутствующая в сети с правами на write-операции к ПЛК, начинает отправлять команды в нехарактерное время и к контроллерам, с которыми раньше не взаимодействовала.Это самый сложный сценарий для детектирования аномалий в промышленном трафике. Трафик синтаксически валиден, исходит от авторизованного хоста, использует корректные function codes. Стандартный IT-подход на основе IP/port - бесполезен.
Все три платформы используют поведенческий анализ: новые пары общения (станция X к ПЛК Y, которых не было в baseline), нехарактерное время, новые адреса регистров. Dragos маппит на Valid Accounts (T1078, Initial Access / Persistence). Claroty SRA даёт дополнительное преимущество: полная запись удалённой сессии - кто подключался, когда, какие действия выполнял.
Именно здесь проявляется слабость detection-only архитектуры: пока аналитик расследует, скомпрометированная станция продолжает отправлять команды. Playbook Dragos предусматривает немедленный запрос к OT-инженеру на ручную изоляцию станции. В инциденте Oldsmar (2021) уставка NaOH была изменена через TeamViewer-сессию; атрибуция до сих пор спорна - операторская ошибка или внешний доступ. Ключевой урок: изменение обнаружил оператор визуально, а не SCADA-мониторинг. Человек заметил, что курсор двигается сам. Не платформа. Не SIEM.
Detection-чеклист для SOC-команды
Нумерованный список действий при развёртывании OT-мониторинга - можно передать сисадмину или включить в operational playbook:Регуляторный контекст добавляет срочности: NERC CIP-015-1 (одобрен FERC в 2024) требует Internal Network Security Monitoring для high/medium impact BES Cyber Systems - мониторинг east-west трафика внутри OT-периметра. Compliance deadline - 36 месяцев после approval, для большинства subjects это 2027–2028 годы. IEC 62443 задаёт модель зон и conduits для сегментации OT IT сетей. TSA security directives после Colonial Pipeline обязали операторов трубопроводов и железных дорог внедрить непрерывный мониторинг. В России аналогичные требования формирует ФСТЭК для объектов КИИ. Для SOC-инженера это значит одно: защита АСУ ТП от кибератак перешла из категории "хорошо бы" в категорию комплаенс-обязательство.
Самая частая ошибка при внедрении OT-мониторинга - ожидание результата "из коробки". Ни одна из трёх платформ не работает по принципу "подключил и защищён". Nozomi, Claroty и Dragos - детекторы, не блокировщики. Они дают видимость, контекст и алерты, но между обнаружением и сдерживанием всегда стоит человек, SOAR-playbook или интеграция с enforcement-точкой. Зрелые SOC-команды разворачивают одну платформу для detection, а параллельно закрывают enforcement через промышленные межсетевые экраны или микросегментацию. Попытка закрыть обе задачи одним вендором из "большой тройки" - пока невозможна.
Выбор между платформами - не вопрос "какая лучше". Вопрос "что критичнее": масштаб и IoT - Nozomi, мультидоменная CPS-среда - Claroty, зрелый threat hunting - Dragos. По наблюдениям из реальных проектов, зрелые операторы критической инфраструктуры нередко разворачивают две-три платформы из разных категорий, а не полагаются на одного вендора. По свежим OT-инцидентам на форуме разбираем алерты и SIEM-правила для промышленных протоколов - тред по OT-мониторингу на yg140.servegame.com.
Последнее редактирование модератором:
