前回（その２）は、リスク分析について深くご紹介しました。
大きく、６種類のステップでやることをご紹介します。
- Step 1 : 資産の特定
- Step 2 : 脅威の特定
- Step 3 : 脆弱性の特定
- Step 4 : 残存リスクの特定
- Step 5 : 発生確率・影響度の決定
- Step 6 : アウトプット作成
上記のプロセスは、上記のプロセスは、NIST SP800-30 "Managing Information Security Risk"におけるリスクマネジメントプロセスにおいて、「Assess」フェーズに該当します。今回は、残りの二つのプロセス「Respond」と「Monitor」をご紹介します。
リスク管理プロセス：Respondフェーズ
リスク分析を経てリスクを特定した後は、リスクへの対応を行います。リスク対応戦略は大きく４種類存在します。一般的には、リスク低減 → リスク受容をすることが一般的な戦略となります。
- リスク低減（Risk Mitigation）
- セキュリティコントロールの導入などにより、リスクを低減することを意味します。
- リスク受容（Risk Acceptance）
- 経営層の判断に基づき、残存リスクを受容することを意味します。
- リスク転移（Risk Transfer）
- リスクを第三者（3rd Party）に転移することを意味します。例えば、サイバー保険の活用や、サードパーティ製品・サービスの活用を意味します。*1
- リスク回避（Risk Avoidance）
- リスク、もしくはリスクの原因を取り除くことを意味します。例えば、ご送信のリスクを避けるために、メールでの顧客とのやり取りを禁止するなどが挙げられます。
５種類のセキュリティコントロール
リスク低減（Risk Mitigation）において、セキュリティコントロールを実装することが一般的です。分類は様々ですが、セキュリティコントロールは複数のカテゴリーに分類されます*2。
- 指揮的コントロール（Directive・Deterrent）
- 望ましい行動を促進したり、望ましくない行動を抑制するように指定・指示コントロール
- 例）ルール・啓発研修
- 予防的コントロール（Preventive）
- 特定の悪意のある行動を禁止・制限・抑止するコントロール
- 例）FW・アクセスコントロール
- 発見的コントロール（Detective）
- 悪意のある行動を検知するコントロール
- 例）IDS・EDR
- 訂正的コントロール（Corrective・Recovery）
- 発見的コントロールで検知された事象を修正・是正するコントロール
- 例）バックアップ
- 代替コントロール（Compensating）
- あるコントロールが正当な理由で取れない場合、リスクを低減するために取る代替策のこと
ここでのポイントは、多層防御（Defense-In-Depth）の観点から、複数種類のコントロールを組み合わせていくことが重要だとされています。例えば、アクセスコントロールによる予防的コントロールを実装した後、ログ監視による発見的コントロールを入れるなど組み合わせていくことが重要です。
リスク管理プロセス：Monitorフェーズ
さて、リスクマネジメントプロセスにおける最後のフェーズはモニタリングです。これは、以下の観点から、リスクと対応を監視し、何か変化があればリスク分析・リスク対応をやり直していくというプロセスです。
- 「リスク対応戦略が適切か？」
- 「セキュリティコントロールの実効性はあるか？」
- 「新しいリスクが登場していないか？」
リスク管理プロセスに関するまとめ
さて、上記の結果から、リスクマネジメントとは、リスク分析 → リスク対応 → リスクモニタリングを行っていくことだと言えます。そのため、リスク管理とはこの地道なプロセスを繰り返してく、PDCAサイクルにほかなりません。
さて、リスク分析・管理について少し補足しておきましょう。
補論１：リスク分析の簡略化について
第１回では、リスクとは、「脅威 × 脆弱性 × 資産」と紹介しました。しかし、一部のリスク分析では、「脅威 × 脆弱性」だけでリスク分析をする、さらにはCSCなどのフレームワークを使い、実質的に脆弱性だけでリスク評価をする場合もあります。
このように、リスク分析は簡略化をすることができます。
例えば、「資産は複数種類存在しない」、「いずれの資産も情報漏洩すればビジネス上大きな影響がある」など資産分析の種類によって分析結果がぶれない場合、省略することは可能です。
また、脅威についても、省略することが可能です。例えば、「脅威として特定のシナリオを想定している」、あるいは「いずれの脅威に対しても全力で対応する必要がある」などの場合、脅威をいくら考えても仕方ない場合があります。そうした場合、省略をすることが可能です。
特に、資産・脅威という二つのパラメータは、防御側でコントロールが難しいパラメータです。（一応、資産は防御側で管理できるパラメータなのですが、「これは非常にリスクが高い資産なので破棄しましょう」と主張したところでビジネス側は絶対に受け入れないでしょう）。そのため、当該２つのパラメータについては整理さえできれば簡略化することができます。
補論２：チェックリストアプローチ vs. シナリオベースアプローチ
上記のように、リスク分析を簡略化し、CSCによる「脆弱性」評価だけによるリスク分析をよくチェックリストアプローチと呼ぶことがあります。ようするに、CSCなどのチェックリストを用意し、YES/NO、あるいは５段階評価などで成熟度を測っていく方法です。このアプローチ自体は、簡単にでき、なにをやらなければいけないか明確にできるアプローチであるためとっかかりとしては非常に良いでしょう。下記記事で紹介した、CIS CSATは典型的なチェックリストアプローチのツールです。
しかし、これだけに頼ることは推奨しません。むしろ、CSCなどの棚卸をネットワーク図に当てはめ、攻撃シナリオを意識しながら分析していく、シナリオベースアプローチを利用することをを推奨します。そうしないと、落とし穴が生まれてしまう可能性があるためです。
例を挙げて説明します。例えば、ある企業Xは重要な業務システム・業務データをすべてクラウドに依存しているとしましょう。一方、チェックリストアプローチでチェックすると、（社内OA環境については）全て完璧に対策をできていました。この場合、正しいリスク分析はできているといえるでしょうか。
答えはNOです。上記の場合、一つの攻撃シナリオとしては、クラウドへの攻撃を考えるべきです。しかし、チェックリストに集中してしまい、「どんなネットワークか？」、「実際の攻撃シナリオは何か？」という点をおろそかにすると、本質を見失います。そのため、チェックリストアプローチは重要なアプローチですが、きちんと本質を見失いように攻撃シナリオを意識しながら分析していくことが必要になります。
参考文献
- 政府におけるRisk Management Framework（解説資料）
まとめ
さて、今回は「リスク分析・管理」の最終回ということで、リスクマネジメントプロセスの残りのフェーズについてご紹介しました。また、シナリオベースアプローチの重要性についてもお話をしました。
このように、リスク分析・リスク管理はセキュリティ施策の基礎となる方法ですが、こうした考えがあまり明確に書かれている資料がないため、ご参考になれば幸いです。
