デジタル社会推進実践ガイドブック

DS-201

政府情報システムにおけるセキュリティリスク分析ガイドライン～

ベースラインと事業被害の組み合わせアプローチ ～2023（令和 5）年 3 月 31 日
デジタル庁
〔ドキュメントの位置付け〕
Informative
参考とするドキュメント〔キーワード〕リスク、リスク分析、ベースライン、セキュリティ・バイ・デザイン〔概要〕
情報システムのセキュリティを確保するためには、リスクを認識して確実に管理することが不可欠である。セキュリティリスク分析には、さまざまな手法があるが、本文書では、ベースラインと事業被害を組み合わせたリスク分析の手順を紹介し、作業効率と分析精度とをバランスをとって向上させることを目的としている。
本文書は、DS-200「政府情報システムにおけるセキュリティ・バイ・デザ
インガイドライン」のセキュリティリスク分析の手順の事例として具体的に示したものである。

改定履歴
改定年月日
2023年3月31日

改定箇所
-

改定内容
・初版決定

目次
１. はじめに ....................................................... 1
1.1. 目的とスコープ .............................................. 1
1.2. 位置づけ .................................................... 2
1.3. 本書の構成 .................................................. 2
1.4. 用語 ........................................................ 2
２. セキュリティリスク分析の概要 ................................... 4
2.1. セキュリティリスク分析の必要性 .............................. 4
2.2. セキュリティリスク分析の考え方 .............................. 4
2.3. 本ガイドラインで採用するセキュリティリスク分析 .............. 7
2.4. リスク分析のプロセス ........................................ 83.
リスク分析の実施 .............................................. 10
3.1. リスク管理に関わる関係者の役割 ............................. 10
3.2. 事業への影響度（インパクト）の定義 ......................... 11
3.3. システム・プロファイルの作成 ............................... 14
3.4. リスク分析（ベースラインアプローチ） ....................... 19
3.5. リスク分析（事業被害ベースアプローチ） ..................... 24
3.6. リスク分析結果のとりまとめ ................................. 27
4.
リスク管理プロセス ............................................ 28
4.1. リスク分析結果の実装への反映 ............................... 28
4.2. リスク分析の見直し ......................................... 29
4.3. リスク分析ドキュメントの取扱い ............................. 30

参考資料 A）参照したセキュリティ及びリスク分析のガイドライン ....... 31
参考資料 B）セキュリティ管理策のベースライン ....................... 33
参考資料 C）システム・プロファイルの記載例 ......................... 34
参考資料 D）ベースラインアプローチの記載例と様式 ................... 39
参考資料 E）事業被害ベースアプローチのリスク分析の記載例と様式 ..... 40i１. はじめに政府情報システムにおいて、セキュリティ対策を確実かつ効率的に実装するためにはシステム開発の上流工程から取り組むことが重要であることを、「DS200 政府情報システムにおけるセキュリティ・バイ・デザインガイドライン(2022 年 6 月デジタル庁発行）」で説明を行った。この中でセキュリティ対策の最初のプロセスとしてセキュリティリスク分析を行うことが示されている。

図１－１

セキュリティ・バイ・デザインのプロセス

セキュリティリスク分析には様々な方法がある、多くのガイドラインでは、
脅威事象の発生レベル、脆弱性の対策レベル、事業への影響の組み合わせでセキュリティリスクを分析する方法が紹介されている。この方法では、脅威の洗い出しや各レベルを決めてマトリックス表を作るための作業が必要であり、脅
威事象を網羅させることやレベルの決め方などに苦労することがある。
本文書では、分析の前に対象システムの特性をプロファイルとして定義する
ことで分析の根拠を固め、ベースラインのアプローチと事業被害のアプローチ
を組み合わせてリスク分析をする手順を提案している。この方法は、作業効率と分析精度のバランスがよく、リスク分析の結果をセキュリティ・バイ・デザ
インのプロセスに反映しやすい方法と考えている。

1.1. 目的とスコープ
本文書は、政府情報システムの開発や運用業務に従事する関係者に対して、セキュリティ・バイ・デザインの中のセキュリティリスク分析の手順を示すこ

1

とを主な目的としている。また、リスク分析の結果をセキュリティ要件として開発委託先へ提示する方法や、実装後にどのように確認するかについてもスコープとしている。
本文書の利用は、リスク分析の必要性を理解しているシステム管理者が、ベースラインと事業被害の組み合わせアプローチの手順を参考に、セキュリティ・バイ・デザインのためのリスク分析を効果的に実施することを想定している。リスク分析の考え方や手法を詳しく知りたい場合は、参考にしたガイドラ
インや提供情報を参考資料 A に示しているので、参照いただきたい。

1.2. 位置づけ
本文書は、標準ガイドライン群の Informative（情報提供）のレベルの参考文書である。

1.3. 本書の構成
本文書は、セキュリティ・バイ・デザインでのリスク分析の手順を本文に記載する。リスク分析は手法や手順だけでは理解が進まないこともあるため、記載サンプルと様式を参考資料に掲載する。
第 2 章では、セキュリティリスク分析における一般的な考え方とそれぞれの手法の長所・短所を比較し、本文書で採用するリスク分析の方法とその選択理由について説明する。
第 3 章では、第 2 章で選択したリスク分析のプロセスに沿って、分析対象のシステムにおける事業視点のインパクトの基準とプロファイルの項目、組み合わせ方式のリスク分析の実施手順について説明する。手順を示すことに重点を置き、分析における背景やその理由など説明は避け、プロセス毎の実施事項と記載事項、考え方とに整理して示している。
第 4 章では、第 3 章でのリスク分析の結果を、セキュリティ・バイ・デザイ
ンのインプットとしてどのように確実に対策につなげるか、実装の結果が漏れなく対策できているかをどのようにトレースするかについて説明している。

1.4. 用語
本文書において使用する用語は、表１-1 及び本文書に別段の定めがある場合を除くほか、標準ガイドライン群用語集の例による。その他専門的な用語については、民間の用語定義を参照すること。

2

表１－１

用語の定義

用語

意味

セキュリティ

本ガイドラインでは、サイバーセキュリティ
基本法第二条で定義された「サイバーセキュ
リティ」を「セキュリティ」と表現する。

リスク「リスク」とは、目的に対する不確かさの影響をいう。ある事象（周辺状況の変化を含む。）の結果とその発生の起こりやすさとの組合せとして表現されることが多い。
（引用元：政府機関等の対策基準策定のためのガイドライン 令和３年度版）

リスク分析

リスク分析の意義は、必要に応じてリスクのレベルを含め、リスクの性質及び特徴を理解することである。リスク分析には、不確かさ、リスク源、結果、起こりやすさ、事象、
シナリオ、管理策及び管理策の有効性の詳細な検討が含まれる。
（引用元：JIS Q 31000:2019）

システム・プロファイル

本ガイドラインでは、リスク分析対象のシステムの事業への影響度、利用形態や特性・特質を分析・整理したものをシステム・プロフ
ァイルと表現する。これから開発するシステ
ムでは、完成時を想定したプロファイルとする。
本文中では、情報システムに係る政府調達におけるセキュリティ要件策定マニュアル(SBD
マニュアル)の「業務要件の検討」を参考に
本ガイドライン向けに再定義している。

3

２. セキュリティリスク分析の概要
2.1. セキュリティリスク分析の必要性
事業における情報セキュリティを確保するためには、対象システムが担う業
務や取り扱う情報、そして情報システムの特性に応じてリスクが異なるため、リスク分析が必要となる。リスク分析の結果は、リスクへの対処法や、講ずべ
き対策の程度を決定するための根拠として使用する。
実際にリスク分析を行って正しい結果を得るためには、リスク分析手法の習得や実務経験が必要となる。もし、分析手法の理解や実務経験が十分な要員が不在の場合にリスク分析を省略することや、簡易的に済ませてしまうことはせず、セキュリティ専門家（セキュリティリスクアセッサー）の支援を受けて必ずリスク分析を実施する。

2.2. セキュリティリスク分析の考え方
リスク評価手法については、対象組織の情報セキュリティに係るマネジメン
ト能力の成熟度や対象組織の置かれた環境に応じたふさわしい手法を選ぶとされている。リスク評価に係る規格には、「ISO31000:2018, Risk management－
Guidelines1」等がある。
（１）セキュリティリスク分析の種類2
リスク分析の例として、以下に４種類の手法を示す。
① ベースラインアプローチ
既存の標準や基準をもとに、想定する典型的なシステムに対して、予め一定の確保すべきセキュリティレベルを設定し、それを達成するためのセキュリティ対策要件を定め、分析対象となるシステムの対策の適合性等をチェックする。

1②

非形式的アプローチ
組織や担当者の経験や判断によってリスク分析を実施する。

③

詳細リスク分析

ISO31000:2018, Risk management－Guidelines（国内標準としては、JIS Q 31000:2019 リスクマネジメント－指針）

2

セキュリティリスク分析の種類は、NISC(内閣サイバーセキュリティセンター) 政府機関等の対策基準策定のためのガイドライン（令和 3 年）の 2.1.3 項 2.1.3 情報セキュリティ関係規程の整備 より引用している。

4

分析対象のシステム自体に対して、そのシステムもしくはそれにより実現されている事業を、「重要度」（あるいは損なわれた場合の被害レ
ベル）「脅威」「脆弱性」の評価指標の下で、リスク分析を実施する。
④ 組み合わせアプローチ
複数のアプローチを併用し、作業の効率化、異なった評価視点の活用によって、分析精度の向上と、作業工数増大の回避を図る。
以下に、それぞれのセキュリティリスク分析手法の長所と短所の比較を記載する。
表２－１ セキュリティリスク分析手法の比較
リスク分析手法

長所

短所

ベースライン 決められた対策要件をチェッ 対策基準に対する適合レベル

アプローチ

クすることにより、作業の工のチェックであり、自分のシ数は大きくない。

ステムの状況に沿ったリスク

 既存の基準をもとにしている

分析にはなっていない。

ので、あるレベルの評価の目

 事業被害を起こさない裏づけ

安としては利用できる。

には間接的にしかならない。
 未実施の対策群があった場
合、自分のシステムに沿った選択基準が得られない。

非形式的 経験値を活用するので、属人アプローチ的ではあるが工数は小さい。

 リスク分析にはなっていない。
 起こりうる脅威、あるいは新たな脅威に対しての対応が困難である。
 属人的であり、継続的なセキュリティレベルの向上は困難である。

詳細リスク分析 自分のシステム自体に対す

 システムの規模や手法によっる、正確なリスク分析が可能ては、かなりの工数がかかるである。

ことがある。

 一度実施すると、それをベー リスク分析の結果の評価に技スに継続的なセキュリティレ

量を要する。また、技量を持

ベルの向上が可能となる。

つ評価者のアサインが難し

5リスク分析手法

長所

短所

 セキュリティ投資の優先順位

い。※

等、組織として戦略的に検討していくことができる。
組み合わせ
アプローチ

 上記、各手法の長所の取り込みの可能性である。

 どう組み合わせるのか、それぞれのシステムや事業者によ 上記、各手法の短所の改善の可能性がある。

って異なってくるが、その指針は示されていない。

（出典）ＩＰＡ「制御システムのセキュリティリスク分析ガイド

第２版」より作成※下線の箇所は、出典に対して本ガイドラインとして追記した箇所（２）詳細リスク分析について3
リスク分析の中でも、詳細リスク分析は、以下の点で、最も実態の把握と対策を検討するのに適している。
• 分析対象の実態に沿った評価を行うことで、分析対象のリスクを明確化できる。
• 対策の優先順位の客観的な決定と、リスク低減に最も効果的な選定が•可能である。（組織内における対策の優先順位の共通の理解と認識を有することができる。）
一度確立しておくと、それをベースに、システムの拡張や新たな脅威の出現等にも継続的に見直しや更新をしていくことが可能である。

詳細リスク分析には、いくつかのアプローチがある。
➢ 資産ベース
保護すべきシステムを構成する各資産（サーバ、端末、通信機器等）に対して、その重要度（価値）、想定される脅威、脆弱性の３つを評価指標として、リスク分析を実施する。
この場合のリスク値としては、想定される「脅威の受容の可能性とそれにより損なわれる資産価値」の相乗値を算出することになる。リスク値が高い脅威に対しては、その受容性を低減する対策の強化を検討することになる。
➢ 事業被害ベース（シナリオベース）
保護すべきシステムにおいて実現されている事業やサービスに対して、回避したい事業被害を定義し、発生した際の事業被害のレベル、その被3

詳細リスク分析の説明は、ＩＰＡ「制御システムのセキュリティリスク分析ガイド
スク分析の概要と長短解説から引用している。

6

第２版」2.1（３）項

詳細リ

害を起こしうる攻撃シナリオによる脅威、攻撃シナリオに対する脆弱性（攻撃シナリオの受容可能性）の３つを評価指標として、リスク分析を実施する。この場合のリスク値としては、攻撃シナリオの「成功可能性と発生する被害のレベル」の相乗値を算定することになる。リスク値が高い攻撃シナリオに対しては、その成功可能性を低減する対策の強化を検討することになる。

2.3. 本ガイドラインで採用するセキュリティリスク分析
前項で各リスク分析手法の長所・短所の比較をしたが、セキュリティ・バ
イ・デザインで採用するリスク分析として重要視する要件を以下に挙げる。
① 対策の網羅的な把握保護すべき事業（行政サービス）に対して、想定される脅威とその対策を一通り把握して評価できること。
② レビューによる品質確認システムを知るシステム管理者、事業影響を知るビジネスオーナ、分析手法を知るセキュリティリスクアセッサーがリスク分析の結果を相互確認できること。
③ リスク分析のリソース
人員や予算は限られており、現実的な工数でリスク分析の達成が可能であること。
この①を満たすものとして、シナリオベースのリスク分析があるが、このシナリオベースのリスク分析を全て詳細に実施するとなると、システムによっては膨大な工数となり、③の要件が満たせないことが想定される。また、非形式的アプローチや複雑・大規模な詳細リスク分析などリスク分析者の力量に依存するアプローチでは、②のリスク分析の結果が確認できない可能性がでてくる。
これらのリスク分析での要件を満たすために、本ガイドラインでは、リスク分析にはベースラインと事業被害ベースの組み合わせアプローチを採用する。
既存の基準をもとに一定レベルの評価が可能かつ作業の工数が大きくないベー
スラインアプローチを軸として、ベースラインの短所である事業被害が測れない点を事業被害ベースのリスク分析でカバーする。事業被害ベースでは、攻撃の起点と被害の起点のすべての攻撃ツリー洗い出すことはせず、最も大きな事7

業被害（トップリスク）を回避できるか否かを評価することにフォーカスさせることで工数の爆発的な増大を回避する。
なお、今回採用したリスク分析のアプローチは多くのシステムをカバーするが万能ではない。高度標的型攻撃の対象となりうるシステムや国民の資産を預かるようなきわめて影響度が大きいシステム、新しい技術基盤を採用したシス
テムでは十分ではない。そのようなシステムに対して、リスク分析の手法はそのシステムのインパクトや特性に見合ったものを検討いただきたい。

2.4. リスク分析のプロセス
リスク分析のプロセスは、「ISO31000:2018, Risk management－Guidelines」のプロセスを参考に、本ガイドラインで採用する組み合わせアプローチのプロ
セスを以下のように定義する。

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

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

リスク分析
事業被害ベース
アプローチ

リスク分析
ベースラインアプローチ

リスク分析の取りまとめ

リスク対応

図２－１

本ガイドラインのリスク分析のプロセス

表２－２ リスク分析のプロセスの実施事項

8

プロセス

実施事項

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

事業の影響度を定義し、それぞれのリスク分
析で共通した基準とする。

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

システムの利用形態や特性・特質を分析しプ
ロファイルを作成する。作成したプロファイ
ルはそれぞれのリスク分析で使用する。

リスクアセスメント

リスク特定、リスク分析及びリスク評価のプ
ロセス全体。

ベースラインアプローチ

対象システムにあったセキュリティ管理策をチェックすることにより、確保すべきセキュ
リティレベルを達成するためのセキュリティ対策要件を分析する。

事業被害ベース
アプローチ

事業やサービスに対して、回避したい事業被害 を 定 義 し、 発 生した 際 の 事 業被 害 のレベ
ル、その被害を起こしうる攻撃シナリオによりリスク分析を実施する。

リスク分析の取りまとめ

２つのリスク分析の結果から、設定したセキュリティレベルを達成するセキュリティ対策
を取りまとめる。

リスク分析のプロセスでは、セキュリティ・バイ・デザインでの対策へ効率的につなげるために、以下の点を考慮する。
・リスク分析のプロセスは、セキュリティ要件をシステム開発（調達）前に決定するためにシステムの企画フェーズ（要件定義フェーズ）で実施する。
・リスク分析の精度及びレビューの精度を上げるために、事業への影響度（インパクト）の定義とシステムのプロファイルをアセスメントの前に作成する。
・リスク分析のプロセス毎にレビューを実施し、リスク分析の妥当性を評価する。

9

3. リスク分析の実施
リスク分析の実施において、関係者の役割や事業への影響度の基準、システ
ム・プロファイルの正確さは分析結果に影響するため重要となる。
本章では、リスク分析の基準と手順を説明する。
3.1. リスク管理に関わる関係者の役割
リスク分析では、開発チームがリスク分析やセキュリティ対策を実施するだけでなく、専門的な知見を有した評価者によって分析内容の妥当性を検証し進める必要がある。事業への影響度については、システム開発の都合でなく、行政サービスに責任をもつビジネス／リスクオーナーが事業視点で評価する必要がある。
以下に、セキュリティ・バイ・デザインに関わる関係者の役割と責任を示す。

表 ３-1
項番
1

セキュリティ・バイ・デザインに関わる関係者の役割と責任

役割（呼称）

責任システム管理者 • セキュリティ対策が実施できるよう、委託先実施者との責任範囲を明確にし、セキュリティ対策全体を管理する。
• システム開発、運用の各工程において、要求事項を満たす
ようにセキュリティ対策を実施する。
• ビジネス/リスクオーナーの指示に従って是正対応を行う。
• システム管理者からの委託を受け、責任範囲にかかるセキュリティ対策を実施する。

2

委託先実施者3

ビ ジ ネ ス / リ ス • 事業被害の設定し、セキュリティ対策によるリスク軽減の
クオーナー
有効性、残存リスクが許容できるかを判断する。
• システム対策と事業リスクのトレードオフの関係を判断する。
• システム管理者によるセキュリティリスクへの是正対応状
況を管理する。

4

セキュリティリ • 業務観点及びシステム観点でのセキュリティリスク分析及
スクアセッサー び対策の妥当性を評価する。
（評価者）• 適合するセキュリティ・ベースラインやセキュリティ管理策をシステム管理者へ進言する。
• システムのセキュリティリスク対応状況をモニタリング
し、問題がある場合、システム管理者やビジネス/リスクオ
ーナーに対して勧告、提言をおこなう。
10

【参照】デジタル庁「政府情報システムにおけるセキュリティ・バイ・デザ
インガイドライン」5.1：セキュリティ・バイ・デザインのリスク管理に関わる関係者の役割

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

3.2. 事業への影響度（インパクト）の定義
政府情報システムが提供する国民や事業者向けの行政サービスや、行政機関の業務において生じる負の影響を、事業リスクとして以下のように定義する。
この定義は、リスク分析を実施する際の共通の基準として用いられ、事業に責任をもつビジネス／リスクオーナーが影響度と最も大きな事業被害（最悪シナリオ）を評価する際に使用する。
（１）事業リスクの種類
事業リスクの種類を、NIST SP 800-63-3「Digital Identity Guidelines（電11子的認証に関するガイドライン）」を引用して以下のとおり定義する。
表３－２＃

事業リスクの種類

事業リスクの種類
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)

は個人に致命的又は壊滅的な悪影響を及ぼすと予想される

12

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

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

非該当
(NA)

該当しない
る

または

当該リスクによる影響がないと予想され（出典）「連邦政府の情報および情報システムに対するセキュリティ分類規格（連邦情報処理規格 FIPS 199）」より作成【補足説明】
致命的または壊滅的な悪影響：
事業が滞り元の状態に戻せない損失が発生した事象
重大な悪影響：事業が滞り大きな影響はあったが、発生前の状況へ復旧できた事象
限定的な悪影響：
事業への影響は短期間または一部であった事象
NA：影響なし（NOT APPLICABLE）（３） 事業リスク毎の事業への影響度の導出
上記の事業リスクの種類と事業への影響度を組み合わせて事業リスク毎の事
業への影響度を定義する。
表３－４
＃

事業リスク
Impacts per Category

事業への影響度の定義

影響度① 利用者に不便、 高位
苦痛を与える、又は事業を所管中位する機関等が信頼を失う
低位② 利用者に金銭的 高位
被害を与える、機関等に賠償責 中位任が生じるなど 低位
財務上の影響を影響度の定義深刻または重大かつ長期的な不便、苦痛、損害。この影響は、特に深刻な影響や多くの利用者に影響するレベル相当かつ短期間ないしは限定的だが長期間の不便、苦痛、損害限定的かつ短期間の不便、苦痛、損害
重大または致命的な経済的損失または賠償責任
相当な経済的損失または賠償責任
些細でとるに足らない経済的損失または賠償
責任

13

＃

事業リスク
Impacts per Category

影響度

影響度の定義与える③ 機関等の活動計 高位
画や公共の利益に対して影響を中位
与える
低位④ 利用者の個人情 高位
報などの機微な情報が漏洩する
中位

低位⑤ 利用者の身の安 高位
全に影響を与え 中位
る
低位

組織の運用や資産、公共の利益への致命的な悪 影 響 （ 長 期 間 の 機能 停 止 ま た は 深 刻 な損害）
組織の運用や資産、公共の利益への相当な悪影響（長期間の機能低下または著しい損害）
組織の運用や資産、公共の利益への限定的な悪影響（処理効率の低下または軽微な損害）情報の不当な開示が、組織活動、組織資産、または個人に致命的または壊滅的な悪影響を及ぼすことが予想されうる(FIPS 199)
情報の不当な開示が、組織活動、組織資産、または個人に重大な悪影響を及ぼすことが予想されうる(FIPS 199)
情報の不当な開示が、組織活動、組織資産、または個人に限定的な悪影響を及ぼすことが予想されうる(FIPS 199)
重傷または死亡のリスク
医療治療を必要とする怪我のリスク
治療を必要としない軽傷

特に重要とされている民事上又は刑事上の違反のリスク
法執行の対象となる可能性のある民事上又は中位
刑事上の違反のリスク
法執行の対象とならない性質の民事上又は刑低位
事上の違反のリスク（出典）NIST SP 800-63-3「Digital Identity Guidelines（電子的認証に関⑥ 法律に違反する

高位

するガイドライン）」より作成

3.3. システム・プロファイルの作成
次に、対象システムの利用形態や特性・特質を分析する。これはリスク分析
を正しい情報を根拠に正確に実施することを目的としているが、ビジネス/リスクオーナーやセキュリティリスクアセッサーなどレビュー関係者が分析結果を評価するためにも使用する。実際の記載例を、参考資料 C に掲載する。
（１）事業の概要(Business Scope）
14

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

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

項目

記載事項

事業目的・ミッション

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

事業の影響度システムの保証レベル

3.1 項「事業の影響度の定義」を参考に事業の影響度を記載する。
➢ ６つの事業リスクそれぞれに対して最も大きな事業被害と影響度を記載する。この事業被害は、後の事業被害ベースの分析のインプットにする。
➢ ６つの事業リスクの影響度から、後述の「システムの保証レベルのデシジョンフロー」に従ってシステムの保証レベルを求める。この保証レ
ベルは、後のベースラインの要否判断をする際に使用する。

情 報 シ ステム運用継続 「NISC 政府機関等における情報システム運用継計画の復旧優先度
続計画ガイドライン(第 3 版）」で定める当該シス
テムをどのくらいの時間で復旧させるかというRTO(目標復旧時間)とどの水準まで復旧させるかという RLO(目標復旧レベル)及び RTO・RLO から定めた復旧優先度を記載する。まだ、復旧優先度が設定されていない場合は、「未設定」と記載する。
統 一 基 準での情報格付 システムで取り扱う情報の格付区分を「NISC 政
区分
府機関等のサイバーセキュリティ対策のための統一基準（令和３年度版）」の基準により記載する。
その他の格付区分

このほかにシステム格付区分がある場合は記載する。

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

4「NIST SP 800-63-3 の保証レベル（AAL：Authentication Assurance Level）」から引用

15

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

図３－２

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

※「システムの保障レベルのデシジョンフロー」は、個人情報や手続きを扱う
行政サービスを提供するシステムを対象としている。ただし、国民の資産を預かるシステムや人命に関わるシステムでは、非常に高い保証レベルが求められるため、影響度判断に専門家が参加し、決定されることがある。このデシジョンフローは、上記以外のシステムに対して使用する。
（２）システムの意図する使用（Intended Use）
対象のシステムを、誰が、どこで、どのようなアクセス方法で利用するかを整理する。意図する使用方法を整理することで、何が不正なアクセスであるかを明らかにする。
表３－６

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

16

項目

記載事項

システムの概要・機能

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

意図する使用者想定する利用者数

システムが意図している使用者と想定人数を列挙する。システム管理者や運用担当も含む。許可されない利用者（unauthorized user）を明確にする目的もある。

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

（３）システムの特質(Characteristics related to security)
情報資産とデータフローからシステムの特質を明らかにする。
表３－７

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

項目

記載事項

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

項目

記載事項
があれば併記する。

使用シナリオまたはデータフロー

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

（４）システム・プロファイル作成での注意事項
リスク分析が不十分な理由の一つに、システムの現状把握や分析が不正確のまま実施されていることがあげられる。本ガイドラインでは、リスク分析の精度を確保するために、プロファイルを丁寧に作成することを推奨する。
 分析の粒度は、セキュリティのリスク分析の根拠とできるレベルでよい。
ビジネス/リスクオーナー、セキュリティリスクアセッサーがレビューにあたって必要とするレベルを想定する。また、足りないとわかってか
ら追記しても問題ない。
 システム・プロファイルは、資料作成が目的ではなくリスク分析の根拠を明らかにするために作成するものなので、開発ドキュメントがある場
合は引用しても問題はなく、プロファイル作成にかかる負担を軽減する
ように工夫する。
 リスク分析の時点で決まっていない仕様は、仕様が決まる際に再度リス
ク分析を行う。特にアジャイルアプローチでセキュリティの実装方式を決めるケースでは、セキュリティ要件を取りこぼさないようバックログ
として管理し、あとからトレースできるようにする。

18

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

図３－２

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

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

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

5

NIST SP800-37 Rev2 情報システムおよび組織のためのリスクマネジメントフレームワーク －セキュリティとプラ
イバシーのためのシステムライフサイクルアプローチ「Risk Management Framework for Information Systems andOrganizations A System Life Cycle Approach for Security and Privacy 」

19

・実施事項➢ リスク分析を担当するステークホルダ6（システム管理者、ビジネス/リスクオーナー、セキュリティリスクアセッサー）を特定する。
➢ システムがサポートする事業（行政サービス）の目的とミッション（達成しようとしている目標）及び事業の影響度を定義する。
➢ システムの使われ方を分析する。
➢ システムの特性を分析する。
・記載事項
システム・プロファイルを作成する。
➢ セキュリティリスク分析の担当者➢ プロファイル（事業の概要）の記載項目（表３－５の項目）➢ プロファイル（システムの意図する使用）の記載項目（表３－６の項目）➢ プロファイル（システムの特質）の記載項目（表３－７の項目）
・考え方
NIST SP800-37 では、主に資産管理、ビジネス環境、リスクアセスメン
ト、ガバナンスなどを分析することとされているが、本ガイドラインでは、３章で定義したシステム・プロファイルを作成することでリスクマネ
ジメントの準備とする。

【ステップ 2】情報システムの分類（CATEGORIZE）
対象となる事業の影響度から、当該システムに求められるセキュリティ保証
レベルを決定する。
・実施事項➢ 事業の影響度（システムの保証レベル）を設定する。
➢ 事業の影響度の結果をレビューし決定する。
・記載事項➢ 事業の影響度（システムの保証レベル）（表３－５の項目）

6

リスク分析を担当するステークホルダの説明は「4.1.リスク管理に関わる関係者の役割」を参照

20

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

【ステップ 3】セキュリティ管理策の選択（SELECT）
対象システムの現状調査に基づき、ベースラインとなるセキュリティ管理策を選択し、必要な場合はその内容を調整し、文書化する。
・実施事項➢ 対象システムの特性にあったセキュリティ管理策を選択する。
➢ セキュリティ管理策の個々の項目について、要否を調整（テーラリン
グ）する。
➢ セキュリティ管理策の選択と個々の項目の要否をレビューし決定する。
・記載事項
セキュリティ管理策に対応するベースラインの表を作成する。
ベースラインの表に以下の列を追加して記載する。
➢ セキュリティ管理策の個々の項目の要否判定➢ 判定の理由➢ 不要としたために発生するリスク➢ 採用した場合の実装検証のタイミング
・考え方
行政サービスでは政府系システムのセキュリティ管理策から、システム構
成からクラウドや Web などシステムの特性にあったセキュリティ管理策を選択する。システムの特性をカバーするために複数の管理策を採用してもよい。セキュリティ管理策の選択の判断ができないときはセキュリティリ
スクアセッサーへ支援を求める。参考資料 B に管理策の候補を示す。
システムの保証レベルやシステム特性にあわせて管理策の適用要否や適用
レベルを調整する。セキュリティ管理策セキュリティ管理策の選択と調整の結果はビジネス/リスクオーナーとセキュリティリスクアセッサーへレビューをして妥当であることを確認する。
以上がベースラインアプローチのプロセスとなる。

21

次に、リスク分析をした後のプロセスを説明する。
【ステップ 4】セキュリティ管理策の実装（IMPLEMENT）
対象システムのセキュリティ管理策を実装する。また、セキュリティ管理策の実装方法を文書化する。
・実施事項➢ 選択したセキュリティ管理策をセキュリティ要件として文書化する。
➢ セキュリティ・バイ・デザインのプロセスで実装する。
・記載事項➢ セキュリティ要件
・調達仕様書に添付する要件仕様書（ステップ３で作成したベースラインの表から要求事項を抽出して作成する。）
・考え方
セキュリティ要求を開発者（委託先）へ示すとき、クライテリアと検証タ
イミングを合わせて提示することが望ましい。実装方式の決定によってセキュリティ要件が変わった際は、ベースラインの該当項目を満たしているか再度確認する。

【ステップ 5】セキュリティ管理策のアセスメント（ASSESS）
セキュリティ管理策が、正しく実装され、意図したとおりに機能し、セキュリティの要件を満たしているか有効性をアセスメントする。
・実施事項➢ セキュリティ管理策が実装されているかを確認する。
➢ セキュリティ管理策の実装が意図した通りに機能し要件を満たしているか有効性をアセスメントする。
・記載事項
ベースラインの表に以下の列を追加して記載する。
➢ 管理策の実施の有無➢ 実施エビデンスの文書名

22

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

【ステップ 6】情報システムの運用認可（AUTHORIZE）
システムの運用または共通運用でのセキュリティ管理策について、運用認可責任者の許可をえる。
・実施事項➢ セキュリティ管理策で運用対策とした項目について、運用認可責任者より認可を受けていることを確認する。
・記載事項
ベースラインの表に以下の列を追加して記載する。
➢ 運用対策の認可の有無➢ 運用エビデンスの文書名・考え方
運用体制によって確認先や確認方法が異なるため有効な方法をとること。
運用を担当しない開発担当への確認では十分ではない。また、稼動後に運用整備することは原則認められない。やむを得ない理由がある場合は、例
外事項として運用整備までの間のリスクと期限を合わせてビジネス/リスクオーナーからの承認をえる。

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

23

3.5. リスク分析（事業被害ベースアプローチ）
事業被害ベースのリスク分析は、回避したい事業被害を明確化し、事業被害を引き起こすと想定される攻撃について、事業被害の大きさと、攻撃の発生可能性と受容可能性（脆弱性）の相乗値によって、事業のリスクを評価するリスク分析手法である。
本ガイドラインでは、分析のフレームワークとして・IPA「制御システムのセキュリティリスク分析ガイド 第２版」
・ANSSI「EBIOS（Expression des Besoins et Identification des Objectifsde Sécurité）」
を参考に、最も大きな事業被害（トップリスク）を洗い出すことより、ベースラインのセキュリティ対応策でカバーができているか確認することに主眼を置いた手順を示している。この手順にあわせた事業被害ベースのリスク分析シートを参考資料 E に掲載する。

【ステップ１】事業被害の洗い出しシステム・プロファイル（事業の概要）の６つの事業リスクでの最も大きな事業被害（トップリスク）を洗い出す。
・実施事項➢ 事業に直接影響を及ぼす被害を洗い出し、各事業被害について現実化した場合の事業への影響の大きさを評価する。
・記載事項➢ システム・プロファイル（事業の概要）「表３－５」で作成済み。
・考え方
システム・プロファイルを利用して、事業被害を洗い出す。洗い出しの対象は最も影響度（インパクト）が大きいものとするが、大きなリスクが複数想定できる場合は複数を対象としてよい。この後の分析が正しく実施できるように適切な表現で記載することに留意する。

【ステップ２】脅威の特定事業被害を引き起こす攻撃シナリオを検討する。
・実施事項➢ それぞれのケースで事業被害を引き起こす脅威を想定し攻撃シナリオを作

24

成する。
脅威としては一般的な攻撃手法（不正アクセス・なりすまし、脆弱性の悪用、マルウェア、サービス拒否、盗聴、フィッシング、ソーシャル攻
撃、物理攻撃など）を想定する。
・記載事項➢ システム・プロファイル（事業の概要）「表３－５」から事業影響度の分類①～⑥の最も大きな事業被害を、「事業被害ベースのリスク分
析シート」へ転記する。
・考え方
ここでは、専門的な攻撃手法や実施可能性を深掘りせず可能性を列挙すればよい。過去の類似システムのインシデントを参考にしてもよい。明らかに脅威となり得ない場合や事業被害につながらない場合は脅威としなくてもよい。

【ステップ３】攻撃シナリオの分析
攻撃シナリオを実現する攻撃ツリーを構成する。
・実施事項➢ 攻撃のシナリオを必要に応じてサブ攻撃シナリオに分類する。攻撃シ
ナリオを実現する攻撃ツリーは、事業被害を最終的に引き起こす最終的な攻撃まで漏れなく記載する。
・記載事項➢ 事業被害ベースのリスク分析シートへ攻撃シナリオを記載する。
攻撃ツリーのステップを分析シートに階層的に記載する。
・考え方
攻撃シナリオの記載では、攻撃者や攻撃の入り口や機器、攻撃内容をできるだけ具体的に記載する。文章に曖昧さがあると分析が不正確になるため
注意する。

25

【ステップ４】リスク値の算定
事業リスクに加え、脅威レベルと脆弱性レベルを評価しリスク値を算定する。
・実施事項➢ 攻撃ツリーを構成する一連の攻撃ステップにおける攻撃の難易度から
脅威レベルを評価する。
➢ 攻撃ツリーを構成する一連の攻撃ステップについて、すでに対策済みであるなど脆弱性レベルを評価する。
➢ 攻撃ツリーを構成する一連の攻撃ステップについて、システム・プロ
ファイルから事業被害レベルを転記する。
➢ 脅威レベル、脆弱性レベル、事業被害レベルから、参考資料 E「事業被害ベースアプローチでのリスク算定基準」を参考にリスク値を算定する。
・記載事項➢ 脅威レベル、脆弱性レベル、事業被害レベルを分析シートへ記載する。
➢ 算定したリスク値を分析シートへ記載する。
・考え方
ここでのリスク算定は、追加のリスク対策の要否の判断基準となる。

【ステップ５】リスクへの対策
発生可能性を下げる対策を抽出する。
・実施事項➢ 攻撃ツリーを構成する一連の攻撃ステップに対して有効なリスク対策の項目を設定する。
・記載事項➢ 事業被害ベースのリスク分析シートへ転記する。
・考え方
対策が複数存在してもよい（多層防御）。対策実施がこの段階では決められず設計時に検討する場合は、この後のセキュリティ要件を作成できる
よう備考欄へ説明を残す。

26

3.6. リスク分析結果のとりまとめ
ベースラインアプローチと事業被害ベースアプローチの２つのリスク分析の結果をとりまとめる。
（１）２つのリスク分析のギャップ確認・実施事項➢ 事業被害ベースのリスク分析シートの対策がベースラインの管理策に含まれているかを確認する。このとき、ベースラインの管理策に含まれていても不採用になっていないことを確認する。
・記載事項➢ ベースラインの管理策に含まれている場合は、事業被害ベースのリ
スク分析シートへベースラインの対応策番号を記入する。
➢ ベースラインの管理策に含まれていない場合は、セキュリティ要件に含むことをできるようにリスク分析シートへ記載する。
・考え方
判断を要する場合は、レビューを開催し判断の根拠を記録に残す。

（２）ベースラインリスク分析の有効性の検証
・実施事項➢ 上記の２つのリスク分析のギャップ確認で、事業被害ベースのリスク分析からの対策がベースラインで大きくカバーできなかった場合
は、ベースライン管理策の選定の誤りか足りないと判断し、ベース
ライン管理策の選定を見直しリスク分析を再度実施する。
・記載事項➢ 有効／無効の判断をレビューし記録を残す。
・考え方
組み合わせ方式のリスク分析を採用する理由は、リスク分析の欠点であるシステムの特性と合わないものや陳腐化を排除するためである。そのため、ベースラインリスク分析の有効性の検証は確実に実施する。

27

4. リスク管理プロセス
セキュリティリスク分析は、セキュリティ・バイ・デザインの最初の工程であり、デジタル・ガバメント推進標準ガイドライン7におけるサービス・業務企
画の工程として実施することを想定している。本ガイドラインは、その手順を示している。リスク分析の結果を対策につなげるためのリスク管理のプロセス
は、セキュリティ・バイ・デザインのプロセスに含まれ実施される。
4.1. リスク分析結果の実装への反映分析されたリスク管理策は、セキュリティ要件として定義され、システム開発のプロセスとして実装され、その結果、リスクが受容可能であることを評価する。この一連のプロセスが、セキュリティ・バイ・デザインのプロセスで実施されるよう以下の点に配慮する。
（１）セキュリティ要件
セキュリティリスク分析結果、セキュリティ対応方針に従い、システムで満たすべきセキュリティの状態が、機能面、非機能面ともに定義されていること。
【参照】デジタル庁「政府情報システムにおけるセキュリティ・バイ・デザインガイドライン」4.2.2)項：セキュリティ要件定義
要件は具体的な実装までを指示するものではないが、実装のクライテリ
ア（合否判定基準）があるものは要件の中で示すことが望ましい。
（２）開発委託先の提示
セキュリティ要件に基づいて、システム調達におけるセキュリティ仕様が策定され、委託先との責任範囲が明確になっていること。
【参照】デジタル庁「政府情報システムにおけるセキュリティ・バイ・デザインガイドライン」4.2.3)項：セキュア調達
セキュリティ要件を調達時に示すこと、また実装の検証タイミングと評価者を委託先へ示すことが望ましい。実装の検証は、委託者が受け入れ時に行う方法と、受託者が検証してそのエビデンスを委託者が確認する方法がある。

7

デジタル・ガバメント推進標準ガイドラインの工程とセキュリティリスク分析を含むセキュリティ・バイ・デザインの工程の対応は、デジタル庁「政府情報システムにおけるセキュリティ・バイ・デザインガイドライン」表 ４-1 セキュリティ・バイ・デザインの実施工程と概要を参照のこと

28

（３）リスク対策の実施確認
セキュリティ機能に対する各種テストが実施され、品質が確保されていること。
【参照】デジタル庁「政府情報システムにおけるセキュリティ・バイ・デザインガイドライン」4.2.6)項：セキュリティテスト
ここでのセキュリティテストは、セキュリティ要件に対して、実装と検証が実施されているかのホワイトボックス・テストをいう。テストエビデンスにセキュリティ要件の管理番号を記載、または、ベースラインのシートに対策実施のエビデンス番号を記載するなど、トレーサビリティを確保する方法を推奨する。
（４）運用によるリスク対策の確認
セキュリティ管理策で運用対策とした項目について、運用体制が整備され、セキュリティ手順が策定され、運用の実行性が確保されていること。
【参照】デジタル庁「政府情報システムにおけるセキュリティ・バイ・デザインガイドライン」4.2.7)項：セキュリティ運用準備
運用によるリスク対策の確認は、開発者でなく運用認可責任者によって認可を受けること。このプロセスはビジネス/リスクオーナーが必ず監督する。
4.2. リスク分析の見直し
リスク分析は、一度実施して終わりでなく、システムのライフサイクルの間、
新たなリスクが発生していないかを継続して監視しなければならない。
システムのライフサイクルでのイベントとして・システムの設計や実装方式の決定
・運用開始後に発見された脆弱性、新しい脅威事象・使用するプロダクトのサポート終了
・システム改修での機能追加
・システムの使用対象、アクセス環境の変化
・セキュリティ管理策が変化した場合（暗号の危殆化など）などがある。
これらのイベントが発生した場合は、過去に実施したリスク分析を見直し、分析範囲や管理策に要否に変更がないか判断を行い、必要な場合はリスク分析

29

の再実施と対策の実装と検証を行う。要否判断をシステム担当者だけで行わず、開発の時と同じくビジネス/リスクオーナーとセキュリティリスクアセッサーが参加し妥当性を確認する。
また、セキュリティ対策の技術や管理策は新たな脅威に対応するよう見直されているため、リスク分析の再実施では、その時点の最新技術や規格（Stateof-the-Art）を基準にすることが望ましい。
リスク分析と対策を継続することは、コストが発生するために、再分析は敬遠される傾向にあるが、システムの企画段階から継続実施することを想定しアプローチすることで、効率的な対応が可能となる。本ガイドラインで採用したベースラインと事業被害ベースの組み合わせ方式のリスク分析は、上記イベン
ト時に反復的に実行しやすいものとなっている。
変化するシステムやセキュリティの脅威に対して、継続的にセキュリティリ
スクの軽減をはかることが肝要である。

4.3. リスク分析ドキュメントの取扱い
リスク分析のドキュメントは、そのシステムの攻撃に有用な情報を含むため、管理対象の文書とする。セキュリティリスクアセッサーはリスク分析のドキュメントを共有する必要があるが、内容の秘匿義務を負い、公開や二次配布などしてはならない。
リスク分析から作成したセキュリティ要件は、他の開発ドキュメントと同じ基準で委託先など開発や検証の関係者へ提示しても問題はない。委託先とは他の開発ドキュメントと同じく契約で決められた守秘義務に則って運用する。

30

参考資料 A）参照したセキュリティ及びリスク分析のガイドライン#

発行元

ガイドライン名

1

デジタル庁

政府情報システムにおけるセキュリティ・バ
イ・デザインガイドライン（令和 4 年 6 月 30 日）

2

NISC(内閣サイバーセ
キュリティセンター)

3

NISC(内閣サイバーセ
キュリティセンター)

4

NISC(内閣サイバーセ
キュリティセンター)

5

ISO/JIS

政府機関等のサイバーセキュリティ対策のための統一基準（令和 3 年 7 月 7 日）
政府機関等の対策基準策定のためのガイドライン（令和 3 年 7 月 7 日）
情報システムに係る政府調達におけるセキュリ
ティ要件策定マニュアル(SBD マニュアル)（2022 年７月 29 日）
ISO31000:2018, Risk management－Guidelines
JIS Q 31000:2019 リスクマネジメント指針

6

IPA（情報処理推進機
構）

7

IPA（情報処理推進機
構）

8

NIST（米国国立標準技
術研究所）

9

NIST（米国国立標準技
術研究所）

10

NIST（米国国立標準技
術研究所）

11

NIST（米国国立標準技
術研究所）

12

NIST（米国国立標準技
術研究所）

13

ANSSI（フランス国家
情報システムセキュリ
ティ機関）

制御システムのセキュリティリスク分析ガイド
第２版（2020 年 3 月）
セキュリティ・バイ・デザイン導入指南書（2022 年 8⽉）

NIST SP800-63-3
Digital Identity Guidelines(UPDATES AS OF 03-02-2020)
デジタル・アイデンティティ・ガイドライン
NIST SP800-37 Rev2
Risk Management Framework for Information
Systems and Organizations
A System Life Cycle Approach for Security
and Privacy (Dec. 2018)
情報システムおよび組織のためのリスクマネジ
メントフレームワーク －セキュリティとプラ
イバシーのためのシステムライフサイクルアプ
ローチ
Cybersecurity Framework Version 1.1

URL
https://www.digital.go.jp/asse
ts/contents/node/basic_page/fi
eld_ref_resources/e2a06143ed29-4f1d-9c310f06fca67afc/2a169f83/20220630_resources_standard_guidelines_guidelines_01.pdf
https://www.nisc.go.jp/pdf/policy/general/kijyunr3.pdf
https://www.nisc.go.jp/pdf/policy/general/guider3_2.pdf
https://www.nisc.go.jp/policy/
group/general/sbd_sakutei.html-

https://www.ipa.go.jp/security/guide/vuln/controlsystemriskanalysis.html
https://www.ipa.go.jp/jinzai/i
cs/core_human_resource/final_p
roject/2022/security-bydesign.html
https://nvlpubs.nist.gov/nistp
ubs/SpecialPublications/NIST.S
P.800-63-3.pdf
https://csrc.nist.gov/publicat
ions/detail/sp/800-37/rev2/final

https://www.nist.gov/cyberfram
ework/framework-documents

NIST SP800-53 Rev.5
Security and Privacy Controls for
Information Systems and Organizations
組織と情報システムのためのセキュリティおよびプライバシー管理策
FIPS PUB 199: Feb 2004
Standards for Security Categorization ofFederal Information and Information Systems
連邦情報処理標準 (FIPS 199)
連邦政府の情報および情報システムに対するセキュリティ分類規格

https://csrc.nist.gov/publicat
ions/detail/sp/800-53/rev5/final

EBIOS RISK MANAGER
Version 1.0 — November 2019https://www.ssi.gouv.fr/guide/ebios-risk-manager-the-method/

31

https://nvlpubs.nist.gov/nistp
ubs/fips/nist.fips.199.pdf

#
14

発行元
OWASP

ガイドライン名
Software Assurance Maturity Model（Version 2.0.3 (2022)）32

URL
https://owasp.org/www-projectsamm/参考資料 B）セキュリティ管理策のベースライン
ベースラインアプローチのリスク分析でのセキュリティ管理策の候補を示す。ここで示すもの以外のセキュリティ管理策を採用してもよい。なお、セキュリティ管理策の採用ではリスク分析時点で最新のバージョンであることを確認すること。

◆政府系システムのセキュリティ管理策
・NISC

政府機関等のサイバーセキュリティ対策のための統一基準（令和３年度版）

・NISC

情報システムに係る政府調達におけるセキュリティ要件策定マニュアル(SBD マニュアル)・NIST SP800-53 rev5 : Security and Privacy Controls for Federal Information Systems
and Organizations
・CIS Controls V8（https://www.cisecurity.org/controls/v8）◆クラウド系のセキュリティ管理策
・ISMAP

政府情報システムのためのセキュリティ評価制度

管理策基準

・CLOUD CONTROLS MATRIX VERSION 4.0（https://cloudsecurityalliance.org/research/cloud-controls-matrix/）
・CIS

Benchmarks（https://www.cisecurity.org/cis-benchmarks/）◆アプリケーション・プロダクト
・OWASP

Application Security Verification Standard

Ver4.03orVer5(https://owasp.org/www-project-application-security-verification-standard/)

・CIS Benchmarks（https://www.cisecurity.org/cis-benchmarks/）

・ENISA Good practices for Security of Internet of Things.
(https://www.enisa.europa.eu/publications/good-practices-for-security-of-iot-1)◆特定分野・ISO/IEC

27002:2022（情報セキュリティ管理策）

・総務省

IoT セキュリティガイドライン Ver1.0

・総務省、厚生労働省、経済産業省
基本的指針

民間 PHR 事業者による健診等情報の取扱いに関するチェックシート(https://www.meti.go.jp/policy/mono_info_service/healthcare/phr.html)
・厚生労働省

医療情報システムの安全管理に関するガイドライン

第 5.2 版

(https://www.mhlw.go.jp/stf/shingi/0000516275_00002.html)

33

参考資料 C）システム・プロファイルの記載例
以下にシステム・プロファイルの記載例を示す。
記載項目は、本ガイドラインの項目を基本とするが、記載様式は自由に定めてもよい。開発ドキュメントなど他ドキュメントを引用・転用してもよい。
※本記載例は、例示を目的に作成したものであって、実際の業務や組織、システムと異なる。
――― システム・プロファイル ―――◆セキュリティリスク分析の担当者
システム管理者：

デジタル庁〇〇Ｇ△△Ｔ□□、□□、□□

ビジネス/リスクオーナー：

デジタル庁〇〇Ｇ△△Ｔ□□

セキュリティリスクアセッサー： デジタル庁〇〇Ｇ△△Ｔ□□、□□◆システム・プロファイル（事業の概要）
項目
説明・内容
事業目的・ミッション デジタル庁及び政府各省が管理運営するシステムの全体像把握に必要な情報を収集・蓄積して、デジタル庁としての意思決定・組織運営に活用するため、ダッシュボードを用いてわかりやすく可視化する。
事業の影響度ＡＡＬ２（中程度）
システムの保証レベル ・リスクの種類別の影響度は下記別表に記載
・保証レベルは、システムの保証レベルのデシジョンフロー
から導出
情報システム運用継続 ＲＴＯ(目標復旧時間)：1 週間から 2 週間以内に復旧が必要な計画の復旧優先度
情報システム

統一基準での情報格付
区分

その他の格付区分

ＲＬＯ(目標復旧レベル)：特になし
復旧優先度：Ｄ
機密性３情報：なし
機密性２情報：あり （システム構成等非公開情報を含む）
完全性２情報：なし （オリジナルデータから復元可能）
可用性２情報：なし （停止しても代替方法あり）
特になし

34

◆リスクの種類別の影響度＃
事業リスク
Impacts per Category① 利用者に不便、苦痛を与える、又は事業を所管する機関等が信頼を失う
②

③

④
⑤
⑥

利用者に金銭的被害を与える、機関等に賠償責任が生じるなど財務上の影響を与える
機関等の活動計画や公共の利益に対して影響を与える
利用者の個人情報などの機微な情報が漏洩する
利用者の身の安全に影響を与える
法律に違反する

最も大きな事業被害
サイバー攻撃によってシステムが停止し、利用できなくなる。
サイバーインシデントの被害が公になり、デジタル庁の信頼低下を招く。
サイバー攻撃によって、システムのデータやプログラムが改ざんされてしまい、復旧のための工数（費用）が発生する。
影響なし（効率は悪化するが、このシステ
ムだけに異存はしていないので実害はない）
システムの構成情報が漏洩し、セキュリテ
ィ攻撃に悪用される
影響なし
影響なし

低位

NA

中位
NA
NA

◆システムの保証レベルの導出
上記で求めた影響度をフロー上にマーキングする。

NA
NA
NA

35

影響
度
中位

◆システム・プロファイル（システムの意図する使用）
項目
システムの概要・機能

意図する使用者想定する利用者数

意図する使用環境、アクセス方法ネットワークの構成と
設定条件

説明・内容
システム名：○○○○システム
政府情報システムの情報資産管理シートとデジタル庁が保有するデータを○○○社の△△システムで取込し、利用者のニーズに沿って□□□□ツールで可視化し提供する。
デジタル庁職員 システム管理Ｔ
約○名
企画Ｔ
約○名
セキュリティＴ
約○名
各府省
システム管理担当
約○名
システム運営者
約○名※システム管理に関わらない政府職員は利用しない
デジタル庁職員 庁内ネットワーク
各府省
庁内ネットワークにゲストアカウントを登録して各府省ネットからの接続
システム運営者 庁内ネットワーク
既存のデジタル庁内ネットワーク内で構成
この記載事例は省略する。
対象システムのネットワーク構成図とアクセス制限やセキュリティ機
能・機器があれば記載すること。
記載すること◆システム概要図〇〇〇〇システム△△システム
情報資産管理シート
情報資産管理シート

サンプル

デーブル作成データフロー

登録・追加更新

システム運営者

登録・追加更新

データ照会・検索システム担当イメージ□□□ツールシステム管理 T

企画 T

システム管理担当

36

データ変換

◆システム・プロファイル（システムの特質）
項目
説明・内容
情報資産
システム基本情報（管理番号、システム名、所管部門）
システム利用情報（利用開始年度、利用対象者）
システム構成（プラットフォーム、アクセス、連携先）
開発・改修履歴（開発名、開始／終了、委託先）
運用実績（登録ユーザ数、アクセス数）
システムの機能と権 機能と権限：下記に別途記載
限、認証方法
認証方法： 庁内認証基盤でのＳＳＯ（ＭＦＡ）
システムのアーキテ ○○○社（△△システム）で構成
クチャモデルシステムの相互運用 認証のため □□□と連携
性（システム連携） データの初期セットに EXCEL を使用
使用シナリオ１）庁内でデータ登録する
またはデータフロー ２）各府省からデータを登録する
３）登録データを確認・メンテナンスする
４）庁内でデータ照会する
５）庁内ユーザの権限設定をする
６）各府省のユーザ登録・アクセス権設定をする
７）各府省からのアクセスを有効／無効の設定をする（入力期間の制御処理）◆システムの機能と権限（業務上の機能と使用者の関係）
業務
機能
使用者
システム情 登録・更新機能（庁内）
システム管理Ｔ
報登録・更 調査票 Web エントリー
各府省システム管
新（登録、結果確認、履理担当歴）
情報メンテナンス
システム運営者システム情 一般情報ビューの照会システム管理Ｔ
報検索
企画Ｔ
セキュリティ T
システム構成情報の照会システム管理Ｔ
セキュリティＴ各府省からの情報照会
各府省システム管理担当
維持管理
ゲストユーザ登録
システム運営者
権限設定
システム運営者
入力期間の設定登録
システム運営者
ログ取得・確認機能
システム運営者37

システムの機能権限
システム情報登録
調査票 Web アクセス

システム情報更新
システム情報照会システム構成照会
システム情報照会（自省）（基盤担当へ申請）（基盤担当へ申請）
入力期間設定アクセスログ出力

◆システムの機能と権限（ロール定義）
権限
ユーザグループ

登録

システム管理Ｔ

調査票
Web
アクセス

情報
更新

照会
照会
入力期間 アクセス（全部） （自省）
設定
ログ出力

✔

企画Ｔ

✔

セキュリティ T✔

各府省システム
管理担当✔

✔

システム運営者

✔

✔

✔

✔

◆システムのアーキテクチャモデル
Structure

サンプル
イメージ


ミドルウェア・ＯＳＳ
コンポーネント名〇〇〇〇〇〇△△△△△△□□□□□□

Ver
1.0
2.0
3.0

提供元
〇〇〇社
〇〇〇社
□□□社

38

パッチ
レベル

サポート
期限
2029.122029.122029.12

参考資料 D）ベースラインアプローチの記載例と様式

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

39“セキュリティ管理策の“管理策のアセスメント”

選択”の項目を追加するの項目を追加する

セキュリティ管理策

セキュリティ

の要否判定を行い記管理策の実施載する。

結果を確認し記載する。

参考資料 E）事業被害ベースアプローチのリスク分析の記載例と様式8【ステップ 2】
事業被害を転記【ステップ 2】【ステップ５】

攻撃シナリオをリスクの対策【ステップ３】リスクの算定
事業被害レベルは、システム・プロファイルの事業影響度と同じ
脅威レベル・脆弱レベルは別表を参考に記載

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

ベースラインリスク分析の該当する管理策をチェック

階層的に記載8【分析結果とりまとめ】の 様式を元に作成

40

◆事業被害ベースアプローチでのリスクの算定基準9・脅威レベル
脅威
レベル

3
2

1

判断基準（技術的要素）

判断基準（時間的要素）

脅威が発生する可能性が高い。
・攻撃実現に必要な知識は限定的。
・攻撃実現に必要な技術の入手は容易。
脅威が発生する可能性が中程度である。
・攻撃実現に必要な知識は中程度。
・攻撃実現に必要な技術の入手容易性は中程度。
脅威が発生する可能性が低い。
・攻撃実現に必要な知識は膨大。
・攻撃実施に必要な技術の入手は困難。

脅威が発生する可能性が高い。
・攻撃実施に必要な時間は短い。
・攻撃実施可能な時間帯は無制限。
脅威が発生する可能性が中程度である。
・攻撃実施に必要な時間は中程度。
・攻撃実施可能な時間帯に制約がある。
脅威が発生する可能性が低い。
・攻撃実施に必要な時間は長い。
・攻撃実施可能な時間帯は極めて限定的。

・脆弱性レベル
脆弱性
レベル

判断基準

3
2

脅威に対するセキュリティ対策が実施されておらず、攻撃が成功する可能性は高い。

1

脅威の対策が十分実施されており、攻撃が成功する可能性は低い。
効果的な対策や、多層的な対策を実施しており、攻撃が成功する可能性は低い。

脅威の対策が実施されているが、十分とは言えないため、攻撃が成功する可能性は中程度である。
一般的な対策を実施しており、攻撃が成功するか否かは攻撃者のレベルに依る。

・リスク値の算定基準

低位

9

中位

高位

ＩＰＡ 「制御システムのセキュリティリスク分析ガイド第２版」を元に作成
事業被害レベルの区分について、本ガイドラインの事業影響度の表現に変更している。

41