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

Waktu deteksi dapat tertunda karena pemrosesan. Meskipun beberapa aturan dipicu hampir secara real-time, aturan lainnya mungkin memerlukan waktu beberapa menit atau jam untuk selesai. Faktor seperti jenis aturan, frekuensi penerapan, dan metode pembuatan deteksi memengaruhi penundaan ini. Dokumen ini membahas faktor-faktor ini dan faktor penundaan lainnya.

Kami mengategorikan keterlambatan sebagai diharapkan atau tidak terprediksi.

• Penundaan yang diharapkan: Penundaan ini disebabkan oleh proses penyerapan dan pilihan konfigurasi yang Anda buat saat menyiapkan aturan deteksi. Misalnya, waktu yang diperlukan untuk membuat deteksi adalah salah satu faktornya. 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 mengurangi penundaan.

• Penundaan yang tidak terduga: 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, klik nama aturan untuk melihat histori deteksi dan detail lainnya untuk aturan tertentu.

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

Ikon di kolom Jenis Deteksi mengidentifikasi deteksi dari retrohunt atau menjalankan pemrosesan ulang. Ikon ini juga muncul di halaman Peringatan di Google SecOps.

1. Pahami topik berikut untuk memahami pengaruh faktor-faktor ini terhadap keterlambatan 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. Fitur ini memproses aturan peristiwa tunggal dengan bagian tanpa kecocokan dan tanpa 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 pencocokan dengan kondisi sederhana. Misalnya, "peristiwa saat jumlah peristiwa kami > 0". Aturan ini berjalan pada kecepatan kueri frekuensi tinggi (hampir 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, dan pengayaan dapat memperbarui peristiwa UDM hingga 24 jam setelah peristiwa diserap.
• Aturan multiperistiwa 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 tinggi.
• 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 dipicu berdasarkan waktu eksekusi pipeline pemrosesan ulang.
• Untuk batas deteksi tambahan, lihat Memahami batas deteksi.

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 perbedaan besar antara Event time dan Ingested time, Anda kemungkinan dapat mengaitkan keterlambatan deteksi dengan keterlambatan yang diharapkan.

2. Tinjau waktu pengumpulan sumber konteks:

   Periksa waktu pengumpulan sumber konteks.

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

   • 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 jalannya 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:

    Mengurangi periode pencocokan tidak secara langsung memengaruhi latensi, tetapi dapat meningkatkan efisiensi dengan menetapkan penundaan minimum.

• 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 dibagi menjadi dua kategori utama:

Aturan satu peristiwa

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

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 ini lebih rentan terhadap keterlambatan deteksi karena mencakup periode pencocokan atau daftar referensi:

• Aturan peristiwa tunggal berjangka waktu

  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 multi-peristiwa

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

• Aturan multi-peristiwa

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

• Aturan kontekstual

  Aturan kontekstual membantu Anda menggabungkan data konteks deteksi dan entitas tambahan ke peristiwa Anda.

  • Aturan ini terdiri dari dua atau lebih sumber data, dengan setidaknya satu kondisi adalah peristiwa entity UDM (dengan peristiwa UDM berjenis konteks, seperti user_context).
  • Aturan kontekstual paling sensitif terhadap data yang terlambat tiba.
  • Aturan kontekstual umumnya memiliki penundaan terpanjang karena sistem harus menghasilkan data konteks yang diperlukan terlebih dahulu, seperti data dalam Grafik Konteks Entitas .
  • Untuk mengetahui detail selengkapnya, lihat Menggunakan data yang diperkaya konteks dalam aturan.

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. Ini hanya berlaku untuk aturan peristiwa tunggal.
• Frekuensi lainnya: Untuk jenis aturan lainnya, Anda dapat menetapkan frekuensi berikut:
  • Frekuensi 10 menit berlaku untuk periode pencocokan < 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.

Solusi yang mungkin: Untuk mencapai deteksi yang lebih cepat, gunakan frekuensi eksekusi yang lebih singkat. Mengurangi periode pencocokan tidak secara langsung memengaruhi latensi, tetapi dapat meningkatkan efisiensi dengan menetapkan penundaan minimum.

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 Google SecOps SIEM 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 penundaan 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 peristiwa 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 cara 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 kolom UEBA atau grafik konteks entitas, 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 oleh 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, pembuatan alias dapat menghubungkan satu hostname (seperti alex-macbook) ke indikator terkait lainnya, seperti IP addresses dan MAC addresses (dari log DHCP). Penamaan alias juga dapat menghubungkan user ID (seperti alex) ke job title dan employment status pengguna (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, alamat 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: Jika data pokok berubah setelah peristiwa di-ingest, sistem akan memproses ulang data historis dan memperbarui peristiwa hingga 24 jam setelah penyerapan.

• 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, lalu memperbarui peristiwa UDM. Sekarang aturan cocok, dan sistem membuat deteksi.

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

• Perubahan data pengayaan: Perubahan 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 kompromi (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 lama, yang menyebabkan penundaan deteksi.

Contoh proses update retroaktif:

1. Peristiwa awal: Peristiwa tiba pada 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 secara retroaktif: Sistem pemberian nama alternatif 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: Pemutaran ulang aturan berikutnya akan melihat nilai yang telah diperkaya (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 kecondongan 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 rujukan 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 tidak adanya (misalnya, aturan yang berisi !$e atau #e=0), sehingga data memiliki waktu untuk tiba.

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