Network Security

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

  • February 13, 2026

引言

在现代 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 架构，本文提供了一套可在生产环境落地的实践框架。

最新文章