Keamanan di DevOps (DevSecOps)

Keamanan adalah bagian penting 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 dan berkelanjutan yang membutuhkan perhatian semua orang dalam operasi pengembangan dan 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 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 mulai merencanakan sesegera mungkin. Pada awalnya mungkin ada 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

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	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 yang mengasumsikan pelanggaran sistem tidak dapat dihindari. Dengan asumsi bahwa Anda telah dilanggar dapat sulit diakui, terutama ketika mengalami percakapan yang sulit dengan manajemen, tetapi asumsi itu dapat membantu Anda menjawab pertanyaan tentang keamanan pada waktu Anda sendiri. Anda tidak ingin mencari tahu semuanya selama keadaan darurat keamanan nyata.

Pertanyaan umum yang perlu dipikirkan meliputi:

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

Praktik DevSecOps Utama

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 langsung yang sedang berlangsung dari rencana respons keamanan. Saat mengevaluasi potensi kebijakan, 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 akan ideal untuk menghentikan penyerang sebelum sampai sejauh itu, kebijakan dengan asumsi pelanggaran mendorong tim untuk meminimalkan paparan dari penyerang yang telah masuk.

Terakhir, lakukan penilaian pasca-pelanggaran berkala terhadap praktik dan 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 dilihat sebagai kesempatan untuk berbenah.

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 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 Anda bisa bertahan melawan vektor ini?

• Menyimpan rahasia di vault yang dilindungi
• Menghapus akun admin lokal
• Membatasi SAMR
• Penjaga Kredensial
• Menghapus server berumah dua
• Langganan terpisah
• Autentikasi multifaktor
• Stasiun kerja akses istimewa
• Deteksi dengan ATP &Microsoft Defender untuk Cloud

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

Anda harus menggunakan 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

• Microsoft Defender untuk 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 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 kesenjangan dalam 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 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. 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. Tim biru mungkin didemoralisasi pada awalnya karena mereka akan dieksekusi berulang kali. Untungnya, sistem dan praktik harus berkembang dari waktu ke waktu sehingga tim biru secara konsisten menang.

Bersiap untuk 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. Mulailah dengan mengidentifikasi kerentanan melalui tinjauan kode manual dan alat analisis statis.

Mengatur 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 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. Membawa pakar keamanan luar di area seperti Direktori Aktif mungkin membantu 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. Ketika mereka melakukannya, itu akan sering memerlukan penemuan dan penautan beberapa kerentanan untuk memiliki dampak terbatas. Melalui penggunaan alat pemantauan real time, tim biru harus mulai menangkap upaya 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.

Tata Tertib

Berikut adalah contoh kode etik yang digunakan oleh Microsoft:

1. Tim merah dan biru tidak akan melakukan hal berbahaya. Jika potensi menyebabkan kerusakan signifikan, ini harus di dokumentasikan dan ditangani.
2. Tim merah tidak boleh membahayakan lebih dari yang diperlukan untuk menangkap aset target.
3. 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.
4. Jika serangan rekayasa sosial berhasil, jangan ungkapkan nama orang yang disusupi. Pelajaran dapat dibagikan tanpa mengasingkan atau memalukan anggota tim yang perlu terus dikerjakan oleh semua orang.

Aturan keterlibatan

Berikut adalah contoh aturan keterlibatan yang digunakan oleh Microsoft:

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

Hasil kerja

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 efektif untuk mengubah budaya DevSecOps dan menjaga keamanan tetap unggul.
• 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.