все таки это очень странный разговор, как сравнивать бмв и ауди? что толку от сравнений и то и другое доставит вас из точки а в точку б. Но выбор делает заказчик, как ему комфортно за рулем и тут тоже самое, все равно заказчик должен на своей инфраструктуре попробовать и понять в чем ему лучше и удобней работать. Заказчик может хоть 10 решений пробовать, если он не торопиться.

Блин, сдаюсь... Я даже не смог найти расшифровку NSM (вряд ли Naval Strike Missile имелись ввиду) и NDR ))

На самом деле, у заказчиков бывают условия особые. Например, еще до Виталия, в Соларе мы тестировали МЭ с DPI 104 протокола. Казалось бы, все просто.. Но на месте оказалось, что есть особенности и у системы ССПИ, и порты нестандартные используются и в итоге почти  все вендоры ушли на доработку, а было выбрано 1 решение и то на определенной прошивке..

Если к этим аббревиатурам в поиске добавить security, жизнь становится проще

Network Security Monitoring

Спасибо. Рецепт Алексея помог. Что-то я самое банальное уточнение не добавил))

В целом, этим:
- Возможность логирования действий по указанным функциям (UUID)
- Возможность залогировать/разрешить/запретить использовать OPC DA. OPC DA различается в общем трафике DCERPC, в частности, WMI
- Возможность логировать/запретить участникам сетевого обмена запись или чтение по OPC DA,  например, по имени тега
- Ну и тестирование работы с вендорами систем автоматизации, которые его используют. Тут следите за релизами, выпускаем информацию. Скоро (месяц-два) должен быть получен сертификат совместимости с плотной проверкой работы по OPC DA с одним из вендоров

Ну это вообще общая рекомендация)))
Но не для всех возможная

Если уж занимаетесь сертификацией, то лучше не с вендорами это делать, а вот с этими ребятами: https://opcfoundation.org/certification/how-to-certify/

Как минимум, такой сертификат универсален и снимает вопросы разом у всех вендоров

А по функциям... Ну, разве что, до конкретного тэга не всякий МЭ проваливается, а все остальное разные производители МЭ "на слуху" давным-давно поддерживают...

В теории да. Но вот по результатам тестирования оказывается, что на практике количество false positive не дает нормально это использовать. Правда тестировали уже почти два года назад. Сейчас изменилась ситуация?

Ну фокус с настройкой MS-RPC для пропуска исключительно UUID интерфейсов клиента и сервера OPC DA я на курсах демонстрировал еще года с 2015-го... С той поры только лучше стало.

Ну и умолчу, что когда-то был такой MS ISA Server (aka MS TMG), который тоже умел разбирать DCOM/RPC на уровне UUID интерфейсов... А это еще версия 2004-го года умела.

Да, но это же производилось на базе рабочей станции, а не сетевого трафика?

Если так, то весь вопрос ведь в отсутствии аутентификации, как и с большей частью промышленных протоколов. Отсюда необходимость это разграничить/выявить на уровне сети.

У многих пром. протоколов имеются сервисные функции, использование которых может быть ограничено на уровне SCADA. Но весь фокус в том, что если злоумышленник вышел за пределы ПО SCADA или получил доступ к сети, то он может напрямую обращаться к ПЛК. Аутентификации нет у многих протоколов и АСУ ТП в эксплуатации. Поэтому и есть необходимость такие действия выявить/предотвратить.

нет. Это на уровне трафика. Там нет ничего сложного, так как шифрование в DCOM/RPC до сих пор не в почете...

Ну ПЛК-кто вряд ли прям по OPC общается...

Ну если так, могу только только порадоваться)) Мы вроде как все перечисленное делали в 16 году, но вот решение, казалось бы, мелких нюансов заняло гораздо больше времени, чем первый прототип.
А если так давно была технология, из-за чего не выпустили продукт на базе того, что делали? Потребность на рынке точно есть.

Это речь не о каких-то особых разработках - речь про существующие на рынке МЭ. Просто они как-то плохо позиционируют свои возможности для АСУ ТП.
Приходится за них ))