Нас обязали пройти пентест — что это такое на реальном примере и нужен ли он нам?

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

Прошлой осенью мы впервые проходили это для своего логистического софта схожего масштаба. Тест занял 4 рабочих дня, отдали 3 200 GBP. Нашли 6 уязвимостей, из них одну критическую. Мы в своём коде были уверены на все сто, но в заголовках сервера случайно светилась точная версия базы данных. За неделю всё закрыли, клиент увидел чистый отчёт и сразу подписал контракт.

Будьте предельно внимательны при согласовании скоупа (границ тестирования). Не включайте туда самого хостинг-провайдера вашей облачной инфраструктуры — только ваш собственный код, механизмы авторизации и API. Иначе они начнут сканировать сервисы облачного провайдера, а это раздует сроки и бюджет тестирования в два раза.

Не соглашайтесь сразу на первые попавшиеся предложения от ИБ-компаний. Многие агентства ломят космические ценники вроде 10.000 GBP, а по факту прогоняют всё автосканерами и на этом успокаиваются. Возьмите 2-3 предложения от бутиковых контор или независимых сертифицированных сеньор-специалистов. И обязательно уточните, будет ли отчет оформлен по международно признанным методологиям.

Ради контракта с годовой выручкой в 52.000 GBP потратить около 3.000 GBP на пентест — это вполне оправданная стоимость привлечения клиента (CAC). К тому же, получив этот отчет, вы сможете следующие 12 месяцев показывать его как доказательство надежности другим корпоративным заказчикам на переговорах.

а если во вреям теста найдут уязвимости и мы не успеем их быстро закрыть, что тогда? безопасники отправляют отчет напрямую заказчику или сначала отдают его нам?

исправление: ошибся в цифре, было чуть меньше.

Стандартный процесс состоит из 4 этапов: 1) Согласование скоупа и подписание NDA, 2) Симуляция атак на тестовом контуре (на клоне сервера без боевых данных), 3) Передача вашей команде промежуточного отчета со списком уязвимостей и их исправление, 4) Проверка исправлений (ретест) и составление финального чистого отчета для заказчика.

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

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

А как вы решили этот вопрос? Если не зафиксировать это письменно с самого начала, потом возникнут споры.

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

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

Я бы пошел этим путем.

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

Мне тоже интересно. Без измерений мы всегда приходим к одному и тому же.

Безопасность не бывает абсолютной; цель — сделать атаку нецелесообразной. Интересно, есть ли те, кто делает иначе.

Спасибо за ваш пост. Если делаете впервые, начните с малого, масштабирование потом.

Все, кто торопится с пример пентеста, спотыкаются на одном и том же. Проверено опытом.

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

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

Поделюсь своим опытом. Все, кто торопится с пример пентеста, спотыкаются на одном и том же.

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

Согласен, хочу даже особо подчеркнуть. Ответ сильно зависит от отрасли, универсального правила нет.

Конечно, если ваша ситуация отличается, всё меняется.

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

Ответ выше точно передал суть вопроса. При принятии решений записывайте и худший сценарий, а не только лучший.

Изменение платежных данных никогда не подтверждается через тот же канал. Проверено опытом.