Руслан Рахметов, Security Vision
Современные злоумышленники используют несколько эффективных векторов атак, основными из которых являются фишинг, использование ВПО и эксплуатация уязвимостей. Именно уязвимости позволяют атакующим проникнуть в защищаемую инфраструктуру, а автоматизированные проверки приложений на наличие уязвимостей помогают им масштабировать и ускорить кибератаки. Многие компании, особенно крупные, сами разрабатывают программное обеспечение - от служебных утилит до высоконагруженных веб-приложений. В таком случае сама компания отвечает за своевременное обнаружение уязвимостей и выпуск обновлений для их устранения. И атакующие, и разработчики, несмотря на диаметрально противоположные цели, заинтересованы в быстром обнаружении уязвимостей - для этого используются различные методологии и инструменты. В данной статье рассмотрим основные методы тестирования приложений в ИБ с помощью методов «белого», «серого» и «черного» ящиков.
Начнем с терминологии:
· Метод «белого ящика» (White box, метод «открытого ящика») подразумевает тестирование системы (ПО) при наличии предварительного знания о ней - архитектуры, документации, исходного кода, описания её поведения;
· Метод «серого ящика» (Gray box) подразумевает тестирование системы (ПО) при наличии частичного предварительного знания о ней - могут быть известны общее описание всей системы или более точные описания лишь отдельных её частей;
· Метод «черного ящика» (Black box, метод «закрытого ящика») подразумевает тестирование системы (ПО) без наличия предварительного знания о ней - без понимания её архитектуры, без наличия документации и исходного кода, без исходного понимания её поведения.
1. White box тестирование
Методом «белого ящика» пользуются разработчики, тестировщики, ИБ-аудиторы и специалисты по AppSec, которым важно отслеживать безопасность ПО на каждом этапе жизненного цикла. Метод «открытого ящика» используется также для того, чтобы устранить все баги и ошибки, которые напрямую не влияют на безопасность, но могут негативно сказаться на пользовательском опыте и эффективности работы информационной системы. Проверки методом «White box» занимают, как правило, длительное время по причине достаточно большой глубины тестирования и многостороннего характера проверок (безопасность, функционал, UI/UX, совместимость и т.д.). Для повышения эффективности White box-проверок систему (ПО) можно декомпозировать на несколько составных частей или логических модулей, проводя последовательное тестирование каждого из них, а затем проверяя их связность и взаимодействие как единого целого. Кроме того, именно метод «открытого ящика» позволяет проанализировать сценарии атак со стороны внутреннего нарушителя - инсайдера, который может иметь легитимный привилегированный доступ к системе и хорошо знать её особенности и даже архитектуру.
Для автоматизации тестирования методом «белого ящика» можно использовать методы статического анализа кода, в частности, использовать статические анализаторы и решения для статического тестирования безопасности приложений (SAST, Static Application Security Testing). Статические анализаторы - это решения для автоматизации крайне трудоёмкого ручного процесса code review (код-ревью), который подразумевает вычитку исходного кода и формирование рекомендаций по его улучшению. Самые простые статические анализаторы встроены в большинство компиляторов - они предупреждают разработчиков о тривиальных ошибках и опечатках. SAST-решения сфокусированы на выявлении уязвимостей в коде на самых ранних этапах, когда цена устранения ошибки гораздо ниже. Инструменты статического анализа кода не гарантируют стопроцентный результат, дают высокий уровень ложноположительных срабатываний, не могут обнаружить ошибки конфигурирования - в целом, их задача заключается в том, чтобы подсветить разработчикам, тестировщикам и ИБ-аудиторам возможные проблемные места и автоматически проверить код на самые распространенные типы ошибок. Для эффективной работы со статическими анализаторами и в целом с методом «белого ящика» от проверяющих потребуется высокая экспертиза и значительные трудозатраты. Кроме того, в рамках тестирования методом «белого ящика» могут быть использованы такие инструменты, как решения для анализа состава ПО (SCA, Software Composition Analysis) и решения для анализа компонентов с открытым исходным кодом (OSA, Open Source Analysis).
Если же обратиться к нормативно-правовой документации, то в стандарте ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования» статический анализ исходного кода программы определяется как вид работ по инструментальному исследованию программы, основанный на анализе исходного кода программы с использованием специализированных инструментальных средств (статических анализаторов) в режиме, не предусматривающем исполнения кода, и выполняемый для определения свойств программы; в частности, статический анализ применяется для выявления потенциальных ошибок в программе. Кроме того, для статического анализа утвержден стандарт ГОСТ Р 71207-2024 «Защита информации. Разработка безопасного программного обеспечения. Статический анализ программного обеспечения. Общие требования».
Отметим, что злоумышленники могут также использовать метод тестирования White box, но только для тех продуктов, к исходному коду которых они имеют доступ - например, к решениям на базе Open Source, применяемым целевой компанией-жертвой, или если они получили доступ к исходному коду продукта, который уже используется различными заказчиками.
2. Gray box тестирование
Тестирование методом «серого ящика» позволяет компании компенсировать некоторые недостатки тестирования White box - такие как ресурсозатратность и длительность, а также частично воспроизвести действия злоумышленника, который обладает ограниченными привилегиями в системе. Gray box тестирование может моделировать сценарии атак со стороны APT-группы, которая уже длительное время собирает информацию о жертве и используемом ей ПО - в результате, такие продвинутые атакующие получают частичное знание о том, как работает система и какие техники можно использовать для её компрометации. В случае проверки системы методом пентеста специалисты предварительно получают общее представление об архитектуре системы и обладают ограниченными учетными записями в ней (например, не административные привилегии, а пользовательские). С одной стороны, такие ограничения сужают скоуп пентеста и не позволяют выявить все уязвимости, с другой - не дают пентестерам возможности случайно нарушить работу информационной системы. Тестирование методом «серого ящика» могут выбрать те компании, которые при моделировании угроз и нарушителя сделали вывод о том, что для них актуальны атаки со стороны высокомотивированных атакующих (APT-группы, киберпреступные синдикаты, киберармии, продвинутые хактивисты).
3. Black box тестирование
Метод «черного ящика» позволяет взглянуть на ПО или информационную систему в целом глазами внешних атакующих, которые, не обладая предварительными знаниями о ней, будут искать потенциально эксплуатируемые уязвимости методом перебора точек входа, веб-форм, передаваемых параметров и поиска потенциально опасных конструкций и элементов, используя дебаггеры и декомпиляторы. Кроме того, атакующие будут искать уязвимости не только в самой системе, но и в её конфигурации, и в примененных мерах защиты, включая СЗИ. Таким образом, метод «закрытого ящика» позволяет смоделировать действия реальных атакующих различной степени подготовленности и целеустремленности.
Тестирование методом Black box может быть разделено на пять фаз:
· Разведка: получение первичной информации о цели (системе или ПО), включая поиск документации, руководств, отзывов потребителей, сообществ пользователей продукта в соцсетях;
· Сканирование: поиск «входных точек», таких как открытые порты, баннеры, API-эндпоинты, формы ввода данных, доступные для вызова методы, веб-запросы;
· Перечисление: получение детальной информации об атакуемой системе, включая учетные записи и группы пользователей, каталоги, общие папки, данные об инфраструктуре и устройствах в сети;
· Получение доступа: осуществление несанкционированного (или санкционированного, в случае пентеста) доступа за счет взлома паролей, использования уязвимостей, социальной инженерии;
· Повышение привилегий и закрепление: для успешного выполнение задачи пентеста требуются, как правило, повышенные привилегии, а также методы сохранения доступа в скомпрометированную сеть (например, за счет бэкдоров, реверс-шеллов, инструментов удаленного интерактивного управления).
При тестировании методом «черного ящика» могут быть использованы средства автоматизации, такие как решения для динамического анализа кода (DAST, Dynamic Application Security Testing) - они позволяют выявлять уязвимости и моделировать работу пользователей и атакующих с системой. В отличие от SAST, решения для динамического анализа кода не имеют доступа к исходному коду, однако позволяют обнаруживать ошибки и уязвимости уже во время работы скомпилированной программы. Если же обратиться к определению из стандарта ГОСТ Р 56939-2024, то динамический анализ кода программы определяется как вид работ по инструментальному исследованию программы, основанный на анализе кода программы в режиме непосредственного исполнения (функционирования) кода. В целом, DAST-решения работают с тестируемым ПО с точки зрения пользователя (или атакующего), задача которого - найти уязвимость в запущенном приложении. Для этого используется в том числе метод фаззинга (англ. fuzzing), при котором на вход приложения намеренно подаются некорректные, неправильно сформированные, неожиданные или случайные данные в целях проверки безопасности и устойчивости приложения к подобным ошибкам.
Таким образом, DAST-решения помогают выявить ошибки на более поздних этапах жизненного цикла разработки ПО, но могут позволить обнаружить уязвимости, которые появляются только после установки и запуска программы (например, уязвимости конфигурации). Кроме DAST, используются продукты для интерактивного анализа кода (IAST, Interactive Application Security Testing) и для поведенческого анализа кода (BAST, Behavioral Application Security Testing), которые также работают с уже запущенным приложением и позволяют выявить его недостатки на более поздних стадиях цикла разработки. IAST-решения проверяют безопасность потоков команд и данных запущенного приложения и проверяют его работу со средой исполнения и инфраструктурой (например, доступ к файлам, вызов системных функций, открытие сокетов и т.д.). BAST-решения проверяют безопасность и корректность работы критичного для бизнеса функционала приложения (например, доступ к чувствительными данным, использование шифрования, аутентификация пользователей и т.д.).
Подводя итог, можно выделить следующие характерные отличия SAST инструментов для тестирования методом «белого ящика» и DAST инструментов для тестирования методом «черного ящика»:
· SAST-решение анализирует исходный код системы, в то время как DAST-решение тестирует уже готовое и запущенное приложение;
· SAST подразумевает тестирование внутренних компонентов системы с точки зрения разработчика, а DAST тестирует внешнюю «оболочку» системы, моделируя действия атакующего;
· SAST не может обнаружить недостатки и уязвимости, связанные со средой исполнения или проявляющиеся только во время выполнения программы, а DAST может;
· SAST позволяет обнаружить недостатки и уязвимости в системе на более ранних стадиях жизненного цикла разработки, что помогает снизить стоимость их исправления, а DAST обнаруживает проблемы на более поздних этапах разработки, что повышает стоимость их устранения;
· Для более эффективного устранения ошибок и уязвимостей рекомендуется совместно использовать и SAST, и DAST инструменты на разных этапах разработки ПО, а также применять решения классов IAST, BAST, SCA, OSA.
