脆弱性診断の概要

本章では、脆弱性診断を効果的に推進する上で必要となる基本的な事項を解説する。脆弱性診断はシステムにおけるセキュリティ上の弱点を特定するものであるが、診断のみでシステムのセキュリティリスクを防ぐことはできない。また、脆弱性診断は既に作り込まれた脆弱性を検出するものであるが、それ以前に脆弱性の発生を未然に防ぐことが肝要である。こうした背景から、脆弱性診断は他のセキュリティプロセス（パッチマネジメントやセキュアコーディング、セキュリティレビュー等）と組み合わせて実施することが望ましい。さらに、脆弱性診断の検出結果をセキュリティプロセスそのものの改善に役立てていくことが望ましい。

脆弱性対策における脆弱性診断の位置付け

本節では、はじめにシステムの脆弱性対策全体を俯瞰し、その中における脆弱性診断の位置付けを明らかにする。図 ２‑１は、システムにおける脆弱性を集合として表したものである。

図 ２‑１では、次の集合を定義している。

• システムにおける脆弱性全体 (U) 当該のシステムにおいて本来対処すべき脆弱性の母集団と定義する。サイバー攻撃の高度化や新しい攻撃手法の発見、システム構成の複雑化等の複合的な要因により、(U)は時間とともに増えていく構造にある。

• 発生の想定される脆弱性 (A) 脆弱性の母集団(U)のうち、システム開発に関わるステークホルダーが発生を予期できる脆弱性の集合を(A)と定義する。(A)には、過去に検出されたことのある脆弱性や一般的によく知られている脆弱性等が含まれる。往々にして、(A)の集合の大きさはシステムに携わる者の知見に左右される。政府機関においては、外部有識者の知見を活用し、組織や開発プロセスを通じて(A)を補強していく必要がある。また、母集団(U)が拡大を続けていく中、最新の脅威情報に基づき、常に(A)を最新化していくことが必要である。

• 仕様や要件としてカバーしている脆弱性 (B) 集合(B)は発生の想定される脆弱性(A)の部分集合にあたり、各機関の情報セキュリティポリシーや開発の要件定義等において発生を防ぐための対策が求められるものである。対策内容が明示的であることから、仕様や実装に適切に反映されていること（トレーサビリティ）の確認や、対策状況について第三者による確認や検証が可能である。理想的には(B)を(A)に近づけていくことが望ましいが、(A)には有識者ならではの暗黙的な知見や、汎化や明文化の難しい各システム固有の脅威も含まれることから、部分的とならざるを得ない状況にある。

• 想定外の脆弱性($\overline{A}$) 集合($\overline{A}$)は、システム開発に関わるステークホルダーでは発生の予期できない脆弱性である。システムを運用していく中では、予期しない脆弱性が常に発生しうることを認識しておくことが重要である。サイバー攻撃に悪用される脆弱性は母集団(U)であることから、攻撃を防ぐためには、発生を予期できる脆弱性(A)を(U)に近づけて行くための取り組みや、攻撃者の目線から($\overline{A}$)の存在をテストするといった取り組みが必要となる。

上記の構造を踏まえた上で、脆弱性診断は発生の想定される脆弱性(A)の確認を目的として実施することが望ましい。これには、仕様や要件としてカバーすべき脆弱性(B)として本来対処すべきであったものの漏れを検出することや、発生が想定される脆弱性(A)のうち政府機関内の知見ではカバーできていなかったものを検出することが含まれる。

脆弱性診断そのものは既に発生してしまった脆弱性を検出するものであることから、セキュリティ・バイ・デザイン等の取り組みを強化し、脆弱性が作り込まれない状態を目指していくことが重要である。また、脆弱性診断は対象システムにおける将来の脆弱性の発生を防ぐものではないことから、診断で検出された脆弱性はシステム開発の要件定義や組織のセキュリティプロセスに反映し、(B)の対策の強化につなげていくことが望ましい。

想定外の脆弱性($\overline{A}$)の対策には脆弱性報奨金制度により未知の脆弱性の検出を試みること等が挙げられるが、本書のスコープからは除外するものとする。($\overline{A}$)の対策は際限なく実施できるため、システムが侵害された際のリスクや費用対効果を鑑み、対策の実施内容を決めることが望ましい。

一般的な脆弱性診断の種別

図 ２‑２は、システムに脆弱性が混入しうる箇所を部位ごとにまとめたものである。

図 ２‑２が示すとおり、脆弱性の発生箇所はシステムの広範に渡る。攻撃のアクターはこれら全体の中から脆弱性を見つけ出し悪用しうることから、その対策もまたシステム全体を網羅的に行う必要がある。セキュリティベンダーが提供する診断サービスもまた、診断対象の部位に応じてサービスが分かれている。

本書が対象とする3種類の脆弱性診断は、図 ２‑２の次の部位を対象とする。上記の脆弱性診断は、脆弱性の発生部位に応じて組み合わせて行う必要がある。

• プラットフォーム診断 FW（ファイアウォール）、LB（ロードバランサ）、リバースプロキシ、仮想化インフラ、サーバOS（ゲストOS）、サーバミドルウェア、VPN

• Webアプリ診断 Webアプリ、アプリミドルウェア

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

昨今はVPN機器や外部ネットワークに接続されている複合機等が攻撃の起点として狙われていることから、これらも診断対象とする必要がある。また、連携する外部システムも侵入の糸口となるおそれがあることから、脆弱性診断の実施状況等を確認することが望ましい。

プラットフォーム診断

プラットフォーム診断は、対象のサーバやネットワーク機器等に対して疑似的な攻撃の通信を行うことにより、脆弱性やセキュリティリスクの有無を確認するものである。一般的には自動化されたツールを用いて診断を行い、誤検出（偽陽性）の精査やツールでは検出できない脆弱性の診断を人手で補う。

プラットフォーム診断では、主に表 ２‑１のようなセキュリティ上の問題が検出される。

表 ２‑１　プラットフォーム診断で検出される脆弱性

プラットフォーム診断には、外部診断（リモート診断）と内部診断（オンサイト診断）が存在する。外部診断は、グローバルIPアドレスを通じてインターネットからアクセス可能な装置を対象とし、セキュリティ境界の外側より攻撃者が悪用可能な脆弱性を明らかにすることを目的とする。一方の内部診断は、システム内のネットワークや拠点のLAN内等における主にプライベートIPアドレスを有する装置を対象とし、セキュリティ境界の内側で、内部犯や境界防御を超えて侵入した外部の攻撃者により悪用されうる脆弱性を明らかにする。

過去に診断を実施していない場合、優先して実施すべきは外部診断である。外部診断の場合、診断対象はグローバルIPアドレス単位となり、診断の費用はIPアドレス数に応じて変動する。内部診断もまた、診断対象のIPアドレス数に応じて費用が変動する。また、現地に出向いて診断を行うことに対する追加費用が生じることがある。

新しい脆弱性や攻撃手法は日々公表されるため、診断サービスの選定においては、最新の脆弱性情報を収集し診断項目に反映させていることの確認が必要である。また、ツールの検出結果には誤検出や実際には攻撃の困難な指摘事項が含まれうるため、診断対象のシステムに対する現実的な攻撃の発生可能性に基づいて対応要否を判断する必要がある。

Webアプリ診断

Webアプリ診断は、対象のWebアプリ（Web APIを含む）に対して疑似的な攻撃のリクエストを行うことにより、情報漏えいやサイト改ざん等につながる脆弱性の有無を確認するものである。診断手法には、ツールによる自動診断、専門家による手動診断、両者を併用するものの3種類が存在する。情報処理推進機構（IPA）の「安全なウェブサイトの作り方[^4]」等のセキュリティ標準への準拠を謳う診断サービスも存在する。

Webアプリ診断では、主に表 ２‑２のような脆弱性が検出される。

ツールによる自動診断は効率の観点では有用であるが、仕様に起因する脆弱性(A)全般の検出が難しい。また、実装上の問題(B)の中でも、対象のWebアプリの内部実装に対する深い洞察を要する脆弱性(B-1)や、一般的な実装の不備による脆弱性(B-2)においても一定の制限を迂回しなければ攻撃できないものが見落とされやすいため、専門家の人手による診断で補強する必要がある。

セキュリティ標準に基づく診断サービスも、テストのカバレッジを確認する用途では有用であるが、これらの標準がカバーするのは多くのWebサイトに見られる一般的な脆弱性(A-2)(B-2)に留まることから、専門家の知見に基づき、対象のWebアプリに固有の脆弱性(A-1)(B-1)を診断する必要がある。

情報システムの開発では、WebアプリケーションフレームワークやCMS等の様々なサードパーティのミドルウェアが利用されるため、これらに固有の脆弱性(C)が検出できることも重要である。この中には、個々のミドルウェアが提供する機能の誤用や設定の誤りにより発現するものが含まれるため、システムの利用するミドルウェアの内部構造に精通した専門家による診断が必要となる。

過去に診断を実施していない場合、優先して実施すべきはインターネットからアクセス可能な箇所である。この場合の診断は、対象の外部公開機能に対してインターネットを通じて行われる。診断対象は主に画面数やAPI等のリクエスト数単位となり、診断の費用もこれらの数によって変動する。

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

スマートフォンアプリ診断は、AndroidやiOS/iPadOS端末上で動作するアプリの脆弱性の有無を確認するものである。診断対象にはアプリ本体に加え、アプリとサーバとの間の通信等も含まれる。診断手法にはアプリ本体をツールで自動解析するものや、リバースエンジニアリングを用いるもの、アプリとサーバ間の通信内容に着目し脆弱性を探索するもの等がある。

スマートフォンアプリ診断で検出される脆弱性の発生箇所を図 ２‑３に示す。

図 ２‑３の(A)〜(C)において検出される脆弱性の代表例は以下の通りである。

診断サービスを選定する際は、上記の(A)〜(C)に述べた発生部位の脆弱性が網羅されることを確認する必要がある。また、ツールによる自動解析では実際には悪用できないものが脆弱性として指摘される場合があるため、攻撃の実証までを行う診断サービスを選定することが重要である。さらに、昨今JVN[^5]等で公表されている脆弱性にはアプリに認証情報がハードコードされている等のリバースエンジニアリングにより発見されるものが見られることから、脆弱性を未然に防ぐためには、ソースコードレビューやリバースエンジニアリング等の手法が含まれる診断サービスを選定する必要がある。

スマートフォンアプリは各利用者の端末上で実行されることや、アプリ本体を容易に解析可能であることから、セキュリティを確保することが難しい。様々な脅威を全て対策することは不可能であり、また対策にかかる費用も高額となることから、費用対効果に応じて対策を行うことが望ましい。

その他の脆弱性診断

これまでに述べた脆弱性診断の他にも、様々な種類の診断サービスが存在する。情報システムではなく制御システムやIoT機器を対象とするもの、システムではなく物理環境、組織とその従業員を対象とするもの等が登場してきている。これらの診断については、政府情報システムにおける導入の必要性が高まってきた際に、適宜、本書のスコープに加えるものとする。

脆弱性診断を行うにあたっての留意事項

脆弱性診断サービスの選定

高度化するサイバー攻撃の脅威を未然に防ぐためには、十分な経験と能力を有したセキュリティベンダーの選定を要することから、選定に際しては経済産業省の定義する「情報セキュリティサービス基準[^6]」を満たすことの確認に加えて、脆弱性を検出する能力を測るため、ペネトレーションテストの国際資格の保有状況やCTF（Capture The Flag）等のセキュリティコンテストにおける上位入賞実績、国内外の脆弱性届出制度[^7]や開発者等への報告及び調整実績を問い合わせること等が有効である。また、診断サービスの調達においては、上記の基準に沿った有識者や有資格者が、診断の実施の中で、どのような役割として、何名、どの期間に関わる予定であるかを確認することが望ましい。

診断サービスの選定においては、ツールによる自動的な診断のみでは不十分であり、専門家による手動による診断との併用が不可欠である。また、手動の診断においても、事前に定義された脆弱性を網羅的に検出することに加え、専門家の知見に基づきリスクベースで追加の脆弱性検出を試みるサービスを併用することが必要である。

脆弱性診断の推進においては、システムの非公開情報や検出した脆弱性をはじめとする機密性の高い情報を取り扱うこととなるため、統一基準群に基づき、情報管理体制を有することの確認が必要となる。また、診断におけるシステムへの影響を最小化するための仕組みやルールの有無に加え、診断を行う要員にルールを遵守させるための取り組みを備えていることを確認することが望ましい。

検出された脆弱性の深刻度評価

診断により検出された脆弱性は、保有するシステムに対するリスク評価に基づき、優先度を定め対応する必要がある。こうした脆弱性の評価において世界的に活用されているのはFIRST（Forum of Incident Response and Security Teams）が公開するCVSS（Common Vulnerability Scoring System）[^8]である。CVSSでは、脆弱性そのものの技術的な深刻度を評価する基本評価基準（Base Metrics）に加え、攻撃コードの出現状況や対象のシステム環境において想定される脅威に基づき、0.0〜10.0までのスコアで脆弱性の深刻度を評価する。また、このスコアに応じて、深刻度を以下の5段階で表現している。

表 ２‑４　CVSSのスコアと深刻度

脆弱性診断では、検出された脆弱性の深刻度をCVSSの基本評価基準で評価することが多い。しかし、基本評価基準はあくまでもその脆弱性の技術的特性を示すものであり、それ単体で対応の優先度を決めるべきものではない。基本評価基準を参考に自身のシステム環境において想定される具体的なリスクに基づいて対応の優先度を定めることが望ましい。セキュリティベンダーによっては、独自基準で脆弱性の深刻度を評価する場合がある。こうした場合も、CVSSの基本評価基準と同等のものとして扱い、自身のシステムにおけるリスク評価を行う必要がある。

脆弱性診断に伴うリスク

脆弱性診断は対象のシステムに対して疑似的な攻撃を仕掛けるため、システムに影響を与えるおそれがある。診断の実施においては、システムに発生しうるリスクを認識し、事前に関係者との間でリスクの低減に向けた取り組みを行う必要がある。生じうるリスクには以下のようなものが挙げられるが、他にも予期しない問題が生じる可能性がある。

• 診断の通信によるネットワーク通信帯域の圧迫

• システムのクラッシュ等に伴うサービス停止

• 疑似攻撃のペイロードを含むダミーデータのデータベースへの残存

• 大量のメール送信の発生

• データの破損や損失

• 脆弱性の検証に伴う個人情報や機密情報の意図せぬ閲覧

• 攻撃の検知やエラーの大量発生等に伴う監視アラートの発生

これらのリスクを低減するため、本番環境ではなく検証環境で診断することや、本番環境で行う場合は事前のデータバックアップ等を検討する。また、業務への影響を避けるため、休日や夜間、メンテナンス時間帯等に診断を行うことも考慮し、その旨を発注時にも明記する。診断の開始前には、異常発生時のエスカレーションルールや事業継続計画（BCP: Business Continuity Plan）を確認しておくことで、万が一障害が発生した際、迅速な対応が可能となる。

テストを行う際は、影響を受けるおそれのある全ての関係者に対して、事前に周知と診断可否の確認を行う。この際の関係者には主に以下を含むが、対象のシステムによって異なる。

• 対象システムの責任者（システムオーナー）

• 対象システムの開発や運用者

• 対象システムの負荷や異常監視を行う者

• インフラ提供者（クラウドサービスプロバイダー等）

特にインフラ提供者によって禁止されている診断項目や、関係者がリスクを許容できない診断内容は実施を避ける必要がある。プラットフォーム診断等においてサービス妨害（DoS: Denial of Service）の脆弱性を診断する必要がある場合は、明示的に確認を行い、関係者の許可を得る必要がある。診断を行うセキュリティベンダーにも、安全管理の指針を組織として有することの確認や、安全対策に関する項目を盛り込んだ契約を締結する。