保証ケース：合理的な安全ケース

ソース



何も見逃さずにセキュリティを評価するための最良の方法は何ですか？さまざまなセキュリティアーティファクトをすべて1つのドキュメント（または図）に収集し、あらゆる側面を理解可能な詳細レベルで視覚化できるように整理することは可能ですか？



技術者は、たとえそれがセキュリティを提供しなかったとしても、少なくとも必要なレベルの完全性でそれを評価するような「哲学者の石」を喜んで発明するでしょう。このような開発は20年以上前から存在していますが、ロシア語を話す読者には事実上知られていません。これは、保証ケース（または安全ケース）の方法論に関するものです。これは、システムまたはサービスが特定の要件に準拠していることを正当化する、構造化された一連の引数と文書による証拠を意味します。

前書き

記事を読む前に、いくつかの重要な点に注意を向けたいと思います。記載されている資料は、まず第一に、重要な情報インフラストラクチャ（CII）のオブジェクトに適用できます。このようなオブジェクト、特に情報および制御システムの場合、セキュリティ分析を実行する必要があります。安全性分析の結果は、適切なレポートの形式で提示されます。これはすべて何十年にもわたって行われてきましたが、レポートには原則として任意のテキスト形式があり、その論理は必ずしも理解しやすいとは限りません。



提示されたアプローチの主なアイデアは、セキュリティ分析の結果をセミフォーマル表記を使用してグラフ形式で提示できることであり、その後のすべての利点があります。したがって、Assurance Caseは、テスト、静的コード分析、信頼性計算、FMEA、リスク分析などのプライベートな方法を置き換えたりキャンセルしたりすることなく、セキュリティを確保および評価するためのすべての手段を統合的に表示する方法です。この記事は、以前に公開されたセキュリティに関するシリーズの続きです。

議論の地図とその哲学的起源

あるオブジェクトが安全であるとどのように理解または主張できますか？明らかに、これにはいくつかの基準を導入する必要があります。ただし、これらの基準については、オブジェクトに関する知識の信頼性を判断する必要がありますか？なぜこの知識を信頼できるのでしょうか。何が私たちの推論と推論を本当に信頼できるものにしますか？そのような問題を掘り下げてみると、オントロジー、エピステモロジー、エピステモロジー、ロジックなどの哲学的分野がなければ、またこれらの質問を心配していた偉大な思想家がいなければ、何もできません。古代の世界では、アリストトルやプラトがそのようなものでした。「現代」の時代には、フランシス・ベーコンは現代の科学的手法の創始者と見なされています。



合理的かつ論理的な方法で安全性を正当化または評価するために何ができるでしょうか？このアプローチは、議論の理論に基づいています。議論の現代的発展への新たな推進力は、1958年に出版された「議論の使用」と題された英国の哲学者スティーブン・トゥールミンの作品に与えられました。 Tulminは、追加のパラメーターを使用して論理的な含意推論を拡張し、この操作をグラフ形式で表すことを提案しました。 Tulminの表記は、次のエンティティで機能します。データ（D）-分析用の初期データ、クレーム（）-論理的含意推論の目的（D So Cの場合）、保証（W）-追加の引数、修飾子（Q）-論理結果の信頼度出力、反論可能（R）は、追加の反論です（図1）。





図1.StephenTulminによる表記



Toulminへの視覚化と推論の目的で使用される引数のマップ または引数（Argument the Map）が、引数の分析と検証のための構造モデルを最もうまく要約したのは彼でした。最新の引数マップは、原則としてTulminの表記を使用しないことに注意してください。たとえば、次の図のように、すべてが簡略化されています。これは、有料のオンラインサービスRationalで使用される表記法です（無料バージョンがありますが、機能が非常に制限されています）（図2）。有料版では、結果の図を論理的に構造化されたテキストに変換できます。批判的思考と議論のマッピングに関する無料のガイドとチュートリアルもサイトで利用できます。





図2.サービスで開発された引数マップ合理的



ご覧のとおり、すべてが非常に透過的であり、エンティティは4つだけで、それらの間には3つのタイプの関係があります。論理入力の結果は競合と呼ばれ、引数-理由（接続のため）、反論-異議（接続が）を確認しますが、反論の反論には特別な名前-反論（ただし接続）があります。



現在、引数マップを作成するための一般的に受け入れられている表記法はありません。引数の構造に使用される表記法に統一性はありません。たとえば、推論結果は、クレーム、競合、結論、目標と呼ぶことができます。引数は、前提、正当化などと呼ぶことができます。引数モデリングの分野には、多くの国際的なイニシアチブとコミュニティがあります（例：引数交換フォーマット、AIF）、しかし彼らは統一の問題を解決しませんでした。議論マップとマインドマップの間に類似点を描く研究があります（マインドマップ、おそらく誰もがそれらについて聞いたことがあるでしょう）。実際、マインドマップエディタの機能を使用すると、引数マップの類似物を作成できます。

保証ケースの履歴と概念

これはすべてセキュリティと何の関係がありますか？この質問に答えるために、セキュリティを確保するという現代の理論と実践が始まった20世紀の後半に目を向けましょう。その後、核エネルギー、宇宙技術、石油・ガス、化学産業、輸送などの複雑な技術産業の発展の結果として、人類は前例のない規模の人為的な災害に直面しました。



次に、最初の安全性分析レポートが表示され、関連するすべての要件と、それらのコンプライアンスを確認する情報がまとめられました。その後、アシュアランスケースの前身であるセーフティケース（実際には、安全性に関する分析レポート）という用語が登場しました。 「安全ケース」または「保証ケース」という用語をロシア語に直接翻訳することはできないことに注意してください。この文脈では、最も論理的な翻訳は「安全ケース」です。たとえば、ISO / IEC 15026シリーズの標準のロシア語訳（システムおよびソフトウェアエンジニアリング-システムおよびソフトウェア保証）では、「保証ケース」は「保証ケース」として翻訳されます。



一部の業界では、安全ケースという用語が保証ケースとともに使用されていることに注意してください。より現代的な用語であるAssuranceCaseは、今日のシステムが安全性（機能的安全性）だけでなくセキュリティ（情報セキュリティ）にも準拠する必要があるという意味で、SafetyCaseとは対照的です。したがって、保証ケースと安全ケースの概念を使用して、それを特別なケースと見なすことを提案します。



保証ケースとは、この用語の現代的な意味で、セミフォーマル表記を使用して取得された、グラフまたは表の形式での視覚的表現を含む、実行された安全性分析に関するレポートを意味します（表記については以下で説明します）。同時に、保証ケースを文書（安全分析レポートまたは安全ケースレポート）として解釈することが可能であり、他方ではセミフォーマル表記を使用する議論システムとして解釈することができるため、同じ用語のいくらかの矛盾が得られます。 ..。理想的には、保証ケースには両方のコンポーネントを含めることができます。つまり、セキュリティを評価するドキュメントは、引数モデルに基づいて作成されます。



しかし、20世紀に戻りましょう。潜在的に危険な産業施設のセーフティケースの開発と分析を要求する最初の規制文書は、1984年に英国で発行され、その後他のいくつかの国で採用されたCIMAH（産業重大事故ハザードの管理）規制でした。1988年に167人が死亡した北海のパイパーアルファ石油プラットフォームでの前例のない事故の後、実際のセーフティケースのより広範な実施が始まりました。



1990年代、研究者たちは安全性を評価するための新しいアプローチを模索し続けています。アイデアは表面上にあるようです。人工のオブジェクトやシステムが安全要件に準拠していることを正当化するための特別な表記法を開発しましょう。スピンオフ会社Adelardが設立されたロンドン大学とヨーク大学の2つの英国の大学チームが引き継ぎました。今日、アデラードとヨーク大学は、アシュアランスケースの推進において主導的な地位を占めていると言わなければなりません。



表記法の開発では、システムのプロパティまたはコンポーネントが指定された要件を満たしているという論理的な推論に重点が置かれました。すでに検討したスティーブン・トゥールミンの作品が理論的根拠として選ばれました。人道主義者として、トゥールミンは人工システムについてほとんど考えませんでした、しかし、彼は、とりわけ、保証事件の議論の創設者として歴史に名を残しました。



Toulminの表記法を基礎として、英国はすぐにAssurance Case手法（当時はSafety Caseと呼ばれていました）を開発し、その結果を実際の産業実装にもたらしました。ヨーク大学では、目標構造表記（GSN）が、ジョン・マクダーミッド教授の指導の下、博士課程の学生であるティム・ケリーによって開発および推進されました。その結果、論文が安全性の主張：安全ケースを管理するための体系的なアプローチ。博士論文。ヨーク大学、1998年」は20年以上にわたって古典と見なされており、引き続き積極的に引用されています。しかし、私の意見では、セキュリティ問題を解決するためのアプローチはより学術的であり、その結果、何らかの理由で、AssuranceCaseをサポートするソフトウェアツールの開発に関連して一見理解できる論理的なステップが取られませんでした。



対照的に、ロビン・ブルームフィールドとピーター・ビショップが率いるアデラードは、主に結果の商品化に関心を持っていました。ヨークと並行して、Claim、Argument and Evidence（CAE）という表記がロンドンで開発され、AdelardASCEソフトウェアツールも開発されました。（Assurance and Safety Case Environment）、CAEとGSNの両方をサポートします。英国では、多くの安全関連分野の法律や基準により、保証ケース（安全ケース）の開発が義務付けられているため、ASCEはここでかなり強い市場を持っています。 ASCEは、これまでも、そして今も最も使用されているAssuranceCase開発ツールです。ツールの主要部分はグラフィックエディタであり、追加のテキストまたはハイパーリンク情報をグラフィックブロックに添付できます（図3）。 ASCEソフトウェアをAdelardのWebサイトから自分でダウンロードすることはできません。 30日間のトライアルまたはアカデミックライセンスのリクエストを完了する必要があります。その後、リクエストは会社によって確認されます。





図3.AdelardASCEプログラムのインターフェース



次に、保証ケースの作成に使用される2つの基本的な表記法（CAEとGSN）を見てみましょう。

CAE（クレーム、引数、および証拠）表記

CAE（Claim、Argument and Evidence）表記は、指定された3つのエンティティで機能します。目標はシステムの必要なプロパティの達成を示し、確認は議論の文書化された基礎を提供し、目標の達成または未達成を示します。議論は推論ルールを使用して構築され、接続します。目的を持った確認。決定論的（または論理的）、確率論的、定性的などの議論が一般的に使用されます。目標、議論、証拠を指定するために、さまざまな形のグラフィカルプリミティブが導入されています（図4）。



図4.クレーム、引数、および証拠（CAE）表記：主要コンポーネント



目標とサブ目標の階層を構築することは、保証ケースを作成するための最初のステップです。図に示されているように、目標、引数、およびアサーションの構造は必ずしも3層である必要はありません。たとえば、追加のサブ目標を使用して引数をサポートできます。CAE表記も簡単に表形式に変換できます。このようなテーブルの列はすべて同じターゲット、引数、および確認になり、それらの間でリンクがテーブルレコード内に確立されます。保証ケースの開発への同様のアプローチは、例えば、exidaによって使用されます。

GSN（目標構造表記）

GSNは、目標（長方形で示され、CAEの主張の類似物である目標）、議論戦略（平行四辺形で示され、議論の類似物である戦略）、および解決策（円で示され、証拠に類似している）などのコンポーネントで動作します（図5）。コンテキストは、目標の情報サポートに使用されます。仮定と正当化は、議論をサポートするために使用できます。目標の構造は階層的です。





図5.目標構造化表記（GSN）：主要コンポーネント



CAEとGSNを比較する場合、CAEは個々の引数の論理的根拠にさらに注意を払うことに注意してください。このために、議論のステップの詳細な設計が実行されます。 GSNは、一般的な引数構造（パターン）に重点を置いています。エンティティの数が多いため、GSNはそれほど厳密ではありませんが、同時に、より簡潔な説明で、CAEに減らすことができます。引数を作成するアプローチはこのタスクを実行する人に依存するため、各表記の使用は非常に主観的である可能性があります。一部のアシュアランスケースの実務家は、セマンティック要素の定義の完全性に関連する表記法には多くのギャップがあることに注意しています。



今日GSNがより一般的になるように起こった。 GSNフォーマットは標準で修正されましたGoal Structuring Notation（GSN）Community Standard、およびObject Management Group（OMG）のStructured Assurance Case Metamodel（SACM）データモデル。

知識ベース：業界、標準、研究、ツール、代替表記

アシュアランスケースは、主にその使用が規制文書によって規制されている業界で使用されます。ここでのリーダーは、イギリスとイギリス連邦の他のいくつかの国です。UK Health Foundationのレポート「産業とヘルスケアにおける安全ケースの使用」（2012）は、ヘルスケア、航空、原子力、自動車、防衛、石油化学、鉄道業界における保証ケース（安全ケース）の規制経験について報告しています。



英国外で保証ケースを適用するための要件を考慮すると、次の点に注意する必要があります。

• 自動車規格ISO26262：2011、道路車両-機能安全、IEC61508の要件を詳述する機能安全規格ファミリーの一部。
• 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”, (, , , , , , , , );
• ISO / IEC 15026シリーズの標準、システムおよびソフトウェアエンジニアリング-システムおよびソフトウェアの保証。これには4つの部分が含まれます。パート1：概念と語彙（2019）。パート2：保証ケース（2011）; パート3：システム整合性レベル（2015）; パート4：ライフサイクルの保証（2012）。
  
  

また、アシュアランスケースの分野で積極的に活動している多くの組織（すでに述べたAdelardとヨーク大学のHigh Integrity Systems Engineering Groupを除く）も注目に値します。これらには以下が含まれます：

• US-CERT（United States Computer Emergency Readiness Team）、彼らは彼らの方法論をセキュリティ保証ケースと呼んでいます。
• 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（ケースケースおよびセーフティケース環境） は、依然として最もよく知られているアシュアランスケースサポートソフトウェアです。異なる年に言及されたプロジェクトのほとんどは、深刻なレベルに達していません。 NASAはAdvoCATEソフトウェアの作成を発表しましたが、彼らはそれを独自の目的で使用しており、市場にリリースする予定はありません。表記が単純なため、たとえば、MS Visioを使用して、保証ケース図を作成し、ハイパーリンクで補足することができます。



Assurance Caseを開発するための代替アプローチには、NOR-STAソフトウェアツールが含まれます。..。これは、ポーランドの会社Argevide（Gdansk University of Technologyのスピンオフ）によって開発されます。 NOR-STAは、独自のTRUST-IT表記をサポートしています。違いは、NOR-STAはグラフィカル表現の代わりに、構造化された階層リストを使用することです（図6）。







図6.Trust-IT表記：コアコンポーネントと使用例



保証ケースのエンティティの階層リストは、さまざまなアイコンで示されています。議論戦略は、声明の遵守を確認するために使用され、事実または観察、正当化、仮定、および追加の声明は、証拠の類似物として使用されます。デスクトップのAdelardASCEとは異なり、NOR-STAはオンラインで使用され、分散チームワークをサポートします。



さらに、保証ケースは、次のアプリケーションを解決するために使用されます。

• 品質、信頼性、セキュリティなどの複雑なプロパティの属性を評価する。
• 標準の要件を引数構造に変換することにより、認証と標準化をサポートします。
• 保証ベースの開発（ABD）または保証ベースの製品開発は、モデルベース開発（MBD）の形式です。
• 知識管理。たとえば、ドキュメントの構造をモデル化したり、アクティビティの任意の領域（ビジネスプロセス、ワークフロー、変更管理など）で構造的なリンクを決定したりします。

情報セキュリティの保証ケース

セキュリティ（信頼性）ケースは、保証ケースの種類の1つとして知られています。必要に応じて、セキュリティケースにセーフティケースコンポーネントを追加できます。実際、保証ケースの背後にある考え方は、安全性とセキュリティの属性を組み合わせることです。認証分野では、ISO / IEC 15408（一般基準）規格の開発が行われており、要件は保証ケース構造と互換性のある構造に変換されています。この変換は、ISO 27000、IEC 62443、またはその他のフレームワークなど、他の関連する標準に対して実行できます。



例は、セキュリティ保証ケースのスニペットです。US-CERTのWebサイトに掲載されています。このスニペットは、ソフトウェア開発ライフサイクル（SDLC）の実装の証明を確認します。焦点は、プログラマーのトレーニング、コードレビュー、静的分析、テストなどの方法が使用されるコーディングの欠陥（特に、バッファーオーバーフロー）の排除にあります。もちろん、このフラグメントの完全性について議論することはできますが、これは説明としてのみ提供されています（図7）。





図7.セキュリティ保証ケースのフラグメント



したがって、情報セキュリティは、保証ケースが最も需要のあるアプリケーションですが、その可能性と多くのパイロット調査にもかかわらず、保証ケースはこの分野でよく知られた慣行になっていないことに注意してください。

ケーススタディ保証ケース

最後に、これがどのように機能するかの例を見てみましょう。これは、構造化された引数の開発に基づくアプローチに基づいています。

構造化された引数

2つの連続したステップで引数を作成するプロセスを想像してみましょう（図8）。推論ステップ（RS）と呼ばれる最初のステップは、メインゴール（C）の達成を目的としたサブゴール（SC）の分析です。この段階で、議論の構造が発展します。エビデンシャルステップ（ES）と呼ばれる2番目のステップでは、前のステップで生成されたサブゴール（SC）をサポートするために、確認（Evidece、E）が作成されます。RSおよびESステップをさらに形式化するために、一般的な構造化テキスト（ST）テンプレートが使用されます。





図8.構造化された引数のステップとコンポーネント

要件の階層

AssuranceCase列に対応する構造を形成する要件の階層またはピラミッドを想像してみてください。コンピュータシステムまたはソフトウェアのほとんどの規制要件には、3または4レベルの要件構造があります（図9）。





図9.要件の階層と、議論のステップとの関係



レベル0はメタ目標であり、評価対象のシステムはすべてのセキュリティ要件を満たす必要があります。最初のレベルでは、グローバルな安全目標が達成されます。たとえば、機能安全に関するIEC61508の要件から次の目標が続きます。

• 安全管理システムを実装する必要があります。
• システム（またはソフトウェア）の開発中に、セキュリティライフサイクルを適用する必要があります。
• 偶発的な障害から保護するための十分な一連の対策をシステムに適用する必要があります。
• システム（またはソフトウェア）の場合、サイバー攻撃からの保護を含め、体系的およびソフトウェアの障害から保護するために十分な一連の対策を適用する必要があります。

2番目のレベルでは、要件グループは特定のグローバル目標をサポートします。たとえば、セキュリティ管理要件（IEC 61508に準拠）には、人事管理、構成管理、ドキュメント管理などの要件のグループが含まれます。ゼロ、第1、第2レベル間のリンクの構造は、かなり単純なツリーです。これらの引数は典型的であり、さまざまなプロジェクトで繰り返しテストされているため、この構造では引数の詳細な詳細は必要ありません。ただし、第2レベルから下位レベルに移動する場合は、構造化された引数が必要です。この場合、下位レベルの要件は、複合（つまり、いくつかの個別の要件を含む）または単純（アトミック）にすることができます。すべての要件がアトミックである場合（複合要件がない場合）、このレベルは3番目になり、要件のサブグループに直接関連します。複合要件がある場合は、より複雑な4レベルの構造になります。



最も低いレベルでは、RSの他に、ESも適用する必要があります。引数の内容に関する詳細情報をグラフの構造に追加するのは不便であるため、保証ケースグラフの各ノードは、第2レベルから始まり、構造化テキスト（ST）を使用して引数の説明でマークされます。同じ確認（E）で異なるサブゴール（SC）をサポートできるため、下位レベルの保証ケースグラフはツリーではなくなりました。

HR要件のグループの保証ケース（IEC 61508）

例として、IEC 61508 HR要件（IEC 61508-1条項6）に関連するAssuranceCaseスニペットについて考えてみます。





合計7つの人事管理要件がIEC61508から抽出されました。構造化された議論の観点から、これらの要件はサブ目的です（SC1、...、SC7）。サブゴールの1つ（SC5）のみが複合であり、他のすべてはアトミックです。複合サブゴール（SC5）からアトミック（SC5.1、...、SC5.11）に移動するために、推論のもう1つのステップ（RS）が実行されます。IEC 61508の要件に従って、抽象的な製品の作成に関連するプロジェクトのために人的資源管理計画が作成されたことが理解されます。この計画は、プロジェクトのコンテキストで標準の要件を解釈します。





すべての確認ステップ（ES）について、確認（E）のサブゴール（SG）間のリンクを示す共通の構造化テキストを使用することが提案されています。SG-> Eの関係を使用して、対応するサブゴール（SG）とそれをサポートする確認（E）の間の関係を示します。





構造化された引数用に変更されたGSN表記に従って、取得されたすべての関係SG-> Eを保証ケース列に変換できます（図10）。このグラフは、IEC 61508に準拠した人事管理に関連する要件のグループ全体を反映しています。このグラフは、IEC61508の要件への準拠を評価するためのテンプレートとしても使用でき





ます。図10.HR要件のグループの構造化された引数から導出された保証ケースグラフ（IEC 61508）



一見、これはすべて長くて難しいですが、それにもかかわらず、保証ケースはその実用的なアプリケーションを持っています。これは、RdICSPLCがIEC61508に準拠していることを証明するときに使用したアプローチです。

結論

アシュアランスケース（セーフティケース）方式は、CII施設の安全性を分析するために20年以上使用されてきました。この方法は、英国および英国連邦諸国の多くで、ヘルスケア、航空、核エネルギー、自動車、防衛、石油化学、鉄道などの業界で最も広く使用されています。



アシュアランスケースの利点には、私たちの認識と理解を向上させることにより、複雑な主題領域の関係を視覚化することによって達成されるすべての利点が含まれます。不利な点は、評価を実行する人の専門知識に依存するという点で、メソッドの主観性によるものです。 AssuranceCaseアプリケーションで最も有名な「エピックフェイル」についてここで説明します..。つまり、2006年9月2日、英国空軍ニムロッドに乗ってアフガニスタンで火災が発生しました。問題は燃料漏れから生じました。乗船していた14人全員が死亡した。以前のセーフティケースレポートは、航空機の安全性を確認しました。調査の結果、生産機では燃料系統の変更が正しくなく、以前にも同様の問題が発生していたが、何らかの理由でシステムエラーとして注目されていなかった。発表された600ページのレポートでは、この事件は「リーダーシップ、文化、優先事項の失敗」に過ぎないと名付けられました。



ちなみに、ニムロッドのレポートではグラフィカルな表記は使用されていません。この大惨事の結果の1つは、議論の構築の分野での研究の深化でした。しかし、すべての人を満足させる一般的なアプローチは開発されていません。



今日、アシュアランスケースの実装の主な推進力は、利便性、実現可能性、費用対効果ではなく、規制および法的要件です。明らかに、保証事件の分野では人工知能の絶好の機会がありますが、どういうわけか私はこのトピックに関する出版物に出くわしていません。

それにもかかわらず、複雑なシステムのセキュリティの評価に関連する問題は未解決のままです。この方法は、哲学的研究の当初から人類を占領してきたすべての重要なポイントに基づいているため、この分野でのある程度の進歩は、保証ケースの積極的な実施によって達成できる可能性があります。