Bagikan melalui


Rekomendasi untuk pengujian keamanan

Berlaku untuk rekomendasi daftar periksa Well-Architected Security ini Power Platform :

SE:09 Tetapkan rejimen pengujian komprehensif yang menggabungkan pendekatan untuk mencegah masalah keamanan, memvalidasi implementasi pencegahan ancaman, dan menguji mekanisme deteksi ancaman.

Pengujian yang ketat adalah dasar dari desain keamanan yang baik. Pengujian adalah bentuk validasi taktis untuk memastikan kontrol berfungsi sebagaimana mestinya. Pengujian juga merupakan cara proaktif untuk mendeteksi kerentanan dalam sistem.

Tetapkan ketelitian pengujian melalui irama dan verifikasi dari berbagai Perspektif. Anda harus menyertakan sudut pandang dari dalam ke luar yang menguji platform dan infrastruktur dan evaluasi dari luar ke 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 Devinisi
Pengujian keamanan aplikasi (AST) Teknik Siklus Hidup Pengembangan Keamanan (SDL) Microsoft 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 Sebuah tim yang bertahan melawan serangan tim mérah dalam latihan permainan perang.
Pengujian penetrasi Metodologi pengujian yang menggunakan teknik peretasan etis untuk memvalidasi pertahanan keamanan suatu sistem.
Tim mérah Sebuah tim yang berperan sebagai musuh dan mencoba meretas sistem dalam latihan permainan perang.
Siklus Hidup Pengembangan Keamanan (SDL) Serangkaian praktik yang disediakan oleh Microsoft yang mendukung jaminan keamanan dan persyaratan kepatuhan.
Siklus hidup pengembangan perangkat lunak (SDLC) Proses multitahap 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 membedakan antara pengujian dan respons insiden. Meskipun pengujian adalah mekanisme deteksi yang idealnya memperbaiki masalah sebelum produksi, pengujian tidak boleh disamakan dengan remediasi atau investigasi yang dilakukan sebagai bagian dari respons insiden. Aspek pemulihan dari insiden keamanan dijelaskan dalam Rekomendasi untuk respons insiden keamanan.

Terlibat dalam perencanaan tes. 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.

Berpikirlah 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 ketelitian pengujian Anda seputar irama, jenis pengujian, faktor pendorong, dan hasil yang diinginkan.

Gunakan alat yang tepat untuk pekerjaan itu. Gunakan alat yang dikonfigurasi untuk bekerja dengan beban kerja. Jika Anda tidak memiliki alat, belilah alat tersebut. Jangan membangunnya. Alat keamanan sangat terspesialisasi, dan membangun alat Anda sendiri dapat 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. Tes dapat diklasifikasikan sebagai destruktif atau nondestruktif. Tes nondestruktif tidak invasif. Mereka menunjukkan ada masalah, tetapi mereka tidak mengubah fungsionalitas untuk memperbaiki masalah. Tes destruktif bersifat invasif dan dapat merusak fungsionalitas dengan menghapus data dari database.

Pengujian di lingkungan produksi memberi Anda informasi terbaik tetapi menyebabkan gangguan paling besar. 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 untuk keamanan.

Anda dapat membuat klon terisolasi dari lingkungan produksi Anda dengan menggunakan fitur penyalinanlingkungan. Jika Anda telah menyiapkan alur penyebaran, Anda juga dapat menyebarkan solusi Anda ke lingkungan pengujian khusus.

Selalu evaluasi hasil tes. Pengujian adalah upaya yang-jika hasilnya tidak digunakan untuk memprioritaskan tindakan dan melakukan perbaikan di hulu. Dokumentasikan pedoman keamanan, termasuk praktik terbaik, yang Anda temukan. 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 pertanyaan-pertanyaan berikut:

  • Seberapa sering Anda mengharapkan tes berjalan, dan bagaimana pengaruhnya terhadap lingkungan Anda?
  • Apa saja jenis tes berbeda yang harus Anda jalankan?

Seberapa sering Anda mengharapkan tes berjalan?

Uji beban kerja secara teratur untuk memastikan perubahan tidak menimbulkan risiko keamanan dan 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 atas insiden keamanan. Bagian berikut memberikan rekomendasi tentang frekuensi pengujian.

Tes rutin

Pengujian 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 tes tersebut dilakukan secara berkala dan sesuai jadwal.

Anda harus mengintegrasikan tes ini ke dalam SDLC Anda karena mereka memberikan pertahanan mendalam di setiap tahap. Diversifikasi rangkaian pengujian untuk memverifikasi jaminan identitas, penyimpanan dan transmisi data, serta saluran komunikasi. Lakukan pengujian yang sama pada 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 menemukan masalah baru pada 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 kemanjuran tes dengan otomatisasi, diimbangi dengan tinjauan sejawat.

Pertimbangkan untuk menjalankan pengujian keamanan sebagai bagian dari alur otomatis atau uji coba 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 bagus untuk kasus penggunaan eksplorasi dan menemukan risiko yang tidak diketahui.

Tes improvisasi

Tes 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 peringatan meningkat menjadi keadaan darurat.

Manfaat dari tes improvisasi adalah kesiapan untuk insiden nyata. Pengujian ini dapat menjadi fungsi yang 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, harapkan untuk memprioritaskan kembali tugas, yang dapat menunda pekerjaan lain yang direncanakan.

Risiko: Ada risiko yang tidak diketahui. Tes improvisasi mungkin merupakan upaya satu kali tanpa proses atau alat yang mapan. Tetapi risiko utama 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. Kesenjangan keamanan ini harus diselesaikan untuk memastikan insiden tidak terulang.

Insiden juga meningkatkan kasus uji dari waktu ke waktu dengan mengungkap kesenjangan yang ada. Tim harus menerapkan pelajaran yang dipetik dari insiden tersebut dan secara rutin memasukkan perbaikan.

Apa saja jenis tes yang berbeda?

Tes dapat dikategorikan berdasarkan teknologi dan metodologi pengujian. Gabungkan kategori dan pendekatan tersebut dalam kategori tersebut untuk mendapatkan cakupan lengkap.

Dengan menambahkan beberapa pengujian dan jenis pengujian, Anda dapat mengungkapkan:

  • Kesenjangan dalam kontrol keamanan atau kontrol kompensasi.
  • Kesalahan konfigurasi.
  • Kesenjangan 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 pengujian rutin. Namun, pengulangan dapat menimbulkan biaya dalam beberapa kasus dan menyebabkan gangguan. Pertimbangkan pengorbanan itu dengan hati-hati.

Pengujian yang memvalidasi tumpukan teknologi

Berikut adalah beberapa contoh jenis tes dan area fokusnya. Daftar ini tidak lengkap. Uji seluruh tumpukan, termasuk tumpukan aplikasi, front end, back end, API, database, dan integrasi eksternal apa pun.

  • Keamanan data: Uji efektivitas enkripsi data dan kontrol akses untuk memastikan data terlindungi dengan benar dari akses dan gangguan 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 pengkodean yang aman dan untuk menangkap kesalahan runtime seperti kerusakan memori dan masalah hak istimewa.
  • Identitas: Evaluasi apakah penetapan peran dan pemeriksaan bersyarat berfungsi sebagaimana mestinya.

Metodologi pengujian

Ada banyak Perspektif tentang metodologi pengujian. Kami merekomendasikan pengujian yang memungkinkan perburuan ancaman dengan mensimulasikan serangan dunia nyata. Mereka dapat mengidentifikasi aktor ancaman potensial, teknik mereka, dan eksploitasi mereka yang menimbulkan ancaman bagi beban kerja. Jadikan serangan serealistis mungkin. Gunakan semua vektor ancaman potensial yang Anda identifikasi selama pemodelan ancaman.

Berikut adalah beberapa keuntungan pengujian melalui serangan dunia nyata:

  • Saat Anda menjadikan 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 menanggapi insiden.

Risiko: Pengujian secara umum dapat memengaruhi kinerja. Mungkin ada masalah kelangsungan bisnis jika tes destruktif menghapus atau merusak data. Ada juga risiko yang terkait dengan paparan informasi; Pastikan untuk menjaga kerahasiaan data. Pastikan integritas data setelah Anda menyelesaikan pengujian.

Beberapa contoh pengujian simulasi termasuk pengujian kotak hitam dan kotak putih, pengujian penetrasi, dan latihan permainan perang.

Pengujian kotak hitam dan kotak putih

Jenis tes 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.

Risiko: Perbedaan antara kedua jenis adalah biaya di muka. Pengujian kotak putih bisa mahal dalam hal waktu yang dibutuhkan untuk memahami sistem. Dalam beberapa kasus, pengujian kotak putih mengharuskan Anda membeli alat khusus. Pengujian kotak hitam tidak memerlukan waktu peningkatan, tetapi mungkin tidak seefektif itu. Anda mungkin perlu melakukan upaya ekstra untuk mengungkap masalah. Ini adalah pengorbanan investasi waktu.

Pengujian yang mensimulasikan serangan melalui pengujian penetrasi

Pakar keamanan yang bukan bagian dari tim TI atau aplikasi organisasi melakukan pengujian penetrasi, atau pentesting. Mereka melihat sistem dengan cara aktor jahat menjangkau permukaan serangan. Tujuan mereka adalah menemukan celah keamanan dengan mengumpulkan informasi, menganalisis kerentanan, dan melaporkan hasilnya.

Tradeoff: Tes penetrasi bersifat improvisasi dan bisa mahal dalam hal gangguan dan investasi moneter karena pentesting biasanya merupakan penawaran berbayar oleh praktisi pihak ketiga.

Risiko: Latihan pentesting dapat memengaruhi lingkungan runtime dan dapat mengganggu ketersediaan lalu lintas normal.

Praktisi mungkin memerlukan akses ke data sensitif di seluruh organisasi. Ikuti aturan keterlibatan untuk memastikan bahwa akses tidak disalahgunakan. Lihat sumber daya yang tercantum dalam Informasi terkait.

Tes yang mensimulasikan serangan melalui latihan permainan perang

Dalam metodologi simulasi serangan ini, ada dua tim:

  • Tim mérah adalah musuh yang mencoba memodelkan serangan dunia nyata. Jika mereka berhasil, Anda menemukan celah dalam desain keamanan Anda dan mengevaluasi penahanan radius ledakan dari pelanggaran mereka.
  • Tim biru adalah tim beban kerja yang bertahan melawan serangan. Mereka menguji kemampuan mereka untuk mendeteksi, merespons, dan memulihkan serangan. Mereka memvalidasi pertahanan yang telah diterapkan untuk melindungi sumber daya beban kerja.

Jika dilakukan sebagai tes rutin, latihan permainan perang dapat memberikan visibilitas berkelanjutan dan jaminan bahwa pertahanan Anda berfungsi seperti yang dirang. Latihan permainan perang berpotensi menguji lintas level dalam beban kerja Anda.

Pilihan populer untuk mensimulasikan skenario serangan realistis adalah pelatihan Office 365 simulasi Microsoft Defender forAttack.

Untuk informasi selengkapnya, lihat Wawasan dan laporan untuk pelatihan simulasi serangan.

Untuk informasi tentang penyiapan tim mérah dan tim biru, lihat Microsoft Cloud Red Teaming.

Power Platform Fasilitasi

Microsoft Sentinel solusi untuk Microsoft Power Platform memungkinkan pelanggan untuk mendeteksi berbagai aktivitas yang mencurigakan, seperti:

  • Power Apps eksekusi dari geografi yang tidak sah
  • Penghancuran data yang mencurigakan oleh Power Apps
  • Penghapusan massal Power Apps
  • Serangan phishing dilakukan melalui Power Apps
  • Power Automate Aktivitas Aliran dengan Karyawan yang Keluar
  • Microsoft Power Platform konektor ditambahkan ke lingkungan
  • Memperbarui atau menghapus Microsoft Power Platform kebijakan pencegahan kehilangan data

Untuk informasi selengkapnya, lihat Microsoft solusi Sentinel untuk gambaran Microsoft Power Platform umum.

Untuk dokumentasi produk, lihat Kemampuan berburu di Microsoft Sentinel.

Microsoft Defender for Cloud menawarkan pemindaian kerentanan untuk berbagai area teknologi. Untuk informasi selengkapnya, lihat Mengaktifkan pemindaian kerentanan dengan Microsoft Manajemen Kerentanan Defender.

Praktik DevSecOps mengintegrasikan pengujian keamanan sebagai bagian dari pola pikir peningkatan yang berkelanjutan dan berkelanjutan. Latihan permainan 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 (CI/CD). Untuk informasi selengkapnya, lihat Mengaktifkan DevSecOps dengan Azure dan GitHub.

Pengujian penetrasi dan penilaian keamanan terakhir dapat ditemukan di Portal Kepercayaan Layanan Microsoft.

Microsoft melakukan pengujian ekstensif terhadap layanan Cloud Microsoft. Pengujian ini mencakup pengujian penetrasi, dengan hasil yang dipublikasikan di Portal Kepercayaan Layanan untuk organisasi Anda. Organisasi Anda dapat melakukan uji penetrasi Anda sendiri pada Microsoft Power Platform layanan dan 365 Microsoft Dynamics . Semua pengujian penetrasi harus mengikuti Aturan Keterlibatan Pengujian Penetrasi Cloud Microsoft. Penting untuk diingat bahwa dalam banyak kasus, Microsoft Cloud menggunakan infrastruktur bersama untuk menghosting aset Anda dan aset milik pelanggan lain. Anda harus membatasi semua tes penetrasi ke aset Anda dan menghindari konsekuensi yang tidak diinginkan bagi pelanggan lain di sekitar Anda.

Ikuti aturan keterlibatan untuk memastikan bahwa akses tidak disalahgunakan. Untuk panduan tentang perencanaan dan eksekusi simulasi serangan, lihat:

Anda dapat mensimulasikan serangan penolakan layanan (DoS) di Azure. Pastikan untuk mengikuti kebijakan yang ditetapkan dalam pengujian simulasi Azure DDoS Protection.

Daftar periksa keamanan

Lihat rangkaian rekomendasi lengkap.