Обзор аудита программного обеспечения
, Проверка программного обеспечения или аудит программного обеспечения , — это тип проверки программного обеспечения , при котором один или несколько аудиторов, не являющихся членами организации, занимающейся разработкой программного обеспечения, проводят «независимую проверку программного продукта, программного процесса или набора программных процессов для оценки соответствие спецификациям, стандартам, договорным соглашениям или другим критериям». [1]
«Программный продукт» в основном, но не исключительно, относится к некоторому техническому документу. Стандарт IEEE . 1028 [2] предлагает список из 32 «примеров программных продуктов, подлежащих аудиту», включая документальные продукты, такие как различные виды планов, контрактов, спецификаций, проектов, процедур, стандартов и отчетов, а также недокументированные продукты, такие как данные, данные испытаний. и доставляемые носители.
Аудит программного обеспечения отличается от экспертных проверок программного обеспечения и проверок управления программным обеспечением тем, что он проводится персоналом, внешним и независимым от организации, занимающейся разработкой программного обеспечения, и касается соответствия продуктов или процессов, а не их технического содержания и технического качества. или управленческие последствия.
Термин «проверка аудита программного обеспечения» используется здесь для обозначения формы аудита программного обеспечения, описанной в стандарте IEEE Std. 1028.
Цели и участники [ править ]
«Цель аудита программного обеспечения — обеспечить независимую оценку соответствия программных продуктов и процессов применимым нормам, стандартам, руководствам, планам и процедурам». [3] Рекомендуются следующие роли:
- Инициатор определяет (которым может быть руководитель проверяемой организации, представитель заказчика или пользователя проверяемой организации или третье лицо) принимает решение о необходимости проведения аудита, устанавливает его цель и объем, определяет критерии оценки, аудиторский персонал, решает, какие последующие действия потребуются, и распространяет аудиторский отчет.
- Ведущий аудитор (который должен быть человеком, «свободным от предвзятости и влияния, которые могут ограничить его способность проводить независимые, объективные оценки») отвечает за административные задачи, такие как подготовка плана аудита, формирование и управление аудиторской группой, а также за обеспечение того, чтобы аудит достигает своих целей.
- Регистратор документирует аномалии, действия, решения и рекомендации , сделанные аудиторской группой.
- Аудиторы (которые, как и ведущий аудитор, должны быть свободны от предвзятости) проверяют продукты, определенные в плане аудита, документируют свои наблюдения и рекомендуют корректирующие действия. (Одитор может быть только один.)
- Проверяемая организация обеспечивает связь с аудиторами и предоставляет всю информацию, запрошенную аудиторами. По завершении аудита проверяемая организация должна выполнить корректирующие действия и дать рекомендации.
аудита Принципы программного обеспечения
Должны найти отражение следующие принципы аудита: [4]
- Своевременность: только когда процессы и программы постоянно проверяются на предмет их потенциальной подверженности ошибкам и недостаткам, а также в отношении продолжения анализа обнаруженных сильных сторон или путем сравнительного функционального анализа с аналогичными приложениями, обновленная структура может быть обновлена. быть продолжено.
- Открытость исходного кода: при аудите зашифрованных программ требуется явная ссылка на то, как следует понимать обращение с открытым исходным кодом. Например, программы, предлагающие приложения с открытым исходным кодом, но не рассматривающие сервер обмена мгновенными сообщениями как открытый исходный код, должны рассматриваться как критически важные. Аудитор должен занять собственную позицию в отношении необходимости открытого исходного кода в криптологических приложениях.
- Продуманность: процессы аудита должны быть ориентированы на определенный минимальный стандарт. Недавние процессы аудита программного обеспечения для шифрования часто сильно различаются по качеству, объему и эффективности, а также по опыту восприятия в средствах массовой информации, часто различающееся восприятие. Из-за необходимости специальных знаний, с одной стороны, и умения читать программный код, а с другой стороны, знания процедур шифрования, многие пользователи доверяют даже самым коротким заявлениям формального подтверждения. Таким образом, индивидуальные обязательства аудитора, например, в отношении качества, масштаба и эффективности, должны оцениваться рефлексивно для вас самих и документироваться в ходе аудита.
- Финансовый контекст: необходима дополнительная прозрачность, чтобы уточнить, было ли программное обеспечение разработано на коммерческой основе и финансировался ли аудит из коммерческих источников (платный аудит). Имеет значение, является ли это частным хобби/общественным проектом или за ним стоит коммерческая компания.
- Научная ссылка на перспективы обучения. Каждый аудит должен подробно описывать результаты в контексте, а также конструктивно освещать прогресс и потребности в развитии. Аудитор не является родителем программы, но выполняет роль наставника, если аудитор рассматривается как часть учебного кружка PDCA ( PDCA = Планируй-Делай-Проверяй-Действуй). Рядом с описанием обнаруженных уязвимостей должно быть также описание инновационных возможностей и развития потенциала.
- Включение литературы: читатель не должен полагаться исключительно на результаты одного обзора, но также должен судить в соответствии с циклом системы управления (например, PDCA, см. выше), чтобы гарантировать, что команда разработчиков или рецензент были и подготовлены. для проведения дальнейшего анализа, а также в процессе разработки и обзора открыт для извлечения уроков и рассмотрения заметок других. Список литературы должен сопровождаться в каждом случае аудита.
- Включение руководств пользователя и документации: Далее следует проверить, имеются ли руководства и техническая документация и расширяются ли они.
- Определите ссылки на инновации: Приложения, которые позволяют обмениваться сообщениями как с оффлайн, так и с онлайн-контактами, поэтому рассмотрение чата и электронной почты в одном приложении - как и в случае с GoldBug - должно быть протестировано с высоким приоритетом (критерий присутствия чатов дополнительно к функции электронной почты). Аудитор должен также выделить ссылки на инновации и обосновать потребности в дальнейших исследованиях и разработках.
Этот список принципов аудита криптографических приложений описывает, помимо методов технического анализа, в частности, основные ценности, которые следует принимать во внимание.
Инструменты [ править ]
Часть аудита программного обеспечения может выполняться с использованием инструментов статического анализа, которые анализируют код приложения и оценивают его соответствие стандартам, рекомендациям и передовым практикам. Из списка инструментов для статического анализа кода некоторые охватывают очень широкий спектр — от анализа кода до проверки архитектуры — и могут быть использованы для сравнительного анализа.
Ссылки [ править ]
- ^ Стандарт IEEE . 1028-1997, Стандарт IEEE для проверок программного обеспечения , пункт 3.2.
- ^ «IEEE 1028-2008 — Стандарт IEEE для проверок и аудита программного обеспечения» . Standards.ieee.org . Проверено 12 марта 2019 г.
- ^ Стандарт IEEE. 10281997, п. 8.1
- ^ Ссылки на дополнительные основные принципы аудита в: Адамс, Дэвид / Майер, Анн-Катрин (2016): Исследование BIG SEVEN, сравниваемые крипто-мессенджеры с открытым исходным кодом - или: Комплексная проверка конфиденциальности и аудит GoldBug, шифрование электронной почты. -Client & Secure Instant Messenger, Описания, тесты и аналитические обзоры 20 функций приложения GoldBug на основе основных полей и методов оценки 8 основных международных руководств по аудиту для расследований ИТ-безопасности, включая 38 рисунков и 87 таблиц., URL: https://sf.net/projects/goldbug/files/bigseven-crypto-audit.pdf — английский/немецкий язык, версия 1.1, 305 страниц, июнь 2016 г. (ISBN: DNB 110368003X — 2016B14779)