Manajemen Patch dan SLA

Prioritisasi memberi tahu Anda hal yang harus diperbaiki; manajemen perbaikan adalah proses disiplin yang benar-benar mendorong penyelesaian perbaikan tersebut tepat waktu dan di seluruh lingkungan.

SLA (perjanjian tingkat layanan) menentukan seberapa cepat tingkat keparahan yang berbeda harus ditangani. Tanpa SLA, perbaikan mendesak akan tertunda dan akuntabilitas menghilang.

Siklus yang dapat diulang membantu menjaga sistem tetap mutakhir:

• Identifikasi perbaikan yang tersedia (advisori penyedia, hasil pemindaian).
• Evaluasi relevansi dan risiko penerapannya.
• Uji di lingkungan nonproduksi.
• Terapkan secara bertahap dan terkendali.
• Verifikasi bahwa perbaikan telah diterapkan dan sistem berfungsi dengan baik.

Setiap langkah memiliki penanggung jawab dan bukti, seperti halnya siklus hidup VM secara keseluruhan.

SLA mengubah maksud menjadi tenggat waktu. SLA menetapkan waktu maksimum yang diizinkan sejak penemuan hingga perbaikan, dengan tingkatan berdasarkan tingkat keparahan. Contoh target:

• Kritis / KEV: 7-15 hari (atau lebih cepat jika menghadap internet).
• Tinggi: 30 hari.
• Sedang: 90 hari.
• Rendah: sesuai upaya terbaik / siklus berikutnya.

SLA membuat lamanya temuan dapat diukur dan mendorong penyelesaian, bukan sekadar pengakuan.

Kaitkan tenggat waktu dengan risiko nyata, bukan hanya CVSS. Kerentanan kritis yang tercantum dalam KEV atau menghadap internet harus memiliki SLA yang lebih ketat daripada kerentanan sedang pada sistem internal.

Kerangka kerja rujukan dapat membantu: CISA mewajibkan lembaga federal menangani kerentanan dalam KEV dalam tenggat yang telah ditetapkan, dan banyak perusahaan menerapkan tenggat serupa yang dipercepat untuk kerentanan yang sedang dieksploitasi, terlepas dari CVSS.

Perbaikan dapat menyebabkan masalah. Pengujian di lingkungan penahapan dapat menemukan regresi sebelum perubahan mencapai produksi:

• Terapkan terlebih dahulu pada kelompok pengujian yang mewakili lingkungan Anda.
• Validasi fungsi penting dan kinerja.
• Pastikan tidak ada konflik dengan perangkat lunak yang sudah ada.

Seimbangkan kecepatan dan keamanan: untuk KEV yang sedang dieksploitasi di dunia nyata, terima risiko yang lebih besar dan lakukan perbaikan lebih cepat daripada untuk pembaruan rutin.

Terapkan secara bertahap (penerapan bertingkat): mulai dari kelompok percontohan, lalu kelompok yang lebih luas, kemudian seluruh sistem. Pantau kondisi sistem pada setiap tingkat sebelum melanjutkan.

Selalu siapkan rencana pengembalian: salinan sesaat, penurunan versi paket, atau pemulihan konfigurasi. Jika suatu perbaikan menyebabkan gangguan, Anda harus dapat mengembalikannya dengan cepat sambil melakukan penyelidikan.

Penerapan perbaikan secara manual tidak dapat ditingkatkan skalanya. Gunakan alat terpusat:

• WSUS / SCCM / Intune untuk Windows.
• Manajemen konfigurasi (Ansible, Puppet, Chef) untuk kelompok sistem Linux.
• Citra dasar yang dibuat ulang dengan perbaikan untuk komputasi awan dan kontainer.

Otomatisasi menegakkan konsistensi dan memperpendek jeda antara rilis perbaikan dan penerapannya.

Terkadang Anda tidak dapat segera melakukan perbaikan: penyedia terlambat, sistem lama yang rapuh, atau waktu aktif yang harus dipertahankan. Terapkan kontrol kompensasi untuk mengurangi risiko sementara itu:

• Segmentasi jaringan / aturan penyaring jaringan.
• Perbaikan virtual melalui tanda tangan WAF atau IPS.
• Menonaktifkan fitur atau layanan yang rentan.

Langkah-langkah ini memberi Anda waktu, tetapi bukan pengganti permanen untuk perbaikan yang sebenarnya.

Sistem yang telah mencapai akhir masa dukungan mungkin sama sekali tidak memiliki perbaikan. Pilihannya:

• Isolasi sistem tersebut pada segmen jaringan yang dibatasi.
• Lindungi dengan kontrol akses dan pemantauan yang ketat.
• Rencanakan migrasi atau penonaktifan dengan tenggat waktu.
• Terima risiko tersisa secara resmi dengan tanggal kedaluwarsa.

Dokumentasikan semuanya; sistem yang tidak dapat diperbaiki dan dibiarkan tanpa dokumentasi menimbulkan risiko audit dan pelanggaran keamanan.

Lacak apakah program benar-benar memenuhi komitmennya:

• MTTR berdasarkan tingkat keparahan dibandingkan dengan target SLA.
• Tingkat kepatuhan SLA (persentase temuan yang ditutup dalam tenggat waktu).
• Temuan yang terlambat / menua berdasarkan tim dan aset.
• Cakupan perbaikan (persentase seluruh sistem yang telah diperbarui).

Buat laporan berdasarkan tim penanggung jawab agar akuntabilitas terlihat dan area yang lambat mendapat perhatian.

Setelah penerapan, verifikasi: lakukan pemindaian ulang untuk memastikan CVE telah teratasi dan sistem berfungsi dengan baik, lalu tutup temuan dengan menyertakan bukti. Masukkan masalah yang berulang (pustaka yang terus muncul kembali, tim yang terus-menerus terlambat) ke dalam proses peningkatan.

Manajemen perbaikan yang dilakukan dengan baik mengubah risiko yang telah diprioritaskan menjadi pengurangan risiko yang terukur dan tepat waktu.

Pastikan Anda memahami peran SLA perbaikan.

Manajemen perbaikan mendorong penyelesaian temuan yang telah diprioritaskan melalui identifikasi, evaluasi, pengujian, penerapan bertahap, dan verifikasi, dengan dukungan rencana pengembalian serta otomatisasi. SLA menetapkan tenggat waktu berdasarkan tingkat keparahan dan risiko, dengan tenggat lebih ketat untuk KEV atau sistem yang menghadap internet, sehingga perbaikan selesai tepat waktu.

Jika penerapan perbaikan tidak memungkinkan, gunakan kontrol kompensasi serta penerimaan risiko yang terdokumentasi dan dibatasi waktunya. Ukur MTTR, kepatuhan SLA, dan cakupan, lalu masukkan pembelajaran ke dalam siklus hidup.