Этический хакинг: проверенные методологии и практики

Профессиональный пентест — не импровизированная серия сканирований и попыток эксплуатации. Он начинается с письменного разрешения и согласованного объёма работ, продолжается систематическим сбором доказательств и заканчивается отчётом, пригодным для принятия решений. Методология помогает обеспечить охват и повторяемость, но не заменяет опыт тестировщика и не гарантирует обнаружение каждой уязвимости. В статье разобраны NIST SP 800-115, OWASP WSTG, PTES и OSSTMM, модели black box, white box и grey box, а также практические правила безопасного проведения авторизованного теста.

Содержание

• Почему методология этического хакинга необходима?

• Ключевые этапы процесса по NIST SP 800-115

• Методология тестирования веб-приложений: OWASP Testing Guide

• Модели тестирования: black box, white box и grey box

• PTES, OSSTMM и корректное применение метрик

• Практический подход к методологии этического хакинга

• Когда для тестирования требуется специальное оборудование

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

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

Почему методология этического хакинга необходима?

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

Структура повышает повторяемость, однако не устраняет профессиональное суждение. В обзоре методологий пентеста приведена распространённая схема NIST SP 800-115: Planning, Discovery, Attack и Reporting. В самом руководстве эти четыре фазы относятся к сценарию теста на проникновение; их содержание адаптируют к цели, риску и ограничениям конкретного проекта.

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

Практическая методология помогает:

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

• повторять проверки и корректно сравнивать результаты при неизменной области;

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

• управлять техническим, операционным и правовым риском теста;

• координировать работу команды и безопасно эскалировать инциденты.

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

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

Практический совет: до старта утвердите Rules of Engagement (RoE). Укажите активы, домены, IP-адреса, тестовые учётные записи, разрешённые и запрещённые методы, часовой пояс и временные окна, исходные адреса тестировщиков, правила хранения данных, условия немедленной остановки, контакты для эскалации и ограничения поставщиков.

Ключевые этапы процесса по NIST SP 800-115

NIST SP 800-115 — широко используемое руководство по проверке информационной безопасности. Оно помогает связать задачи каждого этапа с проверяемыми результатами. National Institute of Standards and Technology опубликовал документ в 2008 году. Он находится в открытом доступе и остаётся справочным материалом для планирования тестов, несмотря на появление более специализированных методик.

В разделе 5.2.1 приведён пример процесса из четырёх фаз: Planning, Discovery, Attack и Reporting. Это один из допустимых вариантов организации пентеста. Ниже — содержание каждой фазы.

1. Planning (планирование) — подготовительная фаза. Определяются цель аудита, границы работ, модель тестирования и правовые условия. Оформляются договорённости и разрешения. Также определяются специалисты и оборудование, необходимые для проекта.

2. Discovery (исследование) — сбор информации и сканирование, за которыми следует анализ возможных уязвимостей. Изучаются поддомены, данные WHOIS, адреса электронной почты и серверные технологии; выявляются открытые порты, версии служб и операционных систем. Пассивные и активные методы дополняют друг друга. В современных проектах здесь применяют, например, Nmap, Shodan и Nessus.

3. Attack (атака) — проверка выявленных уязвимостей эксплуатацией. В пределах согласованного задания пентестер пытается получить доступ, недоступный обычному пользователю, повысить привилегии, проверить перемещение между системами и собрать доказательства. Действия документируются по мере выполнения. Эта фаза подтверждает реальный эффект находок Discovery.

4. Reporting (отчётность) — документирование сопровождает остальные три фазы, а после теста клиент получает итоговый отчёт. Он содержит методику, уязвимости с оценкой риска, доказательства эксплуатации и рекомендации. Технические результаты отделяются от резюме для руководства.

Discovery заслуживает особого внимания: пропуски на этом этапе влияют на весь аудит. Если при исследовании не заметить подсеть, она может не попасть в фазу Attack. Полнота разведки определяет качество итоговых результатов. Инструменты в таблице — современные примеры, а не список рекомендаций из документа 2008 года.

Совет специалиста: В фазе Discovery сочетайте активное сканирование с пассивными методами. Открытые репозитории, например GitHub, позволяют получить сведения об инфраструктуре без обращения к системам самой проверяемой организации. История коммитов помогает выявлять опубликованные ключи API и пароли. Эти подходы полезны и при фаззинге приложений: знание архитектуры помогает направить проверки на наиболее рискованные точки входа.

Методология тестирования веб-приложений: OWASP Testing Guide

Когда объект аудита — веб-приложение, общую методологию NIST SP 800-115 стоит дополнить специализированным руководством. Для этого используют OWASP Web Security Testing Guide (WSTG, ранее OWASP Testing Guide), широко принятый в этой области.

OWASP Testing Guide версии 4.2 содержит 11 основных категорий тестов: Information Gathering, Configuration and Deployment Management, Identity Management, Authentication, Authorization, Session Management, Input Validation, Error Handling, Cryptography, Business Logic и Client-Side Testing. В категориях описаны конкретные проверки, методы, инструменты и способы оценки результатов.

Практическая ценность OWASP Testing Guide в технической детализации: это не просто перечень угроз. Пентестер получает указания, что искать, как проводить проверку и как интерпретировать результат.

Ниже — несколько категорий OWASP Testing Guide:

• Information Gathering — сбор сведений о фреймворке, сервере, серверных технологиях и структуре URL

• Configuration Management — проверка настроек сервера, HTTPS, защитных заголовков и конфигурации TLS

• Authentication Testing — проверка парольной политики, блокировки попыток входа, многофакторной аутентификации и устойчивости к перебору паролей

• Session Management Testing — анализ токенов сессий, защиты cookies, фиксации сессии и CSRF

• Authorization Testing — проверка контроля доступа, повышения привилегий и небезопасных прямых ссылок на объекты

• Input Validation Testing — SQL Injection, XSS, Command Injection, Path Traversal, XML Injection

• Business Logic Testing — поиск ошибок бизнес-логики, которые трудно выявить автоматическим сканированием

• Client-Side Testing — анализ JavaScript, DOM-based XSS, HTML Injection и безопасности WebSocket

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

Совет специалиста: В Business Logic Testing опирайтесь на ручной анализ бизнес-процессов, дополняя его автоматизацией отдельных проверок. Сканер не заменяет понимания правил конкретного приложения. Пошагово проверяйте оформление покупок, применение купонов и ограничения учётных записей: здесь часто находятся ошибки, которые автоматический сканер пропускает.

Модели тестирования: black box, white box и grey box

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

Black box, white box и grey box — распространённые модели пентеста. Во всех трёх случаях требуются письменная авторизация, согласованная область и RoE; различается только предоставленный тестировщику контекст.

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. В каталоге можно собрать оснащение для конкретных этапов аудита: от анализа радиосигналов до демонстрации USB/HID-сценариев. Использование оборудования в проекте требует разрешения уполномоченной стороны и условий, зафиксированных в RoE.

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

Нужно ли в каждом проекте использовать все фазы NIST SP 800-115?

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

Можно ли сочетать OWASP WSTG и NIST SP 800-115?

Да. NIST SP 800-115 можно использовать как общую структуру технической оценки, а OWASP WSTG — как подробный набор направлений для веб-приложений и API. В стабильной WSTG 4.2 выделено 11 категорий тестирования веб-приложений; в отчёте следует указать версию и реально выполненные тесты.

Как выбрать между black box, white box и grey box?

Выбор зависит от цели, модели угроз, доступного времени и требуемого покрытия. Black box даёт минимум контекста, white box — полный доступ к материалам, grey box — выбранные роли и сведения. Письменная авторизация и RoE обязательны независимо от модели.

Что на практике показывает rav из OSSTMM?

rav описывает поверхность атаки и баланс Operational Security, Controls и Limitations в определённой области. Он не является показателем бизнес-риска и не заменяет CVSS или анализ влияния. Сравнение корректно только при совместимых области, векторе, методе и версии расчёта.