Kehandalan dan Keamanan

http://blog.sribu.com/

Pendekatan Risk-driven dan Spesifikasi keselamatan

Persyaratan kehandalan dan keamanan dapat dianggap sebagai persyaratan perlindungan. Untuk menemukan persyaratan perlindungan ini, maka perlu memahami risiko terhadap sistem dan lingkungannya. Pendekatan risk-driven dengan kebutuhan spesifikasi memperhitungkan peristiwa berbahaya yang mungkin terjadi, probabilitas bahwa ini benar-benar akan terjadi, kemungkinan bahwa kerusakan akan hasil dari sebuah acara tersebut, dan tingkat kerusakan yang ditimbulkan.

Pendekatan risk-driven adalah pendekatan yang telah banyak digunakan oleh pengembang sistem keselamatan-dan keamanan-kritis. Hal Ini berfokus pada peristiwa-peristiwa yang dapat menyebabkan kerusakan sebagian besar atau yang mungkin sering terjadi. Peristiwa yang memiliki konsekuensi kecil atau yang sangat jarang dapat diabaikan. Dalam sistem keselamatan-kritis, risiko yang terkait dengan bahaya dapat mengakibatkan kecelakaan; dalam sistem keamanan-kritis, risiko datang dari dalam maupun orang luar serangan pada sistem yang dimaksudkan untuk mengeksploitasi kemungkinan kerentanan.

Proses Pendekatan risk-driven umum melibatkan pemahaman risiko yang dihadapi oleh sistem, menemukan akar penyebab, dan menghasilkan persyaratan untuk mengelola risiko tersebut. Tahapan dalam proses ini adalah:

1.      Identifikasi risiko. Potensi risiko untuk sistem diidentifikasi. Ini bergantung pada lingkungan di mana sistem ini akan digunakan.

2.      Analisis Risiko dan klasifikasi. Setiap risiko dianggap secara terpisah. Mereka yang berpotensi serius dan tidak masuk akal yang dipilih untuk analisa lebih lanjut.

3.      Dekomposisi Risiko. Setiap resiko dianalisis untuk menemukan potensi akar penyebab dari risiko itu.

4.      Pengurangan Risiko. Permintaan untuk cara di mana risiko yang teridentifikasi dapat dikurangi atau dihilangkan dibuat. Ini berkontribusi pada persyaratan sistem ketergantungan yang mendefinisikan pertahanan terhadap risiko dan bagaimana risiko tersebut akan dikelola.

Dalam sistem keselamatan-kritis, risiko utama berasal dari bahaya yang dapat menyebabkan kecelakaan. Anda dapat mengatasi masalah identifikasi bahaya dengan mempertimbangkan berbagai jenis bahaya, seperti bahaya fisik, bahaya listrik, bahaya biologis, bahaya radiasi, layanan bahaya kegagalan, dan sebagainya. Masing-masing kelas kemudian dapat dianalisis untuk menemukan bahaya tertentu yang bisa terjadi. kemungkinan kombinasi dari bahaya yang berpotensi berbahaya juga harus diidentifikasi.

Proses penilaian bahaya berfokus pada pemahaman probabilitas bahwa bahaya akan terjadi dan konsekuensi jika kecelakaan atau insiden yang terkait dengan bahaya yang harus terjadi. Anda perlu membuat analisis ini untuk memahami apakah bahaya adalah ancaman serius bagi sistem atau lingkungan. Analisis ini juga menyediakan dasar untuk memutuskan bagaimana mengelola risiko yang terkait dengan bahaya.

Untuk setiap bahaya, hasil analisis dan klasifikasi proses adalah pernyataan penerimaan. Ini dinyatakan dalam hal risiko, di mana risiko memperhitungkan kemungkinan kecelakaan dan konsekuensinya. Ada tiga kategori risiko yang dapat Anda gunakan dalam penilaian bahaya:

1.      Risiko Intolerable

2.      Risiko As low as reasonably practical (ALARP)

3.      Risiko yang dapat

analisis bahaya adalah proses menemukan akar penyebab bahaya dalam sistem kritis keselamatan. Tujuan Anda adalah untuk mencari tahu apa peristiwa atau kombinasi peristiwa dapat menyebabkan kegagalan sistem yang menghasilkan bahaya.

Setelah potensi risiko dan akar mereka telah diidentifikasi, Anda kemudian dapat menurunkan persyaratan keselamatan yang mengelola risiko dan memastikan bahwa insiden atau kecelakaan tidak terjadi. Ada tiga strategi yang mungkin yang dapat Anda gunakan:

1.      Menghindari bahaya. Sistem ini dirancang agar bahaya tidak dapat terjadi.

2.      Deteksi dan penghapusan bahaya. Sistem ini dirancang agar bahaya terdeteksi dan dinetralisir sebelum mereka mengakibatkan kecelakaan.

3.      Pembatasan kerusakan. Sistem ini dirancang sehingga konsekuensi dari kecelakaan diminimalkan.

Spesifikasi Keandalan

Keandalan berbeda dari keselamatan dan keamanan dalam hal ini adalah atribut sistem terukur. Yaitu, mungkin untuk menentukan tingkat keandalan yang diperlukan, memantau operasi sistem dari waktu ke waktu, dan periksa apakah kehandalan yang dibutuhkan telah dicapai. Misalnya, persyaratan keandalan memungkinkan bahwa kegagalan sistem yang dibentuk memerlukan reboot tidak terjadi lebih dari sekali per minggu. Setiap kali kegagalan tersebut terjadi, dapat login dan Anda dapat memeriksa apakah tingkat yang diperlukan kehandalan telah dicapai. Jika tidak, Anda sebaiknya mengubah persyaratan keandalan.

Persyaratan keandalan ada dua jenis:

1.      Persyaratan Non-fungsional, yang menentukan jumlah kegagalan yang diterima selama penggunaan dari sistem normal, atau waktu di mana sistem ini tidak tersedia untuk digunakan. Ini adalah persyaratan keandalan kuantitatif.

2.      Kebutuhan fungsional, yang menentukan sistem dan perangkat lunak fungsi yang menghindari, mendeteksi, atau mentolerir kesalahan dalam perangkat lunak dan memastikan bahwa kesalahan ini tidak menyebabkan kegagalan sistem.

Ada dua metrik penting yang digunakan untuk menentukan kehandalan plus metrik tambahan yang digunakan untuk menentukan atribut sistem terkait ketersediaan. Pilihan metrik tergantung pada jenis sistem yang sedang ditentukan dan persyaratan dari domain aplikasi. Metrik tersebut adalah:

1.      Probability of failure on demand (POFOD) Jika Anda menggunakan metrik ini, Anda menentukan probabilitas bahwa permintaan untuk layanan dari sistem akan menghasilkan kegagalan sistem. Jadi, POFOD? 0,001 berarti bahwa ada 1/1000 kemungkinan bahwa kegagalan akan terjadi ketika permintaan dibuat.

2.      Rate of occurrence of failures (ROCOF) Metrik ini mengatur tentang jumlah kemungkinan kegagalan sistem yang mungkin diamati relatif terhadap periode waktu tertentu (misalnya, satu jam), atau jumlah eksekusi sistem. Dalam contoh di atas, ROCOF adalah 1 / 1.000. Kebalikan dari ROCOF adalah mean time to failure (MTTF), yang kadang-kadang digunakan sebagai metrik kehandalan. MTTF adalah rata-rata jumlah unit waktu antara kegagalan sistem yang diamati. Oleh karena itu, ROCOF dari dua kegagalan per jam menunjukkan bahwa rata-rata waktu untuk kegagalan adalah 30 menit.

3.      Ketersediaan (AVAIL) Tersedianya sistem mencerminkan kemampuannya untuk memberikan layanan ketika diminta. AVAIL adalah probabilitas bahwa sistem akan beroperasi saat permintaan dibuat untuk layanan. Oleh karena itu, ketersediaan 0,9999, berarti bahwa rata-rata, sistem akan tersedia untuk 99,99% dari waktu operasi

Persyaratan keandalan non-fungsional adalah spesifikasi kuantitatif keandalan yang diperlukan dan ketersediaan sistem, dihitung dengan menggunakan salah satu metrik dijelaskan di bagian atas. keandalan kuantitatif dan spesifikasi ketersediaan telah digunakan selama bertahun-tahun dalam sistem keselamatan-kritis tetapi hanya jarang digunakan dalam sistem bisnis penting. Namun, karena semakin banyak perusahaan menuntut 24/7 layanan dari sistem mereka, ada kemungkinan bahwa teknik tersebut akan semakin digunakan.

Spesifikasi Kehandalan Fungsional melibatkan identifikasi persyaratan yang mendefinisikan kendala dan fitur yang berkontribusi terhadap keandalan sistem. Untuk sistem di mana keandalan telah secara kuantitatif ditentukan, persyaratan fungsional mungkin diperlukan untuk memastikan bahwa tingkat yang diperlukan untuk dicapai. Ada tiga jenis persyaratan keandalan fungsional untuk sistem:

1. Persyaratan Memeriksa persyaratan. Ini mengidentifikasi pemeriksaan pada input ke sistem untuk memastikan bahwa salah atau out-of-range input terdeteksi sebelum mereka diproses oleh sistem.

2. Persyaratan Pemulihan Persyaratan. Ini ditujukan untuk membantu sistem pulih setelah kegagalan telah terjadi. Biasanya, persyaratan ini digunakan dengan mempertahankan salinan sistem dan data dan menentukan cara mengembalikan layanan sistem setelah kegagalan.

3. Persyaratan redundansi. Ini menentukan fitur berlebihan dari sistem yang memastikan bahwa kegagalan komponen tunggal tidak menyebabkan hilangnya layanan lengkap.

Spesifikasi keamanan

Firesmith (2003) telah mengidentifikasi 10 jenis persyaratan keamanan yang mungkin dimasukkan dalam spesifikasi sistem keamanan:

1.       persyaratan Identifikasi menentukan apakah sistem harus mengidentifikasi penggunanya sebelum berinteraksi dengan mereka.

2.       Persyaratan Authentication menentukan bagaimana pengguna diidentifikasi.

3.       persyaratan Otorisasi menentukan hak dan izin akses pengguna diidentifikasi.

4.       persyaratan  Imunitas menentukan bagaimana sistem harus melindungi diri terhadap virus, worm, dan ancaman serupa.

5.       persyaratan Integritas menentukan bagaimana data korupsi dapat dihindari.

6.       persyaratan deteksi intrusi menentukan apa yang harus digunakan mekanisme untuk mendeteksi serangan pada sistem.

7.       persyaratan Non-repudiation menentukan bahwa pihak dalam suatu transaksi tidak dapat menyangkal keterlibatannya dalam transaksi itu.

8.       Persyaratan Privasi menentukan berapa privasi data untuk dipertahankan.

9.       persyaratan audit Keamanan menentukan bagaimana penggunaan sistem dapat diaudit dan diperiksa.

10.   persyaratan keamanan pemeliharaan Sistem menentukan bagaimana aplikasi dapat mencegah perubahan yang berwenang sengaja mengalahkan mekanisme keamanan.

Tentu saja, Anda tidak akan melihat semua jenis persyaratan keamanan di setiap sistem. Persyaratan tertentu tergantung pada jenis sistem, situasi penggunaan, dan pengguna diharapkan. Analisis risiko dan proses penilaian dapat digunakan untuk mengidentifikasi persyaratan keamanan sistem. Ada tiga tahap untuk proses ini:

1.       Analisis risiko awal. Tujuan dari proses penilaian ini adalah untuk memperoleh persyaratan keamanan untuk sistem secara keseluruhan.

2.       Analisis risiko siklus hidup. Penilaian risiko ini berlangsung selama sistem pengembangan siklus hidup setelah pilihan desain yang telah dibuat. Tambahan persyaratan keamanan  mempertimbangkan teknologi yang digunakan dalam membangun sistem dan desain sistem dan keputusan implementasi.

3.       Analisis risiko operasional penilaian risiko ini mempertimbangkan risiko yang ditimbulkan oleh serangan berbahaya pada sistem operasional oleh pengguna, dengan atau tanpa insider pengetahuan tentang sistem.