Ini adalah artikel kedua dalam seri ini, yang dikhususkan untuk metodologi untuk membuat aturan korelasi out-of-the-box untuk sistem SIEM. Pada artikel sebelumnya , kami mengatur sendiri tugas ini, menjelaskan keuntungan yang akan diperoleh dalam implementasinya, dan juga mencantumkan masalah utama yang menghalangi kami. Dalam artikel ini, kita akan mulai mencari solusi dan mulai dengan masalah mengubah model "dunia" , serta manifestasinya pada tahap normalisasi peristiwa.



Masalah mengubah model "dunia" dijelaskan dalam artikel pertama. Mari kita secara singkat mengingat esensinya: ketika sebuah fenomena muncul di sumber peristiwa (misalnya, memulai proses dalam OS), ia diperbaiki dalam format yang berbeda, pertama dalam memori, kemudian dalam log peristiwa OS dan kemudian dalam sistem SIEM. Setiap tahap pemrosesan disertai dengan kehilangan data, karena pada tingkat OS ada satu model "dunia", dan dalam log OS, yang lain, dibatasi oleh seperangkat bidang, oleh skema log. Dengan demikian, ada refleksi (transformasi) dari satu model dengan sejumlah besar parameter ke yang lain, dengan jumlah yang lebih kecil. Normalisasi dan penyimpanan suatu peristiwa di SIEM adalah transformasi lain yang juga terjadi dengan kehilangan data, karena SIEM juga memiliki model "dunia" sendiri.

Sulit untuk menemukan cara yang memungkinkan transformasi satu model menjadi model lain tanpa kehilangan. Mengetahui batasan ini, perlu dirumuskan pendekatan normalisasi dan pembentukan daftar bidang skema acara, di mana informasi tidak akan hilang, penting dalam korelasi dan penyelidikan lebih lanjut dari insiden keamanan informasi.

Dalam kerangka SIEM, model diwakili oleh skema - seperangkat bidang di mana data dari acara awal cocok dengan proses normalisasi. Di masa depan, ini akan digunakan oleh spesialis dalam membuat aturan korelasi. Agar penyelidik insiden dan mereka yang bertanggung jawab untuk mengembangkan aturan korelasi dengan jelas menginterpretasikan kejadian yang dinormalisasi, skema harus memenuhi sifat dasar:

• disatukan untuk acara apa pun jenis dan sumbernya;
• jelas menggambarkan siapa yang berinteraksi dengan siapa dan bagaimana;
• menjaga esensi dan konteks interaksi.

Dalam proses mengembangkan aturan normalisasi, informasi tentang interaksi harus ditemukan di acara awal dan didekomposisi menjadi bidang yang ditunjuk secara khusus. Hal yang sama perlu dilakukan dengan konteks dan esensi interaksi (lebih lanjut tentang ini di artikel selanjutnya).

Muncul pertanyaan: apakah mungkin untuk mengidentifikasi skema khas untuk interaksi yang akan memuaskan setiap peristiwa yang dibuat oleh semua sumber TI dan keamanan informasi yang mungkin? Jika demikian, seperti apa skema ini?

Untuk menemukan jawaban atas pertanyaan-pertanyaan ini, Anda perlu beralih ke analytics dan mencoba menganalisis sebanyak mungkin aturan normalisasi yang telah dikembangkan dan beroperasi dalam solusi SIEM mungkin untuk mengidentifikasi pola umum. Sebagai bagian dari pekerjaan tersebut, dimungkinkan untuk menganalisis lebih dari 3.000 aturan normalisasi dari lebih dari 100 sumber berbeda dari solusi seperti Positive Technologies MaxPatrol SIEM dan Micro Focus ArcSight. Analisis menghasilkan kesimpulan sebagai berikut:

1. Ada skema interaksi yang khas.
2. Dalam setiap peristiwa individu, sebagai aturan, ada informasi tentang interaksi di tingkat jaringan dan di tingkat aplikasi .
3. Pola interaksi yang khas dapat bervariasi pada tingkat yang berbeda, dan ini harus diperhitungkan.

Skema komunikasi lapisan aplikasi dan jaringan

Kami menggambarkan skema tipikal untuk setiap level. Sebelum ini, Anda perlu menyoroti entitas yang selalu hadir dalam acara. Selanjutnya, berdasarkan pada mereka, skema interaksi akan dibangun. Ini termasuk:

• Subjek . Entitas yang memengaruhi suatu objek. Misalnya, pengguna mengubah kunci registri, atau host dengan IP 10.0.0.1, mengirim paket ke host dengan IP 20.0.0.1.
• Obyek . Entitas yang dipengaruhi oleh Subjek.
• Sumber Sebagai aturan, tuan rumah yang mendaftarkan interaksi Subjek dengan Objek dan menghasilkan acara itu sendiri. Misalnya, Sumber akan menjadi firewall yang mencatat pengiriman paket dari host - Subjek dengan IP 10.0.0.1, ke host - Obyek dengan IP 20.0.0.1.
• Pemancar Ada beberapa kasus ketika SIEM menerima peristiwa tidak langsung dari sumbernya, tetapi dari server perantara yang melaluinya peristiwa ini. Contoh paling sederhana adalah server syslog menengah. Contohnya lebih rumit - ketika Transmitter dapat menjadi server manajemen, misalnya, Pusat Keamanan Kaspersky. Dalam hal ini, Sumber adalah agen spesifik Kaspersky Endpoint Security.

Namun, tidak semua entitas dapat secara bersamaan diwakili dalam acara tersebut (lebih lanjut tentang ini nanti), oleh karena itu penting untuk awalnya menandatangani perjanjian, karena dalam kasus ini bidang skema yang sesuai diisi. Ini akan membantu di masa depan untuk secara jelas membedakan antara kasus-kasus di mana bidang-bidang ini tidak diisi karena kesalahan oleh seorang spesialis yang mengembangkan aturan normalisasi dari kasus-kasus di mana acara asli tidak benar-benar berisi data tentang entitas apa pun.

Mari kita beralih ke pola interaksi dan contoh acara. Untuk kejelasan, semua contoh akan diberikan berdasarkan file log, pesan syslog, atau catatan dalam database relasional, tetapi mereka dapat digunakan untuk format log lainnya, misalnya, biner.

Tingkat jaringan

Pengidentifikasi utama untuk entitas tingkat jaringan adalah alamat IP. Penting untuk dipahami bahwa mungkin ada pengidentifikasi terkait lainnya - alamat MAC di tingkat saluran, FQDN - di tingkat aplikasi. Muncul pertanyaan: apakah mereka berbicara tentang entitas yang sama atau berbeda? Bisakah pengidentifikasi ini berubah seiring waktu dengan entitas yang sama? Artikel terpisah akan dikhususkan untuk ini. Sekarang mari kita memikirkan fakta bahwa pengidentifikasi utama untuk model interaksi di tingkat jaringan adalah alamat IP.

Jadi, skema interaksi khas tingkat ini dapat dibagi menjadi dua kelas - dasar dan merosot.

Skema interaksi dasar

Skema 1. Skema interaksi lengkap

Dalam kerangka model ini, dalam hal diterima pada input SIEM, semua entitas utama dapat dibedakan: Subjek, Objek, Sumber, Pemancar. Dalam skema interaksi, Subjek bertindak pada Objek. Efek ini mendaftarkan (mengamati) Sumber dan menghasilkan suatu peristiwa. Acara dari Sumber memasuki Transmitter dan dari itu memasuki SIEM.

Acara di bawah ini menangkap resolusi interaksi jaringan antara host oleh firewall Stonesoft (sekarang Forcepoint), sementara acara itu sendiri tidak memasukkan SIEM secara langsung, tetapi dari server syslog perantara.



Di sini:
40.0.0.1 - Transmitter (server syslog menengah),
30.0.0.1 - Sumber (simpul firewall),
10.0.0.1 - Subjek (mengirim paket UDP),
20.0.0.1 - Objek (menerima paket UDP).


Diagram 2: Diagram pengumpulan langsung tanpa pemancar

Tidak selalu dalam skema interaksi adalah pemancar. Sebagai aturan, itu hadir ketika server perantara (misalnya, server syslog) digunakan untuk mengirimkan peristiwa, atau ketika solusi dari mana peristiwa dikumpulkan memiliki sistem manajemen terpusat - misalnya, Pusat Keamanan Kaspersky, Check Point Smart Console atau Cisco Prime. Di bawah skema ini, peristiwa jatuh ke SIEM langsung dari Sumber. Sebagian besar dari semua peristiwa dijelaskan oleh skema khusus ini. Ngomong-ngomong, contoh kejadian seperti itu dapat dilihat pada Gambar 1 , jika tidak ada server syslog perantara di dalamnya dan kami menerima acara langsung dari firewall.



Di sini:
30.0.0.1 - Sumber (simpul firewall),
10.0.0.1 - Subjek (mengirim paket UDP),
20.0.0.1 - Objek (menerima paket UDP).


Skema 3. Interaksi dengan banyak Obyek

Skema interaksi ini di tingkat jaringan sangat jarang dan, sebagai suatu peraturan, adalah tipikal untuk kejadian peralatan jaringan. Dalam skema, satu Subjek berinteraksi dengan banyak Objek, interaksi serupa hadir dalam acara yang menggambarkan siaran multicast, unicast atau siaran.

Perhatikan bahwa terkadang banyak Objek dapat disatukan oleh pengidentifikasi umum - alamat subnet atau alamat broadcast. Ini harus diingat, karena ketika menganalisis peristiwa, termasuk pada tingkat aturan korelasi, Anda dapat dengan mudah melewatkan interaksi yang berpotensi penting, karena dalam skema ini alamat Objek disembunyikan di belakang alamat grup.

Contoh berikut menunjukkan acara dari server Relay IGMP yang melaluinya permintaan keanggotaan multicast disiarkan.



Di sini:
30.0.0.1 - Sumber (server Relay IGMP),
10.0.0.1 - Subjek (meminta keanggotaan dalam grup),
224.0.0.252 - Objek (alamat multicast).

Skema degenerasi

Subjek, Obyek dan Sumber adalah entitas dasar dalam kelompok skema interaksi dasar. Namun, ada beberapa kasus ketika salah satu entitas mungkin tidak hadir dalam acara tersebut.


Skema 4. Interaksi tanpa Obyek

Seringkali pola semacam itu tipikal dalam situasi di mana Subjek melaporkan perubahan dalam keadaan internalnya - yaitu, ia bertindak secara bersamaan dalam peran Subjek dan Objek. Misalnya, interaksi ini dapat diamati dalam perubahan konfigurasi atau peristiwa deteksi malware di workstation. Tetapi informasi ini tidak direkam oleh Subjek sendiri, tetapi oleh sistem manajemen terpusat dan disimpan dalam jurnalnya.

Contoh tersebut menunjukkan bagaimana Server Manajemen Symantec menangkap bahwa agen Perlindungan Titik Akhir Symantec yang dikelolanya telah mendeteksi file jahat di inangnya.



Di sini:
30.0.0.1 - Sumber (Server Manajemen Symantec),
10.0.0.1 - Subjek (Symantec Endpoint Protection Agent).


Skema 5. Menggabungkan peran Subjek dan Objek dalam Sumber

Skema interaksi degenerasi terakhir adalah tipikal untuk situasi ketika SIEM menerima peristiwa dari Sumber melaporkan perubahan dalam kondisi internalnya: misalnya, mengkonfigurasi ulang perangkat atau perangkat lunak, mengaktifkan atau menonaktifkan port jaringan. Dalam skema semacam itu, peran Sumber bertepatan dengan peran Subjek dan Obyek. Berbeda dengan skema sebelumnya, acara di SIEM datang langsung.

Dalam contoh ini, switch berbasis Cisco IOS melaporkan bahwa antarmuka telah beralih ke status UP.



Di sini 30.0.0.1 adalah Sumber (switch).

Tingkat aplikasi

Pada level ini, ada interaksi entitas yang sudah dikenal: Subjek, Objek. Namun, semua informasi tentang Sumber dan Pemancar tetap langsung di tingkat jaringan dan tidak tercermin di tingkat aplikasi.

Sebagian besar dari semua jenis peristiwa menggabungkan interaksi secara bersamaan di tingkat jaringan dan tingkat aplikasi. Namun, kami mencatat bahwa peristiwa yang dihasilkan langsung oleh perangkat lunak aplikasi, misalnya, 1C: Enterprise, Microsoft SQL Server, atau Oracle Database, dapat berisi interaksi tingkat aplikasi secara eksklusif.

Selain itu, entitas Sumber Daya tambahan muncul di tingkat aplikasi.

Sumber daya adalah entitas perantara di mana Subjek memberikan pengaruh pada Obyek tanpa interaksi langsung. Misalnya, memberi Alex hak untuk mengakses MyFile ke Bob. Di sini Alex adalah Subjek, Bob adalah Obyek, MyFile adalah Sumberdaya. Harap perhatikan bahwa dalam contoh ini, Alex tidak berinteraksi langsung dengan Bob.

Penting : peristiwa di tingkat aplikasi dapat berisi parameter tambahan pada Subjek dan Objek, serta Sumberdaya itu sendiri. Misalnya, parameter tambahan Sumber Daya seperti "file" dapat berupa direktori di mana ia berada, atau ukurannya.
Dalam hal ini, Subjek, Obyek dan Sumberdaya diidentifikasi dengan nama atau pengidentifikasi unik: alamat email, nama file, nama direktori, nama tabel dalam database.

Pertimbangkan pola interaksi tambahan khusus untuk tingkat aplikasi.


Gambar 6. Interaksi Sumber Daya

Dalam diagram ini, Subjek secara tidak langsung bertindak pada Obyek melalui Sumber tengah. Sebagai aturan, acara dengan skema seperti itu terlihat jelas di log audit database atau ketika bekerja dengan hak akses ke file dan direktori di tingkat OS.

Contoh ini menunjukkan entri dari database audit dari Oracle Database. Ini memperbaiki proses pencabutan peran dari pengguna.



Di sini:
"ALEX" - Subjek (nama pengguna yang menarik peran),
"BOB" - Obyek (nama pengguna yang dicabut),
"ROLE" - Sumberdaya (nama peran yang dicabut).


Diagram 7. Interaksi dengan banyak sumber daya

Di tingkat aplikasi, serta di tingkat jaringan, ada beberapa jenis peristiwa di mana Subjek berinteraksi dengan Obyek segera melalui banyak Sumber Daya. Ini sangat jarang, tetapi ada kalanya jumlah Obyek juga lebih dari satu. Jenis peristiwa ini muncul saat memperbaiki operasi massal. Misalnya, memberikan akses ke beberapa file ke satu pengguna atau mengubah seperangkat aturan yang termasuk dalam kebijakan.

Dalam contoh tersebut, solusi untuk melindungi lingkungan virtual vGate Security Code menangkap penambahan kebijakan baru ke set.



Di sini:
"Admin @ VGATE" - Subjek (nama pengguna mengubah serangkaian kebijakan)
"Base" - Obyek (set kebijakan)
“Menginstal dan memelihara integritas sistem file”, “Memeriksa pengaturan agen SNMP”, “Menonaktifkan instalasi otomatis Alat VMware” - Sumberdaya (nama kebijakan tambahan)

Model saluran interaksi antara Subjek dan Objek

Pada semua skema, kami membedakan entitas yang berbeda (subjek, objek, sumber daya, sumber, pemancar) dan mencatat apa yang disebut saluran interaksi di antara mereka. Mari kita membahas lebih rinci tentang komponen kedua dari model besar "dunia" yang harus dioperasikan SIEM - pada model saluran interaksi antara Subjek dan Objek. Ingat bahwa komponen terakhir adalah konteks interaksi (artikel selanjutnya akan dikhususkan untuk ini).

Jadi, ada dua entitas yang saling berinteraksi. Sebagai bagian dari interaksi ini, data ditransfer dari satu entitas ke entitas lain. Ini bisa berupa paket jaringan dengan data, file, atau perintah manajemen. Dalam hal ini, saluran yang terbentuk dapat direpresentasikan dalam bentuk "pipa" di mana ada aliran data dan perintah yang diarahkan. Model seperti itu jelas terlihat di tingkat jaringan, tetapi kurang menonjol pada tingkat aplikasi (lihat contoh ).


Model saluran data

Berdasarkan model seperti itu, setiap peristiwa yang diterima SIEM dapat berisi informasi yang menjelaskan:

• Parameter saluran itu sendiri adalah "pipa",
• Data ditransmisikan melalui "pipa" ini.

Biasanya, saluran dijelaskan oleh parameter seperti pengidentifikasi sesi, protokol transfer data, waktu pembuatan saluran, waktu penyelesaian, durasi. Data dalam peristiwa dicirikan oleh format yang digunakan oleh algoritma enkripsi, jumlah paket yang ditransmisikan, jumlah byte yang dikirim.

Pertimbangkan contoh acara yang berisi data tentang saluran interaksi. Berikut ini adalah peristiwa dari Cisco Identity Services Engine (ISE), sistem manajemen proses untuk mengidentifikasi dan mengendalikan akses, yang merekam sesi jaringan pengguna sebagai bagian dari prosedur akuntansi (akuntansi).




Di sini:
"Acct-Session-Id = 1A346216", "Acct-Session-Time = 50", "Service-Type = Framed", "Frame-Protocol = PPP" - parameter saluran komunikasi,
"Acct-Input-Octets = 43525", "Acct-Output-Octets = 122215", "Acct-Input-Packets = 234", "Acct-Output-Packets = 466" - parameter data yang dikirim melalui saluran.

Contoh model interaksi entitas dan saluran dalam satu acara

Jadi, kami memeriksa skema interaksi tingkat jaringan dan aplikasi, serta model saluran interaksi. Selanjutnya, kami menunjukkan contoh bagaimana dalam satu peristiwa skema interaksi dari berbagai tingkatan digabungkan dan informasi tentang model saluran digunakan.

Di sini kita melihat peristiwa dari firewall - Cisco Adaptive Security Appliance (ASA), di mana koneksi TCP keluar diperbaiki.



Contohnya dengan jelas menunjukkan bahwa dalam satu peristiwa terdapat entitas tingkat jaringan dan tingkat aplikasi. Di tingkat jaringan, skema interaksi antara Subjek dan Objek, yang ditetapkan oleh Sumber. Tidak ada pemancar.

Di sini:
30.0.0.1 - Sumber (Cisco ASA),
10.0.0.1 - Subjek (alamat orang yang menghubungkan),
20.0.0.1 - Objek (alamat dari siapa mereka terhubung).

Pada tingkat aplikasi, skema sederhana di mana hanya Subjek dan Objek hadir:
"ALEX" - Subjek (nama pengguna yang menghubungkan),
"BOB" - Objek (nama pengguna yang mereka hubungkan).

Juga dalam acara ini ada deskripsi saluran transmisi data, tetapi tidak ada deskripsi data itu sendiri:
"TCP" adalah protokol berdasarkan saluran yang dibuat,
"136247" adalah pengidentifikasi sesi saluran.

Kesimpulan

Bagaimana skema interaksi tipikal yang disorot oleh kami dapat membantu?

• Pertama , ketika menulis aturan korelasi dan menganalisis peristiwa, seorang ahli harus memahami entitas apa yang hadir dalam setiap peristiwa yang tiba di SIEM. Untuk ini, perlu, pada tahap normalisasi peristiwa, untuk secara jelas membedakan entitas: Subjek, Obyek, Sumber Daya, Sumber dan Pemancar.
• Kedua , selama normalisasi, penting untuk mempertimbangkan bahwa acara tersebut berisi informasi baik tentang interaksi tingkat jaringan dan tingkat aplikasi. Kedua interaksi ini dapat hadir secara bersamaan dalam satu acara.
• Ketiga , interaksi itu sendiri adalah struktur komposit di mana ada informasi tentang saluran yang terbentuk dan tentang data yang dikirimkan melalui saluran ini.

Dengan demikian, model "dunia", yang dibangun dalam SIEM dan diwakili oleh seperangkat bidang (skema), harus berisi bagian untuk menggambarkan:

1. Di tingkat jaringan :
   
   • Subjek;
   • Objek;
   • Sumber;
   • Pemancar
   • Saluran interaksi;
   • Data dikirimkan melalui saluran.
   
   
2. Di tingkat aplikasi :
   
   • Subjek;
   • Suatu objek atau sejumlah objek;
   • Sumber daya atau banyak sumber daya.
   
   

Untuk setiap entitas, perlu untuk menentukan serangkaian properti yang secara unik mengidentifikasinya. Di tingkat jaringan, entitas diidentifikasi oleh IP, MAC, atau FQDN. Pada level aplikasi, dengan nama atau ID. Skema harus memiliki bidang khusus untuk menyimpan pengidentifikasi ini.

Ada skema interaksi yang menurun di mana satu entitas dapat menggabungkan beberapa peran sekaligus. Ketika menormalkan peristiwa tersebut, perlu untuk secara eksplisit mendefinisikan aturan untuk mengisi semua bidang skema yang bertanggung jawab untuk seluruh rangkaian entitas. Di masa depan, ini akan membantu aturan korelasi untuk tidak melewatkan bagian dari interaksi.

Mari kita jelaskan: ambil kasus menggabungkan peran Subjek dan Objek di Sumber. , , , , .

, . , .

, , :


,

— «» SIEM , . , , Alex , — , , , . , . , - , , SIEM .

, , . , , .

---

:

SIEM: « ». 1: ?

SIEM: « ». 2. «» ( )

SIEM: « ». 3.1.

SIEM: « ». 3.2.

SIEM: « ». 4.

SIEM: « ». 5.