Rekomendasi untuk pengujian keamanan
Berlaku untuk rekomendasi daftar periksa Azure Well-Architected Framework Security ini:
| SE:11 | Tetapkan rejimen pengujian komprehensif yang menggabungkan pendekatan untuk mencegah masalah keamanan, memvalidasi implementasi pencegahan ancaman, dan menguji mekanisme deteksi ancaman. |
|---|
Pengujian ketat adalah fondasi desain keamanan yang baik. Pengujian adalah bentuk validasi taktis untuk memastikan kontrol berfungsi seperti yang diinginkan. Pengujian juga merupakan cara proaktif untuk mendeteksi kerentanan dalam sistem.
Menetapkan uji ketekunan melalui irama dan verifikasi dari berbagai perspektif. Anda harus menyertakan titik pandang luar yang menguji platform dan infrastruktur serta evaluasi luar-dalam yang menguji sistem seperti penyerang eksternal.
Panduan ini memberikan rekomendasi untuk menguji postur keamanan beban kerja Anda. Terapkan metode pengujian ini untuk meningkatkan ketahanan beban kerja Anda terhadap serangan dan menjaga kerahasiaan, integritas, dan ketersediaan sumber daya.
Definisi
| Istilah | Definisi |
|---|---|
| Pengujian keamanan aplikasi (AST) | Teknik Microsoft Security Development Lifecycle (SDL) yang menggunakan metodologi pengujian kotak putih dan kotak hitam untuk memeriksa kerentanan keamanan dalam kode. |
| Pengujian kotak hitam | Metodologi pengujian yang memvalidasi perilaku aplikasi yang terlihat secara eksternal tanpa pengetahuan tentang internal sistem. |
| Tim biru | Tim yang bertahan dari serangan tim merah dalam latihan permainan perang. |
| uji penetrasi | Metodologi pengujian yang menggunakan teknik peretasan etis untuk memvalidasi pertahanan keamanan sistem. |
| Tim merah | Tim yang memainkan peran sebagai setan dan mencoba meretas sistem dalam latihan permainan perang. |
| Siklus Hidup Pengembangan Keamanan (SDL) | Serangkaian praktik yang disediakan oleh Microsoft yang mendukung persyaratan jaminan dan kepatuhan keamanan. |
| Siklus hidup pengembangan perangkat lunak (SDLC) | Proses multistage dan sistematis untuk mengembangkan sistem perangkat lunak. |
| Pengujian kotak putih | Metodologi pengujian di mana struktur kode diketahui oleh praktisi. |
Strategi desain utama
Pengujian adalah strategi yang tidak dapat dinegosiasikan, terutama untuk keamanan. Ini memungkinkan Anda untuk secara proaktif menemukan dan mengatasi masalah keamanan sebelum dapat dieksploitasi dan untuk memverifikasi bahwa kontrol keamanan yang Anda terapkan berfungsi seperti yang dirancang.
Ruang lingkup pengujian harus mencakup aplikasi, infrastruktur, dan proses otomatis dan manusia.
Catatan
Panduan ini membuat perbedaan antara pengujian dan respons insiden. Meskipun pengujian adalah mekanisme deteksi yang idealnya memperbaiki masalah sebelum produksi, pengujian tidak boleh dikacaukan dengan remediasi atau penyelidikan yang dilakukan sebagai bagian dari respons insiden. Aspek pemulihan dari insiden keamanan dijelaskan dalam rekomendasi Respons Insiden.
SDL mencakup beberapa jenis pengujian yang menangkap kerentanan dalam kode, memverifikasi komponen runtime, dan menggunakan peretasan etis untuk menguji ketahanan keamanan sistem. SDL adalah aktivitas shift-left kunci. Anda harus menjalankan pengujian seperti analisis kode statis dan pemindaian otomatis infrastruktur sebagai kode (IaC) sedini mungkin dalam proses pengembangan.
Terlibat dalam perencanaan pengujian. Tim beban kerja mungkin tidak merancang kasus pengujian. Tugas itu sering terpusat di perusahaan atau diselesaikan oleh pakar keamanan eksternal. Tim beban kerja harus terlibat dalam proses desain tersebut untuk memastikan bahwa jaminan keamanan terintegrasi dengan fungsionalitas aplikasi.
Berpikir seperti penyerang. Rancang kasus pengujian Anda dengan asumsi bahwa sistem telah diserang. Dengan begitu, Anda dapat mengungkap potensi kerentanan dan memprioritaskan pengujian yang sesuai.
Jalankan pengujian secara terstruktur dan dengan proses yang dapat diulang. Bangun kekakuan pengujian Anda sekeliling irama, jenis pengujian, faktor pendorongan, dan hasil yang dimaksudkan.
Gunakan alat yang tepat untuk pekerjaan tersebut. Gunakan alat yang dikonfigurasi untuk bekerja dengan beban kerja. Jika Anda tidak memiliki alat, beli alat ini. Jangan membangunnya. Alat keamanan sangat khusus, dan membangun alat Anda sendiri mungkin menimbulkan risiko. Manfaatkan keahlian dan alat yang ditawarkan oleh tim SecOps pusat atau dengan cara eksternal jika tim beban kerja tidak memiliki keahlian tersebut.
Siapkan lingkungan terpisah. Pengujian dapat diklasifikasikan sebagai destruktif atau tidak merusak. Tes nondestruktif tidak invasif. Mereka menunjukkan ada masalah, tetapi mereka tidak mengubah fungsionalitas untuk memulihkan masalah. Pengujian destruktif invasif dan dapat merusak fungsionalitas dengan menghapus data dari database.
Pengujian di lingkungan produksi memberi Anda informasi terbaik tetapi menyebabkan gangguan paling banyak. Anda cenderung hanya melakukan pengujian nondestruktif di lingkungan produksi. Pengujian di lingkungan nonproduksi biasanya kurang mengganggu tetapi mungkin tidak secara akurat mewakili konfigurasi lingkungan produksi dengan cara yang penting bagi keamanan.
Jika Anda menyebarkan dengan menggunakan IaC dan otomatisasi, pertimbangkan apakah Anda dapat membuat klon lingkungan produksi yang terisolasi untuk pengujian. Jika Anda memiliki proses berkelanjutan untuk pengujian rutin, sebaiknya gunakan lingkungan khusus.
Selalu evaluasi hasil pengujian. Pengujian adalah upaya terbuang sia-sia jika hasilnya tidak digunakan untuk memprioritaskan tindakan dan melakukan perbaikan di hulu. Dokumentasikan panduan keamanan, termasuk praktik terbaik, yang Anda ungkap. Dokumentasi yang menangkap hasil dan rencana remediasi mendidik tim tentang berbagai cara penyerang mungkin mencoba melanggar keamanan. Lakukan pelatihan keamanan rutin untuk pengembang, admin, dan penguji.
Saat Anda merancang rencana pengujian, pikirkan tentang pertanyaan berikut:
Seberapa sering Anda mengharapkan pengujian berjalan, dan bagaimana hal itu memengaruhi lingkungan Anda?
Apa saja jenis pengujian berbeda yang harus Anda jalankan?
Seberapa sering Anda mengharapkan tes berjalan?
Uji beban kerja secara teratur untuk memastikan perubahan tidak menimbulkan risiko keamanan dan bahwa tidak ada regresi. Tim juga harus siap menanggapi validasi keamanan organisasi yang mungkin dilakukan kapan saja. Ada juga pengujian yang dapat Anda jalankan sebagai respons terhadap insiden keamanan. Bagian berikut memberikan rekomendasi tentang frekuensi pengujian.
Tes rutin
Tes rutin dilakukan secara teratur, sebagai bagian dari prosedur operasi standar Anda dan untuk memenuhi persyaratan kepatuhan. Berbagai pengujian mungkin dijalankan pada irama yang berbeda, tetapi kuncinya adalah bahwa mereka dilakukan secara berkala dan sesuai jadwal.
Anda harus mengintegrasikan pengujian ini ke dalam SDLC Anda karena memberikan pertahanan secara mendalam pada setiap tahap. Diversifikasi rangkaian pengujian untuk memverifikasi jaminan untuk identitas, penyimpanan data, dan transmisi, dan saluran komunikasi. Lakukan pengujian yang sama di titik yang berbeda dalam siklus hidup untuk memastikan bahwa tidak ada regresi. Tes rutin membantu menetapkan tolok ukur awal. Namun itu hanya titik awal. Saat Anda mengungkap masalah baru di titik siklus hidup yang sama, Anda menambahkan kasus pengujian baru. Tes juga meningkat dengan pengulangan.
Pada setiap tahap, pengujian ini harus memvalidasi kode yang ditambahkan atau dihapus atau pengaturan konfigurasi yang telah berubah untuk mendeteksi dampak keamanan dari perubahan tersebut. Anda harus meningkatkan khasiat pengujian dengan otomatisasi, seimbang dengan ulasan serekan.
Pertimbangkan untuk menjalankan pengujian keamanan sebagai bagian dari alur otomatis atau eksekusi pengujian terjadwal. Semakin cepat Anda menemukan masalah keamanan, semakin mudah untuk menemukan kode atau perubahan konfigurasi yang menyebabkannya.
Jangan hanya mengandalkan pengujian otomatis. Gunakan pengujian manual untuk mendeteksi kerentanan yang hanya dapat ditangkap oleh keahlian manusia. Pengujian manual baik untuk kasus penggunaan eksplorasi dan menemukan risiko yang tidak diketahui.
Pengujian improvisasi
Pengujian improvisasi memberikan validasi titik waktu pertahanan keamanan. Pemberitahuan keamanan yang mungkin memengaruhi beban kerja pada saat itu memicu pengujian ini. Mandat organisasi mungkin memerlukan pola pikir jeda dan uji untuk memverifikasi efektivitas strategi pertahanan jika pemberitahuan meningkat ke keadaan darurat.
Manfaat dari tes improvisasi adalah kesiapsiagaan untuk insiden nyata. Pengujian ini dapat menjadi fungsi memaksa untuk melakukan pengujian penerimaan pengguna (UAT).
Tim keamanan mungkin mengaudit semua beban kerja dan menjalankan pengujian ini sesuai kebutuhan. Sebagai pemilik beban kerja, Anda perlu memfasilitasi dan berkolaborasi dengan tim keamanan. Negosiasikan waktu tunggu yang cukup dengan tim keamanan sehingga Anda dapat mempersiapkannya. Akui dan komunikasikan kepada tim dan pemangku kepentingan Anda bahwa gangguan ini diperlukan.
Dalam kasus lain, Anda mungkin diminta untuk menjalankan pengujian dan melaporkan status keamanan sistem terhadap potensi ancaman.
Tradeoff: Karena pengujian improvisasi adalah peristiwa yang mengganggu, berharap untuk memprioritaskan kembali tugas, yang dapat menunda pekerjaan terencana lainnya.
Risiko: Ada risiko tidak diketahui. Pengujian improvisasi mungkin berupa upaya satu kali tanpa proses atau alat yang ditetapkan. Tetapi risiko yang dominan adalah potensi gangguan ritme bisnis. Anda perlu mengevaluasi risiko tersebut relatif terhadap manfaatnya.
Tes insiden keamanan
Ada tes yang mendeteksi penyebab insiden keamanan di sumbernya. Celah keamanan ini harus diselesaikan untuk memastikan insiden tidak diulang.
Insiden juga meningkatkan kasus pengujian dari waktu ke waktu dengan mengungkap celah yang ada. Tim harus menerapkan pelajaran yang dipelajari dari insiden dan secara rutin menggabungkan peningkatan.
Apa saja jenis pengujian yang berbeda?
Pengujian dapat dikategorikan berdasarkan teknologi dan dengan menguji metodologi. Gabungkan kategori dan pendekatan tersebut dalam kategori tersebut untuk mendapatkan cakupan lengkap.
Dengan menambahkan beberapa pengujian dan jenis pengujian, Anda dapat mengungkap:
Celah dalam kontrol keamanan atau kontrol kompensasi.
Kesalahan konfigurasi.
Celah dalam metode pengamatan dan deteksi.
Latihan pemodelan ancaman yang baik dapat menunjuk ke area utama untuk memastikan cakupan dan frekuensi pengujian. Untuk rekomendasi tentang pemodelan ancaman, lihat Rekomendasi untuk mengamankan siklus hidup pengembangan.
Sebagian besar pengujian yang dijelaskan di bagian ini dapat dijalankan sebagai tes rutin. Namun, pengulangan dapat dikenakan biaya dalam beberapa kasus dan menyebabkan gangguan. Pertimbangkan tradeoff tersebut dengan hati-hati.
Pengujian yang memvalidasi tumpukan teknologi
Berikut adalah beberapa contoh jenis pengujian dan area fokusnya. Daftar ini tidak lengkap. Uji seluruh tumpukan, termasuk tumpukan aplikasi, ujung depan, back end, API, database, dan integrasi eksternal apa pun.
Keamanan data: Uji efektivitas enkripsi data dan kontrol akses untuk memastikan data dilindungi dengan benar dari akses dan perusakan yang tidak sah.
Jaringan dan konektivitas: Uji firewall Anda untuk memastikan firewall hanya mengizinkan lalu lintas yang diharapkan, diizinkan, dan aman ke beban kerja.
Aplikasi: Uji kode sumber melalui teknik pengujian keamanan aplikasi (AST) untuk memastikan bahwa Anda mengikuti praktik pengodean yang aman dan untuk menangkap kesalahan runtime seperti kerusakan memori dan masalah hak istimewa. Untuk detailnya, lihat tautan komunitas ini.
Identitas: Mengevaluasi apakah penetapan peran dan pemeriksaan kondisional berfungsi seperti yang dimaksudkan.
Metodologi pengujian
Ada banyak perspektif tentang metodologi pengujian. Kami merekomendasikan pengujian yang memungkinkan perburuan ancaman dengan mensimulasikan serangan dunia nyata. Mereka dapat mengidentifikasi pelaku ancaman potensial, teknik mereka, dan eksploitasi mereka yang menimbulkan ancaman terhadap beban kerja. Buat serangan senyaman mungkin. Gunakan semua vektor ancaman potensial yang Anda identifikasi selama pemodelan ancaman.
Berikut adalah beberapa keuntungan pengujian melalui serangan dunia nyata:
Ketika Anda membuat serangan ini sebagai bagian dari pengujian rutin, Anda menggunakan perspektif luar dalam untuk memeriksa beban kerja dan memastikan pertahanan dapat menahan serangan.
Berdasarkan pelajaran yang mereka pelajari, tim meningkatkan pengetahuan dan tingkat keterampilan mereka. Tim meningkatkan kesadaran situasional dan dapat menilai sendiri kesiapan mereka untuk merespons insiden.
Beberapa contoh tes yang disimulasikan termasuk pengujian kotak hitam dan kotak putih, pengujian penetrasi, dan latihan permainan perang.
Pengujian kotak hitam dan kotak putih
Jenis pengujian ini menawarkan dua perspektif yang berbeda. Dalam pengujian kotak hitam, internal sistem tidak terlihat. Dalam pengujian kotak putih, penguji memiliki pemahaman yang baik tentang aplikasi dan bahkan memiliki akses ke kode, log, topologi sumber daya, dan konfigurasi untuk melakukan eksperimen.
Pengujian yang mensimulasikan serangan melalui pengujian penetrasi
Pakar keamanan yang bukan bagian dari tim TI atau aplikasi organisasi melakukan pengujian penetrasi, atau pentes. Mereka melihat sistem dengan cara aktor jahat mencakup permukaan serangan. Tujuan mereka adalah untuk menemukan celah keamanan dengan mengumpulkan informasi, menganalisis kerentanan, dan melaporkan hasilnya.
Praktisi mungkin memerlukan akses ke data sensitif di seluruh organisasi. Ikuti aturan keterlibatan untuk memastikan bahwa akses tidak disalahgunakan. Lihat sumber daya yang tercantum di Tautan terkait.
Tes yang mensimulasikan serangan melalui latihan game perang
Dalam metodologi serangan yang disimulasikan ini, ada dua tim:
Tim merah adalah musuh yang mencoba memodelkan serangan dunia nyata. Jika berhasil, Anda menemukan celah dalam desain keamanan Anda dan mengevaluasi radius ledakan penahanan pelanggaran mereka.
Tim biru adalah tim beban kerja yang bertahan dari serangan. Mereka menguji kemampuan mereka untuk mendeteksi, merespons, dan memulihkan serangan. Mereka memvalidasi pertahanan yang telah diterapkan untuk melindungi sumber daya beban kerja.
Jika mereka dilakukan sebagai tes rutin, latihan game perang dapat memberikan visibilitas dan jaminan berkelanjutan bahwa pertahanan Anda berfungsi seperti yang dirancang. Latihan game perang berpotensi menguji lintas level dalam beban kerja Anda.
Pilihan populer untuk mensimulasikan skenario serangan realistis adalah Pelatihan simulasi serangan Microsoft Defender untuk Office 365.
Untuk informasi selengkapnya, lihat Wawasan dan laporan untuk Pelatihan simulasi serangan.
Untuk informasi tentang penyiapan tim merah dan tim biru, lihat Microsoft Cloud Red Teaming.
Fasilitasi Azure
Microsoft Sentinel adalah kontrol asli yang menggabungkan kemampuan manajemen peristiwa informasi keamanan (SIEM) dan respons otomatis orkestrasi keamanan (SOAR). Ini menganalisis peristiwa dan log dari berbagai sumber yang terhubung. Berdasarkan sumber data dan pemberitahuannya, Microsoft Azure Sentinel membuat insiden dan melakukan analisis ancaman untuk deteksi dini. Melalui analitik dan kueri cerdas, Anda dapat secara proaktif berburu masalah keamanan. Jika ada insiden, Anda dapat mengotomatiskan alur kerja. Selain itu, dengan templat buku kerja, Anda bisa dengan cepat mendapatkan wawasan melalui visualisasi.
Untuk dokumentasi produk, lihat Kemampuan berburu di Microsoft Azure Sentinel.
Microsoft Defender untuk Cloud menawarkan pemindaian kerentanan untuk berbagai area teknologi. Untuk detailnya, lihat Mengaktifkan pemindaian kerentanan dengan Pengelolaan Kerentanan Microsoft Defender - Microsoft Defender untuk Cloud.
Praktik DevSecOps mengintegrasikan pengujian keamanan sebagai bagian dari pola pikir peningkatan berkelanjutan dan berkelanjutan. Latihan game perang adalah praktik umum yang diintegrasikan ke dalam ritme bisnis di Microsoft. Untuk informasi selengkapnya, lihat Keamanan di DevOps (DevSecOps).
Azure DevOps mendukung alat pihak ketiga yang dapat diotomatisasi sebagai bagian dari alur integrasi berkelanjutan/penyebaran berkelanjutan. Untuk detailnya, lihat Mengaktifkan DevSecOps dengan Azure dan GitHub - Azure DevOps.
Tautan terkait
Ikuti aturan keterlibatan untuk memastikan bahwa akses tidak disalahgunakan. Untuk panduan tentang merencanakan dan mengeksekusi serangan yang disimulasikan, lihat artikel berikut ini:
Anda dapat mensimulasikan serangan penolakan layanan (DoS) di Azure. Pastikan untuk mengikuti kebijakan yang ditata dalam pengujian simulasi Azure DDoS Protection.
Tautan komunitas
Pengujian keamanan aplikasi: Alat, jenis, dan praktik terbaik - Sumber Daya GitHub menjelaskan jenis metodologi pengujian yang dapat menguji pertahanan build-time dan runtime aplikasi.
Standar Eksekusi Pengujian Penetrasi (PTES) memberikan panduan tentang skenario umum dan aktivitas yang diperlukan untuk menetapkan garis besar.
OWASP Sepuluh Teratas | OWASP Foundation menyediakan praktik terbaik keamanan untuk aplikasi dan kasus pengujian yang mencakup ancaman umum.
Daftar periksa keamanan
Lihat serangkaian rekomendasi lengkap.
Saran dan Komentar
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat: https://aka.ms/ContentUserFeedback.
Kirim dan lihat umpan balik untuk