Фреймворк для интеграции безопасности приложений в разработку программного обеспечения (FIASSE)

Примечание: Этот репозиторий находится в стадии активной разработки. Вклад приветствуется!

Обзор

Кратко: пожалуйста, прочитайте DOC. Изучите веб-сайт FIASSE. Посетите GitHub Discussions, чтобы внести свой вклад.

Этот репозиторий содержит ресурсы и материалы для фреймворка OWASP по интеграции безопасности приложений в разработку программного обеспечения (FIASSE). FIASSE (произносится /feiz/, как «phase») — это независимый от поставщиков фреймворк, который продвигает ориентированный на разработчика, основанный на принципах подход к созданию защищаемого программного обеспечения. Он признаёт, что безопасность — это динамичный, непрерывный процесс, подобный разработке. Он вводит Модель разработки защищаемого программного обеспечения (SSEM) как общий язык проектирования, который использует устоявшиеся термины программной инженерии для интеграции безопасности в архитектуру, проектирование и разработку программного обеспечения путём встраивания безопасности в принципы, формирующие сам код. Фреймворк позволяет командам разработчиков устойчиво создавать вычислительную ценность, снижая вероятность материального ущерба от киберсобытий на протяжении всего жизненного цикла кода.

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

Назначение

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

Чем это отличается?

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

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

Ключевые ценности

FIASSE ориентирован на четыре ключевые ценности. Каждая выражает относительное предпочтение: обе стороны имеют ценность, но когда необходимо сделать выбор, FIASSE отдаёт предпочтение левой.

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

Ключевые принципы

• Парадигма защищаемости: Не существует статичного состояния «безопасно». Система, объявленная безопасной сегодня, может оказаться уязвимой завтра. FIASSE перенаправляет инженерную цель с вопроса «безопасна ли она?» на вопрос «построена ли она так, чтобы безопасность можно было поддерживать?» через адаптивную устойчивость, эволюционную безопасность и непрерывное совершенствование.
• Устойчивое создание вычислительной ценности: Основная директива программной инженерии в бизнес-контексте. Программное обеспечение должно удовлетворять функциональным требованиям, сохраняя при этом качества защищаемости, позволяющие ему выдерживать изменения, нагрузку и атаки, следующие за каждым изменением.
• Миссия безопасности: снижение материального ущерба: Миссия безопасности — снизить вероятность материального ущерба от киберсобытия. Полное устранение утечек не является практичной бизнес-целью, поэтому стратегии безопасности должны соответствовать бизнес-целям и допустимому уровню риска.
• Взаимосвязь качества и безопасности: Безопасность не может превышать качество программного обеспечения. Качества, которые делают программное обеспечение простым для понимания, изменения, тестирования и наблюдения, — это те же качества, которые делают возможным его защиту. Инвестиции в инженерное качество — это инвестиции в безопасность.
• Безопасность, ориентированная на разработчика: Расширение возможностей инженеров-программистов создавать защищаемые системы с использованием знакомых принципов программной инженерии, вместо требования перенимать образ мышления пентестера.
• SSEM как общий язык проектирования: Использование устоявшихся терминов программной инженерии (например, анализируемость, модифицируемость, тестируемость) для определения и обсуждения атрибутов безопасности. Это делает безопасность доступной для разработчиков и даёт специалистам по безопасности общую основу для оценки.
• Согласование безопасности с целями разработки и бизнеса: Безопасность и разработка дополняют друг друга, а не противостоят. AppSec участвует в SDLC на ранних этапах, особенно при сборе требований и планировании функций, чтобы ожидания были явными до написания кода.
• Принцип прозрачности: Системы проектируются так, чтобы авторизованные стороны могли понимать внутреннее состояние и поведение. Структурированное журналирование, инструментирование и аудиторские следы встраиваются в код, а не обеспечиваются только внешними инструментами.
• Принцип наименьшего удивления: Системы ведут себя интуитивно и предсказуемо для пользователей, разработчиков и администраторов. Предсказуемость помогает анализу, снижает когнитивную нагрузку и делает границы доверия ясными.
• Требования как полноправный участник AppSec: Функции безопасности, сценарии угроз и критерии приёмки безопасности реализуются через процесс работы с требованиями. Уязвимости часто восходят к ожиданию, которое никогда не было специфицировано, поэтому этот пробел относится к процессу работы с требованиями.

Инженерные принципы

Раздел 4 фреймворка даёт разработчикам принципы, применимые непосредственно на уровне кода: