Keamanan Perangkat Lunak

BUD I R AHARD JO

KEAMANAN PERANGKATL UNAK

Contents

Pendahuluan 7

Dasar-Dasar Keamanan 11

Secure Software Development Life Cycle 15

Pengujian 17

Bibliography 23

Kata Pengantar

Buku ini merupakan buku pegangan untuk kuliah KeamananPerangkat Lunak (Software Security) yang saya ajarkan di InstitutTeknologi Bandung (ITB). Ketika saya mengajarkan kuliah ini tahunlalu, sayangnya belum ada buku pegangan dalam Bahasa Indonesia.Bahkan buku teks mengenai hal ini dalam Bahasa Inggris pun masihdapat dikatakan jarang. Terpaksa buku ini harus dibuat.

Selain buku, tools untuk mengajarkan ilmu ini juga masih belumbanyak. Ini merupakan masalah lain. Untuk sekarang, kita bereskankekurangan bukunya dahulu.

Fokus dari pembahasan buku ini adalah pada keamanan dariperangkat lunak. Dasar-dasar dari keamanan tidak akan dibahassecara panjang lebar pada buku ini. Pembaca diharapkan dapatmembaca dari sumber lainnya.

Buku ini masih dalam tahap pengembangan. Pembaharuan akanmasih sering berlangsung. Untuk itu saya menyarankan agar bukuini tersedia dalam format elektronik sehingga mengurangi kebutuhankertas untuk mencetaknya. Selain itu format elektronik juga mem-permudah distribusi buku ini. Jika Anda ingin menyediakan bukuini secara online di tempat Anda (misalnya Anda mengajarkan kuliahyang sama), hubungi saya agar versi di tempat Anda sama barunyadengan versi yang ada di saya.

Semoga buku ini bermanfaat.

Bandung, Agustus 2013

Penulisan daftar pustaka: Budi Rahardjo, Keamanan PerangkatLunak, PT Insan Infonesia, 2014.

Pendahuluan

Perangkat lunak (software) sudah menjadi bagian dari kehidu-pan kita sehari-hari. Bahkan dapat dikatakan sebagian dari sudahbergantung kepada perangkat lunak.

Berapa banyak di antara kita yang masih mengambil uang melaluikantor cabang? Sementara itu, berapa kali kita sudah mengunjungimesin ATM dalam satu bulan terakhir? Dapatkah kita hidup tanpakenyamanan mesin ATM? Semestinya jawabannya adalah iya, tetapisiapa di antara kita yang mau menjadi nasabah sebuah bank yangtidak memiliki layanan ATM? Maukah Anda? Di belakang layananATM ini ada perangkat lunak yang menjalankannya. 0 Mesin ATM yang kita gunakan ada

yang menggunakan sistem operasikhusus, tetapi ada juga yang meng-gunakan sistem operasi umum - yangsudah diperkuat (hardened). Sementaraitu aplikasi di belakangnya, core bank-ing, menggunakan berbagai jenis sistemoperasi dan aplikasi. Kesemuanyasangat bergantung kepada perangkatlunak.

Pemesanan tiket pesawat terbang sekarang banyak yang dilakukandengan menggunakan web. Penerbangan Air Asia, misalnya, memi-liki situs AirAsia.com yang dapat digunakan untuk memesan tiket.Tiketpun tidak harus berbentuk fisik tiket yang dicetak dengan kertaskhusus. Tiket dapat kita cetak sendiri dengan menggunakan printerkita. Bahkan kita dapat hanya menunjukkan berkas tiket tersebutdengan menggunakan perangkat tablet, misalnya.

Pemesanan tiket kereta api pun sekarang dapat dilakukan melaluigerai Alphamart. Kalau kita ke stasiun kereta api pun, penjualantiket juga sudah menggunakan software.

Saat ini telah beredar ratusan juta handphone di Indonesia. Tentusaja ada perangkat lunak yang berjalan di dalam handphone ini.Bahkan saat ini aplikasi untuk handphone dapat dipasang sendirioleh penggunanya, seperti komputer biasa saja.

Perangkat yang terkait dengan kesehatan juga menggunakansoftware. Bahkan devices yang berbentuk perangkat keras (hardware)(embedded system) sebetulnya di dalamnya memiliki software juga.

Kegagalan Perangkat Lunak

Bagaimana jika perangkat lunak ini gagal beroperasi? Apa efeknya?Kegagalan perangkat lunak dapat berakibat ketidaknyamanan, keru-gian finansial, hilangnya nama baik, timbulnya masalah kesehatan,

8 budi rahardjo

dan bahkan sampai kepada hilangnya nyawa. Cerita mengenai kega-galan software dapat dibaca pada bukunya Ivars Peterson 1. 1 Ivars Peterson. Fatal Defect: Chasing

Killer Computer Bugs. Random House,1995

Sebagai contoh, jika sebuah mesin ATM tidak berfungsi, maka kitaakan kesal dan mencari mesin ATM lainnya. Kegagalan ini hanyamenimbulkan ketidaknyamanan semata 2. Lain ceritanya jika aplikasi 2 Richard Milller. Social network

analysis. IEEE Transaction of Networks,2013

core banking yang mencatat saldo rekening bank kita gagal berfungsidan menihilkan saldo kita, maka ini bukan hanya membuat kesaltetapi menjadi masalah finansial yang sangat besar bagi semua pihak.Berapa kerugian yang terjadi akibat gagalnya perangkat lunak?

Jika kegagalam perangkat lunak terjadi pada alat pacu jantung,misalnya, dapat dibayangkan masalah yang ditimbulkannya. Inibukan lagi masalah finansial, tetapi masalah nyawa. Berapa hargayang ingin kita pasang untuk sebuah nyawa?

Kegagalan perangkat lunak umumnya dilihat dari kacamata fung-sional, yaitu aplikasi tidak berfungsi seperti yang diharapkan. Na-mun kegagalan perangkat lunak dapat juga menimbulkan masalahkeamanan (security), seperti misalnya orang yang tidak berhak men-gakses rekening kita ternyata dapat membaca dan mengubah data.

Sebagai contoh, ada kasus bug dalam sistem operasi iOS 7 yangdigunakan oleh Apple dalam produk iPhone-nya. Pada gam-

Figure 1: Kesalahan kode yang mengak-ibatkan alur logika salah

bar 1 3 ditunjukkan kode dari software yang bertujuan untuk men- 3 Sumber:http://www.wired.com/threatlevel/2014/02/gotofail/

guji apakah sertifikat SSL yang digunakan valid. Jika kita perhatikanlebih lanjut ada kesalahan, yaitu duplikat "goto fail;". Baris "gotofail;" yang kedua akan selalu dieksekusi sehingga kode-kode setelahbaris itu tidak akan dicek. Akibat dari kesalahan ini diduga banyak

keamanan perangkat lunak 9

pihak dapat masuk ke perangkat iPhone dengan sertifikat palsu.Kesalahan ini sudah diperbaiki di iOS 7.0.6.

Masalah security seperti ini dikaitkan dengan akses atau secaraumum dapat dimasukkan ke dalam kategori aspek confidentiality(kerahasiaan data) dan integrity (integritas data). Selain dari itu kega-galan perangkat lunak dapat menyebabkan aplikasi menjadi gagalberfungsi (mati, hang, crash, atau terlalu lambat). Yang ini dikaitkandengan aspek availability (ketersediaan) . Aspek-aspel keamanan ini 3 Confidentiality, Integrity, dan Avail-

ability sering disingkat menggunakanhuruf depan mereka menjadi CIA. Se-lain itu ada juga aspek non-repudiation,yaitu tidak dapat menyangkal (telahterjadinya transaksi).

yang akan menjadi fokus pembahasan dengan bahasan lebih ke as-pek perangkat lunaknya. Selain sisi perangkat lunak ada juga sisijaringan, tetapi yang itu menjadi bahasan terpisah.

Figure 2: Statistik MeningkatnyaKelemahan Pada Perangkat LunakJumlah kelemahan perangkat lunak semakin meningkat, seba-

gaimana ditunjukkan pada Gambar 2. Kecenderungan peningkatanini akan terus bertambah, meskipun belum diketahui apakah penam-bahannya tetap seperti eksponensial ataupun linier.

Ada beberapa penyebab kegagalan perangkat lunak; ketidak-tahuan programmer bahwa apa yang dikerjakannya dapat berakibatgagalnya software, kemalasan programmer dalam membuat kodeyang bersih, dan adanya proses bisnis tertentu yang menyebabkankeamanan harus dikorbankan karena berseberangan dengan prosesbisnis tersebut. Setidaknya, buku ini akan mencoba membasmi keti-

10 budi rahardjo

daktahuan.

Fokus Bahasan

Ketika kita mendiskusikan keamanan perangkat lunak, apa mak-sudnya? Bahasan dari buku ini adalah bagaimana kita memastikanbahwa perangkat lunak yang sudah kita gunakan atau kita kem-bangkan bebas dari masalah keamanan. 3 Software yang sudah jadi atau soft-

ware yang dikembangkan sendiri?Untuk perangkat lunak yang sudah kita miliki, kita dapat mengujiapakah dia memiliki masalah keamanan. Metodologi penetrationtesting sering digunakan untuk menguji hal ini. Pengujian cara inidapat dikatakan sudah terlambat dan sering membutuhkan biayayang besar untuk memperbaikinya dibandingkan jika kita sudahmengujinya ketika perangkat lunak tersebut sedang dikembangkan.(Ini akan kita bahas secara lebih rinci.)

Untuk perangkat lunak yang sedang (atau akan) kita kembangkan,maka kita berbicara tentang secure software development life cycle.Intinya adalah isyu keamanan sudah menjadi perhatian pada setiapfase pengembangan perangkat lunak.

Perangkat lunak ada yang berbasis client-sever dan ada yang berba-sis web. Kedua jenis perangkat lunak ini membutuhkan cara yangberbeda untuk pengujian keamanannya. Akan ada bahasan yang 3 Client-server atau web-based? Kedu-

anya memiliki keuntungan dan keru-gian. Pemilihan bergantung kepadajenis aplikasi.

khusus mengenai masing-masing jenis.

Dasar-Dasar Keamanan

Buku ini membahas tentang keamanan dari perangkat lunak. Untukitu perlu terlebih dahulu diuraikan mengenai dasar-dasar keamanansecara singkat sehingga cukup untuk melakukan pembahasan men-genai keamanan perangkat lunak. Dasar-dasar keamanan yang lebihrinci dapat dipelajari dengan menggunakan buku referensi lainnya.

Apa yang dimaksud dengan keamanan? Ada tiga faktor utamayang disebut sebagai tujuan (goals) atau aspek dari keamanan, yaituConfidentiality, Integrity, dan Availability. Mereka sering disebut CIAberdasarkan singkatan dari huruf depan mereka. Selain ketiga haldi atas, yang juga dapat disebut sebagai core security concepts, adageneral security concepts lainnya seperti non-repudiation, authentication,authorization, access control, dan auditing.

Confidentiality

Confidentiality atau kerahasian menyatakan bahwa data tidak dapatdiakses oleh orang yang tidak berhak. Ketika orang berbicara menge-nai keamanan data, faktor ini yang hadir di dalam pikiran kita.

Serangan terhadap aspek ini dilakukan dengan berbagai caraseperti misalnya menyadap jaringan, menerobos akses dari sistemkomputer, sampai ke menanamkan trojan horse dan keylogger4 untuk 4 Keylogger adalah sebuah aplikasi atau

alat yang menangkap apa-apa yang kitaketikkan di keyboard.

mengambil data secara ilegal. Cara non-teknis dapat dilakukan den-gan social engineering, yaitu berpura-pura sebagai orang yang berhakmengakses data dan meminta orang lain untuk memberikan datatersebut.

Cara-cara pengamanan terhadap serangan kerahasiaan antaralain adalah dengan menggunakan kriptografi (yaitu mengubah datasehingga terlihat seperti sampah), membatasi akses ke sistem den-gan menggunakan userid dan password sehingga ini dikaitkan jugadengan access control.

Salah satu masalah yang terkait dengan aspek kerahasiaan adalahmemilah dan melabel data apa saja yang dianggap sebagai datarahasia. Sebagai contoh, apakah data kepegawaian di kantor kitadianggap sebagai rahasia? Apakah data nilai (transkrip) mahasiswa

12 budi rahardjo

di kampus merupakan data yang rahasia? Apakah klasifikasi dataitu hanya rahasia atau tidak rahasia saja? Atukah ada tingkatannya- seperti top secret, rahasia, untuk keperluan internal saja, dan untukpublik? Lantas, siapa yang berhak menentukan tingkat kerahasiaandata ini?5 Ini masih merupakan masalah besar di berbagai institusi 5 Secara umum seharusnya pemilik

aplikasi yang tahu tingkat kerahasi-aan data, bukan orang IT. Orang ITdapat dianggap seperti tukang parkiryang menjaga kendaraan di tempatparkir, tetapi dia bukan pemilik darikendaraan yang diparkir. Juga tukangparkir sesungguhnya tidak tahu nilaidari kendaraan (aset) yang dijaganya.

karena umumnya mereka tidak memiliki panduan atau standar men-genai klasifikasi data.

Integrity

Integrity mengatakan bahwa data tidak boleh berubah tanpa ijindari pihak yang berhak. Sebagai contoh, data saldo rekening bankmiliki kita tidak boleh berubah secara tiba-tiba. Transaksi bernilaiRp. 3.000.000,- tidak boleh dapat diubah oleh penyerang menjadiRp. 3.500.000,-. Atau tujuan transaksi tidak boleh diubah tanpa dike-tahui. Contoh lain adalah data jumlah pemilih dalam sebuah sistempemilu atau e-voting tidak boleh berubah tanpa melalui proses yangsah.

Serangan terhadap aspek ini dilakukan melalui serangan man inthe middle (MITM). Data transaksi ditangkap (intercepted) di tengahjalan, dimodifikasi, dan kemudian diteruskan ke tujuan. Penerimatidak sadar bahwa data sudah berubah dan memproses yang sudahberubah ini.

Perlindungan terhadap serangan dapat dilakukan dengan menam-bahkan message digest (signature, checksum) dalam pesan yang dikir-imkan secara terpisah sehingga ketika terjadi perubahan akan ter-deteksi di sisi penerima. Banyak aplikasi atau sistem yang belummenerapkan ini sehingga perubahan data yang tidak sah tidak dike-tahui.

Pencatatan (logging) terhadap perubahan data juga harus di-lakukan sebagai upaya untuk mengetahui terjadinya serangan ter-hadap integritas ini. Perlu diingat bahwa pencatatan tidak mencegahterjadinya serangan.

Availability

Aspek availability menyatakan bahwa data harus tersedia ketika dibu-tuhkan. Pada mulanya aspek ini tidak dimasukkan ke dalam aspekkeamanan, tetapi ternyata kegagalan berfungsinya sistem dapat men-gakibatkan kerugian finansial atau bahkan hilangnya nyawa.

Serangan terhadap aspek ini adalah dengan cara membuat sis-tem gagal berfungsi, misalnya dengan melakukan permintaan (re-quest) yang bertubi-tubi. Serangan ini disebut sebagai Denial of Service(DOS). DOS attack ini dapat dilakukan pada jaringan dan aplikasi.


Perlindungan terhadap serangan ini dapat dilakukan denganmenggunakan sistem redundant dan backup.

Non-repudiation

Aspek non-repudiation menyatakan bahwa seseorang tidak dapatmenyangkal (telah melakukan sebuah aktifitas tertentu, misalnyatelah melakukan transaksi). Aspek ini biasanya dibutuhkan untukaplikasi yang terkait dengan transaksi.

Serangan, atau masalah, terhadap aspek ini dapat terjadi jikaseseorang menyangkal telah melakukan transaksi. Atau, ada disputeantar dua pihak akan keabsahan sebuah transaksi. Misalnya bisasaja terjadi serangan terhadap integritas, yang mana data seseorangdiubah. Maka terjadilah ketidaksepakatan.

Perlindungan terhadap serangan pada aspek ini dapat dikaitkandengan perlindungan terhadap serangan pada aspek integritas danditambahkan dengan pencatatan (logging).

Manajemen Risiko

Masalah keamanan yang terkait dengan sistem teknologi informasipada awalnya dianggap sebagai masalah teknis. Hal ini menyulitkankomunikasi dengan pihak atasan (manajemen) sehingga penangananmasalah keamanan teknologi informasi tidak mendapat perhatian.Pendekatan yang lazim dilakukan adalah melihat masalah keamananini sebagai masalah risiko, sehingga masalah ini dapat dilihat sebagaimasalah manajemen risiko (risk management).

Ada beberapa metodologi untuk melakukan manajemen risiko.Salah satu panduan yang cukup banyak digunakan adalah metodologiyang didokumentasikan di NIST SP800-306. Manajemen risiko ter- 6 Gary Stoneburner, Alice Goguen, and

Alexis Feringa. Risk management guidefor information technology systems.Technical Report NIST SP 800-30, NIST,2002

diri atas tiga hal risk assessment, risk mitigation, dan evaluation andassessment. Manajemen risiko ini menjadi bagian dari setiap langkahpengembangan sistem. Hal ini konsisten dengan usulan-usulan inte-grasi keamanan dalam pengembangan perangkat lunak.

Risk Assessment

Langkah pertama dalam manajemen risiko adalah melakukan assess-ment. NIST SP 800-30 mengusulkan sembilan (9) langkah (kegiatan)dalam melakukan assessment ini7: 7 Buku ini tidak membahas secara

rinci mengenai langkah-langkah ini.Silahkan membaca dokumen tersebut.1. System Characterization

2. Threat Identification

3. Vulnerability Identification

14 budi rahardjo

4. Control Analysis

5. Likelihood Determination

6. Impact Analysis

7. Risk Determination

8. Control Recommendations

9. Results Documentation

Pada prinsipnya, risk assessment bertujuan untuk mengidentifikasiaset yang ingin diproteksi, ancaman, kelemahan, probabilitas kelema-han tersebut dapat dieksploitasi, dan

Secure Software Development Life Cycle

Pengembangan perangkat lunak secara formal harus mengikutilangkah atau tahapan tertentu, yang dikenal dengan nama SoftwareDevelopment Life Cycle (SDLC). Pengembangan diawali dengan tahaprequirement untuk kemudian dilanjutkan dengan desain, pengem-bangan test plan, implementasi (coding), pengujian, dan peluncuran(deployment). Secara rinci, SDLC dapat dipelajari dari Pressman.

Hal yang belum nampak secara eksplisit pada conventional SDLCadalah aspek keamanan. Keamanan seharusnya hadir pada setiaptahapan SDLC. Ada beberapa pendekatan tentang secure SDLC. GaryMcGraw menjabarkan pengembangan perangkat lunak yang amandalam bukunya 8. Selain itu ada beberapa metodologi lain yang akan 8 Gary McGraw. Software Security:

Building Security In. Addison-Wesley,2006

dibahas lebih lanjut.

Figure 3: Secure SDCL menurut GaryMcGraw

16 budi rahardjo

Seperti dapat dilihat pada gambar 3, keamanan - bagian yangberwarna hijau - dipertimbangkan pada setiap tahapan SDLC. Con-ventional SDLC ditunjukkan dengan warna hitam.

Security Requirement

Dalam pengembangan perangkat lunak, requirement merupakan se-buah hal yang sangat esensial. Banyak pengembangan perangkatlunak yang gagal dikarenakan requirement yang berubah-ubah. Waktupengembangan bertambah panjang sesuai dengan perubahan require-ment.

Pengembangan perangkat lunak tanpa security requirement men-galami masalah tambahan, yaitu masalah yang terkait dengan kea-manan. Namun penambahan security requirement, yang merupakannon-fuctional requirement malah dianggap sebagai tambahan bebansehingga tidak dilakukan. Padahal tanpa adanya security requirement,masalah yang timbul di kemudian hari justru akan mahal untukdiperbaiki.

Security requirement dikaitkan dengan faktor yang terkait den-gan keamanan, yaitu confidentiality, integrity, dan availability. Selainkomponen di atas, ada juga faktor lain yang diusulkan oleh Mano 9 9 Mano Paul. Official (ISC) Guide to the

CSSLP. CRC Press, 2011seperti authentication requirement, authorization requirement, auditingrequirement, session management requirement, errors and exceptions man-agement requirement, configuration parameters management requirement,sequencing and timing requirement, archiving requirement, internationalrequirement, deployment requirement, procurement requirement, antipiracyrequirement.

Contoh security requirement antara lain:

Password harus dilindungi ketika diketikkan / ditampilkan harusdimasking (misal dengan menggunakan karakter bintang).Ketika disimpan, password harus disimpan dalam bentuk hashed.

Perubahan data harga harus tercatat dengan menyertakan times-tamp dan identitas pengguna yang melakukan perubahan.

Sumber dari security requirement dapat diperoleh dari internal danexternal. Dari internal sumber dapat berasal dari kebijakan, standar,guidelines, dan kebiasaan. Dari sumber external sumber dapat berasaladari regulasi, compliance, dan seterusnya.

Pengujian

Pengujian (testing) dilakukan untuk memastikan bahwa perangkatlunak atau sistem yang kita kembangkan sudah memenuhi apa yangkita inginkan (kebutuhan). Pengujian adalah membandingkan antararequirement dan implementasi. Skenario pengujian dan datanya harusdisiapkan sebelum kode dibuat. Jika tidak, kode akan kita uji denganapa? Pada bagian ini akan dibahas pengujian dengan lebih rinci.

Pembuktian versus Pengujian

Sebetulnya untuk mengetahui apakah sebuah sistem sudah benaratau tidak dapat kita lakukan dengan dua cara, yaitu melalui pem-buktian (proof) dan melalui pengujian (testing). Perbedaan antarakeduanya dapat dijelaskan dengan contoh berikut.

Berapa gaya tarik bumi (gravity)? Ada dua cara untuk mencarigaya tarik bumi. Cara pertama adalah dengan menurunkan dariberbagai persamaan sehingga akhirnya diperoleh nilai 9,8 m/detik2.(Ada yang tahu persamaan-persamaan apa saja yang digunakanuntuk menurunkan angka ini?)

Care kedua adalah dengan melakukan pengukuran (pengujian)melalui percobaan dengan menjatuhkan benda dengan variasi beratdengan ketinggian tertentu dan mengukur waktunya sampai bendatersebut hit the ground. Dari berbagai pengukuran akan diperolehnilai yang sama.

Pembuktian memberikan nilai kepercayaan yang lebih tinggidaripada pengujian (pengukuran), akan tetapi seringkali pembuk-tian sulit untuk dilakukan. Seringkali sistem yang ingin dibuktikanmemiliki tingkat kompleksitas yang tinggi sehingga sulit untuk di-lakukan pembuktian. Perangkat lunak masuk kategori ini. Sehinggapembuktian hanya dapat dilakukan untuk sistem yang ukurannyakecil, atau sering disebut sebagai toy problems.

Ilmu yang membahas tentang pembuktian ini dikenal seba-gai formal methods, metoda formal. Bidang ini masih kental aspekpenelitiannya karena tingginya kompleksitas yang harus dihadapi.Terkait dengan hal ini adalah automated theorem prover. Untuk bidang

18 budi rahardjo

perangkat keras (hardware) 10, metoda formal lebih banyak keberhasi- 10 Budi Rahardjo. Formal Verificationof Asynchronous Systems. PhD thesis,University of Manitoba, 1996

lannya dibandingkan dengan di bidang perangkat lunak.Buku ini akan lebih fokus kepada pengujian.

Manual Atau Otomatis

Pengujian dapat dilakukan secara manual atau otomatis. Umumnyapengembang melakukan pengujian secara manual karena tidak tahubahwa ada mekanisme untuk melakukan pengujian secara otomatis.Pengujian secara manual digunakan untuk hal-hal yang sederhanadan tidak memerlukan pengulangan, tetapi pada kenyataannyaperangkat lunak harus diuji berkali-kali. Jarang sekali kita mem-buat sebuah perangkat lunak yang langsung berjalan dengan benardalam satu kali percobaan. Sehingga, sesungguhnya pengujian secaraotomatis merupakan hal yang harus diketahui.

Misalnya kita membuat modul "login" untuk sebuah aplikasi.Kita menguji modul tersebut secara terpisah dari modul lainnya.Pengujian katakanlah dilakukan dengan 100 kali (data) percobaan.Apabila ada perubahan, maka modul tersebut harus kita uji lagi.Maka kita harus melakukan 100 kali pengujian lagi. Katakanlah adaperubahan versi, maka dia harus diuji 100 kali lagi. Jika ini dilakukansecara manual, dapat dibayangkan betapa repotnya.

Ada beberapa tools (framework) yang dapat digunakan untukmelakukan pengujian secara otomatis ini. Biasanya tools ini bergan-tung kepada bahasa pemrograman yang digunakan. Sebagai contoh,untuk yang menggunakan bahasa pemrograman Java dapat meng-gunakan JUnit11. Untuk menguji aplikasi yang berbasis web dapat 11 Informasi mengenai JUnit dapat

dilihat di junit.org. JUnit is a simpleframework to write repeatable tests.

digunakan Selenium12.

12 Informasi mengenai Se-lenium dapat diperoleh dihttp://docs.seleniumhq.org/Skenario Pengujian

Pengujian dilakukan dengan menggunakan skenario atau kasus-kasus (test cases). Kasus-kasus ini seharusnya tersedia sebelum kodedibuat sehingga pengembang dapat memastikan kodenya benar ataumasih salah dengan menggunakan kasus-kasus tersebut.

Ada beberapa kasus yang harus ditangani:

normal;

ekstrim;

abuse.


Kasus Normal

Untuk menjelaskan hal tersebut, mari kita ambil contoh. Kita dimintauntuk membuat sebuah modul atau fungsi untuk mengurutkan datayang berupa bilangan integer positif dari kecil ke besar. Contoh datauntuk kasus normal adalah sebagai berikut:

input: 1, 7, 5, 3, 2, 6, 4

output: 1, 2, 3, 4, 5, 6, 7

Apakah dengan satu kali pengujian tersebut kita yakin bahwamodul kita sudah benar? Seharusnya kita membutuhkan beberapakali pengujian13. Kita dapat membuat beberapa data lagi untuk 13 Berapa kali seharusnya pengujian

dilakukan menurut statistik?kasus normal.

1, 7, 3, 2, 5, 6, 4

2, 1, 7, 3, 4, 5, 6

3, 9, 2, 11, 8, 34

... dan seterusnya.

Dalam contoh di atas kita masih harus membuat daftar hasil be-narnya.

Pembuatan data di atas dapat kita lakukan secara manual ataudihasilkan (generate) oleh program secara otomatis.

Pengujian yang berkali-kali ini disebut regression(?). Apakah den-gan menguji berkali-kali tersebut kita yakin seratus persen bahwamodul tersebut telah kita buat dengan benar? Tidak. Untuk memas-tikan bahwa modul sudah benar, secara teori dia harus diuji dengansemua kombinasi yang memungkinan. All possible combinations.

Jika kita membuat sebuah adder (penjumlah) untuk dua bilan-gan 4-bit, maka akan ada 28 kombinasi. Jumlah 256 kombinasi inimasih dapat dilakukan secara exhaustive, yaitu mencoba semuakombinasi. Begitu jumlah bit-nya meningkat, maka jumlah kombi-nasinya juga meningkat secara eksponensial. Sebagai contoh, longinteger di dalam bahasa C didefinisikan sebagai 32-bit. Untuk moduladder dengan long integer dibutuhkan 264 atau 18446744073709551616(1, 8446744073709551616 1019) kombinasi. Menguji semua kombinasiini tidak dapat dilakukan dengan ketersediaan komputasi saat ini.

Untuk kasus modul sorting kita tidak dimungkinkan untuk men-guji semua kombinasi. Bayangkan, ada berapa permutasi bilanganinteger yang perlu diurut tersebut? Maka pengujian terpaksa meng-gunakan sampel.

20 budi rahardjo

Kasus Ekstrim

Salah satu cara untuk meningkatkan kepercayaan adalah denganmenguji modul dengan data yang mewakili kasus ekstrim. Dalamcontoh modul pengurutan sebelumnya, kasus ekstrim dapat dita-mpilkan sebagai berikut.

1, 2, 3, 4, 5, 6, 7 (data sudah terurut);

7, 6, 5, 4, 3, 2, 1 (data sudah terurut secara terbalik);

1, 1, 1, 1, 1, 1, 1 (data sama semua);

0, 0, 0, 0, 0, 0, 0 (data minimal);

65535, 65535, 65535, 65535, 65535 (data maksimal);

1,8,2,9,11,37,8,19,29,4,5,91,... (jumlah data yang banyak).

Kita dapat menambahkan data ekstrim lainnya. Sayangnya ke-lengkapan data ini bergantung kepada kemampuan kita untuk me-lengkapinya.

Kasus Abuse

Kalau dalam kasus-kasus sebelumnya kita memberikan data yang be-nar dan fokus kepada fungsionalitas sesuai dengan yang diinginkan,maka pada kasus ini kita mulai memikirkan aspek keamanannya.Kita mulai memikirkan kasus atau data yang seharusnya tidak bolehdiberikan ke modul tersebut.

7, -3, 1, 2, 4, 5 (data negatif);

7, 3, a, 8, 5, 2 (ada data yang bukan integer, bukan tipe data yanglegal);

7, 3, 1.2, 7, 5, 2 (data bilangan riil);

7, 238273897283789273892738, 1, 2 (bilangan terlalu besar);

7, 3, , , 2 (ada data yang kosong).

Kesulitan yang ada dalam membuat daftar kasus abuse adalahkita tidak dapat membuat daftar all possible abuse. Data yang adaadalah data yang teringat.


Standard Data Set

Seringkali ada pihak lain yang sudah pernah mengembangkanmodul yang sama atau mirip. Mereka menerbitkan juga data yangdigunakan untuk menguji modul mereka. Jika banyak orang yangmengembangkan hal yang sama, seperti misalnya di dunia peneli-tian, maka akhirnya akan ada kumpulan data standar yang digu-nakan untuk pengujian. Ini sering juga dikenal dengan standardcorpus.

Sebagai contoh, jika kita mengembangkan aplikasi yang terkaitdengan pemrosesan citra (image processing) maka ada data standaruntuk pengujian. Standar data ini berisi gambar Leena, Baboon, Bridge,dan seterusnya. Coba cari apakah aplikasi atau modul Anda jugamemiliki standar data pengujian.

Fuzzing

Kasus abuse dapat kita perdalam lebih lanjut lagi dengan menggu-nakan cara yang lebih otomatis, yaitu dengan menggunakan teknikfuzzing 14. Pada prinsipnya teknik fuzzing adalah mencoba memberi 14 Ari Takanen, Jared DeMoot, and

Charlie Miller. Fuzzing for SoftwareSecurity Testing and Quality Assurance.Artech House, 2008

data invalid secara otomatis atau semi otomatis. Tujuannya adalahuntuk mencari kesalahan yang misalnya dapat membuat sistemmenjadi gagal berfungsi (crash). Dari kacamata security harapannyakegagalan fungsi ini menimbulkan celah keamanan yang dapat diek-sploitasi.

Ada beberapa tools atau framework dari fuzzing ini. Merekaumumnya masih dalam tahap penelitian.

Bibliography

[1] Gary McGraw. Software Security: Building Security In. Addison-Wesley, 2006.

[2] Richard Milller. Social network analysis. IEEE Transaction ofNetworks, 2013.

[3] Mano Paul. Official (ISC) Guide to the CSSLP. CRC Press, 2011.

[4] Ivars Peterson. Fatal Defect: Chasing Killer Computer Bugs. RandomHouse, 1995.

[5] Budi Rahardjo. Formal Verification of Asynchronous Systems. PhDthesis, University of Manitoba, 1996.

[6] Gary Stoneburner, Alice Goguen, and Alexis Feringa. Risk man-agement guide for information technology systems. TechnicalReport NIST SP 800-30, NIST, 2002.

[7] Ari Takanen, Jared DeMoot, and Charlie Miller. Fuzzing for Soft-ware Security Testing and Quality Assurance. Artech House, 2008.

PendahuluanKegagalan Perangkat LunakFokus Bahasan

Dasar-Dasar KeamananConfidentialityIntegrityAvailabilityNon-repudiationManajemen Risiko

Secure Software Development Life CycleSecurity Requirement

PengujianPembuktian versus PengujianManual Atau OtomatisSkenario Pengujian

Bibliography

Documents

Keamanan Perangkat Lunak