How to Write a Penetration Test Findings Summary in English

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

Ключовий словник

** Визначення ** — одна визначена проблема безпеки, задокументована у звіті, зазвичай, включає опис, докази, оцінку тяжкості і рекомендовані заходи по усуненню. “Це виявлення описує обхід автентифікації в потоці скасування пароля, з долученим запитом на дослідження концепції, який показує, як саме це було викликано.”

** Оцінка тяжкості ** — стандартизована класифікація (часто Критична, Висока, Середня, Низька), яка присвоюється кожному виявленню на основі його потенційного впливу і того, наскільки легко його можна використати.

• “Ми оцінили це виявлення як Критичне, оскільки воно надає неавтентифікований доступ до даних інших користувачів без необхідності виконання особливих умов.” *

** Доказ концепції (PoC) ** — мінімальна, відтворювана демонстрація того, що вразливість є реальною і експлуатабельною, зазвичай включена, щоб інженери могли перевірити виправлення за допомогою тих самих кроків. “Доказ концепції — це одна команда curl, яка повертає приватні дані іншого користувача — відтворіть їх проти стажування до і після вашого виправлення.”

** Ремонт ** — рекомендований виправлення або зменшення для виявлення, ідеально достатньо конкретний, щоб інженер міг діяти безпосередньо на нього без подальшого дослідження.

• “Розв’ язання цієї проблеми дуже просто: перевірте, чи запитуваний ресурс належить автентифікованому користувачеві, перш ніж повернути його.” *

** Поверхня атаки ** — загальний набір точок, де неавторизований користувач може потенційно взаємодіяти або спробувати вдертися до системи, які тест проникнення має на меті відобразити і проаналізувати. *“Це залучення було зосереджено на зовнішній поверхні атаки - публічні API і веб-застосування, спрямовані на клієнта - внутрішні служби були за межами цього раунду.” *

Структурування резюме

• Розгорнуте резюме: “Заявте загальну позицію ризику в двох або трьох реченнях, і кількість виявлених випадків за тяжкістю, перед будь-якими технічними деталями - керівництво читає цей розділ і зупиняється.”
• ** Обсяг**: « Визначте точно, що було перевірено, а що ні, щоб ніхто не вважав, що неперевірена система була непрямо очищена. »
• ** Види**: « Один запис на проблему, кожна з тяжкістю, описом, доказом концепції і виправленням — ніколи не об’ єднуйте кілька не пов’ язаних проблем в один випадок. »
• ** Графік усунення помилок **: « Сполучте ступінь тяжкості кожного виявлення з очікуваним графіком виправлення, оскільки « Критичний » має означати невідкладність, яка фактично відображається у строку »

Розповсюджується на різні аудиторії

• Для лідерства: «Це залучення визначило один Критичний і три Середніх результати; Критичний випадок вже був залатий і перевірений, і Середні заплановані для цього спринту»
• Для інженерів: «Це виявлення є IDOR на кінцевій точці /api/orders/{id} — дивіться долучене доведення концепції для точного запиту, який повертає запит іншого користувача»
• «Для зацікавлених сторін: «Всі результати відстежуються з тяжкістю, власником і терміном виправлення в пов’язаній системі квитків, і ми надамо підтвердження повторного тестування, як тільки кожен буде закритий»

Професійні поради

1. ** Оцініть ступінь тяжкості послідовно, а не за інстинктивним відчуттям. ** Використання документованої рубрики (можливість використання плюс вплив) для кожного виявлення, а не інтуїтивної мітки, запобігає розбіжностям пізніше щодо того, чи було щось справді « Критичним », чи просто звучить тривожно.
2. ** Включіть доказ концепції для кожного технічного виявлення. ** Ясний, відтворюваний доказ концепції виключає неоднозначність щодо того, чи є проблема реальною, і дозволяє інженерам перевірити власне виправлення за допомогою точно таких самих кроків.
3. ** Спаруйте кожен результат з конкретним, призначеним для усунення. ** Результат без конкретного рекомендованого виправлення сприймається як критика без напрямку — завжди закінчуйте кожен результат тим, що слід змінити, а не лише тим, що не так.

Практичні вправи

1. Напишіть резюме у одному реченні, у якому буде описано гіпотетичний тест проникнення з одним критичним і двома низькими результатами.
2. Створити чернетку прикладного запису пошуку (опис, ступінь тяжкості, виправлення) для кінцевої точки, яка повертає дані без перевірки прав доступу запитувача.
3. Поясніть, в одному реченні, чому доказ концепції має значення навіть після того, як виявлення вже було описано словами.

Національні мови: мова рідних, мова носіїв мов інших народів

Написання резюме результатів тестів проникнення вже є викликом - переробка складних технічних деталей в дії, що вимагають точності. Але для розробників, чия перша мова не є англійською, завдання може здатися експоненційно важчим. Це не просто переклад слів; це розуміння тонких нюансів у фразуваннях і прийняття стилю, який поширений у професійному спілкуванні з розробкою програмного забезпечення. Погано сформоване резюме може призвести до неправильного тлумачення, затримок у усуненні, або навіть сприйняття недбалості. Давайте розглянемо деякі конкретні області, в яких носії мови, які не є рідними, часто стикаються з труднощами, і запропонуємо практичні стратегії.

Однією з ключових областей є використання активного голосу. Рідні носії англійської інстинктивно використовують активний голос – «The vulnerability was exploited» (вразливість була використана), а не «It was exploited» (її використовували). Хоча останнє не є граматично неправильним, активний голос забезпечує ясність і негайно визначає, хто або що виконав дію. Наприклад, у коментарі до перегляду коду ви можете побачити, як ваш колега каже: « Логіка цього скрипту не обробляє регістр країв; її слід переписати, щоб запобігти обходу цього типу ». Активне формулювання (« не обробляє ») є більш прямим, ніж пасивне (« не обробляється »). Аналогічно, при описі результатів в описі Pull Request, заява «Злочинець використав вразливість введення SQL…» є набагато яснішою і більш вражаючим, ніж «Вразливість введення SQL була використана злочинцем»

Крім того, пам’ятайте про рівень формальності. Хоча технічні обговорення часто включають жаргон, уникайте надто складного словника, якщо це абсолютно не потрібно. Ясність завжди повинна переважати над звучанням. Розглянемо повідомлення Slack, в якому обговорюється критичний висновок: «Привіт, команда, ми виявили потенційну проблему XSS в розділі профілю користувача. Чи може хтось переглянути логіку санітарного очищення вхідних даних? ” Прямість і використання “потенціалу” визнають необхідність подальшого дослідження, не викликаючи відразу серйозного ризику. Не бійтеся запитати про пояснення, якщо ви не впевнені щодо терміну або фрази — більшість досвідчених розробників оцінять вашу спробу ефективно спілкуватися, навіть якщо є невеликий мовний бар’ єр. Це цілком прийнятно сказати: «Чи можете ви пояснити, що означає «експлуатація нульового дня» в цьому контексті?»

Нарешті, зосередьтеся на логічному структуруванні ваших резюме. Використовуйте чіткі заголовки і пункти для розбиття складної інформації. Використання стандартних фраз, таких як « Вплив: » або « Рекомендації: », забезпечує читачеві негайний контекст. Пам’ ятайте, що добре структуроване резюме демонструє професіоналізм і дозволяє учасникам швидко зрозуміти основні проблеми і запропоновані рішення. Не припускайте, що всі розуміють технічні терміни; завжди надавайте перевагу передачі * значень * вразливості простою мовою разом з технічними деталями.