Sekarang semakin banyak orang berbicara tentang analisis statis untuk mencari kerentanan sebagai tahap pengembangan yang diperlukan. Namun, banyak yang membicarakan masalah analisis statis. Kami banyak berbicara tentang hal ini pada
Positive Hack Days di masa lalu, dan berdasarkan hasil diskusi ini,
kami telah menulis tentang cara kerja penganalisa statis. Jika Anda mencoba alat yang serius, Anda mungkin takut dengan laporan panjang dengan rekomendasi yang membingungkan, kesulitan dalam menyiapkan alat dan positif palsu. Jadi, apakah analisis statis masih diperlukan?
Pengalaman kami menunjukkan apa yang dibutuhkan. Dan banyak masalah yang muncul saat pertama kali melihat alat ini, sangat mungkin untuk dipecahkan. Saya akan mencoba memberi tahu Anda apa yang dapat dilakukan pengguna dan seperti apa penganalisa itu sehingga penggunaannya bermanfaat, dan tidak memperkenalkan "alat lain yang tidak perlu yang dibutuhkan oleh petugas keamanan."
Tentang analisis statis
Jadi, kita sudah bicara tentang keterbatasan teoritis analisis statis. Sebagai contoh, analisis statis yang mendalam mencoba untuk memecahkan masalah yang eksponensial dalam kompleksitas. Oleh karena itu, setiap alat mencari kompromi antara waktu yang dibutuhkan, sumber daya yang dikeluarkan, jumlah kerentanan yang ditemukan, dan jumlah positif palsu.
Mengapa kita perlu analisis mendalam? Setiap IDE sangat cepat menemukan kesalahan, kadang-kadang bahkan yang berhubungan dengan keamanan - apa masalah yang umumnya bersifat eksponensial? Contoh klasik adalah injeksi SQL (dan injeksi lainnya, seperti XSS, RCE dan sejenisnya), yang melewati beberapa fungsi (yaitu, membaca data dari pengguna dan menjalankan kueri terjadi dalam fungsi yang berbeda). Pencariannya memerlukan analisis antar-proses dari aliran data, dan ini adalah tugas kompleksitas eksponensial. Setuju, tanpa mencari kerentanan semacam itu, analisis tidak dapat dianggap mendalam. Untuk alasan yang sama, Anda perlu menganalisis kode secara keseluruhan, dan bukan di bagian - jika tidak, kerentanan antar-prosedur dapat terlewatkan.
Dalam beberapa tahun terakhir, saya telah memperoleh banyak pengalaman dalam berkomunikasi dengan pelanggan (potensial) dari berbagai analisa statis. Secara khusus, kami membahas klaim untuk alat berdasarkan hasil penggunaan pertama (pilot). Sebagian besar klaim mengikuti satu atau lain cara dari keterbatasan teoritis teknologi. Selain itu, alat mungkin tidak memiliki fungsionalitas yang dibutuhkan pengguna. Namun, menurut pendapat saya, alat analisis dapat bergerak (dan bergerak) ke arah pengguna dalam hal memecahkan masalah yang ditunjukkan di bawah ini. Tetapi Anda juga harus dapat menggunakan analisis, meratakan konsekuensi dari masalah yang sama - ternyata, ini tidak begitu sulit. Mari kita mulai.
Anda dapat membayangkan situasi model: Anda memutuskan untuk mencoba teknologi dalam aksi atau memilih penganalisa statis - membelanjakan seorang pilot. Tentu saja, Anda tidak mempercayai kasus uji vendor dan ingin mencoba menganalisis kode Anda (pada saat yang sama Anda dapat menemukan kerentanan nyata dan memperbaikinya). Anda diberi penginstal atau mesin virtual jadi dengan sistem untuk waktu yang singkat.
Jalankan analisis
Pertama, Anda perlu menjalankan analisis. Anda pergi ke antarmuka, dan semuanya tampak jelas: unggah arsip dengan kode sumber ke dalam formulir dan klik "analisis". Tapi tidak: Anda mendapatkan beberapa formulir dengan bidang berbeda yang perlu diisi, entah bagaimana. Penting untuk menentukan bahasa pemrograman, beberapa pengaturan analisa, pilih paket kerentanan (bagaimana Anda tahu apa yang termasuk di dalamnya?) Dan seterusnya. Anda lulus tes ini, dan analisis dimulai. Ah, tidak - kesalahan pindai. "Format tidak memenuhi persyaratan", "Perakitan kode diperlukan untuk bahasa ini", "File untuk pemindaian tidak ditemukan" ... Jika Anda tidak menulis kode ini sendiri, Anda masih harus pergi ke pengembang untuk meminta bantuan.
Pengembang menyerahkan kode sumber untuk pengujianPerhatian khusus diberikan pada persyaratan untuk kode bangunan. Sebagian besar analisis untuk sejumlah bahasa mengharuskan kode dikumpulkan selama analisis (bahasa JVM - Java, Scala, Kotlin dan sejenisnya, C / C ++, Objective-C, C #). Anda memahami betapa menyakitkannya: untuk mereproduksi lingkungan proyek besar untuk perakitan pada mesin baru. Di sisi lain, persyaratan ini dibenarkan, mereka mengikuti dari teknologi analisis dan spesifik bahasa ini.
Bagaimana penganalisa menyelesaikan masalah ini? Pertama, mereka membuat peluncuran analisis seotomatis mungkin. Idealnya, cukup mengunduh file dalam format apa pun, dan penganalisa itu sendiri harus memahami bahasa apa yang ada di sana, cara mencoba membangun dan cara mengatur sisa pengaturan secara default sehingga hasilnya selengkap mungkin. Jelas bahwa tidak mungkin untuk meramalkan segalanya - namun, Anda dapat mencoba menangani sebagian besar kasus.
Persyaratan perakitan harus dibuat selembut mungkin. Misalnya, untuk bahasa JVM, Anda tidak perlu meminta perakitan selama analisis - cukup minta memuat artefak, yaitu kode yang dirangkai bersama dengan sumbernya (yang jauh lebih sederhana). Untuk Xcode, dalam kasus Objective-C, perakitan dapat diotomatisasi untuk sebagian besar kasus. Jika tidak mungkin untuk mengumpulkan kode, analis dapat mencoba melakukan analisis parsial. Hasilnya tidak akan begitu lengkap, tetapi lebih baik daripada tidak ada hasilnya sama sekali. Juga nyaman jika modul analisis dapat diletakkan di mesin ke pengembang, di mana perakitan kode sudah dikonfigurasi, sementara arsitektur harus memungkinkan modul lain dan bagian antarmuka ditransfer ke mesin lain.
Akhirnya, penganalisa harus mengajukan persyaratan format paling lunak dan menangani file input itu sendiri. Arsip dengan kode sumber, arsip bersarang, arsip dari repositori, tautan ke repositori, arsip dari suatu produk, file yang dapat dieksekusi dari suatu produk - ada baiknya jika analisator mendukung semua ini.
Namun, jangan lupa bahwa penganalisa tidak memiliki kecerdasan buatan dan tidak dapat melihat semuanya. Karena itu, jika kesalahan terjadi, Anda harus membiasakan diri dengan manual - ada banyak hal berguna dalam mempersiapkan kode untuk analisis. Nah, semua pekerjaan meluncurkan pemindaian selama implementasi analisa dilakukan hanya sekali untuk setiap basis kode. Paling sering, penganalisis umumnya diintegrasikan ke dalam siklus CI, yaitu, tidak akan ada masalah dengan perakitan.
Proses analisis
Oke, pemindaian telah dimulai. Satu jam berlalu - tidak ada hasil. Bilah kemajuan tergantung di suatu tempat di tengah, tidak jelas dengan persentase dan perkiraan apa yang selesai. Jam kedua berlalu - kemajuan telah bergerak 99 persen dan telah bertahan di sana selama setengah jam. Jam ketiga berlalu dan penganalisa lumpuh, melaporkan kekurangan RAM. Atau menggantung satu jam lagi dan berakhir. Anda dapat mengharapkan analisis untuk lulus pada kecepatan yang sama dengan checkstyle Anda, dan di sini harapan akan sangat berbeda dari kenyataan.
Ya, penganalisa statis yang baik dapat menghabiskan banyak sumber daya, saya tunjukkan salah satu alasan di atas: menemukan kerentanan yang kompleks adalah tugas yang sulit secara eksponensial. Jadi semakin banyak sumber daya dan semakin banyak waktu, hasil yang lebih baik akan (dengan mesin yang bagus, tentu saja). Sangat sulit untuk memprediksi waktu analisis dan sumber daya yang diperlukan - waktu pengoperasian algoritma analisis statis sangat tergantung pada konstruksi bahasa, kompleksitas kode, pada kedalaman panggilan - karakteristik yang sulit untuk dihitung sebelumnya.
Masalah dengan sumber daya adalah kejahatan yang perlu. Anda harus berhati-hati dalam mengalokasikan sumber daya yang diperlukan, dengan sabar menunggu pemindaian selesai, dan juga memahami bahwa tidak ada yang dapat secara akurat memprediksi sumber daya yang diperlukan untuk penganalisa, bahkan dengan basis kode yang diberikan, dan Anda harus siap untuk mengubah parameter ini. Selain itu, parameter yang diperlukan dapat berubah bahkan tanpa memperbarui basis kode - karena pembaruan analisa.
Namun demikian, penganalisa dapat sedikit membantu dengan masalah ini. Ia mampu memisahkan bagian sumber daya intensif (mesin) dan antarmuka menjadi mesin yang berbeda. Ini akan memungkinkan Anda untuk tidak memuat mesin dengan program yang tidak perlu yang akan memperlambat pekerjaan mereka, sementara itu mungkin untuk menggunakan antarmuka sistem untuk setiap beban kerja pada pemindaian (misalnya, untuk melihat dan mengedit hasil). Ini juga akan membuatnya mudah untuk skala tanpa menginstal ulang seluruh sistem (kami meningkatkan analisa pada mesin virtual baru, tentukan IP mesin utama - dan voila).
Selain itu, penganalisa dapat memungkinkan Anda untuk memilih kedalaman analisis, menonaktifkan pemeriksaan berat, menggunakan analisis tambahan (di mana tidak semua kode diperiksa, tetapi hanya diubah). Hal-hal ini harus digunakan dengan sangat hati-hati, karena dapat sangat mempengaruhi hasil pemindaian. Jika Anda menggunakan fungsionalitas seperti itu, disarankan untuk melakukan analisis penuh pada beberapa interval.
Hasil analisis
Mari kita beralih ke hasil pemindaian (untuk waktu yang lama kita pergi ke mereka). Anda menunggu sejumlah kerentanan di jendela penganalisa dengan gentar, dan Anda sangat terkejut melihatnya. 156 kritis, 1260 sedang, dan rendah 3210. Anda pergi ke halaman hasil dan tenggelam dalam sejumlah masalah yang ditemukan. Anda mengunduh laporan pdf dan Anda melihat beberapa ribu halaman teks. Coba tebak apa yang akan dikatakan pengembang kode ketika dia melihat kanvas seperti itu?
Satpam membawa laporan kerentanan kepada pengembangTapi mari kita tetap mencoba melihat hasilnya, beri dia kesempatan. Setelah memeriksa lusinan kejadian dengan cermat, Anda mulai memahami mengapa ada begitu banyak kerentanan. Beberapa kerentanan benar-benar terlihat serius, Anda memahami bahwa mereka perlu diperbaiki. Namun, segera Anda menemukan sekitar selusin palsu. Dan juga - sejumlah besar kerentanan dalam kode perpustakaan. Anda tidak akan memperbaiki perpustakaan! Dan kemudian Anda mengerti berapa banyak waktu yang Anda habiskan untuk menganalisis hasil. Dan prosedur ini harus diulang setiap hari, minggu, baik, atau setidaknya setiap rilis. (Sebenarnya tidak).
Untuk mulai dengan, positif palsu dapat dipahami dengan cara yang sangat berbeda. Seseorang tidak akan menganggap hanya kerentanan kritis salah yang dapat dieksploitasi saat ini. Seseorang akan menganggap hanya kesalahan eksplisit yang salah dari penganalisa. Banyak tergantung pada apa yang Anda inginkan dari alat ini. Kami menyarankan Anda mempertimbangkan hampir semua kejadian, karena bahkan kerentanan tingkat rendah yang tidak dapat dieksploitasi saat ini dapat berubah menjadi masalah serius besok, misalnya, karena perubahan kode dan kondisi eksternal.
Ok, Anda perlu melihat semua entri, tetapi ini masih banyak pekerjaan. Dan di sini analisanya dapat membantu dengan sangat baik. Fungsi paling penting dari penganalisis adalah kemampuan untuk melacak kerentanan antara pemindaian satu proyek, sementara melacaknya tahan terhadap perubahan kecil yang standar untuk pengembangan kode. Ini menghilangkan masalah yang perlu diulang analisis panjang: pertama kali Anda menghabiskan lebih banyak waktu, menghapus positif palsu dan mengubah kekritisan kejadian, tetapi kemudian Anda hanya perlu melihat kerentanan baru, yang akan beberapa kali lebih kecil.
Bagus, tetapi apakah perlu untuk meninjau semua kerentanan untuk pertama kalinya? Kami merekomendasikan melakukan ini, tetapi secara umum, ini tidak perlu. Pertama, alat analisis memungkinkan Anda untuk menyaring hasil berdasarkan direktori dan file: misalnya, ketika Anda memulai pemindaian, Anda dapat langsung mengecualikan komponen, pustaka, kode uji apa pun dari analisis. Ini akan mempengaruhi kecepatan analisis. Kedua, penganalisa memungkinkan Anda untuk menyaring hasil berdasarkan kerentanan, yaitu, ketika Anda mulai memindai, Anda dapat membatasi sekumpulan kerentanan. Akhirnya, selain kritikalitas, penganalisa dapat menghasilkan sesuatu seperti probabilitas kerentanan palsu (yaitu, kepercayaannya terhadap kerentanan ini). Dengan menggunakan metrik ini, Anda dapat memfilter hasilnya.
Secara terpisah, perlu dicatat teknologi Analisis Komposisi Perangkat Lunak (sekarang mulai didukung oleh semakin banyak instrumen di tingkat yang berbeda). Teknologi ini memungkinkan Anda untuk mendeteksi penggunaan perpustakaan dalam kode Anda, menentukan nama dan versi, menunjukkan kerentanan yang diketahui, serta lisensi. Teknologi ini dapat memisahkan kode perpustakaan dari milik Anda, yang juga dapat menyaring hasil.
Ternyata Anda dapat menangani masalah hasil analisis yang melimpah, dan ini tidak terlalu sulit. Dan meskipun melihat hasil pertama mungkin memang memakan waktu, maka ketika Anda memindai, itu akan menghabiskan lebih sedikit. Namun, saya perhatikan lagi bahwa Anda harus berhati-hati tentang penyaringan hasil - Anda dapat melewati kerentanan. Bahkan jika perpustakaan diketahui, itu tidak berarti bahwa tidak ada kerentanan di dalamnya. Jika sekarang kerentanan ini terdeteksi dengan buruk (yaitu, alat ini menunjukkan banyak kesalahan positif untuk kerentanan ini), dan Anda menonaktifkannya, saat memperbarui penganalisa, Anda dapat melewati kerentanan sebenarnya.
Periksa alat analisa
Dipahami dengan laporan besar dan positif palsu. Tetapi Anda ingin melangkah lebih jauh - untuk memastikan bahwa penganalisa menemukan kerentanan yang Anda tahu pasti (Anda dapat dengan sengaja meletakkannya, atau menemukan alat lain).
Untuk memulainya, penting untuk memahami bahwa penganalisa tidak dapat menemukan kerentanan karena berbagai alasan. Yang paling sederhana adalah pemindaian tidak terkonfigurasi dengan benar (Anda harus memperhatikan pesan kesalahan). Namun dari sudut pandang teknologi analisis, alasannya bisa berbeda. Analisis statis terdiri dari dua komponen penting: mesin (berisi semua kompleksitas algoritmik dan matematika) dan basis aturan pencarian kerentanan. Satu situasi adalah ketika mesin memungkinkan Anda untuk menemukan kerentanan kelas ini, tetapi tidak ada kerentanan di basis aturan. Dalam hal ini, menambahkan aturan biasanya tidak sulit. Situasi yang sama sekali berbeda, jika mesin, pada prinsipnya, tidak mendukung kerentanan seperti itu - di sini revisi bisa sangat signifikan. Saya memberi contoh di awal artikel: Injeksi SQL tidak akan pernah ditemukan tanpa algoritma analisis aliran data.
Penganalisa statis harus menerapkan seperangkat algoritma dalam mesin yang mencakup kelas kerentanan yang tersedia untuk bahasa pemrograman tertentu (analisis aliran kontrol, aliran data, analisis interval, dll.). Poin penting adalah kemampuan untuk menambahkan aturan pencarian kerentanan Anda sendiri ke alat - ini akan menghilangkan alasan pertama hilangnya kerentanan.
Jadi, jika Anda tidak menemukan kerentanan yang ada dalam hasil pemindaian, pertama-tama Anda perlu mencari tahu alasan untuk melewatkan - biasanya vendor dapat membantu dengan ini. Jika alasannya ada di basis aturan atau dalam konfigurasi pemindaian, maka situasinya dapat dengan mudah dihilangkan. Yang paling penting adalah untuk mengevaluasi kedalaman analisis, yaitu, apa, pada prinsipnya, memungkinkan Anda untuk mencari mesin.
Kompetensi
Setelah membaca artikel di tempat ini, kita dapat mengasumsikan bahwa untuk bekerja dengan alat ini, diperlukan keahlian yang mendalam dari pengembang, karena Anda perlu memahami tanggapan mana yang salah dan mana yang benar. Menurut saya, itu semua tergantung pada seberapa ramah instrumen itu berperilaku. Jika ia menyediakan fungsionalitas yang nyaman dan mudah dimengerti, deskripsi kerentanan yang mudah dipahami dengan contoh, tautan, dan rekomendasi dalam berbagai bahasa, jika alat ini menunjukkan jejak kerentanan yang terkait dengan analisis aliran data, Anda tidak perlu memiliki keahlian yang mendalam dari pengembang dengan memahami semua seluk-beluk bahasa pemrograman dan kerangka kerja. Namun, harus ada latar belakang minimal dalam pengembangan untuk membaca kode.
Integrasi dalam proses pengembangan
Di akhir artikel, kami secara singkat menyentuh salah satu masalah paling penting dalam menggunakan alat ini, dan kami akan mempertimbangkannya secara rinci dalam artikel berikut. Misalkan Anda memutuskan untuk menggunakan analisa statis. Namun, Anda memiliki proses pengembangan yang mapan, baik teknologi dan organisasi, dan Anda tidak ingin mengubahnya (tidak ada yang akan memberikannya).
Alat tersebut harus memiliki antarmuka non-grafis penuh (misalnya, CLI atau REST API), yang dengannya Anda dapat mengintegrasikan alat analisis ke dalam proses apa pun. Baik jika penganalisa memiliki integrasi siap pakai dengan berbagai komponen: plug-in untuk IDE atau sistem build, integrasi dengan sistem kontrol versi, plug-in untuk server CI / CD (Jenkins, TeamCity), integrasi dengan sistem manajemen proyek (JIRA), atau bekerja dengan pengguna ( Direktori Aktif).
Integrasi analisis statis ke dalam proses pengembangan (yang disebut SDLC) adalah cara paling efektif untuk menggunakannya jika prosesnya sudah mapan dan semua peserta sepakat dan tahu mengapa ini perlu. Analisis kode yang konstan setelah perubahan atau pembaruan ke penganalisis akan memungkinkan Anda untuk menemukan kerentanan sedini mungkin. Pemisahan peran pengembang dan spesialis keamanan informasi, indikasi yang jelas tentang persyaratan keamanan informasi dan integrasi lunak ke dalam proses saat ini (misalnya, pada awalnya - sifat penasehat sistem) akan memungkinkan Anda untuk menggunakan alat tanpa rasa sakit dan bermanfaat. Namun, belum ada yang membatalkan penggunaan alat secara manual, jika model pengembangan Anda tidak menyiratkan proses serupa.
Ringkasan
Artikel ini berisi rekomendasi dasar untuk mulai menggunakan analisa statis. Penganalisa yang baik bekerja dengan urutan besarnya lebih baik daripada pemeriksa ringan, ia mencari masalah dengan kompleksitas yang berbeda secara fundamental. Oleh karena itu, perlu diperhitungkan dengan fitur analisis statis sebagai teknologi, tetapi pada saat yang sama memilih alat tertentu sehingga fungsinya secara maksimal menghaluskan semua fitur tersebut.