小規模言語モデル(SLM)でWazuhログとファイアウォールSyslogからサイバー攻撃を検知する

セキュリティオペレーションセンター(SOC)は日々大量のアラートに埋もれています。数百台のエンドポイントでWazuhを運用し、さらにFortiGateなどのファイアウォールからSyslogを受信している中規模企業では、1日に数万件のイベントが容易に発生します。従来のルールベースの相関分析は既知のパターンには強い一方、ロングテールの脅威には弱いという課題があります。個々には無関係に見えるが意味的には関連するアラートの連続、じわじわと進行する偵察活動、あるいは人間のアナリストでなければ気づけない文脈などです。

ここで小規模言語モデル(SLM)——巨大なフロンティアモデルではなく、オンプレミスで動作する70億〜140億パラメータ規模のコンパクトなモデル——がパイプラインに加わる意義が生まれます。WazuhやSIEMの検知エンジンを置き換えるのではなく、それらの後段に配置し、構造化されたアラートのノイズをアナリストがすぐに読める分析結果へと変換する役割を担います。

なぜLLMではなくSLMなのか

SOCのワークロードでは、大規模なホスト型モデルの採用を妨げる制約が3つあります。

• データ所在地(レジデンシー)の要件 — 規制業種のエンタープライズ顧客は、生のセキュリティログをネットワーク外に出すことをほとんど許可しません。これによりAPI型のフロンティアモデルの多くは選択肢から外れます。
• 大量処理時のレイテンシとコスト — 1日に数千件のアラートクラスタをスコアリングするには、呼び出しごとに安価で高速なモデルが必要であり、フロンティア水準の従量課金モデルでは割に合いません。
• タスク自体がフロンティア級の推論を必要としない — アラート群をMITRE ATT&CKの手法に分類したり、2文程度のインシデント要約を書いたりする作業は、適切にプロンプト設計された70億〜140億パラメータモデルで十分対応できます。

Llama 3.1 8B、Qwen2.5 14B、Phi-4といったモデルをvLLMやOllamaでローカル運用すれば、ちょうど良いバランスが得られます。構造化されたJSON出力に十分対応できる指示追従性を持ちながら、顧客環境内の単一GPUでも動作するほどコンパクトです。

パイプライン内でのSLMの位置づけ

避けるべき失敗は、生ログを直接モデルに入力することです。WazuhとファイアウォールはすでにNormalization(正規化)を行っているので、それを活用しましょう。SLMの仕事は集約(aggregation)の「後」から始まるべきで、その前ではありません。

flowchart TD
    A["Wazuhエージェント + FortiGate Syslog"] --> B["Wazuhマネージャー: ルール照合と正規化"]
    B --> C["OpenSearch: 送信元IP/時間窓ごとにアラートを集約"]
    C --> D["SLMスコアリングサービス: 分類・要約・MITRE ATT&CKへのマッピング"]
    D --> E["DFIR-IRIS: 補強された情報でケース作成"]
    E --> F["Shuffle SOAR: SLMの判定に応じて分岐"]
    F --> G["PagerDuty: アナリストへのエスカレーション"]

Wazuhのアラートはすでに構造化されたJSONです——ルールID、深刻度レベル、エージェント、送信元/宛先IP、生ログ行が含まれています。モデルに届く前に、関連するアラートを短い時間窓(例えば5分間)で送信元IPやユーザーごとにまとめておきましょう。これによりSLMは大量のテキストを解析するのではなく、コンパクトなイベントの並びに対して推論を行うことになり、コスト削減と精度向上の両方につながります。

SLMが本当に得意なこと

ルールエンジンは正確ですが融通が利きません。「このログパターンが発生した」という判定は得意ですが、「一見何でもないイベントの並びが、進行中の攻撃のように見える」という判断は苦手です。このギャップこそ、SLMが価値を発揮する領域です。

• インシデント要約 — 関連する12件のWazuhアラートを、オンコールアナリストが5秒で読める平易な2文の要約に変換します。生ログをスクロールする必要がなくなります。
• 複数ログソースをまたいだパターン推論 — FortiGateの接続拒否の集中発生と、同じ送信元IPからのWazuh認証失敗の連続を関連付け、その組み合わせがパスワードスプレー攻撃やクレデンシャルスタッフィングに類似する理由を説明します。この種の推論は、事前にその組み合わせ専用のルールを誰かが書いていない限り、静的な相関ルールでは見逃されがちです。
• 誤検知(False Positive)の抑制 — アセットの重要度、既知のメンテナンス時間帯、想定される管理者の行動といった短い文脈情報に照らしてアラートをスコアリングし、DFIR-IRISでケースが作成される前にノイズを減らします。

自由文ではなく構造化出力を

モデルはSOARプラットフォームが正規表現で解析するような文章を返すべきではありません。厳密なJSONを返すようプロンプトを設計します。

{
  "severity": "high",
  "mitre_technique": "T1110.003 - Password Spraying",
  "summary": "17 failed logins across 4 accounts from a single external IP within 6 minutes, followed by one successful login.",
  "recommended_action": "disable_account_and_escalate",
  "confidence": 0.82
}

これにより、Shuffleはseverityとrecommended_actionフィールドに基づいて直接分岐処理を行えます。確信度が高く深刻度の高いケースはPagerDutyへ即座にエスカレーションし、確信度の低いケースはアナリストのレビュー待ちキューに回します。

精度よりもガードレールが重要

最も重要な設計判断は、モデルに「させないこと」を明確にすることです。SOCパイプラインにおけるSLMはあくまで助言役に徹するべきです——要約し、分類し、推奨はしますが、ケースを自動的にクローズしたり、システムを自動的に修復したりはしません。定義された深刻度のしきい値を超える案件については、常に人間によるレビューを介在させます。これは単なる慎重さの問題ではなく、顧客監査の際に見逃し(false negative)について説明責任を果たせるSOCプロセスかどうかを左右する分かれ目です。

ラベル付きデータがなくても始められる

多くの組織は「アラートクラスタ→正しい判定」というペアのクリーンなデータセットをファインチューニング用に持っていませんが、それで問題ありません。まずは強力なFew-shotプロンプティングから始めましょう——正しいMITREマッピングと深刻度が付与された数件のアラートクラスタの例を、組織固有のルール説明とともにシステムプロンプトに直接埋め込むことで、70億〜140億パラメータのモデルはすぐに実用的な精度に到達します。ファインチューニングは、アナリストが検証済みの実際のインシデントが数百件蓄積された段階で取り組む価値が出てきます。

その結果として実現するのは、Wazuhとファイアウォールがそれぞれもっとも得意とする迅速かつ決定論的な検知を担い続ける一方、SLMが従来は深夜2時に疲れ切ったアナリストが画面をにらみながら行っていた、より複雑で文脈依存性の高い推論の層を引き受けるSOCパイプラインです。