4. リスク管理プロセス
セキュリティリスク分析は、セキュリティ・バイ・デザインの最初の工程であり、デジタル・ガバメント推進標準ガイドラインにおけるサービス・業務企画の工程として実施することを想定している。本ガイドラインは、その手順を示している。リスク分析の結果を対策につなげるためのリスク管理のプロセスは、セキュリティ・バイ・デザインのプロセスに含まれ実施される。
4.1. リスク分析結果の実装への反映
分析されたリスク管理策は、セキュリティ要件として定義され、システム開発のプロセスとして実装され、その結果、リスクが受容可能であることを評価する。この一連のプロセスが、セキュリティ・バイ・デザインのプロセスで実施されるよう以下の点に配慮する。
（１）セキュリティ要件
セキュリティリスク分析結果、セキュリティ対応方針に従い、システムで満たすべきセキュリティの状態が、機能面、非機能面ともに定義されていること。
【参照】デジタル庁「政府情報システムにおけるセキュリティ・バイ・デザインガイドライン」4.2.2)項：セキュリティ要件定義
要件は具体的な実装までを指示するものではないが、実装のクライテリア（合否判定基準）があるものは要件の中で示すことが望ましい。
（２）開発委託先の提示
セキュリティ要件に基づいて、システム調達におけるセキュリティ仕様が策定され、委託先との責任範囲が明確になっていること。
【参照】デジタル庁「政府情報システムにおけるセキュリティ・バイ・デザインガイドライン」4.2.3)項：セキュア調達
セキュリティ要件を調達時に示すこと、また実装の検証タイミングと評価者を委託先へ示すことが望ましい。実装の検証は、委託者が受け入れ時に行う方法と、受託者が検証してそのエビデンスを委託者が確認する方法がある。
（３）リスク対策の実施確認
セキュリティ機能に対する各種テストが実施され、品質が確保されていること。
【参照】デジタル庁「政府情報システムにおけるセキュリティ・バイ・デザインガイドライン」4.2.6)項：セキュリティテスト
ここでのセキュリティテストは、セキュリティ要件に対して、実装と検証が実施されているかのホワイトボックス・テストをいう。テストエビデンスにセキュリティ要件の管理番号を記載、または、ベースラインのシートに対策実施のエビデンス番号を記載するなど、トレーサビリティを確保する方法を推奨する。
（４）運用によるリスク対策の確認
セキュリティ管理策で運用対策とした項目について、運用体制が整備され、セキュリティ手順が策定され、運用の実行性が確保されていること。
【参照】デジタル庁「政府情報システムにおけるセキュリティ・バイ・デザインガイドライン」4.2.7)項：セキュリティ運用準備
運用によるリスク対策の確認は、開発者でなく運用認可責任者によって認可を受けること。このプロセスはビジネス/リスクオーナーが必ず監督する。
4.2. リスク分析の見直し
リスク分析は、一度実施して終わりでなく、システムのライフサイクルの間、新たなリスクが発生していないかを継続して監視しなければならない。
システムのライフサイクルでのイベントとして
・システムの設計や実装方式の決定
・運用開始後に発見された脆弱性、新しい脅威事象
・使用するプロダクトのサポート終了
・システム改修での機能追加
・システムの使用対象、アクセス環境の変化
・セキュリティ管理策が変化した場合（暗号の危殆化など）
などがある。
これらのイベントが発生した場合は、過去に実施したリスク分析を見直し、分析範囲や管理策に要否に変更がないか判断を行い、必要な場合はリスク分析の再実施と対策の実装と検証を行う。要否判断をシステム担当者だけで行わず、開発の時と同じくビジネス/リスクオーナーとセキュリティリスクアセッサーが参加し妥当性を確認する。
また、セキュリティ対策の技術や管理策は新たな脅威に対応するよう見直されているため、リスク分析の再実施では、その時点の最新技術や規格（State-of-the-Art）を基準にすることが望ましい。
リスク分析と対策を継続することは、コストが発生するために、再分析は敬遠される傾向にあるが、システムの企画段階から継続実施することを想定しアプローチすることで、効率的な対応が可能となる。本ガイドラインで採用したベースラインと事業被害ベースの組み合わせ方式のリスク分析は、上記イベント時に反復的に実行しやすいものとなっている。
変化するシステムやセキュリティの脅威に対して、継続的にセキュリティリスクの軽減をはかることが肝要である。
4.3. リスク分析ドキュメントの取扱い
リスク分析のドキュメントは、そのシステムの攻撃に有用な情報を含むため、管理対象の文書とする。セキュリティリスクアセッサーはリスク分析のドキュメントを共有する必要があるが、内容の秘匿義務を負い、公開や二次配布などしてはならない。
リスク分析から作成したセキュリティ要件は、他の開発ドキュメントと同じ基準で委託先など開発や検証の関係者へ提示しても問題はない。委託先とは他の開発ドキュメントと同じく契約で決められた守秘義務に則って運用する。
参考資料 A）参照したセキュリティ及びリスク分析のガイドライン
| # | 発行元 | ガイドライン名 | URL |
|---|---|---|---|
| 1 | デジタル庁 | 政府情報システムにおけるセキュリティ・バイ・デザインガイドライン （令和4年6月30日） |
|
| 2 | NISC(内閣サイバーセキュリティセンター) | 政府機関等のサイバーセキュリティ対策のための統一基準 （令和3年7月7日） |
|
| 3 | NISC(内閣サイバーセキュリティセンター) | 政府機関等の対策基準策定のためのガイドライン （令和3年7月7日） |
|
| 4 | NISC(内閣サイバーセキュリティセンター) | 情報システムに係る政府調達におけるセキュリティ要件策定マニュアル(SBDマニュアル) （2022 年７月 29 日） |
|
| 5 | ISO/JIS | ISO31000:2018, Risk management－Guidelines JIS Q 31000:2019 リスクマネジメント指針 |
|
| 6 | IPA（情報処理推進機構） | 制御システムのセキュリティリスク分析ガイド 第２版 （2020 年 3 月） |
|
| 7 | IPA（情報処理推進機構） | セキュリティ・バイ・デザイン導入指南書 （2022年8⽉） |
|
| 8 | NIST（米国国立標準技術研究所） | NIST SP800-63-3 Digital Identity Guidelines (UPDATES AS OF 03-02-2020) デジタル・アイデンティティ・ガイドライン |
|
| 9 | NIST（米国国立標準技術研究所） | NIST SP800-37 Rev2 Risk Management Framework for Information Systems and Organizations A System Life Cycle Approach for Security and Privacy (Dec. 2018) 情報システムおよび組織のためのリスクマネジメントフレームワーク －セキュリティとプライバシーのためのシステムライフサイクルアプローチ |
|
| 10 | NIST（米国国立標準技術研究所） | Cybersecurity Framework Version 1.1 | |
| 11 | NIST（米国国立標準技術研究所） | NIST SP800-53 Rev.5 Security and Privacy Controls for Information Systems and Organizations 組織と情報システムのためのセキュリティおよびプライバシー管理策 |
|
| 12 | NIST（米国国立標準技術研究所） | FIPS PUB 199: Feb 2004 Standards for Security Categorization of Federal Information and Information Systems 連邦情報処理標準 (FIPS 199) 連邦政府の情報および情報システムに対するセキュリティ分類規格 |
|
| 13 | ANSSI（フランス国家情報システムセキュリティ機関） | EBIOS RISK MANAGER Version 1.0 — November 2019 |
|
| 14 | OWASP | Software Assurance Maturity Model （Version 2.0.3 (2022)） |
参考資料 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.03 or Ver5
(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)
参考資料 C）システム・プロファイルの記載例
以下にシステム・プロファイルの記載例を示す。
記載項目は、本ガイドラインの項目を基本とするが、記載様式は自由に定めてもよい。開発ドキュメントなど他ドキュメントを引用・転用してもよい。
※本記載例は、例示を目的に作成したものであって、実際の業務や組織、システムと異なる。
――― システム・プロファイル ―――
◆セキュリティリスク分析の担当者
システム管理者： デジタル庁〇〇Ｇ△△Ｔ □□、□□、□□
ビジネス/リスクオーナー： デジタル庁〇〇Ｇ△△Ｔ □□
セキュリティリスクアセッサー： デジタル庁〇〇Ｇ△△Ｔ □□、□□
◆システム・プロファイル（事業の概要）
| 項目 | 説明・内容 |
|---|---|
| 事業目的・ミッション | デジタル庁及び政府各省が管理運営するシステムの全体像把握に必要な情報を収集・蓄積して、デジタル庁としての意思決定・組織運営に活用するため、ダッシュボードを用いてわかりやすく可視化する。 |
事業の影響度 システムの保証レベル |
ＡＡＬ２（中程度） ・リスクの種類別の影響度は下記別表に記載 ・保証レベルは、システムの保証レベルのデシジョンフローから導出 |
| 情報システム運用継続計画の復旧優先度 | ＲＴＯ(目標復旧時間)：1 週間から2 週間以内に復旧が必要な情報システム ＲＬＯ(目標復旧レベル)：特になし 復旧優先度：Ｄ |
| 統一基準での情報格付区分 | 機密性３情報：なし 機密性２情報：あり （システム構成等非公開情報を含む） 完全性２情報：なし （オリジナルデータから復元可能） 可用性２情報：なし （停止しても代替方法あり） |
| その他の格付区分 | 特になし |
◆リスクの種類別の影響度
| ＃ | 事業リスク Impacts per Category |
最も大きな事業被害 | 影響度 |
|---|---|---|---|
① |
利用者に不便、苦痛を与える、又は事業を所管する機関等が信頼を失う |
サイバー攻撃によってシステムが停止し、利用できなくなる。 サイバーインシデントの被害が公になり、デジタル庁の信頼低下を招く。 |
中位 |
② |
利用者に金銭的被害を与える、機関等に賠償責任が生じるなど財務上の影響を与える |
サイバー攻撃によって、システムのデータやプログラムが改ざんされてしまい、復旧のための工数（費用）が発生する。 |
低位 |
③ |
機関等の活動計画や公共の利益に対して影響を与える |
影響なし（効率は悪化するが、このシステムだけに異存はしていないので実害はない） |
NA |
④ |
利用者の個人情報などの機微な情報が漏洩する |
システムの構成情報が漏洩し、セキュリティ攻撃に悪用される |
中位 |
⑤ |
利用者の身の安全に影響を与える |
影響なし |
NA |
⑥ |
法律に違反する |
影響なし |
NA |
◆システムの保証レベルの導出
上記で求めた影響度をフロー上にマーキングする。
NA
NA
◆システム・プロファイル（システムの意図する使用）
| 項目 | 説明・内容 |
|---|---|
| システムの概要・機能 | システム名：○○○○システム 政府情報システムの情報資産管理シートとデジタル庁が保有するデータを○○○社の△△システムで取込し、利用者のニーズに沿って□□□□ツールで可視化し提供する。 |
意図する使用者 想定する利用者数 |
デジタル庁職員 システム管理Ｔ 約○名 企画Ｔ 約○名 セキュリティＴ 約○名 各府省 システム管理担当 約○名 システム運営者 約○名 ※システム管理に関わらない政府職員は利用しない |
| 意図する使用環境、 アクセス方法 | デジタル庁職員 庁内ネットワーク 各府省 庁内ネットワークにゲストアカウント を登録して各府省ネットからの接続 システム運営者 庁内ネットワーク |
| ネットワークの構成と設定条件 |
◆システム概要図
◆システム・プロファイル（システムの特質）
| 項目 | 説明・内容 |
|---|---|
| 情報資産 | システム基本情報（管理番号、システム名、所管部門） システム利用情報（利用開始年度、利用対象者） システム構成（プラットフォーム、アクセス、連携先） 開発・改修履歴（開発名、開始／終了、委託先） 運用実績（登録ユーザ数、アクセス数） |
| システムの機能と権限、認証方法 | 機能と権限：下記に別途記載 認証方法： 庁内認証基盤でのＳＳＯ（ＭＦＡ） |
| システムのアーキテクチャモデル | ○○○社（△△システム）で構成 |
| システムの相互運用性（システム連携） | 認証のため □□□と連携 データの初期セットにEXCELを使用 |
使用シナリオ またはデータフロー |
１）庁内でデータ登録する ２）各府省からデータを登録する ３）登録データを確認・メンテナンスする ４）庁内でデータ照会する ５）庁内ユーザの権限設定をする ６）各府省のユーザ登録・アクセス権設定をする ７）各府省からのアクセスを有効／無効の設定をする （入力期間の制御処理） |
◆システムの機能と権限（業務上の機能と使用者の関係）
| 業務 | 機能 | 使用者 | システムの機能権限 |
|---|---|---|---|
| システム情報登録・更新 | 登録・更新機能（庁内） | システム管理Ｔ | システム情報登録 |
調査票Webエントリー （登録、結果確認、履歴） |
各府省システム管理担当 | 調査票Webアクセス | |
| 情報メンテナンス | システム運営者 | システム情報更新 | |
| システム情報検索 | 一般情報ビューの照会 | システム管理Ｔ 企画Ｔ セキュリティT |
システム情報照会 |
| システム構成情報の照会 | システム管理Ｔ セキュリティＴ |
システム構成照会 | |
| 各府省からの情報照会 | 各府省システム管理担当 | システム情報照会（自省） | |
| 維持管理 | ゲストユーザ登録 | システム運営者 | （基盤担当へ申請） |
| 権限設定 | システム運営者 | （基盤担当へ申請） | |
| 入力期間の設定登録 | システム運営者 | 入力期間設定 | |
| ログ取得・確認機能 | システム運営者 | アクセスログ出力 |
◆システムの機能と権限（ロール定義）
| ユーザグループ | 権限 | |||||||
|---|---|---|---|---|---|---|---|---|
| 登録 | 調査票Web アクセス | 情報 更新 |
照会 （全部） |
照会 （自省） | 入力期間設定 | アクセスログ出力 | ||
| システム管理Ｔ | ✔ | |||||||
| 企画Ｔ | ✔ | |||||||
| セキュリティT | ✔ | |||||||
| 各府省システム管理担当 | ✔ | ✔ | ||||||
| システム運営者 | ✔ | ✔ | ✔ | ✔ | ||||
◆システムのアーキテクチャモデル
- Structure
サンプル
- ミドルウェア・ＯＳＳ
| コンポーネント名 | Ver | 提供元 | パッチ レベル | サポート 期限 |
|---|---|---|---|---|
| 〇〇〇〇〇〇 | 1.0 | 〇〇〇社 | 2029.12 | |
| △△△△△△ | 2.0 | 〇〇〇社 | 2029.12 | |
| □□□□□□ | 3.0 | □□□社 | 2029.12 |
参考資料 D）ベースラインアプローチの記載例と様式
“管理策のアセスメント”の項目を追加する
“セキュリティ管理策の選択”の項目を追加する
対象のシステムの特性にあったセキュリティ管理策を選択する。
セキュリティ管理策の実施結果を確認し記載する。
セキュリティ管理策の要否判定を行い記載する。
参考資料 E）事業被害ベースアプローチのリスク分析の記載例と様式
【ステップ2】
攻撃シナリオを階層的に記載
【ステップ2】
事業被害を転記
【分析結果とりまとめ】
ベースラインリスク分析の該当する管理策をチェック
【ステップ５】
リスクの対策
【ステップ３】リスクの算定
事業被害レベルは、システム・プロファイルの事業影響度と同じ
◆事業被害ベースアプローチでのリスクの算定基準
・脅威レベル
| 脅威 レベル | 判断基準（技術的要素） | 判断基準（時間的要素） |
| 3 | 脅威が発生する可能性が高い。 ・攻撃実現に必要な知識は限定的。 ・攻撃実現に必要な技術の入手は容易。 |
脅威が発生する可能性が高い。 ・攻撃実施に必要な時間は短い。 ・攻撃実施可能な時間帯は無制限。 |
| 2 | 脅威が発生する可能性が中程度である。 ・攻撃実現に必要な知識は中程度。 ・攻撃実現に必要な技術の入手容易性は中程度。 |
脅威が発生する可能性が中程度である。 ・攻撃実施に必要な時間は中程度。 ・攻撃実施可能な時間帯に制約がある。 |
| 1 | 脅威が発生する可能性が低い。 ・攻撃実現に必要な知識は膨大。 ・攻撃実施に必要な技術の入手は困難。 |
脅威が発生する可能性が低い。 ・攻撃実施に必要な時間は長い。 ・攻撃実施可能な時間帯は極めて限定的。 |
・脆弱性レベル
| 脆弱性レベル | 判断基準 |
| 3 | 脅威に対するセキュリティ対策が実施されておらず、攻撃が成功する可能性は高い。 |
| 2 | 脅威の対策が実施されているが、十分とは言えないため、攻撃が成功する可能性は中程度である。 一般的な対策を実施しており、攻撃が成功するか否かは攻撃者のレベルに依る。 |
| 1 | 脅威の対策が十分実施されており、攻撃が成功する可能性は低い。 効果的な対策や、多層的な対策を実施しており、攻撃が成功する可能性は低い。 |
・リスク値の算定基準
