Благодаря мудрому @islam_babaev, у нас теперь есть блог на сайте. Новые статьи будем публиковать там, старые тоже со временем пересем из телеграфа туда.

Продолжаем серию про небезопасные элементы безопасных систем. На этот раз по просьбам читателей -- ссылкой на блог.

Если «железо» не разработано согласно ИСО 26262, то в проект с требованиями безопасности оно попадет только после прохождения процедуры квалификации.
Квалификация проводится в контексте проекта, то есть один и тот же элемент подойдет в одном проекте и не подойдет в другом.
Стандарт ИСО 26262 предлагает разделить «небезопасные» аппаратные средства на три класса. Что это за классы, и как интегрируются в безопаснчые системы устройства разных классов, читаем по ссылке.

Тем временем глас народа поменялся: большинство за публикацию полных текстов на канале. Мне тоже так больше нравится 😀

Вот и прошли майские праздники 🎄
После паузы продолжаем публикации

Анализ безопасности

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

Сначала формулируются высокоуровневые требования. Такие требования называют целями. Затем продукт проектируют: разделяют на отдельные элементы и получают требования к ним. Элементы воплощают (пишут код, проектируют аппаратные средства) и тестируют отдельно друг от друга. За основу при тестировании берут требования к отдельным элементам, полученные на предыдущем этапе. Затем систему собирают и тестируют по высокоуровневым требованиям (целям).

Считается, что стоимость исправления ошибки с каждым этапом разработки растёт на порядок. Представим, что ошибка допущена на стадии воплощения. Исправление на стадии приемки (валидации) будет стоить в 10+ раз дороже, чем при проверке (верификации).

Полезность верификации напрямую зависит от того, насколько требования к элементам полно описывают цели всего продукта и соответствуют им. При этом рассматривать нужно не только позитивные сценарии («как должно быть»), но и негативные («как не должно быть»)

Посмотрим на процесс разработки, также известный как «V-модель».

Анализ системы именно для этого и нужен. Цели анализа:
* Определить полноту требований нижнего уровня
* Сформулировать дополнительные требования, если текущая спецификация неполна
* Создать дополнительные тестовые сценарии, чтобы убедиться, что требования нижнего уровня «покрывают» цели создания системы.

Итак, анализ – формализованная процедура, которая преобразует информацию об архитектуре и свойствах отдельных компонентов в выводы о функционировании всего продукта. Анализ выполняется по заранее выбранной методике. Для применения некоторых методов анализа используют специальные справочники.

Виды анализа безопасности

Процедуры, применяемые при анализе безопасности, делятся на два класса: индуктивные («анализ снизу вверх») и дедуктивные («анализ сверху вниз»). Кроме этого, анализ безопасности делят на количественный и качественный. Эта классификация не зависит от предыдущей.

Индуктивный анализ

Индуктивный анализ начинается со сбоев отдельных элементов и следует логике распространения отказов. После отказа элемента система переходит в «ошибочное состояние», т.е. состояние, отличающееся от того, которое ожидали проектировщики. Пребывание в этом состоянии вызывает сбои других элементов и в конечном счете – отказ, ситуацию, когда не выполняются функции.

На рисунке закрашенными точками меньшего размера показаны сбои компонентов, а точками большего размера – отказное состояние системы. Пунктирными линиями показано распространение отказа. За один шаг анализа (другими словами – строчкой в таблице, документирующий анализ) принимают «переход» от одного отказа к другому. Для каждого такого «перехода» можно определить параметры. Список параметров зависит от конкретного вида анализа. Эти параметры связаны с вероятностью «перехода» и/или вероятностью обнаружения отказа до того, как отказ начнет распространяться. По параметрам определяют критичность отказа. Затем разрабатывают меры, направленные против возникновения и/или распространения отказов. Чем критичнее отказ -- тем больший приоритет у мер по борьбе с ним.

К индуктивным видам анализа относится анализ видов и последствий отказов (АВПО). По-английски он называется Failure Mode and Effect Analysis (FMEA). Туда же -- подвиды FMEA: DFMEA (Design FMEA), SFMEA (System FMEA), FMEDA (Failure Modes, Effects and Diagnostics Analysis), FMECA (Failure modes, Effects and Cost Analysis), SW FMEA (Software FMEA) и т.п. Кроме того, анализ дерева событий (АДС, ETA), применяемый для поиска опасных путей исполнения программ -- тоже индуктивный.

Дедуктивный анализ

Дедуктивный анализ начинается с отказов системы и идёт «назад» – к сбоям отдельных элементов. В ходе анализа выясняется, какие сбои компонентов привели к интересующему отказу. Если сбоев больше одного – важно, в каких они отношениях. Если отказ происходит после двух сбоев, такие сбои объединяются логическим элементом «И», а если каждый сбой отдельно вызвает отказ – нужна логическая операция «ИЛИ».

Анализ дерева отказов (АДО; по-английски – Fault Tree Analysis, FTA) -- дедуктивный, как и все его подвиды: SW FTA, System FTA, HW FTA.

Резюме

Чтобы завершить разговор о различных видах анализа безопасности, приведем несколько таблиц.

Виды анализа безопасности

Входная информация

Результаты