Belajar Cyber Security #20: Digital Forensics — Log, Timeline, dan Chain of Custody

Di episode #19 kita sudah punya alur PICERL untuk merespons insiden. Tapi ada satu fase yang sering saya remehkan sebagai programmer: membaca bukti digital. Selama ini saya terbiasa “lihat log, tebak, bereskan” — dan ternyata cara itu rapuh. Hari ini saya mencatat dasar-dasar digital forensics: bagaimana bukti dikumpulkan supaya tetap sah, bagaimana timeline kejadian disusun ulang, dan kenapa cara kita memegang bukti sama pentingnya dengan buktinya sendiri.

Apa itu digital forensics?

Sederhananya: digital forensics adalah ilustrasi dari pertanyaan “apa yang sebenarnya terjadi di komputer ini, dan bagaimana saya membuktikannya?” Kalau incident response (episode #19) fokus memadamkan api, forensik fokus merekonstruksi kejadian dengan cara yang bisa dipertanggungjawabkan — termasuk di hadapan manajemen, auditor, atau pengadilan.

Ini berarti bagi saya sebagai developer: ketika server kena insiden, keputusan pertama saya bukan “hapus malware-nya”, tapi “amankan dulu buktinya”. Menghapus atau mengubah data di host justru membuang satu-satunya cara mengetahui seberapa dalam penyerang masuk.

Chain of custody — bukti yang dipegang siapa?

Bagian yang paling baru saya pahami adalah chain of custody: catatan lengkap siapa memegang bukti kapan, dan apa yang dilakukan terhadapnya. Bayangkan bukti fisik di film detektif — sidik jari harus disimpan di kantong tertutup dengan label. Bukti digital sama: kalau tidak ada rantai dokumentasi, lawan bisa membantah bahwa bukti sudah dimodifikasi.

Kerja di salinan, bukan asli. Buat disk image dulu (misal dengan format E01 atau raw dd), lalu seluruh analisis dilakukan di salinan itu.

Write blocker. Alat keras/software yang memastikan disk asli tidak pernah tertulis saat diakses.

Hash bukti. Hitung SHA-256 saat copy dan saat selesai analisis — hash sama = bukti utuh. Ini prinsip yang sama dengan yang kita pakai di episode #3 soal password hash, tapi tujuannya integritas, bukan autentikasi.

Catatan waktu dan pelaku. Setiap akses ke bukti dicatat: jam, orang, alasan.

Log analysis & timeline

Kerja forensik yang paling lama adalah menyusun timeline: kapan akun dibuat, kapan file dipindahkan, kapan koneksi keluar terjadi. Sumbernya macam-macam — auth log SSH, web server access log, log aplikasi, file system metadata. Di episode #14 kita sudah mengaktifkan auditd di Linux; sekarang kelihatannya jelas kenapa itu penting: tanpa log yang tersimpan, tidak ada timeline yang bisa disusun.

# contoh baris log yang biasanya jadi petunjuk awal
Jul 12 03:14:02 web1 sshd[2211]: Failed password for invalid user admin from 203.0.113.9 port 51224 ssh2
Jul 12 03:16:47 web1 sshd[2498]: Accepted publickey for deploy from 203.0.113.9 port 51390 ssh2

Saya menempelkan pola ini seperti menempelkan injection ke query orang lain di episode #8: sekadar melihat dua baris berurutan (gagal berkali-kali, lalu berhasil) sudah menceritakan brute force yang akhirnya menembus. Bedanya, kali ini saya membacanya sebagai penyelidik, bukan penyerang — dan konteksnya wajib defensif: semua ini dilakukan di sistem milik sendiri atau dengan izin tertulis.

Kesalahan pemula yang saya catat

Langsung restart server. Mematikan mesin bisa menghapus data di memori (running processes, koneksi aktif) yang tidak pernah tersimpan di disk. Kalau memungkinkan, capture RAM dulu sebelum shutdown.

Menghapus malware sebelum di-snapshot. Penyerang yang tahu jejaknya dibersihkan akan mengganti modus dan menghapus persistence-nya juga.

Mengandalkan ingatan. Timeline yang disusun seminggu kemudian dari ingatan = spekulasi. Catat sejak menit pertama.

Ini yang mengubah kebiasaan saya: menangani insiden bukan cuma soal teknis, tapi soal bukti. Saya terapkan dengan begini — di setiap playbook tim, langkah pertama selalu “snapshot dulu, baru bersihkan”, dan setiap orang yang menyentuh bukti mencatat namanya. Sedikit merepotkan, tapi justru bagian itu yang membuat analisis setelahnya bisa dipercaya. Perlu diingat juga bahwa membaca log dan rekonstruksi hanya sah pada sistem yang kita miliki atau diuji dengan izin tertulis — UU ITE mengatur keras soal akses tanpa izin, apa pun niatnya.

Sumber

NIST SP 800-86 — Guide to Integrating Forensic Techniques into Incident Response: csrc.nist.gov/pubs/sp/800/86/final

RFC 3227 — Guidelines for Evidence Collection and Archiving: rfc-editor.org/rfc/rfc3227

SANS Digital Forensics & Incident Response poster: sans.org/posters