Скорее всего процесс просто очень долгий

Анекдот про это есть, мышки, станьте ежиками.

Если никто не знает как в общем случае оценивать эти несчастные likelihood и consequences, можно хоть примеры давать

Открою маленькую тайну. Первоначально статья называлась "Что придёт на смену риск-ориентированному подходу". Но поскольку в западных стандартах превращение мышей в ёжиков пока не описано, вот и решили пока не смущать потенциальных читателей. 🙂

Прекрасно ))

Consequences можно смело брать из LOPA, а likelihood это пока сказки. Не придумать же каталоги вроде OREDA для таких событиях. Может со временем МITRE ATT&CK что-нибудь да накопит и можно будет как-то ссылаться. Но чёткого конца пока не видно.

Ну а что они тебе дадут без четкого описания объекта, для которых они приводятся?

Мне - ничего, я сама все могу написать. Но у народа массовые вопросы по реализации стандартизованных подходов, вот тут примеры и могут помочь.

А тракторы тем временем ржавеют :) Их появление, кстати, обеспечил достаточно скромный научный уровень и относительно примитивная теория. Квантовые заморочки не пригодились.

Про ржавение тракторов как раз теоретики и горазды рассуждать

Ждём стартапов по расчету likelihood для отрасли, конечно же на базе AI и ML😄

1

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

Сплошь и рядом. Основной вопрос такой, как применение наложенных СЗИ повлияет на работу АСУ ТП. Часто встречается, что вендоры АСУ ТП грозятся снять систему с гарантии, при установки компонентов не входящих в проект и не протестированных на совместимость. Эту проблему по опыту возможно снять при плотном взаимодействии с вендорами АСУ и СЗИ.

Ставьте по периметру, настраивайте сбор сетевой информации, syslog, flow через инфодиоды. это не влияет на АСУ ТП

Этот вопрос поднимался и мы плотно занимаемся общением с производителями СЗИ. Тот же Касперский выкладывает сертификаты совместимости с системами АСУ ТП (за подписью представителей внедорожник асу тп).

В том и дело, упираются рогом. Не хотим и все. Есть альтернативы?

Что именно не хотят? Что вы предлагали? Вообще, отказы надо обосновывать бумажками. С обоих сторон, это не технические решения.

Не хотят ничего дополнительного подключать к элементам асу тп. обоснования в виде сертификатов совместимости, тех описания способов подключения и их безопасности и отсутствия влияния на систему или отдельные элементы (например использование span порта), как с гуся вода

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