implementing-vulnerability-remediation-sla

脆弱性修復 SLA の実装

概要

脆弱性修復 SLA では、特定された脆弱性の深刻度、資産の重要度、エクスプロイトの入手可能性に基づいて、パッチ適用または緩和策を実施する期限を定めます。効果的な SLA プログラムは、責任を明確にし、一貫した修復スケジュールを確保するとともに、脆弱性管理の成熟度を測る指標を提供します。

使用する場面

• 環境で脆弱性修復 SLA 機能を導入または設定する場合
• コンプライアンス要件に沿ったセキュリティ制御を確立する場合
• この分野のセキュリティアーキテクチャを構築または改善する場合
• この実装が必要となるセキュリティ評価を実施する場合

前提条件

• 定期的に検出結果を出力する脆弱性スキャンプログラム
• 重要度の分類を含む資産インベントリ
• 修復状況を追跡するチケット管理システム（Jira、ServiceNow など）
• SLA の適用に対する経営陣の支援
• IT 運用、開発、セキュリティ部門間の合意

基本概念

SLA フレームワークの構成要素

1. 深刻度の分類：CVSS 基本スコア＋脅威の状況（EPSS、KEV）
2. 資産の階層化：ビジネス上の重要度と公開レベル
3. 修復期限：カテゴリごとの修復期限の上限日数
4. 例外プロセス：SLA 延長に対する承認を文書化
5. エスカレーション手順：SLA 違反時の対応
6. 指標とレポート：コンプライアンス追跡用 KPI

推奨 SLA マトリクス

深刻度	Tier 1（クリティカル）	Tier 2（重要）	Tier 3（標準）
クリティカル（CVSS 9.0-10.0）	24-48 時間	72 時間	7 日
高（CVSS 7.0-8.9）	7 日	14 日	30 日
中（CVSS 4.0-6.9）	30 日	45 日	60 日
低（CVSS 0.1-3.9）	90 日	90 日	90 日
CISA KEV 掲載	24 時間	48 時間	7 日

SLA 短縮要因（SLA を 50% 短縮）

• エクスプロイトコードが一般公開されている
• 実環境での悪用が確認されている（CISA KEV）
• インターネットに公開された資産が影響を受ける
• EPSS スコア > 0.5（悪用確率 50%）
• 類似の脆弱性を介した過去の侵害がある

ワークフロー

ステップ 1：資産の階層を定義する

Tier 1 (Critical Assets):
- Customer-facing production systems
- Payment processing infrastructure
- Domain controllers and identity systems
- Core network infrastructure (firewalls, routers)
- Databases containing PII/PHI/PCI data

Tier 2 (Important Assets):
- Internal production applications
- Email and collaboration systems
- Development/staging environments with production data
- Backup and recovery infrastructure
- VPN and remote access gateways

Tier 3 (Standard Assets):
- End-user workstations
- Development/test environments
- Print servers and peripheral management
- Non-critical internal tools

ステップ 2：SLA ポリシー文書を作成する

含める主な項目：

• 目的と適用範囲
• 役割と責任（RACI マトリクス）
• 深刻度の定義と算出方法
• 深刻度と資産階層ごとの修復期限
• 例外申請プロセスと承認権限
• SLA 違反時のエスカレーション手順
• 指標、レポートの頻度、ガバナンス
• ポリシーの見直しと更新スケジュール

ステップ 3：チケット管理システムと連携する

# ServiceNow / Jira integration for automatic ticket creation
# See process.py for full implementation

# Key fields for remediation tickets:
# - Vulnerability ID (CVE/Plugin ID)
# - Affected host(s)
# - Severity (CVSS + contextual factors)
# - Asset tier
# - SLA deadline (calculated from discovery date)
# - Assignment group
# - Remediation instructions
# - Verification criteria

ステップ 4：エスカレーション経路を設定する

SLA Status          Action                          Notify
───────────────────────────────────────────────────────────
75% elapsed         Warning email                   Asset owner
100% elapsed        SLA breach notification          Manager + CISO
100% + 7 days       Executive escalation             VP/CTO
100% + 30 days      Risk acceptance required          CISO approval
100% + 90 days      Compensating controls mandatory   Board report

ステップ 5：例外プロセスを確立する

例外が認められる理由：

• 大規模なダウンタイムなしにシステムへパッチを適用できない（計画済みのメンテナンス期間に実施）
• ベンダーからパッチが提供されていない（代替の制御を適用）
• パッチによって重要な機能が損なわれる（証拠としてテスト結果が必要）
• サポート終了システムで、廃止が予定されている（リスク受容を文書化）

例外の要件：

• ビジネスへの影響を記載した書面による正当化
• 代替の制御を文書化し、実装する
• 資産所有者とセキュリティ責任者の両方による承認
• 例外の最大期間：90 日（再承認により更新可能）
• 脆弱性管理プラットフォームで追跡

主要業績評価指標（KPI）

主要な指標

KPI	定義	目標
SLA 遵守率	SLA 期間内に修復された脆弱性の割合	>90%
平均修復時間（MTTR）	発見から修正までの平均日数	クリティカル：<3 日、高：<10 日
脆弱性バックログ	SLA を超過している未解決の脆弱性	全体の <5%
例外率	有効な例外が適用されている検出結果の割合	<10%
再発率	修復後に再発した脆弱性の割合	<5%

傾向指標

• 前月比の SLA 遵守率の推移
• 重大度別の MTTR の推移
• 資産ごとの脆弱性密度（脆弱性数/ホスト）
• パッチ適用カバレッジ率（スキャン済みかつ準拠している資産の割合）
• 最初の対応までの時間（検出事項の確認応答まで）

ベストプラクティス

1. 達成可能な SLA から始め、成熟度の向上に合わせて徐々に厳格化する
2. 自動化されたチケット管理を使用し、手動による SLA 追跡を不要にする
3. 修復チームには、CVE 番号だけでなく明確な修正手順を提供する
4. 責任の所在を明確にするため、チーム/部門単位で SLA 遵守状況を追跡する
5. SLA の指標を毎月経営陣に報告する
6. 補償的統制を有効な暫定的修復策として含める
7. SLA を規制要件（PCI DSS、HIPAA、SOX）と整合させる
8. 脅威の状況の変化に基づき、SLA を毎年見直して調整する

よくある落とし穴

• チームが達成できない非現実的な SLA を設定してしまう（SLA 疲れを招く）
• SLA 違反に対する経営層による強制力がない
• 階層化せず、すべての資産を同等に扱ってしまう
• SLA の算出において脆弱性のコンテキスト（EPSS、KEV）を考慮しない
• 例外管理プロセスが欠けている（追跡されないリスクにつながる）
• 違反の根本原因を分析せず、遵守率のみを測定する

関連スキル

• prioritizing-vulnerabilities-with-cvss-scoring
• implementing-patch-management-workflow
• implementing-vulnerability-metrics-and-reporting
• implementing-exception-management-process