導入

EBIOS は「ニーズの調査とセキュリティ目標の特定」の略です。 EBIOS 手法は、国家情報システム セキュリティ局 (ANSSI) によって開発された情報システム セキュリティ (SSI) リスク管理手法です。
それにより次のことが可能になります。
リスクに関する連絡や相談もサポートします。
最後に、必要な要素がすべて提供されます。
- リスクの受け入れ(リスクの管理方法と残留リスクについての当局による正式な検証)、
- リスクの監視とレビュー(管理と継続的改善)。
規格に対する位置付け
EBIOS方式は、ISO 27001(情報セキュリティマネジメントシステムの要求事項の規格、ISMS)の要求事項に準拠しています。 ISO 27002(優良事例カタログ)のセキュリティ対策を利用できます。 ISO 31000 (あらゆる分野のリスク管理規格の一般的な枠組み) と互換性があります。 ISO27005で定められた枠組み(情報セキュリティリスク管理の具体的な枠組み)を実現するための手法です。 ISO 15408(共通基準)の利用が可能になります。
アプローチのモジュール
EBIOS は、リスクを管理するための「全地形型」ツールです。実際、プロジェクトの枠組み内で具体的な答えを提供し、管理者向けの成果物を作成したり、製品を研究したりするために使用されます。このアプローチはこれらすべての状況に共通です。したがって、EBIOS を実際の「ツールボックス」として使用することが適切であり、その動作とその使用方法は、研究対象、期待される成果物、およびプロジェクトの状態によって異なります。
EBIOS メソッドは、5 つのモジュールに分割されたリスク管理アプローチを形式化しています。
- 背景の研究: なぜ、どのようにリスクを管理するのか、そして研究の主題は何なのか?
- 恐れられている出来事の研究: 専門家はどのような出来事を恐れており、どれが最も深刻でしょうか?
- 脅威シナリオの研究: 考えられるすべてのシナリオは何ですか? 最も可能性が高いのはどれですか?
- リスク調査: リスクマップとは何ですか?また、リスクの治療方法はどのように選択すればよいですか?
- セキュリティ対策の検討: どのような対策を適用する必要があるか、また残留リスクは許容できるか?
モジュール 1 – コンテキストの検討
このモジュールは、リスク管理に必要な要素を収集することを目的としています。これにより、リスク管理が良好な条件で実装され、研究状況の現実に適応し、その結果が関係者にとって関連性があり利用できるようになります。
特に、研究が実施されるリスク管理枠組みを形式化することが可能になります。また、研究の範囲だけでなく、その問題、その使用状況、その特定の制約などを特定し、範囲を定め、説明することも可能になります。
したがって、このモジュールの最後には、他のモジュールで考慮すべきすべてのパラメータと同様に、研究の調査分野が明確に定義および説明されます。
このモジュールには次のアクティビティが含まれます。
- アクティビティ1.1 – リスク管理フレームワークを定義する
- アクティビティ 1.2 – メトリクスを準備する
- アクティビティ 1.3 – 資産を特定する
モジュール 2 – 恐れられている出来事の研究
このモジュールは、研究の範囲に関して避けたい一般的なシナリオ、つまり恐れられている出来事を体系的に特定することを目的としています。議論は技術的なレベルよりも機能的なレベルで行われます(サポート商品ではなく必須商品について)。
まず、各要素を特定して組み合わせることで、恐れられているすべての出来事を明らかにすることが可能になります。こうして、私たちが守りたいものの価値(必需品のセキュリティニーズ)を推定し、私たちが直面している脅威の原因を強調し、災害の結果(影響)。これにより、恐れられている各イベントのレベル (重大度と可能性) を推定することが可能になります。
また、既存のセキュリティ対策を特定し、セキュリティ対策が適用された後に懸念されるイベントの重大度を再評価することでその効果を推定することも可能になります。
このモジュールの最後では、恐れられている出来事が特定され、説明され、深刻さと可能性の観点から相互に関連付けられます。
モジュールには次のアクティビティが含まれています。
- アクティビティ 2.1 – 恐れられた出来事を感謝する
モジュール 3 – 脅威シナリオの検討
このモジュールは、調査の範囲である脅威シナリオ内で、情報のセキュリティを損なう可能性のある一般的な操作方法を体系的に特定することを目的としています。議論は機能レベルよりも技術的なレベルで行われます(サポート品と必須ではなくなった製品について)。
まず、各コンポーネントを特定して組み合わせることで、すべての脅威シナリオを明らかにすることができます。これにより、調査の範囲に影響を与えるさまざまな脅威、およびそれらを実現するために悪用される可能性のある脆弱性が強調表示されます。サポート資産の脆弱性)、およびそれらを利用する可能性のある脅威の発生源。これにより、各脅威シナリオのレベル(その可能性)を推定することが可能になります。
また、既存のセキュリティ対策を特定し、セキュリティ対策が適用された後に脅威シナリオの可能性を再推定することでその効果を推定することも可能になります。
このモジュールの最後では、脅威シナリオが特定され、説明され、可能性の観点から相互に関連付けられます。
モジュールには次のアクティビティが含まれています。
- アクティビティ 3.1 – 脅威シナリオを評価する
モジュール 4 – リスク調査
このモジュールは、調査範囲に重くのしかかるリスクを体系的に強調し、状況の特殊性を考慮してそれらに対処する方法を選択することを目的としています。議論は技術的なレベルよりも機能的なレベルで行われます。
このモジュールは、恐れられる出来事とそれを引き起こす可能性のある脅威シナリオを関連付けることにより、調査の範囲に真に関連するシナリオのみを特定することを可能にします。また、優先順位を付けて適切な治療オプションを選択することを目的として、患者を明示的に認定することもできます。
このモジュールの最後では、リスクが評価および評価され、治療法の選択が行われます。
このモジュールには次のアクティビティが含まれます。
- アクティビティ 4.1 – リスクを評価する
- アクティビティ 4.2 – セキュリティ目標を特定する
モジュール 5 – セキュリティ対策の検討
このモジュールは、研究の内容に沿って、リスクに対処し、その実施を監視する手段を決定することを目的としています。反映は、機能レベルと技術レベルの間で共同で実行されることが好ましい。
これにより、事前に特定された目的に従って、リスクに対処することを目的としたセキュリティ対策に関する合意を見つけ、正しい適用範囲を実証し、最終的には治療の計画、実装、検証を実行することが可能になります。
このモジュールの最後では、セキュリティ対策が決定され、重要なポイントが正式に検証されます。導入状況のモニタリングも可能です。
このモジュールには次のアクティビティが含まれます。
- アクティビティ 5.1 – 実装するセキュリティ対策を正式に策定する
- アクティビティ 5.2 – セキュリティ対策を実装する
