Пентест на боевом сайте — как составить план, чтобы избежать падения боевой среды?

Осторожнее с автозаполнением форм в сканерах. Если они начнут сканировать форму обратной связи или подписку, за 10 минут забивают очередь на 20 тысяч фейковых писем, и ваш почтовый сервер улетает в спам-листы. Исключайте эти формы.

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

Пару лет назад тестировали прод, пентестер искал SQLi и закинул запрос с задержкой (SLEEP). Пул соединений к БД выжрали за 3 минуты, в итоге вся оплата легла на 20 минут. Дежурный DevOps во время тестов обязателен!

Мы проводили с 02:00 до 06:00. При 1000 заказов в день ночью падаем до 15. В случае падения убытки минимальные. Днем на проде делать пентест категорически нельзя.

А как они платёжку будут тестировать? Реальные копейки списывать с карты или фейковый шлюз ставить? Если в ТЗ не прописать, бухгалтерия потом с ума сойдет.

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

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

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

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

Проверено опытом.

На что обратить внимание при выполнении этого. Главное не цифра, а то, на основе чего она получена.

То, что делают все, не значит, что это правильно. Я бы пошел этим путем.

Согласен.

Появились три разных мнения, они дополняют друг друга. Если на один вопрос вы получаете три разных ответа, вопрос задан неправильно.

Исправьте, если я ошибаюсь.

Слежу за темой.

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

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

Именно так, и при этом об этом мало кто знает. Пытаться сделать это в одиночку — самый дорогой путь.

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

Надеюсь, это будет полезно.

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

Оставлю как заметку, пригодится.

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

Ошибка сделанная на стороне план тестирования web pentest обычно исправима но дорого... Пишите если есть вопросы, отвечу по мере возможности.