Membuka Visibilitas M365: Mengapa Konektor SIEM Bawaan Membuat Anda Buta

By Mirko Peters · 2026-08-11

Selamat datang kembali di blog! Jika Anda mengelola operasi keamanan untuk organisasi yang menggunakan Microsoft 365, Anda kemungkinan merasa aman secara semu. Anda mengklik "en…

Automatically translated with AI from the original post. Read the English original

Selamat datang kembali di blog! Jika Anda mengelola operasi keamanan untuk organisasi yang menggunakan Microsoft 365, Anda kemungkinan merasa aman secara semu. Anda mengklik "enable" pada konektor M365 bawaan SIEM Anda, memastikan log sudah mengalir, dan mencentang kotak kepatuhan. Namun, apakah Anda benar-benar terlindungi? Kenyataan yang tidak nyaman adalah bahwa konektor SIEM bawaan sering kali menyisakan titik buta yang besar, dengan sepenuhnya mengabaikan beban kerja cloud tingkat lanjut tempat penyerang modern sering beroperasi. Untuk membahas topik penting ini secara menyeluruh, pastikan Anda mendengarkan episode podcast pendamping kami, Kirim Log Microsoft 365 Penting ke SIEM Anda, tempat kami mengulas celah-celah ini secara rinci.

Dalam artikel ini, kita akan membahas secara mendalam mengapa konfigurasi bawaan Anda gagal, di mana titik buta tersembunyi berada, dan bagaimana Anda dapat membangun pipeline ingesti yang tangguh dan hemat biaya, yang menghasilkan deteksi bersinyal tinggi yang benar-benar dapat digunakan oleh analis Anda.

Titik Buta Microsoft 365 di Berbagai SIEM Populer

Apakah Anda menggunakan Microsoft Sentinel, Splunk, atau QRadar, template ingesti bawaan umumnya berfokus pada log masuk Azure AD dasar dan log aktivitas Office 365 yang sederhana. Meskipun ini mencakup hal-hal paling mendasar, beban kerja penting tetap sepenuhnya terekspos. Di berbagai platform SIEM populer, ada beberapa titik buta utama yang secara konsisten muncul:

• Exchange: Konektor bawaan sering melewatkan akses kotak surat oleh pihak yang bukan pemilik, pembuatan aturan dan penerusan yang mencurigakan, aktivitas SendAs atau SendOnBehalf, serta perubahan izin kotak surat yang tiba-tiba.
• SharePoint dan OneDrive: Anda mungkin melihat unduhan file, tetapi apakah Anda melihat pembuatan dan penggunaan tautan eksternal dan anonim, pembagian ulang file, atau perubahan izin situs yang memiliki hak istimewa?
• Teams: Penyerang senang berkolaborasi secara terbuka. Konfigurasi bawaan jarang mencatat berbagi eksternal melalui saluran yang didukung SharePoint, penghapusan dan pengeditan pesan, perubahan kebijakan rapat, atau sideloading aplikasi yang tidak sah.
• Power Platform: Maraknya lingkungan low-code/no-code membawa risiko tersembunyi. Lonjakan pembuatan flow dan aplikasi, penggunaan konektor berisiko (seperti Outlook, Teams, atau konektor HTTP arbitrer), serta upaya melewati kebijakan Data Loss Prevention (DLP) sering kali tidak tercatat.
• Sensitivitas dan DLP: Penerapan label, peristiwa penghapusan, kecocokan kebijakan, dan penggantian manual sering kali sama sekali tidak ada kecuali secara eksplisit ditargetkan.
• Konteks Azure AD: Konteks penting mengenai log masuk berisiko, hasil akses bersyarat, serta anomali perangkat atau geografis sering kali tidak disertakan dalam kueri standar.

Akar Penyebab: Mengapa Anda Melewatkan Peristiwa Penting

Mengapa aliran telemetri penting ini bisa hilang? Hal ini jarang terjadi secara kebetulan; sebaliknya, ini adalah hasil dari pilihan arsitektur dan komersial yang dibuat oleh penyedia platform maupun pembeli perusahaan.

Pertama, pembatasan lisensi memegang peranan besar. Auditing tingkat lanjut, telemetri Exchange yang terperinci, dan pencatatan peristiwa SharePoint yang lengkap sering kali hanya tersedia pada lisensi tingkat lebih tinggi seperti Microsoft 365 E5 atau add-on Advanced Audit. Jika penyewa Anda menggunakan tingkat E3, peristiwa tersebut sejak awal tidak dihasilkan maupun disimpan.

Kedua, batasan cakupan konektor membatasi pengumpulan data. Konektor standar umumnya hanya menarik aliran "OfficeActivity" dasar dan mengabaikan beban kerja tingkat lanjut. Ketiga, pembatasan throughput API dan penundaan batching dapat membebani pengumpul native selama jam sibuk, sehingga menyebabkan log hilang. Keempat, celah parser berarti bahwa meskipun blob JSON mentah sudah tiba di SIEM Anda, kolom yang tidak dipetakan dan perubahan skema yang diam-diam membuatnya terlihat seperti kode yang tidak bermakna. Terakhir, kontrol biaya yang diterapkan oleh tim yang sensitif anggaran diam-diam mengecualikan kategori yang berisik tanpa memahami implikasi keamanannya.

Menyeimbangkan Pengendalian Biaya Tanpa Kehilangan Visibilitas

Salah satu penolakan terbesar terhadap ingesti visibilitas Microsoft 365 yang "lengkap" adalah biaya. Mengingesti setiap log yang dihasilkan oleh penyewa M365 berskala besar dapat menguras anggaran penyimpanan keamanan Anda. Namun, Anda tidak harus memilih antara bangkrut dan tetap buta. Anda perlu menyaring dengan cerdas, bukan mengurangi secara sembarangan.

Mulailah dengan menyaring data di hulu. Konfigurasikan mekanisme ingestion Anda agar hanya menyertakan operasi bernilai sinyal tinggi, seperti New-InboxRule, Add-MailboxPermission, atau peristiwa pembuatan dan penggunaan tautan anonim. Hilangkan duplikasi dan gabungkan peristiwa yang berisik dan bernilai rendah, seperti penyimpanan versi SharePoint di latar belakang, sebelum data tersebut masuk ke SIEM Anda.

Terapkan strategi penyimpanan bertingkat. Simpan penyimpanan panas (hot) dalam waktu singkat (30 hingga 60 hari) untuk investigasi yang sedang berjalan, dan alihkan penyimpanan dingin atau arsip ke object store yang lebih murah agar memenuhi jangka waktu kepatuhan. Selain itu, modelkan volume data sebelum mengaktifkan aliran data baru. Perkirakan gigabyte per hari berdasarkan sumber, lalu gandakan estimasi tersebut untuk memperhitungkan lonjakan bisnis, audit triwulanan, atau periode penemuan hukum (legal discovery).

Merancang Pipeline Ingestion yang Tangguh

Mengandalkan konektor polling langsung yang rapuh adalah resep untuk kehilangan peringatan saat insiden keamanan berlangsung dalam tekanan tinggi. Sebaliknya, rancanglah pipeline yang tangguh dan sadar akan pembatasan laju (throttling). Pola yang kuat terlihat seperti ini:

• Sumber: Ambil data dari M365 Unified Audit Log, Advanced Audit, log sign-in dan log risiko Azure AD, Microsoft Information Protection (MIP), peringatan DLP, serta peringatan keamanan Microsoft Defender.
• Transpor: Alirkan data dari Graph atau Management API ke Azure Event Hub (yang berfungsi sebagai buffer dan mekanisme replay) sebelum meneruskannya ke SIEM Anda.
• Pemrosesan: Normalisasi dan perkaya data tepat di landing zone, dengan menambahkan konteks pengguna, penanda departemen, penanda VIP, status perangkat, dan data geografis.
• Tata kelola: Terapkan pemeriksaan kelengkapan harian, handler backoff untuk batas laju 429, pemantauan perubahan skema, serta peringatan dead-letter queue.

Normalisasi dan Pengayaan untuk Data yang Siap Dianalisis

Log M365 mentah terkenal berantakan, penuh dengan objek JSON bersarang dan konvensi penamaan field yang tidak konsisten antar-workload. Jika Anda menyerahkan data mentah kepada analis Tier 1, mereka akan menghabiskan separuh shift untuk menguraikan payload alih-alih melakukan triase ancaman.

Ratakan field-field utama saat ingestion: Actor, Target, Action, ResourcePath, LinkType (anonymous, organization, atau specific people), ExternalRecipient, dan LabelName. Petakan field-field ini ke skema terpadu, seperti Azure Monitor Common Security Incident Model (ASIM) atau Elastic Common Schema (ECS), agar pengembangan deteksi Anda mencakup seluruh workload secara mulus. Terakhir, perkaya peristiwa ini dengan data HR (peran, jenis kepegawaian, departemen), daftar VIP, daftar izinkan mitra (partner allowlist), status kepatuhan perangkat, dan klasifikasi sensitivitas.

Deteksi Bernilai Sinyal Tinggi untuk Segera Diterapkan

Setelah pipeline Anda berjalan dan data Anda ternormalisasi, Anda dapat menerapkan deteksi bernilai sinyal tinggi yang benar-benar mampu menangkap perilaku penyerang yang canggih. Berikut delapan deteksi dasar yang sebaiknya segera Anda terapkan:

• Mailbox Exfiltration: Deteksi aturan kotak masuk baru yang meneruskan pesan ke pihak eksternal atau memindahkan pesan ke RSS/Junk, yang terjadi dalam satu jam setelah login dari lokasi geografis baru atau perangkat yang tidak dikenal.
• Stealth Access: Tandai akses kotak surat oleh pihak non-pemilik ke akun VIP apabila disertai peristiwa Add-MailboxPermission dalam 24 jam sebelumnya.
• SharePoint Spill: Beri peringatan pada tautan berbagi anonim atau "specific people" yang dibuat pada file berlabel Confidential atau Restricted.
• Link Abuse: Deteksi volume unduhan eksternal yang tinggi dalam jendela 15 menit yang berasal dari tautan berbagi yang baru dibuat dari IP atau ASN baru.
• Teams Pivot: Tangkap skenario ketika sebuah file dibagikan ke pihak eksternal dan pengguna yang sama menambahkan tamu eksternal ke Team dalam dua jam.
• Power Automate Abuse: Tandai lonjakan mendadak tiga atau lebih pembuatan flow harian oleh akun non-developer, khususnya yang menggunakan konektor HTTP atau Outlook.
• Privilege Creep: Lacak penambahan dan penghapusan berulang pada peran member atau admin di workspace atau situs sensitif yang sama dalam jendela 24 jam.
• Stale Truth: Deteksi ketika dataset konten eksekutif atau keuangan gagal diperbarui selama dua siklus atau lebih, sehingga pimpinan terlindungi dari pengambilan keputusan berdasarkan data yang sudah usang.

Rencana Implementasi 30 Hari untuk Menutup Celah

Memperbaiki postur visibilitas M365 Anda tidak perlu memakan waktu setahun. Anda dapat menutup celah visibilitas secara sistematis hanya dalam 30 hari:

• Minggu 1: Aktifkan Advanced Audit jika diperlukan, inventarisasi konektor SIEM Anda saat ini, dan petakan kategori peristiwa yang belum tercakup.
• Minggu 2: Siapkan pipeline Event Hub Anda. Arahkan telemetri Unified Audit Logs, Advanced Audit, Azure AD, dan Defender, lalu terapkan filter di bagian hulu.
• Minggu 3: Normalisasi dan perkaya aliran data Anda, isi ulang log kritis selama 30 hari terakhir, dan terapkan tujuh deteksi bersinyal tinggi yang disebutkan di atas dengan jendela penekanan (suppression window) yang tepat.
• Minggu 4: Optimalkan biaya dengan membuang sisa noise dan menyesuaikan tingkat retensi. Tambahkan pemantauan kelengkapan data, lalu jalankan latihan tabletop purple-team yang menguji aturan kotak surat, berbagi eksternal, dan lonjakan alur.

KPI Eksekutif untuk Membuktikan Hasilnya

Ketika pimpinan bertanya apakah anggaran keamanan yang dihabiskan untuk perbaikan pipeline itu sepadan, Anda memerlukan metrik untuk membuktikan keberhasilan Anda. Pantau KPI eksekutif berikut:

• Cakupan: Persentase keluarga event M365 yang ditargetkan dan berhasil diserap serta diurai (target 95% atau lebih).
• Kecepatan: Mean Time to Acknowledge (MTTA) dan Mean Time to Resolve (MTTR) untuk insiden terkait M365 (tren menurun).
• Noise: Rasio alert terhadap true positive (tren naik dalam kualitas sinyal).
• Biaya: Biaya per gigabyte yang diserap (tren menurun sekitar 40% berkat pemfilteran di bagian hulu).
• Keandalan: Jumlah hari dengan celah penyerapan data (targetnya nol) dan SLA perubahan skema (pembaruan parser dalam tujuh hari setelah modifikasi skema Microsoft).

Jebakan Umum dan Cara Mengatasinya

Rencana terbaik pun bisa menemui hambatan. Waspadai jebakan umum berikut:

Tim sering mengatakan, "Kami sudah menyalakannya," padahal log tidak pernah muncul karena lisensi Advanced Audit atau baseline audit kotak surat belum benar-benar diverifikasi. Masalah umum lainnya terjadi ketika aturan SIEM tetap diam sepenuhnya selama serangan karena aturan tersebut mengevaluasi event secara terisolasi, bukan mengorelasikan pembuatan aturan, pergeseran geografis, dan berbagi eksternal.

Lonjakan tagihan terjadi ketika pra-filter dilewati. Selalu lakukan pra-filter pada operasi yang berisik dan kecualikan event sinkronisasi latar belakang. Pembusukan parser adalah pembunuh senyap lainnya; tetapkan rutinitas perbandingan skema bulanan dan jalankan unit test terhadap sampel payload. Terakhir, kelelahan analis cepat muncul jika alert tidak memiliki konteks. Pastikan alert Anda selalu mencakup siapa, apa, di mana, dan label sensitivitas, lengkap dengan tautan langsung ke Microsoft Compliance Center untuk pendalaman.

Kesimpulan: Berhenti Mengandalkan Kepatuhan untuk Perlindungan

Intinya sederhana: konektor SIEM bawaan membuat Anda patuh, tetapi tidak membuat Anda terlindungi. Dengan mengambil log Microsoft 365 yang tepat, menormalisasinya ke dalam skema terpadu, memperkayanya dengan konteks bisnis yang krusial, dan memburu ancaman dengan deteksi yang disetel sesuai perilaku penyerang di dunia nyata, Anda dapat menghilangkan titik buta sepenuhnya. Begitulah cara SIEM Anda berhenti melewatkan cerita dan mulai menuliskannya. Untuk mendalami strategi ini lebih jauh, dengarkan episode lengkapnya di Send Critical Microsoft 365 Logs to Your SIEM dan mulai tutup celah visibilitas Anda hari ini!