Banyak perusahaan masih belum sepenuhnya menyadari keuntungan menggunakan fuzzing ketika mengembangkan produk perangkat lunak mereka. Tetapi keamanan produk harus sejalan dengan pengembangan. Karena mengoreksi apa yang telah dilakukan adalah padat karya dan jauh lebih mahal daripada melakukan kebaikan dengan segera.
Dan ini terlepas dari kenyataan bahwa konsep seperti Security Development Life Cycle (SDLC), dan yang relatif baru seperti DevSecOps atau SecDevOps, telah muncul di dunia pengembangan untuk waktu yang lama, tetapi tidak semua orang menggunakan teknik ini. Mereka memiliki satu esensi - untuk menerapkan pendekatan untuk meningkatkan keamanan dari tahap pertama pengembangan, dan lebih baik untuk memulai dengan pelatihan karyawan. Dan, tentu saja, penting untuk memperhatikan keamanan produk dari serangan sepanjang siklus hidupnya. Untuk detail - selamat datang di kucing.
Salah satu langkah terpenting dalam pengembangan yang aman adalah fuzzing. Fuzzing adalah teknik pengujian perangkat lunak, yang intinya adalah deteksi otomatis kesalahan implementasi dengan mengirimkan data yang diketahui salah dan menganalisis reaksi program terhadapnya.
Tepat saat menulis artikel di Twitter, catatan berkedip tentang penggunaan fuzzing dari Dmitry Vyukov.
Dia hanya menarik perhatian pada fakta bahwa menggunakan fuzzing Anda dapat mendeteksi sejumlah besar kesalahan dalam kode, yang jika tidak akan hilang bahkan setelah selang waktu.
Biasanya fuzzing menyelesaikan proses pengembangan, tetapi fuzzing juga dapat memisahkan fungsi dari produk yang dikembangkan.
Keuntungan fuzzing dibandingkan metode pengujian lainnya:
- Anda dapat memulai fuzzer dan melupakannya sampai akhir pengujian, dan bekerja dengan hasilnya;
- pengujian otomatis dapat mengidentifikasi kesalahan-kesalahan yang tidak dapat ditemukan dengan pengujian manual, karena cakupan kode yang lebih besar;
- memungkinkan Anda mengumpulkan gagasan umum tentang keamanan kode yang diuji.
Salah satu kasus sensasional ketika fuzzing melakukan perbuatan baiknya adalah penemuan lima puluh CVE dalam Adobe Reader dalam 50 hari. Para peneliti dapat menemukan begitu banyak kerentanan tanpa akses ke kode sumber, dan sulit membayangkan berapa banyak yang akan ditemukan jika mereka memiliki sumbernya.
Jika Anda mencari di sumber terbuka untuk informasi tentang penggunaan fuzzing di antara pengembang, maka Microsoft akan menjadi yang pertama. Perusahaan ini adalah salah satu pelopor fuzzing di SDLC. Mereka memiliki Deteksi Risiko Keamanan , layanan yang memungkinkan pengguna untuk mengunduh file biner untuk fuzzing mereka. Data apa yang akan dimasukkan ke input, pengguna memutuskan. Hasil fuzzer adalah kesalahan yang ditemukan dan data yang menghasilkannya.
Google juga menggunakan fuzzing, dan mereka memiliki banyak alat di domain publik. Yang paling menarik dari mereka adalah OSS-Fuzz . Intinya adalah bahwa siapa pun dapat mengajukan permintaan dengan fuzzer mereka. Biasanya ini adalah fuzzers, pernah dibuat oleh pengembang untuk proyek kecil mereka. Selain fuzzers ini, Google menggunakan ClusterFuzz untuk mendeteksi kesalahan di Chrome. Selama beberapa tahun, lebih dari 16 ribu kerentanan di browser dan lebih dari 11 ribu di 160 proyek sumber terbuka ditemukan.
Beberapa perusahaan yang mengembangkan perangkat lunak menyediakan semua orang dengan majelis malam untuk fuzzing. Begitu juga Mozilla dan VLC . Siapa pun dapat mengunduh perakitan dan mencoba mencari kesalahan dan kerentanan di dalamnya.
Tentu saja, banyak pengembang perangkat lunak berpemilik tentang bagaimana mereka meningkatkan keamanan produk mereka. Tetapi fakta bahwa banyak dari mereka tidak memperhatikan keamanan produk mereka terbukti dalam jumlah kerentanan yang terdeteksi. Oleh karena itu, kami memutuskan untuk melakukan survei sampel pengembang untuk mengetahui sikap mereka terhadap fuzzing.
Kami mengajukan pertanyaan berikut:
Apakah Anda menggunakan fuzzing dalam proses pengembangan produk Anda?
Sepertiga responden menjawab pertanyaan ini secara positif.
Jika tidak menggunakan, lalu mengapa? Atau apa, menurut Anda, biasanya menghentikan Anda dari memasukkan fase fuzzing ke dalam proses pengembangan produk?
Kemungkinan jawaban:
- Tidak ada yang membingungkan
- Keamanan produk bukanlah prioritas
- Tidak ada alat yang cocok
- Tidak ada spesialis yang relevan
- Kurangnya infrastruktur yang tepat
- Lainnya
Responden dapat memilih beberapa alasan untuk menolak menggunakan fuzzing dalam proses pengembangan.
Diagram menunjukkan persentase relevansi alasan penolakan fuzzing dalam proses pengembangan.
Alasan paling umum untuk TIDAK menggunakan fuzzing adalah kurangnya karyawan yang memenuhi syarat di bidang ini. Tetapi tidak selalu perlu memiliki pakar keamanan informasi Anda sendiri, Anda dapat menarik pakar luar yang akan mengaudit produk yang dikembangkan.
Beberapa responden yang memilih opsi jawaban "Lainnya" memberikan jawaban terperinci yang menarik. Berikut adalah beberapa alasan untuk menolak fuzzing:
- departemen keamanan informasi tidak menghargai inisiatif salah satu pengembang untuk menulis fuzzer mereka;
- kurangnya teknik pencarian kerentanan FSTEC.
Di antara jawabannya adalah klarifikasi tentang penggunaan fuzzer dan libfuzzer AFL , yang merupakan kabar baik .
Sebagai pakar keamanan, kami menyarankan Anda untuk tidak mengabaikan pengembangan yang aman, termasuk penggunaan fuzzing, untuk meningkatkan keamanan produk Anda.