Integrasi SIEM akan membantu analis menyelidiki kondisi autentikasi, bukan menciptakan insiden untuk setiap baris laporan agregat yang gagal. Pilih tujuan dan alur kerja tertentu. Panduan ini menggunakan penyerapan Azure Monitor dan manajemen insiden Microsoft Sentinel sebagai contoh desain yang terdokumentasi, dengan usulan pemetaan dan keputusan hipotetis, bukan integrasi EmailAuth yang diklaim.
Pisahkan observasi dari temuan
Sebuah laporan agregat mencatat evaluasi otentikasi. Temuan menambah interpretasi seperti pengirim penagihan yang disetujui tiba-tiba kalah penyelarasan. Simpan populasi bukti, rentang waktu, pengirim yang diketahui, kepercayaan, dan dampak bisnis. RFC 9990 menyediakan semantik pelaporan; hal ini tidak menetapkan bahwa setiap kegagalan itu berbahaya atau bahwa suatu insiden harus dibuka.
Gunakan kunci korelasi terbatas yang berisi cakupan pelanggan, domain, pengirim, dan kondisi. Hindari memasukkan badan pesan atau alamat penerima ke dalam peristiwa ketika metadata dan referensi bukti yang dikontrol akses sudah mencukupi. Cantumkan waktu kejadian dan waktu penyerapan secara terpisah sehingga bukti yang tertunda tidak disalahartikan sebagai pemadaman saat ini.
Petakan ke batas penyerapan sebenarnya
Dokumentasi API Penyerapan Log Azure Monitor menjelaskan pengiriman data melalui aturan pengumpulan data ke dalam tabel target, dengan autentikasi dan izin terkait. Penerapan memerlukan skema tabel aktual, aliran, titik akhir, DCR, dan identitas resmi. Serialisasi JSON yang berhasil saja tidak membuktikan bahwa layanan menerima atau mengindeks peristiwa tersebut.
Pemetaan yang diusulkan menetapkan nilai event_time ke TimeGenerated dan menentukan kolom khusus TenantScope_s, Domain_s, FindingType_s, EvidenceRef_s, CorrelationKey_s, Severity_s, dan SchemaVersion_s. Nama khusus ini adalah skema yang diusulkan, bukan bidang Sentinel bawaan. TenantScope_s adalah label korelasi aplikasi; itu tidak menerapkan isolasi atau izin penyewa Azure. Konfigurasikan dan uji akses secara terpisah.
Korelasikan dan kelola insiden tersebut
Putuskan apakah aturan analitik menyebabkan insiden dari data yang diserap atau adaptor resmi mengelola insiden secara langsung. Hindari menjalankan kedua jalur tanpa deduplikasi. Itu Insiden Sentinel Membuat atau Memperbarui API mendokumentasikan operasi PUT terhadap ID insiden tertentu untuk versi 01-09-2025, dengan bidang judul, tingkat keparahan, dan status yang diperlukan. Sematkan versi sebenarnya dalam implementasi dan tangani konkurensi daripada menimpa pekerjaan analis secara membabi buta.
Pertahankan hubungan korelasi-kunci-ke-insiden-ID. Alokasikan ID insiden yang berbeda untuk setiap kunci cakupan penyewa tepercaya; menggunakan kembali satu ID tetap di seluruh kunci dapat menimpa insiden pelanggan lain. Validasi pengikatan penyewa sebelum korelasi, karena string penyewa yang disediakan oleh peristiwa yang tidak tepercaya bukanlah otoritas. Pengamatan yang berulang-ulang dapat memperbarui kejadian yang ada dengan bukti tambahan alih-alih membuka duplikat. Tetapkan seorang analis dan tindakan selanjutnya. Penutupan harus mencatat apa yang diselidiki dan mengapa hasilnya dapat dibenarkan, menggunakan bidang status dan klasifikasi tujuan yang didukung.
Pisahkan korelasi pelanggan dan keputusan analis
Misalkan dua observasi dari peta kehilangan penyelarasan pengirim yang disetujui yang sama ke satu insiden cakupan pelanggan, sedangkan pengiriman berulang dari observasi pertama tidak menambahkan bukti duplikat. Temuan pelanggan kedua yang serupa harus dipetakan ke tujuan resminya dan identitas insiden yang berbeda. Menggunakan kembali satu ID insiden tetap di kedua kunci berisiko menimpa rekaman yang salah, meskipun label korelasi berisi nama penyewa.
Secara terpisah, seorang analis dapat menutup insiden pertama setelah mengkonfirmasi rencana pengujian yang diharapkan. Peristiwa yang terlambat tidak boleh menimpa keputusan tersebut atau membukanya kembali tanpa aturan siklus hidup yang disetujui. Simpan bukti yang ada, evaluasi apakah observasi baru mengubah temuan dan selesaikan pengeditan bersamaan menggunakan kontrak tujuan. Ini adalah keputusan hipotetis, bukan insiden aktual, hasil klasifikasi, atau pengujian siklus hidup yang dijalankan.
Panduan ini tidak membuat DCR, tidak memperoleh token, tidak menyerap log, dan tidak memanggil API Sentinel. Sebelum penerimaan produksi, jalankan acara pengujian resmi melalui tujuan sebenarnya, verifikasi bidang yang diindeks dan akses penyewa, lakukan pengiriman duplikat, dan konfirmasikan penutupan tanpa menimpa perubahan analis yang tidak terkait. Simpan ID permintaan dan hasil yang diamati. Jika ada tahapan yang hilang, beri label integrasi sebagai desain terdokumentasi dengan eksekusi yang tertunda, bukan kontrol yang diterapkan.