政府情報システムにおける脆弱性診断の実施基準

本章では、政府情報システムに対して脆弱性診断を行う際の実施基準を示す。ここでは診断を実施する目的の違いに着目し、以下2種類の診断施策を定義する。これらの診断は目的に応じて組み合わせて実施することを想定しており、一方の診断を代替するものではない。

構築時診断各システムの構築時に行う診断で、脆弱性対策の実施内容の確認やセキュリティ品質の確保を目的として実施するものを示す。各システムの情報セキュリティ責任者やPJMO等が、統一基準群に従い自身のWebアプリを運用段階へ移行する前に脆弱性診断を実施する場合や、ソフトウェアに関する脆弱性対策の一環として、自身の管理するシステム、あるいは新たに設置したサーバ装置、端末及び通信回線装置に対して脆弱性診断を実施する場合を想定する。各システムの開発にあたる者は、システムの構築や更改時に適切な診断が行われるようにするため、本章の基準に従い、調達仕様書等に脆弱性診断要件を明記するものとする。
定期診断各機関で定期的に実施する診断で、各システムの脆弱性対策が適切に実施されていることの点検や監査を目的として実施するものを示す。統一基準群の求める情報セキュリティ対策における自己点検や情報セキュリティ監査の一環として自組織のシステム全体を視野に実施する場合、自身の管理するシステムの運用時の対策として行う場合等を想定する。各機関で定期点検や監査にあたる者は、適切な脆弱性診断が行われるようにするため、本章の基準を参考に、脆弱性診断の実施方針を定義するものとする。

脆弱性診断の対象システム

構築時診断

新規構築または機能追加等の改修を行ったシステムを対象とする。ただし、Webアプリとスマートフォンアプリに対する脆弱性診断は、変更が軽微である場合の実施を任意とする。実施要否の判断の目安として、以下の変更が行われた場合には診断を行うことが望ましい。

Webアプリ診断

外部から入力されたデータの処理（フォームやAPI等）に追加や変更がある場合
動的な画面生成処理に追加や変更がある場合
認証、暗号化、ファイルアップロード等、実装に注意を要する処理に追加や変更がある場合
開発を担当するベンダーに変更がある場合

スマートフォンアプリ診断

ネットワーク通信に関する処理に追加や変更がある場合
認証、暗号化等のセキュリティ機能に追加や変更がある場合
アプリ間連携機能（カスタムURLスキーム等）に追加や変更がある場合
開発を担当するベンダーに変更がある場合

定期診断

定期診断の対象システムは各機関の自己点検や監査計画に準ずるものとし、本書では選定の基準を設けないものとする。保有するシステムが多く、全てのシステムの診断を行うことが難しい場合は、最高情報セキュリティアドバイザー等の有識者に相談の上、各システムのセキュリティリスクの大きさや過去の脆弱性診断の実施状況等を踏まえた総合的な判断を行うことが望ましい。

脆弱性診断の実施範囲

構築時診断

当該のシステムに対する外部攻撃のリスク低減を行う目的から、外部から攻撃を受ける可能性のある箇所（アタックサーフェス）の全てを診断の対象とする。外部との接続点を持たない箇所に対する診断は、システムの脅威環境に応じて任意で実施とする。また、実際の脅威への耐性の確認を目的として、診断対象は本番環境を前提とする。システムに対する影響を許容できない場合は検証環境等での実施も可能とするが、この場合、当該環境のシステム構成が本番環境と同等であることとする。ただし、侵入防止システム（IPS: Intrusion Prevention System）やWAF（Web Application Firewall）については、脆弱性の存在を隠蔽してしまうおそれがあることから、診断時は無効化しておくことが望ましい。これらの前提を踏まえ、各診断の対象を以下に定義する。実際の診断範囲は、以下の基準に基づき、対象システムの内部構成を把握する開発担当者を交えて検討の上、決定するものとする。

プラットフォーム診断

追加や構成の変更が生じた全ての外部公開IPアドレス（グローバルIPアドレス）を診断の対象とする（必須）
診断対象は本番環境とする。システム構成が本番環境と同等である場合に限り、検証環境等での診断を可能とする（必須）
IPSやWAFは脆弱性の存在を隠蔽するおそれがあるため、無効化した上で診断を行う（推奨）
グローバルIPアドレスを持たない装置に対する診断は、システム内部のネットワークの脅威環境に基づき、必要に応じて実施とする。実施を推奨する例としては、複数の異なるサブシステムが相乗りして利用するマルチテナント型のシステムが挙げられる。この場合は、システムを利用する一つのテナントが侵害を受けた際、他のテナントに対して侵害が及ぶ可能性を確認することを目的として、内部診断を行うこととなる（任意）

Webアプリ診断

新規追加や変更の生じた全ての外部公開インタフェース（動的画面やAPI等）を診断の対象とする。外部公開とは、ネットワーク層での送信元IPアドレス制限やクライアント証明書等によるアクセス制限等が施されておらず、インターネットからHTTP（WebSocketを含む）による何らかの通信が可能であるものを示す（必須）
他のシステムと連携する場合は、その外接箇所も診断の対象とする（推奨）
IPSやWAFは脆弱性の存在を隠蔽するおそれがあるため、無効化した上で診断を行う（推奨）

ネットワーク層での十分なアクセス制限等が施された内部機能（管理者向け画面等）の診断は必要に応じて実施とする（任意）
診断対象は本番環境を前提とする。検証環境等での診断を行う場合は、全ての外部公開インタフェースが本番と同等に診断できるように、診断用のアカウント設定やデータの投入、外部システム連携等の準備を行うものとする（必須）

スマートフォンアプリ診断

アプリストアに公開する全てのAndroidとiOS/iPadOS向けのアプリを診断の対象とする（必須）

診断対象のアプリは本番用を前提とする。検証用のアプリを対象とする場合は、サーバとの接続等を含めた全ての機能が本番用と同等に診断できるように準備を行うものとする（必須）

定期診断

各機関が保有するシステムのインベントリ情報（構成情報）に基づき、構築時診断と同様に外部から攻撃を受ける可能性のある箇所（アタックサーフェス）を対象に診断を行う。

インベントリ情報の管理

診断に際して、各機関が保有するインベントリは常に最新化されていることが重要である。インベントリの把握が難しい場合や、把握の抜け漏れが生じうる場合には、各システム担当者へのヒアリング等に加えて、セキュリティベンダーの提供するOSINT（Open Source Intelligence）[^9]やASM（Attack Surface Management）等のサービスを活用し、定期的なインベントリの見直しを行うことが望ましい。

インベントリ情報の管理対象としては、利用しているグローバルIPアドレスとドメイン名、OSとミドルウェア、サーバやPC端末、セキュリティ製品(ファイアウォール、WAF、IPS/IDS)、ネットワーク機器(VPN、ネットワーク複合機等のインターネットに接続されるもの)等が例として挙げられる。

脆弱性診断の実施規模

診断の実施範囲はシステムごとに異なり、事前の把握が難しい。このため、定期診断の調達に際しては、上限となるIPアドレス数や画面数を定めた上で調達を行うことが望ましい。この場合、実際の診断時には上限の実施数までの範囲で、優先度を付けて診断対象を選定する形となる。実施規模の目安として、プラットフォーム診断は10〜30IPアドレス程度、Webアプリ診断は50〜100リクエスト程度、スマートフォンアプリ診断は10〜20画面程度の間で定めると良い。また、実際に各システムの診断対象を決める際は、サイトのトップページから辿れる範囲で行うことや、同様の作りの画面が複数ある場合は代表する1画面のみを診断対象とすること等の選定方針を決めておくと良い。また、同じシステムを再度診断する場合は、過去に行った診断とは異なる画面やAPIを対象とすることが望ましい。いずれにせよ、最終的な診断対象は、対象システムの内部構成を把握する運用担当者を交えて決定するものとする。

脆弱性診断の実施要件

それぞれの診断の実施要件を以下に述べる。要件には、全ての診断に共通するものと、診断の種別ごとに異なるものがある。実際に要件を策定する際は、これらの要件を組み合わせるものとする。

全ての脆弱性診断に共通する要件

全ての診断に共通する要件は、診断の品質に関わる実務要件、診断を円滑に進めるための管理要件、そして診断の成果物に関する要件に大別される。特記すべき点として、実務者のスキルに関する要件（以下(5)）は必須ではなく推奨に留めている。これは、国内では高度な専門性を有する人材が限られており調達が困難であるという現状に鑑みたものである。しかしながら、脆弱性診断の品質は実務者の知見や経験に大きく左右されるため、リスクの高いシステム等においては、(5)を必須とすることが望ましい。

脆弱性診断では検出した脆弱性等の機微な情報を扱うことから、以下の要件に加え、各機関の定める情報管理や秘密保持等に関する要件を併せて求める必要がある。

経済産業省の「情報セキュリティサービス基準[^10]」における「脆弱性診断サービス」の認定を取得したセキュリティベンダーであること（必須）

上記(1)の認定基準における「技術要件」と「品質管理要件」を満たす人員が1名以上診断に参画すること（必須）
作業従事者のうち少なくとも１名は、当該の種別の診断において2年以上の経験を有すること（必須）
業務に関連する外部ステークホルダーとのコミュニケーションや調整業務について、2年以上の実務経験を有する者が診断に参画すること（必須）
以下を満たす者が１名以上診断に参画すること。条件を満たさない場合は、経験を満たすことと同等以上の技術を保持していることを政府機関の職員が判断できる理由が具体的に提示されること（推奨）
1. OSCP[^11]、OSWA[^12]、GWAPT[^13]、GPEN[^14]、GMOB[^15]またはその上位資格の保有
2. CTF等のセキュリティコンテストにおける上位入賞実績
3. 国内外の脆弱性届出制度[^16]や開発者等への報告及び調整実績（付与されたCVE識別番号[^17]等）
ツールを用いる場合は、診断対象の見落とし、診断のエラーや誤検出が含まれないように手動で精査すること（必須）
要請に応じて、休日夜間における診断業務が実施可能であること（任意）
要請に応じて、使用するネットワーク通信帯域を制限可能であること（任意）
診断の実施前に実施計画書を提出すること。実施計画書には以下を含むものとする（必須）
1. 診断の実施方針及び実施内容
2. スケジュール
3. 実施体制
4. 情報セキュリティ管理体制
5. 実施上の留意事項や準備事項
診断の実施前に、対象システムの責任者及び担当者に対して説明会を実施すること。説明会の内容は上記(9)で作成した実施計画書に準ずるものとし、診断を円滑に進められるよう、双方の役割やコミュニケーション体制を確認するものとする（推奨）
診断結果の報告書には、以下の項目を記載すること。フォーマットは機関からの指定の無い限り、PDF（Portable Document Format）形式で作成するものとする。これ以外の形式を使用する場合は、事前に機関へ相談すること（必須）
1. 検出された脆弱性の概要
2. 検出された脆弱性の深刻度
3. 検出された脆弱性による影響
4. 検出された脆弱性の対策方法
5. 脆弱性を検出した全てのパラメータ
6. 脆弱性を検出した際の入力文字列
上記(11-2)は、実際の攻撃可能性に基づき、深刻度を評価すること。評価方法はCVSSの基本評価基準に基づく5段階評価（None, Low, Medium, High, Critical）とし、その評価根拠（CVSS Vector String[^18]等）も明記すること（推奨）
上記(11-3)は、その脆弱性が悪用できることを可能な範囲で実証し、対象システムにおける現実的な攻撃の発生可能性や想定される脅威のシナリオに基づき記述すること。また、可能なものについては、実証した攻撃のスクリーンショット等の証跡を含めること（必須）
上記(11-1)(11-3)(11-4)は政府職員が読解可能な平易な文章で記述されていること。目安として、サイバーセキュリティに1年程度従事した職員が読解可能であるものとする（推奨）
診断結果の報告会を実施すること。報告会には診断の作業従事者が同席し、質疑に応じられるようにすること（推奨）
検出された脆弱性の改修後、改修した脆弱性に対する再診断を行うこと。再診断は報告書の納品から最低1カ月以内の期間、1回以上の実施ができるようにすること（必須）

総合評価の実施

上記の要件は、履行証明書等の提出を通じて入札の参加資格の確認時に利用することを想定するが、総合評価落札方式での調達が可能である場合は、上記の要件を満たすことに加えて、最高情報セキュリティアドバイザー等の有識者を交えた加点評価を行うことが望ましい。この際の主な評価観点を以下に示す。

診断に採用する手法やツールについて、診断の品質を高めるための優れた工夫がなされているか
報告書は具体的かつ政府職員が読解可能な平易な文章で記述されているか
高度な知識や経験を有する人員による体制が組まれているか

定期診断における留意点

同一の条件下で診断を繰り返し実施した場合、初回以降の検査では脆弱性が検出されない可能性がある。このため、定期診断においては、以下のような条件を変えて診断を実施することが望ましい。

診断の実施範囲（対象とするIPアドレスや画面、API等）
診断を実施するセキュリティベンダーまたは診断の作業従事者
診断に採用するツールや手法

プラットフォーム診断に関する要件

プラットフォーム診断に固有の要件を以下に示す。

表２‑１に示す全ての脆弱性種別（以下、(1-1)〜(1-4)）を診断対象とすること（必須）
1. 不要ポートの開放
2. 脆弱なソフトウェアの利用
3. 設定の不備
4. プロトコル固有の脆弱性

上記(1-1)では、TCP、UDPに対してオープンポートの確認と稼働しているサービスの推定を行うこと。TCPの確認は1〜65535番ポートの全てを対象とすること。UDPの確認には多くの時間を要することから、利用するツールが確認を推奨するポート（一般的に利用頻度の高いポート）の上位100位相当を確認対象に含めること（必須）
上記(1-2)(1-3)(1-4)に関する診断は、表４‑１に示す脆弱性種別を全て網羅すること（必須）
ツールによる診断には、最新の攻撃手法を反映した実績ある商用ツールを活用すること。フリーツールや自社製ツールのみによる診断は行わないこと（必須）

Webアプリ診断に関する要件

Webアプリ診断に固有の要件を以下に示す。Webアプリの脆弱性には人手でなければ検出の難しいものが多数存在し、また、その検出能力は実務者の知識や経験に大きく左右される。このため、攻撃されることによる社会的影響の大きいシステムや、実装に注意を要する機能（ファイルアップロード、ID連携、マイナンバーカードによる署名や認証等）を有するシステムは、上述の共通要件(5)に該当する熟練者による手動の診断を必須とすべきである。

表２‑２に示す全ての脆弱性種別（以下、(1-1)〜(1-5)）を診断対象とすること（必須）
1. 固有のビジネスロジックに依存するもの
2. 一般的な仕様上の不具合
3. 実装のメカニズムに対する高度な理解が要求されるもの
4. 一般的な実装の不備
5. 利用するWebアプリミドルウェア固有の脆弱性

上記(1-1)〜(1-3)の診断は全て人手で行うこと。ツールの誤検出の除去ではなく、診断そのものを人手で行うものとする（必須）
上記(1-2)(1-4)の診断は以下の基準に準ずること。具体的には、表４‑２に示す脆弱性種別を診断対象として網羅すること。他の基準を用いる場合は、表４‑２に対する充足性を説明すること（必須）
1. NISC「政府機関等の対策基準策定のためのガイドライン（令和５年度版）[^19]」
2. IPA「安全なウェブサイトの作り方改訂第7版[^20]」
3. 脆弱性診断士スキルマッププロジェクト「Webアプリケーション脆弱性診断ガイドライン第1.2版[^21]」
上記(1-1)〜(1-4)の診断は、(3)の基準に加え、熟練者の経験に基づく手動の診断を行うこと（推奨）
上記(1-4)(1-5)においてツールを用いる場合は、サイトを手動巡回すること（必須）
機能の確認に十分な権限を有するアカウントを用いて診断を行うこと（必須）

スマートフォンアプリ診断に関する要件

スマートフォンアプリ診断に固有の要件を以下に示す。

表２‑３に示す全ての脆弱性発生部位（以下、(1-1)〜(1-3)）を診断対象とすること（必須）
1. アプリ本体
2. 通信路
3. 外部サービス

上記(1-1)(1-3)の診断には、対象アプリのソースコードレビューまたはリバースエンジニアリングを用いること（必須）
上記(1-1)(1-2)の診断はOWASPの「Mobile Application Security Checklist (MAS Checklist)[^22]」におけるL1の実施項目を網羅するものとする[^23]。ただし、MASVS-CODE及びMASVS-RESILIENCEに属する診断項目は除外して構わない。（必須）

検出された脆弱性の対応方針

検出された脆弱性は、各機関の対応基準に従い、改修や防御策の適用を行うものとする。構築時診断ではシステムの納品前に、定期診断ではシステムの運用保守において適切に対応が行われるように契約内容等を定める必要がある。この際の対応基準は脆弱性の深刻度に基づいて策定されることが望ましい。また、既に当該の脆弱性を悪用する攻撃が国内外で観測されている場合には、対応基準に関わらず、迅速な対応を行うものとする。