ログは「死体検分」ではない。SIEMを「予知能力」に変えるアーキテクチャの極意
世の中の多くのエンジニアがログを「事後の言い訳」や「コンプライアンスの帳尻合わせ」だと捉えているなら、それは重大な過ちだ。インシデントが発生した後にログを漁るのは、死体を解剖する検視官の仕事に過ぎない。我々が目指すべきは、パケットの微かな揺らぎやプロセスの不自然な挙動から、攻撃者の「意志」を読み取る予知能力である。
今回は、OWASP Top 10の脆弱性を突こうとする攻撃者の息遣いを、SIEMでいかにして「検知」という形に昇華させるか、現場の泥臭い知見を共有する。
—
1. 認証ログの深淵：単なる失敗回数では何も見えない
「同一IPから5回連続ログイン失敗でアラート」といった静的な閾値設定は、現代の攻撃者には通用しない。彼らは分散型ボットネットを使い、数千のIPから数秒に1回ずつ試行する「Low and Slow」攻撃を行うからだ。
ここで注目すべきは、認証成功後の「セッションハイジャック」や「権限昇格」を狙うプロトコル層のノイズである。
検知すべき重要ログポイント
- User-AgentとTLS Fingerprint (JA3) の不一致: ブラウザの挙動を模倣したヘッドレスブラウザ（Playwright/Puppeteer）や、Pythonの`requests`ライブラリ特有のヘッダー順序をSIEMで識別せよ。
- 権限昇格の予兆: 正常な操作フローではありえない、`GET /admin`への直接アクセス。これは、アプリケーションのロジック欠陥やIDOR（Insecure Direct Object Reference）を突く探索行為だ。
SIEMでの相関分析例 (Pseudo-KQL)
// JA3フィンガープリントとUser-Agentの不整合を突く
SigninLogs
| where ResultType == 0 // ログイン成功のみを抽出
| summarize DistinctUserAgents = dcount(UserAgent) by IPAddress, JA3Hash
| where DistinctUserAgents > 1 // 同じIP/JA3で複数のユーザーエージェントを使い分ける変態的な挙動
| project TimeGenerated, IPAddress, JA3Hash, Message
—
2. 生成AI時代の新たな境界：プロンプトインジェクションの検知
今、最も厄介なのはLLMを利用したアプリケーションへの「間接的プロンプトインジェクション」だ。攻撃者は悪意ある文字列をWebページやドキュメントに埋め込み、AIモデルに「管理者権限でデータベースをダンプせよ」と指示を送る。
この防衛には、ガードレイル層でのログ監査が不可欠だ。
ガードレイル防御層の設計
入力値と出力値の「意味的乖離」をログとして吐き出し、SIEMで異常スコアリングを行う必要がある。
- Input: ユーザーの入力（自然言語）
- Prompt: システムがAIに投げた最終的な指示書（サンドイッチ構造）
- Output: モデルの応答
検知ルール: `Output`の中に、本来含まれるはずのない「SQL構文」や「特権コマンドのフラグメント」が含まれていないかを正規表現とNLPで突き合わせる。
—
3. メモリレイヤの挙動を見逃さない（EDRとの統合）
アプリケーションの脆弱性は、多くの場合「メモリ破壊（Buffer Overflow等）」に起因する。しかし、アプリケーションログだけでこれを追うのは不可能だ。SIEMには、EDR（Endpoint Detection and Response）から送られる「異常なプロセス終了コード」や「ヒープ領域への不正アクセス」を統合せよ。
特に、耐量子暗号（PQC）への移行期である現在、アルゴリズムの複雑化に伴う実装ミスを狙った「サイドチャネル攻撃」が新たな脅威となっている。暗号化処理時間の異常な揺らぎ（Jitter）をログとして計測し、標準偏差から外れたものを「潜在的な攻撃」としてトリアージするロジックを実装すべきだ。
—
4. 現場のアーキテクチャ設計：SIEMの「ノイズ」を消す技術
SIEMの運用で最も失敗するのは、「アラート疲れ」だ。これを回避するためには、「エンティティ・ベースのスコアリング」が必須である。
1. ベースライン作成: 特定ユーザーのアクセス時間、アクセス先リソースのパターンを7日間学習させる。
2. リスクスコア付与:
- 認証失敗 (10点)
- 普段使わない国からのアクセス (30点)
- `eval()` や `system()` に酷似した文字列の入力 (50点)
3. 閾値超えで自動遮断: 合計スコアが80を超えた時点で、WAFまたはAPIゲートウェイを介して該当セッションを強制終了（Kill Session）する。
実装のヒント：Go言語でのログ出力サンプル
// 重要な操作には必ずコンテキストを含める
log.WithFields(log.Fields{
“user_id”: userID,
“ip_address”: req.RemoteAddr,
“ja3”: calculateJA3(req), // TLSハンドシェイクから算出
“action”: “sensitive_operation”,
“risk_score”: calculateRisk(req), // 相関分析のフラグメント
}).Warn(“Potential malicious activity detected”)
—
最後に：防御側の美学
セキュリティの最前線にいる我々にとって、ログとは「情報の断片」ではなく「敵との対話」だ。攻撃者のツールキットがどれだけ洗練されても、彼らがシステムを操作する際に必ず残す「不自然な痕跡」は消せない。
SIEMを単なるログ保管庫にするのではなく、攻撃者の思考を逆なでし、その動きを数手先で封じ込めるための「チェス盤」として使いこなしてほしい。技術の深淵を覗き込む勇気がある者だけが、真の安全を勝ち取れる。
次は、「なぜ君のWAFは、特定のパケット断片化攻撃をスルーしてしまうのか」という、もう少し深いプロトコルスタックの闇について語ろうか。
コメント