performing-false-positive-reduction-in-siem

SIEMにおける誤検知の削減の実施

概要

誤検知アラートとは、セキュリティルールをトリガーする非悪意のイベントのことで、SOCアナリストをノイズで圧倒します。調査によると、SIEMアラートの最大45%が誤検知であり、一般的なSOCアナリストが1シフトで効果的に調査できるアラートは20～25件に限られます。誤検知を減らすには、しきい値、相関ロジック、許可リスト、エンリッチメント、継続的な検証にわたる体系的なチューニングが必要です。SIEMルールは、最低でも四半期ごとに見直す必要があります。

使用するタイミング

• SIEMにおける誤検知の削減を含むセキュリティアセスメントを実施する場合
• 関連するセキュリティイベントに対してインシデント対応手順に従う場合
• 定期的なセキュリティテストまたは監査活動を実施する場合
• 実地テストによってセキュリティ統制を検証する場合

前提条件

• SOC運用の概念およびツールに関する理解
• 安全に実行するためのテストまたはラボ環境へのアクセス
• 必要な依存関係がインストールされたPython 3.8以上
• テスト活動に対する適切な許可

誤検知削減の手法

1. ノイズの多いルールの特定

# Splunk - Top 10 noisiest correlation searches
index=notable
| stats count by rule_name
| sort -count
| head 10
| eval pct=round(count / total * 100, 1)

# False positive rate per rule
index=notable
| stats count as total
    count(eval(status_label="Closed - False Positive")) as false_positives
    count(eval(status_label="Closed - True Positive")) as true_positives
    by rule_name
| eval fp_rate=round(false_positives / total * 100, 1)
| sort -fp_rate
| where total > 10

2. しきい値のチューニング

# Before: Too sensitive - fires on 5 failed logins
index=wineventlog EventCode=4625
| stats count by src_ip
| where count > 5

# After: Tuned - requires 20+ failures across 3+ accounts in 10 minutes
index=wineventlog EventCode=4625
| bin _time span=10m
| stats count dc(TargetUserName) as unique_accounts by src_ip, _time
| where count > 20 AND unique_accounts > 3

3. 許可リスト/除外の管理

# Create allowlist lookup for known benign sources
| inputlookup fp_allowlist.csv
| fields src_ip, reason, approved_by, expiry_date

# Apply allowlist in detection rule
index=wineventlog EventCode=4625
| lookup fp_allowlist src_ip OUTPUT reason as allowlisted_reason
| where isnull(allowlisted_reason)
| stats count dc(TargetUserName) as unique_accounts by src_ip
| where count > 20 AND unique_accounts > 3

4. 相関の強化

# Before: Single-event detection (noisy)
index=wineventlog EventCode=4688 New_Process_Name="*powershell.exe"
| eval severity="medium"

# After: Multi-signal correlation (precise)
index=wineventlog EventCode=4688 New_Process_Name="*powershell.exe"
| join src_ip type=left [
    search index=wineventlog EventCode=4625
    | stats count as failed_logins by src_ip
]
| join Computer type=left [
    search index=sysmon EventCode=3
    | stats dc(DestinationIp) as unique_external_connections by Computer
    | where unique_external_connections > 10
]
| where isnotnull(failed_logins) OR unique_external_connections > 10
| eval severity=case(
    failed_logins > 10 AND unique_external_connections > 10, "critical",
    failed_logins > 5 OR unique_external_connections > 5, "high",
    true(), "medium"
)

5. 時間ベースの除外

# Exclude known maintenance windows
| eval hour=strftime(_time, "%H")
| eval day=strftime(_time, "%A")
| where NOT (hour >= "02" AND hour <= "04" AND day="Sunday")

# Exclude known batch job schedules
| lookup scheduled_tasks_allowlist process_name, schedule_time
    OUTPUT is_scheduled
| where isnull(is_scheduled)

6. 振る舞いベースラインの統合

# Build baseline for user login patterns
index=wineventlog EventCode=4624
| bin _time span=1h
| stats count as logins dc(Computer) as unique_hosts by TargetUserName, _time
| eventstats avg(logins) as avg_logins stdev(logins) as stdev_logins
    avg(unique_hosts) as avg_hosts stdev(unique_hosts) as stdev_hosts
    by TargetUserName
| where logins > (avg_logins + 3 * stdev_logins)
    OR unique_hosts > (avg_hosts + 3 * stdev_hosts)

7. 脅威インテリジェンスによるフィルタリング

# Only alert when destination matches known threat intelligence
index=firewall action=allowed direction=outbound
| lookup ip_threat_intel_lookup ip as dest_ip OUTPUT threat_type, confidence
| where isnotnull(threat_type) AND confidence > 70
# This eliminates FPs from flagging connections to benign IPs

チューニングプロセスの枠組み

ステップ1: 特定（毎週）

• アラート件数の多い上位10ルールを抽出する
• 各ルールの誤検知率を算出する
• 誤検知率が30%を超えるルールを特定する

ステップ2: 分析（毎週）

• ルールごとに誤検知を20件サンプリングする
• 各誤検知の根本原因を分類する
• 共通パターンを特定する

ステップ3: チューニング（隔週）

• ベースラインデータに基づいてしきい値を調整する
• 良性パターンの許可リストエントリを追加する
• 相関ロジックを強化する
• エンリッチメントのコンテキストを追加する

ステップ4: 検証（毎月）

• Atomic Red Teamテストを実行し、真陽性が引き続きトリガーされることを確認する
• チューニング後の新しい誤検知率を算出する
• チューニングの根拠を文書化する
• 検知エンジニアリングチームとレビューする

ステップ5: 報告（四半期ごと）

• ルールごとの誤検知削減の指標
• 全体的なアラート件数の傾向
• アナリストの生産性の向上
• 廃止または置き換えられたルール

検証テスト

# Run Atomic Red Team test after tuning to confirm detection still works
# Example: Test brute force detection after threshold adjustment
Invoke-AtomicTest T1110.001 -TestNumbers 1

# Verify detection still triggers after tuning
index=notable rule_name="Brute Force Detection"
earliest=-24h
| stats count
| where count > 0

誤検知削減の指標

指標	計算式	目標
誤検知率	FP / (FP + TP) * 100	< 20%
アラート件数の削減率	(旧件数 - 新件数) / 旧件数 * 100	四半期ごとに30～50%
平均トリアージ時間	総トリアージ時間 / 総アラート数	< 8分
ルールの適合率	TP / (TP + FP)	> 0.80
アナリストの満足度	アンケートスコア	> 4/5

参考文献

• CyberSierra - Tune SIEM Alerts to Eliminate False Positives
• ConnectWise - 9 Ways to Eliminate SIEM False Positives
• Prophet Security - Alert Tuning Best Practices
• ManageEngine - Reducing SIEM Alert False Positives