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) reguler dan entitas—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 sebelumnya dihasilkan untuk menghasilkan pemberitahuan gabungan.

Penundaan yang diharapkan dan tidak diprediksi

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

  • Penundaan yang diharapkan: Penundaan yang dihasilkan dari faktor struktural, seperti proses penyerapan, jenis aturan, frekuensi menjalankan, metode pembuatan deteksi, durasi periode pencocokan, dan batas sistem yang diketahui. Anda dapat meminimalkan penundaan yang diharapkan dengan menyesuaikan konfigurasi aturan deteksi dan parameter penjadwalan.
  • Penundaan yang tidak diprediksi: Penundaan yang disebabkan oleh kondisi pipeline eksternal atau dinamis, termasuk bottleneck 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 berjendela secara terus-menerus dalam waktu yang hampir real time (biasanya dalam waktu 5 menit setelah penyerapan). Peristiwa yang terlambat tiba dan pengayaan retrospektif dievaluasi secara terus-menerus 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 membuat kueri daftar referensi atau tabel data.
    • Aturan multiperistiwa: Membuat kueri data dalam blok waktu peristiwa yang dikelompokkan (seperti interval 10 menit atau 1 jam, atau match_window / 10 untuk periode yang lebih besar dari 48 jam) berdasarkan jadwal yang dikonfigurasi.
  • Aturan dijalankan terhadap data historis: Mengevaluasi aturan secara retrospektif terhadap log historis melalui retrohunt. Deteksi muncul setelah pemindaian historis selesai.
  • Pengayaan ulang peristiwa UDM: Mengevaluasi ulang blok waktu yang sebelumnya diproses saat konteks baru atau data entitas yang diperbarui ditambahkan ke peristiwa historis.

Faktor yang berkontribusi pada penundaan deteksi aturan

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

Jenis dan kompleksitas aturan

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

Aturan peristiwa tunggal

Aturan peristiwa tunggal dieksekusi dalam waktu yang hampir real time di mesin streaming berkelanjutan dan menawarkan latensi deteksi terendah. Aturan ini mengevaluasi peristiwa individual tanpa menggabungkan set data eksternal, tabel data, atau periode pencocokan multiperistiwa.

Aturan peristiwa tunggal yang kompleks

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

  • Aturan peristiwa tunggal berjendela: Aturan peristiwa tunggal yang menyertakan bagian match (misalnya, mengevaluasi apakah satu peristiwa cocok dengan kondisi selama periode waktu). Aturan ini dievaluasi dalam waktu yang hampir real time di mesin streaming berkelanjutan saat data diserap.
  • Aturan peristiwa tunggal referensi: Aturan peristiwa tunggal yang membandingkan atribut peristiwa dengan daftar referensi atau tabel data.

Aturan multiperistiwa

Aturan multiperistiwa mengorelasikan dua atau beberapa kondisi peristiwa UDM selama periode pencocokan yang ditentukan dan dieksekusi pada interval batch terjadwal.

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

Frekuensi menjalankan aturan

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

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

Durasi periode pencocokan

Untuk aturan multiperistiwa, durasi periode pencocokan menentukan periode observasi yang diperlukan untuk mengagregasi peristiwa. Deteksi tidak dapat muncul hingga periode waktu penuh 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 tersebut akan terlewatkan pada proses pertama. Sistem akan menangkap 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 terlewatkan pada eksekusi awal untuk blok 09.00–09.30. Sistem mengevaluasi ulang blok 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 menghilangkan offset zona waktu eksplisit, sistem akan memperlakukan stempel waktu sebagai UTC, yang dapat menyebabkan log tampak terlambat tiba meskipun diterima segera.

  • Contoh: Peristiwa terjadi pada pukul 10.00 Waktu Bagian Timur (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 membuat penundaan penyerapan yang dirasakan selama 5 jam yang menunda evaluasi aturan ke proses penyesuaian latar belakang.

Solusi: Untuk mengatasi perbedaan zona waktu:

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

Gabungan kontekstual dan pengayaan data

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

Mekanisme pemberian alias dan pengayaan

Pemberian alias dan pengayaan mengorelasikan indikator mentah dengan konteks organisasi:

  • Pemberian alias: Mengidentifikasi dan menautkan berbagai ID 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 pemberian alias UDM.

Pengayaan ulang peristiwa UDM

Sistem terus memperbarui peristiwa historis saat sumber konteks berkembang:

  • Perubahan data yang mendasarinya: Peristiwa historis dapat diperbarui hingga 24 jam setelah penyerapan saat data konteks baru tiba.
  • Update sistem pengayaan: Saat metadata entity, geolokasi IP, atau update threat intelligence VirusTotal, mesin aturan mengevaluasi ulang blok historis (biasanya selama proses penyesuaian terjadwal atau pemrosesan ulang) 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 peristiwa UDM, dan proses penyesuaian berikutnya akan mengevaluasi data yang diperkaya.
  • Perubahan konteks: Jika update pengayaan mengubah atribut peristiwa (seperti memperbarui geolokasi IP dari USA ke Canada), aturan yang cocok dengan nilai yang diperbarui akan memicu deteksi selama evaluasi ulang berikutnya.

Pemrosesan Entity Context Graph (ECG)

The Entity Context Graph (ECG) mengorelasikan Indikator Kompromi (IOC) dan data grafik aset perusahaan. Karena pipeline EKG bergantung pada batch processing (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 graf dihitung sepenuhnya.

Retrohunt dan operasi aturan historis

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

  • Alur kerja pengayaan retrospektif:
    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 menautkan 10.0.0.5 ke workstation-123.
    3. Pipeline pemberian alias memperbarui peristiwa historis pukul 13.00 dengan principal.hostname = workstation-123.
    4. Replay aturan berikutnya mengevaluasi nama host yang diperkaya dan menampilkan deteksi yang tidak dipicu selama proses awal.

Daftar referensi

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

Aturan non-eksistensi

Untuk mencegah positif palsu, sistem memperkenalkan buffer minimum satu jam sebelum mengevaluasi aturan yang memeriksa kondisi non-eksistensi (seperti !$e atau #e=0), sehingga memastikan semua log terkait memiliki waktu untuk tiba.

Batasan pemrosesan data dan penyesuaian

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 multiperistiwa otomatis dijalankan ulang sekitar 4 jam (dan secara opsional 30 jam) setelah proses utama untuk menangkap data yang terlambat tiba. Untuk mengetahui informasi selengkapnya, lihat Memahami replay aturan dan MTTD.
  • Batas deteksi: Untuk mengetahui kapasitas platform dan batas throttling, lihat Memahami batas deteksi.

Memecahkan masalah penundaan 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 penundaan pengiriman log di sumber atau selama pengumpulan. Deteksi yang dihasilkan dari data peristiwa yang terlambat lebih dari 30 menit, proses penyesuaian otomatis, pipeline pemrosesan ulang, atau retrohunt menampilkan ikon bola lampu di kolom **Jenis Deteksi**.
  • Tinjau dependensi sumber konteks: Periksa apakah aturan mereferensikan pengayaan principal, pemberian alias UDM, atau kolom graph.entity. Pipeline konteks diproses secara asinkron dan dapat menampilkan deteksi selama proses penyesuaian berikutnya.
  • Verifikasi kompatibilitas frekuensi dan periode pencocokan: Pastikan frekuensi menjalankan yang dikonfigurasi cocok dengan ukuran periode pencocokan (misalnya, memastikan 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 penundaan penyerapan atau gangguan sumber sementara.

Tips untuk mempersingkat penundaan deteksi

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

  • Optimalkan frekuensi menjalankan aturan:
    • Gunakan Hampir real time untuk aturan peristiwa tunggal (standar dan berjendela).
    • Konfigurasikan jadwal 10 menit untuk aturan multiperistiwa dengan periode pencocokan di bawah 60 menit.
    • Gunakan 1 jam untuk aturan dengan periode pencocokan antara 1 dan 48 jam jika pemberitahuan cepat diperlukan.
  • Sesuaikan durasi periode pencocokan: Tetapkan periode pencocokan ke durasi minimum yang diperlukan untuk menangkap perilaku ancaman yang berkorelasi.
  • Hilangkan bottleneck pengiriman log: Pastikan penerus dan pengumpul mengirim data peristiwa segera untuk mencegah log terlewatkan pada periode eksekusi awal.
  • Validasi konfigurasi zona waktu: Pastikan sumber log memberikan offset UTC eksplisit untuk mencegah penundaan penyerapan yang dirasakan selama 5+ jam.
  • Audit konteks dan kondisi non-eksistensi: Gunakan kolom yang diperkaya konteks dan kondisi non-eksistensi (!$e) hanya jika diperlukan oleh logika deteksi, karena hal ini akan 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.