Pengembangan Software Yang Aman

Kebanyakan vulnerability (lubang kerentanan) keamanan dihasilkan oleh cacat (defect) yang tanpa disengaja ada di dalam software selama disain dan pengembangan. Oleh karena itu, untuk mengurangi vulnerability software, kecacatan dari software harus dikurangi. Saat ini praktek-praktek rekayasa software telah mendorong sejumlah besar kecacatan yang ada di dalam software diperlihatkan. Bagaimanapun, data dari lusinan proyek software di dunia-nyata secara sistematis telah menerapkan pengembangan software dengan mengurangi kecacatan di dalam software yang dilepaskan. Kemajuan penerapan praktek ini juga perlu dilakukan untuk pereduksian cacat karena vulnerability. Institusi/organisasi yang sudah menerapkan praktek ini bisa memperoleh manfaat tambahan berupa berkurangnya waktu siklus dan biaya pengembangan software.
Seiring dengan pengurangan cacat, keamanan harus sangat terintegrasi ke dalam siklus hidup pengembangan software (SDLC) secara penuh. Keamanan harus “ built-in” dalam produk yang sedang dikembangkan, dan tidak hanya “ bolted-on” setelah fakta kecacatan muncul.

1.    Mengelola Cacat Sepanjang Siklus Hidup Pengembangan Software (SDLC)
Cacat yang hadir pada saat software dirilis adalah suatu persentase total dari cacat yang dihadirkan sepanjang siklus hidup pengembangan software. Untuk mengurangi cacat pada saat software dilepaskan, maka cacat harus diatur/dikelola sepanjang SDLC. Manajemen cacat tersebut meliputi pemusnahan cacat dan pengukuran cacat.
Seharusnya ada banyak titik pemusnahan cacat di dalam SDLC. Semakin banyak titik pemusnahan cacat yang ada, maka semakin dekat untuk menemukan permasalahan dengan benar setelah hal itu muncul. Sehingga permasalahan dapat dengan mudah diperbaiki  dan penyebab utama dengan mudah ditentukan dan dituju. Setiap kali cacat dimusnahkan, mereka harus diukur. Tiap-Tiap titik pemusnahan cacat ini adalah menjadi suatu titik pengukuran. Pengukuran cacat adalah sesuatu yang bahkan penting daripada pemusnahan dan pencegahan cacat. Ini bisa membantu dalam SDLC untuk memutuskan apakah terus bergerak ke tahap berikutnya atau berhenti dan mengambil tindakan korektif, dan menandai dimana memperbaiki proses sehingga sesuai dengan tujuan.
Pertanyaan-pertanyan berikut ini harus dipertimbangkan ketika mengelola cacat:Dimanakah tempat di dalam SDLC yang harus diukur cacatnya?
Produk kerja apa yang harus diuji kecacatannya?
Perkakas/tool dan metoda apa yang harus digunakan untuk ukuran kecacatan?
Berapa banyak cacat dapat dihilangkan pada masing-masing tahapan?
Berapa banyak cacat diperkirakan tinggal setelah disetiap tahapan dimusnahkan?
Masing-masing aktivitas pemusnahan cacat dapat dipikirkan sebagai saringan yang memindahkan beberapa persen dari cacat yang bisa menimbulkan vulnerability dari produk software, sedangkan ada cacat lainnya yang bisa menimbulkan vulnerability lepas dari saringan dan tetap tinggal di software ( lihat Gambar 1).

Gambar 1  Filter pemusnah vulnerability

Semakin banyak saringan bisa menyaring cacat yang ada di dalam SDLC,  semakin sedikit cacat yang bisa menimbulkan vulnerability yang tetap tinggal di produk software ketika dilepaskan. Lebih penting lagi, karena cacat  diukur lebih awal, institusi akan mempunyai waktu untuk mengambil tindakan korektif lebih awal di dalam SDLC.
Beberapa contoh titik-titik pengukuran dan pemusnahan cacat di dalam SDLC adalah analisa arsitektural, pemodelan ancaman, verifikasi desain, review disain, review kode, analisa kode statis, test unit, test penetrasi, dan test sistem.

2.    Menujukan Keamanan Sepanjang  Siklus Hidup Pengembangan Software
Meskipun pengurangan cacat merupakan kunci untuk mengurangi vulnerability, ada hal lain yang diperlukan untuk menghasilkan software yang aman. Pertama-pertama, penyebab umum dari vulnerability keamanan harus dipahami. Beberapa penyebab umum bisa meliputi buffer overflow, SQL injection, race condition, dan cross-site scripting. Walaupun keseluruhan pengetahuan tentang isu keamanan adalah penting, menghapus penyebab umum dari vulnerability memerlukan pendefinisian seperangkat praktek operasional yang baik dimana tim pengembangan dapat menggunakannya dalam pekerjaan sehari-hari: berupa catatan, perkakas, daftar nama (checklist), dan metoda yang memokuskan pada pekerjaan tertentu yang pengembang sedang lakukan pada situasi tertentu.
Pendefinisian praktek operasional yang baik bermanfat sebagai panduan bagi pengembang untuk memeriksa hal-hal umum yang bisa menyebabkan vulnerability yang biasanya luput dari perhatian. Kalau definisi praktek ini sudah ditetapkan, maka pada saat mengembangkan software praktek ini harus digunakan. Gambar 2 memperlihatkan praktek yang baik untuk menujukan keamanan melalui fase-fase yang berbeda dari SDLC. Contoh praktek yang baik pada SDLC tersebut di antaranya meliputi analisis resiko keamanan, prinsip desain yang aman, pemodelan ancaman, review dan inspeksi berdasarkan checklist, dan metode pengujian (testing).
Keamanan harus didefinisikan dengan tegas pada level kebutuhan (requirement). Kebutuhan keamanan tersebut harus mencakup keamanan fungsional yang jelas (penggunaan kriptography) dan kareakteristik yang muncul. Salah satu cara yang terbaik untuk mencakup ruang keamanan yang muncul adalah dengan membangun  abuse cases.  Abuse cases menggambarkan perilaku sistem di bawah serangan, pembuatan hal ini memerlukan pencakupan secara eksplisit dari apa yang harus dilindungi, dari siapa, dan untuk berapa lama.

Di level disain dan arsitektur, suatu sistem harus padu dan menyajikan suatu arsitektur keamanan yang dipersatukan dengan mempertimbangkan prinsip keamanan pengguna (seperti prinsip privilege yang sedikit mungkin). Para perancang,  arsitek, dan analis harus dengan jelas mendokumentasikan asumsi-asumsi dan mengidentifikasi kemungkinan serangan. Pada keduanya, yaitu tahap arsitektur berbasis spesifikasi dan tahap disain berbasis hirarki-kelas, analisa resiko adalah suatu kebutuhan, analis keamanan perlu membongkar dan menggolongkan resiko ini sehingga mitigasi dapat segera dimulai. Tak mengindahkan analisis risiko pada level ini akan menghadirkan permasalahan yang berbiaya mahal sepanjang jalan. Review eksternal  (di luar  tim disain) adalah sering  diperlukan untuk melakukan pengecekan silang terhadap resiko yang ada.
Di level kode, perlu fokus pada  kekurangan (flaws) implementasi, terutama pada penemuan dan pemanfaatan perkakas analisis statis, yaitu perkakas untuk meneliti source program terhadap vulnerability. Beberapa vendor sekarang sudah memperhatikan ruang ini, dan perkakas semacam ini menggerakkan pasar yang terus meningkat dan dengan cepat menuju ke kedewasaan di tahun-tahun berikutnya.
Keamanan pengujian harus meliputi dua strategi, yaitu menguji kemampuan fungsional keamanan dengan teknik pengujian fungsional standar dan pengujian keamanan berbasis resiko yang didasarkan pada pola serangan dan model ancaman. Suatu rencana tes keamanan yang baik ( dengan kemampuan melacak kembali ke kebutuhan) menggunakan kedua strategi tersebut. Permasalahan keamanan tidak selalu nyata, bahkan ketika kita memeriksa suatu sistem secara langsung, sehingga jaminan kualitas terhadap isu-standar tidak dapat membongkar semua isu keamanan yang menekan. Dengan melakukan pengujian penentrasi juga bisa berguna, terutama jika analisi risiko arsitektural sedang menjalankan test tertentu. Keuntungan dari tes penetrasi ini memberi suatu pemahaman yang baik tentang bidang software dalam lingkungan riilnya.
Akhirnya, proses pengembangan software yang aman seharusnya diukur untuk menentukan keefektifannya dan  untuk menentukan ukuran yang merupakan ukuran prediksi dari vulnerability yang tersembunyi di dalam software sewaktu dirilis. Tentang ukuran dan pengukuran trhadap vulnerability ini dibahas pada bagaian selanjutnya. Secara singkat bahasan selanjutnya adalah mengenai bagaimana pengukuran dapat diterapkan pada proses-proses pengembangan dan produk kerja dari software untuk memonitor dan meningkatkan karakteristik keamanan dari software yang sedang dibangun
.

Referensi

1.    G. McGraw, Software Security: Building Security In, IEEE Security & Privacy, 2004.
2.    Dave Zubrow, Measures and Measurement for Secure Software Development, Carnegie Mellon University, 2005.
3.     Noopur Davis, Developing Secure Software, Software Engineering Institute, 2005.
4.    ilmukomputer.com/category/rekayasa-perangkat-lunak/
5.    ilmukomputer.com/2007/09/28/perencanaan-proyek-rekayasa-perangkat-lunak/