VALIDASI SITEM KRITIS

A. Metode formal dan sistem kritis

Penggunaan spesifikasi matematis formal dan verifikasi yang terkait dimandatkan pada standar pertahanan Inggris untuk perangkat lunak yang kritis dalam hal keselamatan. Namun, banyak pengembang sistem kritis tidak yakin bahwa metode formal efektif dalam hal biaya dan mengajukan argumen bahwa metode tersebut dapat menurunkan dan bukan menambah tingkat dependabilitas sistem.

Metode formal dapat dipakai pada 2 tingkat pengembangan kritis :

1. Spesifikasi formal sistem dapat dikembangkan dan di analisis secara matematis terhadap ketakkonsistenan sistem.

2. Verifikasi formal bahwa sistem perangkat lunak konsisten dengan spesifikasi dapat dikembangkan.

Argumen untuk penggunaan spesifikasi formal dan verifikasi program yang berhubungan ialah bahwa spesifikasi formal memaksa analisis spesifikasi rinci. Analisis ini dapat mengungkap ketakkonsistenan yang potensial atau hal-hal yang terlewat yang mungkin tidak akan di temukan sampai sistem di pakai. Verifikasi formal mendemonstrasikan bahwa program yang di kembangkan memenuhi spesifikasi sehingga kesalahan implementasi tidak mengkompromi tingkat dependabilitas.

Kadang-kadang dikatakan bahwa pemakaian metode formal untuk pengembangan sistem menghasilkan sistem yang lebih dapat di andalkan dan lebih aman. Tidak ada keraguan bahwa spesifikasi sistem formal lebih tidak mungkin mengandung penyimpangan yang harus di selesaikan oleh perancang sistem. Bagaimanapun spesifikasi formal dan bukti tidak menjamin bahwa perangkat lunak akan diandalkan dalam pemakaian formal. Alasan untuk hal ini adalah :

1. Spesifikasi mungkin tidak merefleksikan persyaratan yang sebenarnya dari user sistem.

2. Bukti mungkin berisi error.

3. Bukti mungkin mengasumsikan pola pemakaian yang tidak benar.

Walaupun memiliki kekurangan, metode formal memiliki peran penting yang dimainkan pada pengembangan perangkat lunak yang berhubungan dengan keselamatan dan keamanan. Spesifikasi formal sangat efektif dalam menemukan masalah spesifikasi yang merupakan penyebab kegagalan sistem yang paling umum. Verifikasi formal menambah kepercayaa pada sebagian besar komponen kritis pada sistem ini. Penggunaan pendekatan formal bertambah karena pihak pengadaan menuntutnya dan makin banyak rekayasawan yang makin mengenal teknik ini. Bagaimanapun mungkin diperlukan bertahun-tahun sebelum pemakaiannya universal untuk pengembangan sistem kritis.

B. Validasi keandalan

Proses pengukuran keandalan sistem di ilustrasikan pada gambar di bawah ini :

1. Sistem yang ada dan berjenis sama dipelajari untuk menentukan profil operasional. Profil operasional mengidentifikasi kelas-kelas yang berbeda dari input sistem dan probabilitas input ini pada pemakaian normal.

2. Satu set data uji di bangun yang merefleksikan profil operasional.

3. Sistem di uji dengan data ini dan jumlah kegagalan di teliti. Waktu terjadinya kegagalan juga di catat.

4. Setelah sejumlah kegagalan yang signifikan telah terlihat, keandalan perangkat lunak dapat di hitung. Anda dapat menghitung nilai ukuran keandalan yang sesuai.

Pendekatan ini sering disebut pengujian statistik. Tujuan pengujian statistik ialah untuk menilai keandalan sistem. Ini berlawanan dengan pengujian defect yang tujuannnnya adalah untuk menemukan kegagalan sistem. Pendekatan yang menarik secara konceptual terhadap pengukuran keandalan ini tidak mudah diterapkan dalam praktiknya. Kesulitan utama yang muncul disebabkan oleh :

1. Ketakpastian profil operasional. Profil operasional bukan merupakan refleksi yang akurat dari pemain sistem yang sebenarnya .

2. Biaya yang tinggi untu pembangkitan data uji. Mendefinisiskan sejumlah besar data uji memakan waktu lama jika pembangkitannya tidak mungkin dilakukan secara otomatis.

3. Ketakpastian statistik ketika keandalan tinggi di spesifikasi. Penting untuk membangkitkan jumlah kegagalan yang signifikan secara statistik untuk memungkinkan pengukuran keandalan yang akurat.

Pengembangan profil operasional yang akurat mungkin bagi beberapa jenis sistem yang memiliki pola pemakaian baku. Ada banyak user yang berbeda-beda yang masing-masing memiliki cara pemakaian sistem sendiri. Umumnya, cara terbaik untuk membangkitkan set data yang besar dibutuhkan untuk pengukuran keandalandengan menggunakan suatu bentuk pembangkit data yang dapat dipasang untuk membangkitkan input secara otomatis dan sesuai dengan profil operasional. Namun, biasanya tidak mungkin mengotomasi produksi senua data uji untuk sistem interaktif. Set data untuk sistem ini harus dibangkitkan secara manual dengan biaya terkait yang lebih tinggi.

1. Profil operasional

Profil operasional perangkat lunak merefleksikan bagaimana penggunaan perangkat lunak dalam praktik. Profil ini terdiri dari spesifikasi kelas input dan probabilitas terjadinya profil tersebut. Ketika sistem perangkat lunak yang baru menggantikan sistem manual atau terotomasi yang ada, cukup mudah untuk menilai pola penggunaan perangkat lunak baru yang mungkin. Pola ini secara kasar harus berhubungan dengan penggunaan penggunaan yang ada dengan kemungkinan yang dibuat untuk fungsionalitas baru yang termasuk ke dalam perangkat lunak baru.

2. Ramalan keandalan

Pada saat validasi perangkat lunak, manajer harus mengusahakan pengujian sistem. Karena pengujian sangat mahal, maka penting untuk menghentikan pengujian sesegera mungkin dan tidak terlalu menguji sistem. Pengujian dapat berhenti ketika tingkat keandalan sistem yang dibutuhkan telah tercapai. Tentu saja, ramalan keandalan dapat mengungkap bahwa tingkat keandalan yang dibutuhkan tidak akan pernah tercapai. Dalam hal ini, manajer harus mengambil keputusan sulit mengenai penulisan ulang bagian-bagian perangkat lunak atau negosisasi ulang kontrak sistem.

Model pertumbuhan keandalan adalah bagaimana keandalan sistem berubah pada saat pengujian dengan ditemukan kegagalan sisitem, kesalahan yang mendasarinya didasari sehingga keandalan harus membaik pada saat pengujian dan debug sistem. Untuk meramalkan keandalan, model pertumbuhan keandalan konseptual kemudian harus diterjemahkan menjadi model matematis.

Ada berbagai model yang diturunkan dari pengalaman keandalan dalam sejumlah domain aplikasi yang berbeda. Model pertumbuhan keandalan yang paling sederhana adalah model fungsi langkah dengan keandalan bertambah dengan inkremen yang konstan setiap kali suatu kesalahan ditemukan dan diperbaiki. Model ini menganggap bahwa perbaikan perangkat lunak selalu diimplementasi dengan benar sehingga banyaknya kesalahan perangkat lunak dan kegagalan yang terkait berkurang terhadap waktu.

C. Jaminan Keselamatan

1. Verifikasi dan validasi

Verifikasi dan validasi sistem kritis dalam hal keselamatan memiliki banyak kesamaan denganpengujian sistem lain dengan persyaratan keandalan yg tinggi . harus ada pengujian ekstensif untuk menemukan sebanyak mungkin cacat dan pengujian statistic harus digunakan untuk menilai keandalan sistem. Namun, karena kecepatan kegagalan yang sangat rendah yang di tuntut pada banyak sistem yang kritis dalam hal keselamatan, pengujian statistic tidak perlu dapat menyediakan perkiraan kuantitatif dari keandalan sistem karena banyaknya uji yang dibutuhkan yang tidak realistis. Uji hanya memberikan bukti yang dengan bukti lain untuk menilai keselamatan sistem.

Parna et al (1990) mengusulkan 5 jenis review yang harus mandatori untuk sistem yang kritis dalam hal keselamatan :

a. Review untuk tujuan yang benar

b. Review untuk struktur yang daapat di pelihara, dapat dipahami

c. Review untuk menverifikasi bahwa algoritma dan rancangan struktur data konsisten dengan perilaku yang dispesifikasi

d. Review kecukupan kasus uji sistem

2. Argumen keselamatan

Untuk berbagai aplikasi kritis akan ekonomis untuk mengembangkan bukti kebenaran untuk menambah kepercayaan bahwa sistem memenuhi persyaratan keselamatan atau keamanan. Walaupun mungkin tidak efektif dalam hal biaya untuk mengembangkan bukti kebenaran pada sebagian besar sistem, kadang-kadang mungkin mengembangkan argumen keselamatan yang mendemonstrasikan bahwa program memenuhi kewajiban keselamatannya. Tidak perlu membuktikan bahwa program memenuhi spesifikasinya. Hanya perlu di demonstrasikan bahwa eksekusi program tidak dapat mengakibatkan status yang tidak selamat.

Teknik yang paling efektif untuk mendemonstrasikan keselamatan sistem adalah bukti dengan kontradiksi. Ini berarti mengasumsikan bahwa status yang tidak selamat dapat dicapai dengan mengeksekusi program.

3. Jaminan proses

Jaminan kualitas proses pengembangan sistem penting untuk semua sistem kritis terutama dalam hal keselamatan. Ada 2 alasan untuk ini yaitu :

a. Kecelakaan merupakan peristiwa yang jarang pada sistem kritis dan kemungkinan tidak secara praktis mensimulasikan pada saat pengujian sistem.

b. Persyaratan keselamatan, kadang-kadang berupa persyaratan yang tidak mencakup perilaku sistem yang tidak selamat. Tidak mungkin mendemonstrasikan secara konklusif melalui pengujian dan kegiatan validasi lain bahwa persyaratan ini telah dipenuhi.

4. Pemeriksaan keselamatan run-time

Pemikiran pemrograman defensif dengan statement redudun dan ditambahkan pada program untuk memeriksa kesalahan sistem. Teknik ini juga dapat digunakan pada sistem kritis dalam hal keselamatan. Kode pemeriksaan dapat ditambahkan yang memeriksa batasan keselamatan dan yang memberikan eksepsi jika batasan tersebut dilanggar. Batasan keselamatan yang harus selalu berlaku pada tempat-tempat tertentu pada prorogram dapat dinyatakan sebagai assertions.

Assertions adalah predikat yang mendeskripsikan kondisi yang harus berlaku sebelum statement berikutnya dapat di eksekusi. Pada sistem yang kritis dalam hal keselamatan assertions harus diturunkandari spesifikasi keselamatan. Assertions ini ditujukan untuk menjamin perilaku selamat dan bukan perilaku yang sesuai dengan spesifikasi. Assertions sangat berguna untuk menjamin keselamatan komunikasi antara komponen sistem.

D. Penilaian Keamanan

Penilaian keamanan sistem menjadi brtambah penting dengan semakin banyaknya sistem yang yang ke internet. Persyaratan keamanan mirip dengan persyaratan keselamatan. Persyaratan itu menspesifikasi perilaku sistem yang tidak di perbolehkan dan bukan perilaku yang di harapkan dari sistem.

Perbedaan mendasar antara keselamatan dan keamanan adalah pada masalahmasalah di bidang keselamatan biasanya tidak disengaja sedangkan seranagnan pada siste (masalah keamanan) adalah suatu kejahatan. Bahkan pada sistem yang telah dipakai beberapa tahun, penyerang jenius dapat menemukan bentuk baru dari serangan dan dapat menembus apa yang di anggap sebagai sistem yang aman. Sebagai contoh, algoritma RSA untuk enkripsi data yang di anggap aman di crack pada tahun 1999.

Ada 4 pendekatan yang saling melengkapi untuk pemeriksaan keamanan :

1. Validasi berdasarkan pengalaman

Dalam kasus ini, sistem di analisis terhadap jenis serangan yang dikenal tim validasi. Jenis validasi ini biasanya dalam hubungannya dengan validasi berdasar alat bantu.

2. Validasi berdasarkan alat bantu

Dalam hal ini, berbagai alat bantu keamananseperti pemeriksa password dipakai untuk menganalisis sistem. Ini sebenarnya merupakan pengembangan validasi berdasar pengalaman dengan berada dalam alat bantu yang di pakai.

3. Tim macan

Dalam kasusu ini satu tim dibuat dan diberikan tujuan menembus keamanan sistem. Mereka mensimulasi serangan pada sistem dan menggunakan kecerdasan mereka untuk menemukan cara baru mengkompromi keamanan sistem.

4. Verifikasi formal.

Sistem dapat diverifikasi terhadap spesifikasi keamanan formal. Namun demikian pada area lain verifikasi formal untuk keamanan tidak dipakai secara luas.

Sangat sulit bagi end user untuk menverifikasi keamanan. Akibatnya sebagai mana dibahas oleh Gollmann (1999), badan –badan di Amerika Utara dan Eropa telah menentukan set kriteria evaluasi keamanan yang dapat diperiksa oleh evaluator khusus. Pemasok produk perangkat lunak dapat menyerahkan produk mereka untuk evaluasi dan sertifikasi terhadap kriteria ini.

Dengan demikian, jika anda memilki persyaratan untuk tingkat keamanan tertentu, anda dapat memilih produk yang telah divalidasi sampai tingkat itu. Bagaimanapun, banyak produk tidak di sertifikasi keamanan dan sertifikasi berlaku untuk produk individu. Ketika sistem sertifikasi dipakai bersama sistem lain yang tidak tersertifikasi seperti perangkat lunak yang dikembangkan lokal, tingkat keamanan sistem secara keseluruhan tidak dapat di nilai.