На данный момент действительно отсутствует методика, по которой необходимо проводить пентест в соответствии с требованиями 187-ФЗ.

В статье рассмотрены различные международные стандарты, но хотелось бы обратить внимание на ещё один документ. У совета PCI SSC есть PCI DSS Pentest Guidance. Это хороший пример документа, который описывает «правила игры» и отвечает на следующие вопросы: «какой должен быть пентест?», «какие доступы и какую информацию необходимо предоставить пентестеру?», «что является целью пентеста?».

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

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

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

Методика также должна включать описание модели нарушителя, которую необходимо использовать при проведении пентеста. 

Если в область аудита входят приложения, то нужно договориться о минимальных привилегиях учётной записи, которая будет предоставлена пентестеру. Ведь если в область аудита входит приложение со сложной бизнес-логикой, а клиент просит протестировать его только «чёрным ящиком», толку от такой работы будет немного. 

Если речь идёт о внутреннем пентесте, то нужно указать, что необходимо предоставить пентестеру сетевой доступ во внутреннюю сеть, а также, например, учётную запись в Active Directory или на терминальном сервере с привилегиями обычного пользователя. 

Кроме того, методика должна содержать верхнеуровневое описание шагов, которые необходимо выполнить пентестеру. 

Например, необходимо провести сбор информации, выполнить сканирование на предмет открытых портов, определить сервисы, доступные на выявленных портах, и так далее. 

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

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

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

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

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

Ещё один важный момент, который стоит описать в методике, — структура отчёта. Необходимо описать основные разделы, например:

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

Авторы статьи указали и на проблемы, связанные с отсутствием инструментов полного цикла. Тут нужно отметить важный момент: сканирование уязвимостей и тестирование на проникновение очень сильно отличаются. Пентестеры редко используют коммерческие инструменты полного цикла. В основном они используют open-source-решения, инструменты, разработанные комьюнити и собственные разработки. Поэтому данная проблема переоценена. 

Что касается определения критичности выявленных уязвимостей, то данный момент тоже довольно сложно стандартизовать, так как критичность одной и той же уязвимости в разных информационных инфраструктурах может отличаться. Более того, она может быть разной в той же самой информационной инфраструктуре, но при проведении разных пентестов. Например, при проведении тестирования на проникновение в соответствии с требованиями PCI DSS самым критичным активом являются данные держателей карт. Соответственно, уязвимость, которая позволяет их получить, например XSS на платёжной странице, является критичной. В пентесте, не связанном с PCI DSS, критичность у такой уязвимости может быть ниже. 

В заключительной части статьи авторы говорят о том, что необходимо разработать собственный OWASP TOP 10. Я не могу с этим согласиться, так как считаю, что не нужно отгораживаться от международного опыта. OWASP TOP 10 не имеет какой-либо привязки к локации и включает в себя самые популярные уязвимости, встречаемые в мире в целом. Но и у OWASP TOP 10 есть недостаток, связанный с тем, что он не учитывает специфику индустрии. Было бы полезно разработать подобные списки для разных сфер: финансовая сфера, энергетика, здравоохранение и так далее, согласно перечню отраслей КИИ.