Sebagai bagian dari aktivitas profesional mereka, pengembang, pentester, dan spesialis keamanan harus berurusan dengan proses seperti Manajemen Kerentanan (VM), SDLC (Aman).
Di bawah ungkapan-ungkapan ini terdapat berbagai praktik dan alat yang digunakan dan saling terkait, meskipun penggunanya berbeda.
Kemajuan teknis belum mencapai titik di mana satu alat dapat menggantikan seseorang untuk menganalisis keamanan infrastruktur dan perangkat lunak.
Menarik untuk memahami mengapa hal ini terjadi dan masalah apa yang dihadapi.
Процессы
Proses Manajemen Kerentanan dirancang untuk pemantauan berkelanjutan terhadap keamanan infrastruktur dan manajemen patch.
Proses Secure SDLC (“siklus pengembangan aman”) dirancang untuk menjaga keamanan aplikasi selama pengembangan dan pengoperasian.
Bagian serupa dari proses ini adalah proses Penilaian Kerentanan - penilaian kerentanan, pemindaian kerentanan.
Perbedaan utama antara pemindaian VM dan SDLC adalah dalam kasus pertama, tujuannya adalah untuk mendeteksi kerentanan yang diketahui pada perangkat lunak atau konfigurasi pihak ketiga. Misalnya, versi Windows yang sudah ketinggalan zaman atau string komunitas default untuk SNMP.
Dalam kasus kedua, tujuannya adalah untuk mendeteksi kerentanan tidak hanya pada komponen pihak ketiga (dependensi), tetapi terutama pada kode produk baru.
Hal ini menciptakan perbedaan dalam alat dan pendekatan. Menurut pendapat saya, tugas menemukan kerentanan baru dalam suatu aplikasi jauh lebih menarik, karena tidak sampai pada versi sidik jari, mengumpulkan spanduk, memaksa kata sandi, dll.
Untuk pemindaian otomatis kerentanan aplikasi berkualitas tinggi, diperlukan algoritma yang mempertimbangkan semantik aplikasi, tujuannya, dan ancaman spesifik.
Pemindai infrastruktur seringkali dapat diganti dengan pengatur waktu, seperti yang saya katakan . Intinya adalah, secara statistik, Anda dapat menganggap infrastruktur Anda rentan jika Anda tidak memperbaruinya, katakanlah, selama sebulan.
Alat
Pemindaian, seperti analisis keamanan, dapat dilakukan menggunakan kotak hitam atau kotak putih.
Black Box
Saat pemindaian blackbox, alat tersebut harus dapat bekerja dengan layanan melalui antarmuka yang sama dengan yang digunakan pengguna untuk bekerja dengannya.
Pemindai infrastruktur (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose, dll.) mencari port jaringan yang terbuka, mengumpulkan “spanduk”, menentukan versi perangkat lunak yang diinstal, dan mencari basis pengetahuan mereka untuk informasi tentang kerentanan dalam versi ini. Mereka juga mencoba mendeteksi kesalahan konfigurasi seperti kata sandi default atau akses data terbuka, sandi SSL yang lemah, dll.
Pemindai aplikasi web (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP, dll.) juga dapat mengidentifikasi komponen yang dikenal dan versinya (misalnya, CMS, kerangka kerja, pustaka JS). Langkah-langkah utama pemindai adalah crawling dan fuzzing.
Selama perayapan, pemindai mengumpulkan informasi tentang antarmuka aplikasi dan parameter HTTP yang ada. Selama fuzzing, data yang bermutasi atau dihasilkan dimasukkan ke dalam semua parameter yang terdeteksi untuk memicu kesalahan dan mendeteksi kerentanan.
Pemindai aplikasi tersebut termasuk dalam kelas DAST dan IAST - Pengujian Keamanan Aplikasi Dinamis dan Interaktif.
Kotak putih
Ada lebih banyak perbedaan dengan pemindaian whitebox.
Sebagai bagian dari proses VM, pemindai (Vulners, Incsecurity Couch, Vuls, Tenable Nessus, dll.) sering kali diberikan akses ke sistem dengan melakukan pemindaian yang diautentikasi. Dengan demikian, pemindai dapat mengunduh versi paket yang terinstal dan parameter konfigurasi langsung dari sistem, tanpa menebaknya dari spanduk layanan jaringan.
Pemindaian lebih akurat dan lengkap.
Jika kita berbicara tentang pemindaian whitebox (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs, dll.) aplikasi, maka kita biasanya berbicara tentang analisis kode statis dan penggunaan alat yang sesuai dari kelas SAST - Pengujian Keamanan Aplikasi Statis.
Masalah
Ada banyak masalah dengan pemindaian! Saya harus menangani sebagian besar dari mereka secara pribadi sebagai bagian dari penyediaan layanan untuk pemindaian gedung dan proses pengembangan yang aman, serta ketika melakukan pekerjaan analisis keamanan.
Saya akan menyoroti 3 kelompok masalah utama, yang dikonfirmasi oleh percakapan dengan para insinyur dan kepala layanan keamanan informasi di berbagai perusahaan.
Masalah Pemindaian Aplikasi Web
- Kesulitan implementasi. Pemindai perlu diterapkan, dikonfigurasi, disesuaikan untuk setiap aplikasi, mengalokasikan lingkungan pengujian untuk pemindaian, dan diimplementasikan dalam proses CI/CD agar hal ini efektif. Jika tidak, ini akan menjadi prosedur formal yang tidak berguna dan hanya akan menghasilkan hasil positif palsu
- Durasi pemindaian. Bahkan pada tahun 2019, pemindai melakukan pekerjaan yang buruk dalam mendeduplikasi antarmuka dan dapat menghabiskan waktu berhari-hari memindai seribu halaman dengan masing-masing 10 parameter, menganggapnya berbeda, meskipun kode yang sama bertanggung jawab untuk itu. Pada saat yang sama, keputusan penerapan ke produksi dalam siklus pengembangan harus dibuat dengan cepat
- Rekomendasi yang buruk. Pemindai memberikan rekomendasi yang cukup umum, dan pengembang tidak selalu dapat dengan cepat memahami cara mengurangi tingkat risiko, dan yang paling penting, apakah ini perlu dilakukan sekarang, atau belum menakutkan.
- Dampak destruktif pada aplikasi. Pemindai mungkin melakukan serangan DoS pada suatu aplikasi, dan juga dapat membuat entitas dalam jumlah besar atau mengubah entitas yang sudah ada (misalnya, membuat puluhan ribu komentar di blog), jadi Anda tidak boleh meluncurkan pemindaian dalam produksi tanpa berpikir panjang
- Kualitas deteksi kerentanan yang rendah. Pemindai biasanya menggunakan rangkaian muatan tetap dan dapat dengan mudah melewatkan kerentanan yang tidak sesuai dengan skenario perilaku aplikasi yang diketahui.
- Pemindai tidak memahami fungsi aplikasi. Pemindai itu sendiri tidak mengetahui apa itu “Internet banking”, “pembayaran”, “komentar”. Bagi mereka, yang ada hanyalah tautan dan parameter, sehingga lapisan besar kemungkinan kerentanan logika bisnis tetap terbuka sepenuhnya; mereka tidak akan berpikir untuk melakukan penghapusan ganda, memata-matai data orang lain dengan ID, atau meningkatkan saldo melalui pembulatan
- Pemindai tidak memahami semantik halaman. Pemindai tidak dapat membaca FAQ, tidak dapat mengenali captcha, dan tidak dapat mengetahui cara mendaftar lalu masuk kembali, tidak dapat mengeklik “logout”, dan cara menandatangani permintaan saat mengubah parameter nilai-nilai. Akibatnya, sebagian besar aplikasi mungkin tidak dipindai sama sekali.
Masalah saat memindai kode sumber
- Positif palsu. Analisis statis adalah tugas kompleks yang melibatkan banyak trade-off. Akurasi sering kali harus dikorbankan, dan bahkan pemindai perusahaan yang mahal pun menghasilkan positif palsu dalam jumlah besar
- Kesulitan implementasi. Untuk meningkatkan keakuratan dan kelengkapan analisis statis, aturan pemindaian perlu disempurnakan, dan penulisan aturan ini bisa jadi terlalu memakan waktu. Terkadang lebih mudah untuk menemukan semua tempat dalam kode yang memiliki beberapa jenis bug dan memperbaikinya daripada menulis aturan untuk mendeteksi kasus seperti itu
- Kurangnya dukungan ketergantungan. Proyek besar bergantung pada sejumlah besar perpustakaan dan kerangka kerja yang memperluas kemampuan bahasa pemrograman. Jika basis pengetahuan pemindai tidak memiliki informasi tentang "tenggelam" dalam kerangka kerja ini, itu akan menjadi titik buta dan pemindai bahkan tidak akan memahami kodenya.
- Durasi pemindaian. Menemukan kerentanan dalam kode adalah tugas yang kompleks dalam hal algoritma. Oleh karena itu, prosesnya mungkin memakan waktu lama dan memerlukan sumber daya komputasi yang besar.
- Cakupan rendah. Terlepas dari konsumsi sumber daya dan waktu pemindaian, pengembang alat SAST masih harus berkompromi dan menganalisis tidak semua status di mana program tersebut mungkin berada.
- Reproduksibilitas temuan. Menunjuk ke jalur tertentu dan tumpukan panggilan yang mengarah ke kerentanan adalah hal yang bagus, namun kenyataannya, seringkali pemindai tidak memberikan informasi yang cukup untuk memeriksa keberadaan kerentanan dari luar. Lagi pula, kelemahannya mungkin juga terletak pada kode mati, yang tidak dapat dijangkau oleh penyerang
Masalah pemindaian infrastruktur
- Persediaan tidak mencukupi. Dalam infrastruktur yang besar, khususnya yang terpisah secara geografis, seringkali merupakan hal yang paling sulit untuk mengetahui host mana yang harus dipindai. Dengan kata lain, tugas pemindaian berkaitan erat dengan tugas manajemen aset
- Prioritas yang buruk. Pemindai jaringan sering kali memberikan banyak hasil dengan kelemahan yang tidak dapat dieksploitasi dalam praktiknya, namun secara formal tingkat risikonya tinggi. Konsumen menerima laporan yang sulit diinterpretasikan, dan tidak jelas apa yang perlu diperbaiki terlebih dahulu.
- Rekomendasi yang buruk. Basis pengetahuan pemindai seringkali hanya berisi informasi yang sangat umum tentang kerentanan dan cara memperbaikinya, sehingga admin harus mempersenjatai diri dengan Google. Situasinya sedikit lebih baik dengan pemindai whitebox, yang dapat mengeluarkan perintah khusus untuk memperbaikinya
- Buatan tangan. Infrastruktur dapat memiliki banyak node, yang berarti berpotensi memiliki banyak kelemahan, yang laporannya harus diurai dan dianalisis secara manual pada setiap iterasi
- Cakupan yang buruk. Kualitas pemindaian infrastruktur secara langsung bergantung pada ukuran basis pengetahuan tentang kerentanan dan versi perangkat lunak. Di mana, , bahkan para pemimpin pasar tidak memiliki basis pengetahuan yang komprehensif, dan database solusi gratis berisi banyak informasi yang tidak dimiliki oleh para pemimpin.
- Masalah dengan penambalan. Seringkali, menambal kerentanan infrastruktur melibatkan pembaruan paket atau perubahan file konfigurasi. Masalah besarnya di sini adalah sistem, terutama sistem lama, dapat berperilaku tidak terduga akibat pembaruan. Pada dasarnya, Anda harus melakukan pengujian integrasi pada infrastruktur langsung dalam produksi.
Pendekatan
Bagaimana itu bisa terjadi?
Saya akan memberi tahu Anda lebih banyak tentang contoh dan cara menangani banyak masalah yang tercantum di bagian berikut, tetapi untuk saat ini saya akan menunjukkan arah utama yang dapat Anda kerjakan:
- Agregasi berbagai alat pemindaian. Dengan penggunaan beberapa pemindai yang benar, Anda dapat mencapai peningkatan yang signifikan dalam basis pengetahuan dan kualitas deteksi. Anda dapat menemukan lebih banyak kerentanan dibandingkan jumlah total pemindai yang diluncurkan secara terpisah, sekaligus Anda dapat menilai tingkat risiko dengan lebih akurat dan membuat lebih banyak rekomendasi.
- Integrasi SAST dan DAST. Cakupan DAST dan keakuratan SAST dapat ditingkatkan dengan bertukar informasi di antara keduanya. Dari sumbernya Anda bisa mendapatkan informasi tentang rute yang ada, dan menggunakan DAST Anda bisa memeriksa apakah kerentanan terlihat dari luar
- Pembelajaran Mesin™. Pada tahun 2015 I (dan ) tentang penggunaan statistik untuk memberikan intuisi peretas kepada pemindai dan mempercepatnya. Hal ini jelas merupakan bahan untuk pengembangan analisis keamanan otomatis di masa depan.
- Integrasi IAST dengan autotests dan OpenAPI. Dalam pipeline CI/CD, dimungkinkan untuk membuat proses pemindaian berdasarkan alat yang berfungsi sebagai proksi HTTP dan pengujian fungsional yang bekerja melalui HTTP. Tes dan kontrak OpenAPI/Swagger akan memberikan pemindai informasi yang hilang tentang aliran data dan memungkinkan untuk memindai aplikasi di berbagai status
- Konfigurasi yang benar. Untuk setiap aplikasi dan infrastruktur, Anda perlu membuat profil pemindaian yang sesuai, dengan mempertimbangkan jumlah dan sifat antarmuka serta teknologi yang digunakan
- Kustomisasi pemindai. Seringkali suatu aplikasi tidak dapat dipindai tanpa memodifikasi pemindai. Contohnya adalah gateway pembayaran, di mana setiap permintaan harus ditandatangani. Tanpa menulis konektor ke protokol gateway, pemindai akan membombardir permintaan dengan tanda tangan yang salah tanpa berpikir panjang. Penting juga untuk menulis pemindai khusus untuk jenis cacat tertentu, seperti
- Manajemen risiko. Penggunaan berbagai pemindai dan integrasi dengan sistem eksternal seperti Manajemen Aset dan Manajemen Ancaman akan memungkinkan penggunaan banyak parameter untuk menilai tingkat risiko, sehingga manajemen dapat memperoleh gambaran yang memadai tentang kondisi keamanan pembangunan atau infrastruktur saat ini.
Pantau terus dan mari kita ganggu pemindaian kerentanan!
Sumber: www.habr.com