Black box, grey box, white box — какой пентест нужен вам?

Когда компания заказывает пентест, один из первых вопросов — что нужно предоставить команде, которая будет проводить проверку?

От этого зависит формат тестирования:

• Black box — согласуются только адреса или домены, а проверка идёт без внутренней информации о системе;

• Grey box — дополнительно раскрывается требуемые сведения о системе и предоставляется ограниченный доступ;

• White box — предоставляется полный доступ к внутреннему устройству системы.

Это не градация «плохой — хороший — лучший». Каждый формат нужен для своей задачи.

В нашей практике выбор зависит от того, какой риск важно оценить: внешнюю атаку, действия внутреннего нарушителя или полный анализ системы.

Разберем, в чем разница.

Black box

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

Из нашего опыта:

Black box хорошо показывает, насколько компания заметна и уязвима извне. На таких проектах часто всплывают проблемы с открытыми сервисами, устаревшими версиями ПО, неправильными настройками, лишними доступами или забытыми файлами конфигураций.

Но у black box есть ограничение: значительная часть времени уходит на разведку. Если срок пентеста ограничен, команда может не добраться до глубоких сценариев внутри приложения.

Поэтому black box — хороший выбор для проверки внешнего периметра, но не всегда лучший вариант для глубокого анализа веб-приложения, API или бизнес-логики.

Когда мы рекомендуем black box:

• нужно проверить защиту именно внешнего периметра;

• важно понять, что доступно атакующему со внешней сети;

• компания хочет оценить, какие данные и сервисы можно найти из открытых источников;

• нужно проверить базовую устойчивость публичных систем.

Grey box

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

• тестовые учетные записи;

• роли пользователей;

• описание бизнес-сценариев;

• API-документацию;

• схему компонентов;

• ограничения по тестированию.

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

Из нашего опыта:

Именно в grey box-подходе часто находятся уязвимости, которые сложно выявить в black box: там команда тратит время на поиск точки входа, а в grey box этот этап не нужен — доступ уже есть, и можно сразу заняться тем, что происходит дальше: искать способы связать отдельные находки в единую цепочку атаки. Например, найденная ошибка в токене сессии может открыть путь к административному аккаунту, а оттуда — к конфиденциальным данным, недоступным изначально в бизнес-логике.

Поэтому, если клиент спрашивает: «Какой формат выбрать для веб-приложения?», мы часто предлагаем начать именно с grey box. Он сосредоточен на устройстве самого приложения, бизнес логики, ролях и данных, а не на поиске точки входа на ресурсе.

Когда мы рекомендуем grey box:

• нужно протестировать именно логику веб-приложение;

• есть личный кабинет, роли пользователей, админ-панель;

• нужно проверить API;

• важно найти уязвимости в разграничении прав или утечки данных;

• есть ограниченные сроки, но нужна глубокая и практичная проверка.

White box

White box-пентест предполагает максимальную прозрачность. Команда может получить:

• архитектурные схемы;

• документацию;

• конфигурации;

• доступ к тестовой среде;

• исходный код;

• описание интеграций;

• информацию о бизнес-процессах.

Цель white box — глубокий анализ системы.

Из нашего опыта:

White box особенно полезен там, где система большая, сложная или хорошо защищенная, например, состоит из множества сервисов с внешними интеграциями и разными уровнями доступа, тогда одних публичных данных (которых вообще может не оказаться, если система хорошо защищена) может быть недостаточно. В такой ситуации проверка снаружи методом проб и гипотез может занять непропорционально много времени и не дать результата. Но в White box команда сразу видит архитектуру целиком и может целенаправленно строить цепочки атак, зная наиболее уязвимые места системы. При этом такой подход требует больше подготовки от заказчика, однако позволяет наиболее полно проверить систему.

Когда мы рекомендуем white box:

• система критична для бизнеса;

• продукт готовится к запуску или крупному релизу;

• нужна глубокая проверка архитектуры;

• есть сложные интеграции и микросервисы;

• нужно найти максимум уязвимостей за доступное время;

• есть требования со стороны регуляторов, партнеров или крупных клиентов.

Как выбрать формат?

Коротко:

Мы проводим пентесты, в рамках которых можем проверить внешний периметр, веб-приложения, API и внутреннюю инфраструктуру. Перед стартом разбираем задачу: что нужно проверить, какие риски критичны, какие действия недопустимы и какой результат нужен бизнесу.

На выходе заказчик получает отчёт с описанием найденных по ходу работ уязвимостей, уровнем риска, шагами воспроизведения, журналом событий и рекомендациями по устранению. Если в ходе тестирования удалось выстроить цепочку из нескольких уязвимостей и скомпрометировать какие-то данные, аккаунт или целый ресурс, в отчёт добавляется отдельный блок с описанием этого вектора атаки. В нем показан путь от точки входа до конечного результата, со скриншотами, командами и подробным объяснением.

Если вы планируете провести пентест и не уверены, какой формат выбрать — оставьте заявку. Поможем подобрать подход и подготовиться к проверке.