Memahami pemutaran ulang aturan dan MTTD

Didukung di:

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

Pemutaran ulang aturan

Google SecOps memproses data keamanan dalam jumlah besar. Untuk memastikan deteksi yang 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: Saat proses pengayaan UDM memperbarui peristiwa yang sebelumnya dievaluasi, sistem akan memutar ulang aturan peristiwa tunggal. (Lihat pengecualian untuk aturan dengan tabel data di bawah).

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

  • Aturan multi-peristiwa: Aturan multi-peristiwa 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 Gangguan (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 ini mencakup kategori berikut:

  • Peristiwa sumber yang terlambat: Log mentah atau peristiwa UDM itu sendiri tiba di Google SecOps jauh lebih lambat daripada stempel waktu peristiwa yang sebenarnya.
  • Data pengayaan yang terlambat: Data kontekstual (misalnya, pengguna, aset, intelijen ancaman) yang terkait dengan peristiwa 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 (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 akan memperbarui nilai kolom tersebut secara retrospektif.

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

Jenis aturan dan konfigurasinya menentukan jangka waktu data yang terlambat 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 dengan jendela (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 dimasukkan 7 hari atau lebih setelah stempel waktu peristiwa.
      • Data yang Terlambat (<7d): Sistem memproses peristiwa yang terlambat kurang dari 7 hari, tetapi dengan potensi latensi yang lebih tinggi.
      • Peristiwa sumber yang terlambat: 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 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 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.
      • 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. Cara Anda mengonfigurasi jadwal aturan menentukan jendela batas waktu yang efektif:
      • Jadwal default: Sistem biasanya menjalankan penyesuaian otomatis sekitar 5 jam dan 24 jam setelah waktu peristiwa. Jika data tiba setelah penyesuaian 24 jam selesai, data tersebut tidak akan dievaluasi oleh aturan ini untuk jangka waktu tersebut.
      • Jadwal yang dapat disesuaikan diaktifkan: Fitur ini memberi Anda kontrol yang lebih besar atas waktu proses melalui setelan "Frekuensi Proses". Lihat Mengonfigurasi jadwal yang disesuaikan untuk aturan. Waktu utama adalah:
        • Proses pertama: Sistem menjalankan proses pertama pada waktu peristiwa ditambah offset yang dikonfigurasi (misalnya, T + 1 jam).
        • Proses penyesuaian 1: Sistem menjalankan Proses penyesuaian pertama sekitar 4 jam setelah Proses Pertama. Artinya, sistem dapat menyertakan peristiwa yang tiba hingga sekitar T + 4-5 jam.
        • Proses penyesuaian 2 (Bersyarat): Jika Anda mengaktifkan Pastikan pengayaan selesai, sistem akan menjalankan proses penyesuaian akhir sekitar 30 jam setelah Proses Pertama. Hal ini memperpanjang jangka waktu bagi sistem untuk memproses data yang terlambat hingga sekitar T + 30-31 jam.
      • Implikasi batas waktu: Dengan jadwal yang dapat disesuaikan, proses penyesuaian terakhir menentukan batas waktu efektif untuk menyertakan data yang terlambat. Hal ini biasanya terjadi sekitar 4 jam setelah proses pertama, atau sekitar 30 jam setelah proses pertama jika Anda mengaktifkan Pastikan pengayaan selesai. Peristiwa atau pengayaan yang tiba setelah proses penyesuaian akhir untuk jangka waktu tertentu tidak akan diproses oleh aturan ini untuk jangka waktu tersebut.

Contoh skenario data yang terlambat

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

    • Google SecOps memasukkan 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 memasukkan 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 (Jadwal default)

    • Jika peristiwa tiba 10 jam setelah stempel waktu peristiwanya, sistem akan melewatkannya selama proses penyesuaian 5 jam, tetapi memprosesnya selama proses penyesuaian 24 jam. Peristiwa yang terlambat 25 jam tidak akan diproses.

  • Skenario 4: Peristiwa sumber yang terlambat - Aturan multi-peristiwa (Jadwal yang dapat disesuaikan)

    • Anda mengonfigurasi aturan multi-peristiwa dengan offset proses pertama 1 jam. Peristiwa tiba 6 jam setelah stempel waktunya.
    • Peristiwa ini melewatkan proses pertama (T + 1 jam) dan proses penyesuaian pertama (T + 4 jam). Sistem TIDAK akan memproses peristiwa ini dengan aturan ini, kecuali jika Anda mengaktifkan Pastikan pengayaan selesai.

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

    • Aturan multi-peristiwa memiliki offset 1 jam dan Anda mengaktifkan Pastikan pengayaan selesai. Data pengayaan untuk peristiwa tiba 28 jam setelah stempel waktu peristiwa.
    • Beberapa data pengayaan yang terlambat ini mungkin tersedia untuk "Proses penyesuaian" kedua, yang terjadi sekitar T + 30 jam (karena Anda mengaktifkan Pastikan pengayaan selesai). Jika data pengayaan tersedia, sistem akan mengevaluasi ulang aturan menggunakan pengayaan yang terlambat ini.

  • Skenario 6: Peristiwa sumber yang terlambat - Aturan multi-peristiwa dengan Jendela Kecocokan

    • Aturan multi-peristiwa memiliki jendela match 48 jam dan jadwal kustom dengan Pastikan pengayaan selesai diaktifkan (penyesuaian akhir sekitar T + 30 jam). Peristiwa tiba 36 jam setelah stempel waktunya. Peristiwa ini tidak akan diproses karena tiba setelah proses 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 dengan jendela

    • Jika peristiwa sumber dengan stempel waktu dari 8 hari yang lalu terlambat, peristiwa tersebut mungkin berada di luar jendela 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 bisa jauh lebih lambat, terkadang beberapa jam atau hari kemudian.
  • Latensi deteksi adalah selisih waktu antara Stempel waktu peristiwa dan Waktu pembuatan deteksi.

Pengayaan ulang karena data yang terlambat, atau latensi dengan pembaruan sumber konteks seperti grafik konteks entity (ECG) biasanya menyebabkan latensi deteksi yang tinggi.

Selisih waktu ini dapat membuat deteksi tampak "terlambat" atau "tertunda", yang dapat membingungkan analis dan mendistorsi metrik performa seperti MTTD.

Komponen metrik Sumber waktu Pengaruh pemutaran ulang terhadap MTTD
Jendela deteksi / Stempel waktu peristiwa Waktu terjadinya peristiwa keamanan asli. Pemutaran ulang menjaga akurasi waktu peristiwa.
Waktu deteksi / Waktu pembuatan Waktu mesin benar-benar memunculkan deteksi. Proses sekunder (pemutaran ulang) yang menggabungkan data pengayaan yang terlambat menyebabkan waktu ini tampak 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 ancaman yang efektif. Saat 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 detail tentang metrik ini, lihat Contoh kueri YARA-L 2.0 untuk halaman Dasbor.

Ikon di kolom Jenis Deteksi mengidentifikasi deteksi yang dihasilkan sistem dari data peristiwa yang terlambat lebih dari 30 menit, proses ulang aturan, 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 dalam waktu yang 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 proses yang dijadwalkal kan. Saat 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 proses praktis terpendek. Mengurangi jendela kecocokan 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 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, 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 proses pengayaan retrospektif, pertimbangkan untuk menggunakan kolom non-alias (kolom yang tidak diproses oleh pipeline pengayaan hilir) dalam logika aturan Anda jika memungkinkan.

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