Day-281-关联规则引擎

# Day 302: 关联规则引擎 - 规则语法/逻辑/优化技巧

> 安全运维系列第 12 天 | 预计阅读时间：25 分钟 | 难度：★★★☆☆

---

## 清单 目录

1. [关联规则概述](#关联规则概述)
2. [规则语法](#规则语法)
3. [规则逻辑](#规则逻辑)
4. [规则类型](#规则类型)
5. [规则优化](#规则优化)
6. [规则管理](#规则管理)
7. [实战案例](#实战案例)
8. [总结与思考](#总结与思考)
9. [参考资料](#参考资料)

---

## 关联规则概述

### 什么是关联规则

关联规则是 SIEM 检测安全威胁的核心机制，通过定义条件和逻辑关系，从海量日志中识别可疑活动。

**规则组成**：
- **条件 (Condition)**: 触发规则的条件
- **逻辑 (Logic)**: 条件之间的关系
- **动作 (Action)**: 规则触发后的动作

**示例**：
```
IF 5 分钟内同一源 IP 登录失败 >= 10 次
AND 随后登录成功
THEN 生成 P2 告警：疑似暴力破解成功
```

### 规则引擎架构

```
┌─────────────────────────────────────────────────────────────┐
│                    关联规则引擎                              │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐         │
│  │  规则解析   │  │  事件匹配   │  │  状态管理   │         │
│  │  编译器     │  │  引擎       │  │  窗口管理   │         │
│  └─────────────┘  └─────────────┘  └─────────────┘         │
│                                                             │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐         │
│  │  规则库     │  │  告警输出   │  │  性能监控   │         │
│  │  版本管理   │  │  富化       │  │  统计       │         │
│  └─────────────┘  └─────────────┘  └─────────────┘         │
│                                                             │
└─────────────────────────────────────────────────────────────┘
```

---

## 规则语法

### 通用规则语法

**基本结构**：
```yaml
rule:
  name: "Brute Force Detection"
  description: "Detect brute force login attempts"
  severity: medium
  
  condition:
    event_type: "authentication"
    event_result: "failure"
    count: 10
    time_window: "5 minutes"
    group_by: ["src_ip", "target_user"]
  
  action:
    type: "alert"
    priority: "P2"
    message: "Possible brute force attack detected"
```

### Splunk 规则语法

**SPL 关联规则**：
```spl
index=security event_type=authentication event_result=failure
| bucket _time span=5m
| stats count by src_ip target_user _time
| where count >= 10
| join src_ip _time [
    search index=security event_type=authentication event_result=success
    | stats count as success_count by src_ip target_user _time
]
| where success_count > 0
| eval alert="Brute Force Success"
| table _time src_ip target_user count success_count alert
```

### Elastic 规则语法

**EQL (Event Query Language)**：
```eql
sequence by src_ip with maxspan=5m
  [authentication where event_type == 'login' and event_result == 'failure']
  [authentication where event_type == 'login' and event_result == 'success']
| stats count() as failure_count by src_ip, user.name
| where failure_count >= 5
```

**KQL + Aggregation**：
```json
{
  "query": {
    "bool": {
      "must": [
        { "match": { "event.type": "authentication" } },
        { "match": { "event.outcome": "failure" } }
      ]
    }
  },
  "aggs": {
    "by_src_ip": {
      "terms": { "field": "source.ip" },
      "aggs": {
        "over_time": {
          "date_histogram": { "field": "@timestamp", "calendar_interval": "5m" },
          "aggs": {
            "failure_count": { "value_count": { "field": "_id" } }
          }
        }
      }
    }
  }
}
```

### QRadar 规则语法

**AQL (Ariel Query Language)**：
```sql
SELECT 
    sourceip,
    username,
    COUNT(*) as failure_count,
    MAX(logsourceid) as last_seen
FROM events
WHERE 
    eventcategory = 'Authentication'
    AND severity >= 5
    AND logsourceid IN (SELECT id FROM logsources WHERE devicetype = 'Windows')
GROUP BY sourceip, username
HAVING failure_count >= 10
LAST 5 MINUTES
```

---

## 规则逻辑

### 阈值逻辑

**简单阈值**：
```
IF 事件计数 >= 阈值
THEN 触发告警

示例：
IF login_failure_count >= 10 in 5 minutes
THEN alert
```

**动态阈值**：
```
IF 事件计数 > 基线均值 + 3 * 标准差
THEN 触发告警

示例：
IF current_count > baseline_mean + 3 * baseline_std
THEN alert
```

### 时序逻辑

**顺序检测**：
```
事件 A → 事件 B → 事件 C
时间窗口：10 分钟

示例：
端口扫描 → 漏洞利用尝试 → 成功登录
```

**频率检测**：
```
IF 事件频率 > 正常频率 * 倍数
THEN 触发告警

示例：
API 调用频率 > 正常频率 * 5
```

### 关联逻辑

**多条件关联**：
```
IF (条件 A AND 条件 B) OR (条件 C AND 条件 D)
THEN 触发告警

示例：
(登录失败 >= 10 AND 来自外部 IP) OR
(登录成功 AND 非常规时间 AND 访问敏感系统)
```

**跨数据源关联**：
```
IF 防火墙告警 AND IDS 告警 AND 终端告警
THEN 高优先级告警

示例：
防火墙：检测到异常外联
IDS:  检测到 C2 通信特征
EDR:  检测到可疑进程
→ 综合判定为恶意软件感染
```

---

## 规则类型

### 按检测目标分类

**认证安全规则**：
```
- 暴力破解检测
- 凭证填充检测
- 异常登录检测
- 特权账户滥用检测
```

**网络安全规则**：
```
- 端口扫描检测
- DDoS 攻击检测
- 异常流量检测
- C2 通信检测
```

**恶意软件规则**：
```
- 已知恶意软件检测
- 可疑进程执行
- 持久化机制检测
- 横向移动检测
```

**数据安全规则**：
```
- 大量数据访问
- 敏感数据外传
- 异常文件操作
- 数据渗出检测
```

### 按检测方法分类

**签名检测**：
```
基于已知特征：
- IOC 匹配 (IP、域名、哈希)
- 攻击特征匹配
- 恶意代码特征
```

**异常检测**：
```
基于行为异常：
- 偏离基线
- 异常时间活动
- 异常访问模式
```

**行为检测**：
```
基于攻击行为：
- 攻击链检测
- TTP 匹配
- 杀伤链阶段检测
```

---

## 规则优化

### 性能优化

**减少误报**：
```
优化前：
IF login_failure THEN alert

优化后：
IF login_failure >= 10 in 5min 
   AND src_ip NOT IN whitelist
   AND target_user NOT IN service_accounts
THEN alert
```

**提高效率**：
```
优化前：
全量搜索所有日志

优化后：
1. 先过滤时间范围
2. 再过滤事件类型
3. 最后聚合统计
```

### 规则调优

**白名单管理**：
```yaml
whitelist:
  ips:
    - 10.0.0.0/8      # 内网扫描器
    - 192.168.1.100   # 安全团队
  users:
    - service_account
    - backup_user
  hosts:
    - scanner01
    - test-server
```

**阈值调整**：
```
初始阈值：10 次/5 分钟
运行 1 周后分析：
- 误报率：80% (阈值过低)
- 调整为：20 次/5 分钟
- 误报率降至：30%
```

---

## 规则管理

### 规则生命周期

```
需求 → 开发 → 测试 → 评审 → 部署 → 监控 → 优化/下线
```

**各阶段要点**：

**开发**：
- 明确检测目标
- 定义触发条件
- 编写规则代码

**测试**：
- 使用历史数据测试
- 验证检测效果
- 评估误报率

**部署**：
- 灰度发布
- 监控性能影响
- 收集反馈

**运营**：
- 定期审查效果
- 调整阈值
- 更新白名单

### 规则文档

**规则文档模板**：
```markdown
# 规则名称：暴力破解检测

## 基本信息
- 规则 ID: RULE-AUTH-001
- 版本：1.2
- 创建日期：2026-01-15
- 最后更新：2026-04-12

## 检测目标
检测针对用户账户的暴力破解攻击

## 规则逻辑
5 分钟内同一源 IP 对同一用户登录失败>=10 次，且随后登录成功

## 阈值
- 失败次数：10 次
- 时间窗口：5 分钟

## 白名单
- 内网扫描器 IP
- 安全测试账户

## 误报处理
已知误报场景和处置方法

## 变更历史
- v1.0: 初始版本
- v1.1: 调整阈值为 10 次
- v1.2: 添加白名单
```

---

## 实战案例

### 案例 1：暴力破解检测

```yaml
rule:
  name: "SSH Brute Force Detection"
  id: RULE-SSH-001
  
  condition:
    log_source: "sshd"
    event_type: "authentication"
    event_result: "failure"
    count: 10
    time_window: "5m"
    group_by: ["source.ip", "user.name"]
    
  action:
    type: "alert"
    severity: "medium"
    message: "SSH brute force detected from ${source.ip}"
```

### 案例 2：横向移动检测

```yaml
rule:
  name: "Lateral Movement Detection"
  id: RULE-LAT-001
  
  condition:
    sequence:
      - event: "login_success"
        constraints:
          user.type: "privileged"
      - event: "file_access"
        time_after: "0-10m"
        constraints:
          file.sensitivity: "high"
      - event: "remote_connection"
        time_after: "0-5m"
        constraints:
          destination.type: "server"
    group_by: ["user.name"]
    
  action:
    type: "alert"
    severity: "high"
    message: "Possible lateral movement by ${user.name}"
```

### 案例 3：数据渗出检测

```yaml
rule:
  name: "Data Exfiltration Detection"
  id: RULE-EXF-001
  
  condition:
    log_source: "proxy"
    direction: "outbound"
    bytes_sent: "> 100MB"
    time_window: "1h"
    group_by: ["source.ip", "user.name"]
    filter:
      destination.country: "high_risk"
      OR destination.category: "file_sharing"
    
  action:
    type: "alert"
    severity: "high"
    message: "Possible data exfiltration detected"
```

---

## 总结与思考

### 核心要点回顾

1. **规则语法**：各 SIEM 平台语法不同，核心逻辑相似
2. **规则逻辑**：阈值、时序、关联是核心逻辑
3. **规则类型**：按检测目标和检测方法分类
4. **规则优化**：减少误报、提高效率
5. **规则管理**：全生命周期管理，文档化
6. **实战案例**：暴力破解、横向移动、数据渗出

### 深入思考

**规则开发的挑战**
- 误报与漏报的平衡
- 性能与检测率的平衡
- 规则维护成本

**最佳实践**
- 从高风险场景开始
- 持续调优和迭代
- 建立规则库和知识共享

---

## 参考资料

### 学习资源

- **MITRE ATT&CK**: https://attack.mitre.org
- **Sigma Rules**: https://github.com/SigmaHQ/sigma

### 工具资源

- **Splunk Correlation Search**: https://docs.splunk.com
- **Elastic Detection Rules**: https://www.elastic.co

---

*Day 302 完成 | 关联规则引擎详解 | 字数：约 11,000 字*