Ques/Help/Req Идеальный пентест. Как довести заказчика до экстаза

[XakeR]

Пентест, то есть проверка инфраструктуры компании на возможность хакерского проникновения, — это распространенная услуга, которую предоставляют ИБ‑компании. Однако пентесты бывают очень разными. В этой статье я расскажу, как, на мой взгляд, должны и как не должны выглядеть результаты таких работ. Думаю, мои советы пригодятся и заказчикам, и исполнителям.

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

У нас была уязвимая библиотека с высоким CVSS, и при этом она легко эксплуатировалась. PoC не было, но составить его не проблема — коллеги из Китая оставили очень хорошие описания к CVE, за недельку можно заиметь боевой образец. Но мы знали, что благодаря нашим усилиям эта уязвимость была неприменима.

Мы ждали отчет с кричащими тегами CRITICAL. Но увидели эту библиотеку с маркером LOW. Исполнители прекрасно понимали, как мы защитились, сами же описали причину, по которой эта уязвимость не может быть проэксплуатирована, и корректно отметили, что библиотека уязвима и ее нужно обновить, когда появится патч.

После такого понимаешь:

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

Программа минимум​

Итак, что же нужно делать, чтобы заказчики были счастливы и писали приятные отзывы?

1. Самый важный аспект — вникать в логику работы. Не просто сканировать инфраструктуру, валидировать баги руками, что‑то тыкать и фаззить, но еще и понять, как работает сервис, посмотреть потоки данных и взаимодействие с остальными микросервисами и интеграциями.
2. Покрывать все сервисы автоматизированными средствами.
3. Валидировать все уязвимости. Не просто отдавать репорты сканера, обернутые в логотипы твоей компании, а обязательно проверять, что каждая найденная уязвимость реальна.
4. Корректировать уровень опасности уязвимостей согласно критичности сервиса и возможности эксплуатации. Даже если сканеры пишут, что уязвимость критична, нужно учитывать обстоятельства: можно ли ее проэксплуатировать, есть ли реальные уязвимости с PoC, критичный ли сервис и так далее.
5. Весь чек‑лист пройден в ручном режиме. 90% работы над проектом должно занимать ручное тестирование, ресерч, попытки эксплуатации именно в ручном режиме.

Как писать отчет​

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

1. 
   Единый стиль изложения, отсутствие грамматических и стилистических ляпов, описание рисунков, схем, таблиц. Чтобы всем было приятно смотреть на отчет и содержание было предельно ясным.
   
   
2. 
   Детальное описание недостатков. Не просто общее описание, а для конкретных случаев: где нашли уязвимость, в каком параметре или модуле.
   
   
3. 
   Примеры эксплуатации. Показаны найденные баги, прикреплена картинка как пруф. Читающий может повторить действие с картинки. Также не помешает детальное описание процесса тестирования, ссылки на базы уязвимостей ФСТЭК России или техник MITRE.
   
   
4. 
   Рекомендации также прописаны для конкретных случаев, описаны точечные советы, именно для того фреймворка и стека технологий, который использует заказчик. Нет двусмысленности. Есть разные варианты устранения.
   

Например, ты нашел уязвимость, которая позволяет перебирать пользователей. Система реагировала по‑разному в тех случаях, когда пользователь существует и когда его нет. Можно дать общую рекомендацию — внедрить CAPTCHA-тест. Но если знаешь, что у заказчика используется, например, Django, то можно дать рекомендации именно для этого фреймворка.

1. 
   Резюме работы с цифрами, рекомендациями и выводом.
   
   
2. 
   Отчет оформлен на основе вопросов, заданных заказчиком перед проектом. Затем идет то, что специалисты считают важным и релевантным. Если вопросов не было, то по иерархии критичности всех находок.
   
   
3. 
   Приведена аналитика: количество уязвимостей, хостов, которые были проверены, или топ уязвимостей в компании, или динамика по предыдущим пентестам и времени жизни уязвимостей, если есть такая возможность.
   
   
4. 
   Моделирование угроз поведения злоумышленника. Нужно показать, что случится, если злоумышленник проэксплуатирует уязвимость. Например, уязвимость с SMS-спамом, как правило, заказчики не понимают. Поэтому нужно показать, в чем ее риск, объяснить, что провайдер позволяет крупным компаниям отправлять до 3 тысяч SMS в секунду. На отправку 200 запросов компания тратит 400 рублей в секунду. Если атака длится час, то злоумышленник сожжет почти 1,5 миллиона рублей с баланса компании.
   

Что важно обсудить​

Присоединяйся к сообществу «Xakep.ru»!​

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее

-60%

1 year​

9990 рублей 4000 р.


[TD]

1 month_r​

920 р.
[/TD]

Я уже участник «Xakep.ru»