building-patch-tuesday-response-process

# 构建补丁星期二响应流程

## 概述
Microsoft 每月第二个星期二（"补丁星期二（Patch Tuesday）"）发布安全更新，涵盖 Windows、Office、Exchange、SQL Server、Azure 服务和其他产品中的漏洞。2025 年，Microsoft 全年修补了超过 1,129 个漏洞——比 2024 年增加了 11.9%——使结构化的响应流程至关重要。主要风险类型包括权限提升（49%）、远程代码执行（34%）和信息披露（7%）。本技能涵盖从初始公告审查到测试、部署和验证的可重复补丁星期二响应工作流的构建。

## 前置条件
- 访问 Microsoft 安全响应中心（MSRC）更新指南
- 漏洞管理平台（Qualys VMDR、Rapid7、Tenable）
- 补丁部署基础设施（WSUS、SCCM/MECM、Intune 或第三方）
- 镜像生产配置的测试环境
- 变更管理流程（基于 ITIL 或等效方案）
- 跨团队协调的通信渠道

## 核心概念

### 补丁星期二时间线

| 天数 | 活动 | 负责人 |
|-----|----------|-------|
| T+0（星期二上午 10 点 PT） | Microsoft 发布补丁和公告 | Microsoft |
| T+0（星期二下午） | 安全团队审查公告并分类 | 安全运营 |
| T+1（星期三） | Qualys/供应商扫描特征更新 | 漏洞管理平台 |
| T+1 至 T+2 | 为零日漏洞部署紧急补丁 | IT 运营 |
| T+2 至 T+5 | 在暂存环境中测试补丁 | QA/IT 运营 |
| T+5 至 T+7 | 部署到试点组（5-10% 的设备） | IT 运营 |
| T+7 至 T+14 | 部署到生产环 Ring 1（服务器） | IT 运营 |
| T+14 至 T+21 | 部署到生产环 Ring 2（工作站） | IT 运营 |
| T+21 至 T+30 | 验证扫描和合规报告 | 安全运营 |

### 补丁分类框架

| 类别 | 标准 | 响应 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 操作系统 | Windows 10、11、Server 2016-2025 | 严重 |
| Exchange Server | Exchange 2016、2019、Online | 严重 |
| SQL Server | SQL 2016-2022 | 高 |
| Office 套件 | Microsoft 365、Office 2019-2024 | 高 |
| .NET 框架 | .NET 4.x、.NET 6-9 | 中等 |
| Azure 服务 | Azure AD、Entra ID、Azure Stack | 高 |
| Edge/浏览器 | Edge Chromium、IE 模式 | 中等 |
| 开发工具 | Visual Studio、VS Code | 低 |

## 实施步骤

### 步骤 1：补丁星期二前准备（前一个星期一）
```
准备检查表：
  [ ] 确认 WSUS/SCCM 同步计划处于活动状态
  [ ] 验证测试环境可用且为最新状态
  [ ] 审查上个月的未完成补丁
  [ ] 确认监控仪表盘正常运行
  [ ] 预先准备通信模板
  [ ] 确保回滚程序已有文档记录
  [ ] 验证关键服务器的备份作业已成功运行
```

### 步骤 2：当日分类（补丁星期二）

```
分类流程：
  1. 监控 MSRC 更新指南（https://msrc.microsoft.com/update-guide）
  2. 查看 Microsoft 安全博客中的公告摘要
  3. 与同日的 CISA KEV 新增内容交叉参考
  4. 检查供应商公告（Qualys、Rapid7、CrowdStrike 分析）
  5. 识别零日和主动利用的漏洞
  6. 按严重性和适用性对每个 CVE 进行分类
  7. 确定每个补丁的部署环和时间线
  8. 为零日补丁提交紧急变更请求
  9. 将分类结果通报给 IT 运营和管理层
```

### 步骤 3：扫描和差距分析

```python
# 补丁星期二后扫描工作流
def run_patch_tuesday_scan(scanner_api, target_groups):
    """补丁星期二更新后触发漏洞扫描。"""
    for group in target_groups:
        print(f"[*] 正在扫描 {group['name']}...")
        scan_id = scanner_api.launch_scan(
            target=group["targets"],
            template="patch-tuesday-focused",
            credentials=group["creds"]
        )
        print(f"    扫描已启动：{scan_id}")

    # 等待扫描完成，然后生成报告
    results = scanner_api.get_scan_results(scan_id)
    missing_patches = [r for r in results if r["status"] == "missing"]

    # 按补丁星期二发布分类
    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 - 紧急（0-48 小时）：
    范围：     仅零日和主动利用的 CVE
    方式：     手动或定向推送（SCCM 加速）
    目标：     面向互联网的服务器、关键基础设施
    审批：     紧急变更，CISO 口头批准
    回滚：     如果出现服务降级，立即回滚

Ring 1 - 试点（第 2-7 天）：
    范围：     所有严重和高级别补丁
    方式：     WSUS/SCCM 自动部署
    目标：     IT 部门机器，测试组（5-10%）
    审批：     标准变更，CAB 通知
    监控：    48 小时浸泡期，检查蓝屏、应用崩溃

Ring 2 - 生产服务器（第 7-14 天）：
    范围：     所有安全补丁
    方式：     SCCM 维护窗口（非工作时间）
    目标：     按层级划分的生产服务器
    审批：     标准变更，CAB 批准
    监控：     应用健康检查，性能基线

Ring 3 - 工作站（第 14-21 天）：
    范围：     所有安全补丁 + 质量更新
    方式：     Windows Update for Business / Intune
    目标：     所有托管工作站
    审批：     预批准标准变更
    监控：     监控服务台工单中的问题

Ring 4 - 落后（第 21-30 天）：
    范围：     捕获剩余未打补丁的系统
    方式：     强制部署并重启
    目标：     错过之前环的系统
    审批：     合规驱动的强制执行
```

### 步骤 5：验证和报告

```
部署后验证：
  1. 使用更新的漏洞特征重新扫描环境
  2. 比较补丁前和补丁后的扫描结果
  3. 按环和部门计算补丁合规率
  4. 识别失败的补丁并调查根本原因
  5. 生成供管理层审查的合规报告
  6. 用剩余未打补丁的漏洞更新风险登记册
  7. 记录例外情况和补偿性控制
```

## 最佳实践
1. 订阅 MSRC 通知和供应商分析博客以获取早期情报
2. 为补丁星期二维护专用战情室（War Room）或 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