Автомобильная безопасность требует бесконечного жизненного цикла разработки программного обеспечения

Zeitgeist Addendum [Full Movie] (June 2019).

$config[ads_text] not found
Anonim

В настоящее время четкая обязанность разработчиков автомобильной техники заключается в обеспечении того, чтобы небезопасное прикладное программное обеспечение не могло долго подрывать безопасность, поскольку продукт отсутствует в полевых условиях

МАРК ПИТЧФОРД, технический специалист
Программное обеспечение LDRA
www.ldra.com

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

Хотя известный стандарт ISO 26262: 2012 «Дорожные транспортные средства - функциональная безопасность» помогает, предоставляя формализованный процесс разработки программного обеспечения, он явно не обсуждает безопасность программного обеспечения. При этом, где уязвимости в области безопасности могут угрожать безопасности, ISO 26262 действительно требует целей и требований безопасности для решения этих проблем. Действия, которые необходимо предпринять для решения каждой проблемы безопасности, связанной с безопасностью, должны быть пропорциональны риску, используя схему классификации рисков безопасности для уровня безопасности для автомобилей (ISOAL) 26262.

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

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

Защита кода приложения
Для безопасной встроенной системы гораздо больше, чем для обеспечения безопасности кода приложения. Технологии, такие как защищенные от операционной системы, гипервизоры, ядра разделения и проверка целостности образа загрузки, имеют жизненно важные компоненты для игры. Эти технологии не только обеспечивают многоуровневую защиту от агрессоров, но также могут использоваться взаимодополняющим образом.

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

Использование анализа рисков может помочь в систематическом выявлении слабых мест, которые могут быть обнаружены в таких областях, как:

  • Интерфейсы между различными доменами
  • Интерфейсы к файлам извне сети
  • Интерфейсы, совместимые с обратной связью

    • Старые протоколы, иногда старый код и библиотеки, а также труднодоступные и труднодоступные несколько версий
  • Пользовательские интерфейсы прикладного программирования (API)
  • Код безопасности

    • Управление сеансом шифрования, аутентификации и авторизации

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

Разработка безопасного и безопасного кода приложения
Традиционный подход к защищенной разработке программного обеспечения имеет тенденцию быть реактивным: разработать программное обеспечение, а затем использовать проникновение, пух и функциональный тест, чтобы выявить любые недостатки. Полезно, хотя это, в отдельности, недостаточно, чтобы соответствовать функциональному стандарту безопасности, например, ISO 26262. Этот стандарт подразумевает, что факторы безопасности с последствиями безопасности считаются с самого начала, потому что критически важная для безопасности система не может быть безопасной если это не безопасно.

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

Рисунок 1: V-модель разработки программного обеспечения с перекрестными ссылками на ISO 26262 и стандартными инструментами разработки.

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

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

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

Рисунок 2: Инструменты статического анализа обеспечивают графическое представление взаимосвязи между компонентами кода для сравнения с предполагаемой конструкцией - в данном случае между контролем и потоком данных.

Показан типичный пример таблицы из ISO 26262-6: 2011, относящейся к проектированию и реализации программного обеспечения ( рис.3 ). В нем показаны принципы кодирования и моделирования, которые должны быть соблюдены во время реализации, накладываются с указанием того, где соответствие может быть подтверждено с помощью автоматизированных инструментов.

Рисунок 3: Руководства по кодированию и моделированию ISO 26262.

«Использование подмножества языков» (тема 1b в таблице) иллюстрирует влияние соображений безопасности на процесс. Языковые подмножества традиционно рассматривались как помощь безопасности, но повышение безопасности стандартов MISRA C: 2012 и стандартов безопасности, таких как Common Weakness Enumeration (CWE), отражает растущий интерес к той роли, которую они должны играть в борьбе с проблемами безопасности, Они также могут быть проверены с помощью статического анализа ( рис.4 ).

Рисунок 4: Нарушения стандартов кодирования улучшений безопасности для стандарта MISRA C: 2012 и стандартов безопасности, таких как Common Weakness Enumeration (CWE), могут быть проверены посредством статического анализа.

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

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

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

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

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

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

Затем возникает вопрос об изменениях требований. Что делать, если у клиента есть смятение? Яркая идея? Консультация адвоката о том, что существующие подходы могут быть проблематичными?

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

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

Автоматизированная двунаправленная прослеживаемость связывает требования от множества различных источников до проектирования, кодирования и тестирования. Влияние любых изменений требований (или, действительно, неудачных тестовых случаев) может быть оценено посредством анализа воздействия и соответствующим образом рассмотрено. И артефакты могут автоматически восстанавливаться, чтобы представить доказательства постоянного соответствия ISO 26262 ( рис.6 ).

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

Рисунок 6: Автоматическая двунаправленная прослеживаемость связывает требования от множества разных источников до проектирования, кода и тестирования.

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

Существующие инструменты и методы могут использоваться во время такого развития, иногда адаптированного к таким, как в случае безопасных правил кодирования, в дополнение к существующим с акцентом на безопасность. Некоторые методы, такие как анализ покрытия, используют точно подобный подход с совершенно иной целью - в том числе, в данном случае, обеспечение отсутствия какого-либо дополнительного кода «задней двери».

Двунаправленная прослеживаемость между требованиями, дизайнами, кодом и тестами является фундаментальным требованием ISO 26262, и его автоматизация может значительно сэкономить накладные расходы на управление проектом. Значение такой автоматизированной прослеживаемости повышается, когда влияние нарушения безопасности может означать новые требования к проектам после запуска продукта. В таких условиях быстрый ответ на изменение требований может как спасти жизни, так и повысить репутацию.