SIEM Basics: Turning Raw Logs into Real Detections

Banyak tim IT yang gue temui punya masalah yang sama: mereka sudah beli SIEM, sudah streaming log dari berbagai sumber, tapi layar dashboard tetap gelap. Tidak ada deteksi yang berarti. Tidak ada alert yang actionable. Yang ada cuma kebisingan.

Masalahnya bukan di alatnya, tapi di pendekatannya. SIEM bukan tong ajaib yang otomatis menemukan serangan. Ia alat analisis yang membutuhkan masukan berkualitas dari manusia yang paham konteks.

Tulisan ini buat tim yang sudah atau mau deploy SIEM, tapi belum tahu bagaimana mengubah tumpukan log menjadi deteksi yang beneran berguna.

SIEM Itu Bukan Detektor Kejahatan Otomatis

Banyak ekspektasi yang salah tentang SIEM. Orang membayangkan alat ini seperti antivirus: install, nyalakan, dan ia akan memberi tahu kalau ada serangan. Kenyataannya, SIEM yang baru dipasang lebih mirip ruangan kosong. Ia bisa menampung banyak log, tapi tidak tahu apa yang harus dicari.

Tugas lo adalah memberitahu SIEM apa yang normal dan apa yang tidak. Ini proses yang berkelanjutan. Lo mulai dengan aturan sederhana, lo pantau hasilnya, lo perbaiki rule yang terlalu berisik, dan lo tambah rule baru seiring lo memahami lingkungan lo.

Mulai dari Sumber Log yang Tepat

Kesalahan paling umum adalah mencoba mengambil semua log dari semua sumber sekaligus. Hasilnya: biaya melonjak, pencarian lambat, dan kebisingan tidak terkendali.

Mulai dari sumber yang paling bernilai. Gue selalu merekomendasikan urutan ini untuk deployment awal:

Authentication logs adalah yang pertama. Active Directory, Azure AD, Okta, atau VPN. Hampir semua serangan melibatkan pergerakan lateral yang dimulai dengan kredensial yang dicuri. Log login mencatat siapa yang masuk, dari mana, kapan, dan apakah berhasil. Ini harta karun.

Endpoint logs adalah yang kedua. Sysmon, Windows Event Logs, atau EDR telemetry. Proses creation, network connection, file creation. Di sinilah lo bisa melihat malware dijalankan, script PowerShell mencurigakan, atau koneksi ke server command-and-control.

Network logs adalah yang ketiga. Firewall, proxy, DNS. Ini membantu lo melihat gambaran besar: kemana data dalam jaringan lo mengalir, domain apa yang diakses, dan berapa banyak data yang keluar.

Mulai dengan tiga sumber ini dulu. Bikin mereka berfungsi dengan baik sebelum menambah sumber lain.

Dari Log ke Deteksi

Setelah log masuk, lo harus menulis deteksi. Ini bagian yang paling menantang dan paling memuaskan.

Deteksi yang baik dimulai dari skenario serangan, bukan dari log yang tersedia. Jangan tanya "Apa yang bisa gue deteksi dengan log ini?" Tapi tanya "Apa yang akan dilakukan penyerang, dan log apa yang akan ia tinggalkan?"

Contoh: penyerang biasanya akan mencoba banyak password sebelum berhasil. Ini disebut password spraying. Dalam log autentikasi, ini akan terlihat sebagai banyak kejadian login gagal dari satu alamat IP ke banyak akun dalam waktu singkat. Rule lo: jika ada lebih dari 20 kegagalan login dari satu IP dalam 5 menit, alert.

Contoh lain: penyerang yang sudah di dalam sering mencoba mengakses file yang biasanya tidak diakses. Di log file server, lo bisa mendeteksi lonjakan aktivitas baca yang tidak normal. Rule lo: jika seorang pengguna mengakses lebih dari 100 file dalam 1 jam, padahal rata-ratanya 10 file per jam, alert.

Tapi deteksi bukan hanya tentang menulis rule. Ia juga tentang tuning. Setiap rule menghasilkan false positive. Lo harus melacak mana yang terlalu berisik dan menyesuaikan ambang batasnya.

False Positive Bukan Musuh

Banyak engineer menyerah karena terlalu banyak false positive. Mereka mematikan rule yang berisik, tanpa mencoba memperbaikinya. Ini kesalahan.

False positive itu informasi. Ia memberi tahu lo bahwa asumsi lo tentang "normal" masih kurang tepat. Mungkin jam kerja yang lo anggap normal ternyata lebih luas. Mungkin aplikasi tertentu melakukan koneksi yang sah tapi tidak biasa.

Catat setiap false positive. Analisis penyebabnya. Perbaiki rule-nya. Setelah beberapa iterasi, false positive akan berkurang drastis. Rule yang tadinya menghasilkan 100 alert sehari bisa turun jadi 5, dan semuanya layak diselidiki.

Use Case yang Paling Sering Berhasil

Berikut beberapa deteksi yang hampir selalu berhasil diimplementasikan di berbagai organisasi yang pernah gue bantu.

Login dari lokasi atau perangkat yang tidak biasa. Rule ini mendeteksi ketika seorang pengguna login dari lokasi geografis yang belum pernah mereka gunakan sebelumnya, atau dari perangkat yang tidak dikenal. Butuh baseline beberapa minggu, tapi setelahnya sangat efektif.

Pembuatan akun baru yang diikuti dengan penambahan ke grup admin. Ini pola klasik penyerang yang sudah mendapat akses dan mencoba mempertahankan foothold.

Lalu lintas keluar dalam jumlah besar. Penyerang yang mencuri data akan mengirimkannya keluar. Traffic keluar yang tiba-tiba naik 10 kali lipat dari baseline adalah indikasi kuat data exfiltration.

Penghapusan log. Penyerang yang cerdas akan mencoba menghapus jejak. Alert untuk setiap penghapusan event log, atau penghentian layanan logging.

PowerShell dengan koneksi jaringan. Banyak malware menggunakan PowerShell untuk mengunduh payload. Blokir eksekusi PowerShell dengan koneksi keluar dari akun yang tidak membutuhkannya.

Membangun Budaya Deteksi

SIEM tidak akan berhasil tanpa orang yang peduli. Deteksi bukan pekerjaan satu orang, tapi budaya tim.

Jadwalkan review rutin. Seminggu sekali, duduk bersama tim, buka alert yang muncul, bahas mana yang benar dan mana yang salah. Dari diskusi ini, ide rule baru sering muncul.

Dorong semua orang di tim IT untuk berkontribusi. Developer yang paham aplikasi bisa memberi masukan tentang log mana yang penting. Network engineer bisa menjelaskan pola trafik normal. Semua orang punya potongan puzzle.

Penutup

SIEM adalah investasi jangka panjang. Ia tidak akan sempurna di bulan pertama, atau bulan ketiga, atau bahkan tahun pertama. Tapi setiap rule yang ditambahkan, setiap false positive yang diperbaiki, setiap deteksi yang berhasil — semua itu membangun fondasi pertahanan yang semakin kokoh.

Mulai dari log autentikasi. Tulis satu rule sederhana minggu ini. Lihat hasilnya. Perbaiki minggu depan. Setahun dari sekarang, lo akan punya sistem deteksi yang lo bangun sendiri, yang paham lingkungan lo lebih baik dari alat apapun yang bisa lo beli.

#SIEM #SOC #Cybersecurity #Monitoring #InfoSec

Kesalahan Fatal dalam Deployment SIEM

Beberapa kesalahan yang gue lihat berulang kali dan dampaknya selalu mahal.

Tidak menetapkan retention policy sejak awal. Log menumpuk, storage membengkak, dan biaya meledak. Tentukan berapa lama setiap jenis log disimpan. Authentication log mungkin perlu 90 hari, sementara DNS log cukup 30 hari.

Tidak memvalidasi kelengkapan log. Lo kira semua log masuk, tapi ternyata agen di beberapa server mati diam-diam. Audit sumber log secara berkala. Pastikan setiap perangkat yang seharusnya mengirim log benar-benar mengirim.

Membangun dashboard tanpa deteksi. Dashboard yang bagus itu indah, tapi tidak mencegah serangan. Dashboard adalah produk sampingan, bukan tujuan. Fokus ke alert dulu, dashboard nanti.

Mengabaikan konteks bisnis. Alert yang sama bisa berarti berbeda di lingkungan yang berbeda. Di bank, akses ke database nasabah di luar jam kerja adalah kritis. Di startup, mungkin itu normal. Kenali bisnis lo sebelum menulis rule.

Lab untuk Berlatih

Kalau lo belum punya SIEM di tempat kerja, lo bisa mulai belajar dengan alat gratis.

Wazuh adalah platform open source yang menggabungkan SIEM dan endpoint monitoring. Bisa dipasang di mesin virtual dan diisi log dari lab lo sendiri. Mulai dari sini untuk belajar korelasi rule dan alerting.

Elastic Stack juga bisa dikonfigurasi sebagai SIEM. Elasticsearch untuk menyimpan, Logstash untuk mengolah, Kibana untuk visualisasi. Semuanya punya tier gratis.

Security Onion adalah distro Linux yang sudah dibundle dengan banyak alat keamanan, termasuk SIEM. Cocok untuk lab dan belajar.

#SIEM #SOC #Cybersecurity #Monitoring #InfoSec