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 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 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 Tim yang berperan sebagai musuh dan mencoba meretas sistem dalam latihan game 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 sistematis multitahap 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, 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 kali 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 ketelitian pengujian Anda seputar irama, jenis tes, 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 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. Tes dapat diklasifikasikan sebagai destruktif atau nondestruktif. Tes nondestruktif tidak invasif. Mereka menunjukkan ada masalah, tetapi mereka tidak mengubah fungsionalitas untuk memperbaiki masalah. Pengujian 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 tidak terlalu 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 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 tes, pikirkan pertanyaan-pertanyaan berikut:

  • Seberapa sering Anda mengharapkan pengujian berjalan, dan bagaimana pengaruhnya terhadap lingkungan Anda?
  • Apa saja jenis tes 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 terhadap 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 tes mungkin dijalankan pada irama yang berbeda, tetapi kuncinya adalah mereka dilakukan secara berkala dan sesuai jadwal.

Anda harus mengintegrasikan pengujian ini ke dalam SDLC Anda karena mereka memberikan pertahanan yang mendalam di setiap tahap. Diversifikasi rangkaian pengujian untuk memverifikasi jaminan identitas, penyimpanan dan transmisi data, dan 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 mengungkap masalah baru pada titik yang sama dalam siklus hidup, 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, seimbang dengan tinjauan sejawat.

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

Tes improvisasi

Tes improvisasi memberikan validasi pertahanan keamanan tepat waktu. 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 pemaksaan 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 tes improvisasi adalah peristiwa yang mengganggu, harapkan untuk memprioritaskan ulang tugas, yang dapat menunda pekerjaan yang direncanakan lainnya.

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.

Pengujian 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 pengujian 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?

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 mengungkap:

  • Kesenjangan dalam kontrol keamanan atau kontrol kompensasi.
  • Salah konfigurasi.
  • Kesenjangan dalam metode observabilitas 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 dalam 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, ujung depan, ujung belakang, 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 gangguan yang tidak sah.
  • Jaringan dan konektivitas: Uji firewall Anda untuk memastikannya 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: Mengevaluasi 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 pelaku 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 dari luar ke 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 pengujian 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, bagian dalam 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 berusaha 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 pengujian. Mereka melihat sistem dengan cara pelaku jahat menjangkau permukaan serangan. Tujuan mereka adalah menemukan kesenjangan keamanan dengan mengumpulkan informasi, menganalisis kerentanan, dan melaporkan hasilnya.

Tradeoff: Tes penetrasi diimprovisasi dan bisa mahal dalam hal gangguan dan investasi moneter karena tes peni 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 game perang

Dalam metodologi simulasi serangan ini, ada dua tim:

  • Tim mérah adalah musuh yang mencoba memodelkan serangan dunia nyata. Jika berhasil, Anda menemukan celah dalam desain keamanan Anda dan mengevaluasi penahanan radius ledakan dari 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 dilakukan sebagai tes rutin, latihan permainan perang dapat memberikan visibilitas berkelanjutan dan jaminan bahwa pertahanan Anda bekerja seperti yang dirancang. Latihan game perang berpotensi menguji di seluruh 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

Solusi Microsoft Sentinel untuk Microsoft Power Platform memungkinkan pelanggan 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 yang dilakukan melalui Power Apps
  • Power Automate mengalirkan aktivitas dengan karyawan yang berangkat
  • Microsoft Power Platform konektor yang ditambahkan ke lingkungan
  • Memperbarui atau menghapus Microsoft Power Platform kebijakan data

Untuk informasi selengkapnya, lihat solusi Microsoft Sentinel untuk Microsoft Power Platform gambaran 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 Manajemen Kerentanan Microsoft Defender.

Praktik DevSecOps mengintegrasikan pengujian keamanan sebagai bagian dari pola pikir peningkatan berkelanjutan dan berkelanjutan. Latihan permainan perang adalah praktik umum yang terintegrasi 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 Microsoft Cloud. Pengujian ini mencakup pengujian penetrasi, dengan hasil yang dipublikasikan di Portal Kepercayaan Layanan untuk organisasi Anda. Organisasi Anda dapat melakukan tes penetrasi Anda sendiri pada Microsoft Power Platform Microsoft Dynamics dan layanan 365. 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 dan aset milik pelanggan lain Anda. 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. Pelajari selengkapnya tentang merencanakan dan mengeksekusi serangan simulasi:

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

Daftar periksa keamanan

Lihat rangkaian lengkap rekomendasi.