Telah di Baca 2599 kali
Bagian ini membahas mengenai bagaimana pengukuran dapat diterapkan pada proses-proses pengembangan dan produk kerja software untuk memonitor dan meningkatkan karakteristik keamanan dari software yang sedang dibangun. Pengukuran sangat bergantung pada siklus hidup pengembangan software (SDLC) yang meliputi kebijakan, proses, dan prosedur yang bisa merefleksikan keamanan itu sendiri. Hal bisa membantu para praktisi (desainer, arsitek, spesialis kebutuhan, pengkode, penguji, dan manajer) yang memerlukan panduan sebagai cara yang terbaik untuk pendekatan pengukuran untuk pengembangan yang aman.
1. Pengukuran dan siklus hidup pengembangan software (SDLC)
dan merefleksikan proses-proses mature, yang digambarkan dengan CMMI.
Ada beberapa ukuran dan praktek yang digunakan dalam pengembangan software yang secara sukses dapat diperluas untuk menuju ke perhatian masalah keamanan. Pada area SDLC, ini berhubungan dengan definisi dan penggunaan ukuran-ukuran untuk pengembangan keamanan yang ditujukan pada pembangunan keamanan dalam modul-modul yang meliputi: analisis kebutuhan (requirement), analisis resiko arsitektural, assembly, integrasi dan evolusi, analisi kode, pengujian keamanan fungsional dan berbasis-risiko, proses siklus-hidup pengembangan software, aturan-aturan pengkodean, kesadaran dan pelatihan, dan manajemen proyek. Manajemen resiko pada umum dituangkan secara terpisah di dalam modul kerangka analisis resiko. Berlawanan dengan fokus manajemen resiko tradisional pada kegagalan proyek di dalam pengembangan software, sekarang ini harus lebih diperluas untuk menunjukkan eksploitasi kejahatan dari kelemahan produk. Pemodelan ancaman (threat) dan penggunaannya di dalam SDLC ditujukan dalam modul-modul pola serangan, pemodelan ancaman, dan resiko historikal. Semua area ini mempunyai dampak pada penggunaan pengukuran.
2.1 Ukuran software dan ukuran pengembangan yang aman
2.1 Proses pengukuran perekayasaan software
Pekerjaan terbaru untuk menetapkan suatu perspektif umum bagaimana cara melaksanakan pengukuran dan analisa software dapat ditemukan di Organisasi Intemasional untuk Standardisasi dan Komisi pengawas Elektroteknis Internasional (ISO/IEC) 15939 (Standar Proses Pengukuran Software), area pemrosesan Pengukuran Dan Analisa Capability Maturity Model Integration (CMMI), dan bimbingan yang disajikan oleh Practical Software Measurement (PSM). Praktek dari model CMMI terorganisir di sekitar dua tema atau tujuan utama, yaitu aktivitas pengukuran dan analisa ”aligning” dengan tujuan organisatoris dan pengembangan, kemudian aktivitas analisa dan pengukuran ”performing”. Secara singkat, praktek untuk pengukuran ”aligning” adalah
* Membangun objektif pengukuran,
* Menetapkan ukuran-ukuran,
* Menetapkan prosedur pengumpulan dan penympanan data,
* Menetapkan prosedur analisis.
Sedangkan praktek untuk pengukuran ”performing” adalah
* Mengumpulkan data pengukuran,
* Mengalisa data pengukuran,
* Menyimpan data dan hasil-hasilnya,
* Menyampaikan hasil-hasil yang diperoleh.
Tahapan-tahapan paraktek ini ditunjukkan di dalam tabel 1, adalah penting bagi mereka yang terlibat dalam organisasi dan proyek untuk merencanakan aktivitas pengukuran mereka sehingga ukuran yang benar dapat dikumpulkan, dianalisa, dan disampaikan ke pihak-pihak yang tepat dengan format yang informatif dan tepat waktu. Manajemen proyek dan pengertian yang mendalam tentang mutu produk bergantung pada data yang relevan, dapat dipercaya, sekarang, dan valid. Langkah-langkah praktek berikut ini memokuskan aktivitas pengukuran pada kumpulan data yang akan digunakan, bukan hanya mengumpulkan data demi pengukuran. Berkenaan dengan pengembangan software yang aman, adalah penting perhatian keamanan itu ditujukan pada langkah-langkah proses pengukuran seperti yang diuraikan di bawah ini.
Table 1. Proses pengukuran dan analisis
Penggunaan yang efektif dari proses-proses di atas pertama-tama terletak pada persetujuan sasaran hasil (objektif) pengukuran yang dapat diterapkan baik pada produk maupun proses pengembangan. Tujuan ini bersandar pada kebutuhan sistem secara eksplisit, yang berarti bahwa keduanya aspek fungsionalitas dan keamanan harus ditetapkan terlebih dahulu. Organisasi perlu menilai lingkungan resiko untuk menunjukkan kemungkinan ancaman dan menerjamahkannya ke dalam kebutuhan keamanan spesifik seperti halnya mendisain dan menerapkan suatu proses pengembangan yang akan memenuhi kebutuhan keamanan.
Berikut ini adalah spesifikasi kebutuhan berhubungan dengan keamanan, sasaran hasil pengukuran mungkin bisa dirumuskan sehingga akan menyediakan pengertian yang mendalam dalam pemenuhan kebutuhan keamanan. Contoh sasaran hasil pengukuran meliputi hal-hal berikut:
* Vulnerability (lubang kerentanan) apa yang terdeteksi pada produk kita?
* Poin-poin proses apa yang paling rentan terhadap resiko yang berhubungan dengan keamanan (yaitu injeksi kode/modul ke dalam program dimana variabel dapat tak terkendali, dll) ?
* Proporsi cacat apa yang berhubungan dengan masalah keamanan dan kebutuhan? Skema klasifikasi cacat apa yang meliputi kategori keamanan?
* Perluasan apa yang praktisi lakukan untuk mematuhi prosedur dan proses yang berhubungan dengan keamanan?
* Perluasan apa yang menyangkut keamanan ditujukan pada ukuran produk kerja lanjutan (kebutuhan, desain, dll) yang diasosiasikan dengan kebutuhan keamanan dan implementasi mereka yang telah digambarkan dan direncanakan?
* Apa modul-modul yang kritis dan mudah rentan? Sudahkah vulnerabilities (lubang kerentanan) telah diidentifikasi dan dialamatkan?
Pemodelan ancaman atau usaha untuk mengidentifikasi tipe/sumber serangan, dapat juga membentuk kebutuhan panduan yang signifikan untuk proses pengembangan. Banyak metodologi resiko dan ancaman telah dipublikasikan, dan Microsoft telah menerbitkan material luas yang menggambarkan pendekatan perusahaan dalam meneliti dan mengurangi ancaman resiko sepanjang SDLC [ Microsoft 03, MSDN 04].
2.2 Ukuran proses untuk pengembangan yang aman
Objektif pengukuran keamanan untuk proses pengembangan seharusnya merujuk pada:
* keberadaan kebijakan keamanan yang dapat digunakan untuk SDLC (peran, prosedur, tanggung-jawab manajemen, aturan persandian, kriteria acceptance/release, dll.),
* pemenuhan poin di atas,
* efisiensi dan efektifitas dari waktu ke waktu.
Haruslah dicatat bahwa objektif pengukuran keamanan untuk proses pengembangan adalah serupa dengan objektif pengukuran umum, disini terjadi penekanan kebutuhan yang memasukkan apa yang menyangkut keamanan di dalam proses implementasi. Ukuran seperti ini bisa diterapkan sebagai bagian dari fungsi jaminan kualitas organisasi. Walaupun menargetkan pengembangan sistem dan penilaian resiko secara keseluruhan, panduan yang bermanfaat untuk pengukuran jenis ini dapat ditemukan pada publikasi NIST, Security Metrics Guide for Information Technology Systems.
Kerapatan cacat adalah suatu ukuran kwalitas sistem. Sering dihitung sebagai banyaknya cacat yang ditemukan selama tes sistem atau sepanjang penggunaan operasional enam bulan pertama yang dibagi dengan ukuran sistem tersebut. Perkiraan sisa cacat produk (yang dihitung dengan tahap pengurungan, deplesi cacat, atau teknik capture-recapture) membentuk suatu keadaan yang alami untuk menaksir sisa vulnerability keamanan di dalam software. Tahap pengurungan cacat mengacu pada suatu teknik analitis yang mengukur proporsi cacat yang berada dalam suatu fase yang dideteksi di dalam fase yang sama. Itu menyediakan suatu karakteristik yang baik dari kemampuan proses pengembangan untuk memelihara mutu sepanjang seluruh SDLC. INFOSEC Assurance Capability Maturity Model (IA-CMM) mengenali dampak pengendalian mutu dengan daftar “ Establishing Measurable Quality Goals” sebagai salah satu dari dua fitur yang meliputi suatu penilaian tingkat 4 menurut banyaknya yang dikendalikan.
2.3 Ukuran produk untuk pengembangan yang aman
Dalam kaitannya dengan produk, objektif pengukuran keamanan boleh mengambil bentuk :
* kebutuhan keamanan, yang berdasarkan pada resiko yang ditentukan oleh penilaian ancaman, kebijakan keleluasaan pribadi, implikasi legal, dan lain lain dan dapat ditetapkan perluasan dan kelengkapannya,
* keamanan arsitektur, yang menunjuk pada kebutuhan keamanan tertentu,
* mengamankan kriteria disain, dimana kebutuhan keamanan dapat dilacak,
* mengamankan praktek perkodean, dimana integritas dapat diakses dan ditaksir.
Tidak semua ukuran perlu untuk diperumit. Sebagai contoh, di dalam tahap kebutuhan adalah berguna untuk mengetahui apakah kebutuhan yang terkait dengan keamanan telah dipertimbangkan untuk masuk dalam kebutuhan sistem. Awalnya ini bisa diukur dengan ya atau tidak ada. seiring dengan pengalaman ukuran yang bertambah dari waktu ke waktu, ukuran bisa berkembang dengan memasukkan karakterisasi perluasan kebutuhan yang berhubungan dengan keamanan, barangkali berlawanan dengan standar. Objektif pengukuran keamanan sepanjang fase disain dan perkodean akan menggunakan tool-tool dan inspeksi/review. Sebagian besar pengukuran pemeriksaan ada dalam bentuk daftar nama identifikasi cacat secara tradisional, dimana item yang berorientasi keamanan dapat ditambahkan. Tabel 2 mendaftar beberapa sumber vulnerability (rentan serangan) yang telah didokumentasikan secara luas, bersama dengan suatu acuan ke bagian dari ISO/IEC 9126 [ ISO/IEC 03b, c] yang telah mendefinisikan suatu ukuran yang relevan. Checklist pemeriksaan software bisa diperluas dengan memasukkan tinjauan ulang isu-isu di dalam tabel.
Tabel 2. Isu integritas kode umum
Ukuran enumerasi sederhana dan penanganan keamanan yang sesuai untuk vulnerability-nya akan menyediakan pengertian yang mendalam terhadap status keamanan sistem selama pengembangan. Sebagai tambahan terhadap tabel di atas, suatu daftar yang bermanfaat dari “Measurable Security Entities” dan “Measurable Concepts” telah diterbitkan oleh Practical Software and Systems Measurement.
Sebagai tambahan untuk teknik pemeriksaan/inspeksi, perkakas baru hadir untuk pengecekan disain dan kode terhadap vulnerability keamanan dan pengukuran keluaran sebagai hasil. Walaupun banyak perusahaan menggambarkan basis konseptual untuk perkakas mereka, hanya sedikit yang menawarkan panduan spesifik mengenai pengukuran yang dilakukan. Dua perusahaan menyediakan suatu perkecualian terhadap penggunaan pengukuran baru mereka yang tidak ditemukan di literatur lainnya adalah :
1. Microsoft’s Secure Windows Initiative menggunakan suatu ukuran baru, Relative Attack Surface Quotient (RASQ) yang pada awalnya diperkenalkan oleh Michael Howard. Jumlah hasil kalkulasi diusahakan sebagai ukuran kompleksitas siklomatik untuk keamanan yang menghasilkan suatu metrik relatif dari produk “attackability.” Ukuran ini didasarkan pada identifikasi dari semua ekspose eksternal di dalam kode produk, dengan tujuan mengurangi profil serangan terhadap produk. Karena ukuran ini hanya bermaknau untuk produk seperti itu maka penggunaannya juga terbatas, tetapi suatu evaluasi independen mengkonfirmasikan efektivitas ukuran ini [ Ernst& muda 03]. Manadhata dan Wing dari departemen Ilmu pengetahuan Komputer Carnegie Mellon juga dengan sukses menerapkan pengukuran itu ke Linux [ Manadhata 04].
2. Laboratorium Ons Prexis melakukan analisa kontekstual terhadap kode untuk identifikasi vulnerability, banyak produk analisis statis lainnya semacam ini. Prexis berbeda dengan penghitungan ukuran V-density untuk menghubungkan kegentingan dan jumlah vulnerability di dalam kode untuk pengambilan keputusan proyek. Sebagai suatu produk penilaian vulnerability dan manajemen resiko software terintegrasi, Prexis meliputi (1) Prexis/Engine: source code vulnerability scanning dan knowledgebase core, (2) Dashboard resiko manajemen, Dan ( 3) Meja kerja remediasi pengembang untuk siklus hidup pengembangan produk [ Laboratorium Ons 05].
3 Perkakas/tool
Banyak sekali terdapat perkakas/tool yang digunakan untuk pengukuran vulnerability dari software yang dapat dikategorikan sebagai Black Box Testing Tools, Code Analysis Tools, dan Modeling Tools. Perlu dicatat bahwa program spreadsheet, paket statistik, dan program database dapat sangat menolong untuk beberapa maksud pengukuran dan analisa. Beberapa penjual juga menawarkan perkakas yang memanen data dari database dan tempat penyimpanan lainnya untuk menghasilkan berbagai laporan pengukuran.
Berbagai perkakas pengembangan sekarang memiliki kemampuan dinamis dan statis untuk menganalisa karakteristik keamanan di dalam kode program. Banyak dari perkakas ini melanjut untuk melakukan tes black box (kotak hitam), dimana kode dibangun dan kemudian memasukkan ke alat dan hasilnya diproduksi sebagai keluaran. Tool pengujian white box (kotak putih) baru-baru ini sudah tersedia, yang mengintegrasi ke dalam lingkungan pengembangan, menawarkan umpan balik yang interaktif dan remediasi kepada pengembang sepanjang proses perkodean.
4 Maturity Praktek
Pengukuran software sedang menjadi suatu bidang yang dewasa, seperti dibuktikan dengan standar internasional dan profesional, konferensi yang khusus, dan beberapa dekade literatur dan riset. Kendati sejarah ini, praktek pengukuran software masih sangat variabel di antara organisasi pengembangan software, dengan banyak yang sedikit melakukan pengukuran proyek dan produk mereka selama pengembangan. Sangat sedikit organisasi memakai beberapa format pengukuran untuk menilai karakteristik keamanan dari produk mereka secara kuantitatif selama pengembangan. Tentu saja, bahkan hanya sedikit yang memperhatikan masalah keamanan. Hanya ada sedikit literatur yang diterbitkan yang konsen terhadap penggunaan pengukuran software yang berkenaan dengan karakterisasi keamanan selama pengembangan software.
Kesimpulan
Karena cacat software yang umum adalah penyebab utama dari vulnerability, maka keseluruhan isi kecacatan dari software harus dikurangi. Berikutnya, keamanan harus secara sistematis ditujukan sepanjang siklus hidup pengembangan software, sehingga harus ada pergeseran di dalam sikap dari “bolting security on” setelah software jadi, ke “building security in” ketika produk dikembangkan. Hal ini memerlukan praktek perekayasaan software yang baik yang harus diikuti ketika sedang mengembangkan software, dan ini mencakup berbagai aktivitas pemusnahan cacat.
Praktek ini melibatkan pengukuran-pengukuran yang diterapkan pada proses-proses pengembangan dan produk kerja software untuk memonitor dan meningkatkan karakteristik keamanan dari software yang sedang dibangun. Pengukuran telah lama diketahui sebagai suatu aktivitas yang penting untuk kesuksesan pengembangan software. Pelaksanaan dan data pengukuran yang baik memungkinkan untuk perencanaan proyek yang lebih realistis, pengawasan status dan kemajuan proyek, pengidentifikasian resiko-resiko proyek, dan peningkatan proses-proses yang lebih efektif. Ukuran dan indikator dari produk kerja software yang meliputi requirement (kebutuhan), desain, kode program dapat dianalisa untuk mendiagnosa masalah-masalah dan mengindentifikasi solusi-solusi selama eksekusi proyek. Hal ini bisa mereduksi cacat, pemborosan (usaha, sumber daya, dll), dan waktu siklus dari pengembangan software. Pelaksanaan kegiatan semacam ini memungkinkan institusi untuk menghasilkan kualitas produk yang lebih tinggi dan lebih aman.
Umumnya, arsitek perangkat lunak, pengembang, dan penguji tetap dengan bangga tidak peduli pada masalah keamanan software. Salah satu bentuk yang mendasar dari praktek yang baik adalah melakukan pelatihan ke staf pengembang software menyangkut isu-isu keamanan software yang kritis. Format yang paling efektif dari pelatihan dimulai dengan uraian tentang masalah keamanan dan mendemonstrasikan arti penting dan dampaknya. Pelatihan mengenai keamanan software yang lebih lanjut seharusnya menawarkan cakupan tentang perekayasaan keamanan, prinsip dan panduan disain, resiko pada saat implementasi, kekurangan (flaws) disain, teknik analisa, eksploitasi software, dan pengujian keamanan. Keluaranya adalah pengembang diharapkan mampu mengembangkan dan memproduksi software yang aman bebas dari vulnerability dengan menjalankan praktek-praktek pengembangan software yang baik yang sudah dipelajarinya.
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/
Telah di Baca 2599 kali