Patch Management Berbasis Risiko: Panduan untuk Tim IT

Patch management berbasis risiko berarti Anda menentukan urutan dan tenggat penambalan berdasarkan seberapa besar kemungkinan dan dampak sebuah celah bagi organisasi Anda, bukan sekadar mengikuti skor tertinggi atau jadwal bulanan. Panduan ini ditujukan bagi tim IT di Indonesia, lengkap dengan contoh tingkat SLA dan pelajaran dari kasus PHP2Shell per 29 Oktober 2026.

Mengapa patch management tradisional tidak cukup

Ribuan CVE terbit tiap bulan, sementara tim IT punya jam kerja dan jendela pemeliharaan yang terbatas. Jika semua celah berskor tinggi dianggap sama mendesak, tim akan kewalahan dan celah yang benar-benar diserang tetap tertinggal. Sebaliknya, siklus bulanan yang kaku terlalu lambat bagi celah yang dieksploitasi dalam hitungan jam. Pendekatan berbasis risiko memadukan beberapa sinyal: apakah celah sudah dieksploitasi, seberapa besar kemungkinannya, seberapa terpapar aset Anda, dan seberapa penting aset itu.

Contohnya PHP2Shell. Menurut Help Net Security, honeypot Amazon Threat Intelligence mencatat upaya eksploitasi pada 17 Oktober 2026, empat hari sebelum pengungkapan publik, dan patch (PHP 8.5.12, 8.4.27, 8.3.36, dan 8.2.35) dirilis bersamaan dengan pengungkapan itu. CISA memasukkan celah ini ke KEV pada 26 Oktober dengan tenggat 29 Oktober bagi lembaga federal AS, yaitu tiga hari. Siklus patch 30 hari tidak akan relevan di sini. Detail celahnya ada di artikel PHP2Shell.

Enam langkah proses patch management

1. Inventaris aset. Catat server, aplikasi, perangkat jaringan, container, dan dependensi beserta versi, pemilik, lokasi, dan apakah menghadap internet. Tanpa ini, Anda tidak tahu apa yang perlu ditambal. Inventaris juga mencakup hosting yang dikelola vendor dan situs yang dipasang tim lain.
2. Pantau sumber peringatan. Advisori vendor, katalog CISA KEV, peringatan BSSN, dan milis distro Linux Anda. Tetapkan siapa yang membaca dan meneruskan.
3. Nilai risiko. Gabungkan status eksploitasi (CISA KEV dan EPSS), skor CVSS, paparan jaringan, dan kekritisan aset.
4. Uji dan jadwalkan. Uji di staging untuk aset penting, siapkan rencana rollback, dan komunikasikan jendela pemeliharaan. Untuk kasus darurat, uji yang minimal tetapi tetap ada.
5. Terapkan dan verifikasi. Pastikan layanan benar-benar memakai versi baru (restart bila perlu, rebuild image container), lalu cek ulang dengan pemindai atau perintah versi. Banyak insiden terjadi karena paket sudah diperbarui tetapi proses lama masih berjalan.
6. Laporkan dan tinjau. Ukur waktu rata-rata penambalan per tingkat risiko, jumlah pengecualian, dan aset yang tertinggal.

Contoh tingkat SLA berbasis risiko

Angka di bawah adalah contoh titik awal yang masuk akal untuk dikalibrasi dengan kapasitas tim Anda, bukan standar baku. Perbedaannya yang penting adalah tingkat ditentukan oleh risiko, bukan hanya skor CVSS.

• Tingkat 0 - Darurat: celah berstatus KEV atau dieksploitasi aktif pada aset yang menghadap internet. Target 24 sampai 72 jam, di luar siklus normal, disertai pemeriksaan kompromi. Sebagai pembanding, BOD 26-04 mewajibkan lembaga federal AS menyelesaikan remediasi atau mitigasi dalam tiga hari, plus triase forensik, untuk kombinasi risiko tertinggi dalam tabel tenggatnya.
• Tingkat 1 - Tinggi: KEV pada aset internal, atau kritis dengan EPSS tinggi pada aset yang menghadap internet. Target sekitar 7 hari.
• Tingkat 2 - Menengah: skor tinggi tanpa tanda eksploitasi dan paparan terbatas. Target sekitar 30 hari, mengikuti siklus bulanan.
• Tingkat 3 - Rendah: sisanya. Target 90 hari atau pada pembaruan versi terjadwal berikutnya.

Tenggat dapat bergeser. BOD 26-04 sendiri menyatakan bahwa mencabut sistem dari internet dapat menggeser tenggatnya, sedangkan entri KEV baru dapat memperpendeknya. Terapkan logika yang sama: kontrol kompensasi dan perubahan paparan mengubah tingkat, dan tingkat harus dihitung ulang ketika kondisi berubah.

Menangani aset yang tidak bisa ditambal

Selalu ada sistem lawas, perangkat yang vendornya berhenti mendukung, atau aplikasi yang rusak bila diperbarui. Untuk itu siapkan jalur pengecualian yang tertulis: pemilik risiko menyetujui, ada kontrol kompensasi (misalnya WAF, pembatasan jaringan, atau mematikan fitur yang rentan), ada tenggat tinjau ulang, dan ada rencana penggantian. Dalam kasus PHP2Shell, Kementerian Perindustrian mengumumkan penonaktifan sementara SIINas, situs utama, dan seluruh domain kemenperin.go.id sejak 22 Oktober 2026 pukul 22.00 WIB hingga 25 Oktober sebagai langkah mitigasi. Itu contoh pengecualian yang ekstrem tetapi sah: menurunkan layanan lebih baik daripada membiarkannya terpapar tanpa patch. Pemeriksaan dari luar juga punya batas. Pemindaian CISSReC terhadap 597 domain go.id pada 22 Oktober, yang dilaporkan Katadata, menemukan sebagian situs menyembunyikan versi PHP sehingga status mereka tidak bisa dipastikan dari luar. Menyembunyikan versi bukan mitigasi, dan verifikasi sebenarnya hanya bisa dilakukan di dalam server. Lihat juga respons Indonesia terhadap PHP2Shell.

Kesalahan umum dalam patch management

• Mengandalkan CVSS saja dan mengabaikan status eksploitasi.
• Menambal paket tetapi lupa restart layanan atau rebuild image.
• Tidak punya inventaris sehingga aset bayangan tidak pernah ditambal.
• Menganggap patch selesai tanpa memeriksa kompromi pada celah yang sudah dieksploitasi sebelum rilis patch.
• Tidak menguji sama sekali, lalu patch merusak layanan dan tim jadi enggan menambal lagi. Uji singkat di staging tetap perlu, dan pantau catatan rilis susulan vendor.

Pertanyaan yang Sering Diajukan

Apakah semua patch harus langsung diterapkan?

Tidak. Yang harus langsung adalah yang berisiko tinggi: dieksploitasi, terpapar, atau kritis bagi bisnis. Sisanya mengikuti siklus rutin.

Bagaimana jika vendor belum merilis patch?

Terapkan mitigasi sementara dari vendor, kurangi paparan, perketat pemantauan, dan catat sebagai pengecualian dengan tanggal tinjau ulang.

Apakah organisasi kecil perlu proses seformal ini?

Perlu versi ringkasnya: daftar aset, satu orang penanggung jawab, notifikasi KEV, dan aturan sederhana tentang kapan patch darurat dilakukan.

Kesimpulan

Patch management berbasis risiko membantu tim kecil menangani hal yang paling penting lebih dulu. Mulailah dari inventaris, tetapkan tingkat SLA, dan ukur hasilnya tiap bulan. Untuk membangun kompetensi tim, lihat pelatihan Linuxhackingid tentang manajemen kerentanan dan respons insiden. Rujukan: BOD 26-04 CISA, Help Net Security tentang PHP2Shell, dan Bisnis.com tentang penonaktifan situs Kemenperin.