Итак, третий пост на тему идеального пентеста, настало время хейта! Каким НЕ ДОЛЖЕН быть пентест:
⠀
1. Есть целый класс так называемых «уязвимостей» вроде: «Support for SSL and/or Early TLS Protocols», «Secure Flag not set on Session Cookies» и прочее, что автоматически генерируют сканирующие движки. Если в отчете есть эти или подобные им уязвимости, то там также должны находится описания, которые поясняют:
— причину, по которым это было включено в отчет;
— описание того, как это вообще влияет на систему, в каких условиях и какая предполагается модель нарушителя.
⠀
Если этого нет, можно смело трактовать это, как формальную отписку. Исполнитель не потрудился примерить найденное к жизни и дать более глубокую оценку. Чаще всего просто «выплёвывают» в отчет простыню из автоматически сгенерированного текста.
⠀
2. Короткие формальные описания уязвимостей без пруфов и примеров эксплуатации бесполезны еще потому, что даже специалист не поймет сути баги, не сможет применить результат тестирования в своей работе. Что уж говорить про заказчика.
⠀
3. Отсутствие описанных рисков. Если заказчик не получает ответы на главные вопросы о том, что угрожает компании, смысл проекта теряется.
⠀
4. Нет подтверждения, что уязвимость существует, возможно исполнитель ее придумал. Качественный пентест предполагает максимально развернутую аргументацию на каждом этапе. Показаны найденные баги, прикреплена картинка, как пруф. Читающий может повторить действие с картинки.
⠀
5. Нет конкретных рекомендации. Например, понятно, что надо ограничить количество запросов, но как это сделать? Даже если заказчик не воспользуется рекомендациями, нужно показать пример, как это можно сделать в его случае.
⠀
❗️Мы собрали еще 10 таких критериев и назвали это — «Check up пентест-проектов». Если интересно посмотреть или самостоятельно продиагностировать себя и своих подрядчиков, ставьте «+» в комментарии и мы пришлем вам PDF.
⠀
#бенчмарк_пентеста