4. 事件分类与优先级：基于CVSS的漏洞评分、业务影响评估、紧急程度划分
安全事件来了，第一件事是什么？不是修，是分类。
我见过太多团队，一上来就全员扑上去修漏洞，结果修了半天发现是个低危告警，真正要命的业务系统反而没人管。说白了，没有分类和优先级，安全响应就是一场混乱。
这一节，我们聊聊怎么给事件“定级”。核心就三件事：CVSS评分、业务影响评估、紧急程度划分。这三者结合，才能排出真正的优先级。
4.1 CVSS评分：技术维度的“硬指标”
CVSS，全称Common Vulnerability Scoring System，通用漏洞评分系统。它是目前业界最通用的漏洞严重性评估标准。
我个人习惯，拿到一个漏洞报告，先看CVSS分。这玩意儿虽然不完美，但至少是个客观起点。
4.1.1 评分维度
CVSS v3.1主要分三组指标：
- 基础指标（Base）：漏洞本身的固有属性，比如攻击途径、攻击复杂度、权限要求、用户交互、影响范围、机密性/完整性/可用性影响。
- 时间指标（Temporal）：随时间变化的因素，比如漏洞利用代码成熟度、补丁修复状态、报告置信度。
- 环境指标（Environmental）：针对特定环境的定制化评分，比如受影响资产的重要性、安全控制措施的强度。
最终得分是0到10分。分级标准如下：
| 评分范围 | 严重等级 | 颜色标识 |
|---|---|---|
| 9.0 - 10.0 | 严重（Critical） | 红色 |
| 7.0 - 8.9 | 高危（High） | 橙色 |
| 4.0 - 6.9 | 中危（Medium） | 黄色 |
| 0.1 - 3.9 | 低危（Low） | 蓝色 |
| 0.0 | 无风险（None） | 灰色 |
4.1.2 计算示例
举个例子，一个典型的远程代码执行漏洞：
- 攻击途径：网络（AV:N）
- 攻击复杂度：低（AC:L）
- 权限要求：无（PR:N）
- 用户交互：无（UI:N）
- 影响范围：已变更（S:C）
- 机密性影响：高（C:H）
- 完整性影响：高（I:H）
- 可用性影响：高（A:H）
这个组合算下来，基础分通常是9.8或10.0。嗯，妥妥的严重级别。
你可以用NVD官方计算器算一下，或者直接用命令行工具：
# 使用cvsscalc工具计算
cvsscalc -v "AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H"
# 输出：9.8 (Critical)4.2 业务影响评估：技术分之外的“人情分”
CVSS分再高，如果漏洞所在的系统是个测试服务器，那优先级也得降。反过来，一个CVSS只有5分的漏洞，如果它影响的是核心交易系统，那也得当回事。
这就是业务影响评估的意义。
核心原则： 技术严重性 × 业务重要性 = 最终优先级
4.2.1 业务影响评估维度
我一般从这几个角度评估：
- 资产价值：这个系统是核心业务系统、支撑系统还是边缘系统？
- 数据敏感度：涉及的数据是客户PII、财务数据、还是公开信息？
- 合规要求：是否涉及等保、GDPR、PCI-DSS等合规要求？
- 业务连续性：系统宕机对业务的影响有多大？
- 用户影响范围：影响的是内部员工、外部客户还是合作伙伴？
举个例子，我曾经遇到一个情况：一个CVSS 7.5的漏洞出现在内部OA系统上，另一个CVSS 6.0的漏洞出现在核心支付系统上。按CVSS分，前者优先级更高。但结合业务影响，支付系统一旦出问题，直接影响公司营收和客户信任。所以我建议把支付系统的漏洞优先级提到最高。
4.3 紧急程度划分：从P0到P4的五级体系
结合CVSS评分和业务影响，我们可以把事件紧急程度划分为五个等级。这是我个人比较推荐的分级方式：
| 等级 | 名称 | 定义 | 响应时间 | 示例 |
|---|---|---|---|---|
| P0 | 紧急 | 核心业务系统被攻破，数据泄露，或关键服务完全不可用 | 立即响应，15分钟内介入 | RCE漏洞被利用，核心数据库被勒索 |
| P1 | 高 | 重要系统存在高危漏洞，或部分业务功能受损 | 1小时内响应 | CVSS 9.0+漏洞影响核心系统 |
| P2 | 中 | 非核心系统存在高危漏洞，或核心系统存在中危漏洞 | 4小时内响应 | 内部OA系统存在SQL注入 |
| P3 | 低 | 边缘系统存在中低危漏洞，或需要计划性修复 | 24小时内响应 | 测试服务器存在弱口令 |
| P4 | 信息 | 告警信息，无需立即处理，但需记录跟踪 | 下一个迭代周期 | 扫描发现的低危配置项 |
4.3.1 如何快速定级？
我总结了一个简单的决策矩阵，你可以直接拿来用：
| CVSS评分 | 核心业务系统 | 支撑业务系统 | 边缘/测试系统 |
|---|---|---|---|
| 9.0 - 10.0 | P0 | P1 | P2 |
| 7.0 - 8.9 | P1 | P2 | P3 |
| 4.0 - 6.9 | P2 | P3 | P3 |
| 0.1 - 3.9 | P3 | P4 | P4 |
你想想看，这个矩阵的好处是什么？它把技术维度和业务维度结合起来了。一个CVSS 10.0的漏洞，如果出现在测试服务器上，最多也就是P2，不用半夜爬起来修。
4.4 实战中的动态调整
定级不是一成不变的。事件在发展，优先级也要跟着变。
我记得有一次，一个P2事件（内部系统SQL注入）在调查过程中发现，攻击者已经通过这个漏洞拿到了域管理员权限。好家伙，P2瞬间变成P0。
所以，我建议在事件响应过程中，每隔一段时间重新评估一次优先级。特别是出现以下情况时：
- 发现新的攻击路径
- 影响范围扩大
- 出现公开的利用代码
- 合规监管机构介入
4.5 小结
事件分类与优先级，说白了就是回答三个问题：
- 这个漏洞有多严重？ —— 看CVSS分
- 这个系统有多重要？ —— 做业务影响评估
- 现在该不该动？ —— 定紧急程度
这三步走完，你就能排出真正合理的响应顺序。不会因为一个高分漏洞而忽略核心业务，也不会因为一个低分漏洞而掉以轻心。
嗯，下一节我们聊聊事件响应流程的具体执行。到时候我会分享一个我亲手搭建的响应SOP模板，希望能帮到你。