C1: Определение требований безопасности

Описание

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

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

OWASP ASVS

Стандарт подтверждения безопасности приложений OWASP (ASVS) представляет собой каталог доступных требований безопасности и параметров проверки. OWASP ASVS может служить источником расширенных требований безопасности для команд разработчиков.

Требования безопасности объединены в категории на основе общих функций безопасности высшего порядка. Например, ASVS содержит следующие категории: аутентификация, контроль доступа, обработка и журналирование ошибок, а также веб-службы. Каждая категория содержит перечень требований, представляющих собой рекомендации для данной категории в виде списка проверяемых параметров.

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

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

Ниже представлен пример расширения требования ASVS 3.0.1. Пункт 2.19 раздела «Требования проверки аутентификации» ASVS 3.0.1 посвящен паролям по умолчанию:

2.19 Удостоверьтесь в том, что пароли, задаваемые по умолчанию (например, «admin/password»), не используются для фреймворка приложения или в каком-либо из компонентов приложения.

Данное требование описывает проверку на отсутствие паролей по умолчанию и запрет на использование паролей по умолчанию в приложении.

Сценарий эксплуатации приложения предполагает наличие пользователя, администратора или злоумышленника, а также описывает функциональные возможности системы на основе ожиданий пользователя. Сценарий эксплуатации заказчика представляется в следующей форме: «В качестве пользователя я могу выполнить x, y и z».

В качестве пользователя, для получения доступа к приложению, я могу ввести имя пользователя и пароль.

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

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

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

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

Реализация

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

Поиск и выбор

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

Исследование и документирование

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

Реализация и тестирование

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

Предотвращаемые уязвимости

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