3. リスク分析の実施

リスク分析の実施において、関係者の役割や事業への影響度の基準、システム・プロファイルの正確さは分析結果に影響するため重要となる。

本章では、リスク分析の基準と手順を説明する。

3.1. リスク管理に関わる関係者の役割

　リスク分析では、開発チームがリスク分析やセキュリティ対策を実施するだけでなく、専門的な知見を有した評価者によって分析内容の妥当性を検証し進める必要がある。事業への影響度については、システム開発の都合でなく、行政サービスに責任をもつビジネス／リスクオーナーが事業視点で評価する必要がある。

以下に、セキュリティ・バイ・デザインに関わる関係者の役割と責任を示す。

　

表 ３‑1　セキュリティ・バイ・デザインに関わる関係者の役割と責任
項番 役割（呼称） 責任
1 システム管理者

  • セキュリティ対策が実施できるよう、委託先実施者との責任範囲を明確にし、セキュリティ対策全体を管理する。

  • システム開発、運用の各工程において、要求事項を満たすようにセキュリティ対策を実施する。

  • ビジネス/リスクオーナーの指示に従って是正対応を行う。
2 委託先実施者

  • システム管理者からの委託を受け、責任範囲にかかるセキュリティ対策を実施する。
3 ビジネス/リスクオーナー

  • 事業被害の設定し、セキュリティ対策によるリスク軽減の有効性、残存リスクが許容できるかを判断する。

  • システム対策と事業リスクのトレードオフの関係を判断する。

  • システム管理者によるセキュリティリスクへの是正対応状況を管理する。
4 セキュリティリスクアセッサー（評価者）

  • 業務観点及びシステム観点でのセキュリティリスク分析及び対策の妥当性を評価する。

  • 適合するセキュリティ・ベースラインやセキュリティ管理策をシステム管理者へ進言する。

  • システムのセキュリティリスク対応状況をモニタリングし、問題がある場合、システム管理者やビジネス/リスクオーナーに対して勧告、提言をおこなう。

図 ３‑1 セキュリティ・バイ・デザインに関わる関係者

3.2. 事業への影響度（インパクト）の定義

　政府情報システムが提供する国民や事業者向けの行政サービスや、行政機関の業務において生じる負の影響を、事業リスクとして以下のように定義する。この定義は、リスク分析を実施する際の共通の基準として用いられ、事業に責任をもつビジネス／リスクオーナーが影響度と最も大きな事業被害（最悪シナリオ）を評価する際に使用する。

（１）事業リスクの種類

事業リスクの種類を、NIST SP 800-63-3「Digital Identity Guidelines（電子的認証に関するガイドライン）」を引用して以下のとおり定義する。

表３－２　事業リスクの種類

＃

事業リスクの種類　

Impacts per Category　

①

利用者に不便、苦痛を与える、又は事業を所管する機関等が信頼を失う

Potential impact of inconvenience, distress, or damage to standing or reputation:

②

利用者に金銭的被害を与える、機関等に賠償責任が生じるなど財務上の影響を与える

Potential impact of financial loss:

③

機関等の活動計画や公共の利益に対して影響を与える

Potential impact of harm to agency programs or public interests:

④

利用者の個人情報などの機微な情報が漏洩する

Potential impact of unauthorized release of sensitive information:

⑤

利用者の身の安全に影響を与える

Potential impact to personal safety:

⑥

法律に違反する

The potential impact of civil or criminal violations is:

（出典）NIST SP 800-63-3「Digital Identity Guidelines（電子的認証に関するガイドライン）」より作成

　事業への影響度を評価する場合、情報セキュリティの3要素である機密性・完全性・可用性が失われた場合に関係する事業にどの程度の影響があるかによって評価する方法が一般的である。しかしながら、この3要素が失われた状況をリスクと認識して事業の影響まで評価しないミスを犯すことがある。本文書では、ビジネスオーナが影響度を認識しやすいNIST SP 800-63-3のImpacts per Categoryを事業リスクの定義として採用することでミスを回避することを意図している。

（２） 事業への影響度の定義

事業への影響度を、「連邦政府の情報および情報システムに対するセキュリティ分類規格（連邦情報処理規格 FIPS 199）」を引用して以下の通り定義する。

表３－３.事業への影響度の定義

影響度 内容

高位

(High)

 当該リスクの影響による損失が、組織の運営、組織の資産、又は個人に致命的又は壊滅的な悪影響を及ぼすと予想される

中位

(Moderate)

 当該リスクの影響による損失が、組織の運営、組織の資産、又は個人に重大な悪影響を及ぼすと予想される

低位

(Low)

 当該リスクの影響による損失が、組織の運営、組織の資産、又は個人に限定的な悪影響を及ぼすと予想される

非該当

(NA)

 該当しない　または　当該リスクによる影響がないと予想される

（出典）「連邦政府の情報および情報システムに対するセキュリティ分類規格（連邦情報処理規格 FIPS 199）」より作成

【補足説明】　

致命的または壊滅的な悪影響：

　　事業が滞り元の状態に戻せない損失が発生した事象

重大な悪影響：

　事業が滞り大きな影響はあったが、発生前の状況へ復旧できた事象

限定的な悪影響：

事業への影響は短期間または一部であった事象

　　NA：影響なし（NOT APPLICABLE）

（３） 事業リスク毎の事業への影響度の導出

上記の事業リスクの種類と事業への影響度を組み合わせて事業リスク毎の事業への影響度を定義する。

表３－４　事業への影響度の定義

＃

事業リスク

Impacts per Category

 影響度 影響度の定義

①

利用者に不便、苦痛を与える、又は事業を所管する機関等が信頼を失う

高位

深刻または重大かつ長期的な不便、苦痛、損害。この影響は、特に深刻な影響や多くの利用者に影響するレベル
中位 相当かつ短期間ないしは限定的だが長期間の不便、苦痛、損害
低位 限定的かつ短期間の不便、苦痛、損害

④

利用者に金銭的被害を与える、機関等に賠償責任が生じるなど財務上の影響を与える

高位

重大または致命的な経済的損失または賠償責任
中位 相当な経済的損失または賠償責任
低位 些細でとるに足らない経済的損失または賠償責任

⑦

機関等の活動計画や公共の利益に対して影響を与える

高位

組織の運用や資産、公共の利益への致命的な悪影響（長期間の機能停止または深刻な損害）
中位 組織の運用や資産、公共の利益への相当な悪影響（長期間の機能低下または著しい損害）
低位 組織の運用や資産、公共の利益への限定的な悪影響（処理効率の低下または軽微な損害）

⑩

利用者の個人情報などの機微な情報が漏洩する

高位

情報の不当な開示が、組織活動、組織資産、または個人に致命的または壊滅的な悪影響を及ぼすことが予想されうる(FIPS 199)
中位 情報の不当な開示が、組織活動、組織資産、または個人に重大な悪影響を及ぼすことが予想されうる(FIPS 199)
低位 情報の不当な開示が、組織活動、組織資産、または個人に限定的な悪影響を及ぼすことが予想されうる(FIPS 199)

⑬

利用者の身の安全に影響を与える

高位

重傷または死亡のリスク
中位 医療治療を必要とする怪我のリスク
低位 治療を必要としない軽傷

⑯

法律に違反する

高位

特に重要とされている民事上又は刑事上の違反のリスク
中位 法執行の対象となる可能性のある民事上又は刑事上の違反のリスク
低位 法執行の対象とならない性質の民事上又は刑事上の違反のリスク

（出典）NIST SP 800-63-3「Digital Identity Guidelines（電子的認証に関するガイドライン）」より作成

3.3. システム・プロファイルの作成

次に、対象システムの利用形態や特性・特質を分析する。これはリスク分析を正しい情報を根拠に正確に実施することを目的としているが、ビジネス/リスクオーナーやセキュリティリスクアセッサーなどレビュー関係者が分析結果を評価するためにも使用する。実際の記載例を、参考資料Cに掲載する。

（１） 事業の概要(Business Scope）

　システムの事業（行政サービス）の内容とインパクトを以下の項目に整理する。

表３－５　システム・プロファイル（事業の概要）の記載項目

項目 記載事項
事業目的・ミッション 事業において達成する目的やミッション（達成しようとしている目標）を記載する。図示を交えてもよい。

事業の影響度

システムの保証レベル

3.1項「事業の影響度の定義」を参考に事業の影響度を記載する。

  • ６つの事業リスクそれぞれに対して最も大きな事業被害と影響度を記載する。この事業被害は、後の事業被害ベースの分析のインプットにする。

  • ６つの事業リスクの影響度から、後述の「システムの保証レベルのデシジョンフロー」に従ってシステムの保証レベルを求める。この保証レベルは、後のベースラインの要否判断をする際に使用する。
情報システム運用継続計画の復旧優先度 「NISC　政府機関等における情報システム運用継続計画ガイドライン(第3版）」で定める当該システムをどのくらいの時間で復旧させるかというRTO(目標復旧時間)とどの水準まで復旧させるかというRLO(目標復旧レベル)及びRTO・RLOから定めた復旧優先度を記載する。まだ、復旧優先度が設定されていない場合は、「未設定」と記載する。
統一基準での情報格付区分 システムで取り扱う情報の格付区分を「NISC　政府機関等のサイバーセキュリティ対策のための統一基準（令和３年度版）」の基準により記載する。
その他の格付区分 このほかにシステム格付区分がある場合は記載する。

・システムの保証レベルのデシジョンフロー[^4]

　６つの影響度からシステムの保証レベルを求める。

図３－２　システムの保証レベルのデシジョンフロー

※「システムの保障レベルのデシジョンフロー」は、個人情報や手続きを扱う行政サービスを提供するシステムを対象としている。ただし、国民の資産を預かるシステムや人命に関わるシステムでは、非常に高い保証レベルが求められるため、影響度判断に専門家が参加し、決定されることがある。このデシジョンフローは、上記以外のシステムに対して使用する。

（２） システムの意図する使用（Intended Use）

　対象のシステムを、誰が、どこで、どのようなアクセス方法で利用するかを整理する。意図する使用方法を整理することで、何が不正なアクセスであるかを明らかにする。

表３－６　システム・プロファイル（システムの意図する使用）の記載項目

項目 記載事項
システムの概要・機能 システムの概要や機能を記載する。リスク分析に必要とする情報を含むこと。図示を交えてもよい。

意図する使用者

想定する利用者数

 システムが意図している使用者と想定人数を列挙する。システム管理者や運用担当も含む。許可されない利用者（unauthorized user）を明確にする目的もある。
意図する使用環境、アクセス方法 システムが意図している使用環境・アクセス方法を列挙する。不正アクセス（unauthorized access）を明確にする目的もある。
ネットワークの構成と設定条件 システムを機能させるためのネットワーク構成を図示する。イメージや概念でなくセキュリティ確保のための機器やアクセス経路は明示する。保守や監視のアクセスも含む。記載粒度は、リスク分析が可能なレベルでよい。ポリシーやアクセス制御があれば併記する。

（３） システムの特質(Characteristics related to security)

　情報資産とデータフローからシステムの特質を明らかにする。

表３－７　システム・プロファイル（システムの特質）の記載項目

項目 記載事項
情報資産（保護されるべき情報とプロセス） 情報資産を列挙する。また、可用性の対象とするサービスも列挙する。機微な情報については情報の件数も併記する。
システムの機能と権限、認証方法 システムの機能と機能を使用する権限（ロール）、使用者の認証方法を記載する。機能には管理者機能を含む。記載粒度は、リスク分析で確認するパターンが判別できるレベルでよい。
システムのアーキテクチャモデル システムを構成するアーキテクチャに関連するパーツ（サーバの役割やモジュールの階層構造、I/Fやプロトコルなど）を図示または列挙する。
システムの相互運用性（システム連携） 他システムとのデータ連係やAPI、共通使用する基盤を記載する。インターフェース仕様や依存関係があれば併記する。

使用シナリオ

またはデータフロー

 脅威を洗い出す場合に重要になるが、システムの企画段階で網羅的に作成するのは負担が大きいため、今回は必須とはしない。最も大きな事業被害（トップリスク）が想定されるシナリオだけでもよい。

（４） システム・プロファイル作成での注意事項

　リスク分析が不十分な理由の一つに、システムの現状把握や分析が不正確のまま実施されていることがあげられる。本ガイドラインでは、リスク分析の精度を確保するために、プロファイルを丁寧に作成することを推奨する。

  • 分析の粒度は、セキュリティのリスク分析の根拠とできるレベルでよい。ビジネス/リスクオーナー、セキュリティリスクアセッサーがレビューにあたって必要とするレベルを想定する。また、足りないとわかってから追記しても問題ない。

  • システム・プロファイルは、資料作成が目的ではなくリスク分析の根拠を明らかにするために作成するものなので、開発ドキュメントがある場合は引用しても問題はなく、プロファイル作成にかかる負担を軽減するように工夫する。

  • リスク分析の時点で決まっていない仕様は、仕様が決まる際に再度リスク分析を行う。特にアジャイルアプローチでセキュリティの実装方式を決めるケースでは、セキュリティ要件を取りこぼさないようバックログとして管理し、あとからトレースできるようにする。

　

3.4. リスク分析（ベースラインアプローチ）

リスク分析のベースラインアプローチは、「NIST SP800-37 Rev2　情報システムおよび組織のためのリスクマネジメントフレームワーク[^5]」を参考に作成した手順を示す。

図３－２　リスクマネジメントフレームワーク（SP800-37 Rev2）

　このフレームワークのステップ１からステップ３がベースラインアプローチのプロセスに対応する。ステップ４以降は、リスク分析の後のセキュリティ・バイ・デザインのプロセスになるが、分析結果が確実に対策されるようにこれらの手順もあわせて示す。記載例を参考資料C及び参考資料Dに掲載するので合わせて参考にしていただきたい。

【ステップ１】リスクマネジメントの準備（PREPARE）

対象システムの事業目的を明らかにし、そのシステムのプロファイルを作成し、システムの範囲及びリスクアセスメントで必要となる情報を明確にする。

【ステップ2】情報システムの分類（CATEGORIZE）

対象となる事業の影響度から、当該システムに求められるセキュリティ保証レベルを決定する。

・実施事項

  • 事業の影響度（システムの保証レベル）を設定する。

  • 事業の影響度の結果をレビューし決定する。

・記載事項

  • 事業の影響度（システムの保証レベル）（表３－５の項目）

・考え方

事業の影響度は、３章で定義した事業の影響度を使用することで情報システムの分類とする。この分類は【ステップ3】でのセキュリティ管理策の調整で使用する。情報システムの分類は、ビジネス/リスクオーナーが参加しレビューを実施して決定する。

【ステップ3】セキュリティ管理策の選択（SELECT）

　対象システムの現状調査に基づき、ベースラインとなるセキュリティ管理策を選択し、必要な場合はその内容を調整し、文書化する。

・実施事項

  • 対象システムの特性にあったセキュリティ管理策を選択する。

  • セキュリティ管理策の個々の項目について、要否を調整（テーラリング）する。

  • セキュリティ管理策の選択と個々の項目の要否をレビューし決定する。

・記載事項

　セキュリティ管理策に対応するベースラインの表を作成する。

ベースラインの表に以下の列を追加して記載する。

  • セキュリティ管理策の個々の項目の要否判定

  • 判定の理由

  • 不要としたために発生するリスク

  • 採用した場合の実装検証のタイミング

・考え方

行政サービスでは政府系システムのセキュリティ管理策から、システム構成からクラウドやWebなどシステムの特性にあったセキュリティ管理策を選択する。システムの特性をカバーするために複数の管理策を採用してもよい。セキュリティ管理策の選択の判断ができないときはセキュリティリスクアセッサーへ支援を求める。参考資料 Bに管理策の候補を示す。

システムの保証レベルやシステム特性にあわせて管理策の適用要否や適用レベルを調整する。セキュリティ管理策セキュリティ管理策の選択と調整の結果はビジネス/リスクオーナーとセキュリティリスクアセッサーへレビューをして妥当であることを確認する。

以上がベースラインアプローチのプロセスとなる。

次に、リスク分析をした後のプロセスを説明する。

【ステップ4】セキュリティ管理策の実装（IMPLEMENT）

　対象システムのセキュリティ管理策を実装する。また、セキュリティ管理策の実装方法を文書化する。

・実施事項

  • 選択したセキュリティ管理策をセキュリティ要件として文書化する。

  • セキュリティ・バイ・デザインのプロセスで実装する。

・記載事項

  • セキュリティ要件

・調達仕様書に添付する要件仕様書

　（ステップ３で作成したベースラインの表から要求事項を抽出して　作成する。）

・考え方

セキュリティ要求を開発者（委託先）へ示すとき、クライテリアと検証タイミングを合わせて提示することが望ましい。実装方式の決定によってセキュリティ要件が変わった際は、ベースラインの該当項目を満たしているか再度確認する。

【ステップ5】セキュリティ管理策のアセスメント（ASSESS）

　セキュリティ管理策が、正しく実装され、意図したとおりに機能し、セキュリティの要件を満たしているか有効性をアセスメントする。

・実施事項

  • セキュリティ管理策が実装されているかを確認する。

  • セキュリティ管理策の実装が意図した通りに機能し要件を満たしているか有効性をアセスメントする。

・記載事項

　ベースラインの表に以下の列を追加して記載する。

  • 管理策の実施の有無

  • 実施エビデンスの文書名

・考え方

個々のセキュリティ管理策の要求事項が漏れなく正しく実装されていることを確認する。実装の確認は、受入時に行ってもよいし、委託先が実施したエビデンスを確認することで実施してもよい。セキュリティ管理策に紐付けて確認したエビデンスを記載することでトレーサビリティを確保する。

【ステップ6】情報システムの運用認可（AUTHORIZE）

システムの運用または共通運用でのセキュリティ管理策について、運用認可責任者の許可をえる。

・実施事項

  • セキュリティ管理策で運用対策とした項目について、運用認可責任者より認可を受けていることを確認する。

・記載事項

　ベースラインの表に以下の列を追加して記載する。

  • 運用対策の認可の有無

  • 運用エビデンスの文書名

・考え方

運用体制によって確認先や確認方法が異なるため有効な方法をとること。運用を担当しない開発担当への確認では十分ではない。また、稼動後に運用整備することは原則認められない。やむを得ない理由がある場合は、例外事項として運用整備までの間のリスクと期限を合わせてビジネス/リスクオーナーからの承認をえる。

【ステップ7】セキュリティ管理策の監視（MONITOR）

　セキュリティ管理策の有効性を継続的にアセスメントし、必要な場合は適切に対応する。監視活動を報告し継続的な認可を受ける。また、必要に応じてシステムの廃棄戦略を策定し実施する。

3.5. 　リスク分析（事業被害ベースアプローチ）

事業被害ベースのリスク分析は、回避したい事業被害を明確化し、事業被害を引き起こすと想定される攻撃について、事業被害の大きさと、攻撃の発生可能性と受容可能性（脆弱性）の相乗値によって、事業のリスクを評価するリスク分析手法である。

本ガイドラインでは、分析のフレームワークとして

・IPA「制御システムのセキュリティリスク分析ガイド　第２版」

・ANSSI「EBIOS（Expression des Besoins et Identification des Objectifs de Sécurité）」

を参考に、最も大きな事業被害（トップリスク）を洗い出すことより、ベースラインのセキュリティ対応策でカバーができているか確認することに主眼を置いた手順を示している。この手順にあわせた事業被害ベースのリスク分析シートを参考資料 E　に掲載する。

【ステップ１】事業被害の洗い出し

システム・プロファイル（事業の概要）の６つの事業リスクでの最も大きな事業被害（トップリスク）を洗い出す。

・実施事項

  • 事業に直接影響を及ぼす被害を洗い出し、各事業被害について現実化した場合の事業への影響の大きさを評価する。

・記載事項

  • システム・プロファイル（事業の概要）「表３－５」で作成済み。

・考え方

システム・プロファイルを利用して、事業被害を洗い出す。洗い出しの対象は最も影響度（インパクト）が大きいものとするが、大きなリスクが複数想定できる場合は複数を対象としてよい。この後の分析が正しく実施できるように適切な表現で記載することに留意する。

【ステップ２】脅威の特定

事業被害を引き起こす攻撃シナリオを検討する。

・実施事項

  • それぞれのケースで事業被害を引き起こす脅威を想定し攻撃シナリオを作成する。

脅威としては一般的な攻撃手法（不正アクセス・なりすまし、脆弱性の悪用、マルウェア、サービス拒否、盗聴、フィッシング、ソーシャル攻撃、物理攻撃など）を想定する。

・記載事項

  • システム・プロファイル（事業の概要）「表３－５」から事業影響度の分類①～⑥の最も大きな事業被害を、「事業被害ベースのリスク分析シート」へ転記する。

・考え方

ここでは、専門的な攻撃手法や実施可能性を深掘りせず可能性を列挙すればよい。過去の類似システムのインシデントを参考にしてもよい。明らかに脅威となり得ない場合や事業被害につながらない場合は脅威としなくてもよい。

【ステップ３】攻撃シナリオの分析

攻撃シナリオを実現する攻撃ツリーを構成する。

・実施事項

  • 攻撃のシナリオを必要に応じてサブ攻撃シナリオに分類する。攻撃シナリオを実現する攻撃ツリーは、事業被害を最終的に引き起こす最終的な攻撃まで漏れなく記載する。

・記載事項

  • 事業被害ベースのリスク分析シートへ攻撃シナリオを記載する。

攻撃ツリーのステップを分析シートに階層的に記載する。

・考え方

攻撃シナリオの記載では、攻撃者や攻撃の入り口や機器、攻撃内容をできるだけ具体的に記載する。文章に曖昧さがあると分析が不正確になるため注意する。

【ステップ４】リスク値の算定

事業リスクに加え、脅威レベルと脆弱性レベルを評価しリスク値を算定する。

・実施事項

  • 攻撃ツリーを構成する一連の攻撃ステップにおける攻撃の難易度から脅威レベルを評価する。

  • 攻撃ツリーを構成する一連の攻撃ステップについて、すでに対策済みであるなど脆弱性レベルを評価する。

  • 攻撃ツリーを構成する一連の攻撃ステップについて、システム・プロファイルから事業被害レベルを転記する。

  • 脅威レベル、脆弱性レベル、事業被害レベルから、参考資料E「事業被害ベースアプローチでのリスク算定基準」を参考にリスク値を算定する。

・記載事項

  • 脅威レベル、脆弱性レベル、事業被害レベルを分析シートへ記載する。

  • 算定したリスク値を分析シートへ記載する。

・考え方

ここでのリスク算定は、追加のリスク対策の要否の判断基準となる。

【ステップ５】リスクへの対策

発生可能性を下げる対策を抽出する。

・実施事項

  • 攻撃ツリーを構成する一連の攻撃ステップに対して有効なリスク対策の項目を設定する。

・記載事項

  • 事業被害ベースのリスク分析シートへ転記する。

・考え方

対策が複数存在してもよい（多層防御）。対策実施がこの段階では決められず設計時に検討する場合は、この後のセキュリティ要件を作成できるよう備考欄へ説明を残す。

3.6. 　リスク分析結果のとりまとめ

ベースラインアプローチと事業被害ベースアプローチの２つのリスク分析の結果をとりまとめる。

（１） ２つのリスク分析のギャップ確認

・実施事項

  • 事業被害ベースのリスク分析シートの対策がベースラインの管理策に含まれているかを確認する。このとき、ベースラインの管理策に含まれていても不採用になっていないことを確認する。

・記載事項

  • ベースラインの管理策に含まれている場合は、事業被害ベースのリスク分析シートへベースラインの対応策番号を記入する。

  • ベースラインの管理策に含まれていない場合は、セキュリティ要件に含むことをできるようにリスク分析シートへ記載する。

・考え方

判断を要する場合は、レビューを開催し判断の根拠を記録に残す。

（２） ベースラインリスク分析の有効性の検証

・実施事項

  • 上記の２つのリスク分析のギャップ確認で、事業被害ベースのリスク分析からの対策がベースラインで大きくカバーできなかった場合は、ベースライン管理策の選定の誤りか足りないと判断し、ベースライン管理策の選定を見直しリスク分析を再度実施する。

・記載事項

  • 有効／無効の判断をレビューし記録を残す。

・考え方

組み合わせ方式のリスク分析を採用する理由は、リスク分析の欠点であるシステムの特性と合わないものや陳腐化を排除するためである。そのため、ベースラインリスク分析の有効性の検証は確実に実施する。