Category: Network

はじめに 現代の Security Operations Center（SOC）において、「迅速な対応」と「一貫性のある判断」は非常に重要です。アナリストによる手動トリアージは時間がかかり、判断のばらつきも発生します。 そこで必要になるのが Automated Decision Logic（自動意思決定ロジック） です。構造化されたルールやスコアリングモデルに基づき、セキュリティアラートを自動評価し、次のアクションを決定します。 本記事では、以下の構成を前提に解説します： Shuffle（SOAR 自動化プラットフォーム） Wazuh（SIEM） DFIR-IRIS（インシデント対応管理） PagerDuty（オンコール通知） 自社開発 SOC Integrator（Django ベース） 実践的な例と、実運用可能なアーキテクチャを紹介します。

引言 在现代 Security Operations Center（SOC）中，“响应速度”与“决策一致性”是核心竞争力。依赖人工分析告警不仅效率低，而且容易产生误判与不一致。 解决方案是构建 Automated Decision Logic（自动化决策逻辑） —— 通过结构化规则与评分模型，对安全告警进行自动评估，并自动决定后续处置动作。 本文将基于以下技术栈进行讲解： Shuffle（SOAR 自动化平台） Wazuh（SIEM 平台） DFIR-IRIS（事件响应系统） PagerDuty（值班通知系统） 自研 SOC Integrator（Django 后端） 通过真实示例与可落地架构，展示如何构建企业级自动化决策体系。

บทนำ ใน Security Operations Center (SOC) ยุคใหม่ “ความเร็ว” และ “ความสม่ำเสมอ” คือหัวใจสำคัญ การวิเคราะห์เหตุการณ์แบบ Manual นั้นช้า ไม่สม่ำเสมอ และมีต้นทุนสูง ทางออกคือ Automated Decision Logic — โครงสร้างการตัดสินใจอัตโนมัติที่ประเมิน Alert และกำหนดการดำเนินการโดยไม่ต้องรอมนุษย์ บทความนี้อธิบายวิธีออกแบบระบบตัดสินใจอัตโนมัติโดยใช้: Shuffle (SOAR Platform) Wazuh (SIEM) DFIR-IRIS (Incident Response) PagerDuty (On-call Alerting) SOC Integrator แบบพัฒนาเอง (Django Backend) เราจะอธิบายด้วยตัวอย่างจริงและสถาปัตยกรรมที่สามารถนำไปใช้งานได้จริง ทำความเข้าใจองค์ประกอบของ Shuffle ก่อนออกแบบระบบตัดสินใจอัตโนมัติ เราควรเข้าใจองค์ประกอบหลักของ Shuffle และการทำงานร่วมกันของแต่ละส่วน 1. Backend (Core Engine) Backend คือหัวใจของระบบอัตโนมัติ ทำหน้าที่: […]

Introduction 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: Shuffle (SOAR platform) Wazuh (SIEM) […]

现代 SOC（Security Operations Center，安全运营中心）通常由多种强大的安全工具组成。 例如： Wazuh（检测与关联分析） Shuffle（SOAR 自动化） IRIS（事件与案件管理） PagerDuty（告警升级与值班通知） 从技术上看，这些工具之间可以直接进行集成。 但许多组织在系统上线运行数月后，都会遇到同一个问题： 工具之间的直接集成会随着时间推移变得越来越复杂，最终难以控制。 因此，我们没有采用简单的工具直连模式，而是引入了一个关键架构组件： SOC Integrator —— API 编排与控制层（API Orchestration Layer）

現代のSOC（Security Operations Center）は非常に強力なツール群で構成されています。 例えば以下のような構成が可能です。 Wazuh（検知・相関分析） Shuffle（SOAR自動化） IRIS（インシデント管理） PagerDuty（エスカレーション／オンコール対応） しかし、多くの組織が運用開始から数か月後に直面する問題があります。 ツール同士を直接接続する構成は、時間とともに複雑化し、制御不能になりやすい という点です。 そこで私たちは、単純なツール間連携ではなく、以下のアーキテクチャを採用しました。 SOC Integrator — APIオーケストレーション層

ระบบ SOC สมัยใหม่มีเครื่องมือที่ทรงพลังมาก คุณสามารถเชื่อมต่อ: Wazuh (Detection & Correlation) Shuffle (SOAR Automation) IRIS (Case Management) PagerDuty (Escalation & On-call) แต่ปัญหาที่หลายองค์กรพบหลังจากใช้งานไปสักระยะคือ: การเชื่อมต่อแบบตรงระหว่างเครื่องมือหลายตัว ทำให้ระบบซับซ้อน ควบคุมยาก และขยายต่อได้ยาก ดังนั้นแทนที่จะเชื่อมทุกอย่างเข้าหากันโดยตรง เราจึงออกแบบองค์ประกอบใหม่ในสถาปัตยกรรมชื่อว่า:

Modern SOC stacks are powerful. You can connect: Wazuh (Detection & Correlation) Shuffle (SOAR Automation) IRIS (Case Management) PagerDuty (Escalation & On-call) 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 […]

在重大灾害或突发事件发生时，最先失效的往往不是人员，而是基础设施。地震、洪水、台风、极端天气、地质灾害、工业事故——在这些场景中，电力中断、通信网络拥塞或中断、互联网连接不可用几乎是常态。 然而，许多被称为“智慧化”的应急系统，却是在默认网络始终可用的前提下设计的。 在真实的应急管理场景中，这一前提并不成立。 因此，应急响应系统必须在设计之初就以 Offline First（离线优先） 作为基本原则，而不是事后的补充能力。

大規模災害が発生したとき、最初に機能しなくなるのは人ではなく、インフラであることが少なくありません。地震、津波、台風、豪雨、土砂災害、原子力・産業事故――その瞬間、停電が起こり、通信回線は輻輳し、インターネット接続は不安定、あるいは完全に失われます。 それにもかかわらず、多くの「スマート」な緊急対応システムは、常にネットワークが利用可能であるという前提で設計されています。 この前提は、現実の災害対応においては成立しません。 緊急対応システムは、付加的な機能としてではなく、根本設計として Offline First である必要があります。