Зміст статті
Добрий звіт з пентесту містить коротке резюме для керівництва, межі і дати перевірки, методику, а також кожну знахідку з рівнем критичності, доказом, кроками відтворення, впливом на бізнес і способом виправлення. Після виправлень до нього додають результат ретесту: що закрито, а що ні.
Нижче розбір звіту за розділами, таблиця «хто читає і що має бути», як оцінюють критичність, приклад однієї знахідки і ознаки звіту, за який не треба платити.
Коротко
- Резюме для керівництва пояснює простими словами, що знайшли і чим це загрожує бізнесу. Без жаргону.
- Межі, дати й обмеження показують, що саме перевіряли, а що ні. Без цього звіт не можна показати партнеру чи аудитору.
- Кожна знахідка має назву, рівень критичності, опис, доказ, кроки відтворення, вплив і рекомендацію з виправлення.
- Критичність зазвичай рахують за CVSS від FIRST і уточнюють з урахуванням вашого бізнесу.
- Ретест підтверджує, що виправлення працюють. Його результат додають до звіту або видають окремим документом.
- Експорт сканера з новою обкладинкою не є звітом з пентесту.
Звіт за розділами: хто читає і що має бути
Звіт читають різні люди: керівник вирішує, на що дати гроші й час, розробник виправляє, аудитор чи партнер перевіряє, що тест був. NIST прямо пише, що в звіту може бути кілька аудиторій і для них можуть знадобитися різні формати. [2] PTES ділить звіт на дві великі частини: резюме для керівництва і технічний звіт. [3] OWASP WSTG пропонує схожу структуру: вступ з межами й обмеженнями, резюме, знахідки і додатки. [4]
| Розділ | Хто читає | Що має бути | Тривожний знак, якщо цього немає |
|---|---|---|---|
| Резюме для керівництва | Власник, CEO, CTO | Мета перевірки, головні знахідки мовою бізнесу, загальний стан, пріоритетні кроки | Керівник не розуміє, що робити, і звіт лягає в шухляду |
| Межі, дати, обмеження | CTO, аудитор, партнер | Які системи, адреси й ролі перевіряли, період робіт, що не перевіряли і чому | Неможливо довести, що саме перевірено |
| Методика | CISO, аудитор | Підхід і стандарти (OWASP WSTG, PTES, NIST SP 800-115), ручна і автоматична частина | Незрозуміло, чи це пентест, чи прогін сканера |
| Зведена таблиця знахідок | CTO, керівник розробки | Номер, назва, рівень критичності кожної знахідки | Важко спланувати роботу і розподілити задачі |
| Деталі знахідок | Розробники, адміністратори | Опис, доказ, кроки відтворення, вплив, рекомендація, посилання | Команда не може відтворити проблему і не вірить у неї |
| Пояснення оцінки ризику | CISO, аудитор | Як рахували критичність: CVSS, бізнес-контекст | Рівні виглядають довільними |
| Додатки | Технічна команда | Очищений вивід інструментів, перелік виконаних перевірок | Немає слідів, що перевірки взагалі проводили |
| Результат ретесту | Усі, хто читав звіт | Статус кожної знахідки після виправлень | Невідомо, чи виправлення спрацювали |
WSTG також радить додати до вступу застереження, що тест показує стан на конкретний момент і не гарантує повноти. [4] Це чесно: пентест обмежений межами і часом.
Що має бути в кожній знахідці
Знахідка є основною одиницею звіту. Розробник має відкрити її і без дзвінка тестувальнику зрозуміти, що зламано, як це перевірити і як виправити. WSTG перелічує такі поля: номер, назва, ймовірність або легкість використання, вплив, рівень ризику, опис, рекомендація і додаткові матеріали. [4]
На практиці добра знахідка містить:
- номер і коротку назву, яка каже суть: «Покупець бачить чужі замовлення», а не «Проблема авторизації»;
- рівень критичності і, якщо домовлялися, вектор CVSS;
- де саме: адреса, параметр, роль користувача;
- опис простими словами: що не так і чому це небезпечно;
- доказ: запит і відповідь, знімок екрана, команда, з якої видно результат; чутливі дані замасковані;
- кроки відтворення, за якими розробник повторить проблему сам;
- вплив на бізнес: які дані, гроші чи процеси під загрозою;
- рекомендацію: що саме змінити, а не загальне «оновіть систему»;
- посилання: CWE, документацію, гайд з виправлення.
Приклад добре описаної знахідки
Приклад вигаданий, щоб показати формат.
| Поле | Зміст |
|---|---|
| Номер і назва | VT-03. Покупець бачить чужі замовлення (IDOR) |
| Критичність | Висока |
| Де | GET /orders/{id}, роль «покупець» |
| Опис | Сервер не перевіряє, чи належить замовлення користувачу, який його запитує. Достатньо змінити номер в адресі. |
| Доказ | Користувач A відкриває /orders/1045 (своє замовлення), змінює адресу на /orders/1046 і отримує відповідь 200 з ім’ям, телефоном і адресою доставки користувача B. Знімок екрана і запит додано, персональні дані замасковано. |
| Кроки відтворення | 1. Увійти як тестовий покупець A. 2. Відкрити своє замовлення. 3. Змінити номер в адресі на сусідній. 4. Побачити чуже замовлення. |
| Вплив | Будь-який зареєстрований покупець може по черзі вивантажити дані всіх клієнтів. Це витік персональних даних і питання до вас від регулятора. |
| Рекомендація | На сервері перевіряти власника замовлення для кожного запиту. Не покладатися на те, що номер «важко вгадати». Додати автотест на доступ до чужого об’єкта. |
| Посилання | CWE-639: Authorization Bypass Through User-Controlled Key |
| Ретест | Виправлено. Запит до чужого замовлення повертає 404. |
Різницю між такою знахідкою і рядком зі сканера показано в статті пентест чи сканування вразливостей.
Як оцінюють критичність
Найпоширеніша система оцінки називається CVSS. Її розвиває організація FIRST. Остання версія, CVSS v4.0, вийшла в листопаді 2023 року. [1]
CVSS v4.0 має чотири групи метрик: [1]
- Base: властивості самої вразливості, які не змінюються з часом і не залежать від середовища;
- Threat: те, що змінюється з часом, наприклад чи є готовий експлойт;
- Environmental: особливості вашого середовища, наприклад захисні заходи;
- Supplemental: додатковий контекст, який не змінює саму оцінку.
Оцінка від 0 до 10 перекладається в рівні: 0.1–3.9 низький, 4.0–6.9 середній, 7.0–8.9 високий, 9.0–10.0 критичний. [1] Специфікація радить доповнювати базову оцінку метриками загроз і середовища. Сам по собі Base не описує ризик для вашої компанії. [1]
Тому в доброму звіті поруч з CVSS є бізнес-контекст. Одна й та сама вразливість у тестовому середовищі без даних і в платіжному модулі має різний пріоритет. Чесний підрядник пояснює, чому підняв або знизив рівень.
Альтернатива CVSS: OWASP Risk Rating Methodology. Ризик там рахують як поєднання ймовірності й впливу, кожне за шкалою від 0 до 9, з окремими факторами для технічного і бізнес-впливу. [5] Автори методики прямо пишуть, що бізнес-вплив важливіший. [5] Обидва підходи нормальні. Головне, щоб звіт пояснював, як саме рахували.
Ознаки слабкого звіту
- Експорт сканера під новою назвою. Сотні рядків «можлива вразливість», однакові рекомендації, жодної ручної перевірки. Це сканування, а не пентест.
- Немає доказів. Знахідка описана словами, але не видно запиту, відповіді чи знімка екрана. Команда не може переконатися, що проблема існує.
- Немає кроків відтворення. Розробник не може повторити проблему, а потім і перевірити своє виправлення.
- Усе «критичне». Коли все горить, команда не знає, з чого почати. Рівні мають відрізнятися і мати пояснення.
- Немає меж. Невідомо, які системи перевіряли. Такий звіт не підтвердить нічого партнеру чи аудитору.
- Немає рекомендацій або вони загальні. «Дотримуйтесь найкращих практик» не можна взяти в роботу.
- Немає ретесту. Без повторної перевірки невідомо, чи виправлення спрацювали. NIST описує повторне тестування як спосіб підтвердити, що заходи з виправлення виконано. [2]
Що робити зі звітом далі
NIST радить, щоб звіт для внутрішнього використання містив методику, результати, аналіз і план дій з виправлення з конкретними кроками й строками. [2] Простіше кажучи:
- Розберіть звіт з підрядником на зустрічі, поки питання свіжі.
- Перетворіть знахідки на задачі з відповідальними і строками, починаючи з критичних і високих.
- Виправте, перевірте у себе, потім замовте ретест.
Як організувати цю роботу, описано в статті після пентесту: як закрити знахідки і пройти ретест. Якщо ви ще обираєте виконавця, попросіть знеособлений приклад звіту ще до договору. Що ще запитати, описано в статті як обрати компанію для пентесту.
У звіті Veiltrack є резюме для керівництва, таблиці знахідок за рівнем ризику, а для кожної знахідки категорія, CWE, оцінка CVSS 3.1 або 4.0 на вибір замовника, технічний опис, докази й знімки екрана, а також порядок виправлень. Детальніше на сторінці пентест.
Чекліст: перевірте звіт перед прийманням
Завантажити чекліст підготовки (PDF)PDF · A4
FAQ
Що має бути у звіті з пентесту обов’язково?
Резюме для керівництва, межі і дати, методика, зведена таблиця знахідок і деталі кожної знахідки: критичність, доказ, кроки відтворення, вплив і рекомендація. Після виправлень додають результат ретесту.
Чим звіт з пентесту відрізняється від звіту сканера?
Звіт сканера перелічує можливі проблеми без ручної перевірки. У звіті з пентесту кожна знахідка підтверджена людиною, має доказ, кроки відтворення і пояснення, що це означає саме для вас.
Чи обов’язково використовувати CVSS?
Ні. CVSS найпоширеніший, але можна використовувати й OWASP Risk Rating Methodology чи власну шкалу. Важливо, щоб звіт пояснював, як рахували рівні, і враховував ваш бізнес.
Хто має читати звіт у компанії?
Резюме читає керівництво, щоб ухвалити рішення про ресурси. Деталі знахідок читають розробники й адміністратори, які виправляють. Межі і методику перевіряє аудитор або партнер.
Чи можна показати звіт клієнту чи партнеру?
Так, але зазвичай показують резюме, межі і статус ретесту, а не технічні деталі. Повний звіт з кроками відтворення передають лише тим, кому він потрібен для роботи.
Посилання
- FIRST: CVSS v4.0 Specification Document first.org
- NIST SP 800-115: Technical Guide to Information Security Testing and Assessment nvlpubs.nist.gov
- PTES Technical Guidelines: Reporting pentest-standard.readthedocs.io
- OWASP WSTG: Reporting Structure wstg.owasp.org
- OWASP Risk Rating Methodology community.owasp.org
