Penulis: Jonathan Knudsen, Senior Security Strategist, Synopsys Software Integrity Group
Sedikit perubahan pada strategi keamanan aplikasi untuk mengatasi security fatigue dapat membantu mengelola dan meminimalkan risiko pada aplikasi.
Berapa kali dalam sehari Anda mengalami hal ini? Sepuluh kali sehari? 25 kali? Atau 100 kali?
ilustrasi security fatigue
Bahkan sebagai seorang profesional keamanan yang paham hal teknis pun saya tidak tahu pasti apa yang harus saya lakukan. Apa itu What is PC-Doctor? Apa itu SystemIdleCheck.exe? Jika saya mengeklik "No", mungkinkah terjadi hal yang tidak saya inginkan?
Setiap kali ada notifikasi seperti itu, apa yang Anda lakukan? Mungkin Anda akan berkata, sebelum melakukan apapun, Anda membaca notifikasi dengan cermat dan mempertimbangkan berbagai hal yang mungkin terjadi. Anda mungkin juga akan mengatakan bahwa Anda sudah melakukan riset lain untuk memastikan apakah aman jika diteruskan.
Tapi mari kita jujur. Yang terjadi adalah kita kesal karena merasa terganggu, dan segera mengeklik tombol apapun untuk bisa segera melanjutkan apapun yang sedang kita kerjakan.
"Software yang berteriak '(awas) serigala!'". Ini sebuah analogi modern untuk cerita lama tentang penggembala yang sengaja berteriak "(awas) serigala!" untuk mempermainkan teman-temannya, seolah-olah ada serigala yang menyerang. Si anak gembala senang melihat teman-temannya panik.
Namun ketika serigala benar-benar datang, tak ada lagi yang percaya pada si anak gembala. Domba-domba milik si anak gembala pun habis dimangsa serigala. Dan beberapa versi cerita menyebutkan bahwa si anak gembala pun mati diterkam serigala.
Nah, mirip dengan situasi yang dihadapi para developer software. Tapi bedanya, software Anda tidak hanya mendatangkan masalah. Namun mengevaluasi risiko di depan mata kita memang kadang sulit.
Misalnya kita mengunjungi sebuah situs web dan peramban yang kita gunakan meragukan sertifikat situs web tersebut. Apakah ada seseorang yang membajak situs tersebut? Apakah ada sesuatu yang tidak dikonfigurasi dengan benar? Kita tidak mungkin tahu tentang itu. Pilihnya adalah (a) lanjutkan, berharap tidak ada masalah serius nantinya, (b) tidak melakukan apapun, (c) mencoba lagi di lain hari, siapa tahu masalahnya sudah teratasi. Bagi kebanyakan orang, (b) dan (c) bukan pilihan yang bagus. Jadi, pada umumnya kita cenderung mengabaikan peringatan keamanan dan berharap tidak terjadi masalah sesudahnya. Ini yang disebut security fatigue.
Vulnerability Overload
Fenomena serupa pun terjadi di lingkungan keamanan aplikasi. Organisasi development yang baru mengenal software security seringkali memandang keamanan aplikasi dari sisi tool saja. Mereka menjalankan satu atau dua tool untuk mengidentifikasi masalah keamanan, kemudian memperbaikinya di source code. Tim keamanan akan menjalankan sebanyak mungkin tool untuk meminimalkan risiko, dan berharap tim development akan menambal sebanyak mungkin lubang keamanan. Di sisi lain, tim development juga berharap sesedikit mungkin ada gangguan agar aplikasi bisa segera sampai ke tangan pelanggan.
Masalahnya adalah security tools dapat memunculkan terlalu banyak hasil (informasi adanya masalah keamanan). Ketika harus menghadapi begitu banyak laporan tentang kerentanan, tim development sepertinya akan angkat tangan, putus asa, dan akhirnya mengabaikan hasil-hasil yang disampaikan tool keamanan tadi. Inilah yang disebut vulnerability overload.
Buat Prioritas
Masalah besar, seperti pemanasan global atau kekerasan bersenjata, terlihat sulit diselesaikan. Dalam kasus keamanan aplikasi, masalahnya jadi menakutkan. “Jika empat security tool yang berbeda melaporkan 2.377 temuan dan para developer memiliki waktu lima hari untuk menyiapkan aplikasi yang akan dirilis, apa yang harus mereka lakukan?".
Kemajuannya tidak akan banyak karena perubahan tidak dilakukan sekaligus. Temuan dari tool keamanan bisa dibuatkan prioritas dengan berbagai cara. Anda bisa memilah dari sekian banyak isu berdasarkan risiko dan menangani dari yang paling berbahaya.
Anda dapat menggunakan pendekatan yang sama dalam menerapkan keamanan dalam development workflow. Daripada melemparkan semua masalah ke tim development, Anda dapat mengimplementasikan pendekatan berbasis kebijakan sehingga jenis-jenis tertentu temuan keamanan secara otomatis diintegrasikan ke development issue tracker. Jika volume masalahnya masih masuk akal, developer akan beradaptasi dan berupaya meningkatkan keamanan seperti mereka mengatasi isu-isu lainnya.
Developer tidak suka mengulang pekerjaan. Begitu memahami satu kelemahan pada keamanan, kecil kemungkinan mereka akan mengulanginya.
Lakukan Langkah Kecil
Satu alasan mengapa manusia enggan berhadapan dengan tantangan yang berat, mereka menganggap percuma, apapun yang mereka lakukan tidak akan ada bedanya.
Namun satu hal yang pasti, tidak akan ada perubahan jika kita tidak mencoba. Jika Anda ingin meningkatkan keamanan aplikasi, lakukan sesuatu. Mulailah dari mana saja.
Pertimbangkan untuk memasukkan threat modeling ke design process. Jalankan tool static application security testing (SAST), seperti Coverity®, pada source code. Buat komitmen yang bisa dicapai untuk mengatasi masalah keamanan dengan risiko paling besar.
Gunakan tool interactive application security testing (IAST), misalnya Seeker®, pada aplikasi web. Dan buat komitmen yang mudah dicapai untuk menangani masalah keamanan dengan risiko tertinggi.
Integrasikan security tool di issue tracker sehingga masalah keamanan akan ditangani para developer seperti isu-isu lainnya. Jadikan keamanan sebagai bagian dalam keseharian tim development.
Lakukan dari hal kecil, dan tingkatkan secara bertahap. Rayakan kesuksesan dan belajar dari kesalahan.
Keamanan aplikasi tidak dapat dipisahkan dari pengembangan aplikasi. Lakukan secara perlahan dan hati-hati sampai tercapai tingkat risiko yang dibutuhkan aplikasi.