Semua artikel
// Artikel

SLA Remediasi Kerentanan: Workbook Praktis

Dipublikasikan 31 Juli 2026

SLA remediasi adalah clock operasi dari temuan terkonfirmasi sampai hasil terverifikasi. SLA harus menentukan kapan triage dimulai, kapan mitigasi diperlukan, siapa menyampaikan perbaikan tahan lama, dan bagaimana retest menutup pekerjaan. Ini bukan janji publik atau tenggat patch universal. NIST menjelaskan patch management enterprise sebagai proses terorganisasi; CISA KEV adalah masukan prioritisasi saat eksploitasi diketahui mengubah urgensi.

Tetapkan clock dari bukti

Mulai clock saat temuan dikonfirmasi pada aset ber-owner, bukan saat hasil scanner belum diverifikasi muncul. Catat waktu discovery, waktu konfirmasi, alasan prioritas, asset owner, remediation owner, dan due time. Gunakan kategori sesuai risiko lokal. Contoh target internal: isu dieksploitasi aktif dan exposed—contain segera, rencana hari sama, remediasi pada window aman terawal; isu kritis terjangkau—mitigasi cepat dan perbaikan lewat change dipercepat; isu normal—perbaikan dalam maintenance terencana. Ini contoh, bukan kewajiban universal.

Pisahkan mitigasi dari remediasi. Mitigasi mengurangi paparan segera: pembatasan route, penonaktifan feature, workaround vendor, rotasi kredensial, atau monitoring. Remediasi menghapus atau menyelesaikan akar masalah permanen: update vendor, koreksi konfigurasi, penggantian, atau perubahan kode. Mitigasi memerlukan owner, bukti, dan tanggal review agar tidak menjadi permanen tanpa sengaja.

Jadikan retest tahap wajib

Change ticket membuktikan pekerjaan dicoba, bukan paparan telah hilang. Retest mencocokkan kondisi awal: periksa versi terpasang atau konfigurasi, ulangi uji reachability aman, review kesehatan layanan, lalu kumpulkan bukti baru. Tandai lulus hanya bila perilaku yang sudah diperbaiki dan fungsi layanan wajib sama-sama berjalan. Tandai gagal bila kontrol masih mengizinkan jalur awal, bukti tidak ada, atau perubahan merusak operasi diperlukan.

TahapRecord wajibContoh selesai
Triageaset, owner, prioritas, due dateaset exposed dikonfirmasi; owner menerima tiket
Mitigasikontrol, waktu, buktiroute masuk dibatasi; log disimpan
Remediasichange dan rollback planupdate vendor diterapkan pada window disetujui
Retestkondisi awal dan health testversi lama tidak ada; transaksi layanan lulus
Closurereviewer dan lokasi buktireviewer menandai lulus; record ditautkan

Kendalikan pengecualian

Pengecualian adalah keputusan berbatas, bukan due date kosong. Cantumkan temuan dan aset terdampak, alasan perbaikan belum dapat terjadi, risk owner, otoritas persetujuan, kontrol kompensasi, verifikasi mitigasi, cadence review, dan expiry. Sistem perlu menandai expiry sebelum lewat. Saat expiry, remediasi, perpanjang lewat keputusan baru, atau kembalikan item menjadi overdue. “Dependensi vendor” menjelaskan masalah, bukan record pengecualian.

Untuk entry KEV, simpan bukti catalog terkini dan panduan tindakan vendor bersama fakta paparan lokal. Jika patch belum dapat berjalan, catat mitigasi terpilih dan alasan mitigasi mengubah paparan. Jangan mengklaim patuh pada arahan CISA kecuali berlaku dan telah diverifikasi mandiri.

Pelaporan berbasis bukti

Tampilkan kinerja clock sebagai record, bukan metrik pemasaran: jumlah terbuka menurut prioritas, item overdue, item termitigasi tetapi belum diperbaiki, pengecualian basi, dan status retest. Jauhkan nama serta detail implementasi sensitif dari laporan luas. Workbook SLA yang berguna memungkinkan reviewer menjawab lima hal: apa terdampak, siapa owner, apa jatuh tempo, apa mengurangi risiko sekarang, dan bukti apa yang membuktikan closure.

Jalur eskalasi

Eskalasi saat triage belum memiliki owner, mitigasi melewati clock, change window berulang kali ditunda, atau retest gagal. Eskalasi meminta keputusan: tambah sumber daya, terima pengecualian berbatas, ubah mitigasi, atau hilangkan aset dari paparan. Ini bukan sekadar mengirim pengingat. Simpan keputusan dan due date baru dalam record sama. Review kegagalan berulang untuk penyebab sistemik seperti celah inventaris, platform tak didukung, keterlambatan persetujuan, atau maintenance window tidak memadai. Memperbaiki penyebab ini adalah remediasi proses, sedangkan memperbaiki satu aset adalah remediasi temuan.

Ukur kualitas keputusan

Review sampel record tertutup setiap bulan. Konfirmasikan bukti awal tetap tertaut, mitigasi direview sampai perbaikan permanen, retest memakai kondisi tepat, dan exception expiry ditangani. Bandingkan perubahan due date dengan riwayat persetujuan. Perpindahan tanggal berulang tanpa bukti berubah adalah sinyal tata kelola gagal. Laporkan blocker menurut kategori kepada manajemen: dependensi vendor, kapasitas, change freeze, ownership aset, atau remediasi gagal. Ini membantu owner memperbaiki proses operasi tanpa mengubah contoh workbook menjadi janji layanan universal. Clock berguna hanya bila menghasilkan keputusan akuntabel dan hasil tercatat.

Record SLA selesai

Contoh tertutup harus dapat direkonstruksi: VULN-2026-014, aset EDGE-01, URI bukti konfirmasi, alasan prioritas, asset owner, remediation owner, mitigation owner, mitigation due, remediation due, ID change, ID exception atau none, expiry exception, retest kondisi awal, retest kesehatan layanan, reviewer, dan timestamp closure. Jika perubahan ditunda, catat due date baru bersama risk owner yang menyetujui serta kontrol kompensasi konkret; jangan menimpa tanggal awal. Closure memerlukan paparan awal sudah hilang dan perilaku layanan wajib sudah diverifikasi.

Sources

Penutupan item remediasi

Untuk temuan kritis yang terpapar internet, workbook mencatat tenggat berdasarkan tingkat keparahan, mitigasi sementara, perbaikan permanen, dan pemilik eskalasi. Setiap perpanjangan harus menyebut alasan, kontrol kompensasi, penerima risiko, serta tanggal kedaluwarsa. Item hanya ditutup setelah uji ulang membuktikan perbaikan pada versi yang tepat; tiket atau status mitigasi saja tidak cukup.

Punya sistem yang perlu diuji?