Menulis Laporan Insiden

Laporan insiden mendokumentasikan apa yang terjadi, dampaknya, respons yang diberikan, dan rekomendasi. Laporan ini ditujukan bagi kalangan hukum, regulator, manajemen, dan teknis. Laporan yang ditulis dengan baik menunjukkan kompetensi dan memungkinkan organisasi belajar dari pengalaman.

Bagian standar laporan insiden:

1. Ringkasan Eksekutif
2. Linimasa Peristiwa
3. Analisis Teknis
4. Penilaian Dampak
5. Tindakan Respons yang Diambil
6. Analisis Akar Masalah
7. Rekomendasi
8. Lampiran (bukti, IOC)

Ringkasan eksekutif ditulis untuk pimpinan nonteknis. Ringkasan ini harus menjawab pertanyaan berikut dalam 1–2 paragraf:

• Apa yang terjadi dan kapan?
• Apa yang terdampak?
• Apa yang dilakukan untuk menanganinya?
• Bagaimana status saat ini?

Hindari jargon. Nyatakan dampak secara kuantitatif (X catatan, Y jam waktu henti, biaya $Z).

Linimasa merupakan landasan faktual laporan. Sertakan:

• Stempel waktu (UTC, tentukan zona waktu)
• Apa yang terjadi (fakta yang dapat diamati)
• Sumber informasi (referensi catatan, alat, saksi)

Pisahkan fakta dari interpretasi. Contoh: "14:32 UTC — peringatan IDS dipicu pada host 10.0.1.5 (referensi: peristiwa SIEM dengan ID 8842)"

Bagian teknis mendokumentasikan taktik, teknik, dan prosedur penyerang:

• Metode akses awal (pengelabuan, eksploitasi, pencurian kredensial)
• Alat dan malware yang digunakan (beserta hash)
• Tahapan pergerakan lateral
• Data yang diakses atau dieksfiltrasi
• Mekanisme persistensi yang dipasang

Petakan ke kerangka kerja MITRE ATT&CK untuk komunikasi yang terstandardisasi.

Nyatakan dampak secara kuantitatif berdasarkan triad CIA:

• Kerahasiaan: data apa yang diakses atau dicuri? PII, IP, atau data keuangan?
• Integritas: apakah ada data yang diubah?
• Ketersediaan: berapa lama waktu hentinya?
• Keuangan: biaya langsung, denda regulator, kehilangan pelanggan
• Reputasi: pengungkapan publik, liputan media

Sertakan semua indikator kompromi untuk penggunaan defensif:

Akar masalah harus spesifik: "Penyerang memperoleh akses awal melalui email pengelabuan yang melewati penyaringan email karena tidak adanya penerapan DMARC pada domain korban." Rekomendasi harus konkret, diprioritaskan, dan ditugaskan kepada penanggung jawab dengan tenggat waktu.

Banyak insiden memicu kewajiban pemberitahuan:

• GDPR: beri tahu otoritas pengawas dalam 72 jam sejak menyadari adanya insiden
• HIPAA: beri tahu HHS dalam 60 hari (individu juga dalam 60 hari)
• PCI-DSS: beri tahu merek kartu dalam 24 jam sejak dugaan kompromi

Klasifikasikan laporan dengan tepat — laporan ini berisi informasi sensitif tentang kerentanan dan taktik, teknik, serta prosedur penyerang. Distribusikan berdasarkan kebutuhan untuk mengetahui. Penasihat hukum harus meninjau laporan sebelum distribusi eksternal apa pun. Salinan internal harus memiliki pencatatan akses.

Rekomendasi dari laporan harus dilacak hingga selesai. Tetapkan penanggung jawab, tanggal jatuh tempo, dan prioritas untuk setiap rekomendasi. Lacak statusnya dalam sistem pelacakan masalah Anda. Tinjau kembali setelah 30/60/90 hari. Rekomendasi yang tidak diterapkan dapat menjadi risiko tanggung jawab hukum dalam insiden berikutnya.

Laporan insiden mendokumentasikan apa yang terjadi (linimasa), bagaimana hal itu terjadi (analisis teknis), dampaknya (triad CIA), apa yang dilakukan (tindakan respons), dan apa yang perlu diperbaiki (rekomendasi). Ringkasan eksekutif bersifat nonteknis. IOC didokumentasikan agar dapat digunakan kembali untuk tujuan defensif. Tenggat waktu pemberitahuan kepada regulator harus dipenuhi. Agar dapat ditindaklanjuti, rekomendasi memerlukan penanggung jawab dan tanggal jatuh tempo.