概要
脆弱性管理(Vulnerability Management)は、システムに存在する脆弱性を継続的に発見・識別・評価し、リスクに応じて修正の優先順位を決めて対応するプロセス全体を指します。脆弱性診断やペネトレーションテストが「発見の手法」であるのに対し、脆弱性管理は発見後にどう識別・評価し・優先順位をつけ・組織として対応するかという運用プロセスに焦点を当てます。SC試験ではCVE・CVSSの仕組みに加え、近年はCVSSだけに頼らないSSVCのような文脈依存の優先順位付けの考え方も問われるようになっています。
仕組みと動作原理
脆弱性管理の全体プロセス
CVE(Common Vulnerabilities and Exposures)
CVEは、公開された脆弱性一つひとつに一意の識別番号を付与する共通識別子の仕組みです。MITRE社が運営し、CNA(CVE Numbering Authority)と呼ばれる採番機関(ベンダーやセキュリティ組織)が番号を発行します。
番号形式: CVE-YYYY-NNNNN
例: CVE-2021-44228(Log4Shell)
└─ 発見・登録された年 └─ 通し番号(桁数は可変)
CVEはあくまで「識別子」であり、深刻度の情報は含みません。深刻度の評価はCVSSなど別の枠組みが担います。CVE番号を使うことで、ベンダー間・組織間で同じ脆弱性を正確に参照でき、脆弱性データベース(NVD: National Vulnerability Databaseなど)を横断した情報連携が可能になります。
CVSS(Common Vulnerability Scoring System)
CVSSは脆弱性の深刻度を0.0〜10.0のスコアで表す業界標準の評価手法です(現在はCVSS v3.1・v4.0が主流)。基本評価基準(Base Metrics)は攻撃者から見た「攻撃のしやすさ」と、影響を受ける側の「被害の大きさ」の2軸で構成されます。
攻撃のしやすさに関する評価軸:
| 評価軸 | 内容 | 値の例 |
|---|---|---|
| 攻撃元区分(AV: Attack Vector) | 攻撃者がどこから攻撃できるか | ネットワーク/隣接/ローカル/物理 |
| 攻撃条件の複雑さ(AC: Attack Complexity) | 攻撃を成功させる条件の難易度 | 低/高 |
| 必要な権限レベル(PR: Privileges Required) | 攻撃に必要な事前の権限 | 不要/低/高 |
| ユーザ関与(UI: User Interaction) | 被害者の操作が必要か | 不要/必要 |
影響の大きさに関する評価軸:
| 評価軸 | 内容 |
|---|---|
| 機密性への影響(C: Confidentiality) | 情報漏洩の程度(なし/低/高) |
| 完全性への影響(I: Integrity) | データ改ざんの程度(なし/低/高) |
| 可用性への影響(A: Availability) | サービス停止の程度(なし/低/高) |
深刻度の区分:
| スコア | 深刻度 |
|---|---|
| 9.0〜10.0 | Critical(緊急) |
| 7.0〜8.9 | High(重要) |
| 4.0〜6.9 | Medium(警告) |
| 0.1〜3.9 | Low(注意) |
| 0.0 | None |
CVSSには基本評価基準(Base)に加え、攻撃コードの流通状況や対策状況を反映する現状評価基準(Temporal)、組織の資産の重要性を反映する**環境評価基準(Environmental)**があります。試験や実務では基本値だけで語られがちですが、実際の優先順位付けでは現状・環境評価基準まで含めて判断することが望ましいとされています。
SSVC(Stakeholder-Specific Vulnerability Categorization)
CVSSは「脆弱性そのものの技術的な深刻度」を評価する指標であり、スコアが高くても自組織の環境では実際には影響が小さいケース、逆にスコアが低くても自組織にとって重大なケースがあります。この課題に対応するため、CISA(米国サイバーセキュリティ・インフラセキュリティ庁)等が採用しているのが**SSVC(Stakeholder-Specific Vulnerability Categorization)**です。
SSVCは、CVSSのような単一の数値スコアではなく、意思決定ツリー形式で複数の観点を組み合わせて対応の要否・優先度を分類する、**文脈依存(Stakeholder-Specific)**の優先順位付けフレームワークです。
SSVCが考慮する主な観点:
| 観点 | 内容 |
|---|---|
| Exploitation(悪用状況) | 実際に攻撃コード・悪用事例が存在するか |
| Automatable(自動化可能性) | 攻撃が自動化・大規模展開できるか |
| Technical Impact(技術的影響) | 完全な制御奪取か部分的な影響か |
| Mission & Well-being Impact(組織への影響) | 自組織のミッション・安全性にとっての重大性 |
CVSSとSSVCの違い:
| 観点 | CVSS | SSVC |
|---|---|---|
| 出力形式 | 単一の数値スコア(0.0〜10.0) | 意思決定ツリーによる分類(対応区分) |
| 評価の主体 | 脆弱性そのものの技術的特性 | 組織・利害関係者ごとの文脈を反映 |
| 「悪用実績の有無」の扱い | Temporal/Environmentalで補助的に反映 | 中核的な判断軸として明示的に組み込む |
| 目的 | 汎用的な深刻度の比較 | 「今この組織が何をすべきか」の意思決定支援 |
脆弱性スキャナとパッチマネジメント
脆弱性管理を継続的に回すには、発見(スキャナ)と対応(パッチマネジメント)を組織のプロセスとして接続する必要があります。
| 要素 | 役割 |
|---|---|
| 脆弱性スキャナ(Nessus・OpenVAS等) | 既知の脆弱性を自動的・網羅的に検出しCVE単位で報告 |
| 資産管理台帳(CMDB) | どの脆弱性がどの資産に影響するかを対応付ける基盤 |
| パッチマネジメント | 検出された脆弱性に対しパッチ適用・回避策・受容を計画的に実施するプロセス |
| SLA(対応期限の目安) | 深刻度に応じた対応期限を組織ポリシーとして事前に定義(例:Criticalは7日以内) |
パッチが即座に適用できない場合(可用性への影響・業務都合等)は、WAFルールの追加やネットワーク分離などの**緩和策(Mitigation)**を暫定的に講じ、リスクを許容できる水準まで下げてから計画的にパッチを適用する運用が一般的です。
SC試験での頻出ポイント
- CVEは識別子であり深刻度情報を含まない:深刻度評価はCVSS等の別の枠組みが担う
- CVSS基本評価基準の3要素(C/I/A):機密性・完全性・可用性への影響を評価する観点
- CVSSスコアが高い=即対応ではない:自組織の環境・悪用実績・ビジネス影響を踏まえた優先順位付けが必要
- SSVCの位置づけ:CVSSを補完する、文脈(利害関係者ごとの状況)を反映した意思決定支援フレームワーク
- パッチ適用までの暫定対応:即時パッチが困難な場合の緩和策(WAF・ネットワーク分離等)の重要性
よくある誤問・ひっかけパターン
誤り① 「CVSSスコアが高い脆弱性から機械的に対応順位を決めればよい」→ 不十分。CVSS基本値は汎用的な技術的深刻度にすぎず、実際の悪用状況や自組織への影響を加味した優先順位付け(SSVC等)が推奨されます。
誤り② 「CVE番号があれば、その脆弱性の深刻度も一意に分かる」→ 誤。CVEは脆弱性を一意に識別する番号であり、深刻度の情報は含みません。深刻度はCVSSスコアとして別途評価・公表されます。
誤り③ 「パッチが提供された脆弱性はすぐに全て適用すべきであり、緩和策は不要」→ 状況次第。可用性への影響や業務都合で即時パッチ適用が困難な場合、WAFルール追加やネットワーク分離等の緩和策で暫定的にリスクを下げてから計画的に適用することも実務上重要です。
関連用語
- ペネトレーションテストと脆弱性診断 — 脆弱性の「発見手法」。本記事は発見後の管理・優先順位付けプロセスが対象
- サイバー脅威インテリジェンス(CTI) — 悪用実績等の脅威情報はSSVCの判断材料として活用される
- ISMS(情報セキュリティマネジメントシステム) — 脆弱性管理プロセスを組織のマネジメント体系に組み込む枠組み
重要キーワード
| 用語 | 説明 |
|---|---|
| CVE | 脆弱性に付与される一意の識別番号。深刻度情報は含まない |
| CVSS | 脆弱性の深刻度を0〜10のスコアで表す業界標準の評価手法 |
| SSVC | 悪用状況や組織への影響など文脈を反映した意思決定ツリー型の優先順位付けフレームワーク |
| NVD | 米国が運営するCVE情報を集約した脆弱性データベース |
| パッチマネジメント | 検出された脆弱性へのパッチ適用・緩和策・受容を計画的に運用するプロセス |
| 緩和策(Mitigation) | 即時パッチが困難な場合にリスクを暫定的に下げる代替対策 |