В этом материале рассматривается, что ISO 27001 означает для тестирования безопасности приложений и как построить масштабируемый процесс тестирования и управления уязвимостями, который также формирует полезные доказательства соответствия требованиям.
A.8.29: Security testing in development and acceptance
Для организаций, которые разрабатывают приложения, внедрение этого контроля может предусматривать создание определенного и повторяемого подхода к тестированию безопасности вместо полной зависимости от несистематических проверок. Конкретная реализация должна учитывать риски организации, технологии, процессы разработки и практики выпуска.
SAST и DAST естественно вписываются в эту часть программы безопасности приложений, поскольку автоматизированное сканирование можно интегрировать от ранних этапов разработки, например IDE, репозитория или даже интеграции средств безопасности с AI-ассистентом для написания кода, до staging или тестовой среды для DAST.
Сканирование контейнеров и SCA (анализ программных компонентов) для выявления рисков в библиотеках также являются важными составляющими общей программы безопасности, о которых не стоит забывать.
Что касается частоты тестирования, приложения, которые часто изменяются или обрабатывают чувствительные данные, могут требовать более регулярных проверок, чем системы с более низким уровнем риска и относительно стабильной функциональностью.
A.8.8: Management of technical vulnerabilities
Практический процесс управления уязвимостями связывает их выявление с проверкой, приоритизацией, назначением ответственных, устранением или принятием риска, повторным тестированием и закрытием. Именно здесь качество результатов проверок безопасности приобретает особое значение.
Если разработчики регулярно получают ложноположительные срабатывания или результаты с низким уровнем уверенности, командам безопасности приходится тратить время на их проверку еще до начала устранения. Эту проблему можно решить с помощью автоматического подтверждения уязвимостей, как это реализовано в Invicti.
A.8.26: Application security requirements
В зависимости от приложения требования к безопасности могут охватывать аутентификацию, авторизацию, обработку входных данных, управление сессиями, шифрование, журналирование, доступ к API, безопасную конфигурацию и защиту от соответствующих классов уязвимостей. Тестирование позволяет определить, были ли конкретные требования реализованы надлежащим образом.
DAST не может проверить все требования к безопасности приложений. Требования, связанные с исходным кодом, архитектурой, зависимостями или контролями, которые невозможно наблюдать во время выполнения, могут требовать SAST, SCA, анализа архитектуры, ручного тестирования или других методов.
Требует ли ISO 27001 проведения тестирования на проникновение?
ISO 27001 не устанавливает универсального требования для каждой организации проводить ежегодное тестирование на проникновение.
DAST и тестирование на проникновение выполняют взаимодополняющие функции. Автоматизированный DAST обеспечивает повторяемое покрытие приложений и API и может запускаться значительно чаще, чем ручное тестирование, тогда как пентест позволяет проводить более глубокий анализ в случаях, когда этого требуют риски приложения, существенные изменения, договорные требования или другие обстоятельства.
Распространенные ошибки при внедрении тестирования безопасности приложений для ISO 27001
Восприятие сканирования как самого контроля. Сканирование является лишь одной активностью в рамках процесса безопасности. Организации также должны определять охват, оценивать результаты, назначать ответственных за устранение, обрабатывать риски и проверять исправления.
Полная зависимость от разового тестирования. Ручные проверки обеспечивают ценную глубину анализа, но приложения могут изменяться значительно чаще, чем реально проводить тестирование на проникновение. Автоматизированное тестирование может обеспечивать повторяемое покрытие между ручными проверками и после изменений в приложении.
Тестирование только функциональности без аутентификации. Многие приложения открывают важную функциональность только после входа. Там, где это уместно и технически возможно, тестирование с аутентификацией может обеспечить более репрезентативное покрытие.
Исключение API из охвата тестирования. API могут предоставлять доступ к функциональности приложений и чувствительным данным независимо от традиционного веб-интерфейса. Стратегия тестирования должна учитывать API, которые имеют значение для приложений организации и ее профиля риска.
Отрыв результатов от процесса устранения. Отчет об уязвимостях имеет ограниченную ценность, если никто не отвечает за конкретные результаты и не отслеживает дальнейшие действия. Интеграция результатов проверок безопасности в процессы разработки помогает превращать результаты тестирования в конкретные действия по устранению.
Одинаковое отношение ко всем результатам. Команды безопасности редко располагают неограниченными ресурсами для устранения. Техническая критичность, возможность эксплуатации, доступность приложения, важность для бизнеса и другой контекст помогают определить, какие уязвимости требуют внимания в первую очередь.
Вывод: создавайте повторяемый процесс безопасности, а не безопасность только на время аудита
Цель заключается в создании повторяемого процесса безопасности приложений, который выявляет значимые уязвимости, дает уверенность в уровне риска, передает результаты командам, способным их устранить, и формирует полезные доказательства соответствия требованиям.
Для усиления тестирования безопасности приложений в рамках программы ISO 27001 можно запросить бесплатное тестирование интегрированных решений Invicti DAST и Mend.io для SAST, SCA, сканирования контейнеров, обновления зависимостей и безопасности AI.
