Format data log sebagai UDM

Semua peristiwa Model Data Terpadu (UDM) memiliki kumpulan kolom dan pesan umum yang dapat diisi oleh partner terlepas dari jenis peristiwanya. Kolom ini meliputi:

  • Entitas: Perangkat, pengguna, dan proses yang terlibat dalam sebuah peristiwa.
  • Metadata peristiwa: Saat peristiwa terjadi, jenis peristiwa, dari mana asalnya, dll.
  • Metadata jaringan: Metadata jaringan tingkat tinggi untuk peristiwa berorientasi jaringan serta detail protokol dalam sub-pesan:
    • Metadata email: Informasi di kolom email kepada, dari, cc, bcc, dan lainnya.
    • Metadata HTTP: Metode, reference_url, useragent, dll.
  • Hasil keamanan: Klasifikasi atau tindakan apa pun yang dilakukan oleh produk keamanan.
  • Metadata tambahan: Setiap data peristiwa penting khusus vendor yang tidak dapat direpresentasikan secara memadai dalam bagian formal model UDM dapat ditambahkan menggunakan kolom payload json format bebas.

Bagian berikut menjelaskan cara mengenkode dan memformat peristiwa untuk Model Data Terpadu (UDM).

Encoding UDM

Acara UDM harus dikirimkan ke Chronicle menggunakan salah satu format berikut:

Untuk tujuan dokumen ini, kolom direpresentasikan menggunakan notasi titik. Misalnya, sintaksis JSON berikut:

{"menu":
  {
    "id": "file",
    "value": "File",
    "popup": {
      "menuitem": [
        {"value": "New", "onclick": "CreateNewDoc()"}
      ]
    }
  }
}

didokumentasikan sebagai berikut:

menu.id = "file"
menu.value = "File"
menu.popup.menuitem.value = "New"
menu.popup.menuitem.onclick = "CreateNewDoc()"

Memformat Peristiwa UDM

Untuk memformat peristiwa UDM agar siap dikirim ke Google, Anda harus menyelesaikan langkah-langkah berikut:

  1. Menentukan Jenis Peristiwa—Jenis peristiwa yang Anda pilih menentukan kolom yang juga harus Anda sertakan dengan peristiwa.
  2. Menentukan Stempel Waktu Peristiwa—Menentukan stempel waktu peristiwa.
  3. Menentukan Kata Benda (Entitas)—Setiap acara harus menyertakan setidaknya satu kata benda yang menjelaskan perangkat peserta atau pengguna yang terlibat dalam acara.
  4. Menentukan Hasil Keamanan—(Opsional) Tentukan hasil keamanan dengan menyertakan detail tentang risiko keamanan dan ancaman yang ditemukan oleh sistem keamanan serta tindakan yang diambil untuk memitigasi risiko dan ancaman tersebut.
  5. Isi sisa informasi acara yang wajib dan opsional menggunakan kolom acara UDM.

Menentukan Jenis Peristiwa

Nilai terpenting yang ditetapkan untuk peristiwa yang dikirimkan dalam format UDM adalah jenis peristiwa, yang ditentukan menggunakan salah satu nilai yang mungkin yang tersedia untuk Metadata.event_type. Hal ini mencakup nilai seperti PROCESS_OPEN, FILE_CREATION, USER_CREATION, NETWORK_DNS, dll. (untuk daftar lengkapnya, lihat Metadata.event_type. Setiap jenis peristiwa mengharuskan Anda juga mengisi kumpulan kolom dan nilai lainnya dengan informasi yang terkait dengan peristiwa asli. Lihat Kolom Wajib dan Opsional untuk Setiap Jenis Peristiwa UDM untuk mengetahui detail tentang kolom yang harus disertakan untuk setiap jenis peristiwa. Contoh berikut mengilustrasikan cara menentukan PROCESS_OPEN sebagai jenis peristiwa menggunakan notasi teks Proto3:

metadata {
    event_type: PROCESS_OPEN
}

Menentukan Stempel Waktu Peristiwa

Anda harus menentukan stempel waktu GMT untuk setiap acara yang dikirimkan dalam format UDM menggunakan Metadata.event_ timestamp. Stempel harus dienkode menggunakan salah satu standar berikut:

  • Untuk JSON, gunakan RFC 3339
  • Stempel waktu proto3

Contoh berikut mengilustrasikan cara menentukan stempel waktu menggunakan format RFC 3339. Untuk contoh ini, yyyy-mm-ddThh:mm:ss+hh:mm—tahun, bulan, hari, jam, menit, detik, dan perbedaan waktunya dari waktu UTC. Selisih dari UTC adalah minus 8 jam, yang menunjukkan PST.

metadata {
  event_timestamp: "2019-09-10T20:32:31-08:00"
}

Menentukan Kata Benda (Entitas)

Untuk setiap peristiwa UDM, Anda harus menentukan satu atau beberapa kata benda. Kata benda mewakili peserta atau entitas dalam acara UDM. Kata benda dapat berupa, misalnya, perangkat/pengguna yang melakukan aktivitas yang dijelaskan dalam sebuah peristiwa, atau perangkat/pengguna yang menjadi target dari aktivitas tersebut yang dijelaskan dalam peristiwa tersebut. Kata benda juga dapat berupa lampiran atau URL. Terakhir, kata benda juga dapat digunakan untuk menggambarkan perangkat keamanan yang mengamati aktivitas yang dijelaskan dalam peristiwa (misalnya, proxy email atau router jaringan).

Acara UDM harus memiliki satu atau beberapa kata benda berikut:

utama: Menggambarkan entitas yang melakukan tindakan atau perangkat yang menghasilkan aktivitas yang dijelaskan dalam peristiwa. Akun utama harus menyertakan setidaknya satu detail mesin (nama host, MAC, IP, port, ID khusus produk seperti GUID mesin CrowdStrike) atau detail pengguna (misalnya, nama pengguna), dan secara opsional menyertakan detail proses. Email TIDAK boleh menyertakan salah satu kolom berikut: email, file, kunci registry, atau nilai.

Jika semua peristiwa terjadi di perangkat yang sama, perangkat tersebut hanya perlu dijelaskan di utama. Mesin juga tidak perlu dijelaskan di target atau src.

Contoh berikut menggambarkan cara mengisi kolom utama:

principal {
  hostname: "jane_win10"
  asset_id: "Sophos.AV:C070123456-ABCDE"
      ip: "10.0.2.10"
      port: 60671
      user {  userid: "john.smith" }
}

Contoh di atas menjelaskan semua hal yang diketahui tentang perangkat dan pengguna yang merupakan aktor utama yang dijelaskan dalam peristiwa. Contoh ini mencakup alamat IP dan nomor port perangkat, serta nama host-nya. Ini juga mencakup pengenal aset khusus vendor (dari Sophos) yang merupakan pengenal unik yang dihasilkan oleh produk keamanan pihak ketiga.

target: Menggambarkan perangkat target yang direferensikan oleh peristiwa, atau objek pada perangkat target. Misalnya, dalam koneksi firewall dari perangkat A ke perangkat B, A dideskripsikan sebagai akun utama dan B disebut sebagai target. Untuk injeksi proses oleh proses C ke dalam proses target D, proses C dijelaskan sebagai utama dan proses D dijelaskan sebagai target.

prinsip versus target di udm

Target Versus Utama di UDM

Contoh berikut menggambarkan bagaimana kolom target diisi:

target {
   ip: "198.51.100.31"
   port: 80
}

Sekali lagi, jika informasi selengkapnya tersedia, seperti nama host, alamat IP tambahan, alamat MAC, ID aset kepemilikan, dll., informasi tersebut juga harus disertakan dalam target.

Baik utama maupun target (serta kata benda lainnya) dapat mereferensikan aktor di mesin yang sama. Misalnya, proses A (utama) yang berjalan pada mesin X akan diproses pada proses B (target) dan juga pada mesin X.

  • src: Menggambarkan objek sumber yang ditindaklanjuti oleh peserta bersama dengan konteks perangkat atau proses untuk objek sumber (mesin tempat objek sumber berada). Misalnya, jika pengguna U menyalin file A di mesin X ke file B di mesin Y, file A dan mesin X akan ditentukan di bagian src dari peristiwa UDM.
  • perantara: Menampilkan detail pada satu atau beberapa aktivitas pemrosesan perangkat perantara yang dijelaskan dalam peristiwa. Hal ini mencakup detail perangkat tentang server proxy, server relai SMTP, dll.
  • observer: Menggambarkan perangkat pengamat (misalnya, sniffer paket atau pemindai kerentanan berbasis jaringan), yang bukan perantara langsung, tetapi yang mengamati dan melaporkan peristiwa yang dimaksud.
  • about: Digunakan untuk menyimpan detail semua objek yang dirujuk oleh peristiwa yang tidak dijelaskan dalam peserta, src, target, perantara, atau pengamat. Misalnya, ini dapat digunakan untuk melacak hal berikut:
    • Lampiran file email
    • Domain/URL/IP yang disematkan dalam isi email
    • DLL yang dimuat selama peristiwa PROCESS_LAUNCH

Bagian entity acara UDM mencakup informasi tentang berbagai peserta (perangkat, pengguna, objek seperti URL, file, dll.) yang dijelaskan dalam acara. UDM Chronicle memiliki persyaratan wajib terkait pengisian kolom Noun. Persyaratan ini dijelaskan di Kolom Wajib dan Opsional untuk Setiap Jenis Peristiwa UDM. Kumpulan kolom entitas yang harus diisi berbeda-beda bergantung pada jenis peristiwa.

Menetapkan Hasil Keamanan

Secara opsional, Anda dapat menentukan hasil keamanan dengan mengisi kolom SecurityResult, termasuk detail tentang risiko keamanan dan ancaman yang ditemukan oleh sistem keamanan serta tindakan yang diambil untuk mengurangi risiko dan ancaman tersebut. Berikut adalah contoh beberapa jenis peristiwa keamanan yang memerlukan pengisian kolom SecurityResult:

  • Proxy keamanan email mendeteksi upaya phishing (EMAIL_PHISHING) dan memblokir (BLOCK) email.
  • Firewall proxy keamanan email mendeteksi dua lampiran yang terinfeksi (SOFTWARE_MALICIOUS) serta dikarantina dan disinfeksi (QUARANTINE, ALLOW_WITH_MODIFICATION) lampiran ini, kemudian meneruskan email yang telah didisinfeksi tersebut.
  • Sistem SSO memfasilitasi proses masuk (AUTH_VIOLATION) yang diblokir (BLOCK).
  • Sandbox malware mendeteksi spyware (SOFTWARE_MALICIOUS) pada lampiran file lima menit setelah file dikirim (ALLOW) kepada pengguna di kotak masuk mereka.