Pemantauan keamanan cloud

Mentransfer data dan aplikasi ke cloud adalah masalah baru untuk SOC perusahaan yang tidak selalu siap untuk memantau infrastruktur orang lain. Menurut Netoskope, perusahaan menengah (tampaknya masih di AS) menggunakan 1.246 layanan cloud yang berbeda, yang merupakan 22% lebih dari setahun yang lalu. 1246 layanan cloud !!! 175 dari mereka terkait dengan layanan SDM, 170 terkait dengan pemasaran, 110 - di bidang komunikasi dan 76 di bidang keuangan dan CRM. Cisco menggunakan "total" 700 layanan cloud eksternal. Karena itu, saya agak bingung dengan angka-angka ini. Tetapi bagaimanapun juga, masalahnya bukan pada mereka, tetapi pada kenyataan bahwa cloud digunakan secara aktif oleh semakin banyak perusahaan yang ingin memiliki kemampuan yang sama untuk memonitor infrastruktur cloud seperti pada jaringan mereka sendiri. Dan tren ini berkembang - menurut Kantor Audit Amerika , pada tahun 2023, 1.200 pusat data akan ditutup di Amerika Serikat (6.250 sudah ditutup). Tetapi transisi ke cloud bukan hanya "tetapi mari kita transfer server kami ke penyedia eksternal". Arsitektur TI baru, perangkat lunak baru, proses baru, batasan baru ... Semua ini membuat perubahan signifikan pada pekerjaan tidak hanya TI, tetapi juga keamanan informasi. Dan jika penyedia belajar cara mengatasi keamanan cloud itu sendiri (manfaat rekomendasi cukup banyak), maka ada kesulitan yang signifikan dengan pemantauan cloud keamanan informasi, terutama pada platform SaaS, yang akan kita bicarakan.



Katakanlah perusahaan Anda telah memindahkan sebagian infrastrukturnya ke cloud ... Berhenti. Tidak seperti itu. Jika infrastruktur ditransfer, dan Anda sekarang hanya berpikir tentang bagaimana Anda akan memantaunya, maka Anda sudah kehilangan. Jika ini bukan Amazon, Google atau Microsoft (dan dengan pemesanan), maka Anda mungkin tidak akan memiliki banyak kesempatan untuk memantau data dan aplikasi Anda. Nah, jika Anda diberi kesempatan untuk bekerja dengan log. Terkadang data tentang acara keamanan akan tersedia, tetapi Anda tidak akan memiliki akses ke sana. Misalnya, Office 365. Jika Anda memiliki lisensi E1 termurah, maka acara keamanan tidak tersedia untuk Anda sama sekali. Jika Anda memiliki lisensi E3, data Anda disimpan hanya dalam 90 hari, dan hanya jika Anda memiliki E5 - durasi log tersedia untuk satu tahun (namun, ada juga beberapa nuansa yang 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 daripada Exchange perusahaan. Untuk mencapai level yang sama, Anda memerlukan lisensi E5 atau lisensi Kepatuhan Lanjutan tambahan, yang mungkin memerlukan uang tambahan yang tidak termasuk dalam model keuangan Anda untuk transisi ke infrastruktur cloud. Dan ini hanyalah salah satu contoh dari meremehkan masalah yang berkaitan dengan pemantauan cloud IS. Dalam artikel ini, tanpa berpura-pura menjadi lengkap, saya ingin menarik perhatian pada beberapa nuansa yang harus dipertimbangkan ketika memilih penyedia cloud dari sudut pandang keamanan. Dan di akhir artikel, daftar periksa akan diberikan, yang harus diselesaikan sebelum Anda mempertimbangkan bahwa masalah pemantauan keamanan informasi cloud telah diselesaikan.

Ada beberapa masalah khas yang mengarah pada insiden di lingkungan cloud, yang layanan IB tidak punya waktu untuk merespons atau tidak melihat sama sekali:

• Log keamanan tidak ada. Ini adalah situasi yang cukup umum, terutama bagi pemula di pasar cloud. Tetapi mengakhiri mereka tidak berarti. Pemain kecil, terutama yang domestik, lebih sensitif terhadap persyaratan pelanggan dan dapat dengan cepat menerapkan beberapa fungsi yang diminta dengan mengubah peta jalan yang disetujui untuk produk mereka. Ya, itu tidak akan menjadi analog GuardDuty dari Amazon atau modul Proactive Defense dari Bitrix, tetapi setidaknya sesuatu.
• IB tidak tahu di mana log disimpan atau tidak ada akses ke sana. Di sini perlu untuk mengadakan negosiasi dengan penyedia layanan cloud - mungkin dia akan memberikan informasi seperti itu jika dia menganggap klien itu penting untuk dirinya sendiri. Tetapi secara umum, ini tidak terlalu baik ketika akses ke log disediakan "oleh keputusan khusus".
• Ini juga terjadi bahwa penyedia cloud memiliki log, tetapi mereka menyediakan pemantauan terbatas dan pencatatan peristiwa, tidak cukup untuk mendeteksi semua insiden. Misalnya, Anda hanya dapat diberikan log perubahan di situs atau log upaya untuk mengautentikasi pengguna, tetapi mereka tidak dapat memberikan acara lain, misalnya, tentang lalu lintas jaringan, yang akan menyembunyikan dari Anda seluruh lapisan peristiwa yang mencirikan upaya untuk membobol infrastruktur cloud Anda.
• Ada log, tetapi akses ke mereka sulit untuk diotomatisasi, yang membuatnya memantau tidak terus-menerus, tetapi sesuai jadwal. Dan jika Anda masih tidak dapat mengunduh log dalam mode otomatis, kemudian mengunggah log, misalnya, dalam format Excel (seperti dengan beberapa penyedia solusi cloud domestik), sepenuhnya dapat menyebabkan keengganan untuk mengacaukannya dari layanan IS perusahaan.
• Tidak ada pemantauan log. Ini mungkin adalah alasan yang paling tidak bisa dipahami untuk terjadinya insiden keamanan informasi di lingkungan cloud. Tampaknya ada log, dan Anda dapat mengotomatiskan akses ke sana, tetapi tidak ada yang melakukannya. Mengapa

Konsep Keamanan Bersama Cloud

Pindah ke awan selalu mencari keseimbangan antara keinginan untuk mempertahankan kontrol atas infrastruktur dan mentransfernya ke tangan yang lebih profesional dari penyedia cloud, yang berspesialisasi dalam mempertahankannya. Dan di bidang keamanan cloud, keseimbangan ini juga harus dicari. Selain itu, tergantung pada model yang digunakan untuk menyediakan layanan cloud (IaaS, PaaS, SaaS), keseimbangan ini akan selalu berbeda. Dalam situasi apa pun, kita harus ingat bahwa hari ini semua penyedia cloud mengikuti apa yang disebut tanggung jawab bersama dan model keamanan informasi bersama. Cloud bertanggung jawab atas sesuatu, klien bertanggung jawab atas sesuatu, setelah menempatkan datanya, aplikasinya, mesin virtualnya, dan sumber daya lainnya di cloud. Sungguh bodoh berharap bahwa setelah pergi ke cloud, kami akan mengalihkan semua tanggung jawab kepada penyedia. Tetapi untuk membangun semua keamanan sendiri ketika pindah ke cloud juga tidak masuk akal. Diperlukan keseimbangan, yang akan tergantung pada banyak faktor: - strategi manajemen risiko, model ancaman yang tersedia bagi penyedia cloud mekanisme pertahanan, 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 dengan pelanggan. Tapi semua yang ada di antara data dan infrastruktur fisik justru menjadi bahan diskusi dalam artikel ini. Misalnya, ketersediaan cloud adalah tanggung jawab penyedia, dan pengaturan aturan ITU atau enkripsi yang diaktifkan adalah tanggung jawab klien. Dalam artikel ini, kami akan mencoba melihat mekanisme pemantauan keamanan informasi seperti apa yang disediakan oleh berbagai penyedia cloud yang populer di Rusia saat ini, apa saja fitur aplikasi mereka, dan kapan harus melihat ke arah solusi overlay eksternal (misalnya, Cisco E-mail Security) yang memperluas kemampuan cloud Anda sebagian keamanan siber. Dalam beberapa kasus, terutama ketika mengikuti strategi multi-cloud, Anda tidak akan punya pilihan selain menggunakan solusi pemantauan keamanan eksternal di beberapa lingkungan cloud sekaligus (misalnya, Cisco CloudLock atau Cisco Stealthwatch Cloud). Nah, dalam beberapa kasus, Anda akan memahami bahwa penyedia cloud yang Anda pilih (atau paksakan pada Anda) sama sekali tidak menawarkan opsi untuk memantau keamanan informasi. Ini tidak menyenangkan, tetapi juga banyak, karena memungkinkan Anda untuk menilai secara memadai tingkat risiko yang terkait dengan bekerja dengan cloud ini.

Keamanan Cloud Memantau Siklus Hidup

Untuk memantau keamanan awan yang Anda gunakan, Anda hanya memiliki tiga opsi:

• mengandalkan alat yang disediakan oleh penyedia cloud Anda,
• Manfaatkan solusi pihak ketiga yang akan memantau platform IaaS, PaaS atau SaaS yang Anda gunakan,
• Bangun infrastruktur pemantauan cloud Anda sendiri (hanya platform IaaS / PaaS).

Mari kita lihat fitur apa yang dimiliki masing-masing opsi ini. Tetapi pertama-tama, kita perlu memahami skema umum yang akan digunakan dalam memonitor platform cloud. Saya akan menyoroti 6 komponen utama dari proses pemantauan keamanan informasi di cloud:

• Persiapan infrastruktur. Identifikasi aplikasi dan infrastruktur yang diperlukan untuk mengumpulkan acara yang penting untuk keamanan informasi di repositori.
• Koleksi Pada tahap ini, peristiwa keamanan dikumpulkan dari berbagai sumber untuk transmisi selanjutnya ke pemrosesan, penyimpanan, dan analisis.
• Pengolahan Pada titik ini, data ditransformasikan dan diperkaya untuk memudahkan analisis selanjutnya.
• Penyimpanan. Komponen ini bertanggung jawab untuk penyimpanan jangka pendek dan jangka panjang dari data yang diproses dan mentah yang dikumpulkan.
• Analisis. Pada tahap ini, Anda memiliki kemampuan untuk mendeteksi insiden dan meresponsnya secara otomatis atau manual.
• Pelaporan Tahap ini membantu menghasilkan indikator utama untuk pihak yang berkepentingan (manajemen, auditor, penyedia cloud, pelanggan, dll.) Yang membantu kami membuat keputusan tertentu, misalnya mengubah penyedia atau memperkuat IS.

Memahami komponen-komponen ini akan memungkinkan Anda untuk dengan cepat menentukan apa yang bisa Anda dapatkan dari penyedia Anda, dan apa yang harus Anda lakukan sendiri atau dengan bantuan konsultan eksternal.

Layanan Cloud bawaan

Saya sudah menulis di atas bahwa begitu banyak layanan cloud saat ini tidak memberikan kemungkinan untuk memantau keamanan informasi. Secara umum, mereka tidak terlalu memperhatikan topik keamanan informasi. Misalnya, salah satu layanan populer Rusia untuk mengirim laporan ke lembaga pemerintah melalui Internet (saya tidak akan secara spesifik menyebutkan namanya). Seluruh bagian keamanan layanan ini berkisar pada penggunaan alat perlindungan informasi kriptografi bersertifikat. Bagian keamanan informasi dari layanan cloud domestik lainnya untuk manajemen dokumen elektronik bukan contoh lagi. Ini berbicara tentang sertifikat kunci publik, kriptografi bersertifikat, menghilangkan kerentanan web, melindungi terhadap serangan DDoS, menerapkan ITU, mencadangkan, dan bahkan melakukan audit IS reguler. Tetapi tidak sepatah kata pun tentang pemantauan, atau tentang kemungkinan mendapatkan akses ke peristiwa keamanan informasi yang mungkin menarik bagi pelanggan penyedia layanan ini.

Secara umum, dengan cara penyedia cloud menggambarkan masalah keamanan informasi di situs webnya dan dalam dokumentasi, orang dapat memahami seberapa serius ia biasanya menangani masalah ini. Misalnya, jika Anda membaca manual untuk produk My Office, maka tidak ada kata sama sekali tentang keamanan sama sekali, dan dokumentasi untuk produk terpisah My Office. KS3 ", yang dirancang untuk melindungi terhadap akses yang tidak sah, adalah penghitungan umum klausul urutan ke-17 FSTEC, yang mengeksekusi" Kantor saya. KS3 ", tetapi tidak dijelaskan bagaimana kinerjanya dan, yang paling penting, bagaimana mengintegrasikan mekanisme ini dengan keamanan informasi perusahaan. Mungkin dokumentasi semacam itu ada di sana, tetapi saya tidak menemukannya di domain publik di situs My Office. Meskipun mungkin saya hanya tidak memiliki akses ke informasi rahasia ini? ..



Situasi Bitrix yang sama jauh lebih baik. Dokumentasi menjelaskan format log peristiwa dan, yang menarik, log intrusi, yang berisi peristiwa yang terkait dengan ancaman potensial terhadap platform cloud. Dari sana Anda bisa mendapatkan IP, nama pengguna atau nama tamu, sumber acara, waktu, Agen Pengguna, jenis acara, dll. Benar, Anda dapat bekerja dengan acara ini baik dari panel kontrol cloud itu sendiri atau mengunggah data dalam format MS Excel. Sulit untuk mengotomatiskan pekerjaan dengan log Bitrix sekarang dan Anda harus melakukan bagian dari pekerjaan secara manual (mengunggah laporan dan memuatnya ke SIEM Anda). Tetapi jika Anda mengingatnya sampai relatif baru-baru ini, dan ini tidak mungkin, maka ini adalah kemajuan besar. Pada saat yang sama, saya ingin mencatat bahwa banyak penyedia cloud asing menawarkan fungsionalitas serupa "untuk pemula" - baik melihat log dengan mata Anda melalui panel kontrol, atau mengunggah data ke diri Anda sendiri (meskipun sebagian besar mengunggah data dalam format .csv, bukan Excel).



Jika Anda tidak mempertimbangkan opsi tanpa log, maka penyedia cloud biasanya menawarkan tiga opsi untuk memantau peristiwa keamanan - dasbor, mengunggah data, dan mengaksesnya melalui API. Yang pertama tampaknya menyelesaikan banyak masalah untuk Anda, tetapi ini tidak sepenuhnya benar - jika ada beberapa majalah, Anda harus beralih di antara layar yang menampilkannya, kehilangan gambaran besarnya. Selain itu, penyedia cloud tidak mungkin memberi Anda kesempatan 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. Akhirnya, ada baiknya bertanya, peristiwa apa yang dicatat oleh penyedia cloud Anda, dalam format apa, dan berapa banyak yang sesuai dengan proses pemantauan IS Anda? Misalnya, identifikasi dan otentikasi pengguna dan tamu. Bitrix yang sama memungkinkan Anda untuk merekam tanggal dan waktu acara ini, nama pengguna atau tamu (di hadapan modul Web Analytics), objek tempat akses dibuat, dan elemen lain yang khas dari situs web untuk acara ini. Tetapi layanan IS perusahaan mungkin memerlukan informasi tentang apakah pengguna telah masuk ke cloud dari perangkat tepercaya (misalnya, dalam jaringan perusahaan, Cisco ISE mengimplementasikan tugas ini). Dan tugas sederhana seperti fungsi geo-IP, yang akan membantu menentukan apakah akun pengguna layanan cloud dicuri? Dan bahkan jika penyedia cloud menyediakannya untuk Anda, maka 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 melacak berbagai anomali dalam upaya untuk mengidentifikasi dan mengotentikasi. Hanya MS Azure yang memiliki fungsi serupa (jika ada langganan yang sesuai).



Ada satu kesulitan lagi - karena bagi banyak penyedia cloud pemantauan IS adalah topik baru yang baru mereka mulai tangani, mereka terus-menerus mengubah sesuatu dalam keputusan mereka. Hari ini mereka memiliki satu versi API, besok yang lain, lusa ketiga. Seseorang juga harus siap untuk ini. Hal yang sama dengan fungsi yang dapat berubah, yang harus diperhitungkan dalam sistem pemantauan keamanan informasi Anda. Sebagai contoh, Amazon awalnya memiliki layanan pemantauan acara cloud yang terpisah - AWS CloudTrail dan AWS CloudWatch. Kemudian datang layanan pemantauan acara IS terpisah - AWS GuardDuty. Setelah beberapa waktu, Amazon meluncurkan sistem manajemen Hub Keamanan Amazon baru, yang mencakup analisis data yang diterima dari GuardDuty, Inspektur Amazon, Amazon Macie dan beberapa lainnya. Contoh lain adalah alat integrasi log Azure dengan SIEM - AzLog. Banyak vendor SIEM yang secara aktif menggunakannya, hingga pada 2018 Microsoft mengumumkan penghentian pengembangan dan dukungannya, yang menempatkan banyak pelanggan yang menggunakan alat ini sebelum masalah (seperti yang diselesaikan, kami akan berbicara lebih lanjut).

Karenanya, pantau dengan cermat semua fungsi pemantauan yang ditawarkan penyedia cloud Anda. Atau percaya penyedia solusi eksternal yang akan bertindak sebagai perantara antara SOC Anda dan cloud yang ingin Anda pantau. Ya, itu akan lebih mahal (meskipun tidak selalu), tetapi kemudian Anda akan mengalihkan semua tanggung jawab ke pundak orang lain. Atau tidak semua? .. Ingat konsep keamanan bersama dan pahami bahwa kami tidak dapat mengubah apa pun - Anda harus mengetahui bagaimana penyedia cloud yang berbeda menyediakan pemantauan keamanan informasi data, aplikasi, mesin virtual, dan sumber daya lainnya yang berada di cloud. Dan kita akan mulai dengan apa yang Amazon tawarkan di bagian ini.

Contoh: Pemantauan Keamanan di IaaS berbasis AWS

Ya, ya, saya mengerti bahwa Amazon bukan contoh terbaik mengingat fakta bahwa itu adalah layanan Amerika dan dapat diblokir sebagai bagian dari perang melawan ekstremisme dan penyebaran informasi yang dilarang di Rusia. Tetapi dalam publikasi ini, saya hanya ingin menunjukkan bagaimana platform cloud yang berbeda berbeda dalam kemampuan keamanan informasi dan apa yang harus Anda perhatikan ketika mentransfer proses utama Anda ke cloud dari sudut pandang keamanan. Nah, jika beberapa pengembang solusi cloud Rusia mendapatkan sesuatu yang berguna untuk diri mereka sendiri, maka itu akan menjadi hebat.



Pertama saya harus mengatakan bahwa Amazon bukanlah benteng yang tidak dapat ditembus. Berbagai insiden sering terjadi pada kliennya. Misalnya, nama, alamat, tanggal lahir, dan telepon dari 198 juta pemilih dicuri dari Deep Root Analytics. 14 juta catatan berlangganan Verizon dicuri dari Nice Systems, Israel Pada saat yang sama, kemampuan bawaan AWS memungkinkan Anda mendeteksi berbagai insiden. Sebagai contoh:

• Pengaruh pada Infrastruktur (DDoS)
• simpul kompromi (injeksi perintah)
• kompromi akun dan akses tidak sah
• kesalahan konfigurasi dan kerentanan
• antarmuka dan API yang tidak dilindungi.

Perbedaan ini disebabkan oleh fakta bahwa pelanggan sendiri bertanggung jawab atas keamanan data pelanggan, seperti yang kami temukan di atas. Dan jika dia tidak khawatir tentang dimasukkannya mekanisme perlindungan dan tidak termasuk alat pemantauan, maka dia akan belajar tentang insiden itu hanya dari media atau dari kliennya.

Untuk mendeteksi insiden, Anda dapat menggunakan berbagai layanan pemantauan yang dikembangkan oleh Amazon (meskipun mereka sering dilengkapi dengan alat eksternal, seperti osquery). Jadi, di AWS, semua tindakan pengguna dilacak, terlepas dari bagaimana tindakan itu dilakukan - melalui konsol manajemen, baris perintah, SDK, atau layanan AWS lainnya. Semua catatan tindakan setiap akun AWS (termasuk nama pengguna, tindakan, layanan, parameter aktivitas, dan hasilnya) dan penggunaan API tersedia melalui AWS CloudTrail. Anda dapat melihat peristiwa ini (misalnya, masuk ke konsol AWS IAM) dari konsol CloudTrail, menganalisisnya menggunakan Amazon Athena, atau "memberikan" mereka ke solusi eksternal, seperti Splunk, AlienVault, dll. Log AWS CloudTrail sendiri ditempatkan di bucket AWS S3 Anda.



Dua layanan AWS lainnya menyediakan beberapa kemampuan pemantauan yang lebih penting. Pertama, Amazon CloudWatch adalah sumber daya AWS dan layanan pemantauan aplikasi yang, antara lain, dapat mendeteksi berbagai anomali di cloud Anda. Semua layanan AWS bawaan, seperti Amazon Elastic Compute Cloud (server), Layanan Database Relasional Amazon (database), Amazon Elastic MapReduce (analisis data) dan 30 layanan Amazon lainnya, menggunakan Amazon CloudWatch untuk menyimpan log mereka. Pengembang dapat menggunakan Amazon CloudWatch open API untuk menambahkan fungsionalitas pemantauan log ke aplikasi dan layanan pengguna, yang memungkinkan perluasan rentang peristiwa yang dianalisis dalam konteks keamanan informasi.



Kedua, layanan VPC Flow Logs memungkinkan Anda untuk menganalisis lalu lintas jaringan yang dikirim atau diterima oleh server AWS Anda (secara eksternal atau internal), serta antar-layanan Microsoft. Ketika salah satu sumber daya AWS VPC Anda berinteraksi dengan jaringan, layanan VPC Flow Logs mencatat informasi lalu lintas jaringan, termasuk antarmuka jaringan sumber dan tujuan, serta alamat IP, port, protokol, jumlah byte, dan jumlah paket yang Anda lihat. Mereka yang memiliki pengalaman keamanan jaringan lokal mengenali ini sebagai analog dari aliran NetFlow .yang dapat dibuat oleh sakelar, router, dan firewall tingkat perusahaan. Log ini penting untuk pemantauan keamanan informasi karena, tidak seperti aktivitas aktivitas pengguna dan aplikasi, mereka juga memungkinkan Anda untuk tidak ketinggalan komunikasi jaringan di lingkungan cloud pribadi virtual AWS.



Dengan demikian, ketiga layanan AWS ini - AWS CloudTrail, Amazon CloudWatch, dan VPC Flow Logs - bersama-sama memberikan pandangan yang cukup efektif tentang penggunaan akun Anda, perilaku pengguna, manajemen infrastruktur, aktivitas aplikasi dan layanan, dan aktivitas jaringan. Misalnya, mereka dapat digunakan untuk mendeteksi anomali berikut:

• Mencoba memindai situs, mencari backdoors, mencari kerentanan melalui semburan "404 kesalahan".
• Injection- (, SQL injection) “ 500”.
• sqlmap, nikto, w3af, nmap .. User Agent.

Amazon Web Services juga telah mengembangkan layanan lain untuk cybersecurity yang menangani banyak tantangan lain. Misalnya, AWS memiliki layanan bawaan untuk kebijakan dan konfigurasi audit - AWS Config. Layanan ini menyediakan audit terus menerus atas sumber daya AWS Anda dan konfigurasinya. Pertimbangkan contoh sederhana: misalkan Anda ingin memastikan bahwa kata sandi pengguna dinonaktifkan pada semua server Anda dan akses hanya dimungkinkan berdasarkan sertifikat. AWS Config memudahkan verifikasi ini untuk semua server Anda. Ada kebijakan lain yang dapat diterapkan ke 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 ia dapat melakukan ini hanya pada hari Selasa. "Pada musim panas 2016, AWS Config diperluas untuk mengotomatiskan deteksi pelanggaran kebijakan yang dikembangkan. AWS Config Rules adalah, pada dasarnya, permintaan konfigurasi berkelanjutan untuk layanan Amazon yang Anda gunakan, yang menghasilkan peristiwa jika terjadi pelanggaran terhadap kebijakan yang relevan. Misalnya, alih-alih secara berkala menjalankan permintaan AWS Config untuk memverifikasi bahwa semua drive server virtual dienkripsi, Aturan Konfigurasi AWS dapat digunakan untuk terus-menerus memeriksa drive server untuk kondisi ini. Dan, yang paling penting, dalam konteks publikasi ini, setiap pelanggaran menghasilkan peristiwa yang dapat dianalisis oleh layanan IS Anda.Permintaan konfigurasi berkelanjutan untuk layanan Amazon yang Anda gunakan yang menghasilkan peristiwa ketika kebijakan dilanggar. Misalnya, alih-alih secara berkala menjalankan permintaan AWS Config untuk memverifikasi bahwa semua drive server virtual dienkripsi, Aturan Konfigurasi AWS dapat digunakan untuk terus-menerus memeriksa drive server untuk kondisi ini. Dan, yang paling penting, dalam konteks publikasi ini, setiap pelanggaran menghasilkan peristiwa yang dapat dianalisis oleh layanan IS Anda.Permintaan konfigurasi berkelanjutan untuk layanan Amazon yang Anda gunakan yang menghasilkan peristiwa ketika kebijakan dilanggar. Misalnya, alih-alih secara berkala menjalankan permintaan AWS Config untuk memverifikasi bahwa semua drive server virtual dienkripsi, Aturan Konfigurasi AWS dapat digunakan untuk terus-menerus memeriksa drive server untuk kondisi ini. Dan, yang paling penting, dalam konteks publikasi ini, setiap pelanggaran menghasilkan peristiwa yang dapat dianalisis oleh layanan IS Anda.AWS Config Rules dapat digunakan untuk memeriksa disk server secara konstan untuk kondisi ini. Dan, yang paling penting, dalam konteks publikasi ini, setiap pelanggaran menghasilkan peristiwa yang dapat dianalisis oleh layanan IS Anda.AWS Config Rules dapat digunakan untuk memeriksa disk server secara konstan untuk kondisi ini. Dan, yang paling penting, dalam konteks publikasi ini, setiap pelanggaran menghasilkan peristiwa yang dapat dianalisis oleh layanan IS Anda.



AWS juga memiliki padanannya dengan solusi keamanan informasi perusahaan tradisional yang juga menghasilkan peristiwa keamanan yang dapat dan harus Anda analisis:

• Deteksi intrusi - AWS GuardDuty
• kontrol kebocoran - AWS Macie
• EDR (meskipun berbicara tentang titik akhir di cloud agak aneh) - AWS Cloudwatch + osquery open source atau solusi GRR
• Analisis Netflow - AWS Cloudwatch + AWS VPC Flow
• Analisis DNS - AWS Cloudwatch + AWS Route53
• Layanan Direktori AD-AWS
• Manajemen Akun - AWS IAM
• SSO - AWS SSO
• analisis keamanan - Inspektur AWS
• manajemen konfigurasi - AWS Config
• WAF - AWS WAF.

Saya tidak akan merinci semua layanan Amazon yang mungkin berguna dalam konteks keamanan informasi. Hal utama yang harus dipahami adalah bahwa mereka semua dapat menghasilkan peristiwa yang dapat dan harus kita analisis dalam konteks keamanan informasi, yang melibatkan untuk ini kemampuan bawaan Amazon dan solusi eksternal, misalnya, SIEM, yang dapat membawa acara keamanan ke pusat pemantauan Anda dan menganalisisnya di sana bersama dengan peristiwa dari layanan cloud lain atau dari infrastruktur internal, perimeter, atau perangkat seluler.



Bagaimanapun, semuanya dimulai dengan sumber data yang memberi Anda peristiwa IB. Sumber-sumber tersebut termasuk, tetapi tidak terbatas pada:

• CloudTrail - Penggunaan API dan Tindakan Pengguna
• Penasihat Tepercaya - Pemeriksaan Keamanan untuk Praktik Terbaik
• Config —
• VPC Flow Logs —
• IAM —
• ELB Access Logs —
• Inspector —
• S3 —
• CloudWatch —
• SNS — .

Amazon, yang menawarkan berbagai sumber acara dan alat untuk generasi mereka, sangat terbatas dalam kemampuannya untuk menganalisis data yang dikumpulkan dalam konteks keamanan informasi. Anda harus mempelajari log yang tersedia secara independen, mencari indikator kompromi yang sesuai di dalamnya. AWS Security Hub, yang baru saja diluncurkan Amazon, bertujuan untuk menyelesaikan masalah ini dengan menjadi semacam SIEM berbasis cloud untuk AWS. Tetapi sementara itu hanya pada awal perjalanannya dan dibatasi baik oleh jumlah sumber yang digunakannya, dan oleh pembatasan lain yang ditetapkan oleh arsitektur dan langganan Amazon itu sendiri.

Contoh: Memantau IS di IaaS berbasis Azure

Saya tidak ingin terlibat dalam perdebatan panjang tentang mana dari tiga penyedia cloud (Amazon, Microsoft atau Google) mana yang lebih baik (terutama karena masing-masing dari mereka memiliki karakteristik khusus dan cocok untuk menyelesaikan masalahnya); fokus pada kemampuan pemantauan keamanan yang diberikan oleh para pemain ini. Diakui, Amazon AWS adalah salah satu yang pertama di segmen ini dan karena itu telah maju paling jauh dalam hal fungsi keamanan informasinya (walaupun banyak yang mengakui bahwa menggunakannya sangat sulit). Tetapi ini tidak berarti bahwa kita akan mengabaikan peluang yang ditawarkan Microsoft kepada kita dengan Google.

Produk Microsoft selalu dibedakan oleh "keterbukaan" mereka dan di Azure situasinya serupa. Misalnya, jika AWS dan GCP selalu berasal dari konsep "segala sesuatu yang tidak diperbolehkan dilarang," maka Azure memiliki pendekatan yang berlawanan. Misalnya, membuat jaringan virtual di cloud dan mesin virtual di dalamnya, semua port dan protokol terbuka dan diaktifkan secara default. Oleh karena itu, Anda harus meluangkan sedikit usaha lebih banyak pada pengaturan awal sistem kontrol akses di cloud dari Microsoft. Dan ini juga memberlakukan persyaratan yang lebih ketat pada Anda dalam hal aktivitas pemantauan di Azure cloud.



AWS memiliki kekhasan terkait dengan fakta bahwa ketika Anda memonitor sumber daya virtual Anda, maka jika mereka berada di daerah yang berbeda, maka Anda memiliki kesulitan dalam menggabungkan semua peristiwa dan analisis tunggal mereka, untuk menghilangkan yang Anda butuhkan untuk menggunakan berbagai trik, seperti Buat kode khusus untuk AWS Lambda yang akan membawa acara antar wilayah. Tidak ada masalah seperti itu di Azure - mekanisme Log Aktivitas memonitor 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 tunggal, tetapi hanya di dalam wilayahnya, yang, bagaimanapun, tidak relevan untuk Rusia. Azure memiliki Pusat Keamanan sendiri, yang tidak terikat oleh batasan regional,menyediakan akses ke semua fitur keamanan platform cloud. Selain itu, untuk berbagai tim lokal, ia dapat memberikan kemampuan defensif sendiri, termasuk acara keamanan yang dikelola oleh mereka. AWS Security Hub masih berusaha untuk menjadi seperti Azure Security Center. Tapi ada baiknya menambahkan lalat di salep - Anda dapat memeras banyak hal yang sebelumnya dijelaskan dalam AWS dari Azure, tetapi ini paling mudah dilakukan hanya untuk Azure AD, Azure Monitor, dan Azure Security Center. Semua mekanisme pertahanan Azure lainnya, termasuk analisis peristiwa keamanan, belum dikelola dengan cara yang paling nyaman. Sebagian dari masalah diselesaikan oleh API yang menembus semua layanan Microsoft Azure, tetapi ini akan membutuhkan upaya tambahan untuk mengintegrasikan cloud Anda dengan SOC Anda dan ketersediaan spesialis yang berkualifikasi (pada kenyataannya,seperti yang lainnya. SIEM bekerja dengan cloud APIs). Beberapa SIEM, yang akan dibahas nanti, sudah mendukung Azure dan dapat mengotomatiskan tugas pemantauannya, tetapi ada beberapa kesulitan dengan itu - tidak semua dari mereka dapat mengambil semua log yang dimiliki Azure.



Pengumpulan dan pemantauan acara di Azure disediakan menggunakan layanan Azure Monitor, yang merupakan alat utama untuk mengumpulkan, menyimpan, dan menganalisis data dalam cloud Microsoft dan sumber dayanya - Git repositori, wadah, mesin virtual, aplikasi, dll. Semua data yang dikumpulkan oleh Azure Monitor dibagi menjadi dua kategori: metrik real-time yang menggambarkan indikator kinerja utama dari awan Azure, dan log registrasi yang berisi data yang diatur dalam catatan yang mengkarakterisasi aspek-aspek tertentu dari aktivitas sumber daya dan layanan Azure. Selain itu, menggunakan API Pengumpul Data, layanan Monitor Azure dapat mengumpulkan data dari sumber REST apa pun untuk membuat skenario pemantauannya sendiri.



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

• Log Aktivitas - jurnal ini menjawab pertanyaan klasik "siapa", "apa" dan "kapan" tentang operasi penulisan apa pun (PUT, POST, DELETE) melalui sumber daya cloud. Peristiwa yang terkait dengan akses baca (GET) tidak termasuk dalam log ini, serta sejumlah lainnya.
• Log Diagnostik - berisi data tentang operasi dengan sumber daya tertentu yang termasuk dalam langganan Anda.
• Pelaporan Azure AD - berisi aktivitas pengguna dan aktivitas sistem yang terkait dengan manajemen grup dan pengguna.
• Windows Event Log dan Linux Syslog - berisi acara dari mesin virtual yang dihosting di cloud.
• Metrics — “” . . 30 .
• Network Security Group Flow Logs — , Network Watcher .
• Storage Logs — , .

Untuk pemantauan, Anda dapat menggunakan SIEM eksternal atau Monitor Azure bawaan dan ekstensinya. Kami akan berbicara lebih banyak tentang sistem manajemen acara IS, tetapi untuk saat ini kami akan melihat apa yang Azure tawarkan kepada kami untuk menganalisis data dalam konteks keamanan. Layar utama untuk segala sesuatu yang berkaitan dengan keamanan di Azure Monitor adalah Log Analytics Security dan Audit Dashboard (versi gratis mendukung penyimpanan sejumlah peristiwa terbatas hanya dalam satu minggu). Panel ini dibagi menjadi 5 area utama yang memvisualisasikan statistik ringkasan tentang apa yang terjadi di lingkungan cloud Anda:

• Domain Keamanan - indikator kuantitatif utama yang terkait dengan keamanan informasi - jumlah insiden, jumlah node yang dikompromikan, node yang tidak ditambal, peristiwa keamanan jaringan, dll.
• Masalah Penting - Menampilkan jumlah dan pentingnya masalah IB aktif
• Detections — ,
• Threat Intelligence — ,
• Common security queries — , .

Ekstensi Azure Monitor meliputi Azure Key Vault (perlindungan kunci kriptografi di cloud), Malware Assessment (analisis perlindungan terhadap kode berbahaya pada mesin virtual), Azure Application Gateway Analytics (analisis, antara lain, log firewall cloud), dll. . Alat-alat ini, yang diperkaya oleh aturan pemrosesan acara, memungkinkan Anda memvisualisasikan berbagai aspek aktivitas layanan cloud, termasuk keamanan, dan untuk mengidentifikasi penyimpangan tertentu dari pekerjaan. Tetapi, seperti yang sering terjadi, fungsi tambahan apa pun membutuhkan langganan berbayar yang sesuai, yang akan mengharuskan Anda untuk melakukan investasi keuangan yang sesuai, yang perlu Anda rencanakan sebelumnya.



Azure memiliki sejumlah kemampuan pemantauan ancaman bawaan yang terintegrasi ke dalam Azure AD, Azure Monitor, dan Pusat Keamanan Azure. Diantaranya, misalnya, mendeteksi interaksi mesin virtual dengan IP jahat yang dikenal (karena integrasi dengan layanan Microsoft Threat Intelligence), mendeteksi malware di infrastruktur cloud dengan menerima alarm dari mesin virtual yang terletak di cloud, serangan seperti “tebak kata sandi” ”Untuk mesin virtual, kerentanan dalam konfigurasi sistem identifikasi pengguna, masuk dari anonimis atau simpul yang terinfeksi, kebocoran akun, masuk dari lokasi yang tidak biasa, dll. Azure hari ini adalah salah satu dari sedikit penyedia cloud yang menawarkan kemampuan Intelijen Ancaman bawaan untuk memperkaya acara keamanan informasi yang dikumpulkan.



Seperti disebutkan di atas, fungsi pelindung dan, sebagai konsekuensinya, peristiwa keamanan yang dihasilkannya tidak dapat diakses oleh semua pengguna secara setara, tetapi memerlukan langganan tertentu yang mencakup fungsionalitas yang Anda butuhkan, yang menghasilkan peristiwa terkait untuk memantau keamanan informasi. Misalnya, beberapa fungsi untuk memantau anomali dalam akun yang dijelaskan dalam paragraf sebelumnya hanya tersedia dalam lisensi premium P2 untuk Azure AD. Tanpa itu, Anda, seperti dalam kasus AWS, harus menganalisis peristiwa keamanan yang dikumpulkan "secara manual". Dan, juga, tergantung pada jenis lisensi untuk Azure AD, tidak semua acara untuk analisis akan tersedia untuk Anda.

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



Jika Anda tidak hanya membutuhkan kemampuan untuk bekerja dengan log, tetapi pusat keamanan komprehensif platform cloud Azure Anda, termasuk mengelola kebijakan IS, maka Anda dapat berbicara tentang perlunya bekerja dengan Azure Security Center, yang sebagian besar berguna untuk bayaran, misalnya, deteksi ancaman, pemantauan di luar Azure, penilaian kesesuaian, dll. (Dalam versi gratis, Anda hanya memiliki akses ke penilaian keamanan dan rekomendasi untuk menyelesaikan masalah yang diidentifikasi). Ini mengkonsolidasikan semua masalah keamanan di satu tempat. Bahkan, kita dapat berbicara tentang tingkat keamanan informasi yang lebih tinggi daripada yang disediakan Azure Monitor, karena dalam hal ini data yang dikumpulkan di seluruh pabrik cloud Anda diperkaya menggunakan berbagai sumber, seperti Azure, Office 365, Microsoft CRM online, Microsoft Dynamics AX, prospek .com, MSN.com, Microsoft Digital Crimes Unit (DCU) dan Microsoft Security Response Center (MSRC), yang ditumpangkan pada berbagai pembelajaran mesin canggih dan algoritma analitik perilaku, yang pada akhirnya harus meningkatkan efisiensi deteksi ancaman dan respons.

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



Tetapi karena kemampuan bawaan Azure (bahkan dengan langganan Sentinel) seringkali tidak cukup untuk pemantauan IS dan integrasi proses ini dengan sumber acara keamanan lainnya (baik cloud dan internal), ada kebutuhan untuk mengekspor data yang dikumpulkan ke sistem eksternal, yang mungkin termasuk SIEM. Ini dilakukan baik dengan bantuan API, dan dengan bantuan ekstensi khusus yang secara resmi tersedia saat ini hanya untuk SIEM berikut - Splunk (Pengaya Monitor Azure untuk Splunk), IBM QRBar (Microsoft Azure DSM), SumoLogic, ArcSight dan ELK. Baru-baru ini, terdapat lebih banyak SIEM seperti itu, tetapi mulai 1 Juni 2019 Microsoft berhenti mendukung Azure Log Integration Tool (AzLog), yang pada awal Azure dan dengan tidak adanya standardisasi normal bekerja dengan log (Azure Monitor bahkan tidak ada) membuatnya mudah Integrasikan SIEMs eksternal dengan Microsoft Cloud. Sekarang situasinya telah berubah dan Microsoft merekomendasikan platform Azure Event Hub sebagai alat integrasi utama untuk seluruh SIEM. Banyak yang sudah menerapkan integrasi ini, tetapi berhati-hatilah - mereka mungkin tidak menangkap semua log Azure, tetapi hanya beberapa (lihat dokumentasi untuk SIEM Anda).

Sebagai penutup kunjungan singkat ke Azure, saya ingin memberikan rekomendasi umum tentang layanan cloud ini - sebelum Anda mengatakan apa-apa tentang fungsi pemantauan keamanan di Azure, Anda harus mengonfigurasinya dengan sangat hati-hati dan menguji apakah mereka berfungsi seperti yang tertulis dalam dokumentasi dan seperti yang dikatakan oleh konsultan kepada Anda. Microsoft (dan mereka mungkin memiliki pandangan berbeda tentang kinerja fitur Azure). Jika Anda memiliki kemampuan finansial dari Azure, Anda dapat memeras banyak informasi berguna mengenai pemantauan keamanan informasi. Jika sumber daya Anda terbatas, seperti dalam kasus AWS, Anda harus hanya mengandalkan sumber daya Anda sendiri dan data mentah yang disediakan oleh Azure Monitor. Dan ingat bahwa banyak fungsi pemantauan membutuhkan biaya dan lebih baik untuk membiasakan diri dengan harga di muka. Misalnya, Anda dapat menyimpan data selama 31 hari tanpa lebih dari 5 GB per pelanggan secara gratis - melebihi nilai-nilai ini akan mengharuskan Anda untuk membayar tambahan (sekitar $ 2+ untuk menyimpan setiap GB tambahan dari pelanggan dan $ 0,1 untuk 1 GB setiap bulan tambahan) ) Bekerja dengan telemetri dan metrik aplikasi mungkin juga memerlukan sumber daya keuangan tambahan, serta bekerja dengan peringatan dan pemberitahuan (batas tertentu tersedia secara gratis, yang mungkin tidak cukup untuk kebutuhan Anda).

Contoh: Pemantauan IS di IaaS berdasarkan Google Cloud Platform

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



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

• Aktivitas Admin - berisi semua peristiwa yang terkait dengan akses administratif, misalnya, pembuatan mesin virtual, perubahan hak akses, dll. Jurnal ini selalu ditulis, terlepas dari keinginan Anda, dan menyimpan datanya selama 400 hari.
• Akses Data - berisi semua peristiwa yang terkait dengan bekerja dengan data dari pengguna cloud (buat, ubah, baca, dll.). Secara default, jurnal ini tidak ditulis, karena volumenya membengkak sangat cepat. Untuk alasan ini, umur simpannya hanya 30 hari. Selain itu, jauh dari semuanya ditulis dalam jurnal ini. Misalnya, peristiwa terkait dengan sumber daya yang tersedia untuk umum bagi semua pengguna atau yang dapat diakses tanpa akses ke GCP tidak ditulis untuk itu.
• System Event - 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.
• Access Transparency adalah contoh unik dari buku catatan yang mencatat semua tindakan karyawan Google (tetapi belum untuk semua layanan GCP) yang mendapatkan akses ke infrastruktur Anda sebagai bagian dari tanggung jawab pekerjaan mereka. Jurnal ini disimpan selama 400 hari dan tidak tersedia untuk setiap klien GCP, tetapi hanya tunduk pada sejumlah kondisi (baik dukungan Emas atau Platinum, atau keberadaan 4 peran dari jenis tertentu sebagai bagian dari dukungan perusahaan). Fitur serupa juga tersedia, misalnya, di Office 365 - Lockbox.

Contoh Log: Akses Transparansi

{  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-log ini dimungkinkan dalam beberapa cara (dengan cara yang hampir sama seperti yang sebelumnya dipertimbangkan oleh Azure dan AWS) - melalui antarmuka Penampil Log, melalui API, melalui Google Cloud SDK atau melalui halaman Aktivitas proyek Anda, yang menurutnya Anda tertarik dengan peristiwa. Dengan cara yang sama, mereka juga dapat diekspor ke solusi eksternal untuk analisis tambahan. Yang terakhir dilakukan dengan mengekspor log ke BigQuery atau Cloud Pub / Sub storage.

Selain Stackdriver Logging, platform GCP juga menawarkan fungsionalitas Stackdriver Monitoring, yang memungkinkan Anda untuk melacak metrik utama (kinerja, MTBF, status umum, dll.) Dari layanan dan aplikasi cloud. Data yang diproses dan divisualisasikan dapat membuatnya lebih mudah untuk menemukan masalah dalam infrastruktur cloud Anda, termasuk dalam konteks keamanan. Tetapi harus dicatat bahwa fungsi ini tidak akan sangat kaya justru dalam konteks keamanan informasi, karena hari ini GCP tidak memiliki analog dengan AWS GuardDuty yang sama dan tidak dapat membedakan yang buruk dari semua peristiwa yang direkam (Google mengembangkan Event Threat Detection, tetapi sejauh ini masih dalam versi beta dan bicarakan kegunaannya lebih awal). Pemantauan Stackdriver dapat digunakan sebagai sistem untuk mendeteksi anomali, yang kemudian akan diselidiki untuk menemukan penyebab terjadinya mereka. Tetapi dalam kondisi kekurangan personel yang berkualifikasi di bidang keamanan informasi GCP di pasar, tugas ini saat ini terlihat sulit.



Juga bermanfaat untuk mendaftar beberapa modul keamanan informasi yang dapat digunakan dalam cloud GCP Anda, dan yang serupa dengan apa yang ditawarkan AWS:

• Cloud Security Command Center adalah analog dari AWS Security Hub dan Azure Security Center.
• Cloud DLP - deteksi dan pengeditan otomatis (misalnya, masking) data yang terletak di cloud, menurut lebih dari 90 kebijakan klasifikasi yang telah ditentukan.
• Cloud Scanner adalah pemindai kerentanan yang diketahui (XSS, Flash Injection, pustaka yang belum ditambal, dll.) Di App Engine, Compute Engine, dan Google Kubernetes.
• Cloud IAM - kontrol akses ke semua sumber daya GCP.
• Cloud Identity - Kelola akun pengguna, perangkat, dan aplikasi GCP dari satu konsol.
• Cloud HSM - perlindungan kunci kriptografis.
• Layanan Manajemen Kunci Cloud - manajemen kunci kriptografis di GCP.
• Kontrol Layanan VPC - Buat batas aman di sekitar sumber daya GCP Anda untuk melindunginya dari kebocoran.
• Kunci Keamanan Titan - perlindungan terhadap phishing.

Banyak dari modul ini menghasilkan peristiwa keamanan yang dapat dikirim ke BigQuery untuk analisis atau ekspor ke sistem lain, termasuk SIEM. Seperti yang telah disebutkan di atas, GCP adalah platform yang dikembangkan secara aktif dan sekarang Google sedang mengembangkan sejumlah modul keamanan informasi baru untuk platformnya. Diantaranya adalah Event Threat Detection (sekarang tersedia dalam versi beta), yang memindai log Stackdriver untuk melacak aktivitas tidak sah (mirip dengan GuardDuty di AWS), atau Policy Intelligence (tersedia dalam alpha), yang akan memungkinkan pengembangan kebijakan akses cerdas ke sumber daya GCP.

Saya melakukan tinjauan singkat tentang kemampuan pemantauan built-in di platform cloud populer. Tetapi apakah Anda memiliki spesialis yang dapat bekerja dengan log mentah dari penyedia IaaS (tidak semua orang siap untuk membeli fitur canggih dari AWS atau Azure atau Google)? Selain itu, banyak orang tahu pepatah "kepercayaan, tetapi verifikasi", yang dalam bidang keamanan adalah benar seperti sebelumnya. Seberapa jauh Anda memercayai kemampuan bawaan penyedia cloud yang mengirimi Anda acara IB? Seberapa fokus mereka pada keamanan informasi?

Terkadang ada baiknya mencari solusi overlay untuk memantau infrastruktur cloud yang dapat melengkapi keamanan cloud bawaan, dan terkadang solusi seperti itu adalah satu-satunya cara untuk mendapatkan data tentang keamanan data Anda dan aplikasi yang berlokasi di cloud. Selain itu, mereka hanya lebih nyaman, karena mereka mengambil sendiri semua tugas menganalisis log yang diperlukan yang dihasilkan oleh berbagai layanan cloud dari penyedia cloud yang berbeda. Contoh dari solusi yang dipaksakan tersebut adalah Cisco Stealthwatch Cloud, yang berfokus pada satu-satunya tugas - memantau anomali IS di lingkungan cloud, termasuk tidak hanya Amazon AWS, Microsoft Azure dan Google Cloud Platform, tetapi juga cloud pribadi.

Contoh: Memantau Keamanan dengan Stealthwatch Cloud

AWS menyediakan platform komputasi yang fleksibel, tetapi fleksibilitas ini memudahkan perusahaan untuk membuat kesalahan yang mengarah pada masalah keamanan. Dan model IS bersama hanya berkontribusi untuk ini. Menjalankan perangkat lunak di cloud dengan kerentanan yang tidak diketahui (misalnya, AWS Inspector atau GCP Cloud Scanner dapat melawan kerentanan yang diketahui), kata sandi yang lemah, konfigurasi yang salah, orang dalam, dll. Dan semua ini mempengaruhi perilaku sumber daya cloud, yang dapat diamati oleh Cisco Stealthwatch Cloud, yang merupakan sistem untuk memantau keamanan informasi dan deteksi serangan. awan publik dan pribadi.



Salah satu fitur utama dari Cisco Stealthwatch Cloud adalah kemampuan untuk memodelkan entitas. Dengan bantuannya, Anda dapat membuat model program (yaitu, simulasi hampir real-time) dari masing-masing sumber daya cloud Anda (tidak masalah apakah itu AWS, Azure, GCP, atau yang lainnya). Ini mungkin termasuk server dan pengguna, serta tipe sumber daya khusus untuk lingkungan cloud Anda, seperti grup keamanan dan grup skala otomatis. Model-model ini menggunakan aliran data terstruktur yang disediakan oleh layanan cloud sebagai input. Misalnya, untuk AWS, ini akan menjadi VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspektur, AWS Lambda dan AWS IAM. Pemodelan entitas secara otomatis mendeteksi peran dan perilaku sumber daya Anda apa pun (Anda dapat berbicara tentang membuat profil semua aktivitas cloud). Di antara peran-peran ini adalah perangkat seluler Android atau Apple, server Citrix PVS, server RDP, gateway email, klien VoIP, terminal server, pengontrol domain, dll. Dia kemudian terus memantau perilaku mereka untuk menentukan kapan perilaku berisiko atau mengancam keselamatan terjadi. Anda dapat mengidentifikasi tebak kata sandi, serangan DDoS, kebocoran data, akses jarak jauh ilegal, kode berbahaya, pemindaian kerentanan, dan ancaman lainnya. Misalnya, inilah yang tampaknya mendeteksi upaya akses jarak jauh dari negara yang tidak lazim di organisasi Anda (Korea Selatan) ke kluster Kubernetes melalui SSH:



Dan inilah dugaan kebocoran informasi dari database Postgress ke negara yang sebelumnya tidak pernah berinteraksi dengan:



Akhirnya, ini adalah seberapa banyak upaya akses SSH yang gagal dari Cina dan Indonesia dari perangkat remote eksternal terlihat seperti:



Atau, anggap instance server dalam VPC, sesuai dengan kebijakan, seharusnya tidak pernah menjadi tujuan untuk login jarak jauh. Selanjutnya, asumsikan bahwa login jarak jauh telah terjadi pada komputer ini karena perubahan yang salah dalam kebijakan aturan firewall. Fitur pemodelan entitas akan mendeteksi dan melaporkan aktivitas ini ("Akses Jarak Jauh Tidak Biasa") dalam waktu dekat dan menunjuk ke AWS CloudTrail, Monitor Azure atau panggilan API Logging Stackdriver GCP (termasuk nama pengguna, tanggal dan waktu, di antara perincian lainnya), yang menyebabkan perubahan pada aturan ITU. Dan kemudian informasi ini dapat diberikan kepada SIEM untuk dianalisis.



Fitur serupa tersedia untuk setiap lingkungan cloud yang didukung oleh Cisco Stealthwatch Cloud:



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

• Apakah seseorang menemukan backdoor dalam perangkat lunak yang kami gunakan?
• Apakah ada perangkat lunak atau perangkat pihak ketiga di cloud kami?
• Apakah pengguna yang disalahgunakan memiliki hak istimewa?
• Apakah ada kesalahan konfigurasi yang memungkinkan akses jarak jauh atau penggunaan sumber daya lainnya secara tidak sengaja?
• Apakah ada kebocoran data dari server kami?
• Apakah seseorang mencoba terhubung dengan kami dari lokasi geografis yang tidak lazim?
• Apakah cloud kami terinfeksi kode berbahaya?

Acara IB yang terdeteksi dapat ditransmisikan dalam bentuk tiket yang sesuai ke Slack, Cisco Spark, sistem manajemen insiden PagerDuty, dan juga dikirim ke berbagai SIEM, termasuk Splunk atau ELK. Ringkasnya, kita dapat mengatakan bahwa jika perusahaan Anda menggunakan strategi multi-cloud dan tidak terbatas pada satu penyedia cloud, kemampuan pemantauan keamanan informasi yang dijelaskan di atas, kemudian menggunakan Cisco Stealthwatch Cloud adalah pilihan yang baik untuk mendapatkan seperangkat kemampuan pemantauan terpadu untuk pemain cloud terkemuka - Amazon , Microsoft dan Google. Yang paling menarik adalah jika Anda membandingkan harga Stealthwatch Cloud dengan lisensi pemantauan keamanan tingkat lanjut di AWS, Azure, atau GCP, mungkin solusi Cisco akan lebih murah daripada kapabilitas built-in solusi Amazon, Microsoft dan Google. Secara paradoks, memang begitu. Dan semakin banyak cloud dan kemampuan mereka yang Anda gunakan, semakin jelas akan menjadi keuntungan dari solusi gabungan.



Selain itu, Stealthwatch Cloud juga dapat memantau cloud pribadi yang digunakan di organisasi Anda, misalnya, berdasarkan wadah Kubernetes atau dengan memantau aliran Netflow atau lalu lintas jaringan yang diterima melalui mirroring dalam peralatan jaringan (bahkan produksi dalam negeri), data AD atau server DNS dll. Semua data ini akan diperkaya dengan informasi Threat Intelligence yang dikumpulkan oleh Cisco Talos, kelompok peneliti IS IS terbesar di dunia.



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

Ini menyimpulkan bagian pertama dari artikel di mana saya memeriksa alat internal dan eksternal untuk memantau platform IaaS / PaaS yang memungkinkan kita untuk dengan cepat mendeteksi dan menanggapi insiden di lingkungan cloud yang dipilih perusahaan kita. Pada bagian kedua, kami akan melanjutkan topik dan mempertimbangkan opsi pemantauan untuk platform SaaS menggunakan Salesforce dan Dropbox sebagai contoh, dan juga mencoba merangkum dan menyatukan semuanya, menciptakan sistem pemantauan keamanan informasi terpadu untuk penyedia cloud yang berbeda.