Коли йдеться про інформаційну безпеку і захищеність вашої інфраструктури або банально про підготовку до комплаєнсу, замовити тестування на проникнення означає зробити лише половину справи. Друга половина полягає в опрацюванні результатів, тобто в усуненні вразливостей, зазначених у звіті про пентест.
Від того, як складено звіт, може суттєво залежати, як будуть розставлені пріоритети і скільки часу піде на його опрацювання. Тому для компанії нормальною практикою буде попросити в підрядника приклад звіту пентесту до того, як підписувати договір.
Ми рекомендуємо так і робити, адже це може вберегти від багатьох неприємних сюрпризів наприкінці. А в цій статті ми розглянемо, що має входити до звіту, яким він має бути, щоб із ним було зручно працювати, і що може свідчити про те, що з підрядником краще не зв'язуватися. Або навпаки, що це ідеальний вибір для ваших цілей.
Звіт пентесту: яким він має бути і для чого він потрібен
Звіти про пентест у різних підрядників можуть суттєво відрізнятися.. Один може містити десятки сторінок скріншотів із Burp Suite, CVE та технічних термінів. Інший - кілька сторінок із формулюваннями на кшталт “критичних вразливостей не виявлено, рекомендуємо своєчасно оновлювати програмне забезпечення”. Формально обидва документи можуть називатися звітом про тестування на проникнення. Але обидва навряд чи будуть відповідати реальним потребам бізнесу. Що тоді відповідає?
Почнемо з простої, але не завжди очевидної істини - для чого потрібен звіт. Пентест - це процес пошуку вразливостей, а звіт - це результат цього процесу. Звіт пентесту - це саме той документ, за яким CISO, інженери, аудитори й керівництво мають зрозуміти, що було перевірено, які проблеми були знайдені та наскільки вони важливі для бізнесу.
Якість пентесту складно оцінити тільки за кількістю знайдених вразливостей. Можна отримати десятки знахідок і водночас не мати відповіді на прості питання: що з цього справді важливо для бізнесу, як відтворити проблему і як її виправити, і що взагалі потрібно кидатись виправляти в першу чергу. Замовник і не має ломати над цим голову самостійно, бо відповіді на ці питання він має знайти у звіті.
Отже, в ідеалі якісний звіт про пентест містить:
- Executive Summary для керівництва;
- скоуп і методологію тестування;
- опис кожної вразливості з оцінкою CVSS;
- кроки відтворення і докази;
- вплив на бізнес;
- конкретні рекомендації та пріоритети усунення;
- технічні додатки.
Далі розглянемо все по порядку.
Executive Summary у звіті про пентест: що побачить керівництво
Вступну частину звіту зазвичай розглядають керівники напрямів, CISO або аудитори. На цьому рівні фокус зміщується з конкретних технічних деталей (як-от XXE чи IDOR) на загальну оцінку ризиків, охоплені компоненти та потенційні наслідки для бізнесу.
Тому хороший Executive Summary не є копією технічної частини у скороченому вигляді. Він пояснює результати мовою ризиків. Наприклад, замість “SQL injection у параметрі id” керівництву важливіше знати, що в разі хакерської атаки через цю проблему зловмисник може отримати доступ до даних клієнтів.
Ознакою гарного звіту буде, якщо в цій частині є короткий опис загальної картини: які ризики були виявлені, наскільки вони критичні, що входило до скоупу перевірки та, якщо це повторний пентест, що змінилося після попереднього тестування.
Якщо ж Executive Summary починається з CVSS-векторів, назв CVE та технічних деталей, найімовірніше, автор просто переніс частину технічного звіту в перший розділ.
Методологія і скоуп пентесту: що перевіряли і чого не чіпали
Фраза “критичних вразливостей не знайдено” сама по собі мало що говорить з точки зору реальних ризиків. Щоб зрозуміти її значення, потрібно знати, що саме тестували.
Зі звіту має бути зрозуміло, що саме входило до скоупу перевірки (активи): домени, IP-адреси, API, мобільні застосунки або інші компоненти. Так само важливо зазначити, який тип тестування проводився - black box, grey box чи white box - і за якою методологією працювала команда.
Для вебзастосунків це може бути, наприклад, OWASP Testing Guide або ASVS; для загальної структури penetration test - PTES чи NIST SP 800-115. Не обов'язково просто перелічувати стандарти. Важливо, щоб із документа було зрозуміло, як вони вплинули саме на тестування.
У звіті також має бути сказано, що саме команда не перевіряла. Наприклад, атаки на відмову в обслуговуванні (DoS) не проводились, щоб не порушити роботу живих систем. А перевірку співробітників на фішинг і інші прийоми соціальної інженерії просто не було включено в домовлений обсяг робіт.
Так само важливі дати проведення тесту. Звіт описує стан системи на конкретний момент. Кіберзагрози змінюються, і через місяць у системі може з'явитися нова вразливість.
Без всіх цих деталей складно правильно інтерпретувати навіть хороший технічний результат.
Знайдені вразливості: кожна знахідка має бути відтворюваною
Основна цінність технічної частини звіту - не в самому факті, що пентестер щось знайшов. Важливо, щоб команда замовника могла зрозуміти, що сталося, перевірити це у себе та виправити проблему.
Тому опис вразливості в нормі починається з чіткої назви та класифікації, а потім йде пояснення де саме вона знаходиться і як проявляється. Якщо вразливості оцінюють за шкалою CVSS, у звіті мало просто написати «High» чи «Critical». Варто показати, з яких параметрів склалася оцінка (це і є вектор CVSS), і пояснити, чому вразливість отримала саме такий рівень.
Наступним етапом наводяться кроки відтворення. Інженеру важливо отримати вичерпну інформацію без потреби в додаткових уточненнях. Для вебзастосунків це зазвичай включає конкретні URL та параметри, HTTP-запити й відповіді, а також тестові дані. Для інфраструктурних перевірок — відповідні команди, конфігурації чи інші артефакти, необхідні для підтвердження результату.
Важливою складовою звіту є артефакти та підтвердження. Наочні матеріали, як-от графічні докази або фрагменти логів, допомагають об'єктивно верифікувати знахідку та сприяють швидшій передачі інформації фахівцям з усунення вразливостей.
Останній важливий елемент опису вразливостей - це вплив. Технічний опис “можливе виконання довільного коду” не відповідає на питання, що це означає для конкретної компанії. Якщо знайдена проблема загрожує безпеці даних, наприклад дає доступ до даних клієнтів, дозволяє змінити фінансову інформацію або скомпрометувати інші системи, це потрібно показати окремо.
Таким чином, саме зв'язка проблема → доказ → відтворення → вплив перетворює технічну знахідку на результат, з яким можна працювати.
Рекомендації: не “посильте безпеку”, а що саме змінити
Після опису проблеми природно виникає наступне питання: що тепер робити?
Загальні поради на зразок «оновіть програмне забезпечення» або «посильте контроль доступу» без конкретного контексту мають обмежену користь. Ефективні рекомендації зазвичай чітко прив'язані до першопричини виявленої проблеми.
Якщо проблема пов'язана з відсутністю серверної валідації, звіт має вказати, де саме вона потрібна. Якщо використовується вразлива версія бібліотеки - назвати компонент і рекомендовану версію або спосіб усунення ризику. Якщо проблема виникає через неправильну конфігурацію - показати, який параметр потрібно змінити.
Не менш важлива пріоритизація. CVSS - корисна стандартизована метрика, але вона не завжди відображає фактичний пріоритет для конкретної компанії. Вразливість у компоненті, доступному з інтернету, і така сама проблема у внутрішній системі з обмеженим доступом можуть вимагати різної послідовності усунення (детальніше про це ми розповідали в статті “Що робити після пентесту”).
Якісний звіт не обмежується переліком із 40 задач на виправлення. Він допомагає визначити пріоритети і зрозуміти, з чого команді варто почати.
Додатки: усе, що не потрібно керівництву, але потрібно інженеру
Не кожну технічну деталь потрібно виносити в основну частину документа.
Повні HTTP-запити та відповіді, додаткові докази, перелік перевірених компонентів, технічні результати сканування або інформація про використані інструменти можуть бути винесені в додатки.
Це робить звіт зручнішим для обох аудиторій: керівництво отримує зрозумілий документ без безкінечних сторінок технічного шуму, а інженери мають доступ до деталей, необхідних для перевірки та усунення.
Red flags у звіті про пентест: коли варто повернути на доопрацювання
Існує низка ознак, які можуть свідчити про потребу в додатковому обговоренні або уточненні результатів із виконавцем.
- Немає зрозумілого опису скоупу і того, що залишилося за його межами.
- Методологія описана формально, без пояснення, що саме перевірялося.
- Executive Summary переповнений технічним жаргоном.
- Для вразливостей немає зрозумілого обґрунтування критичності.
- Відсутні кроки відтворення або докази результату.
- Рекомендації зводяться до загальних фраз на кшталт “посилити безпеку”.
- Немає пріоритизації усунення.
- Неможливо зрозуміти, які саме компоненти були перевірені.
- Звіт виглядає як шаблон, у якому змінили назву компанії та кілька технічних деталей.
- Після передачі звіту немає можливості поставити виконавцю питання щодо знахідок.
Наявність окремих зауважень не обов'язково свідчить про низьку якість роботи. Однак якщо звіт одночасно не містить чіткого опису скоупу перевірки, не деталізує відтворення знахідок та надає лише узагальнені поради, документ може потребувати суттєвого доопрацювання.
Приклад звіту AI Pentest
Автоматизація може суттєво скоротити час на окремі етапи пентесту, але вона не повинна означати, що фінальний звіт формується без перевірки людиною.
У AI Pentest автоматизована частина відповідає не лише за виявлення поверхні атаки та вразливостей, а й за їх експлуатацію та побудову ланцюжків атак.Виявлені проблеми додатково верифікує пентестер, який відповідає за фінальний результат і підписує звіт про тестування на проникнення.
Сам звіт побудований так, щоб бути корисним не тільки як підтвердження факту проведення тесту, а й як робочий документ для подальшого усунення знайдених вразливостей. Він придатний для проходження міжнародного комплаєнсу, якщо вразливості усунуто, та надається клієнту відразу після завершення пентестування, тобто протягом чотирьох днів від замовлення послуги.
Дізнатись більше AI Pentest від A42
