Після пентесту: як закрити знахідки і пройти ретест?

Після пентесту кожна знахідка отримує пріоритет за тим, наскільки легко її використати і що втратить бізнес, власника, строк і спосіб перевірки, а потім закривається виправленням причини, а не симптому. Наприкінці виконавець робить ретест, тобто повторно перевіряє ті самі знахідки і письмово підтверджує, які з них справді закриті.

Нижче пояснення оцінки CVSS простими словами, як розставити пріоритети, шаблон плану виправлень, що доводить і чого не доводить ретест, і типові помилки, через які знахідки повертаються.

Коротко

• Оцінка CVSS показує технічну тяжкість вразливості, а не ризик саме для вашої компанії. FIRST, автор стандарту, прямо каже, що базову оцінку не можна використовувати окремо для оцінки ризику. ^[1]
• Пріоритет визначають три питання: чи легко це використати, чи вже використовують таке в реальних атаках, і що втратить бізнес.
• У кожної знахідки є один власник із прізвищем, строк і спосіб перевірки. «Відділ розробки» власником не є.
• Виправляйте причину: якщо одна форма пропускала чужі дані, перевірте всі схожі місця.
• Ретест підтверджує, що конкретні знахідки закриті. Він не шукає нових проблем і не замінює наступний пентест.

Як читати критичність: CVSS v4.0 простими словами

CVSS (загальна шкала оцінки вразливостей) дає кожній проблемі число від 0 до 10. У версії 4.0 є такі рівні: 0.0 немає, 0.1 до 3.9 низький, 4.0 до 6.9 середній, 7.0 до 8.9 високий, 9.0 до 10.0 критичний. ^[1]

Важливо розуміти, з чого складається це число. Базова оцінка описує саму вразливість: чи можна атакувати через інтернет, чи потрібен вхід у систему, чи потрібна дія користувача, що станеться з даними. Вона не знає нічого про вашу компанію. Стандарт має ще групу загроз (чи є готовий спосіб атаки) і групу середовища (наскільки важлива саме ваша система), але їх заповнює той, хто використовує оцінку, тобто ви. ^[1]

FIRST окремо наголошує: базова оцінка вимірює тяжкість, а не ризик, і її треба доповнювати даними про загрози та ваше середовище. ^[2] Тому «9.1» у звіті означає «технічно дуже погано», але не завжди «виправляти першим».

Як визначити реальний пріоритет

Поставте до кожної знахідки три питання.

1. Наскільки легко це використати? Чи доступна вразливість з інтернету, чи потрібен обліковий запис, чи пентестер показав робочий приклад атаки. Знахідка, яку пентестер реально використав, важливіша за теоретичну.

2. Чи використовують таке в реальних атаках? Для відомих вразливостей у продуктах є відкриті джерела. Агентство CISA веде каталог KEV, перелік вразливостей, які вже використовуються в реальних атаках. ^[3] FIRST публікує EPSS, щоденну оцінку ймовірності того, що вразливість почнуть використовувати протягом наступних 30 днів. ^[4] Якщо знахідка є в KEV, її пріоритет вищий, ніж каже сама оцінка CVSS.

3. Що втратить бізнес? OWASP у методиці оцінки ризиків розділяє технічний вплив і вплив на бізнес і наголошує, що вплив на бізнес важливіший. ^[5] Доступ до бази клієнтів, платежів чи пошти керівника важить більше, ніж та сама вразливість на тестовому сервері без даних.

Пентестер не завжди знає всі деталі вашого бізнесу, тому може оцінити знахідку вище або нижче, ніж ви. NCSC нагадує, що рішення про ризик і виправлення лишаються за клієнтом, але цей процес не має бути способом применшити проблеми. ^[6]

Хто відповідає за кожну знахідку

Власник знахідки означає одну конкретну людину, яка відповідає за те, щоб проблему закрили і довели це. Це не обов'язково той, хто пише код: власник може доручити роботу, але відповідає за результат.

Типовий розподіл:

• вебзастосунок і API: керівник команди розробки продукту;
• сервери, мережа, хмара: адміністратор або керівник ІТ;
• облікові записи, доступи, пошта: адміністратор Microsoft 365 чи Google Workspace;
• процеси (наприклад, хто видає доступи новим людям): керівник напряму або операційний директор;
• рішення прийняти ризик без виправлення: власник бізнесу або CTO, з підписом.

План виправлень

Найпростіший робочий формат: таблиця з чотирма колонками. Строки нижче лише приклад, їх визначаєте ви з урахуванням пріоритету.

Колонка «як перевірити» найважливіша. Вона описує доказ, який ви покажете на ретесті, а не намір «виправити».

Що таке ретест і що він доводить

Ретест означає повторну перевірку тих самих знахідок після ваших виправлень, щоб підтвердити, що їх справді закрито. Пентестер повторює ту саму атаку, яка спрацювала раніше, і пробує обійти виправлення.

Ретест доводить:

• що конкретна атака зі звіту більше не працює;
• що виправлення не обходиться простим способом, наприклад іншою адресою чи іншою роллю користувача;
• який статус у кожної знахідки: закрита, частково закрита, не закрита або прийнята як ризик.

Ретест не доводить, що система тепер безпечна загалом. Він не шукає нових проблем, а якщо ви суттєво змінили продукт, потрібен новий пентест, а не повтор. Як підготуватися до тестування і ретесту, щоб нічого не загубити, описано в статті як підготуватися до пентесту.

Чи входить ретест у ціну і скільки часу він займає, варто погодити ще до старту. Від чого залежить вартість, пояснено в статті що входить у пентест і скільки він коштує.

Типові помилки

• Виправити симптом. Заблокували одну адресу, через яку видно чужі замовлення, а перевірку прав не додали. Ретест знаходить ту саму помилку в сусідньому розділі.
• Закрити тікет без доказу. Розробник позначив задачу виконаною, але ніхто не перевірив атаку повторно. У звіті ретесту знахідка лишається відкритою.
• Сортувати лише за числом CVSS. Високі оцінки на тестовому сервері виправляють першими, а середня знахідка з доступом до даних клієнтів чекає місяць.
• Не призначити власника. Знахідка «для всіх» не належить нікому і переходить у наступний звіт.
• Мовчки прийняти ризик. Якщо щось вирішили не виправляти, це рішення записують із причиною, строком перегляду і підписом.
• Чекати місяцями з ретестом. За цей час система змінюється, і результат стає важко порівняти зі звітом.

Чекліст після пентесту

• Керівництво прочитало короткий підсумок звіту і розуміє критичні знахідки.
• Кожна знахідка має одного власника з прізвищем.
• Пріоритет враховує простоту використання, каталог KEV і вплив на бізнес, а не лише CVSS.
• Для кожної знахідки записано строк і спосіб перевірки.
• Критичні знахідки закриваються негайно, без очікування решти.
• Після виправлення перевірено схожі місця, а не лише одну адресу зі звіту.
• Знахідки, які вирішили не виправляти, оформлені як прийнятий ризик із підписом.
• Дата ретесту погоджена з виконавцем.
• Після ретесту є письмовий статус кожної знахідки.

Завантажити чекліст підготовки (PDF)PDF · A4

FAQ

Що робити одразу після отримання звіту пентесту?

Прочитайте короткий підсумок, призначте власника кожній критичній знахідці і почніть із них. Потім складіть план для решти: власник, строк і спосіб перевірки для кожного пункту.

Чи завжди виправляти спершу знахідки з найвищою оцінкою CVSS?

Ні. CVSS показує технічну тяжкість, а не ваш ризик. Знахідка, яку легко використати і яка веде до даних клієнтів чи грошей, часто важливіша за вищу оцінку на системі без цінних даних.

Що таке ретест після пентесту?

Це повторна перевірка тих самих знахідок після виправлень. Пентестер повторює атаку і письмово підтверджує, що закрито, що закрито частково, а що ні.

Чи шукає ретест нові вразливості?

Ні, ретест перевіряє лише знахідки з попереднього звіту. Якщо продукт суттєво змінився, потрібен новий пентест.

Що робити, якщо знахідку неможливо виправити зараз?

Додайте тимчасовий захист, наприклад обмеження доступу чи додатковий моніторинг, і оформіть прийнятий ризик: причина, хто вирішив, до якої дати. Повертайтеся до неї на наступному плануванні.

Посилання

1. FIRST: CVSS v4.0 Specification Document first.org
2. FIRST: CVSS v4.0 User Guide first.org
3. CISA: Known Exploited Vulnerabilities catalog data github.com
4. FIRST: Exploit Prediction Scoring System (EPSS) first.org
5. OWASP Risk Rating Methodology community.owasp.org
6. NCSC: Penetration testing ncsc.gov.uk