Intro to SIEM Operations: A Practical Blue Team Guide

Platform Security Information and Event Management (SIEM) berada di jantung sebagian besar Security Operations Centers (SOCs). Platform ini mengagregasi log, mengorelasikan peristiwa, dan menampilkan alert yang harus di-triage dan diselidiki oleh analis. Panduan ini memandu Anda melalui alur kerja operasional inti sehingga Anda dapat mulai berpikir seperti analis SIEM, terlepas dari platform mana (Splunk, Elastic, Microsoft Sentinel, QRadar, dll.) yang digunakan organisasi Anda.

Apa yang Sebenarnya Dilakukan SIEM

SECara mendasar, SIEM melakukan tiga tugas: mengumpulkan log dari endpoint, perangkat jaringan, aplikasi, dan layanan cloud; menormalkan data tersebut ke dalam skema yang konsisten; dan mengorelasikan peristiwa menggunakan aturan deteksi untuk menghasilkan alert. Analis kemudian menangani alert tersebut melalui siklus triage dan investigasi. Memahami pipeline ini membantu Anda mendiagnosis masalah saat data terlihat salah atau alert tampaknya hilang.

Menyiapkan Sumber Log

Sebelum logika deteksi apa pun penting, Anda membutuhkan data yang andal. Sumber umum meliputi:

• Endpoint telemetry (agen EDR, Windows Event Logs via Sysmon)
• Network data (firewall logs, DNS queries, proxy logs, NetFlow)
• Authentication logs (Active Directory, VPN, SSO providers)
• Cloud audit logs (AWS CloudTrail, Azure Activity Logs, GCP Audit Logs)

Saat menambahkan sumber baru, verifikasi akurasi timestamp, konfirmasi parsing field sudah benar, dan periksa volume penerimaan terhadap baseline yang diharapkan. Parser yang salah konfigurasi akan diam-diam merusak deteksi tanpa melempar error, jadi periksa secara berkala raw event terhadap field yang di-parse.

Menulis dan Menyesuaikan Aturan Deteksi

Sebagian besar SIEM menggunakan beberapa bentuk correlation search atau sintaks aturan deteksi. Contoh sederhana dalam SPL Splunk mungkin terlihat seperti ini:

index=auth sourcetype=windows EventCode=4625
| stats count by user, src_ip
| where count > 10

Ini menandai akun dengan lebih dari 10 percobaan logon yang gagal, indikator brute-force klasik. Saat membangun aturan:

1. Mulai sempit, kemudian perluas berdasarkan false positive rate.
2. Petakan setiap aturan ke teknik MITRE ATT&CK untuk konteks dan pelacakan cakupan.
3. Dokumentasikan tujuan aturan, sumber data yang diharapkan, dan skenario false-positive yang diketahui.
4. Tetapkan threshold yang realistis — terlalu sensitif dan analis tenggelam dalam noise; terlalu longgar dan ancaman nyata lolos.

Alur Kerja Triage Alert

Setelah alert dikirim, pekerjaan analis adalah menjawab: apakah ini berbahaya, dan apakah memerlukan eskalasi? Checklist triage praktis:

• Validasi alert — konfirmasi bahwa peristiwa yang mendasarinya benar-benar terjadi dan bukan artifact parsing.
• Perkaya dengan konteks — periksa kritikalitas aset, peran pengguna, geolokasi IP sumber, dan alert terkait baru-baru ini pada host yang sama.
• Periksa pola — pivot pada pengguna, IP, atau hash dalam jendela waktu yang lebih luas untuk melihat apakah ini terisolasi atau bagian dari kampanye yang lebih luas.
• Klasifikasi — true positive, false positive, atau benign true positive (aktivitas nyata, tetapi tidak berbahaya, seperti script sah seorang admin).
• Eskalasi atau tutup — dokumentasikan alasan Anda; alert yang ditutup masih memerlukan justifikasi yang jelas untuk tujuan audit.

Membangun Dashboard yang Efektif

Dashboard harus menjawab pertanyaan operasional spesifik, bukan hanya terlihat mengesankan. Contoh yang berguna meliputi:

• Top failed authentication sources dalam 24 jam terakhir
• Alert volume berdasarkan severity dan penugasan analis
• Data source health (ingestion lag, drop-offs)
• Detection coverage dipetakan terhadap taktik ATT&CK

Hindari dashboard sprawl — segelintir high-signal views lebih baik daripada dua puluh panel yang jarang diperiksa.

Menangani Alert Fatigue

Alert fatigue adalah salah satu risiko operasional terbesar di SOC. Tangani dengan:

• Secara berkala meninjau alert yang ditutup untuk mengidentifikasi pola false-positive berulang.
• Menekan aktivitas yang diketahui benign dengan exception terdokumentasi (bukan penghapusan aturan blanket).
• Melacak mean time to triage dan mean time to respond sebagai metrik untuk menangkap bottleneck.
• Memutar siklus review aturan deteksi sehingga aturan yang sudah usang dan noisy diperbaiki atau dihentikan.

Dokumentasi dan Handoff

Setiap investigasi harus meninggalkan jejak: apa yang memicu alert, apa yang diperiksa, kesimpulan apa yang dicapai, dan tindakan follow-up apa pun. Ini penting untuk shift handoff, audit kepatuhan, dan membangun pengetahuan institusional yang bertahan dari pergantian analis. Template runbook sederhana per jenis alert — langkah investigasi, kontak eskalasi, dan bukti yang diharapkan — menghemat banyak waktu saat situasi sulit.

Mendapatkan Praktik Hands-On

Cara tercepat untuk membangun fluency SIEM adalah repetisi: terima sample log, tulis beberapa aturan deteksi terhadap teknik serangan yang diketahui, dan praktikkan siklus triage lengkap dari awal hingga akhir. Dataset gratis dan stack SIEM open-source (seperti Elastic Stack) adalah lingkungan low-cost yang sangat baik untuk ini.

Siap menggali lebih dalam ke blue team fundamentals? Jelajahi segmen Korra Studio terkait tentang log analysis, incident response workflows, dan detection engineering untuk terus membangun skill set SOC Anda.