Kami memiliki 2 penganalisis kode, 4 alat pengujian dinamis, kerajinan kami sendiri, dan 250 skrip. Bukan berarti semua ini diperlukan dalam proses saat ini, namun begitu Anda mulai menerapkan DevSecOps, Anda harus melanjutkan hingga akhir.
. Pencipta karakter: Justin Roiland dan Dan Harmon.
Apa itu SecDevOps? Bagaimana dengan DevSecOps? Apa perbedaannya? Keamanan Aplikasi - tentang apa? Mengapa pendekatan klasik tidak berhasil lagi? Tahu jawaban atas semua pertanyaan ini Yuri Shabalin dari Keamanan Ikan Todak. Yuri akan menjawab semuanya secara detail dan menganalisis masalah transisi dari model Keamanan Aplikasi klasik ke proses DevSecOps: cara mendekati integrasi proses pengembangan aman ke dalam proses DevOps dengan benar dan tidak merusak apa pun, cara melalui tahapan utama tentang pengujian keamanan, alat apa yang dapat digunakan, dan perbedaannya serta cara mengonfigurasinya dengan benar untuk menghindari jebakan.
Tentang pembicara: Yuri Shabalin- Kepala Arsitek Keamanan di perusahaan Keamanan Ikan Todak. Bertanggung jawab atas penerapan SSDL, atas integrasi keseluruhan alat analisis aplikasi ke dalam ekosistem pengembangan dan pengujian terpadu. 7 tahun pengalaman dalam keamanan informasi. Bekerja di Alfa-Bank, Sberbank dan Positive Technologies, yang mengembangkan perangkat lunak dan menyediakan layanan. Pembicara di konferensi internasional ZerOnights, PHDays, RISSPA, OWASP.
Keamanan Aplikasi: tentang apa?
Keamanan Aplikasi - Ini adalah bagian keamanan yang bertanggung jawab atas keamanan aplikasi. Ini tidak berlaku untuk infrastruktur atau keamanan jaringan, melainkan pada apa yang kami tulis dan apa yang dikerjakan pengembang - ini adalah kekurangan dan kerentanan dari aplikasi itu sendiri.
Arah - Siklus hidup pengembangan keamanan - dikembangkan oleh Microsoft. Diagram menunjukkan model SDLC kanonik, tugas utamanya adalah partisipasi keamanan di setiap tahap pengembangan, mulai dari persyaratan hingga rilis dan produksi. Microsoft menyadari bahwa ada terlalu banyak bug di industri, ada lebih banyak bug dan sesuatu harus dilakukan untuk mengatasinya, dan mereka mengusulkan pendekatan ini, yang telah menjadi kanonik.
Keamanan Aplikasi dan SSDL tidak ditujukan untuk mendeteksi kerentanan, seperti yang diyakini secara umum, namun untuk mencegah terjadinya kerentanan. Seiring berjalannya waktu, pendekatan kanonik Microsoft telah diperbaiki, dikembangkan, dan diperkenalkan secara lebih mendalam dan mendetail.
SDLC kanonik sangat detail dalam berbagai metodologi - OpenSAMM, BSIMM, OWASP. Metodologinya berbeda, namun secara umum serupa.
Membangun Keamanan Dalam Model Kedewasaan
Saya paling menyukainya BSIMM - . Dasar metodologinya adalah pembagian proses Keamanan Aplikasi menjadi 4 domain: Tata Kelola, Intelijen, Titik Sentuh SSDL, dan Penerapan. Setiap domain memiliki 12 praktik, yang direpresentasikan sebagai 112 aktivitas.
Masing-masing dari 112 kegiatan memiliki 3 tingkat kematangan: pemula, menengah dan lanjutan. Anda dapat mempelajari semua 12 praktik bagian demi bagian, memilih hal-hal yang penting bagi Anda, mencari tahu cara menerapkannya, dan secara bertahap menambahkan elemen, misalnya, analisis kode statis dan dinamis atau tinjauan kode. Anda menuliskan sebuah rencana dan dengan tenang mengerjakannya sebagai bagian dari pelaksanaan kegiatan yang dipilih.
Mengapa DevSecOps
DevOps adalah proses umum dan besar yang harus mempertimbangkan keamanan.
Mulanya melibatkan pemeriksaan keamanan. Dalam praktiknya, jumlah tim keamanan jauh lebih kecil dibandingkan sekarang, dan mereka bertindak bukan sebagai peserta dalam proses, namun sebagai badan kontrol dan pengawasan yang memberlakukan persyaratan dan memeriksa kualitas produk di akhir rilis. Ini adalah pendekatan klasik di mana tim keamanan berada di balik tembok pembangunan dan tidak berpartisipasi dalam proses tersebut.
Masalah utamanya adalah keamanan informasi terpisah dari pembangunan. Biasanya ini adalah semacam rangkaian keamanan informasi dan berisi 2-3 alat yang besar dan mahal. Setiap enam bulan sekali, kode sumber atau aplikasi yang perlu diperiksa tiba, dan setahun sekali diproduksi . Semua ini mengarah pada fakta bahwa tanggal rilis untuk industri tertunda, dan pengembang dihadapkan pada sejumlah besar kerentanan dari alat otomatis. Tidak mungkin membongkar dan memperbaiki semua ini, karena hasil enam bulan sebelumnya belum tersortir, tapi ini batch baru.
Dalam perjalanan kerja perusahaan kami, kami melihat bahwa keamanan di semua bidang dan industri memahami bahwa inilah saatnya untuk mengejar ketertinggalan dan memutarbalikkan pembangunan pada roda yang sama - in . Paradigma DevSecOps sangat cocok dengan metodologi pengembangan, implementasi, dukungan, dan partisipasi yang tangkas dalam setiap rilis dan iterasi.
Transisi ke DevSecOps
Kata terpenting dalam Siklus Hidup Pengembangan Keamanan adalah "proses". Anda harus memahami hal ini sebelum berpikir untuk membeli alat.
Memasukkan alat ke dalam proses DevOps saja tidak cukup—komunikasi dan pemahaman antar peserta proses adalah hal yang penting.
Manusia lebih penting, bukan alat.
Seringkali, perencanaan untuk proses pengembangan yang aman dimulai dengan memilih dan membeli alat, dan diakhiri dengan upaya untuk mengintegrasikan alat tersebut ke dalam proses saat ini, yang masih merupakan upaya. Hal ini menimbulkan akibat yang tidak menguntungkan, karena semua alat memiliki karakteristik dan keterbatasannya masing-masing.
Kasus yang umum terjadi adalah ketika departemen keamanan memilih alat yang bagus dan mahal dengan kemampuan yang luas, dan mendatangi pengembang untuk mengintegrasikannya ke dalam proses. Tapi itu tidak berhasil - prosesnya disusun sedemikian rupa sehingga keterbatasan alat yang sudah dibeli tidak sesuai dengan paradigma saat ini.
Pertama, jelaskan hasil apa yang Anda inginkan dan seperti apa prosesnya. Hal ini akan membantu memahami peran alat dan keselamatan dalam proses tersebut.
Mulailah dengan apa yang sudah digunakan
Sebelum membeli alat yang mahal, lihatlah apa yang sudah Anda miliki. Setiap perusahaan memiliki persyaratan keamanan untuk pengembangan, ada pemeriksaan, pentest - mengapa tidak mengubah semua ini menjadi bentuk yang dapat dimengerti dan nyaman bagi semua orang?
Biasanya syaratnya adalah kertas Talmud yang terletak di rak. Ada kasus ketika kami datang ke sebuah perusahaan untuk melihat prosesnya dan meminta untuk melihat persyaratan keamanan untuk perangkat lunaknya. Spesialis yang menangani hal ini menghabiskan waktu lama untuk mencari:
- Sekarang, di suatu tempat di catatan ada jalur di mana dokumen ini berada.
Hasilnya, kami menerima dokumen tersebut seminggu kemudian.
Untuk persyaratan, pemeriksaan, dan hal lainnya, buat halaman di mis. Pertemuan - nyaman untuk semua orang.
Lebih mudah untuk memformat ulang apa yang sudah Anda miliki dan menggunakannya untuk memulai.
Gunakan Juara Keamanan
Biasanya, di rata-rata perusahaan dengan 100-200 pengembang, terdapat satu spesialis keamanan yang menjalankan beberapa fungsi dan secara fisik tidak punya waktu untuk memeriksa semuanya. Bahkan jika dia mencoba yang terbaik, dia sendiri tidak akan memeriksa semua kode yang dihasilkan oleh pengembangan tersebut. Untuk kasus seperti itu, sebuah konsep telah dikembangkan - .
Juara Keamanan adalah orang-orang dalam tim pengembangan yang tertarik dengan keamanan produk Anda.
Juara Keamanan adalah titik masuk ke dalam tim pengembangan dan penginjil keamanan digabung menjadi satu.
Biasanya, ketika seorang spesialis keamanan datang ke tim pengembangan dan menunjukkan kesalahan dalam kode, dia menerima jawaban yang mengejutkan:
- Dan siapa Anda? Aku melihatmu untuk pertama kalinya. Semuanya baik-baik saja bagi saya - teman senior saya memberi saya "lamar" pada peninjauan kode, kita lanjutkan!
Ini adalah situasi yang umum, karena ada lebih banyak kepercayaan pada senior atau rekan satu tim yang selalu berinteraksi dengan pengembang di tempat kerja dan dalam peninjauan kode. Jika, alih-alih petugas keamanan, Juara Keamanan yang menunjukkan kesalahan dan konsekuensinya, maka perkataannya akan lebih berbobot.
Selain itu, pengembang mengetahui kode mereka lebih baik daripada pakar keamanan mana pun. Untuk seseorang yang memiliki setidaknya 5 proyek dalam alat analisis statis, biasanya sulit untuk mengingat semua nuansanya. Juara Keamanan mengetahui produk mereka: apa yang berinteraksi dengan apa dan apa yang harus dilihat pertama kali - mereka lebih efektif.
Jadi pertimbangkan untuk menerapkan Security Champion dan memperluas pengaruh tim keamanan Anda. Hal ini juga berguna bagi sang juara itu sendiri: pengembangan profesional di bidang baru, memperluas wawasan teknisnya, meningkatkan keterampilan teknis, manajerial dan kepemimpinan, serta meningkatkan nilai pasar. Ini adalah beberapa elemen rekayasa sosial, “mata” Anda dalam tim pengembangan.
Tahapan pengujian
mengatakan bahwa 20% usaha menghasilkan 80% hasil. 20% ini adalah praktik analisis aplikasi yang dapat dan harus diotomatisasi. Contoh aktivitas tersebut adalah analisis statis - SAST, analisis dinamis - DAST и Kontrol Sumber Terbuka. Saya akan memberi tahu Anda lebih detail tentang aktivitas, serta alatnya, fitur apa yang biasanya kita temui saat memperkenalkannya ke dalam proses, dan bagaimana melakukannya dengan benar.
Masalah utama alat
Saya akan menyoroti masalah yang relevan untuk semua instrumen dan memerlukan perhatian. Saya akan menganalisisnya lebih detail agar tidak mengulanginya lebih lanjut.
Waktu analisis yang lama. Jika dari komitmen hingga rilis diperlukan waktu 30 menit untuk semua pengujian dan perakitan, maka pemeriksaan keamanan informasi akan memakan waktu satu hari. Jadi tidak ada yang akan memperlambat prosesnya. Pertimbangkan fitur ini dan buat kesimpulan.
Negatif Palsu atau Positif Palsu tingkat tinggi. Semua produk berbeda, semuanya menggunakan kerangka kerja berbeda dan gaya pengkodeannya sendiri. Pada basis kode dan teknologi yang berbeda, alat mungkin menunjukkan tingkat False Negative dan False Positive yang berbeda. Jadi lihat apa sebenarnya yang ada di dalamnya anda perusahaan dan untuk milikmu aplikasi akan menunjukkan hasil yang baik dan dapat diandalkan.
Tidak ada integrasi dengan alat yang ada. Lihatlah alat dalam kaitannya dengan integrasi dengan apa yang sudah Anda gunakan. Misalnya, jika Anda memiliki Jenkins atau TeamCity, periksa integrasi alat dengan perangkat lunak ini, dan bukan dengan GitLab CI, yang tidak Anda gunakan.
Kurangnya atau kompleksitas penyesuaian yang berlebihan. Jika suatu alat tidak memiliki API, lalu mengapa diperlukan? Segala sesuatu yang dapat dilakukan di antarmuka harus tersedia melalui API. Idealnya, alat tersebut harus memiliki kemampuan untuk menyesuaikan pemeriksaan.
Tidak Ada Peta Jalan Pengembangan Produk. Perkembangan tidak berhenti, kami selalu menggunakan kerangka kerja dan fungsi baru, menulis ulang kode lama ke dalam bahasa baru. Kami ingin memastikan bahwa alat yang kami beli akan mendukung kerangka kerja dan teknologi baru. Oleh karena itu, penting untuk mengetahui bahwa produk tersebut nyata dan benar perkembangan.
Fitur proses
Selain fitur alat, pertimbangkan fitur proses pengembangan. Misalnya, menghambat pembangunan adalah kesalahan umum. Mari kita lihat fitur lain apa yang harus dipertimbangkan dan apa yang harus diperhatikan oleh tim keamanan.
Agar tidak ketinggalan tenggat waktu pengembangan dan rilis, buatlah aturan yang berbeda dan berbeda menunjukkan sumbat — kriteria untuk menghentikan proses pembangunan jika terdapat kerentanan — untuk lingkungan yang berbeda. Misalnya, kami memahami bahwa cabang saat ini menuju ke stand pengembangan atau UAT, yang berarti kami tidak berhenti dan berkata:
“Anda memiliki kerentanan di sini, Anda tidak dapat melangkah lebih jauh!”
Pada titik ini, penting untuk memberi tahu pengembang bahwa ada masalah keamanan yang perlu diperhatikan.
Adanya kerentanan bukanlah halangan untuk pengujian lebih lanjut: manual, integrasi atau manual. Di sisi lain, kita perlu meningkatkan keamanan produk, dan agar pengembang tidak mengabaikan apa yang mereka anggap aman. Oleh karena itu, terkadang kami melakukan ini: di stand, ketika diluncurkan ke lingkungan pengembangan, kami hanya memberi tahu pengembangan tersebut:
- Teman-teman, Anda memiliki masalah, harap diperhatikan.
Pada tahap UAT kami kembali menampilkan peringatan tentang kerentanan, dan pada tahap rilis kami mengatakan:
- Kawan, kami memperingatkanmu beberapa kali, kamu tidak melakukan apa pun - kami tidak akan membiarkanmu keluar begitu saja.
Jika kita berbicara tentang kode dan dinamika, maka perlu untuk menunjukkan dan memperingatkan tentang kerentanan hanya pada fitur dan kode yang baru saja ditulis dalam fitur ini. Jika pengembang memindahkan tombol sebesar 3 piksel dan kami memberi tahu dia bahwa dia memiliki injeksi SQL di sana dan oleh karena itu perlu segera diperbaiki, ini salah. Lihat saja apa yang tertulis sekarang dan perubahan yang terjadi pada aplikasi.
Katakanlah kita memiliki cacat fungsional tertentu - cara aplikasi tidak berfungsi: uang tidak ditransfer, ketika Anda mengklik tombol tidak ada transisi ke halaman berikutnya, atau produk tidak dimuat. Cacat Keamanan - ini adalah cacat yang sama, tetapi bukan dalam hal pengoperasian aplikasi, tetapi dalam keamanan.
Tidak semua masalah kualitas perangkat lunak merupakan masalah keamanan. Namun semua masalah keamanan berkaitan dengan kualitas perangkat lunak. Sherif Mansour, Expedia.
Karena semua kerentanan adalah cacat yang sama, maka kerentanan tersebut harus ditempatkan di tempat yang sama dengan semua cacat pengembangan. Jadi lupakan laporan dan PDF menakutkan yang tidak dibaca oleh siapa pun.
Ketika saya bekerja di sebuah perusahaan pengembangan, saya menerima laporan dari alat analisis statis. Saya membukanya, merasa ngeri, membuat kopi, membolak-balik 350 halaman, menutupnya dan terus bekerja. Laporan besar adalah laporan mati. Biasanya mereka tidak kemana-mana, surat-suratnya terhapus, terlupakan, hilang, atau pihak bisnis menyatakan menerima risikonya.
Apa yang harus dilakukan? Kami cukup mengonversi cacat terkonfirmasi yang kami temukan ke dalam bentuk yang nyaman untuk pengembangan, misalnya, kami menyimpannya di backlog di Jira. Kami memprioritaskan cacat dan menghilangkannya berdasarkan urutan prioritas, bersama dengan cacat fungsional dan cacat pengujian.
Analisis Statis - SAST
Ini adalah analisis kode untuk kerentanan., tapi itu tidak sama dengan SonarQube. Kami tidak hanya memeriksa pola atau gaya. Sejumlah pendekatan digunakan dalam analisis: menurut pohon kerentanan, menurut , dengan menganalisis file konfigurasi. Ini semua yang menyangkut kode itu sendiri.
Kelebihan dari pendekatan ini: mengidentifikasi kerentanan dalam kode pada tahap awal pengembanganbila belum ada stand atau alat yang sudah jadi, dan kemampuan pemindaian tambahan: memindai bagian kode yang telah berubah, dan hanya fitur yang sedang kita lakukan, yang mengurangi waktu pemindaian.
Kontra - ini adalah kurangnya dukungan untuk bahasa yang diperlukan.
Integrasi yang diperlukan, yang seharusnya ada di alat, menurut pendapat subjektif saya:
- Alat integrasi: Jenkins, TeamCity dan Gitlab CI.
- Lingkungan pengembangan: Intellij IDEA, Visual Studio. Lebih mudah bagi pengembang untuk tidak menavigasi antarmuka yang tidak dapat dipahami yang masih perlu dihafal, tetapi untuk melihat semua integrasi dan kerentanan yang diperlukan yang ia temukan tepat di tempat kerja di lingkungan pengembangannya sendiri.
- Tinjauan kode: SonarQube dan tinjauan manual.
- Pelacak cacat: Jira dan Bugzilla.
Gambar menunjukkan beberapa perwakilan terbaik dari analisis statis.
Bukan alatnya yang penting, tapi prosesnya, jadi ada solusi Open Source yang juga bagus untuk menguji prosesnya.
SAST Open Source tidak akan menemukan sejumlah besar kerentanan atau DataFlow yang kompleks, namun dapat dan harus digunakan saat membangun suatu proses. Mereka membantu untuk memahami bagaimana proses akan dibangun, siapa yang akan merespons bug, siapa yang akan melaporkan, dan siapa yang akan melaporkan. Jika Anda ingin melakukan tahap awal dalam membangun keamanan kode Anda, gunakan solusi Sumber Terbuka.
Bagaimana hal ini dapat diintegrasikan jika Anda berada di awal perjalanan dan tidak memiliki apa pun: tanpa CI, tanpa Jenkins, tanpa TeamCity? Mari pertimbangkan integrasi ke dalam proses.
Integrasi tingkat CVS
Jika Anda memiliki Bitbucket atau GitLab, Anda dapat berintegrasi di level tersebut .
Berdasarkan acara - tarik permintaan, komit. Anda memindai kode dan status build menunjukkan apakah pemeriksaan keamanan berhasil atau gagal.
Masukan. Tentu saja umpan balik selalu dibutuhkan. Jika Anda hanya melakukan keamanan sampingan, memasukkannya ke dalam kotak dan tidak memberi tahu siapa pun tentang hal itu, dan kemudian pada akhir bulan membuang banyak bug - ini tidak benar dan tidak baik.
Integrasi dengan sistem peninjauan kode
Kami pernah bertindak sebagai peninjau default untuk pengguna AppSec teknis di sejumlah proyek penting. Bergantung pada apakah kesalahan teridentifikasi dalam kode baru atau tidak, peninjau menetapkan status pada permintaan penarikan menjadi "menerima" atau "perlu perbaikan" - semuanya baik-baik saja, atau tautan ke apa yang sebenarnya perlu diperbaiki perlu ditingkatkan. Untuk integrasi dengan versi yang akan diproduksi, kami telah mengaktifkan larangan penggabungan jika uji keamanan informasi tidak lulus. Kami menyertakan ini dalam tinjauan kode manual, dan peserta lain dalam proses tersebut melihat status keamanan untuk proses khusus ini.
Integrasi dengan SonarQube
Banyak yang punya dalam hal kualitas kode. Hal yang sama terjadi di sini - Anda dapat membuat gerbang yang sama hanya untuk alat SAST. Akan ada antarmuka yang sama, gerbang kualitas yang sama, hanya saja yang akan dipanggil gerbang keamanan. Dan juga, jika Anda memiliki proses menggunakan SonarQube, Anda dapat dengan mudah mengintegrasikan semuanya di sana.
Integrasi di tingkat CI
Semuanya di sini juga cukup sederhana:
- Setara dengan autotest, tes unit.
- Pembagian berdasarkan tahapan pengembangan: dev, tes, produksi. Rangkaian aturan yang berbeda atau kondisi kegagalan yang berbeda mungkin disertakan: hentikan perakitan, jangan hentikan perakitan.
- Peluncuran sinkron/asinkron. Kita tunggu saja apakah tes keamanannya selesai atau tidak. Artinya, kami baru saja meluncurkannya dan melanjutkan, lalu kami mendapatkan status bahwa semuanya baik atau buruk.
Semuanya ada di dunia merah jambu yang sempurna. Tidak ada hal seperti itu dalam kehidupan nyata, tapi kami berusaha. Hasil dari menjalankan pemeriksaan keamanan harus serupa dengan hasil pengujian unit.
Misalnya, kami mengambil proyek besar dan memutuskan bahwa sekarang kami akan memindainya dengan SAST - OK. Kami mendorong proyek ini ke SAST, ini memberi kami 20 kerentanan dan dengan keputusan yang berkemauan keras kami memutuskan bahwa semuanya baik-baik saja. 000 kerentanan adalah utang teknis kami. Kami akan memasukkan utang ke dalam kotak, kami akan melunasinya secara perlahan dan menambahkan bug ke pelacak kerusakan. Mari kita menyewa sebuah perusahaan, melakukan segalanya sendiri, atau meminta Security Champion membantu kita - dan utang teknis akan berkurang.
Dan semua kerentanan yang baru muncul dalam kode baru harus dihilangkan dengan cara yang sama seperti kesalahan dalam unit atau pengujian otomatis. Secara relatif, perakitan dimulai, kami menjalankannya, dua pengujian dan dua pengujian keamanan gagal. Oke - kami pergi, melihat apa yang terjadi, memperbaiki satu hal, memperbaiki hal lain, menjalankannya di lain waktu - semuanya baik-baik saja, tidak ada kerentanan baru yang muncul, tidak ada pengujian yang gagal. Jika tugas ini lebih dalam dan Anda perlu memahaminya dengan baik, atau memperbaiki kerentanan memengaruhi lapisan besar dari apa yang ada di balik terpal: bug telah ditambahkan ke pelacak kerusakan, bug tersebut diprioritaskan dan diperbaiki. Sayangnya, dunia ini tidak sempurna dan pengujian terkadang gagal.
Contoh gerbang keamanan dapat dianalogikan dengan gerbang kualitas, dalam hal keberadaan dan jumlah kerentanan dalam kode.
Kami berintegrasi dengan SonarQube - plugin telah diinstal, semuanya sangat nyaman dan keren.
Integrasi dengan lingkungan pengembangan
Opsi integrasi:
- Menjalankan pemindaian dari lingkungan pengembangan sebelum melakukan.
- Lihat hasil.
- Analisis hasil.
- Sinkronisasi dengan server.
Seperti inilah tampilan menerima hasil dari server.
Di lingkungan pengembangan kita item tambahan akan muncul yang memberi tahu Anda bahwa kerentanan tersebut terdeteksi selama pemindaian. Anda dapat langsung mengedit kode, melihat rekomendasi dan . Ini semua terletak di tempat kerja pengembang, yang sangat nyaman - tidak perlu mengikuti tautan lain dan melihat sesuatu yang tambahan.
Open Source
Ini adalah topik favorit saya. Semua orang menggunakan perpustakaan Open Source - mengapa menulis banyak kruk dan sepeda ketika Anda dapat menggunakan perpustakaan yang sudah jadi yang semuanya sudah diimplementasikan?
Tentu saja hal ini benar, tetapi perpustakaan juga ditulis oleh manusia, mereka juga memiliki risiko tertentu dan ada juga kerentanan yang dilaporkan secara berkala atau terus-menerus. Oleh karena itu, ada langkah selanjutnya dalam Keamanan Aplikasi - ini adalah analisis komponen Open Source.
Analisis Sumber Terbuka - OSA
Alat ini mencakup tiga tahap besar.
Mencari kerentanan di perpustakaan. Misalnya, alat tersebut mengetahui bahwa kita menggunakan beberapa perpustakaan, dan itu di dalamnya atau ada beberapa kerentanan dalam pelacak bug yang berhubungan dengan versi perpustakaan ini. Saat Anda mencoba menggunakannya, alat tersebut akan mengeluarkan peringatan bahwa perpustakaan tersebut rentan dan menyarankan Anda untuk menggunakan versi lain yang tidak memiliki kerentanan.
Analisis kemurnian lisensi. Ini belum terlalu populer di sini, tetapi jika Anda bekerja di luar negeri, dari waktu ke waktu Anda bisa mendapatkan pajak di sana karena menggunakan komponen sumber terbuka yang tidak dapat digunakan atau dimodifikasi. Berdasarkan kebijakan perpustakaan berlisensi, kami tidak dapat melakukan hal ini. Atau, jika kita memodifikasinya dan menggunakannya, kita harus memposting kode kita. Tentu saja, tidak ada yang mau mempublikasikan kode produk mereka, tetapi Anda juga dapat melindungi diri dari hal ini.
Analisis komponen yang digunakan dalam lingkungan industri. Mari kita bayangkan sebuah situasi hipotetis dimana kita akhirnya menyelesaikan pengembangan dan merilis rilis terbaru dari layanan mikro kita. Dia tinggal di sana dengan luar biasa - seminggu, sebulan, setahun. Kami tidak mengumpulkannya, kami tidak melakukan pemeriksaan keamanan, semuanya tampak baik-baik saja. Namun tiba-tiba, dua minggu setelah rilis, kerentanan kritis muncul pada komponen Open Source, yang kami gunakan dalam build khusus ini, di lingkungan industri. Jika kami tidak mencatat apa dan di mana kami menggunakannya, maka kami tidak akan melihat kerentanan ini. Beberapa alat memiliki kemampuan untuk memantau kerentanan di perpustakaan yang saat ini digunakan di industri. Itu sangat berguna.
Возможности:
- Kebijakan yang berbeda untuk tahap pembangunan yang berbeda.
- Memantau komponen dalam lingkungan industri.
- Kontrol perpustakaan dalam organisasi.
- Dukungan untuk berbagai sistem dan bahasa build.
- Analisis gambar Docker.
Beberapa contoh pemimpin industri yang terlibat dalam analisis Open Source.
Satu-satunya yang gratis adalah ini dari OWASP. Anda dapat mengaktifkannya pada tahap pertama, melihat cara kerjanya dan apa yang didukungnya. Pada dasarnya, ini semua adalah produk cloud, atau on-premise, tetapi di belakang basisnya, produk tersebut masih dikirim ke Internet. Mereka tidak mengirimkan perpustakaan Anda, tetapi hash atau nilai mereka sendiri, yang mereka hitung, dan sidik jari ke server mereka untuk menerima informasi tentang adanya kerentanan.
Integrasi proses
Kontrol perimeter perpustakaan, yang diunduh dari sumber eksternal. Kami memiliki repositori eksternal dan internal. Misalnya, Event Central menjalankan Nexus, dan kami ingin memastikan bahwa tidak ada kerentanan dalam repositori kami dengan status “kritis” atau “tinggi”. Anda dapat mengonfigurasi proksi menggunakan alat Nexus Firewall Lifecycle sehingga kerentanan tersebut terpotong dan tidak berakhir di penyimpanan internal.
Integrasi ke CI. Setingkat dengan autotest, unit test, dan pembagian ke dalam tahap pengembangan: dev, test, prod. Pada setiap tahap, Anda dapat mengunduh perpustakaan apa pun, menggunakan apa saja, tetapi jika ada sesuatu yang sulit dengan status "kritis", mungkin ada baiknya menarik perhatian pengembang terhadap hal ini pada tahap rilis ke produksi.
Integrasi dengan artefak: Nexus dan JFrog.
Integrasi ke dalam lingkungan pengembangan. Alat yang Anda pilih harus memiliki integrasi dengan lingkungan pengembangan. Pengembang harus memiliki akses ke hasil pemindaian dari tempat kerjanya, atau kemampuan untuk memindai dan memeriksa sendiri kerentanan kode sebelum melakukan CVS.
Integrasi CD. Ini adalah fitur keren yang sangat saya sukai dan telah saya bicarakan - memantau munculnya kerentanan baru di lingkungan industri. Cara kerjanya seperti ini.
Kita punya Repositori Komponen Publik — beberapa alat di luar, dan penyimpanan internal kami. Kami ingin itu hanya berisi komponen tepercaya. Saat mem-proxy permintaan, kami memeriksa apakah perpustakaan yang diunduh tidak memiliki kerentanan. Jika itu termasuk dalam kebijakan tertentu yang kami tetapkan dan perlu dikoordinasikan dengan pengembangan, maka kami tidak mengunggahnya dan diminta untuk menggunakan versi lain. Oleh karena itu, jika ada sesuatu yang sangat kritis dan buruk di perpustakaan, maka pengembang tidak akan menerima perpustakaan pada tahap instalasi - biarkan dia menggunakan versi yang lebih tinggi atau lebih rendah.
- Saat membangun, kami memeriksa bahwa tidak ada orang yang tergelincir, semua komponen aman dan tidak ada orang yang membawa sesuatu yang berbahaya ke dalam flash drive.
- Kami hanya memiliki komponen tepercaya di repositori.
- Saat menerapkan, kami sekali lagi memeriksa paket itu sendiri: war, jar, DL atau Docker image untuk memastikan bahwa paket tersebut mematuhi kebijakan.
- Saat memasuki industri, kami memantau apa yang terjadi di lingkungan industri: apakah kerentanan kritis muncul atau tidak.
Analisis Dinamis - DAST
Alat analisis dinamis pada dasarnya berbeda dari apa yang telah disebutkan sebelumnya. Ini adalah semacam tiruan dari pekerjaan pengguna dengan aplikasi tersebut. Jika ini adalah aplikasi web, kami mengirim permintaan, mensimulasikan pekerjaan klien, klik tombol di bagian depan, mengirim data buatan dari formulir: tanda kutip, tanda kurung, karakter dalam pengkodean berbeda, untuk melihat cara kerja dan proses aplikasi data eksternal.
Sistem yang sama memungkinkan Anda memeriksa kerentanan template di Open Source. Karena DAST tidak mengetahui Open Source mana yang kami gunakan, DAST hanya menampilkan pola “berbahaya” dan menganalisis respons server:
- Ya, ada masalah deserialisasi di sini, tapi tidak di sini.
Ada risiko besar dalam hal ini, karena jika Anda melakukan uji keamanan ini di bangku yang sama dengan tempat penguji bekerja, hal-hal tidak menyenangkan dapat terjadi.
- Beban tinggi pada jaringan server aplikasi.
- Tidak ada integrasi.
- Kemampuan untuk mengubah pengaturan aplikasi yang dianalisis.
- Tidak ada dukungan untuk teknologi yang diperlukan.
- Kesulitan dalam pengaturan.
Kami mengalami situasi ketika kami akhirnya meluncurkan AppScan: kami menghabiskan waktu lama untuk mencoba mendapatkan akses ke aplikasi, mendapatkan 3 akun dan merasa senang - kami akhirnya akan memeriksa semuanya! Kami meluncurkan pemindaian, dan hal pertama yang dilakukan AppScan adalah masuk ke panel admin, menembus semua tombol, mengubah separuh data, dan kemudian mematikan server sepenuhnya dengan itu. -permintaan. Pengembangan dengan pengujian mengatakan:
- Teman-teman, apakah kamu bercanda?! Kami memberi Anda akun, dan Anda mendirikan pendirian!
Pertimbangkan risiko yang mungkin terjadi. Idealnya, siapkan stand terpisah untuk menguji keamanan informasi, yang setidaknya akan diisolasi dari lingkungan lain, dan periksa panel admin secara kondisional, sebaiknya dalam mode manual. Ini adalah pentest - persentase sisa upaya yang tidak kami pertimbangkan sekarang.
Perlu dipertimbangkan bahwa Anda dapat menggunakan ini sebagai analogi pengujian beban. Pada tahap pertama, Anda dapat menyalakan pemindai dinamis dengan 10-15 utas dan melihat apa yang terjadi, tetapi biasanya, seperti yang ditunjukkan oleh latihan, tidak ada hal baik.
Beberapa sumber daya yang biasa kami gunakan.
Layak disorot adalah “pisau Swiss” untuk profesional keamanan mana pun. Semua orang menggunakannya dan itu sangat nyaman. Versi demo baru dari edisi perusahaan kini telah dirilis. Jika sebelumnya hanya utilitas yang berdiri sendiri dengan plugin, kini para pengembang akhirnya membuat server besar yang memungkinkan untuk mengelola beberapa agen. Ini keren, saya sarankan Anda mencobanya.
Integrasi proses
Integrasi terjadi dengan cukup baik dan sederhana: mulai memindai setelah instalasi berhasil aplikasi untuk stand dan pemindaian setelah pengujian integrasi berhasil.
Jika integrasi tidak berfungsi atau ada fungsi stub dan tiruan, itu tidak ada gunanya dan tidak ada gunanya - tidak peduli pola apa yang kita kirim, server akan tetap merespons dengan cara yang sama.
- Idealnya, tempat pengujian terpisah.
- Sebelum pengujian, tuliskan urutan login.
- Pengujian sistem administrasi hanya dilakukan secara manual.
proses
Sedikit menggeneralisasikan proses secara umum dan cara kerja masing-masing alat pada khususnya. Semua aplikasi berbeda - satu bekerja lebih baik dengan analisis dinamis, yang lain dengan analisis statis, yang ketiga dengan analisis OpenSource, pentests, atau yang lainnya, misalnya, peristiwa dengan .
Setiap proses memerlukan pengendalian.
Untuk memahami cara kerja suatu proses dan di mana proses tersebut dapat ditingkatkan, Anda perlu mengumpulkan metrik dari segala hal yang dapat Anda peroleh, termasuk metrik produksi, metrik dari alat, dan dari pelacak kerusakan.
Informasi apa pun sangat membantu. Penting untuk melihat dari sudut yang berbeda di mana alat ini atau itu lebih baik digunakan, di mana prosesnya secara khusus melorot. Mungkin ada baiknya melihat waktu respons pengembangan untuk melihat di mana harus meningkatkan proses berdasarkan waktu. Semakin banyak data, semakin banyak bagian yang dapat dibangun mulai dari tingkat atas hingga detail setiap proses.
Karena semua penganalisis statis dan dinamis memiliki API sendiri, metode peluncuran, prinsipnya sendiri, beberapa memiliki penjadwal, yang lain tidak - kami sedang menulis alat Pengelola AppSec, yang memungkinkan Anda membuat satu titik masuk ke seluruh proses dari produk dan mengelolanya dari satu titik.
Manajer, pengembang, dan teknisi keamanan memiliki satu titik masuk di mana mereka dapat melihat apa yang sedang berjalan, mengonfigurasi dan menjalankan pemindaian, menerima hasil pemindaian, dan mengirimkan persyaratan. Kami mencoba untuk beralih dari dokumen, untuk menerjemahkan semuanya menjadi sesuatu yang manusiawi, yang digunakan oleh pengembangan - halaman di Confluence dengan status dan metrik, cacat di Jira atau di berbagai pelacak cacat, atau integrasi ke dalam proses sinkron/asinkron di CI /CD.
Pengambilan Kunci
Alat bukanlah hal yang utama. Pertama-tama pikirkan prosesnya, lalu terapkan alatnya. Alatnya bagus tapi mahal, jadi Anda bisa memulai prosesnya dan membangun komunikasi serta pemahaman antara pengembangan dan keamanan. Dari segi keselamatan tidak perlu “menghentikan” semuanya, dari segi pembangunan, jika ada sesuatu yang tinggi mega super kritis maka perlu dihilangkan, dan tidak menutup mata terhadap permasalahannya.
Kualitas produk - tujuan bersama baik keamanan maupun pembangunan. Kami melakukan satu hal, kami mencoba memastikan semuanya berjalan dengan benar dan tidak ada risiko reputasi atau kerugian finansial. Itu sebabnya kami mempromosikan pendekatan DevSecOps, SecDevOps untuk meningkatkan komunikasi dan meningkatkan kualitas produk.
Mulailah dengan apa yang sudah Anda miliki: persyaratan, arsitektur, pemeriksaan parsial, pelatihan, pedoman. Tidak perlu segera menerapkan semua praktik pada semua proyek - bergerak secara iteratif. Tidak ada standar tunggal - percobaan dan mencoba pendekatan dan solusi yang berbeda.
Ada persamaan antara cacat keamanan informasi dan cacat fungsional.
Otomatiskan semuanyaitu bergerak. Apapun yang tidak bergerak, pindahkan dan otomatisasi. Jika sesuatu dilakukan dengan tangan, itu bukanlah bagian proses yang baik. Mungkin ada baiknya meninjaunya dan mengotomatiskannya juga.
Jika ukuran tim IS kecil - gunakan Juara Keamanan.
Mungkin apa yang saya bicarakan tidak cocok untuk Anda dan Anda akan menemukan sesuatu sendiri - dan itu bagus. Tetapi pilih alat berdasarkan persyaratan untuk proses Anda. Jangan lihat apa yang dikatakan komunitas, bahwa alat ini jelek dan ini bagus. Mungkin hal sebaliknya akan terjadi pada produk Anda.
Persyaratan alat.
- Positif Palsu tingkat rendah.
- Waktu analisis yang memadai.
- Kemudahan penggunaan.
- Ketersediaan integrasi.
- Memahami peta jalan pengembangan produk.
- Kemungkinan menyesuaikan alat.
Laporan Yuri terpilih sebagai salah satu yang terbaik di DevOpsConf 2018. Untuk mengetahui lebih banyak ide menarik dan kasus praktis, datanglah ke Skolkovo pada tanggal 27 dan 28 Mei di dalam . Lebih baik lagi, jika Anda siap untuk berbagi pengalaman untuk laporan sampai 21 April.
Sumber: www.habr.com