如何在现代 SOC 中构建 Automated Decision Logic(基于 Shuffle + SOC Integrator)

引言

在现代 Security Operations Center(SOC)中,“响应速度”与“决策一致性”是核心竞争力。依赖人工分析告警不仅效率低,而且容易产生误判与不一致。

解决方案是构建 Automated Decision Logic(自动化决策逻辑) —— 通过结构化规则与评分模型,对安全告警进行自动评估,并自动决定后续处置动作。

本文将基于以下技术栈进行讲解:

  • Shuffle(SOAR 自动化平台)
  • Wazuh(SIEM 平台)
  • DFIR-IRIS(事件响应系统)
  • PagerDuty(值班通知系统)
  • 自研 SOC Integrator(Django 后端)

通过真实示例与可落地架构,展示如何构建企业级自动化决策体系。


理解 Shuffle 的核心组件

在设计自动化决策系统之前,需要理解 Shuffle 的核心组件及其协作方式。

1. Backend(核心引擎)

Backend 是自动化执行的核心:

  • 执行 Workflow
  • 接收 Trigger
  • 管理 Integration Apps
  • 记录执行日志

所有 Playbook 逻辑都在此执行。

2. Frontend(Web 控制台)

用于:

  • 拖拽式构建 Workflow
  • 配置 API 与凭证
  • 查看执行日志
  • 管理用户与权限

相当于 SOC 自动化控制中心。

3. Apps(集成模块)

Apps 是运行在容器中的连接器,用于对接外部系统,例如:

  • Wazuh(SIEM)
  • DFIR-IRIS(案例管理)
  • PagerDuty(值班告警)
  • VirusTotal 或其他威胁情报平台

每个 App 负责调用 API 并将结构化结果返回至 Workflow。

4. Workflows(自动化流程)

Workflow 定义自动化逻辑,包括:

  • Trigger(Webhook、定时、手动)
  • Condition(条件判断)
  • Action(情报查询、创建案例、通知等)

Workflow 是 SOAR 的“决策大脑”。

5. Orborus(App 执行器)

负责运行容器化 Apps,并确保各集成模块安全、隔离地执行。

Shuffle 组件协作流程

典型流程:

Wazuh → Webhook → Shuffle Backend → Workflow → 执行 Apps → 外部系统

理解这些组件后,可以更清晰地设计自动化决策架构。


什么是 Automated Decision Logic?

Automated Decision Logic 是基于规则或评分模型的系统,用来回答:

“当收到这个安全告警时,系统应该采取什么行动?”

系统可自动决定:

  • Ignore(忽略)
  • 仅做情报补充(Enrichment)
  • 创建 Incident Case
  • 创建 Case 并通知值班人员
  • 追加至已有 Case

目标是实现快速、标准化、可度量的事件响应流程。


示例场景:可疑 VPN 登录

来自 Wazuh 的告警

检测到 VPN 登录成功,信息如下:

  • Country: Russia
  • User: admin
  • Severity: 12
  • Source IP: 185.199.108.153

我们希望系统自动进行决策。


第一阶段:基础 IF / ELSE 规则

规则示例:

IF

  • country != "Thailand"
  • AND severity >= 10

THEN

  • 查询 IP 威胁情报
  • 创建 IRIS Case
  • 通知 PagerDuty

ELSE

  • 记录日志并结束

适合自动化初级阶段。


第二阶段:风险评分模型(推荐)

单一 IF 条件过于刚性,更推荐使用 Risk Scoring。

示例风险模型

因素 分值
非本国登录 +40
IP 恶意评分高 +30
新用户 +25
异常时间登录 +15
未启用 MFA +20

决策阈值

  • 分数 >= 70 → Critical(创建 Case + 通知)
  • 分数 40–69 → Medium(仅创建 Case)
  • 分数 < 40 → 仅记录

这种方式更灵活且可解释。


第三阶段:有状态决策(关联分析 + 去重)

高级 SOC 必须避免重复创建 Case。

规则示例:

“若同一 IP 在 30 分钟内重复触发告警,不创建新 Case,而是追加到现有 Case。”

需要状态存储:

  • 在 Django 数据库中保存关联记录
  • 使用 Redis 进行短期状态管理
  • 创建 Case 前查询 IRIS

可显著降低告警疲劳(Alert Fatigue)。


推荐架构(职责清晰分离)

建议架构分工如下:

SOC Integrator(Django)

  • 风险评分
  • 关联分析
  • 去重逻辑
  • 输出决策结果

Shuffle

  • 执行 Workflow
  • 调用各类集成
  • 管理触发流程

流程

Wazuh → Shuffle Webhook → SOC Integrator /decide → 返回决策 → Shuffle 执行动作

Sequence Diagram(系统交互流程)

sequenceDiagram
    autonumber

    participant WZ as Wazuh
    participant SH as Shuffle
    participant SI as SOC Integrator
    participant TI as Threat Intel
    participant IR as DFIR-IRIS
    participant PD as PagerDuty

    WZ->>SH: 发送告警 Webhook
    SH->>SI: 调用 /decide 接口
    SI-->>SH: 返回决策结果

    alt ignore
        SH-->>WZ: 标记为已忽略
    else enrich_only
        SH->>TI: 查询威胁情报
        TI-->>SH: 返回结果
    else create_case
        SH->>IR: 创建 Case
    else create_case_and_page
        SH->>IR: 创建 Case
        SH->>PD: 触发值班告警
    end

该架构确保业务逻辑在代码层可控,而自动化执行由 SOAR 负责。


Decision API 返回示例

示例 1:创建 Case 并通知

{
"decision": "create_case_and_page",
"severity": "critical",
"risk_score": 85
}

示例 2:追加至已有 Case

{
"decision": "append_case",
"case_id": 1234
}

示例 3:忽略

{
"decision": "ignore"
}

Shuffle 根据 decision 字段进行分支处理。


为什么该架构适合企业级扩展?

优势包括:

  • 决策逻辑可版本化管理
  • 可测试风险模型
  • 易于持续调优
  • 减少误报
  • 审计追踪清晰

可支持不同服务层级:

C1 – 基础自动化规则
C2 – 风险评分 + 情报补充
C3 – 关联分析 + 自适应决策


总结

Automated Decision System 不仅追求“速度”,更强调“稳定性”和“可度量性”。

从简单规则开始,逐步引入评分模型,再加入关联分析与状态管理。

这就是从 Reactive SOC 迈向 Intelligent SOC 的演进路径。


如果您的组织正在规划 SOC 自动化或构建 SOC Integrator 架构,本文提供了一套可在生产环境落地的实践框架。


Get in Touch with us

Chat with Us on LINE

iiitum1984

Speak to Us or Whatsapp

(+66) 83001 0222

Related Posts

Our Products