Memahami pemutaran ulang aturan dan MTTD

Didukung di:

Dokumen ini menjelaskan cara pemutaran ulang aturan (juga disebut pembersihan 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 jumlah besar. Untuk memastikan deteksi akurat untuk aturan yang bergantung pada data kontekstual atau data yang dikorelasikan, mesin aturan akan 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 Berjendela (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 standar dan aturan multi-peristiwa.

  • Aturan multi-peristiwa: Aturan ini dijalankan sesuai jadwal, memproses blok waktu peristiwa. Aturan ini berulang kali mengevaluasi ulang blok waktu yang sama pada interval yang berbeda untuk menangkap pembaruan pengayaan yang terlambat, seperti data konteks aset atau pengguna yang cocok atau indikator penyusupan (IOC). Waktu yang tepat bergantung pada konfigurasi jadwal.

Pemicu pemutaran ulang aturan

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

  • Peristiwa sumber yang terlambat tiba: Peristiwa log atau UDM mentah itu sendiri tiba di Google SecOps jauh lebih lambat daripada stempel waktu peristiwa yang sebenarnya.
  • 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 entity (ECG), memproses data dalam batch atau bergantung pada sumber data eksternal.
  • Pembaruan pengayaan UDM retrospektif: 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 yang terlambat ini secara retrospektif memperbarui nilai kolom tersebut.

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 berdasarkan jenis aturan

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

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

    • Peristiwa sumber yang terlambat: Umumnya, aturan ini memproses peristiwa terlepas dari usia stempel waktunya saat tiba di sistem. Sistem tidak menerapkan jendela batas waktu yang ketat untuk pemrosesan awal peristiwa sumber yang terlambat.
    • Pengayaan yang terlambat: Jika data pengayaan untuk peristiwa yang sebelumnya dievaluasi tiba atau terjadi pembaruan, 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 berjendela (WSE) dan aturan peristiwa tunggal dengan tabel data:

    • Aturan ini tidak mengikuti penanganan data yang terlambat yang sama seperti aturan peristiwa tunggal lainnya atau jadwal penyesuaian aturan multi-peristiwa.
    • Aturan ini memiliki perilaku berikut:
      • Batas waktu: Aturan ini tidak memproses peristiwa yang di-ingest 7 hari atau lebih setelah stempel waktu peristiwa.
      • Data yang Terlambat Tiba (<7d): Sistem memproses peristiwa yang terlambat tiba kurang dari 7 hari, tetapi dengan potensi latensi yang 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 peristiwa terlambat tiba atau jika peristiwa diperkaya secara retrospektif, 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 yang terlambat: Jika peristiwa UDM diperbarui karena pengayaan (yang dapat terjadi hingga 7 hari setelah pengiriman), 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.
      • Jendela lihat balik: Aturan ini menggunakan jendela lihat balik sekitar 7 hari untuk mengevaluasi ulang peristiwa. Jika data pengayaan tiba untuk peristiwa yang berada dalam jendela 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 jendela batas waktu yang efektif:
      • Jalankan utama: Sistem menjalankan evaluasi pertama pada waktu peristiwa ditambah penundaan penyelesaian yang dikonfigurasi (misalnya, T + 1 jam).
      • Jalankan penyesuaian 1: Sistem menjalankan penyesuaian pertama sekitar 4 jam setelah menjalankan utama. Hal ini memungkinkan sistem menyertakan peristiwa yang terlambat tiba.
      • Jalankan penyesuaian 2 (Bersyarat): Jika Anda mengaktifkan Pastikan kelengkapan pengayaan, sistem akan menjalankan penyesuaian akhir sekitar 30 jam setelah menjalankan utama. Hal ini memperpanjang jangka waktu bagi sistem untuk memproses data yang terlambat tiba dan pengayaan konteks hingga sekitar 30 jam.
      • Implikasi batas waktu: Penyesuaian akhir menentukan batas waktu efektif untuk menyertakan data yang terlambat. Hal ini biasanya terjadi sekitar 4 jam setelah menjalankan utama (atau sekitar 30 jam setelah menjalankan utama jika Anda mengaktifkan Pastikan kelengkapan pengayaan). Peristiwa atau pengayaan yang tiba setelah penyesuaian akhir untuk jangka waktu tertentu tidak akan diproses oleh aturan ini untuk jangka waktu tersebut.

Contoh skenario data yang terlambat tiba

  • Skenario 1: Peristiwa sumber yang terlambat - Aturan peristiwa tunggal

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

  • Skenario 2: Pengayaan yang terlambat - Aturan peristiwa tunggal

    • Sistem memproses peristiwa login kemarin. Hari ini, sistem meng-ingest 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 yang terlambat - Aturan multi-peristiwa (penyesuaian 4 jam default)

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

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

    • Anda mengonfigurasi aturan multi-peristiwa dengan offset menjalankan utama 1 jam tanpa mengaktifkan Pastikan kelengkapan pengayaan. Peristiwa tiba 6 jam setelah stempel waktunya.
    • Peristiwa ini tidak memenuhi syarat untuk menjalankan utama (T + 1 jam) dan penyesuaian pertama (T + 4 jam). Sistem tidak akan memproses peristiwa ini untuk jangka waktu tersebut karena peristiwa tiba setelah penyesuaian akhir.

  • Skenario 5: Pengayaan yang 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 yang terlambat ini selama penyesuaian kedua pada sekitar T + 31 jam.

  • Skenario 6: Peristiwa sumber yang terlambat - Aturan multi-peristiwa dengan jendela kecocokan

    • Aturan multi-peristiwa memiliki jendela 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 penyesuaian akhir, meskipun waktu peristiwa berada dalam jendela kecocokan aturan relatif terhadap peristiwa lainnya. Batas waktu didasarkan pada waktu kedatangan relatif terhadap jadwal penyesuaian, bukan hanya jendela kecocokan.

  • Skenario 7: Peristiwa sumber yang 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:

  • Jendela deteksi atau Stempel waktu peristiwa pemberitahuan merujuk ke waktu aktivitas berbahaya asli.
  • Waktu pembuatan adalah waktu sistem membuat deteksi, yang dapat terjadi jauh kemudian, 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 (Jalankan 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 (Jalankan penyesuaian) 4 jam atau 30 jam setelah menjalankan utama Jalankan sekunder (putar ulang) yang menggabungkan data pengayaan yang terlambat menyebabkan waktu ini muncul terlambat atau tertunda relatif terhadap Stempel waktu peristiwa. Delta ini berdampak negatif pada perhitungan MTTD.

Praktik terbaik untuk mengukur MTTD

MTTD mengukur waktu dari gangguan awal hingga deteksi efektif ancaman. 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 Contoh kueri YARA-L 2.0 untuk halaman Dasbor.

Ikon di kolom Jenis Deteksi mengidentifikasi deteksi yang dihasilkan dari data peristiwa yang terlambat lebih dari 30 menit, penyesuaian otomatis, pipeline pemrosesan ulang, atau retrohunt. Ikon ini juga muncul di halaman Pemberitahuan 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 multi-peristiwa

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

  • Untuk pemberitahuan penting yang sensitif terhadap waktu: Gunakan aturan peristiwa tunggal atau aturan multi-peristiwa dengan frekuensi menjalankan praktis terpendek. Mengurangi jendela kecocokan tidak secara langsung memengaruhi latensi, tetapi dapat meningkatkan efisiensi dengan menetapkan penundaan minimum.

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

Mengoptimalkan aturan untuk mengurangi ketergantungan pada pengayaan yang terlambat

Untuk mengoptimalkan kecepatan deteksi dan meminimalkan dampak menjalankan pengayaan retrospektif, 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.