🛡️ Microsoft Sentinel — Cheat Sheet Komprehensif

Untuk SOC Analyst & DFIR (Digital Forensics & Incident Response)

📌 DAFTAR ISI

1. Pengenalan Microsoft Sentinel
2. Arsitektur & Komponen Utama
3. Data Connectors & Log Sources
4. KQL — Kusto Query Language Essentials
5. Analitik & Detection Rules
6. Incidents & Alert Management
7. Workbooks & Visualization
8. UEBA — User & Entity Behavior Analytics
9. Threat Intelligence Integration
10. Automation & SOAR dengan Playbooks
11. Hunting — Proactive Threat Hunting
12. DFIR — Digital Forensics & Incident Response
13. Tabel Log Penting & Maknanya
14. MITRE ATT&CK Mapping di Sentinel
15. Tuning & Noise Reduction
16. Checklist Harian SOC Analyst
17. Tips & Best Practices

1. Pengenalan Microsoft Sentinel

Microsoft Sentinel adalah cloud-native SIEM (Security Information & Event Management) dan SOAR (Security Orchestration, Automation, and Response) yang berjalan di atas Azure. Sentinel dirancang untuk mengumpulkan data keamanan dari seluruh infrastruktur — cloud, on-premises, dan hybrid — lalu menganalisisnya secara cerdas menggunakan AI dan machine learning.

Mengapa Sentinel Berbeda dari SIEM Tradisional?

• Tanpa infrastruktur fisik: Tidak perlu server, storage, atau hardware tambahan. Semua dikelola Azure.
• Skalabilitas otomatis: Bisa menangani miliaran event per hari tanpa perlu capacity planning manual.
• Bayar sesuai penggunaan: Model pricing berbasis volume data yang diingest (GB/hari), bukan per-seat license.
• Built-in AI/ML: Fitur anomaly detection, UEBA, dan Fusion alert tidak perlu dikonfigurasi dari nol.
• Terintegrasi dengan ekosistem Microsoft: Azure AD, Defender for Endpoint, Defender for Cloud, M365 Defender — semuanya terhubung native.

Posisi Sentinel dalam Ekosistem Security Microsoft

[Data Sources] → [Data Connectors] → [Log Analytics Workspace] → [Sentinel]
                                                                        ↓
                                              Analytics Rules | Hunting | UEBA | TI
                                                                        ↓
                                               Incidents → Playbooks (SOAR) → Remediation

Sentinel pada dasarnya adalah lapisan intelligence di atas Log Analytics Workspace (LAW). Semua log disimpan di LAW, dan Sentinel menambahkan kemampuan deteksi, investigasi, dan respons di atasnya.

2. Arsitektur & Komponen Utama

Log Analytics Workspace (LAW)

LAW adalah "database" tempat semua log disimpan. Sentinel selalu terikat pada satu LAW. Pemahaman tentang LAW penting karena:

• Semua query KQL dijalankan di sini
• Retention period dikonfigurasi di LAW (default 90 hari, bisa diperpanjang)
• Biaya Sentinel sebagian besar ditentukan oleh volume data di LAW

Best practice: Untuk enterprise, pertimbangkan satu LAW per region atau satu LAW terpusat. Jangan mencampur data produksi dan dev/test di workspace yang sama.

Komponen Fungsional Sentinel

Hierarki Entitas di Sentinel

Sentinel mengenali berbagai entitas dari log yang masuk. Entitas ini menjadi "aktor" dalam investigasi:

• Account — user account (UPN, SID, domain\user)
• Host — komputer, server, VM
• IP Address — alamat jaringan
• URL / Domain — web resource
• File / File Hash — artefak file
• Process — proses yang berjalan
• Mailbox / Email — entitas email
• Azure Resource — resource cloud

Sentinel secara otomatis memetakan entitas dari field log ke tipe-tipe di atas, sehingga investigasi bisa melihat "apa yang dilakukan entitas X selama incident?"

3. Data Connectors & Log Sources

Kategori Data Connector

Native / First-Party (Microsoft)

• Azure Active Directory (Sign-in logs, Audit logs, Provisioning logs)
• Microsoft 365 Defender (Endpoint, Identity, Office, Cloud Apps)
• Azure Activity (operasi di Azure portal/ARM)
• Azure Security Center / Defender for Cloud
• Azure Firewall, NSG Flow Logs, Azure DDoS

Third-Party via CEF/Syslog

• Palo Alto Networks, Fortinet, Check Point (firewall)
• CrowdStrike, Carbon Black (EDR)
• Cisco ASA, Cisco Umbrella
• F5, Imperva (WAF)

Via REST API / Custom

• AWS CloudTrail, AWS S3
• Google Cloud Platform logs
• Vendor-specific API connectors

Via Log Analytics Agent (MMA/AMA)

• Windows Security Events (Event Logs)
• Linux Syslog
• On-premises servers

Perbedaan MMA vs AMA (penting!)

Microsoft Monitoring Agent (MMA) adalah agent lama yang akan di-deprecated. Azure Monitor Agent (AMA) adalah generasi baru dengan keunggulan:

• Data Collection Rules (DCR) yang lebih granular — bisa filter event sebelum dikirim, menghemat biaya
• Multi-homing ke beberapa workspace
• Manajemen terpusat via Azure Policy

Rekomendasi SOC: Mulai migrasi ke AMA jika belum. Gunakan DCR untuk filter event yang tidak diperlukan agar tidak membayar log yang tidak berguna.

Log yang Wajib Ada di Setiap Deployment Sentinel

Urutan prioritas berdasarkan nilai investigasi vs biaya:

1. Azure AD Sign-in Logs — deteksi credential attack, MFA bypass, impossible travel
2. Azure AD Audit Logs — deteksi privilege escalation, account manipulation
3. Microsoft Defender for Endpoint — telemetri endpoint paling kaya (process, network, file)
4. Windows Security Events (critical subset) — logon events (4624, 4625, 4648), process creation (4688), privilege use (4672)
5. Azure Activity Logs — perubahan di infrastruktur Azure
6. Firewall/NSG Logs — network traffic baseline
7. DNS Logs — deteksi C2, DNS tunneling, domain generation algorithm (DGA)

4. KQL — Kusto Query Language Essentials

KQL adalah bahasa query utama di Sentinel. Semua analisis, hunting, dan rule detection menggunakan KQL. Memahami KQL dengan baik adalah skill paling penting bagi SOC analyst di lingkungan Sentinel.

Filosofi KQL

KQL bekerja dengan pipeline — data mengalir dari kiri ke kanan, satu operator ke operator berikutnya menggunakan tanda | (pipe). Berbeda dengan SQL yang menggunakan subquery nested, KQL lebih mudah dibaca karena alurnya linear.

Operator-Operator Paling Penting

where — Filter baris. Ini operator yang paling sering digunakan. Selalu letakkan where di awal query untuk mengurangi volume data sebelum operasi lain. Gunakan where TimeGenerated > ago(1h) hampir di setiap query.

summarize — Agregasi data. Setara dengan GROUP BY di SQL. Digunakan untuk menghitung frekuensi event, membuat statistik, atau melihat pola. Contoh penggunaan: menghitung berapa kali IP tertentu gagal login dalam 1 jam.

project — Memilih kolom yang ingin ditampilkan. Penting untuk membersihkan output dan hanya menampilkan field yang relevan. project-away untuk membuang kolom tertentu.

extend — Menambah kolom baru hasil kalkulasi atau parsing. Digunakan sering untuk extract bagian dari string, kalkulasi waktu, atau membuat label.

join — Menggabungkan dua tabel berdasarkan field yang sama. Ada beberapa jenis join: inner, leftouter, rightouter, fullouter. Untuk security analytics, inner dan leftouter paling sering digunakan.

union — Menggabungkan beberapa tabel secara vertikal (menumpuk baris). Berguna ketika ingin query beberapa tabel sekaligus dengan struktur mirip.

let — Mendefinisikan variabel atau subquery yang bisa dipanggil ulang. Membuat query lebih bersih dan modular. Bisa digunakan untuk mendefinisikan threshold, list IP yang diizinkan, atau subquery kompleks.

render — Menampilkan hasil dalam bentuk chart/visualisasi. render timechart, render barchart, render piechart.

mv-expand — Meng-expand field array/dynamic menjadi baris terpisah. Sangat penting untuk menganalisis field bertipe JSON atau array di log modern.

parse / extract — Parsing string dengan pattern matching. parse lebih mudah untuk format terstruktur, extract menggunakan regex untuk pola yang lebih kompleks.

top / limit — Membatasi jumlah hasil. top N by Column menampilkan N baris teratas berdasarkan kolom tertentu.

distinct — Menghapus duplikat dan menampilkan nilai unik. Berguna untuk mendapatkan daftar unik IP, user, atau host.

ago() — Fungsi waktu untuk rentang relatif. ago(1h) = 1 jam lalu, ago(7d) = 7 hari lalu, ago(30m) = 30 menit lalu.

bin() — Mengelompokkan nilai ke dalam bucket. Paling sering digunakan dengan waktu: bin(TimeGenerated, 1h) mengelompokkan event per jam, berguna untuk timechart.

String Functions yang Sering Dipakai

• contains — cek substring, case-insensitive
• has — lebih efisien dari contains, cocokkan kata penuh
• startswith / endswith — cocokkan awal/akhir string
• tolower() / toupper() — normalisasi case, penting untuk join dan comparison
• split() — pecah string menjadi array berdasarkan delimiter
• strcat() — gabungkan beberapa string
• substring() — ambil bagian dari string
• replace_string() — ganti substring

Pola Query SOC yang Umum

Pola Deteksi Brute Force: Hitung jumlah kegagalan login per akun per IP dalam window waktu tertentu, lalu filter yang melebihi threshold (misalnya >10 kali dalam 5 menit).

Pola Deteksi Anomali: Bandingkan perilaku saat ini dengan baseline historis. Misalnya, user yang biasanya login dari Indonesia tiba-tiba login dari negara lain dalam waktu yang tidak mungkin (impossible travel).

Pola Enrichment: Join tabel event dengan tabel referensi (watchlist, threat intelligence) untuk menambahkan konteks. Misalnya, cek apakah IP sumber login ada di daftar IP berbahaya.

Pola Timeline Reconstruction: Urutkan semua event terkait satu entitas (user/host) berdasarkan waktu untuk membangun narasi serangan.

5. Analitik & Detection Rules

Jenis-Jenis Analytics Rules

Scheduled Rules (Paling Umum) Ini adalah rule yang paling banyak digunakan. Rule ini menjalankan query KQL secara periodik (setiap 5 menit, 1 jam, dsb.) dan menghasilkan alert jika kondisi terpenuhi.

Parameter penting dalam Scheduled Rule:

• Query: KQL yang mendefinisikan kondisi deteksi
• Run query every: Seberapa sering query dijalankan (frekuensi)
• Lookup data from last: Rentang waktu data yang dianalisis (query period)
• Alert threshold: Minimal berapa hasil yang harus ada untuk trigger alert
• Event grouping: Satu alert per semua event, atau satu alert per event
• Entity mapping: Pemetaan field log ke tipe entitas Sentinel
• Tactics & techniques: Mapping ke MITRE ATT&CK

Near Real-Time (NRT) Rules Dijalankan hampir real-time (latensi ~1 menit), cocok untuk deteksi yang sangat time-sensitive. Querynya harus sederhana dan tidak bisa menggunakan join kompleks.

Microsoft Security Rules Secara otomatis mengubah alert dari Microsoft Defender products (MDE, MDI, MDA, MDO) menjadi Sentinel incidents. Tidak perlu konfigurasi query.

Anomaly Rules (Fusion & UEBA) Dibuat otomatis oleh Sentinel menggunakan ML. Tidak perlu dikonfigurasi manual. Fusion alert menggabungkan beberapa low-fidelity signal dari berbagai sumber menjadi satu high-confidence alert.

Threat Intelligence Rules Otomatis mencocokkan indicator dari TI feed (IP, domain, URL, hash) dengan log yang masuk. Berguna untuk deteksi berbasis IOC.

Siklus Hidup Rule Detection

Pembuatan Rule: Mulai dari use case (apa yang ingin dideteksi?) → tulis KQL → uji dengan data historis → set parameter → aktifkan.

Tuning Rule: Rule baru hampir selalu menghasilkan false positive. Proses tuning adalah menambahkan exclusion untuk known-good behavior tanpa mengorbankan deteksi true positive. Dokumentasikan setiap exclusion dan alasannya.

Validasi Rule: Gunakan fitur "Test with current data" atau buat environment simulasi untuk memastikan rule berfungsi sebagaimana mestinya. Lakukan validasi ulang setelah perubahan infrastruktur besar.

Retirement Rule: Rule yang tidak lagi relevan (karena sistem sudah diganti, atau tidak pernah menghasilkan true positive) sebaiknya dinonaktifkan, bukan dibiarkan jalan dan menghabiskan compute.

Severity Guideline

OOTB (Out-of-the-Box) vs Custom Rules

Microsoft menyediakan ratusan rule siap pakai melalui Content Hub. Rule ini dibuat oleh Microsoft dan komunitas, berdasarkan MITRE ATT&CK framework.

Kapan pakai OOTB: Untuk coverage teknik ATT&CK yang umum, deteksi berbasis signature, dan quick win saat pertama deploy.

Kapan buat custom: Ketika OOTB tidak cocok dengan environment spesifik Anda, ada kebutuhan deteksi bisnis yang unik, atau perlu logic yang lebih spesifik dari environment Anda.

Strategi hybrid: Aktifkan OOTB sebagai baseline, kemudian buat custom rule untuk gap yang tidak tertutup dan untuk high-value assets Anda.

6. Incidents & Alert Management

Perbedaan Alert vs Incident

Alert adalah output dari satu analytics rule — notifikasi bahwa kondisi tertentu terdeteksi di data. Alert bisa bernilai rendah atau tinggi, dan mungkin berdiri sendiri.

Incident adalah kumpulan alert yang dikelompokkan oleh Sentinel menjadi satu kasus investigasi. Sentinel menggunakan alert grouping untuk mengumpulkan alert terkait berdasarkan entitas yang sama, waktu yang berdekatan, atau rule yang sama.

Analogi: Alert = laporan dari satu sensor. Incident = kasus polisi yang mengumpulkan semua laporan terkait satu kejadian.

Status Incident

• New — Baru masuk, belum ditangani
• Active — Sedang dalam investigasi
• Closed — Sudah diselesaikan (dengan classification)

Classification saat Close Incident

Ketika menutup incident, selalu pilih classification yang tepat:

• True Positive — Suspicious Activity: Alert valid, ada ancaman nyata
• Benign Positive — Suspicious but Expected: Alert valid secara teknis, tapi behavior ini normal untuk context tertentu (misalnya pentest terjadwal)
• False Positive — Incorrect Alert Logic: Rule detection salah, perlu diperbaiki
• False Positive — Inaccurate Data: Data log tidak akurat/incomplete
• Undetermined: Tidak cukup bukti untuk menentukan

Klasifikasi ini penting untuk tracking metrics MTTD/MTTR dan untuk feedback loop tuning rule.

Alur Kerja Ideal Penanganan Incident

1. Triage: Baca summary incident, lihat entities yang terlibat, baca alert details, tentukan severity awal
2. Assign: Assign incident ke analyst yang bertanggung jawab, update status ke "Active"
3. Investigate: Gunakan Investigation Graph, tambah bookmark dari hunting, cross-reference dengan TI
4. Contain: Jika terbukti ancaman, trigger playbook containment (isolate host, disable user, block IP)
5. Eradicate: Hapus malware, remediate vulnerability yang dieksploitasi
6. Recover: Restore dari backup jika perlu, verify systems bersih
7. Document & Close: Tulis summary, pilih classification, lesson learned, improve detection

Investigation Graph

Fitur visual di Sentinel yang menampilkan hubungan antar entitas dalam satu incident. Sangat berguna untuk:

• Melihat "blast radius" — seberapa luas dampak kompromi satu akun
• Menemukan lateral movement — host mana saja yang terhubung ke host yang dikompromis
• Memahami timeline serangan secara visual

7. Workbooks & Visualization

Apa itu Workbooks?

Workbooks adalah dashboard interaktif di Sentinel yang dibangun di atas Azure Monitor Workbooks. Setiap tile dalam workbook menjalankan query KQL dan menampilkan hasilnya secara visual. Workbook bisa berisi kombinasi teks, query, parameter filter, dan visualisasi.

Workbooks Bawaan yang Paling Berguna

Azure AD Sign-in Workbook: Menampilkan pola login, lokasi geografis, conditional access events, MFA stats. Wajib dibuka setiap pagi untuk SOC yang memonitor identitas.

Security Operations Efficiency Workbook: Metrics operasional SOC — MTTD, MTTR, distribusi severity, incident trend. Berguna untuk laporan manajemen.

Cyber Threat Intelligence Workbook: Visualisasi IOC yang di-ingest, coverage, dan hits dari TI feed.

Zero Trust Workbook: Coverage monitoring untuk implementasi Zero Trust architecture.

Microsoft Defender for Endpoint Workbook: Telemetri endpoint termasuk vulnerability exposure, threat & vulnerability management, active alerts.

Kapan Membuat Custom Workbook?

• Ada kebutuhan monitoring spesifik yang tidak tersedia di OOTB workbooks
• Ingin menggabungkan data dari beberapa sumber dalam satu view
• Management membutuhkan laporan dalam format tertentu
• SOC ingin daily dashboard yang menampilkan KPI internal

8. UEBA — User & Entity Behavior Analytics

Konsep Dasar UEBA

UEBA mempelajari pola normal ("baseline") dari setiap user dan entitas selama periode waktu tertentu, kemudian menghasilkan anomaly score ketika terjadi penyimpangan dari baseline tersebut.

Ini sangat berguna untuk kasus yang sulit dideteksi dengan rule tradisional berbasis threshold:

• Insider threat: Karyawan yang mencuri data secara perlahan menggunakan akun sahnya sendiri
• Compromised account: Attacker yang menggunakan credential yang valid tapi perilakunya anomali
• Lateral movement: User yang tiba-tiba mengakses banyak sistem yang tidak biasa ia akses

Bagaimana Sentinel UEBA Bekerja?

Sentinel UEBA menganalisis log dari berbagai sumber (Azure AD, Active Directory, Microsoft Defender, firewall, dll.) dan membangun profil untuk setiap user dan host. Profil ini mencakup:

• Waktu dan lokasi biasa login
• Device dan browser yang biasa digunakan
• Aplikasi dan resource yang biasa diakses
• Volume data yang biasa didownload/upload
• Peer group comparison (apakah perilaku user mirip dengan kolega se-departemen?)

Hasilnya adalah Investigation Priority Score per user/entitas — angka dari 0-10 yang menunjukkan seberapa anomali perilaku mereka.

Tabel UEBA di LAW

• BehaviorAnalytics — Tabel utama berisi anomaly per user/entitas
• UserPeerAnalytics — Perbandingan perilaku user dengan peer group
• IdentityInfo — Informasi directory user (department, manager, job title)

Cara Menggunakan UEBA dalam Investigasi

Saat menginvestigasi incident yang melibatkan user account, selalu cek UEBA untuk konteks tambahan:

• Berapa Investigation Priority Score user tersebut?
• Apakah ada anomali lain yang terjadi sebelum/sesudah incident?
• Dari peer group comparison, apakah perilaku ini unik untuk user ini atau umum di departemennya?

9. Threat Intelligence Integration

Jenis Threat Intelligence di Sentinel

STIX/TAXII Feed: Sentinel bisa terhubung langsung ke server TAXII untuk mendapatkan IOC dalam format STIX. Ini untuk feed dari vendor TI premium (Recorded Future, ThreatConnect, Anomali, dll.).

Microsoft TI (gratis): Microsoft secara otomatis menyediakan TI feed internal ke semua tenant Sentinel tanpa biaya tambahan. Mencakup IP, domain, dan URL berbahaya yang diidentifikasi oleh tim Microsoft.

Upload via API/CSV: Bisa upload IOC custom dari tim internal, partner ISAC, atau hasil hunting internal menggunakan Microsoft Graph Security API.

Defender TI (premium): Layanan berbayar yang memberikan akses ke dataset TI Microsoft yang lebih luas, termasuk infrastructure analysis, WHOIS, passive DNS, dan certificate tracking.

Tabel TI di LAW

• ThreatIntelligenceIndicator — Semua IOC yang di-ingest, dengan field: IndicatorId, NetworkIP, DomainName, Url, FileHashValue, ExpirationDateTime, Confidence, dll.

Menghubungkan TI dengan Log Operasional

TI menjadi berguna ketika di-join dengan log aktual. Strategi umum:

Untuk deteksi berbasis IOC secara otomatis, aktifkan Threat Intelligence Matching Analytics rule. Rule ini secara otomatis mencocokkan IOC dari ThreatIntelligenceIndicator dengan tabel log utama (SigninLogs, CommonSecurityLog, DnsEvents, dll.) dan menghasilkan alert jika ada match.

Untuk hunting manual, join ThreatIntelligenceIndicator dengan log spesifik yang ingin diperiksa.

Kualitas TI yang Perlu Diperhatikan

Tidak semua TI feed berkualitas sama. Perhatikan:

• Confidence score: Seberapa yakin TI provider bahwa IOC ini memang berbahaya
• Expiration date: IOC yang sudah expired sebaiknya tidak digunakan untuk deteksi (IP bisa berganti pemilik)
• Context/tags: IOC yang dilabeli dengan taktik ATT&CK atau nama threat actor lebih actionable
• Volume vs kualitas: Feed besar dengan jutaan IOC belum tentu lebih baik — false positive rate tinggi akan menguras waktu SOC

10. Automation & SOAR dengan Playbooks

Apa itu Playbook?

Playbook Sentinel adalah workflow otomatis yang dibangun di atas Azure Logic Apps. Playbook bisa dipicu oleh:

• Alert baru yang dibuat
• Incident baru yang dibuat
• Manual trigger dari SOC analyst saat investigasi

Logic Apps menyediakan ratusan connector ke berbagai sistem: Teams, Outlook, ServiceNow, Jira, Slack, AWS, GCP, dan banyak lagi.

Kategori Use Case Playbook

Enrichment Otomatis: Ketika incident dibuat, playbook secara otomatis melakukan enrichment — misalnya query VirusTotal untuk hash/IP yang terlibat, cek reputasi domain di Shodan, pull informasi WHOIS, dan tambahkan semua hasilnya ke komentar incident. Ini menghemat 10-15 menit kerja manual per incident.

Notifikasi: Kirim alert ke channel Teams/Slack dengan format yang sudah distandardisasi. Escalate ke on-call via PagerDuty jika severity High/Critical. Buat ticket otomatis di ServiceNow atau Jira.

Containment Otomatis (High Confidence): Untuk ancaman dengan kepercayaan tinggi, playbook bisa langsung:

• Isolate host dari jaringan via Defender for Endpoint API
• Disable user account di Azure AD
• Block IP di Azure Firewall atau NSG
• Revoke semua active session user di Azure AD
• Force password reset

Containment Semi-Otomatis (Perlu Approval): Untuk tindakan yang lebih berdampak, playbook bisa mengirim request approval ke Teams/Outlook — analyst bisa approve atau reject langsung dari pesan Teams.

Prinsip SOAR yang Baik

• Mulai dari enrichment sebelum otomasi containment. False positive yang di-block otomatis bisa sangat merusak operasional.
• Dokumentasikan setiap aksi yang dilakukan playbook ke komentar incident agar ada audit trail.
• Test playbook di environment non-produksi sebelum diaktifkan di produksi.
• Monitor kesehatan playbook — Logic Apps bisa gagal karena berbagai alasan (auth expired, API rate limit, dll.). Buat alerting jika playbook failure rate tinggi.

11. Hunting — Proactive Threat Hunting

Filosofi Threat Hunting

Threat hunting adalah aktivitas proaktif — berbeda dengan monitoring reaktif. Tujuannya adalah menemukan ancaman yang sudah ada di environment tetapi belum terdeteksi oleh rule otomatis. Premisnya adalah: "Assume breach" — anggap sudah ada yang masuk, dan cari buktinya.

Hunting dilakukan oleh analyst yang lebih senior (Tier 2/3) dan membutuhkan pemahaman mendalam tentang:

• Taktik dan teknik attacker (MITRE ATT&CK)
• Baseline normal environment (apa yang "normal" untuk organisasi Anda)
• KQL tingkat lanjut

Proses Threat Hunting

1. Hypothesis: Mulai dengan hipotesis berdasarkan threat intelligence terbaru, industri yang sama, atau gut feeling berdasarkan pengalaman. Contoh: "Apakah ada living-off-the-land activity menggunakan LOLBins di network kami?"

2. Data Collection: Identifikasi data source yang relevan untuk hipotesis. Pastikan data tersebut ada dan komplit di LAW.

3. Investigation: Tulis dan jalankan query KQL untuk mencari pola yang mendukung atau menolak hipotesis.

4. Pattern Discovery: Jika menemukan sesuatu menarik, gali lebih dalam. Timeline apa yang terjadi sebelum dan sesudah?

5. Bookmark & Escalate: Tandai temuan menarik dengan bookmark, create incident jika memang ada ancaman.

6. Formalize Detection: Jika hipotesis terbukti dan tekniknya bisa berulang, buat analytics rule permanen dari hunting query.

Hunting Queries Berdasarkan ATT&CK Tactics

Initial Access (TA0001)

• Cari login dari IP TOR/VPN berbayar
• Phishing: email dengan attachment executable atau link ke domain baru
• External remote service abuse: RDP brute force, VPN login dari lokasi tidak biasa

Execution (TA0002)

• Proses mencurigakan spawned dari Office applications (winword.exe, excel.exe spawning cmd.exe)
• PowerShell dengan encoded command
• Script execution via wscript/cscript
• Scheduled task creation baru

Persistence (TA0003)

• Registry run key yang ditambahkan oleh proses yang tidak biasa
• Scheduled task baru, terutama yang menjalankan dari temp folder
• Service baru yang dibuat
• Startup folder modification

Defense Evasion (TA0005)

• Proses yang melakukan process hollowing atau injection
• Tools yang rename dirinya agar mirip sistem (svchost.exe di path tidak standar)
• Log clearing events (Event ID 1102, 104)
• AMSI bypass attempts

Credential Access (TA0006)

• LSASS memory access via tools seperti Mimikatz
• Kerberoasting: large volume TGS requests untuk service accounts
• Password spray: banyak username berbeda dengan password yang sama
• DCSync: replication request dari non-DC machine

Lateral Movement (TA0008)

• User yang tiba-tiba login ke banyak host berbeda
• Pass-the-hash / Pass-the-ticket indicators
• WMI atau PSExec remote execution
• SMB lateral movement

Exfiltration (TA0010)

• Volume data upload yang sangat besar ke external destination
• Data staging di uncommon directories sebelum eksfiltrasi
• DNS queries dengan payload yang sangat besar (DNS tunneling)
• Upload ke cloud storage yang tidak dikenal

12. DFIR — Digital Forensics & Incident Response

Sentinel sebagai Alat DFIR

Meskipun Sentinel bukan pengganti dedicated forensic tools (Autopsy, Volatility, Sleuth Kit), ia sangat berguna dalam fase response dan investigation karena:

• Log sudah terkumpul terpusat dan bisa di-query dengan cepat
• Bisa merekonstruksi timeline dari banyak sumber sekaligus
• Entity graph memudahkan understanding blast radius
• Integrasi dengan Live Response Defender for Endpoint untuk forensik endpoint

Timeline Reconstruction

Saat merespons incident, membangun timeline yang akurat adalah prioritas utama. Di Sentinel, gabungkan query dari berbagai tabel dengan kolom TimeGenerated, urutkan secara kronologis, dan filter berdasarkan entitas yang relevan (hostname, username, IP).

Tabel-tabel yang berguna untuk timeline:

• SigninLogs — kapan user login, dari mana, berhasil atau tidak
• AuditLogs — perubahan konfigurasi Azure AD
• SecurityEvent — event Windows Security (logon, process, object access)
• DeviceProcessEvents — proses yang berjalan di endpoint (dari MDE)
• DeviceNetworkEvents — koneksi jaringan dari endpoint
• DeviceFileEvents — file create/modify/delete
• DeviceRegistryEvents — perubahan registry
• DeviceLogonEvents — logon events dari perspektif endpoint

Artifact Penting untuk DFIR di Sentinel

Authentication Artifacts

• Semua login attempts (success dan failure) dari SigninLogs
• Conditional Access evaluations dan hasilnya
• MFA challenges — kapan, hasilnya apa, dari perangkat apa

Process Artifacts

• Process creation dengan command line arguments (DeviceProcessEvents)
• Parent-child process relationship
• Process yang mengakses LSASS
• Unsigned atau low-reputation binaries yang dieksekusi

Network Artifacts

• Koneksi ke IP/domain external yang belum pernah terjadi sebelumnya
• Internal lateral movement (SMB, RDP, WMI)
• DNS resolution untuk domain mencurigakan
• Volume transfer data yang anomali

Persistence Artifacts

• Scheduled tasks yang dibuat
• Registry autorun keys yang dimodifikasi
• Services yang diinstall
• Startup items yang ditambahkan

File Artifacts

• File yang dibuat di lokasi mencurigakan (temp, public, downloads)
• Executable yang di-drop dan langsung dijalankan
• Dokumen yang diakses sebelum potensi exfiltration

Menggunakan Sentinel Notebooks untuk DFIR

Sentinel terintegrasi dengan Jupyter Notebooks via Azure ML atau langsung di Sentinel. Untuk DFIR mendalam, notebooks berguna karena:

• Bisa query KQL dan langsung process hasilnya dengan Python (pandas, seaborn)
• Bisa melakukan analisis yang lebih kompleks dari yang bisa dilakukan murni dengan KQL
• Bisa membuat visualisasi custom untuk laporan
• Ada library MSTICPY (Microsoft Threat Intelligence Python Library) yang khusus dibuat untuk security analysis di Sentinel — berisi fungsi untuk GeoIP, enrichment, network analysis, dll.

Live Response dengan MDE Integration

Dari Sentinel, saat investigasi incident yang melibatkan endpoint, bisa langsung trigger Live Response session ke device via Microsoft Defender for Endpoint:

• Jalankan command di remote device secara real-time
• Collect file untuk analisis forensik
• Run forensic script (custom PowerShell/Bash)
• Upload tool forensik ke remote device
• Isolate device dari jaringan (network isolation)

13. Tabel Log Penting & Maknanya

Identitas & Autentikasi

Endpoint (Windows Security Events)

Endpoint Defender (Microsoft Defender for Endpoint)

Jaringan & Cloud

14. MITRE ATT&CK Mapping di Sentinel

Mengapa Mapping ATT&CK Penting?

MITRE ATT&CK adalah bahasa universal untuk membicarakan taktik dan teknik serangan siber. Dengan memetakan rule detection ke ATT&CK:

• SOC bisa melihat coverage — teknik apa yang sudah terdeteksi dan yang belum
• Komunikasi dengan stakeholder non-teknis lebih mudah
• Incident reporting lebih terstandarisasi
• Mudah membandingkan coverage dengan framework lain

Cara Melihat ATT&CK Coverage di Sentinel

Di halaman Analytics → MITRE ATT&CK (preview), Sentinel menampilkan heatmap interaktif yang menunjukkan teknik ATT&CK mana yang memiliki active detection rules. Teknik yang berwarna gelap = ada coverage, putih = tidak ada coverage.

Gunakan view ini untuk gap analysis — identifikasi teknik high-value yang belum punya coverage detection, lalu prioritaskan pembuatan rule baru.

Taktik ATT&CK vs Fase DFIR

15. Tuning & Noise Reduction

Mengapa Tuning Sangat Penting?

SOC yang kewalahan dengan false positive adalah SOC yang tidak efektif. Alert fatigue adalah salah satu penyebab utama security incident yang terlewat — analyst yang sudah terlalu lelah melihat false positive cenderung mengabaikan alert baru, termasuk yang nyata.

Strategi Tuning

Exclusion Berbasis Entitas: Tambahkan exception untuk entitas yang diketahui menghasilkan false positive. Misalnya: service account tertentu yang selalu trigger "impossible travel" karena berjalan di datacenter dengan IP yang berubah. Atau scanner keamanan internal yang trigger brute force detection.

Penyesuaian Threshold: Naikan threshold untuk environment Anda. Jika threshold "10 failed login" terlalu sensitif dan menghasilkan banyak false positive dari user yang sering lupa password, pertimbangkan naikan ke 20 atau tambahkan kondisi time window yang lebih ketat.

Tuning Berbasis Waktu: Beberapa aktivitas yang normal di jam bisnis bisa mencurigakan di tengah malam. Tambahkan kondisi waktu ke rule jika relevan.

Watchlist untuk Baseline: Gunakan Watchlist untuk mendefinisikan:

• Daftar IP internal yang diizinkan
• Service account yang harus di-exclude dari rule tertentu
• Daftar host yang menjadi admin jump box (boleh login ke banyak server)
• Vendor third-party yang sah mengakses environment

Scoring dan Prioritisasi: Untuk environment dengan volume alert tinggi, buat sistem scoring. Alert dengan dua atau lebih signal yang berkorelasi mendapat prioritas lebih tinggi dari alert tunggal. Ini dilakukan otomatis oleh Fusion, tapi bisa juga dilakukan manual dengan logic rule.

Metrics untuk Mengukur Efektivitas Tuning

• False Positive Rate: Berapa % incident yang di-close sebagai false positive? Target <20% untuk rule yang sudah mature.
• MTTD (Mean Time to Detect): Rata-rata waktu dari kompromis sampai deteksi. Semakin rendah semakin baik.
• MTTR (Mean Time to Respond): Rata-rata waktu dari deteksi sampai containment.
• Alert Volume Trend: Apakah volume alert turun setelah tuning tanpa mengorbankan true positive rate?

16. Checklist Harian SOC Analyst

🌅 Morning Triage (15-30 menit)

• Buka Sentinel → Incidents, filter status "New", sort by severity
• Review semua incident High dan Critical yang belum di-assign
• Assign incident ke analyst yang tepat
• Cek apakah ada incident dari shift malam yang perlu handover/eskalasi
• Review UEBA top anomalous users — siapa yang punya Investigation Priority Score tinggi?
• Cek health data connectors — apakah ada sumber data yang tiba-tiba berhenti kirim log?

🔍 Investigasi Aktif

• Untuk setiap incident yang di-assign: baca semua alert, buka Investigation Graph
• Query timeline entitas yang terlibat di LAW
• Cek reputasi IP/domain/hash di TI
• Jika ada endpoint yang dicurigai: lihat DeviceProcessEvents dan DeviceNetworkEvents
• Dokumentasikan temuan di komentar incident secara real-time (jangan tunggu akhir)
• Eskalasi ke Tier 2/3 jika butuh keahlian tambahan

📊 Review & Reporting (End of Shift)

• Pastikan semua incident punya owner yang jelas
• Close incident yang sudah selesai dengan classification yang tepat
• Update incident yang masih ongoing dengan status terbaru
• Lakukan handover briefing ke shift berikutnya untuk incident yang masih aktif
• Catat any patterns atau anomali yang menarik untuk sharing ke tim
• Review metrics: berapa incident dibuat, berapa diselesaikan, berapa false positive?

📅 Weekly Tasks

• Review analytics rules yang menghasilkan banyak false positive — perlu di-tune?
• Cek Content Hub untuk rule/workbook/playbook baru yang relevan
• Review TI feed — ada IOC baru yang perlu diperhatikan?
• Lakukan satu hunting session proaktif berdasarkan intel terbaru
• Update watchlist jika ada perubahan infrastruktur (IP baru, service account baru)

17. Tips & Best Practices

Untuk SOC Analyst (Tier 1)

Kuasai KQL dasar dulu: Sebelum bisa efektif di Sentinel, pastikan nyaman dengan where, summarize, project, join, dan fungsi waktu. Latihan setiap hari dengan real data akan jauh lebih efektif dari baca tutorial.

Selalu catat temuan di komentar incident: Dokumentasi real-time menghemat waktu jika ada handover, eskalasi, atau perlu review di kemudian hari. Jangan percayakan pada ingatan.

Gunakan Investigation Graph sebagai titik awal: Sebelum mulai query manual, lihat dulu Investigation Graph untuk memahami skala dan hubungan antar entitas.

Jangan close alert terlalu cepat: False positive yang ternyata true positive adalah nightmare. Kalau ragu, eskalasi ke Tier 2.

Pahami context bisnis: Alert yang sama bisa menjadi false positive untuk satu departemen dan true positive untuk departemen lain. Pahami siapa user yang di-alert, posisinya apa, dan apa akses normalnya.

Untuk SOC Engineer / Tier 2-3

Implement detection-as-code: Simpan semua analytics rules, watchlists, dan playbooks di Git repository. Gunakan CI/CD pipeline untuk deploy perubahan. Ini memudahkan version control, review, dan rollback.

Bangun detection library terstruktur: Kategorikan rules berdasarkan ATT&CK tactic, severity, dan data source. Ini memudahkan gap analysis dan onboarding analyst baru.

Monitor kesehatan Sentinel sendiri: Buat workbook atau alert untuk memantau volume log per sumber data, latency ingest, playbook failure, dan LAW ingestion errors.

Lakukan purple team exercise: Kolaborasi dengan red team untuk simulate serangan dan validasi bahwa detection rules benar-benar bekerja. Jangan hanya test di lab — test dengan teknik yang sama persis yang akan digunakan attacker nyata.

Optimalkan biaya: Gunakan DCR (Data Collection Rules) untuk filter log yang tidak diperlukan sebelum dikirim ke LAW. Implement log tiering — hot data di LAW, cold data di Archive tier dengan biaya lebih rendah. Audit secara berkala apakah semua sumber data masih relevan.

Untuk DFIR Analyst

Preserve evidence first: Sebelum melakukan containment, pastikan log sudah tersimpan. Set retention yang cukup di LAW untuk kebutuhan legal/compliance (biasanya minimal 1 tahun, kadang lebih).

Build the timeline, then analyze: Jangan langsung jumping to conclusions. Bangun timeline lengkap dulu dari semua log yang tersedia, baru tarik kesimpulan.

Document everything: Setiap query yang dijalankan, setiap temuan, setiap keputusan — dokumentasikan di incident timeline. Ini penting untuk laporan hukum, asuransi siber, dan lesson learned.

Correlate dengan endpoint forensics: Sentinel log tidak selalu lengkap (tergantung level audit yang dikonfigurasi). Untuk investigasi mendalam, selalu korroborasi dengan live response atau memory/disk forensics dari endpoint yang diduga dikompromis.

📚 Referensi & Resource Lanjutan

Cheat sheet ini dibuat untuk kebutuhan operasional SOC dan DFIR di lingkungan Microsoft Sentinel. Selalu sesuaikan dengan kebijakan dan kebutuhan spesifik organisasi Anda. Versi terakhir: April 2026.