Skip to content

Manajemen kerentanan, patch, dan hardening

Informasi Dokumen

Atribut Keterangan
Kode Dokumen DTSI-SOP-OPS-05
Kode LPM —
Revisi 1.0
Tanggal Efektif — (ditetapkan saat persetujuan Kepala DTSI)
Pemilik Dokumen Departemen Teknologi dan Sistem Informasi (DTSI), Universitas Harapan Bangsa
Pemilik Proses Kepala Departemen Teknologi dan Sistem Informasi (DTSI)
Kelas Wajib
Status DRAFT — siap peninjauan pimpinan

1. Tujuan

Mengurangi risiko eksploitasi teknis melalui identifikasi kerentanan, prioritisasi berbasis risiko, penerapan patch dan hardening terkendali, serta pelacakan hingga penutupan—selaras ISO/IEC 27002 (kerentanan teknis, pembaruan).

2. Ruang lingkup

OS server dan workstation administrasi, hypervisor, perangkat jaringan, firmware, middleware, dan stack aplikasi yang menjadi tanggung jawab DTSI. Aplikasi custom mengikuti juga DTSI-SOP-DEV-01.

3. Dokumen terkait

Dokumen Relasi
DTSI-SOP-OPS-02 Patch sebagai perubahan
DTSI-SOP-OPS-09 Rilis yang menyertakan patch aplikasi
DTSI-SOP-INC-01 Eksploitasi zero-day
DTSI-SOP-NET-01 Segmentasi mendukung mitigasi

4. Definisi

Istilah Makna
CVE Pengidentifikasi kerentanan umum.
Hardening Konfigurasi aman (non-default, least service).

5. Sumber informasi kerentanan

  1. Vendor, security advisory, CVE, hasil scan internal/disetujui, bug bounty institusi [jika ada].
  2. Hasil scan tidak boleh dijalankan tanpa otorisasi pada lingkungan produksi tanpa RFC.

6. Prioritisasi (indikatif)

Tingkat Contoh Target tindakan
Kritis Eksploitasi aktif di internet, RCE publik Patch/mitigasi [Diisi: mis. 72 jam]
Tinggi Tanpa eksploitasi massal tetapi dampak besar [Diisi: mis. 14 hari]
Sedang/Rendah Sesuai jadwal rutin Jendela bulanan

7. Peran dan tanggung jawab

Peran Tanggung jawab
Kepala DTSI Menerima risiko residu tertulis.
Tim infrastruktur / aplikasi Pelaksana patch per domain teknis.
Focal keamanan Validasi skor risiko, koordinasi insiden.

8. Prosedur

8.1 Identifikasi dan pencatatan

  1. Masukkan temuan ke register kerentanan (tiket atau spreadsheet terkendali) dengan CVE, aset, versi, CVSS [atau skor internal].

8.2 Rencana perbaikan

  1. Tentukan patch, workaround, atau segmentasi sebagai mitigasi sementara.
  2. Jika patch memerlukan reboot/downtime → RFC (DTSI-SOP-OPS-02); emergency patch mengikuti jalur darurat.

8.3 Uji dan produksi

  1. Uji di lingkungan non-produksi sejajar bila memungkinkan.
  2. Terapkan di produksi; verifikasi versi dan layanan.
  3. Tutup entri register dengan bukti.

8.4 Hardening baseline

  1. Terapkan baseline per OS/peran (contoh: SNMP mati bila tidak perlu, SSH hanya kunci, port tidak perlu tertutup).
  2. Audit konfigurasi minimal semesteran untuk sampel aset kritis.

9. Pengecualian

  1. Penerimaan risiko tanpa patch hanya dengan persetujuan tertulis Kepala DTSI dan tanggal review ulang.

10. Rujukan ISO (indikatif)

  • ISO/IEC 27002 — technical vulnerability management.

11. Rekaman wajib

  • Register kerentanan, RFC terkait, bukti versi pasca-patch, penerimaan risiko.

12. Indikator kinerja

Indikator Target
Kerentanan kritis terbuka 0 melewati SLA
Kepatuhan patch bulanan [Diisi %]
Aset tanpa baseline Menurun tiap kuartal

13. Tinjauan dokumen

Minimal tahunan atau setelah insiden eksploitasi, perubahan besar arsitektur.

Register SOP: Daftar SOP Operasional