Описание термина поверхность атаки см. здесь. Цели седьмого процесса по ГОСТ Р 56939-2024:
5.7.1.1 Создание условий для снижения количества недостатков, связанных с особенностями реализации архитектуры ПО и логики его функционирования, выработка мер по нейтрализации угроз безопасности, связанных с особенностями реализации архитектуры ПО.
5.7.1.2 Уточнение модели угроз и описания поверхности атаки по результатам разработки кода и его изменений.
При построении этого процесса важным руководствующим документом является уже упомянутый в предыдущем посте ГОСТ Р 58412-2019: Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения.
Собственно, ГОСТ Р 56939-2024 прямо на него ссылается в примечании к п.5.7.3.1:
При составлении перечня угроз безопасности и их описания рекомендуется учитывать положения ГОСТ Р 58412, а также угрозы безопасности информации Банка данных угроз безопасности информации ФСТЭК России, других источников (например, методологии STRIDE, Open Web Application Security Project (OWASP), DREAD и пр.). В модели угроз рекомендуется указывать использованную при моделировании методологию, в том числе в случае ее собственной разработки.
Зачем определять поверхности атаки? Давайте просто всё защищать, проверять и тестировать... В том-то дело, что так не получится, так как ресурсы и время ограничены. Современные программные системы содержат огромные объёмы собственного и стороннего кода. Просто невозможно и избыточно педантично изучать и проверить весь код. Необходимо выделить функции/модули, которые взаимодействуют с внешним миром и, скорее всего, будут подвергаться атаке. На них и следует сосредоточиться в первую очередь с точки зрения противостояния угрозам и более тщательного анализа/проверки/тестирования.
Ссылки по теме:
- Сигалов Даниил. Диссертация. Методы выявления поверхности атаки веб-приложений при помощи анализа клиентского JavaScript-кода.