Keamanan di DevOps (DevSecOps)
Keamanan adalah bagian penting dari DevOps. Tapi bagaimana tim tahu ini aman? Apakah pernah benar-benar memungkinkan untuk memberikan layanan yang benar-benar aman?
Sayangnya, jawabannya adalah tidak. DevSecOps adalah upaya berkelanjutan yang membutuhkan perhatian semua orang di tim. Meskipun pekerjaan tidak pernah benar-benar dilakukan, tim praktik bekerja untuk mencegah dan menangani pelanggaran menghasilkan sistem yang seaman dan setangguh mungkin.
"Pada dasarnya, jika seseorang ingin masuk, mereka akan masuk... terima itu. Apa yang kami katakan kepada klien adalah: nomor satu, Anda berada di medan pertarungan, baik jika Anda menyadarinya atau tidak. Nomor dua, keamanan Anda hampir pasti dapat ditembus." -- Michael Hayden, Mantan Direktur NSA dan CIA
Percakapan keamanan
Tim yang tidak memiliki strategi DevSecOps formal didorong untuk memulai perencanaan sesegera mungkin. Pada awalnya mungkin ada beberapa perlawanan dari anggota tim yang tidak sepenuhnya menghargai ancaman yang ada. Orang lain mungkin tidak merasa bahwa tim dilengkapi untuk menghadapi masalah dan bahwa investasi khusus apa pun akan menjadi gangguan yang sia-sia dari fitur pengiriman. Namun, diperlukan percakapan untuk membangun konsekuensi tentang sifat risiko, bagaimana tim dapat menguranginya, dan apakah tim membutuhkan sumber daya yang saat ini tidak mereka miliki.
Bersiaplah untuk menghadapi orang skeptis yang berargumen seperti:
- Seberapa nyata ancaman ini? Tim sering tidak menghargai potensi nilai layanan dan data yang dibebankan dengan perlindungan.
- Tim kita bagus, kan? Diskusi keamanan dapat dianggap sebagai keraguan dalam kemampuan tim untuk membangun sistem yang aman.
- Saya rasa itu tidak mungkin. Ini adalah argumen umum dari teknisi junior. Mereka yang memiliki pengalaman biasanya tahu lebih baik.
- Kami belum pernah mengalami pelanggaran. Tapi bagaimana Anda bisa tahu? Bagaimana Anda tahu?
- Perdebatan tak berujung tentang nilai. DevSecOps adalah komitmen serius yang mungkin dianggap sebagai gangguan dari pekerjaan fitur inti. Meskipun investasi keamanan harus seimbang dengan kebutuhan lain, investasi tersebut tidak dapat diabaikan.
Pergeseran pola pikir
Pergeseran pola pikir ke budaya DevSecOps mencakup pemikiran penting tentang tidak hanya mencegah pelanggaran, tetapi juga mengasumsikannya.
Komponen strategi keamanan
Ada banyak teknik yang dapat diterapkan dalam pencarian untuk sistem yang lebih aman.
| Mencegah pelanggaran | Mengasumsikan pelanggaran |
|---|---|
| Model ancaman | Latihan permainan perang |
| Peninjauan kode | Monitor keamanan pusat |
| Pengujian keamanan | Pengujian penetrasi situs langsung |
| Siklus hidup pengembangan keamanan (SDL) |
Setiap tim harus memiliki setidaknya beberapa praktik untuk mencegah pelanggaran. Menulis kode yang aman telah menjadi lebih default, dan ada banyak alat gratis dan komersial untuk membantu dalam analisis statis dan fitur pengujian keamanan lainnya.
Namun, banyak tim tidak memiliki strategi dalam menangani dunia tempat mereka menganggap mereka akan mengalami pelanggaran pada titik tertentu. Ini bisa menjadi hal yang sulit untuk diakui, terutama saat mengalami percakapan yang sulit dengan manajemen. Hal terpenting yang perlu difokuskan adalah bahwa mempraktikkan teknik yang mengasumsikan pelanggaran membantu tim menjawab pertanyaan tentang keamanan pada waktu mereka sendiri, sehingga mereka tidak perlu mencari tahu semuanya selama keadaan darurat keamanan yang sebenarnya.
Pertanyaan umum yang perlu dipikirkan tim:
- Bagaimana saya akan mendeteksi serangan?
- Bagaimana tanggapannya jika ada serangan atau penetrasi?
- Bagaimana kita akan pulih dari serangan, seperti kapan data telah bocor atau dirusak?
Praktik DevSecOps Utama
Ada beberapa praktik DevSecOps umum yang berlaku untuk hampir semua tim.
Pertama, tim harus fokus pada peningkatan waktu rata-rata untuk deteksi dan waktu rata-rata untuk pemulihan. Ini adalah metrik yang menunjukkan berapa lama waktu yang dibutuhkan untuk mendeteksi pelanggaran dan berapa lama waktu yang dibutuhkan untuk pulih. Mereka dapat dilacak melalui pengujian situs langsung yang sedang berlangsung dari rencana respons keamanan. Saat mengevaluasi potensi kebijakan, meningkatkan metrik ini harus menjadi pertimbangan penting.
Tim juga harus berlatih pertahanan secara mendalam. Saat pelanggaran terjadi, sering kali menyebabkan penyerang mendapatkan akses ke jaringan internal dan semua yang mereka tawarkan. Meskipun akan ideal untuk menghentikannya sebelum sampai sejauh itu, kebijakan dengan asumsi pelanggaran akan mendorong tim untuk meminimalkan paparan dari penyerang yang telah masuk.
Akhirnya, tim harus melakukan penilaian pasca-pelanggaran berkala dari praktik dan lingkungan. Setelah pelanggaran diselesaikan, tim harus mengevaluasi performa kebijakan, serta kepatuhan mereka sendiri kepada kebijakan. Ini tidak berfungsi hanya untuk memastikan kebijakan efektif, tetapi juga bahwa tim benar-benar mengikuti kebijakan ini. Setiap pelanggaran, baik nyata atau dipraktikkan, harus dilihat sebagai kesempatan untuk berbenah.
Strategi untuk mengurangi ancaman
Daftar potensi ancaman terhadap sistem sangat substansial sehingga tidak mungkin untuk menghitung semuanya. Beberapa lubang keamanan disebabkan oleh masalah dalam dependensi seperti sistem operasi dan pustaka, sehingga menjaganya tetap terbaru sangat penting. Yang lain disebabkan oleh bug dalam kode sistem yang memerlukan analisis yang cermat untuk ditemukan dan diperbaiki. Manajemen rahasia yang buruk adalah penyebab dari banyak pelanggaran, seperti halnya rekayasa sosial. Ini adalah praktik yang baik untuk memikirkan berbagai jenis lubang keamanan dan apa artinya untuk sistem.
Vektor serangan
Pertimbangkan skenario saat penyerang telah mendapatkan akses ke info masuk pengembang. Apa yang dapat mereka lakukan?
| Hak istimewa | Serangan |
|---|---|
| Apakah mereka dapat mengirim email? | Kolega phish |
| Apakah mereka dapat mengakses mesin lain? | Masuk, mimikatz, ulangi |
| Apakah mereka dapat memodifikasi sumber | Menyuntikkan kode |
| Apakah mereka dapat mengubah proses build/rilis? | Menyuntikkan kode, menjalankan skrip |
| Apakah mereka dapat mengakses lingkungan pengujian? | Jika lingkungan produksi mengambil dependensi pada lingkungan pengujian, eksploitasi kesempatan ini |
| Apakag mereka dapat mengakses lingkungan produksi? | Begitu banyak pilihan... |
Bagaimana tim biru dapat bertahan melawan ini?
- Menyimpan rahasia di vault yang dilindungi
- Menghapus akun admin lokal
- Membatasi SAMR
- Penjaga Kredensial
- Menghapus server berumah dua
- Langganan terpisah
- Autentikasi multi faktor
- Stasiun kerja akses istimewa
- Mendeteksi dengan ATP & Azure Security Center
Manajemen rahasia
Semua rahasia harus disimpan dalam vault yang dilindungi. Rahasia meliputi:
- Kata sandi, kunci, dan token
- Kunci akun penyimpanan
- Sertifikat
- Info masuk yang digunakan di lingkungan non-produksi bersama juga
Gunakan hierarki vault untuk menghilangkan duplikasi rahasia. Pertimbangkan juga bagaimana dan kapan rahasia diakses. Beberapa digunakan pada waktu penyebaran saat membangun konfigurasi lingkungan, sedangkan yang lain diakses pada run-time. Rahasia waktu penyebaran biasanya memerlukan penyebaran baru untuk mengambil pengaturan baru, sedangkan rahasia run-time diakses saat diperlukan dan dapat diperbarui kapan saja.
Platform memiliki fitur penyimpanan yang aman untuk mengelola rahasia di alur CI/CD dan lingkungan cloud, seperti Azure Key Vault dan GitHub Actions.
Alat yang bermanfaat
- Azure Security Center sangat bagus untuk peringatan infrastruktur generik, seperti untuk malware, proses yang mencurigakan, dll.
- Alat analisis kode sumber untuk pengujian keamanan aplikasi statis (SAST).
- Keamanan GitHub tingkat lanjut untuk analisis dan pemantauan repositori.
- mimikatz mengekstrak kata sandi, kunci, kode pin, tiket, dan banyak lagi dari memori
lsass.exe, Layanan Subsistem Otoritas Keamanan Lokal pada Windows. Ini hanya memerlukan akses administratif ke komputer, atau akun dengan hak istimewa debug yang diaktifkan. - BloodHound membangun grafik hubungan dalam lingkungan Direktori Aktif. Ini dapat digunakan tim merah untuk mengidentifikasi vektor serangan yang sulit diidentifikasi dengan cepat dan mudah.
Latihan permainan perang
Praktik umum di Microsoft adalah terlibat dalam latihan game perang. Ini adalah peristiwa pengujian keamanan saat dua tim ditugaskan untuk menguji keamanan dan kebijakan sistem.
Tim merah mengambil peran sebagai penyerang. Mereka mencoba memodelkan serangan dunia nyata untuk menemukan celah dalam strategi keamanan. Jika mereka dapat mengeksploitasi apa pun, mereka juga menunjukkan potensi dampak dari pelanggaran mereka.
Tim biru mengambil peran tim DevOps. Mereka menguji kemampuannya untuk mendeteksi dan menanggapi serangan tim merah. Ini membantu meningkatkan kesadaran situasi dan mengukur dampak kesiapan & dari strategi DevSecOps.
Mengembangkan strategi permainan perang
Salah satu alasan permainan perang sangat efektif dalam memperkuat keamanan adalah bahwa mereka memotivasi tim merah untuk menemukan dan mengeksploitasi masalah. Mungkin akan jauh lebih mudah daripada yang diharapkan sejak dini. Tim yang belum mencoba menyerang sistem mereka sendiri secara aktif umumnya tidak menyadari ukuran dan kuantitas lubang keamanan yang tersedia untuk penyerang. Pada awalnya, Ini mungkin menyebabkan demoralisasi tim biru karena mereka akan dijalankan berulang kali. Untungnya, sistem dan praktik harus berkembang dari waktu ke waktu sehingga tim biru secara konsisten menang.
Mempersiapkan permainan perang
Sebelum memulai permainan perang, tim harus mengurus masalah apa pun yang dapat mereka temukan melalui kode keamanan. Ini adalah latihan yang bagus untuk dilakukan sebelum mencoba serangan karena akan memberikan pengalaman dasar bagi semua orang untuk dibandingkan setelah eksploitasi pertama ditemukan nantinya. Ada baiknya untuk memulai dengan mengidentifikasi kerentanan melalui tinjauan kode manual dan alat analisis statis.
Menata tim
Tim merah dan biru harus diatur oleh spesialisasi. Tujuannya adalah untuk membangun tim yang paling mampu untuk setiap sisi guna mengeksekusi seefektif mungkin.
Tim merah harus menyertakan beberapa teknisi dan pengembang yang memiliki kebiasaan dengan keamanan serta sangat terbiasa dengan kode. Ini juga membantu untuk menambah tim dengan spesialis pengujian penetrasi, jika memungkinkan. Jika tidak ada spesialis di tempat, banyak perusahaan menyediakan layanan ini bersama dengan mentoring.
Tim biru harus terdiri dari teknisi dengan pemikiran ops yang memiliki pemahaman mendalam tentang sistem dan pengelogan yang tersedia. Mereka memiliki peluang terbaik untuk mendeteksi dan mengatasi perilaku mencurigakan.
Menjalankan game perang lebih awal
BIasanya, tim merah efektif di awal pertandingan perang. Mereka harus dapat berhasil melalui serangan yang cukup sederhana, seperti dengan menemukan rahasia yang dilindungi dengan buruk, injeksi SQL, dan kampanye phishing yang sukses. Luangkan banyak waktu antar ronde untuk menerapkan perbaikan dan umpan balik tentang kebijakan. Ini akan bervariasi menurut organisasi, tetapi Anda tidak ingin memulai putaran berikutnya sampai semua orang yakin bahwa putaran sebelumnya telah dimanfaatkan dengan baik.
Permainan perang yang sedang berlangsung
Setelah beberapa ronde, tim merah harus mengandalkan teknik yang lebih canggih, seperti pembuatan skrip lintas situs (XSS), eksploitasi deserialisasi, dan kerentanan sistem teknik. ini juga akan membantu untuk membawa tambahan pakar keamanan di luar di area seperti Direktori Aktif untuk menyerang eksploitasi yang lebih tidak jelas. Pada saat ini, tim biru seharusnya tidak hanya memiliki platform yang ditingkatkan untuk dipertahankan, tetapi juga akan menggunakan pencatatan yang komprehensif dan terpusat untuk forensik pasca-pelanggaran.
"Pemain bertahan berpikir dalam daftar. Penyerang berpikir dalam grafik. Selama ini dilakukan, penyerang akan menang." -- John Lambert (MSTIC)
Seiring berjalannya waktu, tim merah akan membutuhkan waktu lebih lama untuk mencapai tujuan. Saat mereka melakukannya, itu akan sering membutuhkan penemuan dan penautan beberapa kerentanan untuk memiliki dampak terbatas. Melalui penggunaan alat pemantauan real-time, tim biru harus mulai menangkapnya secara real time.
Panduan
Permainan perang seharusnya terorganisir. Penting untuk diingat bahwa tujuannya adalah untuk menghasilkan sistem yang lebih efektif yang dijalankan oleh tim yang lebih efektif.
Kode Etik
Berikut adalah contoh kode etik yang digunakan oleh Microsoft:
- Tim merah dan biru tidak akan melakukan hal berbahaya. Jika potensi menyebabkan kerusakan signifikan, ini harus di dokumentasikan dan ditangani.
- Tim merah tidak boleh membahayakan lebih dari yang diperlukan untuk menangkap aset target.
- Aturan akal sehat berlaku untuk serangan fisik. Sementara tim merah didorong untuk kreatif dengan serangan non-teknis, seperti rekayasa sosial, mereka tidak boleh mencetak lencana palsu, melecehkan orang, dll.
- Jika serangan rekayasa sosial berhasil, jangan ungkapkan nama orang yang disusupi. Pelajaran dapat dibagikan tanpa mengasingkan atau mempermalukan anggota tim yang akan terus bekerja dengan semua orang.
Aturan keterlibatan
Berikut adalah contoh aturan keterlibatan yang digunakan oleh Microsoft:
- Jangan merusak ketersediaan sistem apa pun.
- Jangan mengakses data pelanggan eksternal.
- Jangan melemahkan perlindungan keamanan di tempat secara signifikan pada layanan apa pun.
- Jangan melakukan tindakan merusak terhadap sumber daya apa pun secara sengaja.
- Melindungi info masuk, kerentanan, dan informasi penting lainnya yang diperoleh.
Hasil
Setiap risiko keamanan atau pelajaran yang dipelajari harus di dokumentasikan dalam backlog item perbaikan. Tim harus menentukan perjanjian tingkat layanan (SLA) untuk melihat seberapa cepat risiko keamanan akan ditangani. Risiko berat harus ditangani sesegera mungkin, sedangkan masalah kecil mungkin memiliki tenggat waktu dua sprint.
Laporan harus disajikan kepada seluruh organisasi dengan pelajaran yang dipelajari dan kerentanan yang ditemukan. Ini adalah kesempatan belajar untuk semua orang, jadi manfaatkanlah sebaik mungkin.
Pelajaran yang dipelajari di Microsoft
Microsoft secara teratur mempraktikkan game perang dan telah mempelajari banyak pelajaran sepanjang waktu.
- Game perang adalah cara yang sangat efektif untuk mengubah budaya DevSecOps dan menjaga keamanan tetap terbaik.
- Serangan pengelabuan sangat efektif bagi penyerang dan tidak boleh diremehkan. Dampaknya dapat dimuat dengan membatasi akses produksi dan memerlukan autentikasi dua faktor.
- Kontrol sistem rekayasa mengarah pada kontrol segala hal. Pastikan untuk mengontrol akses secara ketat ke agen build/rilis, antrean, kumpulan, dan definisi.
- Latih pertahanan secara mendalam untuk membuatnya lebih sulit bagi penyerang. Setiap batas yang mereka miliki untuk melanggar akan memperlambat mereka dan menawarkan kesempatan lain untuk menangkap mereka.
- Jangan pernah merusak kepercayaan. Produksi tidak boleh mempercayai apa pun dalam pengujian.
Langkah berikutnya
Pelajari selengkapnya tentang siklus hidup pengembangan keamanan dan DevSecOps di Azure.