Wazuh + オープンソースで構築する軽量SOC：実践ガイド（2026年版）

なぜ多くのセキュリティプログラムは始まる前に失敗するのか

「SOCが必要だ」。この一言は、セキュリティインシデントを経験した直後、監査に不合格になった後、あるいは初めてCISOを採用した組織で必ず聞こえてきます。その後に続くのは、商用SIEMベンダーのプレゼン、数千万円規模の見積もり、そして12ヶ月の導入スケジュールです。

ほとんどのチームはそのミーティングから出て、何もしません。

皮肉なのは、実際に機能するSOC——本物の脅威を検知し、不審な挙動をアラートし、インシデントをトリアージし、ISO 27001やISMSの多くの要件を満たせる——が、オープンソースツールだけでクラウドVM数台分のコストで構築できるという事実です。トレードオフは予算ではなく、時間と専門知識です。

このガイドでは、Wazuhを中核とした軽量SOCスタックの構築方法、追加すべき補完ツールとその理由、実際の脅威に対応するdetectionルールの書き方、そして小規模なセキュリティチームが燃え尽きずに運用する方法を解説します。

ISMSとISO 27001：日本企業にとってSOCが必要な理由

技術的な詳細に入る前に、なぜSOCが単なる選択肢ではなく、多くの日本企業にとって事実上の必須要件になっているかを整理します。

ISMS（情報セキュリティマネジメントシステム）とISO/IEC 27001 は、日本のエンタープライズ市場において事実上の標準となっています。取引先や調達部門からISMS認証を求められるケースは増え続けており、特に金融、医療、政府系、製造業のサプライチェーンでは認証の有無が商談の条件になっています。

ISO 27001の附属書A（管理策）のうち、SOCが直接カバーする項目は以下の通りです：

A.8.15（ログ取得）： 活動、例外、障害、その他のセキュリティ関連イベントを記録するログを生成、保護、分析すること
A.8.16（監視活動）： 異常な挙動やセキュリティインシデントの兆候を検知するためにネットワーク、システム、アプリケーションを監視すること
A.5.25（セキュリティインシデントの評価と決定）： 情報セキュリティイベントを評価し、インシデントとして分類するかどうかを決定すること
A.5.26（情報セキュリティインシデントへの対応）： 文書化された手順に従ってインシデントに対応すること

このガイドで構築するSOCは、これらの管理策すべてに対応する技術的証拠を生成します。監査人が「ログ監視の仕組みを見せてください」と言ったとき、ダッシュボード、ルール、ケース管理の記録がその回答になります。

個人情報保護法（改正個人情報保護法） の観点からも、漏洩等が発生した場合の個人情報保護委員会への報告義務（原則72時間以内の速報）があり、SOCはその検知と証拠保全の基盤となります。

軽量SOCが実現すべきこと

ツールを選ぶ前に、最低限必要な機能セットを定義します。軽量SOCは4つのことをカバーする必要があります。

可視性（Visibility）： エンドポイント、ネットワーク、クラウドワークロードで何が起きているかを把握する。あらゆる場所からのログを、検索・クエリ可能な形式に正規化する。

検知（Detection）： 問題が発生していることを示すイベントを特定する。不正アクセス、横断的侵害（ラテラルムーブメント）、マルウェア実行、データ窃取、設定ミス。

アラートとトリアージ（Alerting & Triage）： 適切なアラートを適切な担当者に、判断するための十分なコンテキストとともに届ける。ノイズの洪水でも、沈黙でもなく。

対応（Response）： アクションを起こす。IPをブロックする。ホストを隔離する。ケースを起票する。何が起きたかを記録する。

構築するスタック

レイヤー	ツール	役割
SIEM / XDR	Wazuh	ログ収集、ルールベース検知、FIM、脆弱性スキャン、アクティブレスポンス
ネットワークIDS	Suricata	ネットワークレベルの脅威検知、プロトコル解析
脅威インテリジェンス	MISP	IOC管理、脅威情報共有
インシデントレスポンス	DFIR-IRIS	ケース管理、調査追跡、アナリストワークフロー
自動化（任意）	Shuffle	SOAR-lite、Webhookベースのプレイブック

コンポーネント1：Wazuh — すべての中核

Wazuhはこのスタックの背骨です。SIEM、XDR、ホストベース侵入検知システム（HIDS）、ファイル整合性監視（FIM）、脆弱性スキャナー、アクティブレスポンスエンジンとして同時に機能します。無料かつオープンソースであることが、リソースに制約のあるSOCの明確な中核選択理由となっています。

アーキテクチャ概要

flowchart TD
    subgraph Endpoints
        A1["Windows Agent"]
        A2["Linux Agent"]
        A3["macOS Agent"]
    end

    subgraph Network
        SUR["Suricata (IDS)\nวิเคราะห์ network traffic"]
        FW["Firewall / FortiGate / VPN\nSyslog forwarding"]
    end

    subgraph Wazuh Core
        MGR["Wazuh Manager\nRule engine · Decoder pipeline · Active response"]
        IDX["Wazuh Indexer\n(OpenSearch)"]
        DASH["Wazuh Dashboard\nAlerts · FIM · Vuln · Compliance · PDPA"]
    end

    subgraph Enrichment & Response
        MISP["MISP\nThreat intelligence · IOC feeds"]
        IRIS["DFIR-IRIS\nCase management · Investigation"]
        SHF["Shuffle (ทางเลือก)\nSOAR playbooks · Auto-triage"]
    end

    A1 -->|"Encrypted log stream"| MGR
    A2 -->|"Encrypted log stream"| MGR
    A3 -->|"Encrypted log stream"| MGR
    SUR -->|"EVE JSON via syslog"| MGR
    FW -->|"Syslog (UDP/TCP 514)"| MGR

    MGR -->|"Indexed alerts"| IDX
    IDX --> DASH

    MGR -->|"IOC lookup"| MISP
    MGR -->|"Alert webhook"| SHF
    SHF -->|"Create case"| IRIS
    MGR -->|"Direct integration"| IRIS

Wazuhが初期状態で提供するもの

Wazuhをデプロイして最初のエージェントを接続すると、即座に利用できるものがあります：

ログ収集と正規化： Windows Event Log、Linux syslog、macOS Unified Log、数十種類のアプリケーションログ形式に対応
MITRE ATT&CKマッピング： Wazuhのデフォルトルールセットは数千のイベントをATT&CTの戦術・手法にマッピング済み。アラートが監査人や脅威インテリジェンスチームの共通言語を話す
ファイル整合性監視（FIM）： 監視対象パスのファイル、ディレクトリ、パーミッション、所有者の変更をリアルタイムでアラート
セキュリティ構成評価（SCA）： エンドポイント全体のCISベンチマーク自動スキャン。合否結果がダッシュボードで確認可能
脆弱性検知： エージェントのソフトウェアインベントリを継続更新のCVEデータベースと照合
アクティブレスポンス： ルールが発火したときの自動アクション。firewalldやiptablesでのIPブロック、プロセスの強制終了、カスタムスクリプト実行など

Wazuhのデプロイ

小規模な環境への最速の導入経路は、専用のUbuntu 22.04サーバーへのオールインワンインストールスクリプトです。

小規模デプロイメントの最小スペック（～50エージェント）：

4 vCPU、8 GB RAM、100 GB SSD
Ubuntu 22.04 LTS
開放ポート：1514/UDP（エージェント通信）、1515/TCP（エージェント登録）、443/TCP（ダッシュボード）

# Wazuhインストールアシスタントをダウンロードして実行
curl -sO https://packages.wazuh.com/4.x/wazuh-install.sh
bash wazuh-install.sh -a

このコマンド一本で、Wazuh Manager、Indexer（OpenSearch）、Dashboardが同一ホストにインストールされます。50エージェントを超えるプロダクション環境では、この3コンポーネントを別々のサーバーに分離することを推奨します。

インストール後、管理者パスワードを取得します：

tar -O -xvf wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txt

その後、https://サーバーIPアドレスにアクセスし、adminと取得したパスワードでログインします。

エージェントの登録

Linux：

curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --dearmor \
  -o /usr/share/keyrings/wazuh.gpg
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] \
  https://packages.wazuh.com/4.x/apt/ stable main" \
  | tee /etc/apt/sources.list.d/wazuh.list
apt update && apt install -y wazuh-agent
WAZUH_MANAGER="マネージャーのIPアドレス" WAZUH_AGENT_NAME="web-01" \
  dpkg-reconfigure wazuh-agent
systemctl enable --now wazuh-agent

Windows（PowerShell）：

Invoke-WebRequest -Uri https://packages.wazuh.com/4.x/windows/wazuh-agent-4.x.x-1.msi `
  -OutFile wazuh-agent.msi
msiexec /i wazuh-agent.msi /q `
  WAZUH_MANAGER="マネージャーのIPアドレス" `
  WAZUH_AGENT_NAME="workstation-01"
NET START WazuhSvc

コンポーネント2：実際に機能する検知ルールの作成

Wazuhのデフォルトルールセットは優れた出発点ですが、実際には自社環境にとって重要な脅威を検知するカスタムルールを書き、不要なノイズを抑制する必要があります。

Wazuhルールの仕組み

Wazuhはすべてのログイベントをまずデコーダーパイプラインで処理し（生のログテキストから構造化フィールドを抽出）、その後デコードされたイベントをルールツリーで評価します。カスタムルールは/var/ossec/etc/rules/local_rules.xmlに配置します。

ルールの深刻度レベルは0から15。1〜3が情報、4〜6が低、7〜11が中、12〜15が高/クリティカルです。デフォルト設定ではレベル7以上のみがアラートを生成します。

例1：SSHブルートフォース検知

同一ソースIPから60秒以内に5回以上のSSH認証失敗が発生した場合に発火するルールです：

<!-- /var/ossec/etc/rules/local_rules.xml -->
<group name="sshd,authentication_failed,">

  <rule id="100001" level="10" frequency="5" timeframe="60">
    <if_matched_sid>5716</if_matched_sid>
    <same_source_ip />
    <description>SSHブルートフォース：60秒以内に5回以上の失敗 送信元: $(srcip)</description>
    <mitre>
      <id>T1110.001</id>
    </mitre>
    <group>attack,brute_force,</group>
  </rule>

</group>

例2：不審なPowerShell実行の検知

一般的な難読化パターン（Base64エンコードコマンド、ダウンロードクレードル、実行ポリシー回避）を含むPowerShell起動時に発火するルールです：

<rule id="100010" level="12">
  <if_group>windows,sysmon,</if_group>
  <field name="win.eventdata.commandLine" \
    type="pcre2">(?i)(FromBase64String|EncodedCommand|DownloadString|DownloadFile|bypass|hidden|WebClient)</field>
  <description>不審なPowerShell実行：難読化またはダウンロードクレードルを検知</description>
  <mitre>
    <id>T1059.001</id>
  </mitre>
  <group>attack,execution,powershell,</group>
</rule>

注意： このルールはWindowsエンドポイントへのSysmonインストールと、Wazuh SysmonルールセットのロードをWazuh Managerで有効化する必要があります。最大のカバレッジのためにSwiftOnSecurityの設定でSysmonをインストールしてください。

例3：CDBリストを使ったIOCマッチング

WazuhはConstant Database（CDB）リスト——ルール内で参照できる高速ルックアップのキーバリューストア——をサポートしています。このパターンにより、既知の悪意あるIP、ドメイン、ハッシュのリストとログイベントを照合できます：

# IOCリストの作成・更新
echo "185.220.101.45:" >> /var/ossec/etc/lists/malicious-ips
echo "194.165.16.11:" >> /var/ossec/etc/lists/malicious-ips

<rule id="100020" level="13">
  <if_group>firewall,</if_group>
  <list field="srcip" lookup="match_key">etc/lists/malicious-ips</list>
  <description>既知の悪意あるIPからの接続：$(srcip)</description>
  <mitre>
    <id>T1071</id>
  </mitre>
  <group>attack,threat_intel,</group>
</rule>

ルールのチューニング：誤検知の抑制

新しいWazuhデプロイメントは最初の1週間、アラートが溢れます。そのほとんどは誤検知です。<overwrite>ルールで深刻度を下げるか、<list>ベースのホワイトリストで抑制します：

<!-- 既知の監視ユーザーからの失敗ログインアラートを抑制 -->
<rule id="100030" level="0" overwrite="yes">
  <if_sid>5716</if_sid>
  <user>monitoring-svc</user>
  <description>抑制：監視サービスアカウントからの想定内の失敗ログイン</description>
</rule>

重要な規律：ルールクラス全体を抑制しないこと。具体的かつ十分に理解された条件のみを抑制します。すべての抑制をビジネス上の根拠とともに記録し、四半期ごとに見直します。これはISO 27001の証拠管理の観点からも重要です。

コンポーネント3：ネットワーク可視性のためのSuricata

Wazuhエージェントは優れたエンドポイント可視性を提供します。しかし、ラテラルムーブメント、C2（コマンド＆コントロール）トラフィック、データ窃取はしばしばエンドポイントログに痕跡を残さないネットワーク上の通信として現れます。Suricataはこのギャップを埋めます。

SuricataはSnortルール互換のシグネチャベース検知エンジン、プロトコルアナライザー、ファイル抽出エンジンを使ってリアルタイムでトラフィックを検査する高性能なネットワークIDS/IPSです。EVE JSON形式でログを出力し、WazuhはこれをネイティブにIngestできます。

Suricataのインストール

# Ubuntu 22.04
add-apt-repository ppa:oisf/suricata-stable -y
apt update && apt install -y suricata

# 最新のEmerging Threatsルールセットをダウンロード
suricata-update

SuricataのWazuh連携設定

/etc/suricata/suricata.yamlを編集して監視インターフェイスとEVE JSON出力を有効化します：

af-packet:
  - interface: eth0

outputs:
  - eve-log:
      enabled: yes
      filetype: regular
      filename: /var/log/suricata/eve.json
      types:
        - alert
        - http
        - dns
        - tls
        - flow

次に、Wazuh ManagerでEVEログのIngestを設定します。ossec.confに追記：

<localfile>
  <log_format>json</log_format>
  <location>/var/log/suricata/eve.json</location>
</localfile>

WazuhにはSuricata EVE JSON用の組み込みデコーダーとルールが含まれており、Ingest直後からMITRE ATT&CKマッピング付きのアラートがダッシュボードに表示されます。

コンポーネント4：脅威インテリジェンスのためのMISP

既知の悪意あるIPやドメインにマッチするdetectionルールは、一般的な「異常な接続」アラートより桁違いに有用です。MISP（Malware Information Sharing Platform）はIOC、脅威アクタープロファイル、マルウェアサンプル、インシデント情報を管理・共有するオープンソース標準です。

軽量SOCにおいてMISPは2つの機能を担います：アナリストがIOCをキュレーションするデータベースと、WazuhがリアルタイムマッチングのためにCDBリストを更新するフィードです。

MISPの起動

git clone https://github.com/MISP/misp-docker
cd misp-docker
cp template.env .env
# .envを編集：MISP_BASEURL、管理者メール、パスワードを設定
docker compose up -d

無料IOCフィードの接続

設定 → フィードから有効化を推奨する無料フィード：

CIRCL OSINTフィード： ルクセンブルクのnational CERTによる汎用IOC
Abuse.ch URLhaus： 活動中のマルウェア配布URL
Abuse.ch Feodo Tracker： ボットネットC2 IP（Emotet、TrickBot、Qakbot）
AlienVault OTX： コミュニティ提供のIOC（無料APIキーが必要）
JPCERTの公開フィード： 日本の脅威インテリジェンス文脈では、JPCERT/CCが公開するIOCやインシデント情報も積極的に参照することを推奨します

IOC → Wazuh CDB自動同期

#!/usr/bin/env python3
# misp_to_cdb.py — cronで30分ごとに実行
import requests, json, os

MISP_URL = "https://your-misp-instance"
MISP_KEY = "YOUR_API_KEY"
CDB_PATH = "/var/ossec/etc/lists/malicious-ips"

headers = {"Authorization": MISP_KEY, "Accept": "application/json",
           "Content-Type": "application/json"}

payload = {"returnFormat": "json", "type": "ip-dst",
           "tags": ["tlp:white", "tlp:green"], "limit": 5000}

r = requests.post(f"{MISP_URL}/attributes/restSearch",
                  headers=headers, json=payload, verify=False)
attrs = r.json().get("response", {}).get("Attribute", [])

with open(CDB_PATH, "w") as f:
    for attr in attrs:
        f.write(f"{attr['value']}:\n")

os.system("/var/ossec/bin/wazuh-logtest -U")  # CDBリストを再読み込み
print(f"{len(attrs)}件のIOCを{CDB_PATH}に同期しました")

コンポーネント5：ケース管理のためのDFIR-IRIS

Wazuhはアラートを生成します。MISPはコンテキストを提供します。しかしどちらのツールも「誰がこれを調査しているか、何を発見したか、現在の状況は何か」という問いに答えません。それがDFIR-IRISの役割です。

DFIR-IRISはオープンソースの協調インシデントレスポンスプラットフォームです。タイムライン、証拠追跡、資産台帳、IOC相関、タスク割り当て、MISPおよびWazuhとの組み込み統合を備えたケース管理システムを提供します。Wazuhのアラートがインシデントにエスカレートすると、IRISでケースが起票され、アナリストはそこで調査を進めます。

ISO 27001のA.5.26（インシデント対応）の観点から特に重要なのは、IRISが調査プロセス全体の監査証跡を自動的に生成することです。「このインシデントにどのように対応しましたか」という監査人の問いに対して、IRISのケース記録がそのまま回答になります。

DFIR-IRISの起動

git clone https://github.com/dfir-iris/iris-web
cd iris-web
cp .env.model .env
# .envを編集：IRIS_ADM_PASSWORDとIRIS_SECRET_KEYを設定
docker compose up -d

http://localhost:4433でアクセスできます。

WazuhアラートをIRISケースに連携

#!/usr/bin/env python3
# iris_create_case.py — 高深刻度アラートでWazuhアクティブレスポンスから呼び出し
import sys, json, requests

IRIS_URL = "http://your-iris-instance:4433"
IRIS_API_KEY = "YOUR_IRIS_API_KEY"

alert = json.loads(sys.stdin.read())
rule_desc = alert.get("rule", {}).get("description", "不明")
agent_name = alert.get("agent", {}).get("name", "不明")
level = alert.get("rule", {}).get("level", 0)

if level < 12:
    sys.exit(0)  # 高/クリティカルアラートのみ自動ケース作成

payload = {
    "case_name": f"[AUTO] {rule_desc}",
    "case_description": json.dumps(alert, indent=2, ensure_ascii=False),
    "case_customer": 1,
    "case_soc_id": alert.get("id", ""),
    "custom_attributes": {}
}

r = requests.post(f"{IRIS_URL}/manage/cases/add",
                  headers={"Authorization": f"Bearer {IRIS_API_KEY}"},
                  json=payload)
print(r.json())

コンポーネント6：軽量自動化のためのShuffle

Shuffleはビジュアルワークフロービルダーを使ってWebhookとAPIでセキュリティツールを接続するオープンソースSOARプラットフォームです。軽量SOCにおいては接着剤レイヤーとして機能し、Wazuhのアラートwebhookを受け取り、MISPでエンリッチし、IRISケースを作成し、SlackやメールでアナリストにNotifyします。

Shuffleのデプロイ

git clone https://github.com/Shuffle/Shuffle
cd Shuffle
docker compose up -d

http://localhost:3001でアクセスできます。

基本的なトリアージワークフロー

flowchart LR
    W["Wazuh\n高深刻度アラート\n(level ≥ 12)"] -->|"Webhook POST"| SHF

    subgraph Shuffleワークフロー
        SHF["トリガー\nアラートJSONを解析"] --> ENR["エンリッチ\nMISP APIでsrcipを照合"]
        ENR --> DEC{"IOC\nマッチ?"}
        DEC -->|"あり"| HIGH["深刻度 = クリティカルに設定\nMISPコンテキストを追加"]
        DEC -->|"なし"| MED["深刻度 = HIGHのまま"]
        HIGH --> CASE["IRIS\nフルコンテキストでケース作成"]
        MED --> CASE
        CASE --> NOTIFY["アナリストへ通知\nSlack / メール / Teams"]
    end

Wazuh ManagerでShuffleとの接続を設定します。ossec.confに追記：

<integration>
  <n>shuffle</n>
  <hook_url>http://your-shuffle-instance:3001/api/v1/hooks/YOUR_HOOK_ID</hook_url>
  <level>12</level>
  <alert_format>json</alert_format>
</integration>

SOCの運用

ツールを稼働させることは容易な部分です。SOCを効果的に運用するには、インフラではなくプロセスが必要です。

アラートトリアージSLA

開始前に対応時間の目標を定義します。シンプルな3段階モデル：

深刻度	Wazuhレベル	目標対応時間	例
クリティカル	15	15分	ランサムウェアIOCマッチ、進行中のデータ窃取
高	12〜14	2時間	ブルートフォース成功、権限昇格
中	7〜11	24時間	繰り返しの失敗ログイン、不審なプロセス
低	4〜6	週次レビュー	ポリシー違反、情報提供

アナリストの日常業務

朝のトリアージ（30分）： Wazuhダッシュボードで夜間の高/クリティカルアラートを確認。各アラートについて：真陽性か偽陽性か？真陽性はIRISでケースを起票。偽陽性は根拠を記録した上で抑制ルールを追加。
IOCスイープ（15分）： 夜間に同期された新しいMISPフィードを確認。Wazuhの新しいIOCマッチを確認。必要に応じてCDBリストを更新。
オープンケースレビュー（20分）： IRISのアクティブケースを確認。調査ノートを更新し、タスクを割り当て、エスカレートまたはクローズ。
ルールメンテナンス（随時）： トリアージで特定された偽陽性があれば、その場で即座に抑制ルールを書く。ノイズを蓄積させない。

重要なメトリクス

SOCが改善しているかを把握するために週次で追跡します：

平均検知時間（MTTD）： イベント発生からアラート生成までの平均時間。上昇している場合はログパイプラインに遅延の問題があります。
平均対応時間（MTTR）： アラートからケースクローズまでの平均時間。上昇している場合はトリアージ効率の問題があります。
誤検知率： 偽陽性としてクローズされたアラートの割合。目標は20%未満。
カバレッジギャップ： MITRE ATT&CK Navigatorを月次でレビュー。どの戦術・手法にdetectionルールがないか？最も関連性の高いギャップを優先的に埋める。

アラート疲労への対処

アラート疲労はSOCプログラムの静かな破壊者です。アナリストが1日に何百もの低品質アラートに直面すると、本物の脅威も含めてすべてを無視し始めます。

防御策：

最初の1週間は積極的にチューニングする： 最初の1週間はほぼ偽陽性の抑制だけに費やします。静かで高精度のアラートストリームは、包括的だがノイジーなストリームより価値があります。
アラート量の目標を設定する： 1〜2名のアナリストが現実的にトリアージできるのは1日20〜50件の有意義なアラートです。500件生成しているなら、それはキャパシティの問題ではなくチューニングの問題です。
レベル閾値を活用する： リアルタイムアラートはレベル7以上のみ。レベル4〜6は週次レビューのキューへ。
抑制ルールを定期的にレビューする： 3ヶ月前には有効だった抑制が、今は本物の攻撃ベクターを隠している可能性があります。四半期ごとにすべての抑制ルールを監査します。

このスタックがカバーしないこと — 拡張の方向性

このガイドで構築する軽量SOCは、中小規模の組織が直面する脅威の大部分を処理できます。ただし、把握しておくべきギャップがあります。

クラウドネイティブワークロード： インフラがAWS、GCP、Azureに大きく依存している場合、WazuhのクラウドモジュールIntegrationを追加します。WazuhはCloudTrail、AWS GuardDuty、Azure Activity Logs、GCP Audit Logsをネイティブにingestできます。

コンテナとKubernetes： WazuhエージェントはKubernetesクラスタにDaemonSetとして展開できます。より深いコンテナランタイム可視性のためには、FalcoをWazuhと組み合わせることを検討してください。

ログ保持とコンプライアンス： Wazuhのデフォルト保持期間は90日です。ISO 27001（A.8.15）および改正個人情報保護法の実務では、12ヶ月以上の保持が推奨されます。OpenSearchのインデックスライフサイクルポリシーで保持期間を延長するか、コールドログをオブジェクトストレージ（S3、GCS）にアーカイブします。

UEBA（ユーザーエンティティ挙動分析）： Wazuhのルールエンジンはシグネチャベース検知に優れていますが、異常ベース検知のネイティブサポートは限定的です。Wazuhがすでに使用している同じOpenSearchインスタンスで動作するOpenSearch Anomaly Detectionプラグインの追加を検討してください。

SimplicoのSOC構築アプローチ

Simplicoでは、商用SIEMのコストと複雑さなしに実用的なセキュリティ監視を必要とするクライアントのために、このスタック（またはその変種）を展開しています。

初期デプロイとハードニング： オールインワンまたは分散型Wazuhインストール、エンドポイントとサーバーへのエージェント展開、ネットワーク境界へのSuricata配置、初期フィード設定済みMISP、DFIR-IRISセットアップ。

Detection Engineering： クライアント固有の環境向けカスタムデコーダーとルール開発。ファイアウォールベンダーのログ形式、アプリケーションスタック、ERPとeコマースプラットフォームまで。ルールをインストールするだけでなく、書きます。

ISMSギャップ分析との連携： 既存のISMS管理策とこのSOCスタックのカバレッジを対応させたマッピングドキュメントを作成します。「技術的対策として何を実施しているか」を監査人に説明する際の根拠資料になります。

チューニングスプリント： デプロイ後の最初の2週間は集中的なチューニング作業です。すべての偽陽性を追跡し、抑制ルールを書き、アラート量を管理可能なレベルまで削減してからクライアントチームに引き渡します。

ランブック文書化： SOCの品質はそれを運用する人間によって決まります。最も一般的なアラートタイプ向けのアナリストランブックを納品します。何を確認するか、どうトリアージするか、いつエスカレートするか、どうクローズするか。

自社スタックと要件に合ったアプローチを検討されたい方は、Simplicoにお問い合わせください →

まとめ

オープンソースツールで軽量SOCを構築することは、完全に実現可能です。コンポーネントはすでに存在し、きれいに統合でき、小規模組織にとってのインフラコストは月額数千円単位であり、数千万円ではありません。

投資は時間と専門知識です。Wazuhはインストールに半日かかり、適切にチューニングするのに1ヶ月かかります。MISPは継続的なフィードのキュレーションが必要です。IRISはそれを実際に使うアナリストが必要です。ツールは自分では動きません。

しかし、その投資をする組織には、商用ソリューションに匹敵する検知カバレッジを持つセキュリティ監視能力、すべてのアラートを生成するルールロジックへの完全な可視性、そしてロックされた商用SIEMが決して許さない方法で拡張・カスタマイズできる柔軟性が手に入ります。

主要な判断は難しくありません。

まずWazuhのみで始める。他のツールを追加する前にチューニングを完了させる。
Suricataは早い段階で追加する。ネットワーク可視性はエンドポイントエージェントが見逃すものを捕捉する。
MISPはそれをキュレーションできる担当者がいるときに追加する。誰もメンテナンスしないIOCデータベースはないよりも悪い。
IRISはケース管理が必要なほどのアラート量になったときに追加する。初日には追加しない。
Shuffleはトリアージワークフローが安定して一部を自動化できるときに追加する。

段階的に構築する。継続的にチューニングする。すべてを文書化する。

Simplicoはバンコクを拠点とするソフトウェアエンジニアリング＆プロダクトスタジオです。AI/RAGアプリケーション、セキュリティエンジニアリング、eコマース統合、ERPとのシステム連携を専門とし、タイ・日本・東南アジア市場向けのプロダクト開発を手がけています。詳しくは simplico.net をご覧ください。