Keamanan di DevOps (DevSecOps)

Keamanan adalah bagian utama dari DevOps. Tetapi bagaimana tim tahu apakah sistem aman? Apakah benar-benar mungkin untuk memberikan layanan yang benar-benar aman?

Sayangnya, jawabannya adalah tidak. DevSecOps adalah upaya berkelanjutan yang membutuhkan perhatian semua orang dalam pengembangan dan operasi TI. Meskipun pekerjaan tidak pernah benar-benar dilakukan, praktik yang digunakan tim untuk mencegah dan menangani pelanggaran dapat membantu menghasilkan sistem yang seaman dan tangguh mungkin.

"Pada dasarnya, jika seseorang ingin masuk, mereka akan masuk... terima itu. Apa yang kami sampaikan kepada klien adalah: pertama, Anda memang sedang berada dalam pertarungan ini, terlepas dari apakah Anda sebelumnya menyadari atau tidak. Nomor dua, Anda hampir pasti ditembus." -- Michael Hayden, Mantan Direktur NSA dan CIA

Percakapan keamanan

Tim yang tidak memiliki strategi DevSecOps formal didorong untuk mulai merencanakan sesegera mungkin. Pada awalnya mungkin ada perlawanan dari anggota tim yang tidak sepenuhnya menghargai ancaman yang ada. Yang lain mungkin merasa bahwa tim tidak dilengkapi untuk menghadapi masalah dan bahwa setiap investasi khusus akan menjadi pengalihan yang tidak produktif dari proses pengiriman fitur. Namun, perlu untuk memulai percakapan untuk membangun konsekuensi mengenai sifat risiko, bagaimana tim dapat menguranginya, dan apakah tim membutuhkan sumber daya yang saat ini tidak mereka miliki.

Harapkan skeptis untuk membawa beberapa argumen umum, seperti:

• Seberapa nyata ancamannya? Tim sering tidak menghargai potensi nilai dari layanan dan data yang dipercayakan untuk dilindungi.
• Tim kita bagus, kan? Diskusi keamanan dapat dianggap sebagai keraguan dalam kemampuan tim untuk membangun sistem yang aman.
• Kurasa itu tidak mungkin. Ini adalah argumen umum dari insinyur junior. Mereka yang memiliki pengalaman biasanya lebih tahu.
• Kami belum pernah dilanggar. Tapi bagaimana kau bisa tahu? Bagaimana kau bisa tahu?
• Perdebatan tak berujung tentang nilai. DevSecOps adalah komitmen serius yang mungkin dianggap sebagai gangguan dari pekerjaan fitur inti. Meskipun investasi keamanan harus diimbangi dengan kebutuhan lain, investasi tersebut tidak dapat diabaikan.

Pergeseran pola pikir

Budaya DevSecOps membutuhkan pergeseran penting dalam pola pikir. Anda tidak hanya perlu mencegah pelanggaran, tetapi juga mengasumsikannya .

Komponen strategi keamanan

Ada banyak teknik yang dapat diterapkan dalam pencarian untuk sistem yang lebih aman.

Mencegah pelanggaran	Asumsi akan kemungkinan pelanggaran
Model ancaman	Latihan permainan perang
Peninjauan kode	Pemantau keamanan pusat
Pengujian keamanan	Tes penetrasi situs langsung
Siklus hidup pengembangan keamanan (SDL)

Setiap tim harus sudah memiliki setidaknya beberapa praktik untuk mencegah pelanggaran. Menulis kode 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 yang mengasumsikan pelanggaran sistem tidak dapat dihindari. Mengasumsikan bahwa Anda telah dibobol bisa sulit untuk diakui, terutama ketika harus menghadapi percakapan sulit dengan pihak manajemen, tetapi asumsi itu dapat membantu Anda menjawab pertanyaan tentang keamanan pada waktu yang Anda tentukan sendiri. Anda tidak ingin mencari tahu semuanya selama keadaan darurat keamanan nyata.

Pertanyaan umum yang perlu dipikirkan meliputi:

• Bagaimana Anda akan mendeteksi serangan?
• Bagaimana Anda akan merespons jika ada serangan atau penetrasi?
• Bagaimana Anda akan pulih dari serangan, seperti ketika data telah bocor atau dirusak?

Praktik Utama DevSecOps

Ada beberapa praktik DevSecOps umum yang berlaku untuk hampir semua tim.

Pertama, fokus pada peningkatan waktu rata-rata untuk deteksi dan waktu rata-rata untuk pemulihan. Metrik ini menunjukkan berapa lama waktu yang diperlukan untuk mendeteksi pelanggaran dan berapa lama waktu yang dibutuhkan untuk pulih. Mereka dapat dilacak melalui pengujian situs secara langsung dan berkelanjutan terhadap rencana respons keamanan. Saat mengevaluasi kebijakan potensial, meningkatkan metrik ini harus menjadi pertimbangan penting.

Berlatih pertahanan secara mendalam. Ketika pelanggaran terjadi, penyerang bisa mendapatkan akses ke jaringan internal dan segala sesuatu di dalamnya. Meskipun idealnya menghentikan penyerang sebelum mencapai titik tersebut, kebijakan yang menganggap adanya pelanggaran mendorong tim untuk meminimalkan paparan dari penyerang yang sudah berhasil masuk.

Terakhir, lakukan penilaian berkala pasca-pelanggaran terhadap baik praktik maupun lingkungan Anda. Setelah pelanggaran diselesaikan, tim Anda harus mengevaluasi performa kebijakan, serta kepatuhan mereka sendiri kepada mereka. Kebijakan paling efektif ketika tim benar-benar mengikutinya. Setiap pelanggaran, baik nyata atau dipraktikkan, harus dipandang sebagai kesempatan untuk meningkatkan.

Strategi untuk mengurangi ancaman

Ada terlalu banyak ancaman untuk menghitung semuanya. Beberapa lubang keamanan disebabkan oleh masalah dalam dependensi seperti sistem operasi dan pustaka, sehingga menjaga agar tetap mutakhir sangat penting. Yang lain disebabkan oleh bug dalam kode sistem yang memerlukan analisis yang cermat untuk menemukan dan memperbaiki. Manajemen rahasia yang buruk adalah penyebab banyak pelanggaran, seperti halnya rekayasa sosial. Ini adalah praktik yang baik untuk memikirkan berbagai jenis lubang keamanan dan apa artinya bagi sistem.

Vektor serangan

Pertimbangkan skenario di mana penyerang telah mendapatkan akses ke kredensial pengembang. Apa yang bisa mereka lakukan?

Hak Istimewa	Serangan
Dapatkah mereka mengirim email?	Rekan kerja yang terkena phishing
Dapatkah mereka mengakses mesin lain?	Masuk, mimikatz, ulangi
Dapatkah mereka memodifikasi sumber	Menyuntikkan kode
Dapatkah mereka mengubah proses build/rilis?	Menyuntikkan kode, menjalankan skrip
Dapatkah mereka mengakses lingkungan pengujian?	Jika lingkungan produksi mengambil dependensi pada lingkungan pengujian, manfaatkan.
Dapatkah mereka mengakses lingkungan produksi?	Begitu banyak pilihan...

Bagaimana tim Anda bisa bertahan melawan vektor ini?

• Menyimpan rahasia dalam vault yang dilindungi
• Menghapus akun admin lokal
• Membatasi SAMR
• Penjaga Kredensial
• Hapus server dengan dua koneksi
• Memisahkan langganan
• Autentikasi multifaktor
• Stasiun kerja akses istimewa
• Mendeteksi dengan ATP & Pertahanan Microsoft untuk Cloud

Manajemen rahasia

Semua rahasia harus disimpan dalam vault yang dilindungi. Rahasia meliputi:

• Kata sandi, kunci, dan token
• Kunci akun penyimpanan
• Certificates
• Kredensial yang juga digunakan di lingkungan bersama non-produksi

Anda harus menggunakan hierarki vault untuk menghilangkan duplikasi rahasia. Pertimbangkan juga bagaimana dan kapan rahasia diakses. Beberapa digunakan pada waktu penerapan ketika membangun konfigurasi lingkungan, sementara yang lain diakses pada waktu eksekusi. Rahasia saat penyebaran biasanya memerlukan penyebaran baru untuk mengambil pengaturan baru, sedangkan rahasia saat pelaksanaan diakses ketika 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 bermanfaat

• Microsoft Defender for Cloud sangat bagus untuk pemberitahuan infrastruktur generik, seperti untuk malware, proses yang mencurigakan, dll.
• Alat analisis kode sumber untuk pengujian keamanan aplikasi statis (SAST).
• Keamanan tingkat lanjut GitHub 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 di Windows. Ini hanya memerlukan akses administratif ke komputer, atau akun dengan hak istimewa debug diaktifkan.
• BloodHound membangun grafik hubungan dalam lingkungan Direktori Aktif. Ini dapat digunakan tim merah untuk dengan mudah mengidentifikasi vektor serangan yang sulit untuk diidentifikasi dengan cepat.

Latihan permainan perang

Praktik umum di Microsoft adalah terlibat dalam latihan game perang. Ini adalah peristiwa pengujian keamanan di mana dua tim ditugaskan untuk menguji keamanan dan kebijakan sistem.

Tim merah mengambil peran sebagai penyerang. Mereka mencoba memodelkan serangan dunia nyata untuk menemukan kesenjangan dalam keamanan. Jika mereka dapat mengeksploitasi apa saja, mereka juga menunjukkan konsekuensi potensial dari pelanggaran mereka.

Tim biru mengambil peran tim DevOps. Mereka menguji kemampuan mereka untuk mendeteksi dan merespons serangan tim merah. Ini membantu meningkatkan kesadaran situasi dan mengukur kesiapan dan efektivitas strategi DevSecOps.

Mengembangkan strategi permainan perang

Permainan perang efektif dalam memperkuat keamanan karena mereka memotivasi tim merah untuk menemukan dan mengeksploitasi masalah. Ini mungkin akan jauh lebih mudah daripada yang diharapkan sejak dini. Tim yang belum secara aktif mencoba menyerang sistem mereka sendiri umumnya tidak menyadari ukuran dan kuantitas lubang keamanan yang tersedia untuk penyerang. Tim biru mungkin merasa kecewa pada awalnya karena mereka akan dikalahkan berulang kali. Untungnya, sistem dan praktik harus berkembang dari waktu ke waktu sehingga tim biru secara konsisten menang.

Bersiap untuk permainan perang

Sebelum memulai simulasi perang, tim harus mengurus masalah apa pun yang dapat mereka temukan melalui pengecekan keamanan. Ini adalah latihan yang sangat baik untuk dilakukan sebelum mencoba serangan, karena akan memberikan pengalaman awal sebagai tolok ukur bagi semua orang untuk dibandingkan setelah eksploitasi pertama ditemukan nanti. Mulailah dengan mengidentifikasi kerentanan melalui tinjauan kode manual dan alat analisis statis.

Mengatur tim

Tim merah dan biru harus diatur berdasarkan spesialisasi. Tujuannya adalah untuk membangun tim yang paling mampu untuk setiap sisi agar dapat dijalankan seefektif mungkin.

Tim merah harus menyertakan beberapa insinyur dan pengembang yang berorientasi keamanan dan sangat berpengalaman dengan kode tersebut. Ini juga membantu untuk menambah tim dengan spesialis pengujian penetrasi, jika memungkinkan. Jika tidak ada spesialis di rumah, banyak perusahaan menyediakan layanan ini bersama dengan pendampingan.

Tim biru harus terdiri dari insinyur yang berorientasi operasi dan memiliki pemahaman mendalam tentang sistem serta pencatatan log yang tersedia. Mereka memiliki peluang terbaik untuk mendeteksi dan mengatasi perilaku mencurigakan.

Melakukan simulasi perang awal

Diharapkan tim merah akan efektif dalam permainan perang simulasi awal. 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 antara putaran untuk menerapkan perbaikan dan umpan balik tentang kebijakan. Ini akan bervariasi menurut organisasi, tetapi Anda tidak ingin memulai babak berikutnya sampai semua orang yakin bahwa putaran sebelumnya telah ditambang untuk semua nilainya.

Permainan perang yang sedang berlangsung

Setelah beberapa putaran, tim merah perlu mengandalkan teknik yang lebih canggih, seperti skrip lintas situs (XSS), eksploitasi deserialisasi, dan kerentanan sistem rekayasa. Membawa pakar keamanan eksternal di area seperti Active Directory mungkin membantu untuk mengidentifikasi eksploit yang lebih sulit ditemukan. Pada saat ini, Tim Biru seharusnya tidak hanya memiliki platform yang diperkuat untuk pertahanan, tetapi juga akan memanfaatkan pencatatan log yang komprehensif dan terpusat untuk forensik pasca-pelanggaran.

Defender berpikir dalam daftar. Penyerang berpikir dalam grafik. Selama kondisi ini berlaku, penyerang akan terus menang." -- John Lambert (MSTIC)

Seiring waktu, tim merah akan membutuhkan waktu lebih lama untuk mencapai tujuan. Ketika mereka melakukannya, seringkali diperlukan penemuan dan penggabungan berbagai kerentanan yang berdampak terbatas. Melalui penggunaan alat pemantauan waktu nyata, tim biru harus mulai mendeteksi upaya secara waktu nyata.

Panduan

Permainan perang seharusnya tidak gratis untuk semua. Penting untuk dikenali bahwa tujuannya adalah untuk menghasilkan sistem yang lebih efektif yang dijalankan oleh tim yang lebih efektif.

Kode etik

Berikut adalah kode etik sampel yang digunakan oleh Microsoft:

1. Baik tim merah maupun tim biru tidak akan membahayakan. Jika potensi menyebabkan kerusakan signifikan, itu harus didokumenkan dan ditangani.
2. Tim merah tidak boleh berkompromi lebih dari yang diperlukan untuk menangkap aset target.
3. Aturan akal sehat berlaku untuk serangan fisik. Meskipun tim merah didorong untuk berkreasi dengan serangan non-teknis, seperti rekayasa sosial, mereka tidak boleh mencetak lencana palsu, melecehkan orang, dll.
4. Jika serangan rekayasa sosial berhasil, jangan ungkapkan nama orang yang disusupi. Pelajaran dapat dibagikan tanpa mengasingkan atau memalukan anggota tim yang perlu terus bekerja sama dengan semua orang.

Tata Cara Operasional

Berikut adalah contoh aturan keterlibatan yang digunakan oleh Microsoft:

1. Jangan berdampak pada ketersediaan sistem apa pun.
2. Jangan akses data pelanggan eksternal.
3. Jangan melemahkan perlindungan keamanan di tempat secara signifikan pada layanan apa pun.
4. Jangan sengaja melakukan tindakan destruktif terhadap sumber daya apa pun.
5. Lindungi kredensial, kerentanan, dan informasi penting lainnya yang diperoleh.

Hasil Pekerjaan

Setiap risiko keamanan atau pelajaran yang dipelajari harus didokumentasikan dalam backlog item perbaikan. Teams harus menentukan perjanjian tingkat layanan (SLA) untuk seberapa cepat risiko keamanan akan ditangani. Risiko parah 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 bagi semua orang, jadi manfaatkanlah.

Pelajaran yang dipelajari di Microsoft

Microsoft secara teratur mempraktikkan game perang dan telah mempelajari banyak pelajaran di sepanjang jalan.

• Simulasi perang adalah cara yang efektif untuk mengubah budaya DevSecOps dan menjaga keamanan tetap di garis depan.
• Serangan pengelabuan sangat efektif bagi penyerang dan tidak boleh diremehkan. Dampaknya dapat dikendalikan dengan membatasi akses produksi ke sistem dan memerlukan autentikasi dua faktor.
• Kontrol sistem rekayasa mengarah pada kontrol segala sesuatu. Pastikan untuk mengontrol akses secara ketat ke agen build/rilis, antrean, kumpulan, dan definisi.
• Berlatih pertahanan secara mendalam untuk memperkeras penyerang. Setiap batas yang harus mereka langgar memperlambat mereka dan menawarkan kesempatan lain untuk menangkap mereka.
• Jangan pernah menyeberangi wilayah kepercayaan. Produksi tidak boleh mempercayai apa pun dalam pengujian.

Langkah selanjutnya

Pelajari selengkapnya tentang siklus hidup pengembangan keamanan dan DevSecOps di Azure.