Крупный клиент перед подписанием договора требует пентест. Как правильно определить скоуп?

Аудиторы в корпорациях отчеты из автоматических сканеров палят моментально. Если в начале нет executive summary, описания методологии и дат устранения найденных уязвимостей, клиент отчет просто не примет. Не пытайтесь скроить копейки, рискуя контрактом.

Запросите у заказчика письменное ТЗ или чек-лист требований. У большинства крупных компаний критерии безопасности стандартизированы. Передадите этот документ подрядчикам — и избежите лишних накруток за ненужные проверки.

Чтобы зафиксировать скоуп, подрядчикам нужно четко дать три вещи: 1) Количество ролей в системе (админ, дилер, обычный юзер). 2) Количество публичных эндпоинтов API. 3) Где тестируем — на проде или на идентичном стейджинге.

У нас команда 18 человек в Валенсии, проходили такое. Похожий клиент спокойно принял отчет по пентесту за 4.000 евро. Работали 4 дня, нашли 2 хай-левел бага. Мы их закрыли за 10 дней, ребята бесплатно перепроверили и обновили отчет. Через два дня клиент подписал контракт.

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

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

от тех кто обещает за 2 дня управиться бегите подальше... тупо запустят сканер и скинут pdf... крупный клиент сразу раскусит и заставит переделывать.

edit: выше написал неправильно, извините.

65.000 евро в год — отличный контракт, поздравляю! 3.000–4.000 евро при таком чеке абсолютно нормальная инвестиция в безопасность. Тем более этот отчет потом можно показывать и другим крупным лидам как знак надежности.

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

Удачи.

Именно так и при этом об этом мало кто знает. в общем забытые тестовые среды становятся входом в систему чаще чем продакшн.

Главное не цифра, а то, на основе чего она получена.

Мне тоже интересно.

Эта тема в архиве.

Давайте разделим понятия, их путают. Первые три месяца все идет хорошо проблемы всплывают на четвертом.

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

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

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

Мы тоже какое-то время назад застряли на том же месте. Доступность резервной копии в той же сети и под той же учетной записью делает ее частью цели атаки.

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

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

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

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

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

Давайте немного раскрою техническую сторону. Если не зафиксировать это письменно с самого начала, потом возникнут споры.