Skip to content
← Blog

Kesalahan Umum dalam Menangani Barang Bukti Digital

Barang bukti digital dengan seal, hash, dan log akses
Integritas evidence bergantung pada proses yang konsisten, bukan hanya kecanggihan tool.

Kesalahan tidak selalu membuat bukti tidak berguna, tetapi menambah ketidakpastian. Respons profesional adalah berhenti, mencatat apa yang terjadi, menilai dampak, dan tidak menutupi kesalahan.

Kesalahan sebelum akuisisi#

  1. Tidak memastikan otorisasi. Perbaikan: tetapkan scope, pemilik sistem, dan periode data.
  2. Mematikan perangkat tanpa memahami volatilitas. RAM, connection, dan key dapat hilang. Tentukan urutan akuisisi berdasarkan tujuan.
  3. Membiarkan user terus memakai perangkat. Aktivitas baru mengubah artefak.
  4. Tidak mencatat waktu dan timezone. Timeline kemudian sulit disatukan.

Kesalahan saat akuisisi#

  1. Mount read-write. OS dapat mengubah metadata. Gunakan write blocker bila relevan.
  2. Menganalisis original. Selalu buat master dan working copy.
  3. Tidak merekam tool/version/command. Hasil tidak reproducible.
  4. Hanya satu hash tanpa verifikasi salinan. Hash pada titik transfer penting.
  5. Storage tujuan terlalu kecil. Akuisisi berhenti dan harus diulang.

Kesalahan saat analisis#

  1. Mengubah timestamp karena membuka file. Analisis image atau copy read-only.
  2. Menyimpulkan dari satu indikator. Korelasikan process, filesystem, registry, network, dan identity.
  3. Mengabaikan false positive. Catat hipotesis benign.
  4. Tidak memisahkan fakta dan interpretasi. “Hash X ditemukan” adalah fakta; “pelaku mengunduh malware” adalah interpretasi.

Kesalahan pada pelaporan dan penyimpanan#

  1. Screenshot tanpa sumber/query. Sertakan event ID, command, dan export.
  2. Mengirim evidence lewat kanal tidak terkontrol. Gunakan encrypted storage, least privilege, dan expiry.
  3. Retention tidak jelas. Data sensitif disimpan selamanya tanpa alasan.

Jika kesalahan sudah terjadi#

Contoh: analyst tanpa sengaja membuka drive bukti secara read-write. Jangan “memperbaiki” log. Cabut dengan prosedur aman, catat waktu dan aksi, ambil image secepatnya, bandingkan dengan sumber lain, tentukan artefak yang mungkin berubah, dan masukkan keterbatasan dalam laporan.

Checklist meja kerja#

  • Scope dan otorisasi tersedia.
  • Jam tersinkron atau offset dicatat.
  • ID evidence sudah diberikan.
  • Original dilindungi.
  • Tool, version, dan command tercatat.
  • Hash diverifikasi.
  • Working copy terpisah.
  • Catatan fakta dibedakan dari interpretasi.
  • Transfer dan akses diaudit.
  • Keterbatasan dilaporkan.

Forensik yang matang tidak berpura-pura sempurna; ia membuat setiap tindakan dapat dijelaskan.

Prioritas berdasarkan volatilitas#

Urutan tidak selalu RAM lalu disk. Pertimbangkan risiko perubahan, kebutuhan bisnis, enkripsi, dan kemampuan tool. Pada server kritis, acquisition dapat memengaruhi layanan. Dokumentasikan trade-off: data apa yang mungkin hilang dan mengapa keputusan tersebut proporsional.

Skenario latihan review#

Seorang teknisi menerima laptop menyala, memfoto layar, mencabut kabel jaringan, menjalankan collection script, lalu memasukkan perangkat ke locker. Temukan gap: otorisasi belum disebut, jam/timezone tidak diverifikasi, tool/version dan hash output belum dicatat, kondisi power/encryption tidak dijelaskan, serta transfer ke locker belum mempunyai penerima dan seal ID.

Corrective action yang berguna#

  • Checklist akuisisi satu halaman.
  • Case ID otomatis dan label tercetak.
  • Template command log.
  • Verifikasi hash saat transfer.
  • Access review evidence store bulanan.
  • Tabletop insiden per kuartal.

Budaya pelaporan#

Jika staf takut melaporkan kesalahan, organisasi kehilangan kesempatan menilai dampak. Pisahkan human error yang dilaporkan jujur dari pelanggaran sengaja. Catat fakta, konservasi bukti tersisa, dan perbaiki kontrol sistemik.

💬 Comments (0)

No comments yet. Be the first to share your thoughts!

Related reading

Aug 11, 2026 · 3 min Chain of Custody Digital Evidence untuk Praktisi IT Cara menjaga asal-usul, integritas, akses, pemindahan, dan penyimpanan bukti digital agar temuan teknis dapat diverifikasi. Aug 11, 2026 · 3 min Otomasi SOC: Bagian Mana yang Aman Diotomatisasi dan Mana yang Tetap Membutuhkan Manusia Kerangka memilih otomasi SOC berdasarkan reversibilitas, confidence, blast radius, dan kebutuhan konteks—lengkap dengan contoh playbook phishing. Aug 11, 2026 · 3 min Bagaimana SOC Analyst Melakukan Alert Triage Tanpa Tenggelam dalam False Positive Metode triage berbasis konteks untuk memisahkan sinyal penting dari noise: validasi, enrichment, risk scoring, decision tree, dan feedback tuning.
Now Playing Loading...