Forum V SOC, acara terbesar tentang praktik mendeteksi dan menganalisis insiden di Rusia, akan dimulai besok. Saya yakin bahwa banyak pembaca hub ini akan ada di sana dan mendengar banyak laporan profesional di bidang keamanan informasi ini. Tetapi di samping istilah, definisi, dan praktik yang ada, yang dibahas di Forum SOC, dalam kehidupan nyata, Anda masing-masing mungkin mendengar banyak pendapat berbeda tentang fungsi SOC, perlindungan terhadap serangan APT, dll. Hari ini kita akan membahas beberapa mitos dan legenda populer.
Kami tertarik dengan pendapat Anda tentang masing-masing, jadi kami menunggu komentar Anda. Selamat datang di kucing.
Mitos 1 - SOC pada satu string, atau keajaiban menganalisis lalu lintas jaringan
Sangat sering, ketika berdiskusi dengan pelanggan perlindungan menyeluruh terhadap penyusup eksternal, kami mendengar: "Dan kami memiliki perangkat keras A, itu diperkaya oleh keahlian vendor dan informasi tentang ancaman baru, dan itu benar-benar melindungi kami dari serangan eksternal." Dan oke, jika setelah kata-kata ini kami ditunjukkan solusi Anti-APT multi-modul - akan ada pertanyaan, tetapi akan ada jauh lebih sedikit. Paling sering, di balik "perangkat universal" ini adalah IDS biasa, terkadang dengan fungsi dasar untuk menganalisis lalu lintas https. Kami tidak mempertanyakan keahlian vendor di bidang cybersecurity dan pengetahuan mereka tentang aktivitas peretas, serta kegunaan merekam dan menganalisis lalu lintas jaringan (topik ini tentu saja akan diangkat berulang kali di Forum), tetapi kami tetap ingin fokus pada keterbatasan pendekatan, dengan dimana SOC hanya berfokus pada acara-acara jaringan.
- Mari kita mulai dengan pangkalan dan beberapa sudah usang. Sejak 2013, kami telah mengamati serangan hacker yang dilakukan tanpa menggunakan malware, dan setidaknya tanpa modul untuk berinteraksi dengan server manajemen. Bagi para penyerang datang Alat Administrasi Jarak Jauh yang sah, yang dengan file konfigurasi yang benar berperilaku tidak dapat dibedakan dari pengguna yang suka bekerja dari rumah, atau pekerjaan administrator jarak jauh di perusahaan dengan tingkat kematangan TI yang rendah. Pada tingkat kejadian jaringan, sangat tidak mungkin untuk membedakan satu sesi dari yang lain, dan untuk analisis lengkap dari metode dan alasan untuk memulai sesi, informasi dari sistem akhir diperlukan.
- Jika gagasan RAT menjijikkan bagi penyerang atau tidak berlaku dalam kasus serangan tertentu, protokol https hadir untuk penyelamatan sebagai cara interaksi. Pada salinan lalu lintas, dekripsi protokol tidak dimungkinkan, oleh karena itu, sensor harus puas hanya dengan informasi tentang header paket. Ini hanya berguna ketika pusat kontrol berada di area tertentu dan dapat dihitung dengan IP. Tetapi lebih sering kita berbicara tentang layanan hosting besar atau layanan publik (kami menulis tentang meretas halaman Wordpress sebelumnya ), yang tidak memungkinkan kami untuk mengidentifikasi di mana koneksi yang sah dan di mana yang terganggu.
- Untuk semua manfaatnya, koneksi jaringan (dan kami biasanya berbicara tentang sepotong besi di area perimeter) hanya merekam hubungan antara pusat kontrol dan rantai teratas klien bot. Seringkali, penyerang saat ini menggunakan rantai server C&C proxy (tingkat pertama penangkapan infrastruktur) untuk berkomunikasi dengan klien bot internal. Pada titik ini, pembatasan lokasi peralatan tidak sepenuhnya mendeteksi serangan.
- Dengan semua ragam aksi penyerang, ia secara berkala tidak perlu datang dari Internet sama sekali. Dimungkinkan untuk berkompromi dengan akun akses jarak jauh, dan kemudian bekerja di bawah hak yang sah dari administrator atau pengguna. Semakin banyak kelompok yang menggunakan metodologi rantai pasokan, memulai serangan dengan meretas kontraktor, yang seringkali memiliki saluran statis dan tidak terkontrol dengan baik ke infrastruktur dan semua akun istimewa yang sama. Ada semakin banyak vektor setiap tahun, dan mereka semakin jauh dari pengobatan klasik.
- Secara umum, SOC bukan hanya tentang melawan peretas. Penyerang internal, pelanggaran kebijakan IS atau penipuan, mengunggah atau membahayakan data klien, dan banyak lagi, juga merupakan bagian dari pendekatan SOC yang komprehensif. Dan itu membutuhkan teknik dan alat yang jauh lebih kompleks dalam pekerjaannya.
Mitos 2 - SOC tanpa kaki, atau Bekerja tanpa baris pertama
Salah satu legenda favorit kami. Lelucon tentang SOC, di mana hanya 1 orang bekerja, jadi dia sedikit 1, 2 sedikit dan 3 sedikit garis dukungan, sudah membanjiri Internet. Tetapi banyak pelanggan, setelah mendengar banyak laporan berbeda dan membaca artikel, mulai membicarakan perlunya sepotong besi / prosedur / teknologi (garis bawah seperlunya) yang akan mengotomatisasi dan menyelesaikan semua masalah pada baris pertama. Dan karena sering berada di kepala pelanggan, jalur 1 setara dengan mode operasi 24 * 7 (semua yang lain, sebagai aturan, bekerja sesuai dengan jadwal standar), ini secara otomatis menciptakan perasaan pengurangan biaya personil yang signifikan dan menghasilkan percakapan di tombol “jalur 1 tidak diperlukan, mari kita mulai membangun dengan yang kedua. "
Masalah utama dari legenda ini, menurut pendapat kami, adalah kebingungan dalam terminologi. Seringkali, ketika pembicara berbicara tentang saluran 1, ia dipandu oleh praktik-praktik ITIL, di mana tugas atom benar-benar jatuh ke tangan operator:
- penerimaan tugas
- klasifikasi
- menambahkan konteks (aset atau sistem informasi)
- prioritisasi atau prioritas
- Pengangkatan orang yang bertanggung jawab atas sistem / pemeriksaan / antrian.
Ketika datang ke tugas semacam ini, tentu saja, tidak ada baris pertama yang berdedikasi diperlukan: proses ini, meskipun tidak mudah, sepenuhnya otomatis. Yang kami maksud dengan baris pertama, kami sudah menulis beberapa kali - misalnya di
sini ). Meski begitu, baris pertama bukanlah pengganti untuk otomatisasi, dan bahkan bukan tim yang bekerja secara eksklusif pada buku pedoman. Karyawan ini ingin tahu dan mencari, meskipun mereka hanya memiliki keterampilan dasar dalam menganalisis peristiwa dan menyelidiki insiden. Dalam istilah ITIL, garis seperti itu akan disebut ke-2, yang segera menghapus semua pertanyaan dan perbedaan.
Saya tidak ingin mengabaikan pertanyaan 24 * 7. Tentang organisasi shift, efisiensi operator dan analis di malam hari, kebutaan psikologis saat melihat peristiwa, terlalu banyak yang telah dikatakan. Kesimpulan integralnya kira-kira sama - garis SOC pertama dan shift 24 jam menjadi tidak efisien dan tidak perlu. Untuk bagian kami, selama bertahun-tahun kami juga telah mencoba metode yang berbeda, dan saat ini, tingkat federal SOC memungkinkan kami untuk meminimalkan risiko kelelahan spesialis selama shift malam (insiden kritis hanya dikirim ke zona waktu yang berbeda), namun, saya ingin mencatat beberapa poin.
- Mengurangi waktu shift untuk operator adalah ide yang sangat bagus. Bekerja pada prinsip tugas TI selama satu atau tiga hari dalam keamanan informasi agak tidak mungkin. Namun, mempertahankan fokus pada insiden sangat penting ...
- TAPI ... operator dari baris pertama tidak duduk, seperti operator dari film "The Matrix", melihat aliran peristiwa mentah untuk mencari anomali. Setidaknya dalam tidak ada SOC yang diketahui oleh kami, kami mengalami pendekatan semacam itu. Tugasnya adalah menganalisis laporan dan perburuan berkala, atau menyusun skenario untuk mengidentifikasi insiden. Dalam mode mengalihkan perhatian dan jenis kegiatan ini (dengan keseimbangan angka yang tepat di telepon), risiko kebutaan psikologis yang cepat bagi kita tampaknya minimal.
Dan sebagai kesimpulan - tidak peduli seberapa jauh otomatisasi telah berjalan, adalah kebiasaan untuk meninggalkan spesialis yang memantau situasi dengan mesin dan robot di setiap lokasi produksi kritis. Dan jika garpu Anda dalam hal ini adalah "dapat otomatisasi membantu saya untuk tidak mengalokasikan 5-6 tingkat untuk shift shift", maka jawaban kami jelas: itu tidak bisa.
Mitos 3 - SOC Sempurna tanpa istirahat, atau Kami bekerja tanpa hasil positif yang keliru
Semakin Anda membangun SOC atau bekerja dengan penyedia MSSP / MDR, semakin Anda menginginkan yang ideal. Sekarang, banyak pelanggan melalui api, air dan pipa tembaga dari pendekatan independen pertama ke proyektil atau pilot / kontrak dengan pemasok eksternal dan semua orang berusaha untuk entah bagaimana berusaha untuk yang ideal. Dan cita-cita di mata kepala / orang yang bertanggung jawab atas layanan eksternal biasanya diungkapkan dengan frasa "setiap peringatan adalah insiden yang dikonfirmasi" atau "kami tidak memantau kecurigaan - kami merekam serangan." Dan dalam hal aspek kunci efisiensi, sulit untuk berdebat dengan pernyataan itu. Tetapi, seperti biasa, iblis ada dalam rinciannya.
Sebagian besar SOC ditujukan untuk mengefisienkan analisis sedalam mungkin atas semua informasi yang tersedia. Dan mereka semakin mendekati kesempurnaan, ketika mereka memiliki kesempatan untuk menerima
kulit kayu untuknya. Mari kita periksa contoh insiden pada fakta-fakta pengoperasian indikator jaringan dari perangkat lunak virus (alamat komunikasi dengan pusat kendali) - untuk mengidentifikasi mereka, Anda hanya memerlukan beberapa informasi tentang aliran jaringan ke Internet, misalnya, log firewall, tetapi seringkali memberikan hasil yang salah. Sudah cukup bagi penyerang untuk menyembunyikan server manajemen malware-nya di hosting, dan kami akan secara otomatis menemukan sejumlah besar kesalahan positif. Untuk memfilter dan menganalisis insiden secara efektif, perlu melokalkan aktivitas pada host yang memulai (proses yang dipicu, soket terbuka, dll.). Dan ini mengarahkan kita pada kebutuhan untuk menghubungkan acara dari semua host di jaringan.
Total: agar SOC mendekati kemungkinan mengidentifikasi serangan secara eksklusif, tanpa positif palsu, kita perlu memastikan cakupan pemantauan maksimum infrastruktur - idealnya, untuk mengumpulkan SEMUA log dari SEMUA objek.
Ini membawa kita ke beberapa masalah sekaligus.
- Oposisi aktual departemen TI untuk meningkatkan tingkat audit atau memasang sistem tambahan untuk pengumpulan (untuk menghindari kejahatan, kami bahkan tidak akan menyentuh topik menghubungkan segmen ACS dan teknologi). Tes kompatibilitas, peningkatan beban pada sistem yang tidak dapat diprediksi dan faktor-faktor lain yang dapat mempengaruhi ketersediaan infrastruktur secara keseluruhan adalah pemicu putaran perang berikutnya antara TI dan keamanan informasi. Dan paling sering mereka hanya meninggalkan bintik putih besar di peta pemantauan infrastruktur dari SOC.
- Mempertahankan cakupan penuh. Tidak mungkin mengumpulkan semua log dari semua server. Misalnya, dalam sistem baru, log mungkin tidak dimasukkan. Seringkali dalam proses perubahan server, pengaturan audit pada workstation dan pembatasan akses sebagian atau seluruhnya hilang. Selain itu, pengaturan harus diperbarui ketika vektor serangan baru muncul. Semua ini menciptakan biaya operasional untuk menyediakan cakupan penuh, jauh lebih tinggi daripada risiko dari tinjauan yang tidak lengkap dengan pemantauan, dan tentu saja lebih tinggi daripada biaya potensi tanggapan positif palsu.
- Masalah ketiga membawa kita ke game DOOM lama. Karena, antara lain, cakupan penuh mengharuskan Anda memasukkan kode.
a. IDKFA - amunisi penuh dalam bentuk kapasitas server tanpa akhir untuk mengumpulkan dan menyimpan acara dan, yang jauh lebih menyedihkan dari sudut pandang ekonomi, - lisensi tanpa akhir untuk SIEM dan alat SOC lainnya.
b. IDDQD adalah tim SOC besar dan abadi yang dalam setiap insiden akan dapat menganalisis semua fitur yang jelas dan tidak langsung.
Kebetulan faktor-faktor seperti itu, tugas-tugas dan jumlah anggaran untuk keamanan informasi dianggap sebagai kasus pertemuan gajah hijau dan karenanya tidak dianggap sebagai situasi khas dalam kehidupan SOC. Jadi, mengidentifikasi hanya serangan yang dikonfirmasi (dengan semua keinginan untuk menganalisis sedalam mungkin dengan alat otomatis) adalah mimpi fantastis penjaga keamanan modern.
Alih-alih kata penutup
Kami mencoba membahas hanya mitos paling umum dari industri pembangunan SOC. Oleh karena itu, di daerah permulaan yang kompleks dari awal proses untuk memantau dan menanggapi insiden, kami menyarankan Anda untuk bersikap skeptis tentang informasi yang masuk, memverifikasi dalam sumber yang berbeda dan memaksimalkan rasa takut akan
pemalsuan penilaian yang belum dikonfirmasi.
Dan semoga the Force menyertai Anda;).