Надо у вендоров спросить, как часто шифровальщики ориентируется на сегмент АСУ Dmitry @Anton_Shipulin  есть статистика?

В предверии новогодних праздников позволю себе сделать сообществу маленький подарок )) дам совет который стоит миллион долларов,  на самом деле), и выстрадан многолетним опытом. В случае реальной серьезной кибер атаки, первые 1-48 часов никто включая персонал и даже супер пупер генеральный с крутым образованием не будет понимать и знать с чем и кем он имеет дело и какой протокол спасения или безопасности задействовать. Это и есть основное отличие кибер атаки от промышленной аварии например. Второе отличие , никто и никогда не знает, чем и как закончится данная кибер атака. Пользуйтесь на переговорах, помогает. ).

Аргумент в поддержку чего? Вам тут пытаются сказать, что вероятности плохо подходят для описания процесса кибератак потому, что процесс поиска способов проникновения в вашу сеть — не случайный.

Про вероятности.
В среднем по миру 2 %, как писали выше. Для конкретного одного предприятия или да или нет, то бишь 50%.
Все остальное от лукавого.

Эту простейшую логику я понял много лет назад, когда ждал окончания операции на открытом сердце мой дочери.

Про вероятности.
В среднем по миру 2 %, как писали выше. Для конкретного одного предприятия или да или нет, то бишь 50%.
Все остальное от лукавого.

Эту простейшую логику я понял много лет назад, когда ждал окончания операции на открытом сердце мой дочери.

Кстати, процент "тяжёлых" случаев по Covid - 0,5%, умерло 0.3%.... но по факту это не значит что его стоит игнорировать и все это видят. Меры безопасности надо соблюдать.

Кстати, процент "тяжёлых" случаев по Covid - 0,5%, умерло 0.3%.... но по факту это не значит что его стоит игнорировать и все это видят. Меры безопасности надо соблюдать.

Именно. Применять вероятностный метод для безопасности как для safety или как для надежности плохо именно из-за детерминированной природы происходящего (или частично  случайной, например для шифровальщиков)

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

Теперь о недопонимании. Вероятно ))) многие из присутствующих используют слово "вероятность" в смысле probability, в то время как ISO 27005 и производные от него ссылаются на likelihood (что в переводе тоже обычно звучит как вероятность и вносит путаницу)

У Вас есть статья на эту тему? Ну так, что бы не "кажется", а со ссылками на работы Дейкстры и Липаева. Вот мне кажется 🙂, что с этой идеей статьи уже были. Теоретические проработки есть, но в практику, насколько я владею информацией, они не пошли.

В планах написание статьи в этом направлении есть, но к сожалению за научные статьи не платят.

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

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