Bagaimana Cara Menulis Risk Finding yang Akan Ditindaklanjuti Bisnis?

Sebagian besar security findings mati di spreadsheet karena ditulis untuk security people lain, bukan untuk orang yang menandatangani anggaran. Jika laporan Anda mengatakan "CVE-2023-XXXX, CVSS 9.8, patch segera," Anda telah menjelaskan vulnerability, bukan risk. Bisnis tidak bertindak atas vulnerability. Ia bertindak atas konsekuensi yang bisa dibayangkan.

Mengapa severity scores saja tidak menggerakkan siapa pun

CVSS memberitahu Anda seberapa buruk flaw dalam isolasi. Ia tidak mengatakan apa pun tentang apakah flaw itu reachable, apakah asset di baliknya penting untuk revenue, atau apakah compensating controls sudah melemahkannya. Skor 9.8 pada dev box internal tanpa internet path dan tanpa sensitive data bukan percakapan yang sama dengan 7.5 pada payment gateway. Jika Anda mengurutkan findings murni berdasarkan CVSS Anda akan menghabiskan kredibilitas dengan menambal hal-hal yang tidak akan pernah dieksploitasi siapa pun, dan finding yang benar-benar penting hilang dalam noise.

Risk yang ditindaklanjuti memiliki tiga bahan: plausible path ke impact, dollar atau operational cost yang melekat pada impact itu, dan owner yang benar-benar bisa memperbaikinya. Lewatkan salah satu dari ketiga hal tersebut dan finding tersebut akan duduk di backlog.

Bangun finding di sekitar scenario, bukan scanner output

Bukan "SQL injection ditemukan pada /login endpoint," tulis scenario-nya: "Penyerang yang tidak terautentikasi dapat mengekstrak customer table lengkap, termasuk hashed passwords dan billing addresses, melalui login form. Table ini mendukung 40,000 active accounts dan database yang sama menyimpan order history yang terikat PCI scope." Sekarang pembaca tidak menguraikan vulnerability class, mereka membayangkan breach notification letter dan compliance call.

Struktur yang berguna untuk setiap finding:

• Apa yang bisa terjadi — attack path dalam bahasa plain, satu atau dua kalimat.
• Apa yang disentuhnya — specific system, specific data, specific business process.
• Berapa biayanya — downtime hours, regulatory exposure, customer trust, contractual penalties. Gunakan real numbers di mana Anda memilikinya (SLA penalty clauses, past incident costs, cyber insurance deductible).
• Apa yang diperlukan untuk memperbaikinya — effort, bukan hanya "patch it." Terkadang fix-nya adalah WAF rule hari ini dan code change sprint berikutnya.
• Siapa yang memiliki tanggung jawab fix — nama atau team, bukan "IT."

Hubungkan finding dengan sesuatu yang sudah dilacak bisnis

Setiap perusahaan memiliki metrik yang sudah diperhatikan leadership: uptime SLAs, churn, audit findings dari SOC 2 cycle terakhir, cyber insurance premiums, specific customer contract dengan security clause. Jika Anda dapat menghubungkan finding Anda dengan salah satu existing lines itu — "ini adalah class issue yang sama yang disinggung insurer kami di renewal terakhir" atau "data flow ini dalam scope untuk SOC 2 audit di Q3" — Anda tidak meminta mereka untuk peduli tentang sesuatu yang baru. Anda menunjukkan mereka threat terhadap sesuatu yang sudah mereka pertanggungjawabkan.

Ini juga tempat berbicara dengan business side membayar sebelum Anda menyelesaikan laporan. Percakapan sepuluh menit dengan finance atau ops tentang berapa sebenarnya biaya four-hour outage pada specific system mengalahkan baris "reputational damage" generik apa pun. Dapatkan angkanya, kutip, lanjutkan.

Urutkan berdasarkan exploitability dan blast radius, bukan hanya CVSS

Pendekatan prioritisasi yang dapat digunakan:

1. Apakah internet-reachable atau memerlukan internal access terlebih dahulu?
2. Apakah ada public exploit atau apakah theoretical?
3. Apakah menyentuh regulated data (PCI, PHI, PII) atau crown-jewel systems?
4. Berapa actual time dan cost untuk remediate versus cost untuk meninggalkannya?

Findings yang score tinggi pada reachability dan blast radius tetapi hanya medium pada CVSS sering layak untuk melompat antrian di atas critical-rated bug yang terkubur tiga network hops dalam di belakang jump box dengan MFA.

Tulis ask-nya, bukan hanya problem-nya

Akhiri setiap finding dengan request spesifik: budget line, change window, policy exception untuk ditutup, atau named decision yang diperlukan pada tanggal tertentu. "Kami merekomendasikan remediation" diabaikan. "Kami memerlukan four-hour maintenance window sebelum tanggal 15 untuk patch payment gateway, atau kami menerima residual risk secara tertulis" memaksa keputusan satu arah atau lainnya. Memberikan leadership opsi explicit accept-the-risk, secara tertulis, dengan nama mereka di atasnya, sering kali apa yang akhirnya membuat fix disetujui.

Jika Anda ingin melatih mengubah raw scan output menjadi findings seperti ini, kerjakan Blue Team dan Offensive segments Korra Studio bersama — menggabungkan exploitation context dengan reporting drills adalah tempat skill ini benar-benar terasah.