3. 事件检测与初步分析：日志收集与监控、告警规则设计、事件确认与初步定级

好，我们进入第三个环节。说实话，很多安全团队把大量精力花在「应急响应」上，却忽略了最前面的一步——你怎么知道出事了？

我见过太多案例，攻击者已经在内部横向移动了两周，告警平台愣是没响。为什么？日志没采全，或者规则写得太死。所以这一章，咱们把「看见」这件事聊透。

3.1 日志收集与监控：你得先有数据

没有日志，安全就是瞎子。但日志也不是越多越好。我曾经帮一家金融客户做审计，发现他们每天产生 200TB 日志，结果 90% 是 debug 级别的无用信息。真正需要关注的，反而被淹没了。

我个人习惯，先画一张「数据流图」。搞清楚：

• 资产在哪？
• 流量怎么走？
• 哪些节点必须埋点？

然后按优先级收集。下面这张表是我常用的分类方式：

日志类型	来源	优先级	关键字段
认证日志	AD、VPN、SSH	P0	源IP、用户名、时间、结果
网络流量	防火墙、IDS/IPS	P0	五元组、协议、payload
系统日志	Syslog、EventLog	P1	进程、文件、权限变更
应用日志	Web Server、DB	P1	URL、SQL、状态码
终端日志	EDR、HIDS	P2	进程树、网络连接、注册表

监控工具方面，我推荐 ELK 或 Splunk 做集中存储，配合 Wazuh 或 Suricata 做实时检测。嗯，这里要注意：存储和检索是两回事。热数据（最近7天）放 SSD，冷数据（超过30天）放对象存储，别一股脑全塞进 ES，集群会崩的。

3.2 告警规则设计：别让分析师看海量告警

告警规则设计，说白了就是「怎么让机器帮你干活」。我见过最离谱的规则，一条「登录失败超过5次」就触发 P1 告警。结果呢？每天几千条，全是运维同事输错密码。分析师直接麻木了。

为什么会这样？因为规则没有考虑上下文。

我建议按这个思路来设计：

1. 单点异常：比如一个账号在 1 秒内从 3 个不同城市登录。这基本是撞库。
2. 时序关联：比如先有扫描行为，5 分钟后出现爆破，再 10 分钟后有文件下载。这是攻击链。
3. 基线偏离：比如某台服务器平时晚上流量为 0，今晚突然飙到 500Mbps。这可能是数据外传。

举个例子，一条我常用的规则（Sigma 格式）：

title: 非工作时间异常登录
description: 检测非工作时间从非信任IP的登录成功
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4624
    LogonType: 10  # 远程交互登录
    Time: 
      - '22:00-06:00'
    IpAddress:
      - '!10.0.0.0/8'
      - '!192.168.0.0/16'
  condition: selection
falsepositives:
  - 运维人员夜间紧急维护
level: medium

另外，告警级别别乱标。我习惯用这个矩阵：

• P0（严重）：数据泄露、勒索软件、核心系统沦陷。直接打电话。
• P1（高危）：横向移动、权限提升、持久化。发工单，30分钟内响应。
• P2（中危）：扫描、弱口令、异常流量。日清日结。
• P3（低危）：合规告警、配置漂移。周报汇总。

你想想看，如果所有告警都是 P0，那跟没有告警有什么区别？

3.3 事件确认与初步定级：别急着喊「狼来了」

告警响了，别急着拉群。先做三件事：

1. 确认告警真实性：是不是误报？是不是测试流量？我见过有人把 CDN 回源流量当成 DDoS 的。
2. 确认影响范围：只有一台机器？还是整个网段？有没有核心资产？
3. 确认攻击阶段：是刚进来？还是已经拿到域控了？这决定了你下一步是「封 IP」还是「断网」。

我个人习惯，用一张「事件确认清单」来走流程：

步骤	动作	输出
1	查看原始日志	确认源IP、目标、时间、行为
2	关联上下文	该账号近期行为、该IP历史记录
3	执行初步取证	内存快照、网络连接、进程列表
4	判断业务影响	是否影响核心业务？是否有数据外流？
5	初步定级	P0-P3，并通知对应层级

定级的时候，我建议用「业务影响 + 攻击阶段」两个维度。举个例子：

• 一台测试服务器被扫描 → P3，记录即可。
• 一台生产数据库服务器被提权 → P1，立刻隔离。
• 域控被拿下 → P0，启动全公司应急响应。

好了，这一章的内容就这些。记住：检测是应急的起点，定级是响应的方向盘。下一章我们聊聊「事件遏制与根除」，那才是真正动手的时候。