安全事件分类分级的本质是给每一次告警和异常赋予统一的语义标签和优先级，让安全团队知道先处理什么、由谁处理、需要上报到哪一级。很多企业的SIEM每天产生海量告警，但真正进入应急流程的只有少数，如果分类分级口径不一致，就会出现高优先级事件被漏掉、低优先级事件却频繁拉会的情况。要想改变这种状态，不能只靠工程师个人经验，而应把分类分级变成一套可执行、可度量的规则体系。
一、安全事件分类：从事件类型到攻击阶段
分类首先要回答“这是什么类型的事件”。参考信息安全事件分类分级指南中的常见划分，安全事件通常可以分为有害程序事件、网络攻击事件、信息破坏事件、信息内容安全事件、设备设施故障、灾害性事件和其他事件。每大类下还可以继续细分，例如网络攻击事件可以拆成SQL注入、跨站脚本、暴力破解、拒绝服务、钓鱼攻击等。这样分类的好处是后续可以针对不同类别预设响应手册。
不过仅按攻击类型分类还不够，实际调查中同样一条SQL注入告警，可能只是扫描器触发的探测行为，也可能是已经拖库后的痕迹。因此建议引入“攻击阶段”这一第二维度，将事件归入侦察、武器化、投递、利用、安装、命令控制、横向移动、数据外传等阶段。结合类型和阶段，分类标签可以设计成 web_attack:sql_injection:exploitation 这样的层级结构，而不是只写一个模糊的“注入攻击”。
另外，分类还要考虑影响对象。一台测试服务器的暴力破解与核心数据库服务器的暴力破解，即使攻击手法相同，业务影响完全不可同日而语。影响对象可以按资产等级、所属业务线、网络区域、数据敏感度等属性进行标识。将这些属性作为分类标签的一部分，后续分级计算时可以直接复用。
二、安全事件分级：可量化的评分模型
分级的目标是把“严重”拆成可以计算的分数。常见做法是选择几个核心评分因子，例如影响类型、数据敏感度、影响范围、攻击阶段、恢复难度，然后为每个因子设置权重和分值，最后根据总分映射到P1至P4等级。以影响类型为例，数据泄露通常比短暂页面篡改更严重，拒绝服务直接影响可用性，权重应更高。数据敏感度则可以分成公开、内部、敏感、核心四档，分别给1、2、4、6分。
下面是一段简化的评分函数，用来演示如何把分散的字段变成统一等级。实际系统可以接入CMDB、数据分类系统和资产漏洞库，自动填充这些参数。
def classify_severity(impact, data_level, scope, stage):
impact_score = {
"信息泄露": 3,
"篡改": 4,
"拒绝服务": 5,
"数据破坏": 6,
}
data_score = {
"公开": 1,
"内部": 2,
"敏感": 4,
"核心": 6,
}
scope_score = {
"单台主机": 1,
"单业务": 2,
"多业务": 4,
"全公司": 6,
}
stage_score = {
"侦察": 1,
"入侵": 3,
"横向移动": 5,
"数据外传": 6,
}
score = (
impact_score.get(impact, 1)
+ data_score.get(data_level, 1)
+ scope_score.get(scope, 1)
+ stage_score.get(stage, 1)
)
if score >= 18:
return "P1-特别重大"
if score >= 13:
return "P2-重大"
if score >= 8:
return "P3-较大"
return "P4-一般"
这段代码的核心不是追求数学上的精确，而是把原本依赖人工判断的维度固定下来。比如一次“数据破坏+核心数据+多业务+数据外传”的组合会得到24分，必然进入P1等级；而一次“信息泄露+公开数据+单台主机+侦察”的组合只有6分，可以按P4处理。阈值可以根据企业实际承受能力调整，但必须由安全委员会评审后发布，不能随意修改。
另一种更灵活的方式是用YAML维护评分规则，把分值、阈值和等级解耦，方便运营人员调整而无需改动代码。下面是一个简化的配置片段。
scoring:
factors:
impact:
信息泄露: 3
篡改: 4
拒绝服务: 5
数据破坏: 6
data_level:
公开: 1
内部: 2
敏感: 4
核心: 6
scope:
单台主机: 1
单业务: 2
多业务: 4
全公司: 6
stage:
侦察: 1
入侵: 3
横向移动: 5
数据外传: 6
thresholds:
P1: 18
P2: 13
P3: 8
通过配置化设计，分类分级规则可以进入版本管理，每次调整都有审计记录。对于跨地域、多业务线的企业，还可以在全局模型上增加业务线系数，比如核心支付业务乘以1.2，边缘测试系统乘以0.8，从而在统一框架下保留差异化。
三、自动化落地：规则引擎与响应流程联动
有了分类分级模型后，下一步是把它嵌入到告警处理和应急响应流程中。SIEM、SOAR、XDR等平台通常支持通过剧本或规则引擎对告警打标签、计算优先级。常见做法是先将日志中的事件类型、源地址、目标资产、告警名称等字段标准化，然后调用分级服务获取评分，最后根据等级路由到不同队列。例如P1事件自动创建战时群组并通知值班负责人，P3和P4事件则进入日常工单池。
如果团队使用Elasticsearch或Splunk作为安全数据平台，可以先写一个查询把标准化后的事件提取出来，再由后端脚本完成分级。下面是一个按攻击阶段聚合未处理事件的Elasticsearch查询示例。
{
"query": {
"bool": {
"must": [
{
"term": {
"event.category": "intrusion_detection"
}
},
{
"range": {
"@timestamp": {
"gte": "now-1h"
}
}
}
]
}
},
"aggs": {
"by_stage": {
"terms": {
"field": "event.outcome",
"size": 10
}
}
},
"size": 0
}
这个查询本身只是筛选近一小时内的入侵检测事件，但它的作用在于为后续分级提供一致的数据口径。自动化落地过程中最容易出问题的不是算法，而是字段缺失和命名不统一。比如有的日志把数据敏感度写成 dataLevel，有的写成 data_sensitivity，规则引擎就无法稳定计算。因此需要先建立日志字典，把不同来源的字段映射到统一模型上。
自动化分级还要考虑纠偏机制。模型上线后可能因为某些字段误填导致大量告警被错误升级或降级，例如资产标签未及时更新，把已下线系统标记为“核心”。可以设置保护性规则：当单台主机一小时内的P1事件超过阈值时，不继续自动通知，而是合并为一条聚合事件并提示值班人员核对标签。人工评审结果可以回流为模型的训练样本或规则修正依据。
四、常见误区与改进建议
第一个常见误区是把分类分级的粒度做得过细。一些团队把事件类型拆到几十个，每种类型都设置不同响应流程，结果值班人员根本记不住，误操作反而增加。分类不是越细越好，而应看是否能为后续动作提供差异化的决策依据。如果两种类型对应的响应动作完全一致，就可以合并成一个标签，避免无效分类。
第二个误区是只按技术指标定级，不考虑业务影响。比如同样是一次低权限命令执行，发生在核心支付系统与内部知识库系统上的影响差别巨大。分级模型必须引入资产重要性、数据敏感度和用户规模等业务维度。安全团队需要与业务方一起确认关键资产清单，并定期更新，否则自动化分级很快就会失真。
第三个误区是分级结果一成不变。安全事件是动态演化的，一个初始被判定为P3的事件，可能随着调查发现横向移动迹象而升级为P1。分级体系应支持动态调整，并记录每次变更的时间和原因。可以引入“升级/降级”规则，例如一旦检测到新的事件阶段标签从“入侵”变为“横向移动”，系统自动提升一级并触发复核。
改进方向上，建议将分类分级与威胁建模、安全度量结合起来。分类数据可以统计出企业最常遭遇的攻击类型，从而指导防护资源投入；分级数据可以衡量MTTD和MTTR是否存在风险集中区域。只有把分类分级从“告警贴标签”提升为安全运营的基础数据能力，才能真正减少响应差异、提高应急效率。