Недавно коллега поделился взглядом. На первый взгляд, парадоксально, но что-то в этом явно есть.
— Зачем, — спрашивает коллега, — нужны тормоза в автомобиле?
— Ну, чтобы тормозить, гасить скорость, — отвечаю я.
— Нет, тормоза нужны, чтобы быстро ехать.
— ???
— Если бы тормозов не было, ездили бы медленно, скажем, со скоростью до 10 км/ч. А когда тормоза есть и исправны — можно разгоняться, зная, что если что, всегда затормозишь.
Вот так и с безопасной разработкой. Безопасная разработка позволяет нам "быстро ехать" (реализовывать потенциально опасный функционал), зная, что у нас есть механизм сведения риска к минимуму.
— Зачем, — спрашивает коллега, — нужны тормоза в автомобиле?
— Ну, чтобы тормозить, гасить скорость, — отвечаю я.
— Нет, тормоза нужны, чтобы быстро ехать.
— ???
— Если бы тормозов не было, ездили бы медленно, скажем, со скоростью до 10 км/ч. А когда тормоза есть и исправны — можно разгоняться, зная, что если что, всегда затормозишь.
Вот так и с безопасной разработкой. Безопасная разработка позволяет нам "быстро ехать" (реализовывать потенциально опасный функционал), зная, что у нас есть механизм сведения риска к минимуму.
Небезопасные элементы безопасных систем
В прошлом посте обсуждалось встраивание в проект с требованиями безопасности компоненты, разработанные разными командами. При этом сами компоненты отвечали стандартам безопасности, вопрос только в том, как правильно все объединить. Но в безопасные продукты интегрируются и «небезопасные» компоненты. Решения таких задач описаны в стандартах. Рассматриваем на примере ИСО 26262, а точнее, ИСО 26262-8. Нас интересуют два «поддерживающих процесса:
· Квалификация компонентов ПО (глава 12)
· Оценка элементов аппаратной части (глава 13)
В прошлом посте обсуждалось встраивание в проект с требованиями безопасности компоненты, разработанные разными командами. При этом сами компоненты отвечали стандартам безопасности, вопрос только в том, как правильно все объединить. Но в безопасные продукты интегрируются и «небезопасные» компоненты. Решения таких задач описаны в стандартах. Рассматриваем на примере ИСО 26262, а точнее, ИСО 26262-8. Нас интересуют два «поддерживающих процесса:
· Квалификация компонентов ПО (глава 12)
· Оценка элементов аппаратной части (глава 13)
Еще немного о названиях
В стандарте ИСО 26262 и связанных стандартах слово «элемент» используется в значении «часть целого». Элементом -- это часть устройства (например, ЭБУ трансмиссии), подсистема, а также часть аппаратных средств или программного обеспечения.
«Компонент» обозначает часть ЭБУ: либо аппаратный, либо программный.
Для «неделимых» компонентов в случае ПО используется термин «модуль ПО» («SW unit»), а в случае аппаратных средств – «часть» («HW part»). Критерий неделимости -- наличие описанных интерфейсов и функционала. Дополнительный критерий -- прагматический: объявляем неделимым, если не хотим лезть внутрь.
В стандарте ИСО 26262 и связанных стандартах слово «элемент» используется в значении «часть целого». Элементом -- это часть устройства (например, ЭБУ трансмиссии), подсистема, а также часть аппаратных средств или программного обеспечения.
«Компонент» обозначает часть ЭБУ: либо аппаратный, либо программный.
Для «неделимых» компонентов в случае ПО используется термин «модуль ПО» («SW unit»), а в случае аппаратных средств – «часть» («HW part»). Критерий неделимости -- наличие описанных интерфейсов и функционала. Дополнительный критерий -- прагматический: объявляем неделимым, если не хотим лезть внутрь.
Часть 1. Квалификация компонентов ПО
Чтобы квалифицировать "внешний" компонент ПО (по-английски он называется сomponent off-the-shelf или COTS), нужно собрать информацию о нем, получить требования из контекста проекта и сравнить их.
Необходимая информация о COTS
Для безопасного контекста подходят только компоненты ПО, для которых известна следующая информация:
· Назначение,, версию и требования конфигурации
· Спецификация требований, описывающая функционал и интерфейсы.
· Отчет о тестировании, включающий метрики покрытия и методы тестирования
· Процесс, по которому компонент разработан. Процессы берутся из стандартов безопасности или из моделей технологической зрелости (capability maturity models), например, SPICE и CMMI. Для автомобильного ПО на основе SPICE разработана модель Automotive SPICE (ASPICE).
Необходимая информация со стороны проекта
Чтобы встроить COTS, из «безопасного» проекта получают:
· Требования к ПО со стороны проектаТребования включают как «позитивные», так и «негативные» (т.е. требования к поведению в ситуации отказа).
· Максимальный уровень ASIL, назначаемый на интегрируемое ПО
· Ограничения, накладываемые на конфигурацию интегрируемого ПО
Чтобы квалифицировать "внешний" компонент ПО (по-английски он называется сomponent off-the-shelf или COTS), нужно собрать информацию о нем, получить требования из контекста проекта и сравнить их.
Необходимая информация о COTS
Для безопасного контекста подходят только компоненты ПО, для которых известна следующая информация:
· Назначение,, версию и требования конфигурации
· Спецификация требований, описывающая функционал и интерфейсы.
· Отчет о тестировании, включающий метрики покрытия и методы тестирования
· Процесс, по которому компонент разработан. Процессы берутся из стандартов безопасности или из моделей технологической зрелости (capability maturity models), например, SPICE и CMMI. Для автомобильного ПО на основе SPICE разработана модель Automotive SPICE (ASPICE).
Необходимая информация со стороны проекта
Чтобы встроить COTS, из «безопасного» проекта получают:
· Требования к ПО со стороны проектаТребования включают как «позитивные», так и «негативные» (т.е. требования к поведению в ситуации отказа).
· Максимальный уровень ASIL, назначаемый на интегрируемое ПО
· Ограничения, накладываемые на конфигурацию интегрируемого ПО
Процесс интеграции
1. Сбор информации о внешнем компоненте.
2. Привязка требований. Требования к внешнему компоненту («внешние») трассируются к требованиям, полученным из проектного контекста («внутренним»). Возможна ситуация, когда внешние требования полностью покрывают внутренние. Но так это редкость. Чаще остается непокрытая часть – «дополнительные» требования, которые придется выполнить в проекте, написав дополнительное ПО или изменив то, что есть. Если такой вариант не подходит, изменяют внутренние требования. При этом учитывается дерево требований вплоть до целей безопасности.
3. Проверка ограничений по конфигурации – отвечаем на вопрос «Можно ли технически интегрировать компонент ПО туда, куда нужно?»
4. Если критических ограничений нет, следует интеграция.
5. Затем идет интеграционное тестирование по внутренним требованиям проекта. Если тестирование заканчивается без замечаний – COTS встроен, работа окончена. Если нет, придется менять требования.
1. Сбор информации о внешнем компоненте.
2. Привязка требований. Требования к внешнему компоненту («внешние») трассируются к требованиям, полученным из проектного контекста («внутренним»). Возможна ситуация, когда внешние требования полностью покрывают внутренние. Но так это редкость. Чаще остается непокрытая часть – «дополнительные» требования, которые придется выполнить в проекте, написав дополнительное ПО или изменив то, что есть. Если такой вариант не подходит, изменяют внутренние требования. При этом учитывается дерево требований вплоть до целей безопасности.
3. Проверка ограничений по конфигурации – отвечаем на вопрос «Можно ли технически интегрировать компонент ПО туда, куда нужно?»
4. Если критических ограничений нет, следует интеграция.
5. Затем идет интеграционное тестирование по внутренним требованиям проекта. Если тестирование заканчивается без замечаний – COTS встроен, работа окончена. Если нет, придется менять требования.
Еще раз про требования
Если часть требований к ПО, полученные внутри проекта, не удается связать со спецификацией требований к интегрируемому ПО, возникают дополнительные требования, тоже нужные в проекте. Ради них придется дописать или изменить имеющийся код.
Альтернативный подход: изменить требования к ПО внутри проекта так, чтобы дополнительных требований не оставалось. Но это несет риск перестройки проекта на разных уровнях.
Если часть требований к ПО, полученные внутри проекта, не удается связать со спецификацией требований к интегрируемому ПО, возникают дополнительные требования, тоже нужные в проекте. Ради них придется дописать или изменить имеющийся код.
Альтернативный подход: изменить требования к ПО внутри проекта так, чтобы дополнительных требований не оставалось. Но это несет риск перестройки проекта на разных уровнях.
Роль SafetyConsult
Инженеры SafetyConsult помогут с интеграцией COTS в проект:
· Разработаем процесс управления требованиями
· Создадим, проанализируем, трассируем требования требований, трассировка
· Улучшим процесс тестирования ПО, поможем с внедрением мер и методов согласно стандартам
· Проведем аудит процессов поставщика, в т.ч. поставщика ПО.
Инженеры SafetyConsult помогут с интеграцией COTS в проект:
· Разработаем процесс управления требованиями
· Создадим, проанализируем, трассируем требования требований, трассировка
· Улучшим процесс тестирования ПО, поможем с внедрением мер и методов согласно стандартам
· Проведем аудит процессов поставщика, в т.ч. поставщика ПО.
Once we understand this chart, we´ve won the war
В далеком 2006 году офицерам штаба американских войск в Афганистане дали задание учесть различные факторы, влияющие на успешность боевых действий. В результате родилась эта диаграмма. Ее показали командующим частями -- на одном слайде Power Point.
Один из офицеров заметил: «Как только мы поймем эту диаграмму, то можно считать, войну выиграли» (оригинальная фраза -- в заголовке)
В SafetyConsult учитывают чужой опыт, так что наши диаграммы гораздо яснее, конкретнее и логичнее.
В далеком 2006 году офицерам штаба американских войск в Афганистане дали задание учесть различные факторы, влияющие на успешность боевых действий. В результате родилась эта диаграмма. Ее показали командующим частями -- на одном слайде Power Point.
Один из офицеров заметил: «Как только мы поймем эту диаграмму, то можно считать, войну выиграли» (оригинальная фраза -- в заголовке)
В SafetyConsult учитывают чужой опыт, так что наши диаграммы гораздо яснее, конкретнее и логичнее.
Благодаря мудрому @islam_babaev, у нас теперь есть блог на сайте. Новые статьи будем публиковать там, старые тоже со временем пересем из телеграфа туда.
Как лучше публиковать?
Anonymous Poll
59%
Публиковать на канале статьи целиком (как делается сейчас)
41%
Публиковать на канале только краткую аннотацию и ссылку на статью
Продолжаем серию про небезопасные элементы безопасных систем. На этот раз по просьбам читателей -- ссылкой на блог.
Если «железо» не разработано согласно ИСО 26262, то в проект с требованиями безопасности оно попадет только после прохождения процедуры квалификации.
Квалификация проводится в контексте проекта, то есть один и тот же элемент подойдет в одном проекте и не подойдет в другом.
Стандарт ИСО 26262 предлагает разделить «небезопасные» аппаратные средства на три класса. Что это за классы, и как интегрируются в безопаснчые системы устройства разных классов, читаем по ссылке.
Квалификация проводится в контексте проекта, то есть один и тот же элемент подойдет в одном проекте и не подойдет в другом.
Стандарт ИСО 26262 предлагает разделить «небезопасные» аппаратные средства на три класса. Что это за классы, и как интегрируются в безопаснчые системы устройства разных классов, читаем по ссылке.
SafetyConsult: Инженерия безопасности
Как лучше публиковать?
Тем временем глас народа поменялся: большинство за публикацию полных текстов на канале. Мне тоже так больше нравится 😀
Вот и прошли майские праздники 🎄
После паузы продолжаем публикации
После паузы продолжаем публикации
Анализ безопасности
В предыдущих главах уже упоминался анализ безопасности. В этой серии статей расскажем, что это такое, как работает в функциональной и кибер-безопасности, и приведем примеры.
В предыдущих главах уже упоминался анализ безопасности. В этой серии статей расскажем, что это такое, как работает в функциональной и кибер-безопасности, и приведем примеры.
Сначала формулируются высокоуровневые требования. Такие требования называют целями. Затем продукт проектируют: разделяют на отдельные элементы и получают требования к ним. Элементы воплощают (пишут код, проектируют аппаратные средства) и тестируют отдельно друг от друга. За основу при тестировании берут требования к отдельным элементам, полученные на предыдущем этапе. Затем систему собирают и тестируют по высокоуровневым требованиям (целям).
Считается, что стоимость исправления ошибки с каждым этапом разработки растёт на порядок. Представим, что ошибка допущена на стадии воплощения. Исправление на стадии приемки (валидации) будет стоить в 10+ раз дороже, чем при проверке (верификации).
Полезность верификации напрямую зависит от того, насколько требования к элементам полно описывают цели всего продукта и соответствуют им. При этом рассматривать нужно не только позитивные сценарии («как должно быть»), но и негативные («как не должно быть»)
Считается, что стоимость исправления ошибки с каждым этапом разработки растёт на порядок. Представим, что ошибка допущена на стадии воплощения. Исправление на стадии приемки (валидации) будет стоить в 10+ раз дороже, чем при проверке (верификации).
Полезность верификации напрямую зависит от того, насколько требования к элементам полно описывают цели всего продукта и соответствуют им. При этом рассматривать нужно не только позитивные сценарии («как должно быть»), но и негативные («как не должно быть»)
Анализ системы именно для этого и нужен. Цели анализа:
* Определить полноту требований нижнего уровня
* Сформулировать дополнительные требования, если текущая спецификация неполна
* Создать дополнительные тестовые сценарии, чтобы убедиться, что требования нижнего уровня «покрывают» цели создания системы.
* Определить полноту требований нижнего уровня
* Сформулировать дополнительные требования, если текущая спецификация неполна
* Создать дополнительные тестовые сценарии, чтобы убедиться, что требования нижнего уровня «покрывают» цели создания системы.
Виды анализа безопасности
Процедуры, применяемые при анализе безопасности, делятся на два класса: индуктивные («анализ снизу вверх») и дедуктивные («анализ сверху вниз»). Кроме этого, анализ безопасности делят на количественный и качественный. Эта классификация не зависит от предыдущей.
Процедуры, применяемые при анализе безопасности, делятся на два класса: индуктивные («анализ снизу вверх») и дедуктивные («анализ сверху вниз»). Кроме этого, анализ безопасности делят на количественный и качественный. Эта классификация не зависит от предыдущей.