Seiring dengan semakin canggihnya serangan siber saat ini, aplikasi perangkat lunak modern menjadi semakin kompleks dan bergantung pada komponen pihak ketiga.
Jarang sekali aplikasi perangkat lunak dibuat dari awal; sebaliknya, mereka dikumpulkan dari lusinan—jika bukan ratusan— perangkat lunak sumber terbuka perpustakaan, modul pihak ketiga, dan komponen komersial.
CISSP, Mitra Pendiri di CIOSO Global.
Software Bill of Materials (SBOM) telah muncul sebagai kebutuhan modern keamanan siber. Namun SBOM sering kali dianggap sebagai pilihan atau diabaikan sama sekali.
Bagi CISO dan pemimpin teknologi, ketidakjelasan rantai pasokan perangkat lunak telah menjadi titik buta. Tidaklah bijaksana untuk mengimplementasikan aplikasi tanpa mengetahui isinya.
SBOM yang komprehensif bukan lagi praktik terbaik; itu adalah persyaratan dasar. Dan hal ini harus dilakukan secara terus-menerus, bukan hanya sekali saja.
Dilema CISO: Risiko yang Diketahui, Ketergantungan yang Tak Terlihat
Setiap elemen yang dimasukkan ke dalam aplikasi berisiko mengungkap potensi kerentanan dalam lingkungan. Masalahnya terletak pada terbatasnya visibilitas terhadap apa yang sebenarnya ada dalam perangkat lunak yang digunakan.
Kerentanan Log4Shell yang terkenal (CVE-2021-44228) pada tahun 2021 adalah kerentanan zero-day yang kritis. Hal ini memengaruhi Apache Log4j, yang merupakan pustaka logging yang banyak digunakan dan tertanam di banyak aplikasi perusahaan.
Kerentanan ini memungkinkan penyerang untuk mengeksekusi kode arbitrer dari jarak jauh pada sistem yang terkena dampak. Ini berasal dari validasi input yang tidak tepat dalam fungsi pencarian Java Naming and Directory Interface (JNDI) Log4j.
Setelah penyakit ini ditemukan, organisasi-organisasi menghabiskan waktu berminggu-minggu, bahkan berbulan-bulan, untuk mencoba menentukan di mana dan bagaimana penyakit tersebut terekspos. Dalam situasi tertentu, SEC mewajibkan perusahaan publik untuk melaporkan dampaknya dalam jangka waktu singkat. Dengan kata lain, SBOM harus segera diciptakan.
Bagi perusahaan terbesar, hal ini hampir merupakan tugas yang mustahil! Kesulitan ini dapat dihindari jika mereka memiliki SBOM yang menyediakan informasi ini, sehingga memungkinkan organisasi untuk mengidentifikasi dan memitigasi paparan dalam hitungan jam, bukan minggu.
Apa Itu SBOM dan Mengapa Itu Penting?
SBOM adalah daftar lengkap seluruh komponen, termasuk perpustakaan, kerangka kerja, dan modul, yang terkandung dalam aplikasi perangkat lunak dan terkandung dalam “tumpukan” perangkat lunak yang diperlukan untuk mengoperasikan aplikasi. Hal ini dapat mencakup sistem operasidriver perangkat, firmware, dll. Ini setara dengan label nutrisi untuk kode.
Jika dilakukan dengan benar, SBOM memberikan tim keamanan:
– Visibilitas lengkap ke dalam ketergantungan langsung dan transitif (tertanam).
– Kemampuan untuk menilai paparan kerentanan yang diketahui dengan cepat.
– Landasan untuk pemantauan risiko dan kepatuhan secara berkelanjutan.
Singkatnya, ini memberi kami tingkat visibilitas yang sama dalam hierarki perangkat lunak yang kami nikmati di titik akhir, server, dan mesin virtual dari alat manajemen aset dan EDR/MDR.
Namun, situasi yang tidak menguntungkan saat ini adalah vendor perangkat lunak menyediakan SBOM yang tidak lengkap atau bahkan tidak menawarkannya sama sekali. Masalah lainnya adalah tim pengembangan internal mungkin kekurangan alat atau disiplin untuk menghasilkan dan memeliharanya.
Kasus untuk Visibilitas Berkelanjutan
SBOM harus diperlakukan sebagai dokumen hidup, diperbarui dengan setiap perubahan kode, rilis baru, atau patch. Pelaku ancaman tidak akan dengan mudah menunggu siklus peninjauan triwulanan berikutnya untuk mengeksploitasi kerentanan yang “tidak terlihat”. Segera setelah CVE baru diterbitkan, inilah saatnya untuk bertindak.
Serangan SolarWinds pada tahun 2020 adalah contoh klasik dari rantai perangkat lunak yang kompleks saat ini. Peretas mengeksploitasi lingkungan build dari vendor perangkat lunak tepercaya, memasukkan kode berbahaya ke dalam pembaruan rutin.
Bahkan organisasi yang dengan setia mengikuti praktik terbaik patching pun menjadi korban ketika pintu belakang ini dibuka ke dalam jaringan mereka. Jika SolarWinds memiliki disiplin SBOM, paparan dapat diidentifikasi lebih awal.
Praktik Terbaik untuk Adopsi SBOM
Bagi organisasi yang ingin membangun rantai pasokan perangkat lunak yang tangguh, berikut adalah rekomendasi utama:
Mandat SBOM dari semua vendor: Memerlukan SBOM yang komprehensif dan dapat dibaca mesin sebagai bagian dari proses penilaian risiko pengadaan dan vendor Anda.
Mandat SBOM dari semua tim pengembangan internal: Memerlukan SBOM yang komprehensif dan dapat dibaca mesin sebagai bagian dari tim arsitektur, desain, dan pengembangan perangkat lunak Anda. Ketahui keseluruhan saluran pipa Anda dari atas ke bawah, luar dan dalam.
Tim Operasi TI harus menjaga visibilitas secara konstan melalui penggunaan alat observasi modern seperti Dynatrace.
Integrasikan alat SBOM ke dalam siklus pengembangan Anda: Manfaatkan alat otomatis seperti Snyk, Endor Labs, atau Scribe Security untuk menghasilkan SBOM selama waktu pembuatan dan melacak perubahan seiring waktu.
Menetapkan tata kelola untuk pemeliharaan SBOM: Tulis kebijakan yang jelas untuk menentukan kepemilikan, memperbarui irama, dan mengintegrasikan dengan alur kerja manajemen kerentanan. Buat program manajemen pengecualian yang terlihat, konsisten, dan dijalankan dengan baik.
Seringkali kerentanan komponen perangkat lunak ditemukan dengan alat yang disebutkan di atas sehingga sulit, mahal, atau tidak nyaman untuk diperbaiki.
Dalam kasus ini, kita dapat memilih untuk “menoleransi” keberadaan kerentanan, namun hal ini harus dikelola melalui proses tata kelola pengecualian dan, jika memungkinkan, mempertahankan serangkaian kontrol yang memberikan kompensasi.
Gunakan SBOM untuk pemindaian kerentanan proaktif: Referensi silang inventaris SBOM Anda dengan database seperti National Vulnerability Database (NVD) untuk mendapatkan wawasan risiko secara real-time. Lakukan ini terus-menerus seperti yang Anda lakukan untuk titik akhir Anda (waktu nyata, sepanjang waktu).
Latih tim Anda: Pastikan bahwa pengembang, DevOpsdan tim keamanan memahami cara membaca, menggunakan, dan memelihara SBOM secara efektif. Yang paling penting, tanamkan disiplin yang sama dalam tim pengembangan kami seperti yang kami terapkan dalam upaya pengelolaan kerentanan titik akhir.
Kenali lingkungan Anda: Mengabaikan celah keamanan ini tidak dapat diterima lagi. Alat dan informasi tersedia untuk menutup kesenjangan ini. Hal ini memerlukan komitmen yang tiada henti dari para pemimpin pengembangan perangkat lunak Anda.
Visibilitas Tidak Dapat Dinegosiasikan
Menjalankan perangkat lunak tanpa SBOM seperti menawarkan undangan terbuka kepada pelaku ancaman. Tanpa SBOM, Anda tidak tahu apa yang Anda jalankan, dan selama Anda melakukan ini, Anda berisiko menjadi aktor ancaman berikutnya di sistem Anda, atau sistem pelanggan Anda. Kerugian akibat tidak adanya tindakan mungkin bukan hanya bersifat finansial—tetapi juga dapat berupa reputasi dan peraturan.
Anda mungkin pernah mendengar bahwa keamanan siber hanya sekuat tautan terlemahnya. Dan jika tautan itu adalah ketergantungan yang terkubur dalam beberapa lapisan, Anda memerlukan SBOM untuk menyadarinya. Masalah keamanan siber dapat diatasi. Kerangka kerjanya ada. Yang sering kali kurang adalah komitmen budaya, pengembangan kebijakan, manajemen pengecualian, dan penegakan hukum.
CISO dan pemimpin pengembangan perangkat lunak harus mengambil inisiatif. SBOM yang komprehensif adalah suatu keharusan; sebuah alat pertahanan yang tidak dapat dimiliki oleh suatu organisasi.
Saatnya sekarang untuk memasukkannya ke dalam kerangka risiko, jalur pengembangan, dan kontrak vendor Anda. Semakin lama Anda menunggu, semakin lama Anda membiarkan diri Anda terkena ancaman yang sebenarnya bisa dicegah.
Kami menampilkan perangkat lunak manajemen patch terbaik.
Artikel ini dibuat sebagai bagian dari saluran Expert Insights TechRadarPro tempat kami menampilkan para pemikir terbaik dan tercemerlang di industri teknologi saat ini. Pandangan yang diungkapkan di sini adalah milik penulis dan belum tentu milik TechRadarPro atau Future plc. Jika Anda tertarik untuk berkontribusi, cari tahu lebih lanjut di sini: https://www.techradar.com/news/submit-your-story-to-techradar-pro
