Сроки подготовки отчета по пентесту: сколько ждать и что должно быть в образце?

Смотрите в образце прежде всего раздел PoC (Proof of Concept). Настоящий пентестер обязан доказать, что смог вытащить данные или выполнить код, приложив скриншоты. Не тратьте время на конторы, которые не отсеивают ложные срабатывания (false positive) после автосканеров.

Обязательно внесите в договор такие пункты: 1) При обнаружении критических или высоких рисков уведомлять по e-mail в течение 24 часов, 2) Черновой отчет предоставлять максимум через 5 рабочих дней после тестов, 3) Бесплатный повторный тест (re-test) в течение 30 дней после закрытия уязвимостей.

Нам в прошлом месяце закончили тест приложения и API. В пятницу вечером завершили проверки, во вторник утром черновик уже был у нас. Нашли 4 критичные дыры, разработка закрыла их за 10 дней, а на следующий день подрядчик провел ретест и выдал чистый отчет. Ждать отчет 15 дней — значит полностью заблокировать процесс исправления.

Если фирма настаивает на 15 днях, требуйте пункт о ежедневных промежуточных отчетах по критическим багам. Отказываются — сразу в бан. Сидеть две недели с SQL-инъекцией или RCE и ждать отчета — это самоубийство для бизнеса.

Те, кто обещает отчет за 3 дня, часто просто жмут кнопку «Экспорт в PDF» в сканере и лепят ваш логотип на обложку. Оцените по образцу действительно ли отчет готовится вручную и содержит глубокий анализ под вашу систему.

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

Обратите внимание на сроки повторной проверки (re-test). На закрытие багов у вас уйдет время, поэтому важно, чтобы исполнитель зафиксировал в договоре право на бесплатную повторную проверку в течение 30–45 дней после сдачи отчета.

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

Абсолютно. Если добавить к этому: Больше всего времени у нас уходило на то, что было непонятно, кто принимает решения.

Решения, работающие в малом масштабе, рушатся при росте, я узнал это слишком поздно. Оставлю как заметку, пригодится.

Извините, но это верно не во всех случаях. Доступность резервной копии в той же сети и под той же учетной записью делает ее частью цели атаки.

У меня есть возражение. Прежде чем принимать решение, посмотрите, какие данные у вас есть.

Прежде чем принимать решение, посмотрите, какие данные у вас есть. Интересно, есть ли те, кто делает иначе.

Взял на заметку, спасибо.

Очень актуальная тема. Чем сложнее отменить решение, тем медленнее его принимайте.

Пишите, если есть вопросы отвечу по мере возможности.

Хочу задать вопрос. Люди защищают не процесс, а привычку. Сопротивление идет оттуда.

Это мое мнение, не утверждаю, что оно единственно верное.

вы правы. короче чем сложнее отменить решение, тем медленнее его принимайте.

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

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

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

Автоматический отчет о сканировании и пентест — это не одно и то же. Удачи.

Отличная работа.