3. 事件检测与初步分析：日志收集、SIEM工具介绍、告警分类、误报处理
好，咱们进入正题。事件检测，说白了就是回答三个问题：「发生了什么？」「严重吗？」「该不该管？」。我见过太多团队，日志堆成山，告警响不停，但真到出事了，反而找不到关键线索。这一章，咱们就把检测环节的底裤扒干净。
3.1 日志收集：你的「眼睛」和「耳朵」
没有日志，安全分析就是盲人摸象。我个人的习惯是，先搞清楚「要收什么」，再想「怎么收」。
3.1.1 必须收集的日志类型
你想想看，攻击者进来总要留下痕迹。这些痕迹藏在哪？
- 系统日志：Windows Event Log、Linux syslog。重点关注登录、权限变更、服务启停。
- 应用日志：Web服务器（Nginx/Apache）、数据库（MySQL/Oracle）、中间件（Tomcat/WebLogic）。
- 网络设备日志：防火墙、路由器、交换机。连接记录、ACL命中、VPN拨入。
- 安全设备日志：IDS/IPS、WAF、EDR、杀毒软件。这是告警的「富矿」。
- 云平台日志：AWS CloudTrail、Azure Activity Log、阿里云ActionTrail。云上操作全记录。
3.1.2 日志收集架构
常见的就两种：Agent模式和Agentless模式。
| 模式 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| Agent（如Filebeat、Winlogbeat） | 灵活、支持解析、低延迟 | 需部署维护、占用客户端资源 | 服务器、容器环境 |
| Agentless（如Syslog、SNMP Trap） | 无需安装、对业务无侵入 | 格式单一、易丢包、安全风险 | 网络设备、老旧系统 |
我个人更倾向混合使用。服务器上装Agent，网络设备走Syslog。嗯，这里要注意：Syslog默认走UDP，容易丢包。我曾经因为这个问题，排查了三天才发现是网络拥塞导致日志丢失。后来全部改成了TCP或RELP协议。
3.2 SIEM工具介绍：你的「大脑」
日志收上来了，堆在一起就是垃圾。你需要一个SIEM（安全信息和事件管理）来帮你看。说白了，SIEM就是把日志变成情报的工具。
3.2.1 主流SIEM工具对比
| 工具 | 类型 | 核心优势 | 我踩过的坑 |
|---|---|---|---|
| Splunk | 商业 | 搜索快、可视化强、生态好 | 贵！许可证按数据量计费，一不小心就超预算 |
| ELK Stack | 开源 | 灵活、可定制、社区活跃 | 运维成本高，ES集群调优是个技术活 |
| IBM QRadar | 商业 | 内置规则多、关联分析强 | 部署笨重，升级一次要半天 |
| Wazuh | 开源 | 免费、集成EDR功能、合规基线 | 性能一般，大规模场景需分布式部署 |
3.2.2 SIEM核心能力
一个合格的SIEM，至少要有这四板斧：
- 日志归一化：把不同格式的日志（JSON、Syslog、Windows Event）转成统一字段。比如「登录失败」，在Windows里是EventID 4625，在Linux里是sshd的Failed password。SIEM得能识别。
- 关联分析：把看似无关的事件串起来。比如「用户A在10秒内从北京登录，又在上海登录」——这明显是账号被盗。
- 告警生成：命中规则就发告警。支持邮件、短信、Webhook。
- 仪表盘：可视化展示。我习惯把「实时攻击地图」「Top 10告警源」「未处理告警数」放在首页。
3.3 告警分类：别让告警淹死你
告警太多，等于没有告警。我见过最夸张的，一天10万条告警，安全团队直接躺平。所以，分类是第一步。
3.3.1 按严重程度分
| 级别 | 颜色 | 定义 | 响应要求 |
|---|---|---|---|
| 紧急（Critical） | 红色 | 确认攻击成功，数据已泄露或系统已失陷 | 立即响应，15分钟内介入 |
| 高危（High） | 橙色 | 高度疑似攻击，有明确攻击特征 | 1小时内分析确认 |
| 中危（Medium） | 黄色 | 可疑行为，需进一步调查 | 24小时内处理 |
| 低危（Low） | 蓝色 | 信息性告警，如扫描探测 | 记录即可，定期回顾 |
3.3.2 按攻击阶段分（MITRE ATT&CK）
这个我强烈推荐。把告警映射到ATT&CK的战术阶段，一眼就能看出攻击者到哪一步了。
- 初始访问：钓鱼邮件、漏洞利用、弱口令爆破
- 执行：PowerShell命令、计划任务、WMI
- 持久化：注册表启动项、服务安装、SSH密钥
- 横向移动：RDP连接、SMB共享、PsExec
- 数据窃取：大量文件读取、压缩、外传
举个例子：你看到一条「用户从内网下载了10GB数据到外网」的告警。如果只看严重程度，可能是高危。但结合ATT&CK，这是数据窃取阶段，说明攻击已经快结束了。你得立刻断网封堵。
3.4 误报处理：别让狼来了
误报是SIEM的「阿喀琉斯之踵」。我做过统计，一个刚上线的SIEM，误报率通常在80%以上。不处理误报，团队迟早会崩溃。
3.4.1 误报的常见原因
- 规则太宽：比如「任何外部IP访问内网数据库」——但你的运维人员也要远程维护啊。
- 基线不准：比如「凌晨3点有登录」——但你的备份任务就是凌晨跑的。
- 白名单缺失：比如「扫描器IP」没加白，结果自己扫自己，告警满天飞。
- 日志质量差：时间戳不对、字段缺失，导致关联分析出错。
3.4.2 误报处理流程
我总结了一个「三明治」流程：
- 确认：先看原始日志，确认是不是误报。别只看SIEM的摘要。
- 分类：
- 真阳性：确认攻击，升级事件响应。
- 假阳性：误报，进入下一步。
- 噪音：告警本身没错，但无实际危害（如扫描探测）。
- 处置：
- 假阳性：调整规则（加白名单、缩小范围、修改阈值）。
- 噪音：降级为信息性告警，或直接静默。
举个例子，一条「用户从非办公地点登录」的告警。你查了日志，发现IP是公司VPN出口。这就是假阳性。怎么办？把VPN出口IP加入白名单，规则就安静了。
3.4.3 误报率指标
我建议团队关注两个指标：
- 误报率 = 假阳性告警数 / 总告警数。目标：低于30%。
- 告警有效率 = 真阳性告警数 / 总告警数。目标：高于50%。
如果误报率超过50%，说明你的规则需要大修了。别犹豫，花一周时间做规则优化，比天天看告警强。
3.5 小结
事件检测不是一蹴而就的。日志收集是基础，SIEM是工具，告警分类是方法，误报处理是持续优化的过程。我个人觉得，最核心的是「人」——你得培养团队的分析能力，让他们能分辨「狼来了」和「狼真的来了」。
下一章，咱们聊聊事件确认与定级。到时候我会分享一个真实的勒索软件事件，看看我们是怎么从一堆误报里揪出真凶的。