🥇Pemantauan keamanan cloud

Memindahkan data dan aplikasi ke cloud menghadirkan tantangan baru bagi SOC korporat, yang tidak selalu siap memantau infrastruktur orang lain. Menurut Netoskope, rata-rata perusahaan (tampaknya di AS) menggunakan 1246 layanan cloud yang berbeda, 22% lebih banyak dibandingkan tahun lalu. 1246 layanan awan!!! 175 di antaranya terkait dengan layanan SDM, 170 terkait dengan pemasaran, 110 di bidang komunikasi, dan 76 di bidang keuangan dan CRM. Cisco “hanya” menggunakan 700 layanan cloud eksternal. Jadi saya sedikit bingung dengan angka-angka ini. Namun bagaimanapun juga, masalahnya bukan pada mereka, tetapi pada fakta bahwa cloud mulai digunakan secara aktif oleh semakin banyak perusahaan yang ingin memiliki kemampuan yang sama untuk memantau infrastruktur cloud seperti di jaringan mereka sendiri. Dan tren ini terus berkembang - menurut menurut Kamar Akun Amerika Pada tahun 2023, 1200 pusat data akan ditutup di Amerika Serikat (6250 sudah ditutup). Namun transisi ke cloud bukan sekadar “mari kita pindahkan server kita ke penyedia eksternal.” Arsitektur TI baru, perangkat lunak baru, proses baru, batasan baru... Semua ini membawa perubahan signifikan tidak hanya pada pekerjaan TI, tetapi juga keamanan informasi. Dan jika penyedia telah belajar bagaimana cara mengatasi keamanan cloud itu sendiri (untungnya ada banyak rekomendasi), maka dengan pemantauan keamanan informasi cloud, terutama pada platform SaaS, terdapat kesulitan yang signifikan, yang akan kita bicarakan.

Katakanlah perusahaan Anda telah memindahkan sebagian infrastrukturnya ke cloud... Berhenti. Tidak dengan cara ini. Jika infrastruktur sudah dialihkan, dan Anda baru memikirkan bagaimana cara memantaunya, maka Anda sudah rugi. Kecuali Amazon, Google, atau Microsoft (dan dengan reservasi), Anda mungkin tidak memiliki banyak kemampuan untuk memantau data dan aplikasi Anda. Ada baiknya jika Anda diberi kesempatan untuk bekerja dengan log. Terkadang data peristiwa keamanan akan tersedia, namun Anda tidak memiliki akses ke data tersebut. Misalnya, Office 365. Jika Anda memiliki lisensi E1 termurah, peristiwa keamanan tidak tersedia untuk Anda sama sekali. Jika Anda memiliki lisensi E3, data Anda hanya disimpan selama 90 hari, dan hanya jika Anda memiliki lisensi E5, durasi log tersedia selama satu tahun (namun, ini juga memiliki nuansa tersendiri terkait dengan kebutuhan untuk secara terpisah meminta sejumlah fungsi untuk bekerja dengan log dari dukungan Microsoft). Omong-omong, lisensi E3 jauh lebih lemah dalam hal fungsi pemantauan dibandingkan Exchange korporat. Untuk mencapai tingkat yang sama, Anda memerlukan lisensi E5 atau lisensi Kepatuhan Lanjutan tambahan, yang mungkin memerlukan biaya tambahan yang tidak diperhitungkan dalam model keuangan Anda untuk berpindah ke infrastruktur cloud. Dan ini hanyalah salah satu contoh meremehkan masalah terkait pemantauan keamanan informasi cloud. Dalam artikel ini, tanpa berpura-pura lengkap, saya ingin menarik perhatian pada beberapa nuansa yang harus dipertimbangkan ketika memilih penyedia cloud dari sudut pandang keamanan. Dan di akhir artikel akan diberikan checklist yang layak untuk diselesaikan sebelum mempertimbangkan bahwa masalah pemantauan keamanan informasi cloud telah teratasi.

Ada beberapa masalah umum yang menyebabkan insiden di lingkungan cloud, sehingga layanan keamanan informasi tidak punya waktu untuk merespons atau tidak melihatnya sama sekali:

Log keamanan tidak ada. Ini adalah situasi yang cukup umum, terutama di kalangan pemain pemula di pasar solusi cloud. Namun Anda tidak boleh langsung menyerah. Pemain kecil, terutama pemain domestik, lebih peka terhadap kebutuhan pelanggan dan dapat dengan cepat menerapkan beberapa fungsi yang diperlukan dengan mengubah peta jalan yang disetujui untuk produk mereka. Ya, ini bukan analog dari GuardDuty dari Amazon atau modul “Perlindungan Proaktif” dari Bitrix, tapi setidaknya sesuatu.
Keamanan informasi tidak mengetahui di mana log disimpan atau tidak ada akses ke sana. Di sini perlu untuk melakukan negosiasi dengan penyedia layanan cloud - mungkin dia akan memberikan informasi tersebut jika dia menganggap klien penting baginya. Namun secara umum, tidak baik jika akses terhadap log diberikan “melalui keputusan khusus”.
Penyedia cloud juga memiliki log, tetapi mereka menyediakan pemantauan terbatas dan pencatatan peristiwa, yang tidak cukup untuk mendeteksi semua insiden. Misalnya, Anda mungkin hanya menerima log perubahan di situs web atau log upaya autentikasi pengguna, namun tidak menerima peristiwa lain, seperti lalu lintas jaringan, yang akan menyembunyikan dari Anda seluruh lapisan peristiwa yang menjadi ciri upaya meretas infrastruktur cloud Anda.
Ada log, tetapi akses ke dalamnya sulit untuk diotomatisasi, sehingga memaksanya untuk dipantau tidak terus menerus, tetapi sesuai jadwal. Dan jika Anda tidak dapat mengunduh log secara otomatis, mengunduh log, misalnya, dalam format Excel (seperti sejumlah penyedia solusi cloud domestik), bahkan dapat menyebabkan keengganan layanan keamanan informasi perusahaan untuk mengotak-atiknya.
Tidak ada pemantauan log. Ini mungkin alasan paling tidak jelas atas terjadinya insiden keamanan informasi di lingkungan cloud. Tampaknya ada log, dan dimungkinkan untuk mengotomatiskan akses ke sana, tetapi tidak ada yang melakukan ini. Mengapa?

Konsep keamanan cloud bersama

Transisi ke cloud selalu merupakan pencarian keseimbangan antara keinginan untuk mempertahankan kendali atas infrastruktur dan mentransfernya ke tangan yang lebih profesional dari penyedia cloud yang berspesialisasi dalam memeliharanya. Dan di bidang keamanan cloud, keseimbangan ini juga harus diupayakan. Selain itu, bergantung pada model penyampaian layanan cloud yang digunakan (IaaS, PaaS, SaaS), keseimbangan ini akan berbeda setiap saat. Bagaimanapun, kita harus ingat bahwa semua penyedia cloud saat ini mengikuti apa yang disebut model tanggung jawab bersama dan keamanan informasi bersama. Cloud bertanggung jawab untuk beberapa hal, dan untuk hal lain klien bertanggung jawab, menempatkan datanya, aplikasinya, mesin virtualnya, dan sumber daya lainnya di cloud. Adalah tindakan yang gegabah jika berharap bahwa dengan beralih ke cloud, kita akan mengalihkan semua tanggung jawab kepada penyedia layanan. Namun juga tidak bijaksana untuk membangun sendiri semua keamanan saat berpindah ke cloud. Diperlukan keseimbangan, yang bergantung pada banyak faktor: - strategi manajemen risiko, model ancaman, mekanisme keamanan yang tersedia untuk penyedia cloud, undang-undang, dll.

Misalnya, klasifikasi data yang dihosting di cloud selalu menjadi tanggung jawab pelanggan. Penyedia cloud atau penyedia layanan eksternal hanya dapat membantunya dengan alat yang akan membantu menandai data di cloud, mengidentifikasi pelanggaran, menghapus data yang melanggar hukum, atau menyamarkannya menggunakan satu metode atau lainnya. Di sisi lain, keamanan fisik selalu menjadi tanggung jawab penyedia cloud, yang tidak dapat dibagikan kepada klien. Namun segala sesuatu yang berhubungan antara data dan infrastruktur fisik justru menjadi bahan diskusi dalam artikel ini. Misalnya, ketersediaan cloud adalah tanggung jawab penyedia, dan menyiapkan aturan firewall atau mengaktifkan enkripsi adalah tanggung jawab klien. Pada artikel ini kami akan mencoba melihat mekanisme pemantauan keamanan informasi apa yang saat ini disediakan oleh berbagai penyedia cloud populer di Rusia, apa saja fitur penggunaannya, dan kapan sebaiknya mencari solusi overlay eksternal (misalnya, Cisco E- Keamanan email) yang memperluas kemampuan cloud Anda dalam hal keamanan siber. Dalam beberapa kasus, terutama jika Anda mengikuti strategi multi-cloud, Anda tidak punya pilihan selain menggunakan solusi pemantauan keamanan informasi eksternal di beberapa lingkungan cloud sekaligus (misalnya, Cisco CloudLock atau Cisco Stealthwatch Cloud). Nah, dalam beberapa kasus Anda akan menyadari bahwa penyedia cloud yang Anda pilih (atau dikenakan pada Anda) tidak menawarkan kemampuan pemantauan keamanan informasi sama sekali. Ini tidak menyenangkan, tetapi juga tidak sedikit, karena memungkinkan Anda menilai secara memadai tingkat risiko yang terkait dengan bekerja dengan cloud ini.

Siklus Hidup Pemantauan Keamanan Cloud

Untuk memantau keamanan cloud yang Anda gunakan, Anda hanya memiliki tiga pilihan:

mengandalkan alat yang disediakan oleh penyedia cloud Anda,
menggunakan solusi dari pihak ketiga yang akan memantau platform IaaS, PaaS atau SaaS yang Anda gunakan,
membangun infrastruktur pemantauan lingkungan cloud Anda sendiri (hanya untuk platform IaaS/PaaS).

Mari kita lihat fitur apa saja yang dimiliki masing-masing opsi ini. Namun pertama-tama, kita perlu memahami kerangka umum yang akan digunakan saat memantau platform cloud. Saya akan menyoroti 6 komponen utama dari proses pemantauan keamanan informasi di cloud:

Persiapan infrastruktur. Menentukan aplikasi dan infrastruktur yang diperlukan untuk mengumpulkan peristiwa penting untuk keamanan informasi ke dalam penyimpanan.
Koleksi. Pada tahap ini, peristiwa keamanan dikumpulkan dari berbagai sumber untuk transmisi selanjutnya untuk pemrosesan, penyimpanan, dan analisis.
Perlakuan. Pada tahap ini, data diubah dan diperkaya untuk memudahkan analisis selanjutnya.
Penyimpanan. Komponen ini bertanggung jawab atas penyimpanan jangka pendek dan jangka panjang dari kumpulan data yang telah diproses dan mentah.
Analisis. Pada tahap ini, Anda memiliki kemampuan untuk mendeteksi insiden dan meresponsnya secara otomatis atau manual.
Pelaporan. Tahap ini membantu merumuskan indikator utama bagi pemangku kepentingan (manajemen, auditor, penyedia cloud, klien, dll.) yang membantu kita mengambil keputusan tertentu, misalnya mengganti penyedia atau memperkuat keamanan informasi.

Memahami komponen-komponen ini akan memungkinkan Anda dengan cepat memutuskan di masa depan apa yang dapat Anda ambil dari penyedia Anda, dan apa yang harus Anda lakukan sendiri atau dengan keterlibatan konsultan eksternal.

Layanan cloud bawaan

Saya sudah menulis di atas bahwa banyak layanan cloud saat ini tidak menyediakan kemampuan pemantauan keamanan informasi apa pun. Pada umumnya mereka kurang memperhatikan topik keamanan informasi. Misalnya, salah satu layanan populer Rusia untuk mengirim laporan ke lembaga pemerintah melalui Internet (saya tidak akan menyebutkan namanya secara spesifik). Seluruh bagian tentang keamanan layanan ini berkisar pada penggunaan CIPF bersertifikat. Bagian keamanan informasi dari layanan cloud domestik lainnya untuk manajemen dokumen elektronik juga demikian. Ini berbicara tentang sertifikat kunci publik, kriptografi bersertifikat, menghilangkan kerentanan web, perlindungan terhadap serangan DDoS, penggunaan firewall, pencadangan, dan bahkan audit keamanan informasi rutin. Namun tidak ada sepatah kata pun tentang pemantauan, atau tentang kemungkinan mendapatkan akses ke peristiwa keamanan informasi yang mungkin menarik bagi klien penyedia layanan ini.

Secara umum, dari cara penyedia cloud menjelaskan masalah keamanan informasi di situs webnya dan dalam dokumentasinya, Anda dapat memahami betapa seriusnya mereka menangani masalah ini. Misalnya, jika Anda membaca manual untuk produk “My Office”, tidak ada kata tentang keamanan sama sekali, tetapi dalam dokumentasi untuk produk terpisah “My Office. KS3”, dirancang untuk melindungi dari akses yang tidak sah, terdapat daftar poin biasa dari urutan ke-17 FSTEC, yang diimplementasikan oleh “My Office.KS3”, tetapi tidak dijelaskan bagaimana cara mengimplementasikannya dan, yang paling penting, bagaimana caranya mengintegrasikan mekanisme ini dengan keamanan informasi perusahaan. Mungkin dokumentasi seperti itu ada, tetapi saya tidak menemukannya di domain publik, di situs web “Kantor Saya”. Meskipun mungkin saya tidak memiliki akses ke informasi rahasia ini?..

Bagi Bitrix, situasinya jauh lebih baik. Dokumentasi tersebut menjelaskan format log peristiwa dan, yang menarik, log intrusi, yang berisi peristiwa terkait potensi ancaman terhadap platform cloud. Dari sana Anda dapat mengeluarkan IP, nama pengguna atau tamu, sumber acara, waktu, Agen Pengguna, jenis acara, dll. Benar, Anda dapat bekerja dengan peristiwa ini baik dari panel kontrol cloud itu sendiri, atau mengunggah data dalam format MS Excel. Sekarang sulit untuk mengotomatiskan pekerjaan dengan log Bitrix dan Anda harus melakukan beberapa pekerjaan secara manual (mengunggah laporan dan memuatnya ke SIEM Anda). Namun jika kita ingat bahwa sampai saat ini peluang seperti itu belum ada, maka ini merupakan kemajuan besar. Pada saat yang sama, saya ingin mencatat bahwa banyak penyedia cloud asing menawarkan fungsi serupa "untuk pemula" - baik melihat log dengan mata Anda melalui panel kontrol, atau mengunggah data ke diri Anda sendiri (namun, sebagian besar mengunggah data dalam format . format csv, bukan Excel).

Tanpa mempertimbangkan opsi tanpa pencatatan, penyedia cloud biasanya menawarkan tiga opsi untuk memantau peristiwa keamanan - dasbor, pengunggahan data, dan akses API. Yang pertama tampaknya menyelesaikan banyak masalah bagi Anda, tetapi ini tidak sepenuhnya benar - jika Anda memiliki beberapa majalah, Anda harus beralih di antara layar yang menampilkannya, sehingga kehilangan gambaran keseluruhan. Selain itu, penyedia cloud kemungkinan besar tidak akan memberi Anda kemampuan untuk mengkorelasikan peristiwa keamanan dan umumnya menganalisisnya dari sudut pandang keamanan (biasanya Anda berurusan dengan data mentah, yang perlu Anda pahami sendiri). Ada pengecualian dan kami akan membicarakannya lebih lanjut. Terakhir, ada baiknya menanyakan kejadian apa saja yang dicatat oleh penyedia cloud Anda, dalam format apa, dan bagaimana hubungannya dengan proses pemantauan keamanan informasi Anda? Misalnya, identifikasi dan otentikasi pengguna dan tamu. Bitrix yang sama memungkinkan Anda, berdasarkan peristiwa ini, untuk mencatat tanggal dan waktu peristiwa, nama pengguna atau tamu (jika Anda memiliki modul "Analisis Web"), objek yang diakses, dan elemen lain yang khas untuk sebuah situs web . Namun layanan keamanan informasi perusahaan mungkin memerlukan informasi tentang apakah pengguna mengakses cloud dari perangkat tepercaya (misalnya, dalam jaringan perusahaan, tugas ini dilaksanakan oleh Cisco ISE). Bagaimana dengan tugas sederhana seperti fungsi geo-IP, yang akan membantu menentukan apakah akun pengguna layanan cloud telah dicuri? Dan meskipun penyedia cloud menyediakannya untuk Anda, ini tidak cukup. Cisco CloudLock yang sama tidak hanya menganalisis geolokasi, tetapi menggunakan pembelajaran mesin untuk ini dan menganalisis data historis untuk setiap pengguna dan memantau berbagai anomali dalam upaya identifikasi dan otentikasi. Hanya MS Azure yang memiliki fungsi serupa (jika Anda memiliki langganan yang sesuai).

Ada kesulitan lain - karena bagi banyak penyedia cloud, pemantauan keamanan informasi adalah topik baru yang baru mulai mereka tangani, mereka terus-menerus mengubah sesuatu dalam solusi mereka. Hari ini mereka memiliki satu versi API, besok versi lain, dan lusa versi ketiga. Anda juga perlu bersiap untuk ini. Hal yang sama berlaku untuk fungsionalitas, yang mungkin berubah, yang harus diperhitungkan dalam sistem pemantauan keamanan informasi Anda. Misalnya, Amazon awalnya memiliki layanan pemantauan peristiwa cloud terpisah—AWS CloudTrail dan AWS CloudWatch. Kemudian layanan terpisah untuk memantau peristiwa keamanan informasi muncul - AWS GuardDuty. Setelah beberapa waktu, Amazon meluncurkan sistem manajemen baru, Amazon Security Hub, yang mencakup analisis data yang diterima dari GuardDuty, Amazon Inspector, Amazon Macie, dan beberapa lainnya. Contoh lainnya adalah alat integrasi log Azure dengan SIEM - AzLog. Alat ini digunakan secara aktif oleh banyak vendor SIEM, hingga pada tahun 2018 Microsoft mengumumkan penghentian pengembangan dan dukungannya, yang menyebabkan banyak klien yang menggunakan alat ini mengalami masalah (kita akan membicarakan cara penyelesaiannya nanti).

Oleh karena itu, pantau dengan cermat semua fitur pemantauan yang ditawarkan penyedia cloud Anda. Atau andalkan penyedia solusi eksternal yang akan bertindak sebagai perantara antara SOC Anda dan cloud yang ingin Anda pantau. Ya, itu akan lebih mahal (walaupun tidak selalu), tetapi Anda akan mengalihkan semua tanggung jawab ke pundak orang lain. Atau tidak semuanya?.. Mari kita ingat konsep keamanan bersama dan memahami bahwa kita tidak dapat mengubah apa pun - kita harus memahami secara mandiri bagaimana penyedia cloud yang berbeda menyediakan pemantauan keamanan informasi data, aplikasi, mesin virtual, dan sumber daya lainnya dihosting di cloud. Dan kita akan mulai dengan apa yang ditawarkan Amazon di bagian ini.

Contoh: Pemantauan keamanan informasi di IaaS berbasis AWS

Ya, ya, saya memahami bahwa Amazon bukanlah contoh terbaik karena ini adalah layanan Amerika dan dapat diblokir sebagai bagian dari perang melawan ekstremisme dan penyebaran informasi yang dilarang di Rusia. Namun dalam publikasi ini saya hanya ingin menunjukkan perbedaan platform cloud dalam kemampuan pemantauan keamanan informasinya dan apa yang harus Anda perhatikan saat mentransfer proses utama Anda ke cloud dari sudut pandang keamanan. Nah, jika beberapa pengembang solusi cloud Rusia mempelajari sesuatu yang berguna untuk diri mereka sendiri, itu akan sangat bagus.

Hal pertama yang harus saya katakan adalah bahwa Amazon bukanlah benteng yang tidak bisa ditembus. Berbagai kejadian kerap menimpa kliennya. Misalnya, nama, alamat, tanggal lahir, dan nomor telepon 198 juta pemilih dicuri dari Deep Root Analytics. Perusahaan Israel Nice Systems mencuri 14 juta catatan pelanggan Verizon. Namun, kemampuan bawaan AWS memungkinkan Anda mendeteksi berbagai macam insiden. Misalnya:

dampak pada infrastruktur (DDoS)
kompromi simpul (injeksi perintah)
penyusupan akun dan akses tidak sah
konfigurasi dan kerentanan yang salah
antarmuka dan API yang tidak aman.

Perbedaan ini disebabkan oleh fakta bahwa, seperti yang kami ketahui di atas, pelanggan sendirilah yang bertanggung jawab atas keamanan data pelanggan. Dan jika dia tidak mau repot-repot mengaktifkan mekanisme perlindungan dan tidak menyalakan alat pemantauan, maka dia hanya akan mengetahui kejadian tersebut dari media atau dari kliennya.

Untuk mengidentifikasi insiden, Anda dapat menggunakan berbagai layanan pemantauan berbeda yang dikembangkan oleh Amazon (meskipun layanan ini sering kali dilengkapi dengan alat eksternal seperti osquery). Jadi, di AWS, semua tindakan pengguna dipantau, terlepas dari cara tindakan tersebut dilakukan - melalui konsol manajemen, baris perintah, SDK, atau layanan AWS lainnya. Semua catatan setiap aktivitas akun AWS (termasuk nama pengguna, tindakan, layanan, parameter aktivitas, dan hasil) dan penggunaan API tersedia melalui AWS CloudTrail. Anda dapat melihat peristiwa ini (seperti login konsol AWS IAM) dari konsol CloudTrail, menganalisisnya menggunakan Amazon Athena, atau “mengalihdayakan” peristiwa tersebut ke solusi eksternal seperti Splunk, AlienVault, dll. Log AWS CloudTrail itu sendiri ditempatkan di bucket AWS S3 Anda.

Dua layanan AWS lainnya menyediakan sejumlah kemampuan pemantauan penting lainnya. Pertama, Amazon CloudWatch adalah layanan pemantauan untuk sumber daya dan aplikasi AWS yang, antara lain, memungkinkan Anda mengidentifikasi berbagai anomali di cloud Anda. Semua layanan AWS bawaan, seperti Amazon Elastic Compute Cloud (server), Amazon Relational Database Service (database), Amazon Elastic MapReduce (analisis data), dan 30 layanan Amazon lainnya, menggunakan Amazon CloudWatch untuk menyimpan lognya. Pengembang dapat menggunakan API terbuka dari Amazon CloudWatch untuk menambahkan fungsionalitas pemantauan log ke aplikasi dan layanan khusus, sehingga memungkinkan mereka memperluas cakupan analisis peristiwa dalam konteks keamanan.

Kedua, layanan Log Aliran VPC memungkinkan Anda menganalisis lalu lintas jaringan yang dikirim atau diterima oleh server AWS Anda (secara eksternal atau internal), serta antar layanan mikro. Ketika salah satu sumber daya AWS VPC Anda berinteraksi dengan jaringan, Log Aliran VPC mencatat detail tentang lalu lintas jaringan, termasuk antarmuka jaringan sumber dan tujuan, serta alamat IP, port, protokol, jumlah byte, dan jumlah paket yang Anda gunakan. gergaji. Mereka yang berpengalaman dengan keamanan jaringan lokal akan mengenali ini sebagai analogi thread NetFlow, yang dapat dibuat oleh sakelar, router, dan firewall tingkat perusahaan. Log ini penting untuk tujuan pemantauan keamanan informasi karena, tidak seperti peristiwa tentang tindakan pengguna dan aplikasi, log ini juga memungkinkan Anda untuk tidak melewatkan interaksi jaringan di lingkungan virtual private cloud AWS.

Singkatnya, ketiga layanan AWS ini—AWS CloudTrail, Amazon CloudWatch, dan VPC Flow Logs—bersama memberikan wawasan yang cukup kuat mengenai penggunaan akun Anda, perilaku pengguna, manajemen infrastruktur, aktivitas aplikasi dan layanan, serta aktivitas jaringan. Misalnya, mereka dapat digunakan untuk mendeteksi anomali berikut:

Upaya memindai situs, mencari pintu belakang, mencari kerentanan melalui semburan “kesalahan 404”.
Serangan injeksi (misalnya, injeksi SQL) melalui semburan “500 kesalahan”.
Alat serangan yang dikenal adalah sqlmap, nikto, w3af, nmap, dll. melalui analisis bidang Agen Pengguna.

Amazon Web Services juga telah mengembangkan layanan lain untuk tujuan keamanan siber yang memungkinkan Anda memecahkan banyak masalah lainnya. Misalnya, AWS memiliki layanan bawaan untuk mengaudit kebijakan dan konfigurasi - AWS Config. Layanan ini menyediakan audit berkelanjutan terhadap sumber daya AWS Anda dan konfigurasinya. Mari kita ambil contoh sederhana: Misalkan Anda ingin memastikan bahwa kata sandi pengguna dinonaktifkan di semua server Anda dan akses hanya dapat dilakukan berdasarkan sertifikat. AWS Config memudahkan pemeriksaan ini untuk semua server Anda. Ada kebijakan lain yang dapat diterapkan pada server cloud Anda: “Tidak ada server yang dapat menggunakan port 22”, “Hanya administrator yang dapat mengubah aturan firewall” atau “Hanya pengguna Ivashko yang dapat membuat akun pengguna baru, dan dia hanya dapat melakukannya pada hari Selasa. " Pada musim panas 2016, layanan AWS Config diperluas untuk mengotomatisasi deteksi pelanggaran kebijakan yang dikembangkan. Aturan AWS Config pada dasarnya adalah permintaan konfigurasi berkelanjutan untuk layanan Amazon yang Anda gunakan, yang menghasilkan peristiwa jika kebijakan terkait dilanggar. Misalnya, alih-alih menjalankan kueri AWS Config secara berkala untuk memverifikasi bahwa semua disk di server virtual dienkripsi, Aturan AWS Config dapat digunakan untuk terus memeriksa disk server guna memastikan bahwa kondisi ini terpenuhi. Dan yang terpenting, dalam konteks publikasi ini, setiap pelanggaran menghasilkan peristiwa yang dapat dianalisis oleh layanan keamanan informasi Anda.

AWS juga memiliki solusi keamanan informasi perusahaan yang setara, yang juga menghasilkan peristiwa keamanan yang dapat dan harus Anda analisis:

Deteksi Intrusi - AWS GuardDuty
Pengendalian Kebocoran Informasi - AWS Macie
EDR (walaupun agak aneh membahas tentang titik akhir di cloud) - AWS Cloudwatch + osquery sumber terbuka atau solusi GRR
Analisis Netflow - AWS Cloudwatch + Aliran AWS VPC
Analisis DNS - AWS Cloudwatch + AWS Route53
IKLAN - Layanan Direktori AWS
Manajemen Akun - AWS IAM
SSO - AWS SSO
analisis keamanan - AWS Inspector
manajemen konfigurasi - AWS Config
WAF - WAF AWS.

Saya tidak akan menjelaskan secara detail semua layanan Amazon yang mungkin berguna dalam konteks keamanan informasi. Hal utama adalah memahami bahwa semuanya dapat menghasilkan peristiwa yang dapat dan harus kita analisis dalam konteks keamanan informasi, untuk tujuan ini menggunakan kemampuan bawaan Amazon itu sendiri dan solusi eksternal, misalnya, SIEM, yang dapat membawa peristiwa keamanan ke pusat pemantauan Anda dan menganalisisnya di sana bersama dengan peristiwa dari layanan cloud lainnya atau dari infrastruktur internal, perimeter, atau perangkat seluler.

Bagaimanapun, semuanya dimulai dengan sumber data yang memberi Anda peristiwa keamanan informasi. Sumber-sumber ini termasuk, namun tidak terbatas pada:

CloudTrail - Penggunaan API dan Tindakan Pengguna
Trusted Advisor - pemeriksaan keamanan terhadap praktik terbaik
Konfigurasi - inventaris dan konfigurasi akun dan pengaturan layanan
Log Aliran VPC - koneksi ke antarmuka virtual
IAM - layanan identifikasi dan otentikasi
Log Akses ELB - Penyeimbang Beban
Inspektur - kerentanan aplikasi
S3 - penyimpanan file
CloudWatch - Aktivitas Aplikasi
SNS adalah layanan notifikasi.

Amazon, meskipun menawarkan berbagai sumber peristiwa dan alat untuk pembuatannya, kemampuannya sangat terbatas untuk menganalisis data yang dikumpulkan dalam konteks keamanan informasi. Anda harus mempelajari secara mandiri log yang tersedia, mencari indikator kompromi yang relevan di dalamnya. AWS Security Hub, yang baru-baru ini diluncurkan Amazon, bertujuan untuk memecahkan masalah ini dengan menjadi SIEM cloud untuk AWS. Namun sejauh ini, ini baru pada awal perjalanannya dan dibatasi baik oleh jumlah sumber yang digunakannya maupun oleh batasan lain yang ditetapkan oleh arsitektur dan langganan Amazon itu sendiri.

Contoh: Pemantauan keamanan informasi di IaaS berdasarkan Azure

Saya tidak ingin berdebat panjang lebar tentang mana di antara ketiga penyedia cloud (Amazon, Microsoft atau Google) yang lebih baik (terutama karena masing-masing masih memiliki spesifikasi spesifiknya sendiri dan cocok untuk menyelesaikan masalahnya sendiri); Mari kita fokus pada kemampuan pemantauan keamanan informasi yang disediakan oleh para pemain ini. Harus diakui bahwa Amazon AWS adalah salah satu yang pertama di segmen ini dan oleh karena itu telah mencapai kemajuan terjauh dalam hal fungsi keamanan informasinya (walaupun banyak yang mengakui bahwa fungsi tersebut sulit digunakan). Namun ini tidak berarti bahwa kita akan mengabaikan peluang yang diberikan Microsoft dan Google kepada kita.

Produk Microsoft selalu dibedakan berdasarkan “keterbukaan” dan di Azure situasinya serupa. Misalnya, jika AWS dan GCP selalu berangkat dari konsep “apa yang tidak boleh dilarang”, maka Azure memiliki pendekatan sebaliknya. Misalnya, saat membuat jaringan virtual di cloud dan mesin virtual di dalamnya, semua port dan protokol terbuka dan diizinkan secara default. Oleh karena itu, Anda harus mengeluarkan lebih banyak upaya pada pengaturan awal sistem kontrol akses di cloud dari Microsoft. Dan ini juga memberlakukan persyaratan yang lebih ketat pada Anda dalam hal pemantauan aktivitas di cloud Azure.

AWS memiliki kekhasan yang terkait dengan fakta bahwa ketika Anda memantau sumber daya virtual Anda, jika mereka berlokasi di wilayah yang berbeda, maka Anda mengalami kesulitan dalam menggabungkan semua peristiwa dan analisis terpadunya, untuk menghilangkannya Anda perlu menggunakan berbagai trik, seperti sebagai Buat kode Anda sendiri untuk AWS Lambda yang akan mengangkut peristiwa antar wilayah. Azure tidak mengalami masalah ini - mekanisme Log Aktivitasnya melacak semua aktivitas di seluruh organisasi tanpa batasan. Hal yang sama berlaku untuk AWS Security Hub, yang baru-baru ini dikembangkan oleh Amazon untuk mengkonsolidasikan banyak fungsi keamanan dalam satu pusat keamanan, namun hanya dalam wilayahnya, namun tidak relevan untuk Rusia. Azure memiliki Pusat Keamanannya sendiri, yang tidak terikat oleh batasan regional, menyediakan akses ke semua fitur keamanan platform cloud. Selain itu, untuk tim lokal yang berbeda, tim ini dapat menyediakan serangkaian kemampuan perlindungannya sendiri dan, antara lain, peristiwa keamanan yang dikelola oleh mereka. AWS Security Hub masih dalam proses untuk menjadi mirip dengan Microsoft Defender untuk Cloud. Namun ada baiknya menambahkan sedikit tambahan - Anda dapat memanfaatkan Azure banyak hal yang dijelaskan sebelumnya di AWS, tetapi ini paling mudah dilakukan hanya untuk Azure AD, Azure Monitor, dan Azure Security Center. Semua mekanisme keamanan Azure lainnya, termasuk analisis peristiwa keamanan, belum dikelola dengan cara yang paling nyaman. Masalahnya sebagian diselesaikan oleh API, yang meresapi semua layanan Microsoft Azure, tetapi ini akan memerlukan upaya tambahan dari Anda untuk mengintegrasikan cloud Anda dengan SOC Anda dan kehadiran spesialis yang berkualifikasi (pada kenyataannya, sama seperti SIEM lain yang bekerja dengan API awan). Beberapa SIEM yang akan dibahas nanti sudah mendukung Azure dan dapat mengotomatiskan tugas pemantauannya, namun juga memiliki kesulitan tersendiri - tidak semuanya dapat mengumpulkan semua log yang dimiliki Azure.

Pengumpulan dan pemantauan peristiwa di Azure disediakan menggunakan layanan Azure Monitor, yang merupakan alat utama untuk mengumpulkan, menyimpan, dan menganalisis data di cloud Microsoft dan sumber dayanya - repositori Git, kontainer, mesin virtual, aplikasi, dll. Semua data yang dikumpulkan oleh Azure Monitor dibagi menjadi dua kategori - metrik, yang dikumpulkan secara real-time dan menjelaskan indikator kinerja utama cloud Azure, dan log, yang berisi data yang disusun ke dalam catatan yang mencirikan aspek tertentu dari aktivitas sumber daya dan layanan Azure. Selain itu, dengan menggunakan Data Collector API, layanan Azure Monitor dapat mengumpulkan data dari sumber REST mana pun untuk membangun skenario pemantauannya sendiri.

Berikut adalah beberapa sumber peristiwa keamanan yang ditawarkan Azure kepada Anda dan dapat Anda akses melalui Portal Azure, CLI, PowerShell, atau REST API (dan beberapa hanya melalui Azure Monitor/Insight API):

Log Aktivitas - log ini menjawab pertanyaan klasik “siapa”, “apa”, dan “kapan” terkait operasi tulis apa pun (PUT, POST, DELETE) pada sumber daya cloud. Peristiwa yang terkait dengan akses baca (GET) tidak disertakan dalam log ini, seperti sejumlah log lainnya.
Log Diagnostik - berisi data tentang operasi dengan sumber daya tertentu yang termasuk dalam langganan Anda.
Pelaporan Azure Active Directory - berisi aktivitas pengguna dan aktivitas sistem yang terkait dengan manajemen grup dan pengguna.
Log Peristiwa Windows dan Syslog Linux - berisi peristiwa dari mesin virtual yang dihosting di cloud.
Metrik - berisi telemetri tentang kinerja dan status kesehatan layanan dan sumber daya cloud Anda. Diukur setiap menit dan disimpan. dalam 30 hari.
Log Aliran Grup Keamanan Jaringan - berisi data tentang peristiwa keamanan jaringan yang dikumpulkan menggunakan layanan Network Watcher dan pemantauan sumber daya di tingkat jaringan.
Log Penyimpanan - berisi peristiwa yang terkait dengan akses ke fasilitas penyimpanan.

Untuk pemantauan, Anda dapat menggunakan SIEM eksternal atau Azure Monitor bawaan dan ekstensinya. Kita akan membicarakan sistem manajemen peristiwa keamanan informasi nanti, tetapi untuk saat ini mari kita lihat apa yang ditawarkan Azure sendiri untuk analisis data dalam konteks keamanan. Layar utama untuk semua yang terkait dengan keamanan di Azure Monitor adalah Dasbor Keamanan dan Audit Analitik Log (versi gratis mendukung penyimpanan peristiwa dalam jumlah terbatas hanya selama satu minggu). Dasbor ini dibagi menjadi 5 area utama yang memvisualisasikan ringkasan statistik tentang apa yang terjadi di lingkungan cloud yang Anda gunakan:

Domain Keamanan - indikator kuantitatif utama yang terkait dengan keamanan informasi - jumlah insiden, jumlah node yang disusupi, node yang belum ditambal, peristiwa keamanan jaringan, dll.
Masalah Penting - menampilkan jumlah dan pentingnya masalah keamanan informasi yang aktif
Deteksi - menampilkan pola serangan yang digunakan terhadap Anda
Threat Intelligence - menampilkan informasi geografis pada node eksternal yang menyerang Anda
Kueri keamanan umum - kueri umum yang akan membantu Anda memantau keamanan informasi Anda dengan lebih baik.

Ekstensi Azure Monitor mencakup Azure Key Vault (perlindungan kunci kriptografi di cloud), Penilaian Malware (analisis perlindungan terhadap kode berbahaya pada mesin virtual), Azure Application Gateway Analytics (analisis, antara lain, log firewall cloud), dll. . Alat-alat ini, diperkaya dengan aturan tertentu untuk memproses peristiwa, memungkinkan Anda memvisualisasikan berbagai aspek aktivitas layanan cloud, termasuk keamanan, dan mengidentifikasi penyimpangan tertentu dalam pengoperasian. Namun, seperti yang sering terjadi, fungsionalitas tambahan apa pun memerlukan langganan berbayar yang sesuai, yang akan memerlukan investasi finansial yang sesuai dari Anda, yang perlu Anda rencanakan sebelumnya.

Azure memiliki sejumlah kemampuan pemantauan ancaman bawaan yang terintegrasi ke dalam Azure Active Directory, Azure Monitor, dan Microsoft Defender untuk Cloud. Diantaranya misalnya deteksi interaksi mesin virtual dengan IP berbahaya yang diketahui (karena adanya integrasi dengan layanan Threat Intelligence dari Microsoft), deteksi malware di infrastruktur cloud dengan menerima alarm dari mesin virtual yang dihosting di cloud, kata sandi. serangan tebakan ” pada mesin virtual, kerentanan dalam konfigurasi sistem identifikasi pengguna, masuk ke sistem dari anonimizer atau node yang terinfeksi, kebocoran akun, masuk ke sistem dari lokasi yang tidak biasa, dll. Azure saat ini adalah salah satu dari sedikit penyedia cloud yang menawarkan kepada Anda kemampuan Threat Intelligence bawaan untuk memperkaya peristiwa keamanan informasi yang dikumpulkan.

Seperti disebutkan di atas, fungsionalitas keamanan dan, sebagai akibatnya, peristiwa keamanan yang dihasilkannya tidak tersedia untuk semua pengguna secara merata, tetapi memerlukan langganan tertentu yang mencakup fungsionalitas yang Anda perlukan, yang menghasilkan peristiwa yang sesuai untuk pemantauan keamanan informasi. Misalnya, beberapa fungsi yang dijelaskan dalam paragraf sebelumnya untuk memantau anomali di akun hanya tersedia dalam lisensi premium P2 untuk layanan Microsoft Azure Active Directory. Tanpanya, Anda, seperti halnya AWS, harus menganalisis peristiwa keamanan yang dikumpulkan “secara manual”. Selain itu, bergantung pada jenis lisensi Azure Active Directory, tidak semua peristiwa akan tersedia untuk dianalisis.

Di portal Microsoft Azure, Anda dapat mengelola kueri pencarian untuk log yang Anda minati dan menyiapkan dasbor untuk memvisualisasikan indikator keamanan informasi utama. Selain itu, di sana Anda dapat memilih ekstensi Azure Monitor, yang memungkinkan Anda memperluas fungsionalitas log Azure Monitor dan mendapatkan analisis peristiwa yang lebih mendalam dari sudut pandang keamanan.

Jika Anda tidak hanya membutuhkan kemampuan untuk bekerja dengan log, tetapi juga pusat keamanan komprehensif untuk platform cloud Azure Anda, termasuk manajemen kebijakan keamanan informasi, maka Anda dapat berbicara tentang perlunya bekerja dengan Pusat Keamanan Azure, yang sebagian besar fungsinya berguna. tersedia untuk sejumlah uang, misalnya, deteksi ancaman, pemantauan di luar Azure, penilaian kepatuhan, dll. (dalam versi gratis, Anda hanya memiliki akses ke penilaian keamanan dan rekomendasi untuk menghilangkan masalah yang teridentifikasi). Ini menggabungkan semua masalah keamanan di satu tempat. Faktanya, kita dapat berbicara tentang tingkat keamanan informasi yang lebih tinggi daripada yang diberikan Azure Monitor kepada Anda, karena dalam hal ini data yang dikumpulkan di seluruh pabrik cloud Anda diperkaya menggunakan banyak sumber, seperti Azure, Office 365, Microsoft CRM online, Microsoft Dynamics AX , Outlook .com, MSN.com, Microsoft Digital Crimes Unit (DCU) dan Microsoft Security Response Center (MSRC), yang ditumpangkan pada berbagai algoritma pembelajaran mesin dan analisis perilaku yang canggih, yang pada akhirnya akan meningkatkan efisiensi pendeteksian dan respons terhadap ancaman .

Azure juga memiliki SIEM sendiri - muncul pada awal tahun 2019. Ini adalah Microsoft Sentinel, yang mengandalkan data dari Azure Monitor dan juga dapat berintegrasi dengannya. solusi keamanan eksternal (misalnya, NGFW atau WAF), yang daftarnya terus bertambah. Selain itu, melalui integrasi Microsoft Graph Security API, Anda memiliki kemampuan untuk menghubungkan umpan Threat Intelligence Anda sendiri ke Sentinel, yang memperkaya kemampuan untuk menganalisis insiden di cloud Azure Anda. Dapat dikatakan bahwa Azure Sentinel adalah SIEM “asli” pertama yang muncul dari penyedia cloud (Splunk atau ELK yang sama, yang dapat dihosting di cloud, misalnya AWS, masih belum dikembangkan oleh penyedia layanan cloud tradisional). Azure Sentinel dan Pusat Keamanan dapat disebut SOC untuk cloud Azure dan dapat dibatasi pada keduanya (dengan syarat tertentu) jika Anda tidak lagi memiliki infrastruktur apa pun dan Anda mentransfer semua sumber daya komputasi Anda ke cloud dan itu akan menjadi cloud Microsoft Azure.

Namun karena kemampuan bawaan Azure (bahkan jika Anda berlangganan Sentinel) sering kali tidak cukup untuk memantau keamanan informasi dan mengintegrasikan proses ini dengan sumber peristiwa keamanan lainnya (baik cloud maupun internal), terdapat perlu mengekspor data yang dikumpulkan ke sistem eksternal, yang mungkin mencakup SIEM. Hal ini dilakukan baik menggunakan API maupun menggunakan ekstensi khusus, yang saat ini secara resmi hanya tersedia untuk SIEM berikut - Splunk (Azure Monitor Add-On for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight, dan ELK. Sampai saat ini, terdapat lebih banyak SIEM seperti itu, tetapi mulai 1 Juni 2019, Microsoft berhenti mendukung Alat Integrasi Log Azure (AzLog), yang pada awal keberadaan Azure dan tidak adanya standarisasi normal dalam bekerja dengan log (Azure Monitor bahkan belum ada) memudahkan integrasi SIEM eksternal dengan cloud Microsoft. Sekarang situasinya telah berubah dan Microsoft merekomendasikan platform Azure Event Hub sebagai alat integrasi utama untuk SIEM lainnya. Banyak yang telah menerapkan integrasi seperti itu, namun hati-hati - integrasi tersebut mungkin tidak menangkap semua log Azure, namun hanya sebagian (lihat dokumentasi SIEM Anda).

Sebagai penutup perjalanan singkat ke Azure, saya ingin memberikan rekomendasi umum tentang layanan cloud ini - sebelum Anda mengatakan apa pun tentang fungsi pemantauan keamanan informasi di Azure, Anda harus mengonfigurasinya dengan sangat hati-hati dan menguji apakah fungsi tersebut berfungsi seperti yang tertulis dalam dokumentasi dan seperti yang dikatakan konsultan kepada Anda Microsoft (dan mereka mungkin memiliki pandangan berbeda tentang fungsionalitas fungsi Azure). Jika Anda memiliki sumber daya keuangan, Anda dapat memperoleh banyak informasi berguna dari Azure dalam hal pemantauan keamanan informasi. Jika sumber daya Anda terbatas, seperti halnya AWS, Anda hanya perlu mengandalkan kekuatan Anda sendiri dan data mentah yang disediakan Azure Monitor. Dan ingat bahwa banyak fungsi pemantauan memerlukan biaya dan lebih baik Anda memahami kebijakan penetapan harga terlebih dahulu. Misalnya, secara gratis Anda dapat menyimpan data selama 31 hari hingga maksimum 5 GB per pelanggan - jika melebihi nilai ini, Anda harus mengeluarkan uang tambahan (kira-kira $2+ untuk menyimpan setiap GB tambahan dari pelanggan dan $0,1 untuk menyimpan 1 GB setiap bulan tambahan). Bekerja dengan telemetri dan metrik aplikasi mungkin juga memerlukan dana tambahan, serta bekerja dengan peringatan dan pemberitahuan (batas tertentu tersedia secara gratis, yang mungkin tidak cukup untuk kebutuhan Anda).

Contoh: Pemantauan keamanan informasi di IaaS berbasis Google Cloud Platform

Google Cloud Platform tampak lebih muda dibandingkan AWS dan Azure, tetapi ini cukup bagus. Berbeda dengan AWS yang meningkatkan kemampuannya, termasuk keamanan, secara bertahap, mengalami masalah dengan sentralisasi; GCP, seperti Azure, dikelola secara terpusat dengan lebih baik, sehingga mengurangi kesalahan dan waktu implementasi di seluruh perusahaan. Dari sudut pandang keamanan, anehnya GCP berada di antara AWS dan Azure. Dia juga memiliki satu pendaftaran acara untuk seluruh organisasi, namun tidak lengkap. Beberapa fungsi masih dalam mode beta, namun secara bertahap kekurangan ini harus dihilangkan dan GCP akan menjadi platform yang lebih matang dalam hal pemantauan keamanan informasi.

Alat utama untuk mencatat peristiwa di GCP adalah Stackdriver Logging (mirip dengan Azure Monitor), yang memungkinkan Anda mengumpulkan peristiwa di seluruh infrastruktur cloud Anda (serta dari AWS). Dari perspektif keamanan di GCP, setiap organisasi, project, atau folder memiliki empat log:

Aktivitas Admin - berisi semua peristiwa yang terkait dengan akses administratif, misalnya pembuatan mesin virtual, perubahan hak akses, dll. Log ini selalu ditulis, apapun keinginan Anda, dan menyimpan datanya selama 400 hari.
Akses Data - berisi semua peristiwa yang terkait dengan pengerjaan data oleh pengguna cloud (pembuatan, modifikasi, pembacaan, dll.). Secara default, log ini tidak ditulis, karena volumenya membengkak dengan sangat cepat. Oleh karena itu, umur simpannya hanya 30 hari. Apalagi tidak semuanya tertulis di majalah ini. Misalnya, peristiwa terkait resource yang dapat diakses publik oleh semua pengguna atau yang dapat diakses tanpa login ke GCP tidak akan ditulis ke dalamnya.
Peristiwa Sistem - berisi peristiwa sistem yang tidak terkait dengan pengguna, atau tindakan administrator yang mengubah konfigurasi sumber daya cloud. Itu selalu ditulis dan disimpan selama 400 hari.
Transparansi Akses adalah contoh unik log yang mencatat semua tindakan karyawan Google (tetapi belum untuk semua layanan GCP) yang mengakses infrastruktur Anda sebagai bagian dari tugas pekerjaan mereka. Log ini disimpan selama 400 hari dan tidak tersedia untuk setiap klien GCP, tetapi hanya jika sejumlah kondisi terpenuhi (dukungan tingkat Gold atau Platinum, atau adanya 4 peran jenis tertentu sebagai bagian dari dukungan perusahaan). Fungsi serupa juga tersedia, misalnya di Office 365 - Lockbox.

Contoh log: Transparansi Akses

{
 insertId:  "abcdefg12345"
 jsonPayload: {
  @type:  "type.googleapis.com/google.cloud.audit.TransparencyLog"
  location: {
   principalOfficeCountry:  "US"
   principalEmployingEntity:  "Google LLC"
   principalPhysicalLocationCountry:  "CA"
  }
  product: [
   0:  "Cloud Storage"
  ]
  reason: [
    detail:  "Case number: bar123"
    type:  "CUSTOMER_INITIATED_SUPPORT"
  ]
  accesses: [
   0: {
    methodName: "GoogleInternal.Read"
    resourceName: "//googleapis.com/storage/buckets/[BUCKET_NAME]/objects/foo123"
    }
  ]
 }
 logName:  "projects/[PROJECT_NAME]/logs/cloudaudit.googleapis.com%2Faccess_transparency"
 operation: {
  id:  "12345xyz"
 }
 receiveTimestamp:  "2017-12-18T16:06:37.400577736Z"
 resource: {
  labels: {
   project_id:  "1234567890"
  }
  type:  "project"
 }
 severity:  "NOTICE"
 timestamp:  "2017-12-18T16:06:24.660001Z"
}

Akses ke log ini dimungkinkan dalam beberapa cara (sama seperti yang dibahas sebelumnya tentang Azure dan AWS) - melalui antarmuka Log Viewer, melalui API, melalui Google Cloud SDK, atau melalui halaman Aktivitas proyek tempat Anda tertarik pada acara. Dengan cara yang sama, data tersebut dapat diekspor ke solusi eksternal untuk analisis tambahan. Yang terakhir dilakukan dengan mengekspor log ke penyimpanan BigQuery atau Cloud Pub/Sub.

Selain Stackdriver Logging, platform GCP juga menawarkan fungsi Stackdriver Monitoring, yang memungkinkan Anda memantau metrik utama (kinerja, MTBF, kesehatan secara keseluruhan, dll.) dari layanan dan aplikasi cloud. Data yang diproses dan divisualisasikan dapat mempermudah menemukan masalah pada infrastruktur cloud Anda, termasuk dalam konteks keamanan. Namun perlu dicatat bahwa fungsi ini tidak akan terlalu kaya dalam konteks keamanan informasi, karena saat ini GCP tidak memiliki analog dari AWS GuardDuty yang sama dan tidak dapat mengidentifikasi peristiwa buruk di antara semua peristiwa yang terdaftar (Google telah mengembangkan Deteksi Ancaman Peristiwa, tetapi masih dalam pengembangan dalam versi beta dan masih terlalu dini untuk membicarakan kegunaannya). Stackdriver Monitoring dapat digunakan sebagai sistem untuk mendeteksi anomali, yang kemudian diselidiki untuk menemukan penyebab kemunculannya. Namun mengingat kurangnya personel yang berkualifikasi di bidang keamanan informasi GCP di pasar, tugas ini saat ini terlihat sulit.

Sebaiknya berikan juga daftar beberapa modul keamanan informasi yang dapat digunakan dalam cloud GCP Anda, dan modul tersebut serupa dengan yang ditawarkan AWS:

Cloud Security Command Center adalah analog dari AWS Security Hub dan Azure Security Center.
Cloud DLP - Penemuan dan pengeditan otomatis (misalnya masking) data yang dihosting di cloud menggunakan lebih dari 90 kebijakan klasifikasi yang telah ditentukan sebelumnya.
Cloud Scanner adalah pemindai untuk kerentanan yang diketahui (XSS, Flash Injection, perpustakaan yang belum ditambal, dll.) di App Engine, Compute Engine, dan Google Kubernetes.
Cloud IAM - Mengontrol akses ke semua resource GCP.
Cloud Identity - Kelola akun pengguna, perangkat, dan aplikasi GCP dari satu konsol.
Cloud HSM - perlindungan kunci kriptografi.
Layanan Cloud Key Management - pengelolaan kunci kriptografi di GCP.
Kontrol Layanan VPC - Buat perimeter aman di sekitar resource GCP Anda untuk melindunginya dari kebocoran.
Kunci Keamanan Titan - perlindungan terhadap phishing.

Banyak dari modul ini menghasilkan peristiwa keamanan yang dapat dikirim ke penyimpanan BigQuery untuk dianalisis atau diekspor ke sistem lain, termasuk SIEM. Seperti disebutkan di atas, GCP adalah platform yang aktif berkembang dan Google kini mengembangkan sejumlah modul keamanan informasi baru untuk platformnya. Diantaranya adalah Deteksi Ancaman Peristiwa (sekarang tersedia dalam versi beta), yang memindai log Stackdriver untuk mencari jejak aktivitas tidak sah (analog dengan GuardDuty di AWS), atau Intelijen Kebijakan (tersedia dalam alfa), yang memungkinkan Anda mengembangkan kebijakan cerdas untuk akses ke resource GCP.

Saya membuat ikhtisar singkat tentang kemampuan pemantauan bawaan di platform cloud populer. Namun apakah Anda memiliki spesialis yang mampu bekerja dengan log penyedia IaaS “mentah” (tidak semua orang siap membeli kemampuan lanjutan AWS atau Azure atau Google)? Selain itu, banyak orang yang akrab dengan pepatah “percaya, tapi verifikasi,” yang lebih benar dari sebelumnya dalam bidang keamanan. Seberapa besar kepercayaan Anda terhadap kemampuan bawaan penyedia cloud yang mengirimkan peristiwa keamanan informasi kepada Anda? Seberapa besar fokus mereka pada keamanan informasi?

Terkadang ada baiknya melihat solusi pemantauan infrastruktur cloud overlay yang dapat melengkapi keamanan cloud bawaan, dan terkadang solusi tersebut adalah satu-satunya pilihan untuk mendapatkan wawasan tentang keamanan data dan aplikasi Anda yang dihosting di cloud. Selain itu, mereka lebih nyaman karena mereka melakukan semua tugas menganalisis log yang diperlukan yang dihasilkan oleh berbagai layanan cloud dari penyedia cloud yang berbeda. Contoh dari solusi overlay tersebut adalah Cisco Stealthwatch Cloud, yang berfokus pada satu tugas - memantau anomali keamanan informasi di lingkungan cloud, termasuk tidak hanya Amazon AWS, Microsoft Azure, dan Google Cloud Platform, tetapi juga private cloud.

Contoh: Pemantauan Keamanan Informasi Menggunakan Stealthwatch Cloud

AWS menyediakan platform komputasi yang fleksibel, namun fleksibilitas ini memudahkan perusahaan melakukan kesalahan yang berujung pada masalah keamanan. Dan model keamanan informasi bersama hanya berkontribusi pada hal ini. Menjalankan perangkat lunak di cloud dengan kerentanan yang tidak diketahui (kerentanan yang diketahui dapat diatasi, misalnya dengan AWS Inspector atau GCP Cloud Scanner), kata sandi yang lemah, konfigurasi yang salah, orang dalam, dll. Dan semua ini tercermin dalam perilaku sumber daya cloud, yang dapat dipantau oleh Cisco Stealthwatch Cloud, yang merupakan sistem pemantauan keamanan informasi dan deteksi serangan. cloud publik dan privat.

Salah satu fitur utama Cisco Stealthwatch Cloud adalah kemampuan memodelkan entitas. Dengan itu, Anda dapat membuat model perangkat lunak (yaitu, simulasi hampir real-time) dari setiap sumber daya cloud Anda (tidak peduli apakah itu AWS, Azure, GCP, atau yang lainnya). Ini dapat mencakup server dan pengguna, serta jenis sumber daya khusus untuk lingkungan cloud Anda, seperti grup keamanan dan grup penskalaan otomatis. Model ini menggunakan aliran data terstruktur yang disediakan oleh layanan cloud sebagai masukan. Misalnya, untuk AWS, ini adalah VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda, dan AWS IAM. Pemodelan entitas secara otomatis menemukan peran dan perilaku sumber daya Anda (Anda dapat berbicara tentang pembuatan profil semua aktivitas cloud). Peran ini termasuk perangkat seluler Android atau Apple, server Citrix PVS, server RDP, gateway email, klien VoIP, server terminal, pengontrol domain, dll. Kemudian mereka terus memantau perilaku mereka untuk menentukan kapan perilaku berisiko atau mengancam keselamatan terjadi. Anda dapat mengidentifikasi tebakan kata sandi, serangan DDoS, kebocoran data, akses jarak jauh ilegal, aktivitas kode berbahaya, pemindaian kerentanan, dan ancaman lainnya. Misalnya, seperti inilah deteksi upaya akses jarak jauh dari negara yang tidak biasa untuk organisasi Anda (Korea Selatan) ke cluster Kubernetes melalui SSH:

Dan seperti inilah dugaan kebocoran informasi dari database Postgress ke negara yang belum pernah kita temui sebelumnya:

Terakhir, seperti inilah banyak upaya SSH yang gagal dari Tiongkok dan Indonesia dari perangkat jarak jauh eksternal:

Atau, misalkan instans server di VPC, berdasarkan kebijakan, tidak pernah menjadi tujuan login jarak jauh. Mari kita asumsikan lebih lanjut bahwa komputer ini mengalami logon jarak jauh karena kesalahan perubahan dalam kebijakan aturan firewall. Fitur Pemodelan Entitas akan mendeteksi dan melaporkan aktivitas ini (“Akses Jarak Jauh yang Tidak Biasa”) hampir secara real-time dan mengarah ke panggilan API AWS CloudTrail, Azure Monitor, atau GCP Stackdriver Logging tertentu (termasuk nama pengguna, tanggal dan waktu, serta detail lainnya ), yang mendorong perubahan peraturan ITU. Dan kemudian informasi ini dapat dikirim ke SIEM untuk dianalisis.

Kemampuan serupa diterapkan untuk lingkungan cloud apa pun yang didukung oleh Cisco Stealthwatch Cloud:

Pemodelan entitas adalah bentuk otomatisasi keamanan unik yang dapat mengungkap masalah yang sebelumnya tidak diketahui pada orang, proses, atau teknologi Anda. Misalnya, ini memungkinkan Anda mendeteksi, antara lain, masalah keamanan seperti:

Apakah ada yang menemukan backdoor pada software yang kita gunakan?
Apakah ada perangkat lunak atau perangkat pihak ketiga di cloud kami?
Apakah pengguna yang berwenang menyalahgunakan hak istimewanya?
Apakah ada kesalahan konfigurasi yang memungkinkan akses jarak jauh atau penggunaan sumber daya lainnya yang tidak diinginkan?
Apakah ada kebocoran data dari server kami?
Apakah seseorang mencoba terhubung dengan kami dari lokasi geografis yang tidak biasa?
Apakah cloud kita terinfeksi kode berbahaya?

Peristiwa keamanan informasi yang terdeteksi dapat dikirim dalam bentuk tiket yang sesuai ke Slack, Cisco Spark, sistem manajemen insiden PagerDuty, dan juga dikirim ke berbagai SIEM, termasuk Splunk atau ELK. Ringkasnya, kami dapat mengatakan bahwa jika perusahaan Anda menggunakan strategi multi-cloud dan tidak terbatas pada satu penyedia cloud saja, kemampuan pemantauan keamanan informasi dijelaskan di atas, maka menggunakan Cisco Stealthwatch Cloud adalah pilihan yang baik untuk mendapatkan serangkaian pemantauan terpadu kemampuan untuk pemain cloud terkemuka - Amazon, Microsoft dan Google. Hal yang paling menarik adalah jika Anda membandingkan harga Stealthwatch Cloud dengan lisensi lanjutan untuk pemantauan keamanan informasi di AWS, Azure, atau GCP, ternyata solusi Cisco akan lebih murah daripada kemampuan bawaan Amazon, Microsoft. dan solusi Google. Ini paradoks, tapi itu benar. Dan semakin banyak cloud dan kemampuannya yang Anda gunakan, semakin jelas keuntungan dari solusi konsolidasi.

Selain itu, Stealthwatch Cloud dapat memantau private cloud yang diterapkan di organisasi Anda, misalnya berdasarkan container Kubernetes atau dengan memantau aliran Netflow atau lalu lintas jaringan yang diterima melalui mirroring pada peralatan jaringan (bahkan yang diproduksi di dalam negeri), data AD atau server DNS, dan sebagainya. Semua data ini akan diperkaya dengan informasi Threat Intelligence yang dikumpulkan oleh Cisco Talos, kelompok peneliti ancaman keamanan siber non-pemerintah terbesar di dunia.

Hal ini memungkinkan Anda menerapkan sistem pemantauan terpadu untuk cloud publik dan hybrid yang mungkin digunakan perusahaan Anda. Informasi yang dikumpulkan kemudian dapat dianalisis menggunakan kemampuan bawaan Stealthwatch Cloud atau dikirim ke SIEM Anda (Splunk, ELK, SumoLogic, dan beberapa lainnya didukung secara default).

Dengan ini, kita akan menyelesaikan bagian pertama artikel ini, di mana saya meninjau alat bawaan dan eksternal untuk memantau keamanan informasi platform IaaS/PaaS, yang memungkinkan kita dengan cepat mendeteksi dan merespons insiden yang terjadi di lingkungan cloud yang perusahaan kami telah memilih. Di bagian kedua, kami akan melanjutkan topik dan melihat opsi untuk memantau platform SaaS menggunakan contoh Salesforce dan Dropbox, dan kami juga akan mencoba merangkum dan menggabungkan semuanya dengan membuat sistem pemantauan keamanan informasi terpadu untuk berbagai penyedia cloud.

Sumber: www.habr.com

Pemantauan Keamanan Cloud