Seberapa sering Anda mendengar pernyataan bahwa aturan korelasi yang diberikan oleh produsen SIEM tidak berfungsi dan dihapus atau dinonaktifkan segera setelah menginstal produk? Pada acara keamanan informasi, setiap bagian yang didedikasikan untuk SIEM mengatasi masalah ini dengan satu atau lain cara.

Mari kita mengambil kesempatan dan mencoba mencari solusi untuk masalah ini.



Paling sering, masalah utama disebut bahwa aturan korelasi pabrikan SIEM pada awalnya tidak disesuaikan dengan infrastruktur tertentu dari pelanggan tertentu.
Menganalisis masalah yang disuarakan di situs yang berbeda, orang merasa bahwa masalahnya tidak memiliki solusi. Menerapkan SIEM masih harus memperbaiki apa yang diberikan pabrikan, atau membuang semua aturan dan menulis sendiri dari awal, sementara masalah ini melekat pada semua solusi dari bagian mana pun dari kuadran Gartner.

Tanpa sadar Anda bertanya pada diri sendiri apakah semuanya benar-benar buruk dan simpul Gordian ini tidak dapat dipotong? Apakah ungkapan "Aturan korelasi yang bekerja di luar kotak" hanyalah slogan pemasaran yang tidak memerlukan biaya apa pun?

Sebuah artikel mungkin menarik bagi Anda jika:

• Anda sudah bekerja dengan beberapa jenis solusi SIEM.
• Hanya berencana untuk mengimplementasikannya.
• Kami memutuskan untuk membangun SIEM kami dengan blackjack dan korelasi berdasarkan tumpukan ELK, atau yang lainnya.

Apa yang akan artikel tentang

Dalam kerangka seri artikel ini, kami membuat daftar masalah utama yang menghambat implementasi konsep "Aturan Korelasi yang bekerja di luar kotak", dan juga mencoba menggambarkan pendekatan sistematis untuk menyelesaikannya.

Saya harus mengatakan segera bahwa artikel ini yang dapat dikarakteristikkan oleh para pakar teknis sebagai: "air", "tentang apa-apa". Semuanya begitu, tetapi tidak cukup. Sebelum berurusan dengan tugas yang sulit, saya ingin mencari tahu mengapa itu muncul dan apa solusinya memberi kita.

Untuk pemahaman yang lebih baik tentang seluruh jajaran masalah yang akan disajikan, saya akan memberikan struktur umum dari seluruh seri artikel:

• Artikel 1: Artikel ini. Mari kita bicara tentang pernyataan masalah dan mencoba memahami mengapa kita umumnya membutuhkan aturan "Aturan korelasi yang bekerja di luar kotak." Artikel itu akan bersifat ideologis dan, jika benar-benar membosankan, Anda bisa melewatkannya. Tapi, saya tidak menyarankan melakukan ini, karena dalam artikel mendatang saya akan sering merujuknya. Di sini kita akan membahas masalah utama yang menghalangi kita, dan metode untuk menyelesaikannya.
• Pasal 2: Hore! Di sinilah kita sampai pada perincian pertama dari pendekatan yang diusulkan untuk menyelesaikan masalah. Mari kita jelaskan bagaimana sistem informasi SIEM aman kita harus “melihat”. Mari kita bicara tentang apa yang seharusnya menjadi kumpulan bidang yang diperlukan untuk menormalkan peristiwa.
• Pasal 3: Kami menjelaskan peran mengkategorikan peristiwa dan bagaimana metodologi untuk menormalkan peristiwa dibangun atas dasar itu. Kami menunjukkan bagaimana acara TI berbeda dari peristiwa IS dan mengapa mereka harus memiliki prinsip kategorisasi yang berbeda. Kami memberikan contoh langsung dari pekerjaan metodologi ini.
• Pasal 4: Perhatikan dengan seksama aset yang membentuk sistem otomatis kami dan lihat bagaimana mereka memengaruhi kinerja peraturan. Kami akan memastikan bahwa itu tidak sesederhana itu bagi mereka: mereka harus diidentifikasi dan terus diperbarui.
• Pasal 5: Bahwa semuanya dimulai. Kami menggambarkan pendekatan untuk menulis aturan korelasi, berdasarkan semua yang dinyatakan dalam artikel sebelumnya.

Pernyataan masalah dan mengapa itu penting

Mari kita coba menguraikan, dengan kata-kata sederhana, tugas kita: "Saya, sebagai klien yang membeli solusi SIEM, berlangganan untuk memperbarui basis aturan dan membayar kepada pabrikan (dan kadang-kadang integrator) untuk dukungan, saya ingin segera dilengkapi dengan aturan korelasi yang ditetapkan akan berguna dalam SIEM saya. " Bagi saya, harapan yang begitu baik, tidak dibebani dengan keterbatasan teknis arsitektur atau struktural.

Dan sekarang, perhatian, mari kita asumsikan bahwa kita telah menyelesaikan semua masalah dan tugas kita telah selesai. Apa yang ini berikan pada kita?

• Pertama , kami menghemat biaya tenaga kerja spesialis kami. Sekarang mereka tidak perlu menghabiskan waktu mempelajari logika setiap aturan baru dan mengadaptasinya dengan realitas sistem otomatis tertentu.
• Kedua , kami menghemat anggaran sejak itu kami tidak meminta integrator, atau orang lain untuk menulis atau menyesuaikan aturan untuk kami dengan biaya.
• Ketiga , semua pemain pasar SIEM yang signifikan memiliki unit penelitian dan departemen yang berfokus pada analisis ancaman keamanan informasi. Penting untuk menggunakan pengalaman mereka, terutama jika kita membayarnya.
• Keempat , kami memperpendek respons kami terhadap ancaman baru. Saya tidak akan menulis tentang keabadian yang melewati antara munculnya ancaman, pengembangan aturan korelasi untuk deteksi dan penerapannya dalam produk tertentu untuk pelanggan tertentu, banyak artikel telah ditulis tentang topik ini.
• Kelima , ini membawa kita lebih dekat ke kemungkinan berbagi di antara kita sendiri aturan terpadu yang akan bekerja untuk setiap pelanggan, dalam kerangka solusi SIEM tertentu, tentu saja.

Banyak ahli teknis yang telah menemukan solusi untuk masalah ini dan membaca sampai titik ini akan segera keberatan: "Ya, tentu saja ada plus, tetapi ini secara teknis tidak layak." Secara pribadi, saya percaya bahwa tugas ini cukup "mengangkat" dan sekarang, baik di pasar barat dan Rusia, ada SIEM yang berisi semua elemen yang diperlukan untuk menyelesaikannya. Saya ingin memusatkan perhatian Anda pada hal ini - produk tidak memungkinkan Anda untuk menyelesaikan masalah, tetapi hanya berisi semua blok yang diperlukan, dari perancang, Anda dapat mengumpulkan solusi yang kami cari.

Saya pikir ini sangat penting, karena semua yang akan dijelaskan nanti dapat diimplementasikan di hampir semua SIEM yang ada dan matang.

Cukup dengan liriknya, maka kita akan berbicara lebih detail tentang masalah yang muncul dalam menyelesaikan masalah kita.

Tantangan yang kita hadapi

Dalam mencari solusi untuk masalah di atas, mari kita lihat masalah apa yang harus kita hadapi. Menyoroti masalah utama akan memungkinkan pemahaman yang lebih baik tentang masalah, serta mengembangkan pendekatan sistematis untuk menyelesaikannya.
Masalah yang kita hadapi adalah bola salju, yang masing-masing secara dramatis memperburuk situasi. Banyak dari masalah ini mengarah pada penciptaan "Aturan Korelasi yang bekerja di luar kotak" sangat sulit.

Secara umum, masalah dibagi menjadi empat blok besar berikut:

1. Hilangnya data selama normalisasi terkait dengan transformasi model "dunia".
2. Kurangnya aturan yang jelas dan diterima secara universal untuk peristiwa normalisasi.
3. "Mutasi" konstan dari objek perlindungan - sistem otomatis kami.
4. Kurangnya aturan untuk menulis aturan korelasi.

Mari sekarang kita periksa masalah ini secara lebih rinci.

Transformasi Model Dunia

Masalah ini paling mudah dijelaskan dengan menggunakan analogi berikut.
Dunia di sekitar kita beragam dan beragam, tetapi pendengaran dan penglihatan kita hanya memperbaiki spektrum radiasi yang terbatas. Setelah melihat atau mendengar semacam fenomena, kami membangun di kepala kami citra acara ini, menggunakan model terpotongnya. Misalnya, mata kita tidak melihat dalam spektrum inframerah, dan telinga tidak menangkap getaran di bawah 16 Hz. Ini adalah transformasi pertama dari fenomena asli. Itu terjadi dalam model ini bahwa imajinasi kita membawa sesuatu yang tidak ada dalam fenomena aslinya. Kita dapat memberi tahu teman bicara tentang fenomena ini menggunakan ucapan lisan dengan semua keterbatasan dan fitur-fiturnya. Ini adalah transformasi model yang kedua. Akhirnya, lawan bicara, dalam kata-kata kami, memutuskan untuk menulis tentang fenomena ini kepada rekannya di pembawa pesan. Ini adalah transformasi ketiga dan, paling mungkin, paling dramatis dari model dalam hal kehilangan informasi.


Dalam contoh yang diuraikan di atas, kami mengamati masalah klasik, di mana "model konseptual" yang asli ( Sovetov B. Ya., Yakovlev S. A., Pemodelan Sistem ) ditransformasikan melalui penyederhanaan menjadi model lain sambil kehilangan detail.
Hal yang persis sama terjadi di dunia peristiwa yang dihasilkan oleh perangkat lunak atau perangkat keras.

Penjelasan yang dapat disajikan di sini adalah gambaran yang sudah disederhanakan dari bidang subjek kami:

• Transformasi pertama model. File yang dapat dieksekusi dimuat ke dalam RAM, OS mulai menjalankan instruksi yang dijelaskan di dalamnya. Sistem operasi menyampaikan beberapa informasi tentang operasi ini ke layanan daemon / logging (auditd, eventlog, dll.). Jika Anda tidak mengaktifkan audit tindakan yang diperluas, beberapa informasi tidak termasuk daemon ini. Tetapi bahkan dalam audit yang diperpanjang, beberapa informasi masih akan dibuang, karena Pengembang OS memutuskan bahwa volume informasi seperti itu cukup untuk memahami apa yang terjadi.
• Transformasi kedua model. Dan sekarang daemon / layanan membuat sebuah acara, menulis informasi ke disk, dan di sini kita memahami bahwa panjang garis acara dapat dibatasi oleh sejumlah byte. Jika daemon / layanan memelihara log terstruktur, maka ia berisi beberapa skema acara dengan bidang-bidang tertentu. Apa yang harus dilakukan jika ada begitu banyak informasi yang tidak sesuai dengan skema “kabel”? Dengan benar, kemungkinan besar informasi ini akan dibuang begitu saja.

Sekarang apa yang tampak seperti bagian dari tugas kita.
Kami sudah memiliki model yang disederhanakan (sudah kehilangan banyak detail) dari beberapa fenomena yang diwakili oleh catatan dalam file log - suatu peristiwa. SIEM membaca acara ini, menormalkannya dengan mendistribusikan data di antara bidang skema. Jumlah bidang dalam skema yang apriori tidak dapat memuatnya sebanyak yang diperlukan untuk mencakup semua kemungkinan semantik semua peristiwa dari semua sumber, yaitu, pada langkah ini model ditransformasikan dan data hilang.


Penting untuk memahami bahwa karena masalah ini, ahli, menganalisis log dalam SIEM atau menggambarkan aturan korelasi, tidak melihat kejadian awal itu sendiri, tetapi setidaknya dua kali model terdistorsi, yang telah kehilangan banyak informasi. Dan, jika informasi yang hilang sangat penting dalam investigasi insiden dan, sebagai konsekuensi dari penulisan aturan, itu harus diambil dari suatu tempat. Adalah mungkin bagi seorang ahli untuk menemukan informasi yang hilang baik dengan merujuk pada sumber aslinya (peristiwa mentah, memori dump, dll) atau dengan memodelkan data yang hilang di kepalanya berdasarkan pengalamannya sendiri, yang secara praktis tidak mungkin untuk membuat langsung dari aturan korelasi.

Indikator yang baik untuk masalah ini adalah, jika tidak aneh, bidang-bidang seperti string perangkat Pelanggan, Datafield, atau yang lainnya. Bidang ini mewakili semacam "tempat pembuangan" tempat mereka meletakkan data yang tidak mereka ketahui di mana harus diletakkan, atau ketika semua bidang lain yang sesuai hanya dibanjiri.

Himpunan bidang taksonomi, sebagai suatu peraturan, mencerminkan model "dunia" sebagaimana pengembang SIEM melihat bidang subjek. Jika model ini sangat "sempit", maka ada sejumlah kecil bidang di dalamnya dan setelah normalisasi beberapa peristiwa mereka hanya akan terjawab. SIEM dengan kumpulan bidang yang awalnya diperbaiki dan dinamis tidak dapat diperluas sering mengalami masalah ini.

Di sisi lain, jika ada terlalu banyak bidang, masalah muncul karena kurangnya pemahaman di bidang mana Anda perlu memasukkan data tertentu dari acara asli. Situasi ini mensyaratkan kemungkinan munculnya duplikasi semantik, ketika secara semantik data yang sama dari peristiwa awal segera cocok ke beberapa bidang. Ini sering diamati dalam solusi di mana set bidang skema dapat diperluas secara dinamis oleh modul normalisasi dengan dukungan sumber baru.

Jika Anda memiliki "pertarungan" SIEM, lihatlah acara Anda. Seberapa sering selama normalisasi Anda menggunakan bidang tambahan khusus (string perangkat khusus, bidang data, dll.)? Banyak jenis acara dengan bidang tambahan yang diisi menunjukkan bahwa Anda mengamati masalah pertama. Sekarang ingat, atau tanyakan pada kolega Anda, seberapa sering dengan dukungan sumber baru mereka harus menambahkan bidang baru, karena tidak ada cukup cadangan? Jawaban untuk pertanyaan ini adalah indikator dari masalah kedua.

Metodologi Normalisasi Peristiwa

Penting untuk mengingat siapa dan bagaimana menormalkan peristiwa, karena itu memainkan peran penting. Sebagian sumber didukung langsung oleh pengembang solusi SIEM, sebagian adalah integrator yang mengimplementasikan SIEM untuk Anda, dan sebagian lagi milik Anda. Di sinilah masalah berikutnya menanti kita: Setiap peserta menafsirkan makna bidang skema acara dengan cara mereka sendiri dan oleh karena itu melakukan normalisasi dengan cara yang berbeda. Dengan demikian, peserta yang berbeda dapat menguraikan data yang identik secara semantik menjadi bidang yang berbeda. Tentu saja, ada sejumlah bidang, yang namanya tidak memungkinkan penafsiran ganda. Misalkan src_ip atau dst_ip, tetapi bahkan dengan mereka ada kesulitan. Misalnya, dalam acara jaringan, apakah perlu mengubah src_ip ke dst_ip ketika menormalkan koneksi masuk dan keluar dalam sesi yang sama?

Berdasarkan hal di atas, ada kebutuhan untuk membuat metodologi yang jelas untuk sumber-sumber pendukung, dalam kerangka yang akan ditunjukkan dengan jelas:

1. Apa bidang dari rangkaian untuk apa yang dibutuhkan.
2. Jenis data apa yang sesuai dengan bidang mana.
3. Informasi apa yang penting bagi kami dalam kerangka setiap jenis acara.
4. Apa aturan untuk mengisi kolom.

Model objek perlindungan dan mutasinya

Sebagai bagian dari solusi tugas, objek perlindungan adalah sistem otomatis kami (AS). Ya, itu adalah AU dalam definisi GOST 34.003-90 , dengan semua proses, orang, dan teknologinya. Ini adalah poin penting, kami akan kembali lagi nanti di artikel berikut.

Kata "mutasi" tidak dipilih secara kebetulan di sini. Mari kita ingat bahwa dalam mutasi biologi dipahami sebagai perubahan genom yang persisten. Apa genom AC itu? Dalam kerangka seri artikel ini, di bawah genom AS, saya akan memahami arsitektur dan strukturnya. Dan "perubahan abadi" tidak lain adalah hasil pekerjaan sehari-hari administrator sistem, insinyur jaringan, insinyur keamanan informasi. Di bawah pengaruh perubahan ini, AC berubah dari satu kondisi ke kondisi lainnya setiap menit. Beberapa negara ditandai dengan tingkat keamanan yang tinggi, beberapa lainnya kurang. Tapi, sekarang bagi kami itu tidak masalah.

Penting untuk dipahami bahwa model AC tidak statis, yang semua parameternya dijelaskan dalam dokumentasi teknis dan kerja, tetapi objek yang hidup dan terus bermutasi. SIEM, yang membangun model objek perlindungan di dalam dirinya sendiri, harus mempertimbangkan hal ini dan dapat memperbaruinya secara tepat waktu dan efisien, mengikuti laju mutasi. Dan, jika kita ingin membuat aturan korelasi “bekerja di luar kotak”, perlu bahwa mereka memperhitungkan mutasi ini dan selalu beroperasi dengan gambaran yang paling relevan dari “dunia”.

Metodologi untuk mengembangkan aturan korelasi

Dari "piramida" yang disajikan di atas , jelas bahwa ketika mengembangkan aturan korelasi, kita dipaksa untuk berjuang tentang semua masalah yang ada di tingkat yang lebih rendah. Dalam menangani masalah ini, aturan diberkahi dengan logika tambahan: pemfilteran tambahan acara, memeriksa nilai kosong, casting tipe data dan mentransformasikan data ini (misalnya, mengekstraksi nama domain dari nama pengguna domain yang sepenuhnya memenuhi syarat), mengisolasi informasi tentang siapa yang berinteraksi dengan siapa dan dengan siapa kerangka acara.

Setelah semua ini, aturan dikelilingi oleh sejumlah ekspresi tangkapan, pencarian substring dan ekspresi reguler sehingga logika pekerjaan mereka menjadi jelas hanya untuk penulis mereka dan itu, sampai liburan mereka berikutnya. Selain itu, perubahan konstan dalam sistem otomatis - mutasi memerlukan pembaruan berkala aturan terhadap penipuan. Gambar yang akrab?

Pada akhirnya

Sebagai bagian dari seri artikel ini, kami akan mencoba memahami cara membuat aturan korelasi bekerja di luar kotak.

Untuk menyelesaikan masalah kita harus menghadapi masalah-masalah berikut:

1. Kehilangan data selama transformasi model "dunia" pada tahap normalisasi.
2. Kurangnya definisi yang jelas tentang metodologi normalisasi.
3. Mutasi permanen pada objek perlindungan di bawah pengaruh orang dan proses.
4. Kurangnya metodologi untuk menulis aturan korelasi.

Banyak dari masalah ini terletak pada bidang pembangunan skema acara yang benar - seperangkat bidang dan proses normalisasi peristiwa - fondasi aturan korelasi. Bagian lain dari masalah diselesaikan dengan metode organisasi dan metodologis. Jika kami berhasil menemukan solusi untuk masalah ini, maka konsep bekerja di luar aturan kotak akan memiliki efek positif yang luas dan akan meningkatkan keahlian yang ditetapkan oleh produsen SIEM ke tingkat yang baru.

Apa selanjutnya Pada artikel berikutnya, kami akan mencoba menangani kehilangan data selama transformasi model "dunia" dan berpikir tentang bagaimana seperangkat bidang yang diperlukan untuk tugas kita akan terlihat seperti - diagram.

---

Seri artikel:

Kedalaman SIEM: korelasi out-of-box. Bagian 1: Pemasaran murni atau masalah yang tidak dapat diselesaikan? ( Artikel ini )

Kedalaman SIEM: korelasi out-of-box. Bagian 2. Skema data sebagai refleksi dari model "dunia"

Kedalaman SIEM: korelasi out-of-box. Bagian 3.1. Kategorisasi acara

Kedalaman SIEM: korelasi out-of-box. Bagian 3.2. Metodologi Normalisasi Peristiwa

Kedalaman SIEM: korelasi out-of-box. Bagian 4. Model sistem sebagai konteks aturan korelasi

Kedalaman SIEM: korelasi out-of-box. Bagian 5. Metodologi untuk mengembangkan aturan korelasi