SIEMは「ログの墓場」ではない：インシデントを見抜くための相関分析の極意
「SIEMを導入したからもう安心だ」。現場でそんな言葉を耳にするたび、私は背筋が凍る思いがする。多くのチームが、SIEMをただのログストレージとして扱い、溢れかえるアラートの嵐の中で溺れている。
いいか、よく聞け。攻撃者は「単発のログ」には痕跡を残さない。彼らは、OSのコマンド実行、不審なネットワーク接続、権限昇格という、一見無関係に見える小さな断片を時間軸で繋ぎ合わせることで侵入を達成する。DFIRのプロとして断言するが、ログの集約はスタートラインに過ぎない。重要なのは「相関」だ。
今回は、現場で実際に使われている「攻撃者が潜む盲点」を突くための相関ロジックと、それを実装するための泥臭いテクニックを共有しよう。
—
なぜ攻撃者は「単一のログ」をすり抜けるのか
攻撃者は、システム管理者の監視を欺くために「低速かつ隠密な攻撃」を仕掛けてくる。
例えば、Webアプリの脆弱性（RCEやSQLi）を突いてバックドアを仕込んだ際、Webサーバーのアクセスログには 200 OK が並ぶだけだ。これ単体では、ただの「正常なリクエスト」と区別がつかない。
ここでSIEMの出番だ。「Webサーバーの不審なステータスコード」と「バックエンドの権限昇格」を時間軸で相関させる必要がある。
実践：相関ルールの思考プロセス
以下の3ステップをSIEMで相関させるのが、最も確実な防御だ。
1. Webサーバー: 異常な長さのクエリ文字列や eval などのキーワード検出
2. OS/システム: Web実行ユーザー（www-data等）による sh や python の子プロセス生成
3. ネットワーク: 外部への不審なアウトバウンド通信（C2サーバーへのコールバック）
—
攻撃を防ぐための実装サンプル：Pythonによるログ監視の自動化
SIEMにログを送る前に、まずはアプリケーションレベルで「怪しい挙動」をシグネチャとして検知し、構造化ログとして出力する仕組みが必要だ。以下は、PHPでのコード実行を模した攻撃を検知し、SIEMへJSON形式で送信するPythonのガードレール実装だ。
import json
import logging
import sys
# 実際の運用ではSIEM(Splunk/Elasticsearch)のAPIエンドポイントへ転送する
def send_to_siem(event_type, details):
log_data = {
"event": event_type,
"severity": "CRITICAL",
"details": details,
"source": "app-web-node-01"
}
# JSON構造化ログとして出力（SIEM側でパースしやすい形式）
print(json.dumps(log_data))
def check_for_malicious_input(user_input):
# 攻撃者がよく使うシグネチャ（簡略版）
# 実際にはWAFで防ぐべきだが、アプリ側でもログを吐くことが重要
forbidden_patterns = ['eval(', 'base64_decode', 'system(', 'exec(']
for pattern in forbidden_patterns:
if pattern in user_input:
send_to_siem("RCE_ATTEMPT_DETECTED", {
"detected_pattern": pattern,
"input_sample": user_input[:50] # 攻撃内容を一部抽出
})
return True
return False
# 利用例
user_input = "system('whoami');"
if check_for_malicious_input(user_input):
print("Security Alert: 攻撃が検知されました。管理者に通知します。")—
盲点を突くインフラ設定：Nginxでの不審な通信のブロック
SIEMで相関させる以前の「前処理」として、WAFやリバースプロキシで攻撃のノイズを減らすことは必須だ。特に、User-Agent を偽装したスキャナーや、HTTPメソッド の異常は、ここで弾く。
nginx.conf での基本的な保護設定例だ。
# 不審なUser-Agentを弾く（最小限の防御）
if ($http_user_agent ~* (sqlmap|nikto|nmap|dirbuster)) {
return 403;
}
# HTTPメソッドの制限（GET/POST/HEAD以外を拒否）
if ($request_method !~ ^(GET|POST|HEAD)$ ) {
return 444; # 接続を閉じる
}
# ログのJSONフォーマット化（SIEMのパース効率を最大化）
log_format json_combined escape=json '{'
'"time_local":"$time_local",'
'"remote_addr":"$remote_addr",'
'"request":"$request",'
'"status":"$status",'
'"http_user_agent":"$http_user_agent"'
'}';
access_log /var/log/nginx/access.json json_combined;—
私からのアドバイス：SIEM運用を「自分事」にするために
最後に、後輩である諸君に伝えておきたいことがある。
どれだけ高価なSIEMを導入しても、「ログを分析する側の意図」がなければ、それはただの電子ゴミだ。 攻撃者の手法は日々進化している。だからこそ、自分の書いたコードが「どう悪用される可能性があるか」を常に考え、その異常系をログに書き出す癖をつけてほしい。
1. ログにコンテキストを持たせる: 単なるエラーメッセージではなく、ユーザーIDやリクエストの意図をJSON形式で記録する。
2. ノイズを排除する: 全てのログを拾うのではなく、攻撃に繋がりそうな「重要イベント」を絞り込む。
3. 定期的な演習: 「もし今、このサーバーが侵害されたら、どのログを見れば追跡できるか？」を月に一度は自問自答せよ。
インシデントレスポンスは、最後に頼れるのは「ツール」ではなく「人間が蓄積した知見とロジック」だ。今日から、君たちのログを「意味のあるデータ」に変える努力を始めてくれ。健闘を祈る。
コメント