Memahami penundaan deteksi aturan

Didukung di:

Dokumen ini menjelaskan penundaan deteksi aturan di Google Security Operations, mengidentifikasi faktor-faktor yang berkontribusi di seluruh pipeline penyerapan dan pemrosesan, menguraikan pendekatan pemecahan masalah terstruktur, dan memberikan teknik untuk mengurangi latensi deteksi.

Ringkasan aturan deteksi

Aturan deteksi memeriksa log mentah yang dinormalisasi—peristiwa Model Data Universal (UDM) entitas dan reguler—untuk menghasilkan deteksi keamanan sesuai dengan spesifikasi aturan. Peristiwa UDM entitas biasanya berisi informasi konteks seperti metadata pengguna atau metadata aset. Aturan deteksi juga dapat mengevaluasi deteksi yang dihasilkan sebelumnya untuk menghasilkan pemberitahuan gabungan.

Keterlambatan yang diperkirakan dan tidak diperkirakan

Latensi deteksi bervariasi berdasarkan logika aturan, dependensi data, dan siklus pemrosesan sistem. Penundaan dikategorikan menjadi dua jenis:

  • Penundaan yang diharapkan: Penundaan yang disebabkan oleh faktor struktural, seperti proses penyerapan, jenis aturan, frekuensi eksekusi, metode pembuatan deteksi, durasi periode pencocokan, dan batas sistem yang diketahui. Anda dapat meminimalkan penundaan yang diperkirakan dengan menyesuaikan konfigurasi aturan deteksi dan parameter penjadwalan.
  • Penundaan yang tidak terduga: Penundaan yang disebabkan oleh kondisi pipeline eksternal atau dinamis, termasuk hambatan pengiriman log dari sumber data, latensi pemrosesan sementara dalam layanan Google SecOps, ketersediaan konteks yang tertunda, dan siklus pengayaan ulang UDM.

Metode pembuatan deteksi

Google SecOps menghasilkan deteksi aturan melalui pipeline eksekusi berikut:

  • Mesin streaming: Pipeline berkecepatan tinggi yang mengevaluasi aturan peristiwa tunggal standar dan berjangka waktu secara berkelanjutan dalam waktu hampir real-time (biasanya dalam waktu 5 menit setelah penyerapan). Peristiwa yang terlambat tiba dan pengayaan retroaktif dievaluasi secara berkelanjutan selama eksekusi standar.
  • Mesin kueri: Mengevaluasi aturan yang memerlukan korelasi peristiwa berbasis waktu di beberapa peristiwa atau gabungan data eksternal:
    • Aturan peristiwa tunggal yang kompleks: Mencakup aturan peristiwa tunggal yang mengkueri daftar referensi atau tabel data.
    • Aturan multi-peristiwa: Mengueri data dalam blok waktu peristiwa yang dikelompokkan (seperti interval 10 menit atau 1 jam, atau match_window / 10 untuk periode lebih dari 48 jam) berdasarkan jadwal yang dikonfigurasi.
  • Aturan dijalankan terhadap data historis: Mengevaluasi aturan secara retroaktif terhadap log historis melalui retrohunt. Deteksi muncul setelah pemindaian historis selesai.
  • Pengayaan ulang peristiwa UDM: Mengevaluasi ulang blok waktu yang diproses sebelumnya saat konteks baru atau data entitas yang diperbarui ditambahkan ke peristiwa historis.

Faktor yang menyebabkan keterlambatan deteksi aturan

Kecepatan munculnya deteksi bergantung pada kompleksitas aturan, interval penjadwalan, latensi penyerapan data, dan pipeline pengayaan konteks.

Jenis dan kompleksitas aturan

Aturan deteksi terbagi dalam beberapa kategori dengan profil latensi yang berbeda:

Aturan peristiwa tunggal

Aturan peristiwa tunggal dieksekusi hampir real-time di mesin streaming berkelanjutan dan menawarkan latensi deteksi terendah. Aturan ini mengevaluasi setiap peristiwa tanpa menggabungkan set data eksternal, tabel data, atau jendela pencocokan multi-peristiwa.

Aturan peristiwa tunggal yang kompleks

Aturan ini mengevaluasi peristiwa tunggal, tetapi menggabungkan dependensi data tambahan:

  • Aturan peristiwa tunggal berjangka waktu: Aturan peristiwa tunggal yang menyertakan bagian match (misalnya, mengevaluasi apakah satu peristiwa cocok dengan suatu kondisi selama jangka waktu tertentu). Aturan ini dievaluasi secara hampir real-time di mesin streaming berkelanjutan saat data diserap.
  • Merujuk aturan peristiwa tunggal: Aturan peristiwa tunggal yang membandingkan atribut peristiwa dengan daftar referensi atau tabel data.

Aturan banyak peristiwa

Aturan multi-peristiwa mengorelasikan dua atau lebih kondisi peristiwa UDM selama periode pencocokan yang ditentukan dan dijalankan pada interval batch terjadwal.

  • Aturan multi-peristiwa standar: Menggabungkan beberapa peristiwa di seluruh periode waktu dan dieksekusi pada interval 10 menit atau 1 jam (atau match_window / 10 untuk periode yang lebih dari 48 jam).
  • Aturan kontekstual: Hubungkan data peristiwa dengan peristiwa entitas UDM (seperti user_context atau asset_context) menggunakan analisis kontekstual. Karena aturan kontekstual mengandalkan beberapa feed data, aturan ini lebih sensitif terhadap waktu penyerapan. Untuk mengetahui informasi selengkapnya, lihat Menggunakan data yang diperkaya konteks dalam aturan.

Frekuensi aturan dijalankan

Frekuensi eksekusi yang dikonfigurasi menentukan seberapa sering mesin kueri mengevaluasi blok waktu peristiwa:

  • Hampir real-time: Evaluasi berkelanjutan untuk aturan peristiwa tunggal (standar dan berjangka waktu).
  • Frekuensi 10 menit: Tersedia untuk aturan multi-peristiwa dengan periode pencocokan di bawah 60 menit.
  • Frekuensi 1 jam: Interval default untuk aturan multi-peristiwa dengan periode pencocokan 48 jam atau kurang.
  • match_window / 10 frekuensi: Ditetapkan secara otomatis untuk aturan multi-peristiwa dengan jendela kecocokan lebih dari 48 jam (misalnya, dijalankan setiap 10 jam untuk jendela kecocokan 100 jam, atau setiap 24 jam untuk jendela 10 hari).

Durasi periode pencocokan

Untuk aturan multi-peristiwa, durasi periode pencocokan menentukan periode pengamatan yang diperlukan untuk menggabungkan peristiwa. Deteksi tidak dapat muncul hingga seluruh jangka waktu telah berlalu.

Penundaan penyerapan log

Penundaan penyerapan adalah waktu yang berlalu antara saat peristiwa terjadi di sumber dan saat Google SecOps menerima dan mengurai log.

Jika peristiwa tiba setelah evaluasi terjadwal awal untuk blok waktu tersebut, peristiwa akan terlewatkan pada proses pertama. Sistem akan mengambil data yang terlambat tiba dalam proses latar belakang otomatis berikutnya (proses penyesuaian), yang terjadi sekitar 4 jam (dan secara opsional 30 jam dengan kelengkapan pengayaan) setelah proses utama.

  • Contoh: Aturan mengorelasikan Peristiwa A (waktu peristiwa 09.03) dan Peristiwa B (waktu peristiwa 09.05) dalam periode 30 menit. Jika Peristiwa A tiba pada pukul 10.05 (terlambat satu jam), peristiwa tersebut akan melewatkan eksekusi awal untuk blok 09.00–09.30. Sistem mengevaluasi ulang pemblokiran selama proses penyesuaian berikutnya sekitar 4 jam setelah proses utama (sekitar pukul 14.00), sehingga menghasilkan deteksi sekitar 5 jam setelah peristiwa terjadi.

Perbedaan zona waktu

Google SecOps menafsirkan stempel waktu log sebagai UTC secara default. Jika sumber log tidak menyertakan offset zona waktu eksplisit, sistem akan memperlakukan stempel waktu sebagai UTC, yang dapat menyebabkan log tampak terlambat tiba meskipun diterima dengan segera.

  • Contoh: Peristiwa terjadi pada pukul 10.00 Eastern Time (15.00 UTC) dan tiba di Google SecOps pada pukul 15.05 UTC tanpa metadata zona waktu. Sistem menafsirkan stempel waktu sebagai 10.00 UTC, sehingga menimbulkan penundaan penyerapan yang dirasakan selama 5 jam yang menunda evaluasi aturan ke proses sinkronisasi latar belakang.

Solusi: Untuk mengatasi perbedaan zona waktu:

  • Konfigurasi sumber log untuk menyertakan offset zona waktu UTC eksplisit dalam stempel waktu peristiwa.
  • Hubungi Dukungan untuk menyetel penggantian zona waktu untuk feed penyerapan tertentu.
  • Gunakan pemroses BindPlane untuk menormalisasi stempel waktu isi log ke UTC sebelum penyerapan. Untuk mengetahui informasi selengkapnya, lihat Mengubah stempel waktu isi log menggunakan BindPlane.

Penggabungan kontekstual dan pelengkapan data

Google SecOps memperkaya peristiwa UDM dengan menambahkan metadata identitas, aset, dan ancaman dari sumber sekunder. Penundaan ketersediaan konteks dapat memperpanjang waktu deteksi.

Mekanisme pembuatan alias dan pengayaan

Aliasing dan pengayaan mengorelasikan indikator mentah dengan konteks organisasi:

  • Pembuatan alias: Mengidentifikasi dan menautkan ID yang berbeda untuk entitas yang sama di seluruh sumber data (seperti memetakan alamat IP dari log DHCP ke alamat MAC dan nama host seperti alex-macbook, atau memetakan ID pengguna ke jabatan karyawan).
  • Pengayaan: Mengisi kolom peristiwa UDM yang dinormalisasi dengan konteks yang diberi alias (seperti mengisi $udm.event.principal.hostname saat hanya alamat IP yang ada dalam peristiwa mentah).

Jenis pengayaan yang didukung mencakup aset, pengguna, proses, metadata hash file, lokasi geografis, dan resource cloud. Untuk mengetahui informasi selengkapnya, lihat Ringkasan pengayaan dan pembuatan alias UDM.

Pengayaan ulang peristiwa UDM

Sistem terus memperbarui peristiwa historis seiring berkembangnya sumber konteks:

  • Perubahan data pokok: Peristiwa historis dapat diperbarui hingga 24 jam setelah penyerapan saat data konteks baru tiba.
  • Pembaruan sistem pengayaan: Saat metadata entitas, geolokasi IP, atau intelijen ancaman VirusTotal diperbarui, mesin aturan mengevaluasi ulang pemblokiran historis (biasanya selama proses penyamaan atau pemrosesan ulang terjadwal) untuk menghasilkan deteksi dengan konteks yang diperbarui.
  • Data konteks yang tertunda: Jika data konteks (seperti nama host) tiba sehari setelah log peristiwa, sistem akan memperkaya ulang peristiwa UDM, dan proses penyelarasan berikutnya akan mengevaluasi data yang diperkaya.
  • Modifikasi konteks: Jika pembaruan pengayaan mengubah atribut peristiwa (seperti memperbarui geolokasi IP dari USA menjadi Canada), aturan yang cocok dengan nilai yang diperbarui akan memicu deteksi selama evaluasi ulang berikutnya.

Pemrosesan Grafik Konteks Entity (ECG)

Grafik Konteks Entitas (ECG) mengorelasikan Indikator Kompromi (IOC) dan data grafik aset perusahaan. Karena pipeline EKG mengandalkan pemrosesan batch (yang dapat memerlukan waktu 30 jam atau hingga beberapa hari, bergantung pada volume data), aturan yang mereferensikan kolom graph.entity akan menghasilkan deteksi setelah hubungan grafik dihitung sepenuhnya.

Retrohunt dan eksekusi aturan historis

Menjalankan aturan terhadap data historis hanya akan menghasilkan deteksi setelah pemindaian retrohunt selesai di seluruh rentang waktu yang dipilih.

  • Alur kerja pengayaan data secara retroaktif:
    1. Peristiwa tiba pada pukul 13.00 dengan ip_address = 10.0.0.5 (nama host tidak diketahui).
    2. Pada pukul 14.30, log DHCP tiba yang menghubungkan 10.0.0.5 ke workstation-123.
    3. Pipeline pembuatan alias memperbarui peristiwa pukul 13.00 sebelumnya dengan principal.hostname = workstation-123.
    4. Pemutaran ulang aturan berikutnya akan mengevaluasi nama host yang telah di-enrich dan menampilkan deteksi yang tidak dipicu selama proses awal.

Daftar referensi

Aturan yang membuat kueri daftar referensi dievaluasi terhadap versi daftar terbaru pada waktu eksekusi. Memperbarui daftar referensi dapat menyebabkan aturan terjadwal menghasilkan deteksi secara retrospektif terhadap log yang sebelumnya di-ingest.

Aturan tidak ada

Untuk mencegah positif palsu, sistem memperkenalkan jeda minimal satu jam sebelum mengevaluasi aturan yang memeriksa kondisi tidak ada (seperti !$e atau #e=0), sehingga semua log terkait memiliki waktu untuk tiba.

Batasan pemrosesan dan penyesuaian data

Perhatikan perilaku sistem berikut saat menilai latensi deteksi:

  • Pemrosesan pengayaan: Pengayaan konteks dapat memperbarui peristiwa UDM historis hingga 24 jam setelah penyerapan awal.
  • Siklus penyesuaian: Aturan multi-peristiwa otomatis dijalankan ulang sekitar 4 jam (dan secara opsional 30 jam) setelah dijalankan pertama kali untuk mencatat data yang terlambat tiba. Untuk mengetahui informasi selengkapnya, lihat Memahami pemutaran ulang aturan dan MTTD.
  • Batas deteksi: Untuk mengetahui kapasitas platform dan batas throttling, lihat Memahami batas deteksi.

Memecahkan masalah keterlambatan deteksi aturan

Untuk mendiagnosis alasan aturan menghasilkan deteksi yang tertunda, periksa heuristik dan tahap pipeline berikut di konsol Google SecOps:

  • Tinjau metadata dan jadwal aturan: Di Dasbor Aturan, periksa kolom Nama Aturan, Jenis Aturan, dan Jadwal aturan untuk mengidentifikasi mesin eksekusi aturan dan frekuensi evaluasi dasar.
  • Bandingkan Waktu peristiwa dengan Waktu penyerapan: Temukan deteksi di tab Deteksi dan bandingkan stempel waktu peristiwa dengan stempel waktu penyerapan. Jika selisih antara waktu peristiwa dan waktu penyerapan melebihi 30 menit, latensi disebabkan oleh keterlambatan pengiriman log di sumber atau selama pengumpulan. Deteksi yang dihasilkan dari data peristiwa yang terlambat lebih dari 30 menit, proses penyelarasan otomatis, pipeline pemrosesan ulang, atau perburuan retro menampilkan ikon di kolom Jenis Deteksi.
  • Tinjau dependensi sumber konteks: Periksa apakah aturan mereferensikan pengayaan principal, pembuatan alias UDM, atau kolom graph.entity. Pipeline konteks diproses secara asinkron dan dapat menampilkan deteksi selama proses penyelarasan berikutnya.
  • Verifikasi frekuensi dan kompatibilitas periode pencocokan: Konfirmasi bahwa frekuensi eksekusi yang dikonfigurasi cocok dengan ukuran periode pencocokan (misalnya, pastikan aturan dengan periode pencocokan 15 menit dijadwalkan selama 10 menit atau 1 jam).
  • Periksa gangguan feed data: Tinjau log penyerapan dan dasbor pengelolaan feed untuk mengetahui apakah ada penundaan penyerapan atau gangguan sumber sementara.

Tips untuk memperpendek penundaan deteksi

Untuk meminimalkan penundaan deteksi di seluruh lingkungan Anda, terapkan teknik pengoptimalan berikut:

  • Mengoptimalkan frekuensi menjalankan aturan:
    • Gunakan Hampir real-time untuk aturan peristiwa tunggal (standar dan berjangka waktu).
    • Konfigurasi jadwal 10 menit untuk aturan multi-peristiwa dengan periode pencocokan di bawah 60 menit.
    • Gunakan 1 jam untuk aturan dengan periode pencocokan antara 1 dan 48 jam jika perlu pemberitahuan cepat.
  • Sesuaikan durasi jendela pencocokan: Tetapkan jendela pencocokan ke durasi minimum yang diperlukan untuk merekam perilaku ancaman yang berkorelasi.
  • Menghilangkan hambatan pengiriman log: Pastikan penerus dan pengumpul mengirim data peristiwa dengan segera untuk mencegah log tidak masuk ke jendela eksekusi awal.
  • Validasi konfigurasi zona waktu: Pastikan sumber log memberikan offset UTC eksplisit untuk mencegah penundaan penyerapan yang dirasakan lebih dari 5 jam.
  • Kondisi audit konteks dan tidak ada: Gunakan kolom yang diperkaya konteks dan kondisi tidak ada (!$e) hanya jika diperlukan oleh logika deteksi, karena kondisi ini memperkenalkan periode buffering yang disengaja.

Langkah berikutnya

Untuk mempelajari konsep penjadwalan dan alur kerja konfigurasi terkait, lihat dokumen berikut:

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