Menganalisis log untuk menentukan lingkup insiden

Apa yang ingin dibuktikan dari log?

Tentukan pertanyaan lebih dulu: akun mana yang melakukan tindakan, data atau layanan mana yang mungkin terlibat, dan bagian apa yang belum dapat dijelaskan. Jangan langsung menyamakan peringatan ekspor dengan pengambilan seluruh data.

Triase peringatan menentukan prioritas serta pemilik tindakan awal. Analisis di sini melanjutkan pemeriksaan lingkup. Pengumpulan dan penanganan sumber tetap mengikuti panduan bukti elektronik, dengan akses yang sah.

Simpan sumber dan konteks sebelum mengolah

Catat asal, rentang waktu, petugas, cara ekspor, filter yang dipakai dan bagian yang tidak tersedia. Pertahankan sumber, lalu gunakan salinan kerja untuk mencari, mengurutkan atau menyamarkan. Rekam perubahan salinan; jangan memperbaiki baris asli agar cocok dengan kesimpulan.

Pilih catatan akun/izin, aplikasi, pekerjaan latar belakang, storage dan gateway sesuai pertanyaan. Satu log tidak harus memuat semuanya. Hindari token atau data pribadi yang tidak diperlukan dalam keluaran analisis; simpan rujukan bukti di tempat terbatas.

Samakan waktu tanpa menghilangkan nilai asli

Catat zona waktu serta perbedaan antara waktu peristiwa, pencatatan dan pengambilan bukti. WIB adalah UTC+07:00. Bila jam sistem terlambat, tulis dasar dan besar koreksi pada kolom turunan; jangan diam-diam mengganti timestamp sumber.

Waktu tanpa zona, tanggal tidak valid atau informasi jam yang tidak cukup perlu ditandai. Urutan yang berdekatan juga bisa tidak pasti karena resolusi waktu atau keterlambatan pencatatan. Jangan menebak zona hanya karena penguji sedang berada di Jakarta.

Contoh yang dijalankan: dua pekerjaan ekspor

Unduh source, log buatan dan hasil lab analisis insiden 1.0. Contoh dijalankan 2 Oktober 2026, Node 24.21.0, macOS arm64, tanpa server, simulator atau layanan cloud:

node incident-lab.mjs --out results.json

Runner menjalankan 20 pemeriksaan fixture. Ia membaca log buatan, bukan mengumpulkan log layanan nyata atau menjalankan ekspor. Dari 13 baris: tujuh kejadian dipertahankan, satu duplikat persis tidak dihitung lagi dan lima baris ditolak. Penolakan mencakup dua baris dengan ID sama tetapi isi berbeda, satu waktu tanpa zona, satu tanggal 30 Februari dan satu JSON terpotong.

Kunci pembanding adalah sumber dan event ID. Deduplikasi ini hanya mengenali baris identik; format JSON berbeda bisa menjadi konflik. Baris ditolak tetap disebut dalam hasil, bukan dihilangkan dari batas analisis.

Jam worker sengaja dibuat tertinggal 120 detik. Koreksi +120 berasal dari desain fixture, bukan metode mengukur jam sistem nyata. Kronologi turunannya:

Waktu UTC → WIB	Rekaman yang dipertahankan
00.59 → 07.59	IAM mencatat peran akun ACC-DEMO-7 diubah menjadi exporter.
01.00 → 08.00	Gateway mencatat permintaan EXP-A, R1, dengan status 202.
01.00.02 → 08.00.02	Worker mencatat awal EXP-A/R1, setelah koreksi waktu.
01.00.03 → 08.00.03	Worker mencatat artefak EXP-A dengan nilai rows 100.
01.01 → 08.01	Worker mencatat awal EXP-B/R3; tidak ada rekaman penyelesaian dalam data yang dipakai.
01.05 → 08.05	Gateway mencatat EXP-A/R2, status 200 dan bytesSent 2048.
01.06 → 08.06	Gateway mencatat satu respons EXP-B/R4, status 403.

Request ID R1 menghubungkan permintaan dan pekerjaan EXP-A; job ID menghubungkan pekerjaan dengan respons unduhan R2. Akun, request dan job adalah penanda buatan, bukan bukti identitas manusia. Nama akun yang sama juga belum menjelaskan siapa yang menguasai sesinya saat itu.

Pisahkan rekaman, kesimpulan dan pertanyaan terbuka

Log EXP-A mencatat pembuatan artefak dan respons unduhan. Nilai 100 adalah jumlah baris yang diklaim log, bukan pemeriksaan isi berkas atau 100 orang. Status 200 dan laporan 2048 byte belum membuktikan penerima membaca seluruh isi.

EXP-B mencatat awal pekerjaan dan satu respons yang ditolak. Ketiadaan rekaman selesai tidak membuktikan pekerjaan tidak pernah selesai; satu 403 tidak membuktikan semua jalur unduhan tertutup. Periksa rentang/kelengkapan log, storage dan jalur lain sebelum menyimpulkan.

Hipotesis awal dapat berupa penyalahgunaan akun, kegiatan sah yang belum dikonfirmasi, atau pencatatan yang tidak lengkap. Tuliskan bukti yang mendukung/melemahkan masing-masing serta siapa mencari informasi tambahan. IP atau user agent juga tidak cukup sendiri untuk menuduh orang tertentu.

Apa yang masuk ke laporan?

Gunakan catatan insiden untuk kronologi dan status. Cantumkan ID bukti, sumber, normalisasi waktu, hasil per kasus, penolakan baris serta cakupan yang belum diperiksa. Riwayat pemegang/salinan tetap di lembar penanganan bukti.

Contoh tidak menguji collector, kejujuran sumber log, identitas pelaku, isi ekspor, bukti jaringan penerima, akuisisi memori/disk atau prosedur hukum pembuktian. Hasilnya tidak menjadi laporan forensik perangkat atau penilaian kebocoran sistem nyata. Gunakan rencana komunikasi untuk menyampaikan fakta dan ketidakpastian; penilaian kewajiban data pribadi berjalan bersama pemeriksaan teknis.

Bagian panduan log yang diadaptasi dari OWASP mengikuti CC BY-SA 4.0, dengan perubahan bahasa dan contoh. Kode, data dan hasil contoh orisinal Kompli memakai CC0 1.0.