building-patch-tuesday-response-process

Patch Tuesday 対応プロセスの構築

概要

Microsoft は毎月第 2 火曜日（「Patch Tuesday」）にセキュリティ更新プログラムをリリースし、Windows、Office、Exchange、SQL Server、Azure サービスなど、さまざまな製品の脆弱性に対処します。2025 年には、Microsoft は年間を通じて 1,129 件を超える脆弱性にパッチを適用しました。これは 2024 年から 11.9% の増加であり、体系的な対応プロセスが重要になっています。主なリスクの種類は、権限昇格（49%）、リモートコード実行（34%）、情報漏えい（7%）です。このスキルでは、最初のアドバイザリ確認からテスト、展開、検証まで、再現可能な Patch Tuesday 対応ワークフローの構築について説明します。

使用するタイミング

• 環境で Patch Tuesday 対応プロセスの機能を展開または構成するとき
• コンプライアンス要件に沿ったセキュリティ制御を確立するとき
• この領域のセキュリティアーキテクチャを構築または改善するとき
• この実装を必要とするセキュリティ評価を実施するとき

前提条件

• Microsoft Security Response Center（MSRC）の更新ガイドへのアクセス
• 脆弱性管理プラットフォーム（Qualys VMDR、Rapid7、Tenable）
• パッチ展開インフラストラクチャ（WSUS、SCCM/MECM、Intune、またはサードパーティ製品）
• 本番環境の構成を反映したテスト環境
• 変更管理プロセス（ITIL ベース、または同等のもの）
• チーム間の調整に使用するコミュニケーションチャネル

主な概念

Patch Tuesday のタイムライン

日	アクティビティ	担当
T+0（火曜日 午前 10 時 PT）	Microsoft がパッチとアドバイザリをリリース	Microsoft
T+0（火曜日 午後）	セキュリティチームがアドバイザリを確認し、トリアージを実施	Security Ops
T+1（水曜日）	Qualys／ベンダーのスキャンシグネチャが更新	VM Platform
T+1～T+2	ゼロデイ脆弱性に対する緊急パッチを展開	IT Operations
T+2～T+5	ステージング環境でパッチをテスト	QA/IT Ops
T+5～T+7	パイロットグループ（全体の 5～10%）に展開	IT Operations
T+7～T+14	本番リング 1（サーバー）に展開	IT Operations
T+14～T+21	本番リング 2（ワークステーション）に展開	IT Operations
T+21～T+30	検証スキャンとコンプライアンスレポート作成	Security Ops

パッチ分類フレームワーク

カテゴリ	基準	対応 SLA
ゼロデイ／悪用確認済み	実際の悪用を確認済み、CISA KEV に掲載	24～48 時間
重大な RCE	CVSS >= 9.0、リモートコード実行、認証不要	3～5 日
エクスプロイトが存在する重大な脆弱性	公開されたエクスプロイトコード、または EPSS > 0.7	7 日
高深刻度	CVSS 7.0～8.9、権限昇格	14 日
中深刻度	CVSS 4.0～6.9	30 日
低／情報提供	CVSS < 4.0、多層防御	次回のメンテナンス期間

監視対象の Microsoft 製品カテゴリ

カテゴリ	製品	リスクレベル
Windows OS	Windows 10, 11, Server 2016-2025	重大
Exchange Server	Exchange 2016, 2019, Online	重大
SQL Server	SQL 2016-2022	高
Office スイート	Microsoft 365, Office 2019-2024	高
.NET Framework	.NET 4.x, .NET 6-9	中
Azure サービス	Azure AD, Entra ID, Azure Stack	高
Edge／ブラウザー	Edge Chromium, IE mode	中
開発ツール	Visual Studio, VS Code	低

ワークフロー

ステップ 1：Patch Tuesday 前の準備（前日の月曜日）

Preparation Checklist:
  [ ] Confirm WSUS/SCCM sync schedules are active
  [ ] Verify test environment is available and current
  [ ] Review outstanding patches from previous month
  [ ] Confirm monitoring dashboards are operational
  [ ] Pre-stage communication templates
  [ ] Ensure rollback procedures are documented
  [ ] Verify backup jobs ran successfully on critical servers

ステップ 2：当日のトリアージ（Patch Tuesday）

Triage Process:
  1. Monitor MSRC Update Guide (https://msrc.microsoft.com/update-guide)
  2. Review Microsoft Security Blog for advisory summaries
  3. Cross-reference with CISA KEV additions (same day)
  4. Check vendor advisories (Qualys, Rapid7, CrowdStrike analysis)
  5. Identify zero-day and actively exploited vulnerabilities
  6. Classify each CVE by severity and applicability
  7. Determine deployment rings and timeline for each patch
  8. Submit emergency change request for zero-day patches
  9. Communicate triage results to IT Operations and management

ステップ 3：スキャンとギャップ分析

# Post-Patch-Tuesday scan workflow
def run_patch_tuesday_scan(scanner_api, target_groups):
    """Trigger vulnerability scans after Patch Tuesday updates."""
    for group in target_groups:
        print(f"[*] Scanning {group['name']}...")
        scan_id = scanner_api.launch_scan(
            target=group["targets"],
            template="patch-tuesday-focused",
            credentials=group["creds"]
        )
        print(f"    Scan launched: {scan_id}")

    # Wait for scan completion, then generate report
    results = scanner_api.get_scan_results(scan_id)
    missing_patches = [r for r in results if r["status"] == "missing"]

    # Categorize by Patch Tuesday release
    current_month = [p for p in missing_patches
                     if p["vendor_advisory_date"] >= patch_tuesday_date]

    return {
        "total_missing": len(missing_patches),
        "current_month": len(current_month),
        "zero_day": [p for p in current_month if p.get("actively_exploited")],
        "critical": [p for p in current_month if p["cvss"] >= 9.0],
    }

ステップ 4：リングベースの展開戦略

Ring 0 - Emergency (0-48 hours):
    Scope:     Zero-day and actively exploited CVEs only
    Method:    Manual or targeted push (SCCM expedite)
    Targets:   Internet-facing servers, critical infrastructure
    Approval:  Emergency change, verbal CISO approval
    Rollback:  Immediate rollback if service degradation

Ring 1 - Pilot (Day 2-7):
    Scope:     All critical and high patches
    Method:    WSUS/SCCM automatic deployment
    Targets:   IT department machines, test group (5-10%)
    Approval:  Standard change with CAB notification
    Monitoring: 48-hour soak period, check for BSOD, app crashes

Ring 2 - Production Servers (Day 7-14):
    Scope:     All security patches
    Method:    SCCM maintenance windows (off-hours)
    Targets:   Production servers by tier
    Approval:  Standard change with CAB approval
    Monitoring: Application health checks, performance baseline

Ring 3 - Workstations (Day 14-21):
    Scope:     All security patches + quality updates
    Method:    Windows Update for Business / Intune
    Targets:   All managed workstations
    Approval:  Pre-approved standard change
    Monitoring: Help desk ticket monitoring for issues

Ring 4 - Stragglers (Day 21-30):
    Scope:     Catch remaining unpatched systems
    Method:    Forced deployment with restart
    Targets:   Systems that missed prior rings
    Approval:  Compliance-driven enforcement

ステップ 5：検証とレポート作成

Post-Deployment Validation:
  1. Re-scan environment with updated vulnerability signatures
  2. Compare pre-patch and post-patch scan results
  3. Calculate patch compliance rate per ring and department
  4. Identify failed patches and investigate root causes
  5. Generate compliance report for management review
  6. Update risk register with residual unpatched vulnerabilities
  7. Document exceptions and compensating controls

ベストプラクティス

1. 早期情報を得るため、MSRC の通知とベンダーの分析ブログを購読します
2. 専用のパッチチューズデー対応ルーム、または Slack／Teams チャンネルを用意します
3. ゼロデイ脆弱性には、通常のリングスケジュール外で必ずパッチを適用します
4. 広範囲に展開する前に、重要な業務アプリケーションでパッチをテストします
5. 傾向分析のため、パッチ適用率の指標を毎月追跡します
6. 展開リングごとにロールバック手順を用意します
7. 互換性テストのため、アプリケーションの所有者と連携します
8. すべての例外について、代替策となる管理策とレビュー日を記録します

よくある落とし穴

• リングベースのテストを行わず、すべてのパッチを同時に展開する
• 修正を検証するためのパッチ適用後のスキャンを行わない
• リスクに基づく優先順位付けをせず、すべてのパッチを同等に扱う
• 累積更新プログラムの依存関係を無視し、パッチの適用に失敗する
• メンテナンス時間にサーバーの再起動要件を考慮しない
• パッチの適用状況を業務関係者に伝えない

関連スキル

• implementing-rapid7-insightvm-for-scanning
• performing-cve-prioritization-with-kev-catalog
• implementing-vulnerability-remediation-sla
• implementing-patch-management-workflow