为什么许多网络安全项目一开始就失败

许多中国企业希望“加强网络安全”，但实际落地后往往出现以下问题：

• 告警数量巨大，但无人真正响应
• 投入昂贵的安全产品，运维团队却无法有效使用
• 看起来很专业的仪表盘，却无法阻止真实攻击
• 系统严重依赖个别工程师，一旦人员变动，安全能力随之下降

真正的问题 不在于工具本身，而在于 系统架构设计（System Design）。

Continue reading "现代网络安全监控与事件响应系统设计 基于 Wazuh、SOAR 与威胁情报的可落地架构实践" →

なぜ多くのセキュリティプロジェクトは最初から失敗するのか

多くの日本企業が「セキュリティを強化したい」と考えていますが、実際には次のような状況に陥りがちです。

• アラートは大量に出るが、誰も対応しない
• 高価な製品を導入したが、現場で使いこなせない
• 見た目の良いダッシュボードはあるが、実害を防げない
• 特定の担当者に依存し、その人が不在になると運用が止まる

本当の問題はツールそのものではありません。
問題はシステム設計（System Design）です。

本記事では、私たちが実際の現場で採用している 実運用に耐えるサイバーセキュリティ監視・対応システム の設計思想とアーキテクチャを、日本企業の運用・監査・ガバナンスを前提として解説します。

Continue reading "モダンなサイバーセキュリティ監視・インシデント対応システムの設計 Wazuh・SOAR・脅威インテリジェンスを用いた実践的アーキテクチャ" →

ทำไมหลายโครงการด้านความปลอดภัยไซเบอร์ในไทยถึงล้มเหลวตั้งแต่เริ่ม

หลายองค์กรในประเทศไทยอยากได้ “ระบบความปลอดภัยที่ดีขึ้น” แต่สิ่งที่ได้จริงมักเป็น:

• แจ้งเตือนจำนวนมาก แต่ไม่มีใครตอบสนอง
• เครื่องมือราคาแพงที่ทีมใช้งานไม่เป็น
• Dashboard สวย แต่ไม่ช่วยป้องกันเหตุจริง
• ระบบที่พึ่งพาคนเก่งไม่กี่คน ถ้าคนนั้นไม่อยู่ ทุกอย่างหยุด

ปัญหาที่แท้จริง ไม่ใช่เครื่องมือ
แต่คือ การออกแบบระบบ (System Design)

Continue reading "การออกแบบระบบ Cybersecurity Monitoring & Incident Response สมัยใหม่ สถาปัตยกรรมเชิงปฏิบัติ ด้วย Wazuh, SOAR และ Threat Intelligence" →

Building a Modern Cybersecurity Monitoring & Response System

A Practical Architecture Using Wazuh, SOAR, and Threat Intelligence

Why most security projects fail before they start

Many organizations want “better security”, but what they usually get is:

• Too many alerts, no action
• Expensive tools nobody understands
• Security dashboards that look good but don’t protect anything
• A system that depends on a few individuals’ knowledge

The real problem is not tools.
It’s system design.

This article explains how we design a production-ready cybersecurity monitoring & response system—one that is practical, auditable, and automatable—and why this architecture works in the real world.

---

The real objective (not marketing buzzwords)

The goal is not “installing SIEM” or “using AI”.

The real objectives are:

1. Detect real threats, not noise
2. Know who must respond, and when
3. React fast before damage spreads
4. Keep evidence for audit & investigation
5. Stay flexible and vendor-neutral

This is a system engineering problem, not a product selection problem.

---

The architecture philosophy

We deliberately separate responsibilities.

Detection ≠ Automation ≠ Escalation ≠ Investigation

Each part must do one job extremely well.

---

The core stack we use (and why)

System architecture overview

graph TD
    A["Endpoints / Servers / Cloud"] --> B["Wazuh Agent"]
    B --> C["Wazuh Manager (SIEM/XDR)"]
    C --> D["Shuffle SOAR"]
    D -->|Create / Update Incident| E["DFIRTrack"]
    D -->|SEV-1 / SEV-2| F["PagerDuty"]
    D -->|Automated Response| G["Firewall / DNS / IAM / EDR"]

    F --> H["On-call Engineer"]

This diagram shows how detection, automation, escalation, and investigation are cleanly separated but tightly integrated.

1. Detection layer — Wazuh

Wazuh acts as the security sensor network:

• Collects logs from:

  • Firewall
  • DNS
  • IDS / IPS
  • VPN
  • Servers & endpoints
• Normalizes events
• Applies correlation rules

Wazuh answers:
“Something suspicious happened. What is it?”

We do not overload Wazuh with business logic.
Its job is detection, not decision-making.

---

2. Automation & decision layer — SOAR (Shuffle)

Once something is detected, we need logic:

• Is this serious?
• Is this known malicious?
• Should we block, alert, or just log?

This is where SOAR comes in.

Shuffle allows us to build explicit security playbooks:

• Threat-intelligence enrichment
• Severity calculation
• Conditional response
• System-to-system orchestration

Shuffle answers:
“What should we do next?”

This is where engineering experience matters most.

---

3. Guaranteed human response — PagerDuty

Automation is powerful—but humans are still responsible.

PagerDuty ensures:

• The right person is notified
• Escalation happens if no one responds
• Response time is measurable (SLA)

PagerDuty answers:
“Who is responsible right now?”

This is the difference between alerts and accountability.

---

4. Investigation & audit trail — DFIRTrack

Every serious event becomes an incident:

• Evidence
• Timeline
• Decisions
• Actions taken

DFIRTrack provides:

• Incident records
• Asset tracking
• Investigation notes
• Audit readiness

DFIRTrack answers:
“What happened, exactly?”

This is essential for compliance, post-incident review, and trust.

---

How real use cases are implemented

Example 1: DNS communication to malicious domains

Problem
Malware almost always uses DNS to “phone home”.

System behavior

1. DNS logs are collected
2. Domain is compared against live threat-intelligence feeds

3. If malicious:

   • Incident is created
   • Endpoint is identified
   • Firewall/DNS block is applied
   • On-call engineer is notified (if severity is high)

This detects attacks before data is stolen.

---

Example 2: IDS / IPS traffic to known attacker IPs

Problem
Some attacks bypass endpoint security.

System behavior

• IDS/IPS logs are analyzed
• Destination IP matches known attacker infrastructure
• Correlated with asset criticality
• Automated containment or escalation

This avoids “signature spam” and focuses on real risk.

---

Example 3: VPN login success from outside Thailand

Problem
A successful login can still be an attack.

System behavior

• VPN authentication logs analyzed
• GeoIP enrichment applied

• If login is successful from unexpected country:

  • Risk score increases
  • Incident created
  • Optional forced verification or temporary block

This detects credential theft, not just brute force.

---

Why threat intelligence must be always fresh

Attackers rotate:

• Domains
• IPs
• Infrastructure

That’s why we build:

• Scheduled IOC updates
• Confidence scoring
• Expiration handling
• Automated enforcement updates

Security systems that rely on static rules become obsolete fast.

---

Why this architecture scales (and survives audits)

• Modular
• Vendor-neutral
• Open-source friendly
• Easy to extend
• Clear responsibility boundaries

This system works for:

• SMEs
• Factories
• Enterprises
• Managed security services (MDR)

---

Why clients hire us to build this

Because we don’t:

• Install tools and disappear
• Sell dashboards without response
• Hide logic inside black boxes

We design systems:

• With clear intent
• With documented logic
• With measurable outcomes

Security is not about tools.
It’s about decisions, timing, and responsibility.

---

If you are planning a similar system

If you’re thinking:

• “We want better security visibility”
• “We need real incident response, not alerts”
• “We want something we can understand and control”

Then this architecture is a strong foundation.

If you want it designed and implemented correctly,
with real operational experience behind it—

Let’s talk.

---

Final thought

Good security systems don’t feel complicated.
They feel calm, predictable, and under control.

That’s the system we build.