Безопасность программного обеспечения

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

Программное обеспечение для общих электронных систем, связанных с безопасностью: IEC 61508. ^{[ 1 ]} (часть 3 стандарта)
Автомобильное программное обеспечение: ISO 26262. ^{[ 2 ]} (часть 6 стандарта)
Программное обеспечение для железных дорог: EN 50716. ^{[ 3 ]}
Бортовое программное обеспечение: DO-178C/ED-12C ) ^{[ 4 ]}
Программное обеспечение для управления воздушным движением: DO-278A/ED-109A. ^{[ 5 ]}
Медицинские приборы: МЭК 62304. ^{[ 6 ]}
Атомные электростанции: МЭК 60880. ^{[ 7 ]}

Терминология

Системная безопасность — это всеобъемлющая дисциплина, целью которой является достижение безопасности путем снижения рисков в технических системах до приемлемого уровня. В соответствии с широко распространенным стандартом безопасности системы IEC 61508 , ^{[ 1 ]} безопасность – это «свобода от неприемлемого риска причинения вреда». Поскольку само по себе программное обеспечение, которое можно рассматривать как чистую информацию, не может причинить никакого вреда, термин «безопасность программного обеспечения» иногда игнорируется и заменяется «безопасностью программной системы» (например, Joint Software Systems Safety Engineering Handbook). ^{[ 8 ]} и MIL-STD-882E ^{[ 9 ]} используйте эту терминологию). Это подчеркивает, что программное обеспечение может причинить вред только в контексте технической системы (см. Руководство по безопасности программного обеспечения НАСА, ^{[ 10 ]} глава 2.1.2), что оказывает определенное влияние на окружающую среду.

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

Назначение уровней безопасности

Одним из первых шагов при создании программного обеспечения, связанного с безопасностью, является классификация программного обеспечения в соответствии с его критичностью для безопасности. Различные стандарты предлагают разные уровни, например, уровни программного обеспечения AE в DO-178C , ^{[ 4 ]} SIL (уровень полноты безопасности) 1–4 в соответствии с IEC 61508, ^{[ 1 ]} ASIL (Уровень полноты автомобильной безопасности) AD в ISO 26262 . ^{[ 2 ]} Задание обычно выполняется в контексте всеобъемлющей системы, в которой исследуются наихудшие последствия сбоев программного обеспечения. Например, автомобильный стандарт ISO 26262 требует проведения оценки опасностей и рисков («HARA») на уровне транспортного средства для определения уровня ASIL программного обеспечения, выполняемого на компоненте.

Соблюдение процесса и гарантия

Крайне важно использовать адекватный процесс разработки и обеспечения безопасности с использованием соответствующих методов и технологий, соразмерных критичности безопасности программного обеспечения. Стандарты безопасности программного обеспечения рекомендуют, а иногда и запрещают использование таких методов и приемов, в зависимости от уровня безопасности. Большинство стандартов предлагают модель жизненного цикла (например, EN 50716, ^{[ 3 ]} SIL (уровень полноты безопасности) 1–4 в соответствии с IEC 61508 ^{[ 1 ]} предлагает, среди прочего, V-модель) и предписывает необходимые действия, которые необходимо выполнить на различных этапах разработки программного обеспечения. Например, IEC 61508 требует, чтобы программное обеспечение было задано адекватно (например, с использованием формальных или полуформальных методов), чтобы конструкция программного обеспечения была модульной и тестируемой, чтобы использовались адекватные языки программирования, выполнялись документированные проверки кода и чтобы тестирование было выполнил несколько слоев для достижения достаточно высокого тестового покрытия. Акцент на процессе разработки и обеспечения качества программного обеспечения обусловлен тем фактом, что качество программного обеспечения (и, следовательно, безопасность) во многом зависит от процесса разработки программного обеспечения, как это предполагает стандарт IEC 25010. ^{[ 11 ]} Утверждается, что процесс влияет на внутренние атрибуты качества программного обеспечения (например, качество кода), а они, в свою очередь, влияют на внешние атрибуты качества программного обеспечения (например, функциональность и надежность).

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

Документация

Практически все стандарты безопасности программного обеспечения требуют комплексной документации всего процесса разработки и обеспечения качества. Обычно эта документация проверяется и одобряется третьими лицами и, следовательно, является обязательным условием для утверждения программного обеспечения, связанного с безопасностью. Документация варьируется от различных документов планирования, спецификаций требований, архитектуры программного обеспечения и проектной документации, тестовых примеров на различных уровнях абстракции, отчетов о квалификации инструментов, доказательств проверки, результатов проверки и валидации и т. д. Рисунок C.2 в EN 50716 ^{[ 3 ]} перечисляет 32 документа, которые необходимо создать на протяжении жизненного цикла разработки.

Прослеживаемость

Прослеживаемость — это практика установления связей между различными типами требований, а также между требованиями и артефактами проектирования, реализации и тестирования. Согласно EN 50716, ^{[ 3 ]} цель «состоит в том, чтобы можно было продемонстрировать, что все требования были надлежащим образом выполнены и что не было внесено никаких неотслеживаемых материалов». Путем документирования и поддержания прослеживаемости становится возможным следовать, например, требованию безопасности при проектировании системы (чтобы проверить, адекватно ли оно считается), далее в исходном коде программного обеспечения (чтобы проверить, соответствует ли код требованию) и соответствующий тестовый пример и выполнение теста (чтобы проверить, были ли требования безопасности проверены адекватно).

Программная реализация

Стандарты безопасности могут иметь требования, непосредственно влияющие на реализацию программного обеспечения в исходном коде, такие как, например, выбор подходящего языка программирования, размер и сложность функций, использование определенных программных конструкций и необходимость стандартов кодирования. Часть 3 стандарта IEC 61508 содержит следующие требования и рекомендации:

Использование строго типизированного языка программирования. Некоторые языки лучше других подходят для систем, связанных с безопасностью. Языки, поддерживающие строгую типизацию, могут обнаружить больше ошибок в процессе компиляции, которые в противном случае были бы обнаружены только во время выполнения. Поэтому ассемблер обычно не рекомендуется, тогда как рекомендуются языки высокого уровня, специально предназначенные для рынка, связанного с безопасностью (например, ADA ).
Использование соответствующего стандарта кодирования, определяющего «безопасное» подмножество языка, например MISRA C. MISRA-C — это стандарт кодирования для языка программирования C, целью которого является повышение качества и безопасности кода за счет запрета конструкций, подверженных ошибкам, или функций, которые зависят от компилятора (и поведение которых поэтому не определено).
Ограничение использования рекурсии, указателей и прерываний (поскольку они подвержены ошибкам).
Запретить «неструктурированный поток управления в программах», т.е. избегать неструктурированных переходов, например, с помощью « goto ». операторов типа

Тестовое покрытие

Необходимо продемонстрировать соответствующий охват испытаний, т.е. в зависимости от уровня безопасности должны применяться более строгие схемы испытаний. Хорошо известное требование относительно тестового покрытия в зависимости от уровня программного обеспечения приведено в DO-178C: ^{[ 4 ]}

Уровень C: Требуется покрытие операторов, то есть «каждый оператор в программе был вызван хотя бы один раз» во время тестирования.
Уровень B: Требуется покрытие филиалов, т.е. «каждая точка входа и выхода в программе была задействована хотя бы один раз, и каждое решение в программе было принято по всем возможным результатам хотя бы один раз».
Уровень A: модифицированное покрытие условий/решений — расширение покрытия ветвей с требованием, чтобы «каждое условие в решении было показано, что оно независимо влияет на результат этого решения».

Независимость

Стандарты безопасности программного обеспечения обычно требуют, чтобы некоторые действия выполнялись независимо, т. е. другим человеком, лицом с разными линиями подчинения или даже независимой организацией. Это гарантирует предотвращение конфликтов интересов и увеличивает вероятность выявления ошибок (например, в конструкции программного обеспечения). Например, EN 50716. ^{[ 3 ]} Рисунок 2 требует, чтобы роли «исполнитель», «тестер» и «верификатор» выполнялись разными людьми, роль «валидатора» должна выполняться человеком с другой линией подчинения, а роль «оценщик» должна выполняться одним человеком. из другого организационного подразделения. ДО-178С ^{[ 4 ]} и ДО-278А ^{[ 5 ]} требуют, чтобы некоторые действия (например, проверка тестового покрытия, деятельность по обеспечению качества) выполнялись «с независимостью», при этом независимость определяется как «разделение обязанностей, которое обеспечивает выполнение объективной оценки».

Открытые вопросы и проблемы

Частота отказов программного обеспечения

В технике безопасности систем принято устанавливать верхние границы интенсивности отказов подсистем или компонентов. Затем необходимо показать, что эти подсистемы или компоненты не превышают назначенную им интенсивность отказов, или в противном случае необходимо использовать резервирование или другие механизмы отказоустойчивости. Этот подход неприменим для программного обеспечения. Частоту отказов программного обеспечения невозможно предсказать с какой-либо уверенностью. Хотя были проведены значительные исследования в области надежности программного обеспечения (см., например, Лю (1996), ^{[ 12 ]} текущие стандарты безопасности программного обеспечения не требуют использования ни одного из этих методов и даже не препятствуют их использованию, например DO178C. ^{[ 4 ]} (стр. 73) утверждает: «Было опубликовано множество методов прогнозирования надежности программного обеспечения на основе показателей разработки, например структура программного обеспечения, уровень обнаружения дефектов и т. д. Этот документ не содержит рекомендаций по этим типам методов, поскольку в то время С момента написания доступные в настоящее время методы не дали результатов, которым можно доверять». АРП 4761 ^{[ 13 ]} В пункте 4.1.2 говорится, что ошибки проектирования программного обеспечения «не то же самое, что отказы оборудования. В отличие от аппаратных сбоев, вероятность таких ошибок не поддается количественной оценке».

Безопасность и безопасность

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

Искусственный интеллект

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

Гибкие методы разработки

Гибкая разработка программного обеспечения , которая обычно включает в себя множество итераций, иногда до сих пор считается слишком хаотичной для разработки программного обеспечения, связанного с безопасностью. Частично это может быть вызвано такими утверждениями, как «работающее программное обеспечение важнее подробной документации», которые можно найти в манифесте гибкой разработки. ^{[ 14 ]} Хотя большинство стандартов безопасности программного обеспечения представляют жизненный цикл программного обеспечения в традиционной каскадной последовательности, некоторые из них содержат утверждения, которые допускают более гибкие жизненные циклы. DO-178C гласит: «Процессы жизненного цикла программного обеспечения могут быть итеративными, то есть вводиться и вводиться повторно». EN 50716 содержит Приложение C, которое показывает, как можно использовать итеративные жизненные циклы разработки в соответствии с требованиями стандарта.

Цели

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

См. также

Обеспечение программного обеспечения
МЭК 61508 — Функциональная безопасность электрических/электронных/программируемых электронных систем, связанных с безопасностью
ISO 26262 – Транспорт дорожный. Функциональная безопасность.
Функциональная безопасность
Качество программного обеспечения
Системная авария

Примечания

Ссылки

^ Jump up to: ^а ^б ^с ^д МЭК (2010). МЭК 61508 — Функциональная безопасность электрических/электронных/программируемых электронных систем, связанных с безопасностью . Международная электротехническая комиссия.
^ Jump up to: ^а ^б ИСО (2018). ISO 26262 — Транспорт дорожный. Функциональная безопасность . Международная организация по стандартизации.
^ Jump up to: ^а ^б ^с ^д ^и СЕНЭЛЕК (2023). EN 50716 – Железнодорожные приложения – Требования к разработке программного обеспечения . СЕНЕЛЕК.
^ Jump up to: ^а ^б ^с ^д ^и РТКА (2012). DO-178C — Вопросы программного обеспечения при сертификации бортовых систем и оборудования . как ED-12C RTCA (также опубликованный Eurocae ).
^ Jump up to: ^а ^б РТКА (2011). DO-278A — Вопросы обеспечения целостности программного обеспечения для систем связи, навигации, наблюдения и управления воздушным движением (CNS/ATM) . как ED-109A RTCA (также опубликованный Eurocae ).
^ МЭК (2006). Программное обеспечение медицинского оборудования. Процессы жизненного цикла программного обеспечения . Международная электротехническая комиссия.
^ МЭК (2006). измерительные приборы и системы управления, важные для безопасности - Аспекты программного обеспечения для компьютерных систем, выполняющих функции категории А. Атомные электростанции - Контрольно - Международная электротехническая комиссия.
^ Министерство обороны США (2010). Совместное руководство по обеспечению безопасности программных систем . Министерство обороны США.
^ Министерство обороны США (2012). MIL-STD-882E — Безопасность системы . Министерство обороны США.
^ НАСА (2004). Руководство НАСА по безопасности программного обеспечения . НАСА.
^ ИСО (2011). ISO 25010 — Разработка систем и программного обеспечения. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программного обеспечения . Международная организация по стандартизации.
^ Майкл Р. Лю (1996). Справочник по проектированию надежности программного обеспечения . Издательство IEEE Computer Society Press и книжная компания McGraw-Hill.
^ САЭ АРП (2023 г.). ARP 4761 — Руководство по проведению процесса оценки безопасности гражданских самолетов, систем и оборудования . Рекомендуемая практика SAE Aerospace (также опубликованная Eurocae как ED-135).
^ https://agilemanifesto.org/

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

[iec61508-1] Jump up to: ^а ^б ^с ^д МЭК (2010). МЭК 61508 — Функциональная безопасность электрических/электронных/программируемых электронных систем, связанных с безопасностью . Международная электротехническая комиссия.

[iso26262-2] Jump up to: ^а ^б ИСО (2018). ISO 26262 — Транспорт дорожный. Функциональная безопасность . Международная организация по стандартизации.

[en50716-3] Jump up to: ^а ^б ^с ^д ^и СЕНЭЛЕК (2023). EN 50716 – Железнодорожные приложения – Требования к разработке программного обеспечения . СЕНЕЛЕК.

[do178c-4] Jump up to: ^а ^б ^с ^д ^и РТКА (2012). DO-178C — Вопросы программного обеспечения при сертификации бортовых систем и оборудования . как ED-12C RTCA (также опубликованный Eurocae ).

[do278a-5] Jump up to: ^а ^б РТКА (2011). DO-278A — Вопросы обеспечения целостности программного обеспечения для систем связи, навигации, наблюдения и управления воздушным движением (CNS/ATM) . как ED-109A RTCA (также опубликованный Eurocae ).

[iec62304-6] МЭК (2006). Программное обеспечение медицинского оборудования. Процессы жизненного цикла программного обеспечения . Международная электротехническая комиссия.

[iec60880-7] МЭК (2006). измерительные приборы и системы управления, важные для безопасности - Аспекты программного обеспечения для компьютерных систем, выполняющих функции категории А. Атомные электростанции - Контрольно - Международная электротехническая комиссия.

[jsssehdbk-8] Министерство обороны США (2010). Совместное руководство по обеспечению безопасности программных систем . Министерство обороны США.

[milstd882e-9] Министерство обороны США (2012). MIL-STD-882E — Безопасность системы . Министерство обороны США.

[nasa-10] НАСА (2004). Руководство НАСА по безопасности программного обеспечения . НАСА.

[iec25010-11] ИСО (2011). ISO 25010 — Разработка систем и программного обеспечения. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программного обеспечения . Международная организация по стандартизации.

[lyu1996-12] Майкл Р. Лю (1996). Справочник по проектированию надежности программного обеспечения . Издательство IEEE Computer Society Press и книжная компания McGraw-Hill.

[arp4761-13] САЭ АРП (2023 г.). ARP 4761 — Руководство по проведению процесса оценки безопасности гражданских самолетов, систем и оборудования . Рекомендуемая практика SAE Aerospace (также опубликованная Eurocae как ED-135).

[14] ttps://agilemanifesto.org/

[ 1 ]

[ 2 ]

[ 3 ]

[ 4 ]

[ 5 ]

[ 6 ]

[ 7 ]

[ 8 ]

[ 9 ]

[ 10 ]

[ 11 ]

[ 12 ]

[ 13 ]

[ 14 ]