How to Present Security Findings in English

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

Ключові фрази

** Відкривається вікно безпеки: **

• «Ми виявили вразливість SQL-втручання в кінцевій точці автентифікації користувача»
• «Під час нашого огляду, ми виявили, що сеансові токени не анульовані при виході»
• «Аудит виявив, що конфіденційні дані записуються в звичайному тексті»
• «Ми знайшли неправильну конфігурацію в політиці S3 bucket, яка виставляє записи клієнтів»

Опис тяжкості та впливу:

• Цей фільм отримав критичний рейтинг з CVSS 9.8
• «Радиус вибуху включає всіх автентифікованих користувачів — приблизно 40 000 облікових записів»
• «Поверхня атаки включає будь-яку неавтентифіковану кінцеву точку HTTP на публічному API.»
• Ця вразливість може дозволити атакуючому досягти віддаленого виконання коду
• Потенційний вплив - це ексфільтрація даних з персонально ідентифікованої інформації

** Рекомендуємо усунення: **

• «Для того, щоб виправити це, я рекомендую параметризувати всі запити бази даних.»
• «Відновлення включає негайне обертання відкритих реквізитів»
• Як короткострокове зменшення, ми пропонуємо заблокувати зачеплену кінцеву точку в WAF. ”
• Рекомендований час відновлення для критичних результатів становить від 24 до 72 годин

Мова ескалації:

• “Учитывая серьезность ситуации, я передаю это команде безопасности.”
• Це вимагає негайної уваги з боку інженерного менеджера
• “Я рекомендую зібрати виклик реагування на інцидент протягом години.”
• «Ми повинні повідомити нашого офіцера з захисту даних, враховуючи потенційні наслідки GDPR»

Як це використовувати на практиці

Звіти про безпеку відповідають стандартній структурі: ** знайдення → тяжкість → докази → вплив → усунення → часова шкала **. Якщо ви представили результати у такому порядку, навіть нетехнічні учасники можуть слідувати логіці і приймати обґрунтовані рішення.

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

** Оцінка CVSS ** (Система оцінки загальної вразливості) надає результатам числову оцінку від 0, 0 до 10, 0. При представленні результату завжди пояснюйте, що це означає: «Рейтинг CVSS становить 8,1, що класифікує це як високу серйозність, в першу чергу тому, що його можна використовувати віддалено і не вимагає автентифікації»

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

Приклад розмови

Олена (інженер з безпеки): “Я б хотіла розповісти вам про результати аудиту, проведеного минулого тижня. Ми виявили критичну вразливість у потоці скасування пароля. Поверхня атаки включає в себе публічний API скидання, який приймає надані користувачем токени без обмеження швидкості. Радіус атаки буде повним захопленням облікового запису будь- якого користувача, адреса електронної пошти якого відома атакуючому. Рейтинг CVSS становить 9.1»

** Розробник: ** « Як швидко нам потрібно це виправити? »

“Учитывая серьезность, восстановление должно произойти в течение 24 часов. Щоб виправити це, я рекомендую додати обмеження швидкості на рівні API- шлюзів і впровадити 15- хвилинний термін дії токена. Як негайне зменшення, ми можемо вимкнути кінцеву точку доки не буде розгорнуто виправлення. Я передаю це інженерному менеджеру зараз»

Практичні поради

1. ** Переписати резюме CVE: ** Знайдіть публічний запис CVE у Національній базі даних уразливостей (nvd. nist. gov) і перепишіть технічний опис власними словами, використовуючи фрази з цього повідомлення. Це вправляє перекладати густу жаргонну безпеку на чітку професійну англійську.

2. ** Вправи з використання шкалою ступенів тяжкості: ** Візьміть чотири виявлені проблеми безпеки різних ступенів тяжкості і напишіть про кожну з них речення, яке починається з відповідної терміни — « Це критичне і вимагає…» і закінчується « Це рекомендація щодо посилення безпеки з низьким пріоритетом ». Зауважте, як змінюється ваш тон і вибір дієслова за шкалою тяжкості.

3. ** Імітація брифінгу для зацікавлених осіб: ** Представте вигаданий випадок порушення безпеки другу або колегі, який грає роль нетехнічного менеджера. Практикуйте використання еквівалентів простої мови разом з технічними термінами: “Поверхня атаки - тобто, точки входу, які може використовувати нападник - включає…”

Наприклад, англійська мова має особливий лексичний склад для не-індіанців

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

Одним з найчастіших каменів спотикання є використання таких термінів, як «вразливий» проти «експлуатабельний». Хоча обидва вони описують слабкість системи, «вразливий» зазвичай вважається більш нейтральним і професійним. Сказати « Цей компонент має уразливість до атаки X » набагато менш звинувачувальніше, ніж відразу сказати « Цей код можна використати! » Правильним правилом є зосередитися на описі * потенціалу * нанесення шкоди, а не відразу вказати на зловмисні наміри. Розглянемо це повідомлення Slack: « Гей, команда, я виявив потенційну проблему з потоком автентифікації — зокрема, неперевірене поле вводу може призвести до розкриття інформації, якщо його не обробляти належним чином. » У мові уникається прямих звинувачень і зосереджено увагу на * можливості * проблеми, що дозволяє обговорювати і спільно вирішувати проблеми.

Іншою областю, яка вимагає ретельної уваги, є опис рівнів тяжкості. Просто сказати «Високий» або «Нізкий» може бути неоднозначним. Замість цього, використовуйте більш описові фрази, наприклад, « Ця вразливість становить критичний ризик для конфіденційності даних користувача через … » або « Потенційний вплив цієї проблеми обмежено [особливим компонентом] і на даний момент не становить значної загрози ». Використання кількісних термінів, коли це можливо, наприклад, оцінювання кількості користувачів, яких стосується проблема, або потенційних фінансових втрат, додає довіри. Наприклад, у описі завантаження запиту на виправлення ви можете написати: « Розв’ язано: Логіку перевірки введення було посилено, щоб зменшити ризик атак за допомогою введення SQL. Ця зміна вирішує вразливість, яка могла б дозволити атакуючому потенційно покласти на карту конфіденційні дані користувачів, збережені в базі даних - що впливає приблизно на 10% наших активних користувачів”

Нарешті, пам’ ятайте про важливість чітких пунктів дій. Фрази на кшталт «Будь ласка, виправте» можуть здатися вимогливими. Замість цього, запитайте конструктивно: «Ми рекомендуємо реалізувати параметризовані запити, щоб запобігти вразливостям введення SQL» або «Щоб вирішити цю проблему, будь ласка, присвоєйте пріоритет оновленню бібліотеки залежностей до версії X». Використання фраз на кшталт «зменшення» і «розв’язання» демонструє професійне розуміння процесу.