siem-detection

SIEM 検知 — 検知エンジニアリング

SIEM の検知コンテンツ、つまりアラートを発報するルールを作成、監査、保守します。アラート発報後に対応する incident-triage や、アラートをトリアージする SOC を運用する soc-operations とは異なります。このスキルはエンジニアリング層を担い、ログのカバレッジ、ルールの作成、チューニング、検知のコード化ワークフローを扱います。

相互参照：アラート発報後の対応については incident-triage、検知ルールに発展することの多い、仮説に基づくプロアクティブなハンティングについては threat-hunting、公開された侵害情報から得た検知アイデアについては breach-patterns、ここで設計した検知を基にアラートをトリアージする運用については soc-operations、まだ SIEM を導入していない小規模チーム向け（すでに保有するログを定期的に調べるエージェント — このスキルへの導入として）には log-watch を参照してください。

認可

ユーザーが所有する、または作業権限を与えられている環境の検知ルールを作成し、チューニングしてください。このスキルではルールファイルを書き込みます（そのための Write 権限があります）が、デプロイ、既存ルールの無効化、本番 SIEM のアラートルーティングの変更は行いません。攻撃活動をシミュレーションしてルールをテストする場合は、ラボ内で行うか、ホストの所有者から承認を得てください。

対象範囲

このスキルでは、以下を扱います。

• ログソースのカバレッジ評価（「X を検知するために必要なイベントを、そもそも収集できているか？」）
• 主要な SIEM クエリ言語を使ったルール作成（Sigma、KQL、SPL、Elastic ES|QL、Chronicle YARA-L）
• MITRE ATT&CK とのマッピング — カバレッジ分析のため、すべてのルールにテクニック ID を付与
• 検知のコード化ワークフロー（Git でのルール管理、CI テスト、デプロイの自動化）
• アラートチューニングのワークフロー — 真陽性を見逃さずに誤検知を減らす
• ATT&CK Navigator を使ったカバレッジギャップ分析

このスキルでは、以下を扱いません。

• 本番アラートのトリアージ（これは incident-triage の対象です）
• SOC チームの構築やアラートのエスカレーション基準の策定（soc-operations）
• アクティブな脅威ハンティング（threat-hunting）

方法論

ステップ 1：ログソースを ATT&CK カバレッジにマッピングする

ルールを作成する前に、何を検知できるかを監査してください。

観測対象に基づいてログソースを分類します。

カテゴリ	ソース	観測対象
エンドポイント	EDR（CrowdStrike、SentinelOne、Defender）、Sysmon、osquery	プロセス実行、ファイル書き込み、ネットワーク、レジストリ、親子関係
ネットワーク	Zeek/Bro、Suricata、NSM、ファイアウォール、DNS クエリログ	接続、プロトコル、DNS クエリ、TLS メタデータ
ID	Okta、Entra ID、AD、Auth0、GCP/AWS のサインイン	認証、MFA、グループ変更、ロールの割り当て
クラウド	CloudTrail（AWS）、Audit Logs（GCP）、Activity Log（Azure）	API 呼び出し — 作成、変更、削除されたもの
アプリケーション	アプリログ、WAF ログ、ロードバランサーログ、ゲートウェイログ	リクエスト URL、ステータスコード、認証結果
SaaS	Google Workspace、M365、Salesforce、GitHub の監査ログ	管理者アクション、共有、機密文書へのアクセス

ギャップを確認します。

• MITRE ATT&CK Enterprise matrix を取得します
• 環境に関連する各テクニックについて、どのログソースで検知できるかを確認します
• マッピングできるソースがないテクニックは盲点です — ルールを書く前に記録してください

よくある盲点：

• エンドポイントログはあるものの、コマンドライン引数を取得していない（ほとんどの Windows イベントログは、デフォルトでは引数ではなくバイナリのみを記録します）
• クラウド監査ログを収集していても、ReadOnly: true イベントを除外しているため、攻撃前の偵察が見えない
• SaaS の監査ログがない — 現代の攻撃はどれも、いずれかの時点で SaaS を経由します
• 相関 ID がないアプリログ — 「WAF がペイロードを検知した」ことと「アプリがペイロードを処理した」ことを関連付けられない

ステップ 2：ケースごとに適切な検出モデルを選ぶ

すべての脅威に SIEM ルールが必要なわけではありません。検出対象に合わせて検出モデルを選びます。

脅威の特性	最適なモデル	例
既知の IOC（ハッシュ、IP、ドメイン）	脅威インテリジェンスの照合	Sysmon のハッシュが既知のマルウェアと一致
既知のパターン（特定のコマンド、特定のパス）	シグネチャルール	powershell.exe -enc <base64>
既知の異常（ベースラインから逸脱した挙動）	統計的検出	サービスアカウントが突然、新しい地域から認証
イベントの連続	相関ルール	ログオン失敗 → 成功 → 5 分以内に権限変更
新規／未確認	脅威ハンティング（threat-hunting を参照）	仮説駆動型の SIEM 検索
内部不正	UEBA／リスクスコアリング	リスクのある行動を時間経過とともに累積して重み付け

シグネチャルールは作成コストが最も低く、チューニングも最も簡単です。統計的検出にはベースラインデータが必要で、最初の 1 か月は誤検知が増えます。

ステップ 3：ルールを作成する

可能な限り Sigma を信頼できる唯一の情報源として使う

Sigma は SIEM を横断する検出形式です。ルールを Sigma で記述し、sigmac／sigma-cli／pySigma を使ってバックエンド向けに自動変換します。現在は Splunk のみを対象にしていても、将来の自分に感謝されるでしょう。

title: AWS IAM CreateUser Followed by AttachUserPolicy
id: <UUID>
status: experimental
description: Detects an identity creating a new IAM user and immediately attaching an admin policy
references:
  - https://attack.mitre.org/techniques/T1136/003/
author: <name>
date: 2026-05-26
tags:
  - attack.persistence
  - attack.t1136.003
logsource:
  product: aws
  service: cloudtrail
detection:
  create_user:
    eventName: CreateUser
  attach_policy:
    eventName: AttachUserPolicy
    requestParameters.policyArn|contains: 'Administrator'
  timeframe: 10m
  condition: create_user and attach_policy
falsepositives:
  - Legitimate provisioning workflows (CI roles that bootstrap admin accounts)
level: high

KQL（Microsoft Sentinel／Defender／Azure Monitor）

SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType != 0
| summarize FailureCount = count() by UserPrincipalName, IPAddress, bin(TimeGenerated, 5m)
| where FailureCount > 10
| join kind=inner (
    SigninLogs
    | where TimeGenerated > ago(1h)
    | where ResultType == 0
) on UserPrincipalName, IPAddress
| project TimeGenerated, UserPrincipalName, IPAddress, FailureCount

（1 人のユーザー／IP でログオン失敗が急増し、その後、同じユーザー／IP でログオンに成功するケースです。典型的なパスワードスプレーの成功です。）

SPL（Splunk）

index=aws sourcetype=aws:cloudtrail
  (eventName=CreateUser OR eventName=AttachUserPolicy)
| transaction userIdentity.arn maxspan=10m
| where like(eventName, "%CreateUser%") AND like(eventName, "%AttachUserPolicy%")
| table _time, userIdentity.arn, eventName, requestParameters

ES|QL（Elastic）

FROM logs-aws.cloudtrail-*
| WHERE event.action == "CreateUser" OR event.action == "AttachUserPolicy"
| STATS create_count = COUNT(*) BY user.arn, event.action
| WHERE create_count > 0

（SIEM に合った LookML／KQL／SPL／ES|QL を使いますが、正規版は Sigma で作成してください。）

ステップ 4：MITRE ATT&CK にマッピングする

すべてのルールに、少なくとも 1 つの ATT&CK テクニックをタグ付けします。カバレッジマップは ATT&CK Navigator（navigator.mitre-attack.org）に集約されます。

• ルールを ATT&CK タグとともにエクスポートします
• Navigator のマトリックスに描画します
• 戦術ごとにカバレッジのギャップを特定します。「フィッシング経由の初期アクセスに対する検出がない」は、「もっとルールが必要」よりも具体的なアクションにつながります

Navigator の JSON 形式はオープンです。ルールをコードとして管理するリポジトリからこのレポートを作成するのに必要な Python コードは数百行ほどで、誰かに「何を検出しているのか」と初めて聞かれたときに元が取れます。

ステップ 5：チューニングする

誤検知への対応プロセス：

1. ルールを level: experimental で 1～2 週間デプロイします
2. 検知のたびに確認します — 真陽性か、誤検知か、抑制可能か？
3. 誤検知ごとに確認します： ルールを絞り込めるか（より具体的なフィルター）、またはチューニング例外を追加できるか（既知の正常な対象を許可リストに追加）？
4. 比率を追跡します — チューニング後も誤検知が 80％を超える場合、検出モデルが適切ではありません（シグネチャを統計的なものにする必要があるか、その逆です）。不適切なモデルを 100 件の許可リストエントリで取り繕わないでください。
5. 誤検知率が許容できる水準になってから、level: high／本番環境に昇格します

一度も検知したことのないルールもシグナルです。ログのカバレッジに問題があるか、クエリが間違っているか、脅威が実際に発生していない可能性があります。意図的なテストイベントをシステムに流して、どれに該当するかを確認してください。

ステップ 6：検出をコードとして管理する

ルールは SIEM のコンソールではなく、Git で管理します。

detections/
├── aws/
│   ├── credential-access/
│   │   └── iam-create-user-attach-admin.yml
│   └── ...
├── windows/
├── linux/
└── identity/
    └── okta-password-spray.yml
.github/workflows/
└── detection-ci.yml

CI チェック：

• Sigma の検証（sigma-cli check）
• ATT&CK タグがあり、解決可能であること
• description フィールドと references フィールドが空でないこと
• バックエンドへの変換が成功すること（sigma convert -t splunk など）
• 任意：既知の正常なイベントストアに対してルールをリプレイし、ヒット件数を検証する

デプロイ：マージ後、API 経由でルールを SIEM にプッシュします。Git の revert でロールバックします。

出力形式

カバレッジ評価：

# SIEM Detection Coverage
## Environment: [name]
## Date: [date]

### Log sources mapped
| Source | Status | Notes |
|---|---|---|

### ATT&CK coverage
| Tactic | Techniques covered / total | Blind spots |
|---|---|---|

### Rule inventory
| Rule | ATT&CK | Severity | Status | Last fired |
|------|--------|----------|--------|------------|

### Tuning queue
[Rules in experimental / needing FP triage]

### Recommended next 30 days
[Prioritized — usually 3-5 items]

ルールごとのドキュメントは別のランブックではなく、ルール（Sigma YAML）と一緒に管理します。description、references、falsepositives フィールドがランブックになります。

範囲

• 自組織の環境、またはユーザーから明示的な許可を得ている環境を対象とした検知コンテンツ
• 回避ルールや、正規のセキュリティツールを検知対象とすることを目的とした検知ルールの作成は拒否します
• 人事部門および法務部門の承認範囲を超えて従業員を意図的に監視する検知は対象外です。ユーザーにエスカレーションしてください
• アラートをトリアージするアナリストが次に何をすべきか理解できるよう、各ルールに十分なコンテキストを付けてください。そのコンテキストがないルールはアラート疲れにつながります

参考資料

• MITRE ATT&CK Enterprise マトリックス
• MITRE ATT&CK Navigator
• Sigma ルールリポジトリ（SigmaHQ/sigma）
• Florian Roth の「Detection Engineering」に関する記事
• Splunk Security Essentials ／ Microsoft Sentinel コンテンツハブ ／ Elastic 検知ルールリポジトリ
• 「Detection Engineering Maturity Matrix」（Florian Roth）
• 「The Pyramid of Pain」（David Bianco）— IOC の価値階層
• NIST SP 800-92（コンピューターセキュリティログ管理）