ログは「死体検視」ではない。SIEMによるリアルタイム・タクティカル・インテリジェンスの構築
多くの企業が「ログをSIEMに投げ込んでいる」ことに満足しているが、それは死体検視をしているに過ぎない。サイバー攻撃者がシステム内部を這い回っている最中に、その挙動をどう可視化し、どう阻止するか。これがCISOやテックリードに求められる、真のオブザーバビリティだ。
CloudTrailやVPC Flow LogsをSplunkやSentinelに集約するのはスタート地点に過ぎない。本稿では、単なるログ収集を超えた、攻撃者の心理と技術的ロジックを突く「攻めのログ戦略」を説く。
—
1. ログの「質」を問う：相関分析を殺すノイズを排除せよ
SIEMのコスト高騰の主因は、無意味なログの垂れ流しだ。攻撃者は、過剰なログの中に自身の痕跡を埋没させる「ログ・フロッディング」を好む。
攻撃者の盲点を突くログ設計
単にCloudTrailを流すのではなく、以下の「異常系」に特化したフィルターをゲートウェイで適用せよ。
- IAMの不整合: `AssumeRole` の頻発と `UserAgent` の不一致。
- ネットワークの非対称性: VPC Flow Logsにおける「拒否されたSYNパケット」の急増（ポートスキャンの兆候）。
- 認証のメタデータ: MFA成功前の失敗回数ではなく、成功後の「地理的矛盾」と「セッション持続時間」の相関。
—
2. 実装：SIEMとの連携における「ガードレイル」のコード例
Terraformを用いて、最低限必要なログソースをセキュアに集約する定義の一例だ。ここでは、S3バケットへの転送時にKMSで暗号化し、かつ整合性チェックを行う設計を推奨する。
CloudTrailのログをセキュアに転送するための設定例
resource “aws_cloudtrail” “main” {
name = “enterprise-audit-trail”
s3_bucket_name = aws_s3_bucket.log_storage.id
include_global_service_events = true
is_multi_region_trail = true
enable_log_file_validation = true # ログ改ざん検知の要
# 攻撃者が権限昇格した際にログを消去させないための防御的制御
# S3のObject Lockと合わせて構成することが必須
}
ログバケットの防御設定
resource “aws_s3_bucket_server_side_encryption_configuration” “log_crypto” {
bucket = aws_s3_bucket.log_storage.id
rule {
apply_server_side_encryption_by_default {
kms_master_key_id = aws_kms_key.log_key.arn
sse_algorithm = “aws:kms”
}
}
}
—
3. 次世代の脅威：プロンプトインジェクションとログの役割
現在、最も頭を悩ませるのはLLMを利用したアプリケーションの脆弱性だ。従来のWAFでは、プロンプトインジェクションによる「モデルのハック」は防げない。
ガードレイル・ログの設計
LLMのAPIリクエストとレスポンスをSIEMへ流し、以下の異常を検知するルールを構築せよ。
1. トークン・シーケンスの異常: ユーザー入力にシステムプロンプトの指示を上書きする文字列が含まれているか。
2. 出力の逸脱: モデルが本来生成すべきでない、機密データやプログラムコードを含んだ回答を返していないか。
これらを検知するために、Splunk上で `eval` を使い、特定の正規表現（プロンプトの脱獄パターン）とマッチングさせるリアルタイムアラートが不可欠だ。
—
4. 防御の最前線：耐量子暗号とパケット解析の未来
将来的な「Harvest Now, Decrypt Later（今盗んで、後で解読する）」攻撃に備え、通信プロトコルの暗号スイートをTLS 1.3かつ耐量子暗号（PQC）対応のものへ移行する準備を急ぐべきだ。
また、パケット構造の解析において、TLSのフィンガープリント（JA3/JA3S）を活用せよ。通信の中身が暗号化されていても、クライアントのハンドシェイク挙動を分析すれば、それが正当なアプリケーションからのアクセスか、攻撃ツール（Cobalt Strike等）によるものかを見抜くことができる。
—
結論：ログは武器である
SIEMを「記録庫」として扱う時代は終わった。ログ基盤は、敵の戦術（TTPs）をリアルタイムにマッピングし、自動的な遮断スクリプトをトリガーするための「インテリジェンス・エンジン」であるべきだ。
次にシステムを設計する際、自問してほしい。「このログは、攻撃者の次のステップを予測するために使えるか？」と。答えが「No」であれば、そのログ設定はゴミだ。今すぐ設定を書き換え、防御の解像度を一段階引き上げろ。
セキュリティは教条主義を嫌う。常に「攻撃者ならどうやってこの監視網を回避するか？」を考え続ける者だけが、システムを真に守ることができるのだ。
コメント