1. はじめに — なぜ「単一機器のログ」では不十分なのか #

セキュリティログ監視の現場では、「あるIPアドレスが怪しい」という判断を、たいてい個々の機器のログ単独で下しています。

• FWで多数のポートをスキャンしている → ブロック
• Webサーバーで脆弱性スキャンが来た → 警告
• VPN認証に何度も失敗している → アカウントロック

それぞれの機器が個別に判断する。これが普通の運用です。

しかし、実際の攻撃はもっと組織的で、層をまたいだシナリオで動いてくる。

たとえば、ある攻撃者が次の手順で侵入を試みているとします。

1. FW で偵察(ポートスキャン)を仕掛ける    ← L1 ネットワーク層
2. 公開している Web ポートに脆弱性スキャン  ← L4 アプリケーション層
3. SSH や VPN へブルートフォース           ← L3 認証層
4. 侵入後、内部ネットワークで横展開         ← L5 エンドポイント層

これを個別の機器が個別に検知しても、それぞれは「ちょっと怪しい単独の挙動」にしか見えません。FW担当者は「いつものスキャンか」、Webサーバー担当者は「いつものスキャナか」、VPN担当者は「またブルートフォース試行か」と判断して、それぞれ別々に対応する。

でも、この4つは同じ攻撃者の連続した行動です。一連のシナリオとして見れば、対応の優先度も、ブロック範囲も、警戒レベルも、まったく違ってきます。

BASTION の多層相関キャンペーン検知は、「複数機器の個別検知を、同一IPを軸に時間と層で重ね合わせる」仕組みです。本記事では、その設計思想と仕組みを、特許出願準備中につき非公開の数式部分を除いて解説します。

2. 「層」という概念 — ログを5つの観点で整理する #

BASTION は、ログを次の5つの「層」で整理します。

この層分けは、機械的な機器分類ではなく「攻撃の進行段階」に対応した分類になっています。L1で偵察、L2で経路探索、L3で認証突破、L4でアプリ脆弱性、L5で内部活動、というふうに、攻撃の進行は概ね層を昇っていきます。

「ある攻撃IPが複数の層で観測されている」という事実は、「攻撃が次の段階に進んでいる」という強い兆候です。

3. trace-registry — IPごとに層をまたいだ観測状況を集約する #

BASTION は、各機器のログを分析する過程で「このIPが、いつ、どの層で、何回観測されたか」を蓄積していきます。これを trace-registry と呼んでいます。

概念的にはこういう構造です(実値はサンプル)。

{
  "traces": {
    "203.0.113.42": {
      "layers": {
        "L1_network": {
          "first_seen": "2026-05-10T13:01:23+09:00",
          "last_seen":  "2026-05-10T13:42:11+09:00",
          "count": 47,
          "context": ["FW block: port_scan", "FW block: ssh_attempt"]
        },
        "L4_app": {
          "first_seen": "2026-05-10T13:35:08+09:00",
          "last_seen":  "2026-05-10T13:41:55+09:00",
          "count": 12,
          "context": ["webserver 404: vuln_scan", "webserver 403: forbidden_path"]
        }
      },
      "layer_count": 2,
      "total_count": 59
    }
  }
}

この構造のポイントは、「機器」ではなく「層」で集約していることです。同じFW製品が複数台あっても、それらは全て L1 ネットワーク層として扱われる。逆に、1台のサーバーがApache(L4)とauditd(L5)の両方のログを吐いていれば、それは2層分のシグナルとして扱われる。

そして、各層への観測が時間軸とともに記録されます。攻撃の進行が読み取れる粒度です。

4. コヒーレンス関数 — 「層をまたいだ協調性」を数値化する #

ここからが BASTION の核心部分です。

「あるIPが複数層で観測されている」という事実だけでは、まだキャンペーンとは言えません。たまたまL1とL4で観測されたが、両者は時間的に独立で関連のない挙動かもしれない。

そこで、「層間の協調性」を数値で評価する関数を定義します。これを コヒーレンス関数 C(i,t) と呼んでいます。

この関数は、概念的には次の4要素を組み合わせています。

1. 層間結合の強さ — どの層とどの層が同時に観測されたか
2. 時間的近接性 — 観測のタイミングがどれくらい近いか
3. 観測の振幅 — 各層での観測量(count)がどの程度か
4. デコヒーレンス(時間減衰) — 古い観測は影響を弱める

具体的な数式形(層間結合行列 K_ℓk、減衰率 γ、振幅項 Φ など)は特許出願準備中につき非公開ですが、概念としては:

C(i,t) = "層間結合 × 時間的近接性 × 観測振幅 × 時間減衰" の関数

という形をしています。

C(i,t) は0から1の範囲の値を取ります。値が大きいほど、そのIPの行動が「層を横断して協調している」可能性が高いと判断できます。

5. キャンペーン判定 — 閾値超過で自動行動 #

各IPについて C(i,t) を計算した結果、閾値を超えたものを「攻撃キャンペーン進行中」と判定します。

ここで重要な設計判断:

1. 判定は決定論的: コヒーレンス値が閾値を超えたかどうかで機械的に判定する。LLMの推論には頼らない
2. 閾値は環境ごとに調整可能: デフォルト値は社内実証で決めた値だが、顧客環境に合わせて微調整できる
3. 判定理由が説明可能: 「どの層でどれくらい観測されているからキャンペーンと判定した」を全て出力する

判定理由の出力例(値はマスク):

[COHERENCE_CAMPAIGN] ip=203.0.113.42  C=███
  L1_network: count=███ first=████ last=████
  L4_app:     count=███ first=████ last=████
  reason: layer_count=2 + coherence > threshold

判定根拠が明示されているので、運用者は AI のブラックボックス判断を信用するのではなく、観測事実そのものを確認して納得した上で自動防御を許可できます。

6. エンタングルメント — 「グループとしての協調」を検知する #

ここまでは「1つのIPが、複数層で協調しているか」を見てきました。これだけでも強力ですが、現実の攻撃はさらに巧妙です。

たとえばクラウドプロバイダ上の複数IPを使った組織的な脆弱性スキャン。各IP単独では低頻度すぎてキャンペーン判定の閾値を超えないけれども、サブネット全体やASN全体で集計すれば明らかに組織的な活動になっている、というケースです。

そこで BASTION は、「IPをグループ単位で評価する」機構を持っています。

• サブネット単位のグループ化 — 同一/24に属するIP群を1つの集合として扱う
• ASN単位のグループ化 — 同一ASNに属するIP群を1つの集合として扱う

それぞれのグループについて、グループコヒーレンス(GC) を計算します。GCは、各メンバーIPのコヒーレンス値を集約したものに、グループサイズによるブースト係数をかけた値です。

これも数式の具体形は非公開ですが、概念は単純です:

GC = Σ C(i,t) × boost(group_size)

3IPで構成されるグループより、10IPで構成されるグループの方が「組織的攻撃」の蓋然性が高いので、boost が効きます。

この機構をエンタングルメント(もつれ)検知と呼んでいます。これも量子物理の用語からの借用で、「個別では小さな信号でも、グループとして見れば強い意味を持つ」という現象を数学的にモデル化しています。

7. 実運用での検出例(匿名化) #

社内本番環境で、エンタングルメント検知が捕捉したグループの例(2026年5月時点)を、IP/組織名を伏せて紹介します。

[ENTANGLEMENT_CAMPAIGN] type=asn group=AS█████  size=17  GC=███
  Member IPs: ████.██.██.███,  ████.███.██.██,  ███.███.███.███, ... (17件)
  Observed layers: L1_network (FW block), L4_app (vuln scan)
  Time window: 24 hours
  Action: All 17 IPs auto-blocked across boundary FW + DMZ Agents

これは大手クラウドプロバイダの17個のIPから、24時間以内に2層(FW スキャンとWeb脆弱性スキャン)で組織的な活動が観測されたケースです。1IP単独では大した量ではなく、従来のSIEMでは検知できないレベルですが、グループとしてみれば明確な意図を持った活動でした。

検知後、17個のIP全部を、境界FWと公開サーバー側DMZ Agent群へ同時に伝播してブロックしています(カスケード防御。これは別記事で詳述予定)。

8. なぜこれが SIEM/SOAR と違うのか #

従来の SIEM や SOAR でも、相関ルールを書けば「複数機器の検知を組み合わせた判定」自体は実現できます。じゃあ何が違うのか。

最大の違いは、「未知のシナリオも検出できる」ことです。SIEM はルールに書かれていない攻撃は見逃します。多層相関は、層間の協調性という普遍的な特性を見るため、新しい攻撃手口にも対応できます。

9. 設計上のトレードオフ #

正直に書くと、この仕組みにはいくつかのトレードオフがあります。

1. 計算コスト: 全IPについて C(i,t) を計算するので、観測IP数が多いと処理時間が増える。BASTION は trace-registry に書かれた直近の活動IPに絞って計算することでこの問題を緩和している。

2. 閾値の調整: 閾値を低くすると誤検知が増え、高くすると見逃しが増える。これは環境依存で、初期は保守的に高めに設定し、観察しながら下げていくのが安全。

3. 既知IPの偽陰性: ホワイトリストに登録されたIP(自社サーバー、取引先、CDN等)は判定対象から除外する必要がある。これは別の機構で管理。

4. クラウドASN の特性: AWS や Microsoft のような大規模ASNは正規ユーザーも多数含む。エンタングルメント検知で大きなグループサイズが出ても、即ブロックではなく、CAP(1グループあたりの最大ブロックIP数)で安全側に制約する。

これらは設計の初期段階から認識していて、それぞれに対策を講じています。BASTION の設計原則の一つに「安全包絡線」があり、何かが暴走した時に物理的に被害を限定する仕組みを常に組み込みます。

10. 今後の発展 #

多層相関エンジン自体は十分実用域に達しましたが、さらに改良の余地があります。

• 適応的閾値: 環境の通常レベルを学習して閾値を自動調整(Phase 4 構想)
• 時間帯別の感度調整: 深夜と業務時間で異なる感度を適用
• 健全性コヒーレンス: 攻撃検知だけでなく、内部システムの不調を生物学的なモデルで検知する応用
• ASN信用スコア: クラウドASNごとに過去の挙動から信用度を算出

これらは順次実装予定です。