Bagikan melalui


Mengotomatiskan penanganan ancaman di Microsoft Sentinel dengan aturan automasi

Artikel ini menjelaskan apa itu aturan otomatisasi Microsoft Sentinel, dan cara menggunakannya untuk mengimplementasikan operasi Security Orchestration, Automation and Response (SOAR) Anda. Aturan automasi meningkatkan efektivitas SOC Anda dan menghemat waktu dan sumber daya Anda.

Penting

Microsoft Sentinel umumnya tersedia di portal Microsoft Defender, termasuk untuk pelanggan tanpa Microsoft Defender XDR atau lisensi E5.

Mulai Juli 2026, Microsoft Sentinel hanya akan didukung di portal Defender, dan pelanggan yang tersisa yang menggunakan portal Microsoft Azure akan dialihkan secara otomatis.

Kami menyarankan agar setiap pelanggan yang menggunakan Microsoft Sentinel di Azure mulai merencanakan transisi ke portal Defender untuk pengalaman operasi keamanan terpadu penuh yang ditawarkan oleh Pertahanan Microsoft. Untuk informasi selengkapnya, lihat Merencanakan perpindahan Anda ke portal Pertahanan Microsoft untuk semua pelanggan Microsoft Azure Sentinel.

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 agar dapat diikuti oleh 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 pemberitahuan yang 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 menyebabkan aturan berjalan, tunduk pada kondisi.
  • Kondisi yang menentukan keadaan yang tepat di mana aturan berjalan dan melakukan tindakan.
  • Tindakan untuk mengubah insiden dalam beberapa cara atau memanggil playbook, yang melakukan tindakan yang lebih kompleks dan berinteraksi dengan layanan lain.

Pemicu

Aturan otomatisasi dipicu saat insiden dibuat atau diperbarui atau saat pemberitahuan dibuat. Ingat bahwa insiden menyertakan pemberitahuan, dan bahwa pemberitahuan dan insiden dapat dibuat oleh aturan analitik, seperti yang dijelaskan dalam Deteksi ancaman di Microsoft Azure Sentinel.

Tabel berikut ini memperlihatkan berbagai kemungkinan skenario yang menyebabkan aturan otomatisasi berjalan.

Jenis pemicu Peristiwa yang menyebabkan aturan berjalan
Ketika insiden dibuat Portal Pertahanan Microsoft:
  • Insiden baru dibuat di portal Pertahanan Microsoft.

    Microsoft Sentinel tidak tergabung ke portal Defender:
  • Insiden baru dibuat oleh aturan analitik.
  • Insiden diserap dari Pertahanan Microsoft XDR.
  • Insiden baru dibuat secara manual.
  • Ketika suatu insiden diperbarui
  • Status insiden diubah (ditutup/dibuka kembali/di-triase).
  • Pemilik insiden ditetapkan atau diubah.
  • Tingkat keparahan insiden dinaikkan atau diturunkan.
  • Pemberitahuan ditambahkan ke insiden.
  • Komentar, tag, atau taktik ditambahkan ke insiden.
  • Saat pemberitahuan dibuat
  • Pemberitahuan dibuat oleh aturan analitik Terjadwal atau NRT Microsoft Sentinel.
  • Automasi berbasis insiden atau berbasis peringatan?

    Dengan aturan otomatisasi yang menangani respons secara terpusat terhadap insiden dan pemberitahuan, bagaimana Anda harus memilih mana yang akan diotomatiskan, dan dalam keadaan mana?

    Untuk sebagian besar kasus penggunaan, otomatisasi yang dipicu insiden adalah pendekatan yang lebih disukai. Di Microsoft Sentinel, insiden adalah "file kasus" – yaitu penggabungan semua bukti yang relevan untuk penyelidikan tertentu. Insiden merupakan kontainer untuk peringatan, entitas, komentar, kolaborasi, dan artefak lainnya. Tidak seperti alert yang merupakan bukti tunggal, insiden dapat dimodifikasi, memiliki status yang paling diperbarui, dan dapat diperkaya dengan komentar, tag, dan penanda. 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 oleh peringatan adalah untuk menanggapi peringatan yang dihasilkan oleh aturan analitik yang tidak membuat insiden (yaitu, di mana pembuatan insiden dinonaktifkan di tab Pengaturan Insiden di wizard aturan analitik).

    Alasan ini sangat relevan ketika ruang kerja Microsoft Azure Sentinel Anda di-onboarding ke portal Defender. Dalam skenario ini, semua pembuatan insiden terjadi di portal Defender, 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 memutuskan apakah dan kapan membuat insiden dari pemberitahuan, dan bagaimana pemberitahuan dikelompokkan bersama. Contohnya:

    • Playbook, yang dipicu oleh pemberitahuan yang tidak memiliki insiden terkait, dapat memperkaya pemberitahuan dengan informasi dari sumber lain, dan berdasarkan beberapa logika eksternal memutuskan apakah akan membuat insiden atau tidak.

    • Playbook, yang dipicu oleh pemberitahuan, dapat, alih-alih membuat insiden, mencari insiden yang sesuai untuk menambahkan pemberitahuan. Pelajari selengkapnya tentang pengembangan insiden.

    • Playbook, yang dipicu oleh pemberitahuan, dapat memberi tahu personel SOC tentang pemberitahuan sehingga tim dapat memutuskan apakah akan membuat insiden atau tidak.

    • Playbook, yang dipicu oleh pemberitahuan, dapat mengirim pemberitahuan ke sistem tiket eksternal untuk pembuatan dan manajemen insiden, dan sistem tersebut membuat tiket baru untuk setiap pemberitahuan.

    Catatan

    • Otomatisasi yang dipicu peringatan hanya tersedia untuk peringatan yang dibuat oleh aturan analitik Terjadwal, NRT, dan keamanan Microsoft.

    • Otomatisasi yang dipicu pemberitahuan untuk pemberitahuan yang dibuat oleh Microsoft Defender XDR tidak tersedia di portal Defender. Untuk informasi selengkapnya, lihat Otomatisasi di portal Defender.

    Kondisi

    Rangkaian kondisi yang kompleks dapat didefinisikan untuk mengatur kapan tindakan (lihat di bawah) harus berjalan. Kondisi ini termasuk peristiwa yang memicu aturan (insiden yang dibuat atau diperbarui, atau peringatan dibuat), status atau nilai properti insiden dan properti entitas (hanya untuk pemicu insiden), dan juga aturan atau aturan analitik yang menghasilkan insiden atau peringatan.

    Saat aturan automasi dipicu, aturan tersebut memeriksa insiden pemicu terhadap kondisi yang ditentukan dalam aturan. Untuk insiden, kondisi berbasis properti dievaluasi sesuai dengan status properti saat ini saat evaluasi terjadi, atau sesuai dengan perubahan status properti (lihat di bawah ini untuk detailnya). Karena pembuatan atau pembaruan suatu insiden dapat memicu beberapa aturan otomatisasi, urutan mereka dijalankan (lihat di bawah) berpengaruh penting dalam menentukan hasil evaluasi kondisi. Tindakan yang ditentukan dalam aturan hanya dijalankan jika semua kondisi terpenuhi.

    Pemicu pembuatan insiden

    Untuk aturan yang ditentukan menggunakan pemicu Saat insiden dibuat, Anda dapat menentukan kondisi yang memeriksa status nilai saat ini dari daftar properti insiden tertentu, menggunakan satu atau beberapa operator berikut:

    • 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.

    Misalnya, jika Anda menentukan nama aturan analitik sebagai Berisi == serangan brute force terhadap PC Cloud, aturan analitik dengan serangan brute force terhadap portal Azure tidak memenuhi kondisi. Namun, jika Anda menentukan Nama aturan Analitik sebagai Tidak berisi == Kredensial pengguna, maka serangan Brute force terhadap PC Cloud dan Brute force terhadap aturan analitik portal Microsoft Azure memenuhi kondisi tersebut.

    Catatan

    Status saat ini dalam konteks ini mengacu pada saat kondisi dievaluasi - yaitu, saat aturan otomatisasi 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 Saat 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 melakukan onboarding ruang kerja Anda ke portal Defender:

    • Aplikasi, termasuk aplikasi di portal Azure dan Defender.
    • Pengguna, termasuk perubahan yang dilakukan oleh pengguna di portal Azure dan Defender.
    • AIR, untuk pembaruan oleh penyelidikan 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.

    Intinya, pemicu pembaruan juga menggunakan operator lain yang memeriksa perubahan status pada nilai-nilai properti insiden serta statusnya sekarang. Kondisi perubahan status akan terpenuhi jika:

    Nilai properti insiden adalah

    • diubah (terlepas dari nilai aktual sebelum atau sesudah).
    • diubah dari nilai yang ditentukan dalam kondisi.
    • diubah ke nilai yang ditentukan dalam kondisi.
    • ditambahkan ke (ini berlaku untuk properti dengan daftar nilai).

    Properti tag: individu vs. koleksi

    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 ketikasetidaknya satu tag memenuhi kondisi.
    • Kumpulan semua tag operator memeriksa kondisi koleksi 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 sama, terlepas dari jenis kondisi mana yang ditentukan.

    Properti entitas yang didukung

    Untuk daftar properti entitas yang didukung sebagai kondisi untuk aturan otomatisasi, lihat Referensi aturan otomatisasi Microsoft Azure Sentinel.

    Pemicu pembuatan pemberitahuan

    Saat ini satu-satunya kondisi yang dapat dikonfigurasi untuk pemicu pembuatan pemberitahuan adalah sekumpulan aturan analitik tempat aturan otomatisasi dijalankan.

    Tindakan

    Tindakan dapat didefinisikan untuk berjalan ketika kondisi (lihat di atas) terpenuhi. Anda dapat menentukan banyak tindakan dalam aturan, dan Anda dapat memilih urutan menjalankannya (lihat di bawah). Tindakan berikut dapat didefinisikan menggunakan aturan otomatisasi, tanpa perlu fungsionalitas lanjutan dari playbook:

    • Menambahkan tugas ke insiden – Anda dapat membuat daftar tugas yang dapat diikuti oleh para analis sepanjang proses penilaian awal atau triase, investigasi, dan penyelesaian atau remediasi insiden, untuk memastikan bahwa tidak ada langkah penting yang terlewatkan.

    • Mengubah status insiden, menjaga alur kerja Anda tetap terkini.

      • Saat mengubah ke "tertutup", menentukan alasan penutupan dan menambahkan komentar. Ini membantu Anda melacak performa dan efektivitas Anda, dan 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 yang melibatkan sistem eksternal. Playbook yang tersedia untuk digunakan dalam aturan otomasi bergantung pada pemicu di mana playbook dan aturan otomasi didasarkan: Hanya playbook pemicu insiden yang dapat dijalankan dari aturan otomasi pemicu insiden, dan hanya playbook pemicu peringatan yang dapat dijalankan dari aturan otomasi pemicu peringatan. Anda dapat menentukan beberapa tindakan yang memanggil playbook, atau kombinasi playbook dan tindakan lainnya. Tindakan dijalankan dalam urutan di mana tindakan tersebut tercantum dalam aturan.

    Playbook yang menggunakan salah satu versi Azure Logic Apps (Standar atau Konsumsi) tersedia untuk dijalankan dari aturan otomatisasi.

    Tanggal kedaluwarsa

    Anda dapat menentukan tanggal kedaluwarsa pada aturan otomasi. Aturan dinonaktifkan setelah tanggal tersebut berlalu. 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 otomatisasi dijalankan. Kemudian aturan otomatisasi mengevaluasi kondisi insiden sesuai dengan keadaannya setelah ditindaklanjuti oleh aturan otomatisasi sebelumnya.

    Misalnya, jika "Aturan Automasi Pertama" mengubah tingkat keparahan insiden dari Sedang ke Rendah, dan "Aturan Otomatisasi Kedua" didefinisikan untuk berjalan hanya pada insiden dengan tingkat keparahan Sedang atau lebih tinggi, itu tidak berjalan pada insiden tersebut.

    Urutan aturan otomatisasi yang menambahkan tugas insiden menentukan urutan tugas muncul dalam insiden tertentu.

    Aturan berdasarkan pemicu pembaruan memiliki antrean pesanan terpisah sendiri. Jika aturan tersebut dipicu untuk berjalan pada insiden yang baru saja dibuat (oleh perubahan yang dibuat oleh aturan otomatisasi lain), aturan tersebut hanya berjalan setelah semua aturan yang berlaku berdasarkan pemicu pembuatan selesai 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 di portal Azure, bidang urutan secara otomatis diisi dengan angka yang mengikuti 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 berjalan di urutan mana.
    • Untuk aturan jenis pemicu insiden yang berbeda, semua aturan yang berlaku dengan jenis pemicu pembuatan insiden dijalankan terlebih dahulu (berdasarkan nomor urutannya), dan baru kemudian aturan dengan jenis pemicu pembaruan insiden (berdasarkan nomor urutan mereka).
    • Aturan selalu berjalan secara berurutan, tidak pernah secara paralel.

    Catatan

    Setelah onboarding ke portal Defender, 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 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. Semua kejadian ini 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 otomatisasi dapat memanggil playbook (izin khusus diperlukan) dan mengalihkan insiden kepada mereka dengan semua rinciannya, termasuk peringatan 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:

    • Perlindungan ID Microsoft Entra
    • Microsoft Defender untuk Cloud
    • Microsoft Defender untuk Aplikasi Cloud
    • Pertahanan Microsoft untuk Office 365
    • Pertahanan Microsoft untuk Titik Akhir
    • Microsoft Defender untuk Identitas
    • 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 dan personel lainnya saat perubahan dilakukan pada insiden, sehingga mereka tidak 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 menggunakan playbook untuk membuat tiket di sistem eksternal saat insiden dibuat, Anda dapat menggunakan aturan otomatisasi pemicu pembaruan untuk memanggil playbook yang memperbarui tiket tersebut.

    Eksekusi aturan otomasi

    Aturan otomatisasi dijalankan secara berurutan, sesuai dengan 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 otomasi akan dapat menjalankan playbook apa pun dalam grup sumber daya tersebut.

    Saat Anda mengonfigurasi aturan otomatisasi dan menambahkan tindakan run playbook, menu tarik-turun playbook akan muncul. Playbook di mana Microsoft Sentinel tidak memiliki izin ditampilkan sebagai tidak tersedia ("berwarna abu-abu"). Anda dapat memberikan izin kepada Microsoft Sentinel pada grup sumber daya playbook secara langsung dengan memilih tautan Kelola izin playbook. Untuk memberikan izin tersebut, Anda memerlukan izin Pemilik pada grup sumber daya tersebut. Lihat persyaratan izin lengkap.

    Izin dalam arsitektur multipenyewa

    Aturan otomatisasi sepenuhnya mendukung penyebaran lintas ruang kerja dan penyebaran multitenant (dalam kasus multitenant, 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 otomatisasi yang dibuat di tenant pelanggan dikonfigurasi untuk menjalankan playbook yang berada di tenant 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 otomasi Anda, dan Anda mencapai tahap di mana Anda memberikan izin kepada Microsoft Sentinel pada grup sumber daya relevan tempat playbook tersebut berada (menggunakan panel Kelola izin playbook), Anda dapat melihat grup sumber daya yang dimiliki oleh penyewa penyedia layanan di antara opsi yang dapat Anda pilih. Lihat seluruh proses yang diuraikan di sini.

    • Sebuah aturan otomatisasi yang dibuat di ruang kerja pelanggan (ketika masuk sebagai tenant penyedia layanan) dikonfigurasi untuk menjalankan playbook yang terletak di tenant pelanggan.

      Konfigurasi ini digunakan ketika tidak perlu melindungi kekayaan intelektual. Agar skenario ini berfungsi, izin untuk menjalankan playbook perlu diberikan kepada Microsoft Sentinel di kedua entitas. Di penyewa pelanggan, Anda memberikan akses kepada mereka di panel Kelola izin playbook, seperti yang dilakukan dalam skenario di atas. Untuk memberikan izin yang relevan di penyewa penyedia layanan, Anda perlu menambahkan delegasi tambahan Azure Lighthouse yang memberikan hak akses ke aplikasi Azure Security Insights dengan peran Kontributor Otomatisasi Microsoft Sentinel pada kelompok sumber daya tempat playbook berada.

      Skenarionya terlihat sepert inii:

      Arsitektur aturan otomatisasi multi-penyewa

      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 portal Pertahanan, 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 berlaku untuk insiden dari Microsoft Defender XDR, atau dari banyak aturan analitik di Microsoft Sentinel, buat langsung di halaman Automation.

    • Panduan aturan analitik

      Di tab Tanggapan otomatis dari wizard aturan analitik Microsoft Sentinel, di bawah Aturan otomatisasi, Anda dapat melihat, mengedit, dan membuat aturan otomatisasi yang berlaku untuk aturan analitik tertentu yang sedang dibuat atau diedit dalam wizard.

      Saat Anda membuat aturan otomatisasi dari sini, panel Buat aturan otomatisasi baru memperlihatkan kondisi aturan analitik sebagai tidak tersedia, karena aturan ini sudah diatur untuk diterapkan hanya ke aturan analitik yang Sedang Anda edit di wizard. Semua opsi konfigurasi lainnya masih tersedia untuk Anda.

    • Halaman insiden

      Anda juga dapat membuat aturan otomatisasi dari halaman Insiden untuk merespons insiden yang berulang satu per satu. Ini berguna saat membuat aturan supresi untuk menutup insiden "berisik" secara otomatis.

      Saat Anda membuat aturan otomatisasi dari sini, panel Buat aturan otomatisasi baru mengisi semua bidang dengan nilai dari insiden. 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.

    Mengekspor dan mengimpor aturan otomatisasi

    Ekspor aturan otomatisasi Anda ke file templat Azure Resource Manager (ARM), dan impor aturan dari file-file ini, sebagai bagian dari mengelola dan mengontrol penyebaran Microsoft Azure Sentinel Anda sebagai kode. Tindakan ekspor membuat file JSON di lokasi unduhan browser Anda, yang kemudian dapat Anda ganti nama, pindahkan, dan tangani seperti file lainnya.

    File JSON yang diekspor bersifat independen dari ruang kerja, sehingga dapat diimpor ke ruang kerja lain dan bahkan penyewa lainnya. Sebagai kode, versi file tersebut juga dapat dikontrol, diperbarui, dan disebarkan dalam kerangka kerja CI/CD terkelola.

    File mencakup semua parameter yang ditentukan dalam aturan otomatisasi. Aturan jenis pemicu apa pun dapat diekspor ke file JSON.

    Untuk petunjuk tentang mengekspor dan mengimpor aturan otomatisasi, lihat Mengekspor dan mengimpor aturan otomatisasi Microsoft Azure Sentinel.

    Langkah berikutnya

    Dalam dokumen ini, Anda mempelajari cara menggunakan aturan automasi guna mengelola automasi respons secara terpusat untuk insiden dan pemberitahuan Microsoft Sentinel.