Все верно. Шифруя канал вы защищаете информацию при транзите(!) от несанкционированного чтения и изменения. Но теряете мониторинг этой информации (в случае без отсутствия ключей у системы мониторинга). В то время как информация может быть изменена на конечных участниках этого туннеля, таким образом туннель будет прятать эти изменения от системы мониторинга. Поэтому подход должен быть сбалансированным. Удаляя одни риски, можно создать новые. В любом случае систему мониторинга лишать доступа к содержанию трафика нельзя. Методы как мы видим для этого есть. Не использовать шифрование (но использовать контроль целостности и аутентификацию) или применять схемы с предоставлением доступа к содержимого зашифрованного трафика (делая таким образом систему мониторинга третьим доверенным участников информационного обмена)

а в какую ветку это вставить: https://miro.com/app/board/o9J_kka6j9s=/ ?

А ещё лучше не надеяться на мониторинг и реакцию администратора безопасности, а сделать узел безопасным при проектировании, позаботится о доверенном обновлении, если сценарий имеется, решить вопрос с доверенной загрузкой, запретить запись для неаутентифицированных приложений и пользователей, сделать авторизацию пользователей, не хранить пароли в открытом виде. В отличие от IT, в АСУ ТП все очень детерминировано и нет необходимости постоянной установки новых приложений и веб-сёрфинга пользователей

При размытыми периода именно защита самого узла - самое главное, а вот потом можно говорить и про защищённые коммуникации, и про мониторинг

Надеяться нельзя ни на какую одну меру защиты. Надеяться можно на комплекс мер. Мониторинг трафика это одна из важных мер из всего из многообразия.

Давайте сразу на фею надеяться

Да, комплекс мер и эшелонирование

Это эпоха уже прошла, даже эпоха надежды на забор с собакой заканчивается )

Да, поэтому прятать/шифровать трафик от системы мониторинга нельзя, и это говорит не только то что я работаю у вендора системы мониторинга трафика АСУ ТП (я так считал и до этого), но и здравый смысл 🙂

Забавно звучит «спрятать трафик от системы мониторинга» 😂

А в чем проблема ну зашифровали вы трафик от точки к точке в АСУ ну тогда давайте интегрируем возможность добавления на сетевой мониторинг (различных вариантов прослушивания шифрованного трафика, ну сертификат, ключ или протокол добавить в средство мониторинга) тогда и овцы целы (шифрование есть трафика) и волки сыты (мониторинг видит что в шифрованном трафике есть).

Да, я этом и писал. Либо не шифровать, либо дать доступ к трафику, примеры схем доступа в IEC TR 62351-90-2:2018 Technical Report on Deep Packer Inspection (DPI) of encrypted communications in power systems

Крестную!

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

Тоже все верно. Я просто пытался донести до аудитории. Беззаботно радоваться шифрованию не надо, есть особенности которые нужно учесть

+

Ждем поддержку шифрования (добавления сертификатов и ключей)  в кикс фор нитворк

как вы оцениваете процентное соотношение шифрованных промышленных ethernet сетей к нешифрованным на уровне контроллеров и ЧМИ на 2020 год?

1 к 1000 ) пока видел тока одну организацию которые пытались шифровать от PLC до АРМ и серверов.

Но прогресс не стоит на месте