Як читати звіт про тестування на проникнення

З чого складається хороший звіт

Більшість професійних звітів мають передбачувану структуру, і знання її дозволяє швидко знаходити потрібне. Резюме для керівництва пишеться для управлінців: межі, загальний рівень ризику і дві-три головні теми. Розділ методології вказує, якого стандарту дотримувався тест — найчастіше OWASP Web Security Testing Guide (WSTG) для вебзастосунків, OWASP ASVS як базу верифікації та PTES для перебігу всього проєкту — а також дати, середовище й обмеження. Розділ знахідок — робоче ядро: один запис на проблему, кожен із рівнем критичності, вектором CVSS, доказами і способом виправлення. Додаток зазвичай містить деталі меж, інструменти й елементи поза межами робіт.

• Резюме для керівництва — для осіб, що ухвалюють рішення, без жаргону, загальний ризик і теми
• Межі та правила проведення — що саме тестувалося, коли і що було під забороною
• Методологія — застосований стандарт (OWASP WSTG/ASVS, PTES, NIST SP 800-115)
• Знахідки — ранжований список дій, у якому ви проведете найбільше часу
• Додатки — докази, вивід інструментів і деталі відтворення

Що насправді означають оцінки CVSS v3.1

CVSS (Common Vulnerability Scoring System) v3.1 перетворює набір характеристик на число 0.0–10.0 і відповідний рівень критичності. Базова оцінка (Base) відповідає на питання «наскільки погана ця вразливість у принципі» за допомогою метрик, які ви бачите у векторі, наприклад CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (оцінка 9.8). Читайте вектор, а не лише число: Attack Vector (Network/Adjacent/Local/Physical), Attack Complexity, Privileges Required, User Interaction, Scope і вплив на Confidentiality/Integrity/Availability.

• 0.0 = None, 0.1–3.9 = Low, 4.0–6.9 = Medium, 7.0–8.9 = High, 9.0–10.0 = Critical
• AV:N (доступна мережею) набагато терміновіша, ніж AV:L (потрібен локальний доступ)
• PR:N + UI:N означає відсутність входу і дій жертви — вважайте небезпечнішим
• S:C (Scope: Changed) означає, що вразливість виходить за межі свого компонента і впливає на інші
• Базова оцінка поза контекстом; хороший звіт додає контекст середовища зверху

Рівень критичності — відправна точка, а не вся картина

Базова оцінка CVSS навмисно поза контекстом — вона не знає, що знахідка «High» перебуває на внутрішньому адміністративному інструменті, доступному лише через VPN, або що «Medium» — на вашій публічній сторінці оплати. Тому CVSS визначає також метрики середовища (Environmental), що коригують оцінку під ваше розгортання (цінність активу, наявні заходи, експозиція). Зрілий звіт або застосовує цю корекцію, або дає бізнес-контекст, щоб ви зробили це самі. Практичне правило: використовуйте рівень критичності від виконавця для первинного сортування, а потім переранжуйте за цінністю активу і тим, хто може до нього дістатися.

• Medium на доступному з інтернету неавтентифікованому ендпоінті може перевершити High на ізольованій машині
• Компенсаційні заходи (WAF, сегментація мережі, MFA) реально знижують ризик
• Ланцюжки знахідок важливі: два Medium, що складаються в захоплення акаунта, — це фактично Critical
• Попросіть тестувальника пояснити будь-яку оцінку, з якою ви не згодні — обґрунтування має бути прозорим

Пріоритизація усунення: ризик × трудовитрати

Не можна виправити все одразу, і не потрібно намагатися. Розмістіть кожну знахідку за двома осями: ризик (критичність із поправкою на ваше середовище) і трудовитрати на усунення (години, радіус впливу, ризик розгортання). Порядок, який захищає найшвидше: спершу пункти високого ризику і низьких витрат — швидкі перемоги, що дешево прибирають реальну експозицію (відсутній заголовок безпеки, облікові дані за замовчуванням, застаріла залежність із доступним патчем). Далі пункти високого ризику і високих витрат отримують запланований проєкт і тимчасовий компенсаційний захід. Проблеми низького ризику і низьких витрат об'єднуються в планове обслуговування. Пункти низького ризику і високих витрат — кандидати на документоване прийняття ризику.

• Квадрант 1 — високий ризик, низькі витрати: робіть зараз, це ваші термінові патчі
• Квадрант 2 — високий ризик, високі витрати: плануйте і виділяйте ресурси, додайте тимчасовий захід
• Квадрант 3 — низький ризик, низькі витрати: включіть у найближче вікно обслуговування
• Квадрант 4 — низький ризик, високі витрати: формально прийміть ризик або відкладіть із власником і датою
• Призначте кожній знахідці власника і термін — знахідка без власника ніколи не буде виправлена

Proof of concept: доказ, якому можна довіряти

Proof of concept (PoC) — це демонстрація тестувальником того, що вразливість реальна й експлуатована, а не теоретична. Зазвичай він містить точний запит або кроки, відповідь чи результат, що доводить вплив, і достатньо деталей, щоб розробники відтворили це в безпечному середовищі. Хороший PoC — це різниця між «сканер це позначив» і «ми отримали дані іншого клієнта цим запитом». Відтворіть PoC самі на стенді до і після виправлення — так ви підтверджуєте і проблему, і рішення, а не вірите жодному звіту на слово.

• Шукайте конкретний запит/payload, спостережений результат і кроки відтворення
• Скриншоти або захоплені відповіді мають показувати вплив, а не лише попередження інструмента
• PoC — це демонстрація, а не експлуатація — професійний тест зупиняється на доказі, не озброюючи атаку
• Якщо у знахідки немає PoC і чіткого обґрунтування, запитайте, чи це не false positive

False positive і false negative

False positive — це заявлена проблема, яка у вашому контексті не експлуатована, наприклад сканер позначає версію бібліотеки як вразливу, хоча вразливий шлях коду ніколи не викликається, або «відбите введення», яке безпечно кодується. Тестування на проникнення, яке проводить людина, існує значною мірою для того, щоб їх усувати: справжній тестувальник перевіряє кожну машинну підказку, перш ніж вона потрапить у звіт. Складніша проблема — false negative, реальна вразливість, яку тест не знайшов. Жоден тест не доводить відсутність усіх помилок; тому важливі межі, обмеження часу і прозорість методології, і тому тестування періодичне, а не одноразове.

• False positive = заявлено, але не реально/не експлуатовано; у перевірених звітах їх дуже мало
• False negative = реальна проблема, яку пропустили; керується межами, покриттям і повторними тестами
• Якщо вважаєте знахідку false positive, відповідайте з доказами — тестувальники приймають виправлення
• Проходження без знахідок — не гарантія безпеки, а лише того, що охопив цей тест

Ретест і верифікація

Виправлення знахідки — це заява; верифікація — доказ. Після усунення тестувальник повторно запускає початковий proof of concept проти виправленої системи, щоб підтвердити, що виправлення тримається і не просто перемістило проблему в інше місце. Більшість проєктів включають раунд верифікації у визначеному вікні (часто 30–90 днів). Результат — оновлений звіт, де кожен виправлений пункт позначено як перевірений/закритий із датою ретесту, а все ще експлуатоване переоткривається. Цей замкнений запис — знайдено, виправлено, перевірено, закрито — це саме те, що хочуть бачити аудитори і клієнти.

• Верифікація повторює початковий PoC, а не свіже загальне сканування
• Очікуйте статуси: Open, Remediated (заявлено клієнтом), Verified/Closed і Risk Accepted
• Узгодьте вікно ретесту до початку робіт, щоб виправлення встигли в нього вкластися
• Часткове виправлення має бути переоткрите — верифікація захищає від регресій «виглядає виправленим»

Використання звіту для відповідності вимогам

Один і той самий звіт підтримує кілька стандартів, але кожен читає його по-своєму. Для SOC 2 пентест — це доказ для критеріїв безпеки Trust Services Criteria: аудитори хочуть бачити, що тест відбувся, знахідки відстежувалися, а усунення керувалося. Для ISO 27001 він живить технічні заходи Додатка A (зокрема A.8.8 управління технічними вразливостями та A.8.25/A.8.29 безпечна розробка і тестування безпеки в редакції 2022) і ваш процес оброблення ризику. Для PCI DSS v4.0 тестування на проникнення — жорстка вимога в межах Вимоги 11.4, з визначеними межами (зовнішні та внутрішні), щорічною періодичністю, тестуванням після значних змін і перевіркою того, що засоби сегментації дійсно ізолюють середовище даних власників карток.

• SOC 2 — підтверджує критерії безпеки; аудитори перевіряють тест + відстеження + усунення
• ISO 27001:2022 — підтримує Додаток A.8.8, A.8.25, A.8.29 і план оброблення ризику
• PCI DSS v4.0 — Вимога 11.4: щорічні + після змін тести, внутрішні та зовнішні, перевірка сегментації
• Дайте аудиторам звіт разом із трекером усунення і результатами верифікації, а не сам звіт
• Збережіть заяву про межі — вона точно визначає, що оцінка охоплює, а що ні

Поширені помилки, яких варто уникати

Точка відмови — не звіт, а те, що відбувається після нього. Команди, які отримують користь із пентесту, ставляться до знахідок як до відстежуваного бэклогу з власниками і термінами, перевіряють свої виправлення і ретестують за розкладом. Команди, які цього не роблять, зазвичай виправляють лише Critical, підшивають звіт для аудитора і через рік заново відкривають те саме Medium. Дві звички найважливіші: ніколи не дозволяйте одному рівню критичності задавати порядок робіт без поправки на експозицію і ніколи не позначайте щось як виправлене без верифікації.

• Не виправляйте лише Critical — зчеплені Medium призводять до реальних зломів
• Не ставтеся до звіту як до артефакту відповідності, який підшили і забули
• Не сертифікуйте виправлення самі — проведіть їх верифікацію
• Не ігноруйте прийняті ризики — переглядайте їх кожен цикл, власник і контекст змінюються

Часті запитання