Memahami keterlambatan 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 yang terstruktur, dan memberikan teknik untuk mengurangi latensi deteksi.

Ringkasan aturan deteksi

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

Penundaan yang diperkirakan dan tidak terduga

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

  • Penundaan yang diperkirakan: Penundaan yang disebabkan oleh faktor struktural, seperti proses penyerapan, jenis aturan, frekuensi operasi, metode pembuatan deteksi, durasi periode pencocokan, dan batasan sistem yang diketahui. Anda dapat meminimalkan penundaan yang diperkirakan dengan menyesuaikan konfigurasi aturan deteksi dan parameter penjadwalan.
  • Penundaan yang tidak dapat 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 hampir real-time (biasanya dalam waktu 5 menit setelah penyerapan). Peristiwa yang datang terlambat dan pengayaan retroaktif dievaluasi secara terus-menerus selama eksekusi standar.
  • Mesin kueri: Mengevaluasi aturan yang memerlukan korelasi peristiwa berbasis waktu di beberapa peristiwa atau penggabungan data eksternal:
    • Aturan peristiwa tunggal yang kompleks: Mencakup aturan peristiwa tunggal yang mengkueri daftar referensi atau tabel data.
    • Aturan multi-peristiwa: Membuat kueri data dalam blok waktu peristiwa dalam batch (seperti interval 10 menit atau 1 jam, atau match_window / 10 untuk periode yang lebih dari 48 jam) berdasarkan jadwal yang dikonfigurasi.
  • Aturan dijalankan terhadap data historis: Mengevaluasi aturan secara retroaktif terhadap log historis melalui retrohunt. Deteksi akan muncul setelah pemindaian historis selesai.
  • Pengayaan ulang peristiwa UDM: Mengevaluasi ulang blok waktu yang telah diproses sebelumnya saat konteks baru atau data entity yang diperbarui ditambahkan ke peristiwa historis.

Faktor yang berkontribusi pada keterlambatan deteksi aturan

Kecepatan kemunculan 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 dijalankan 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 menyertakan dependensi data tambahan:

  • Aturan peristiwa tunggal berjendela: Aturan peristiwa tunggal yang menyertakan bagian match (misalnya, mengevaluasi apakah satu peristiwa cocok dengan kondisi selama jangka waktu tertentu). Aturan ini dievaluasi secara 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 banyak peristiwa

Aturan multi-peristiwa menghubungkan dua atau beberapa 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 mengeksekusi pada interval 10 menit atau 1 jam (atau match_window / 10 untuk periode yang lebih dari 48 jam).
  • Aturan kontekstual: Menghubungkan 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 berjendela).
  • Frekuensi 10 menit: Tersedia untuk aturan banyak peristiwa dengan periode pencocokan di bawah 60 menit.
  • Frekuensi 1 jam: Interval default untuk aturan multi-peristiwa dengan periode pencocokan 48 jam atau kurang.
  • Frekuensi match_window / 10: Ditetapkan secara otomatis untuk aturan multi-peristiwa dengan jendela kecocokan lebih dari 48 jam (misalnya, berjalan 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 jangka waktu penuh 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 melewatkan eksekusi pertama. Sistem akan menangkap data yang terlambat tiba dalam operasi latar belakang otomatis berikutnya (operasi penyesuaian), yang terjadi sekitar 4 jam (dan secara opsional 30 jam dengan kelengkapan pengayaan) setelah operasi utama.

  • Contoh: Aturan menghubungkan 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 pukul 09.00–09.30. Sistem akan mengevaluasi ulang blokir selama proses penyesuaian berikutnya sekitar 4 jam setelah proses utama (sekitar pukul 14.00), sehingga menghasilkan deteksi sekitar 5 jam setelah peristiwa terjadi.

Untuk mengetahui informasi tentang latensi pengindeksan upstream di feed polling API pihak ketiga, lihat Peristiwa yang terlambat tiba di feed polling.

Perbedaan zona waktu

Google SecOps menafsirkan stempel waktu log sebagai UTC secara default. Jika sumber log menghilangkan selisih zona waktu eksplisit, sistem akan memperlakukan stempel waktu sebagai UTC, yang dapat menyebabkan log tampak terlambat meskipun diterima 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 menciptakan penundaan penyerapan selama 5 jam yang menunda evaluasi aturan ke proses penyesuaian latar belakang.

Solusi sementara: Untuk mengatasi perbedaan zona waktu:

  • Konfigurasikan sumber log untuk menyertakan selisih zona waktu UTC eksplisit dalam stempel waktu peristiwa.
  • Hubungi Dukungan untuk menetapkan 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 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 aliasing dan pengayaan

Aliasing dan pengayaan menghubungkan indikator mentah dengan konteks organisasi:

  • Aliasing: Mengidentifikasi dan menautkan ID yang berbeda untuk entity 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 alias (seperti mengisi $udm.event.principal.hostname jika 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 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 masuk.
  • Update sistem pengayaan: Saat metadata entity, geolokasi IP, atau threat intelligence VirusTotal diupdate, mesin aturan akan mengevaluasi ulang blok historis (biasanya selama eksekusi true-up atau pemrosesan ulang terjadwal) untuk menghasilkan deteksi dengan konteks yang diperbarui.
  • Data konteks tertunda: Jika data konteks (seperti nama host) tiba sehari setelah log peristiwa, sistem akan memperkaya ulang peristiwa UDM, dan operasi penyesuaian berikutnya akan mengevaluasi data yang diperkaya.
  • Modifikasi konteks: Jika pembaruan 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)

Entity Context Graph (ECG) menghubungkan Indikator Penyusupan (IOC) dan data grafik aset perusahaan. Karena pipeline ECG mengandalkan batch processing (yang dapat memerlukan waktu 30 jam atau hingga beberapa hari, bergantung pada volume data), aturan yang merujuk ke kolom graph.entity akan menghasilkan deteksi setelah hubungan grafik dihitung sepenuhnya.

Operasi aturan historis dan retrohunt

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

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

Daftar referensi

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

Aturan ketiadaan

Untuk mencegah positif palsu, sistem menerapkan jeda minimal satu jam sebelum mengevaluasi aturan yang memeriksa kondisi non-eksistensi (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 operasi 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 pengukuran.
  • Bandingkan Waktu peristiwa dengan Waktu penyerapan: Temukan deteksi di tab Detections 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 penyesuaian otomatis, pipeline pemrosesan ulang, atau retrohunt akan menampilkan ikon di kolom Detection Type.
  • Tinjau dependensi sumber konteks: Periksa apakah aturan merujuk pada pengayaan principal, 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 operasi yang dikonfigurasi sesuai dengan ukuran periode pencocokan (misalnya, memastikan aturan dengan periode pencocokan 15 menit dijadwalkan untuk 10 menit atau 1 jam).
  • Periksa gangguan feed data: Tinjau log penyerapan dan dasbor pengelolaan feed untuk mengetahui penundaan penyerapan atau pemadaman layanan sumber sementara.

Tips untuk mempersingkat penundaan deteksi

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

  • Optimalkan frekuensi eksekusi aturan:
    • Gunakan Hampir real-time untuk aturan peristiwa tunggal (standar dan berjendela).
    • Konfigurasikan 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 yang memerlukan pemberitahuan cepat.
  • Menyesuaikan durasi jendela pencocokan: Tetapkan jendela pencocokan ke durasi minimum yang diperlukan untuk menangkap perilaku ancaman yang berkorelasi.
  • Menghilangkan bottleneck pengiriman log: Pastikan forwarder dan kolektor segera mengirim data peristiwa untuk mencegah log melewatkan periode eksekusi awal.
  • Validasi konfigurasi zona waktu: Pastikan sumber log memberikan offset UTC eksplisit untuk mencegah penundaan penyerapan yang diperkirakan lebih dari 5 jam.
  • Audit konteks dan kondisi tidak ada: Gunakan kolom yang diperkaya konteks dan kondisi tidak ada (!$e) hanya jika diperlukan oleh logika deteksi, karena hal ini menyebabkan 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.