Mengotomatiskan penanganan ancaman di Microsoft Sentinel dengan aturan automasi
Artikel ini menjelaskan aturan otomatisasi Microsoft Azure Sentinel, dan cara menggunakannya untuk menerapkan operasi Orkestrasi, Otomatisasi dan Respons Keamanan (SOAR), dengan meningkatkan efektivitas SOC dan menghemat waktu dan sumber daya Anda.
Penting
Microsoft Azure Sentinel tersedia sebagai bagian dari pratinjau publik untuk platform operasi keamanan terpadu di portal Pertahanan Microsoft. Untuk informasi selengkapnya, lihat Microsoft Azure Sentinel di portal Pertahanan Microsoft.
Apa itu aturan otomasi?
Aturan otomatisasi adalah cara untuk mengelola otomatisasi secara terpusat di Microsoft Azure Sentinel, dengan memungkinkan Anda menentukan dan mengoordinasikan sekumpulan kecil aturan yang dapat diterapkan di berbagai skenario.
Aturan automasi berlaku untuk kategori kasus penggunaan berikut:
Melakukan tugas automasi dasar untuk penanganan insiden tanpa menggunakan playbook. Contohnya:
- Tambahkan tugas insiden untuk diikuti analis.
- Menekan insiden bising.
- Triase insiden baru dengan mengubah statusnya dari Baru ke Aktif dan menetapkan pemilik.
- Tandai insiden untuk mengklasifikasikannya.
- Tingkatkan insiden dengan menetapkan pemilik baru.
- Tutup insiden yang diselesaikan, tentukan alasan dan tambahkan komentar.
Mengotomatiskan respons untuk beberapa aturan analitik sekaligus.
Mengontrol urutan tindakan yang dijalankan.
Memeriksa konten insiden (peringatan, entitas, dan properti lainnya) dan mengambil tindakan lebih lanjut dengan memanggil playbook.
Aturan automasi juga dapat menjadi mekanisme di mana Anda menjalankan playbook sebagai respons terhadap pemberitahuanyang tidak terkait dengan insiden.
Singkatnya, aturan automasi menyederhanakan penggunaan automasi di Microsoft Sentinel, sehingga Anda dapat menyederhanakan alur kerja yang kompleks untuk proses orkestrasi ancaman.
Komponen
Aturan otomasi terdiri dari beberapa komponen:
- Pemicu yang menentukan jenis peristiwa insiden apa yang akan menyebabkan aturan berjalan, tunduk pada...
- Kondisi yang akan menentukan keadaan yang tepat di mana aturan akan berjalan dan melakukan...
- Tindakan untuk mengubah insiden dalam beberapa cara atau mengingat playbook.
Pemicu
Aturan otomatisasi dipicu saat insiden dibuat atau diperbarui atau saat pemberitahuan dibuat. Ingat bahwa insiden mencakup pemberitahuan, dan bahwa pemberitahuan dan insiden dapat dibuat oleh aturan analitik, yang ada beberapa jenis, seperti yang dijelaskan dalam Mendeteksi ancaman dengan aturan analitik bawaan di Microsoft Azure Sentinel.
Tabel berikut menunjukkan berbagai kemungkinan skenario yang memicu aturan otomatisasi untuk dijalankan.
| Jenis pemicu | Peristiwa yang menyebabkan aturan berjalan |
|---|---|
| Ketika insiden dibuat | Platform operasi keamanan terpadu di Pertahanan Microsoft: Microsoft Azure Sentinel tidak di-onboard ke platform terpadu: |
| Ketika insiden diperbarui | |
| Saat peringatan dibuat |
Automasi berbasis insiden atau berbasis peringatan?
Setelah automasi insiden dan automasi peringatan ditangani secara terpusat oleh aturan automasi serta playbook, bagaimana cara mengetahui kapan salah satu automasi tersebut harus digunakan?
Untuk sebagian besar kasus penggunaan, otomatisasi yang dipicu insiden merupakan pendekatan yang lebih disukai. Di Microsoft Azure Sentinel, insiden adalah "file kasus", yakni agregasi semua bukti yang relevan untuk penyelidikan tertentu. Insiden merupakan kontainer untuk peringatan, entitas, komentar, kolaborasi, dan artefak lainnya. Tidak seperti peringatan yang merupakan bukti tunggal, insiden dapat dimodifikasi, memiliki status yang terbaru, dan dapat diperkaya dengan komentar, tag, dan marka buku. Insiden ini memungkinkan Anda melacak cerita serangan yang terus berkembang dengan penambahan pemberitahuan baru.
Untuk alasan ini, sebaiknya bangun automasi Anda berdasarkan insiden. Jadi, cara paling tepat untuk membuat playbook adalah dengan mendasarkannya pada pemicu insiden Microsoft Azure Sentinel di Azure Logic Apps.
Alasan utama untuk menggunakan otomatisasi yang dipicu pemberitahuan adalah untuk menanggapi pemberitahuan yang dihasilkan oleh aturan analitik yang tidak membuat insiden (yaitu, di mana pembuatan insiden telah dinonaktifkan di tab Pengaturan insiden wizard aturan analitik).
Alasan ini sangat relevan ketika ruang kerja Microsoft Azure Sentinel Anda di-onboarding ke platform operasi keamanan terpadu, karena semua pembuatan insiden terjadi di Pertahanan Microsoft XDR, dan oleh karena itu aturan pembuatan insiden di Microsoft Azure Sentinel harus dinonaktifkan.
Bahkan tanpa onboarding ke portal terpadu, Anda mungkin tetap memutuskan untuk menggunakan otomatisasi yang dipicu pemberitahuan jika Anda ingin menggunakan logika eksternal lainnya untuk menentukan apakah dan bagaimana insiden dibuat dari pemberitahuan, serta jika dan bagaimana pemberitahuan dikelompokkan ke dalam insiden. Contohnya:
Playbook dapat dipicu oleh pemberitahuan yang tidak memiliki insiden terkait, memperkaya pemberitahuan dengan informasi dari sumber lain, dan didasarkan pada beberapa logika eksternal yang memutuskan apakah insiden akan dibuat atau tidak.
Playbook dapat dipicu oleh pemberitahuan. Selain itu, alih-alih membuat insiden, playbook mencari insiden yang ada sesuai untuk menambahkan pemberitahuan. Pelajari ekspansi insiden lebih lanjut.
Playbook dapat dipicu oleh pemberitahuan dan memberi tahu personel SOC tentang pemberitahuan tersebut. Dengan begitu, tim dapat memutuskan apakah akan membuat insiden atau tidak.
Playbook dapat dipicu oleh pemberitahuan dan mengirim pemberitahuan ke sistem tiket eksternal untuk pembuatan dan manajemen insiden, sehingga membuat tiket baru untuk setiap pemberitahuan.
Catatan
Otomatisasi yang dipicu pemberitahuan hanya tersedia untuk pemberitahuan yang dibuat oleh aturan analitik keamanan Terjadwal, NRT, dan Microsoft.
Otomatisasi yang dipicu pemberitahuan untuk pemberitahuan yang dibuat oleh Pertahanan Microsoft XDR tidak tersedia di platform operasi keamanan terpadu. Untuk informasi selengkapnya, lihat Automation dengan platform operasi keamanan terpadu.
Kondisi
Rangkaian kondisi yang kompleks dapat didefinisikan untuk mengatur kapan tindakan (lihat di bawah) harus berjalan. Kondisi ini mencakup kejadian yang memicu aturan (insiden dibuat atau diperbarui, atau pemberitahuan dibuat), status atau nilai properti insiden dan properti entitas, dan juga aturan analitik atau aturan yang menghasilkan insiden.
Saat aturan automasi dipicu, aturan tersebut memeriksa insiden pemicu terhadap kondisi yang ditentukan dalam aturan. Untuk insiden, kondisi berbasis properti dievaluasi menurut keadaan saat ini dari properti pada saat evaluasi dilakukan, atau menurut perubahan status properti (lihat di bawah untuk mengetahui detailnya). Karena pembuatan insiden tunggal atau peristiwa pembaruan dapat memicu beberapa aturan automatisasi, urutan yang dijalankan (lihat di bawah) membuat perbedaan dalam menentukan hasil evaluasi kondisi. Tindakan yang ditentukan dalam aturan hanya akan berjalan jika semua kondisi terpenuhi.
Pemicu pembuatan insiden
Untuk aturan yang ditentukan menggunakan pemicu Ketika insiden dibuat, Anda dapat menentukan kondisi yang memeriksa status saat ini nilai dari daftar properti insiden tertentu, menggunakan satu atau beberapa operator berikut:
Nilai properti insiden
- sama dengan atau tidak sama dengan nilai yang ditentukan dalam kondisi.
- berisi atau tidak berisi nilai yang ditentukan dalam kondisi.
- dimulai dengan atau tidak dimulai dengan nilai yang ditentukan dalam kondisi.
- diakhir dengan atau tidak diakhir dengan nilai yang ditentukan dalam kondisi.
Status saat ini dalam konteks ini mengacu pada saat kondisi dievaluasi - yaitu, saat aturan automatisasi berjalan. Jika lebih dari satu aturan automatisasi ditetapkan untuk dijalankan sebagai respons terhadap pembuatan insiden ini, maka perubahan yang dibuat pada insiden oleh aturan automatisasi yang dijalankan sebelumnya dianggap sebagai status saat ini untuk aturan yang dijalankan selanjutnya.
Pemicu pembaruan insiden
Kondisi yang dievaluasi dalam aturan yang ditentukan menggunakan pemicu Ketika insiden diperbarui mencakup semua yang tercantum untuk pemicu pembuatan insiden. Tetapi pemicu pembaruan mencakup lebih banyak properti yang dapat dievaluasi.
Salah satu properti ini Diperbarui oleh. Properti ini memungkinkan Anda melacak jenis sumber yang membuat perubahan dalam insiden tersebut. Anda dapat membuat kondisi yang mengevaluasi apakah insiden diperbarui oleh salah satu nilai berikut, tergantung pada apakah Anda telah melakukan onboarding ruang kerja Anda ke platform operasi keamanan terpadu:
- Aplikasi, termasuk aplikasi di portal Azure dan Defender.
- Pengguna, termasuk perubahan yang dilakukan oleh pengguna di portal Azure dan Defender.
- AIR, untuk pembaruan oleh investigasi dan respons otomatis di Microsoft Defender untuk Office 365
- Pengelompokan pemberitahuan (yang menambahkan pemberitahuan ke insiden), termasuk pengelompokan pemberitahuan yang dilakukan baik oleh aturan analitik maupun logika korelasi Microsoft Defender XDR bawaan
- Playbook
- Aturan otomatisasi
- Lainnya, jika tidak ada nilai di atas yang berlaku
Dengan menggunakan kondisi ini, misalnya, Anda dapat menginstruksikan aturan automatisasi ini untuk dijalankan pada setiap perubahan yang dibuat pada insiden, kecuali jika dibuat oleh aturan automatisasi lain.
Lebih penting lagi, pemicu pembaruan juga menggunakan operator lain yang memeriksa perubahan status dalam nilai properti insiden serta statusnya saat ini. Kondisi perubahan status akan terpenuhi jika:
Nilai properti insiden adalah
- berubah (terlepas dari nilai aktual sebelum atau sesudah).
- berubah dari nilai yang ditentukan dalam kondisi.
- berubah dari nilai yang ditentukan dalam kondisi.
- ditambahkan ke (ini berlaku untuk properti dengan daftar nilai).
Properti tag: individual vs. collection
Tag properti insiden adalah kumpulan item individual—satu insiden dapat memiliki beberapa tag yang diterapkan padanya. Anda dapat menentukan kondisi yang memeriksa setiap tag dalam koleksi satu per satu, dan kondisi yang memeriksa kumpulan tag sebagai unit.
- Setiap operator tag individual memeriksa kondisi terhadap setiap tag dalam koleksi. Evaluasi benar ketika setidaknya satu tag memenuhi kondisi.
- Kumpulan semua operator tag memeriksa kondisi terhadap kumpulan tag sebagai satu unit. Evaluasi hanya berlaku jika koleksi secara keseluruhan memenuhi kondisi.
Perbedaan ini penting ketika kondisi Anda negatif (tidak mengandung), dan beberapa tag dalam koleksi memenuhi kondisi dan yang lain tidak.
Mari kita lihat contoh di mana kondisi Anda berada, Tag tidak berisi "2024", dan Anda memiliki dua insiden, masing-masing dengan dua tag:
| \Insiden ▶ Kondisi ▼ \ |
Insiden 1 Tag 1: 2024 Tag 2: 2023 |
Insiden 2 Tag 1: 2023 Tag 2: 2022 |
|---|---|---|
| Tag individual apa pun tidak berisi "2024" |
BENAR | BENAR |
| Kumpulan semua tag tidak berisi "2024" |
SALAH | BENAR |
Dalam contoh ini, dalam Insiden 1:
- Jika kondisi memeriksa setiap tag satu per satu, maka karena setidaknya ada satu tag yang memenuhi kondisi (yang tidak berisi "2024"), kondisi keseluruhan adalah benar.
- Jika kondisi memeriksa semua tag dalam insiden sebagai satu unit, maka karena setidaknya ada satu tag yang tidak memenuhi kondisi (yang berisi "2024"), kondisi keseluruhan salah.
Dalam Insiden 2, hasilnya akan sama, terlepas dari jenis kondisi mana yang ditentukan.
Pemicu pembuatan pemberitahuan
Saat ini satu-satunya kondisi yang dapat dikonfigurasi untuk pemicu pembuatan pemberitahuan adalah sekumpulan aturan analitik yang aturan automasinya akan berjalan.
Tindakan
Tindakan dapat didefinisikan untuk berjalan ketika kondisi (lihat di atas) terpenuhi. Anda dapat menentukan banyak tindakan dalam aturan dan memilih urutan dijalankannya (lihat di bawah). Tindakan berikut dapat didefinisikan menggunakan aturan otomasi, tanpa perlu fungsionalitas lanjutan dari playbook:
Menambahkan tugas ke insiden – Anda dapat membuat daftar periksa tugas untuk diikuti analis sepanjang proses triase, investigasi, dan remediasi insiden, untuk memastikan bahwa tidak ada langkah penting yang terlewatkan.
Mengubah status insiden, menjaga alur kerja Anda tetap terkini.
- Saat mengubah ke "tertutup", tentukan alasan penutupan dan tambahkan komentar. Ini membantu Anda melacak performa dan efektivitas Anda, serta menyempurnakan untuk mengurangi positif palsu.
Mengubah tingkat keparahan insiden – Anda dapat mengevaluasi ulang dan memprioritaskan ulang berdasarkan kehadiran, ketidakhadiran, nilai, atau atribut entitas yang terlibat dalam insiden tersebut.
Menetapkan insiden ke pemilik – hal ini membantu Anda mengarahkan jenis insiden ke staf yang paling cocok untuk menanganinya, atau staf yang paling tersedia.
Menambahkan tag ke insiden – ini berguna untuk mengklasifikasikan insiden berdasarkan subjek, penyerang, atau penyebut umum lainnya.
Selain itu, Anda dapat menentukan tindakan untuk menjalankan playbook, untuk mengambil tindakan respons yang lebih kompleks, termasuk tindakan apa pun yang melibatkan sistem eksternal. Playbook yang tersedia untuk digunakan dalam aturan otomatisasi bergantung pada pemicu yang menjadi dasar playbook dan aturan: Hanya playbook pemicu insiden yang dapat dijalankan dari aturan automasi pemicu insiden, dan hanya playbook pemicu pemberitahuan yang dapat dijalankan dari aturan automasi pemicu pemberitahuan. Anda dapat menentukan beberapa tindakan yang memanggil playbook, atau kombinasi playbook dan tindakan lainnya. Tindakan akan berjalan sesuai urutan yang tercantum dalam aturan.
Playbook yang menggunakan versi Azure Logic Apps (Standar atau Konsumsi) akan tersedia untuk dijalankan dari aturan otomatisasi.
Tanggal kedaluwarsa
Anda dapat menentukan tanggal kedaluwarsa pada aturan otomasi. Aturan akan dinonaktifkan setelah tanggal tersebut. Ini berguna untuk menangani (yaitu, menutup) insiden "kebisingan" yang disebabkan oleh kegiatan yang direncanakan dan terbatas waktu seperti pengujian penetrasi.
Pesanan
Anda dapat menentukan urutan di mana aturan otomasi akan berjalan. Nantinya aturan otomasi akan mengevaluasi kondisi insiden sesuai dengan keadaannya setelah ditindaklanjuti oleh aturan otomasi sebelumnya.
Misalnya, jika "Aturan Otomasi Pertama" mengubah tingkat keparahan insiden dari Sedang ke Rendah, dan "Aturan Otomasi Kedua" didefinisikan untuk hanya berjalan pada insiden dengan tingkat keparahan sedang atau lebih tinggi, itu tidak akan berjalan pada insiden itu.
Urutan aturan otomatisasi yang menambahkan tugas insiden menentukan urutan tugas akan muncul dalam insiden tertentu.
Aturan berdasarkan pemicu pembaruan memiliki antrean pesanan terpisah sendiri. Jika aturan tersebut dipicu untuk dijalankan pada insiden yang baru dibuat (oleh perubahan yang dilakukan oleh aturan otomatisasi lain), aturan tersebut akan berjalan hanya setelah semua aturan yang berlaku berdasarkan pemicu pembuatan telah berjalan.
Catatan tentang urutan dan prioritas eksekusi
- Mengatur nomor pesanan dalam aturan otomatisasi menentukan urutan eksekusinya.
- Setiap jenis pemicu mempertahankan antreannya sendiri.
- Untuk aturan yang dibuat dalam portal Azure, bidang pesanan akan secara otomatis diisi dengan angka berikut angka tertinggi yang digunakan oleh aturan yang ada dari jenis pemicu yang sama.
- Namun, untuk aturan yang dibuat dengan cara lain (baris perintah, API, dll.), nomor pesanan harus ditetapkan secara manual.
- Tidak ada mekanisme validasi yang mencegah beberapa aturan memiliki nomor pesanan yang sama, bahkan dalam jenis pemicu yang sama.
- Anda dapat mengizinkan dua aturan atau lebih dari jenis pemicu yang sama untuk memiliki nomor pesanan yang sama, jika Anda tidak peduli urutan mana yang mereka jalankan.
- Untuk aturan jenis pemicu yang sama dengan nomor pesanan yang sama, mesin eksekusi secara acak memilih aturan mana yang akan berjalan di urutan mana.
- Untuk aturan jenis pemicu insiden yang berbeda, semua aturan yang berlaku dengan jenis pemicu pembuatan insiden akan berjalan terlebih dahulu (sesuai dengan nomor pesanannya), dan hanya kemudian aturan dengan jenis pemicu pembaruan insiden (sesuai dengan nomor pesanannya).
- Aturan selalu berjalan secara berurutan, tidak pernah secara paralel.
Catatan
Setelah onboarding ke platform operasi keamanan terpadu, jika beberapa perubahan dilakukan pada insiden yang sama dalam periode lima hingga sepuluh menit, satu pembaruan dikirim ke Microsoft Azure Sentinel, hanya dengan perubahan terbaru.
Kasus dan skenario penggunaan umum
Tugas insiden
Aturan otomatisasi memungkinkan Anda menstandarkan dan memformalisasi langkah-langkah yang diperlukan untuk triaging, investigasi, dan remediasi insiden, dengan membuat tugas yang dapat diterapkan pada satu insiden, di seluruh grup insiden, atau ke semua insiden, sesuai dengan kondisi yang Anda tetapkan dalam aturan otomatisasi dan logika deteksi ancaman dalam aturan analitik yang mendasarinya. Tugas yang diterapkan pada insiden muncul di halaman insiden, sehingga analis Anda memiliki seluruh daftar tindakan yang perlu mereka ambil, tepat di depannya, dan tidak akan melewatkan langkah-langkah penting apa pun.
Automasi yang dipicu insiden dan pemberitahuan
Aturan otomatisasi dapat dipicu oleh pembuatan atau pembaruan insiden dan juga oleh pembuatan pemberitahuan. Kejadian ini semua dapat memicu rantai respons otomatis, yang dapat mencakup playbook (izin khusus diperlukan).
Picu playbook untuk penyedia Microsoft
Aturan otomasi menyediakan cara untuk mengotomasi penanganan pemberitahuan keamanan Microsoft dengan menerapkan aturan ini pada insiden yang dibuat dari pemberitahuan. Aturan otomasi dapat memanggil playbook(diperlukan izin khusus) dan meneruskan insiden kepada mereka dengan semua detailnya, termasuk pemberitahuan dan entitas. Secara umum, praktik terbaik Microsoft Azure Sentinel ditentukan menggunakan antrean insiden sebagai titik fokus operasi keamanan.
Pemberitahuan keamanan Microsoft meliputi yang berikut ini:
- Microsoft Entra ID Protection
- Microsoft Defender for Cloud
- Microsoft Defender for Cloud Apps
- Microsoft Defender for Office 365
- Pertahanan Microsoft untuk Titik Akhir
- Microsoft Defender for Identity
- Microsoft Defender for IoT
Beberapa playbook/tindakan berurutan dalam satu aturan
Anda sekarang dapat memiliki kontrol hampir penuh atas urutan pelaksanaan tindakan dan playbook dalam satu aturan otomatisasi. Anda juga mengontrol urutan pelaksanaan aturan otomasi itu sendiri. Ini memungkinkan Anda untuk sangat menyederhanakan playbook Anda, menguranginya menjadi satu tugas atau urutan tugas yang kecil dan mudah, dan menggabungkan playbook kecil ini dalam kombinasi yang berbeda dalam aturan otomasi yang berbeda.
Tetapkan satu playbook ke beberapa aturan analitik sekaligus
Jika Anda memiliki tugas yang ingin Anda otomatiskan pada semua aturan analitik Anda – misalnya, pembuatan tiket dukungan dalam sistem tiket eksternal – Anda dapat menerapkan satu playbook ke salah satu atau semua aturan analitik Anda – termasuk aturan masa depan – dalam satu bidikan. Ini membuat perawatan sederhana tetapi berulang dan tugas pemeliharaan jauh lebih sedikit dari tugas.
Penugasan insiden otomatis
Anda dapat menetapkan insiden kepada pemilik yang tepat secara otomatis. Jika SOC Anda memiliki analis yang memiliki spesialisasi dalam platform tertentu, insiden apa pun yang terkait dengan platform tersebut dapat secara otomatis ditetapkan ke analis tersebut.
Penindasan insiden
Anda dapat menggunakan aturan untuk secara otomatis menyelesaikan insiden yang diketahui palsu/positif jinak tanpa menggunakan playbook. Misalnya, saat menjalankan tes penetrasi, melakukan pemeliharaan atau peningkatan terjadwal, atau menguji prosedur otomatisasi, banyak insiden positif palsu mungkin dibuat yang ingin diabaikan SOC. Aturan otomasi terbatas waktu dapat secara otomatis menutup insiden ini saat dibuat, sambil menandainya dengan deskriptor penyebab pembuatannya.
Otomasi terbatas waktu
Anda dapat menambahkan tanggal kedaluwarsa untuk aturan otomasi Anda. Mungkin ada kasus selain penindasan insiden yang menjamin otomatisasi terbatas waktu. Anda mungkin ingin menetapkan jenis insiden tertentu kepada pengguna tertentu (misalnya, magang atau konsultan) untuk jangka waktu tertentu. Jika jangka waktu diketahui sebelumnya, Anda dapat secara efektif menyebabkan aturan dinonaktifkan di akhir relevansinya, tanpa harus ingat untuk melakukannya.
Menandai insiden secara otomatis
Anda dapat secara otomatis menambahkan tag teks bebas ke insiden untuk mengelompokkan atau mengklasifikasikannya sesuai dengan kriteria yang Anda pilih.
Gunakan kasus yang ditambahkan oleh pemicu pembaruan
Sekarang setelah perubahan yang dibuat pada insiden dapat memicu aturan automatisasi, lebih banyak skenario terbuka untuk automatisasi.
Perpanjang automatisasi saat insiden berkembang
Anda dapat menggunakan pemicu pembaruan untuk menerapkan banyak kasus penggunaan di atas ke insiden saat penyelidikan berlangsung dan analis menambahkan peringatan, komentar, dan tag. Kontrol pengelompokan peringatan dalam insiden.
Perbarui orkestrasi dan pemberitahuan
Beri tahu berbagai tim Anda dan personel lain saat terjadi perubahan pada insiden, sehingga mereka tidak akan melewatkan pembaruan penting apa pun. Tingkatkan insiden dengan menetapkannya ke pemilik baru dan memberi tahu pemilik baru tentang penugasan mereka. Kontrol kapan dan bagaimana insiden dibuka kembali.
Pertahankan sinkronisasi dengan sistem eksternal
Jika Anda telah menggunakan playbook untuk membuat tiket di sistem eksternal saat insiden dibuat, Anda dapat menggunakan aturan automatisasi pemicu pembaruan untuk menggunakan playbook yang akan memperbarui tiket tersebut.
Eksekusi aturan otomasi
Aturan automasi dijalankan secara berurutan, sesuai urutan yang Anda tentukan. Setiap aturan otomasi dijalankan setelah aturan sebelumnya selesai dijalankan. Dalam aturan otomasi, semua tindakan dijalankan secara berurutan dalam urutan di mana mereka didefinisikan.
Tindakan playbook dalam aturan otomatisasi mungkin diperlakukan secara berbeda dalam beberapa keadaan, sesuai dengan kriteria berikut:
| Durasi playbook | Aturan Azure Automation menuju ke tindakan berikutnya... |
|---|---|
| Kurang dari satu detik | Segera setelah playbook selesai |
| Kurang dari dua menit | Hingga dua menit setelah playbook mulai berjalan, tetapi tidak lebih dari 10 detik setelah playbook selesai |
| Lebih dari dua menit | Dua menit setelah playbook mulai berjalan, terlepas dari apakah playbook selesai atau tidak |
Izin untuk aturan otomasi untuk menjalankan playbook
Saat aturan otomatisasi Microsoft Azure Sentinel menjalankan playbook, aturan ini menggunakan akun layanan Microsoft Azure Sentinel khusus yang secara khusus diizinkan untuk tindakan ini. Penggunaan akun ini (dibandingkan dengan akun pengguna Anda) meningkatkan tingkat keamanan layanan.
Agar aturan otomasi dapat menjalankan playbook, akun ini harus diberikan izin eksplisit ke grup sumber daya tempat playbook berada. Pada saat itu, setiap aturan automasi akan dapat menjalankan playbook apa pun dalam grup sumber daya tersebut.
Saat Anda mengonfigurasi aturan otomasi dan menambahkan tindakan jalankan playbook, daftar drop-down playbook akan muncul. Playbook yang tidak dapat diakses oleh Microsoft Azure Sentinel akan ditampilkan sebagai tidak tersedia ("berwarna abu-abu"). Anda dapat memberikan izin Microsoft Azure Sentinel ke grup sumber daya playbook di tempat tersebut dengan memilih tautan Kelola izin playbook. Untuk memberikan izin tersebut, Anda memerlukan izin Pemilik pada grup sumber daya tersebut. Lihat persyaratan izin penuh.
Izin dalam arsitektur multipenyewa
Aturan automasi sepenuhnya mendukung penyebaran lintas ruang kerja dan multipenyewa (dalam kasus multipenyewa, menggunakan Azure Lighthouse).
Oleh karena itu, jika penyebaran Microsoft Azure Sentinel Anda menggunakan arsitektur multipenyewa, Anda dapat memiliki aturan otomatisasi dalam satu penyewa yang menjalankan playbook yang berada di penyewa yang berbeda, tetapi izin bagi Sentinel untuk menjalankan playbook harus ditentukan di penyewa tempat playbook berada, bukan di penyewa tempat aturan otomatisasi ditentukan.
Dalam kasus spesifik Penyedia Layanan Keamanan Terkelola (MSSP), di mana penyewa penyedia layanan mengelola ruang kerja Microsoft Azure Sentinel di penyewa pelanggan, ada dua skenario khusus yang memerlukan perhatian Anda:
Aturan otomasi yang dibuat di penyewa pelanggan dikonfigurasi untuk menjalankan playbook yang terletak di penyewa penyedia layanan.
Pendekatan ini biasanya digunakan untuk melindungi kekayaan intelektual dalam playbook. Tidak ada syarat khusus untuk menjalankan skenario ini. Saat menentukan tindakan playbook dalam aturan otomatisasi, dan Anda sampai ke tahap di mana Anda memberikan izin Microsoft Azure Sentinel pada grup sumber daya yang relevan tempat playbook berada (menggunakan panel Kelola izin playbook), Anda akan melihat grup sumber daya milik penyewa penyedia layanan tempat Anda dapat memilih salah satunya. Lihat seluruh proses yang diuraikan di sini.
Aturan otomasi yang dibuat di ruang kerja pelanggan (saat masuk ke penyewa penyedia layanan) dikonfigurasi untuk menjalankan playbook yang terletak di penyewa pelanggan.
Konfigurasi ini digunakan ketika tidak perlu melindungi kekayaan intelektual. Agar skenario ini berfungsi, izin untuk menjalankan playbook harus diberikan kepada Microsoft Sentinel di kedua penyewa. Di penyewa pelanggan, Anda memberikannya di panel Kelola izin playbook, seperti dalam skenario di atas. Untuk memberikan izin yang relevan di penyewa penyedia layanan, Anda perlu menambahkan delegasi Azure Lighthouse tambahan yang memberikan hak akses ke aplikasi Azure Security Insights, dengan peran Kontributor Otomatisasi Microsoft Azure Sentinel, pada grup sumber daya tempat playbook berada.
Skenarionya terlihat sepert inii:
Lihat instruksi kami untuk menyiapkan ini.
Membuat dan mengelola aturan otomasi
Anda dapat membuat dan mengelola aturan otomatisasi dari berbagai area di Microsoft Sentinel atau platform operasi keamanan terpadu, tergantung pada kebutuhan dan kasus penggunaan khusus Anda.
Halaman automasi
Aturan otomatisasi dapat dikelola secara terpusat di halaman Automation , di bawah tab Aturan otomatisasi. Dari sana, Anda dapat membuat aturan otomatisasi baru dan mengedit yang sudah ada. Anda juga dapat menyeret aturan otomasi untuk mengubah urutan eksekusi, dan mengaktifkan atau menonaktifkannya.
Di halaman Automation , Anda akan melihat semua aturan yang ditentukan di ruang kerja, bersama dengan statusnya (Diaktifkan/Dinonaktifkan) dan aturan analitik mana yang diterapkan.
Saat Anda memerlukan aturan otomatisasi yang akan berlaku untuk insiden dari Microsoft Defender XDR, atau dari banyak aturan analitik di Microsoft Azure Sentinel, buat langsung di halaman Automation .
Wizard aturan analitik
Di tab Respons otomatis wizard aturan analitik Microsoft Azure Sentinel, di bawah Aturan otomatisasi, Anda dapat melihat, mengedit, dan membuat aturan otomatisasi yang berlaku untuk aturan analitik tertentu yang dibuat atau diedit dalam wizard.
Anda akan melihat bahwa saat Anda membuat aturan aitomatisasi dari sini, panel Buat aturan automatisasi baru menunjukkan kondisi aturan analitik sebagai tidak tersedia, karena aturan ini telah disetel untuk diterapkan hanya pada aturan analitik yang Anda edit di wisaya. Semua opsi konfigurasi lainnya masih tersedia untuk Anda.
Halaman insiden
Anda juga dapat membuat aturan otomatisasi dari halaman Insiden, untuk merespons satu insiden berulang. Ini berguna saat membuat aturan penekanan untuk menutup insiden "berisik" secara otomatis.
Anda akan melihat bahwa saat Anda membuat aturan automatisasi dari sini, panel Buat aturan automatisasi baru telah mengisi semua bidang dengan nilai dari insiden tersebut. Ini menamai aturan dengan nama yang sama dengan insiden, menerapkannya ke aturan analitik yang menghasilkan insiden, dan menggunakan semua entitas yang tersedia dalam insiden sebagai kondisi aturan. Ini juga menyarankan tindakan penindasan (penutupan) secara default dan menyarankan tanggal kedaluwarsa untuk aturan. Anda dapat menambahkan atau menghapus kondisi dan tindakan, serta mengubah tanggal kedaluwarsa, sesuai keinginan Anda.
Langkah berikutnya
Dalam dokumen ini, Anda mempelajari cara menggunakan aturan automasi guna mengelola automasi respons secara terpusat untuk insiden dan pemberitahuan Microsoft Sentinel.
- Membuat dan menggunakan aturan automatisasi Microsoft Azure Sentinel untuk mengelola insiden.
- Gunakan aturan otomatisasi untuk membuat daftar tugas untuk analis.
- Untuk mempelajari lebih lanjut opsi otomatisasi tingkat lanjut, lihat Mengotomatiskan respons ancaman dengan playbook di Microsoft Azure Sentinel.
- Untuk bantuan dalam menerapkan playbook, lihat Tutorial: Menggunakan playbook untuk mengotomatiskan respons ancaman di Microsoft Sentinel.