現代の Security Operations Center（SOC）において、「迅速な対応」と「一貫性のある判断」は非常に重要です。アナリストによる手動トリアージは時間がかかり、判断のばらつきも発生します。
そこで必要になるのが Automated Decision Logic（自動意思決定ロジック） です。構造化されたルールやスコアリングモデルに基づき、セキュリティアラートを自動評価し、次のアクションを決定します。
本記事では、以下の構成を前提に解説します：
実践的な例と、実運用可能なアーキテクチャを紹介します。
Continue reading “現代 SOC における Automated Decision Logic の構築方法（Shuffle + SOC Integrator 編）”
在现代 Security Operations Center（SOC）中，“响应速度”与“决策一致性”是核心竞争力。依赖人工分析告警不仅效率低，而且容易产生误判与不一致。
解决方案是构建 Automated Decision Logic（自动化决策逻辑） —— 通过结构化规则与评分模型，对安全告警进行自动评估，并自动决定后续处置动作。
本文将基于以下技术栈进行讲解：
通过真实示例与可落地架构，展示如何构建企业级自动化决策体系。
Continue reading “如何在现代 SOC 中构建 Automated Decision Logic（基于 Shuffle + SOC Integrator）”
ใน Security Operations Center (SOC) ยุคใหม่ “ความเร็ว” และ “ความสม่ำเสมอ” คือหัวใจสำคัญ การวิเคราะห์เหตุการณ์แบบ Manual นั้นช้า ไม่สม่ำเสมอ และมีต้นทุนสูง
ทางออกคือ Automated Decision Logic — โครงสร้างการตัดสินใจอัตโนมัติที่ประเมิน Alert และกำหนดการดำเนินการโดยไม่ต้องรอมนุษย์
บทความนี้อธิบายวิธีออกแบบระบบตัดสินใจอัตโนมัติโดยใช้:
เราจะอธิบายด้วยตัวอย่างจริงและสถาปัตยกรรมที่สามารถนำไปใช้งานได้จริง
ก่อนออกแบบระบบตัดสินใจอัตโนมัติ เราควรเข้าใจองค์ประกอบหลักของ Shuffle และการทำงานร่วมกันของแต่ละส่วน
Backend คือหัวใจของระบบอัตโนมัติ ทำหน้าที่:
นี่คือจุดที่ Playbook ถูกประมวลผลจริง
หน้าเว็บสำหรับ:
เปรียบเสมือน Control Panel ของ SOC Automation
Apps คือ Connector ที่รันใน Container ใช้เชื่อมต่อระบบภายนอก เช่น:
แต่ละ App จะเรียก API และส่งผลลัพธ์กลับเข้า Workflow
Workflow คือ Logic ของระบบ ประกอบด้วย:
Workflow คือสมองของ SOAR
Orborus ทำหน้าที่รัน Container ของ Apps และเชื่อมต่อ Backend กับ Docker เพื่อให้แต่ละ Integration ทำงานแยกจากกันอย่างปลอดภัย
Flow ปกติ:
Wazuh → Webhook → Shuffle Backend → Workflow → App Execution → ระบบภายนอก
เมื่อเข้าใจส่วนประกอบเหล่านี้ จะสามารถออกแบบ Automated Decision Architecture ได้อย่างเป็นระบบ
Automated Decision Logic คือระบบ Rule-based หรือ Score-based ที่ตอบคำถามว่า:
"เมื่อมี Security Alert นี้เข้ามา เราควรทำอะไรต่อ?"
แทนที่ Analyst จะตัดสินใจเอง ระบบจะตัดสินใจอัตโนมัติ เช่น:
เป้าหมายคือการจัดการ Incident ที่รวดเร็ว สม่ำเสมอ และวัดผลได้
ระบบตรวจพบการ Login VPN สำเร็จ โดยมีข้อมูล:
เราต้องการให้ระบบตัดสินใจอัตโนมัติ
IF
THEN
ELSE
เหมาะสำหรับองค์กรที่เพิ่งเริ่มต้นทำ Automation
การใช้ IF เดียวแข็งเกินไป ควรใช้ Scoring
| ปัจจัย | คะแนน |
|---|---|
| ประเทศนอกประเทศไทย | +40 |
| IP มี Reputation อันตราย | +30 |
| User ใหม่ | +25 |
| Login เวลาผิดปกติ | +15 |
| ไม่มี MFA | +20 |
แนวทางนี้ยืดหยุ่นและอธิบายได้
SOC ระดับสูงต้องลด Duplicate Case
ตัวอย่าง Rule:
"ถ้า IP เดิมเกิด Alert ซ้ำใน 30 นาที ไม่ต้องสร้าง Case ใหม่ ให้ Append เข้า Case เดิม"
ต้องมีการจัดเก็บ State เช่น:
ช่วยลด Alert Fatigue อย่างมาก
แยกความรับผิดชอบดังนี้:
SOC Integrator (Django)
Shuffle
Wazuh → Shuffle Webhook → SOC Integrator /decide → Decision Response → Shuffle Execute Actions
sequenceDiagram
autonumber
participant WZ as Wazuh
participant SH as Shuffle (Webhook/Workflow)
participant SI as SOC Integrator (Django /decide)
participant TI as Threat Intel (VT/AbuseIPDB)
participant IR as DFIR-IRIS
participant PD as PagerDuty
WZ->>SH: POST Webhook (alert JSON)
SH->>SI: POST /decide (normalized alert)
SI-->>SH: Decision {ignore|enrich_only|create_case|create_case_and_page|append_case}
alt decision == ignore
SH-->>WZ: Tag/Comment: ignored + reason
else decision == enrich_only
SH->>TI: Enrich src_ip/domain
TI-->>SH: Enrichment result
SH-->>WZ: Tag/Comment: enriched + summary
else decision == append_case
SH->>IR: Add note to existing case (case_id)
IR-->>SH: OK
SH-->>WZ: Tag/Comment: appended_case + case_id
else decision == create_case
SH->>TI: Enrich src_ip/domain
TI-->>SH: Enrichment result
SH->>IR: Create case (title, description, severity)
IR-->>SH: case_id
SH-->>WZ: Tag/Comment: case_created + case_id
else decision == create_case_and_page
SH->>TI: Enrich src_ip/domain
TI-->>SH: Enrichment result
SH->>IR: Create case (title, description, severity)
IR-->>SH: case_id
SH->>PD: Trigger incident (critical) + case link
PD-->>SH: incident_key
SH-->>WZ: Tag/Comment: paged + case_id + incident_key
endแนวทางนี้ช่วยให้ Business Logic อยู่ในโค้ด และ Automation อยู่ใน SOAR อย่างชัดเจน
SOC Integrator ควรส่งผลลัพธ์เป็นโครงสร้างที่ชัดเจน
ตัวอย่าง 1 – สร้าง Case และ Page:
{
"decision": "create_case_and_page",
"severity": "critical",
"reason": "High risk VPN login",
"risk_score": 85,
"case_payload": {
"title": "Suspicious VPN Login – admin",
"description": "Login from Russia with malicious IP score"
}
}
ตัวอย่าง 2 – Append เข้า Case เดิม:
{
"decision": "append_case",
"case_id": 1234,
"reason": "Repeated event within 30 minutes"
}
ตัวอย่าง 3 – Ignore:
{
"decision": "ignore",
"reason": "Low risk score"
}
Shuffle จะทำ Branch ตามค่า "decision"
ข้อดี:
รองรับ Service Tier เช่น:
C1 – Automation พื้นฐาน
C2 – Risk Scoring + Enrichment
C3 – Correlation + Adaptive Decision Logic
Automated Decision System ไม่ได้มีเป้าหมายแค่ “เร็ว” แต่ต้อง “สม่ำเสมอ” และ “วัดผลได้”
เริ่มจาก IF ง่าย ๆ
พัฒนาไปสู่ Scoring
และเพิ่ม Correlation + State Awareness
นี่คือเส้นทางจาก Reactive SOC ไปสู่ Intelligent SOC
หากองค์กรของคุณกำลังวางแผนพัฒนา SOC Automation หรือสร้าง SOC Integrator Layer บทความนี้คือพื้นฐานที่สามารถนำไปใช้จริงใน Production ได้
In a modern Security Operations Center (SOC), speed and consistency are everything. Manual triage is slow, inconsistent, and expensive. The solution is automated decision logic — a structured way to evaluate alerts and decide what action should happen automatically.
This article explains how to build automated decision systems using:
We’ll walk through concrete examples and recommended architecture.
现代 SOC（Security Operations Center，安全运营中心）通常由多种强大的安全工具组成。
例如：
从技术上看，这些工具之间可以直接进行集成。
但许多组织在系统上线运行数月后，都会遇到同一个问题：
工具之间的直接集成会随着时间推移变得越来越复杂，最终难以控制。
因此，我们没有采用简单的工具直连模式，而是引入了一个关键架构组件：
SOC Integrator —— API 编排与控制层（API Orchestration Layer）
Continue reading “为什么我们选择设计 SOC Integrator，而不是直接进行 Tool-to-Tool 集成”
現代のSOC（Security Operations Center）は非常に強力なツール群で構成されています。
例えば以下のような構成が可能です。
しかし、多くの組織が運用開始から数か月後に直面する問題があります。
ツール同士を直接接続する構成は、時間とともに複雑化し、制御不能になりやすい という点です。
そこで私たちは、単純なツール間連携ではなく、以下のアーキテクチャを採用しました。
SOC Integrator — APIオーケストレーション層
Continue reading “なぜ私たちは Tool-to-Tool ではなく SOC Integrator を設計したのか”
ระบบ SOC สมัยใหม่มีเครื่องมือที่ทรงพลังมาก
คุณสามารถเชื่อมต่อ:
แต่ปัญหาที่หลายองค์กรพบหลังจากใช้งานไปสักระยะคือ:
การเชื่อมต่อแบบตรงระหว่างเครื่องมือหลายตัว ทำให้ระบบซับซ้อน ควบคุมยาก และขยายต่อได้ยาก
ดังนั้นแทนที่จะเชื่อมทุกอย่างเข้าหากันโดยตรง เราจึงออกแบบองค์ประกอบใหม่ในสถาปัตยกรรมชื่อว่า:
Continue reading “ทำไมเราจึงออกแบบ SOC Integrator แทนการเชื่อมต่อเครื่องมือแบบตรง ๆ (Tool-to-Tool)”
Modern SOC stacks are powerful.
You can connect:
But here’s the problem most organizations discover too late:
Direct integrations between tools become operational chaos.
Instead of connecting everything directly, we introduced a new architecture component:
SOC Integrator — an API Orchestration Layer
Continue reading “Why We Designed a SOC Integrator Instead of Direct Tool-to-Tool Connections”
现代 EV 充电平台不仅是“插上就充”，更需要远程控制、实时监控以及与外部系统的高效集成。
本文基于一个真实运行中的 OCPP 1.6 演示环境，系统性介绍 Web 仪表盘、Backend API 以及 OCPP WebSocket 通信，帮助读者直观理解一个可用于生产环境的 CSMS（充电站管理系统）。
本文的目标很明确：展示真实可用的系统，而不是演示幻灯片或概念原型。
Continue reading “基于 OCPP 1.6 的 EV 充电平台构建 面向仪表盘、API 与真实充电桩的实战演示指南”
近年のEV充電プラットフォームは、単に充電するだけでなく、遠隔制御・リアルタイム監視・外部システム連携が求められています。
本記事では、実際に稼働しているOCPP 1.6デモ環境を用いて、Webダッシュボード、Backend API、OCPP WebSocket通信までを一貫して紹介します。
目的は明確です。スライドではなく、実運用レベルで動作するCSMSを体験してもらうことです。
Continue reading “OCPP 1.6によるEV充電プラットフォーム構築 ダッシュボード・API・実機対応の実践デモガイド”