场景解决方案 · WEB-ITDR
身份威胁
研判与响应
告警很多，能定性的很少。本方案把原始告警按身份聚合成可处理的事件，说明触发依据，给出分级处置建议，并把执行结果记录成事后可复核的证据。
The Problem
告警很多，能定性的很少
运营团队每天面对的不是「有没有告警」，而是「这条要不要动、按什么依据动、动完怎么交代」。这三个问题答不上来，告警再多也变不成防护。
Where It Applies
这套流程接在什么条件上
研判与响应不是一套独立系统，它接在已有的接入范围与运营流程上。下面三件事先确认清楚，后面的分级与动作清单才写得出来。
- 告警来自已接入 Web ITDR 的应用与认证入口
- 接入方式决定可见字段与可执行动作
- 未接入的系统不在本流程内
- 小到一两个人兼顾，大到有排班的值班班组
- 分级与动作清单按班组能力约定
- 一线按依据执行，不靠个人经验判断
- 与 SIEM、工单与审批系统对接
- 跨系统的统一研判仍由 SIEM 承担
- 部分处置动作的最终执行在其他系统
旁路镜像模式下，本流程输出的是告警、判断依据与处置建议，实际阻断需要身份系统或网络侧联动完成；反向代理模式才具备在访问链路上直接执行策略的条件。接入方式见业务访问与身份防护。
How It Works
从原始告警到一次可交代的处置
五段流程，前两段解决「看不过来」，中间两段解决「说不清楚」，最后一段解决「事后交代不了」。三层研判对应三种角色，各看各需要的那一层。
| 研判层次 | 输入与输出 | 主要面向 |
|---|---|---|
| 事件级研判 | 输入：同一来源或同一账号的多条聚合告警。输出：这次活动的性质、涉及的账号与资产范围、所处的攻击阶段 | 管理者与审计：看这次活动整体是什么 |
| 日志级研判 | 输入：单条原始访问记录及其字段。输出：关键异常字段、判断依据，以及与其他访问的关联 | 分析师：核对结论是否站得住 |
| 处置建议 | 输入：上面两层的结论与当前业务上下文。输出：分级的处置动作、预期效果与误伤风险提示 | 值班运营：知道该做什么、风险在哪 |
聚合把同一次活动的多条告警收敛成一个事件。聚合结果用于辅助判断，不等于已确认因果；收敛程度取决于告警质量与策略配置，收得过狠会把独立事件并在一起。
AI 研判在这里的角色是辅助：每条结论都要引用具体字段与关联关系，供人复核；结论是否成立、动作是否执行，由人决定并留痕。系统不替人做决定，也不把建议记成已执行。
Division of Responsibility
判断可以辅助，决定要有人签字
研判环节最容易出问题的地方，是把「系统给的建议」当成「已经做出的决定」。下表把两者分开，也把必须由别的系统执行的动作标出来。
| 环节 | Web ITDR | 由人或现有系统负责 |
|---|---|---|
| 告警聚合与降噪 | 按身份与时间聚合，收敛成事件 | 降噪策略由运营团队确认后生效 |
| 研判结论 | 给出判断，并引用所依据的字段与关联 | 分析师确认结论是否成立 |
| 处置建议 | 给出分级动作、预期效果与误伤风险提示 | 是否执行由授权人决定 |
| 代理链路上的动作 | 放行、验证、拦截，并记录结果 | 策略与阈值由运营团队维护 |
| 账号与凭据动作 | 不代为执行 | IAM / 目录服务：重置密码、提升 MFA、停用账号 |
| 网络侧封禁 | 不代为执行 | 防火墙 / 网络团队 |
| 工单与审批 | 输出可归档的记录 | 企业既有的工单与审批系统 |
| 跨系统统一研判 | 输出身份化的告警与证据 | SIEM / SOC：跨系统汇聚与统一研判 |
标为「不代为执行」的几行都会直接影响业务或员工，应由对应系统的责任人在自己的流程里执行。本方案负责把依据、影响面与预期效果说清楚，让这些决定有据可依。
Rollout
先把噪声收掉，再写处置清单
四步推进，每一步的产出都是下一步的输入。跳过降噪直接写清单，写出来的分级会跟着噪声走。
- 确认告警来源与可见字段范围
- 与现有 SIEM、工单系统对齐格式
- 约定谁在什么时段看告警
- 观察一段时间，建立正常访问的基线
- 调整聚合与抑制策略
- 收掉重复与已知合规的行为
- 约定分级标准与每一级的处置动作
- 标注每个动作的影响面与误伤风险
- 明确哪些动作必须先审批
- 按授权路径执行并记录结果
- 定期复盘误判与漏判
- 把复盘结论回写到策略与清单
顺序上，先把降噪做完再定分级。噪声还没收敛就写处置清单，分级会跟着噪声走，上线后大量动作落在本来不需要处理的事件上，一线很快就会停止执行清单。
Validation
拿一条真实告警，走完四步
验证这套流程是否成立，最直接的方式是取一条已经发生过的告警，从聚合一路走到归档，看每一步能不能交代清楚。
举证依赖已经采集到的证据，时间线与关系视图的完整性取决于接入范围与日志可见性；没有采集到的环节应当显示为缺口，而不是补一条推断出来的连线。
建议在试点前约定参与验证的告警范围、判定标准与复盘周期；未完成验证前不填报降噪率、研判准确率或响应时间一类的数字。演示环境展示的是产品演示场景，不是某一位客户的实际事件记录。
Expert Consultation
拿一条真实告警，走完研判到复核的全过程
告诉我们现在的告警来源、运营班组规模与工单流程，我们会用一条真实或约定的告警演示聚合、研判、处置与归档的完整链路：
聚合与降噪演示
原始告警如何收敛成事件
研判依据核对
结论引用了哪些字段与关联
处置与归档
动作、授权、回执与复盘记录
飞书扫码，即可咨询