はじめに

現代の Security Operations Center（SOC）において、「迅速な対応」と「一貫性のある判断」は非常に重要です。アナリストによる手動トリアージは時間がかかり、判断のばらつきも発生します。

そこで必要になるのが Automated Decision Logic（自動意思決定ロジック） です。構造化されたルールやスコアリングモデルに基づき、セキュリティアラートを自動評価し、次のアクションを決定します。

本記事では、以下の構成を前提に解説します：

• Shuffle（SOAR 自動化プラットフォーム）
• Wazuh（SIEM）
• DFIR-IRIS（インシデント対応管理）
• PagerDuty（オンコール通知）
• 自社開発 SOC Integrator（Django ベース）

実践的な例と、実運用可能なアーキテクチャを紹介します。

---

Shuffle の主要コンポーネントを理解する

自動意思決定を設計する前に、Shuffle の構成要素を理解することが重要です。

1. Backend（コアエンジン）

Backend は自動化処理の中心です。

• Workflow の実行
• Trigger の受信
• Integration App の管理
• 実行ログの保存

Playbook のロジックはここで処理されます。

2. Frontend（Web UI）

以下を行う管理画面です。

• ドラッグ＆ドロップで Workflow 作成
• API キーや認証情報の設定
• 実行ログの確認
• ユーザーと権限管理

SOC 自動化のコントロールパネルといえます。

3. Apps（統合モジュール）

Apps はコンテナで動作するコネクタで、外部システムと連携します。

例：

• Wazuh（SIEM）
• DFIR-IRIS（ケース管理）
• PagerDuty（通知）
• VirusTotal などの脅威インテリジェンス

各 App は API を呼び出し、構造化データを Workflow に返します。

4. Workflows（自動化フロー）

Workflow は以下で構成されます。

• Trigger（Webhook、スケジュール、手動）
• Condition（条件分岐）
• Action（エンリッチメント、ケース作成、通知など）

SOAR の意思決定ロジックはここに実装されます。

5. Orborus（App 実行エンジン）

コンテナ化された Apps を実行し、安全かつ分離された形で統合処理を行います。

Shuffle の全体フロー

Wazuh → Webhook → Shuffle Backend → Workflow → Apps 実行 → 外部システム

この構造を理解することで、より明確な自動化設計が可能になります。

---

Automated Decision Logic とは？

Automated Decision Logic とは、ルールまたはスコアリングに基づき、次の問いに答える仕組みです。

「このセキュリティアラートに対して、どのような対応を行うべきか？」

自動で以下を判断します：

• Ignore（無視）
• Enrichment のみ実施
• Incident Case 作成
• Case 作成 + オンコール通知
• 既存 Case へ追加

目的は迅速かつ標準化された対応の実現です。

---

例：不審な VPN ログイン

Wazuh からのアラート

• Country: Russia
• User: admin
• Severity: 12
• Source IP: 185.199.108.153

このアラートに対し、自動意思決定を行います。

---

第1段階：基本的な IF / ELSE ルール

IF

• country != "Thailand"
• AND severity >= 10

THEN

• IP の脅威情報を取得
• IRIS に Case 作成
• PagerDuty 通知

ELSE

• ログ記録のみ

初期段階の自動化に適しています。

---

第2段階：リスクスコアリング（推奨）

単純な IF では柔軟性が不足します。スコアリング方式を推奨します。

例：リスクモデル

要素	スコア
国内以外からのログイン	+40
IP が高リスク	+30
新規ユーザー	+25
異常時間帯	+15
MFA 未使用	+20

判定基準

• 70点以上 → Critical（Case 作成 + 通知）
• 40–69点 → Medium（Case のみ）
• 40点未満 → ログのみ

柔軟で説明可能な判断が可能です。

---

第3段階：状態管理型意思決定（相関分析 + 重複排除）

高度な SOC では、重複 Case を防ぐ必要があります。

例：

「同一 IP が30分以内に再発した場合、新規 Case は作成せず既存 Case に追加」

実装方法：

• Django DB に相関データ保存
• Redis に短期状態保持
• Case 作成前に IRIS を検索

Alert Fatigue の大幅削減につながります。

---

推奨アーキテクチャ（責務分離）

SOC Integrator（Django）

• リスクスコア計算
• 相関分析
• 重複排除
• Decision 出力

Shuffle

• Workflow 実行
• 各種 Integration 呼び出し
• Trigger 管理

フロー

Wazuh → Shuffle Webhook → SOC Integrator /decide → Decision 戻り値 → Shuffle 実行

Sequence Diagram（システム連携）

sequenceDiagram
    autonumber

    participant WZ as Wazuh
    participant SH as Shuffle
    participant SI as SOC Integrator
    participant TI as Threat Intel
    participant IR as DFIR-IRIS
    participant PD as PagerDuty

    WZ->>SH: アラート送信
    SH->>SI: /decide 呼び出し
    SI-->>SH: Decision 応答

    alt ignore
        SH-->>WZ: ignore タグ付与
    else enrich_only
        SH->>TI: 情報照会
        TI-->>SH: 結果
    else create_case
        SH->>IR: Case 作成
    else create_case_and_page
        SH->>IR: Case 作成
        SH->>PD: 通知送信
    end

ビジネスロジックはコードで管理し、自動化は SOAR に任せる設計です。

---

Decision API 例

例1：Case 作成 + 通知

{
"decision": "create_case_and_page",
"severity": "critical",
"risk_score": 85
}

例2：既存 Case へ追加

{
"decision": "append_case",
"case_id": 1234
}

例3：無視

{
"decision": "ignore"
}

Shuffle は decision フィールドに基づき分岐します。

---

なぜこの構成はエンタープライズ向けか？

• ロジックをバージョン管理可能
• リスクモデルのテストが可能
• 継続的なチューニングが容易
• 誤検知削減
• 監査証跡の明確化

サービスレベルにも対応：

C1 – 基本自動化
C2 – スコアリング + エンリッチメント
C3 – 相関分析 + 適応型意思決定

---

まとめ

Automated Decision System は単なる高速化ではなく、「安定性」と「再現性」を重視します。

シンプルなルールから開始し、スコアリングを導入し、最終的に相関分析と状態管理を追加する。

これが Reactive SOC から Intelligent SOC への進化プロセスです。

---

SOC 自動化や SOC Integrator の導入を検討されている企業にとって、本記事は実運用可能な設計指針となります。