Pemantauan Keamanan Cloud. Bagian 2

Jadi, saya akan melanjutkan artikel tentang pemantauan keamanan penyedia cloud. Pada bagian pertama, saya berbicara tentang pengalaman Cisco dalam bekerja dengan layanan cloud eksternal, serta pengamatan Cisco yang kami temui ketika membangun atau mengaudit SOC pelanggan kami. Mengambil bagian pertama, sebagai contoh, tiga solusi paling populer dari Amazon, Microsoft dan Google, yang merupakan platform IaaS / PaaS, hari ini saatnya berbicara tentang pemantauan platform SaaS - Dropbox, Salesforce.com, Slack dan Apple Business Manager, dan juga tentang SIEM mana yang paling cocok untuk memantau platform cloud saat ini.

Contoh: IS pemantauan di SaaS berbasis Dropbox

Jika berdasarkan AWS, Azure atau GCP Anda dapat membuat analog hampir lengkap dari infrastruktur perusahaan Anda, hanya di cloud, yaitu layanan cloud yang melakukan satu tugas tertentu, misalnya penyimpanan file, seperti yang dilakukan Dropbox. Layanan ini telah lama melampaui penyimpanan pengguna biasa, memberikan kepada seluruh perusahaan korporatnya serangkaian mekanisme keamanan:

• identifikasi dan otentikasi pengguna
• kontrol akses file
• penghapusan data jarak jauh
• manajemen perangkat tepercaya
• integrasi dengan solusi keamanan informasi eksternal (DLP, SSO, DRM, eDiscovery, SIEM, dll.)
• logging acara keamanan.

Log Dropbox Business (yang tidak mungkin di versi Basic atau Pro) mencatat jenis-jenis peristiwa keamanan berikut:

• pengaturan perlindungan kata sandi
• upaya yang berhasil dan tidak berhasil untuk memasukkan penyimpanan file
• kontrol akses istimewa dan tindakan administrator
• mengajukan tindakan (menambah, mengedit, menghapus, mentransfer, memuat, dll.)
• koneksi ke penyimpanan file aplikasi pihak ketiga
• perangkat yang mengakses Dropbox
• tambah / hapus anggota untuk mengakses grup
• membuat folder / file yang dapat diakses secara eksternal

Anda dapat menganalisis peristiwa keamanan di Dropbox baik melalui konsol administratif Dropbox Business (tapi jangan berharap wahyu besar di dalamnya), atau menggunakan solusi pemantauan eksternal yang beroperasi dengan Dropbox Business API. Akses ke log tidak tersedia dalam tarif Dropbox Business apa pun, tetapi hanya dimulai dengan lisensi tingkat lanjut (ingat Office365, yang juga tidak memulai akses ke log dengan lisensi bisnis dasar). Seperti halnya AWS, ada baiknya menanyakan apakah SIEM Anda mendukung Dropbox? Misalnya, Splunk memiliki modul terpisah untuk bekerja dengan Dropbox, yang, berkat REST API, memungkinkan Anda untuk memantau peristiwa keamanan berikut:

• masuk
• aktivitas menambahkan / menghapus / permintaan pengguna
• aktivitas perangkat yang terhubung ke Dropbox
• aktivitas berbagi file di dalam dan di luar perusahaan
• aktivitas aplikasi
• dll.

SIEM lain tidak memiliki dukungan bawaan Dropbox - Anda harus menulis konektor sendiri.

Contoh, pemantauan IS dalam SaaS berdasarkan Slack dan Salesforce.com

Kami memahami bahwa saat ini ada sejumlah besar platform cloud yang dapat digunakan oleh bisnis untuk menyelesaikan masalah mereka dan yang ingin kami pantau dari sudut pandang keamanan mereka. Kami tidak akan terjun ke masing-masing platform ini (dan saya tidak menetapkan tugas seperti itu, hanya ingin memperhatikan secara spesifik tugas-tugas pemantauan keamanan informasi platform cloud), tetapi kami akan mencoba menyelesaikan diskusi dengan contoh platform spesifik dengan dua solusi bisnis yang lebih umum - Slack dan Salesforce.com .

Slack terintegrasi dengan 50+ alat keamanan (dari perlindungan konten dan privasi hingga pemantauan sertifikat dan kontrol akses), tetapi dari sudut pandang pemantauan berbagai peristiwa keamanan, Slack memiliki beberapa integrasi yang sudah jadi - di situs daftar ini terbatas pada Symantec CloudSOC, Cisco yang kurang dikenal. CloudLock (lebih lanjut tentang itu di bawah) dan Chronicle. Itu mungkin saja. Tetapi memiliki sertifikasi ISO 27001, SOC2 / 3, Fed-RAMP dan sejumlah lainnya, Slack tidak bisa tidak menerapkan fungsionalitas canggih untuk memantau infrastrukturnya, beberapa di antaranya tersedia untuk pelanggan. Secara khusus, menggunakan API Log Audit (hanya tersedia untuk pengguna Slack Enterprise Grid dan tidak tersedia dalam paket Gratis, Standar, Plus), Anda dapat "menarik" berbagai data dari infrastruktur Slack Anda dan memuatnya ke SIEM Anda yang terkait dengan aktivitas pengguna, tetapi tidak dengan pemantauan konten (untuk tugas-tugas ini perlu menggunakan solusi DLP atau eDiscovery khusus). Pada saat yang sama, Slack tidak memiliki mekanisme yang mirip dengan AWS GuardDuty - mengirimkan acara "apa adanya" dan tidak memberi tahu Anda apakah itu buruk atau baik, hanya Anda yang dapat menentukannya dengan menuliskan aturan korelasi Anda sendiri di SIEM Anda atau menggunakan solusi eksternal yang memiliki serangkaian pola aktivitas tanpa izin yang telah ditentukan sebelumnya di Slack (seperti, misalnya, di Cisco CloudLock).

Setiap peristiwa dalam buku catatan Slack memiliki 4 elemen kunci - tindakan, pengguna yang membuatnya (aktor), entitas yang terkait dengan acara (ruang kerja, aplikasi, pengguna, saluran, file), dan lokasi (konteks) di mana tindakan ini terjadi (ruang kerja yang terpisah atau seluruh organisasi). Secara total, Slack menangkap sekitar 70 aksi berbeda. Sebagai contoh, ini adalah bagaimana acara pendaftaran pengguna di Slack terlihat seperti:

{ "entries":[ { "id":"0123a45b-6c7d-8900-e12f-3456789gh0i1", "date_create":1521214343, "action":"user_login", "actor":{ "type":"user", "user":{ "id":"W123AB456", "name":"Charlie Parker", "email":"bird@slack.com" } }, "entity":{ "type":"user", "user":{ "id":"W123AB456", "name":"Charlie Parker", "email":"bird@slack.com" } }, "context":{ "location":{ "type":"enterprise", "id":"E1701NCCA", "name":"Birdland", "domain":"birdland" }, "ua":"Mozilla\/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.186 Safari\/537.36", "ip_address":"1.23.45.678" } } ] } 

Dengan Salesforce, situasinya serupa - menggunakan API, Anda dapat mengakses semua aktivitas pengguna di cloud CRM ini, dan khususnya peristiwa berikut:

• masuk
• logout
• unggah laporan
• Panggilan API
• URI (klik web di Salesforce Classic)
• Lightning (klik web di Lightning Experience dan aplikasi seluler Salesforce)
• Unduhan Halaman Visualforce
• Eksekusi puncak
• Dan lainnya

Selain itu, Anda dapat memantau keamanan instance Salesforce Anda dan bekerja dengan log peristiwa di konsol admin Salesforce. Anda memiliki 4 opsi:

• Memantau semua upaya akses ke portal SFDC. Halaman Riwayat Masuk menunjukkan 20.000 entri tentang memasuki portal selama 6 bulan terakhir (menunjukkan metode masuk HTTP - GET, POST, atau lainnya). Jika Anda membutuhkan cerita yang lebih panjang, maka log yang sesuai dapat diunduh dalam format .csv atau .gzip.
• Pekerjaan lapangan Pemantauan dalam CRM. Melalui konsol admin, Anda dapat melacak riwayat bekerja dengan bidang CRM cloud standar dan khusus selama 18 bulan terakhir, dan melalui API dapatkan akses ke riwayat perubahan bidang dua tahun. Anda juga dapat mengarsipkan cerita ini hingga 10 tahun dan, jika perlu, mengaksesnya.
• Memantau perubahan administrasi. Menggunakan fungsi Pengaturan Audit Trail, Anda dapat memantau lebih dari 100 tindakan semua administrator Anda (terutama jika ada beberapa) selama 180 hari terakhir.
• Pemantauan Transaksi Dengan menggunakan layanan Keamanan Transaksi, Anda dapat menangkap peristiwa Salesforce secara waktu nyata dan menerapkan pemberitahuan dan alarm kepada mereka dengan logika pemrosesan yang sesuai.

Baru-baru ini, Salesforce telah mengembangkan solusi pemantauan keamanan khusus untuk platformnya - Salesforce Shield. Ini mencakup tiga komponen - mengelola enkripsi semua informasi yang tersimpan, memantau keamanan dan penggunaan data, dan mengelola kebijakan keamanan. Dalam hal pemantauan keamanan informasi, fitur di Salesforce Shield ini mirip dengan ekstensi Azure Monitor, yang tidak hanya menampilkan acara, tetapi juga karena pemrosesan dan visualisasi yang memberi tahu Anda apa yang harus dicari. Misalnya, dapatkah Anda mencari tahu dari perangkat dan platform mana yang paling sering diakses pengguna SFDC? Atau kapan, paling sering, dan dari mana pengguna memasukkan salinan Salesforce mereka (dapatkah ini membantu mengidentifikasi titik masuk yang tidak lazim)? Siapa yang melihat informasi rahasia? Siapa yang paling sering mengunduh laporan ke komputernya? Jawaban untuk pertanyaan-pertanyaan ini dapat diperoleh dengan menggunakan 16 panel pra-instal, yang inputnya dianalisis oleh subsistem Analisis Pemantauan Acara Einstein berlisensi yang berlisensi (nama yang bagus, bukan). Dengan bantuannya, Anda juga dapat membuat model dasbor, mengunggah data ke sistem BI eksternal, dll.

Contoh: memantau keamanan informasi di iPhone dan iPad

Ups ... Dan di mana iPhone dan cloud memantau, Anda bertanya. Semuanya sederhana di sini. Misalnya, tidak ada SIEM pada saat penulisan artikel ini yang memiliki konektor ke platform Apple Business Manager (atau Apple School Manager, yang lebih dikenal di universitas AS), yang memungkinkan Anda untuk mengelola perangkat perusahaan Apple - iPhone, iPad, Mac. Untuk tugas ini, Anda dapat menggunakan salah satu solusi MDM, atau Anda dapat menggunakan Apple Business Manager (jika Anda berpartisipasi dalam Program Pendaftaran Perangkat Apple atau Program Pembelian Volume, yang tidak berlaku di Rusia). Solusi MDM dapat diinstal secara lokal dan mengintegrasikannya dengan SIEM Anda pada dasarnya mudah, sama seperti MDM cloud (misalnya, Cisco Meraki), tetapi cerita dengan Apple Business Manager memiliki warna awan yang nyata dan dalam konteks artikel ini menarik lihat bagaimana salah satu produsen TI terbesar memecahkan masalah menyediakan kemampuan untuk memantau keamanan solusi mereka.

Secara umum, dari sudut pandang inilah keputusan Apple di Rusia tidak terlalu dikenal (meskipun di Barat kita dihadapkan dengan mereka dalam proyek SOC). Oleh karena itu pendapat yang berlaku bahwa Apple adalah perusahaan konsumen murni yang belum beralih ke pelanggan korporat dalam hal integrasi ke dalam SOC mereka. Ini tidak demikian pada saat yang bersamaan. Faktanya adalah bahwa memiliki sistem perlindungan yang cukup kuat untuk iOS dan MacOS, Apple terus tetap menjadi perusahaan tertutup dan tidak sangat aktif memungkinkan pihak luar untuk informasi tentang keamanan produknya. Meskipun gambar secara bertahap berubah. Misalnya, Apple Business Manager memungkinkan Anda melihat informasi tentang aktivitas pada perangkat Apple perusahaan, yang digabungkan menjadi tiga blok informasi - acara, status, dan tanggal mulai acara (dengan tanggal akhir, sayangnya, masalah). Acara yang dikendalikan (Apple School Manager memiliki sedikit lebih banyak, tetapi mereka terkait dengan siswa / siswa) termasuk:

• Kirim email masuk baru
• Buat info masuk baru
• Email kode verifikasi baru
• Tetapkan peran
• Hapus akun
• Nonaktifkan akun
• Akun reaktif
• Tetapkan perangkat
• Batalkan penetapan perangkat
• Lepaskan perangkat
• Batalkan dan hapus server
• Tetapkan ulang dan hapus server.

Sejujurnya, tidak ada banyak informasi. Anda dapat bekerja dengannya di panel kontrol Apple Business Manager atau dengan mengunggahnya sebagai file .csv ke komputer Anda untuk analisis lebih lanjut. Saya harus mengakui bahwa orientasi utama fitur ini di Apple masih fokus pada menemukan masalah di bidang TI, daripada menangani masalah keamanan - Apple tidak memiliki pengumpulan atau analisis log otomatis. Anda bisa mendapatkan lebih banyak informasi jika Anda mengintegrasikan Apple Business Manager dengan solusi MDM apa pun - maka Anda bisa mendapatkan informasi tentang pengguna aktif, ID pengguna dan perangkat, termasuk alamat Wi-Fi, data aplikasi yang diinstal dan versinya, keberadaan pembaruan yang dihapus, operator telekomunikasi, jalur akses pribadi, fungsi “Cari iPhone” yang diaktifkan, enkripsi data, jailbreak, sertifikat yang dipasang, ketersediaan dan pengaturan ITU pribadi, pengaturan PIN saat, pengaturan jarak jauh fenomena, dll. Ini cukup untuk tugas pemantauan IS, tetapi akan membutuhkan gerakan tertentu untuk mengintegrasikan perangkat Apple perusahaan Anda ke dalam SOC Anda.

SIEM untuk pemantauan cloud

Perlu dicatat bahwa Amazon, seperti banyak cloud publik lainnya, sangat memperhatikan keamanannya, namun berfokus terutama pada mekanisme untuk mendeteksi dan mencegah ancaman yang cukup sederhana dalam infrastrukturnya, serta menyediakan akses ke berbagai peristiwa yang dapat dianalisis menggunakan keputusan eksternal. Microsoft datang paling dekat untuk menciptakan sistem untuk memantau dan menganalisis peristiwa keamanan di cloud, tetapi menggunakan solusinya akan memerlukan investasi keuangan tambahan. Jika Anda hanya menggunakan awan perusahaan ini, maka mungkin Anda dapat membatasi diri ke Pusat Keamanan Azure dengan ekstensi. Tetapi jika Anda memiliki lingkungan multi-cloud, maka ada baiknya mempertimbangkan penggunaan solusi independen - SIEM, yang, mungkin, Anda sudah gunakan untuk memantau keamanan informasi infrastruktur internal Anda. Dan di sini Anda perlu memahami bagaimana dipilih atau dipilih oleh Anda SIEM mendukung cloud yang Anda gunakan (dan berbagai layanannya) sebagai sumber data. Misalnya, Splunk, QRadar, ArcSight, ELK mendukung AWS dan ini secara langsung dinyatakan dalam dokumentasi untuk sistem pemantauan ini, tetapi RuSIEM atau PT SIEM yang sama tidak mendukung.

Harus diingat bahwa berbagai SIEM dapat mengambil data dari layanan cloud yang berbeda dengan cara yang berbeda. Ambil contoh ELK dan Amazon. Banyak layanan dan aplikasi cloud dapat meneruskan acara mereka ke bucket S3, dan Logstash kemudian dapat mengambilnya berdasarkan permintaan. AWS CloudWatch yang disebutkan sebelumnya juga dapat mengirim data ke S3, dan dapat mengalirkannya ke AWS Lambda (dan Logstash membawanya untuk dianalisis) atau dihosting di cloud ElasticSearch. Yah, tentu saja, ada aplikasi yang dapat langsung mengirim data ke ELK, melewati S3, Lambda atau CloudWatch. IBM QRadar mengumpulkan data AWD GuardDuty yang sama melalui AWS CloudWatch, log Amazon VPC Flow Logs dengan menerbitkannya di keranjang S3 diikuti dengan tangkapan di QRadar, dan data dari AWS CloudTrail baik melalui keranjang S3 atau melalui AWS CloudWatch. Bergantung pada data apa yang Anda butuhkan untuk pemantauan, pengetahuan ini dapat membantu Anda untuk tidak melakukan kesalahan fatal dengan memilih SIEM, yang setelah implementasi tidak akan dapat bekerja dengan aplikasi cloud dan layanan yang Anda butuhkan.

Terlepas dari popularitas AWS atau Azure, sejumlah SIEM tidak memiliki konektor bawaan untuk bekerja dengan Amazon dan cloud Microsoft, tetapi dimungkinkan untuk membuatnya sendiri - baik secara mandiri atau dengan bantuan pabrikan, seperti, dalam kasus PT SIEM dengan Konektor Kustom. Perlu dicatat bahwa AWS bukan contoh yang tepat untuk mendapatkan gambaran tentang bagaimana SIEM bekerja dengan cloud. AWS adalah platform bisnis cloud paling populer di dunia dan karenanya banyak produsen, termasuk yang di bidang teknologi informasi, mencoba mengintegrasikan produk mereka dengannya. Tetapi bahkan dalam kasus ini, kita harus mengakui bahwa secara umum, SIEM hari ini tidak begitu sering memungkinkan Anda untuk memantau platform cloud. Sebagai contoh, IBM QRadar hanya bekerja dengan layanan cloud berikut (tidak termasuk layanan cloud IB seperti Cisco Umbrella, Cisco Meraki, Cisco Threat Grid, dll.):

• AWS GuardDuty dan AWS CloudTrail (layanan AWS lainnya belum didukung)
• Kotak
• Cloudera
• Ms azure
• Tenaga penjualan

Daftarnya tidak terlalu panjang. Modul dasar Splunk yang sama untuk bekerja dengan cloud jauh lebih luas. Selain yang di atas untuk IBM Qradar, solusi Splunk juga mendukung:

• Office365
• Sekarang Layanan
• Amazon kinesis
• Kendur
• Jira
• Google drive
• Google cloud
• Nagios
• Aplikasi G Suite
• Docker
• Kubernetes
• dan lainnya

Harap perhatikan bahwa belum ada yang mendukung GCP.

Menggunakan Aplikasi Splunk untuk ekstensi AWS (idenya akan serupa dengan ArcSight atau QRadar), Anda dapat menerapkan, misalnya, skenario pemantauan kasus penggunaan berikut yang akan memungkinkan Anda untuk menjawab pertanyaan-pertanyaan penting dari sudut pandang keamanan informasi:

• Siapa yang menambahkan aturan ke grup keamanan yang melindungi server aplikasi kami?
• Di mana lalu lintas yang diblokir datang ke VPC?
• Apa aktivitas pengguna tertentu sebelum dan sesudah kejadian?
• Beritahu saya ketika grup keamanan memungkinkan akses dari semua port
• Grup keamanan apa yang didefinisikan tetapi tidak terkait dengan sumber daya apa pun?
• Beritahu saya kapan konsol akan diakses dari alamat IP eksternal
• Beri tahu saya ketika agen pengguna tipikal serangan web dilakukan
• Kapan sumber daya instance dilampaui oleh X%?

Beberapa SIEM yang dirancang khusus untuk jaringan perusahaan mungkin memiliki masalah arsitektur dengan awan. Minimal, Anda harus membuka serangkaian aturan untuk semua sistem cloud Anda yang mengirim log ke SIEM Anda di perimeter ITU. Masalah lain, dan yang lebih serius, adalah kenyataan bahwa memiliki konektor untuk bekerja dengan cloud tidak berarti SIEM siap untuk digunakan dalam peran ini. Jika kami memperhatikan komponen sistem pemantauan yang disebutkan di awal 6, ternyata konektor ke SIEM membantu Anda menyelesaikan dua tugas yang perlu, tetapi jelas tidak cukup - mengumpulkan dan memproses peristiwa keamanan informasi. Penyimpanan disediakan oleh SIEM sendiri, tetapi dengan analisis kami masih memiliki pertanyaan besar. Jika tipikal SIEM perusahaan memiliki rasio yang sangat berguna dan bekerja "di luar kotak" aturan korelasi dengan jumlah total aturan adalah 20 hingga 80, maka untuk memantau keamanan informasi cloud rasio ini akan berada di suatu tempat sekitar 5 hingga 95, atau bahkan kurang. Karena itu, jangan lupa bahwa kehadiran SIEM yang bekerja dengan cloud tidak semua yang diperlukan untuk memantau keamanan mereka yang sebenarnya. Anda akan membutuhkan lebih banyak upaya (belum lagi personel yang berkualifikasi) untuk menulis aturan korelasi acara untuk cloud Anda, untuk cloud Anda, serta untuk cloud dan lingkungan perusahaan (karena Anda mungkin ingin mengkorelasikan data lokasi pengguna yang terhubung ke platform cloud dengan fitur keamanan perusahaan).

Jika situasi dengan pemantauan IaaS / PaaS kurang lebih baik - jumlah sumber, volume log yang dibuat, dan jenis peristiwa cukup untuk analisisnya, maka bagi banyak SaaS ini masih menyebabkan kesulitan. Oleh karena itu, saya ingin memperhatikan kegiatan / acara berikut yang tersedia untuk pemain SaaS paling serius dan yang perlu dianalisis dalam SIEM Anda saat memantau SaaS:

• Akses Pengguna dan Administrator
  
  • Upaya masuk yang berhasil dan tidak berhasil
  • Waktu dan tempat masuk
  • Masukkan tipe dan atribut perangkat
  • Upaya masuk yang gagal diikuti oleh yang berhasil
  • Aktivitas SSO
  • Aktivitas AD
• Perilaku pengguna
  
  • Aktivitas file pengguna (mengunduh, menghapus, menyalin, mencetak, mentransfer, mengirim)
  • File "Berbagi" dengan pengguna eksternal dan internal
  • Membuat tautan terbuka / berbagi
  • Aktivitas dari perangkat seluler yang tidak sah / tidak dipercaya
  • Aktivitas jaringan
• Akses API Pihak Ketiga
  
  • Perubahan privilege API
  • Aktivitas Terkait Sertifikat OAuth
  • Aktivitas yang terkait dengan token OAuth.

Paling tidak, analisis peristiwa ini, yang, misalnya, akan diberikan oleh Salesforce.com, Box atau Dropbox, akan memungkinkan Anda untuk mengidentifikasi sejumlah besar insiden dengan data dan pengguna cloud Anda.

Bagaimana cara menjelaskan kesenjangan kemampuan memantau lingkungan perusahaan dan cloud dengan SIEM? Prevalensi awan rendah? Kami memahami bahwa ini tidak benar. Sebaliknya, pertanyaannya adalah kematangan pelanggan yang sudah siap untuk cloud, tetapi tidak siap untuk memantau keamanan mereka, seperti yang saya tulis di awal artikel. Dan tanpa ini, jumlah kasus bisnis yang diperlukan tidak direkrut dan pengembang SIEM tidak terburu-buru atas inisiatif mereka sendiri untuk mengimplementasikan dukungan cloud dalam produk mereka; terutama dalam konteks perubahan reguler dalam mekanisme kerja dan kembalinya acara keamanan dari penyedia cloud (mari kita ingat kisah AzLog dengan Azure).

Apa yang harus dilakukan ketika penyedia Anda tidak memiliki alat pemantauan

Tetapi bagaimana jika penyedia cloud Anda memiliki log, tetapi tidak memiliki alat sendiri untuk menganalisis dan memonitor mereka, SIEM Anda tidak mendukung cloud yang Anda pilih dan tidak ada cara untuk menulis konektor ke sana? Ada opsi yang memungkinkan Anda untuk menggunakan perantara khusus yang, dengan menggunakan cloud API yang ada (seharusnya), mengakses penyedia cloud Anda dan kemudian menarik log dari situ, menerapkan berbagai alat analitis kepada mereka, mengidentifikasi berbagai insiden dan penyimpangan lainnya, data yang kemudian dapat diberikan kepada SIEM Anda.

Contoh perantara seperti itu adalah Broker Keamanan Akses Cloud, solusi CASB (misalnya, Cisco CloudLock), atau beberapa Otentikasi Multi-Faktor, solusi MFA dengan kemampuan kontrol akses tingkat lanjut (misalnya, Cisco Duo). Benar, CASB atau MFA, menyelesaikan satu masalah, menambahkan yang lain - mendapatkan konsol manajemen lain, yang harus diintegrasikan ke dalam SOC Anda. Tetapi menyelesaikan masalah ini biasanya lebih sederhana. SIEM, seringkali tanpa konektor cloud, dapat bekerja dengan alat keamanan informasi, termasuk CASB dan MFA (setelah semua, ini adalah tugas utama mereka). Dalam hal ini, API dalam bantuan CASB dan MFA, yang memungkinkan Anda mengirim acara keamanan yang dikumpulkan dan dianalisis ke SIEM perusahaan dan menanamkannya dalam SOC Anda. Ternyata sistem tiga tingkat di mana SIEM, yang tidak harus berintegrasi langsung dengan cloud, menggunakan CASB / MFA untuk ini (dalam kasus di atas dengan Cisco Stealthwatch Cloud cerita yang sama).



Benar, CASB juga bukan obat mujarab. Tidak semua penyedia cloud memiliki API di platform mereka yang memungkinkan data dikirim ke SOC dan SIEM perusahaan. Biasanya atribut inilah yang membedakan keputusan perusahaan. Kadang-kadang bahkan solusi cloud populer tidak memiliki API seperti itu, seperti yang Anda lihat di awal, ketika saya menyebutkan Bitrix, “My Office” atau solusi SKB Kontur.

Contoh: Memantau Keamanan dengan Cisco CloudLock

Cisco CloudLock adalah solusi berbasis API yang terintegrasi dengan berbagai platform SaaS cloud populer yang ada, seperti G Suite, Salesforce, Office 365, Dropbox, Box, ServiceNow, Slack, Okta, dll., Serta dengan IaaS / PaaS platform seperti Salesforce dan AWS. Tidak seperti proxy CASB, solusi berbasis API memungkinkan Anda untuk bekerja dengan data yang sudah dimuat ke cloud, menganalisis lalu lintas antar-cloud, dan mengontrol akses dari perangkat perusahaan dan pribadi yang tidak dikelola dan mobile. Pada saat yang sama, Cisco CloudLock, yang secara bertahap menjadi bagian integral dari Cisco Umbrella , tidak mengganggu pekerjaan pengguna dan terhubung ke cloud yang dikendalikan karena API mereka, yang memungkinkan Anda untuk memantau pelanggaran seperti:

• menebak kata sandi
• login dari lokasi yang tidak biasa (pencurian akun)
  
  
• pelanggaran aturan untuk bekerja dengan informasi rahasia (penyimpanan di awan informasi yang seharusnya tidak ada di sana)
  
  
• malware di cloud
• kebocoran data
  
  
• pelanggaran persyaratan peraturan
• Akses dari aplikasi yang dilarang atau kedaluwarsa.
  
  

Akses ke insiden ini dimungkinkan baik dari layanan Cisco CloudLock itu sendiri, dan melalui SIEM, yang CloudLock memberikan informasi yang diperlukan melalui API yang ada. Saat ini, Cisco CloudLock dapat berintegrasi dengan Splunk, QRadar, dan Arcsight.

SOC

Jadi, kami mendapat ide tentang bagaimana pemantauan keamanan informasi bekerja di lingkungan cloud yang populer di Rusia. Sekarang Anda mengerti data apa dan bagaimana Anda dapat mengunggah ke SIEM Anda. Tetapi apakah ini berarti Anda dapat berbicara tentang sistem pemantauan cloud IS terintegrasi? Tentu saja tidak. Cukup untuk mengingat kembali bahwa menurut konsep yang populer, tetapi tidak terlalu tepat, SOC adalah kombinasi dari orang-orang, proses dan teknologi. Kami berbicara di atas hanya tentang teknologi. Waktunya telah tiba untuk berbicara sedikit tentang komponen lain.

Untuk memulainya, dunia cloud saat ini tidak memiliki favorit dan pemimpin yang jelas. Perusahaan menggunakan cloud yang berbeda untuk tugas yang berbeda. Di atas, saya memberikan contoh Cisco, yang menggunakan sekitar 700 penyedia cloud di seluruh dunia dalam aktivitasnya.Dan mereka semua berbeda, dengan pendekatan berbeda untuk memastikan keamanan informasi dan pemantauannya. Untuk mengintegrasikan semuanya ke dalam pusat pemantauan IS kami, perlu untuk melihat melampaui cara memuat data ke dalam SIEM dan membangun strategi pemantauan multi-cloud yang lengkap, yang mencakup langkah-langkah berikut:

1. , ( use case). use case Splunk. , . , , - “”. , ? use case . — , .
   
   
2. playbook' runbook', .
3. , use case, . , , . Amazon — ( , , ..), ( , , Amazon EC2 VPC) (, , ). , , .
4. , , , , .
5. , . , , Threat Intelligence, , , ( Cisco Stealthwatch Cloud), (, Amazon Web Services ), , - . .
6. , .
7. , , , - . , - osquery.
8. , (, WORM — Write Once, Read Many), (, AWS Key Management System) (, Amazon S3 Glacier).
9. , , Threat Intelligence, (, GCP Azure), . , . , , .
10. (SIEM), CASB NTA (, Cisco Stealthwatch Cloud).
    
    
11. Threat Hunting, , . , , — . .
12. .

Harus diingat bahwa beberapa komponen ini akan tumpang tindih dengan tugas pemantauan lain yang mungkin dihadapi organisasi Anda - pemantauan SLA, pemantauan ketersediaan, pemantauan kinerja aplikasi, pemantauan penggunaan untuk penagihan berikutnya, dll. Karena itu, ketika membangun sistem pemantauan keamanan informasi cloud Anda, tentukan terlebih dahulu apa yang telah dilakukan dan apa yang direncanakan akan dilakukan oleh kolega Anda dari departemen lain - Anda mungkin dapat menggunakan pencapaian atau alat yang sudah dibuat atau untuk berbagi sejumlah tugas dengan orang lain.

Sepertinya saya tidak menulis sesuatu yang spesial dan baru. Jika awalnya SOC Anda dirancang dengan benar, maka menambahkan entitas yang dikendalikan baru (baik itu cloud, ICS atau perangkat seluler) tidak boleh mengarah pada perubahan yang kuat pada dokumen dan proses yang dikembangkan sebelumnya. Ketika kami merancang atau melakukan audit SOC, kami mencoba untuk awalnya mempertimbangkan semua aspek ini dalam pekerjaan kami.

Kesimpulan

Kesimpulannya, perlu diulangi lagi bahwa pemantauan IS lingkungan cloud adalah topik yang relatif baru bahkan untuk "oldies" pasar cloud. Oleh karena itu, perubahan terus-menerus terjadi di segmen ini, dan sesuatu yang tidak mungkin hingga saat ini muncul dalam portofolio penyedia cloud. Hal yang sama berlaku untuk fungsi pemantauan IS. Terlepas dari penyedia mana yang kita bicarakan, mereka dapat memberi Anda salah satu dari beberapa opsi pemantauan:

• — .
• SIEM . , “” /.
• API, “” . .
• .
• Akses melalui perantara yang mengumpulkan data cloud yang menarik bagi Anda, memperkaya mereka dengan informasi tambahan dan menerapkan berbagai alat analitik dan algoritme, setelah itu mereka mentransfer hasil analisis ke SIEM Anda atau sistem analisis peristiwa keamanan informasi.

Kelima opsi ini berbeda dalam kompleksitas bekerja dengannya, harga dan kecepatan pemantauan dan respons. Saya tidak bisa mengatakan yang mana yang harus dipilih, karena sangat tergantung tidak hanya pada cloud mana Anda bekerja, tetapi juga apa strategi pemantauan Anda. IB. Saya hanya dapat membantu dengan daftar pertanyaan untuk diri sendiri dan penyedia cloud Anda, yang dengannya Anda memutuskan untuk "menghubungkan hidup Anda":

• Apakah Anda bekerja / berencana untuk bekerja dengan satu cloud atau dengan beberapa cloud?
• Mekanisme perlindungan apa yang ditawarkan penyedia cloud Anda? Tergantung pada apa yang dapat Anda monitor dan apa yang tidak.
• ISO 27001, Fed-RAMP, SOC2/3? , - - .
• ? .
• ? ( )?
• / ? , , .
• ? ? ? threat hunting? - Threat Intelligence?
• ? / ?
• API ?
• SIEM ? /API ( )?
• “” SIEM? use case ?
• SIEM ? — SIEM?
• SIEM CASB?
• SIEM TI- ?

Berikut adalah daftar pertanyaan singkat, jawaban yang akan memungkinkan Anda untuk mulai membangun proses pemantauan keamanan informasi lingkungan cloud yang Anda atau bisnis Anda memutuskan untuk menggunakan. Semakin cepat Anda tertarik untuk menjawab pertanyaan-pertanyaan ini, semakin murah biayanya untuk membangun sistem pemantauan dan semakin sedikit insiden akan terjadi dengan sumber daya Anda diberikan kepada penyedia cloud eksternal. Seperti yang ditunjukkan oleh pengalaman Cisco dalam membangun atau mengaudit SOC, bahkan pusat pemantauan IS paling sukses yang menangani secara efektif insiden dalam jaringan perusahaan tidak selalu memajukan kemampuan pemantauan cloud dalam arsitektur mereka, yang mengharuskan restrukturisasi. Saya berharap pengamatan dan rekomendasi yang dijelaskan dalam dua bagian ini akan membantu memastikan keamanan siber.