Объем заказа на пентест: руководство для профессионалов

Объем заказа - один из наиболее недооцениваемых элементов всего процесса тестирования на проникновение. Большинство пентестеров понимают, что такое пентест в общем смысле, но воспринимают scope как простой список IP-адресов для сканирования. Это ошибка, которая обходится проектам временем, деньгами и репутацией. Объем заказа - это формальная фиксация границ теста, которая определяет активы, техники и продолжительность тестирования. Без точного определения scope даже лучший пентестер работает вслепую, а клиент получает отчет, который не отвечает его реальным потребностям.

Содержание

• Составные элементы объема заказа в пентестинге

• Как модель black/grey/white box влияет на объем и ход тестирования на проникновение

• Роль точного определения объема в правовой защите и качестве результатов теста

• Практические рекомендации и примеры определения объема в пентестах веб-приложений и API

• Затраты и ресурсы в зависимости от объема пентест-заказа

• Почему точное определение объема - главная сложность и ключ к успеху пентеста

• Инструменты и оборудование для пентеста, поддерживающие выполнение объема заказа

• Часто задаваемые вопросы

Ключевые выводы

Составные элементы объема заказа в пентестинге

Перейдя от общего введения, рассмотрим подробно ключевые компоненты объема заказа. Объем пентест-заказа не однороден. Он состоит из трех отдельных измерений, каждое из которых задает свои границы теста и требует отдельного согласования с клиентом.

Объем заказа разбивается на scope целей, scope техник и временной scope. Это трехчастное деление, которое полезно использовать как шаблон на каждой стартовой встрече с клиентом. Из нашего опыта как поставщика пентест-оборудования мы знаем, что клиенты чаще всего возвращаются за дополнительными инструментами именно тогда, когда объем заказа меняется в ходе проекта - точное определение scope в самом начале экономит время и бюджет.

Scope целей определяет, какие системы, сети и приложения подлежат тестированию. Включает:

• Конкретные IP-адреса, диапазоны CIDR или доменные имена

• Веб-приложения, указанные по URL или среде (производственная, staging)

• Исключения - системы, которые тестировщик не вправе затрагивать, например, производственные системы третьих сторон

• Сетевые устройства: маршрутизаторы, межсетевые экраны, коммутаторы

• Облачную инфраструктуру с указанием учетных записей и регионов

Scope техник определяет, какие методы атаки разрешены. Это одна из областей, где чаще всего возникают недоразумения. Клиент может ожидать полноценного теста, но запрещать эксплуатацию уязвимостей из-за опасения простоя системы. Scope техник охватывает решения по:

• Эксплуатации уязвимостей (с payload'ом или без)

• Атакам типа отказа в обслуживании (DoS), которые, как правило, запрещены в производственных средах

• Социальной инженерии, фишингу и pretexting'у

• Физическим атакам на инфраструктуру

• Методам эскалации привилегий и lateral movement

Временной scope - это окно, в котором может проводиться тестирование. Определяет часы и дни допустимых тестовых действий. Включает также blackout-периоды - запретные промежутки времени, например, в период закрытия финансовой отчетности или обновления систем. Пропуск этого элемента приводит к ситуации, когда тестировщик запускает сканер в пятницу в 23:00, а мониторинг клиента фиксирует тревогу, которую никто не ожидает обработать.

Рекомендуем ознакомиться с методологиями тестирования на проникновение, которые уточняют, как эти три измерения формализуются в различных отраслевых фреймворках.

Как модель black/grey/white box влияет на объем и ход тестирования на проникновение

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

Модель black/grey/white box определяет уровень знаний и доступ тестировщика, что, в свою очередь, влияет на то, насколько детально необходимо формулировать объем заказа в документации.

Несколько практических наблюдений по каждой модели:

• Black box требует расширенного scope целей, поскольку тестировщик должен самостоятельно картировать инфраструктуру. Scope техник здесь обычно шире, но ограничен внешними действиями.

• Grey box - наиболее часто выбираемая модель в коммерческих услугах тестирования безопасности. Scope учитывает предоставленные клиентом учетные данные и возможные сетевые диаграммы.

• White box переносит акцент scope на техническую документацию. Тестировщику нужен доступ к репозиторию кода, диаграммам архитектуры и конфигурациям систем. Scope должен точно указывать, какие репозитории и среды охвачены тестом.

Подробный обзор оборудования, поддерживающего реализацию различных моделей black/grey/white box, найдете в отдельной статье.

Роль точного определения объема в правовой защите и качестве результатов теста

Рассмотрев модели тестирования, сосредоточимся на правовых и качественных последствиях, вытекающих из объема. Это область, которую многие пентестеры воспринимают как формальность. Ею она не является.

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

Два ключевых документа, формализующих объем, - это SOW (Statement of Work) и ROE (Rules of Engagement). Разница между ними принципиальна и нередко игнорируется:

• SOW определяет, что тестируется. Содержит перечень систем, приложений, сред и исключений.

• ROE определяет, как должен проводиться тест. Регулирует разрешенные техники, часы тестирования, правила эскалации и условия остановки.

Разделение этих документов имеет практическое значение. SOW подписывает юрист или руководитель проекта со стороны клиента. ROE подписывает лицо, технически ответственное, например, CTO или менеджер по безопасности. Подпись под неправильным документом неправомочным лицом не дает требуемой авторизации.

Совет профессионала: Всегда проверяйте, действительно ли лицо, подписывающее ROE, уполномочено давать согласие на проведение тестов. Подпись сотрудника IT без соответствующих полномочий не защитит вас юридически в случае инцидента.

Шаги для правильного определения объема:

1. Определите системы, охваченные тестом, и составьте список исключений

2. Согласуйте разрешенные методы и техники, зафиксируйте запреты

3. Установите временное окно и запланируйте blackout-периоды

4. Определите условия остановки теста и процедуры эскалации

5. Утвердите документацию подписями уполномоченных лиц с обеих сторон

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

Практические рекомендации и примеры определения объема в пентестах веб-приложений и API

С учетом общих принципов и рисков перейдем к практическим аспектам определения объема в тестировании веб-приложений. Этот вид тестирования имеет свою специфику, требующую очень точного подхода к скоупингу.

Объем теста веб-приложений/API определяется на уровне URL-адресов, эндпоинтов и ролей доступа. Необходимо точное определение границ тестирования аутентификации.

На практике объем теста веб-приложения должен включать:

• Список URL и эндпоинтов API: указания домена недостаточно. Необходимо уточнить, тестируются ли все субдомены, конкретные пути, версионированные API (v1, v2) и среды (production vs staging).

• Роли доступа для охвата: анонимный пользователь, зарегистрированный пользователь, модератор, администратор. Каждая роль открывает отдельный набор функциональности и потенциальных уязвимостей.

• Объем тестовых данных: какие тестовые учетные записи предоставляет клиент, какие данные можно создавать и изменять в ходе теста.

• Ограничения среды: могут ли тесты затрагивать производственные базы данных или тестировщик работает исключительно в staging-среде.

• Специфические угрозы для исследования: клиент может приоритизировать OWASP Top 10, бизнес-логику или авторизацию между учетными записями.

Недостаточная конкретизация ролей доступа - одна из наиболее распространенных ошибок. Тестировщик работает исключительно как анонимный пользователь, тогда как наиболее серьезные уязвимости находятся в панели администратора. Итоговый отчет не охватывает области, наиболее важные для клиента, и заказ признается неудачным. В разговорах с пентестерами, покупающими у нас оборудование, этот сценарий повторяется регулярно - клиент ожидал теста "панели" администратора, но никто этого не зафиксировал в scope.

Совет профессионала: Включите в scope все ключевые пути аутентификации и авторизации, в том числе процессы сброса пароля, OAuth, SSO и API keys. Именно эти пути чаще всего остаются упущенным вектором атаки.

Больше технических аспектов скоупинга веб-тестов найдете в руководстве по объему пентеста веб-приложений и API.

Затраты и ресурсы в зависимости от объема пентест-заказа

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

Чем больше и сложнее объем, тем выше стоимость и больше времени требуется на выполнение теста. Это кажется очевидным, но детали менее интуитивны, чем кажется.

Несколько факторов, которые менее очевидно влияют на ресурсы и затраты:

• Исключения из объема: парадоксально, многочисленные исключения могут удлинять тест, поскольку тестировщик вынужден постоянно проверять, какие системы он вправе атаковать, а какие нет.

• Доступность сред: тестирование в staging вместо production требует дополнительной настройки и нередко отдельных тестовых данных.

• Отчетность: подробный отчет с повторными тестами и сессиями разбора результатов может добавить от 20 до 30 процентов к общему времени выполнения заказа.

• Доступ к специализированным инструментам: некоторые векторы тестирования требуют специального оборудования, что влияет на затраты со стороны компании-тестировщика.

Больше о планировании времени и ресурсов пентеста найдете в наших материалах для специалистов.

Почему точное определение объема - главная сложность и ключ к успеху пентеста

Рассмотрев все практические аспекты, время на экспертный взгляд. Объем заказа - тема, в которой рынок совершает одни и те же ошибки годами, и никто об этом не говорит вслух.

Наиболее распространенная причина расхождения теста с ожиданиями клиента - ошибочный скоупинг и плохо определенный ROE. Но проблема обычно не в технической небрежности - она в процессе коммуникации.

Клиенты описывают объем в бизнес-языке. Они говорят "протестируйте наши системы" или "проверьте, насколько мы защищены". Пентестеры должны перевести это в список хостов, эндпоинтов и разрешенных техник. Именно в этом переводе чаще всего теряется информация. Мы наблюдаем это в отрасли годами - пентестеры, заказывающие у нас оборудование для физических тестов, нередко лишь после начала заказа узнают, что клиент не включил в scope физический доступ к серверной, хотя ожидал "полного теста безопасности".

Второй часто упускаемый аспект - условия остановки теста (stop conditions). ROE должен точно указывать, что тестировщик делает при обнаружении критической уязвимости, например, удаленной эксплуатации без аутентификации на производственной системе. Продолжает ли он работу или немедленно уведомляет клиента и ожидает решения? Отсутствие этих правил приводит к ситуации, когда тестировщик либо останавливается слишком рано, либо эксплуатирует уязвимость способом, который клиент расценивает как превышение границ.

Следующая ошибка - отсутствие бизнес-стейкхолдеров в процессе определения объема. Технические специалисты, как правило, сосредоточены на инфраструктуре. Тогда как именно риск-менеджер или операционный директор знает, какие бизнес-процессы критичны и требуют приоритизации. Объем, определенный исключительно IT-отделом, может упустить приложение, обслуживающее 80 процентов выручки компании, потому что "это старая система и все её знают".

Совет профессионала: Привлекайте бизнес-стейкхолдеров к сессии скоупинга. Одна встреча с лицом, ответственным за бизнес-процессы, может выявить активы, о которых IT-отдел не упомянул, поскольку не считал их "IT".

Эффективная стандартизация scope и ROE требует шаблонов, процессов и организационной дисциплины. Компании, которые воспринимают скоупинг как разовый телефонный разговор, регулярно поставляют тесты, которые клиент оценивает как бесполезные.

Инструменты и оборудование для пентеста, поддерживающие выполнение объема заказа

Зная вызовы и лучшие практики, стоит познакомиться с инструментами, которые помогают пентестерам реализовывать точный объем заказа. Правильное оборудование позволяет работать быстрее, точнее и в полном соответствии с согласованным scope.

В ассортименте Sapsan вы найдете оборудование, предназначенное для конкретных тестовых векторов, охваченных объемом заказа. Bash Bunny Hak5 - универсальное устройство для автоматизации HID-атак и сетевых тестов, особенно полезное в заказах, охватывающих физический доступ или конечные точки. Packet Squirrel Mark II эффективен во внутренних тестах и пивотинге в сети клиента, когда scope охватывает LAN-инфраструктуру. Для заказов, сосредоточенных на веб-приложениях и API, доступны инструменты для пентеста веб-приложений, покрывающие полный объем тестов согласно OWASP. Sapsan осуществляет доставку по всей территории ЕС и США, обеспечивая быстрый доступ к оборудованию независимо от местонахождения проекта.

Часто задаваемые вопросы

Что такое объем пентест-заказа?

Объем заказа - это формальная фиксация границ теста, разрешенных техник и сроков выполнения. Он определяет, какие системы подлежат тестированию, какие методы атаки разрешены и в каком временном окне может проводиться тестирование.

Почему точное определение объема так важно?

Неточный объем ведет к расхождению ожиданий и правовым рискам. Точное определение границ теста предотвращает правовые инциденты и гарантирует, что итоговый отчет отвечает реальным потребностям клиента.

Какие модели тестирования влияют на объем пентеста?

Модели black/grey/white box определяют уровень доступа тестировщика и влияют на объем тестирования. Black box имитирует атакующего без знания инфраструктуры, grey box предполагает частичный доступ, а white box обеспечивает полный доступ к архитектуре и коду.

Что должно включать определение объема тестирования веб-приложений?

Объем теста web/API определяется на уровне эндпоинтов и ролей доступа. Точный scope включает конкретные URL-адреса, версии API, тестовые среды и все роли пользователей - от анонимного до администратора.

Как размер объема влияет на стоимость и сроки тестирования на проникновение?

Объем напрямую влияет на время и стоимость: внешние тесты обычно занимают от 3 до 7 дней, а масштабные заказы red team могут занять несколько недель. Чем больше систем, ролей и техник охватывает scope, тем выше потребность в ресурсах и бюджете.