В предыдущих главах уже упоминался анализ безопасности. В этой серии статей расскажем, что это такое, как работает в функциональной и кибер-безопасности, и приведем примеры.
Анализ безопасности: что это и зачем?
Посмотрим на процесс разработки, также известный как «V-модель».
Сначала формулируются высокоуровневые требования. Такие требования называют целями. Затем продукт проектируют: разделяют на отдельные элементы и получают требования к ним. Элементы воплощают (пишут код, проектируют аппаратные средства) и тестируют отдельно друг от друга. За основу при тестировании берут требования к отдельным элементам, полученные на предыдущем этапе. Затем систему собирают и тестируют по высокоуровневым требованиям (целям).
Считается, что стоимость исправления ошибки с каждым этапом разработки растёт на порядок. Представим, что ошибка допущена на стадии воплощения. Исправление на стадии приемки (валидации) будет стоить в 10+ раз дороже, чем при проверке (верификации).
Полезность верификации напрямую зависит от того, насколько требования к элементам полно описывают цели всего продукта и соответствуют им. При этом рассматривать нужно не только позитивные сценарии («как должно быть»), но и негативные («как не должно быть»).
Анализ системы именно для этого и нужен. Цели анализа:
- Определить полноту требований нижнего уровня
- Сформулировать дополнительные требования, если текущая спецификация неполна
- Создать дополнительные тестовые сценарии, чтобы убедиться, что требования нижнего уровня «покрывают» цели создания системы.
Итак, анализ – формализованная процедура, которая преобразует информацию об архитектуре и свойствах отдельных компонентов в выводы о функционировании всего продукта. Анализ выполняется по заранее выбранной методике. Для применения некоторых методов анализа используют специальные справочники.
Виды анализа безопасности
Процедуры, применяемые при анализе безопасности, делятся на два класса: индуктивные («анализ снизу вверх») и дедуктивные («анализ сверху вниз»). Кроме этого, анализ безопасности делят на количественный и качественный. Эта классификация не зависит от предыдущей.
Индуктивный анализ
Индуктивный анализ начинается со сбоев отдельных элементов и следует логике распространения отказов. После отказа элемента система переходит в «ошибочное состояние», т.е. состояние, отличающееся от того, которое ожидали проектировщики. Пребывание в этом состоянии вызывает сбои других элементов и в конечном счете – отказ, ситуацию, когда не выполняются функции.
На рисунке закрашенными точками меньшего размера показаны сбои компонентов, а точками большего размера – отказное состояние системы. Пунктирными линиями показано распространение отказа. За один шаг анализа (другими словами – строчкой в таблице, документирующий анализ) принимают «переход» от одного отказа к другому. Для каждого такого «перехода» можно определить параметры. Список параметров зависит от конкретного вида анализа. Эти параметры связаны с вероятностью «перехода» и/или вероятностью обнаружения отказа до того, как отказ начнет распространяться. По параметрам определяют критичность отказа. Затем разрабатывают меры, направленные против возникновения и/или распространения отказов. Чем критичнее отказ — тем больший приоритет у мер по борьбе с ним.
К индуктивным видам анализа относится анализ видов и последствий отказов (АВПО). По-английски он называется 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.
Резюме
Чтобы завершить разговор о различных видах анализа безопасности, приведем несколько таблиц.
Роль SafetyConsult
У специалистов SafetyConsult большой опыт проведения анализа безопасности
- Проведем анализ за вас
- Поможем вашим инженерам провести анализ
- Создадим и развернем процессы анализа на предприятии
- Проверим анализ, пришедший от поставщика
