リスク管理プロセス
セキュリティリスク分析は、セキュリティ・バイ・デザインの最初の工程であり、デジタル・ガバメント推進標準ガイドラインにおけるサービス・業務企画の工程として実施することを想定している。本ガイドラインは、その手順を示している。リスク分析の結果を対策につなげるためのリスク管理のプロセスは、セキュリティ・バイ・デザインのプロセスに含まれ実施される。
リスク分析結果の実装への反映
分析されたリスク管理策は、セキュリティ要件として定義され、システム開発のプロセスとして実装され、その結果、リスクが受容可能であることを評価する。この一連のプロセスが、セキュリティ・バイ・デザインのプロセスで実施されるよう以下の点に配慮する。
（１）セキュリティ要件
セキュリティリスク分析結果、セキュリティ対応方針に従い、システムで満たすべきセキュリティの状態が、機能面、非機能面ともに定義されていること。
【参照】デジタル庁「政府情報システムにおけるセキュリティ・バイ・デザインガイドライン」4.2.2)項：セキュリティ要件定義
要件は具体的な実装までを指示するものではないが、実装のクライテリア（合否判定基準）があるものは要件の中で示すことが望ましい。
（２）開発委託先の提示
セキュリティ要件に基づいて、システム調達におけるセキュリティ仕様が策定され、委託先との責任範囲が明確になっていること。
【参照】デジタル庁「政府情報システムにおけるセキュリティ・バイ・デザインガイドライン」4.2.3)項：セキュア調達
セキュリティ要件を調達時に示すこと、また実装の検証タイミングと評価者を委託先へ示すことが望ましい。実装の検証は、委託者が受け入れ時に行う方法と、受託者が検証してそのエビデンスを委託者が確認する方法がある。
（３）リスク対策の実施確認
セキュリティ機能に対する各種テストが実施され、品質が確保されていること。
【参照】デジタル庁「政府情報システムにおけるセキュリティ・バイ・デザインガイドライン」4.2.6)項：セキュリティテスト
ここでのセキュリティテストは、セキュリティ要件に対して、実装と検証が実施されているかのホワイトボックス・テストをいう。テストエビデンスにセキュリティ要件の管理番号を記載、または、ベースラインのシートに対策実施のエビデンス番号を記載するなど、トレーサビリティを確保する方法を推奨する。
（４）運用によるリスク対策の確認
セキュリティ管理策で運用対策とした項目について、運用体制が整備され、セキュリティ手順が策定され、運用の実行性が確保されていること。
【参照】デジタル庁「政府情報システムにおけるセキュリティ・バイ・デザインガイドライン」4.2.7)項：セキュリティ運用準備
運用によるリスク対策の確認は、開発者でなく運用認可責任者によって認可を受けること。このプロセスはビジネス/リスクオーナーが必ず監督する。
リスク分析の見直し
リスク分析は、一度実施して終わりでなく、システムのライフサイクルの間、新たなリスクが発生していないかを継続して監視しなければならない。
システムのライフサイクルでのイベントとして
・システムの設計や実装方式の決定
・運用開始後に発見された脆弱性、新しい脅威事象
・使用するプロダクトのサポート終了
・システム改修での機能追加
・システムの使用対象、アクセス環境の変化
・セキュリティ管理策が変化した場合（暗号の危殆化など）
などがある。
これらのイベントが発生した場合は、過去に実施したリスク分析を見直し、分析範囲や管理策に要否に変更がないか判断を行い、必要な場合はリスク分析の再実施と対策の実装と検証を行う。要否判断をシステム担当者だけで行わず、開発の時と同じくビジネス/リスクオーナーとセキュリティリスクアセッサーが参加し妥当性を確認する。
また、セキュリティ対策の技術や管理策は新たな脅威に対応するよう見直されているため、リスク分析の再実施では、その時点の最新技術や規格（State-of-the-Art）を基準にすることが望ましい。
リスク分析と対策を継続することは、コストが発生するために、再分析は敬遠される傾向にあるが、システムの企画段階から継続実施することを想定しアプローチすることで、効率的な対応が可能となる。本ガイドラインで採用したベースラインと事業被害ベースの組み合わせ方式のリスク分析は、上記イベント時に反復的に実行しやすいものとなっている。
変化するシステムやセキュリティの脅威に対して、継続的にセキュリティリスクの軽減をはかることが肝要である。
リスク分析ドキュメントの取扱い
リスク分析のドキュメントは、そのシステムの攻撃に有用な情報を含むため、管理対象の文書とする。セキュリティリスクアセッサーはリスク分析のドキュメントを共有する必要があるが、内容の秘匿義務を負い、公開や二次配布などしてはならない。
リスク分析から作成したセキュリティ要件は、他の開発ドキュメントと同じ基準で委託先など開発や検証の関係者へ提示しても問題はない。委託先とは他の開発ドキュメントと同じく契約で決められた守秘義務に則って運用する。
参考資料 A）参照したセキュリティ及びリスク分析のガイドライン
参考資料 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）システム・プロファイルの記載例
以下にシステム・プロファイルの記載例を示す。
記載項目は、本ガイドラインの項目を基本とするが、記載様式は自由に定めてもよい。開発ドキュメントなど他ドキュメントを引用・転用してもよい。
※本記載例は、例示を目的に作成したものであって、実際の業務や組織、システムと異なる。
――― システム・プロファイル ―――
◆セキュリティリスク分析の担当者
システム管理者： デジタル庁〇〇Ｇ△△Ｔ □□、□□、□□
ビジネス/リスクオーナー： デジタル庁〇〇Ｇ△△Ｔ □□
セキュリティリスクアセッサー： デジタル庁〇〇Ｇ△△Ｔ □□、□□
◆システム・プロファイル（事業の概要）
◆リスクの種類別の影響度
◆システムの保証レベルの導出
上記で求めた影響度をフロー上にマーキングする。
NA
NA
◆システム・プロファイル（システムの意図する使用）
◆システム概要図
◆システム・プロファイル（システムの特質）
◆システムの機能と権限（業務上の機能と使用者の関係）
◆システムの機能と権限（ロール定義）
◆システムのアーキテクチャモデル
- Structure
サンプル
- ミドルウェア・ＯＳＳ
参考資料 D）ベースラインアプローチの記載例と様式
“管理策のアセスメント”の項目を追加する
“セキュリティ管理策の選択”の項目を追加する
対象のシステムの特性にあったセキュリティ管理策を選択する。
セキュリティ管理策の実施結果を確認し記載する。
セキュリティ管理策の要否判定を行い記載する。
参考資料 E）事業被害ベースアプローチのリスク分析の記載例と様式
【ステップ2】
攻撃シナリオを階層的に記載
【ステップ2】
事業被害を転記
【分析結果とりまとめ】
ベースラインリスク分析の該当する管理策をチェック
【ステップ５】
リスクの対策
【ステップ３】リスクの算定
事業被害レベルは、システム・プロファイルの事業影響度と同じ
◆事業被害ベースアプローチでのリスクの算定基準
・脅威レベル
・脆弱性レベル
・リスク値の算定基準
