Memahami pemutaran ulang aturan dan MTTD

Didukung di:

Dokumen ini menjelaskan cara pemutaran ulang aturan (juga disebut penyelesaian atau penyesuaian) menangani data yang terlambat tiba dan pembaruan konteks, serta pengaruh pemutaran ulang ini terhadap metrik Waktu Rata-Rata untuk Mendeteksi (MTTD).

Pemutaran ulang aturan

Google Security Operations memproses data keamanan dalam volume besar. Untuk memastikan deteksi yang akurat untuk aturan yang bergantung pada data kontekstual atau berkorelasi, mesin aturan otomatis menjalankan proses pemutaran ulang aturan.

Proses pemutaran ulang aturan menangani kategori aturan berikut:

  • Aturan peristiwa tunggal: Aturan ini diputar ulang saat proses pengayaan UDM memperbarui peristiwa yang sebelumnya dievaluasi. Untuk pengecualian terkait aturan dengan tabel data, lihat Skenario data yang terlambat tiba di bagian selanjutnya dalam dokumen ini.

  • Aturan Peristiwa tunggal dengan periode (WSE) dan Aturan peristiwa tunggal dengan tabel data: Aturan ini memiliki mekanisme penjadwalan yang berbeda untuk menangani data yang terlambat tiba, yang berbeda dari aturan peristiwa tunggal dan multi-peristiwa standar.

  • Aturan banyak peristiwa: Aturan ini dijalankan sesuai jadwal, memproses blok waktu peristiwa. Mereka berulang kali mengevaluasi ulang blok waktu yang sama pada interval yang berbeda untuk mendapatkan pembaruan pengayaan yang terlambat, seperti mencocokkan data konteks pengguna atau aset atau Indikator Penyusupan (IOC). Waktu persisnya bergantung pada konfigurasi jadwal.

Pemicu pemutaran ulang aturan

Sistem mengevaluasi ulang (menjalankan ulang) aturan untuk memastikan sistem mendeteksi, meskipun data tiba atau diperbarui setelah eksekusi aturan awal. Data yang terlambat tiba ini mencakup kategori berikut:

  • Peristiwa sumber yang terlambat tiba: Peristiwa log mentah atau UDM itu sendiri tiba di Google SecOps jauh lebih lambat daripada stempel waktu sebenarnya dari peristiwa tersebut.
  • Data pengayaan yang terlambat tiba: Data kontekstual (misalnya, pengguna, aset, intelijen ancaman) yang terkait dengan peristiwa menjadi tersedia, atau sistem memperbaruinya, setelah pertama kali memproses peristiwa tersebut. Hal ini sering terjadi karena pipeline pengayaan, seperti grafik konteks entitas (ECG), memproses data dalam batch atau bergantung pada sumber data eksternal.
  • Pembaruan pengayaan UDM secara retroaktif: Data sumber yang terlambat tiba (seperti catatan DHCP yang memperbarui nama host) memicu perubahan pada kolom peristiwa UDM. Aturan yang menggunakan kolom yang diberi alias (kolom yang diperkaya) dalam logika deteksinya, seperti $udm.event.principal.hostname, dapat memicu pemutaran ulang saat data sumber tertunda. Kedatangan terlambat ini akan memperbarui nilai kolom tersebut secara retroaktif.

Sistem memicu pemutaran ulang aturan secara berbeda, bergantung pada jenis aturan dan sifat data yang terlambat. Tujuannya adalah menyeimbangkan ketepatan waktu deteksi dengan kelengkapan data.

Cara sistem menangani data yang terlambat tiba menurut jenis aturan

Jenis aturan dan konfigurasinya menentukan jangka waktu saat data yang terlambat tiba dapat memicu evaluasi ulang aturan.

  • Aturan peristiwa tunggal (tanpa jendela pencocokan atau tabel data):

    • Peristiwa sumber yang terlambat: Umumnya, aturan ini memproses peristiwa terlepas dari berapa lama stempel waktunya saat tiba di sistem. Sistem tidak memberlakukan periode penutupan yang ketat untuk pemrosesan awal peristiwa sumber yang terlambat.
    • Pengayaan terlambat: Jika data pengayaan untuk peristiwa yang sebelumnya dievaluasi tiba atau pembaruan terjadi, sistem akan mengevaluasi ulang aturan peristiwa tunggal ini terhadap peristiwa dengan konteks baru. Hal ini dapat terjadi beberapa jam atau bahkan beberapa hari setelah peristiwa awal.

  • Aturan peristiwa tunggal berjangka waktu (WSE) dan aturan peristiwa tunggal dengan tabel data:

    • Aturan ini tidak mengikuti penanganan data terlambat yang sama seperti aturan peristiwa tunggal lainnya atau jadwal penyesuaian aturan multi-peristiwa.
    • Perilakunya adalah sebagai berikut:
      • Batas waktu: Aturan ini tidak memproses peristiwa yang dimasukkan 7 hari atau lebih setelah stempel waktu peristiwa.
      • Data yang Terlambat (<7 hari): Sistem memproses peristiwa yang terlambat kurang dari 7 hari, tetapi dengan latensi yang berpotensi lebih tinggi.
      • Peristiwa sumber yang terlambat tiba: Aturan WSE tidak akan memproses peristiwa jika data tiba di Google SecOps 7 hari atau lebih setelah stempel waktu peristiwa.
      • Pembaruan Konteks: Jika konteks untuk suatu peristiwa terlambat tiba atau jika suatu peristiwa diperkaya secara retroaktif, sistem akan otomatis mengevaluasi ulang aturan terhadap peristiwa yang diperkaya. Pemutaran ulang aturan ini dapat memicu deteksi baru, meskipun evaluasi awal tidak menghasilkan deteksi.
      • Pengayaan terlambat: Jika peristiwa UDM diperbarui karena pengayaan (yang dapat terjadi hingga 7 hari setelah penyerapan), sistem akan mengevaluasi ulang aturan ini terhadap peristiwa yang diperbarui. Namun, tidak seperti jenis aturan lainnya, pembaruan pada konten tabel data tidak memicu evaluasi ulang otomatis peristiwa sebelumnya untuk aturan ini.
      • Periode lihat balik: Aturan ini menggunakan periode lihat balik sekitar 7 hari untuk mengevaluasi ulang peristiwa. Jika data pengayaan tiba untuk peristiwa yang berada dalam jangka waktu 7 hari ini, aturan akan dievaluasi ulang.

  • Aturan multi-peristiwa:

    • Aturan multi-peristiwa dijalankan sesuai jadwal dan mengevaluasi ulang blok waktu untuk memperhitungkan data yang terlambat. Jadwal aturan menentukan periode penghentian yang efektif:
      • Run utama: Sistem menjalankan evaluasi pertama pada waktu peristiwa ditambah penundaan penyelesaian yang dikonfigurasi (misalnya, T + 1 jam).
      • Penyesuaian berjalan 1: Sistem menjalankan penyesuaian pertama sekitar 4 jam setelah proses utama. Hal ini memungkinkan sistem menyertakan peristiwa yang terlambat tiba.
      • Penyesuaian berjalan 2 (Bersyarat): Jika Anda mengaktifkan Pastikan kelengkapan pengayaan, sistem akan menjalankan penyesuaian akhir sekitar 30 jam setelah penyesuaian utama. Hal ini memperpanjang periode bagi sistem untuk memproses data yang terlambat tiba dan pengayaan konteks hingga sekitar 30 jam.
      • Implikasi penghentian: Penyesuaian akhir yang sebenarnya menentukan penghentian efektif untuk menyertakan data yang terlambat. Hal ini biasanya terjadi sekitar 4 jam setelah proses utama (atau sekitar 30 jam setelah proses utama jika Anda mengaktifkan Pastikan kelengkapan pengayaan). Peristiwa atau pengayaan yang tiba setelah operasi penyesuaian akhir untuk jangka waktu tertentu tidak akan diproses oleh aturan ini untuk jangka waktu tersebut.

Contoh skenario data yang tiba terlambat

  • Skenario 1: Peristiwa sumber terlambat - Aturan peristiwa tunggal

    • Google SecOps menyerap peristiwa dengan stempel waktu dari 3 hari yang lalu. Aturan peristiwa tunggal standar memproses peristiwa ini sebagai data baru.

  • Skenario 2: Pengayaan terlambat - Aturan peristiwa tunggal

    • Sistem memproses peristiwa login kemarin. Saat ini, sistem ini menyerap dan memperkaya informasi baru untuk pengguna yang terlibat (misalnya, perubahan departemen). Sistem mengevaluasi ulang aturan peristiwa tunggal terhadap peristiwa login dengan konteks pengguna yang diperbarui.

  • Skenario 3: Peristiwa sumber terlambat - Aturan multi-peristiwa (penyesuaian default 4 jam)

    • Peristiwa tiba 3 jam setelah stempel waktu peristiwanya untuk aturan multi-peristiwa yang dijadwalkan dengan setelan default. Peristiwa tersebut terlewatkan pada proses utama awal (T + 1 jam), tetapi sistem memprosesnya selama proses penyesuaian 4 jam.

  • Skenario 4: Peristiwa sumber terlambat - Aturan multi-peristiwa (tanpa kelengkapan pengayaan)

    • Anda mengonfigurasi aturan multi-peristiwa dengan offset eksekusi utama 1 jam tanpa mengaktifkan Pastikan kelengkapan pengayaan. Peristiwa tiba 6 jam setelah stempel waktunya.
    • Peristiwa ini tidak ada pada run utama (T + 1 jam) dan true-up run pertama (T + 4 jam). Sistem tidak akan memproses peristiwa ini untuk periode waktu tersebut karena peristiwa tiba setelah proses penyesuaian akhir dijalankan.

  • Skenario 5: Pengayaan terlambat - Aturan multi-peristiwa (dengan kelengkapan pengayaan)

    • Aturan multi-peristiwa memiliki offset 1 jam dan Anda mengaktifkan Pastikan kelengkapan pengayaan. Data pengayaan untuk peristiwa tiba 28 jam setelah stempel waktu peristiwa.
    • Sistem mengevaluasi ulang aturan menggunakan pengayaan terlambat ini selama proses penyesuaian kedua pada sekitar T + 31 jam.

  • Skenario 6: Peristiwa sumber terlambat - Aturan multi-peristiwa dengan periode pencocokan

    • Aturan multi-peristiwa memiliki periode match 48 jam dan jadwal dengan Pastikan kelengkapan pengayaan diaktifkan (penyesuaian akhir sekitar T + 30 jam). Peristiwa tiba 36 jam setelah stempel waktunya. Peristiwa ini tidak akan diproses karena tiba setelah proses penyamaan akhir dijalankan, meskipun waktu peristiwa berada dalam periode pencocokan aturan relatif terhadap peristiwa lain. Batas waktu didasarkan pada waktu kedatangan relatif terhadap jadwal penyesuaian, bukan hanya periode pertandingan.

  • Skenario 7: Peristiwa sumber terlambat - Aturan peristiwa tunggal berjendela

    • Jika peristiwa sumber dengan stempel waktu dari 8 hari yang lalu terlambat tiba, peristiwa tersebut mungkin berada di luar periode lihat balik 7 hari untuk aturan WSE, dan mungkin tidak diproses.

Dampak pada metrik waktu

Jika deteksi dihasilkan dari pemutaran ulang aturan, sistem akan menggunakan terminologi berikut:

  • Periode deteksi atau Stempel waktu peristiwa peringatan merujuk pada waktu aktivitas berbahaya asli.
  • Waktu pembuatan adalah waktu sistem membuat deteksi, yang bisa jauh lebih lama, terkadang beberapa jam atau hari kemudian.
  • Latensi deteksi adalah selisih waktu antara Stempel waktu peristiwa dan Waktu pembuatan deteksi.

Delta linimasa dan MTTD

Waktu yang berlalu antara stempel waktu peristiwa awal dan pembuatan deteksi secara langsung memengaruhi perhitungan MTTD Anda.

Tahap pipeline / jadwal Waktu evaluasi Dampak pada pengukuran MTTD
Aturan peristiwa tunggal (Streaming) Berkelanjutan (<5 menit setelah kedatangan) Deteksi real-time menunjukkan kecepatan platform yang sebenarnya dengan dampak minimal pada MTTD.
Aturan multi-peristiwa (Run Utama) 1 hingga 2 jam setelah kedatangan (ditambah penundaan penyelesaian yang dikonfigurasi) Mencakup jendela buffering batch yang tidak dapat dihindari yang diperlukan untuk menggabungkan status korelasi multi-peristiwa.
Aturan multi-peristiwa (Menjalankan penyesuaian) 4 jam atau 30 jam setelah tugas utama Jalankan ulang sekunder (replay) yang menggabungkan data pengayaan yang terlambat menyebabkan waktu ini muncul terlambat atau tertunda relatif terhadap Stempel waktu peristiwa. Delta ini berdampak negatif pada penghitungan MTTD.

Praktik terbaik untuk mengukur MTTD

MTTD mengukur waktu dari gangguan awal hingga deteksi ancaman yang efektif. Saat Anda menganalisis deteksi yang dipicu oleh pemutaran ulang aturan, terapkan praktik terbaik berikut untuk mempertahankan metrik MTTD yang akurat.

Google SecOps menyediakan beberapa metrik yang dapat dikueri pengguna untuk mengukur MTTD secara akurat. Untuk mengetahui informasi selengkapnya tentang metrik ini, lihat halaman Contoh kueri YARA-L 2.0 untuk Dasbor.

Ikon di kolom Jenis Deteksi mengidentifikasi deteksi yang dihasilkan dari data peristiwa yang terlambat lebih dari 30 menit, proses penyelarasan otomatis, pipeline pemrosesan ulang, atau retrohunt. Ikon ini juga muncul di halaman Peringatan di Google SecOps.

Memprioritaskan sistem deteksi real-time

Untuk deteksi tercepat, gunakan aturan peristiwa tunggal. Aturan ini berjalan secara hampir real-time, biasanya dengan penundaan kurang dari 5 menit. Hal ini juga mendukung penggunaan Deteksi gabungan yang lebih komprehensif.

Memperhitungkan pemutaran ulang aturan dalam aturan multiperistiwa

Aturan multi-peristiwa secara inheren menimbulkan latensi yang lebih tinggi karena frekuensi jalannya yang terjadwal. Saat Anda mengukur MTTD untuk deteksi dari aturan multiperistiwa, ketahui bahwa pemutaran ulang aturan otomatis meningkatkan cakupan dan akurasi. Pemutaran ulang ini sering kali menangkap ancaman yang memerlukan konteks terlambat, yang meningkatkan latensi yang dilaporkan untuk deteksi tersebut.

  • Untuk pemberitahuan penting dan mendesak: Gunakan aturan peristiwa tunggal atau aturan multi-peristiwa dengan frekuensi eksekusi praktis yang paling singkat. Mengurangi periode pencocokan tidak secara langsung memengaruhi latensi, tetapi dapat meningkatkan efisiensi dengan menetapkan penundaan minimum.

  • Untuk korelasi yang kompleks dan berdurasi panjang (UEBA, serangan multi-tahap): Aturan ini mengandalkan gabungan kontekstual atau daftar referensi yang ekstensif, yang mungkin diperbarui secara asinkron. Pengguna dapat mengalami latensi tinggi dengan data peristiwa atau kontekstual yang terlambat tiba, tetapi menawarkan manfaat deteksi fidelitas yang lebih tinggi daripada kecepatan absolut.

Mengoptimalkan aturan untuk mengurangi ketergantungan pada pengayaan data terlambat

Untuk mengoptimalkan kecepatan deteksi dan meminimalkan dampak eksekusi pengayaan secara retroaktif, pertimbangkan untuk menggunakan kolom non-alias (kolom yang tidak diproses oleh pipeline pengayaan hilir) dalam logika aturan Anda jika memungkinkan.

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.