Panduan mendetail ini membahas tentang mengapa tim keamanan kewalahan dengan kerentanan, bahaya yang tersembunyi di balik pelaporan ganda kerentanan, dan cara mengurangi kerentanan tersebut menggunakan alat patching langsung seperti KernelCare.
Kami tahu bahwa ancaman keamanan siber sedang tumbuh, dengan pertumbuhan yang serasi dalam upaya untuk mencoba dan mengurangi ancaman dan biaya yang terkait. Tetapi bukti menunjukkan bahwa mitigasi tidak berkembang cukup cepat.
Menurut analisis bersama dilakukan oleh McAfee dan Pusat Studi Strategis dan Internasional , 2020 akan melihat biaya global kejahatan dunia maya meningkat melewati $1tn menandai untuk pertama kalinya - peningkatan besar-besaran 50% dari total 2018. Itu adalah tingkat perubahan yang jelas melampaui metrik yang sebanding seperti pertumbuhan PDB, atau pertumbuhan pengeluaran TI.
Kesadaran bukanlah masalahnya - bagaimanapun juga, perusahaan menghabiskan banyak uang untuk mempertahankan diri dari ancaman dunia maya.
Sebaliknya, dalam artikel ini, kami berpendapat bahwa para pemain keamanan siber pada dasarnya kewalahan oleh tantangan yang mereka hadapi. Kami menunjuk pada kejadian baru-baru ini dari pelaporan ganda tentang kerentanan yang diketahui sebagai bukti yang jelas.
Teruslah membaca untuk melihat mengapa tim keamanan kewalahan dengan kerentanan, pengaruhnya terhadap patch, dan apa yang dapat dilakukan tim untuk melakukan patch secara konsisten dalam menghadapi serangan gencar dari kerentanan dan eksploitasi.
Ada lagi kerentanan?
Pada paruh kedua tahun lalu, kerentanan kernel Linux ditemukan, dan dilaporkan. Itu diberi C biasa V kerentanan dan E nomor eksposur (CVE), CVE-2020-29369 , dan kerentanan telah ditambal seperti yang diharapkan. Sejauh ini tidak ada yang aneh.
Tidak ada yang luar biasa tentang kerentanan itu sendiri. Di OS apa pun, kernel harus mengelola memori dengan hati-hati – menetapkan (memetakan) ruang memori saat aplikasi membutuhkannya, dan menghapus alokasi dengan benar dan menetapkan ulang memori kosong saat aplikasi tidak lagi membutuhkannya.
Namun, proses pengelolaan ruang memori ini bisa rawan kesalahan. Ketika dikodekan tanpa perawatan yang diperlukan, proses penanganan memori kernel dapat memberikan peluang bagi penjahat dunia maya. Dalam kasus CVE-2020-29369, masalah terjadi pada fungsi mmap yang digunakan untuk pemetaan memori di Linux.
Sifat kerentanan berarti bahwa dua aplikasi yang berbeda dapat meminta akses ke ruang memori yang sama – yang menyebabkan kerusakan kernel.
Jika penyerang memainkan kartu mereka dengan benar - dengan kata lain, merekayasa exploit - penyerang akan dapat mengambil data yang seharusnya dilindungi oleh kernel. Ini bisa berupa data yang sama sekali tidak berbahaya - atau sesuatu yang lebih berharga, seperti data pribadi atau sandi yang berharga.
Kisah tentang dua laporan kerentanan
Jadi kita dapat melihat bahwa kerentanan khas dilaporkan, dan diterima seperti prosedur biasa. Tapi sesuatu yang membingungkan terjadi selanjutnya.
Hanya beberapa bulan kemudian, kerentanan yang sama dilaporkan. Sekali lagi, nomor CVE dialokasikan, kali ini CVE-2020-20200 . Namun, segera ternyata peringatan kerentanan baru adalah duplikat dari kerentanan lain - CVE-2020-29369.
Para peneliti yang "menemukan" kerentanan untuk kedua kalinya karena suatu alasan atau lainnya gagal menemukan contoh pertama dari kerentanan sebelum meminta reservasi CVE lain untuk apa yang telah mereka temukan. Salah satu tujuan utama dari database CVE adalah untuk menghindari pelaporan ganda, tetapi dalam kasus khusus ini, CVE lain tetap diminta.
Kasus yang disebut “pelaporan ganda” bukan yang pertama atau satu-satunya contoh kerentanan yang dilaporkan dua kali. Lebih buruk lagi, ketika investigasi kerentanan mencapai titik di mana CVE telah ditetapkan, kerentanan tersebut telah ditinjau oleh banyak pakar keamanan yang sangat terlatih.
Bahkan peneliti keamanan dapat mencampurnya
Dalam contoh pelaporan ganda ini, jelas bahwa peneliti keamanan seharusnya mengetahui kerentanan yang ada, atau seharusnya menemukan CVE yang ada jika mereka cukup meneliti kerentanan "baru" sebelum mereka meminta nomor CVE baru.
Ini adalah pemikiran yang mengkhawatirkan. Kerentanan pemetaan memori ini terletak pada inti kernel Linux, namun peneliti keamanan tampaknya tidak menyadarinya, oleh karena itu daftar ganda. Lebih buruk lagi, setiap cantuman tidak terpisah satu dekade atau bahkan bertahun-tahun:masing-masing cantuman dengan kerentanan yang sama dibuat hanya berselang beberapa bulan, satu pada Agustus 2020 dan satu pada November 2020.
Apakah peneliti keamanan lalai? Tidak. Peneliti keamanan benar-benar kewalahan oleh banyaknya tantangan keamanan siber. Itulah sebabnya, dalam contoh ini, pakar keamanan kernel Linux melewatkan laporan yang ada tentang kerentanan yang berpotensi kritis.
Bahaya tersembunyi di balik pelaporan ganda kerentanan
Bukti nyata bahwa ancaman keamanan siber berkembang, dikombinasikan dengan contoh-contoh di mana bahkan pakar keamanan pun salah mengartikannya, menunjukkan bahwa pelaporan ganda memiliki implikasi yang lebih besar daripada yang terlihat pada pandangan pertama.
Ini tidak menunjukkan bahwa pakar keamanan Linux rentan terhadap kesalahan dan kelalaian. Ini hanya menunjukkan bahwa tugas mengelola kerentanan keamanan telah menjadi sangat sulit sehingga bahkan para ahli pun berjuang untuk mengikutinya.
Pertimbangkan sejenak tim teknologi internal yang memiliki tugas komprehensif - ya, termasuk keamanan, tetapi juga mencakup pemeliharaan, pengoperasian, dan tanggung jawab lain yang tak terbatas.
Bahkan jika tim perusahaan memiliki pakar keamanan khusus, kemungkinan besar keahlian tersebut harus diterapkan di berbagai ancaman dan alat teknologi. Akan sangat jarang bahkan bagi perusahaan besar untuk mempekerjakan ahli keamanan kernel Linux. Dan bahkan jika mereka melakukannya, seperti yang telah kita lihat, pakar keamanan ini dapat melakukan kesalahan.
Tim TI menghadapi masa-masa sulit di depan
Tim di tempat akan selalu mengelola kerentanan keamanan sampai tingkat tertentu. Dengan menanggapi berita tentang eksploitasi besar, misalnya, dan menerapkan tambalan yang sesuai. Peringatan dari vendor juga dapat mendorong tindakan, dan sebagian besar departemen TI yang baik akan memiliki beberapa jenis rezim tambalan yang memastikan tambalan diterapkan pada interval yang ditetapkan.
Tetapi bagaimana tim TI dapat secara realistis mengikuti tumpukan CVE yang terus bertambah yang memengaruhi distribusi Linux di seluruh papan, yang masuk setiap hari. Apakah, katakanlah, rezim penambalan triwulanan benar-benar memberikan keamanan yang memadai? Dan ya, menambal itu penting , tetapi haruskah itu mendominasi aktivitas dengan mengorbankan segalanya - yang dapat dengan mudah terjadi mengingat volume tambalan?
Sangat mudah untuk melihat bahwa tim TI akan kesulitan untuk tetap berada di depan daftar kerentanan yang terus bertambah.
Perbaiki rezim patching Anda
Memformalkan rezim patching Anda adalah langkah pertama dalam mencoba mengatasi gunungan CVE. Patch ad-hoc berdasarkan laporan berita yang mengkhawatirkan bukanlah cara yang tepat - ada terlalu banyak kerentanan, dan relatif sedikit yang diketahui secara luas - meninggalkan kerentanan tersembunyi yang tak terhitung jumlahnya dan eksploitasi terkait yang menimbulkan bahaya.
Meskipun demikian, salah satu langkah kunci dalam menciptakan rezim penambalan adalah memprioritaskan tambalan. Kerentanan kritis yang diketahui secara luas harus ditambal dengan cepat - tanpa penundaan, dan mengorbankan ketersediaan jika perlu. Patch untuk kerentanan risiko menengah dan rendah dapat dijadwalkan agar sesuai dengan beban kerja tim teknologi, atau untuk menghindari masalah ketersediaan.
Langkah kunci lainnya adalah membangun inventaris perangkat keras dan perangkat lunak yang cukup lengkap yang memerlukan patching. Beberapa target untuk penambalan akan segera terlihat, tetapi target lainnya dapat dengan mudah terlewatkan.
Dalam membangun inventaris Anda, Anda juga dapat mengidentifikasi beberapa ruang lingkup untuk standardisasi - dengan kata lain, meningkatkan perangkat lunak ke versi yang sama atau menggabungkan vendor untuk mempermudah pengelolaan patch.
Akhirnya, ada baiknya mengkodifikasi rezim penambalan Anda ke dalam kebijakan penambalan formal. Menambal sulit dilakukan secara konsisten, dan yang diperlukan hanyalah satu kegagalan untuk membuka pintu bencana. Rezim patching yang terkodifikasi dapat membantu tim Anda tetap pada jalurnya dengan patching - tahun demi tahun.
Pertukaran dengan patch
Dengan rezim penambalan apa pun biasanya ada trade-off yang harus dibuat antara ketersediaan dan keamanan. Ya, Anda dapat menambal dengan cara yang sangat aman – menerapkan tambalan secepat mereka dirilis. Tetapi patching pasti berdampak pada ketersediaan karena patching sering kali membutuhkan reboot server.
Faktanya, beberapa perusahaan dapat memiliki persyaratan bisnis khusus yang mencegah penghapusan layanan atau server untuk menerapkan patch bahkan jika CVE kritis muncul, yang dapat membuat layanan rentan terhadap eksploitasi baru.
Bahkan di mana Anda dapat membuat server offline untuk pemeliharaan, layanan menurun dan akibatnya, pengalaman pengguna akhir menurun. Bayangkan pengecer online dengan ribuan pelanggan online yang tiba-tiba membuat setengah servernya offline untuk pemeliharaan, misalnya.
Lalu ada juga pengurasan pada tim teknologi yang mau tidak mau mengorbankan waktu yang dihabiskan untuk tugas-tugas lain untuk menghabiskan waktu untuk menambal. Tim keamanan bisa benar-benar kewalahan oleh beban patching. Namun, ada alternatif.
Pertimbangkan alat tambalan otomatis
Kami telah mengidentifikasi dua masalah utama di balik rezim penambalan standar:waktu dan upaya yang diperlukan oleh penambalan, dan gangguan yang terkait dengan penambalan. Salah satu solusi yang layak dipertimbangkan adalah penambalan otomatis - dan terlebih lagi jika itu adalah penambalan otomatis tanpa boot ulang yang menerapkan patch tanpa memerlukan restart server.
Alat tambalan otomatis terus memantau rilis tambalan dan menerapkan tambalan ini secara otomatis tanpa intervensi. Ini menghilangkan kebutuhan untuk mendedikasikan tenaga kerja untuk menambal armada server - penambalan hanya terjadi dengan mulus di latar belakang. Dengan penambalan otomatis, tim teknologi tidak pernah kewalahan dengan tugas penambalan yang tak terhitung jumlahnya, tim teknologi juga tidak perlu mencoba dan memprediksi tambalan mana yang paling penting. Sebagai gantinya, semua patch diterapkan dengan mulus, merata, dan konsisten.
Beberapa alat tambalan otomatis seperti KernelCare dapat menerapkan patch on-the-fly - patching hidup, saat mesin sedang berjalan, dan tanpa memerlukan reboot. Patching langsung membatasi gangguan karena mesin tidak offline untuk memproses patch. Bila ada risiko minimal gangguan, konsistensi patch kemungkinan akan meningkat.
Dengan kata lain, alat tambalan otomatis yang tepat dapat menyelesaikan dua masalah terbesar yang dihadapi perusahaan dengan penambalan:diperlukan upaya, dan gangguan.
Menambal sangat penting, tidak peduli bagaimana Anda memilih untuk melakukannya
Apa pun yang dilakukan perusahaan Anda untuk menutupi dirinya sendiri untuk penambalan atau bagaimanapun Anda mengatur rezim penambalan Anda, satu-satunya kepastian adalah bahwa penambalan itu penting. Patch harus diterapkan, tetapi ada keputusan yang harus dibuat tentang seberapa sering Anda menambal dan bagaimana Anda menambal.
Mengingat besarnya ancaman keamanan siber, ada argumen kuat untuk penambalan otomatis. Tim teknologi dan peneliti keamanan semakin kewalahan dan penambalan otomatis menjembatani masalah sumber daya dan ketersediaan.
Itu selalu merupakan pilihan untuk hanya menerapkan lebih banyak tenaga kerja ke tantangan patching, dan untuk beberapa beban kerja yang mungkin menjadi satu-satunya pilihan. Namun, dalam kebanyakan kasus, patching tanpa booting otomatis dapat memberikan kemenangan besar terhadap tantangan keamanan siber yang sangat besar saat ini.
Bacaan yang disarankan:
- Patch Kernel Linux Raspberry Pi Dengan KernelCare GRATIS!
- Deteksi Pustaka Bersama yang Kedaluwarsa di Memori Dengan UChecker