Assurance Case: kasus keamanan yang beralasan

sumber



Apa cara terbaik untuk menilai keamanan tanpa melewatkan apa pun? Apakah mungkin mengumpulkan semua variasi artefak keamanan dalam satu dokumen (atau diagram) dan mengaturnya sedemikian rupa sehingga aspek apa pun dapat divisualisasikan dengan tingkat detail yang dapat dimengerti?



Teknisi akan dengan senang hati menemukan "batu filsuf" yang, meskipun tidak memberikan keamanan, setidaknya akan menilai dengan tingkat kelengkapan yang diperlukan. Perkembangan seperti itu telah ada selama lebih dari 20 tahun, namun secara praktis tidak diketahui oleh pembaca yang berbahasa Rusia. Ini akan tentang metodologi Assurance Case (atau Safety Case), yang berarti serangkaian argumen terstruktur dan bukti dokumenter yang membenarkan kepatuhan sistem atau layanan dengan persyaratan yang ditentukan.

pengantar

Sebelum membaca artikel ini, saya ingin menarik perhatian Anda ke beberapa poin penting. Materi yang disebutkan dapat diterapkan, pertama-tama, untuk objek infrastruktur informasi kritis (CII). Untuk objek seperti itu, khususnya untuk sistem informasi dan kontrol, analisis keamanan harus dilakukan. Hasil analisis keselamatan disajikan dalam bentuk laporan yang sesuai. Semua ini telah dilakukan selama beberapa dekade, namun, laporan, sebagai suatu peraturan, memiliki bentuk teks yang berubah-ubah, yang logikanya tidak selalu mudah untuk dipahami.



Ide utama dari pendekatan yang disajikan adalah bahwa hasil analisis keamanan dapat disajikan dalam bentuk grafik menggunakan notasi semiformal, dengan segala keuntungan yang didapat. Dengan demikian, Kasus Jaminan adalah cara pandang terintegrasi dari semua tindakan untuk memastikan dan menilai keamanan, tanpa mengganti atau membatalkan metode pribadi seperti, misalnya, pengujian, analisis kode statis, perhitungan keandalan, FMEA, analisis risiko, dll. Artikel ini melanjutkan seri keamanan yang diterbitkan sebelumnya .

Peta argumen dan asal usul filosofisnya

Bagaimana kita dapat memahami atau menegaskan bahwa beberapa objek aman? Jelas, sejumlah kriteria harus diperkenalkan untuk ini. Namun, untuk kriteria ini, kita perlu menentukan seberapa andal pengetahuan kita tentang objek tersebut? Mengapa kita bisa mempercayai pengetahuan ini? Apa yang membuat penalaran dan penalaran kita benar-benar dapat dipercaya? Setelah mendalami masalah seperti itu, seseorang tidak dapat melakukannya tanpa disiplin filosofis, seperti ontologi, epistemologi, epistemologi, logika, dan juga, tanpa pemikir hebat yang mengkhawatirkan masalah ini. Di dunia kuno, seperti Aristoteles dan Plato, dan di era "zaman modern" Francis Bacon dianggap sebagai pendiri metode ilmiah modern.



Apa yang dapat dilakukan untuk membenarkan atau menilai keselamatan dengan cara yang masuk akal dan logis? Pendekatan ini didasarkan pada teori argumentasi. Dorongan baru untuk perkembangan modern argumentasi diberikan dalam karya filsuf Inggris Stephen Toulmin berjudul "The Uses of Argument", yang diterbitkan pada tahun 1958. Tulmin memperluas inferensi implikatif logis dengan parameter tambahan dan mengusulkan untuk merepresentasikan operasi ini dalam bentuk grafik. Notasi Tulmin beroperasi dengan entitas berikut: data (D) - data awal untuk analisis, klaim () - tujuan inferensi implikasi logis (Jika D Jadi C), jaminan (W) - argumen tambahan, kualifikasi (Q) - tingkat kepercayaan pada hasil logika output, rebuttable (R) adalah argumen tambahan tambahan (Gambar 1).





Gambar 1. Notasi oleh Stephen Tulmin



Peta argumen atau argumen ( Argument the Map ) digunakan untuk tujuan visualisasi dan penalaran ke Toulmin, tetapi dialah yang paling berhasil merangkum model struktural untuk analisis dan verifikasi argumen. Perhatikan bahwa peta argumen modern, sebagai aturan, tidak menggunakan notasi Tulmin, semuanya disederhanakan, misalnya, seperti pada gambar di bawah. Ini adalah notasi yang digunakan oleh layanan online berbayar Rasional (ada versi gratis, tetapi fungsinya sangat terbatas) (Gambar 2). Versi berbayar mampu mengubah diagram yang dihasilkan menjadi teks terstruktur secara logis. Ada juga panduan & tutorial gratis yang tersedia di situs tentang pemikiran kritis dan pemetaan argumen.





Gambar 2. Peta argumen dikembangkan dengan layananRasional



Seperti yang Anda lihat, semuanya cukup transparan, hanya ada empat entitas dan tiga jenis hubungan di antara mereka. Hasil dari masukan logis disebut Pertentangan, mengkonfirmasikan argumennya adalah Alasan (hubungan karena), argumen lawannya adalah Keberatan (hubungan tetapi), tetapi argumen tandingan untuk argumen tandingan memiliki nama khusus - Sanggahan (namun hubungan tersebut).



Saat ini tidak ada notasi yang diterima secara umum untuk membangun peta argumen. Tidak ada keseragaman dalam notasi yang digunakan untuk struktur argumen. Misalnya, hasil inferensi bisa disebut klaim, pertengkaran, kesimpulan, tujuan. Argumen bisa disebut premis, justifikasi, dll. Ada sejumlah inisiatif dan komunitas internasional di bidang pemodelan argumen (misalnya Argument Interchange Format, AIF), tetapi mereka tidak menyelesaikan pertanyaan tentang penyatuan. Ada penelitian yang menarik kesejajaran antara peta argumen dan peta pikiran (Peta Pikiran, semua orang mungkin pernah mendengarnya). Memang, kemampuan editor Peta Pikiran memungkinkan Anda membangun analog dari peta argumen.

Sejarah dan konsep Assurance Case

Apa hubungan semua ini dengan keamanan? Untuk menjawab pertanyaan ini, mari kita beralih ke paruh kedua abad kedua puluh, di mana teori dan praktik modern untuk memastikan keamanan berasal. Kemudian, sebagai akibat dari perkembangan industri teknogenik yang kompleks, seperti energi nuklir, teknologi luar angkasa, industri minyak dan gas dan kimia, transportasi, umat manusia dihadapkan pada bencana buatan manusia dengan skala yang belum pernah terjadi sebelumnya.



Kemudian laporan analisis keselamatan pertama muncul, yang mengumpulkan semua persyaratan yang relevan, serta informasi yang mengonfirmasi kepatuhannya. Kemudian muncul istilah Safety Case (sebenarnya, sebuah laporan analitis tentang keselamatan), yang merupakan pendahulu dari Assurance Case. Perhatikan bahwa istilah "Kasus Keamanan" atau "Kasus Jaminan" tidak dapat langsung diterjemahkan ke dalam bahasa Rusia; dalam konteks ini, terjemahan yang paling logis adalah "kasus keamanan". Meskipun, misalnya, dalam terjemahan Rusia dari seri standar ISO / IEC 15026 (Sistem dan rekayasa perangkat lunak - Sistem dan jaminan perangkat lunak) "Kasus Jaminan" diterjemahkan sebagai "kasus jaminan".



Perlu dicatat bahwa di beberapa industri istilah Safety Case masih digunakan, bersama dengan Assurance Case. Kasus Jaminan, menjadi istilah yang lebih modern, bertentangan dengan Kasus Keamanan dalam arti bahwa saat ini sistem harus memenuhi tidak hanya persyaratan keselamatan, tetapi juga persyaratan keamanan. Oleh karena itu, diusulkan untuk menggunakan konsep Assurance Case, dan mempertimbangkan Safety Case sebagai kasus khusus.



Assurance Case, dalam pengertian modern istilah ini, berarti laporan tentang analisis keselamatan yang dilakukan, termasuk representasi visual berupa grafik atau tabel yang diperoleh dengan menggunakan notasi semiformal (notasi tersebut akan dibahas di bawah). Pada saat yang sama, beberapa perbedaan dari istilah yang sama diperoleh, karena dimungkinkan untuk menafsirkan Assurance Case, di satu sisi, sebagai dokumen (laporan analisis keselamatan atau laporan kasus keselamatan), dan, di sisi lain, sebagai sistem argumentasi menggunakan notasi semiformal ... Idealnya, Assurance Case dapat mencakup kedua komponen, yaitu dokumen yang mengevaluasi keamanan dibangun atas dasar model argumen.



Namun, mari kita kembali ke abad kedua puluh. Dokumen peraturan pertama yang mensyaratkan pengembangan dan analisis Kasus Keselamatan untuk fasilitas industri yang berpotensi berbahaya adalah Peraturan CIMAH (Pengendalian Bahaya Kecelakaan Utama Industri), yang awalnya dikeluarkan di Inggris pada tahun 1984 dan kemudian diadaptasi di beberapa negara lain. Penerapan Kasus Keselamatan yang lebih luas ke dalam praktik dimulai setelah kecelakaan yang belum pernah terjadi sebelumnya di anjungan minyak Piper Alpha di Laut Utara, yang menewaskan 167 orang pada tahun 1988.



Pada 1990-an, para peneliti terus mencari pendekatan baru untuk menilai keselamatan. Idenya tampaknya berada di permukaan: mari kita kembangkan notasi khusus untuk membenarkan pemenuhan benda dan sistem buatan manusia dengan persyaratan keselamatan. Dua tim universitas Inggris mengambil alih, Universitas London, tempat perusahaan spin-off Adelard dibentuk, dan Universitas York. Saya harus mengatakan bahwa saat ini Adelard dan University of York menempati posisi terdepan dalam promosi Kasus Jaminan.



Untuk pengembangan notasi, penekanan ditempatkan pada penalaran logis bahwa properti atau komponen sistem memenuhi persyaratan yang dinyatakan. Karya Stephen Toulmin, yang telah kami pertimbangkan, dipilih sebagai landasan teoretis. Sebagai seorang humanis, Toulmin hampir tidak memikirkan sistem buatan manusia, namun, ia tercatat dalam sejarah, antara lain, sebagai pendiri argumentasi untuk Kasus Jaminan.



Mengambil notasi Toulmin sebagai dasar, Inggris segera mengembangkan metodologi Kasus Jaminan (disebut Kasus Keamanan pada saat itu) dan membawa hasilnya ke penerapan industri praktis. Di University of York, Goal Structuring Notation (GSN) dikembangkan dan dipromosikan oleh mahasiswa PhD Tim Kelly di bawah bimbingan Profesor John McDermid. Akibatnya, ada kasus langka ketika disertasiMemperdebatkan Keselamatan: Pendekatan Sistematis untuk Mengelola Kasus Keselamatan. Tesis PhD. University of York, 1998 ” telah dianggap klasik selama lebih dari 20 tahun, dan terus dikutip secara aktif. Namun, pendekatan untuk memecahkan masalah keamanan, menurut saya, lebih akademis, dan sebagai hasilnya, untuk beberapa alasan, langkah yang tampaknya dapat dimengerti dan logis tidak diambil terkait dengan pengembangan perangkat lunak untuk mendukung Kasus Jaminan.



Sebaliknya, Adelard, yang dipimpin oleh Robin Bloomfield dan Peter Bishop, lebih mengutamakan komersialisasi hasil. Sejalan dengan York, notasi Claim, Argument and Evidence (CAE) dikembangkan di London, serta perangkat lunak Adelard ASCE.(Assurance and Safety Case Environment), yang mendukung CAE dan GSN. Di Inggris, pengembangan Kasus Jaminan (Kasus Keamanan) diwajibkan oleh undang-undang dan standar di banyak bidang terkait keselamatan, sehingga ASCE memiliki pasar yang cukup kuat di sini. ASCE telah dan tetap menjadi alat pengembangan Kasus Jaminan yang paling banyak digunakan. Bagian utama dari alat ini adalah editor grafik, di mana informasi teks atau hyperlink tambahan dapat dilampirkan ke blok grafik (Gambar 3). Anda tidak dapat mengunduh sendiri perangkat lunak ASCE dari situs web Adelard. Anda harus melengkapi permintaan untuk uji coba 30 hari atau lisensi akademik, setelah itu permintaan akan ditinjau oleh perusahaan.





Gambar 3. Antarmuka program Adelard ASCE



Sekarang mari kita lihat dua notasi dasar yang digunakan untuk mengembangkan Kasus Jaminan (CAE dan GSN).

CAE (Claim, Argument and Evidence) notasi

Notasi CAE (Claim, Argument and Evidence) beroperasi pada tiga entitas yang ditentukan: tujuan menunjukkan pencapaian properti yang diperlukan dari sistem, konfirmasi memberikan dasar yang terdokumentasi untuk argumentasi, menunjukkan pencapaian atau non-pencapaian tujuan, argumen dibangun menggunakan aturan inferensi dan menghubungkan konfirmasi dengan tujuan. Argumen seperti deterministik (atau logis), probabilistik dan kualitatif biasanya digunakan. Untuk menentukan tujuan, argumen dan bukti, diperkenalkan grafik primitif yang memiliki berbagai bentuk (Gambar 4).



Gambar 4. Klaim, Argumen dan Bukti (CAE) Notasi: Komponen Utama



Membangun hierarki tujuan dan sub-tujuan adalah langkah pertama dalam mengembangkan Kasus Jaminan. Seperti yang ditunjukkan pada diagram, struktur tujuan, argumen, dan pernyataan tidak harus bertingkat tiga, misalnya, sub-tujuan tambahan dapat digunakan untuk mendukung argumentasi. Notasi CAE juga mudah diubah menjadi bentuk tabel. Kolom dari tabel seperti itu akan menjadi target, argumen dan konfirmasi yang sama, di antaranya sekarang akan dibuat tautan dalam catatan tabel. Pendekatan serupa untuk pengembangan Kasus Jaminan digunakan, misalnya, oleh exida .

GSN (Notasi Penyusunan Sasaran)

GSN beroperasi dengan komponen seperti tujuan (tujuan, dilambangkan dengan persegi panjang dan merupakan analog dari klaim di CAE), strategi argumentasi (strategi, dilambangkan dengan jajaran genjang dan analog dari argumen), dan solusi (dilambangkan dengan lingkaran dan dianalogikan dengan bukti) (Gambar 5). Konteks digunakan untuk mendukung informasi tujuan. Asumsi dan justifikasi dapat digunakan untuk mendukung argumen tersebut. Struktur tujuan bersifat hierarkis.





Gambar 5. Notasi Struktur Sasaran (GSN): komponen utama



Ketika membandingkan CAE dan GSN, perlu dicatat bahwa CAE lebih memperhatikan alasan argumen individu. Untuk ini, desain rinci langkah-langkah argumentasi dilakukan. GSN lebih berfokus pada struktur (pola) argumen umum. Karena jumlah entitas yang lebih besar, GSN menjadi kurang ketat, dan pada saat yang sama, dengan deskripsi yang lebih ringkas, dapat direduksi menjadi CAE. Penggunaan masing-masing notasi bisa sangat subjektif, karena pendekatan untuk menyusun argumen bergantung pada orang yang melakukan tugas ini. Beberapa praktisi Assurance Case mencatat bahwa ada sejumlah celah dalam notasi yang terkait dengan kelengkapan definisi elemen semantik.



Itu terjadi sehingga saat ini GSN lebih umum. Format GSN tetap dalam standarStandar Komunitas Goal Structuring Notation (GSN) , serta Structured Assurance Case Metamodel (SACM) dari Object Management Group (OMG).

Basis pengetahuan: industri, standar, penelitian, alat, notasi alternatif

Assurance Case digunakan terutama di industri-industri yang penggunaannya diatur oleh dokumen regulasi. Pemimpin di sini adalah Inggris Raya dan beberapa negara Persemakmuran Inggris lainnya. Laporan Yayasan Kesehatan Inggris Menggunakan kasus keselamatan dalam industri dan perawatan kesehatan (2012) menjelaskan pengalaman peraturan Kasus Jaminan (Kasus Keamanan) dalam perawatan kesehatan, penerbangan, tenaga nuklir, otomotif, pertahanan, petrokimia dan industri kereta api.



Mempertimbangkan persyaratan untuk menerapkan Kasus Jaminan di luar Inggris Raya, perlu diperhatikan:

• standar otomotif ISO 26262: 2011, Kendaraan jalan raya - Keselamatan fungsional, bagian dari rangkaian standar keselamatan fungsional yang merinci persyaratan IEC 61508;
• European Organisation for the Safety of Air Navigation (EUROCONTROL): “Safety Case Development Manual, 2006”, “EAD (European Aeronautical Information System Database) Safety Case, 2009”, “EAD (European Aeronautical Information System Database) Safety Case Guidance, 2010”;
• “Licensing of safety critical software for nuclear reactors – Common position of international nuclear regulators and authorised technical support organisations, 2018”, (, , , , , , , , );
• standar seri ISO / IEC 15026, Rekayasa sistem dan perangkat lunak - Jaminan sistem dan perangkat lunak, yang mencakup empat bagian: Bagian 1: Konsep dan kosakata (2019); Bagian 2: Kasus jaminan (2011); Bagian 3: Tingkat integritas sistem (2015); Bagian 4: Assurance in the life cycle (2012).
  
  

Yang juga patut diperhatikan adalah sejumlah organisasi (selain Adelard yang telah disebutkan dan Grup Teknik Sistem Integritas Tinggi dari University of York) yang secara aktif bekerja di bidang Kasus Penjaminan. Ini termasuk:

• US-CERT (Tim Kesiapan Darurat Komputer Amerika Serikat), mereka menyebut metodologi Kasus Jaminan Keamanan ;
• SEI/CMU (Sofrware Engineering Institute – Carnegie Mellon University), , CERT Division, SEI, Assurance Case US-CERT;
• NASA (National Aeronautics and Space Administration) Scientific and Technical Information (STI) Assurance Case ;
• , , John Rushby, SRI International ( Stanford Research Institute), , “The Interpretation and Evaluation of Assurance Cases”, .

Adelard ASCE (Case Case and Safety Case Environment) tetap menjadi perangkat lunak pendukung Assurance Case yang paling terkenal . Sebagian besar proyek yang disebutkan pada tahun yang berbeda belum mencapai tingkat yang serius. NASA mengumumkan pembuatan perangkat lunak AdvoCATE , tetapi mereka menggunakannya untuk tujuan mereka sendiri, dan tidak berencana untuk merilisnya ke pasar. Mengingat kesederhanaan notasi, Anda dapat menggunakan, misalnya, MS Visio untuk membuat diagram Kasus Jaminan dan melengkapinya dengan hyperlink.



Pendekatan alternatif untuk mengembangkan Kasus Jaminan termasuk alat perangkat lunak NOR-STA... Ini akan dikembangkan oleh perusahaan Polandia Argevide (spin-off dari Universitas Teknologi Gdansk). NOR-STA mendukung notasi TRUST-IT-nya sendiri. Perbedaannya adalah bahwa alih-alih representasi grafis, NOR-STA menggunakan daftar hierarki terstruktur (Gambar 6).







Gambar 6. Notasi Trust-IT: Komponen Inti dan



Entitas Studi Kasus dalam daftar hierarki Kasus Assurance daftar tujuan ditunjukkan dengan ikon yang berbeda. Strategi argumentasi digunakan untuk memastikan kepatuhan terhadap pernyataan, dan fakta atau pengamatan, pembenaran, asumsi, dan pernyataan tambahan digunakan sebagai analogi bukti. Berbeda dengan Adelard ASCE desktop, NOR-STA digunakan online dan mendukung kerja tim terdistribusi.



Selain itu, Kasus Jaminan digunakan untuk menyelesaikan aplikasi berikut:

• evaluasi atribut properti kompleks, seperti Quality, Dependability, Security;
• mendukung sertifikasi dan standardisasi dengan mengubah persyaratan standar menjadi struktur argumen;
• Assurance Based Development (ABD) atau pengembangan produk berbasis garansi merupakan bentuk Model Based Development (MBD);
• manajemen pengetahuan, misalnya, memodelkan struktur dokumentasi atau menentukan tautan struktural di area aktivitas apa pun (proses bisnis, alur kerja, manajemen perubahan, dll.).

Kasus Jaminan Keamanan Informasi

Security (Trustworthiness) Case dikenal sebagai salah satu jenis dari Assurance Case. Jika perlu, Kotak Keamanan dapat dilengkapi dengan komponen Kotak Keamanan. Sebenarnya, ide di balik Kasus Assurance adalah menggabungkan atribut keselamatan & keamanan. Di area sertifikasi, terdapat rekam jejak untuk ISO / IEC 15408 (Kriteria Umum), yang persyaratannya telah diubah menjadi struktur yang kompatibel dengan struktur Kasus Jaminan. Konversi ini dapat dilakukan untuk standar relevan lainnya, seperti ISO 27000, atau IEC 62443, atau kerangka kerja lainnya.



Contohnya adalah cuplikan Kasus Jaminan Keamanandiposting di situs US-CERT. Cuplikan ini mengulas bukti implementasi Siklus Hidup Pengembangan Perangkat Lunak (SDLC). Fokusnya adalah menghilangkan cacat pengkodean (khususnya, Buffer Overflow), di mana metode seperti pelatihan programmer, tinjauan kode, analisis dan pengujian statis digunakan. Seseorang dapat, tentu saja, memperdebatkan kelengkapan fragmen ini, tetapi fragmen ini diberikan hanya sebagai ilustrasi (Gambar 7).





Gambar 7. Fragmen Kasus Jaminan Keamanan



Jadi, meskipun keamanan informasi adalah aplikasi di mana Kasus Jaminan paling diminati, perlu dicatat bahwa meskipun potensi dan sejumlah studi percontohan, Kasus Jaminan belum menjadi praktik yang terkenal di bidang ini.

Kasus Jaminan Studi Kasus

Terakhir, mari kita lihat contoh bagaimana ini bisa bekerja. Ini didasarkan pada pendekatan yang didasarkan pada pengembangan argumen terstruktur .

Argumen terstruktur

Mari kita bayangkan proses mengembangkan argumen dalam dua langkah berurutan (Gambar 8). Langkah pertama, disebut Reasoning Step (RS), adalah analisis sub-tujuan (SC), yang ditujukan untuk mencapai tujuan utama (C). Pada tahap ini berkembang struktur argumentasi. Pada langkah kedua, yang disebut Langkah Bukti (ES), konfirmasi (Evidece, E) dirumuskan untuk mendukung sub-tujuan (SC) yang dihasilkan pada langkah sebelumnya. Untuk lebih memformalkan langkah-langkah RS dan ES, templat Teks Terstruktur (ST) yang khas digunakan.





Gambar 8. Langkah dan komponen argumen terstruktur

Hierarki persyaratan

Bayangkan hierarki atau piramida persyaratan yang membentuk struktur yang sesuai dengan kolom Kasus Jaminan. Sebagian besar persyaratan peraturan untuk sistem komputer atau perangkat lunak memiliki struktur persyaratan tingkat 3 atau 4 (Gambar 9).





Gambar 9. Hierarki persyaratan dan hubungannya dengan langkah-langkah argumentasi



Tingkat nol adalah tujuan meta, yang menurutnya sistem yang sedang dinilai harus memenuhi semua persyaratan keamanan. Pada tingkat pertama, tujuan keselamatan global tercapai, misalnya, tujuan berikut mengikuti persyaratan IEC 61508 untuk keselamatan fungsional:

• sistem manajemen keselamatan harus diterapkan;
• selama pengembangan sistem (atau perangkat lunak), siklus hidup keamanan harus diterapkan;
• serangkaian tindakan yang memadai untuk melindungi dari kegagalan yang tidak disengaja harus diterapkan pada sistem;
• untuk sistem (atau perangkat lunak), serangkaian tindakan yang memadai harus diterapkan untuk melindungi dari kegagalan sistematis dan perangkat lunak, termasuk perlindungan terhadap serangan cyber.

Di tingkat kedua, grup persyaratan mendukung tujuan global tertentu. Misalnya, persyaratan manajemen keamanan(menurut IEC 61508) termasuk kelompok persyaratan untuk manajemen personalia, manajemen konfigurasi, manajemen dokumen dan lain-lain. Struktur hubungan antara tingkat nol, pertama dan kedua adalah pohon yang cukup sederhana. Struktur seperti itu tidak memerlukan elaborasi argumen yang rinci, karena argumen ini khas dan telah berulang kali diuji dalam berbagai proyek. Namun, ketika berpindah dari tingkat kedua ke yang lebih rendah, diperlukan argumen terstruktur. Dalam hal ini, persyaratan tingkat yang lebih rendah dapat berupa komposit (yaitu, mencakup sejumlah persyaratan terpisah) atau sederhana (atom). Jika semua persyaratan bersifat atom (tidak ada persyaratan gabungan), maka level ini menjadi yang ketiga, dan kemudian terkait langsung dengan subgrup persyaratan. Jika ada persyaratan majemuk, maka kita mendapatkan struktur empat tingkat yang lebih kompleks.



Untuk level paling bawah, selain RS, ES juga harus diterapkan. Karena tidak nyaman untuk menambahkan informasi rinci tentang konten argumen ke struktur grafik, setiap node dari grafik Assurance Case, mulai dari tingkat kedua, ditandai dengan deskripsi argumen menggunakan teks terstruktur (ST). Grafik Assurance Case tingkat yang lebih rendah tidak lagi berupa pohon karena konfirmasi yang sama (E) dapat mendukung sub-tujuan (SC) yang berbeda.

Kasus Jaminan untuk sekelompok persyaratan SDM (IEC 61508)

Sebagai ilustrasi, pertimbangkan cuplikan Kasus Jaminan dalam kaitannya dengan persyaratan IEC 61508 HR ( IEC 61508-1 klausul 6 ).





Total tujuh persyaratan manajemen personalia diambil dari IEC 61508. Dari sudut pandang argumentasi terstruktur, persyaratan ini adalah sub-tujuan (SC1, ..., SC7). Hanya satu dari sub-tujuan (SC5) yang komposit, yang lainnya atom. Untuk berpindah dari sub-tujuan komposit (SC5) ke atom (SC5.1, ..., SC5.11), satu langkah penalaran lagi (RS) dilakukan. Dipahami bahwa, sesuai dengan persyaratan IEC 61508, Rencana Manajemen Sumber Daya Manusia dikembangkan untuk proyek yang terkait dengan pembuatan produk abstrak. Rencana ini menafsirkan persyaratan standar dalam konteks proyek.





Untuk semua langkah konfirmasi (ES), diusulkan untuk menggunakan teks terstruktur umum yang menunjukkan hubungan antara sub-tujuan (SG) dari konfirmasi (E). Kita akan menggunakan relasi SG -> E untuk menunjukkan relasi antara subgoal (SG) terkait dan konfirmasi (E) yang mendukungnya.





Semua relasi yang diperoleh SG -> E dapat diubah menjadi kolom Assurance Case, menurut notasi GSN, dimodifikasi untuk argumentasi terstruktur (Gambar 10). Grafik ini mencerminkan seluruh kelompok persyaratan yang terkait dengan manajemen personalia sesuai dengan IEC 61508. Grafik ini juga dapat digunakan sebagai template untuk menilai kepatuhan terhadap persyaratan IEC 61508.





Gambar 10. Grafik Kasus Jaminan berasal dari argumen terstruktur untuk sekelompok persyaratan SDM (IEC 61508)



Sekilas, semua ini panjang dan sulit, tetapi, bagaimanapun, Kasus Jaminan memiliki penerapan praktisnya. Ini adalah pendekatan yang kami gunakan saat mensertifikasi RdICS PLC untuk kepatuhan dengan IEC 61508 .

Kesimpulan

Metode Assurance Case (Safety Case) telah digunakan selama lebih dari 20 tahun untuk menganalisis keamanan fasilitas CII. Metode ini paling banyak digunakan di Inggris Raya dan sejumlah negara Persemakmuran Inggris untuk industri seperti perawatan kesehatan, penerbangan, energi nuklir, otomotif, pertahanan, petrokimia, dan industri kereta api.



Keuntungan dari Kasus Penjaminan mencakup semua keuntungan yang dicapai dengan memvisualisasikan hubungan dalam bidang subjek yang kompleks, dengan meningkatkan persepsi dan pemahaman kita. Kerugiannya disebabkan oleh subjektivitas metode dalam hal ketergantungannya pada keahlian orang yang melakukan penilaian. "Kegagalan epik" yang paling terkenal dalam aplikasi Kasus Jaminan dijelaskan di sini... Singkatnya: Pada tanggal 2 September 2006, kebakaran terjadi di Afghanistan di atas Nimrod Angkatan Udara Inggris. Masalahnya muncul dari kebocoran bahan bakar. Semua 14 orang di dalamnya tewas. Laporan Kasus Keselamatan sebelumnya mengonfirmasi keamanan pesawat. Penyelidikan menunjukkan bahwa modifikasi sistem bahan bakar tidak tepat pada pesawat produksi, dan masalah serupa telah muncul sebelumnya, tetapi untuk beberapa alasan tidak ada yang memperhatikannya sebagai kesalahan sistem. Dalam laporan setebal 600 halaman yang dirilis, insiden ini tidak lebih dari "kegagalan kepemimpinan, budaya, dan prioritas".



Omong-omong, notasi grafis tidak digunakan dalam laporan untuk Nimrod. Salah satu akibat dari bencana ini adalah pendalaman penelitian di bidang konstruksi argumentasi. Namun, pendekatan umum yang memuaskan semua orang belum dikembangkan.



Saat ini, pendorong utama implementasi Kasus Penjaminan adalah persyaratan peraturan dan hukum, bukan kenyamanan, kelayakan, atau efektivitas biaya. Jelas, ada peluang besar untuk kecerdasan buatan di bidang Kasus Jaminan, tetapi entah bagaimana saya belum menemukan publikasi tentang topik ini.

Namun demikian, masalah yang terkait dengan penilaian keamanan sistem yang kompleks tetap terbuka. Ada kemungkinan bahwa beberapa kemajuan di bidang ini dapat dicapai dengan penerapan aktif Kasus Penjaminan, karena metode ini didasarkan pada semua poin penting yang telah menduduki umat manusia sejak awal penelitian filosofis.