Pemecahan masalah aturan analitik di Microsoft Azure Sentinel
Artikel ini menjelaskan cara menangani masalah tertentu yang mungkin muncul dengan eksekusi aturan analitik terjadwal di Microsoft Azure Sentinel.
Masalah: Tidak ada peristiwa yang muncul dalam hasil kueri
Saat pengelompokan peristiwa diatur untuk memicu peringatan untuk setiap peristiwa, hasil kueri yang dilihat di lain waktu mungkin tampak hilang, atau berbeda dari yang diharapkan. Misalnya, Anda mungkin melihat hasil kueri di lain waktu saat menyelidiki insiden terkait, dan sebagai bagian dari investigasi tersebut, Anda memutuskan untuk mempivot kembali ke hasil kueri ini sebelumnya.
Hasil disimpan secara otomatis dengan peringatan. Namun, jika hasilnya terlalu besar, tidak ada hasil yang disimpan, dan tidak ada data yang muncul saat menampilkan hasil kueri lagi.
Dalam kasus di mana ada penundaan penyerapan, atau kueri tidak deterministik karena agregasi, hasil pemberitahuan mungkin berbeda dari hasil yang ditunjukkan dengan menjalankan kueri secara manual.
Untuk mengatasi masalah ini, ketika aturan memiliki pengaturan pengelompokan peristiwa ini, Microsoft Sentinel menambahkan bidang OriginalQuery ke hasil kueri. Berikut adalah perbandingan bidang Kueri yang ada dan bidang baru:
| Nama bidang | Berisi | Menjalankan kueri di bidang ini menghasilkan... |
|---|---|---|
| Kueri | Catatan terkompresi peristiwa yang menghasilkan instans pemberitahuan ini. | Peristiwa yang menghasilkan instans pemberitahuan ini; dibatasi hingga 10 kilobyte. |
| OriginalQuery | Kueri asli seperti yang ditulis dalam aturan analitik. | Peristiwa terbaru dalam jangka waktu di mana kueri berjalan, yang sesuai dengan parameter yang ditentukan oleh kueri. |
Dengan kata lain, bidang OriginalQuery berulah seperti bidang Kueri berulah di bawah pengaturan pengelompokan peristiwa default.
Masalah: Aturan terjadwal gagal dijalankan, atau muncul dengan AUTO DISABLED yang ditambahkan ke namanya
Ini jarang terjadi bahwa aturan kueri terjadwal gagal dijalankan, tetapi ini bisa terjadi. Microsoft Azure Sentinel mengklasifikasikan kegagalan di depan sebagai sementara atau permanen, berdasarkan jenis kegagalan tertentu dan keadaan yang menyebabkannya.
Kegagalan sementara
Kegagalan sementara terjadi karena keadaan sementara dan segera kembali normal, di mana eksekusi aturan berhasil. Beberapa contoh kegagalan yang diklasifikasikan Microsoft Azure Sentinel sebagai sementara adalah:
- Kueri aturan membutuhkan waktu terlalu lama untuk dijalankan dan waktu habis.
- Masalah konektivitas antara sumber data dan Log Analytics, atau antara Log Analytics dan Microsoft Azure Sentinel.
- Kegagalan baru dan tidak diketahui lainnya dianggap sementara.
Jika terjadi kegagalan sementara, Microsoft Azure Sentinel terus mencoba mengeksekusi aturan lagi setelah interval yang ditentukan sebelumnya dan terus meningkat, hingga satu titik. Setelah itu, aturan akan berjalan lagi hanya pada waktu yang dijadwalkan berikutnya. Aturan tidak pernah dapat diskotomatis karena kegagalan sementara.
Kegagalan permanen—aturan autodisabled
Kegagalan permanen terjadi karena perubahan kondisi yang memungkinkan aturan berjalan, yang tanpa intervensi manusia tidak dapat kembali ke status sebelumnya. Berikut ini adalah beberapa contoh kegagalan yang diklasifikasikan sebagai permanen:
- Ruang kerja target (tempat kueri aturan dioperasikan) dihapus.
- Tabel target (tempat kueri aturan dioperasikan) dihapus.
- Microsoft Sentinel dihapus dari ruang kerja target.
- Fungsi yang digunakan oleh kueri aturan tidak lagi valid; itu dimodifikasi atau dihapus.
- Izin ke salah satu sumber data kueri aturan diubah (lihat contoh).
- Salah satu sumber data kueri aturan dihapus.
Jika terjadi sejumlah kegagalan permanen berturut-turut yang ditentukan sebelumnya, dengan jenis yang sama dan aturan yang sama, Microsoft Azure Sentinel berhenti mencoba eksekusi aturan, dan juga mengambil langkah-langkah berikut:
- Menonaktifkan aturan.
- Menambahkan kata "AUTO DISABLED" ke awal nama aturan.
- Menambahkan alasan kegagalan (dan penonaktifan) ke deskripsi aturan.
Anda dapat dengan mudah menentukan keberadaan aturan yang dapat diskotomatis, dengan mengurutkan daftar aturan menurut nama. Aturan yang dapat diubah otomatis berada di atau di dekat bagian atas daftar.
Manajer SOC harus memastikan untuk memeriksa daftar aturan secara teratur untuk keberadaan aturan yang dapat diubah otomatis.
Kegagalan permanen karena pembuangan sumber daya
Jenis kegagalan permanen lainnya terjadi karena kueri yang dibuat secara tidak benar yang menyebabkan aturan mengonsumsi sumber daya komputasi yang berlebihan dan risiko menjadi pengosongan performa pada sistem Anda. Ketika Microsoft Azure Sentinel mengidentifikasi aturan seperti itu, dibutuhkan tiga langkah yang sama yang disebutkan untuk jenis kegagalan permanen lainnya—menonaktifkan aturan, menambahkan "AUTO DISABLED" ke nama aturan, dan menambahkan alasan kegagalan ke deskripsi.
Untuk mengaktifkan kembali aturan, Anda harus mengatasi masalah dalam kueri yang menyebabkannya menggunakan terlalu banyak sumber daya. Lihat artikel berikut untuk praktik terbaik untuk mengoptimalkan kueri Kusto Anda:
Lihat Juga Sumber daya yang berguna untuk bekerja dengan Bahasa Kueri Kusto di Microsoft Azure Sentinel untuk bantuan lebih lanjut.
Kegagalan permanen karena kehilangan akses di seluruh langganan/penyewa
Salah satu contoh khusus ketika kegagalan permanen dapat terjadi karena perubahan izin pada sumber data (lihat daftar) menyangkut kasus Penyedia Solusi Keamanan Microsoft (MSSP)—atau skenario lain di mana aturan analitik dikueri di seluruh langganan atau penyewa.
Saat Anda membuat aturan analitik, token izin akses diterapkan ke aturan dan disimpan bersama dengannya. Token ini memastikan bahwa aturan dapat mengakses ruang kerja yang berisi tabel yang direferensikan oleh kueri aturan, dan bahwa akses ini dipertahankan meskipun pembuat aturan kehilangan akses ke ruang kerja tersebut.
Namun, ada satu pengecualian: ketika aturan dibuat untuk mengakses ruang kerja di langganan atau penyewa lain, seperti apa yang terjadi dalam kasus MSSP, Microsoft Sentinel mengambil langkah-langkah keamanan ekstra untuk mencegah akses tidak sah ke data pelanggan. Aturan semacam ini memiliki kredensial pengguna yang membuat aturan yang diterapkan padanya, alih-alih token akses independen. Ketika pengguna tidak lagi memiliki akses ke penyewa lain, aturan berhenti berfungsi.
Jika Anda mengoperasikan Microsoft Sentinel dalam skenario lintas langganan atau lintas penyewa, dan jika salah satu analis atau insinyur Anda kehilangan akses ke ruang kerja tertentu, aturan apa pun yang dibuat oleh pengguna tersebut akan berhenti berfungsi. Anda akan mendapatkan pesan pemantauan kesehatan mengenai "akses ke sumber daya yang tidak mencukup", dan aturan akan dapat diskotomatis sesuai dengan prosedur yang dijelaskan sebelumnya.
Langkah berikutnya
Untuk informasi selengkapnya, lihat:
- Tutorial: Menyelidiki insiden dengan Microsoft Azure Sentinel
- Menavigasi dan menyelidiki insiden di Microsoft Azure Sentinel - Pratinjau
- Mengklasifikasikan dan menganalisis data menggunakan entitas di Microsoft Azure Sentinel
- Tutorial: Menggunakan playbook dengan aturan otomatisasi di Microsoft Azure Sentinel
Selain itu, pelajari contoh penggunaan aturan analitik kustom saat memantau Zoom dengan konektor kustom.