Singkatnya, saya akan mengatakan bahwa itu meniru kota yang lengkap, dan agak besar, di mana hampir semuanya ada - mulai dari bandara hingga lembaga keuangan dan taman hiburan! Ini memberi penyerang kesempatan untuk menunjukkan keterampilan meretas mereka, dan mempertahankan keterampilan mereka dalam mendeteksi dan menangkis ancaman.
Jadi, muncul pertanyaan, bagaimana kita bisa “mengamati” pertempuran ini dari sudut pandang keamanan informasi? Sebenarnya, artikel ini tentang detail konstruksi dari proses observasi seperti itu dan hasil yang kami peroleh.
Kami memahami bahwa kami tidak boleh mengganggu pengoperasian poligon, dan bahwa format acara tidak memungkinkan kami untuk terlibat dalam penyesuaian mendetail profil deteksi serangan, jadi solusi kelas NTA (NTA - Network Traffic Analytics) dipilih - ini adalah solusi yang mengidentifikasi ancaman dengan menganalisis telemetri jaringan , atau, sederhananya, profil lalu lintas jaringan. Penerapan sistem semacam itu jauh lebih sederhana dan lebih mulus daripada, misalnya, penerapan sistem deteksi dan pencegahan intrusi klasik. Hal ini disebabkan oleh fakta bahwa tidak perlu melakukan perubahan pada topologi jaringan, serta fakta bahwa inti dari sistem tersebut adalah pembelajaran mesin yang dikombinasikan dengan data intelijen ancaman. Pendekatan ini memungkinkan sistem tidak hanya dengan cepat mengidentifikasi ancaman tipikal, tetapi juga untuk "belajar" selama periode waktu tertentu,dan kemudian menggunakan pengetahuan yang diperoleh untuk mendeteksi perilaku pengguna, sistem, dan aplikasi yang tidak normal. Selain itu, sistem seperti itu, hanya dalam pendekatannya, secara signifikan tidak terlalu "berisik" dalam hal peringatan tentang semua jenis ancaman dan jauh lebih akurat dalam hal mengidentifikasi insiden nyata. Mengenai ini, saya akan mengakhiri perjalanan singkat ke topik ini, yang ingin membaca lebih lanjut tentang ini, saya menyarankan Anda untuk memperhatikan
tentang materi ini .
Awalnya, saya memutuskan untuk menggunakan produk Cisco Stealthwatch Enterprise yang terkenal, yang berhasil digunakan oleh banyak rekan saya di berbagai organisasi. Dan saya akan menelepon kolega saya di Positive untuk memberi tahu mereka berapa banyak prosesor, ruang disk, mesin virtual, dll. Yang saya butuhkan. Pada saat itu, sebuah pikiran aneh muncul - saya ingat berapa banyak sumber daya, baik manusia maupun teknis, yang dimasukkan untuk membuat poligon maya ini, dan saya pikir tidak ada yang menyangka bahwa saya akan meminta beberapa dari sumber daya ini. Di sisi lain, saya tidak ingin menyerah pada ide, dan dalam kerangka tren modern dalam keamanan informasi, saya memutuskan untuk beralih ke solusi cloud yang disebut Stealthwatch Cloud. Saya harus mengatakan bahwa solusi ini disebut cloud karena suatu alasan, karena ia dapat mengumpulkan dan menganalisis telemetri cloud pribadi,dibuat di dalam awan publik melalui antarmuka pemrograman aplikasi (API). Artinya, dengan bantuan solusi ini, saya dapat menganalisis, dari sudut pandang keamanan informasi, apa yang terjadi di dalam Amazon AWS, Microsoft Azure, Google GCP, serta kontainer Kubernetes. Tetapi sekarang saya membutuhkan aplikasi lain untuk produk ini - yaitu pemantauan jaringan pribadi. Dalam hal ini, sebuah sensor (sensor) hanya dipasang di kisi tersebut, yang mengirimkan telemetri ke konsol kontrol dan pemantauan berbasis cloud. Pada kalimat sebelumnya saya menggunakan kata "sederhana" dan sekarang saya akan mencoba mengembangkannya lebih detail.serta container Kubernetes. Tetapi sekarang saya membutuhkan aplikasi lain untuk produk ini - yaitu pemantauan jaringan pribadi. Dalam hal ini, sebuah sensor (sensor) hanya dipasang di kisi tersebut, yang mengirimkan telemetri ke konsol kontrol dan pemantauan berbasis cloud. Pada kalimat sebelumnya saya menggunakan kata "sederhana" dan sekarang saya akan mencoba mengembangkannya lebih detail.serta container Kubernetes. Tetapi sekarang saya membutuhkan aplikasi lain untuk produk ini - yaitu pemantauan jaringan pribadi. Dalam hal ini, sebuah sensor (sensor) hanya dipasang di grid seperti itu, yang mengirimkan telemetri ke konsol kontrol dan pemantauan berbasis cloud. Pada kalimat sebelumnya saya menggunakan kata "sederhana" dan sekarang saya akan mencoba mengembangkannya lebih detail.
Jadi seperti apa prosesnya?
Anda perlu meminta uji coba, ini membutuhkan beberapa menit.
Tautkan di sini .
Kemudian, dalam beberapa hari, berbagai surat berguna mulai berdatangan dan pada akhirnya muncul surat yang portal tersebut diaktifkan!
Setelah itu, Anda mendapatkan portal pribadi, tautan yang terlihat seperti ini:
cisco-YOUR_CISCO_USERNAME.obsrvbl.com , misalnya: cisco-mkader.obsrvbl.com .
Masuk ke sana, kita melihat layar utama, dari mana Anda dapat mengunduh mesin virtual sensor untuk memantau jaringan pribadi. Persyaratan untuk mesin virtual ini tidak bagus - 2 vCPU, memori 2 gigabyte, dan ruang disk 32 gigabyte. Secara umum, proses instalasi sangat sederhana dan dijelaskan dalam manual yang sangat sederhana dan nyaman, dibuat dalam bentuk e-book yang dapat digulir .
Saya harus segera mengatakan bahwa sensor memiliki dua antarmuka - satu berfungsi untuk komunikasi dengan konsol kontrol dan juga mengumpulkan telemetri pada dirinya sendiri, misalnya, NetFlow, dan pada saat yang sama memonitor semua lalu lintas yang datang ke sana. Yang kedua dapat bekerja dalam mode menangkap paket (mode promiscuous) dan menghasilkan telemetri pada lalu lintas yang ditangkapnya. Dalam kasus khusus kami, kami hanya menggunakan antarmuka pertama.
Setelah pemasangan, sensor berjalan ke cloud tempat konsol berada - ini sebenarnya adalah AWS dan menghasilkan pesan yang indah:
{"error":"unknown identity","identity":"185.190.117.34"}
Ini adalah alamat IP yang sama di mana sensor berpikir bahwa ia melihat dirinya sendiri di dunia luar, menerobos firewall perusahaan, terjemahan alamat, dll. Untuk berjaga-jaga, saya akan langsung mengatakan bahwa sensor memerlukan HTTP dan HTTP, serta menyiapkan DNS Sebuah. Setelah menerima pesan di atas, Anda hanya perlu mengambil alamat ini dan menambahkannya ke daftar sensor Anda di konsol:
Dan setelah beberapa saat sensor berubah menjadi hijau - ini berarti sensor telah membuat sambungan ke konsol.
Dan, secara umum, peluncuran sistem selesai pada ini. Langkah selanjutnya adalah menambahkan sumber telemetri, selain sensor itu sendiri yang mendengarkan. Jika kami ingin menerima telemetri melalui protokol NetFlow, situs tersebut sangat berguna .
Di atasnya, kita dapat memilih perangkat jaringan yang kita butuhkan, memasukkan beberapa parameter dan mendapatkan konfigurasi siap pakai:
Dan salin informasi yang diterima ke perangkat jaringan kita. Selesai - sistem siap digunakan! Sebaliknya, itu bahkan sudah mulai bekerja.
Omong-omong, contoh pengaturan Netflow dari situs ini tidak hanya dapat digunakan untuk Steathwatch, tetapi untuk produk lain yang dapat menggunakan telemetri tersebut - misalnya, Cisco Tetration, IBM QRadar, dll.
Sekarang Anda dapat melakukan fine tuning pada sistem. Saya ingin langsung mengatakan bahwa saya sangat suka menonton bagaimana berbagai produk keamanan informasi Cisco memberi tahu saya tentang segala hal yang terjadi pada satu konsol pemantauan dan respons Cisco SecureX. Faktanya, SecureX adalah hal yang sangat menarik dan membutuhkan penjelasan tersendiri. Singkatnya, ini adalah sistem pemantauan keamanan informasi (SIEM) berbasis cloud, investigasi (Berburu Ancaman), investigasi dan respons terhadap insiden, dan pada saat yang sama proses otomatisasi (SOAR). Saya sangat menyarankan Anda untuk membiasakan diri dengan sistem ini lebih detail, dan sistem ini "terpasang" secara default ke produk keamanan informasi Cisco. Nah, sedikit pemasaran tentang topik ini di sini .
Jadi, pertama-tama, saya menyiapkan integrasi ini:
Pada saat yang sama, saya menyiapkan integrasi dengan platform cloud kami untuk menyediakan layanan keamanan Cisco Umbrella: https://habr.com/ru/company/jetinfosystems/blog/529174/ .
Saya tidak menaruh harapan khusus padanya, percaya bahwa semua hal paling menarik akan terjadi di dalam TPA, dan bukan tugas saya untuk melindungi TPA ini.
Setelah itu saya membuat sendiri konsol pemantauan baru di SecureX. Semua ini memakan waktu total 5 menit, dan bahkan mungkin kurang. Beberapa gambar dari SecureX saya di bawah ini:
Setelah itu, saya memutuskan untuk mematikan notifikasi yang tidak menarik bagi saya, dan mengaktifkan notifikasi yang menarik. Untuk melakukan ini, saya kembali ke konsol SWC dan menyiapkan pemberitahuan yang sama ini:
Saya akan langsung mengatakan bahwa untuk setiap pemberitahuan Anda dapat melihat apa itu, berapa hari pengumpulan informasi telemetrik diperlukan untuk mendeteksi ancaman yang sesuai, dan bagaimana kelanjutannya jika turun, untuk MITRE ATT & CK.
Jumlah ancaman yang terdeteksi dan pemberitahuan terkait terus bertambah seiring dengan berkembangnya solusi itu sendiri. Tetapi saya tidak benar-benar perlu memikirkannya - cloud, saat mereka menambahkan sesuatu yang baru, segera siap membantu saya.
Saya menonaktifkan sebagian besar notifikasi yang terkait dengan serangan di AWS, Azure, awan GCP, karena tidak digunakan dalam poligon ini, dan mengaktifkan semua notifikasi yang terkait dengan serangan pada jaringan pribadi.
Selain itu, saya dapat mengelola kebijakan pemantauan untuk subnet berbeda yang ingin saya kontrol. Anda dapat mengaktifkan pemantauan secara terpisah untuk negara-negara yang kami minati:
Pada tahap ini saya membaca teks saya di atas dan menyadari bahwa menulisnya membutuhkan waktu lebih lama daripada waktu yang diperlukan untuk mengonfigurasi sistem, termasuk semua integrasi.
Sekarang apa yang telah kita lihat?
Pada hari-hari awal Standoff, telemetri diberikan kepada saya oleh beberapa firewall ASAv virtual kami, tetapi jumlah sumbernya sedikit meningkat - lebih banyak firewall ditambahkan, serta Netflow dari broker lalu lintas pusat.
Pemberitahuan pertama datang dengan sangat cepat dan, seperti yang Anda harapkan, pemberitahuan tersebut dikaitkan dengan banyak pemindaian. Nah, jadi lebih menarik untuk melihat prosesnya setiap jam. Saya tidak akan menjelaskan keseluruhan proses observasi di sini, tetapi hanya memberi tahu Anda tentang beberapa fakta. Pertama, kami berhasil mengumpulkan informasi yang baik tentang apa yang ada di lokasi pengujian:
Kedua, untuk menilai skala acara - dengan negara mana yang pertukaran lalu lintas paling aktif:
Sebenarnya, ada format yang lebih nyaman untuk menyajikan data ini, tetapi di sini saya memutuskan untuk menampilkan lebih detail.
Jadi, "eksternal" utama, selain Rusia, pengguna TPA adalah AS, Jerman, Belanda, Irlandia, Inggris, Prancis, Finlandia, Kanada, meskipun ada beberapa interaksi dengan hampir semua negara, termasuk negara-negara Amerika Selatan, Afrika dan Australia:
Tentu saja, kami dapat melihat siapa yang memiliki alamat yang mereka lihat:
Dan, jika diinginkan, tanyakan tentang mereka dari sumber analitis berguna lainnya:
Apa yang memungkinkan kami untuk melihat, misalnya, interaksi aktif dengan sumber daya Microsoft di banyak negara.
Selain itu, tabel interaksi yang paling aktif juga dapat dilihat dalam bentuk gambar koneksi yang dinamis dengan kemungkinan analisis yang lebih detail:
Tapi apa yang telah kita kumpulkan sebenarnya dari sudut pandang serangan?
Daftar pemberitahuan memberitahu kami tentang hal ini, beberapa di antaranya Anda lihat di bawah ini:
Secara total, 117 serangan diidentifikasi, dikonfirmasi oleh banyak pengamatan (Observables) Kami melihat pemindaian jaringan di sini, sesi panjang yang mencurigakan, masalah dengan SMB, penggunaan port dan layanan jaringan yang salah, perilaku aneh node jaringan, perubahan tak terduga dalam perilaku mereka dan keanehan lain yang harus mengingatkan spesialis keamanan informasi.
Untuk setiap peristiwa yang menarik bagi kami, kami dapat menerima informasi rinci, termasuk apa itu, apa yang buruk dan rekomendasi untuk pencegahan. Beberapa peristiwa menarik seperti itu dapat dilihat di bawah - peluncuran server SSH yang tidak terduga pada workstation Windows dan penggunaan rentang port non-standar. Anda juga dapat memperhatikan fakta bahwa, dengan integrasi yang dikonfigurasi, Anda dapat langsung dari deskripsi acara ke konsol investigasi SecureX Treat Response untuk analisis mendetail tentang insiden ini:
Jadi, beberapa kesimpulan singkat berdasarkan hasil dari uji coba kecil dan menghibur ini.
Pertama, Positive Technologies melakukan latihan dunia maya yang sangat baik dan sangat menarik untuk mengamatinya sedikit "dari dalam", dan itu nyaman, mudah dan sederhana.
Yang kedua, yang harus saya katakan, solusi keamanan cloud cepat, sederhana, dan nyaman. Dan jika masih banyak dan Anda dapat mengatur integrasi di antara mereka - terlebih lagi, ini sangat efektif.
Ketiga, peserta uji situs juga aktif menggunakan layanan cloud, misalnya layanan dari Microsoft.
Keempat, analisis mesin otomatis dari berbagai telemetri jaringan memudahkan untuk mengidentifikasi insiden keamanan informasi, termasuk aktivitas penyusup yang direncanakan. Dan saya menyarankan Anda untuk memperhatikan fakta bahwa sudah ada banyak skenario yang dikembangkan dengan baik untuk penggunaan yang efektif dari solusi Cisco Stealthwatch untuk kebutuhan keamanan informasi. Setiap pembaca dapat menemukan naskah yang mereka sukai di sini .
Nah, dan komentar terakhir kecil - dalam artikel ini saya sengaja tidak mencantumkan daftar alamat IP, domain, detail interaksi, dll. Yang diterima secara mendetail, menyadari berapa banyak upaya yang dilakukan oleh Teknologi Positif untuk menyusun poligon ini dan berharap itu akan berguna bagi mereka berkali-kali dan kami di masa depan. Dan kami tidak akan membuat hidup lebih mudah bagi penyerang di masa depan.