Что такое хороший отчет по пентесту и зачем он нужен

Геннадий Перминов
Ведущий консультант по ИБ RTM Group

Проведение тестирования на проникновение (пентеста) направлено на предотвращение утраты активов, связанной с кражей и утечкой данных в результате хакерских атак. Рынок пентеста на территории РФ, по различным оценкам, в 2022 году составил от 1,5 до 2,5 млрд рублей, и продолжает расти.

Анализ результатов пентестов, проведенный экспертами компании RTM Group в 2022 году, показал, что 83% протестированных компаний имели в своих информационных системах уязвимости среднего уровня, 69% - высокого и 46% - критического! При этом критический и высокий уровень опасности обычно означает, что уязвимость может быть проэксплуатирована злоумышленником низкой квалификации даже удаленно.

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

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

Заинтересованные стороны

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

Если проведение пентеста регламентировано нормативными документами, то отчет по его результатам также изучается и регулятором.

Например, в финансовом секторе тестирование на проникновение и анализ уязвимостей информационной безопасности объектов информационной инфраструктуры проводится на основе:

• Положения Банка России от 17.04.2019 N 683-П, устанавливающего ежегодное тестирование для кредитных организаций (п. 3.2);
• Положения Банка России от 04.06.2020 N 719-П, устанавливающего ежегодное тестирование для операторов по переводу денежных средств, банковских платежных агентов (субагентов), операторов услуг информационного обмена, операторов услуг платежной инфраструктуры (п. 1.1);
• Положения Банка России от 20.04.2021 N 757-П, устанавливающего ежегодное тестирование для некредитных финансовых организаций, реализующие усиленный и стандартный уровни защиты информации (п. 1.4.5);
• Положения Банка России от 8 апреля 2020 г. № 716-П, определяющего необходимость  ежегодного тестирования для кредитных организаций (п. 8.8);
• ГОСТ Р 57580 Безопасность финансовых (банковских) операций, устанавливающего для стандартного и усиленного уровней защиты информации однократное тестирование на этапе «Ввод в эксплуатацию АС» и ежегодное тестирование на этапе «Эксплуатация (сопровождение) АС».

Перед началом

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

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

Поэтому еще до проведения пентеста и даже до предоставления исходных данных, между Заказчиком и Исполнителем подписывается NDA (от англ. non‑disclosure agreement) — это соглашение о неразглашении, в соответствии с которым Исполнитель обязуется не разглашать информацию, полученную в рамках исполнения договора. При этом весь информационный обмен между Заказчиком и Исполнителем, содержащий такие чувствительные данные, осуществляется в защищенном виде. Например, посредством инструментов шифрования или защищенных облачных сервисов.

В отчете приводятся основания для проведения тестирования: обычно таким основанием является договор.

Помимо NDA и договора, у Заказчика может запрашиваться письменное подтверждение, что информационные ресурсы, предоставленные на тестирование, принадлежат ему. В некоторых случаях такое подтверждение необходимо, так как поиск уязвимостей вне рамок договора или в отношении третьих лиц напрямую подпадает под действие УК РФ.

Условия и границы

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

Например, если речь идет о выполнении требований регулятора, таких как Положения Банка России №№ 683-П, 719-П, 757-П, 716-П, о которых шла речь выше, то задача определения области исследования упрощается – исследованию подлежит вся внутренняя инфраструктура организации, а также все внешние IP-адреса, доступные из сети Интернет.

А при выполнении требований PCI DSS тест на проникновение охватывает периметр среды, в которой обрабатываются данные о держателях карт, то есть это может быть лишь часть информационной инфраструктуры Заказчика.

Тестирование на проникновение, в зависимости от потребностей Заказчика, может быть двух видов: анализ уязвимостей или тестирование с эксплуатацией.

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

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

Также в данном разделе могут быть описаны временные рамки, накладываемые ограничения, порядок взаимодействия с ИТ-департаментом или службой безопасности.

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

 Методология

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

• PTES (Penetration Testing Execution Standard - Стандарт выполнения тестирования на проникновение). Текущая версия PTES v1.0 (2017 год);
• OWASP WSTG (Web Security Testing Guide - Руководство по тестированию веб-безопасности). Текущая версия WSTG v4.2 (2020 год);
• OSSTMM (Open Source Security Testing Methodology Manual - Руководство по методологии тестирования безопасности с открытым исходным кодом). Текущая версия OSSTMM v3 (2010 год);
• NIST SP 800-115 (Technical Guide to Information Security Testing and Assessment - Техническое руководство по тестированию и оценке информационной безопасности). Принят в 2008 году;
• ISSAF (Information Systems Security Assessment Framework – Фреймворк оценки безопасности информационной системы). Текущая версия ISSAF 0.2.1 (2006 год);
• OWASP MASTG (Mobile Application Security Testing Guide (MASTG)) - руководство по тестированию безопасности мобильных приложений. Текущая версия MASTG v2.0.0 (2023 год);
• PETA: Methodology of Information Systems Security Penetration Testing. Опубликован в 2016 году.

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

Говоря об инструментарии Исполнителя, следует отметить, что не существует какого-то обязательного набора. Несмотря на то, что есть негласные «отраслевые стандарты» (nmap, burp suite, wireshark, hashcat или metasploit), одну и ту же задачу можно решить множеством различных инструментов, от коммерческих до бесплатных, от общеизвестных до самописных. Каждое из этих средств может иметь какие-то особенности реализации. Поэтому, во-первых, желательно, чтобы один и тот же результат подтверждался несколькими средствами хотя бы косвенно, а, во-вторых, в отчете должен быть раздел с перечнем использованных средств с указанием их версий.

Ход работ

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

Например, web-приложение может оказаться устойчивым к классическим SQL-инъекциям, но не устоять перед внедрением кода через сообщения об ошибках СУБД (Error-based SQLi).

Много уязвимостей не бывает

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

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

Описание выявленных слабостей и уязвимостей должно содержать: название, перечень уязвимых хостов, оценку уровня риска, описание (каким образом они могут быть проэксплуатированы и к каким последствиям это может привести), а также рекомендации по их устранению

Существуют ряд различных баз данных уязвимостей, содержащих их описание, пути возникновения, перечни уязвимого ПО, способы устранения и иную полезную информацию. Для идентификации обнаруженных проблем безопасности отчет должен содержать ссылки на подобные перечни. Наиболее известны из них - CVE (Common Vulnerabilities and Exposures) – общие уязвимости и воздействия, CWE (Common Weakness Enumeration) – общее перечисление слабостей, БДУ ФСТЭК России – Банк данных угроз безопасности информации, который ведет ФСТЭК России.

Помимо этого, для обнаруженных уязвимостей должна проводиться оценка их критичности.  Наиболее часто применяется стандарт CVSS (Common Vulnerability Scoring System), разработанный Национальным советом по инфраструктуре (National Infrastructure Advisory Council, NIAC) США.

Ключевой особенностью CVSS является использование помимо базовых и временных метрик, характерных для уязвимости в целом, еще и контекстных, которые учитывают особенности эксплуатации уязвимости в конкретной системе Заказчика.

Например, уязвимость CVE-2023-24800 позволяет удаленным злоумышленникам вызвать отказ в обслуживании (DoS) в маршрутизаторах D-Link. Базовая и временные метрики для данной уязвимости дают оценку CVSS - 9.8, что соответствует критическому уровню.

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

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

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

Выводы

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

Примером таких рекомендаций могут быть:

• проведение внутреннего аудита процессов патч-менеджмента на сетевых хостах, если выявленные недостатки связаны с использованием устаревших версий системного и прикладного программного обеспечения;
• внедрение дополнительных программных (или программно-аппаратных) средств защиты информации в границах сети, включая межсетевые экраны, средства обнаружения и предотвращения вторжений (IDPS), анализаторы трафика, SIEM-системы;
• создание рабочей группы, ответственной за мониторинг и оперативное реагирование на возникающие инциденты информационной безопасности с целью предотвращения распространения (эскалации) компьютерных атак;
• модернизация существующей парольной политики организации, с целью исключения использования словарных паролей, паролей меньше 10 символов, паролей без использования цифр и специальных символов в их составе.

Вместо заключения

Для предоставления услуг пентеста организация должна иметь лицензию ФСТЭК России на виды работ, предусмотренные подпунктом «б» пункта 4 постановления Правительства РФ от 3 февраля 2012 года № 79. В настоящее время на рынке присутствует большое количество компаний, заявляющих о предоставлении подобных услуг. Однако, их качество не всегда соответствует рекламе. Наличие в штате Исполнителя сотрудников с различными сертификатами в области тестирования на проникновение лишь частично решает проблему. В значительной степени при выборе Исполнителя играет роль его репутация. Однако, приведенные ниже рекомендации позволят оценить корректность и эффективность услуг пентеста со стороны внешнего Исполнителя.

Примером плохого или бессмысленного отчета может быть наличие следующих недостатков:

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

Другим нюансом является то, как Исполнитель относится к самому проекту и работам в целом. Это может выражаться в том, насколько у него продуман опросный лист; насколько быстро он его обрабатывает и дает необходимый фидбек на вопросы Заказчика; в наличии приветственного письма с указанием исполнителей и их контактов; в строгости соблюдения сроков договора; наличии или отсутствии контакта с Исполнителем в процессе выполнения работ и так далее.