Kerentanan Log4j Tetap Ada — Apakah Anda Siap?

Kerentanan Log4j Tetap Ada — Apakah Anda Siap?

Kerentanan Log4j Akan Tetap Ada — Apakah Anda Siap? Kecerdasan Data PlatoBlockchain. Pencarian Vertikal. Ai.

Kerentanan luas yang pertama kali muncul di Apache Log4j pada tahun 2021 akan terus dieksploitasi, bahkan berpotensi dengan cara yang lebih buruk dari yang pernah kita lihat hingga saat ini. Aspek yang lebih mengkhawatirkan dari ancaman-ancaman ini adalah bahwa ada kemungkinan besar mereka akan terus dieksploitasi berbulan-bulan atau bertahun-tahun ke depan.

Papan Tinjauan Keselamatan Cyber ​​Departemen Keamanan Dalam Negeri memulai debutnya pada tahun 2021, dan pada tahun 2022 merilisnya laporan keselamatan perdana (PDF). Di dalamnya, dewan menyebut Log4j sebagai "kerentanan endemik", terutama karena tidak ada "daftar pelanggan" yang komprehensif untuk Log4j, membuat menjaga kerentanan menjadi tugas yang hampir mustahil. Satu departemen Kabinet federal bahkan menghabiskan 33,000 jam untuk tanggapan Log4j-nya.

Dan banyak organisasi dan solusi keamanan di pasar gagal mengidentifikasi perbedaan antara eksploitasi dan kerentanan — meninggalkan peluang bagi penyerang untuk melakukan aktivitas jahat.

Eksploitasi vs. Kerentanan

Salah satu masalah utama keamanan siber saat ini adalah memahami perbedaan antara kerentanan dan tingkat keparahannya. Ketika datang untuk mengukur exploitability versus kerentanan, ada perbedaan besar antara apakah ancaman keamanan dapat dieksploitasi dalam bisnis Anda atau jika itu hanya "rentan" dan tidak dapat menghambat bisnis atau mencapai aset penting. Tim keamanan menghabiskan terlalu banyak waktu untuk tidak memahami perbedaan antara keduanya dan memperbaiki setiap kerentanan saat datang, alih-alih memprioritaskan yang dapat dieksploitasi.

Setiap perusahaan memiliki ribuan kerentanan dan paparan umum (CVE), banyak di antaranya mendapat skor tinggi pada Sistem Penilaian Kerentanan Umum (CVSS), jadi tidak mungkin untuk memperbaiki semuanya. Untuk mengatasi hal ini, harapannya adalah alat manajemen kerentanan berbasis risiko (RBVM) akan melakukannya membuat prioritas lebih mudah dengan mengklarifikasi apa yang dapat dieksploitasi.

Namun, pendekatan prioritas keamanan yang menggabungkan skor CVSS dengan intel ancaman RBVM tidak memberikan hasil yang optimal. Bahkan setelah memfilter dan hanya melihat apa yang dapat dieksploitasi di alam liar, tim keamanan masih harus menangani terlalu banyak karena daftarnya panjang dan tidak dapat dikelola. Dan hanya karena CVE tidak memiliki exploit hari ini tidak berarti bahwa CVE tidak akan memilikinya minggu depan.

Sebagai tanggapan, perusahaan telah menambahkan AI risiko prediktif, yang dapat membantu pengguna memahami jika CVE dapat dieksploitasi di masa mendatang. Ini masih belum cukup dan menyebabkan terlalu banyak masalah untuk diperbaiki. Ribuan kerentanan masih akan terbukti dapat dieksploitasi, tetapi banyak yang akan memiliki serangkaian kondisi lain yang harus dipenuhi untuk benar-benar mengeksploitasi masalah tersebut.

Misalnya, dengan Log4j, parameter berikut perlu diidentifikasi:

  • Apakah perpustakaan Log4j yang rentan ada?
  • Apakah ini dimuat oleh aplikasi Java yang sedang berjalan?
  • Apakah pencarian JNDI diaktifkan?
  • Apakah Java mendengarkan koneksi jarak jauh, dan apakah ada koneksi untuk mesin lain?

Jika kondisi dan parameter tidak terpenuhi, kerentanan tidak kritis dan tidak perlu diprioritaskan. Dan bahkan jika kerentanan dapat dieksploitasi pada mesin, lalu apa? Apakah mesin itu sangat kritis, atau mungkin tidak terhubung ke aset penting atau sensitif apa pun?

Mungkin juga mesin itu tidak penting namun dapat memungkinkan penyerang untuk terus menuju aset penting dengan cara yang lebih tersembunyi. Dengan kata lain, konteks adalah kuncinya — apakah kerentanan ini berada pada jalur serangan potensial ke aset kritis? Apakah cukup memotong kerentanan di chokepoint (persimpangan beberapa jalur serangan) untuk menghentikan jalur serangan mencapai aset kritis?

Tim keamanan membenci proses kerentanan dan solusinya, karena ada semakin banyak kerentanan — tidak ada yang dapat sepenuhnya membersihkan papan tulis. Tapi jika mereka bisa fokus pada apa yang bisa dibuat kerusakan ke aset kritis, mereka dapat memiliki pemahaman yang lebih baik tentang dari mana harus memulai.

Memerangi Kerentanan Log4j

Kabar baiknya adalah bahwa manajemen kerentanan yang tepat dapat membantu mengurangi dan memperbaiki paparan serangan yang berpusat pada Log4j dengan mengidentifikasi di mana ada risiko potensi eksploitasi.

Manajemen kerentanan merupakan aspek penting keamanan siber dan diperlukan untuk memastikan keamanan dan integritas sistem dan data. Namun, ini bukanlah proses yang sempurna dan kerentanan masih dapat hadir dalam sistem meskipun telah dilakukan upaya terbaik untuk mengidentifikasi dan memitigasinya. Penting untuk secara teratur meninjau dan memperbarui proses dan strategi manajemen kerentanan untuk memastikan bahwa mereka efektif dan kerentanan ditangani tepat waktu.

Fokus pengelolaan kerentanan seharusnya tidak hanya pada kerentanan itu sendiri, tetapi juga pada potensi risiko eksploitasi. Penting untuk mengidentifikasi titik-titik di mana penyerang mungkin mendapatkan akses ke jaringan, serta jalur yang mungkin mereka ambil untuk membahayakan aset penting. Cara yang paling efisien dan hemat biaya untuk mengurangi risiko kerentanan tertentu adalah dengan mengidentifikasi hubungan antara kerentanan, kesalahan konfigurasi, dan perilaku pengguna yang dapat dimanfaatkan oleh penyerang, dan secara proaktif mengatasi masalah ini sebelum kerentanan dieksploitasi. Ini dapat membantu untuk mengganggu serangan dan mencegah kerusakan pada sistem.

Anda juga harus melakukan hal berikut:

  • Tambalan: Identifikasi semua produk Anda yang rentan terhadap Log4j. Ini dapat dilakukan secara manual atau dengan menggunakan pemindai sumber terbuka. Jika tambalan yang relevan dirilis untuk salah satu produk Anda yang rentan, tambal sistem secepatnya.
  • Solusi: Pada Log4j versi 2.10.0 dan yang lebih baru, di baris CMD Java, setel berikut ini: log4j2.formatMsgNoLookups=true
  • Blokir: Jika memungkinkan, tambahkan aturan ke firewall aplikasi Web Anda untuk memblokir: "jndi:"

Keamanan yang sempurna adalah prestasi yang tidak dapat diraih, jadi tidak masuk akal menjadikan kesempurnaan sebagai musuh kebaikan. Alih-alih, fokuslah untuk memprioritaskan dan mengunci jalur serangan potensial yang terus meningkatkan postur keamanan. Mengidentifikasi dan bersikap realistis tentang apa yang sebenarnya rentan versus apa yang dapat dieksploitasi dapat membantu melakukan hal ini, karena akan memungkinkan kemampuan menyalurkan sumber daya secara strategis ke area kritis yang paling penting.

Stempel Waktu:

Lebih dari Bacaan gelap