🛡️ IBM QRadar — Comprehensive Cheat Sheet

Untuk SOC Analyst & DFIR | Blue Team Edition

Daftar Isi

1. Arsitektur & Komponen QRadar
2. Konsep Dasar: Event, Flow, dan Offense
3. AQL — Ariel Query Language
4. Log Source Management
5. Rules & Building Blocks
6. Offense Management untuk SOC
7. Network Activity & Flow Analysis
8. DFIR — Investigasi Insiden di QRadar
9. Reference Sets & Watchlists
10. Use Cases & Detection Patterns
11. QRadar SIEM Tuning & False Positive Reduction
12. Threat Intelligence Integration
13. Reporting & Dashboard
14. QRadar Administration Penting untuk SOC

1. Arsitektur & Komponen QRadar

Komponen Utama

Console Ini adalah otak dari seluruh deployment QRadar. Console adalah antarmuka web utama sekaligus orkestrator — dia yang menerima, memproses korelasi akhir, dan menampilkan offenses. Semua konfigurasi rules, log sources, dan reference sets hidup di sini. Dalam deployment kecil, Console bisa sekaligus menjadi Event Processor dan Flow Processor.

Event Processor (EP) Bertanggung jawab menerima raw log dari log sources, melakukan normalisasi (parsing), dan menjalankan rules engine terhadap event yang masuk. EP juga yang menyimpan event ke dalam Ariel datastore. Dalam environment besar, ada multiple EP untuk distribusi beban. Setiap EP memiliki kapasitas EPS (Events Per Second) tertentu.

Flow Processor (FP) Menerima dan memproses NetFlow, sFlow, IPFIX, dan traffic metadata dari network tap atau router. Flow memberikan visibilitas ke komunikasi jaringan meskipun tidak ada log aplikasi yang tersedia — sangat krusial untuk lateral movement detection dan data exfiltration.

QRadar Data Node Tambahan storage node yang memungkinkan retensi data jangka panjang tanpa harus menambah Event Processor. Data Node tidak memproses events — dia hanya menyimpan. Saat query AQL dijalankan, Console akan secara otomatis meng-query Data Node yang relevan.

QFlow Collector / Network Tap Komponen yang duduk di network untuk menangkap traffic dan menghasilkan flow records. Berbeda dengan NetFlow yang hanya metadata, QFlow bisa menangkap payload aplikasi layer 7 (Application Content Capture).

Event Collector Komponen yang mengumpulkan log dari sumber yang tidak bisa langsung dikirim ke EP — biasanya karena network segmentation. Event Collector bisa menerima syslog dan kemudian mem-forwardnya ke EP.

Managed Host Setiap komponen selain Console disebut Managed Host. Mereka dikonfigurasi dan dimonitor dari Console.

Ariel Database

QRadar tidak menggunakan database SQL tradisional. Ariel adalah time-series columnar store yang dioptimalkan untuk pencarian forensik terhadap volume log yang sangat besar. Ini alasannya AQL query bisa mencari ratusan juta events dalam hitungan detik.

2. Konsep Dasar: Event, Flow, dan Offense

Event

Event adalah representasi tunggal dari satu entri log. Setiap event memiliki:

• Category & Subcategory — QRadar mengkategorikan setiap event ke dalam taksonomi High Level Category (HLC) dan Low Level Category (LLC). Contoh: Authentication > Failed Login.
• QID (QRadar Identifier) — ID unik untuk setiap jenis event. Mapping dari raw log ke QID dilakukan oleh DSM (Device Support Module).
• Normalized Fields — QRadar memetakan field dari berbagai vendor ke field standar seperti username, sourceip, destinationip, eventname.
• Payload — Raw log asli tetap disimpan dan bisa dicari.

Flow

Flow adalah representasi sesi komunikasi jaringan — bukan packet, bukan log, tapi ringkasan koneksi. Sebuah flow record mencatat: source IP, destination IP, port, protokol, bytes sent, bytes received, durasi, dan sometimes application protocol yang terdeteksi.

Flow sangat berguna untuk mendeteksi:

• Komunikasi ke IP mencurigakan yang tidak menghasilkan log aplikasi
• Data exfiltration (volume bytes anomali)
• Lateral movement via SMB/WMI/RDP
• Beacon/C2 communication pattern (koneksi periodik ke IP yang sama)

Offense

Offense adalah "alarm" di QRadar — hasil dari rules yang ter-trigger. Satu offense bisa mengaggregasi ratusan atau ribuan events yang berkaitan. Offense memiliki:

• Magnitude — Skor 0-10 yang dihitung dari Relevance, Severity, dan Credibility.
• Relevance — Seberapa penting target offense ini (berdasarkan asset weight dan vulnerability).
• Severity — Tingkat keparahan berdasarkan kategori event.
• Credibility — Kepercayaan pada akurasi informasi (dipengaruhi log source reliability).
• Contributing Rules — Rules mana yang men-trigger offense ini.
• Offense Type — Source IP, Destination IP, Username, Host (aset), dll.

Perbedaan Event vs Flow dalam Investigasi

Ketika menginvestigasi lateral movement: Event (Windows Security Log 4624/4648) akan menunjukkan authentication. Flow akan menunjukkan apakah ada traffic volume yang tidak normal — misalnya SMB dengan data transfer besar, atau koneksi ke banyak host dalam waktu singkat. Keduanya harus digunakan bersama untuk narasi investigasi yang lengkap.

3. AQL — Ariel Query Language

Filosofi AQL

AQL mirip SQL tapi didesain khusus untuk time-series security data. Perbedaan terpenting dari SQL biasa: setiap query WAJIB punya time range. Ini bukan opsi — AQL tidak pernah bisa query tanpa batasan waktu karena volume data yang sangat besar.

Tabel utama di AQL:

• events — Semua log events
• flows — Semua network flow records
• simsrc — Offense data (jarang digunakan langsung)

Struktur Query

Query AQL mengikuti pola:

SELECT [fields] FROM [events/flows] WHERE [kondisi] LAST [N] MINUTES/HOURS/DAYS

Atau dengan waktu absolut:

SELECT ... FROM events WHERE ... START '2026-04-01 00:00:00' STOP '2026-04-01 23:59:59'

Field Penting untuk Events

Field Penting untuk Flows

Fungsi AQL yang Paling Berguna

LOGSOURCENAME() — Mengubah logsourceid (angka) menjadi nama yang human-readable. Selalu gunakan ini agar hasilnya tidak menjadi deretan angka.

QIDNAME() — Mengubah QID menjadi nama event yang bisa dibaca.

DATEFORMAT() — Mengubah epoch millisecond menjadi format tanggal yang dibaca manusia. Format string mengikuti Java SimpleDateFormat.

REFERENCESETCONTAINS() — Mengecek apakah sebuah nilai ada dalam Reference Set. Ini sangat powerful untuk filtering berdasarkan watchlist.

APPLICATIONNAME() — Menerjemahkan application ID dalam flow menjadi nama aplikasi.

CONCAT() — Menggabungkan string untuk membuat kolom custom.

LOWER() / UPPER() — Normalisasi case untuk username comparison.

INCIDR() — Mengecek apakah IP masuk dalam subnet CIDR tertentu. Berguna untuk filtering traffic internal vs eksternal.

Tips AQL yang Sering Diabaikan

Wildcard di payload — Kamu bisa mencari di dalam raw payload menggunakan payload ILIKE '%keyword%'. ILIKE adalah case-insensitive. Ini slow tapi powerful untuk hunting forensik di event raw.

Grouping dengan HAVING — Sama seperti SQL, gunakan GROUP BY dengan HAVING COUNT(*) > N untuk menemukan pola repetisi.

JOIN antara Events dan Flows — Ini tidak native di AQL. Untuk korelasi, gunakan dua query terpisah dan hubungkan secara manual berdasarkan IP/waktu, atau gunakan Rules untuk korelasi real-time.

Limit hasil — Selalu gunakan LIMIT untuk eksplorasi awal agar tidak membebani sistem. Hanya buang LIMIT jika kamu benar-benar butuh semua data untuk ekspor.

4. Log Source Management

DSM (Device Support Module)

DSM adalah "kamus" QRadar untuk memahami log dari vendor tertentu. Setiap DSM mendefinisikan bagaimana QRadar mem-parse field dari format log vendor tersebut (regex, JSON parser, dll.) dan memetakannya ke QID.

Jika ada log source baru yang tidak dikenali, QRadar akan menyimpannya sebagai "Unknown Log Source" — kamu perlu membuat DSM custom atau menginstal DSM update dari IBM Fix Central.

Protocol untuk Receiving Log

QRadar bisa menerima log via beberapa cara:

• Syslog (UDP/TCP/TLS) — Paling umum, push-based dari source
• JDBC — Pull dari database
• SFTP/FTP — Pull file log dari remote
• Log File Protocol — Baca file log lokal
• Microsoft Windows Event Log (WinCollect / Agent) — Agent-based collection dari Windows
• REST API — Pull dari API cloud services

WinCollect

Untuk Windows environment, IBM WinCollect adalah agent yang diinstall di Windows host dan mengirim Windows Event Log ke QRadar. Ini lebih reliable daripada syslog dari Windows karena dia memahami format EVTX natively.

Alternatif yang umum digunakan: Winlogbeat dikonfigurasi untuk forward ke QRadar via syslog — ini fleksibel tapi perlu DSM penyesuaian.

Log Source Groups

Gunakan Log Source Groups untuk mengorganisir log sources berdasarkan fungsi atau lokasi, misalnya: "DC Servers", "Perimeter Firewalls", "Endpoint Windows". Ini memudahkan ketika membuat rules yang hanya berlaku untuk kategori host tertentu.

Memantau Kesehatan Log Source

SOC analyst harus secara rutin memantau:

• Log Source Activity — Apakah log source masih mengirim events? QRadar bisa mendeteksi "Log Source Disconnected" jika tidak ada event dalam periode tertentu.
• EPS per Log Source — Identifikasi log source yang tiba-tiba mengirim traffic sangat tinggi (bisa jadi indikasi compromise atau misconfiguration).
• Parsing Error — Log yang gagal di-parse akan masuk sebagai "Unknown" dan kehilangan normalisasi — tidak bisa di-query dengan field standar.

5. Rules & Building Blocks

Hierarki Rules

QRadar memiliki beberapa jenis rules:

Event Rules — Bereaksi terhadap satu atau lebih events yang cocok dengan kondisi. Ini yang paling umum untuk detection use cases.

Flow Rules — Bereaksi terhadap flow records. Berguna untuk network anomaly detection dan C2 beaconing.

Common Rules — Berlaku untuk both events dan flows.

Offense Rules — Bereaksi terhadap perubahan state offense yang sudah ada, misalnya: jika offense magnitude naik melebihi threshold tertentu.

Building Blocks

Building Block adalah rules yang tidak menghasilkan offense atau response — mereka hanya menghasilkan boolean true/false yang bisa digunakan rules lain sebagai kondisi. Ini adalah cara QRadar mengimplementasikan modularitas logika detection.

Contoh: Kamu bisa membuat Building Block bernama "BB: Source IP is VPN Range" yang mengecek apakah source IP masuk dalam subnet VPN. Building block ini kemudian digunakan di banyak rules berbeda sebagai kondisi pengecualian — jauh lebih efisien daripada mendefinisikan ulang CIDR check di setiap rule.

Struktur Kondisi Rules

Rules menggunakan boolean logic dengan AND/OR yang bisa dinested. Kondisi umum:

• Ketika sebuah event terdeteksi
• Dan event tersebut cocok dengan kategori atau QID tertentu
• Dan source IP ada di dalam Reference Set tertentu
• Dan kondisi ini ter-trigger lebih dari N kali dalam M menit (threshold)
• Dengan agregasi dalam sliding time window

Accumulation vs Threshold

Accumulation — Rule men-trigger untuk setiap event yang cocok. Satu event menghasilkan satu aksi, meskipun offense sudah ada sebelumnya.

Threshold — Rule men-trigger hanya setelah kondisi terpenuhi N kali dalam window waktu tertentu. Untuk brute force detection, gunakan threshold: "Failed login dari IP yang sama lebih dari 10 kali dalam 5 menit."

Response Limiter

Jika sebuah rule sangat sering ter-trigger, gunakan Response Limiter untuk membatasi berapa kali rule ini bisa membuat offense baru dalam periode tertentu. Ini mencegah "offense storm" yang membanjiri queue dan menyulitkan analyst.

Custom Properties

Jika ada field dalam log yang tidak secara native di-parse oleh DSM, kamu bisa membuat Custom Event Property menggunakan regex extraction dari payload. Field custom ini kemudian bisa digunakan di AQL query dan rules — sangat berguna untuk log custom aplikasi internal yang tidak punya DSM resmi.

6. Offense Management untuk SOC

Lifecycle Offense

1. Open — Offense baru dibuat, belum ada yang menangani
2. Assigned — Sudah di-assign ke seorang analyst
3. In Progress — Analyst sedang investigasi
4. Closed — Investigasi selesai dengan disposition tertentu

Closing Reasons (Dispositions)

Pilih closing reason yang tepat karena ini memengaruhi metrik dan pattern analysis:

• Non-Issue — False positive, event normal yang tidak perlu tindakan
• Policy Violation — Benar terjadi, tapi bukan malicious — melanggar kebijakan organisasi
• Legitimate — Aktivitas normal yang terdeteksi oleh rules (kandidat tuning)
• Threat Mitigated — Ancaman nyata sudah teridentifikasi dan dimitigasi
• False Positive — Label generic untuk false positive

Annotations

Selalu tambahkan annotation yang detail saat menginvestigasi offense. Annotation adalah history investigasi — tuliskan apa yang kamu temukan, query AQL yang kamu jalankan, dan kesimpulan yang kamu tarik. Ini penting untuk:

• Handover ke shift berikutnya
• Audit trail investigasi
• Referensi jika offense yang sama muncul lagi di masa depan

Offense Categories & Prioritization

Prioritaskan offense berdasarkan kombinasi:

1. Magnitude tinggi — terutama jika mendekati atau di atas 8
2. Offense Type adalah Username — lebih impactful daripada sekedar IP
3. Target adalah Critical Asset — server penting, DC, database
4. Ada indikasi data exfiltration — flows dengan high bytes outbound

Multiple Rules dalam Satu Offense

QRadar bisa mengaggregasi events dari banyak rules ke dalam satu offense jika offense type-nya sama. Ini berarti satu offense bisa merupakan agregasi dari berbagai indikator — baca semua contributing rules untuk memahami full picture investigasi.

7. Network Activity & Flow Analysis

Flow Direction

QRadar mendefinisikan arah flow dari perspektif jaringan yang dimonitor:

• L2L (Local to Local) — Traffic internal ke internal. Penting untuk lateral movement detection.
• L2R (Local to Remote) — Traffic dari internal ke internet. Penting untuk C2, exfiltration.
• R2L (Remote to Local) — Traffic dari internet ke internal. Penting untuk inbound attacks.
• R2R (Remote to Remote) — Traffic antar-host eksternal yang melewati jaringan kamu, biasanya karena NAT atau transit routing.

Mendeteksi Anomali via Flow

Data Exfiltration — Cari flow dengan destinationbytes yang sangat besar ke IP eksternal tidak dikenal, terutama di jam-jam tidak normal. Bandingkan dengan baseline traffic normal host tersebut.

Beaconing/C2 — Koneksi ke IP/domain yang sama dengan interval yang sangat reguler, misalnya setiap 60 detik persis. Manual analysis via AQL dengan agregasi per destination IP dan count per jam sangat efektif untuk ini.

Port Scanning — Satu source IP mengkoneksi ke banyak destination port dalam waktu singkat. Gunakan GROUP BY destinationport dengan COUNT untuk mengidentifikasi pola ini.

SMB Lateral Movement — L2L flows via port 445 ke banyak host yang biasanya tidak berkomunikasi via SMB — indikator kuat aktivitas ransomware atau adversary yang bergerak lateral.

QRadar Network Insights (QNI)

QNI adalah fitur advanced yang menganalisis konten packet, bukan hanya metadata flow. QNI bisa mengekstrak:

• DNS queries — sangat berguna untuk domain-based C2 detection dan DGA detection
• HTTP metadata — host header, user agent, URL
• TLS certificate info — subject dan issuer tanpa perlu decrypt traffic
• File transfer detection

Jika environment kamu memiliki QNI, manfaatkan data DNS terutama untuk deteksi DNS tunneling. Subdomain yang sangat panjang dan terlihat random adalah tanda kuat DNS tunneling.

8. DFIR — Investigasi Insiden di QRadar

Framework Investigasi di QRadar

Pendekatan terstruktur untuk investigasi:

1. Scope — Tentukan scope insiden Mulai dari offense, identifikasi semua IP dan username yang terlibat. Kemudian expand: apakah IP tersebut berkomunikasi dengan host lain? Apakah username digunakan di host lain?

2. Timeline — Bangun timeline Sort semua events yang berkaitan berdasarkan waktu. Gunakan DATEFORMAT untuk readability. Timeline adalah backbone dari setiap investigasi DFIR — tanpa urutan kronologis yang jelas, narasi investigasi tidak akan koheren.

3. Context — Tambahkan konteks

• Apa itu host ini? Lihat Asset Information di QRadar.
• Apa peran user ini di organisasi?
• Apakah IP destination ada di threat intel feeds?
• Apakah aktivitas ini terlihat di host lain pada waktu yang sama?

4. Pivot — Lakukan pivoting Dari satu temuan, pivot ke data lain:

• Dari username → temukan di host mana lagi username ini aktif
• Dari IP → lihat semua komunikasi IP ini di flows
• Dari waktu kejadian → lihat events sebelum dan sesudahnya pada host yang sama

5. Narrative — Buat narasi Rangkum temuan dalam bahasa yang bisa dipahami non-teknis. Contoh: "Pada tanggal X pukul Y, akun admin_svc berhasil login ke DC01 dari workstation WS-042 yang tidak biasanya mengakses DC. Sesaat kemudian, terdapat transfer data sebesar 450MB dari DC01 ke IP eksternal yang tidak dikenal melalui port 443."

Pivoting Techniques di QRadar

Username Pivoting — Setelah menemukan username mencurigakan, query semua events dengan username tersebut di seluruh log sources dalam window waktu yang lebih luas. Ini mengungkap scope akses akun tersebut dan semua resource yang dia sentuh.

IP Pivoting — Setelah menemukan IP mencurigakan, query flows untuk melihat semua komunikasi IP tersebut — ke mana dan dari mana. Kemudian query events untuk authentication dari atau ke IP tersebut.

Time-based Pivoting — Setelah menentukan waktu kejadian, query semua events dari host yang sama 30 menit sebelum kejadian. Ini sering mengungkap delivery mechanism atau reconnaissance sebelumnya yang lolos dari detection.

Hash/Process Pivoting — Jika kamu punya EDR logs di QRadar, pivot berdasarkan hash atau nama process untuk melihat di host mana saja process tersebut berjalan — penting untuk menentukan blast radius infeksi malware.

Asset Information

QRadar memaintain database aset berdasarkan informasi yang dipelajari dari log dan flow (passive discovery) atau dari integrasi vulnerability scanner. Saat investigasi, selalu cek Asset Information untuk host yang terlibat:

• IP address history — apakah IP ini pernah digunakan host lain?
• Vulnerability data jika terintegrasi dengan Tenable atau Qualys
• OS dan open ports yang terdeteksi
• User accounts yang pernah terdeteksi di host ini

9. Reference Sets & Watchlists

Apa itu Reference Set

Reference Set adalah kumpulan nilai — IP, username, hash, domain, dll. — yang bisa digunakan dalam rules dan AQL. Ini adalah implementasi "dynamic watchlist" di QRadar yang bisa diupdate tanpa harus mengubah rules.

Tipe Reference Data

Reference Set — Satu kolom nilai. Contoh: daftar IP berbahaya, daftar username yang dikompromis, daftar domain C2.

Reference Map — Key-value pairs dengan satu kolom key dan satu kolom value. Contoh: username → department, IP → asset owner.

Reference Map of Sets — Key yang memetakan ke multiple values. Contoh: IP → set of usernames yang pernah login dari IP tersebut.

Reference Table — Multi-column table yang lebih kompleks. Contoh: IP → hostname, owner, criticality level.

Use Case Reference Set

Dynamic Blacklist — Buat Reference Set berisi IP atau domain yang dikonfirmasi sebagai threat. Rules yang mengecek komunikasi ke IP dalam set ini akan auto-trigger. Set ini bisa di-populate secara otomatis oleh rules — misalnya rule yang mendeteksi brute force kemudian menambahkan source IP ke blacklist secara otomatis.

VIP/Privileged Account Watchlist — Daftar username akun privileged seperti admin dan service account penting. Rules bisa memiliki threshold yang lebih rendah atau response berbeda untuk akun dalam watchlist ini.

Whitelist / Exclusion Lists — Daftar IP yang diketahui aman, misalnya vulnerability scanner, monitoring server, atau backup agent. Digunakan untuk dikecualikan dari rules tertentu agar tidak generate false positive.

Asset Criticality — Reference Map dari IP ke tingkat criticality seperti High, Medium, atau Low. Digunakan rules untuk memprioritaskan response berdasarkan nilai aset yang terlibat.

Mengisi Reference Set

• Manual — Import CSV atau tambah satu per satu via UI
• Rule Action — Rules bisa secara otomatis menambah atau menghapus nilai dari Reference Set berdasarkan kondisi yang ter-trigger
• API — REST API QRadar memungkinkan external system mengupdate Reference Sets secara programmatic, sangat berguna untuk integrasi dengan threat intel platform

Time to Live (TTL)

Setiap entry dalam Reference Set bisa punya TTL atau expiry time. Ini penting untuk IP block list — kamu tidak mau IP yang sebulan lalu mengirim spam masih diblock selamanya. Set TTL yang realistis sesuai kebijakan organisasi.

10. Use Cases & Detection Patterns

Brute Force & Credential Attack

Pattern: Banyak failed authentication dari satu source IP atau ke satu username dalam waktu singkat, kadang diikuti successful login.

Apa yang dicari di QRadar: Event category "Authentication" subcategory "Failed" dengan aggregation berdasarkan source IP atau username. Perhatikan rasio antara failed dan success — successful login setelah banyak failure adalah indikator sangat kuat account compromise. Juga perhatikan apakah username yang berhasil di-login berbeda dari yang gagal, karena ini indikator credential stuffing dari list yang berbeda.

Flow context: Setelah account compromise via brute force, biasanya diikuti dengan koneksi ke destination baru yang tidak biasanya diakses akun tersebut.

Lateral Movement

Pattern: Akun atau host yang berpindah-pindah mengakses host lain melalui protokol admin seperti SMB, WMI, RDP, PsExec, atau WinRM.

Apa yang dicari di QRadar: Events Windows 4648 (logon using explicit credentials), 4624 type 3 (network logon), dan 4624 type 10 (remote interactive). Dikombinasikan dengan L2L flows via port 445, 135, 3389, atau 5985.

Tanda bahaya utama: Account yang biasanya hanya login ke satu workstation tiba-tiba login ke banyak host berbeda dalam waktu singkat. Atau workstation yang sebelumnya tidak pernah berkomunikasi ke DC tiba-tiba melakukan authentication ke sana.

Privilege Escalation

Pattern: Akun non-privileged mendapatkan privilege admin atau mengakses resource yang seharusnya di luar jangkauannya.

Apa yang dicari di QRadar: Events 4672 (special privilege assigned to new logon), 4728 dan 4732 (member added to privileged group), serta 4688 dengan process name yang dikenal sebagai alat privilege escalation.

Data Exfiltration

Pattern: Transfer data keluar dalam volume besar, biasanya via HTTPS ke IP eksternal tidak dikenal, atau via DNS tunneling yang lebih tersembunyi.

Apa yang dicari di QRadar: L2R flows dengan sourcebytes yang sangat besar ke tujuan tidak dikenal. Host yang mengalami exfiltration biasanya tidak punya pola traffic keluar yang besar sebelumnya. Jika QNI tersedia, perhatikan DNS queries dengan subdomain yang panjang dan random — ini adalah indikator kuat DNS tunneling.

Baseline penting: Tanpa baseline volume traffic normal, sulit menentukan apa yang "besar". Penting untuk memiliki referensi traffic normal per host atau segment jaringan.

Ransomware Behavior

Pattern: File access dalam jumlah sangat besar dalam waktu singkat, diikuti dengan shadow copy deletion dan perubahan ekstensi file secara massal.

Apa yang dicari di QRadar: Jika File Integrity Monitoring (FIM) terintegrasi, akan ada banjir events file modification. Windows event 4663 (object access) dengan volume sangat tinggi dalam waktu singkat. Events yang berkaitan dengan vssadmin atau wmic shadowcopy deletion dari process creation event 4688.

Persistence Mechanism

Pattern: Pembuatan scheduled task, registry run key, service baru, atau user baru oleh proses yang tidak biasanya melakukan ini.

Apa yang dicari di QRadar: Windows events 4698 dan 4702 (scheduled task created/modified), 4720 (user account created), 7045 (service installed via System log), serta 4657 (registry value modification) terutama pada run keys.

Command & Control (C2) Beaconing

Pattern: Koneksi periodik ke IP atau domain eksternal tidak dikenal dengan pola waktu yang sangat reguler.

Apa yang dicari di QRadar: Flow analysis dengan agregasi jumlah connection ke destination IP yang sama per jam. Jika sangat konsisten, misalnya tepat 60 koneksi per jam setiap jam, ini adalah indikator kuat beaconing. Juga perhatikan koneksi ke IP yang tidak memiliki PTR record (reverse DNS) atau menggunakan port non-standar yang tidak umum untuk traffic legitim.

11. QRadar SIEM Tuning & False Positive Reduction

Filosofi Tuning

Tuning bukan berarti mematikan rules atau memperbesar threshold sembarangan. Tuning adalah proses menyesuaikan rules agar mereka alert pada sesuatu yang benar-benar membutuhkan perhatian — tidak terlalu sensitif hingga flood false positive, dan tidak terlalu toleran hingga miss real attack.

Setiap keputusan tuning harus didokumentasikan: mengapa rule ini di-tune, apa yang dikecualikan, dan kapan keputusan ini dibuat. Ini penting untuk audit dan untuk memastikan exclusion tidak dieksploitasi.

Strategi Tuning

Whitelist berdasarkan Source — Tambahkan IP scanner, monitoring server, atau backup agent ke Reference Set "Known Good Sources" dan eksklusikan dari rules tertentu. Jangan hardcode IP langsung ke dalam rules — selalu gunakan Reference Set agar mudah diupdate tanpa mengubah logic rules.

Whitelist berdasarkan User/Account — Service account yang selalu melakukan aktivitas yang terdeteksi sebagai anomali bisa dikecualikan. Lakukan dengan sangat hati-hati dan pastikan scope exclusion seminimal mungkin — hanya untuk rule dan akun yang spesifik.

Threshold Adjustment — Jika brute force rule threshold di 5 failed login terlalu sensitif, naikkan ke 10 atau 15 setelah menganalisis distribusi failed login normal di environment. Jangan naikkan terlalu tinggi karena real attack bisa lolos.

Time-based Exclusion — Beberapa aktivitas yang terdeteksi sebagai anomali sebenarnya adalah maintenance window. Pertimbangkan kondisi waktu dalam rules, tapi hati-hati karena attacker pintar akan memilih maintenance window untuk beraksi.

Mengukur False Positive Rate — Secara periodik, sample offenses yang di-close sebagai "Non-Issue" atau "False Positive" dan analisis: rule mana yang paling banyak generate FP? Itu adalah kandidat tuning berikutnya.

Yang Tidak Boleh Dilakukan

• Jangan disable rule secara global hanya karena satu use case menghasilkan FP. Tune scope exclusionnya, bukan matikan rule-nya.
• Jangan menaikkan threshold tanpa analisis distribusi — kamu mungkin membuka blind spot yang signifikan.
• Jangan hapus log source hanya karena terlalu noisy — filter di level parsing atau rules.

12. Threat Intelligence Integration

X-Force Exchange & QRadar TI App

IBM QRadar bisa terintegrasi dengan IBM X-Force Exchange untuk mendapatkan reputasi IP, domain, dan hash langsung di dalam offense view. Ini memberikan konteks tambahan tanpa perlu keluar dari QRadar untuk lookup manual.

STIX/TAXII Integration

QRadar mendukung konsumsi Threat Intelligence via STIX/TAXII. Ini memungkinkan ingest IOC dari threat intel platforms seperti MISP, ThreatConnect, atau feed ISAC ke dalam Reference Sets secara otomatis.

Workflow-nya: TAXII feed berisi IOC terbaru, QRadar secara periodik pull IOC dari feed tersebut, IOC di-populate ke Reference Sets berupa IP, domain, dan hash, kemudian rules mengecek events dan flows terhadap Reference Sets ini secara real-time. Ini adalah cara yang scalable untuk mengintegrasikan threat intelligence ke dalam detection pipeline.

App Exchange

IBM App Exchange menyediakan berbagai apps untuk QRadar termasuk integrasi dengan CrowdStrike Falcon (EDR), Palo Alto Cortex XSOAR (SOAR), VirusTotal, dan MITRE ATT&CK framework overlay yang sangat berguna untuk mapping detection ke teknik ATT&CK.

Contextual Enrichment Manual

Bahkan tanpa integrasi otomatis, SOC analyst bisa memperkaya investigasi dengan lookup eksternal: VirusTotal atau AbuseIPDB untuk IP dan hash dari offense, WHOIS dan passive DNS untuk domain lookups, Shodan untuk fingerprint service dari IP mencurigakan, serta korelasi dengan external threat reports dan advisories yang relevan.

13. Reporting & Dashboard

Dashboard untuk SOC

Dashboard QRadar bisa dikustomisasi per user. Dashboard yang berguna untuk SOC:

Security Operations Dashboard — Menampilkan offense count per severity hari ini versus kemarin, top attacking IPs, top targeted IPs, dan event rate trend per 24 jam. Memberikan situational awareness cepat di awal shift.

Threat Intelligence Dashboard — Komunikasi ke known bad IPs atau domains, hit rate dari threat intel feeds, dan top IOC yang ter-trigger. Menunjukkan seberapa "aktif" ancaman yang ada di TI feeds terhadap environment.

Log Source Health Dashboard — EPS per log source, log sources dengan anomali baik terlalu tinggi maupun terlalu rendah, dan log source yang disconnected. SOC harus memantau ini secara aktif.

Reporting

QRadar memiliki Report Generator built-in. Laporan bisa dijadwalkan otomatis harian, mingguan, atau bulanan dan diekspor ke PDF atau HTML, serta dikirim via email ke stakeholder.

Laporan penting yang biasanya dibutuhkan: Executive Summary dengan high-level offense count dan trend, Compliance Report untuk audit kebutuhan log retention dan authentication monitoring, serta Incident Summary yang merekap insiden yang ter-handle dalam periode laporan.

14. QRadar Administration Penting untuk SOC

Health Monitoring dari Perspektif SOC

SOC analyst perlu memahami tanda-tanda QRadar yang "tidak sehat" karena bisa memengaruhi detection capability:

EPS drop drastis — Jika log source yang biasanya kirim 1000 EPS tiba-tiba menjadi 0, kemungkinan ada problem di sumber: agent down, network issue, atau — yang paling mengkhawatirkan — attacker menonaktifkan logging untuk menutupi jejaknya.

High Disk Usage — Jika disk Ariel datastore hampir penuh, QRadar akan mulai drop events dan kamu akan kehilangan visibility. Monitor ini secara aktif dan eskalasi ke admin sebelum kritis.

Queue Backlog — Jika event processing backlog terus menumpuk, artinya EP kewalahan. Events masih akan diproses tapi ada delay yang bisa memengaruhi real-time detection capability.

QRadar REST API

QRadar memiliki REST API yang komprehensif. SOC yang mature menggunakan API untuk:

• Membuat dan mengupdate offenses secara programmatic untuk integrasi SOAR
• Mengupdate Reference Sets dari tools eksternal seperti threat intel platform
• Menjalankan AQL queries secara headless dari script otomasi dan hunting tools
• Mengambil offense details untuk pembuatan tiket di ITSM secara otomatis

Dokumentasi API tersedia secara interaktif di endpoint /api_doc pada QRadar console.

Backup dan Restoration

Konfigurasi QRadar — rules, log sources, reference sets — bisa di-backup via System Administration. SOC harus aware bahwa Ariel data berupa actual events dan flows tidak masuk dalam backup konfigurasi standar. Backup data forensik jangka panjang membutuhkan strategi terpisah yang biasanya dikelola oleh tim infrastructure.

Quick Reference: Kategori Event Penting

Quick Reference: Windows Event IDs Paling Penting di QRadar

Last Updated: April 2026 | Untuk internal SOC & DFIR use