Articles › Security

现代 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 […]

即使没有网络，现场工作也不应停止 现场作业往往发生在网络条件不理想的环境中。巡检、设备维护、现场调查、应急与灾害响应，常常位于偏远地区、工业区、地下设施或临时作业点。 以云端为核心的系统，在这些关键时刻往往无法正常工作。 OffGridOps 正是为这样的现实场景而设计。 OffGridOps 是一款 离线优先（Offline-first） 的现场作业应用，不依赖服务器或持续的网络连接，也能可靠地记录站点、作业、任务和事件，并附带可核查的证据。

通信が途切れても、現場の仕事は止まらない 現場業務は理想的な環境で行われるとは限りません。点検、保守作業、現地調査、災害対応などは、通信環境が不安定、または完全に圏外の場所で行われることが多くあります。 クラウド前提のツールは、まさにそのような重要な場面で使えなくなることがあります。 OffGridOps は、そうした現実の現場のために設計されました。 OffGridOpsは、オフラインファースト設計のフィールドオペレーションアプリです。サーバーや常時インターネット接続に依存せず、サイト、作業、タスク、インシデントを、証拠付きで確実に記録できます。

เมื่อสัญญาณหาย งานไม่ควรหยุด การทำงานภาคสนามแทบไม่เคยอยู่ในสภาพแวดล้อมที่สมบูรณ์แบบ งานตรวจสอบ งานซ่อมบำรุง การสำรวจพื้นที่ หรือการรับมือเหตุฉุกเฉิน มักเกิดขึ้นในพื้นที่ที่สัญญาณอ่อนหรือไม่มีสัญญาณเลย เช่น พื้นที่ห่างไกล เขตอุตสาหกรรม พื้นที่ใต้ดิน หรือพื้นที่ภัยพิบัติ เครื่องมือที่พึ่งพาคลาวด์เป็นหลัก มักล้มเหลวในช่วงเวลาที่สำคัญที่สุด OffGridOps ถูกสร้างขึ้นมาเพื่อสถานการณ์เหล่านี้ OffGridOps คือ แอปงานภาคสนามแบบ Offline‑first ที่ช่วยให้ทีมงานสามารถติดตามไซต์ งานปฏิบัติการ งานย่อย และเหตุการณ์ต่าง ๆ พร้อมหลักฐานที่ตรวจสอบได้ โดยไม่ต้องพึ่งพาอินเทอร์เน็ตหรือเซิร์ฟเวอร์ตลอดเวลา

When the network disappears, work shouldn’t stop Field teams rarely work in perfect conditions. Inspections, maintenance, surveys, and incident response often happen in places with weak or no connectivity—remote sites, industrial zones, underground facilities, or disaster areas. Cloud‑first tools fail exactly when teams need them most. OffGridOps was built for those moments. It is an […]

中国企业如何利用 AI 提升 Wazuh 安全运维效率 中国环境下 Wazuh 运维面临的现实挑战 Wazuh 作为一款开源 SIEM/XDR 平台，在成本控制、自主可控、灵活扩展方面具有明显优势，因此在中国企业中被广泛采用。 但在实际落地过程中，安全团队通常会遇到以下问题： 检测规则复杂，依赖个人经验，难以标准化 告警数量大，误报多，分析效率低 安全事件难以与业务风险直接关联 需要同时满足等保、内部审计与管理层汇报需求 随着 Agent 和日志规模增长，系统性能与架构压力增大 AI 不能替代安全专家。 但在正确使用的前提下，AI 可以 放大专家经验、加速分析与决策过程。 这正是 Wazuh 管理员 Prompt Pack 的核心价值所在。

日本のセキュリティチームは、どのようにAIを活用してWazuh運用を高度化しているのか 日本企業におけるWazuh運用が難しい理由 Wazuhは、オープンソースでありながらSIEM/XDRとして高い柔軟性と拡張性を持つプラットフォームです。コストを抑えつつ自社でコントロールしたい日本企業にとって、有力な選択肢となっています。 一方で、その柔軟性は運用負荷の増大にも直結します。日本のSOCや情報システム部門では、次のような課題が頻繁に発生します。 検知ルールを業務実態に合わせて正確に設計する難しさ 誤検知（False Positive）を抑えつつ検知力を維持するバランス 技術的な検知結果を経営層・監査部門に説明する必要性 ISO 27001、NIST、社内統制への対応 エージェント数・ログ量増加に伴う性能と運用の問題 AIはセキュリティ専門家の代替ではありません。 しかし、正しく使えば、熟練エンジニアの思考プロセスを再現・加速させることができます。 そのための実践的な手段が Wazuh Admin Prompt Packs です。

ทีมความปลอดภัยในไทยใช้ AI เพื่อดูแล Wazuh อย่างมีประสิทธิภาพได้อย่างไร ทำไมการดูแล Wazuh ในบริบทประเทศไทยจึงไม่ง่าย Wazuh เป็นระบบ SIEM/XDR แบบโอเพ่นซอร์สที่ทรงพลังและยืดหยุ่น เหมาะกับองค์กรไทยที่ต้องการควบคุมต้นทุน แต่ความยืดหยุ่นนี้มาพร้อมภาระด้านการปฏิบัติงาน ผู้ดูแล Wazuh ในไทยมักพบปัญหา เช่น การเขียนกฎตรวจจับ (rules) ให้แม่นยำและเหมาะกับสภาพแวดล้อมจริง การลด false positive โดยไม่ทำให้ blind spot เพิ่มขึ้น การอธิบายความเสี่ยงเชิงเทคนิคให้ผู้บริหารเข้าใจได้ การดูแลระบบให้สอดคล้องกับข้อกำหนด PDPA / ISO 27001 การขยายระบบเมื่อจำนวน agent และ log เพิ่มขึ้น AI ไม่สามารถแทนที่ผู้เชี่ยวชาญด้านความปลอดภัย ได้ แต่หากใช้อย่างถูกต้อง จะช่วย เร่งกระบวนการคิดของผู้เชี่ยวชาญ และลดความผิดพลาดซ้ำ ๆ นี่คือจุดที่ Wazuh Admin Prompt Packs มีประโยชน์

How Security Teams Use AI to Manage, Tune, and Scale Wazuh Faster Why Wazuh Administration Is Harder Than It Looks Wazuh is powerful, open-source, and flexible—but that flexibility comes with operational cost. Many Wazuh administrators struggle with: Writing correct detection rules Tuning alerts without losing visibility Mapping alerts to real business risk Explaining findings to […]

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

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

ในทุกเหตุภัยพิบัติขนาดใหญ่ ไม่ว่าจะเป็น น้ำท่วม พายุ ดินถล่ม ภัยแล้ง แผ่นดินไหว หรืออุบัติเหตุร้ายแรงในวงกว้าง สิ่งแรกที่มักล้มเหลวไม่ใช่ผู้คน แต่คือ โครงสร้างพื้นฐาน ไฟฟ้าดับ เครือข่ายมือถือหนาแน่นหรือใช้งานไม่ได้ การเชื่อมต่ออินเทอร์เน็ตไม่เสถียรหรือหายไปโดยสิ้นเชิง อย่างไรก็ตาม ระบบรับมือเหตุฉุกเฉินที่ถูกเรียกว่า “อัจฉริยะ” จำนวนไม่น้อย กลับถูกออกแบบภายใต้สมมติฐานว่า การเชื่อมต่อเครือข่ายจะพร้อมใช้งานอยู่เสมอ สมมติฐานนี้ไม่ถูกต้อง ระบบรับมือเหตุฉุกเฉินจำเป็นต้องถูกออกแบบแบบ Offline First ไม่ใช่เป็นฟีเจอร์เสริม แต่เป็น ข้อกำหนดพื้นฐาน ของระบบตั้งแต่ต้น

In every major disaster—floods, earthquakes, wildfires, or large-scale accidents—the first thing that fails is often not people, but infrastructure. Power goes down. Mobile networks become congested or unavailable. Internet connectivity becomes unreliable or disappears entirely. Yet many so-called “smart” emergency systems are designed with an assumption that connectivity will always be available. This assumption is […]

用软件工程的视角理解网络安全（Cybersecurity） 为什么网络安全让很多软件工程师觉得“很难” 对许多软件工程师来说，网络安全往往像是一个完全不同的领域： 充满缩写词（SIEM、SOAR、IOC、IDS 等） 使用一套不熟悉的专业术语 听起来复杂、抽象、难以落地 但事实非常简单： 大多数网络安全概念，早已存在于软件工程之中。 区别只是“名称不同、对手不同”。 本文将把常见的 网络安全术语 映射为 软件工程中熟悉的概念，帮助工程师以工程化方式理解和构建安全系统。

サイバーセキュリティ用語をソフトウェア開発の概念で理解する なぜサイバーセキュリティは難しく感じられるのか 多くのソフトウェアエンジニアにとって、サイバーセキュリティは「別世界」に見えがちです。 SIEM、SOAR、IOC などの略語が多い 普段使わない専門用語が多い 何となく難しく、近寄りがたい印象がある しかし実際には、次の一文に集約されます。 サイバーセキュリティの多くの概念は、すでにソフトウェア開発の中に存在しています。 ただし「名前」が違うだけです。

การเทียบคำศัพท์ความปลอดภัยไซเบอร์กับแนวคิด Software Engineering ทำไม Cybersecurity ถึงฟังดูยากสำหรับนักพัฒนา นักพัฒนา Software จำนวนมากรู้สึกว่า Cybersecurity เป็นโลกอีกใบหนึ่ง: เต็มไปด้วยคำย่อ (SIEM, SOAR, IOC, IDS) ใช้ศัพท์คนละชุดกับที่คุ้นเคย ฟังดูเหมือนเรื่องลึกลับ เฉพาะทาง ความจริงคือ: แนวคิดด้าน Cybersecurity ส่วนใหญ่ มีอยู่แล้วในงาน Software Engineering เพียงแค่เรียกชื่อไม่เหมือนกัน

A Practical Mapping Between Security Language and Software Engineering Concepts Why cybersecurity sounds harder than it actually is Many software developers feel that cybersecurity is a different world: Too many acronyms (SIEM, SOAR, IOC, IDS…) Different vocabulary for things that feel familiar Security people sound like they’re talking about something mysterious The truth is simpler: […]