Strategi Meningkatkan Efisiensi Deteksi pada SIEM
Pada tahun 2024 ini, mulai banyak perusahaan atau organisasi yang sudah mulai aware terhadap SIEM. Namun di sisi lain, banyak organisasi yang perlu aware bahwa tidak bisa hanya mengandalkan built-in detection rules dari SIEM karena terbatas. Sisanya tetap perlu untuk dimanage sendiri secara continuous.
Survey diatas sekaligus sebagai awareness perkembangan tren terkini. Dari hasil survey global diluar sana, kalau saya hitung rata-rata sekitar 53.7% responden, memiliki kurang dari 50% detection rules yang dibuat oleh tim internal mereka. Alias lebih dari setengah dari perusahaan tersebut mengandalkan detection rules yang disediakan oleh vendor atau pihak ketiga. Dan rata-rata 46.3% responden memiliki lebih dari 50% detection rules yang dibuat oleh tim internal mereka.
Nah.. Untuk menjadikan SIEM menjadi tools yang sangat berguna, perlu adanya peningkatan kualitas detection rules.
Beberapa poin yang memberikan dampak kualitas Detection :
- Asset Awareness: Adanya checklist Aset dan tools apa aja yang dimiliki secara detail, termasuk memiliki checklist detection rules yang sudah dimiliki secara detail (termasuk versi detection logic kapan terakhir update, tracking issue detection, QA tracking, dll.)
- Prioritas : Aset yang paling critical, atau juga bisa membuat Detection rules CVE baru muncul dalam satu hari/minggu/bulan/tahun terakhir, disesuaikan dengan aset yang dimiliki untuk dijadikan deteksi.
- Strategi logging : Kira-kira bila ada use case untuk mendeteksi X, apakah bisa kita lihat lognya secara lengkap (yang penting untuk analisis) dan bagaimana strategi kita untuk data yang bersifat junk? semakin banyak junk log atau log yang sifatnya kurang dibutuhkan akan semakin lama untuk melakukan incident response ketika ada threat dan mungkin insiden tersebut bisa terlewat dari sepengetahuan kita. Mencari Forensic Readyness dari data sources yang dimiliki.
- Pastikan bahwa informasi timestamp setiap log jelas dan GMT +7 yang sama agar tidak memperlambat investigasi karena timestamp. Tujuannya agar membentuk timeline saat membuat report investigasi.
- Mengambil data log yang dibutuhkan saja, jam terbang akan sangat berpengaruh untuk menentukan data tersebut penting atau tidak.
- Kualitas Data akan berpengaruh pada akurasi deteksi. Data harus dipastikan benar-benar ready saat menjadi alert yang valid, kemudian tim SOC dapat langsung melakukan investigasi, triaging atau mungkin sampai Incident Response secara cepat dan tepat. Perlu diketahui bahwa insiden datang sewaktu-waktu dan tidak terduga. Sebagai mindset Defender, kita harus cepat dan tepat menghentikan serangan.
- Memetakan kebutuhan deteksi dari MITRE ATT&CK atau Sigma rules yang berfokus pada TTP, dapat juga di combine menggunakan Yara, STIX, dll. sesuai kebutuhan. Apabila memang waktu terbatas dan MITRE terlalu luas, dapat melakukan prioritas hanya membuat detection rules pada TTP yang paling banyak digunakan attacker. Bisa dicombine juga menggunakan LLM seperti ChatGPT, dll.
- Detection Gap Awareness : Apakah ada blindspot/cara lain untuk mendeteksi? rules apa saja yang belum dimiliki?
- Goal driven : Meskipun mungkin security tools atau endpoint tidak memiliki dokumentasi yang memadai, tetap dapat dilakukan dengan mencari “data readyness”
- Mendapatkan insight dari bidang CTI (Cyber Threat Intelligence) akan sangat penting untuk membuat detection rules secara tepat selain IoC, Banyak referensi seperti hipotesa, skenario serangan. Dapat juga dikombinasikan dengan report malware analysis, APT analisis yang dishare secara public dari blog atau apapun. Apabila sumbernya kurang jelas perlu dicek lebih lanjut, karena bisa jadi menyebabkan bias.
- Melakukan kolaborasi dengan tim Pentest untuk membuat Detection Rules, memahami alur attack (red teaming) baik sering membaca report pentest maupun hasil deteksi yang dilakukan sendiri. Bisa juga di detailkan menjadi kegiatan Purple teaming, sampai Ngelab membuat simulasi attack & detect.
- Melakukan dokumentasi. Gunanya ketika ada tim baru langsung dapat mudah bergabung. Playbook ketika ada alert serupa (berguna untuk proses deteksi). Apabila tidak keberatan, bisa juga mengadopsi ticketing sistem seperti trello, jira, monday, dll. menyesuaikan budget.
- Membangun Metode Detection.
Strategi & timeline deployment Detection Rules ini:
a. seberapa lama & seberapa banyak,
b. seberapa banyak target Mean time to detect, true positive & false positive detection,
c. visualisasi data/dashboard untuk menyampaikan informasi yang efektif - Built-in rules detection dari SIEM saja tidak cukup, perlu ambil dari tempat lain atau membuat sendiri sesuai kebutuhan perusahaan. Apalagi bila hanya mengandalkan dari vendor, tidak akan sesuai dengan kebutuhan karena mungkin saja informasinya kurang lengkap,dst.
- Biasanya memiliki sifat never ending process, alias Continuous detect & validate. Kalau rules tidak up-to-date, SIEM akan memiliki gap.
- Belajar & mengupdate ilmu sebagai detection engineer/DFIR/Threat Hunting melalui platform manapun.
Tantangan
Yang menjadi kelemahan disini adalah :
Waktu kita yang terbatas satu detection rules bila custom butuh waktu berhari-hari untuk memastikan true positive dan sesuai keinginan, mungkin kita tidak dapat berfokus ke Detection Rules setiap hari dan belum sempat mengkaji/mengupdate rules. Budget & People kita juga terbatas, apalagi bila belum memiliki SOC, hanya bisa mengandalkan automate yang juga perlu waktu untuk melakukan setupnya. Beberapa case lain terlalu banyak false positive dan terlalu dibanjiri dengan log yang kurang penting.
Feel free to Reply bila ada masukan :D
References & Inspirasi