A04:2021- Небезопасный дизайн

Обзор

Новая категория для 2021 года, в которой основное внимание уделяется рискам, связанным с недостатками проектирования. Если мы ходим двигаться в ином направлении, нам нужно больше моделирования угроз, моделей и принципов безопасного проектирования и эталонных архитектур. Как сообщество, мы должны прекратить тесирование подходом "Shift-left" в програмирование и перейти к другим эталонным архитектурам до начала написания кода. Это имеет решающее значение для безопасности дизайна. Известные CWE: CWE-209: Генерация сообщения об ошибке, содержащего конфиденциальную информацию, CWE-256: Незащищенное хранение учетных данных, CWE-501: Нарушение границ доверия и CWE-522: Недостаточно защищенные учетные данные.

Описание

Небезопасный дизайн – это широкая категория, представляющая различные недостатки, выраженные как “отсутствующий или неэффективный дизайн управления”. Небезопасный дизайн не является источником для всех остальных 10 основных категорий рисков. Существует разница между небезопасным дизайном и небезопасной реализацией. Мы различаем недостатки дизайна и дефекты реализации по определенной причине, у них разные коренные причины и способы устранения. Безопасный дизайн все еще может иметь дефекты реализации, приводящие к уязвимостям, которыми можно пользоваться. Небезопасный дизайн не может быть исправлен совершенной реализацией, поскольку по определению необходимые средства контроля безопасности никогда не создавались для защиты от конкретных атак. Одним из факторов, способствующих небезопасному проектированию, является отсутствие профилирования бизнес-рисков, присущих разрабатываемому программному обеспечению или системе, и, следовательно, неспособность определить, какой уровень безопасности требуется.

Требования и управление ресурсами

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

Безопасный Дизайн

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

Жизненный цикл безопасной разработки

Безопасное программное обеспечение требует жизненного цикла безопасной разработки, формы безопасного шаблона проектирования, методологии с твердым покрытием, библиотеки защищенных компонентов, инструментов и моделирования угроз. Обращайтесь к своим специалистам по безопасности в начале проекта программного обеспечения на протяжении всего проекта и обслуживания вашего программного обеспечения. Рассмотрите возможность использования модели зрелости OWASP Software Assurance (SAMM), чтобы помочь структурировать ваши усилия по разработке безопасного программного обеспечения.

Как предотвратить

• Установите и используйте жизненный цикл безопасной разработки с профессионалами AppSec, чтобы помочь оценить и разработать средства контроля безопасности и конфиденциальности.
• Создайте и используйте библиотеку безопасных шаблонов проектирования или готовых к использованию компонентов с твердым покрытием.
• Используйте моделирование угроз для критической аутентификации, контроля доступа, бизнес-логики и потоков ключей.
• Объединяйте язык безопасности и элементы управления в истории пользователя.
• Интегрируйте проверки достоверности на каждом уровне вашего приложения (от внешнего интерфейса до внутреннего).
• Напишите модульные и интеграционные тесты для проверки устойчивости критических потоков к модели угроз. Составьте варианты использования и случаи неправильного использования для каждого уровня вашего приложения.
• Разделите уровни на системные и сетевые в зависимости от потребностей в воздействии и защите.
• Выделите арендаторов по дизайну на всех уровнях.
• Ограничьте потребление ресурсов пользователем или сервисом.

Примеры сценариев атак

Сценарий № 1: Рабочий процесс восстановления учетных данных может включать “вопросы и ответы”, что запрещено NIST 800-63b, ASV OWASP и 10 топ OWASP. Вопросам и ответам нельзя доверять как доказательству личности, потому что ответы могут знать более одного человека. Поэтому они запрещены. Такую реализацию следует удалить и заменить более безопасным дизайном.

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

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