事件分级是什么
安全事件分级是把一次告警或入侵按影响范围、数据敏感度与业务中断时长归类，用来决定三件事：谁被叫起来、多久内必须动作、是否需要停机与上报。没有写死的判定表，现场定级全靠个人感觉，事后必然扯皮：要么把批量扫描当成重大事件把资源耗尽，要么把已落地的后门当成误报放过。分级的作用不是追求绝对精确，而是让响应规模与事件规模匹配，并且留下可追溯的判定依据。
基本信息
| 常用框架 | P1 到 P4 四级，可按组织规模裁剪为三级 |
|---|---|
| 定级要素 | 影响范围、数据敏感度、业务中断时长、是否对外可见、是否涉及监管上报 |
| 决策人 | 应急总指挥或 CSIRT 负责人，技术组长提供事实判断不单独定级 |
| 启动时限 | 参考值：P1 约 15 分钟内启动、P2 约 1 小时内、P3 当日处置 |
| 升级与降级 | 随调查推进可调整级别，调整必须记录时间与理由 |
| 留档要求 | 级别、依据、决策人、时间点四项必须落表 |
典型使用场景
- 值班收到告警后判断是否需要拉起应急小组，避免小事大做或大事化小
- 多家分支或业务线同时出现类似告警时，判断是否属于同一事件的扩散
- 决定是否需要停业务、断网或回滚发布，这类动作需要级别作为授权依据
- 涉及个人信息或重要数据时，判断是否需要按规定向主管部门报告
- 复盘时用当时的定级依据评估响应动作是否与级别匹配
分级参考表
| 级别 | 典型场景 | 响应要求 |
|---|---|---|
| P1 | 核心业务被加密或中断、大规模数据外泄、勒索信已在多台出现 | 立即最高优先级，同步管理层与外联接口人 |
| P2 | 单台主机确认被控、Webshell 落地、账号确认被盗用 | 1 小时内响应，按需隔离并扩大排查范围 |
| P3 | 扫描探测、暴力破解未得手、单台主机异常外联未确认 | 当日处置并留档，观察是否升级 |
| P4 | 误报、策略违规、配置偏差类问题 | 工单跟踪，不做现场处置 |
定级与记录模板
定级与记录模板
date -u '+%F %T UTC' # 统一 UTC 时间，避免时区混乱
hostname; hostname -I; uname -a
cat /etc/os-release 2>/dev/null | head -n 3
# 台账字段：时间 / 资产 / 现象 / 影响面 / 级别 / 依据 / 决策人 / 处置人
printf '%s\t%s\t%s\t%s\n' "$(date -u +%FT%TZ)" "$(hostname)" "P2" "单台主机确认被控" >> /evidence/ir_ledger.tsv
wc -l /evidence/ir_ledger.tsv # 台账行数就是处置动作数，便于复盘定级要素与判断口径
| 要素 | 判断口径 | 影响级别的典型情况 |
|---|---|---|
| 影响范围 | 涉及主机数、业务系统数、是否有横向移动迹象 | 从单台扩到多台即应上调级别 |
| 数据敏感度 | 是否涉及个人信息、重要数据、核心配置与凭据 | 凭据批量泄漏要按高敏感度处理 |
| 业务中断时长 | 已中断多久、能否降级运行、有无人为绕过方案 | 核心链路中断即对标最高级别 |
| 对外可见性 | 是否被客户感知、是否出现在公开渠道 | 客户可感知要同步品牌与客诉团队 |
| 合规与上报 | 是否触发合同或监管的报告义务 | 涉及监管要求时先按高一级处置，再按调查结论回调 |
| 攻击态势 | 是否仍在持续、攻击者是否在线 | 仍在持续的直接定高级别 |
定级宁高勿低，但不能滥用：把批量扫描全部按 P1 处理，会挤占真实 P1 的资源，还要付出重复通知的信任成本。合理做法是先定级后调整，把「依据」写进台账，让升级与降级都有记录可查。
定级依据要落在可验证的事实上：主机名、进程与连接快照、日志时间点、受影响用户数。只写「感觉比较严重」的定级在复盘和对外沟通时都站不住脚，也容易被业务方质疑。
上报义务与级别不完全等价：涉及个人信息或重要数据的泄露可能触发向主管部门报告的义务，具体范围与时限以当地监管要求和本单位合同条款为准，拿不准时按更高一级处置并同步法务。