Тоже добром не заканчивается

:)

так, кажется субботнего предупреждения всем оказалось мало 😈 Давайте по делу, без флуда и нагнетания (последнее относится к отдельным товарищам ;) )

:)

Уже б самоликвидировался из чата, пока тебя не забанили)

Я жду, пока забанят, чтобы можно было жаловаться на репрессии

Тут жалости к подстрекателям не будет)

Это не так. Разногласия между АСУ шнеками , Рза и Ибшниками кроются куда глубже - в фундаментальных подходах. Одним ( Асу , рза) необходимо получить сигнал чистым (без шумов ) и во время . Другим (Иб) необходимо в первую очередь обеспечить конфиденциальность информации, передаваемой сигналом. При этом конфиденциальность в общем случае обеспечивается шифрованием - наведением шума в сигнале. В рамках такой модели сигнал является универсальным носителем информации . Такой диссонанс с подходах порождает инверсию в приоритетах Обеспечения сохранности свойств информации для управляющих систем промышленных предприятий.

Следует отметить , что наличие шума не снижает надежность канала связи ,а ограничивает лишь скорость

(с) моя

Не со всеми положениями согласен. ИБ не только конфиденциальность сигналов, но и их целостность (защита от подмены, например).

Атака типа MITM

При всём уважении, я не опускал целостность и доступность , а говорил об инверсии свойств для Обеспечения верного целеполагания. И говорил о разнице в фундаментальных принципах дисциплин. Mitm- Это криптографическая атака и частный случай.Меры защиты от неё как раз шифрование, которое в управляющей системе приведёт к снижению скорости. Говоря о частностях , в рамках Обеспечения защиты УС, то угроза mitm  с успехом блокируется строгой организационно - допускной системой . Кроме того , выговорили глобально об информации, но почему то оперировали моделью оси, но спишем это на тематику группы)

Масса ложных посылов. Почему обязательно и только конфиденциальность. Я не согласен.

Только о конфиденциальностям речь не шла. Речь идёт об инверсии в приоритетах в свойствах

Некоректно так формулировать. Необходимо задать функциональные и не функциональные требования, а потом оценивать удовлетворяет им решение или нет. Ровно так сделано в МЭК 62351

Например, реализуем MMS с TLS и проверяем соблюдаются функциональные и не функциональные требования. Попадаем в 100 мск или нет в разных режимах

Владимир, сначала надо всегда пытаться отвечать на вопрос "зачем это делать" я про пример ммс тлс

Ты про вопрос реализации правильно говоришь. Но вопрос целесообразности и функционального назначения как-то и нет.

И так же обо всех иб-новшествах в пром автоматизации можно говорить сейчас.