Mengintegrasikan pemodelan ancaman dengan DevOps
Postingan ini ditulis oleh Simone Curzi, Anthony Nevico, Jonathan Davis, Rafael Pazos Rodriguez, dan Ben Hanson
Pendahuluan
Pemodelan ancaman adalah metode keamanan penting yang membantu mengidentifikasi dan memprioritaskan mitigasi risiko terpenting untuk aplikasi atau sistem. Makalah ini berisi beberapa refleksi tentang bagaimana mungkin untuk mengadopsi pemodelan ancaman secara lebih efektif dan efisien, mengintegrasikannya dengan metodologi dan alat DevOps modern, dan berfokus pada nilai yang disediakan untuk semua aktor yang terlibat dengan Siklus Hidup Pengembangan Perangkat Lunak.
Apakah kertas ini untuk Anda?
Makalah ini adalah hasil kerja tim kecil pakar Keamanan dan pemodelan ancaman dari Microsoft dan menggabungkan input dan ide dari beberapa pakar yang paling menonjol dari luar Microsoft. Ini mencoba untuk mengatasi pertanyaan sederhana tetapi mendesak: apa yang harus kita lakukan untuk memastikan bahwa proses pemodelan ancaman yang kita gunakan diperbarui ke persyaratan modern yang diberlakukan oleh metodologi Agile dan DevOps, sehingga kita memberikan nilai yang diperlukan dengan biaya terendah?
Jika Anda adalah Pemilik Produk, anggota tim Keamanan, atau hanya pengembang yang mempertimbangkan untuk mengadopsi pemodelan ancaman sebagai bagian dari siklus hidup pengembangan Anda, makalah ini untuk Anda.
Secara analog, jika Anda sudah mengadopsi pemodelan ancaman, Anda mungkin masih menemukan ide praktis untuk meningkatkan proses Anda.
Namun demikian, makalah ini dirancang untuk memperkenalkan ide-ide untuk meningkatkan proses saat ini atau untuk berhasil mengadopsi pemodelan ancaman sebagai bagian dari proses DevOps Anda. Ini tidak memperkenalkan alat atau produk tertentu, bahkan jika itu adalah harapan kami untuk melihat ide-ide tersebut diimplementasikan oleh beberapa alat atau produk di masa depan. Oleh karena itu, Anda tidak akan menemukan pengumuman alat baru atau pratinjau fitur mendatang, di sini.
Mengapa pemodelan ancaman penting?
Pemodelan Ancaman adalah salah satu pendekatan utama untuk merancang solusi perangkat lunak dengan aman. Melalui Pemodelan Ancaman, Anda menganalisis sistem mengidentifikasi vektor serangan, dan mengembangkan tindakan untuk mengurangi risiko yang dibawa oleh serangan tersebut. Dilakukan dengan tepat, pemodelan ancaman adalah komponen yang sangat baik dari setiap proses Manajemen Risiko. Ini juga dapat membantu mengurangi biaya dengan mengidentifikasi dan memperbaiki masalah desain lebih awal. Sebuah studi lama dari NIST memperkirakan biaya perbaikan masalah desain dalam kode produksi menjadi sekitar 40 kali lebih tinggi daripada memperbaikinya selama fase desain. Ini juga menghemat biaya yang timbul karena insiden keamanan untuk masalah desain akhirnya. Pertimbangkan bahwa Laporan Pelanggaran Biaya Data 2022 dari IBM Security dan Ponemon Institute memperkirakan biaya rata-rata pelanggaran data menjadi $ 4,35M. Untuk apa yang disebut Pelanggaran Mega, yang melibatkan kompromi lebih dari 50 juta catatan, biaya rata-rata mencapai $ 387M!
Pemodelan ancaman adalah aktivitas pertama yang dapat Anda lakukan untuk mengamankan solusi Anda karena beroperasi pada desain solusi. Karakteristik ini menjadikannya praktik keamanan paling efektif yang dapat Anda terapkan ke SDLC Anda.
Microsoft memiliki riwayat panjang dengan pemodelan ancaman. Pada tahun 1999, dua (kemudian) karyawan Microsoft, Loren Kohnfelder dan Praerit Garg, menulis dokumen, Ancaman terhadap produk kami. Makalah ini memperkenalkan pendekatan STRIDE, sinonim untuk proses pemodelan ancaman Microsoft.
Pemodelan ancaman adalah proses evolusioner
Pemodelan ancaman bukanlah proses statis; berevolusi seiring dengan perubahan kebutuhan dan teknologi.
Serangan Rantai Pasokan seperti yang baru-baru ini menargetkan SolarWinds menunjukkan kebutuhan untuk mencakup dengan Pemodelan Ancaman lebih banyak skenario daripada solusi itu sendiri, termasuk pengembangan dan penyebaran.
Kerentanan Sumber Terbuka seperti yang baru-baru ini untuk Log4j telah menunjukkan kebutuhan untuk melengkapi pendekatan saat ini berdasarkan adopsi alat Analisis Komposisi Perangkat Lunak untuk memindai komponen yang rentan dengan merancang solusi secara defensif untuk membatasi paparannya.
Penerapan teknologi baru seperti Pembelajaran Mesin memperkenalkan vektor serangan baru yang harus dipahami dan dikendalikan. Pertimbangkan, misalnya, kemungkinan bermain suara yang dibuat dengan berbahaya tidak dapat diautentikasi oleh telinga manusia untuk menyebabkan eksekusi perintah oleh layanan AI, seperti yang dibahas dalam https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/carlini.
Di Microsoft, grup produk yang berbeda mempraktikkan berbagai varian pemodelan ancaman berdasarkan persyaratan keamanan spesifik mereka. Setiap varian bertujuan untuk menjamin tingkat jaminan keamanan yang memadai untuk skenario yang diterapkannya, tetapi apa yang "memadai" berarti perubahan tergantung pada konteks tertentu.
Misalnya, mengamankan Windows berbeda dengan mengamankan Azure Cognitive Services karena sistem tersebut memiliki ukuran dan karakteristik yang sangat berbeda. Aspek utama pemodelan ancaman adalah menyeimbangkan biayanya terhadap toleransi risiko untuk aplikasi. Meskipun ini dapat menyebabkan keputusan untuk menghindari pemodelan ancaman sama sekali untuk beberapa skenario, sangat efektif ketika dilakukan dengan benar sehingga kami hanya dapat merekomendasikan untuk mengadopsinya untuk inisiatif TI apa pun, termasuk pengembangan perangkat lunak dan proyek penyebaran infrastruktur.
Pentingnya berfokus pada ROI
Beberapa tahun terakhir telah melihat peningkatan minat yang stabil dalam pemodelan ancaman sebagai proses pengembangan perangkat lunak utama. Minat ini disebabkan oleh peningkatan eksponensial serangan terhadap infrastruktur dan solusi. Inisiatif seperti Standar Minimum yang Direkomendasikan NIST untuk Vendor atau Verifikasi Kode Pengembang dan Manifesto Pemodelan Ancaman telah lebih meningkatkan permintaan ke titik bahwa pendekatan saat ini telah menunjukkan beberapa batasan. Misalnya, hasil pemodelan ancaman sangat tergantung pada proses yang diadopsi dan pada siapa yang melakukan model ancaman. Dengan demikian, ada kekhawatiran tentang mendapatkan kualitas yang lebih tinggi secara konsisten dari pengalaman.
Tapi, apa artinya kualitas untuk pemodelan ancaman? Bagi kami, model ancaman Kualitas harus memiliki karakteristik berikut:
Ini harus mengidentifikasi mitigasi yang dapat ditindaklanjuti, aktivitas yang dapat Anda lakukan untuk mengurangi potensi kerugian yang diakibatkan oleh serangan. Dapat ditindaklanjuti berarti bahwa mitigasi tersebut harus didefinisikan dengan baik, yang berarti Anda mendapatkan informasi yang cukup untuk mengimplementasikannya dan kemudian menguji implementasinya. Ini juga berarti bahwa mereka harus disediakan untuk memungkinkan konsumsi yang mudah dari tim Pengembangan. Dengan DevOps dan Agile, ini berarti bahwa ada jalur mudah untuk mengimpor mitigasi ke Backlog.
Untuk setiap Mitigasi, mengidentifikasi statusnya. Beberapa mitigasi baru, sementara yang lain sudah ada. Model ancaman harus mengenali apa yang sudah ada dan fokus pada risiko saat ini untuk mengidentifikasi cara meningkatkan situasi.
Ini harus mengidentifikasi dengan jelas mengapa setiap Mitigasi diperlukan dengan menautkannya ke ancaman masing-masing.
Selain itu, mitigasi memiliki kekuatan relatif untuk setiap ancaman. Misalnya, enkripsi TLS mungkin merupakan mitigasi yang kuat terhadap risiko memiliki data dalam transit yang diungkapkan, dan pada saat yang sama, mungkin mitigasi yang hampir lengkap terhadap risiko memiliki server spoofed.
Ancaman harus kredibel, terdefinisi dengan baik, dan khusus untuk solusi.
Ancaman harus memiliki Tingkat Keparahan terkait, yang harus mempertimbangkan kemungkinan dan dampaknya. Tingkat Keparahan harus masuk akal dan idealnya tidak bias.
Seharusnya dimungkinkan untuk mendapatkan pandangan komprehensif tentang risiko dan bagaimana mereka dapat diatasi. Tampilan ini akan berperan penting dalam mendorong percakapan yang bermakna dengan tim Keamanan dan dengan Pembuat Keputusan Bisnis, dan itu akan memungkinkan kami untuk menyembunyikan kompleksitas yang tidak perlu.
Daftar ini sudah menunjukkan konsep penting: pemodelan ancaman dapat memberikan nilai bagi banyak peran yang terlibat selama siklus hidup perangkat lunak, tetapi setiap peran memiliki kebutuhan dan persyaratan yang berbeda. Misalnya, pengembang perlu menerima informasi yang jelas tentang apa yang perlu mereka terapkan, dan tentang cara memverifikasi bahwa apa yang mereka terapkan berperilaku seperti yang diharapkan. Di sisi lain, tim Keamanan biasanya peduli dengan keamanan keseluruhan ekosistem infrastruktur dan aplikasi yang dimiliki oleh organisasi; oleh karena itu, mereka perlu menerima informasi yang memungkinkan untuk memutuskan apakah sistem dalam cakupan cukup aman dan memenuhi persyaratan kepatuhannya. Akhirnya, Pemilik Produk dan pembuat keputusan Bisnis perlu memahami apa yang diperlukan untuk membuat risiko dapat diterima bagi organisasi.
Kebutuhan yang berbeda tersebut harus memberikan tampilan yang berbeda pada model ancaman, masing-masing berfokus pada skenario penggunaan tertentu.
Masalah umum dengan pemodelan ancaman adalah semakin berhasil, semakin sulit bagi beberapa ahli yang tersedia untuk menutupi permintaan sambil tetap memberikan kualitas tinggi yang diharapkan dari pengalaman ini. Akibatnya, dalam beberapa kasus, kualitas dapat terpengaruh secara negatif. Semua baik sampai pemodelan ancaman berhenti memberikan nilai yang signifikan dibandingkan dengan investasi. Lebih dari beberapa organisasi terpengaruh oleh masalah ini. Sudah ada beberapa laporan Pembuat Keputusan Bisnis mulai mempertanyakan pemodelan ancaman karena akan gagal memberikan nilai signifikan untuk biaya.
Dengan nilai, kami merujuk pada nilai Bisnis, yang merupakan kemampuan untuk memberikan informasi yang diperlukan untuk memahami risiko yang diwakili oleh sistem dalam cakupan dan mendorong proses keputusan yang bermakna untuk memilih mitigasi yang tepat untuk diterapkan. Selain itu, nilai juga terkait dengan memberikan informasi yang benar kepada Pengembang dan Penguji. Akhirnya, nilai terkait dengan mengkomunikasikan risiko residual dengan semua pihak yang terlibat. Kita dapat, misalnya, mengukur nilai dengan mengukur dampak proses pemodelan ancaman. Misalkan kita mengukur risiko keseluruhan untuk solusi dengan menetapkan angka ke Tingkat Keparahan yang diidentifikasi untuk setiap ancaman. Dalam hal ini, kami mengharapkan risiko keseluruhan menurun dari waktu ke waktu per efek model ancaman. Jika risiko keseluruhan tetap konstan atau meningkat, kita mungkin memiliki masalah. Semakin curam penurunan, semakin tinggi dampak model ancaman. Tentu saja, model ancaman tidak akan mengontrol mitigasi yang diterapkan. Merupakan tanggung jawab Pemilik Produk untuk memutuskan apa yang harus diimplementasikan. Tetapi keuntungan menghubungkan efektivitas model ancaman dengan implementasi aktual dari mitigasi adalah meningkatkan dampak pada keamanan solusi yang sebenarnya, mengurangi risiko bahwa model ancaman tetap menjadi latihan teoritis.
Sebaliknya, biaya terkait dengan aktivitas yang diperlukan untuk melakukan model ancaman itu sendiri, yang merupakan waktu yang diperlukan oleh semua pihak yang terlibat untuk menghasilkan model ancaman dan mendiskusikannya.
Ini memohon pertanyaan: dapatkah kita menentukan proses pemodelan ancaman yang berfokus pada memaksimalkan nilai Bisnis dan meminimalkan biaya?
Pentingnya DevOps
Kami telah menyoroti betapa pentingnya memastikan bahwa pemodelan ancaman adalah praktik berharga yang terintegrasi dengan proses DevOps. Ini berarti bahwa proses harus tersedia untuk semua anggota tim, biasanya dengan menyederhanakan dan mengotomatiskannya. Yang paling penting, berfokus pada pemodelan ancaman untuk DevOps berarti bahwa kita perlu memastikan bahwa pengalaman tersebut terintegrasi secara mendalam dengan proses DevOps yang ada.
Pemodelan ancaman seharusnya tidak menjadi beban lain, tetapi sebaliknyaharus menjadi aset untuk memfasilitasi eliitas dan pengumpulan persyaratan keamanan, desain solusi yang aman, penyertaan aktivitas dalam alat Tugas & Pelacakan Bug pilihan, dan evaluasi risiko residual mengingat status solusi saat ini dan di masa depan.
Perataan dengan DevOps
Kita dapat menggunakan berbagai teknik untuk menyelaraskan pemodelan ancaman dengan praktik DevOps saat ini.
Ancaman dan mitigasi
Pertama, kita harus memfokuskan proses pemodelan ancaman pada apa yang perlu dilakukan. Ancaman, yang merupakan pola serangan dan bagaimana mungkin terjadi, diperlukan untuk menjelaskan mengapa tim perlu menerapkan kontrol keamanan. Mereka juga merupakan faktor dalam menentukan kapan mitigasi harus diimplementasikan. Namun, tujuan sebenarnya adalah untuk menentukan apa yang perlu dilakukan: mitigasi. Oleh karena itu, pendekatan harus mengarah pada identifikasi cepat mitigasi yang diperlukan dan harus menginformasikan proses keputusan sehingga lebih mudah untuk menentukan apa yang harus dilakukan dan kapan. Hasil utama dari proses keputusan ini adalah memiliki mitigasi yang dipilih di Backlog untuk menjadikannya bagian dari proses standar. Idealnya, alat pemodelan ancaman dan alat pelacakan tugas &bug harus disinkronkan untuk mencerminkan pembaruan status mitigasi dalam model ancaman. Ini akan memungkinkan revisi risiko residu secara dinamis dan otomatis, yang sangat penting untuk mendukung keputusan yang diinformasikan sebagai bagian dari koreografi biasa dari metodologi Agile yang diadopsi, seperti rapat Perencanaan Sprint.
Apa yang bisa Anda lakukan hari ini?
Sebagai pakar pemodelan ancaman, Anda harus memastikan untuk menerapkan proses pemodelan ancaman yang dapat mengidentifikasi tindakan dengan jelas dan memasukkannya ke dalam Tugas & Pelacakan Bug pilihan Anda. Salah satu caranya mungkin adalah dengan mengadopsi salah satu dari banyak alat pemodelan ancaman yang dapat mengotomatiskan proses ini.
Sebagai Pengembang, Anda harus fokus pada kontrol keamanan yang diidentifikasi seperlunya. Proses ini harus dirancang untuk memberikannya kepada Anda dengan cara yang sama seperti yang Anda harapkan untuk menerima aktivitas lain.
Fitur, cerita pengguna, dan tugas
Kami telah menyatakan bahwa mitigasi mewakili artefak terpenting yang dihasilkan oleh model ancaman mengenai integrasi DevOps. Oleh karena itu, penting untuk menentukan dengan jelas jenis objek yang dibuat dari mitigasi tersebut pada alat Tugas & Pelacakan Bug pilihan. Beberapa mitigasi mungkin berlangsung lebih dari Sprint. Oleh karena itu, mungkin yang terbaik adalah membuatnya sebagai Fitur. Tetapi banyak yang lebih mudah dan dapat diimplementasikan dalam satu Sprint; dengan demikian, akan mungkin untuk mewakili mereka sebagai cerita pengguna atau tugas. Meskipun menghasilkan jenis item kerja yang berbeda mungkin terjadi, ini dapat mengakibatkan proses rumit yang dapat menyebabkan kesalahan dan kebingungan. Untuk alasan ini, tampaknya lebih praktis untuk tetap dengan satu jenis item kerja. Mengingat bahwa mitigasi dapat dianggap sebagai anak-anak cerita pengguna, Anda dapat mempertimbangkan untuk mewakilinya sebagai Tugas, yang menyiratkan melonggarkan persyaratan agar jenis item kerja tersebut dijalankan dalam satu Sprint.
Apa yang bisa Anda lakukan hari ini?
Pastikan bahwa mitigasi yang diidentifikasi oleh model ancaman diwakili dalam backlog. Identifikasi cara untuk mewakilinya dengan jelas.
Cerita pengguna
Mitigasi bukan satu-satunya artefak bagian dari model ancaman, yang dapat dan harus diselaraskan dengan apa yang Anda miliki di alat Pelacakan Tugas & Bug Anda. Misalnya, Anda mungkin juga ingin mewakili ancaman. Tujuan ini dapat dicapai dengan memperluas cerita pengguna melalui penambahan klausul WITHOUT ke biasa "Sebagai [siapa saya] yang saya inginkan [apa yang saya inginkan] sehingga saya dapat [melakukan sesuatu]." Misalnya: "Sebagai pengguna, saya ingin membayar dengan kartu kredit saya sehingga saya dapat membeli beberapa barang, TANPA kartu kredit saya dicuri data yang dicuri". Klausa WITHOUT dapat dipetakan ke satu atau beberapa ancaman dan terkadang diizinkan untuk mengekspresikan Persyaratan Keamanan. Dengan memastikan bahwa keselarasan antara ancaman dan klausul WITHOUT ini dibuat eksplisit dalam model ancaman, kami dapat memastikan bahwa kemungkinan risiko tercermin dan ditangani oleh tim karena termasuk sebagai bagian dari cerita pengguna. Anda juga dapat menggunakan hubungan ini untuk memetakan setiap Persyaratan Keamanan yang diidentifikasi sebagai bagian dari cerita pengguna untuk setidaknya ancaman.
Senang mengetahuinya
Klausul WITHOUT bukanlah ide asli oleh tim yang telah menghasilkan halaman ini. Kami tidak yakin tentang siapa yang pertama kali memperkenalkannya, tetapi kami berterima kasih kepada siapa pun yang datang dengan ide ini.
Gambar 1: Menyelaraskan persyaratan
Misalnya, gambar sebelumnya memperlihatkan situasi berikut:
Ancaman A ditautkan ke Cerita Pengguna 1 melalui klausul TANPA 1.
Ancaman B ditautkan ke Cerita Pengguna 2 melalui klausul TANPA 2.
Ancaman B juga ditautkan ke Cerita Pengguna 3. Tetapi Cerita Pengguna 3 tidak ditetapkan ke klausul TANPA apa pun. Mengapa? Ini mewakili anomali potensial yang harus Anda selidiki.
Ancaman B juga ditautkan ke Cerita Pengguna 1. Belum jelas apakah kita harus mengizinkan memiliki cerita pengguna yang ditautkan ke lebih dari satu ancaman.
Ancaman C ditautkan ke Cerita Pengguna 4, yang terkait dengan TANPA 3 dan 4. Belum jelas apakah kita harus mengizinkan memiliki lebih dari satu klausa WITHOUT.
Ancaman D tidak ditautkan ke cerita pengguna apa pun. Apakah kita kehilangan cerita pengguna atau klausa WITHOUT?
Cerita Pengguna 5 ditautkan ke klausul TANPA, tetapi tidak memiliki ancaman terkait. Apakah kita kehilangan ancaman atau hanya tautan antara cerita pengguna dan ancaman?
Kami jarang mengidentifikasi Persyaratan Keamanan sebagai bagian dari model ancaman. Oleh karena itu, klausul WITHOUT memperkenalkan kesempatan untuk mengintegrasikan pengalaman lebih lanjut dengan memperluas model ancaman dengan Persyaratan Keamanan dan menautkannya dengan cerita pengguna terkait. Pendekatan ini akan memainkan peran penting dalam mengembangkan pengalaman pemodelan ancaman dari penilaian yang diulang dari waktu ke waktu untuk menjadi alat desain keamanan untuk DevOps.
Apa yang bisa Anda lakukan hari ini?
Mulai gunakan klausa WITHOUT dalam cerita pengguna Anda.
Petakan ancaman yang Anda identifikasi ke cerita pengguna dengan klausul WITHOUT, dan sebaliknya.
Pengalaman terintegrasi
Anda dapat menerapkan ide yang sama ke skenario lain. Misalnya, model ancaman dapat menautkan Persyaratan Keamanan dengan artefak di dalam model ancaman itu sendiri - seperti ancaman dan mitigasi - dan yang ada di alat Pelacakan Trek & Bug. Misalnya, persyaratan untuk menerapkan pemantauan untuk mengidentifikasi serangan yang sedang berlangsung harus dipetakan ke semua mitigasi yang terkait dengan pemantauan dan kemudian ke artefak yang sesuai dalam alat Pelacakan Tugas & Bug. Akibatnya, akan mudah untuk mengidentifikasi situasi di mana Persyaratan Keamanan tidak diwujudkan: pada kenyataannya, itu tidak akan ditautkan ke apa pun.
Anda dapat menggunakan tautan yang sama antara artefak di alat Pelacakan Tugas & Bug serta ancaman dan mitigasi yang diidentifikasi oleh model ancaman untuk memfasilitasi prioritas aktivitas keamanan. Keamanan biasanya diterapkan terakhir, terkadang untuk mengatasi kerentanan reaktif yang diidentifikasi oleh beberapa alat atau Uji Penetrasi. Sebaliknya, akan paling efektif untuk menerapkan mitigasi bersama dengan cerita atau fitur pengguna terkait. Mengapa menunggu untuk menerapkan kontrol untuk mengamankan detail kartu kredit ketika Anda harus menerapkannya bersama dengan fungsi pembayaran terkait? Model ancaman harus menyoroti hubungan tersebut dan memberikan cara sederhana untuk menentukan kapan menerapkan beberapa fitur selama Sprint memerlukan implementasi beberapa fitur keamanan terkait. Informasi ini dapat digunakan, misalnya, selama rapat Perencanaan Sprint untuk melakukan diskusi yang bermakna dan mendorong prioritas yang diinformasikan. Mekanismenya sederhana. Misalkan Pemilik Produk untuk proyek yang kami kerjakan memutuskan untuk merencanakan cerita pengguna untuk Sprint berikutnya. Cerita pengguna yang dikatakan memiliki klausul WITHOUT yang terkait dengan ancaman. Model ancaman mengidentifikasi beberapa mitigasi untuk ancaman yang sama. Oleh karena itu, kita dapat segera menyimpulkan bahwa kita harus memprioritaskan satu atau beberapa mitigasi yang diidentifikasi.
Gambar 2: Memprioritaskan keamanan
Misalnya, pada gambar di atas, kita dapat melihat bahwa Cerita Pengguna 1 ditautkan ke ancaman 1, yang pada gilirannya ditautkan ke mitigasi A dan B. Oleh karena itu, kita juga harus mempertimbangkan untuk menerapkan salah satu atau kedua mitigasi tersebut.
Apa yang bisa Anda lakukan hari ini?
Tautkan cerita pengguna dengan klausul WITHOUT ke item kerja yang sesuai dengan mitigasi yang dipilih menggunakan model ancaman sebagai referensi. Saat merencanakan Sprint berikutnya, pastikan untuk memprioritaskan aktivitas keamanan tertaut saat Anda menerapkan salah satu cerita pengguna tersebut dengan klausa WITHOUT.
Integrasi untuk menyoroti ketidakselarasan
Setelah kita mulai berpikir tentang bagaimana kita dapat menautkan artefak yang menyusun model ancaman dengan yang ada di alat Task & Bug Tracking, menjadi lebih mudah untuk mengidentifikasi peluang untuk meningkatkan kualitas keduanya. Kuncinya adalah memanfaatkan hubungan mereka untuk menyoroti perbedaan dan memanfaatkan informasi yang ada dalam satu untuk melengkapi, mengintegrasikan, dan menafsirkan apa yang ada di yang lain. Seperti yang dibahas di atas, Anda dapat melakukannya tanpa berdampak signifikan pada cara kerja tim. Itu karena pendekatan bergantung pada informasi yang ada dan menciptakan hubungan antara berbagai objek di berbagai dunia. Oleh karena itu, Model Ancaman akan menjadi sumber kebenaran untuk keamanan solusi. Pada saat yang sama, Backlog terus diselaraskan dengan status solusi.
Apa yang bisa Anda lakukan hari ini?
Verifikasi secara teratur bahwa tidak ada ancaman atau cerita pengguna yang tidak dipetakan dengan klausul WITHOUT.
Pemodelan ancaman dan operasi
Semua ide tersebut terutama difokuskan pada sisi pengembangan DevOps. Dapatkah kita melakukan sesuatu untuk meningkatkan Operasi juga? Kami berpikir begitu. Misalnya, akan mungkin untuk menggunakan pemodelan ancaman sebagai alat untuk memfasilitasi Analisis Akar Penyebab karena memberikan pandangan komprehensif tentang sistem dari perspektif keamanan dan dengan demikian dapat memberikan pemahaman yang lebih baik tentang implikasi beberapa serangan. Untuk mencapai itu, perlu untuk mengintegrasikan model ancaman dengan umpan yang ada dari alat Pemantauan yang dipilih. Pendekatan ini dapat mewakili pelengkap untuk SIEM yang dipilih.
Ide lain untuk mengintegrasikan pemodelan ancaman dengan Operasi adalah menggunakan yang pertama untuk mendorong desain bagaimana yang terakhir dapat terjadi. Contohnya adalah desain peristiwa untuk solusi. Pemodelan ancaman mengidentifikasi kemungkinan serangan, dan kita dapat menggunakan pengetahuan tersebut untuk mengidentifikasi peristiwa yang dapat dimunculkan solusi dalam cakupan ketika serangan tersebut gagal. Jika Anda melakukan validasi input yang ketat, penyerang berbahaya akan memerlukan beberapa upaya sebelum berhasil. Awalnya, upaya gagal, dan salah satunya akhirnya berhasil. Dengan menaikkan peristiwa untuk setiap kegagalan dan memicu pemberitahuan ketika beberapa ambang tercapai, Anda mungkin dapat mendeteksi serangan dan mengambil tindakan untuk memulihkannya. Situasi tersebut jarang terdeteksi jika Anda membatasi diri untuk memantau infrastruktur. Oleh karena itu, perlu untuk menyertakan peristiwa kustom, yang harus didesain dan diterapkan tim sebelum SOC dapat memanfaatkannya.
Selain itu, yang terakhir mungkin tidak tahu banyak tentang solusinya. Oleh karena itu, SOC mungkin tidak dapat menentukan cara bereaksi ketika validasi input gagal. Sayangnya, ketika pelanggaran data terjadi, sangat penting untuk bereaksi cepat untuk mengurangi kerusakan langsung dan probabilitas dan entitas denda akhir.
Oleh karena itu, kita perlu merencanakan terlebih dahulu apa yang perlu dipantau, dalam kondisi apa kita mungkin memiliki masalah, dan apa yang harus dilakukan ketika itu terjadi. Cara terbaik untuk mengidentifikasi peristiwa tersebut adalah dengan mengandalkan model ancaman. Oleh karena itu, akan sangat membantu untuk memanfaatkannya untuk menghasilkan artefak standar untuk memandu dan mempercepat implementasi konfigurasi yang diperlukan untuk mendorong Pemantauan dan Audit dan memfasilitasi Respons Insiden.
Apa yang bisa Anda lakukan hari ini?
Gunakan model ancaman secara aktif untuk mengidentifikasi peristiwa yang dapat Anda ajukan untuk setiap ancaman. Peristiwa tersebut dapat disediakan oleh infrastruktur, atau sesuatu yang harus dimunculkan aplikasi. Sertakan item kerja di backlog Anda untuk memastikan bahwa peristiwa tersebut diterapkan.
Bekerja secara aktif dengan tim Operasi dan Keamanan Anda, termasuk tim SOC, untuk memastikan bahwa peristiwa dimanfaatkan untuk meningkatkan pemberitahuan dan mengidentifikasi Insiden Keamanan.
Dampaknya pada ROI
Anda mungkin bertanya-tanya mengapa teknik tersebut dapat berdampak positif pada ROI pemodelan ancaman. Dari sudut pandang kami, mereka sangat penting untuk meningkatkan nilai pemodelan ancaman bagi tim DevOps. Masalah yang telah kita lihat berulang kali adalah bahwa tim tersebut melihat keamanan sebagai biaya yang memberikan nilai terbatas dan membutuhkan banyak pekerjaan yang tidak terduga. Terkadang, tidak jelas mengapa mereka harus berinvestasi begitu banyak waktu mereka memperbaiki keamanan. Akibatnya, keamanan menjadi masalah alih-alih menjadi kesempatan. Pemodelan ancaman berpotensi mengatasi masalah tersebut karena memberikan alasan untuk menerapkan keamanan. Selain itu, ini dapat dimulai di awal proses pengembangan dan menghindari kesalahan desain yang mungkin mahal jika tidak segera terdeteksi. Teknik di atas bertujuan untuk mengintegrasikan pemodelan ancaman dengan DevOps dengan lebih baik. Ini memastikan bahwa pembuat keputusan bisnis dan pengembang melihat pemodelan ancaman sebagai pelengkap alami untuk proses pengembangan dan operasi. Oleh karena itu, nilai yang diterima dengan mengadopsi pemodelan ancaman meningkat, dan biayanya menurun karena integrasi dengan berbagai alat yang sudah digunakan.
Menyederhanakan pekerjaan untuk pemodel ancaman
Aspek penting lainnya yang diperlukan untuk meningkatkan ROI pemodelan ancaman adalah terkait dengan mengurangi biayanya dan meningkatkan jumlah orang yang dapat memberikannya sambil mempertahankan tingkat kualitas yang lebih homogen.
Ada banyak upaya untuk mengatasi kekurangan orang yang kompeten. Beberapa di antaranya didasarkan pada keterlibatan aktif seluruh tim DevOps dalam latihan pemodelan ancaman. Idenya adalah untuk mengidentifikasi pemimpin inisiatif, yaitu seseorang dengan pengetahuan menengah tentang proses tetapi belum tentu seorang ahli, dan membuatnya memimpin diskusi di antara anggota tim lainnya. Pendekatan ini secara aktif didukung oleh penanda tangan Manifesto Pemodelan Ancaman.
Kami setuju bahwa pendekatan ini memungkinkan untuk mendapatkan nilai yang baik dan mewakili peningkatan atas situasi saat ini. Ini juga memberikan wawasan yang baik dan memungkinkan tim untuk menumbuhkan budaya keamanannya. Namun demikian, itu bukan tanpa kelemahan karena hanya mencakup beberapa masalah, meninggalkan banyak hal. Ini menciptakan masalah konsistensi karena akan terlalu mudah untuk turun ke lubang kelinci dan membuang waktu berharga pada masalah sekunder, kehilangan yang penting. Pengalaman pemimpin akan memainkan peran penting dalam mencegah situasi tersebut terjadi. Selain itu, pendekatan ini membutuhkan banyak waktu dari semua anggota tim untuk mendiskusikan setiap masalah.
Untuk alasan ini, bahkan menghabiskan beberapa jam per Sprint untuk latihan ini dapat mewakili investasi yang signifikan. Semua orang tahu bahwa sebagian besar tim cenderung membuang waktu pada pertemuan besar yang melibatkan semua orang, dan sesi pemodelan ancaman tersebut tidak akan membuat pengecualian. Namun, pendekatan ini sangat baik untuk produk kecil, di mana tim terdiri dari beberapa anggota senior.
Pendekatan yang berbeda
Mengingat keterbatasan pendekatan sebelumnya, kami lebih suka membatasi jumlah rapat, panjangnya, dan jumlah peserta. Oleh karena itu, tanggung jawab pemodel ancaman akan lebih signifikan: tidak hanya untuk memimpin wawancara tetapi juga untuk menciptakan dan memelihara model ancaman itu sendiri. Pendekatan ini membutuhkan kompetensi dan keahlian yang lebih signifikan. Pemodel ancaman dapat diwakili oleh Juara Keamanan atau oleh anggota tim Keamanan internal. Sebagian besar organisasi akan pergi untuk yang pertama karena tim Keamanan biasanya sepenuhnya dipesan.
Security Champions adalah anggota tim DevOps dengan minat tertentu pada keamanan. Mereka bukan ahli dengan cara apa pun, tetapi mereka memiliki pengetahuan dasar dan kesediaan untuk meningkatkan postur keamanan tim mereka. Idenya adalah untuk membuat koneksi istimewa antara Juara Keamanan dan tim Keamanan internal sehingga yang pertama diberdayakan untuk membantu tim mereka dalam melakukan hal yang benar, sementara tim Keamanan dapat mengurangi beban kerjanya. Dengan pemodelan ancaman, Security Champions akan bertindak sebagai pemodel ancaman, dan tim Keamanan internal akan memiliki tanggung jawab untuk memandu mereka dan meninjau pekerjaan mereka.
Apa yang bisa Anda lakukan hari ini?
Selidiki kemungkinan untuk mengadopsi program Security Champions dan memanfaatkannya untuk lebih memperkuat Siklus Hidup Pengembangan Perangkat Lunak Aman Anda.
Peran basis pengetahuan
Masalah signifikan dengan pemodelan ancaman adalah memastikan bahwa kualitas pengalaman dan nilai untuk tim DevOps tinggi tidak peduli siapa yang melakukan model ancaman. Dengan Juara Keamanan, masalah ini menjadi lebih mendesak. Ide untuk mengatasinya adalah menyediakan basis pengetahuan untuk mendorong pembuatan model ancaman. Pangkalan Pengetahuan untuk pemodelan ancaman adalah paket informasi tentang konteks tertentu: mereka berisi definisi entitas yang terkait dengan konteks tersebut, kemungkinan pola serangan atas entitas tersebut, dan mitigasi standar yang dapat diterapkan. Pangkalan pengetahuan memungkinkan organisasi untuk mendapatkan hasil yang lebih baik dan lebih konsisten karena mewakili materi referensi yang memandu pemodel ancaman dengan cara yang preskriptif. Pangkalan pengetahuan harus memiliki aturan yang memungkinkan kami menerapkan ancaman dan mitigasi ke sistem secara otomatis. Otomatisasi ini akan memungkinkan kita untuk mengatasi fakta bahwa beberapa pemodel ancaman mungkin tidak memiliki pengalaman yang diperlukan untuk menentukan apakah ancaman harus diterapkan atau jika beberapa mitigasi efektif.
Pangkalan pengetahuan bukanlah ide baru: banyak alat pemodelan ancaman saat ini yang sudah mendukungnya dalam beberapa bentuk. Tetapi banyak implementasi saat ini memiliki kelemahan yang signifikan. Misalnya, Anda harus dapat mempertahankan basis pengetahuan dengan mudah. Ketahanan mereka adalah masalah yang masih belum tertangani. Misalnya, tidak mudah untuk mengidentifikasi sumber informasi terbaik yang digunakan untuk membangunnya. Selain itu, pemeliharaan biasanya manual. Pembuatan dan pemeliharaan basis pengetahuan harus menjadi tanggung jawab tim Keamanan internal organisasi. Kami berharap perusahaan akan mulai menyediakan basis pengetahuan untuk alat pemodelan ancaman yang paling umum untuk mengangkat beberapa beban dari pelanggan mereka di masa depan. Basis pengetahuan tersebut harus fleksibel untuk mendukung dan memfasilitasi adopsi mereka bahkan oleh organisasi yang paling matang, yang perlu menyesuaikan basis pengetahuan tersebut dengan praktik, kebijakan, dan peraturan mereka.
Apa yang bisa Anda lakukan hari ini?
Pertimbangkan kemungkinan untuk menculik bagian dari upaya Tim Keamanan terpusat untuk mengembangkan basis pengetahuan yang dapat digunakan oleh berbagai tim pengembangan untuk mempercepat pemodelan ancaman.
Mengkonsumsi basis pengetahuan
Masalah lain dengan basis pengetahuan adalah kadang-kadang terlalu kompleks untuk dikonsumsi. Banyak dari mereka mencoba untuk menjadi komprehensif dengan menyertakan masalah penting dan kurang penting. Sayangnya, tidak semuanya diperlukan oleh semua sistem. Anda ingin mengadopsi pendekatan yang lebih sederhana ketika sistem yang Anda analisis kecil dan tidak menangani data sensitif. Sebaliknya, Anda ingin lebih mendalam jika sistem kompleks dan memproses PII dan data nilai Bisnis tinggi. Oleh karena itu, harus dimungkinkan untuk menerapkan versi pengetahuan yang berbeda tergantung pada konteks atau menandai beberapa pola serangan dan mitigasi terkait sebagai "TOP". Akibatnya, pemodel ancaman akan dapat memutuskan apakah mereka menginginkan pengalaman komprehensif atau menjadi mudah dan meminimalkan pekerjaan yang diperlukan.
Berbicara tentang efisiensi, sangat penting untuk memastikan bahwa aktivitas disederhanakan dan diotomatisasi sebanyak mungkin untuk mengurangi jumlah pekerjaan yang diperlukan. Kami memang berpikir bahwa titik manis untuk melakukan Model Ancaman dari solusi berukuran rata-rata harus 1 hari kerja untuk pemodel ancaman. Hasil tersebut hanya dimungkinkan jika alat pilihan menyediakan akselerator untuk memungkinkan pemotongan waktu yang diperlukan. Misalnya, jika alat ini menerapkan 20 jenis mitigasi yang berbeda di 100 tempat yang berbeda, dan Anda diminta untuk menentukan masing-masing dari mereka statusnya, Anda akan 5 kali lebih efisien dengan berfokus pada yang pertama alih-alih yang terakhir. Alat pilihan harus memberikan kemampuan ini sambil tetap memberikan kemungkinan untuk melakukan pekerjaan yang lebih menyeluruh ketika diperlukan.
Apa yang bisa Anda lakukan hari ini?
Jika basis pengetahuan yang Anda gunakan saat ini tidak mendukung konsep ancaman dan mitigasi "TOP", pertimbangkan kemungkinan untuk menghapus apa yang jarang diperlukan atau berguna, untuk memungkinkan fokus hanya pada apa yang sebenarnya penting.
Terkadang masalahnya adalah bahwa basis pengetahuan yang diadopsi mencoba untuk generik dan mencakup beberapa skenario. Anda dapat meningkatkan situasi dengan mengkhususkan mereka.
Mengajukan pertanyaan yang tepat
Selama analisis kami, kami telah mempertimbangkan kemungkinan penggunaan alat untuk mendukung kerangka kerja Pertanyaan untuk mendorong fase pertama analisis. Kami telah memperhatikan bahwa sebagian besar pemodel ancaman yang tidak berpengalaman tidak dapat mengajukan pertanyaan yang tepat untuk mendapatkan informasi yang diperlukan untuk analisis mereka. Beberapa Pakar kami telah menunjukkan bahwa dimungkinkan untuk menentukan beberapa pertanyaan penting berdasarkan diagram sistem dalam cakupan. Pertanyaan-pertanyaan tersebut bahkan dapat diterapkan secara otomatis, dengan beberapa aturan generasi. Masalahnya adalah bahwa pendekatan ini mungkin tidak memberikan nilai yang tampaknya dijanjikannya. Itu akan karena Anda perlu memahami alasan di balik setiap pertanyaan. Jika tidak, Anda tidak akan dapat mengevaluasi jawaban dan menentukan apakah itu memuaskan. Namun, pembuatan pertanyaan otomatis dapat memberikan nilai signifikan bagi pemodel ancaman yang kurang ahli, meningkatkan pemahaman mereka tentang sistem dalam cakupan.
Apa yang bisa Anda lakukan hari ini?
Mengadopsi pendekatan terstruktur untuk mengajukan pertanyaan. Misalnya, tim kami telah memiliki hasil yang baik dengan mengadopsi Microsoft STRIDE sebagai referensi. Anda dapat melakukannya dengan meminta setiap komponen pertanyaan solusi seperti:
Spoofing: bagaimana komponen mengautentikasi terhadap layanan dan sumber daya yang digunakannya?
Perusakan: apakah komponen memvalidasi pesan yang diterimanya? Apakah validasi longgar atau ketat?
Penolakan: apakah komponen mencatat interaksi dalam log audit?
Pengungkapan Informasi: apakah lalu lintas masuk dan keluar dienkripsi komponen? Protokol dan algoritma apa yang diizinkan?
Penolakan Layanan: apakah komponen dikonfigurasi dalam ketersediaan tinggi? Apakah terlindungi dari serangan DDoS?
Elevasi Hak Istimewa: apakah pengguna diberi hak istimewa paling sedikit yang diperlukan? Apakah kode campuran solusi ditargetkan untuk pengguna normal dengan itu untuk pengguna dengan hak istimewa tinggi?
Teknik seperti ini dapat diajarkan dan dapat ditingkatkan dengan pengalaman. Oleh karena itu, penting untuk menerapkan pendekatan Pembelajaran Berkelanjutan yang dirancang untuk mengumpulkan pembelajaran dan menyebarkannya dalam organisasi.
Dampaknya pada ROI
Intinya, dimungkinkan untuk mengidentifikasi banyak ide untuk meningkatkan efisiensi pengalaman pemodelan ancaman, kualitasnya, dan pada akhirnya meningkatkan ROI. Upaya ini harus dianggap sebagai proses yang sedang berlangsung, meskipun, yang harus diarahkan ke peningkatan praktik yang berkelanjutan.
Kesimpulan
Pemodelan ancaman adalah metodologi yang sangat baik untuk meningkatkan keamanan organisasi Anda. Jika dilakukan dengan benar, itu dapat memberikan nilai dengan biaya yang sangat wajar. Kami telah mengidentifikasi berbagai teknik yang mungkin terbukti penting untuk meningkatkan nilai pemodelan ancaman untuk mengamankan solusi modern, termasuk:
Menyelaraskan model ancaman dengan praktik DevOps Anda dengan
Berfokus pada mitigasi
Menautkan mitigasi dengan cerita pengguna
Menyoroti perbedaan antara model ancaman dan backlog
Gunakan Model ancaman untuk mendorong Pemantauan dan audit yang lebih komprehensif untuk keamanan
Menyederhanakan pembuatan model ancaman dan meningkatkan konsistensi hasil
Mengandalkan Juara Keamanan
Mengadopsi basis pengetahuan untuk mengotomatiskan identifikasi ancaman dan mitigasi
Menciptakan basis pengetahuan yang lebih baik
Berikan kerangka kerja pertanyaan yang didukung oleh otomatisasi
Mudah-mudahan, beberapa dari mereka sudah dapat ditemukan di alat pemodelan ancaman pilihan Anda. Yang lain akan disertakan di masa depan. Kita tahu bahwa memaksimalkan ROI untuk pemodelan ancaman adalah upaya jangka panjang yang membutuhkan jawaban yang belum kita miliki. Kita juga tahu bahwa beberapa pertanyaan masih belum diketahui. Makalah ini harus menyediakan beberapa makanan untuk dipikirkan dan mudah-mudahan dapat membantu Anda dalam meningkatkan bagaimana Anda melakukan pemodelan ancaman. Kami berharap itu bisa menjadi mercusuar bagi Anda dan kami, dan itu akan berguna untuk mengarahkan upaya kami untuk tahun-tahun yang akan datang.