Анализ готовых приложений позволяет оценить защищенность с использованием различных моделей нарушителей в реальных условиях функционирования или близким к ним. Обычно выделяют следующие типы приложений: - веб-приложения – например, Интернет-банк, сервисы типа «Личный кабинет», системы дистанционного банковского обслуживания и пр.; - серверные приложения – автоматизированные банковские системы, программное обеспечение для процессинга операций по платежным картам и пр.; - десктопные приложения – тонкие и толстые клиенты и пр.; - мобильные приложения – мобильный банк, средства аутентификации и генерации одноразовых паролей (OTP), утилиты, игры и пр. Анализ готовых приложений может производиться как с помощью тестирования приложения на проникновение, так и с использованием реверс-инженерии. Анализ методом реверс-инженерии сложен, занимает много времени и дорогостоящ, поэтому крайне редко используется как самостоятельный вид анализа «больших» приложений (однако может быть использован в отдельных тестах и при анализе отдельных модулей). Анализ готовых приложений на проникновение производится обычно методами «черного» и/или «серого ящиков». В первом случае рассматривается модель внешнего по отношению к системе нарушителя, изначально не имеющего доступа в систему, во втором – внешнего нарушителя, имеющего доступ в систему (например, клиент, зарегистрированный в системе и имеющий учетную запись). В ходе тестирования приложения, помимо поиска технических уязвимостей, производится поиск недостатков в архитектуре и бизнес-логике приложений, осуществляется фаззинг. Используются как сканеры уязвимостей, так и, в основном, ручные проверки. Результаты попыток использования недостатков демонстрируются и документируются. Периодичность проверок. Анализ безопасности приложений может проводиться: - однократно, что позволит выявить и исправить текущие недостатки, а также внести изменения в процесс разработки и предотвратить появление уязвимостей, как подобных выявленным, так и других типов; - периодически, один или несколько раз в год, что позволит обнаруживать и устранять уязвимости, открытые сообществом либо появившиеся в приложении в результате изменений за время, прошедшее с последней проверки; - на постоянной основе при внесении изменений (как до изменения приложения в эксплуатации, так и на стадии тестирования) для оперативного и всеобъемлющего контроля. Для анализа безопасности приложений на постоянной основе обычной практикой является проведение полного первичного аудита, а затем, по мере возникновения необходимости, меньших по масштабу проверок изменений (проверке подлежат отдельные модули или части приложения, которые были подвергнуты изменению). При повторных проверках аудитору нет необходимости тратить время на изучение архитектуры приложения и особенностей его функционирования, что позволяет максимально сократить сроки и стоимость таких проверок. Повторные проверки могут быть проведены как в виде разовых услуг, так и по подписке (например, в течение года). Функционирующее приложение может быть скомпрометировано не только из-за недостатков, допущенных на стадии программирования. Доступ в рабочую систему может быть получен через уязвимости окружения – операционную систему , сервисы и программы сервера, на котором запущено приложение, систему управления баз данных , другие серверы и рабочие станции, входящие в один домен с сервером или пользователями приложения. Поэтому, наряду с тестированием приложения эффективно провести и тестирование инфраструктуры. Также может быть проверен исходный код приложения при его наличии. Проверка кода позволяет большее количество уязвимостей, включая те, которые не могут быть идентифицированы при "слепом" тестировании. Подробнее