疑点该怎么排序
调查时间有限，线索数量往往远超处理能力，需要一套可复核的排序规则。通常按三个维度综合：证据强度（是硬证据还是单条弱线索）、影响面（涉及多少主机、多少数据、是否核心业务）、新鲜度（越近期越可能仍在活跃）。三者综合后把资源投给“近期、高影响、证据硬”的疑点，弱线索批量并行验证，长期未解释的单条日志先收录待核，不必立刻深挖。
基本信息
| 适用平台 | 所有事件响应与溯源工作 |
|---|---|
| 评估维度 | 证据强度、影响面、新鲜度 |
| 处理方式 | 立即处置、并行验证、收录待核三档 |
| 复评节奏 | 每轮扩展后重排一次，新证据随时上位 |
| 留痕要求 | 每条线索写一句排位理由，便于复核与交接 |
典型使用场景
- 确定先查哪台主机：优先查仍在活跃外联且权限较高的主机
- 分配人手：强证据线索给资深分析员，弱线索批量脚本化验证
- 向管理层说明资源投入的理由，避免被质疑“为什么先查这个”
- 处理轮次之间保持连续性，交接时不必重新讨论顺序
- 处置窗口紧张时，明确哪些线索决定先做隔离、哪些可以延后
排序示例
排序示例
A: 近 1 小时外联 + 高权限账号 → 立即处置
B: 昨日的可疑扫描流量 → 并行脚本化验证
C: 一周前的单条异常日志 → 收录待核，随新证据再评估
# 排序记录格式
编号 | 疑点摘要 | 强度 | 影响 | 新鲜度 | 处置档位 | 理由排序维度对照
| 维度 | 判断依据 | 对应动作 |
|---|---|---|
| 证据强度 | 是否有哈希、日志、流量等多源印证 | 强证据优先深挖，弱线索批量验证 |
| 影响面 | 涉及主机数、数据敏感度、业务重要性 | 核心业务主机即使证据较弱也需提前确认 |
| 新鲜度 | 事件距离当前时间 | 近期事件优先级高，仍在活动要先处置 |
| 可验证成本 | 验证一条线索需要的时间与数据量 | 低成本验证的可并行铺开 |
| 阻塞关系 | 结论是否依赖该线索 | 被多条线索依赖的优先做 |
排序结果不是定稿：每轮扩展后重排一次，新证据随时可以上位；排位理由要留痕，复评时不必重新讨论。
弱线索批量验证可以脚本化：只要规则明确（例如同一来源 IP 出现次数超过阈值即升档），就能用自动化处理掉大部分低价值线索。