Isi
- Hanya fakta
- Tanpa Bug, Tanpa Stres - Panduan Langkah Demi Langkah Anda untuk Membuat Perangkat Lunak yang Mengubah Hidup Tanpa Menghancurkan Kehidupan Anda
- Akuntansi untuk Dampak?
- Saatnya Mengubah Sistem?
Sumber: BrianAJackson / iStockphoto
Bawa pulang:
Sudah waktunya untuk mengubah keadaan dengan cara kami berpikir tentang menilai risiko untuk komponen sumber terbuka.
Mengembangkan sebuah sistem untuk menilai seberapa serius komunitas pengembangan perangkat lunak harus mempertimbangkan kerentanan adalah sebuah tantangan, untuk membuatnya lebih ringan. Kode ditulis oleh manusia, dan akan selalu memiliki kekurangan. Pertanyaannya kemudian, jika kita berasumsi bahwa tidak ada yang akan sempurna, apakah cara terbaik kita mengkategorikan komponen sesuai dengan risikonya dengan cara yang memungkinkan kita untuk terus bekerja secara produktif?
Hanya fakta
Meskipun ada banyak pendekatan berbeda yang bisa diambil seseorang dalam mengatasi masalah ini, masing-masing dengan pembenaran yang sah sendiri, metode yang paling umum tampaknya didasarkan pada model kuantitatif.
Di satu sisi, menggunakan pendekatan kuantitatif untuk menilai tingkat keparahan kerentanan dapat berguna karena lebih objektif dan terukur, hanya berdasarkan faktor-faktor yang terkait dengan kerentanan itu sendiri.
Metodologi ini melihat kerusakan seperti apa yang dapat terjadi seandainya kerentanan dieksploitasi, mengingat seberapa luas komponen, pustaka, atau proyek digunakan di seluruh industri perangkat lunak, serta faktor-faktor seperti jenis akses apa yang dapat memberikan penyerang untuk hancurkan malapetaka jika mereka menggunakannya untuk melanggar target mereka. Faktor-faktor seperti potensi eksploitasi yang mudah dapat memainkan peran besar di sini dalam mempengaruhi skor. (Untuk lebih lanjut tentang keamanan, lihat Cybersecurity: Bagaimana Uang Muka Baru Membawa Ancaman Baru - Dan Sebaliknya.)
Jika kita ingin melihat pada level makro, perspektif kuantitatif melihat bagaimana kerentanan dapat melukai kawanan, kurang fokus pada kerusakan yang dapat menimpa perusahaan yang benar-benar terpukul dengan serangan itu.
National Vulnerability Database (NVD), mungkin basis data kerentanan yang paling terkenal, menggunakan pendekatan ini untuk versi 2 dan 3 Sistem Penilaian Kerentanan Umum (CVSS) mereka. Pada halaman mereka menjelaskan metrik mereka untuk mengevaluasi kerentanan, mereka menulis metode mereka yang:
Model kuantitatifnya memastikan pengukuran akurat yang dapat diulang sambil memungkinkan pengguna untuk melihat karakteristik kerentanan mendasar yang digunakan untuk menghasilkan skor. Dengan demikian, CVSS sangat cocok sebagai sistem pengukuran standar untuk industri, organisasi, dan pemerintah yang membutuhkan skor dampak kerentanan yang akurat dan konsisten.
Berdasarkan faktor-faktor kuantitatif yang berperan, NVD kemudian mampu menghasilkan skor keparahan, baik dengan angka pada skala mereka - 1 hingga 10, dengan 10 menjadi yang paling parah - serta kategori RENDAH, MENENGAH dan TINGGI. .
Tanpa Bug, Tanpa Stres - Panduan Langkah Demi Langkah Anda untuk Membuat Perangkat Lunak yang Mengubah Hidup Tanpa Menghancurkan Kehidupan Anda
Anda tidak dapat meningkatkan keterampilan pemrograman Anda ketika tidak ada yang peduli dengan kualitas perangkat lunak.
Akuntansi untuk Dampak?
Namun, NVD tampaknya berusaha untuk tetap jelas tentang apa yang bisa kita sebut sebagai ukuran kualitatif kerentanan, berdasarkan seberapa besar dampak eksploitasi tertentu dalam menyebabkan kerusakan. Agar adil, mereka memasukkan dampak sejauh mereka mengukur dampak kerentanan terhadap sistem, dengan melihat faktor-faktor kerahasiaan, integritas, dan ketersediaan. Ini semua adalah elemen penting untuk dilihat - seperti dengan vektor akses yang lebih mudah diukur, kompleksitas akses, dan otentikasi - tetapi mereka tidak merasa sanggup dengan tugas menghubungkan dampak dunia nyata ketika kerentanan menyebabkan kerugian nyata organisasi.
Ambil contoh, pelanggaran Equifax yang mengekspos informasi yang dapat diidentifikasi secara pribadi dari sekitar 145 juta orang, termasuk perincian SIM mereka, nomor jaminan sosial dan bit lain yang dapat digunakan oleh karakter yang tidak bermoral untuk melakukan operasi penipuan besar-besaran.
Itu adalah kerentanan (CVE-2017-5638) yang ditemukan dalam proyek Apache Struts 2 yang digunakan Equifax di aplikasi web mereka yang memungkinkan para penyerang berjalan di pintu depan dan akhirnya berhasil keluar dengan tangan mereka penuh dengan info pribadi yang menarik .
Sementara NVD dengan tepat memberikan skor keparahan 10 dan TINGGI, keputusan mereka adalah karena penilaian kuantitatif kerusakan potensial dan tidak terpengaruh oleh kerusakan luas yang terjadi kemudian ketika pelanggaran Equifax menjadi publik.
Ini bukan pengawasan oleh NVD, tetapi bagian dari kebijakan yang mereka nyatakan.
NVD menyediakan "skor dasar" CVSS yang mewakili karakteristik bawaan dari setiap kerentanan. Kami saat ini tidak menyediakan "skor sementara" (metrik yang berubah seiring waktu karena peristiwa di luar kerentanan) atau "skor lingkungan" (skor yang disesuaikan untuk mencerminkan dampak kerentanan pada organisasi Anda).
Bagi para pembuat keputusan, sistem pengukuran kuantitatif seharusnya tidak terlalu penting karena ia melihat peluang bahwa ia akan menyebarkan bahaya ke seluruh industri. Jika Anda CSO sebuah bank, Anda harus khawatir dengan dampak kualitatif yang dapat dimiliki oleh eksploit jika digunakan untuk kabur dengan data pelanggan Anda, atau lebih buruk lagi, uang mereka. (Pelajari tentang berbagai jenis kerentanan dalam The 5 Threats Threats In Tech.)
Saatnya Mengubah Sistem?
Jadi seandainya kerentanan di Apache Strusts 2 yang digunakan dalam kasus Equifax menerima peringkat yang lebih tinggi mengingat seberapa luas kerusakan yang terjadi, atau akan membuat perubahan menjadi terlalu subyektif untuk sistem seperti NVD untuk teruskan?
Kami mengabulkan bahwa memunculkan data yang diperlukan untuk menghasilkan "skor lingkungan" atau "skor temporal" seperti yang dijelaskan oleh NVD akan sangat sulit, membuka manajer tim CVSS gratis hingga kritik tanpa akhir dan satu ton pekerjaan untuk NVD dan lainnya untuk memperbarui basis data mereka ketika informasi baru keluar.
Ada, tentu saja, pertanyaan tentang bagaimana skor semacam itu akan dikompilasi, karena sangat sedikit organisasi cenderung menawarkan data yang diperlukan tentang dampak pelanggaran kecuali mereka diharuskan oleh undang-undang pengungkapan. Kita telah melihat dari kasus Uber bahwa perusahaan-perusahaan bersedia membayar dengan cepat dengan harapan menjaga informasi di sekitar pelanggaran agar tidak sampai ke pers jika tidak ada reaksi publik.
Mungkin yang diperlukan adalah sistem baru yang bisa menggabungkan upaya baik dari database kerentanan, dan menambahkan skor tambahan mereka sendiri ketika informasi tersedia.
Mengapa menghasut lapisan penilaian tambahan ini ketika yang sebelumnya tampaknya telah melakukan tugasnya dengan cukup baik selama ini?
Terus terang, tanggung jawab organisasi adalah untuk bertanggung jawab atas aplikasi mereka. Dalam dunia yang ideal, semua orang akan memeriksa skor komponen yang mereka gunakan dalam produk mereka sebelum menambahkannya ke inventaris mereka, menerima peringatan ketika kerentanan baru ditemukan dalam proyek yang sebelumnya dianggap aman, dan menerapkan tambalan yang diperlukan semua pada mereka sendiri .
Mungkin jika ada daftar yang menunjukkan seberapa dahsyatnya kerentanan ini bagi sebuah organisasi, maka organisasi mungkin merasa lebih banyak tekanan untuk tidak terjebak dengan komponen yang berisiko. Paling tidak, mereka mungkin mengambil langkah-langkah untuk mengambil inventaris nyata dari perpustakaan open-source mana yang sudah mereka miliki.
Sebagai akibat dari kegagalan Equifax, lebih dari satu eksekutif C-level cenderung berebut untuk memastikan bahwa mereka tidak memiliki versi Struts yang rentan dalam produk mereka. Sangat disayangkan bahwa butuh insiden sebesar ini untuk mendorong industri untuk mengambil keamanan open-source mereka dengan serius.
Semoga pelajaran bahwa kerentanan dalam komponen open-source aplikasi Anda dapat memiliki konsekuensi yang sangat nyata akan berdampak pada bagaimana pembuat keputusan memprioritaskan keamanan, memilih alat yang tepat untuk menjaga produk dan data pelanggan mereka aman.