Пентест заканчивается не получением Domain Admin, не запуском сканера и не красивым скриншотом. Пентест заканчивается отчётом, по которому заказчик должен понять:
- что именно проверили;
- что удалось взломать;
- почему это стало возможным;
- к каким последствиям может привести атака;
- что и в каком порядке необходимо исправлять.
Можно качественно провести техническую часть и полностью испортить результат плохим отчётом. Например, оставить в документе комментарии вроде «добавить скрин», не указать охват инфраструктуры, смешать все площадки в один список и приложить скриншоты без дат и контекста.
Именно такие проблемы превращают результат пентеста в недоказуемый набор утверждений.
В первую очередь — соответствие техническому заданию
Отчёт как минимум должен подтверждать выполнение ТЗ.
Если в задании указано внешнее тестирование, анализ филиалов, веб-приложений, серверов и рабочих станций, по каждому направлению должен быть отдельный результат.
Недостаточно написать: «Инфраструктура была протестирована».
Нормальный вариант — составить матрицу выполнения требований ТЗ. Для каждого требования необходимо указать:
- само требование ТЗ;
- объекты, которые должны были проверяться;
- выполненные тесты;
- полученный результат;
- подтверждающие материалы;
- выявленные ограничения;
- причину невыполнения, если требование выполнено не полностью.
Если какое-то требование не выполнено, это также должно быть прямо указано: не было доступа, объект оказался недоступен, тест запретил заказчик или не хватило времени.
Фраза «невозможно гарантировать обнаружение всех уязвимостей» не объясняет, что именно осталось непроверенным.
Охват должен быть указан в цифрах
Из отчёта должно быть видно:
- сколько адресов и подсетей входило в scope;
- сколько узлов обнаружено;
- сколько узлов было доступно;
- сколько узлов просканировано;
- сколько объектов проверено вручную;
- какие объекты исключены;
- какие объекты были недоступны.
Утверждение «получен доступ к большинству серверов» ничего не значит без количества серверов и их перечня.
Нужно указать, например, что в область тестирования вошло 120 серверов, 108 из них были доступны, 105 просканированы, а 34 дополнительно проверены вручную.
Результаты также необходимо разделять по площадкам, филиалам, информационным системам и типам оборудования. Иначе невозможно понять, где ситуация критическая, а где защита действительно работает.
Должна быть понятна модель тестирования
Нужно прямо указать, как проводились работы:
- black box, grey box или white box;
- внешний или внутренний нарушитель;
- какие учётные записи и доступы были предоставлены;
- были ли включены средства защиты;
- из какого сегмента начиналась атака;
- какие действия были разрешены;
- какие действия были запрещены.
Внешний злоумышленник без доступа к сети и сотрудник, подключившийся к пользовательскому сегменту, — это две разные модели с разными начальными возможностями.
Отдельно желательно указать критерии успешности каждого сценария. Например:
- получение доступа во внутреннюю сеть;
- компрометация пользовательской учётной записи;
- повышение привилегий;
- доступ к критичной информационной системе;
- компрометация домена;
- получение доступа к конфиденциальным данным.
Ссылки на PTES, NIST SP 800-115, OSSTMM или OWASP сами по себе ничего не доказывают. Важно показать, какие конкретно проверки были выполнены в рамках выбранной методологии.
Для веб-приложений удобно прикладывать отдельный перечень проверок OWASP WSTG. Для каждой проверки нужно указать один из результатов:
- выполнено;
- уязвимость обнаружена;
- уязвимость не обнаружена;
- проверка неприменима;
- проверка не выполнена;
- причина невыполнения.
Нужны доказательства и хронология
Скриншот терминала без даты, адреса узла и выполненной команды является слабым доказательством.
По основным действиям желательно фиксировать:
- дату и время;
- часовой пояс;
- исходный адрес тестировщика;
- целевой объект;
- выполненное действие;
- использованный инструмент;
- версию инструмента;
- полученный результат;
- факт уведомления заказчика при выполнении критических действий.
Особенно важно фиксировать время эксплуатации критических уязвимостей, создания учётных записей, изменения паролей, загрузки файлов, получения привилегий и доступа к информационным системам.
В основной отчёт не обязательно вставлять несколько тысяч страниц технических логов. Их можно передать отдельным комплектом:
- журналы команд;
- результаты сканирования;
- HTTP-запросы и ответы;
- выгрузки используемых инструментов;
- результаты ручной проверки;
- контрольные суммы файлов с доказательствами.
При этом пароли, персональные данные и другая чувствительная информация должны быть скрыты. Сам отчёт и приложения необходимо передавать по защищённому каналу.
Каждая уязвимость должна быть воспроизводимой
Карточка недостатка должна содержать не только название и оценку CVSS.
Минимально необходимо указать:
- конкретный уязвимый объект;
- IP-адрес, hostname или FQDN;
- информационную систему;
- площадку или филиал;
- уязвимый компонент;
- версию компонента;
- дату обнаружения;
- необходимые условия эксплуатации;
- последовательность воспроизведения;
- подтверждающие материалы;
- вероятность эксплуатации;
- технические последствия;
- последствия для деятельности организации;
- рекомендации по устранению;
- критерий закрытия недостатка.
Описание должно позволять другому специалисту понять проблему и воспроизвести её в контролируемых условиях.
Формулировка «на сервере обнаружено устаревшее программное обеспечение» недостаточна. Необходимо указать сервер, программный продукт, версию, найденную уязвимость, способ проверки и возможные последствия.
CVSS недостаточно
CVSS — полезный инструмент, но он не учитывает весь контекст конкретной организации.
Одинаковая уязвимость на тестовом сервере и на контроллере домена не должна автоматически иметь одинаковый итоговый приоритет.
В отчёте необходимо описать собственную шкалу риска и объяснить, как техническая оценка корректируется с учётом:
- критичности актива;
- доступности из Интернета;
- доступности из пользовательского сегмента;
- наличия эксплойта;
- сложности эксплуатации;
- требуемых привилегий;
- наличия компенсирующих мер;
- возможности дальнейшего развития атаки;
- влияния на работу организации.
Нельзя обозначать CVSS 9,1 как высокий риск, а CVSS 7,5 — как критический, не объяснив причину изменения итоговой оценки.
Отдельные уязвимости нужно собирать в цепочки атак
Главная ценность пентеста — не перечень открытых портов и устаревших версий, а демонстрация реального сценария атаки.
Например:
Доступ к пользовательскому сегменту → получение пароля сервисной учётной записи → компрометация сервера → повышение привилегий → перемещение по сети → получение административного доступа к домену.
В отчёте необходимо показать:
- первоначальную точку входа;
- первичные уязвимости;
- промежуточные узлы;
- полученные учётные данные;
- способы повышения привилегий;
- перемещение между системами;
- пересечение сетевых сегментов;
- конечные системы и данные, к которым получен доступ;
- достигнутые цели тестирования.
Желательно представить основные цепочки атак в виде схемы и дополнить их хронологией.
Также необходимо указать роль каждой уязвимости в цепочке:
- первоначальный доступ;
- закрепление;
- получение учётных данных;
- повышение привилегий;
- перемещение по сети;
- достижение конечной цели.
Полезны и неуспешные сценарии. Они показывают, какие средства защиты действительно остановили тестировщика.
Необходимо показать инвентаризацию
В ходе пентеста обычно обнаруживается большое количество информации об инфраструктуре. Эти данные не должны оставаться только внутри результатов сканеров.
Полезно приложить реестр обследованных активов, в котором указаны:
- IP-адрес;
- hostname или FQDN;
- MAC-адрес, если он был доступен;
- тип устройства;
- модель оборудования;
- операционная система;
- версия прошивки;
- открытые сетевые сервисы;
- версии программного обеспечения;
- принадлежность к информационной системе;
- площадка или филиал;
- результат проверки.
Такая таблица одновременно подтверждает охват работ и помогает заказчику актуализировать собственную инвентаризацию.
Ограничения нужно описывать честно!
В отчёте должен быть отдельный раздел с ограничениями.
В нём необходимо указать:
- какие сегменты не проверялись;
- какие сервисы были исключены;
- какие узлы оказались недоступны;
- какие действия запретил заказчик;
- какие тесты были остановлены;
- где не хватило времени;
- где не были предоставлены необходимые доступы;
- какие средства защиты могли повлиять на результат;
- происходили ли сбои или нарушения работоспособности;
- как ограничения повлияли на итоговую оценку защищённости.
Если половина инфраструктуры была недоступна, нельзя делать общий вывод о защищённости всей организации.
Если тестирование проводилось при отключённых средствах защиты, это также должно быть явно указано.
В конце должен быть план устранения
Фраза «рекомендуется обновить программное обеспечение» почти бесполезна.
Рекомендации необходимо свести в единый план и разделить на несколько групп:
- немедленные меры;
- краткосрочные меры;
- среднесрочные меры;
- архитектурные изменения.
Для каждой меры следует указать:
- приоритет;
- затронутые объекты;
- рекомендуемый срок;
- ответственного;
- необходимые зависимости;
- временные компенсирующие меры;
- критерий закрытия;
- необходимость повторной проверки.
Например, сначала нужно заблокировать скомпрометированную учётную запись и сменить пароли. Затем ограничить сетевой доступ, обновить уязвимое программное обеспечение и исправить настройки. После этого уже можно заниматься архитектурными изменениями и переработкой сетевой сегментации.
Такой подход превращает отчёт из архива найденных проблем в рабочий план повышения защищённости.
Должно быть понятно, кто выполнял работы!
В отчёте необходимо указать состав команды:
- ФИО специалистов;
- роли в проекте;
- должности;
- руководителя работ;
- автора отчёта;
- специалиста, проводившего техническую проверку;
- лицо, утвердившее результат.
Если в ТЗ установлены требования к опыту или квалификации специалистов, заказчик должен иметь возможность проверить их выполнение.
Это особенно важно, когда отчёт содержит серьёзные выводы о компрометации критичных систем или всей доменной инфраструктуры.
Перед передачей заказчику документ должен пройти техническую и редакторскую проверку.
В нём не должно быть:
- незавершённых комментариев;
- фраз вроде «добавить скрин»;
- пустых шаблонных разделов;
- противоречащих друг другу оценок;
- перепутанных адресов и названий;
- орфографических ошибок;
- скриншотов без пояснений;
- рекомендаций, не относящихся к найденной проблеме;
- упоминаний объектов, не входивших в тестирование.
Также необходимо указать:
- версию документа;
- дату подготовки;
- историю изменений;
- уровень конфиденциальности;
- правила хранения и передачи отчёта.
Черновик с десятками скриншотов не становится профессиональным отчётом только после добавления титульного листа и логотипа исполнителя.
Хороший отчёт по пентесту должен быть понятен руководителю, воспроизводим техническим специалистом и пригоден для контроля устранения недостатков.
Из него должно быть понятно:
- что входило в область тестирования;
- какие проверки были выполнены;
- какие проверки не проводились;
- какие уязвимости обнаружены;
- как развивалась атака;
- какие системы были скомпрометированы;
- какие последствия возможны;
- что необходимо исправлять в первую очередь;
- как проверить устранение недостатков.
Если из документа нельзя установить, что проверялось, какой процент инфраструктуры был охвачен, как развивалась атака и что делать дальше, то это не полноценный отчёт по пентесту.
Это просто красиво оформленный набор скриншотов.
Добавить комментарий