２. セキュリティリスク分析の概要
2.
2.1. セキュリティリスク分析の必要性
事業における情報セキュリティを確保するためには、対象システムが担う業務や取り扱う情報、そして情報システムの特性に応じてリスクが異なるため、リスク分析が必要となる。リスク分析の結果は、リスクへの対処法や、講ずべき対策の程度を決定するための根拠として使用する。
実際にリスク分析を行って正しい結果を得るためには、リスク分析手法の習得や実務経験が必要となる。もし、分析手法の理解や実務経験が十分な要員が不在の場合にリスク分析を省略することや、簡易的に済ませてしまうことはせず、セキュリティ専門家（セキュリティリスクアセッサー）の支援を受けて必ずリスク分析を実施する。
2.2. セキュリティリスク分析の考え方
リスク評価手法については、対象組織の情報セキュリティに係るマネジメント能力の成熟度や対象組織の置かれた環境に応じたふさわしい手法を選ぶとされている。リスク評価に係る規格には、「ISO31000:2018, Risk management－Guidelines[^1]」等がある。
（１）セキュリティリスク分析の種類[^2]
リスク分析の例として、以下に４種類の手法を示す。
① ベースラインアプローチ
既存の標準や基準をもとに、想定する典型的なシステムに対して、予め一定の確保すべきセキュリティレベルを設定し、それを達成するためのセキュリティ対策要件を定め、分析対象となるシステムの対策の適合性等をチェックする。
② 非形式的アプローチ
組織や担当者の経験や判断によってリスク分析を実施する。
③ 詳細リスク分析
分析対象のシステム自体に対して、そのシステムもしくはそれにより実現されている事業を、「重要度」（あるいは損なわれた場合の被害レベル）「脅威」「脆弱性」の評価指標の下で、リスク分析を実施する。
④ 組み合わせアプローチ
複数のアプローチを併用し、作業の効率化、異なった評価視点の活用によって、分析精度の向上と、作業工数増大の回避を図る。
以下に、それぞれのセキュリティリスク分析手法の長所と短所の比較を記載する。
表２－１ セキュリティリスク分析手法の比較
| リスク分析手法 | 長所 | 短所 |
|---|---|---|
ベースライン アプローチ |
|
|
非形式的 アプローチ |
|
|
| 詳細リスク分析 |
|
|
組み合わせ アプローチ |
|
|
（出典）ＩＰＡ「制御システムのセキュリティリスク分析ガイド 第２版」より作成
※下線の箇所は、出典に対して本ガイドラインとして追記した箇所
（２）詳細リスク分析について[^3]
リスク分析の中でも、詳細リスク分析は、以下の点で、最も実態の把握と対策を検討するのに適している。
-
分析対象の実態に沿った評価を行うことで、分析対象のリスクを明確化できる。
-
対策の優先順位の客観的な決定と、リスク低減に最も効果的な選定が可能である。（組織内における対策の優先順位の共通の理解と認識を有することができる。）
-
一度確立しておくと、それをベースに、システムの拡張や新たな脅威の出現等にも継続的に見直しや更新をしていくことが可能である。
詳細リスク分析には、いくつかのアプローチがある。
- 資産ベース
保護すべきシステムを構成する各資産（サーバ、端末、通信機器等）に対して、その重要度（価値）、想定される脅威、脆弱性の３つを評価指標として、リスク分析を実施する。
この場合のリスク値としては、想定される「脅威の受容の可能性とそれにより損なわれる資産価値」の相乗値を算出することになる。リスク値が高い脅威に対しては、その受容性を低減する対策の強化を検討することになる。
- 事業被害ベース（シナリオベース）
保護すべきシステムにおいて実現されている事業やサービスに対して、回避したい事業被害を定義し、発生した際の事業被害のレベル、その被害を起こしうる攻撃シナリオによる脅威、攻撃シナリオに対する脆弱性（攻撃シナリオの受容可能性）の３つを評価指標として、リスク分析を実施する。この場合のリスク値としては、攻撃シナリオの「成功可能性と発生する被害のレベル」の相乗値を算定することになる。リスク値が高い攻撃シナリオに対しては、その成功可能性を低減する対策の強化を検討することになる。
2.3. 本ガイドラインで採用するセキュリティリスク分析
前項で各リスク分析手法の長所・短所の比較をしたが、セキュリティ・バイ・デザインで採用するリスク分析として重要視する要件を以下に挙げる。
① 対策の網羅的な把握
保護すべき事業（行政サービス）に対して、想定される脅威とその対策を一通り把握して評価できること。
② レビューによる品質確認
システムを知るシステム管理者、事業影響を知るビジネスオーナ、分析手法を知るセキュリティリスクアセッサーがリスク分析の結果を相互確認できること。
③ リスク分析のリソース
人員や予算は限られており、現実的な工数でリスク分析の達成が可能であること。
この①を満たすものとして、シナリオベースのリスク分析があるが、このシナリオベースのリスク分析を全て詳細に実施するとなると、システムによっては膨大な工数となり、③の要件が満たせないことが想定される。また、非形式的アプローチや複雑・大規模な詳細リスク分析などリスク分析者の力量に依存するアプローチでは、②のリスク分析の結果が確認できない可能性がでてくる。
これらのリスク分析での要件を満たすために、本ガイドラインでは、リスク分析にはベースラインと事業被害ベースの組み合わせアプローチを採用する。既存の基準をもとに一定レベルの評価が可能かつ作業の工数が大きくないベースラインアプローチを軸として、ベースラインの短所である事業被害が測れない点を事業被害ベースのリスク分析でカバーする。事業被害ベースでは、攻撃の起点と被害の起点のすべての攻撃ツリー洗い出すことはせず、最も大きな事業被害（トップリスク）を回避できるか否かを評価することにフォーカスさせることで工数の爆発的な増大を回避する。
なお、今回採用したリスク分析のアプローチは多くのシステムをカバーするが万能ではない。高度標的型攻撃の対象となりうるシステムや国民の資産を預かるようなきわめて影響度が大きいシステム、新しい技術基盤を採用したシステムでは十分ではない。そのようなシステムに対して、リスク分析の手法はそのシステムのインパクトや特性に見合ったものを検討いただきたい。
2.4. リスク分析のプロセス
リスク分析のプロセスは、「ISO31000:2018, Risk management－Guidelines」のプロセスを参考に、本ガイドラインで採用する組み合わせアプローチのプロセスを以下のように定義する。
図２－１ 本ガイドラインのリスク分析のプロセス
表２－２ リスク分析のプロセスの実施事項
| プロセス | 実施事項 | |
|---|---|---|
| 事業への影響度 （インパクト）の定義 | 事業の影響度を定義し、それぞれのリスク分析で共通した基準とする。 | |
| システム・プロファイルの作成 | システムの利用形態や特性・特質を分析しプロファイルを作成する。作成したプロファイルはそれぞれのリスク分析で使用する。 | |
| リスクアセスメント | リスク特定、リスク分析及びリスク評価のプロセス全体。 | |
| ベースライン アプローチ | 対象システムにあったセキュリティ管理策をチェックすることにより、確保すべきセキュリティレベルを達成するためのセキュリティ対策要件を分析する。 | |
| 事業被害ベース アプローチ | 事業やサービスに対して、回避したい事業被害を定義し、発生した際の事業被害のレベル、その被害を起こしうる攻撃シナリオによりリスク分析を実施する。 | |
| リスク分析の取りまとめ | ２つのリスク分析の結果から、設定したセキュリティレベルを達成するセキュリティ対策を取りまとめる。 | |
リスク分析のプロセスでは、セキュリティ・バイ・デザインでの対策へ効率的につなげるために、以下の点を考慮する。
・リスク分析のプロセスは、セキュリティ要件をシステム開発（調達）前に決定するためにシステムの企画フェーズ（要件定義フェーズ）で実施する。
・リスク分析の精度及びレビューの精度を上げるために、事業への影響度 （インパクト）の定義とシステムのプロファイルをアセスメントの前に作成する。
・リスク分析のプロセス毎にレビューを実施し、リスク分析の妥当性を評価する。