Як написати звіт про ризик, на який бізнес вплине?

Більшість звітів про безпеку гине в електронній таблиці, тому що вони написані для інших фахівців безпеки, а не для людини, яка підписує бюджет. Якщо ваш звіт каже «CVE-2023-XXXX, CVSS 9.8, патч негайно», ви описали вразливість, не ризик. Бізнес не реагує на вразливості. Він реагує на наслідки, які може собі уявити.

Чому оцінки тяжкості самі по собі нікого не переконують

CVSS говорить вам, наскільки серйозна вада саме по собі. Він нічого не говорить про те, чи вразлива ця вада, чи важлива система за нею для доходу, або чи вже компенсаційні контролі її послабляють. Оцінка 9.8 на внутрішній машині розробки без інтернет-доступу та без чутливих даних — це не те саме, що 7.5 на платіжному шлюзі. Якщо ви ранжуєте звіти виключно за CVSS, ви витратите своє авторитет на патчування речей, які ніхто ніколи не буде експлуатувати, і звіт, який насправді мав значення, загубиться в шумі.

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

Будуйте звіт навколо сценарію, не навколо результату сканера

Замість «знайдена SQL injection на /login endpoint», напишіть сценарій: «Неавтентифікований зловмисник може витягти повну таблицю клієнтів, включаючи хешовані паролі та адреси для виставлення рахунків, через форму входу. Ця таблиця обслуговує 40 000 активних облікових записів, і та сама база даних містить історію замовлень, пов'язану з обсягом PCI». Тепер читач не розбирає клас вразливості, він уявляє листа про порушення даних і дзвінок із питань комплайєнсу.

Корисна структура для кожного звіту:

• Що може статися — шлях атаки звичайною мовою, одне або два речення.
• На що це впливає — конкретна система, конкретні дані, конкретний бізнес-процес.
• Скільки це коштує — години простою, нормативне виконання, довіра клієнтів, договірні штрафи. Використовуйте реальні цифри, де вони у вас є (пункти штрафів SLA, витрати від попередніх інцидентів, франшиза кібербезпеки).
• Що потрібно, щоб це виправити — зусилля, не просто «зробити патч». Іноді виправлення — це правило WAF сьогодні та зміна коду в наступному спринті.
• Хто власник виправлення — ім'я або команда, не «IT».

Прив'яжіть звіт до чогось, що бізнес уже відстежує

Кожна компанія має метрики, які керівництво вже контролює: SLA доступності, коефіцієнт відтоку, звіти аудиту з останнього циклу SOC 2, премії з кібербезпеки, конкретний контракт клієнта з пунктом про безпеку. Якщо ви можете пов'язати ваш звіт з однією з цих існуючих категорій — «це той же клас проблем, який наш страховик відмітив останнього разу при поновленні» або «цей потік даних входить до сфери аудиту SOC 2 у Q3» — ви не просите їх піклуватися про щось нове. Ви показуєте їм загрозу для чогось, за що вони вже несуть відповідальність.

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

Ранжуйте за експлуатованістю та радіусом впливу, не тільки за CVSS

Працездатний підхід до пріоритизації:

1. Чи доступна вона в інтернеті, або потрібен спочатку внутрішній доступ?
2. Чи існує публічний експлойт, або це теоретичне?
3. Чи стосується вона нормативних даних (PCI, PHI, PII) або критичних систем?
4. Якою є фактична час і вартість виправлення порівняно з вартістю залишення її?

Звіти, які набирають високі оцінки за доступність і радіус впливу, але лише середні за CVSS, часто заслуговують на просування в очередь перед критичною помилкою, похованою три мережеві стрибки глибоко за jump box з MFA.

Напишіть запит, не тільки проблему

Завершіть кожен звіт конкретним запитом: бюджетною категорією, вікном змін, винятком політики для закриття, або названою необхідністю рішення на певну дату. «Ми рекомендуємо виправлення» ігнорується. «Нам потрібне чотирьохгодинне вікно обслуговування до 15-го, щоб зробити патч платіжного шлюзу, або ми приймаємо залишковий ризик письмово» змушує прийняти рішення в тому чи іншому напрямку. Надання керівництву явного варіанту прийнятися ризику письмово, з їхнім ім'ям на ньому, часто саме те, що нарешті отримує схвалення виправлення.

Якщо ви хочете практикуватися в перетворенні сирих результатів сканування на звіти такого типу, робіть через сегменти Blue Team та Offensive в Korra Studio разом — поєднання контексту експлуатації з навчанням написання звітів — це те місце, де цей навик насправді розвивається.