ログの森で迷子になるな：生ログ信仰を捨て、正規化と相関分析で「本物のシグナル」を掴む
夜中の3時、重く鳴り響くSOC（セキュリティオペレーションセンター）のアラート音。画面を開けば、数万件の「未承認アクセス試行」の文字。その大半は、IPレピュテーションすら汚れていない、どこにでもあるリバースプロキシの404エラーや、設定ミスによる単なる死活監視のノイズ。
私たちは日夜、この「ログの奔流」と戦っている。
多くの組織が「とりあえずSIEMに全量突っ込んでおけば安心だ」という、古い信仰に囚われている。しかし、攻撃者はそんな甘い設計の隙間を縫ってくる。彼らが使うのは、EDRのシグネチャをすり抜けるLiving off the Land（LolFins/LolBins）の技法であり、正規の認証フローを悪用したセッションハイジャックだ。
「何が起きているか」を正確に知るためには、散らばるログの断片をつなぎ合わせ、コンテキスト（文脈）を持った「相関シグナル」へと昇華させなければならない。
今回は、SIEMにおけるログの正規化（Normalization）の本質と、誤検知（False Positive）の荒波を乗り越える実戦的な相関ルール設計のアーキテクチャについて、現場の泥臭い知見を交えて解説する。
—
なぜ「生ログ」のままでは戦えないのか
異なるベンダーの機器、クラウドサービスの監査ログ、オンプレミスのファイアウォール。これらをバラバラのフォーマットのままSIEMに集約しても、それは単なる「ゴミ溜めの拡大」に過ぎない。
例えば、ある製品のログイン失敗ログは login_fail であり、別のクラウドIAMのそれは Auth:Failed であり、また別のレガシーアプライアンスは Error Code 0x80070005 と吐き出す。これらを人間が目視で突合せるのは不可能に近いし、機械学習モデルに食わせても、特徴量の次元が爆発してノイズを学習するだけだ。
ここで必要になるのが、ECS（Elastic Common Schema）などに代表される共通フォーマットへの正規化（Normalization）である。
正規化の本質は、フィールド名の統一（例: source.ip, user.name, event.action）だけではない。「異なるレイヤの事象を、同一のタイムライン上で比較可能な状態に抽象化すること」にある。低レイヤのパケット構造から、アプリケーション層のセッション情報までをフラットに扱えるようにして初めて、高度な相関分析の土俵に立てるのだ。
—
実践：Elasticsearch / SIGMAフォーマットによる相関ルール設計
では、実際に「ブルートフォースからの権限昇格（Privilege Escalation）」という、よくあるが致命的なシナリオを検知するための相関ルールを設計してみよう。
攻撃者は通常、以下のようなステップを踏む。
1. 短時間での連続したログイン失敗（パスワードスプレー / ブルートフォース）
2. ログイン成功直後の、通常とは異なる特権コマンドの実行やIAMロールの変更
これを個別のイベントとして検知してもSOCは疲弊するだけだ。「IP: X.X.X.X が 5分以内に 10回失敗し、その直後に管理者グループへの追加が行われた」という文脈（State）の結合こそが、相関分析の真価である。
以下は、オープンなシグネチャフォーマットであるSIGMAをベースにした、相関ルールの概念的実装例だ。
title: 連続認証失敗からの不審な権限昇格検知
id: 9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d
status: experimental
description: 短期間のブルートフォース試行成功後、直ちに特権グループへのユーザー追加が行われたシナリオを検知
author: White Hacker / Security Architect
references:
- https://attack.mitre.org/tactics/TA0004/
logsource:
category: authentication
product: multi_source
detection:
selection_brute:
event.action: "login_failed"
client.ip: "%attacker_ip%"
timeframe: 5m
condition: selection_brute | count(user.name) > 5
# 相関のための後続アクション定義（概念モデル）
selection_escalation:
event.action: "group_member_add"
user.target.group: ["Domain Admins", "Administrators", "Root"]
client.ip: "%attacker_ip%"
# 連続した一連のフローとして評価
overall: selection_brute -> selection_escalation
falsepositives:
- 頻繁にパスワードを失念する特権管理者の操作
- 自動化されたデプロイメントスクリプトの誤設定
level: highこのルールが稼働している背後では、SIEMのストリーム処理エンジン（LogstashやElastic, Splunkの相関エンジンなど）が、ステートフルにセッションを追跡している。
—
現場で直面する「ノイズ」の正体とチューニングの極意
相関ルールをデプロイした初日、SOCのチャットはアラートの嵐で埋まる。ここで「やっぱり検知感度を下げよう」と逃げ出すエンジニアは二流だ。アラートの裏にある「環境の歪み」を見つけ出すのがプロの仕事である。
1. タイムスキュー（時刻のズレ）の罠
クラウドインスタンス、オンプレサーバー、ネットワーク機器。それぞれのNTP同期が数秒ずれているだけで、相関エンジンのウィンドウ（例: 5分以内）からイベントが漏れ落ちる。
対策: 正規化のパイプライン（Logstash/Fluentd等）のステージで、必ずイベント到着時刻 (@timestamp) とデバイス生成時刻 (event.created) のデルタを監視し、極端な時差があるログは「タイムスキュー警告」として別レーンに逃がす。
2. シャドウITとNAT環境の限界
社内ネットワークの出口に強力なNATルーターがある場合、数百人の従業員が「たった1つのグローバルIP」からアクセスすることになる。結果として、無関係なユーザーの「ログイン失敗」と、別のユーザーの「権限昇格」が同じ client.ip で偶然マッチし、偽の相関アラート（False Positive）を量産する。
対策: IPアドレス単体での相関に頼らず、正規化されたセッションID、デバイスフィンガープリント、あるいはゼロトラストアーキテクチャ（ZTA）下でのアイデンティティ・コンテキスト（user.id単位の相関）へ軸足を移行する。
—
次世代の脅威に向けたSIEMの進化
いまや攻撃者は、生成AIを用いて標的型フィッシングの文面を動的に生成し、APIの脆弱性を突いて瞬時に特権奪取を果たす。静的なルールベースの相関分析だけでは、ゼロデイや高度なLiving off the Landの手口の背後にある「かすかなシグナル」を取りこぼしてしまう。
私たちが目指すべきアーキテクチャの終着点は、「正規化されたECSログを基盤とした、確率的グラフ分析とAIガードレイルの融合」だ。
すべてのログが高精度に正規化され、エンティティ（ユーザー、ホスト、プロセス）のグラフ構造がリアルタイムで構築されていれば、機械学習モデルは「いつもの振る舞いからのわずかな逸脱（Anomaly）」を正確に捉えることができる。
ログを溜めるな。構造化せよ。
そして、点と点を繋ぎ合わせる「物語（コンテキスト）」をルールとしてコード化せよ。それこそが、巧妙化するサイバー攻撃の迷宮を生き抜くための唯一にして最良の防衛策である。
コメント