Written by Y.N.
エンタープライズエンジニアとして、脆弱性診断における品質向上のためのツール開発など、バックエンドの強化に従事。
脆弱性診断を受けたものの、「報告書の読み方が分からない」「報告書や診断結果をどのように活用すればよいか迷っている」といった悩みを抱える企業・組織は少なくありません。
そこで本記事では、脆弱性診断の報告書の読み方や、診断結果をどのように活用するべきかをわかりやすく解説します。
「脆弱性診断の実施を検討している」「実施したのはいいが、活用できていない」といった企業・組織の方は、ぜひご一読ください。
はじめに
脆弱性診断を受けたものの、「報告書の読み方が分からない」「報告書や診断結果をどのように活用すればよいか迷っている」といった悩みを抱える企業・組織は少なくありません。
脆弱性診断の報告書は、診断ベンダーごとに形式や内容が大きく異なります。
ベンダー独自のフォーマットで作成される場合もあれば、診断ツールが自動生成したレポートがそのまま提供される場合もあります。
どのような報告書が最適かは受け取り手によって異なりますが、最低限押さえておくべきポイントはいくつかあります。
例えば、以下のポイントが挙げられます。
- 診断対象の範囲が明確になっているか
- 検出された脆弱性を再現できるだけの情報が記載されているか
- 脆弱性の該当箇所が適切に示されているか
- 改善に向けた具体的な対策案が提案されているか
- 診断で実施した項目が明記されているか
診断費用が安価であっても、報告書が分かりづらかった場合、内容の解読や社内展開に余計な時間がかかってしまいます。
さらに、報告書の不明瞭さが原因で重大な脆弱性を見落とし、結果として攻撃被害が発生する事態は絶対に避けなければなりません。
したがって、脆弱性診断を依頼する際は、診断後の対応までをスムーズに進められるよう、自社の理解度や方針に合ったベンダーを選定することが重要です。
「脆弱性診断を診断したまま」にならないように、脆弱性診断の報告書の読み方や、診断結果をどのように活用するべきかを確認していきましょう。
脆弱性診断報告書の基本構成と読み方
まずは、脆弱性診断報告書の基本構成と、それぞれの項目の読み解き方について解説します。
多くのベンダーが提供する報告書は、大まかに以下の項目で構成されています。
- エグゼクティブサマリ
- 診断結果
- 脆弱性の詳細
- 診断概要
これらは、脆弱性診断の報告書における最低限必要な要素ですが、ベンダーによっては、これに自社製品の宣伝などが加わる場合もあります。
各項目の詳細はベンダーによって異なりますが、主に以下の内容が記載されます。
| 項目 | 内容 |
|---|---|
| エグゼクティブサマリ | ・経営層向けに診断全体の要点をまとめた要素 ・診断結果の概要や考察、対応方針などが記載される ・検出件数や脆弱性が悪用された場合のリスク説明が含まれるケースがある |
| 診断結果 | ・検出された脆弱性の一覧 危険度や脆弱性名が記載される ・ベンダー独自の評価項目が用いられるケースもある |
| 脆弱性の詳細 | ・検出された脆弱性の説明や悪用された場合のリスク、再現例、対策例、該当箇所などの詳細が記載される |
| 診断概要 | ・診断対象、診断手法、実施時期、担当者などの基本情報が記載される ・診断環境（本番・テスト、FQDN等）や使用ツールなどが記載されるケースも多い |
報告書のどの項目を重視するかは、受け取り手の立場や目的によって異なります。
例えば、経営層への報告が必要な場合は「エグゼクティブサマリ」が重要視され、現場で修正を進める開発者や運用担当者の場合は「脆弱性の詳細」が最も重要な項目となるでしょう。
どの項目も充実しているベンダーが望ましいですが、情報の粒度や表現方法はベンダーごとに異なります。
そのため、事前に報告書のサンプルを取り寄せ、自社の活用目的に沿っているかを確認することが推奨されます。
脆弱性の深刻度や危険度の判断基準
次に、脆弱性診断実施後の「深刻度・危険度」の判断基準を解説します。
深刻度や危険度の評価基準
脆弱性診断の報告書では、CVSSスコアで脆弱性の危険度が示されるケースがあります。
CVSS（Common Vulnerability Scoring System）とは、脆弱性の深刻度を統一された基準で定量的に比較できるように作られた国際的な評価手法で、0.0〜10.0の数値で深刻度が評価します。
一般的には、このCVSSスコアが高いほど脅威の大きい脆弱性と評価されます。（※ただし、基本評価のみで判断せず、後述の内容もあわせて確認する必要があります）
例えば、以下の結果では「9.8Critical」と記載されており、CVSSの中でもほぼ最高値に近く、極めて深刻な脆弱性であることがわかります。
出典：Common Vulnerability Scoring System Version 3.1 Calculator
ベンダー独自の評価指標が使われるケース
脆弱性診断ベンダーによっては、CVSSでなくベンダー独自の指標を採用しているケースもあります。
その際は、各社が独自の基準に基づき、脆弱性そのもののリスクや想定される影響度について判断しています。
CVSSの評価と大きく乖離するケースはないと思われますが、評価基準や段階（5段階・4段階など）に違いがあるため、ベンダーを診断の毎に変更している場合は、混乱を避けるための注意が必要です。
エムオーテックスの脆弱性診断の評価基準については後述します。
CVSSスコアの算出方法
CVSSスコアは、各評価項目の設定によって算出されます。
基本評価（ベーススコア）では大きなばらつきはありませんが、これに「現状評価」「環境評価」を組み合わせることで、より正確なスコアとなります。
| 基本評価 | ・脆弱性そのものの特性を評価する指標 ・この基準による評価結果は固定していて、時間経過や環境変化によって変化しない |
|---|---|
| 現状評価 | ・脆弱性の現在の深刻度を評価する指標 ・脆弱性の対応状況に応じ、時間が経過すると変化する |
| 環境評価 | ・利用環境も含めて、最終的な脆弱性の深刻度を評価する指標 ・脆弱性に対して想定される脅威に応じて、利用者ごとに変化する |
検出されたすべての脆弱性に対して、基本評価・現状評価・環境評価まで算出しようとすると、高度なセキュリティ知識や相応の作業時間が必要になります。
そのためすべての脆弱性を詳細に評価することは、実務では困難なケースが多いです。
さらに、最終的な評価は、診断対象そのものだけでなく、周辺の環境や組織内の状況によっても変動するため、ベンダー側だけ完全に正確な評価を行うことは困難である点を理解しておく必要があります。
ベンダー独自の危険度評価
脆弱性の危険度評価は、ベンダーごとに独自の基準やロジックに基づいて行われるため、必ずしも同一ではありません。
しかしいずれのベンダーも、「脆弱性を分かりやすく伝え、セキュアなサイト運営を実現してほしい」という目的のもとで評価指標を設計しています。
そのため、独自の評価指標が用いられている場合でも、脅威を分かりやすく可視化する工夫がされていると受け止めていただけるとよいでしょう。
エムオーテックスの脆弱性診断では、以下のように危険度の評価基準を設けています。
| 危険度 | 概要 |
|---|---|
| High | 1回の攻撃による影響が大きい脆弱性 |
| Medium | 1回の攻撃による影響が小さい脆弱性 |
| Low | 被害を拡大させる潜在的な脆弱性 |
| Information | セキュリティ上および開発上の改善点 |
脆弱性診断報告書における優先度の設定方法
診断で脆弱性が検出された場合、報告書には脆弱性が記載されます。
しかしながら、前述の通り「脆弱性の危険度」は脅威を可視化したものであるため、対策の緊急性とイコールではありません。
そのため、検出されたすべての脆弱性を修正すればいいということではなく、実際にはさまざまな要素を考慮する必要があります。
では、「どれから対策すればよいのか」と悩んだ場合はどうすればいいのでしょうか。
脆弱性を修正する際は、ビジネスへの影響や脆弱性の悪用状況、ユーザビリティなど、複数の要素を考慮しながら、優先度を設定する必要があります。
優先度設定は、主に以下の3つの要素を考慮することが推奨されます。
- ビジネスへの影響度
- 脆弱性への悪用可否
- サービスの公開範囲・状況
一つずつ確認していきましょう。
ビジネスへの影響度
脆弱性の修正にあたっては、CVSSスコアやベンダー評価などの危険度指標だけでなく、自社事業への具体的な影響を総合的に評価することが重要です。
診断ベンダーは技術的な評価を行うものの、サービス内容や情報資産の重要性については自社が最も把握しています。
万が一脆弱性の悪用によって個人情報や機密データが漏洩した場合、法令違反や社会的信用失墜といった重大なリスクが生じます。
そのため、単純な数値評価に頼らず、自社サービスの特性や保有する情報資産への影響も十分に考慮したうえで、対策の優先順位や修正方針を決定することが求められます。
脆弱性の悪用可否
「Webアプリケーション診断」ではWebサイトに対する疑似攻撃を行い、「ネットワーク診断」ではサーバー等のネットワーク機器に対して擬似攻撃を行うことで、それぞれ脆弱性を発見します。
このように、脆弱性診断の種類によって発見される脆弱性は大きく異なるため、以下で紹介する判断基準をすべての診断に適用することは難しい可能性があります。
あくまで、今後の考え方の参考として捉えてください。
判断に用いられる代表的な観点として、次の2点が挙げられます。
- 攻撃方法が公開されているか
- 悪用が報告されているか
ネットワーク診断では、対象がサーバーやネットワーク機器、OSなどの機器となるため、以下のように比較的判断基準に当てはめやすい指摘が上がってきます。
- バージョン依存の脆弱性
- プロトコル起因の脆弱性
一方でWebアプリケーション診断では、同じ脆弱性が検出されたとしても、サイトの構成によって、攻撃への悪用可能性が大きく変わります。
そのため、Webアプリケーション診断では、前述の通り、脆弱性に対する正しい理解がより重要となります。
脆弱性の理解に加えて、攻撃方法や既存の悪用報告などを調査することで、自社サイトにおける優先度の判断に役立てることができるでしょう。
サービスの公開範囲・状況
サービスの公開範囲や運用状況は、大きく以下の4つに分類できます。
- イントラネット環境
- 開発環境
- リリース前本番環境
- 本番稼働環境
例えば、リリース前本番環境や開発環境の段階で脆弱性が発見された場合、リリースまでの期間に猶予がない場合を除き、リリースまでに修正できれば問題ありません。
一方本番環境においては、利用者の関与が必要な脆弱性であっても、外部の第三者によって情報が公開されてしまったり、実際に攻撃を受けたりするリスクがあるため、迅速な対応判断が求められるケースがあります。
イントラネット環境における脆弱性は、一見優先度が低いと判断されがちですが、ネットワークへの侵入に悪用されたり、限定された公開範囲を狙った攻撃者に悪用されたりする可能性があるため、注意が必要です。
このように、「本番環境だからすべて緊急」「イントラネット環境だから優先度は低い」といった単純な判断は避けるべきです。
発見された脆弱性や悪用状況、サービスの公開範囲等を考慮して、自社にとっての優先度を適切に判断することが重要です。
そのほか
CVSSや独自評価で意思決定が難しい場合は、「SSVC（Stakeholder-Specific Vulnerability Categorization）」などの意思決定フレームワークの活用も選択肢になります。
SSVCとは、組織の現実に合わせて「脆弱性対応の優先度」を意思決定するフレームワークです。
詳細が知りたい方は、以下のサイトをご参照ください。
参考：Risk Based Prioritization「Stakeholder-Specific Vulnerability Categorization (SSVC) 」
まとめ
今回は、脆弱性診断報告書の構成や読み方、深刻度・優先度のポイントについて解説しました。
今後の脆弱性の対処の参考になれば幸いです。
脆弱性診断等を実施し自社サービス等の現状を把握することは、安全なシステム運営のために極めて重要です。
また、受診後の対応によって、よりセキュアな運営ができるかが決まります。
適切に対処していきましょう。
次回は、具体的な修正対応や教育方法などについてご紹介したいと思います。
おすすめ記事
