Пентестеры требуют исправить всё за 30 дней: реальны ли такие сроки закрытия уязвимостей?

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

Звоните аудиторам прямо сейчас. Скажите: «У нас ограничен ресурс разработки мы закроем критические и высокие и сначала покажем их а по средним просим отсрочку». Обычно они без проблем продлевают срок по договору до 60 дней.

Общепринятые по рынку SLA на устранение уязвимостей выглядят так: 1) Критические (Critical) — максимум 7–14 дней; 2) Высокие (High) — до 30 дней; 3) Средние (Medium) — от 60 до 90 дней; 4) Низкие (Low) — до 180 дней либо в рамках планового техобслуживания.

edit: исправил несколько опечаток.

Компании по безопасности давят своим «устранить за 30 дней» просто чтобы не сбивать себе графики и побыстрее закрыть акт. Ни один вменяемый B2B-клиент не расторгнет контракт из-за medium-уязвимостей, если вы покажете логичный план, так что не порите горячку в коде.

навесите 28 багов на одного разраба — встанет разработка основного продукта а из-за спешки наделаете новых дыр. пусть чинит только 3 критических и всё.

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

Составьте для заказчика Remediation Plan (план устранения уязвимостей). Укажите в нем точные сроки закрытия критических и высоких рисков, а для средних распишите принятые временные меры — для их отдела комплаенса этого будет вполне достаточно.

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

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

большое сппасибо сегодня попробую.

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

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

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

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

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

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

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

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

Сохранил.

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

Меры, принятые без инвентаризации, оставляют открытыми двери, о которых вы не знаете.

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

На этом всё, извините, если затянул.