Memahami penundaan deteksi aturan

Didukung di:

Google secops SIEM

Dokumen ini menjelaskan penundaan deteksi aturan di Google Security Operations, mengidentifikasi faktor-faktor penyebab, menguraikan pendekatan pemecahan masalah, dan menyarankan teknik untuk mengurangi penundaan jika memungkinkan.

Aturan deteksi

Aturan deteksi memeriksa peristiwa Model Data Universal (UDM) entitas dan reguler, yang merupakan log mentah yang dinormalisasi, untuk menghasilkan deteksi sesuai dengan spesifikasi aturan. Peristiwa UDM entitas biasanya berisi informasi konteks seperti detail pengguna atau aset. Aturan juga menghasilkan deteksi berdasarkan deteksi yang dihasilkan sebelumnya.

Keterlambatan yang diperkirakan dan tidak diperkirakan

Deteksi aturan selalu memiliki penundaan, mulai dari mendekati real-time hingga beberapa menit atau beberapa jam. Faktor seperti jenis aturan, frekuensi eksekusi, dan metode pembuatan deteksi memengaruhi penundaan ini. Dokumen ini membahas faktor-faktor penundaan ini dan faktor lainnya.

Kami mengategorikan keterlambatan sebagai diharapkan atau tidak terprediksi.

• Penundaan yang diharapkan: Penundaan ini adalah hasil dari proses penyerapan dan pilihan konfigurasi yang Anda buat saat menyiapkan aturan deteksi.
  Misalnya, pembuatan deteksi memerlukan waktu. Penundaan ini bergantung pada faktor struktural yang diketahui, seperti jenis aturan, frekuensi eksekusi, metode pembuatan deteksi, batasan yang diketahui, dan faktor-faktor lainnya yang dapat diprediksi.
  Anda dapat meminimalkan penundaan ini dengan mengubah atau menyesuaikan konfigurasi aturan deteksi, seperti yang dijelaskan dalam dokumen ini.
  Untuk mengetahui detailnya, lihat Tips untuk mempercepat proses.

• Penundaan yang tidak dapat diprediksi: Ini adalah penundaan khusus aturan atau khusus peristiwa yang disebabkan oleh banyak faktor, termasuk penundaan dalam data peristiwa yang tiba di Google SecOps, kelambatan sementara dalam pemrosesan pipeline dalam layanan Google SecOps, pengayaan ulang, dan penundaan pemrosesan data lainnya.

Menganalisis penundaan deteksi aturan

Untuk menganalisis penundaan deteksi aturan, temukan informasi tentang aturan dan faktor-faktor di sekitarnya:

1. Di konsol Google SecOps, buka Detection > Rules and detections.

   Dasbor Aturan menampilkan metadata aturan seperti Rule name, Rule type, dan Run frequency.

   Untuk mengetahui detail selengkapnya, lihat Melihat aturan di dasbor Aturan.

2. Di dasbor Aturan, gunakan penelusuran untuk mengidentifikasi aturan yang mengalami penundaan deteksi yang lama.

3. Untuk eksekusi aturan tertentu, ada beberapa faktor yang dapat memengaruhi latensi deteksi. Dimensi seperti Rule type, Run frequency, Event type, Event time, dan Ingested time adalah heuristik yang baik untuk memahami alasan deteksi tertentu mungkin tertunda.

4. Pahami topik berikut untuk memahami bagaimana faktor-faktor ini memengaruhi penundaan deteksi aturan:

   • Metode pembuatan deteksi
   • Batasan umum
   • Faktor yang menyebabkan keterlambatan deteksi aturan

Metode pembuatan deteksi

Pelajari cara sistem membuat deteksi aturan untuk memahami pengaruh metode pembuatan deteksi terhadap penundaan deteksi.

Sistem menghasilkan deteksi aturan dengan cara berikut:

1. Mesin streaming

   Streaming Engine adalah pipeline cepat yang biasanya beroperasi dengan penundaan kurang dari lima menit. Aturan ini memproses aturan peristiwa tunggal dengan bagian tidak ada kecocokan dan tidak ada set data eksternal seperti daftar referensi atau tabel data.

2. Mesin kueri

   Mesin kueri memproses aturan sebagai berikut:

   • Aturan peristiwa tunggal yang kompleks:

     • Aturan peristiwa tunggal yang mereferensikan daftar rujukan atau tabel data.
     • Aturan peristiwa tunggal berjangka waktu yang menggunakan jangka waktu kecocokan dengan kondisi sederhana. Misalnya, "peristiwa saat jumlah peristiwa kami > 0". Aturan ini berjalan pada frekuensi kueri yang tinggi (real-time) saat data baru dimasukkan dan tersedia untuk pemrosesan aturan.

   • Aturan multi-peristiwa: Aturan ini mengkueri data selama blok waktu peristiwa (10 menit, per jam, harian), sesuai dengan jadwal yang Anda tetapkan.
     Misalnya, untuk jadwal 10 menit, aturan akan mengkueri ulang blok waktu peristiwa setelah 5 hingga 8 jam dan 24 hingga 48 jam, bergantung pada linimasa pemrosesan upstream.

3. Aturan yang dijalankan terhadap data historis

   Untuk mengetahui detailnya, lihat Perburuan retro.

4. Pengayaan ulang peristiwa UDM

   Untuk mengetahui detailnya, lihat Pengayaan ulang peristiwa UDM dan Pemrosesan grafik konteks entitas

Batasan umum

Berikut beberapa batasan standar yang menyebabkan keterlambatan deteksi aturan:

• Penundaan pengayaan terkadang memerlukan waktu lebih lama dari yang diperkirakan. Pemrosesan ulang pengayaan menyebabkan aturan yang dijalankan selanjutnya mengevaluasi ulang data. Sistem menjalankan beberapa proses pengayaan, dengan proses terakhir terjadi tiga hari setelah waktu acara.
• Aturan multi-peristiwa sering kali menggabungkan data kontekstual yang tiba beberapa jam setelah waktu peristiwa utama. Latensi tinggi dalam data kontekstual ini dapat menyebabkan pemrosesan pengayaan ulang dan pemutaran ulang aturan berinteraksi, sehingga menyebabkan deteksi tertunda. Meskipun Google SecOps menggunakan fitur ini untuk menangani data yang datang sangat terlambat, fitur ini muncul sebagai rentang waktu yang besar antara periode deteksi (blok waktu peristiwa) dan waktu pembuatan pemberitahuan.
• Aturan kontekstual adalah aturan yang mengandalkan sumber pengayaan seperti pengalihan nama aset dan identitas, atau grafik konteks Entitas. Karena aturan ini mengandalkan beberapa sumber peristiwa, aturan ini lebih rentan terhadap latensi.
• Sistem akan mengeksekusi ulang aturan antara 5 dan 8 jam, dan lagi antara 24 dan 48 jam setelah eksekusi aturan awal. Kedua pemutaran ulang aturan yang terpisah ini terjadi bergantung pada waktu eksekusi pipeline pemrosesan ulang.

Memecahkan masalah keterlambatan deteksi aturan

Pecahkan masalah keterlambatan deteksi aturan melalui proses eliminasi.

Ikuti pendekatan yang disarankan ini untuk menyelidiki dan memecahkan masalah keterlambatan deteksi aturan:

1. Periksa apakah ada keterlambatan yang jelas:

   Tentukan apakah ada penundaan penyerapan:

   1. Di konsol Google SecOps, buka Detection > Rules and detections.

   2. Telusuri aturan yang akan dianalisis di Dasbor Aturan.

   3. Bandingkan Event time dengan Ingested time.

      Misalnya, untuk deteksi aturan tertentu, jika ada kesenjangan besar antara Event time dan Ingested time, Anda kemungkinan dapat mengaitkan penundaan deteksi dengan penundaan yang diharapkan.

2. Tinjau waktu pengumpulan sumber konteks:

   Periksa waktu pengumpulan sumber konteks.

   Aturan kontekstual dapat mencakup sumber konteks berikut. Periksa waktu pengumpulan:

   • Kolom yang berasal dari pengayaan UDM.
   • Peristiwa yang menyertakan kolom principal.

   • Aturan yang mereferensikan kolom graph.entity.

     Aturan yang mereferensikan grafik konteks entitas (ECG) dengan sintaksis graph.entity dapat menyebabkan latensi yang sangat tinggi. Misalnya, pipeline EKG menghasilkan data konteks, sebuah proses yang dapat memakan waktu 30 jam atau, dalam beberapa kasus, hingga 8 hari, bergantung pada jenis data.

   Untuk mengetahui detail selengkapnya, lihat Penundaan pemrosesan data.

3. Periksa frekuensi penerapan aturan dan konfigurasi periode pencocokan:

   • Frekuensi: Periksa frekuensi jalankan aturan. Aturan yang dikonfigurasi untuk berjalan lebih jarang secara alami memiliki penundaan deteksi yang lebih lama.
   • Periode pencocokan: Jika aturan memiliki periode pencocokan, penundaan minimum adalah durasi periode tersebut.
   • Hubungan frekuensi dan jendela pencocokan: Pastikan frekuensi penayangan kompatibel dengan jendela pencocokan. Misalnya, jika periode pencocokan adalah 5 menit, frekuensi eksekusi 10 menit dapat diterima. Namun, jika jendela pencocokan lebih dari 10 menit, gunakan frekuensi eksekusi berikutnya yang tersedia, yaitu 1 jam.

4. Periksa insiden terbaru:

   Cari insiden terbaru yang dapat menyebabkan keterlambatan atau masalah pada feed data.

Tips untuk memperpendek jeda

Untuk memperbarui konfigurasi aturan deteksi, lihat Mengelola aturan menggunakan editor Aturan.

Gunakan teknik berikut untuk mengurangi penundaan jika memungkinkan:

• Untuk aturan yang sensitif terhadap latensi, gunakan opsi menjalankan yang paling sering:

  • Meningkatkan frekuensi aturan:

    Untuk mengurangi penundaan, konfigurasikan frekuensi tertinggi yang memungkinkan berdasarkan jenis aturan dan periode pencocokan:

    • Untuk aturan satu peristiwa: Gunakan Hampir Real Time.
    • Untuk aturan multi-peristiwa dengan periode pencocokan kurang dari 60 menit: Gunakan 10 menit.
    • Untuk aturan dengan periode pencocokan 60 menit atau lebih: Gunakan 1 jam atau 24 jam, sebagaimana mestinya.

    Untuk mengetahui detail selengkapnya, lihat Menetapkan frekuensi eksekusi.

  • Mengurangi durasi periode pencocokan:

    Periode pencocokan yang lebih kecil lebih efisien. Ubah periode pencocokan 60 menit menjadi 59 menit untuk mengaktifkan pemrosesan 10 menit.

• Hindari data yang terlambat tiba:

  Data yang terlambat tiba akan terlewatkan dalam kueri awal, dan sistem hanya memprosesnya saat melakukan kueri ulang blok waktu peristiwanya 5 hingga 8 jam kemudian, sehingga menyebabkan keterlambatan yang signifikan. Data tepat waktu biasanya memiliki penundaan sekitar 20 menit.

Faktor yang menyebabkan keterlambatan deteksi aturan

Jenis aturan, frekuensi eksekusi, dan kecepatan penyerapan Google SecOps adalah faktor utama dalam penundaan deteksi aturan.

Faktor-faktor berikut berkontribusi terhadap keterlambatan deteksi aturan.

Jenis aturan

• Aturan peristiwa tunggal:

  Karena Aturan peristiwa tunggal dieksekusi hampir secara real-time menggunakan pendekatan streaming, gunakan aturan ini untuk meminimalkan penundaan, jika memungkinkan.

  • Aturan peristiwa tunggal sederhana

    Aturan ini mendeteksi peristiwa tunggal dan tidak menggunakan daftar referensi, tabel data, periode pencocokan, atau Analisis Perilaku Pengguna dan Entitas (UEBA). Aturan ini dieksekusi hampir secara real-time, dengan cara streaming, dan memiliki penundaan deteksi terpendek.

    Catatan: Anda dapat menerapkan penekanan pemberitahuan ke aturan peristiwa tunggal menggunakan opsi suppression_window.

  • Aturan peristiwa tunggal yang kompleks

    • Aturan peristiwa tunggal jendela

      Aturan ini adalah aturan peristiwa tunggal yang mencakup periode pencocokan dan biasanya memiliki penundaan yang sedikit lebih lama daripada aturan peristiwa tunggal lainnya. Periode pencocokan biasanya adalah jangka waktu saat aturan memeriksa satu atau beberapa peristiwa.

    • Merujuk aturan peristiwa tunggal

      Ini adalah aturan peristiwa tunggal yang menyertakan daftar referensi atau tabel data.

• Aturan beberapa peristiwa:

  Aturan multi-peristiwa dijalankan secara terjadwal, yang menyebabkan penundaan lebih lama karena waktu di antara jadwal eksekusi.

  • Aturan multi-peristiwa

    Aturan ini memeriksa dua kondisi peristiwa UDM atau lebih. Aturan ini biasanya memiliki periode pencocokan dan beberapa kondisi.

  • Aturan kontekstual

    Aturan yang sadar konteks membantu Anda memahami pola perilaku dalam telemetri dan konteks entitas yang terpengaruh dari pola tersebut.

    • Aturan ini terdiri dari dua atau beberapa kondisi, tetapi setidaknya satu kondisi adalah peristiwa Entity UDM (dengan peristiwa UDM berjenis context, seperti user_context).
    • Jenis aturan ini memiliki penundaan yang lebih lama, dan tidak jarang deteksi memerlukan waktu beberapa hari.
    • Aturan kontekstual umumnya memiliki penundaan terpanjang karena sistem harus menghasilkan data konteks yang diperlukan terlebih dahulu.

Pelajari lebih lanjut perbedaan antara aturan Peristiwa Tunggal dan Multi-Peristiwa.

Frekuensi aturan dijalankan

Frekuensi menjalankan aturan secara langsung memengaruhi penundaan deteksi.

• Hampir real-time: Aturan dijalankan lebih sering untuk data real-time, dan terus berjalan. Ini hanya berlaku untuk aturan peristiwa tunggal.
• Frekuensi lainnya: Untuk jenis aturan lainnya, Anda dapat menetapkan frekuensi berikut:
  • Frekuensi 10 menit berlaku untuk periode pertandingan < 60 menit.
  • Frekuensi 1 jam dan 24 jam berlaku untuk periode pencocokan kurang dari 48 jam.
  • Frekuensi 24 jam berlaku untuk semua periode pencocokan >= 48 jam.

Kemungkinan solusi: Untuk mencapai deteksi yang lebih cepat, gunakan frekuensi eksekusi yang lebih singkat dan periode pencocokan yang lebih kecil. Menggunakan periode pencocokan yang lebih singkat (kurang dari satu jam) memungkinkan lebih seringnya menjalankan tugas.

Periode pencocokan

Jika aturan memiliki periode pencocokan, durasi periode menentukan penundaan deteksi minimum, karena sistem harus menunggu seluruh periode terjadi.

Penundaan penyerapan

Penundaan penyerapan mengacu pada waktu yang dibutuhkan Google SecOps untuk menyerap data setelah peristiwa terjadi.

Jika data terlambat tiba, data tersebut tidak akan masuk ke jendela kueri awal. Kueri pemrosesan historis berikutnya akan mengambilnya, tetapi hal ini dapat menyebabkan penundaan selama 5 hingga 8 jam.

Misalnya: Peristiwa A (waktu peristiwa 09.03) dan Peristiwa B (waktu peristiwa 09.05) adalah bagian dari aturan yang mencari dua peristiwa dalam waktu 30 menit. Jika Peristiwa A tiba pada pukul 10.05 (terlambat 1 jam), peristiwa tersebut tidak akan masuk dalam kueri awal blok 09.00-09.30. Kueri lanjutan untuk blok tersebut antara pukul 14.00-17.00 kemudian menghasilkan deteksi, sehingga menyebabkan keterlambatan 5 hingga 8 jam.

Pemecahan masalah: Pastikan Anda mengirim data ke Google SecOps segera setelah peristiwa terjadi. Saat meninjau deteksi, periksa dengan cermat stempel waktu penyerapan dan peristiwa UDM.

Masalah zona waktu

Zona waktu default SIEM Google SecOps adalah UTC. Jika log tidak menyertakan definisi zona waktu eksplisit, sistem akan menafsirkannya sebagai UTC. Interpretasi yang salah dapat menyebabkan log diperlakukan sebagai log yang terlambat tiba, yang mengakibatkan keterlambatan deteksi, meskipun sistem menerimanya secara real time.

Misalnya, log dengan waktu peristiwa 10.00 AM Waktu Bagian Timur (15.00 UTC) tiba pada 15.05 UTC, tetapi tidak memiliki zona waktu. Jika log tidak memiliki zona waktu, sistem akan menafsirkan waktu acara sebagai 10.00 UTC. Kemudian, sistem menghitung penundaan 5 jam antara waktu peristiwa yang ditafsirkan (10.00 UTC) dan waktu penyerapan sebenarnya (15.05 UTC). Penundaan yang dihitung ini memicu penundaan deteksi karena aturan memprioritaskan pemrosesan berdasarkan penyerapan real-time.

Solusi: Jika stempel waktu peristiwa data asli berada di zona waktu selain UTC, coba salah satu opsi berikut:

• Perbarui zona waktu acara data asli.
• Jika Anda tidak dapat memperbarui zona waktu di sumber log, hubungi Dukungan untuk mengganti zona waktu.
• Atau, gunakan pemroses BindPlane untuk mengoreksi stempel waktu dan memformatnya sebagai UTC, atau tambahkan indikator zona waktu yang sesuai. Untuk mengetahui detailnya, lihat Mengubah stempel waktu isi log menggunakan BindPlane.

Gabungan kontekstual

Aturan multi-peristiwa yang menggunakan data kontekstual, seperti UEBA atau Entity Graph, mungkin mengalami penundaan yang lebih lama. Google SecOps harus menghasilkan data kontekstual terlebih dahulu.

Sistem pengayaan

Google SecOps memperkaya peristiwa UDM dengan menambahkan data kontekstual dari sumber lain. Proses ini biasanya selesai dalam waktu 30 menit. Penundaan dalam menambahkan data yang diperkaya ini ke peristiwa UDM dapat meningkatkan waktu deteksi.

Untuk memeriksa apakah suatu aturan mengevaluasi kolom yang diperkaya, tinjau Penampil Peristiwa. Jika aturan mengevaluasi kolom yang diperkaya, deteksi mungkin tertunda.

Untuk mengetahui detail selengkapnya, lihat Pengayaan data.

Aliasing dan pengayaan

Aliasing dan pengayaan adalah dua langkah dalam proses pengayaan data keamanan Google SecOps yang mengorelasikan dan menambahkan data konteks ke rekaman peristiwa. Pembuatan alias menemukan koneksi, dan pengayaan mengisi kolom UDM dengan data yang terhubung tersebut. Kolom yang diisi melalui proses ini disebut sebagai kolom yang diberi alias atau kolom yang diperkaya.

• Pembuatan Alias: Ini adalah proses mengidentifikasi dan menautkan nama atau ID yang berbeda untuk entitas yang sama. Fungsi ini menemukan data konteks tambahan yang menjelaskan indikator. Misalnya: Pengalihan nama dapat menghubungkan satu hostname (seperti alex-macbook) ke indikator terkait lainnya, seperti IP addresses, MAC addresses (dari log DHCP), atau user ID (seperti alex) ke job title dan employment status (dari data konteks pengguna).
• Pengayaan: Ini adalah proses yang menggunakan informasi yang dikumpulkan dari pembuatan alias untuk menambahkan konteks ke peristiwa UDM. Misalnya: Saat peristiwa baru tiba hanya dengan IP address, proses pengayaan menggunakan data yang diberi alias untuk menemukan hostname terkait (misalnya, alex-macbook) dan mengisi kolom $udm.event.principal.hostname.

Google SecOps mendukung pembuatan alias dan pengayaan untuk beberapa jenis entitas, termasuk: Aset (misalnya, nama host, IP, MAC), Pengguna, Proses, Metadata hash file, Lokasi geografis, dan Resource cloud. Untuk mengetahui detail selengkapnya, lihat Ringkasan pengayaan dan pembuatan alias UDM.

Pengayaan ulang peristiwa UDM

• Perubahan data pokok: Setelah sistem menyerap peristiwa, jika data pokok berubah setelah penyerapan peristiwa, sistem akan memproses ulang data historis dan memperbarui peristiwa hingga 24 jam.

• Pembaruan sistem pengayaan: Jika sistem pengayaan memperbarui metadata entitas atau proses, geolokasi IP, atau indikator VirusTotal, mesin aturan akan mengevaluasi ulang blok ini 24 hingga 48 jam kemudian untuk mencatat pembaruan tersebut.
  Misalnya: Peristiwa pada pukul 09.03 memiliki entity.asset.hostname = hostnameA tetapi tidak ada IP. Log DHCP dari pukul 08.55 menunjukkan hostnameA = IP 1.2.3.4. Mesin aturan berjalan pada pukul 09.10, dan aturan tidak cocok. Pipeline pemrosesan pengayaan mengorelasikan hostnameA dengan 1.2.3.4 untuk jangka waktu tersebut, dan memperbarui peristiwa UDM. Sekarang aturan cocok, dan sistem membuat deteksi.

• Data konteks yang tertunda: Jika Anda mengirim data konteks, seperti hostname, misalnya, tiga hari setelah log awal, sistem akan memperkaya ulang peristiwa UDM. Aturan yang mencari data yang diperkaya ulang ini kemudian dijalankan lagi dan membuat deteksi. Fitur ini memastikan bahwa sistem membuat deteksi meskipun konteks tertunda.

• Perubahan pada data pengayaan: Perubahan pada data pengayaan dapat menyebabkan aturan cocok di lain waktu, meskipun tidak cocok pada awalnya.
  Misalnya, peristiwa pada pukul 09.03 memiliki entity.ip_geo_artifact.country_or_region = USA. Mesin aturan berjalan pada pukul 09.10, mengkueri pukul 09.00-10.00, dan aturan tidak cocok. Kemudian, pemrosesan ulang pengayaan memperbarui geolokasi ke Kanada. Saat aturan dijalankan lagi, aturan tersebut kini cocok, dan sistem membuat deteksi.

Pemrosesan grafik konteks entitas

Sistem membuat dan menambahkan informasi grafik konteks entitas (ECG) ke data log untuk memberikan konteks, misalnya, indikator gangguan (IOC) atau data konteks aset. Karena pipeline EKG sebagian besar mengandalkan pemrosesan batch, informasi konteks entitas sering kali hanya diperbarui setelah eksekusi aturan membuat deteksi.

Perburuan retro

Saat Anda menjalankan aturan terhadap data historis menggunakan perburuan retro, sistem hanya membuat deteksi setelah proses perburuan retro selesai. Proses ini dapat memakan waktu yang cukup lama, sehingga menyebabkan penundaan deteksi.

Contoh proses update retroaktif:

1. Acara awal: Acara tiba pukul 13.00 dengan ip_address = 10.0.0.5. Saat ini, hostname tidak diketahui.
2. Kedatangan sumber alias: Pada pukul 14.30 (lebih dari satu jam kemudian), log DHCP tiba untuk pukul 13.00, yang menautkan 10.0.0.5 ke workstation-123.
3. Pengayaan retroaktif: Sistem pembuatan alias memproses link baru ini. Peristiwa ini secara retroaktif memperbarui peristiwa UDM dari pukul 13.00, yang memperkaya kolom $udm.event.principal.hostname yang sebelumnya kosong dengan nilai workstation-123.
4. Deteksi: Eksekusi aturan berikutnya (proses pembersihan) kini melihat nilai yang telah di-enrich (workstation-123) dan dapat memicu deteksi yang sebelumnya terlewat.

Catatan: Anda tidak dapat membedakan metrik pemantauan latensi untuk aturan deteksi langsung dari aturan deteksi retrohunt. Untuk menghindari penyelewengan metrik pemantauan latensi deteksi, jangan gunakan aturan aktif untuk menyimulasikan aturan retrohunt. Sebagai praktik terbaik, buat aturan deteksi khusus dan jalankan sebagai aturan retrohunt.

Daftar referensi

Eksekusi aturan selalu menggunakan versi terbaru daftar referensi. Saat aturan terjadwal dijalankan lagi, sistem dapat membuat deteksi baru berdasarkan konten daftar referensi yang diperbarui. Deteksi ini mungkin muncul terlambat karena didasarkan pada data yang dimasukkan sebelum pembaruan daftar rujukan.

Untuk memperpendek penundaan deteksi, lakukan hal berikut:

• Kirim data log ke Google SecOps segera setelah peristiwa terjadi.
• Tinjau aturan audit untuk menentukan apakah akan menggunakan data yang tidak ada atau data yang diperkaya konteksnya.
• Konfigurasi frekuensi eksekusi yang lebih kecil.

Aturan tidak ada

Sistem menunggu setidaknya satu jam sebelum menjalankan aturan yang memeriksa ketidakberadaan (misalnya, aturan yang berisi !$e atau #e=0), sehingga data memiliki waktu untuk tiba.

Keterlambatan pemrosesan data

Sistem dapat terus memproses data meskipun setelah membuat deteksi awal, yang berpotensi menghasilkan deteksi baru atau yang diperbarui. Untuk mengetahui detailnya, lihat Kapan pemutaran ulang aturan dipicu.

Perlu bantuan lain? Dapatkan jawaban dari anggota Komunitas dan profesional Google SecOps.