4、日志分析与威胁检测：关联分析、异常检测、规则引擎（Sigma、YARA）、UEBA

日志收集上来，堆在那里，其实没什么用。

真正值钱的是——你怎么从这些看似杂乱的数据里，把坏人揪出来。我见过太多团队，ELK 搭得漂漂亮亮，每天收几个 TB 的日志，但安全告警还是靠人工翻。说白了，就是缺了「分析」这一步。

这一章，我们聊聊实战中的四种检测手段。它们不是孤立的，我习惯把它们串成一条流水线。

4.1 关联分析：把碎片拼成故事

单个日志条目，就像一块拼图。你看到一条 VPN 登录失败，没什么。你看到一条数据库查询异常，也没什么。但如果你把这两条放在一起——同一个 IP，5 分钟内先爆破了 VPN，然后从内网查数据库——故事就出来了。

关联分析的核心，就是找这种「跨系统的因果关系」。

4.1.1 关联规则怎么写？

我常用的套路是「窗口 + 条件 + 动作」。举个例子：

Rule: 异地登录后立即访问敏感数据
Window: 10分钟
Condition:
  - 事件A: VPN登录成功，地理位置 != 常用地
  - 事件B: S3/OSS GetObject 操作，对象标签包含 "敏感"
Action: 告警，优先级高

嗯，这里要注意。关联规则最怕的是「误报爆炸」。我曾经在一个客户现场，写了一条「失败登录 + 成功登录」的规则，结果每天告警 2 万条。为什么？因为正常员工早上打卡也会输错几次密码。后来我加了一个条件——「失败次数 > 5 次」，告警量直接降到 200 条。

4.2 异常检测：找那个「不对劲」的家伙

规则引擎抓的是已知攻击。但未知的呢？零日呢？内部威胁呢？这时候就得靠异常检测了。

异常检测说白了，就是给每个实体（用户、设备、进程）建一个「行为画像」。然后看它今天的行为，跟昨天、上周、上个月比，有没有显著不同。

4.2.1 常用的异常检测方法

方法	适用场景	我踩过的坑
统计基线（均值/标准差）	登录时间、数据量、API 调用频率	节假日数据会拉偏基线，记得做时间窗口加权
时间序列分解	周期性流量、CPU 使用率	周期长度设错了，模型会把正常波动当异常
聚类（K-Means/DBSCAN）	用户分组、设备分组	维度太多时聚类效果很差，先做特征选择
孤立森林	高维数据、少量异常	对「群体异常」不敏感，比如整个部门被钓鱼

我个人比较喜欢「统计基线 + 滑动窗口」的组合。简单，可解释性强。你跟老板解释「这个用户今天下载了 10GB 数据，是他平时 5 倍」，比解释「孤立森林得分 0.87」要容易得多。

4.3 规则引擎：Sigma 与 YARA

聊到规则引擎，就绕不开两个东西：Sigma 和 YARA。它们俩是「一个管日志，一个管文件」。

4.3.1 Sigma：日志规则的通用语言

Sigma 解决了一个很实际的问题：每个 SIEM 的查询语法都不一样。Splunk 用 SPL，ELK 用 EQL，Azure Sentinel 用 KQL。你写一条规则，换个平台就得重写。

Sigma 定义了一套通用规则格式，然后通过「转换器」翻译成各种 SIEM 的查询语句。你想想看，这多省事。

title: 可疑 PowerShell 执行
id: 123e4567-e89b-12d3-a456-426614174000
status: experimental
description: 检测通过 PowerShell 执行 Base64 编码命令
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\powershell.exe'
    CommandLine|contains: '-EncodedCommand'
  condition: selection
falsepositives:
  - 管理员正常使用
level: high

我在项目中遇到过一件事：客户用 Splunk，但安全团队想用 Sigma 社区规则。我们搭了一个自动化流水线，每天从 Sigma 仓库拉新规则，自动转换成 SPL 导入 Splunk。效果不错，但要注意——Sigma 规则的质量参差不齐，一定要先在自己的测试环境跑一遍。

4.3.2 YARA：文件狩猎的利器

YARA 是干另一件事的：匹配文件内容。它最初用在恶意软件分析上，但现在也广泛用于日志中的「文件内容检测」。

比如，你从终端日志里提取了一个可疑脚本，想看看它是不是已知的恶意软件。用 YARA 规则扫一下，几秒钟就知道结果。

rule Suspicious_Mimikatz_Strings {
  meta:
    description = "检测 Mimikatz 特征字符串"
    author = "安全架构师"
  strings:
    $s1 = "mimikatz" nocase
    $s2 = "sekurlsa::logonpasswords" nocase
    $s3 = "kerberos::golden" nocase
  condition:
    any of them
}

4.4 UEBA：用户与实体行为分析

UEBA 是前面几个技术的集大成者。它把关联分析、异常检测、规则引擎揉在一起，专门盯着「人」和「机器」的行为。

说白了，UEBA 想回答一个问题：这个用户今天的行为，像不像他自己？

4.4.1 UEBA 的核心能力

• 画像构建：每个用户有几十个维度的特征，比如登录时间、访问 IP、常用设备、操作类型、数据量。
• 行为基线：基于历史数据，算出每个特征的「正常范围」。
• 异常评分：当前行为偏离基线越远，分数越高。
• 风险聚合：把多个异常事件聚合成一个「案件」，方便分析师调查。

我记得有一次，UEBA 系统给一个普通员工打了 95 分（满分 100）。调查后发现，这个员工的账号在凌晨 3 点登录，从海外 IP 下载了所有客户资料。这就是典型的「账号被盗 + 数据窃取」场景。如果没有 UEBA，这种低频行为很难被规则引擎抓到。

4.4.2 UEBA 的落地难点

难点	我的解法
冷启动问题（没有历史数据）	先用规则引擎顶 2 周，积累数据后再开 UEBA
新员工/转岗员工基线不准	按角色（Role-Based）建基线，而不是按个人
告警太多，分析师看不过来	设置动态阈值，只推送 Top 5% 的高分事件
隐私合规问题	只分析行为元数据，不分析邮件正文/聊天内容

4.5 本章知识体系

下面这张图，是我自己梳理的「日志检测流水线」。你可以看到，数据从采集到告警，经过了四层处理。每一层解决不同的问题。

你看，这个流水线是分层的。规则引擎抓「已知」，关联分析抓「跨系统」，异常检测抓「未知」，UEBA 抓「内部」。每一层都有它的价值，也都有它的盲区。我建议你从规则引擎开始，先把已知攻击覆盖了，再逐步上异常检测和 UEBA。步子迈大了，容易扯着蛋。