Этический хакинг: проверенные методологии и практики
Профессиональный пентест — не импровизированная серия сканирований и попыток эксплуатации. Он начинается с письменного разрешения и согласованного объёма работ, продолжается систематическим сбором доказательств и заканчивается отчётом, пригодным для принятия решений. Методология помогает обеспечить охват и повторяемость, но не заменяет опыт тестировщика и не гарантирует обнаружение каждой уязвимости. В статье разобраны NIST SP 800-115, OWASP WSTG, PTES и OSSTMM, модели black box, white box и grey box, а также практические правила безопасного проведения авторизованного теста.
Содержание
Ключевые выводы
| Пункт | Подробности |
|---|---|
| Роль методологии | Системный подход улучшает охват, воспроизводимость и качество доказательств, но не даёт гарантии полного обнаружения уязвимостей. |
| NIST SP 800-115 и OWASP WSTG | Это источники с разной областью применения: NIST описывает техническое тестирование и оценку, а WSTG подробно структурирует проверки веб-приложений и API. |
| Модели black box, white box и grey box | Модель определяет объём исходной информации, а не наличие разрешения: письменная авторизация и правила взаимодействия нужны в каждом случае. |
| Метрики и сопоставимость | Метрики полезны только при корректно определённой области и методе расчёта; показатель rav из OSSTMM описывает поверхность атаки, а не бизнес-риск. |
Почему методология этического хакинга необходима?
Методология превращает цели проекта в проверяемый план: какие активы и сценарии входят в объём, какие действия разрешены, какие доказательства собирать и как сообщать о критическом событии. Без такого плана легко многократно проверить видимые сервисы и одновременно пропустить целую подсеть, роль пользователя или важный бизнес-процесс.
Структура повышает повторяемость, однако не устраняет профессиональное суждение. В обзоре методологий пентеста приведена распространённая схема NIST SP 800-115: Planning, Discovery, Attack и Reporting. В самом руководстве эти четыре фазы относятся к сценарию теста на проникновение; их содержание адаптируют к цели, риску и ограничениям конкретного проекта.
До начала работ требуется письменная авторизация стороны, имеющей право разрешить тест. Необходимо отдельно учесть облачную инфраструктуру, подрядчиков и другие активы третьих сторон: согласие заказчика не всегда распространяется на них. Объём, сроки, допустимые методы, обработка данных и условия остановки должны быть зафиксированы так, чтобы каждое действие можно было сопоставить с выданным разрешением.
Практическая методология помогает:
системно покрывать согласованные активы, роли и сценарии;
повторять проверки и корректно сравнивать результаты при неизменной области;
собирать воспроизводимые доказательства и готовить понятный отчёт;
управлять техническим, операционным и правовым риском теста;
координировать работу команды и безопасно эскалировать инциденты.
Квалификация пентестера проявляется не только в эксплуатации. Специалист должен понимать, когда остановить действие, как уменьшить влияние на рабочую среду, какие данные действительно нужны в качестве доказательства и кому немедленно сообщить о критическом результате.
Особого согласования требуют социотехнические сценарии. Они затрагивают людей, персональные данные и внутренние процессы, поэтому должны быть явно включены в объём работ с безопасной инфраструктурой, правилами конфиденциальности, допустимыми целевыми группами и порядком уведомления HR, юридической службы и команды реагирования.
Практический совет: до старта утвердите Rules of Engagement (RoE). Укажите активы, домены, IP-адреса, тестовые учётные записи, разрешённые и запрещённые методы, часовой пояс и временные окна, исходные адреса тестировщиков, правила хранения данных, условия немедленной остановки, контакты для эскалации и ограничения поставщиков.
Этапы пентеста по NIST SP 800-115
NIST SP 800-115, Technical Guide to Information Security Testing and Assessment, опубликован в сентябре 2008 года. Это практическое руководство по планированию и проведению технических проверок, анализу результатов и разработке мер снижения риска, а не современный универсальный стандарт для любой программы безопасности. Несмотря на возраст, документ остаётся полезным источником, если учитывать текущие технологии и требования конкретной среды.
В приложении NIST SP 800-115 сценарий теста на проникновение представлен четырьмя фазами: Planning, Discovery, Attack и Reporting. Ниже — практическая интерпретация этой структуры.
Планирование (Planning) — определение цели, активов и исключений, разрешённых методов, модели тестирования, временных окон, критериев остановки, каналов связи, состава команды и правил обращения с данными. Письменная авторизация и RoE должны быть утверждены до технических действий.
Обнаружение (Discovery) — сбор и проверка информации в пределах согласованной области. Он может включать разрешённый анализ открытых источников, инвентаризацию целей, определение сервисов и версий, активное сканирование и анализ уязвимостей. Инструменты выбирают по задаче; например, Nmap помогает исследовать сетевые сервисы, а сканер уязвимостей формирует гипотезы, которые требуют ручной проверки.
Атака (Attack) — контролируемая проверка, можно ли использовать обнаруженную слабость и какой технический эффект реально достижим. Действия выполняют только в разрешённых пределах, с минимальным влиянием и минимально необходимым доказательством. Повышение привилегий, перемещение между системами и доступ к данным допустимы лишь тогда, когда они прямо предусмотрены RoE.
Отчётность (Reporting) — фиксация области, ограничений, методики, доказательств, подтверждённого влияния и рекомендаций. Техническая часть должна позволять воспроизвести результат, а резюме для руководства — объяснять приоритеты и бизнес-контекст без преувеличения. Критические находки сообщают сразу по согласованному каналу, не дожидаясь финального отчёта.
| Этап | Основная цель | Типичные инструменты |
|---|---|---|
| Планирование | Авторизация, область, ограничения и порядок взаимодействия | RoE, реестр активов, каналы связи и план обработки данных |
| Обнаружение | Инвентаризация поверхности атаки и проверка гипотез | OSINT, Nmap, анализ конфигурации и сканеры уязвимостей |
| Атака | Контролируемое подтверждение эксплуатабельности и влияния | Ручные проверки и инструменты, разрешённые для конкретной среды |
| Отчётность | Воспроизводимые доказательства, приоритеты и рекомендации | Система учёта находок, защищённое хранилище и согласованный формат отчёта |
Качество последующих фаз зависит от полноты Discovery. Пропущенный диапазон адресов, неучтённый домен, API или роль пользователя не попадут в проверку эксплуатации. Полноту цели сверяют с утверждённым перечнем активов, а расхождения документируют как ограничение проекта.
Практический совет: сочетайте пассивные и активные методы только в разрешённом объёме. Публичные репозитории можно анализировать, если это предусмотрено RoE; обнаруженные секреты нельзя использовать или сохранять сверх необходимого доказательства. Активное сканирование проводите лишь по согласованным целям и окнам. При фаззинге приложений знание архитектуры помогает выбрать интерфейсы и свойства входных данных, но тест также требует ограничений нагрузки и наблюдения за состоянием среды.
Тестирование веб-приложений по OWASP WSTG
Для веб-приложений и API общую организацию пентеста полезно дополнить OWASP Web Security Testing Guide (WSTG). Это подробное открытое руководство по тестированию, а не гарантирующий полноту чек-лист. На момент подготовки статьи стабильной является версия 4.2, а версия 5.0 разрабатывается; в отчётах лучше указывать версию WSTG и идентификаторы выполненных тестов.
В обзоре OWASP WSTG версии 4.2 выделено 12 активных категорий: Information Gathering, Configuration and Deployment Management Testing, Identity Management Testing, Authentication Testing, Authorization Testing, Session Management Testing, Input Validation Testing, Error Handling, Cryptography, Business Logic Testing, Client-side Testing и API Testing. Набор конкретных проверок нужно адаптировать к архитектуре, функциям и модели угроз приложения.
WSTG объясняет цели тестов, возможные подходы и ожидаемые доказательства. При этом тестировщик должен самостоятельно определить применимость сценария, безопасную технику проверки и влияние результата. Автоматический сканер не заменяет анализа авторизации, бизнес-логики и границ доверия.
Примеры областей, которые структурирует OWASP WSTG:
Information Gathering — определение поверхности приложения, доступных интерфейсов, технологий и потенциальных точек входа
Configuration and Deployment Management Testing — проверка развёртывания, административных интерфейсов, HTTP-заголовков, TLS и раскрытия служебных данных
Authentication Testing — проверка регистрации, восстановления доступа, MFA, блокировки и других механизмов подтверждения личности
Session Management Testing — анализ создания, хранения, обновления и завершения сессий, атрибутов cookie, CSRF и фиксации сессии
Authorization Testing — проверка разграничения прав, прямого доступа к объектам и переходов между ролями
Input Validation Testing — проверка SQL-инъекций, XSS, командных инъекций, обхода путей, XXE и других способов обработки недоверенных данных
Business Logic Testing — проверка последовательности операций, лимитов, цен, состояний, параллельных запросов и правил конкретного процесса
Client-side Testing — анализ DOM, JavaScript, перенаправлений, обмена сообщениями, браузерного хранилища и соединений WebSocket
| Категория OWASP | Инструменты | Типичные уязвимости |
|---|---|---|
| Сбор информации | Прокси, инструменты разработчика, инвентаризация маршрутов и технологий | Неучтённые интерфейсы, раскрытие версий и служебных данных |
| Тестирование аутентификации | Прокси-перехватчик, тестовые учётные записи и ручные сценарии | Ошибки восстановления доступа, MFA, блокировки и управления учётной записью |
| Проверка входных данных | Прокси-перехватчик, ручные запросы и разрешённые специализированные инструменты | Инъекции, XSS, обход путей и небезопасная обработка данных |
| Управление сессиями | Прокси-перехватчик, браузерные инструменты и анализ cookie | Фиксация сессии, CSRF, слабое завершение и повторное использование токенов |
| Бизнес-логика | Ручные сценарии, автоматизация повторов и проверка параллельных запросов | Обход последовательности, ошибки лимитов, цен, состояний и условий гонки |
Доказательства лучше собирать во время проверки: исходный запрос и ответ, время, роль пользователя, состояние среды, минимальный результат и шаги воспроизведения. Скриншот может дополнять материал, но сам по себе часто не подтверждает причину. Данные в отчёте следует обезличить или сократить в соответствии с RoE.
Практический совет: бизнес-логика требует контекстного ручного анализа, но автоматизация помогает повторять последовательности, перебирать сочетания параметров и проверять параллельные запросы. Исследуйте состояния процесса, права, лимиты, цены, купоны и реакцию на повторные или одновременные операции; не предполагайте, что сканер понимает бизнес-правила системы.
Модели тестирования: black box, white box и grey box
Модель определяет, какую исходную информацию и доступ получает тестировщик. Она влияет на глубину, скорость и тип покрываемых сценариев, но сама по себе не гарантирует реалистичность или полноту. Решение принимают по цели проекта, риску, времени и доступности доказательств.
Black box, white box и grey box — распространённые модели пентеста. Во всех трёх случаях требуются письменная авторизация, согласованная область и RoE; различается только предоставленный тестировщику контекст.
| Модель | Уровень знаний | Преимущества | Недостатки |
|---|---|---|---|
| Black box (внешнее знание) | Минимум исходной информации, согласованная точка входа | Показывает доступную тестировщику внешнюю поверхность и путь первоначального доступа | Ограниченное время может снизить глубину и оставить скрытые функции непроверенными |
| White box (полное знание) | Код, архитектура, конфигурации, документация и необходимые учётные записи | Позволяет глубже проверить логику и добиться широкого покрытия за ограниченное время | Не имитирует недостаток знаний внешнего атакующего; требует защиты переданных материалов |
| Grey box (частичное знание) | Ограниченный контекст, например тестовые роли или часть схемы сети | Сочетает проверку внешней поверхности с целевым анализом внутренних функций | Качество зависит от того, какой контекст и какие роли предоставлены |
Black box полезен, когда нужно изучить доступную извне поверхность и возможный путь начального доступа с минимальным контекстом. Результат отражает не весь потенциал реального противника, а то, что тестировщик успел проверить в согласованное время и с разрешёнными методами.
White box предоставляет код, архитектуру, конфигурации, документацию и нужные роли. Это позволяет целенаправленно проверять границы доверия и редкие ветви логики, а также сопоставлять поведение с реализацией. Переданные материалы требуют строгого контроля доступа и удаления по правилам проекта.
Grey box даёт ограниченный контекст, например обычную и привилегированную тестовую учётную запись или описание сегментации. Такая модель экономит время на достижение нужного состояния и помогает сравнить поведение разных ролей, сохраняя часть внешней перспективы.
При выборе модели учитывайте:
Цель и модель угроз: внешний путь первоначального доступа, проверка ролей, аудит кода и проверка конфигурации требуют разного контекста.
Время и требуемое покрытие: дополнительная информация часто позволяет глубже проверить систему, а не тратить большую часть окна на повторное обнаружение известных фактов.
Авторизацию и границы: любой сбор данных, сканирование и использование учётных записей должны соответствовать RoE, применимому праву и условиям поставщиков.
Среду и зависимости: рабочие и тестовые системы, облачные сервисы, регионы, третьи стороны, временные окна и допустимая нагрузка указываются отдельно.
Модели можно комбинировать в одном проекте, например начать с ограниченного black box, а затем перейти к grey box или white box для глубокой проверки. Частоту и последовательность определяют по риску и изменениям системы — универсального ежегодного графика не существует.
PTES, OSSTMM и корректное применение метрик
PTES и OSSTMM решают разные задачи. Документация PTES структурирует выполнение пентеста, а OSSTMM описывает собственную методику операционного тестирования и измерения поверхности атаки. Нельзя приписывать PTES метрику rav из OSSTMM или подменять этими подходами оценку бизнес-риска.
В OSSTMM 3.02 показатель rav (часто пишут RAV) описан как измерение поверхности атаки и объёма неконтролируемых взаимодействий с целью. Расчёт опирается на три категории в пределах одной области: Operational Security, Controls и Limitations. Пористость Operational Security включает Visibility, Access и Trust. Значение 100 означает установленный методикой баланс, но не 100%, не вероятность атаки и не шкалу бизнес-риска.
OSSTMM прямо указывает, что rav не измеряет риск. Показатель может помочь описать экспозицию и баланс контролей в строго заданной области, тогда как CVSS оценивает тяжесть конкретной уязвимости. Ни один из них сам по себе не выражает критичность бизнес-процесса, вероятность сценария или финансовое влияние. Эти выводы требуют отдельного контекста и анализа.
Для корректного использования rav важно понимать исходные категории:
Visibility (видимость) — элементы области, которые можно обнаружить в выбранном канале и векторе; это компонент пористости, а не просто число публичных субдоменов
Access (доступ) — точки взаимодействия с операциями в заданной области; этот компонент не равен сумме CVSS и не описывает сам по себе эксплуатабельность
Trust (доверие) — отношения доверия, через которые одна сторона или операция принимает взаимодействие другой; их учитывают вместе с Visibility и Access
Документация PTES делит процесс на семь разделов: Pre-engagement Interactions, Intelligence Gathering, Threat Modeling, Vulnerability Analysis, Exploitation, Post Exploitation и Reporting. Эта структура подробнее выделяет подготовку, моделирование угроз и действия после эксплуатации, но её следует адаптировать к RoE и не считать источником расчёта rav.
Практический совет: отделяйте доказанный технический эффект от предположений. Для SQL-инъекции укажите подтверждённые операции, затронутые данные или процессы, права использованной роли и минимальное доказательство. Возможные финансовые, договорные или регуляторные последствия описывайте как сценарии с явными допущениями; вывод о применимости и размере санкций GDPR должен делать компетентный юридический специалист.
Сравнивать rav во времени можно только при совместимых области, канале, векторе, индексе, версии методики и качестве исходных данных. Изменение этих условий создаёт другую точку измерения. Даже корректная динамика rav не доказывает эффективность инвестиций без анализа найденных ограничений, бизнес-контекста и других показателей.
Практический подход к методологии этического хакинга
Название методологии в отчёте не доказывает качество теста. Заказчику важнее видеть точную область, выполненные и исключённые сценарии, ограничения, доказательства ручной проверки и связь рекомендаций с подтверждённым влиянием. Вывод автоматического сканера без верификации — исходная гипотеза, а не готовый результат пентеста.
NIST SP 800-115, OWASP WSTG, PTES и OSSTMM дают разные структуры и понятия. Профессиональное суждение нужно, чтобы выбрать применимые тесты, безопасно выполнить их и интерпретировать результат, но оно дополняет метод, а не оправдывает работу без согласованного плана и документированных границ.
Обучение полезно начинать с целей и доказательств каждой фазы, а затем подбирать инструменты. Сканер портов, прокси или фреймворк эксплуатации ценен лишь тогда, когда тестировщик понимает, какую гипотезу проверяет, как ограничивает влияние и какой результат будет достаточным. Такой подход также уменьшает зависимость от конкретного продукта.
Пентест проверяет, можно ли реализовать согласованные сценарии атаки и какое влияние они дают. Более широкая оценка безопасности может включать архитектуру, конфигурацию, политики, процессы и дизайн контролей без эксплуатации. Клиенту иногда нужен не пентест, а обзор архитектуры, анализ конфигурации или оценка зрелости; формат следует выбирать по вопросу, на который должен ответить проект.
Аппаратное обеспечение требуется не для каждого теста. Веб-приложение часто можно полноценно проверять программными средствами, а аудит Wi-Fi, RFID/NFC, USB/HID или радиосвязи требует подходящего интерфейса, антенны либо тестового устройства. Оборудование выбирают с учётом области, частот, стандарта и ограничений RoE, а конфигурацию заранее проверяют в лабораторной среде.
Когда для тестирования требуется специальное оборудование
В магазине SAPSAN представлены устройства для авторизованных проверок беспроводных сетей, радиосвязи, технологий физического доступа и сценариев USB/HID. Выбирать конкретное устройство следует после определения вектора, стандарта и типа доказательства, необходимого в проекте.
В каталоге есть оборудование для тестирования Wi-Fi, средства RFID/NFC для лабораторной проверки контроля доступа, устройства SDR, аксессуары BadUSB и оснащение для Flipper Zero. Не каждый продукт подходит для любого аудита, поэтому перед покупкой проверьте поддерживаемые диапазоны, протоколы, режимы и совместимость с планируемой средой. Использование оборудования в проекте требует разрешения уполномоченной стороны и условий, зафиксированных в RoE.
Часто задаваемые вопросы
Нужно ли в каждом проекте использовать все фазы NIST SP 800-115?
Не с одинаковой глубиной. Объём технических действий адаптируют к цели и риску, но планирование, письменная авторизация, безопасный сбор доказательств и отчётность остаются обязательными. Пропущенные области и связанные с этим ограничения нужно явно указать в отчёте.
Можно ли сочетать OWASP WSTG и NIST SP 800-115?
Да. NIST SP 800-115 можно использовать как общую структуру технической оценки, а OWASP WSTG — как подробный набор направлений для веб-приложений и API. В стабильной WSTG 4.2 выделено 12 активных категорий; в отчёте следует указать версию и реально выполненные тесты.
Как выбрать между black box, white box и grey box?
Выбор зависит от цели, модели угроз, доступного времени и требуемого покрытия. Black box даёт минимум контекста, white box — полный доступ к материалам, grey box — выбранные роли и сведения. Письменная авторизация и RoE обязательны независимо от модели.
Что на практике показывает rav из OSSTMM?
rav описывает поверхность атаки и баланс Operational Security, Controls и Limitations в определённой области. Он не является показателем бизнес-риска и не заменяет CVSS или анализ влияния. Сравнение корректно только при совместимых области, векторе, методе и версии расчёта.