В действительности ситуация имеет следующий вид: для каких-то отраслей установлены требования по проведению теста на проникновение в явном виде, для каких-то даётся только рекомендация по применению меры.

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

В первую очередь эта ситуация обусловлена тем, что такие рекомендации на данный момент описаны только коммерческими организациями, оказывающими услуги по проведению пентестов. Но эта детализированная техническая информация является проприетарной, то есть имеет высокую коммерческую ценность для этих компаний. Раскрыть её — всё равно что разгласить коммерческую тайну или собственное ноу-хау. Задача по формированию общей методологии под силу скорее государственным ведомствам и органам власти.

Второй момент связан с многообразием применяемого стека IT/OT, описать особенности которого в рамках одной методологии — задача не из лёгких. Можно представить, что в идеале это должна быть информационная система или веб-ресурс, в котором на лету конфигурируется методика для конкретного проекта в зависимости от архитектурной особенности и технологического стека.

Третий момент: не всегда при проведении пентеста возможно поэксплуатировать уязвимость, так как к ней может не быть опубликованного PoC (Proof of Concept), а также попытка эксплуатации имеет риск нарушения нормального функционирования объектов ИТ-инфраструктуры. Неслучайно в том же МЭК 63096 при тестировании на проникновение какого-либо технологического оборудования, влияющего на атомную безопасность, рекомендуют его проводить на стендовой инфраструктуре (макете), а на реальном оборудовании только во время проведения планово-предупредительных работ.

Четвёртое: любой тест на проникновение показывает результаты на текущий момент времени. В организации постоянно происходят изменения — добавление и/или обновление аппаратного и программного обеспечения. При этом сами банки данных угроз и уязвимостей, будь то БДУ ФСТЭК или NVD от NIST, постоянно обновляются новыми опубликованными уязвимостями, рекомендациями вендоров и сообщениями об опубликованных PoC. Все эти факторы заставляют нас проводить непрерывные пентесты (Continuous Penetration Testing) и периодические redteam.

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