Ketakutan dan Kebencian terhadap DevSecOps

Kami mempunyai 2 penganalisis kod, 4 alat ujian dinamik, kraf kami sendiri dan 250 skrip. Bukan semua ini diperlukan dalam proses semasa, tetapi sebaik sahaja anda mula melaksanakan DevSecOps, anda perlu pergi ke penghujung.

Source. Pencipta watak: Justin Roiland dan Dan Harmon.

Apakah SecDevOps? Bagaimana pula dengan DevSecOps? Apakah perbezaannya? Keselamatan Aplikasi - tentang apa? Mengapa pendekatan klasik tidak berfungsi lagi? Tahu jawapan kepada semua soalan ini Yuri Shabalin daripada Keselamatan Ikan Todak. Yuri akan menjawab segala-galanya secara terperinci dan menganalisis masalah peralihan daripada model Keselamatan Aplikasi klasik kepada proses DevSecOps: cara mendekati penyepaduan proses pembangunan selamat ke dalam proses DevOps dengan betul dan tidak memecahkan apa-apa, bagaimana untuk melalui peringkat utama ujian keselamatan, alat apa yang boleh digunakan, dan perkara yang berbeza dan cara mengkonfigurasinya dengan betul untuk mengelakkan perangkap.

Mengenai pembesar suara: Yuri Shabalin - Ketua Arkitek Keselamatan di syarikat itu Keselamatan Ikan Todak. Bertanggungjawab untuk pelaksanaan SSDL, untuk penyepaduan keseluruhan alat analisis aplikasi ke dalam ekosistem pembangunan dan pengujian yang bersatu. 7 tahun pengalaman dalam keselamatan maklumat. Bekerja di Alfa-Bank, Sberbank dan Positive Technologies, yang membangunkan perisian dan menyediakan perkhidmatan. Penceramah di persidangan antarabangsa ZerONights, PHDays, RISSPA, OWASP.

Keselamatan Aplikasi: tentang apa?

Keselamatan Aplikasi - Ini ialah bahagian keselamatan yang bertanggungjawab untuk keselamatan aplikasi. Ini tidak terpakai pada infrastruktur atau keselamatan rangkaian, tetapi lebih kepada perkara yang kami tulis dan perkara yang diusahakan oleh pembangun - ini adalah kelemahan dan kelemahan aplikasi itu sendiri.

arah SDL atau SDLC - Kitaran hayat pembangunan keselamatan - dibangunkan oleh Microsoft. Gambar rajah menunjukkan model SDLC kanonik, tugas utamanya ialah penyertaan keselamatan pada setiap peringkat pembangunan, daripada keperluan kepada pelepasan dan pengeluaran. Microsoft menyedari bahawa terdapat terlalu banyak pepijat dalam industri, terdapat lebih banyak pepijat dan sesuatu yang perlu dilakukan mengenainya, dan mereka mencadangkan pendekatan ini, yang telah menjadi kanonik.

Keselamatan Aplikasi dan SSDL tidak bertujuan untuk mengesan kelemahan, seperti yang lazimnya dipercayai, tetapi untuk mencegah kejadiannya. Dari masa ke masa, pendekatan kanonik Microsoft telah dipertingkatkan, dibangunkan dan diperkenalkan ke dalam penyelaman yang lebih mendalam dan terperinci.

SDLC kanonik sangat terperinci dalam pelbagai metodologi - OpenSAMM, BSIMM, OWASP. Metodologi adalah berbeza, tetapi secara amnya serupa.

Membina Keselamatan Dalam Model Kematangan

saya paling suka BSIMM - Membina Keselamatan Dalam Model Kematangan. Asas metodologi adalah pembahagian proses Keselamatan Aplikasi kepada 4 domain: Tadbir Urus, Perisikan, Titik Sentuh SSDL dan Penerapan. Setiap domain mempunyai 12 amalan, yang diwakili sebagai 112 aktiviti.

Setiap daripada 112 aktiviti mempunyai 3 tahap kematangan: pemula, pertengahan dan lanjutan. Anda boleh mengkaji kesemua 12 amalan bahagian demi bahagian, pilih perkara yang penting kepada anda, fikirkan cara melaksanakannya dan tambah elemen secara beransur-ansur, contohnya, analisis kod statik dan dinamik atau semakan kod. Anda menulis rancangan dan dengan tenang bekerja mengikutnya sebagai sebahagian daripada pelaksanaan aktiviti yang dipilih.

Mengapa DevSecOps

DevOps ialah proses umum yang besar di mana keselamatan mesti diambil kira.

Pada mulanya DevOps melibatkan pemeriksaan keselamatan. Dalam amalan, bilangan pasukan keselamatan adalah jauh lebih kecil daripada sekarang, dan mereka tidak bertindak sebagai peserta dalam proses itu, tetapi sebagai badan kawalan dan penyeliaan yang mengenakan keperluan ke atasnya dan menyemak kualiti produk pada akhir keluaran. Ini adalah pendekatan klasik di mana pasukan keselamatan berada di belakang tembok daripada pembangunan dan tidak mengambil bahagian dalam proses itu.

Masalah utama ialah keselamatan maklumat adalah berasingan daripada pembangunan. Biasanya ini adalah sejenis litar keselamatan maklumat dan ia mengandungi 2-3 alat yang besar dan mahal. Setiap enam bulan sekali, kod sumber atau aplikasi yang perlu disemak tiba, dan sekali setahun ia dihasilkan pentests. Semua ini membawa kepada fakta bahawa tarikh keluaran untuk industri ditangguhkan, dan pembangun terdedah kepada sejumlah besar kelemahan daripada alatan automatik. Tidak mustahil untuk membongkar dan membaiki semua ini, kerana keputusan untuk enam bulan sebelumnya tidak diselesaikan, tetapi ini adalah kumpulan baru.

Dalam perjalanan kerja syarikat kami, kami melihat bahawa keselamatan dalam semua bidang dan industri memahami bahawa sudah tiba masanya untuk mengejar dan berputar dengan pembangunan pada roda yang sama - dalam Agile. Paradigma DevSecOps sangat sesuai dengan metodologi pembangunan tangkas, pelaksanaan, sokongan dan penyertaan dalam setiap keluaran dan lelaran.

Peralihan kepada DevSecOps

Perkataan yang paling penting dalam Kitaran Hayat Pembangunan Keselamatan ialah "proses". Anda mesti memahami perkara ini sebelum anda berfikir tentang membeli alatan.

Hanya memasukkan alat ke dalam proses DevOps tidak mencukupi—komunikasi dan pemahaman antara peserta proses adalah penting.

Orang lebih penting, bukan alat.

Selalunya, perancangan untuk proses pembangunan yang selamat bermula dengan memilih dan membeli alat, dan berakhir dengan percubaan untuk menyepadukan alat itu ke dalam proses semasa, yang kekal sebagai percubaan. Ini membawa kepada akibat yang tidak diingini, kerana semua alat mempunyai ciri dan batasan mereka sendiri.

Kes biasa ialah apabila jabatan keselamatan memilih alat yang bagus dan mahal dengan keupayaan yang luas, dan datang kepada pembangun untuk mengintegrasikannya ke dalam proses. Tetapi ia tidak berjaya - prosesnya disusun sedemikian rupa sehingga batasan alat yang sudah dibeli tidak sesuai dengan paradigma semasa.

Mula-mula, terangkan hasil yang anda inginkan dan bagaimana rupa prosesnya. Ini akan membantu memahami peranan alat dan keselamatan dalam proses.

Mulakan dengan perkara yang sudah digunakan

Sebelum membeli alat mahal, lihat apa yang anda sudah ada. Setiap syarikat mempunyai keperluan keselamatan untuk pembangunan, terdapat pemeriksaan, pentest - mengapa tidak mengubah semua ini menjadi bentuk yang boleh difahami dan mudah untuk semua orang?

Biasanya keperluan adalah kertas Talmud yang terletak di atas rak. Terdapat satu kes apabila kami datang ke syarikat untuk melihat proses dan meminta untuk melihat keperluan keselamatan untuk perisian tersebut. Pakar yang menangani perkara ini menghabiskan masa yang lama mencari:

- Sekarang, di suatu tempat dalam nota terdapat laluan di mana dokumen ini terletak.

Hasilnya, kami menerima dokumen itu seminggu kemudian.

Untuk keperluan, semakan dan perkara lain, buat halaman di mis. Confluence - ia mudah untuk semua orang.

Lebih mudah untuk memformat semula perkara yang telah anda miliki dan menggunakannya untuk bermula.

Gunakan Juara Keselamatan

Biasanya, dalam syarikat purata dengan 100-200 pemaju, terdapat seorang pakar keselamatan yang melaksanakan beberapa fungsi dan tidak mempunyai masa untuk memeriksa segala-galanya secara fizikal. Walaupun dia mencuba yang terbaik, dia sendiri tidak akan menyemak semua kod yang dijana pembangunan. Untuk kes sedemikian, satu konsep telah dibangunkan - Juara Keselamatan.

Juara Keselamatan ialah orang dalam pasukan pembangunan yang berminat dengan keselamatan produk anda.

Juara Keselamatan ialah pintu masuk ke dalam pasukan pembangunan dan penginjil keselamatan digabungkan menjadi satu.

Biasanya, apabila pakar keselamatan datang ke pasukan pembangunan dan menunjukkan ralat dalam kod, dia menerima jawapan yang mengejutkan:

- Dan siapa kamu? Saya jumpa awak buat kali pertama. Semuanya baik-baik saja dengan saya - rakan kanan saya memberi saya "mohon" pada semakan kod, kami teruskan!

Ini adalah situasi biasa, kerana terdapat lebih banyak kepercayaan pada warga emas atau hanya rakan sepasukan yang pembangun sentiasa berinteraksi di tempat kerja dan dalam semakan kod. Jika, bukannya pegawai keselamatan, Juara Keselamatan menunjukkan kesilapan dan akibatnya, maka kata-katanya akan lebih berat.

Selain itu, pembangun mengetahui kod mereka lebih baik daripada mana-mana pakar keselamatan. Bagi seseorang yang mempunyai sekurang-kurangnya 5 projek dalam alat analisis statik, biasanya sukar untuk mengingati semua nuansa. Juara Keselamatan mengetahui produk mereka: perkara yang berinteraksi dengan perkara dan perkara yang perlu dilihat pada mulanya - mereka lebih berkesan.

Jadi pertimbangkan untuk melaksanakan Juara Keselamatan dan meluaskan pengaruh pasukan keselamatan anda. Ini juga berguna untuk juara itu sendiri: pembangunan profesional dalam bidang baharu, mengembangkan ufuk teknikalnya, meningkatkan kemahiran teknikal, pengurusan dan kepimpinan, meningkatkan nilai pasaran. Ini adalah beberapa elemen kejuruteraan sosial, "mata" anda dalam pasukan pembangunan.

Peringkat ujian

Paradigma 20 hingga 80 mengatakan bahawa 20% usaha menghasilkan 80% hasil. 20% ini adalah amalan analisis aplikasi yang boleh dan harus diautomasikan. Contoh aktiviti tersebut ialah analisis statik - SAST, analisis dinamik - DAST и Kawalan Sumber Terbuka. Saya akan memberitahu anda dengan lebih terperinci tentang aktiviti, serta tentang alatan, ciri yang biasa kami hadapi semasa memperkenalkannya ke dalam proses, dan cara melakukannya dengan betul.

Masalah utama alat

Saya akan mengetengahkan masalah yang relevan untuk semua instrumen dan memerlukan perhatian. Saya akan menganalisisnya dengan lebih terperinci supaya tidak mengulanginya lagi.

Masa analisis yang panjang. Jika dari komit untuk melepaskan ia mengambil masa 30 minit untuk semua ujian dan pemasangan, maka semakan keselamatan maklumat akan mengambil masa sehari. Jadi tiada siapa yang akan memperlahankan proses itu. Ambil kira ciri ini dan buat kesimpulan.

Tahap tinggi Negatif Palsu atau Positif Palsu. Semua produk adalah berbeza, semuanya menggunakan rangka kerja yang berbeza dan gaya pengekodan mereka sendiri. Pada pangkalan kod dan teknologi yang berbeza, alatan mungkin menunjukkan tahap Negatif Palsu dan Positif Palsu yang berbeza. Jadi lihat apa sebenarnya yang ada di dalamnya anda syarikat dan untuk anda aplikasi akan menunjukkan hasil yang baik dan boleh dipercayai.

Tiada penyepaduan dengan alatan sedia ada. Lihat alat dari segi penyepaduan dengan perkara yang telah anda gunakan. Contohnya, jika anda mempunyai Jenkins atau TeamCity, semak penyepaduan alatan dengan perisian ini dan bukan dengan GitLab CI, yang anda tidak gunakan.

Kekurangan atau kerumitan penyesuaian yang berlebihan. Jika alat tidak mempunyai API, maka mengapa ia diperlukan? Semua yang boleh dilakukan dalam antara muka harus tersedia melalui API. Sebaik-baiknya, alat itu harus mempunyai keupayaan untuk menyesuaikan semakan.

Tiada Pelan Hala Tuju Pembangunan Produk. Pembangunan tidak berhenti, kami sentiasa menggunakan rangka kerja dan fungsi baharu, menulis semula kod lama ke dalam bahasa baharu. Kami ingin memastikan bahawa alat yang kami beli akan menyokong rangka kerja dan teknologi baharu. Oleh itu, adalah penting untuk mengetahui bahawa produk itu mempunyai nyata dan betul Roadmap pembangunan.

Ciri proses

Sebagai tambahan kepada ciri alat, ambil kira ciri proses pembangunan. Sebagai contoh, menghalang pembangunan adalah kesilapan biasa. Mari kita lihat apakah ciri-ciri lain yang perlu diambil kira dan apa yang perlu diberi perhatian oleh pasukan keselamatan.

Untuk tidak terlepas tarikh akhir pembangunan dan keluarkan, buat peraturan yang berbeza dan berbeza tunjuk sumbat — kriteria untuk menghentikan proses binaan sekiranya terdapat kelemahan — untuk persekitaran yang berbeza. Sebagai contoh, kami memahami bahawa cawangan semasa pergi ke pendirian pembangunan atau UAT, yang bermaksud kami tidak berhenti dan berkata:

"Anda mempunyai kelemahan di sini, anda tidak akan pergi ke mana-mana lagi!"

Pada ketika ini, adalah penting untuk memberitahu pembangun bahawa terdapat isu keselamatan yang memerlukan perhatian.

Kehadiran kelemahan bukanlah penghalang untuk ujian selanjutnya: manual, integrasi atau manual. Sebaliknya, kita perlu meningkatkan keselamatan produk, dan supaya pembangun tidak mengabaikan apa yang mereka rasa selamat. Oleh itu, kadangkala kami melakukan ini: di tempat berdiri, apabila ia dilancarkan ke persekitaran pembangunan, kami hanya memberitahu pembangunan:

- Lelaki, anda mempunyai masalah, sila beri perhatian kepada mereka.

Pada peringkat UAT kami sekali lagi menunjukkan amaran tentang kelemahan, dan pada peringkat keluaran kami berkata:

- Kawan-kawan, kami memberi amaran kepada anda beberapa kali, anda tidak melakukan apa-apa - kami tidak akan membiarkan anda keluar dengan ini.

Jika kita bercakap tentang kod dan dinamik, maka adalah perlu untuk menunjukkan dan memberi amaran tentang kelemahan hanya ciri dan kod yang baru ditulis dalam ciri ini. Jika pembangun mengalihkan butang sebanyak 3 piksel dan kami memberitahunya bahawa dia mempunyai suntikan SQL di sana dan oleh itu perlu diperbaiki segera, ini adalah salah. Lihat sahaja apa yang ditulis sekarang dan pada perubahan yang datang kepada aplikasi.

Katakan kita mempunyai kecacatan fungsi tertentu - cara aplikasi tidak sepatutnya berfungsi: wang tidak dipindahkan, apabila anda mengklik butang tidak ada peralihan ke halaman seterusnya, atau produk tidak dimuatkan. Kecacatan Keselamatan - ini adalah kecacatan yang sama, tetapi bukan dari segi operasi aplikasi, tetapi dari segi keselamatan.

Tidak semua masalah kualiti perisian adalah masalah keselamatan. Tetapi semua masalah keselamatan berkaitan dengan kualiti perisian. Sherif Mansour, Expedia.

Memandangkan semua kelemahan adalah kecacatan yang sama, ia harus ditempatkan di tempat yang sama dengan semua kecacatan pembangunan. Jadi lupakan laporan dan PDF yang menakutkan yang tiada siapa yang membaca.

Semasa saya bekerja di syarikat pembangunan, saya menerima laporan daripada alat analisis statik. Saya membukanya, berasa ngeri, membuat kopi, membelek 350 muka surat, menutupnya dan terus bekerja. Laporan besar adalah laporan mati. Biasanya mereka tidak ke mana-mana, surat-surat itu dipadamkan, dilupakan, hilang, atau perniagaan mengatakan ia menerima risiko.

Apa nak buat? Kami hanya menukar kecacatan yang disahkan yang kami temui kepada bentuk yang sesuai untuk pembangunan, contohnya, kami meletakkannya dalam tunggakan di Jira. Kami mengutamakan kecacatan dan menghapuskannya mengikut keutamaan, bersama dengan kecacatan fungsi dan kecacatan ujian.

Analisis Statik - SAST

Ini ialah analisis kod untuk kelemahan., tetapi ia tidak sama dengan SonarQube. Kami tidak hanya menyemak corak atau gaya. Beberapa pendekatan digunakan dalam analisis: mengikut pokok kerentanan, mengikut Aliran data, dengan menganalisis fail konfigurasi. Ini semua yang berkaitan dengan kod itu sendiri.

Kebaikan pendekatan: mengenal pasti kelemahan dalam kod pada peringkat awal pembangunanapabila belum ada dirian atau alatan siap, dan keupayaan pengimbasan tambahan: mengimbas bahagian kod yang telah berubah, dan hanya ciri yang sedang kami lakukan, yang mengurangkan masa pengimbasan.

Kekurangan - ini adalah kekurangan sokongan untuk bahasa yang diperlukan.

Integrasi yang diperlukan, yang sepatutnya ada dalam alat, pada pendapat subjektif saya:

• Alat integrasi: Jenkins, TeamCity dan Gitlab CI.
• Persekitaran pembangunan: Intellij IDEA, Visual Studio. Adalah lebih mudah bagi pembangun untuk tidak menavigasi antara muka yang tidak dapat difahami yang masih perlu dihafal, tetapi untuk melihat semua penyepaduan dan kelemahan yang diperlukan yang telah ditemuinya tepat di tempat kerja dalam persekitaran pembangunannya sendiri.
• Semakan kod: SonarQube dan semakan manual.
• Penjejak kecacatan: Jira dan Bugzilla.

Gambar menunjukkan beberapa wakil terbaik analisis statik.

Bukan alatan yang penting, tetapi prosesnya, jadi terdapat penyelesaian Sumber Terbuka yang juga bagus untuk menguji proses tersebut.

Sumber Terbuka SAST tidak akan menemui sejumlah besar kelemahan atau DataFlow yang kompleks, tetapi ia boleh dan harus digunakan semasa membina proses. Mereka membantu memahami cara proses itu akan dibina, siapa yang akan bertindak balas terhadap pepijat, siapa yang akan melaporkan dan siapa yang akan melaporkan. Jika anda ingin menjalankan peringkat awal membina keselamatan kod anda, gunakan penyelesaian Sumber Terbuka.

Bagaimanakah ini boleh disepadukan jika anda berada di permulaan perjalanan anda dan tidak mempunyai apa-apa: tiada CI, tiada Jenkins, tiada TeamCity? Mari kita pertimbangkan penyepaduan ke dalam proses.

Penyepaduan tahap CVS

Jika anda mempunyai Bitbucket atau GitLab, anda boleh menyepadukan pada tahap Sistem Versi Serentak.

Mengikut acara - tarik permintaan, komited. Anda mengimbas kod dan status binaan menunjukkan sama ada semakan keselamatan lulus atau gagal.

Maklum balas. Sudah tentu, maklum balas sentiasa diperlukan. Jika anda hanya melakukan keselamatan di sisi, masukkannya ke dalam kotak dan tidak memberitahu sesiapa mengenainya, dan kemudian pada akhir bulan membuang sekumpulan pepijat - ini tidak betul dan tidak baik.

Integrasi dengan sistem semakan kod

Pernah, kami bertindak sebagai penyemak lalai untuk pengguna AppSec teknikal dalam beberapa projek penting. Bergantung pada sama ada ralat dikenal pasti dalam kod baharu atau tiada ralat, penyemak menetapkan status pada permintaan tarik untuk "menerima" atau "memerlukan kerja" - sama ada semuanya OK, atau pautan kepada perkara yang perlu diperbaiki. perlu diperbaiki. Untuk penyepaduan dengan versi yang akan dikeluarkan, kami telah mendayakan larangan gabungan jika ujian keselamatan maklumat tidak lulus. Kami memasukkan ini dalam semakan kod manual dan peserta lain dalam proses melihat status keselamatan untuk proses tertentu ini.

Integrasi dengan SonarQube

Ramai dah pintu gerbang berkualiti dari segi kualiti kod. Ia sama di sini - anda boleh membuat get yang sama hanya untuk alatan SAST. Akan ada antara muka yang sama, gerbang kualiti yang sama, hanya ia akan dipanggil pintu pagar keselamatan. Dan juga, jika anda mempunyai proses menggunakan SonarQube, anda boleh dengan mudah menyepadukan segala-galanya di sana.

Integrasi di peringkat CI

Segala-galanya di sini juga agak mudah:

• Setanding dengan autotest, ujian unit.
• Pembahagian mengikut peringkat pembangunan: dev, ujian, prod. Set peraturan yang berbeza atau keadaan gagal yang berbeza mungkin disertakan: hentikan perhimpunan, jangan hentikan perhimpunan.
• Pelancaran segerak/tak segerak. Kami sedang menunggu ujian keselamatan tamat atau tidak. Iaitu, kami hanya melancarkannya dan meneruskan, dan kemudian kami mendapat status bahawa semuanya baik atau buruk.

Semuanya dalam dunia merah jambu yang sempurna. Tidak ada perkara seperti itu dalam kehidupan sebenar, tetapi kami berusaha. Keputusan menjalankan semakan keselamatan hendaklah serupa dengan keputusan ujian unit.

Sebagai contoh, kami mengambil projek besar dan memutuskan bahawa sekarang kami akan mengimbasnya dengan SAST - OK. Kami menolak projek ini ke dalam SAST, ia memberi kami 20 kelemahan dan dengan keputusan yang kuat, kami memutuskan bahawa semuanya baik-baik saja. 000 kelemahan adalah hutang teknikal kami. Kami akan meletakkan hutang dalam kotak, kami akan menjelaskannya secara perlahan-lahan dan menambah pepijat pada penjejak kecacatan. Mari ambil syarikat, lakukan semuanya sendiri atau minta Juara Keselamatan membantu kami - dan hutang teknikal akan berkurangan.

Dan semua kelemahan yang baru muncul dalam kod baharu mesti dihapuskan dengan cara yang sama seperti ralat dalam unit atau dalam autotest. Secara relatifnya, perhimpunan bermula, kami menjalankannya, dua ujian dan dua ujian keselamatan gagal. OK - kami pergi, melihat apa yang berlaku, membetulkan satu perkara, memperbaiki yang lain, menjalankannya pada kali seterusnya - semuanya baik-baik saja, tiada kelemahan baharu muncul, tiada ujian yang gagal. Jika tugas ini lebih mendalam dan anda perlu memahaminya dengan baik, atau membetulkan kelemahan menjejaskan lapisan besar apa yang terdapat di bawah hud: pepijat telah ditambahkan pada penjejak kecacatan, ia diutamakan dan diperbetulkan. Malangnya, dunia tidak sempurna dan ujian kadangkala gagal.

Contoh pintu keselamatan ialah analog pintu gerbang kualiti, dari segi kehadiran dan bilangan kelemahan dalam kod.

Kami menyepadukan dengan SonarQube - pemalam dipasang, semuanya sangat mudah dan sejuk.

Integrasi dengan persekitaran pembangunan

Pilihan integrasi:

• Menjalankan imbasan dari persekitaran pembangunan sebelum melakukan.
• Lihat keputusan.
• Analisis keputusan.
• Penyegerakan dengan pelayan.

Beginilah rupa untuk menerima hasil daripada pelayan.

Dalam persekitaran pembangunan kita IDEA Intellij item tambahan hanya muncul yang memberitahu anda bahawa kelemahan tersebut telah dikesan semasa imbasan. Anda boleh segera mengedit kod, melihat cadangan dan Graf Aliran. Ini semua terletak di tempat kerja pemaju, yang sangat mudah - tidak perlu mengikuti pautan lain dan melihat sesuatu tambahan.

Open Source

Ini adalah topik kegemaran saya. Semua orang menggunakan perpustakaan Sumber Terbuka - mengapa menulis sekumpulan tongkat dan basikal apabila anda boleh mengambil perpustakaan siap yang semuanya telah dilaksanakan?

Sudah tentu, ini benar, tetapi perpustakaan juga ditulis oleh orang, mereka juga termasuk risiko tertentu dan terdapat juga kelemahan yang dilaporkan secara berkala, atau berterusan. Oleh itu, terdapat langkah seterusnya dalam Keselamatan Aplikasi - ini ialah analisis komponen Sumber Terbuka.

Analisis Sumber Terbuka - OSA

Alat ini termasuk tiga peringkat besar.

Mencari kelemahan dalam perpustakaan. Sebagai contoh, alat itu mengetahui bahawa kami menggunakan beberapa perpustakaan, dan itu CVE atau terdapat beberapa kelemahan dalam penjejak pepijat yang berkaitan dengan versi pustaka ini. Apabila anda cuba menggunakannya, alat itu akan mengeluarkan amaran bahawa perpustakaan terdedah dan menasihati anda untuk menggunakan versi lain yang tidak mempunyai kelemahan.

Analisis ketulenan lesen. Ini belum lagi popular di sini, tetapi jika anda bekerja di luar negara, maka dari semasa ke semasa anda boleh mendapatkan cukai di sana kerana menggunakan komponen sumber terbuka yang tidak boleh digunakan atau diubah suai. Mengikut dasar perpustakaan berlesen, kami tidak boleh melakukan ini. Atau, jika kami mengubah suai dan menggunakannya, kami harus menyiarkan kod kami. Sudah tentu, tiada siapa yang mahu menerbitkan kod produk mereka, tetapi anda juga boleh melindungi diri anda daripada ini.

Analisis komponen yang digunakan dalam persekitaran industri. Mari bayangkan situasi hipotesis bahawa kami akhirnya telah menyelesaikan pembangunan dan mengeluarkan keluaran terbaru perkhidmatan mikro kami. Dia tinggal di sana dengan hebat - seminggu, sebulan, setahun. Kami tidak mengumpulnya, kami tidak menjalankan pemeriksaan keselamatan, semuanya nampaknya baik-baik saja. Tetapi tiba-tiba, dua minggu selepas keluaran, kelemahan kritikal muncul dalam komponen Sumber Terbuka, yang kami gunakan dalam binaan khusus ini, dalam persekitaran perindustrian. Jika kami tidak merekodkan apa dan di mana kami gunakan, maka kami tidak akan melihat kelemahan ini. Sesetengah alatan mempunyai keupayaan untuk memantau kelemahan dalam perpustakaan yang digunakan dalam industri pada masa ini. Ia sangat berguna.

Возможности:

• Dasar yang berbeza untuk peringkat pembangunan yang berbeza.
• Memantau komponen dalam persekitaran industri.
• Kawalan perpustakaan dalam organisasi.
• Sokongan untuk pelbagai sistem binaan dan bahasa.
• Analisis imej Docker.

Beberapa contoh pemimpin industri yang terlibat dalam analisis Sumber Terbuka.

Satu-satunya yang percuma adalah ini Ketergantungan-Semak daripada OWASP. Anda boleh menghidupkannya pada peringkat pertama, lihat cara ia berfungsi dan perkara yang disokongnya. Pada asasnya, ini semua adalah produk awan, atau di premis, tetapi di belakang pangkalannya, ia masih dihantar ke Internet. Mereka tidak menghantar perpustakaan anda, tetapi cincang atau nilai mereka sendiri, yang mereka kira, dan cap jari ke pelayan mereka untuk menerima maklumat tentang kehadiran kelemahan.

Penyepaduan proses

Kawalan perimeter perpustakaan, yang dimuat turun daripada sumber luaran. Kami mempunyai repositori luaran dan dalaman. Contohnya, Pusat Acara menjalankan Nexus dan kami ingin memastikan bahawa tiada kelemahan dalam repositori kami dengan status "kritikal" atau "tinggi". Anda boleh mengkonfigurasi proksi menggunakan alat Kitaran Hayat Firewall Nexus supaya kelemahan tersebut diputuskan dan tidak berakhir di repositori dalaman.

Integrasi ke dalam CI. Pada tahap yang sama dengan autotest, ujian unit dan pembahagian ke peringkat pembangunan: dev, test, prod. Pada setiap peringkat, anda boleh memuat turun mana-mana perpustakaan, menggunakan apa sahaja, tetapi jika ada sesuatu yang sukar dengan status "kritikal", mungkin ia patut menarik perhatian pembangun kepada ini pada peringkat pelepasan ke dalam pengeluaran.

Integrasi dengan artifak: Nexus dan JFrog.

Integrasi ke dalam persekitaran pembangunan. Alat yang anda pilih harus mempunyai integrasi dengan persekitaran pembangunan. Pembangun mesti mempunyai akses kepada hasil pengimbasan dari tempat kerjanya, atau keupayaan untuk mengimbas dan menyemak kod itu sendiri untuk mencari kelemahan sebelum melakukan CVS.

Penyepaduan CD. Ini adalah ciri hebat yang saya sangat suka dan yang telah saya bincangkan - memantau kemunculan kelemahan baharu dalam persekitaran perindustrian. Ia berfungsi seperti ini.

Kami ada Repositori Komponen Awam — beberapa alatan di luar dan repositori dalaman kami. Kami mahu ia mengandungi komponen yang dipercayai sahaja. Apabila membuat proksi permintaan, kami menyemak bahawa perpustakaan yang dimuat turun tidak mempunyai kelemahan. Jika ia berada di bawah dasar tertentu yang kami tetapkan dan semestinya menyelaraskan dengan pembangunan, maka kami tidak memuat naiknya dan digesa untuk menggunakan versi lain. Sehubungan itu, jika terdapat sesuatu yang benar-benar kritikal dan buruk dalam perpustakaan, maka pembangun tidak akan menerima perpustakaan pada peringkat pemasangan - biarkan dia menggunakan versi yang lebih tinggi atau lebih rendah.

• Semasa membina, kami menyemak bahawa tiada siapa yang tergelincir apa-apa yang buruk, bahawa semua komponen selamat dan tiada siapa yang membawa apa-apa yang berbahaya pada pemacu denyar.
• Kami hanya mempunyai komponen yang dipercayai dalam repositori.
• Apabila menggunakan, kami sekali lagi menyemak pakej itu sendiri: imej perang, balang, DL atau Docker untuk memastikan ia mematuhi dasar.
• Apabila memasuki industri, kami memantau perkara yang berlaku dalam persekitaran industri: kelemahan kritikal muncul atau tidak muncul.

Analisis Dinamik - DAST

Alat analisis dinamik pada asasnya berbeza daripada semua yang telah dinyatakan sebelum ini. Ini adalah sejenis tiruan kerja pengguna dengan aplikasi. Jika ini adalah aplikasi web, kami menghantar permintaan, mensimulasikan kerja pelanggan, klik pada butang di bahagian hadapan, hantar data tiruan dari borang: petikan, kurungan, aksara dalam pengekodan yang berbeza, untuk melihat cara aplikasi berfungsi dan memproses data luaran.

Sistem yang sama membolehkan anda menyemak kelemahan templat dalam Sumber Terbuka. Memandangkan DAST tidak mengetahui Sumber Terbuka yang kami gunakan, ia hanya membuang corak "berniat jahat" dan menganalisis respons pelayan:

- Ya, terdapat masalah penyahserialisasian di sini, tetapi tidak di sini.

Terdapat risiko besar dalam hal ini, kerana jika anda menjalankan ujian keselamatan ini di bangku yang sama yang digunakan oleh penguji, perkara yang tidak menyenangkan boleh berlaku.

• Beban tinggi pada rangkaian pelayan aplikasi.
• Tiada integrasi.
• Keupayaan untuk menukar tetapan aplikasi yang dianalisis.
• Tiada sokongan untuk teknologi yang diperlukan.
• Kesukaran menyediakan.

Kami mempunyai situasi apabila kami akhirnya melancarkan AppScan: kami menghabiskan masa yang lama mencuba untuk mendapatkan akses kepada aplikasi, mendapat 3 akaun dan gembira - kami akhirnya akan menyemak segala-galanya! Kami melancarkan imbasan, dan perkara pertama yang AppScan lakukan ialah pergi ke panel pentadbir, menembusi semua butang, menukar separuh daripada data, dan kemudian membunuh sepenuhnya pelayan dengannya. borang mel-permintaan. Pembangunan dengan ujian berkata:

- Lelaki, adakah anda bergurau dengan saya?! Kami memberi anda akaun, dan anda menetapkan pendirian!

Pertimbangkan kemungkinan risiko. Sebaik-baiknya, sediakan pendirian berasingan untuk menguji keselamatan maklumat, yang akan diasingkan daripada persekitaran lain sekurang-kurangnya entah bagaimana, dan periksa panel pentadbir secara bersyarat, sebaik-baiknya dalam mod manual. Ini adalah percubaan - baki peratusan usaha yang kami tidak pertimbangkan sekarang.

Perlu dipertimbangkan bahawa anda boleh menggunakannya sebagai analog ujian beban. Pada peringkat pertama, anda boleh menghidupkan pengimbas dinamik dengan 10-15 utas dan melihat apa yang berlaku, tetapi biasanya, seperti yang ditunjukkan oleh latihan, tiada apa yang baik.

Sedikit sumber yang biasa kami gunakan.

Patut ditonjolkan Suite Burp ialah "pisau Swiss" untuk mana-mana profesional keselamatan. Semua orang menggunakannya dan ia sangat mudah. Versi demo baharu edisi perusahaan kini telah dikeluarkan. Jika sebelum ini ia hanya utiliti yang berdiri sendiri dengan pemalam, kini pembangun akhirnya membuat pelayan yang besar dari mana ia akan dapat menguruskan beberapa ejen. Ini bagus, saya syorkan anda mencubanya.

Penyepaduan proses

Integrasi berlaku dengan baik dan ringkas: mula mengimbas selepas pemasangan berjaya permohonan untuk pendirian dan mengimbas selepas ujian integrasi berjaya.

Jika penyepaduan tidak berfungsi atau terdapat stub dan fungsi olok-olok, ia tidak berguna dan tidak berguna - tidak kira apa corak yang kami hantar, pelayan tetap akan bertindak balas dengan cara yang sama.

• Sebaik-baiknya, tempat ujian yang berasingan.
• Sebelum ujian, tuliskan urutan log masuk.
• Pengujian sistem pentadbiran adalah manual sahaja.

proses

Sedikit umum tentang proses secara umum dan tentang kerja setiap alat khususnya. Semua aplikasi adalah berbeza - satu berfungsi lebih baik dengan analisis dinamik, satu lagi dengan analisis statik, satu pertiga dengan analisis OpenSource, pentest atau sesuatu yang lain sama sekali, contohnya, peristiwa dengan Waf.

Setiap proses memerlukan kawalan.

Untuk memahami cara sesuatu proses berfungsi dan tempat ia boleh dipertingkatkan, anda perlu mengumpulkan metrik daripada semua yang anda boleh dapatkan, termasuk metrik pengeluaran, metrik daripada alatan dan daripada penjejak kecacatan.

Sebarang maklumat berguna. Ia adalah perlu untuk melihat dari sudut yang berbeza di mana alat ini atau itu lebih baik digunakan, di mana proses secara khusus merosot. Ia mungkin berbaloi untuk melihat masa tindak balas pembangunan untuk melihat tempat untuk menambah baik proses berdasarkan masa. Lebih banyak data, lebih banyak bahagian boleh dibina dari peringkat atasan kepada butiran setiap proses.

Memandangkan semua penganalisis statik dan dinamik mempunyai API mereka sendiri, kaedah pelancaran mereka sendiri, prinsip, sesetengahnya mempunyai penjadual, yang lain tidak - kami sedang menulis alat AppSec Orkestra, yang membolehkan anda mencipta satu titik masuk ke dalam keseluruhan proses daripada produk dan mengurusnya dari satu titik.

Pengurus, pembangun dan jurutera keselamatan mempunyai satu pintu masuk yang mana mereka boleh melihat perkara yang sedang berjalan, mengkonfigurasi dan menjalankan imbasan, menerima keputusan imbasan dan menyerahkan keperluan. Kami cuba untuk beralih daripada kerja kertas, untuk menterjemahkan segala-galanya menjadi manusia, yang digunakan oleh pembangunan - halaman tentang Confluence dengan status dan metrik, kecacatan dalam Jira atau dalam pelbagai penjejak kecacatan, atau penyepaduan ke dalam proses segerak/tak segerak dalam CI /CD.

Takeaways Utama

Alat bukanlah perkara utama. Mula-mula fikirkan proses - kemudian laksanakan alat. Alatnya bagus tetapi mahal, jadi anda boleh mulakan dengan proses dan membina komunikasi dan persefahaman antara pembangunan dan keselamatan. Dari sudut keselamatan, tidak perlu "menghentikan" segala-galanya. Dari sudut pembangunan, jika ada sesuatu mega super kritikal yang tinggi, maka ia perlu dihapuskan, dan tidak menutup mata terhadap masalah itu.

Kualiti produk - matlamat bersama kedua-dua keselamatan dan pembangunan. Kami melakukan satu perkara, kami cuba memastikan semuanya berfungsi dengan betul dan tiada risiko reputasi atau kerugian kewangan. Inilah sebabnya kami mempromosikan pendekatan DevSecOps, SecDevOps untuk meningkatkan komunikasi dan meningkatkan kualiti produk.

Mulakan dengan apa yang anda sudah ada: keperluan, seni bina, semakan separa, latihan, garis panduan. Tidak perlu segera menggunakan semua amalan untuk semua projek - bergerak secara berulang. Tiada standard tunggal - eksperimen dan cuba pendekatan dan penyelesaian yang berbeza.

Terdapat tanda yang sama antara kecacatan keselamatan maklumat dan kecacatan fungsi.

Automatikkan segalanyayang bergerak. Apa sahaja yang tidak bergerak, gerakkannya dan automatikkannya. Jika sesuatu dilakukan dengan tangan, ia bukanlah sebahagian daripada proses yang baik. Mungkin ia berbaloi untuk menyemaknya dan mengautomasikannya juga.

Jika saiz pasukan IS kecil - gunakan Juara Keselamatan.

Mungkin apa yang saya bincangkan tidak sesuai dengan anda dan anda akan menghasilkan sesuatu yang anda sendiri - dan itu bagus. Tetapi pilih alatan berdasarkan keperluan untuk proses anda. Jangan lihat apa yang masyarakat katakan, alat ini buruk dan ini baik. Mungkin sebaliknya akan berlaku untuk produk anda.

Keperluan untuk alatan.

• Tahap rendah Positif Palsu.
• Masa analisis yang mencukupi.
• Kemudahan penggunaan.
• Ketersediaan integrasi.
• Memahami pelan hala tuju pembangunan produk.
• Kemungkinan menyesuaikan alat.

Laporan Yuri dipilih sebagai salah satu yang terbaik di DevOpsConf 2018. Untuk berkenalan dengan idea dan kes praktikal yang lebih menarik, datang ke Skolkovo pada 27 dan 28 Mei DevOpsConf dalam raya RIT++. Lebih baik lagi, jika anda bersedia untuk berkongsi pengalaman anda, maka memohon untuk laporan sehingga 21 April.

Sumber: www.habr.com