Dengan begitu banyak tim keamanan dan pengembang yang melakukan pemeriksaan mayat pada kegagalan kerentanan keamanan Log4j yang terjadi pada akhir tahun 2021, hanya 10 hari sebelum Natal, pertanyaan utamanya adalah:bagaimana kita menghindari rasa sakit seperti ini di masa depan? Sayangnya, jawabannya adalah … rumit.
Cakupan keamanan yang harus dibaca
Menurut data baru dari (ISC)2, asosiasi profesional keamanan siber bersertifikat nirlaba terbesar di dunia, hampir setengah (48%) tim keamanan siber menyerahkan waktu liburan dan akhir pekan untuk membantu remediasi, dan 52% tim menghabiskan “minggu atau lebih ” memulihkan Log4j. Tidak persis seperti yang diinginkan oleh pengembang yang sudah kewalahan untuk menghabiskan liburan.
Namun, sisi positifnya, rasa sakit dari pengalaman itu telah memicu pemikiran ulang keamanan rantai pasokan perangkat lunak utama dari pengembang dan tim keamanan.
Memperbaiki kerentanan tanpa merusak kode lama
Salah satu aspek yang paling menyusahkan dari Log4j bukanlah kerentanan itu sendiri, tetapi seberapa dalam teknologi tersebut tertanam dalam kode lama. Bagaimanapun, Java adalah salah satu platform paling populer di dunia, dan Log4j adalah sistem logging Java yang sangat populer yang rilis awalnya dimulai sejak tahun 2001. Jadi Log4J tidak hanya menyentuh banyak sistem produksi, tetapi juga banyak warisan kode.
“Tidak ada yang ingin menyentuh kode lama,” kata Sergei Egorov, CEO AtomicJar, startup baru di balik kerangka pengujian integrasi open source, Testcontainers. “Anda tidak hanya perlu memperbaiki kerentanan keamanan, Anda perlu tahu bahwa Anda memperbaiki kerentanan tanpa merusak sistem Anda. Ketika Anda memiliki kerentanan dengan pustaka logging yang sangat populer seperti Log4j, Anda berbicara tentang dependensi pada kode lama yang biasanya tidak memiliki pengujian apa pun, dan terkadang pengembang yang menulis kode dan memahami cara kerjanya bahkan tidak bekerja di perusahaan lagi.”
Menurut Egorov, Log4j sering merupakan ketergantungan transitif dari perpustakaan lain yang perlu diperbarui. Tidak seperti platform yang menyediakan binari statis, dengan sistem Java, penautan kode terjadi saat run-time, jadi tidak ada cara untuk memiliki keyakinan 100% bahwa aplikasi akan berperilaku dengan benar sampai Anda benar-benar menjalankannya dan menguji hubungan waktu nyata antara dependensi dan kompilasi.
Egorov mengatakan Log4j telah mempercepat minat pada platform Testcontainers yang sudah populer, sebagai cara untuk menguji interaksi ini sebelum penyebaran produksi. Dia melihat pengembang yang disengat oleh Log4j sekarang membuat tes integrasi antara sistem dan dependensi eksternal, sehingga saat kerentanan keamanan tiba, pengembang dapat menguji bahwa perbaikan mereka tidak akan menghentikan sistem produksi saat digunakan. Testcontainers menjadi pasangan populer dengan Snyk, karena pengembang bisa mendapatkan permintaan tarik untuk permintaan keamanan otomatis, dan pengujian integrasi memberi mereka keyakinan bahwa mereka dapat menggabungkannya tanpa merusak apa pun.
Mana yang lebih buruk … kerentanan atau mengganggu pengguna?
Munculnya kerentanan keamanan Log4j dan waktunya yang buruk selama musim liburan puncak menciptakan pilihan yang salah bagi tim pengembang—terapkan perbaikan sekarang dan berisiko melumpuhkan sistem selama siklus e-commerce liburan puncak, atau menyepak penyebaran perbaikan ke interval yang kurang berisiko secara komersial ?
Ini adalah keputusan yang tidak mungkin dibuat jika Anda tidak memiliki konteks yang tepat.
“Log4j menyebabkan banyak tim teknik panik karena mereka tidak memiliki cara untuk memprediksi bagaimana perbaikan itu akan memengaruhi pengguna mereka,” kata Marcin Kurc, CEO di startup keandalan perangkat lunak Nobl9, yang pelanggannya termasuk pengecer elektronik besar. “Ada analisis biaya-manfaat yang perlu dilakukan pada setiap perbaikan keamanan. Anda harus menentukan interval yang tepat untuk menerapkan perbaikan, yang memerlukan pemahaman lengkap tentang risiko dalam hal berapa banyak pengguna yang dapat terpengaruh, dan tingkat ketidakandalan yang dapat diterima yang dapat Anda terima.”
Perusahaan Kurc memperjuangkan gerakan yang disebut tujuan tingkat layanan (SLO) yang lahir dari praktik rekayasa keandalan situs Google dan bahwa Nobl9 telah dikomersialkan ke dalam sebuah platform.
SLO memungkinkan pengembang untuk memodelkan waktu aktif dan tingkat keberhasilan di seluruh interaksi perangkat lunak dan untuk menentukan ambang batas untuk hasil pengguna—misalnya, berapa persentase checkout keranjang belanja yang dijalankan dengan benar. Perusahaan yang memodelkan SLO, kata Kurc, dapat berdiskusi secara nyata tentang risiko menambal versus tidak menambal.
Solusi tersebut, bagaimanapun, datang setelah fakta atau, lebih tepatnya, setelah perangkat lunak open source telah ditulis. Tapi apa yang kita lakukan untuk membuatnya lebih aman?
Masalah yang lebih luas:siapa yang memiliki keamanan untuk open source?
Tidak ada yang akan berhenti menggunakan open source. Akan tidak masuk akal untuk membangun solusi logging dari awal, daripada meraih alat seperti Log4j. Pengembang menulis lebih sedikit logika dan mengintegrasikan lebih banyak kerangka kerja, pustaka, dan API akhir-akhir ini, dan itu tidak akan berubah.
Seperti yang ditulis oleh Filippo Valsorda dari Google dalam sebuah posting viral, banyak dari pengelola open source ini “termasuk dalam salah satu dari dua kategori:sukarelawan atau karyawan perusahaan besar. Terkadang keduanya. Tidak ada model yang sehat.”
Log4j menjelaskan fakta bahwa begitu banyak rantai pasokan perangkat lunak modern disangga pada proyek sumber terbuka dengan segelintir pengelola, atau bahkan satu pengelola, yang sering menciptakan teknologi sebagai proyek sampingan. (Dan mari kita perjelas:data terbaru menunjukkan bahwa sebagian besar dari semua perangkat lunak open source ditulis oleh kurang dari 10 orang.)
“Aplikasi modern dibangun dari banyak komponen, banyak di antaranya tidak dikembangkan sendiri tetapi dirakit menggunakan solusi 'off the shelf'," menurut John France, CISO di (ISC)2. “Sebagian besar dari kualifikasi dan identifikasi masalah adalah mengetahui komponen dan pustaka apa yang digunakan oleh perangkat lunak Anda dan menyimpan tagihan bahan perangkat lunak (SBOM).”
Namun menurut salah satu praktisi keamanan anonim dalam jajak pendapat perbaikan Log4 (ISC)2, “Pengembang pada umumnya sangat lemah dalam melacak apa yang mereka gunakan dalam perangkat lunak mereka. Saat kejadian seperti ini mengharuskan kita untuk mengidentifikasi apakah beberapa pustaka atau komponen digunakan oleh kode kita, kurangnya ketertelusuran menjadi titik kesulitan utama. Ini mengubah latihan sederhana untuk memeriksa inventaris dan SBOM menjadi proses pemindaian yang kompleks, dengan banyak peluang untuk positif palsu dan negatif palsu. Jika kami membutuhkan panggilan untuk membangunkan, kami mendapatkan yang besar dengan Log4j.”
Google dan kelas berat lainnya berusaha keras untuk menghadapi tantangan kerentanan keamanan sumber terbuka ini, dan waktu akan membuktikan apakah investasi yang lebih dalam dan kolaborasi vendor dapat membantu mengurangi frekuensi dan penderitaan insiden seperti Log4j. Namun sementara itu, pengembang sedang menyusun strategi untuk menghindari kejutan keamanan yang mengerikan di musim liburan berikutnya.
Pengungkapan:Saya bekerja untuk MongoDB tetapi pandangan ini milik saya sendiri.
Tautan sumber