🔐 SIEM — Security Information and Event Management

📌 DAFTAR ISI

1. Apa Itu SIEM?
2. Sejarah & Evolusi SIEM
3. Mengapa SIEM Dibutuhkan?
4. Arsitektur SIEM
5. Komponen Utama SIEM
6. Cara Kerja SIEM — End to End
7. Log Management & Event Collection
8. Normalisasi & Parsing Log
9. Korelasi Event
10. Alerting & Detection
11. SIEM dan SOAR
12. Use Cases SIEM di Dunia Nyata
13. SIEM di SOC (Security Operations Center)
14. Perbandingan Produk SIEM
15. Generasi SIEM — Dari Tradisional ke Next-Gen
16. Tantangan & Keterbatasan SIEM
17. Best Practices Implementasi SIEM
18. SIEM, XDR, dan MXDR — Apa Bedanya?
19. Masa Depan SIEM

1. Apa Itu SIEM?

SIEM adalah singkatan dari Security Information and Event Management — sebuah platform atau sistem yang menggabungkan dua disiplin keamanan yang berbeda:

• SIM (Security Information Management): Fokus pada pengumpulan, penyimpanan jangka panjang, dan analisis log keamanan dari berbagai sumber untuk keperluan compliance dan audit.
• SEM (Security Event Management): Fokus pada pemantauan event keamanan secara real-time, korelasi event, dan alerting terhadap ancaman aktif.

Penggabungan keduanya menghasilkan SIEM — sebuah sistem yang mampu mengumpulkan, menyimpan, menormalisasi, mengkorelasikan, menganalisis, dan melaporkan event keamanan dari seluruh infrastruktur IT secara terpusat.

Definisi Sederhana

Bayangkan sebuah perusahaan besar dengan ratusan server, ribuan laptop karyawan, puluhan aplikasi web, firewall, router, switch, dan database. Setiap perangkat ini menghasilkan log — catatan tentang apa yang terjadi, kapan terjadi, dan siapa yang melakukannya. Tanpa SIEM, log-log ini tersebar di mana-mana, sulit dibaca secara bersamaan, dan hampir mustahil untuk dianalisis secara manual.

SIEM hadir sebagai pusat komando yang mengumpulkan semua log tersebut, memahami konteksnya, dan memberi tahu tim keamanan ketika ada sesuatu yang mencurigakan — sebelum terlambat.

Dua Fungsi Inti

Security Information (SI) mencakup aspek pengelolaan data keamanan:

• Pengumpulan dan agregasi log dari semua sumber
• Penyimpanan jangka panjang untuk kebutuhan compliance (GDPR, ISO 27001, PCI DSS, dll.)
• Laporan audit yang dapat dipertanggungjawabkan secara hukum
• Forensik pasca-insiden — apa yang terjadi, kapan, dan oleh siapa

Event Management (EM) mencakup aspek pemantauan aktif:

• Real-time monitoring terhadap event keamanan
• Korelasi event dari berbagai sumber untuk mendeteksi pola serangan
• Alert otomatis ketika threshold atau rule terpenuhi
• Prioritisasi ancaman berdasarkan severity

2. Sejarah & Evolusi SIEM

Era Awal (1990-an): Log Management Sederhana

Pada awal era internet korporat, keamanan IT masih sangat sederhana. Perusahaan mulai menyadari perlunya menyimpan log dari server dan perangkat jaringan, namun semua masih manual. Sysadmin membaca log file langsung di server, dan analisis dilakukan setelah kejadian terjadi.

Masalah utama era ini: volume log yang terus bertumbuh melebihi kapasitas manusia untuk membacanya. Tidak ada cara sistematis untuk menemukan event keamanan di antara jutaan baris log sistem.

Kelahiran SEM dan SIM (Akhir 1990-an — 2000-an Awal)

Dua produk kategori lahir hampir bersamaan:

SEM (Security Event Management) berfokus pada real-time correlation — mengumpulkan event dari berbagai perangkat dan mencari pola yang menunjukkan serangan aktif. Produk pionir seperti NetForensics dan ArcSight (versi awal) hadir di era ini.

SIM (Security Information Management) berfokus pada log storage dan compliance reporting. Perusahaan membutuhkan bukti audit untuk regulasi yang mulai bermunculan (HIPAA, SOX, dsb.). Produk seperti Intellitactics hadir mengisi kebutuhan ini.

Lahirnya Istilah SIEM (2005)

Pada tahun 2005, analis dari Gartner — Mark Nicolett dan Amrit Williams — pertama kali memperkenalkan istilah SIEM dalam sebuah research note. Mereka menggambarkan perlunya konvergensi SIM dan SEM menjadi satu platform terintegrasi.

Tahun yang sama, PCI DSS (Payment Card Industry Data Security Standard) mulai mewajibkan log monitoring dan review — ini menjadi driver utama adopsi SIEM oleh perusahaan yang memproses data kartu kredit.

Era Kematangan (2005–2015)

Pemain besar masuk dan mengakuisisi startup:

• HP mengakuisisi ArcSight (2010, senilai $1,5 miliar)
• IBM mengakuisisi Q1 Labs (pembuat QRadar, 2011)
• Intel/McAfee mengakuisisi NitroSecurity (2011)
• Splunk go public (2012) dan mendominasi pasar dengan pendekatan berbasis search

Era ini ditandai dengan SIEM on-premises yang besar, mahal, dan kompleks. Hanya perusahaan enterprise dengan tim keamanan dedicated yang mampu mengoperasikannya secara efektif.

Era Cloud & Next-Gen (2015–Sekarang)

Dengan migrasi infrastruktur ke cloud, SIEM tradisional on-premises mulai ketinggalan. Kebutuhan baru muncul:

• Ingest log dari cloud workload (AWS, Azure, GCP)
• Skalabilitas elastis tanpa batas
• Model biaya yang lebih fleksibel
• Integrasi dengan threat intelligence dan AI/ML

Microsoft Sentinel (2019) menjadi pionir cloud-native SIEM yang sepenuhnya berjalan di atas Azure. Diikuti oleh Google Chronicle, Elastic SIEM, dan versi cloud dari vendor lama.

Tren terkini: SIEM mulai berkonvergensi dengan XDR (Extended Detection and Response) dan SOAR, membentuk platform security operations yang lebih holistik.

3. Mengapa SIEM Dibutuhkan?

Problem Statement: Kompleksitas Infrastruktur Modern

Infrastruktur IT perusahaan modern sangat berbeda dari 20 tahun lalu. Dulu, semuanya ada di dalam gedung — server di data center, karyawan di kantor, jaringan yang terbatas di area fisik. Sekarang:

• Karyawan bekerja dari mana saja (remote work)
• Data ada di multiple cloud provider (AWS, Azure, GCP) sekaligus
• Aplikasi ada yang on-premises, ada yang SaaS (Salesforce, Google Workspace, M365)
• Perangkat yang terhubung bukan hanya laptop dan desktop, tapi juga smartphone, IoT devices, OT/ICS systems
• Supply chain yang kompleks — vendor, contractor, partner punya akses ke sistem internal

Setiap komponen ini menghasilkan log. Setiap koneksi meninggalkan jejak. Tanpa sistem terpusat untuk mengolah semua ini, blind spot sangat besar.

Ancaman yang Semakin Canggih

Serangan siber modern tidak terjadi dalam satu langkah. Mereka mengikuti kill chain yang panjang dan tersebar lintas waktu:

Seorang attacker mungkin memulai dengan spear phishing ke satu karyawan biasa pada bulan Januari. Berhasil masuk, mereka diam-diam mempelajari jaringan selama beberapa minggu. Pada bulan Februari, mereka mencuri credential administrator menggunakan Mimikatz. Pada bulan Maret, mereka mulai exfiltrate data secara perlahan agar tidak terdeteksi.

Tidak ada satu pun langkah di atas yang akan terdeteksi jika dilihat secara terisolasi. Email phishing mungkin lolos filter. Credential theft mungkin tidak ada alertnya. Data exfiltration mungkin terlihat seperti traffic normal.

Hanya dengan menghubungkan dots dari berbagai sumber log — email gateway, endpoint, AD, firewall, DLP — pola serangan ini bisa terlihat. Itulah fungsi inti SIEM.

Kebutuhan Compliance & Regulasi

Banyak regulasi industri dan pemerintah mewajibkan log monitoring dan penyimpanan:

• PCI DSS (kartu kredit): Wajib memonitor semua akses ke data kardholder, menyimpan log minimal 12 bulan
• HIPAA (kesehatan, AS): Wajib audit trail untuk semua akses data kesehatan pasien
• GDPR (data pribadi, Eropa): Wajib bisa mendeteksi dan melaporkan data breach dalam 72 jam
• ISO 27001: Mensyaratkan log management sebagai control keamanan
• SOX (keuangan, AS): Wajib menjaga integritas laporan keuangan, termasuk audit trail sistem IT
• OJKSEOJK/BI (Indonesia): Regulasi keamanan untuk industri keuangan mewajibkan monitoring dan logging

SIEM membantu organisasi membuktikan compliance melalui laporan audit yang tersentralisasi dan dapat ditelusuri.

ROI dan Efisiensi Operasional

Tanpa SIEM, setiap investigasi keamanan memakan waktu lama karena analyst harus mengumpulkan log dari berbagai sumber secara manual — SSH ke server ini, akses dashboard itu, download log dari sana, gabungkan secara manual di spreadsheet. Proses yang harusnya butuh 30 menit bisa memakan berjam-jam atau berhari-hari.

Dengan SIEM, semua log sudah ada di satu tempat, bisa di-query dalam hitungan detik, dan korelasi dilakukan otomatis. MTTD (Mean Time to Detect) dan MTTR (Mean Time to Respond) bisa dipangkas secara signifikan.

4. Arsitektur SIEM

Gambaran Besar Arsitektur

SIEM pada intinya adalah pipeline data keamanan — data masuk dari berbagai sumber, diproses melalui beberapa lapisan, dan akhirnya menghasilkan insight yang dapat ditindaklanjuti.

┌─────────────────────────────────────────────────────────┐
│                    DATA SOURCES                         │
│  Endpoints │ Network │ Cloud │ Apps │ Identity │ Others  │
└─────────────────────────┬───────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────┐
│                  COLLECTION LAYER                       │
│    Agents │ Agentless │ Syslog │ API │ Connectors       │
└─────────────────────────┬───────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────┐
│              PROCESSING & NORMALIZATION                 │
│        Parsing │ Normalization │ Enrichment             │
└─────────────────────────┬───────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────┐
│               STORAGE LAYER                             │
│    Hot Storage (recent) │ Cold Storage (archive)        │
└─────────────────────────┬───────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────┐
│              ANALYTICS ENGINE                           │
│   Correlation Rules │ ML/AI │ UEBA │ Threat Intel       │
└─────────────────────────┬───────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────┐
│             PRESENTATION & ACTION LAYER                 │
│  Dashboards │ Alerts │ Incidents │ Reports │ Automation  │
└─────────────────────────────────────────────────────────┘

Model Deployment SIEM

On-Premises SIEM SIEM diinstall dan dioperasikan di data center milik sendiri. Semua hardware, software, storage, dan kapasitas processing dikelola sendiri.

Kelebihan: Kontrol penuh atas data, tidak bergantung pada pihak ketiga, cocok untuk organisasi dengan regulasi data ketat (bank, pemerintah, militer).

Kekurangan: Biaya awal (CapEx) sangat tinggi, butuh tim dedicated untuk maintenance, scaling sulit dan mahal, update dan patch harus dilakukan sendiri.

Cloud-Native SIEM SIEM berjalan sepenuhnya di cloud. Contoh: Microsoft Sentinel (Azure), Google Chronicle (GCP), Elastic Cloud SIEM.

Kelebihan: Tidak butuh hardware, scaling otomatis dan elastis, biaya OpEx (bayar sesuai pakai), update otomatis, integrasi native dengan layanan cloud.

Kekurangan: Data ada di pihak ketiga (perlu pertimbangan data sovereignty), biaya bisa tidak terduga jika volume log besar, butuh koneksi internet yang handal.

Hybrid SIEM Kombinasi on-premises dan cloud. Beberapa data sensitif tetap on-premises, sementara kapasitas overflow atau data non-sensitif dikirim ke cloud.

Cocok untuk: Organisasi dalam transisi dari on-prem ke cloud, atau yang punya regulasi mixed (sebagian data wajib on-prem, sebagian boleh cloud).

Managed SIEM (MSSPs) SIEM dioperasikan oleh pihak ketiga (Managed Security Service Provider). Organisasi hanya mengkonsumsi layanan monitoring dan response, tidak perlu mengelola platform sendiri.

Cocok untuk: Organisasi kecil-menengah yang tidak punya tim keamanan internal, atau sebagai augmentasi untuk tim yang terbatas.

5. Komponen Utama SIEM

1. Log Collector / Data Collector

Ini adalah lapisan pertama — komponen yang bertanggung jawab mengambil log dari berbagai sumber dan mengirimkannya ke SIEM. Ada beberapa pendekatan:

Agent-Based Collection: Software agent diinstall di setiap host (server, laptop, workstation). Agent ini memantau log secara lokal dan mengirimkannya ke SIEM secara real-time atau batch. Keunggulannya adalah kemampuan collect log bahkan ketika host tidak langsung bisa dihubungi dari SIEM, bisa melakukan pre-filtering lokal, dan lebih andal. Kelemahannya adalah overhead deployment dan management agent di ratusan/ribuan host.

Agentless Collection: SIEM secara langsung mengambil (pull) log dari sumber tanpa perlu agent. Caranya bisa via Syslog (UDP/TCP), WMI (Windows Management Instrumentation), SNMP, atau REST API. Lebih mudah di-deploy tapi kurang fleksibel dalam hal filtering dan transformasi.

API-Based Collection: Terutama untuk sumber cloud dan SaaS modern. SIEM menggunakan API dari vendor (misalnya Microsoft Graph API untuk M365, AWS CloudTrail API) untuk mengambil event secara periodik atau via webhook.

Stream-Based Collection: Untuk volume sangat tinggi, SIEM bisa menerima data via message queue seperti Apache Kafka atau Azure Event Hub, yang memungkinkan ingestion jutaan event per detik tanpa bottleneck.

2. Event Processor / Normalization Engine

Setelah data masuk, SIEM harus memahaminya. Tantangannya adalah setiap vendor dan sistem memiliki format log yang berbeda-beda:

• Windows Event Log punya format XML dengan EventID dan channel tertentu
• Linux Syslog punya format plain text dengan priority dan facility
• Cisco ASA punya format proprietary dengan kode-kode tertentu
• Palo Alto punya format CSV dengan kolom tertentu
• AWS CloudTrail punya format JSON dengan struktur tertentu

Normalization engine memparse semua format ini dan mengubahnya menjadi skema yang seragam sehingga bisa dikueri dan dikorerelasikan secara konsisten.

3. Storage Engine

Log yang sudah dinormalisasi disimpan untuk dua tujuan: real-time analysis dan long-term retention.

Hot Storage (short-term, high-performance): Data terbaru (umumnya 30-90 hari) disimpan di storage yang cepat — SSD atau in-memory database — untuk memungkinkan query real-time yang responsif.

Warm Storage (medium-term): Data yang lebih tua tapi masih mungkin dibutuhkan (3-12 bulan) disimpan di storage yang lebih murah tapi masih bisa di-query, meskipun lebih lambat.

Cold/Archive Storage (long-term): Data lama (1-7+ tahun) untuk compliance dan legal hold. Biasanya di object storage yang sangat murah (seperti Azure Blob, AWS S3 Glacier). Query sangat lambat, tapi biayanya minimal.

4. Correlation Engine

Ini adalah "otak" SIEM. Correlation engine menerima stream event yang sudah dinormalisasi dan menerapkan rules untuk menemukan pola yang menunjukkan ancaman keamanan.

Ada beberapa pendekatan korelasi:

Rule-Based Correlation: Aturan if-then yang didefinisikan manual oleh tim keamanan. "Jika dalam 5 menit ada lebih dari 10 login gagal dari IP yang sama ke akun yang berbeda, maka ini password spray."

Statistical Correlation: Deteksi berdasarkan penyimpangan statistik dari baseline. "Volume outbound traffic dari host ini 10x lebih besar dari rata-rata minggu lalu — anomali."

Temporal Correlation: Korelasi event berdasarkan urutan waktu. "Jika A terjadi, kemudian B terjadi dalam 1 jam, kemudian C terjadi — ini adalah pola serangan X."

Machine Learning: Model ML yang belajar dari data historis untuk mendeteksi pola yang tidak bisa didefinisikan secara manual — misalnya mendeteksi insider threat yang perlahan-lahan mengeksfiltrasi data.

5. Alert & Case Management

Ketika correlation engine menemukan sesuatu, ia menghasilkan alert. Alert management menentukan bagaimana alert ini dikelola:

• Alert diberi priority/severity berdasarkan konteks
• Alert yang saling berkaitan digabungkan menjadi satu incident atau case
• Incident di-assign ke analyst yang bertanggung jawab
• Workflow investigasi difasilitasi (tambah komentar, attach evidence, track status)
• Escalation path didefinisikan (Tier 1 → Tier 2 → CSIRT → Management)

6. Reporting & Dashboard Engine

SIEM menghasilkan berbagai laporan dan visualisasi:

Operational Dashboards: Real-time view untuk SOC analyst — alert terbaru, incident yang sedang aktif, status sistem.

Executive Dashboards: High-level metrics untuk CISO dan manajemen — trend serangan, MTTD/MTTR, compliance status.

Compliance Reports: Laporan terstruktur untuk audit — misalnya laporan semua akses ke data sensitif selama satu bulan, atau laporan semua perubahan konfigurasi firewall.

Forensic Reports: Detail timeline event untuk keperluan investigasi atau pembuktian hukum.

6. Cara Kerja SIEM — End to End

Untuk memahami cara kerja SIEM secara holistik, mari ikuti perjalanan sebuah serangan dari perspektif SIEM:

Skenario: Serangan Credential Stuffing → Lateral Movement

Langkah 1: Log Collection

Setiap detik, ribuan log mengalir masuk ke SIEM dari berbagai sumber:

• Firewall mencatat setiap koneksi masuk dan keluar
• Active Directory mencatat setiap login attempt
• Email gateway mencatat setiap email yang masuk dan keluar
• Endpoint agent mencatat setiap proses yang berjalan

Langkah 2: Normalisasi

Log dari firewall Palo Alto, Active Directory Windows, dan endpoint Carbon Black semuanya punya format berbeda. SIEM memparse dan menormalisasikannya ke skema yang sama — misalnya semua event login memiliki field: timestamp, source_ip, destination_ip, username, status (success/failure), auth_method.

Langkah 3: Enrichment

Setelah normalisasi, SIEM menambahkan konteks:

• Lookup GeoIP: IP sumber ternyata dari Romania
• Lookup Threat Intel: IP tersebut ada di beberapa blocklist sebagai sumber brute force
• Lookup Asset Database: User yang di-target adalah finance director
• Lookup HR System: User ini sedang cuti di luar negeri (tapi bukan di Romania)

Langkah 4: Correlation

Correlation engine melihat pola:

• Dalam 10 menit, ada 847 login gagal ke portal VPN dari IP Romania tersebut
• Semua mencoba username yang berbeda-beda (password spray pattern)
• Kemudian, tiba-tiba ada satu login berhasil — ke akun finance director
• Satu menit setelah login berhasil, ada akses ke shared drive finance yang tidak pernah diakses account ini sebelumnya

Rule korelasi mengenali pola ini sebagai credential stuffing berhasil dan segera generate alert dengan severity CRITICAL.

Langkah 5: Alert & Incident Creation

SIEM membuat incident yang menggabungkan semua alert terkait:

• Alert 1: Password spray dari IP Romania (Medium severity)
• Alert 2: Successful login from anomalous location (High severity)
• Alert 3: Unusual file access after suspicious login (High severity)
• Alert FUSED: Credential stuffing + Unauthorized Data Access (CRITICAL)

Langkah 6: Notification & Escalation

SIEM secara otomatis:

• Mengirim notifikasi ke Slack channel #soc-critical
• Membuat tiket di ServiceNow
• Mengirim email ke on-call analyst
• Jika terintegrasi SOAR: otomatis blokir IP Romania di firewall, suspend session VPN user, kirim peringatan ke finance director

Langkah 7: Investigation

SOC analyst membuka incident di SIEM, melihat timeline lengkap, query log tambahan untuk memahami apa yang diakses, berapa lama attacker di dalam jaringan, apakah ada lateral movement, dan apakah data sudah diekstrak.

Langkah 8: Response & Closure

Setelah investigasi selesai, aksi containment dilakukan, akun di-reset, session diterminasi, dan incident ditutup dengan dokumentasi lengkap tentang apa yang terjadi, bagaimana ditemukan, dan apa yang dilakukan.

7. Log Management & Event Collection

Jenis-Jenis Log yang Di-collect SIEM

Authentication & Access Logs: Semua event login — berhasil atau gagal, ke sistem apa, dari perangkat mana, dari lokasi mana. Ini adalah sumber data paling penting untuk mendeteksi credential-based attack.

Network Traffic Logs: Log dari firewall, router, switch, proxy, dan IDS/IPS. Mencakup informasi koneksi (source IP, destination IP, port, protocol, bytes transferred, action allow/deny). Berguna untuk mendeteksi C2 communication, lateral movement, dan exfiltration.

Endpoint Logs: Log dari sistem operasi (Windows Event Log, Linux Syslog), termasuk process creation, file operations, registry changes, dan service installations. Sangat detail dan penting untuk forensik endpoint.

Application Logs: Log dari aplikasi bisnis — ERP, CRM, web application, database. Berguna untuk mendeteksi abuse of application functionality, SQL injection, dan unauthorized data access.

Cloud Logs: Log dari platform cloud — AWS CloudTrail, Azure Activity Log, GCP Audit Log. Mencakup semua operasi di cloud: siapa membuat/menghapus resource apa, kapan, dan dari mana.

Identity Logs: Log dari identity provider — Active Directory, Azure AD, Okta, LDAP. Mencakup user creation/deletion, group membership changes, password changes, MFA events.

Email Logs: Log dari email gateway dan mail server. Berguna untuk mendeteksi phishing, business email compromise, dan malware delivery via email.

DNS Logs: Query dan response DNS. Berguna untuk mendeteksi DNS tunneling, C2 via DNS, dan domain generation algorithm (DGA) malware.

Security Tool Logs: Log dari endpoint security (antivirus, EDR), IDS/IPS, WAF, DLP. Ini adalah log yang sudah "pre-processed" dan biasanya high-fidelity.

Volume dan Scaling Challenge

Volume log bisa sangat besar. Sebuah perusahaan menengah bisa menghasilkan 1-10 GB log per hari. Enterprise besar bisa menghasilkan terabyte log per hari. Tidak semua log ini sama nilainya untuk keamanan.

Strategi efisiensi log collection:

Filtering di sumber sebelum dikirim ke SIEM — misalnya dari Windows Event Log, hanya kirim event ID yang relevan untuk keamanan, bukan semua event operasional. Ini bisa mengurangi volume 70-80% tanpa kehilangan informasi keamanan penting.

Sampling untuk log volume sangat tinggi yang bersifat repetitif — misalnya log akses web yang normal hanya perlu sampel representatif, bukan 100% record.

Tiering berbasis nilai — log high-value (authentication, security tool alerts) disimpan di hot storage sepenuhnya; log medium-value (network flow) bisa disampling atau disimpan di cold storage lebih cepat.

8. Normalisasi & Parsing Log

Mengapa Normalisasi Penting?

Setiap vendor menulis log dengan caranya sendiri. Cisco mencatat login failure dengan satu format, Microsoft dengan format lain, Linux dengan format lain lagi. Tanpa normalisasi, tidak mungkin menulis satu rule korelasi yang bekerja di semua sumber.

Contoh konkret: Sebuah login failure dari Windows Event Log tertulis sebagai:

EventID: 4625, Account Name: jsmith, Failure Reason: Unknown user name or bad password, Source Network Address: 192.168.1.100

Login failure yang sama dari Cisco ASA tertulis sebagai:

%ASA-6-302013: TCP connection 1234 for outside:203.0.113.5/54321 to inside:10.0.0.1/443, username: jsmith, reason: Authen failed

Dan dari Palo Alto:

type=AUTH,subtype=FAILED,src=203.0.113.5,user=jsmith,authpolicy=VPN-Policy,normalize-user=jsmith@company.com

Setelah normalisasi, ketiganya akan memiliki representasi yang sama dalam skema SIEM:

• event_type: authentication_failure
• source_ip: [IP address]
• username: jsmith
• timestamp: [waktu]
• destination: [sistem target]

Dengan normalisasi, satu rule korelasi "lebih dari 10 authentication_failure dari IP yang sama dalam 5 menit" bisa bekerja untuk semua sumber sekaligus.

Common Event Format (CEF) dan Syslog

Syslog adalah protokol standar untuk pengiriman log, terutama di dunia Unix/Linux dan perangkat jaringan. Syslog mendefinisikan format dasar (facility, severity, timestamp, hostname, message) tapi tidak mengatur isi pesan — setiap vendor masih bebas menulis message field dengan caranya sendiri.

CEF (Common Event Format) adalah standar yang dikembangkan oleh ArcSight untuk menyediakan format yang lebih terstruktur. Banyak vendor security mendukung CEF, membuat integrasi dengan SIEM lebih mudah.

LEEF (Log Event Extended Format) adalah standar serupa yang dikembangkan oleh IBM untuk QRadar.

Trend terbaru adalah log dalam format JSON — lebih mudah di-parse oleh sistem modern dan lebih ekspresif untuk data yang kompleks. Hampir semua cloud service menggunakan JSON untuk log mereka.

9. Korelasi Event

Konsep Dasar Korelasi

Korelasi adalah proses menghubungkan event-event yang secara individual tampak tidak berbahaya, tapi secara bersama-sama membentuk pola serangan.

Analogi sempurna: Seorang satpam bank yang hanya melihat seseorang masuk ke ATM vestibule mungkin tidak curiga. Seseorang yang memfoto interior mungkin tidak curiga. Seseorang yang bertanya jam operasional kasir mungkin tidak curiga. Tapi jika satu orang melakukan ketiganya dalam satu hari, lalu kembali lagi keesokan harinya — ini mencurigakan. Korelasi SIEM bekerja persis seperti ini.

Tipe-Tipe Korelasi

Korelasi Berbasis Threshold (Simple) Paling sederhana — alert ketika satu jenis event melewati ambang batas tertentu. Misalnya: lebih dari 5 login gagal dalam 1 menit dari IP yang sama.

Kelebihan: Mudah dibuat, mudah dipahami, low false negative. Kekurangan: High false positive jika threshold tidak dikalibrasi dengan baik, mudah di-evade oleh attacker (slow-and-low attack di bawah threshold).

Korelasi Multi-Event (Sequence) Alert ketika serangkaian event terjadi dalam urutan tertentu dalam window waktu. Misalnya: (1) login gagal berkali-kali → (2) login berhasil dari IP yang sama → (3) akses ke folder sensitif dalam 10 menit.

Lebih kuat dari threshold biasa karena menangkap narasi serangan, bukan hanya satu event tunggal.

Korelasi Cross-Source (Multi-vector) Menghubungkan event dari sumber yang berbeda-beda. Misalnya: email phishing diterima (dari email gateway) → link di-klik (dari web proxy) → executable di-download (dari web proxy) → proses baru berjalan (dari endpoint agent) → koneksi ke IP asing (dari firewall).

Ini adalah kemampuan yang paling membedakan SIEM dari tool monitoring individual — hanya SIEM yang punya visibility ke semua sumber sekaligus.

Korelasi Temporal (Time-Based) Menghubungkan event berdasarkan urutan waktu dan jarak waktu. "Jika A terjadi, kemudian dalam 1 jam terjadi B, kemudian dalam 24 jam terjadi C" — ini bisa mendeteksi serangan yang disengaja dilakukan perlahan untuk menghindari deteksi berbasis rate.

Korelasi Berbasis Entitas (Entity-Based) Melacak semua aktivitas dari satu entitas (user, host, IP) dan mendeteksi anomali dari perspektif entitas tersebut. "User ini biasanya hanya login dari Jakarta, tapi hari ini login dari Amsterdam — anomali lokasi."

Ini adalah fondasi dari UEBA (User and Entity Behavior Analytics).

Teknik Korelasi Canggih: Fusion

Fusion adalah pendekatan korelasi tingkat lanjut yang menggabungkan sinyal lemah dari banyak sumber berbeda untuk menghasilkan deteksi high-confidence.

Setiap sinyal secara individual mungkin hanya bernilai 10-20% kemungkinan ancaman nyata. Tapi ketika 5-6 sinyal lemah ini terjadi bersamaan pada entitas yang sama dalam waktu berdekatan, probabilitas ancaman nyata menjadi sangat tinggi (>90%).

Microsoft Sentinel mengimplementasikan ini dengan Fusion alert yang menggunakan ML untuk menentukan kombinasi sinyal mana yang berarti ancaman nyata vs kebetulan.

10. Alerting & Detection

Piramida Kualitas Alert

Tidak semua alert bernilai sama. Ada hierarki kualitas:

Tier 1 — Signature-Based Detection: Alert berbasis tanda tangan yang diketahui — file hash malware, IP C2 yang diketahui, pattern exploit yang spesifik. Fidelity sangat tinggi jika signature-nya tepat, tapi mudah di-evade dengan modifikasi kecil.

Tier 2 — Rule-Based Behavioral Detection: Alert berbasis aturan perilaku yang didefinisikan manual — brute force, impossible travel, privilege escalation pattern. Fidelity lebih rendah dari signature, tapi lebih sulit di-evade karena berbasis perilaku bukan konten.

Tier 3 — Statistical Anomaly Detection: Alert ketika ada penyimpangan signifikan dari baseline statistik. Fidelity bervariasi — tergantung kualitas baseline dan seberapa "normal" environment Anda. Bisa mendeteksi ancaman yang tidak dikenal sebelumnya.

Tier 4 — ML/AI Based Detection: Model ML yang belajar dari data historis. Bisa mendeteksi pola kompleks yang tidak bisa didefinisikan secara manual. Tapi membutuhkan data training yang banyak dan hasilnya kadang sulit dijelaskan ("black box").

Konsep True Positive, False Positive, False Negative

Ini adalah konsep fundamental yang harus dipahami setiap orang yang bekerja dengan SIEM:

True Positive (TP): SIEM membuat alert, dan memang ada ancaman nyata. Ini yang diinginkan.

False Positive (FP): SIEM membuat alert, tapi ternyata bukan ancaman — aktivitas normal yang ter-flag. Ini membuang waktu analyst dan menyebabkan alert fatigue. Terlalu banyak FP menyebabkan analyst mulai mengabaikan alert.

False Negative (FN): Ada ancaman nyata tapi SIEM tidak mendeteksinya. Ini yang berbahaya — serangan berhasil tanpa terdeteksi. Sering terjadi ketika rule terlalu konservatif untuk menghindari FP.

True Negative (TN): Tidak ada ancaman dan SIEM tidak membuat alert. Normal.

Tantangan abadi dalam SIEM adalah trade-off antara sensitivity dan specificity. Meningkatkan sensitivity (mendeteksi lebih banyak ancaman) biasanya meningkatkan FP. Menurunkan FP biasanya meningkatkan FN. Tuning rule yang baik adalah tentang menemukan keseimbangan optimal untuk environment spesifik Anda.

Alert Fatigue — Ancaman Nyata bagi SOC

Alert fatigue adalah kondisi ketika SOC analyst dibanjiri begitu banyak alert (terutama false positive) sehingga mereka menjadi tidak sensitif terhadap alert baru. Ini adalah penyebab utama security incident yang terlewat.

Studi industri menunjukkan rata-rata SOC enterprise menerima lebih dari 10.000 alert per hari. Tidak mungkin semuanya diinvestigasi secara mendalam. Tanpa prioritisasi yang baik dan FP yang rendah, alert penting tenggelam di antara kebisingan.

Solusi untuk alert fatigue:

• Tuning agresif untuk mengurangi FP, meskipun prosesnya membutuhkan waktu
• Otomasi untuk alert low-value yang jelas false positive
• Risk scoring dan prioritisasi berbasis konteks
• Konsolidasi alert ke incident yang bermakna
• SOAR untuk auto-remediate beberapa kategori alert