Pengayaan

Didukung di:

Google SecOps SIEM

Pengayaan menggunakan metode berikut untuk menambahkan konteks ke indikator atau peristiwa Unified Data Model (UDM):

• Mengidentifikasi entitas alias yang mendeskripsikan indikator, biasanya kolom UDM.
• Mengisi pesan UDM dengan detail tambahan dari alias atau entity yang diidentifikasi.
• Menambahkan data pengayaan global, seperti GeoIP dan VirusTotal, ke peristiwa UDM.

Catatan: Untuk memprioritaskan pengiriman cepat ke sistem hilir, Google SecOps mungkin tidak memperkaya sebagian kecil peristiwa (kurang dari 1%) selama proses pertama. Sistem kemudian memproses ulang peristiwa ini. Dalam kasus yang jarang terjadi, beberapa peristiwa mungkin tidak di-enrich.

Catatan: Untuk mendukung cakupan data penuh untuk aturan, penelusuran, atau dasbor yang bergantung pada kolom yang di-enrich, gunakan pengayaan real-time dengan gabungan tabel data dan grafik entitas.

Memahami pola logika pengayaan

Google SecOps menerapkan pola logis yang berbeda pada data, bergantung pada jenis pengayaan. Gunakan tabel berikut untuk memahami pola ini dalam pemecahan masalah dan untuk menjelaskan alasan kolom tertentu diisi, digabungkan, atau ditimpa.

Pola logika	Deskripsi	Pengayaan yang berlaku
Pertandingan pertama	Mengikuti daftar prioritas yang ketat. Pipeline hanya mengkueri nilai pertama yang tersedia yang ditemukan dalam urutan.	Artefak (hash file)
Digabung	Mengumpulkan dan menggabungkan data dari beberapa kolom secara bersamaan untuk membuat satu catatan entitas "emas".	Aset, Pengguna
Penggantian bersyarat	Kolom tertentu hanya digunakan untuk pengayaan jika ID dengan prioritas lebih tinggi tidak ada.	Aset (alamat ip)
Pemetaan & penimpaan	Menggunakan ID unik (PSPI) untuk menyelesaikan entity. Data yang diberi alias dari sumber pengayaan menggantikan data yang diuraikan yang ada.	Proses

Pengayaan aset

Untuk pengayaan aset, pipeline mengidentifikasi aset unik dengan mengevaluasi beberapa kolom UDM. Tidak seperti pengayaan artefak (yang memilih salah satunya), pengayaan aset menggabungkan konteks dari beberapa ID untuk membuat profil aset yang lengkap.

Google SecOps memperkaya peristiwa aset yang diklasifikasikan dengan namespace yang sama.

Untuk aset, logikanya adalah kumulatif, bukan eksklusif, kecuali untuk skenario penggantian tertentu. Gunakan detail ini untuk penjelasan:

• Jenis logika: Gabungan atau Penggantian. Pipeline mengumpulkan data dari semua kolom yang tersedia untuk membuat satu tampilan "Entitas", kecuali jika kondisi penggantian (seperti pemeriksaan asset_id) terpenuhi.
• Pemetaan kolom:
  • Nama host, MAC, dan asset_id: Diperlakukan sebagai ID utama. Hasil alias dari semua kolom ini digabungkan untuk menghasilkan profil aset akhir yang lebih kaya.
  • Alamat IP: Disertakan dalam kueri pengayaan hanya jika asset_id tidak tersedia.

Untuk setiap peristiwa aset, pipeline mengekstrak kolom UDM berikut dari entitas principal, src, dan target:

Kolom UDM	Jenis indikator	Logika / prioritas
hostname	HOSTNAME	Digabungkan: Hasil pemberian alias dari kolom ini digabungkan untuk menghasilkan catatan aset akhir yang lebih kaya.
asset_id	PRODUCT_SPECIFIC_ID	Gabungan: ID utama yang digunakan untuk menggabungkan konteks aset.
mac	MAC	Digabungkan: Digunakan bersama dengan ID lain untuk menyelesaikan aset.
ip	IP	Penggantian: Disertakan dalam kueri pengayaan hanya jika asset_id tidak tersedia.

Pengayaan pengguna

Pengayaan pengguna menyelesaikan data identitas dengan mencari ID tertentu. Seperti pengayaan artefak, pipeline ini menggunakan preferensi urutan untuk menentukan ID mana yang digunakan sebagai kunci utama untuk pencarian.

Untuk setiap peristiwa pengguna, pipeline mengekstrak kolom UDM berikut dari principal, src, dan target:

Kolom UDM	Jenis indikator	Logika atau prioritas
user.email_addresses	EMAIL	Prioritas tertinggi: Pipeline pertama-tama mencoba memperkaya berdasarkan alamat email utama atau sekunder pengguna.
user.windows_sid	WINDOWS_SID	Prioritas kedua: Jika tidak ada email yang tersedia, pipeline akan menggunakan ID Keamanan (SID) Windows.
user.userid	USER_ID	Prioritas ketiga: Hanya digunakan jika email dan SID tidak ada; biasanya dipetakan ke ID lokal atau khusus aplikasi.
user.employee_id	EMPLOYEE_ID	Prioritas terendah: Penggantian terakhir untuk menyelesaikan identitas pengguna.

Untuk setiap indikator, pipeline melakukan tindakan berikut:

• Mengambil daftar entity pengguna. Misalnya, entity principal.email_address dan principal.userid mungkin sama, atau mungkin berbeda.
• Memilih alias dari jenis indikator prioritas tertinggi, menggunakan urutan prioritas ini: WINDOWS_SID, EMAIL, USERNAME, EMPLOYEE_ID, dan PRODUCT_OBJECT_ID.
• Mengisi noun.user dengan entitas yang interval validitasnya beririsan dengan waktu peristiwa.

Catatan: Pipeline lebih memilih kolom yang diuraikan daripada kolom yang diberi alias untuk pengayaan pengguna.

Pengayaan proses

Pengayaan proses berfokus pada penyediaan visibilitas ke dalam peristiwa eksekusi. Pipeline mengekstrak detail proses dan memperkayanya dengan merujuk silang reputasi file dan hubungan induk-turunan.

Gunakan pengayaan proses untuk memetakan ID proses khusus produk (product_specific_process_id), atau PSPI, ke proses sebenarnya dan mengambil detail tentang proses induk. Proses ini mengandalkan jenis batch peristiwa EDR.

Entitas UDM	Sumber kolom	Logika atau prioritas
Entitas utama	principal, src, target	Ekstraksi: Pipeline mengekstrak PSPI dari entitas tingkat teratas ini untuk memulai pencarian.
Proses induk	principal.process.parent_process, src.process.parent_process, target.process.parent_process	Pemetaan: PSPI mengambil detail tentang proses induk dengan alias proses.
Penggabungan data	noun.process (misalnya, principal.process)	Aturan Penggantian: Kolom yang diberi alias memiliki prioritas mutlak. Jika data yang diuraikan dan data yang diberi alias ada untuk kolom yang sama, pipeline akan mengganti data yang diuraikan dengan data yang diberi alias.

Pipeline menggunakan pengalihan proses untuk mengidentifikasi proses sebenarnya dari PSPI dan mengambil informasi tentang proses induk. Kemudian, data ini digabungkan ke dalam kolom noun.process yang sesuai dalam pesan yang diperkaya.

Catatan: Pipeline memprioritaskan kolom proses yang memiliki alias. Jika kolom yang di-parse dan diberi alias ada, kolom tersebut akan mempertahankan kolom yang diberi alias dan mengganti kolom yang di-parse.

Kolom terindeks EDR untuk pengubahan nama proses

Saat proses diluncurkan, sistem mengumpulkan metadata (misalnya, baris perintah, hash file, dan detail proses induk). Software EDR yang berjalan di mesin menetapkan UUID proses khusus vendor.

Tabel berikut mencantumkan kolom yang diindeks selama peristiwa peluncuran proses:

Kolom UDM	Jenis indikator
target.product_specific_process_id	PROCESS_ID
target.process	Seluruh proses; bukan hanya indikator

Selain kolom target.process dari peristiwa yang dinormalisasi, Google SecOps mengumpulkan dan mengindeks informasi proses induk.

Pengayaan artefak

Pengayaan artefak menambahkan metadata hash file dari VirusTotal dan data geolokasi untuk alamat IP. Untuk hash file, pipeline berhenti pada nilai pertama yang ditemukan dalam daftar yang diprioritaskan; namun, untuk alamat IP, pipeline memproses semua entri secara paralel. Untuk setiap peristiwa UDM, pipeline mengekstrak dan membuat kueri data konteks untuk indikator artefak berikut dari entity principal, src, dan target, dengan perilaku pengayaan yang berbeda berdasarkan jenis indikator:

Jenis indikator	Logika ekstraksi	Prioritas / urutan operasi
Hash file	Pertandingan pertama	Pipeline menelusuri hash dalam urutan berikut dan hanya memilih yang pertama tersedia untuk mengirim kueri ke VirusTotal: file.sha256 file.sha1 file.md5 process.file.sha256 process.file.sha1 process.file.md5
Alamat IP	Paralel (berulang)	Setiap alamat IP publik atau yang dapat dirutekan diperlakukan sebagai entri independen. Tidak ada urutan preferensi; setiap IP menerima hasil pengayaannya sendiri.

Catatan: Jika pipeline menemukan metadata, pipeline akan menambahkannya ke kolom file atau process.file. Tindakan ini akan mempertahankan nilai yang ada dan hanya menambahkan data baru yang tidak tumpang-tindih dengan informasi saat ini.

Pipeline menggunakan epoch UNIX dan jam peristiwa untuk menentukan rentang waktu kueri artefak file. Jika data geolokasi tersedia, pipeline akan mengganti kolom UDM berikut untuk entitas principal, src, dan target, berdasarkan asal data geolokasi:

• artifact.ip
• artifact.location
• artifact.network (hanya jika data menyertakan konteks jaringan IP)
• location (hanya jika data asli tidak menyertakan kolom ini)

Jika menemukan metadata hash file, pipeline akan menambahkan metadata tersebut ke file atau kolom process.file, bergantung pada asal indikator. Pipeline mempertahankan nilai yang ada yang tidak tumpang-tindih dengan data baru.

Pengayaan geolokasi IP

Aliasing geografis menyediakan data geolokasi untuk alamat IP eksternal. Untuk setiap alamat IP yang tidak memiliki alias di kolom principal, target, atau src untuk peristiwa UDM, buffer subprotokol ip_geo_artifact dibuat dengan informasi lokasi dan ASN terkait.

Pengubahan nama geografis tidak menggunakan pencarian kembali atau penyimpanan dalam cache. Karena volume peristiwa yang tinggi, Google SecOps mempertahankan indeks dalam memori.

Memperkaya peristiwa dengan metadata file VirusTotal

Google SecOps memperkaya hash file menjadi peristiwa UDM dan memberikan konteks tambahan selama investigasi. Penggabungan nama hash memperkaya peristiwa UDM dengan menggabungkan semua jenis hash file dan memberikan informasi tentang hash file selama penelusuran.

Google SecOps mengintegrasikan metadata file VirusTotal dan pengayaan hubungan untuk mengidentifikasi pola aktivitas berbahaya dan melacak pergerakan malware di seluruh jaringan.

Catatan: Data ini hanya tersedia untuk lisensi VirusTotal dan Google SecOps tertentu. Periksa hak Anda dengan Account Manager Anda.

Log mentah memberikan informasi terbatas tentang file. VirusTotal memperkaya peristiwa dengan metadata file, termasuk detail tentang hash dan file berbahaya. Metadata mencakup informasi, misalnya, nama file, jenis, fungsi yang diimpor, dan tag. Anda dapat menggunakan informasi ini di mesin penelusuran dan deteksi UDM dengan YARA-L untuk memahami peristiwa file berbahaya dan selama perburuan ancaman. Misalnya, Anda dapat mendeteksi modifikasi pada file asli yang menggunakan metadata file untuk deteksi ancaman.

Catatan: Proses pengayaan tidak menggantikan nilai di kolom log mentah dengan nilai pengayaan.

Informasi berikut disimpan bersama data. Untuk mengetahui daftar semua kolom UDM, lihat Daftar kolom Model Data Terpadu.

Jenis data	Kolom UDM
sha-256	( principal | target | src | observer ).file.sha256
md5	( principal | target | src | observer ).file.md5
sha-1	( principal | target | src | observer ).file.sha1
ukuran	( principal | target | src | observer ).file.size
ssdeep	( principal | target | src | observer ).file.ssdeep
vhash	( principal | target | src | observer ).file.vhash
authentihash	( principal | target | src | observer ).file.authentihash
Imphash metadata file PE	( principal | target | src | observer ).file.pe_file.imphash
security_result.threat_verdict	( principal | target | src | observer ).(process | file).security_result.threat_verdict
security_result.severity	( principal | target | src | observer ).(process | file).security_result.severity
last_modification_time	( principal | target | src | observer ).file.last_modification_time
first_seen_time	( principal | target | src | observer ).file.first_seen_time
last_seen_time	( principal | target | src | observer ).file.last_seen_time
last_analysis_time	( principal | target | src | observer ).file.last_analysis_time
exif_info.original_file	( principal | target | src | observer ).file.exif_info.original_file
exif_info.product	( principal | target | src | observer ).file.exif_info.product
exif_info.company	( principal | target | src | observer ).file.exif_info.company
exif_info.file_description	( principal | target | src | observer ).file.exif_info.file_description
signature_info.codesign.id	( principal | target | src | observer ).file.signature_info.codesign.id
signature_info.sigcheck.verfied	( principal | target | src | observer ).file.signature_info.sigcheck.verified
signature_info.sigcheck.verification_message	( principal | target | src | observer ).file.signature_info.sigcheck.verification_message
signature_info.sigcheck.signers.name	( principal | target | src | observer ).file.signature_info.sigcheck.signers.name
signature_info.sigcheck.status	( principal | target | src | observer ).file.signature_info.sigcheck.signers.status
signature_info.sigcheck.valid_usage	( principal | target | src | observer ).file.signature_info.sigcheck.signers.valid_usage
signature_info.sigcheck.cert_issuer	( principal | target | src | observer ).file.signature_info.sigcheck.signers.cert_issuer
file_type	( principal | target | src | observer ).file.file_type

Memecahkan masalah pengayaan

Jika Anda melihat bahwa peristiwa UDM tidak memiliki data pengayaan yang diharapkan, gunakan saran berikut untuk membantu menyelesaikan masalah Anda.

Pengayaan umum

Jika beberapa peristiwa Anda tidak diperkaya sama sekali, kemungkinan penyebabnya adalah Google SecOps memprioritaskan kecepatan pengiriman. Sebagian kecil peristiwa (<1%) mungkin melewati pengayaan selama proses pertama. Untuk mengatasinya, periksa kembali dalam beberapa menit. Sistem akan otomatis memproses ulang peristiwa ini. Jika pengayaan masih tidak ada setelah satu jam, pastikan sumber log diuraikan dengan benar ke dalam UDM.

Pengayaan artefak (logika kecocokan pertama)

Jika peristiwa Anda memiliki hash MD5 dan SHA256, tetapi Anda hanya dapat melihat metadata VirusTotal untuk SHA256, ini adalah logika kecocokan pertama. Pipeline berhenti segera setelah menemukan hash dengan prioritas tertinggi (sha256). Pipeline tidak membuat kueri MD5 ke VirusTotal jika SHA256 ada.

Jika Anda melihat geolokasi untuk principal.ip, tetapi tidak untuk target.ip, logika paralel memperlakukan setiap IP secara independen. Jika satu IP bersifat internal atau pribadi (tidak dapat dirutekan) dan yang lainnya bersifat publik, hanya IP publik yang menerima pengayaan geolokasi.

Pengayaan aset (logika penggabungan dan penggantian)

Jika kolom alamat IP tidak menampilkan data pengayaan pada aset Anda, berarti kolom tersebut menggunakan logika penggantian bersyarat. IP hanya digunakan untuk kueri pengayaan jika asset_id (PSID) tidak ada. Jika asset_id ada, sistem akan mengandalkannya dan mengabaikan IP untuk kueri tertentu tersebut guna mencegah data yang berlebihan atau bertentangan.

Pengayaan pengguna (preferensi urutan)

Jika kolom Department menampilkan "IT" saat log lokal saya menampilkan "Security", berarti pengayaan pengguna lebih memilih kolom yang diuraikan daripada kolom yang diberi alias. Jika log mentah Anda diuraikan dengan "IT", pipeline pengayaan tidak akan menggantinya dengan nilai "Security" dari sumber identitas Anda (misalnya, Okta atau AD).

Proses pengayaan (pemetaan dan penimpaan)

Jika Anda melihat nama proses di log mentah, tetapi di penelusuran UDM, nama tersebut diganti dengan nama lain, berarti ada logika penimpaan. Pengayaan proses memprioritaskan kolom yang memiliki alias. Jika pencarian PSPI menampilkan nama proses yang lebih akurat dari konteks EDR, nama tersebut akan sepenuhnya menggantikan nilai yang diuraikan asli.

Langkah berikutnya

Untuk mengetahui informasi tentang cara menggunakan data yang telah di-enrich dengan fitur Google SecOps lainnya, lihat artikel berikut:

• Gunakan data yang diperkaya konteks di Penelusuran UDM.
• Menggunakan data yang diperkaya konteks dalam aturan.
• Menggunakan data yang diperkaya konteks dalam laporan.

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