Ketika datang untuk memantau keamanan jaringan perusahaan atau departemen internal, banyak yang memiliki hubungan dengan pengendalian kebocoran informasi dan implementasi solusi DLP. Dan jika Anda mencoba untuk mengklarifikasi pertanyaan dan bertanya bagaimana Anda mendeteksi serangan pada jaringan internal, jawabannya biasanya akan menyebutkan sistem deteksi intrusi (IDS). Dan apa satu-satunya pilihan 10-20 tahun yang lalu, hari ini menjadi anakronisme. Ada yang lebih efektif, dan di beberapa tempat satu-satunya pilihan yang mungkin untuk memonitor jaringan internal - untuk menggunakan protokol aliran yang awalnya dirancang untuk mencari masalah jaringan (troubleshooting), tetapi akhirnya berubah menjadi alat keamanan yang sangat menarik. Kami akan berbicara tentang apa itu protokol aliran dan mana yang membantu mendeteksi serangan jaringan dengan lebih baik, di mana yang terbaik untuk menerapkan pemantauan aliran, apa yang harus dicari ketika menggunakan skema seperti itu, dan bahkan bagaimana "mengambilnya" pada peralatan domestik. sebagai bagian dari artikel ini.
Saya tidak akan memikirkan pertanyaan "Mengapa pemantauan keamanan infrastruktur internal diperlukan?" Jawabannya jelas. Tetapi jika, bagaimanapun, Anda ingin sekali lagi memastikan bahwa hari ini tidak ada tempat tanpa ini,
tonton video pendek dengan cerita tentang bagaimana Anda bisa masuk ke jaringan perusahaan yang dilindungi oleh firewall dengan 17 cara. Oleh karena itu, kami akan menganggap bahwa kami memahami bahwa pemantauan internal adalah hal yang perlu dan tetap hanya untuk memahami bagaimana hal itu dapat diatur.
Saya akan memilih tiga sumber data utama untuk memantau infrastruktur di tingkat jaringan:
- Lalu lintas "Raw", yang kami tangkap dan kirimkan untuk analisis ke sistem analisis tertentu,
- peristiwa dari perangkat jaringan yang dilaluinya lalu lintas,
- informasi lalu lintas yang diterima menggunakan salah satu protokol aliran.
Menangkap lalu lintas mentah adalah opsi paling populer di kalangan penjaga keamanan, karena secara historis muncul yang pertama. Sistem deteksi serangan berbasis jaringan konvensional (sistem deteksi serangan komersial pertama adalah NetRanger WheelR, dibeli pada tahun 1998 oleh Cisco) hanya dalam bisnis menangkap paket (dan sesi selanjutnya) yang mencari tanda tangan spesifik ("aturan yang menentukan" dalam terminologi FSTEC), memberi sinyal serangan. Tentu saja, Anda dapat menganalisis lalu lintas mentah tidak hanya menggunakan IDS, tetapi juga menggunakan alat lain (misalnya, fungsi Wireshark, tcpdum atau NBAR2 di Cisco IOS), tetapi mereka biasanya tidak memiliki basis pengetahuan yang membedakan alat keamanan informasi dari alat TI biasa.
Jadi, serang sistem deteksi. Metode tertua dan paling populer untuk mendeteksi serangan jaringan, yang cocok dengan tugasnya pada perimeter (tidak peduli apa - perusahaan, pusat data, segmen, dll.), Tetapi lolos dalam dial-up modern dan jaringan yang ditentukan perangkat lunak. Dalam kasus jaringan yang dibangun berdasarkan switch konvensional, infrastruktur sensor deteksi serangan menjadi terlalu besar - Anda harus meletakkan sensor pada setiap koneksi dengan host yang serangannya ingin Anda pantau. Setiap produsen, tentu saja, akan dengan senang hati menjual ratusan dan ribuan sensor, tetapi saya pikir anggaran Anda tidak dapat menahan biaya seperti itu. Saya dapat mengatakan bahwa bahkan di Cisco (dan kami adalah pengembang NGIPS) kami tidak dapat melakukan ini, meskipun tampaknya masalah harga ada di hadapan kami. tidak boleh berdiri - ini adalah keputusan kami sendiri. Selain itu, muncul pertanyaan, tetapi bagaimana menghubungkan sensor dalam perwujudan ini? Ke celah? Dan jika sensor itu sendiri dinonaktifkan? Membutuhkan modul bypass di sensor? Gunakan pemisah keran? Semua ini membuat solusinya lebih mahal dan membuatnya tak tertahankan bagi perusahaan dalam skala berapa pun.
Anda dapat mencoba "menggantung" sensor pada port SPAN / RSPAN / ERSPAN dan mengarahkan lalu lintas ke sana dari port yang diperlukan pada sakelar. Opsi ini menghapus sebagian masalah yang dijelaskan pada paragraf sebelumnya, tetapi memiliki masalah lain - port SPAN tidak dapat menerima sepenuhnya semua lalu lintas yang akan dikirim ke sana - ia tidak akan memiliki bandwidth yang cukup. Merengkuh sesuatu untuk dikorbankan. Entah meninggalkan bagian dari node tanpa pemantauan (maka Anda harus memprioritaskan mereka terlebih dahulu), atau rute tidak semua lalu lintas dari node, tetapi hanya tipe tertentu. Bagaimanapun, kita dapat melewati beberapa serangan. Selain itu, port SPAN dapat ditempati untuk kebutuhan lain. Akibatnya, kami harus merevisi topologi jaringan yang ada dan mungkin membuat penyesuaian untuk menutupi jaringan Anda secara maksimal dengan jumlah sensor yang Anda miliki (dan mengoordinasikan ini dengan IT).
Dan jika jaringan Anda menggunakan rute asimetris? Dan jika Anda telah mengimplementasikan atau berencana untuk memperkenalkan SDN? Dan jika Anda perlu memantau mesin atau wadah virtual yang lalu lintasnya tidak mencapai saklar fisik sama sekali? Produsen IDS tradisional tidak menyukai pertanyaan ini karena mereka tidak tahu bagaimana menjawabnya. Mungkin mereka akan mengarahkan Anda ke fakta bahwa semua teknologi modis ini hype dan Anda tidak membutuhkannya. Mungkin mereka akan berbicara tentang perlunya memulai dari yang kecil. Atau mungkin mereka akan mengatakan bahwa Anda perlu menempatkan perontok yang kuat di pusat jaringan dan mengarahkan semua lalu lintas ke sana menggunakan penyeimbang. Opsi apa pun yang ditawarkan kepada Anda, Anda perlu memahami dengan jelas berapa banyak yang cocok untuk Anda. Dan hanya setelah itu membuat keputusan untuk memilih pendekatan pemantauan keamanan informasi infrastruktur jaringan. Kembali ke paket capture, saya ingin mengatakan bahwa metode ini terus menjadi sangat populer dan penting, tetapi tujuan utamanya adalah kontrol perbatasan; batas antara organisasi Anda dan Internet, batas antara pusat data dan seluruh jaringan, batas antara ICS dan segmen perusahaan. Di tempat-tempat ini, IDS / IPS klasik masih memiliki hak untuk eksis dan melakukan tugasnya dengan baik.
Mari kita beralih ke opsi kedua. Analisis peristiwa yang diterima dari perangkat jaringan juga dapat digunakan untuk mendeteksi serangan, tetapi bukan sebagai mekanisme utama, karena hanya memungkinkan sejumlah kecil intrusi yang terdeteksi. Selain itu, beberapa reaktivitas melekat di dalamnya - serangan pertama-tama harus terjadi, kemudian harus diperbaiki oleh perangkat jaringan, yang dengan satu atau lain cara akan menandakan masalah dengan keamanan informasi. Ada beberapa cara. Ini bisa berupa syslog, RMON atau SNMP. Dua protokol terakhir untuk pemantauan jaringan dalam konteks keamanan informasi hanya diterapkan jika kita perlu mendeteksi serangan DoS pada peralatan jaringan itu sendiri, karena menggunakan RMON dan SNMP, misalnya, kita dapat memantau beban prosesor pusat perangkat atau antarmuka-nya. Ini adalah salah satu yang "termurah" (semua orang memiliki syslog atau SNMP), tetapi juga yang paling tidak efektif dari semua cara untuk memantau keamanan informasi dari infrastruktur internal - banyak serangan yang disembunyikan darinya. Tentu saja, mereka tidak boleh diabaikan dan analisis syslog yang sama membantu Anda untuk mengidentifikasi perubahan dalam konfigurasi perangkat itu sendiri secara tepat waktu, itu kompromi, tetapi tidak sangat cocok untuk mendeteksi serangan pada seluruh jaringan.
Pilihan ketiga adalah untuk menganalisis informasi tentang lalu lintas yang melewati perangkat yang mendukung salah satu dari beberapa protokol aliran. Dalam hal ini, terlepas dari protokol, infrastruktur aliran harus terdiri dari tiga komponen:
- Hasilkan atau ekspor aliran. Peran ini biasanya ditugaskan untuk router, switch, atau perangkat jaringan lain, yang, melewati lalu lintas jaringan itu sendiri, memungkinkan Anda untuk mengekstrak parameter kunci dari itu, yang kemudian ditransfer ke modul koleksi. Sebagai contoh, pada protokol Cisco Netflow didukung tidak hanya pada router dan switch, termasuk yang virtual dan industri, tetapi juga pada pengendali nirkabel, firewall dan bahkan server.
- Aliran koleksi. Mengingat bahwa dalam jaringan modern biasanya ada lebih dari satu perangkat jaringan, tugas mengumpulkan dan mengkonsolidasikan aliran muncul, yang diselesaikan dengan menggunakan apa yang disebut kolektor, yang memproses arus yang diterima dan kemudian mengirimkannya untuk dianalisis.
- Analisis aliran. Penganalisa mengambil tugas intelektual utama dan, menerapkan berbagai algoritma untuk arus, menarik kesimpulan tertentu. Misalnya, sebagai bagian dari fungsi TI, penganalisa tersebut dapat mengidentifikasi hambatan jaringan atau menganalisis profil beban lalu lintas untuk lebih mengoptimalkan jaringan. Dan untuk keamanan informasi, penganalisa seperti itu dapat mendeteksi kebocoran data, penyebaran kode jahat atau serangan DoS.
Anda tidak boleh berpikir bahwa arsitektur tiga tingkat itu terlalu rumit - semua opsi lain (kecuali, mungkin, sistem pemantauan jaringan yang bekerja dengan SNMP dan RMON) juga berfungsi sesuai dengannya. Kami memiliki generator data untuk analisis, yang merupakan perangkat jaringan atau sensor yang berdiri sendiri. Kami memiliki sistem pengumpulan alarm dan kami memiliki sistem manajemen untuk seluruh infrastruktur pemantauan. Dua komponen terakhir dapat digabungkan dalam satu node, tetapi dalam jaringan yang kurang lebih besar mereka biasanya dipisahkan oleh setidaknya dua perangkat untuk memastikan skalabilitas dan keandalan.
Berbeda dengan analisis paket, berdasarkan studi header dan data tubuh setiap paket dan sesi yang terdiri dari mereka, analisis aliran bergantung pada pengumpulan metadata tentang lalu lintas jaringan. Kapan, berapa banyak, di mana dan di mana, bagaimana ... ini adalah pertanyaan yang dijawab oleh analisis telemetri jaringan menggunakan berbagai protokol aliran. Awalnya, mereka digunakan untuk menganalisis statistik dan mencari masalah TI dalam jaringan, tetapi kemudian, dengan pengembangan mekanisme analitis, menjadi mungkin untuk menerapkannya pada telemetri yang sama dan untuk tujuan keamanan. Perlu disebutkan di sini lagi bahwa analisis aliran tidak menggantikan atau membatalkan penangkapan paket. Masing-masing metode ini memiliki bidang aplikasi sendiri. Namun dalam konteks artikel ini, analisis aliran yang paling cocok untuk memantau infrastruktur internal. Anda memiliki perangkat jaringan (dan itu tidak masalah jika mereka bekerja dalam paradigma yang ditentukan perangkat lunak atau sesuai dengan aturan statis) bahwa serangan itu tidak dapat dilewati. Ini dapat memintas sensor IDS klasik, tetapi tidak ada perangkat jaringan yang mendukung protokol aliran. Inilah keunggulan metode ini.
Di sisi lain, jika Anda memerlukan bukti untuk penegakan hukum atau tim investigasi insiden Anda sendiri, Anda tidak dapat melakukannya tanpa paket capture - telemetri jaringan bukan salinan lalu lintas yang dapat digunakan untuk mengumpulkan bukti; diperlukan untuk deteksi operasional dan pengambilan keputusan di bidang keamanan informasi. Di sisi lain, menggunakan analisis telemetri, Anda dapat “menulis” tidak semua lalu lintas jaringan (jika ada, maka Cisco terlibat dalam pusat data :-), tetapi hanya yang terlibat dalam serangan itu. Alat analisis telemetri dalam hal ini akan melengkapi mekanisme penangkapan paket tradisional, memberikan perintah untuk penangkapan dan penyimpanan selektif. Jika tidak, Anda harus memiliki infrastruktur penyimpanan kolosal.
Bayangkan sebuah jaringan beroperasi pada kecepatan 250 Mbps. Jika Anda ingin menyimpan semua volume ini, maka Anda akan memerlukan penyimpanan 31 MB untuk satu detik transfer lalu lintas, 1,8 GB untuk satu menit, 108 GB untuk satu jam, dan 2,6 TB untuk satu hari. Untuk menyimpan data harian dari jaringan dengan bandwidth 10 Gbit / s, Anda memerlukan penyimpanan 108 TB. Tetapi beberapa regulator mengharuskan Anda untuk menyimpan data keamanan selama bertahun-tahun ... Merekam "sesuai permintaan", yang membantu Anda menerapkan analisis aliran, membantu mengurangi nilai-nilai ini dengan urutan besarnya. Ngomong-ngomong, jika kita berbicara tentang rasio volume rekaman data telemetri jaringan dengan total pengambilan data, maka itu adalah sekitar 1 hingga 500. Untuk nilai yang sama di atas, penyimpanan dekripsi penuh semua lalu lintas harian masing-masing akan menjadi 5 dan 216 GB, masing-masing (Anda bahkan dapat menulis ke USB flash drive biasa) )
Jika alat analisis data jaringan mentah memiliki metode menangkap mereka yang hampir sama dengan vendor ke vendor, maka situasinya berbeda dengan analisis arus. Ada beberapa opsi untuk protokol aliran, perbedaan yang perlu Anda ketahui dalam konteks keamanan. Yang paling populer adalah protokol Netflow yang dikembangkan oleh Cisco. Ada beberapa versi protokol ini yang berbeda dalam kemampuannya dan jumlah informasi yang dicatat tentang lalu lintas. Versi saat ini adalah yang kesembilan (Netflow v9), atas dasar yang standar industri Netflow v10, juga dikenal sebagai IPFIX, dikembangkan. Saat ini, sebagian besar vendor jaringan mendukung Netflow atau IPFIX di peralatan mereka. Tetapi ada berbagai opsi lain untuk protokol aliran - sFlow, jFlow, cFlow, rFlow, NetStream, dll., Di mana sFlow lebih populer. Dialah yang paling sering didukung oleh produsen peralatan jaringan domestik karena kemudahan implementasi. Apa perbedaan utama antara Netflow, sebagai standar de facto, dan sFlow? Saya akan memilih beberapa yang utama. Pertama, Netflow memiliki bidang yang ditentukan pengguna dan bukan bidang tetap di sFlow. Dan kedua, dan ini adalah hal yang paling penting dalam kasus kami, sFlow mengumpulkan apa yang disebut sampel telemetri; tidak seperti yang dicampuri di Netflow dan IPFIX. Apa perbedaan di antara mereka?
Bayangkan Anda memutuskan untuk membaca buku "
Pusat Operasi Keamanan: Membangun, Mengoperasikan, dan Menjaga SOC Anda " oleh rekan-rekan saya - Gary MacIntyre, Joseph Muniz, dan Nadef Alfardan (Anda dapat mengunduh sebagian buku dari tautan). Anda memiliki tiga opsi untuk mencapai tujuan Anda - untuk membaca seluruh buku, menjalankannya melalui mata, berhenti di setiap halaman 10 atau 20, atau mencoba untuk menemukan menceritakan kembali konsep-konsep kunci dalam blog atau layanan seperti SmartReading. Jadi telemetri yang tidak terbaca membaca setiap "halaman" lalu lintas jaringan, yaitu menganalisis metadata untuk setiap paket. Telemetri pengambilan sampel adalah studi selektif lalu lintas dengan harapan bahwa sampel yang dipilih akan memiliki apa yang Anda butuhkan. Bergantung pada kecepatan saluran, telemetri sampel akan mengirimkan untuk analisis setiap paket ke 64, 200, 500, 1000, 2000 atau bahkan 10.000.
Dalam konteks pemantauan keamanan informasi, ini berarti bahwa telemetri sampel sangat cocok untuk mendeteksi serangan DDoS, pemindaian, dan penyebaran kode berbahaya, tetapi dapat melewatkan serangan atom atau multi-paket yang tidak termasuk dalam sampel yang dikirim untuk dianalisis. Telemetri yang tidak terampas tidak memiliki kekurangan seperti itu. Menggunakan berbagai serangan yang terdeteksi jauh lebih luas. Berikut adalah daftar singkat peristiwa yang dapat dideteksi menggunakan alat analisis telemetri jaringan.
Tentu saja, beberapa penganalisa Netflow open source tidak akan memungkinkan Anda melakukan ini, karena tugas utamanya adalah mengumpulkan telemetri dan melakukan analisis dasar tentang hal itu dari sudut pandang TI. Untuk mengidentifikasi ancaman keamanan informasi berdasarkan aliran, penting untuk melengkapi penganalisis dengan berbagai mesin dan algoritma yang akan mengidentifikasi masalah keamanan siber berdasarkan bidang standar atau kustom Netflow, memperkaya data standar dengan data eksternal dari berbagai sumber Kecerdasan Ancaman, dll.
Karena itu, jika Anda punya pilihan, maka hentikan di Netflow atau IPFIX. Tetapi bahkan jika peralatan Anda hanya bekerja dengan sFlow, seperti pabrikan dalam negeri, maka bahkan dalam hal ini Anda bisa mendapat manfaat darinya dalam konteks keamanan.
Pada musim panas 2019, saya menganalisis peluang yang dimiliki produsen perangkat keras jaringan Rusia, dan semuanya, kecuali NSG, Polygon, dan Craftway, menyatakan dukungan untuk sFlow (setidaknya Zelax, Natex, Eltex, QTech, Rusteletech).
Pertanyaan selanjutnya yang akan Anda hadapi adalah di mana menerapkan aliran dukungan untuk tujuan keamanan? Padahal, pertanyaannya tidak sepenuhnya benar. Pada peralatan modern, dukungan untuk protokol aliran hampir selalu ada. Oleh karena itu, saya akan merumuskan kembali pertanyaan secara berbeda - di mana cara paling efisien untuk mengumpulkan telemetri dari sudut pandang keamanan? Jawabannya akan sangat jelas - pada tingkat akses, di mana Anda akan melihat 100% dari semua lalu lintas, di mana Anda akan memiliki informasi terperinci tentang host (MAC, VLAN, ID antarmuka), di mana Anda bahkan dapat melacak lalu lintas P2P antar host, yang sangat penting untuk mendeteksi pemindaian dan dan penyebaran kode berbahaya. Pada tingkat kernel, Anda mungkin tidak melihat bagian dari lalu lintas, tetapi pada tingkat perimeter Anda akan melihat dengan baik jika seperempat dari semua lalu lintas jaringan Anda. Tetapi jika, karena alasan tertentu, perangkat asing ditutup di jaringan Anda yang memungkinkan penyerang untuk "masuk dan keluar," melewati perimeter, kemudian menganalisis telemetri darinya tidak akan memberi Anda apa pun. Oleh karena itu, untuk jangkauan maksimum, disarankan untuk memasukkan koleksi telemetri pada tingkat akses. Pada saat yang sama, perlu dicatat bahwa bahkan jika kita berbicara tentang virtualisasi atau wadah, dalam dukungan switch aliran virtual modern juga sering ditemukan, yang memungkinkan Anda untuk mengontrol lalu lintas di sana.
Tetapi karena saya mengangkat topik, saya perlu menjawab pertanyaan, tetapi bagaimana jika, setelah semua, peralatan, fisik atau virtual, tidak mendukung protokol aliran? Atau dimasukkannya dilarang (misalnya, di segmen industri untuk memastikan keandalan)? Atau inklusi menyebabkan penggunaan CPU yang tinggi (ini terjadi pada peralatan yang sudah ketinggalan zaman)? Untuk mengatasi masalah ini, ada sensor virtual khusus (sensor aliran), yang pada dasarnya adalah splitter biasa yang melewati lalu lintas melalui diri mereka dan mengirimkannya dalam bentuk aliran ke modul koleksi. Benar, dalam hal ini kita mendapatkan sejumlah masalah yang kita bicarakan di atas dalam kaitannya dengan alat packet capture. Artinya, Anda perlu memahami tidak hanya keunggulan teknologi analisis aliran, tetapi juga keterbatasannya.
Poin lain yang penting untuk diingat ketika berbicara tentang alat analisis aliran. Jika kita menerapkan metrik EPS (peristiwa per detik, peristiwa per detik) ke cara konvensional menghasilkan peristiwa keamanan, maka indikator ini tidak berlaku untuk analisis telemetri; diganti oleh FPS (flow per detik). Seperti dalam kasus EPS, EPS tidak dapat dihitung sebelumnya, tetapi Anda dapat memperkirakan perkiraan jumlah aliran yang dihasilkan perangkat tertentu tergantung pada tugasnya. Di Internet Anda dapat menemukan tabel dengan nilai perkiraan untuk berbagai jenis perangkat dan ketentuan perusahaan, yang akan memungkinkan Anda untuk mencari tahu lisensi yang Anda perlukan untuk alat analisis dan apa yang akan menjadi arsitektur mereka? Faktanya adalah bahwa sensor IDS dibatasi oleh bandwidth tertentu, yang akan "menarik", dan flow collector memiliki keterbatasannya sendiri, yang harus dipahami. Oleh karena itu, dalam jaringan yang besar dan terdistribusi secara geografis, biasanya ada beberapa reservoir. Ketika saya menggambarkan
bagaimana jaringan di dalam Cisco dimonitor , saya sudah mengutip jumlah kolektor kami - ada 21. Dan ini ada di jaringan yang tersebar di lima benua dan berjumlah sekitar setengah juta perangkat aktif).
Sebagai sistem pemantauan Netflow, kami menggunakan
solusi Cisco Stealthwatch kami sendiri, yang secara khusus berfokus pada pemecahan masalah keamanan. Ini memiliki banyak mesin built-in untuk mendeteksi aktivitas abnormal, mencurigakan, dan jelas berbahaya, yang memungkinkan mendeteksi berbagai ancaman - dari penambangan crypto hingga kebocoran informasi, dari penyebaran kode berbahaya hingga penipuan. Seperti kebanyakan penganalisa aliran, Stealthwatch dibangun sesuai dengan skema tiga tingkat (generator - kolektor - penganalisa), tetapi dilengkapi dengan sejumlah fitur menarik yang penting dalam konteks materi yang sedang dipertimbangkan. Pertama, ini terintegrasi dengan solusi penangkapan paket (misalnya, Cisco Security Packet Analyzer), yang memungkinkan Anda untuk merekam sesi jaringan yang dipilih untuk penyelidikan dan analisis lebih lanjut. Kedua, terutama untuk memperluas tugas keamanan, kami mengembangkan protokol khusus nvzFlow, yang memungkinkan Anda untuk "menerjemahkan" aktivitas aplikasi pada node akhir (server, workstation, dll.) Ke dalam telemetri dan mengirimkannya ke kolektor untuk analisis lebih lanjut. Jika dalam versi aslinya Stealthwatch berfungsi dengan protokol aliran apa pun (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) di tingkat jaringan, maka dukungan nvzFlow juga memungkinkan untuk korelasi data di tingkat host, dengan demikian. meningkatkan efisiensi seluruh sistem dan melihat lebih banyak serangan daripada penganalisa aliran jaringan konvensional.
Jelas bahwa berbicara tentang analisis keamanan sistem Netflow, pasar tidak terbatas pada solusi tunggal dari Cisco. Anda dapat menggunakan solusi komersial dan freeware atau shareware. Anehnya, jika saya menggunakan blog Cisco sebagai contoh solusi yang bersaing, saya akan mengatakan beberapa kata tentang bagaimana telemetri jaringan dapat dianalisis dengan menggunakan dua yang populer, sama namanya, tetapi alat yang masih berbeda - SiLK dan ELK.
SiLK adalah seperangkat alat (Sistem untuk Internet-Level Knowledge) untuk analisis lalu lintas, yang dikembangkan oleh American CERT / CC dan yang mendukung, dalam konteks artikel hari ini, Netflow (ke-5 dan ke-9, versi paling populer), IPFIX dan sFlow dan menggunakan berbagai utilitas (rwfilter, rwcount, rwflowpack, dll.) untuk melakukan berbagai operasi pada telemetri jaringan untuk mendeteksi tanda-tanda tindakan tidak sah di dalamnya. Tetapi ada beberapa poin penting yang perlu diperhatikan. SiLK adalah alat baris perintah dan melakukan analisis operasional, setiap saat Anda memasukkan perintah formulir (deteksi paket ICMP lebih besar dari 200 byte):
rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15sangat tidak nyaman. Anda dapat menggunakan iSiLK GUI, tetapi itu tidak akan membuat hidup Anda jauh lebih mudah dengan hanya menyelesaikan fungsi visualisasi, bukan pengganti analis. Dan ini adalah poin kedua. Tidak seperti solusi komersial, yang sudah memiliki basis analitik yang kuat, algoritma deteksi anomali, algoritma terkait alur kerja, dll., Dalam kasus SiLK Anda harus melakukan semua ini sendiri, yang akan mengharuskan Anda untuk menggunakan kompetensi yang sedikit berbeda daripada menggunakannya. alat yang siap digunakan. Ini buruk dan tidak buruk - ini adalah fitur dari hampir semua alat gratis yang berasal dari fakta bahwa Anda tahu apa yang harus dilakukan, dan ini hanya akan membantu Anda dalam hal ini (alat komersial kurang tergantung pada kompetensi penggunanya, meskipun juga mengasumsikan bahwa analis memahami setidaknya dasar-dasar penyelidikan dan pemantauan jaringan). Tapi kembali ke SiLK. Siklus kerja analis bersamanya adalah sebagai berikut:
- Perumusan hipotesis. Kita harus memahami apa yang akan kita cari di dalam telemetri jaringan, untuk mengetahui atribut unik yang dengannya kita akan mengidentifikasi anomali atau ancaman tertentu.
- Membangun model. Setelah merumuskan hipotesis, kami memprogramnya menggunakan Python, shell, atau alat lain yang sama yang tidak termasuk dalam SiLK.
- Pengujian. Ini adalah giliran menguji validitas hipotesis kami, yang dikonfirmasi atau disangkal menggunakan utilitas SiLK dimulai dengan 'rw', 'set', 'bag'.
- Analisis data nyata. Dalam operasi industri, SiLK membantu kami mengidentifikasi sesuatu dan analis harus menjawab pertanyaan "Apakah kami menemukan apa yang kami harapkan?", "Apakah ini sesuai dengan hipotesis kami?", "Bagaimana cara mengurangi jumlah positif palsu?", "Bagaimana cara meningkatkan tingkat pengakuan?" " dll.
- Perbaikan. Pada tahap akhir, kami meningkatkan apa yang telah dilakukan sebelumnya - membuat template, meningkatkan dan mengoptimalkan kode, merumuskan kembali dan memperbaiki hipotesis, dll.
Siklus ini akan berlaku untuk Cisco Stealthwatch yang sama, hanya lima langkah terakhir yang akan mengotomatisasi secara maksimal, mengurangi jumlah kesalahan analis dan meningkatkan kecepatan deteksi insiden. Misalnya, di SiLK, Anda dapat memperkaya statistik jaringan dengan data eksternal pada IP jahat menggunakan skrip Anda sendiri, dan di Cisco Stealthwatch, ini adalah fungsi bawaan yang segera menampilkan alarm jika ada interaksi dengan alamat IP dari daftar hitam dalam lalu lintas jaringan.
Jika kita melangkah lebih tinggi dalam piramida "berbayar" untuk perangkat lunak analisis aliran, maka SiLK yang benar-benar gratis akan diikuti oleh shareware ELK, yang terdiri dari tiga komponen utama - Elasticsearch (pengindeksan, pencarian dan analisis data), Logstash (input data / output) dan Kibana ( visualisasi). Tidak seperti SiLK, di mana Anda harus menulis semuanya sendiri, ELK sudah memiliki banyak perpustakaan / modul yang sudah jadi (ada yang dibayar, ada yang tidak) yang mengotomatiskan analisis telemetri jaringan. Misalnya, filter GeoIP di Logstash memungkinkan Anda untuk mengikat alamat IP yang diamati ke lokasi geografisnya (untuk Stealthwatch, ini adalah fungsi bawaan).
ELK juga memiliki komunitas yang cukup besar yang sedang menyelesaikan komponen yang hilang untuk solusi pemantauan ini. Misalnya, untuk bekerja dengan Netflow, IPFIX dan sFlow, Anda dapat menggunakan modul
elastiflow jika Anda tidak nyaman dengan Modul Logflow Netflow, yang hanya mendukung Netflow.
Memberikan efisiensi lebih dalam mengumpulkan aliran dan mencari di dalamnya, ELK saat ini tidak memiliki analitik bawaan yang kaya untuk mendeteksi anomali dan ancaman dalam telemetri jaringan. Artinya, mengikuti siklus hidup yang dijelaskan di atas, Anda harus secara mandiri menggambarkan model pelanggaran dan kemudian menggunakannya dalam sistem pertempuran (tidak ada model bawaan di sana).
Tentu saja, ada ekstensi yang lebih canggih untuk ELK yang sudah berisi beberapa model untuk mendeteksi anomali dalam telemetri jaringan, tetapi ekstensi tersebut membutuhkan biaya dan pertanyaannya adalah apakah game itu sepadan dengan lilin - tulis sendiri model yang sama, beli implementasinya untuk alat pemantauan Anda atau beli solusi turnkey untuk kelas Analisis Lalu Lintas Jaringan.
Secara umum, saya tidak ingin masuk ke perdebatan bahwa lebih baik menghabiskan uang dan membeli solusi turnkey untuk memantau anomali dan ancaman dalam telemetri jaringan (misalnya, Cisco Stealthwatch) atau mencari tahu sendiri dan memutar SiLK, ELK atau nfdump atau OSU Flow Tools yang sama (untuk setiap ancaman baru) ( Saya berbicara tentang dua dari mereka terakhir kali)? Setiap orang memilih untuk dirinya sendiri dan setiap orang memiliki motifnya sendiri untuk memilih salah satu dari dua opsi. Saya hanya ingin menunjukkan bahwa telemetri jaringan adalah alat yang sangat penting dalam memastikan keamanan jaringan infrastruktur internal Anda dan Anda tidak boleh mengabaikannya agar tidak mengisi kembali daftar perusahaan yang namanya disebutkan di media bersama dengan julukan “diretas”, “yang tidak memenuhi persyaratan keamanan informasi "," Tidak memikirkan keamanan data dan data pelanggannya. "
Kesimpulannya, saya ingin membuat daftar tips utama yang harus Anda ikuti ketika membangun pemantauan keamanan informasi infrastruktur internal Anda:- Jangan membatasi diri Anda hanya pada batas! Gunakan (dan pilih) infrastruktur jaringan Anda tidak hanya untuk mentransfer lalu lintas dari titik A ke titik B, tetapi juga untuk mengatasi masalah keamanan siber.
- Jelajahi mekanisme pemantauan keamanan yang ada di peralatan jaringan Anda dan gunakan mereka.
- Untuk pemantauan internal, berikan preferensi untuk analisis telemetri - ini memungkinkan Anda untuk mendeteksi hingga 80-90% dari semua insiden keamanan informasi, sambil melakukan apa yang tidak mungkin ketika menangkap paket jaringan dan menghemat ruang untuk menyimpan semua peristiwa keamanan informasi.
- Untuk memantau arus, gunakan Netflow v9 atau IPFIX - mereka memberikan lebih banyak informasi dalam konteks keamanan dan memungkinkan Anda untuk memantau tidak hanya IPv4, tetapi juga IPv6, MPLS, dll.
- flow- – . , Netflow IPFIX.
- – flow-. Netflow Generation Appliance.
- – 100% .
- , , flow- SPAN/RSPAN-.
- / / ( ).
Adapun tip terakhir, saya ingin memberikan ilustrasi, yang telah saya kutip sebelumnya. Anda tahu bahwa jika sebelumnya layanan Cisco IB hampir sepenuhnya membangun sistem pemantauan IS-nya berdasarkan pada sistem deteksi intrusi dan metode tanda tangan, sekarang mereka hanya bertanggung jawab atas 20% insiden. Lain 20% dicatat oleh sistem analisis aliran, yang menunjukkan bahwa solusi ini bukan kemauan, tetapi alat nyata dalam aktivitas layanan keamanan informasi perusahaan modern. Selain itu, Anda memiliki hal terpenting untuk implementasinya - infrastruktur jaringan, investasi yang juga dapat dilindungi dengan menetapkan fungsi pemantauan IS ke jaringan juga.
Saya sengaja tidak menyentuh topik tentang menanggapi anomali atau ancaman yang diidentifikasi dalam aliran jaringan, tetapi saya pikir sudah jelas bahwa pemantauan tidak boleh diselesaikan hanya dengan mendeteksi ancaman. Itu harus diikuti oleh respons dan lebih disukai dalam mode otomatis atau otomatis. Tetapi ini adalah topik dari bahan yang terpisah.Informasi tambahan:Ancaman.
Jika Anda lebih mudah mendengarkan semua yang ditulis di atas, maka Anda dapat menonton presentasi selama satu jam yang menjadi dasar catatan ini.