AC
Скорее, испытательная лаборатория
Не, тут же речь о матмодели, как я понимаю.
Size: a a a
2020 December 25
AZ
Risk= Consequences X (Threats X Vulnerabilities) X Likelihood. C и V как-то можно определить/предусмотреть , а T и L чисто эмпирические значения. Так что все сводятся к оценкам вроде: низкий, умеренный, высокий, очень высокий, итд. Конечно, все хотят цифры - им и выдумывают цифры, но только в коммерческих целях. Клиент хозяин, что хочет, то получает.
AI
В предверии новогодних праздников позволю себе сделать сообществу маленький подарок )) дам совет который стоит миллион долларов, на самом деле), и выстрадан многолетним опытом. В случае реальной серьезной кибер атаки, первые 1-48 часов никто включая персонал и даже супер пупер генеральный с крутым образованием не будет понимать и знать с чем и кем он имеет дело и какой протокол спасения или безопасности задействовать. Это и есть основное отличие кибер атаки от промышленной аварии например. Второе отличие , никто и никогда не знает, чем и как закончится данная кибер атака. Пользуйтесь на переговорах, помогает. ).
Мне кажется, не совсем верно. Коллеги и киберучения проводят вовсю..
W
Мне кажется, не совсем верно. Коллеги и киберучения проводят вовсю..
Полезное дело, для предотвращения уже известных инциндентов.
ER
Как мне кажется частично можно применять вероятностный подход при оценке безопасности связанной с надежностью программного обеспечения. Так как согласно теории надежности программного обеспечения можно построить функцию потока отказов программного обеспечения, как следствие получить функцию распределения вероятности отказов. Далее основываясь на предположении о том часть ошибок программного обеспечения возможно эксплуатировать программными (прграммно-аппаратными) закладками можно создать функцию распределения вероятности успешной атаки на автоматизированную систему.
Нет, не так. Это Вы вероятность существования уязвимости посчитаете. И все.
O
Ekaterina Rudina
Нет, не так. Это Вы вероятность существования уязвимости посчитаете. И все.
Ну он на правильном пути. Ему теперь надо посчитать вероятность мисконфигурации, вероятность прочих человеческих факторов, потом проделать все то же самое для всей цепочки поставок и золотой ключик у него в кармане :)
rr
Дмитрий П
Не обязательно все мерять через деньги. Авторитет специалиста не менее важное явление. К тому же, его можно монетизировать 🙂. Если будет черновик статьи, готов помочь в доработке и публикации.
Спасибо за предложение, как руки дойдут до статей связанных с надежностью программного обеспечения, напишу. У меня 4 статьи было написано в 19 году и вот только первая вышла на публикацию.
rr
Но это может измерить только сам разработчик, либо орган сертификации. Так ведь? По количесвтву строк, системных вызовов, ветвлений и т.п.
В первую очередь сам разработчик. Расчет надежности программного обеспечения лучше всего проводить на этапе завершения цикла разработки, например, с использованием модели оценки надежности Шумана.
AC
В первую очередь сам разработчик. Расчет надежности программного обеспечения лучше всего проводить на этапе завершения цикла разработки, например, с использованием модели оценки надежности Шумана.
Это будет как и "обычная" надёжность: сколько вам надо, столько и посчитаем
rr
Ekaterina Rudina
Нет, не так. Это Вы вероятность существования уязвимости посчитаете. И все.
А потом введя коэффициенты на основе модели нарушителя получить функцию распределения вероятности успешной атаки на автоматизированную систему.
ЗЫ Да коэффициенты эмпирические, но функцию распределения вероятности мы получим.
ЗЫ Да коэффициенты эмпирические, но функцию распределения вероятности мы получим.
rr
Это будет как и "обычная" надёжность: сколько вам надо, столько и посчитаем
Это у нас любят такие "надежности" считать в рамках ОКР и т.п. работ. Причем те кто считает и те кто проверяют находятся, как правило, на уровне культа Карго в части понимания расчета надёжности. В реальной, не православноимпортоазмещающейнантехнологичнойгитхабовскотыренской разработке программного обеспечения стоит задача по разработке надежного, качественного кода, который будучи развернут в автоматизированной системе должен обеспечивать целевую функцию в том числе при деструктивных внешних воздействиях.
AC
Это у нас любят такие "надежности" считать в рамках ОКР и т.п. работ. Причем те кто считает и те кто проверяют находятся, как правило, на уровне культа Карго в части понимания расчета надёжности. В реальной, не православноимпортоазмещающейнантехнологичнойгитхабовскотыренской разработке программного обеспечения стоит задача по разработке надежного, качественного кода, который будучи развернут в автоматизированной системе должен обеспечивать целевую функцию в том числе при деструктивных внешних воздействиях.
Правильно считать надёжность научили именно буржуи :) На этом они сабаку съели с MTBF, MTTF и т.д.
rr
Правильно считать надёжность научили именно буржуи :) На этом они сабаку съели с MTBF, MTTF и т.д.
Наша классическая теория надежности для технических объектов не хуже, достаточно открыть учебники 60-80 готов издания. Другое дело это надежность программного обеспечения - тут у нас просто провал.
P
а еще непонятно сколько умерло от последствий ковида.
P
Вредоносная кампания, в рамках которой злоумышленники взломали целый ряд правительственных учреждений и технологических компаний через вредоносное обновление для ПО SolarWinds Orion, также затронула десятки предприятий критической инфраструктуры. По данным компании, занимающейся расследованием взломов некоторых организаций, среди пострадавших – электроэнергетические, нефтяные и производственные компании, пользующиеся ПО Orion, пишет The Intercept.
https://www.securitylab.ru/news/515112.php
https://www.securitylab.ru/news/515112.php
O
Это у нас любят такие "надежности" считать в рамках ОКР и т.п. работ. Причем те кто считает и те кто проверяют находятся, как правило, на уровне культа Карго в части понимания расчета надёжности. В реальной, не православноимпортоазмещающейнантехнологичнойгитхабовскотыренской разработке программного обеспечения стоит задача по разработке надежного, качественного кода, который будучи развернут в автоматизированной системе должен обеспечивать целевую функцию в том числе при деструктивных внешних воздействиях.
В реальной, а не вот это слово, разработке кода стоит задача оптимизации не по надёжности, а по стоимости.
rr
В реальной, а не вот это слово, разработке кода стоит задача оптимизации не по надёжности, а по стоимости.
Может быть у вас стоит задача оптимизации по стоимости, моя задача что бы код был надежен и устойчив.
ДП
Наша классическая теория надежности для технических объектов не хуже, достаточно открыть учебники 60-80 готов издания. Другое дело это надежность программного обеспечения - тут у нас просто провал.
Липаев с его многочисленными работами не в счёт? 🙂
O
Может быть у вас стоит задача оптимизации по стоимости, моя задача что бы код был надежен и устойчив.
Это вы про свой код? Тогда не буду спорить. :)
AC
В реальной, а не вот это слово, разработке кода стоит задача оптимизации не по надёжности, а по стоимости.
Оптимизируют не "код", а "продукт"/"программу". Это первое правило оптимизации... Оптимизировать по скорости скаду или антивирус - весьма спорное утверждение.