Cybersecurity
▲ TINGGI
Vulnerability Management: Panduan Lengkap Program Manajemen Kerentanan untuk Organisasi
14 Juli 2026 • Seraphim News • 41 mnt baca
Daftar Isi 17 bagian
Ringkasan Eksekutif
Vulnerability management mungkin terdengar seperti topik teknis yang membosankan. Tapi realitanya, ini adalah salah satu kontrol keamanan yang paling sering gagal dieksekusi — dan ironisnya, paling sering menjadi root cause insiden besar.
Logikanya sederhana: Anda tidak bisa memperbaiki kerentanan yang tidak Anda ketahui. Anda juga tidak bisa memperbaiki semuanya — ada terlalu banyak. Maka yang menentukan adalah kemampuan untuk menemukan, memprioritaskan, dan memperbaiki kerentanan yang benar-benar penting sebelum penyerang menemukannya.
Verizon 2025 DBIR mencatat eksploitasi kerentanan sebagai penyebab 14% dari semua breach — naik dari 5% di 2020. Sementara itu CISA BOD 22-01 mengungkap bahwa rata-rata organisasi butuh 55 hari untuk memperbaiki kerentanan yang sudah diketahui publik. Padahal banyak di antaranya mulai dieksploitasi dalam waktu kurang dari 7 hari setelah disclosure. Gap timing inilah yang terus dimanfaatkan oleh penyerang.
Apa Itu Vulnerability Management?
DEFINISI DAN KONSEP DASAR
VULNERABILITY MANAGEMENT ADALAH:
├── Proses SIKLIKAL dan BERKELANJUTAN
├── Mencakup identifikasi, evaluasi, treatment, dan reporting kerentanan
├── Mencakup SELURUH aset: server, endpoint, network devices, cloud, aplikasi
├── Melibatkan people, process, dan technology
└── Bagian dari broader risk management program
YANG BUKAN VULNERABILITY MANAGEMENT:
├── BUKAN sekadar vulnerability scanning (itu hanya satu tahap)
├── BUKAN one-time project (harus continuous)
├── BUKAN tanggung jawab IT saja (butuh kolaborasi lintas tim)
└── BUKAN daftar panjang kerentanan yang tidak pernah ditindaklanjuti
PERBEDAAN DENGAN KONSEP TERKAIT:
VULNERABILITY MANAGEMENT vs VULNERABILITY ASSESSMENT:
├── VM: proses END-TO-END — dari discovery hingga verification
│ ├── Asset inventory
│ ├── Scanning
│ ├── Assessment & prioritization
│ ├── Remediation
│ ├── Verification
│ └── Reporting & metrics
└── VA: HANYA identifikasi dan penilaian kerentanan
├── Scanning
├── Assessment
└── Reporting (tanpa remediation tracking)
VULNERABILITY MANAGEMENT vs PATCH MANAGEMENT:
├── VM: lebih luas dari sekadar patching
│ ├── Patch management adalah subset dari VM
│ └── VM mencakup: vulnerability scanning, konfigurasi, architecture fixes
├── PM: fokus pada instalasi update/patch
│ └── Tidak semua kerentanan bisa di-patch (zero-day, konfigurasi, dll.)
VULNERABILITY VS THREAT VS RISK:
├── Vulnerability: kelemahan yang BISA dieksploitasi
├── Threat: sesuatu yang BISA mengeksploitasi vulnerability
├── Risk: DAMPAK dari vulnerability yang dieksploitasi
└── Formula: Risk = Vulnerability x Threat x Impact
KOMPONEN VULNERABILITY MANAGEMENT:
├── People: VM team, asset owners, system administrators, CISO
├── Process: SLA, remediation workflow, exception handling, risk acceptance
├── Technology: vulnerability scanners, CMDB, ticketing, reporting dashboards
└── Governance: policies, standards, metrics, oversight
Mengapa Vulnerability Management Kritis
STATISTIK DAN JUSTIFIKASI BISNIS
ANCAMAN:
├── 20,000+ CVE baru setiap tahun (rata-rata 55 per hari di 2025)
├── 15% dari semua CVE memiliki exploit publik (PoC) dalam 48 jam
├── CISA Known Exploited Vulnerabilities (KEV): 1,200+ kerentanan
│ yang sedang aktif dieksploitasi
├── Rata-rata waktu dari CVE disclosure ke exploit availability:
│ ├── 2018: 42 hari
│ ├── 2022: 15 hari
│ └── 2025: <5 hari — "Patch Tuesday, Exploit Wednesday"
├── 60% breaches melibatkan kerentanan yang SUDAH ADA PATCH-nya
│ (tapi tidak di-patch)
└── Biaya rata-rata data breach akibat unpatched vulnerability:
$5,2 juta (IBM Cost of a Data Breach 2025)
MASALAH UMUM DI ORGANISASI:
├── Terlalu banyak kerentanan ditemukan — tidak tahu harus mulai dari mana
├── CVSS score tidak mencerminkan risiko aktual dalam konteks organisasi
├── Tim IT/Security overwhelmed — scan → report → abaikan (alert fatigue)
├── Tidak ada SLA untuk remediasi — critical vulns dibiarkan berbulan-bulan
├── Asset inventory tidak akurat — sistem tidak diketahui tidak di-scan
├── Silo antara security (menemukan) dan IT (memperbaiki)
├── Tidak ada risk acceptance process — semua "harus diperbaiki" atau
│ semuanya diabaikan
└── Fokus pada patching, mengabaikan configuration dan architecture fixes
REGULASI YANG MENSYARATKAN VULNERABILITY MANAGEMENT:
├── PCI DSS v4.0: Requirement 6.3 (keamanan aplikasi), 11.3 (scanning)
├── ISO 27001:2022: A.8.8 (Management of technical vulnerabilities)
├── NIST SP 800-53: RA-5 (Vulnerability Monitoring and Scanning)
├── CISA BOD 22-01: Known Exploited Vulnerabilities (KEV) — federal agencies
├── HIPAA Security Rule: 164.308(a)(5)
├── GDPR: Article 32 (Security of processing)
├── UU PDP Indonesia: Pasal 35-39 (Keamanan pemrosesan data)
└── SOC 2: CC7.1 (Vulnerability detection and monitoring)
Vulnerability Management Lifecycle
SIKLUS VULNERABILITY MANAGEMENT
┌──────────────────────────────────────────────────┐
│ VULNERABILITY MANAGEMENT │
│ LIFECYCLE │
│ │
│ 1. ASSET DISCOVERY │
│ Apa yang perlu dilindungi? │
│ ├── Internal & external assets │
│ ├── Cloud & on-premise │
│ └── Continuous discovery │
│ │ │
│ ▼ │
│ 2. VULNERABILITY SCANNING │
│ Apa yang rentan? │
│ ├── Authenticated scanning │
│ ├── Unauthenticated scanning │
│ └── Agent-based scanning │
│ │ │
│ ▼ │
│ 3. ASSESSMENT & PRIORITISASI │
│ Mana yang paling penting? │
│ ├── CVSS scoring │
│ ├── Threat intelligence │
│ ├── Asset criticality │
│ └── Exploitability │
│ │ │
│ ▼ │
│ 4. REMEDIATION │
│ Bagaimana memperbaikinya? │
│ ├── Patch │
│ ├── Configuration change │
│ ├── Compensating control │
│ └── Risk acceptance │
│ │ │
│ ▼ │
│ 5. VERIFICATION │
│ Apakah sudah benar-benar fixed? │
│ ├── Re-scan │
│ ├── Penetration testing │
│ └── Exception tracking │
│ │ │
│ └────────────────────┐ │
│ │ │
│ 6. REPORTING & METRICS ◄──┘ │
│ Apakah program efektif? │
└──────────────────────────────────────────────────┘
Fase 1: Asset Discovery dan Inventory
ASSET DISCOVERY — "YOU CAN'T PROTECT WHAT YOU DON'T KNOW"
TUJUAN: Mendapatkan inventory yang komprehensif dan akurat dari
semua aset yang perlu di-scan.
SUMBER DATA ASSET:
1. NETWORK-BASED DISCOVERY
├── Active scanning: Nmap, masscan, ping sweeps
├── Passive monitoring: network traffic analysis, DHCP logs, NetFlow
├── Advantages: menemukan aset yang tidak terkelola (shadow IT)
└── Limitations: hanya menemukan aset yang terhubung ke jaringan
2. AGENT-BASED DISCOVERY
├── Agent terinstal di setiap endpoint dan server
├── Melaporkan: OS, installed software, last seen, user
├── Advantages: detail informasi (installed software, services, registry)
└── Limitations: perlu instalasi agent — tidak bisa untuk semua aset
3. CLOUD API INTEGRATION
├── AWS, Azure, GCP APIs
├── Auto-discover: EC2 instances, VMs, containers, serverless
├── Advantages: cloud-native, selalu up-to-date
└── Limitations: hanya untuk aset di cloud provider tersebut
4. CMDB / ASSET MANAGEMENT SYSTEM
├── Sumber otoritatif untuk aset yang dikelola
├── ServiceNow, Jira Assets, Snipe-IT, Device42
├── Advantages: ownership, business context, criticality
└── Limitations: sering tidak akurat/tidak lengkap
5. INTEGRASI DENGAN TOOLS LAIN
├── EDR/XDR: endpoint data (user, software, last active)
├── Active Directory: domain-joined computers
├── MDM/RMM: managed mobile devices dan workstations
└── Network scanners: switch/router data (CDP, LLDP)
INFORMASI YANG HARUS DIKUMPULKAN PER ASET:
├── Hostname / IP address
├── Operating System (type, version, patch level)
├── Installed software (name, version, vendor)
├── Open ports dan running services
├── Asset owner (siapa yang bertanggung jawab)
├── Business criticality (Critical / High / Medium / Low)
├── Environment (Production / Staging / Development / Test)
├── Network zone (DMZ, Internal, PCI, Management)
├── Data classification (Public, Internal, Confidential, Restricted)
├── Last seen (kapan terakhir terdeteksi)
└── Source of discovery (scan, agent, API, manual)
TANTANGAN ASSET DISCOVERY:
├── Shadow IT: server/aplikasi yang tidak dikelola IT
├── Dynamic IP (DHCP): IP berubah sehingga sulit dilacak
├── Cloud elasticity: instans muncul dan hilang otomatis
├── Container/Serverless: hidup singkat, sulit di-scan tradisional
├── IoT/OT devices: tidak bisa diinstal agent
├── M&A: aset dari perusahaan yang diakuisisi tidak terdata
└── Orphaned assets: server lama yang tidak dimatikan
STRATEGI:
├── Gunakan MULTIPLE sources (tidak bergantung pada satu sumber)
├── Rekonsiliasi otomatis: gabungkan data dari berbagai sumber
├── Continuous discovery (bukan snapshot periodik)
├── Fokus pada coverage > accuracy di awal
└── Libatkan asset owners untuk validasi
Fase 2: Vulnerability Scanning
VULNERABILITY SCANNING — TEKNIK DAN BEST PRACTICE
JENIS SCANNING:
1. UNAUTHENTICATED SCANNING (REMOTE)
├── Scanner berjalan dari perspektif attacker eksternal
├── Tanpa kredensial — hanya yang terlihat dari jaringan
├── Menemukan: open ports, running services, banner, CVEs
├── Kelebihan: mensimulasikan external attacker perspective
└── Kekurangan: kehilangan banyak kerentanan internal
2. AUTHENTICATED SCANNING (CREDENTIALLED)
├── Scanner login ke sistem dengan kredensial
├── Menemukan: installed software patches, konfigurasi, missing updates
├── Kelebihan: jauh lebih komprehensif dan akurat (lebih sedikit false positives)
└── Kekurangan: perlu kredensial, bisa membebani sistem
3. AGENT-BASED SCANNING
├── Agent berjalan di host dan melaporkan ke central console
├── Menemukan: continuous monitoring, tanpa perlu network scan
├── Kelebihan: real-time, light-weight, bisa untuk remote workers
└── Kekurangan: perlu instalasi agent di setiap host
FREKUENSI SCANNING (REKOMENDASI):
├── External perimeter: WEEKLY (minimal) atau continuous
├── Internal network: MONTHLY (minimal), ideally WEEKLY
├── Critical servers: WEEKLY
├── After major changes: SEGERA
├── New asset onboarding: SEGERA saat terdeteksi
├── Container images: SETIAP BUILD
├── Cloud infrastructure: CONTINUOUS (agent/API-based)
└── Compliance-specific: sesuai requirement (PCI: quarterly external + internal)
BEST PRACTICE SCANNING:
1. SCANNER PLACEMENT
├── External scanner: di luar network (cloud atau dedicated VPS)
├── Internal scanners: distributed di setiap network segment
├── Cloud scanners: cloud-native atau scanner di VPC yang sama
└── Pastikan scanner bisa mencapai semua target
2. SCAN CONFIGURATION
├── Gunakan kombinasi: unauthenticated + authenticated
├── Tuning: nonaktifkan plugin yang tidak relevan (mengurangi noise)
├── Scan windows: di luar jam sibuk (mengurangi impact)
├── Exclusions: daftar sistem yang tidak boleh di-scan
│ ├── Medical devices (bisa malfunction)
│ ├── Legacy/OT systems (bisa crash)
│ └── Systems under warranty restrictions
├── Bandwidth throttling: hindari network congestion
└── Concurrent scans: batasi jumlah scan paralel
3. KREDENSIAL MANAGEMENT
├── Dedicated service account untuk scanning
├── Least privilege: cukup untuk baca, bukan admin
├── Password vault: kredensial terenkripsi (HashiCorp Vault, CyberArk)
├── Rotasi berkala
└── Monitor penggunaan: deteksi penyalahgunaan
4. POST-SCAN ACTIVITIES
├── Validasi scan completion: apakah semua target berhasil di-scan?
├── False positive analysis: identifikasi dan suppress
├── Deduplikasi: gabungkan temuan dari multiple scanners
├── Enrichment: tambahkan threat intel, exploit availability, asset context
└── Export: ke database/ticketing/dashboard
COMMON SCANNING ISSUES:
├── Scan tidak selesai (timeout, network issues)
├── Kredensial expired atau salah → authenticated scan jadi unauthenticated
├── Firewall/IDS/IPS memblokir traffic scanner → false negatives
├── Scanner tidak bisa mencapai isolated network segments
├── Overwhelming jumlah temuan → alert fatigue
├── Scanning menyebabkan service disruption (terlalu agresif)
└── Scan windows terlalu pendek untuk menyelesaikan scanning
Fase 3: Vulnerability Assessment dan Prioritisasi
PRIORITISASI KERENTANAN — TIDAK HANYA CVSS
Mengapa prioritisasi penting:
├── Rata-rata organisasi menemukan ribuan kerentanan per scan
├── Hanya ~2-5% yang benar-benar berisiko tinggi dalam konteks organisasi
├── Sumber daya remediasi terbatas — harus fokus
├── Tidak semua kerentanan memiliki exploit yang tersedia
└── Tidak semua exploit bisa mencapai sistem yang rentan
FRAMEWORK PRIORITISASI — MULTI-FACTOR:
1. CVSS SCORE (BASE SCORE)
├── 9.0 - 10.0: Critical
├── 7.0 - 8.9: High
├── 4.0 - 6.9: Medium
└── 0.1 - 3.9: Low
2. EXPLOIT MATURITY (EXPLOITABILITY)
├── Weaponized: exploit tersedia di framework (Metasploit, Cobalt Strike)
├── Functional: exploit publik (Exploit-DB, GitHub PoC)
├── Proof-of-Concept: PoC ada tapi unreliable
├── Theoretical: hanya konsep — tidak ada exploit publik
└── Sumber: CISA KEV, VulnCheck, AttackerKB, Metasploit modules
3. ASSET CRITICALITY
├── Critical (5): Crown jewels — database customer, payment systems
├── High (4): Production servers, domain controllers
├── Medium (3): Internal applications, dev servers
├── Low (2): Test environments, lab systems
└── Very Low (1): Isolated sandbox
4. EXPOSURE / ACCESSIBILITY
├── Internet-facing: langsung bisa diakses dari internet
├── DMZ: di zona perimeter
├── Internal network: hanya dari dalam
├── Segmented: diisolasi di network khusus
└── Air-gapped: tidak terhubung ke jaringan
5. ENVIRONMENTAL FACTORS
├── Compensating controls: WAF, IPS, segmentation yang mengurangi risiko
├── Data sensitivity: jenis data yang bisa diakses jika dieksploitasi
├── Business process impact: dampak terhadap proses bisnis kritis
└── Regulatory impact: denda regulasi jika data bocor
PRIORITISASI RISK SCORE:
│ Factor │ Weight │
├─────────────────────│────────│
│ CVSS Base Score │ 25% │
│ Exploit Maturity │ 30% │
│ Asset Criticality │ 25% │
│ Exposure │ 15% │
│ Environmental │ 5% │
└─────────────────────│────────│
FORMULA: Priority Score = (CVSS_Weighted) + (Exploit_Weighted) +
(Asset_Weighted) + (Exposure_Weighted) + (Env_Weighted)
THREAT INTELLIGENCE INTEGRATION:
├── CISA KEV (Known Exploited Vulnerabilities) — prioritas TERTINGGI
│ └── Ini adalah kerentanan yang SEDANG AKTIF DIKSPLOITASI — wajib di-patch
├── EPSS (Exploit Prediction Scoring System) — FIRST.org
│ ├── Probabilitas exploit dalam 30 hari ke depan
│ ├── EPSS > 0.5 (50% probability) = very high priority
│ └── EPSS < 0.01 = low priority
├── Commercial threat intel: Recorded Future, Mandiant, CrowdStrike
└── Dark web monitoring: apakah kerentanan Anda dijual di forum underground?
CONTOH KASUS PRIORITISASI:
│ Vuln │ CVSS │ Exploit │ Asset │ Exposure │ Priority │ Action │
├──────│──────│─────────│───────│──────────│──────────│────────────│
│ A │ 9.8 │ Active │ Crit │ Internet │ CRITICAL │ Patch NOW │
│ B │ 9.8 │ Active │ Med │ Internal │ HIGH │ Patch 7d │
│ C │ 9.8 │ None │ Crit │ Internet │ HIGH │ Patch 14d │
│ D │ 6.5 │ Active │ Crit │ Internet │ HIGH │ Patch 7d │
│ E │ 9.8 │ None │ Low │ Internal │ MEDIUM │ Patch 30d │
│ F │ 4.3 │ Active │ Low │ Segmented│ LOW │ Patch 90d │
└──────│──────│─────────│───────│──────────│──────────│────────────┘
Fase 4: Remediation
REMEDIASI — DARI TEMUAN KE PERBAIKAN
REMEDIASI OPTIONS (RISK TREATMENT):
1. REMEDIATE (PERBAIKI)
├── Patch/Update: instal vendor patch
│ ├── OS patches (Windows Update, yum/apt)
│ ├── Application patches (vendor updates)
│ └── Firmware updates (network devices, IoT)
├── Configuration change: ubah konfigurasi yang rentan
│ ├── Registry/GPO changes
│ ├── Security policy adjustments
│ └── Secure configuration baselines
├── Architecture change: ubah desain
│ ├── Segregasi network
│ ├── Tambahkan WAF/IPS rules
│ └── Implementasi microsegmentation
└── Upgrade/Migrasi: ganti software/versi
├── Upgrade ke versi yang didukung
├── Migrasi ke alternatif yang aman
└── Retire legacy systems
2. MITIGATE (KURANGI DAMPAK)
├── Tambahkan compensating control
├── WAF rules, IPS signatures, access restrictions
├── Network segmentation
├── Monitoring ketat
└── Digunakan ketika remediasi penuh tidak memungkinkan segera
3. ACCEPT (TERIMA RISIKO)
├── Risiko rendah — biaya remediasi > potensi dampak
├── Compensating controls yang memadai
├── Business critical system yang tidak bisa di-patch (legacy)
├── Harus ADA FORMAL RISK ACCEPTANCE:
│ ├── Justifikasi bisnis
│ ├── Dampak residual risk
│ ├── Disetujui oleh risk owner dan CISO
│ ├── Tanggal review (maksimal 3-6 bulan)
│ └── Tercatat di risk register
└── CATATAN: risk acceptance BUKAN "saya tidak mau memperbaiki"
4. AVOID (HENTIKAN)
├── Matikan service yang tidak diperlukan
├── Hapus software yang tidak digunakan
└── Decommission sistem yang sudah EOL
SLA REMEDIASI (CONTOH):
│ Severity │ Patch SLA │ Exception Allowed? │ Approval │
├──────────│─────────────│───────────────────│─────────────────│
│ Critical │ 48 jam │ Ya (CISO + CTO) │ 30 hari max │
│ High │ 14 hari │ Ya (CISO) │ 90 hari max │
│ Medium │ 30 hari │ Ya (IT Manager) │ 180 hari max │
│ Low │ 90 hari │ Ya (System Owner) │ 365 hari max │
└──────────│─────────────│───────────────────│─────────────────┘
REMEDIASI WORKFLOW:
1. ASSIGNMENT
├── Kerentanan di-assign ke asset/system owner
├── Notifikasi otomatis (email, Slack, Teams)
├── Due date berdasarkan SLA severity
└── Tracking di ticketing system (Jira, ServiceNow)
2. TESTING
├── Patch diuji di lingkungan test/staging terlebih dahulu
├── Verifikasi kompatibilitas dengan aplikasi
├── Regression testing untuk aplikasi kritis
└── Rollback plan jika patch menyebabkan masalah
3. DEPLOYMENT
├── Change management: approval untuk production changes
├── Maintenance window: di luar jam bisnis
├── Deployment tools: SCCM, Ansible, WSUS, Intune
├── Staged rollout: batch kecil dulu, lalu perluas
└── Monitoring: pantau sistem setelah deployment
4. VALIDASI
├── Konfirmasi patch terinstal (version check, registry)
├── Re-scan untuk verifikasi kerentanan hilang
├── Functional testing: aplikasi masih berfungsi?
└── Jika gagal: rollback + investigasi + retry
TANTANGAN REMEDIASI:
├── Patch merusak aplikasi produksi (kompatibilitas)
├── Tidak ada maintenance window yang cukup
├── Legacy systems: vendor sudah tidak support
├── Medical/OT systems: tidak bisa di-patch (regulasi, FDA approval)
├── Dependency chain: patch membutuhkan upgrade prerequisite
├── Resource constraints: terlalu banyak kerentanan, terlalu sedikit orang
├── Business priority: project lain dianggap lebih penting
└── Change freeze: periode di mana perubahan tidak diizinkan (liburan, audit)
Fase 5: Verification dan Monitoring
VERIFICATION — MEMASTIKAN KERENTANAN BENAR-BENAR HILANG
VERIFIKASI BERTINGKAT:
1. RE-SCAN OTOMATIS
├── Setelah remediation deadline
├── Scanner yang sama, konfigurasi yang sama
├── Verifikasi: kerentanan spesifik sudah tidak terdeteksi
├── Jika masih ada: remediation GAGAL → escalation
└── Frekuensi: otomatis setelah patch window
2. PENETRATION TESTING (UNTUK KERENTANAN KRITIS)
├── Verifikasi manual: apakah benar-benar fixed?
├── Apakah ada bypass untuk patch?
├── Apakah kerentanan serupa ada di sistem lain?
└── Cocok untuk: critical vulnerabilities, compliance requirements
3. CONFIGURATION VALIDATION
├── Verifikasi konfigurasi sesuai hardening standard
├── Automated configuration assessment (CIS-CAT, Chef InSpec)
└── Memastikan perubahan konfigurasi tidak di-revert
4. EXCEPTION MONITORING
├── Tracking risk acceptance:
│ ├── Apakah masih dalam periode yang disetujui?
│ ├── Apakah compensating controls masih efektif?
│ └── Apakah ada exploit baru yang mengubah risk profile?
├── Reminder: 2 minggu sebelum exception expiry
└── Escalation jika exception expired tanpa action
MONITORING BERKELANJUTAN:
1. NEW VULNERABILITY ALERTING
├── Subscribe ke vendor security advisories
├── NVD/NIST feeds (CVE database)
├── CISA KEV: binding operational directive alerts
├── Exploit-DB: exploit baru yang dipublikasikan
└── Threat intelligence feeds komersial
2. DRIFT DETECTION
├── Konfigurasi berubah dari baseline yang disetujui
├── Software baru terinstal tanpa approval
├── Service baru berjalan tanpa izin
└── Tools: Tripwire, OSSEC, CIS-CAT, cloud security posture management
3. CONTINUOUS SCANNING
├── Agent-based: melaporkan secara real-time/periodik
├── Cloud API polling: mendeteksi perubahan konfigurasi
├── Network monitoring: deteksi service/perangkat baru
└── Container image scanning: setiap build/commit
4. TRENDING DAN ANALISIS
├── Apakah jumlah kerentanan meningkat/menurun?
├── Apakah SLA remediasi terpenuhi?
├── Apakah ada pola kerentanan (sistem/lokasi/tim yang selalu bermasalah)?
└── Root cause analysis untuk kerentanan recurring
CVSS: Memahami Severity Scoring
CVSS (COMMON VULNERABILITY SCORING SYSTEM) v3.1
CVSS adalah framework standar untuk menilai severity kerentanan.
Dikelola oleh FIRST (Forum of Incident Response and Security Teams).
TIGA KELOMPOK METRIK:
1. BASE METRICS (Score: 0-10)
├── Exploitability Metrics:
│ ├── Attack Vector (AV): N/A/L/P
│ │ └── Network, Adjacent, Local, Physical
│ ├── Attack Complexity (AC): L/H
│ │ └── Low, High
│ ├── Privileges Required (PR): N/L/H
│ │ └── None, Low, High
│ └── User Interaction (UI): N/R
│ └── None, Required
├── Impact Metrics:
│ ├── Confidentiality (C): N/L/H
│ ├── Integrity (I): N/L/H
│ └── Availability (A): N/L/H
└── Scope (S): U/C (Unchanged, Changed)
2. TEMPORAL METRICS (optional — untuk fine-tuning)
├── Exploit Code Maturity (E): X/H/F/P/U
│ └── Not Defined, High, Functional, PoC, Unproven
├── Remediation Level (RL): X/U/W/T/O
│ └── Official Fix, Temporary Fix, Workaround, Unavailable
└── Report Confidence (RC): X/C/R/U
└── Confirmed, Reasonable, Unknown
3. ENVIRONMENTAL METRICS (optional — untuk konteks organisasi)
├── Confidentiality Requirement (CR): N/L/M/H
├── Integrity Requirement (IR): N/L/M/H
├── Availability Requirement (AR): N/L/M/H
└── Modified Base Metrics (overrides)
CONTOH PERHITUNGAN CVSS:
CVE-2026-XXXXX: SQL Injection pada aplikasi web
BASE METRICS:
├── AV: Network (N) — bisa dari internet
├── AC: Low (L) — tidak perlu kondisi khusus
├── PR: None (N) — tidak perlu login
├── UI: None (N) — tidak perlu user interaction
├── S: Changed (C) — impact ke resource di luar component
├── C: High (H)
├── I: High (H)
└── A: High (H)
CVSS Base Score: 10.0 (CRITICAL)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
TEMPORAL METRICS:
├── E: H (High — exploit tersedia di Metasploit)
├── RL: O (Official Fix — vendor sudah merilis patch)
└── RC: C (Confirmed)
CVSS Temporal Score: 8.8 (HIGH)
ENVIRONMENTAL METRICS:
├── CR: M (Medium — bukan database customer, hanya internal dashboard)
├── IR: M
├── AR: M
└── Modified AV: N → A (Adjacent — hanya bisa diakses dari VPN, bukan internet)
CVSS Environmental Score: 5.9 (MEDIUM)
PELAJARAN: CVSS Base Score 10.0 (Critical) bisa menjadi 5.9 (Medium)
dalam konteks organisasi spesifik. Inilah mengapa ENVIRONMENTAL SCORING
penting untuk prioritisasi yang realistis.
CVSS SCORE SEVERITY RANGES:
├── 0.0: None (Informational)
├── 0.1 - 3.9: Low
├── 4.0 - 6.9: Medium
├── 7.0 - 8.9: High
└── 9.0 - 10.0: Critical
CVSS v4.0 (TERBARU — DIPUBLIKASIKAN 2023):
├── Menambah metrik baru: Attack Requirements (AT)
├── Menambah: Subsequent System Impact metrics
├── Safety impact untuk OT/ICS systems
├── Supplemental metrics: Automatable, Recovery, Value Density, dll.
└── Adopsi: mulai meningkat, transisi dari v3.1
Prioritisasi di Luar CVSS
PENDEKATAN PRIORITISASI MODERN
1. CISA KNOWN EXPLOITED VULNERABILITIES (KEV)
├── Katalog kerentanan yang SEDANG AKTIF DIEKSPLOITASI
├── Wajib di-patch untuk US federal agencies (BOD 22-01)
├── Prioritas TERTINGGI — di atas semua scoring lainnya
└── Action: patch dalam SLA yang ditentukan CISA
2. EPSS (EXPLOIT PREDICTION SCORING SYSTEM)
├── Machine learning model dari FIRST.org
├── Memprediksi probabilitas exploit dalam 30 hari
├── Data points: CVE age, exploit code availability, mentions di
│ social media, vendor advisory, CVSS metrics, dll.
├── Score: 0.0 - 1.0 (0% - 100% probability)
└── EPSS > 0.5 = high priority, terlepas dari CVSS score
3. STAKEHOLDER-SPECIFIC VULNERABILITY CATEGORIZATION (SSVC)
├── Decision tree untuk prioritisasi, oleh CISA/CERT-CC
├── Decision points:
│ ├── Exploitation status: none / PoC / active
│ ├── Technical impact: partial / total
│ ├── Automatable: no / yes
│ ├── Mission impact: low / medium / high / critical
│ └── Public well-being impact: low / medium / high / critical
├── Hasil: Act / Attend / Track / Track*
└── Lebih baik untuk organisasi dengan mission tertentu (militer, kesehatan)
4. ATTACKERKB (RAPID7)
├── Community-driven exploitability assessment
├── Scoring: Very Low / Low / Medium / High / Very High
├── Berdasarkan: apakah exploit berfungsi, reliabilitas, akses yang dibutuhkan
└── Sangat berguna untuk pentester dan red team
5. VULNCHECK / GREYNOISE
├── Observasi exploit attempts di internet (honeypot network)
├── Apakah ada scanning massal untuk CVE ini?
├── Apakah exploit sedang dicoba in-the-wild?
└── Data real-time — paling akurat untuk current threats
KOMBINASI IDEAL:
├── STEP 1: Filter CISA KEV — ini wajib di-patch (compliance + real risk)
├── STEP 2: Tambahkan EPSS filter — probabilitas exploit tinggi
├── STEP 3: Tambahkan asset criticality — aset paling penting
├── STEP 4: Tambahkan exposure — internet-facing prioritaskan
└── STEP 5: Gunakan CVSS Environmental Score untuk fine-tuning
Tools Vulnerability Management
VULNERABILITY MANAGEMENT TOOLS — EKOSISTEM
VULNERABILITY SCANNERS:
ENTERPRISE (KOMPREHENSIF):
├── Tenable (Nessus, Tenable.io, Tenable.sc)
│ ├── Market leader, 180,000+ plugins
│ ├── Agent-based, network scanning, cloud connectors
│ ├── Predictive prioritization (ML-based)
│ └── Coverage: IT, OT, cloud, container, web app
├── Qualys VMDR
│ ├── Cloud-native platform
│ ├── Vulnerability Management, Detection & Response
│ ├── Continuous monitoring dengan agent
│ ├── TruRisk: risk-based prioritization
│ └── Asset inventory + CMDB sync
├── Rapid7 InsightVM (Nexpose)
│ ├── Live dashboards, real-time assessment
│ ├── Integrasi erat dengan Metasploit
│ ├── Policy compliance (CIS, DISA STIG)
│ └── Agent-based + agentless scanning
└── CrowdStrike Falcon Exposure Management
├── Dari vendor EDR terkemuka
├── Agent-based (leverage Falcon sensor)
├── Vulnerability + misconfiguration + threat intel
└── Integrated dengan Falcon platform
OPEN SOURCE:
├── OpenVAS / Greenbone
│ ├── Open source, 50,000+ NVTs
│ ├── Web-based GSA interface
│ └── Gratis — cocok untuk testing dan lab
├── Nmap + vulners scripts
│ ├── Lightweight — untuk targeted scanning
│ └── nmap --script vulners -sV target
├── Nuclei
│ ├── Template-based scanning
│ ├── Fast, customizable, CI/CD friendly
│ └── Community templates (3000+)
└── Wazuh
├── Open source XDR/SIEM
├── Vulnerability detection module
└── Integrasi dengan OpenSCAP
CLOUD-NATIVE:
├── AWS Inspector
├── Azure Security Center / Defender for Cloud
├── GCP Security Command Center
├── Prisma Cloud (Palo Alto)
├── Wiz
└── Orca Security
CONTAINER/KUBERNETES:
├── Trivy (Aqua) — open source
├── Snyk
├── Anchore
├── Clair
├── Sysdig Secure
└── Aqua Security
WEB APPLICATION:
├── Burp Suite Enterprise
├── Acunetix
├── Netsparker (Invicti)
├── OWASP ZAP
└── Qualys WAS
PATCH MANAGEMENT:
├── Microsoft: SCCM, WSUS, Intune, Windows Update for Business
├── Linux: Red Hat Satellite, SUSE Manager, Landscape (Ubuntu)
├── Cross-platform: Ivanti, ManageEngine, Automox, Tanium
├── Cloud: AWS Systems Manager Patch Manager, Azure Update Management
└── Third-party apps: Chocolatey, Ninite Pro, Patch My PC
VULNERABILITY MANAGEMENT PLATFORMS (BEYOND SCANNING):
├── ServiceNow Vulnerability Response
│ ├── Integrasi dengan scanner utama
│ ├── Ticketing native, CMDB integration
│ └── Workflow, SLA, dashboard
├── Kenna Security (Cisco)
│ ├── Risk-based prioritization
│ ├── Aggregasi data dari 15+ scanners
│ └── ML-based prediction
├── Brinqa
│ ├── Risk analytics platform
│ ├── Mencakup VM, app sec, cloud, compliance
│ └── Business context integration
└── Nucleus Security
├── Unified vulnerability management
├── Aggregation + prioritization + orchestration
└── Connector untuk 100+ tools
Membangun Program Vulnerability Management
MEMBANGUN PROGRAM DARI NOL
FASE 1: FOUNDATION (0-3 BULAN)
1. MENETAPKAN GOVERNANCE
├── Vulnerability Management Policy:
│ ├── Scope: aset yang dicakup
│ ├── Frekuensi scanning
│ ├── SLA remediasi per severity
│ ├── Risk acceptance procedure
│ └── Roles and responsibilities
├── Vulnerability Management Standard:
│ ├── Scanner configuration
│ ├── Credential management
│ ├── Scan windows
│ └── Exclusions management
└── Vulnerability Management Procedure:
├── Step-by-step: scan → assess → remediate → verify
├── Escalation procedure
└── Exception handling
2. MEMILIH DAN DEPLOY TOOLS
├── Vulnerability scanner: pilih satu untuk memulai
├── Asset discovery: mulailah dengan yang sudah diketahui
├── Ticketing system: Jira, ServiceNow, atau built-in
├── Dashboard: untuk visibility
└── Integrasi awal: scanner → ticketing
3. INITIAL SCAN
├── Scan seluruh scope (mungkin terbatas di awal)
├── Expect: ribuan temuan — JANGAN PANIK
├── Focus: internet-facing + critical assets
└── Quick wins: patch yang mudah dan aman
FASE 2: MATURATION (3-12 BULAN)
1. ASSET MANAGEMENT
├── Bangun inventory yang akurat
├── Klasifikasi asset (criticality, owner, environment)
├── Integrasikan CMDB dengan scanner
└── Coverage tracking: % aset yang berhasil di-scan
2. PRIORITISASI
├── Implementasikan CVSS + threat intel + asset context
├── Mulai gunakan EPSS untuk prediksi exploit
├── Filter CISA KEV — wajib di-patch
└── Kembangkan risk scoring model internal
3. REMEDIASI WORKFLOW
├── Automated ticket creation dari scanner
├── Assign ke asset owners
├── SLA enforcement: reminder, escalation
├── Patch testing process
└── Change management integration
4. METRICS DAN REPORTING
├── Mulai tracking KPI (lihat section berikutnya)
├── Monthly vulnerability report
├── Executive dashboard
└── Trend analysis
FASE 3: OPTIMIZATION (12-24 BULAN)
1. CONTINUOUS SCANNING
├── Agent-based untuk real-time monitoring
├── Cloud API integration untuk continuous detection
├── Container image scanning di CI/CD
└── Drift detection untuk konfigurasi
2. AUTOMATION
├── Auto-remediation untuk low-risk patches
├── Automated false positive suppression
├── Orchestration: scanner → ticketing → patching → verification
└── SOAR playbook untuk critical vulnerabilities
3. ADVANCED ANALYTICS
├── Predictive analytics: kerentanan mana yang akan jadi masalah?
├── Root cause analysis: mengapa kerentanan terjadi?
├── Attack path analysis: gabungkan kerentanan untuk simulated attack
└── Business impact modeling
4. INTEGRATION ECOSYSTEM
├── ITSM (ticketing, change management, CMDB)
├── SIEM/SOAR
├── Patch management
├── Threat intelligence
├── Penetration testing
├── Red team / purple team
└── Compliance reporting
KPI dan Metrics Program
METRICS UNTUK MENGUKUR EFEKTIVITAS PROGRAM
SECURITY POSTURE METRICS:
1. MEAN TIME TO REMEDIATE (MTTR)
├── Rata-rata waktu dari discovery ke remediation
├── Per severity: MTTR Critical, High, Medium, Low
├── Target:
│ ├── Critical: <48 jam
│ ├── High: <14 hari
│ ├── Medium: <30 hari
│ └── Low: <90 hari
└── Trend: MTTR harus MENURUN dari waktu ke waktu
2. VULNERABILITY DENSITY
├── Jumlah kerentanan per aset
├── Per severity: berapa banyak Critical/High per 100 aset?
└── Trend: density harus MENURUN
3. SCAN COVERAGE
├── % aset yang berhasil di-scan dalam periode
├── Target: >95% (authenticated scan)
└── Unscanned assets: harus ada justifikasi
4. REMEDIATION RATE
├── % kerentanan yang di-remediate dalam SLA
├── Target: >90% untuk Critical, >80% untuk High
└── Backlog: kerentanan yang melebihi SLA
5. EXCEPTION METRICS
├── Jumlah active exceptions
├── % aset dengan active exceptions
├── Average exception age
└── Expired exceptions tanpa review
6. VULNERABILITY AGE
├── Rata-rata usia kerentanan yang masih terbuka
├── Maksimum usia kerentanan tertua
└── Aging: semakin pendek semakin baik
PROGRAM MATURITY METRICS:
1. FALSE POSITIVE RATE
├── % temuan yang merupakan false positive
├── Target: <5% (authenticated scan)
└── Tinggi → scanner perlu tuning
2. TIME TO DETECT (TTD)
├── Waktu dari vulnerability disclosure ke detection di environment
├── Target: <24 jam untuk critical CVE
└── Integrasi: threat intel feeds → scanner
3. PATCH TESTING TIME
├── Waktu dari patch availability ke deployment approval
└── Bottleneck sering di sini — testing terlalu lama
4. REMEDIATION ATTEMPT SUCCESS RATE
├── % remediation attempt yang berhasil (diverifikasi re-scan)
├── Target: >95%
└── Rendah → patch deployment process bermasalah
EXECUTIVE DASHBOARD:
│ KPI │ Current │ Target │ Trend │ Status │
├──────────────────────│─────────│────────│───────│─────────│
│ Critical vulns open │ 3 │ 0 │ ↓ │ YELLOW │
│ High vulns open │ 27 │ <10 │ ↓ │ YELLOW │
│ MTTR Critical │ 36 jam │ <48 jam│ → │ GREEN │
│ MTTR High │ 11 hari │ <14 hr │ ↓ │ GREEN │
│ Scan coverage │ 94% │ >95% │ ↑ │ YELLOW │
│ Remediation rate │ 92% │ >90% │ ↑ │ GREEN │
│ Active exceptions │ 15 │ <20 │ ↓ │ GREEN │
│ Expired exceptions │ 3 │ 0 │ ↑ │ RED │
│ False positive rate │ 4.2% │ <5% │ → │ GREEN │
└──────────────────────│─────────│────────│───────│─────────┘
Continuous Vulnerability Management
DARI PERIODIC SCANNING KE CONTINUOUS VM
MENGAPA PERIODIC SCANNING TIDAK CUKUP:
├── Kerentanan baru muncul setiap hari (55+ CVE/hari)
├── Aset berubah terus: patch, konfigurasi, software baru
├── Scanning bulanan = visibility gap 30 hari
├── Attacker bisa exploit dalam <5 hari setelah disclosure
└── Compliance auditor juga mulai mensyaratkan continuous monitoring
PILAR CONTINUOUS VM:
1. CONTINUOUS ASSET DISCOVERY
├── Network traffic analysis (passive)
├── Cloud API polling (setiap jam)
├── DHCP/DNS log monitoring
├── Agent heartbeat
└── New asset detected → auto-scan triggered
2. CONTINUOUS VULNERABILITY DETECTION
├── Agent-based: melaporkan setiap perubahan
├── Cloud security posture management (CSPM)
├── Container registry scanning
├── CI/CD pipeline integration
└── Network IDS/IPS: deteksi exploit attempts
3. CONTINUOUS THREAT INTELLIGENCE
├── Real-time feed: NVD, CISA KEV, vendor advisories
├── EPSS daily updates
├── Exploit availability monitoring
└── Trigger: CVE pub → cek environment → alert jika ada
4. CONTINUOUS REMEDIATION
├── Auto-patching untuk low-risk, well-tested patches
├── Automated ticketing untuk yang memerlukan approval
├── Drift remediation: kembalikan konfigurasi ke baseline
└── SOAR playbook untuk critical threats
5. CONTINUOUS VERIFICATION
├── Agent: konfirmasi patch terinstal real-time
├── Continuous compliance scanning (CIS benchmarks)
├── Penetration testing as a service (PTaaS)
└── Bug bounty: continuous external testing oleh crowd
IMPLEMENTASI BERTAHAP:
PHASE 1: Basic Continuous
├── Agent di semua endpoint → data real-time
├── Weekly network scan (turun dari monthly)
├── Daily threat intel feed ingestion
└── Alerting: critical CVE yang mempengaruhi environment
PHASE 2: Intermediate
├── Cloud API integration (daily → hourly)
├── Container image scanning di setiap build
├── Automated patch deployment untuk low-risk
├── Configuration drift detection (daily)
└── Dashboard real-time
PHASE 3: Advanced
├── CSPM untuk continuous cloud assessment
├── CI/CD security gates (failed scan = blocked deployment)
├── SOAR automation untuk critical vulnerability response
├── Attack path analysis continuous
└── Predictive risk scoring (AI/ML)
Integrasi dengan Proses Lain
VULNERABILITY MANAGEMENT DALAM EKOSISTEM KEAMANAN
VM + INCIDENT RESPONSE:
├── VM menyediakan visibility: di mana kerentanan yang sama di seluruh environment
├── IR menemukan root cause: kerentanan yang tidak terdeteksi VM → perbaiki VM program
├── Shared data: exploit technique, affected systems
└── Feedback loop: setiap insiden → update VM priorities dan scanning
VM + PATCH MANAGEMENT:
├── VM: "apa yang harus di-patch" (prioritas)
├── PM: "bagaimana melakukan patching" (eksekusi)
├── Integrasi: VM → ticketing → PM deployment → VM verification
├── VM mengukur PM effectiveness (patch coverage, timeliness)
└── PM menyediakan data: patch yang terinstal → VM mengurangi false positives
VM + THREAT INTELLIGENCE:
├── TI: "kerentanan mana yang sedang dieksploitasi"
├── VM: "apakah kita punya kerentanan itu"
├── Integrasi: CISA KEV → auto-escalate → percepat SLA
├── TI enrichment: exploit availability, campaign context
└── TI feedback: environment-specific threat data untuk prioritisasi
VM + PENETRATION TESTING:
├── PT memvalidasi temuan VM (apakah benar-benar exploitable?)
├── PT menemukan kerentanan yang terlewat VM (false negative)
├── VM memperbaiki prioritisasi berdasarkan PT findings
├── PT mensimulasikan attack path dari multiple VM findings
└── Combined reporting: VM coverage + PT validation = assurance
VM + DEVSECOPS:
├── Shift-left: VM di pipeline CI/CD
├── Container image scanning sebelum deployment
├── IaC (Infrastructure as Code) scanning: Terraform, CloudFormation
├── Pre-production scanning (staging environment)
├── Safety gates: critical vuln = blocked deployment
└── Developer feedback: kerentanan + cara memperbaikinya
VM + COMPLIANCE:
├── ISO 27001: A.8.8 (Management of technical vulnerabilities)
├── PCI DSS: Requirement 6, 11
├── SOC 2: CC7.1
├── VM reports = compliance evidence
├── Automated compliance scanning (CIS benchmarks)
└── Policy compliance: apakah kontrol sudah sesuai kebijakan?
Kesimpulan
Vulnerability management adalah fondasi yang menentukan seberapa cepat organisasi bisa merespons ancaman. Tanpa program yang berjalan, tim keamanan pada dasarnya beroperasi dalam kegelapan — berharap tidak ada yang menemukan celah yang tidak mereka ketahui.
Beberapa prinsip yang membedakan program VM yang efektif dari yang hanya formalitas:
Asset discovery lebih dulu. Inventory yang tidak akurat adalah akar dari semua masalah VM. Shadow IT, server development yang terlupakan, cloud instance yang tidak terpantau — semua ini adalah blind spot yang tidak akan muncul di scan manapun sampai seseorang sengaja mencarinya.
Prioritisasi berbasis risiko, bukan CVSS semata. CVSS base score adalah titik awal yang berguna, tapi tidak cukup. Gabungkan dengan exploit maturity (CISA KEV, EPSS), asset criticality, dan konteks organisasi. Kerentanan CVSS 10.0 di server development yang terisolasi tidak seprioritas CVSS 7.0 di database pelanggan yang terekspos internet.
SLA tanpa enforcement hanya ilusi. Tetapkan tenggat waktu yang realistis: 48 jam untuk critical, 14 hari untuk high, 30 hari untuk medium. Tapi SLA tidak berguna tanpa mekanisme eskalasi. Jika pemilik sistem tidak merespons, harus ada konsekuensi yang jelas.
Automasi di mana-mana. Scanning, ticketing, enrichment, bahkan patching untuk low-risk — otomatisasi sebanyak mungkin. Tim manusia harus fokus pada triage, keputusan exception, dan investigasi kasus-kasus kompleks.
Verifikasi jangan pernah dilewatkan. Patch yang “sudah di-deploy” tidak sama dengan kerentanan yang “sudah diperbaiki.” Rescan atau penetration test selalu diperlukan untuk memastikan fix benar-benar bekerja.
Continuous, bukan periodik. Dengan 55+ CVE baru per hari dan exploit timeline yang terus menyusut, scanning bulanan sudah tidak relevan. Continuous visibility adalah harga masuk untuk pertahanan yang kredibel.
Organisasi yang menjalankan vulnerability management dengan disiplin akan selalu selangkah lebih maju dari penyerang yang mengandalkan unpatched systems sebagai entry point.
Sumber Referensi: NIST SP 800-40 Rev 4 (Guide to Enterprise Patch Management Planning), CISA Binding Operational Directive (BOD) 22-01 (Known Exploited Vulnerabilities), FIRST CVSS v3.1 Specification, FIRST EPSS Model Documentation, ISO 27001:2022 Annex A.8.8, PCI DSS v4.0 Requirements 6 & 11, CISA Stakeholder-Specific Vulnerability Categorization (SSVC) Guide, MITRE ATT&CK Enterprise — Exploit Public-Facing Application (T1190), Verizon Data Breach Investigations Report (DBIR) 2025.
