CVSS 9.0 Bukan Berarti Bahaya: Cara Tim Keamanan Salah Nyangkul Dampak Kerentanan

Tahun lalu, tim keamanan perusahaan saya menemukan celah dengan skor CVSS 9.8 di sebuah aplikasi internal. Tim langsung panik, CISO ditanyai oleh CEO, dan budget insiden response dipotong karena “siapa yang bilang ini darurat?”

Kenapa? Karena kami cuma menunjukkan angka. Kami tidak menerjemahkan what happens next ke bahasa yang dipahami oleh orang bisnis.

Artikel ini untukmu jika kamu seorang security engineer, tim SOC, atau IT manager yang sering terjebak di situasi ini. Kamu perlu meyakinkan stakeholder bahwa sebuah vulnerability layak dapat perhatian – bukan dengan menunjukkan CVSS, tapi dengan menjelaskan dampak dan risikonya secara terukur.

Kenapa CVSS Saja Tidak Cukup?

CVSS memberikan skor universal untuk mengukur severity kerentanan secara teknis. Tapi skor ini hanya menggambarkan potensi dampak di lingkungan ideal – asumsi attacker memiliki akses, aplikasi sedang berjalan, dan tidak ada kontrol mitigasi.

Dalam dunia nyata, asumsi itu jarang terpenuhi.

Sebuah SQL injection dengan CVSS 9.8 di sebuah halaman admin yang tidak ada satu orang pun yang mengaksesnya memiliki risiko jauh lebih rendah daripada XSS dengan CVSS 5.4 di halaman login yang diakses 10.000 orang per hari.

Jika kamu cuma mengandalkan CVSS sebagai satu-satunya metrik, kamu akan salah prioritas patch, salah alokasi tim, dan salah menyampaikan urgency ke manajemen.

Framework “So What Test”: Cara Menjawab Dampak Kerentanan dengan Jelas

Ini adalah framework yang saya pakai sendiri di tim saya. Cukup sederhana, tapi sangat efektif untuk mengubah laporan teknis menjadi argumen bisnis yang sulit ditolak.

Step 1: Identify the Attack Vector

Tanyakan: bagaimana attacker bisa memanfaatkan kerentanan ini?

• Apakah vulnerability ini internet-facing? Atau hanya bisa diakses dari internal network?
• Apakah attacker perlu autentikasi? Atau bisa eksploitasi tanpa kredensial?
• Apakah ada PoC (Proof of Concept) yang sudah beredar publik?

Semakin mudah akses attacker, semakin tinggi risiko. Sebuah RCE di REST API yang terbuka ke publik jauh lebih berbahaya daripada RCE di layanan yang hanya bisa diakses dari server internal.

Step 2: Map the Attack Impact

Tanyakan: apa yang terjadi setelah kerentanan ini dieksploitasi?

Ini bagian paling krusial dari impact assessment. Kamu harus memetakan outcome yang nyata:

• Arbitrary Code Execution: Attacker bisa menjalankan kode sembarangan di server. Ini artinya server di bawah kendali penuh mereka. Mereka bisa install malware, buat backdoor, atau gunakan server sebagai pivot ke jaringan lain.
• Data Exfiltration: Data sensitif dicuri dan dibawa keluar jaringan. Customer PII, credential database, trade secret — semua bisa hilang dalam hitungan menit.
• System Compromise: Sistem tidak lagi reliable. Attacker bisa memanipulasi data, menonaktifkan service, atau mengubah konfigurasi keamanan.
• Lateral Movement: Dari satu server terinfeksi, attacker berpindah ke server lain, database lain, bahkan ke AD controller jika ada koneksi yang memungkinkan.

Ini bukan daftar teoretis. Ini adalah skenario yang sudah terjadi berkali-kali di industri.

Step 3: Estimate the Business Impact

Tanyakan: berapa besar kerugian jika semua impact di atas terjadi?

Jangan jawab dalam teknis. Jawab dalam bahasa bisnis:

• “Jika database customer dibobol, kami menghadapi risiko denda GDPR sebesar 4% dari revenue global.”
• “Jika server di bawah kendali attacker, downtime per jam bisa menghabiskan 500 juta rupiah.”
• “Jika lateral movement terjadi ke Active Directory, seluruh domain bisa dikompromi dalam 30 menit.”

Stakeholder tidak peduli CVSS. Tapi mereka sangat peduli angka rupiah dan risiko regulasi.

Studi Kasus Nyata: 4 Kerentanan, 4 Risiko Berbeda

Mari kita lihat bagaimana framework ini bekerja dalam praktik nyata.

Kerentanan A: RCE di API Gateway (CVSS 9.1)

Vector: Internet-facing, no auth required, PoC publik tersedia.

Impact: Attacker dapat akses penuh ke API layer, bisa inject payload ke semua backend service, dan lateral movement ke database.

Business Impact: Semua data customer berpotensi dicuri. Risiko denda regulasi + reputasi.

Risiko: KRITIS. Patch segera.

Kerentanan B: SQL Injection di Sistem Legacy Internal (CVSS 8.6)

Vector: Internal network only, butuh jaringan internal untuk akses.

Impact: Full read access ke database legacy, tapi database itu tidak berisi data PII.

Business Impact: Data operasional ter泄露, tapi tidak ada exposure customer data.

Risiko: SEDANG. Patch dalam 30 hari.

Kerentanan C: Missing MFA di Admin Dashboard (CVSS 5.3)

Vector: Internet-facing, butuh credential valid untuk masuk.

Impact: Jika credential breached (credential stuffing, phishing), attacker dapat akses admin.

Business Impact: Admin access = full control. Satu password bocor bisa jadi disaster.

Risiko: TINGGI. MFA wajib dipasang segera.

Kerentanan D: Information Disclosure di Log File (CVSS 4.2)

Vector: Internal only, butuh akses ke server fisik.

Impact: Log mengandung session ID, tapi tidak ada kredensial atau PII.

Business Impact: Minimal. Log bisa dirotasi dan tidak ada exposure signifikan.

Risiko: RENDAH. Monitoring cukup, patch nanti.

Lihat? Skor CVSS tertinggi tidak selalu risiko tertinggi. Kerentanan C dengan CVSS 5.3 memiliki risiko bisnis yang jauh lebih besar daripada Kerentanan B dengan CVSS 8.6.

Cara Menjual Impact Assessment ke Stakeholder Non-Teknis

Ini bagian yang paling sering dilewatkan tim keamanan. Kamu bisa punya assessment paling sempurna di dunia, tapi kalau kamu tidak bisa menjelaskannya ke orang yang memegang budget, semua percuma.

Gunakan format ini saat presentasi ke manajemen:

1. Apakah ini internet-facing? Ya / Tidak. Ini jawaban pertama yang mereka butuhkan.
2. Apa yang bisa dilakukan attacker jika berhasil eksploitasi? Jelaskan dalam bahasa bisnis: akses data, kendali sistem, downtime.
3. Apakah ada data customer yang berisiko? Ya / Tidak. Jika ya, sebutkan jenis datanya.
4. Apakah ada regulasi yang terkait? GDPR, PDP, PCI-DSS, HIPAA — sebutkan yang relevan.
5. Bagaimana mitigasinya? Patch, WAF rule, virtual patching, atau isolasi network.
6. Berapa lama waktu yang dibutuhkan untuk memperbaiki? Estimasi jam, bukan hari.

Jangan kirim spreadsheet dengan kolom CVSS. Kirim satu halaman dengan pertanyaan di atas. Itu jauh lebih bisa dipahami.

Tools untuk Support Impact Assessment

Kamu tidak perlu menilai semua ini dengan tangan telanjang. Beberapa tools yang membantu:

• CVE Details: Cek apakah CVE sedang dieksploitasi di wild dan apakah ada PoC publik.
• NIST NVD: Mendapatkan informasi detail termasuk affected products dan CVSS vector string.
• EPSS (Exploit Prediction Scoring System): Memberikan probabilitas bahwa sebuah CVE akan dieksploitasi di wild dalam 30 hari ke depan.
• CISA KEV (Known Exploited Vulnerabilities): Daftar CVE yang sudah dikonfirmasi sedang dieksploitasi oleh threat actor.

Kombinasikan CVSS, EPSS, dan status KEV untuk mendapatkan gambaran risiko yang jauh lebih akurat daripada CVSS saja.

FAQ

Apa itu Impact & Risk Assessment dalam konteks keamanan?

Impact & Risk Assessment adalah proses yang menilai dampak teknis dan bisnis dari sebuah kerentanan. Tujuannya bukan hanya menentukan apakah celah itu berbahaya, tapi juga memetakan outcome nyata jika celah tersebut dieksploitasi — seperti arbitrary code execution, data exfiltration, atau system compromise — sehingga tim keamanan bisa memberikan rekomendasi yang bisa dipahami oleh stakeholder.

Berapa lama sebuah kerentanan kritis harus ditangani?

Sekadar CVSS tinggi belum menentukan deadline. Tapi jika kerentanan itu internet-facing, ada PoC publik, dan bisa menyebabkan data exfiltration atau system compromise, patch seharusnya dilakukan dalam 24 hingga 72 jam. Jika ada mitigasi lain seperti WAF atau virtual patching, kamu bisa mendapat jendela waktu tambahan, tapi tidak boleh menunda lebih dari seminggu untuk kasus kritis.

Bagaimana cara membedakan Impact dan Risk?

Impact adalah “apa yang terjadi jika kerentanan dieksploitasi” — contohnya: attacker dapat execute kode sembarangan, data dicuri, atau sistem dikompromi. Risk adalah “seberapa mungkin dan seberapa besar dampaknya di lingkunganmu” — yang menggabungkan impact dengan faktor seperti exposure, exploitability, dan business context. Impact objektif, risk kontekstual.

Kesimpulan

CVSS 9.0 bukan berarti kamu harus panik. CVSS 3.0 bukan berarti kamu bisa mengabaikan. Impact & Risk Assessment memberi kerangka untuk menilai kerentanan secara holistik – dari attack vector, ke impact teknis, ke dampak bisnis yang bisa dikuantifikasi.

Tanpa assessment ini, tim keamanan bekerja berdasarkan angka tanpa konteks. Dengan assessment ini, kamu punya argumen bisnis yang kuat untuk mendapatkan budget, resources, dan prioritas dari stakeholder yang memegang keputusan.

Selanjutnya, pelajari juga bagaimana cara memetakan CVE menjadi bukti compliance untuk auditor, serta bagaimana cara berkomunikasi dengan CISO dan eksekutif tentang risiko kerentanan secara efektif.