siem-logging

SIEM ロギング

目的

SIEM プラットフォーム（Elastic SIEM、Microsoft Sentinel、Wazuh、Splunk）を使用して包括的なセキュリティロギング基盤を構成し、脅威を検出してインシデントを調査し、コンプライアンス監査証跡を維持します。このスキルでは、プラットフォームの選定、ログ集約アーキテクチャ、検出ルールの開発（SIGMA 形式およびプラットフォーム固有の形式）、アラートの調整、規制コンプライアンス（GDPR、HIPAA、PCI DSS、SOC 2）に対応する保持ポリシーを扱います。

このスキルを使用する場面

次のような場合にこのスキルを使用します。

• インフラストラクチャ全体にわたるセキュリティイベントの一元的な監視を実装する
• 認証の失敗、権限昇格、データ流出に関する脅威検出ルールを作成する
• マルチクラウド環境（AWS、Azure、GCP、Kubernetes）向けのログ集約を設計する
• ログ保持と監査証跡に関するコンプライアンス要件を満たす
• 誤検知やアラート疲れを減らすためにセキュリティアラートを調整する
• 大量のセキュリティログ（TB/日規模）のコストを算出する
• セキュリティロギングをインシデント対応ワークフローに統合する

SIEM プラットフォームの選定

迅速な判断フレームワーク

次の基準に基づいて SIEM プラットフォームを選定します。

予算の考慮事項：

• 予算無制限 → Splunk Enterprise Security（エンタープライズ機能、実績のある拡張性）
• 中程度の予算（年間$50k～$500k）→ Microsoft Sentinel または Elastic SIEM（クラウドネイティブ、柔軟）
• 予算が限られている（年間<$50k）→ Wazuh（無料、オープンソースの XDR/SIEM）

インフラストラクチャの状況：

• Azure への投資が大きい → Microsoft Sentinel（ネイティブ統合、SOAR を内蔵）
• AWS への投資が大きい → AWS Security Lake + OpenSearch（AWS ネイティブ）
• マルチクラウドまたはオンプレミス → Elastic SIEM または Wazuh（プラットフォームに依存しない）

データ量：

• >1 TB/日 → Splunk または Elastic Cloud（大規模環境での実績）
• 100 GB～1 TB/日 → Microsoft Sentinel または Elastic SIEM
• <100 GB/日 → Wazuh または Sentinel 50 GB ティア

チームの専門知識：

• Elasticsearch の経験がある → Elastic SIEM（使い慣れたツール）
• Microsoft/Azure の専門知識がある → Microsoft Sentinel（Azure エコシステム）
• ジェネラリストまたはリソースが限られている → Wazuh（最も学習しやすい）

プラットフォーム比較の概要

プラットフォーム	コスト	デプロイ	最適な用途
Elastic SIEM	$$$	クラウド/セルフホスト	マルチクラウド、カスタマイズのニーズ、DevOps チーム
Microsoft Sentinel	$$$	クラウド（Azure）	Azure の利用が多い組織、SOAR 内蔵、クラウドファースト
Wazuh	無料	セルフホスト	コスト重視の組織、中小企業、コンプライアンス要件
Splunk ES	$$$$$	クラウド/オンプレミス	大企業、大規模環境、予算無制限

詳細な機能比較については、references/platform-comparison.md を参照してください。

検出ルール

共通形式：SIGMA ルール

SIGMA は、あらゆる SIEM クエリ言語（Elastic EQL、Splunk SPL、Microsoft KQL）にコンパイルできる共通の検出ルール形式を提供します。

SIGMA ルールの構造：

title: Multiple Failed Login Attempts from Single Source
id: 8a9e3c7f-4b2d-4e8a-9f1c-2d5e6f7a8b9c
status: stable
description: Detects potential brute force attacks (10+ failed logins in 10 minutes)
author: Security Team
date: 2025/12/03
references:
  - https://attack.mitre.org/techniques/T1110/
tags:
  - attack.credential_access
  - attack.t1110
logsource:
  category: authentication
  product: linux
detection:
  selection:
    event.type: authentication
    event.outcome: failure
  timeframe: 10m
  condition: selection | count() by source.ip > 10
level: high

SIGMA をプラットフォーム固有の形式にコンパイルする：

# Install SIGMA compiler
pip install sigma-cli

# Compile to Elastic EQL
sigmac -t es-eql sigma_rule.yml

# Compile to Splunk SPL
sigmac -t splunk sigma_rule.yml

# Compile to Microsoft KQL
sigmac -t kusto sigma_rule.yml

プラットフォーム固有の検出形式

Elastic EQL（Event Query Language）：

sequence by user.name with maxspan=5m
  [process where process.name == "powershell.exe" and
   process.args : ("Invoke-WebRequest", "iwr", "wget")]
  [process where process.parent.name == "powershell.exe"]

Microsoft Sentinel KQL：

SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType != 0  // Failed login
| summarize FailedAttempts=count() by UserPrincipalName, IPAddress
| where FailedAttempts >= 10

Splunk SPL：

index=web_logs sourcetype=access_combined
| rex field=uri "(?<sql_keywords>union|select|insert|update|delete)"
| where isnotnull(sql_keywords)
| stats count by src_ip, uri
| where count > 5

包括的な検出ルールの例については、次を参照してください。

• examples/sigma-rules/ - 共通の SIGMA 検出ルール
• examples/elastic-eql/ - Elastic 固有のクエリ
• examples/microsoft-kql/ - Microsoft Sentinel クエリ
• examples/splunk-spl/ - Splunk 検索
• references/detection-rules-guide.md - 完全ガイド

ログ集約アーキテクチャ

集中型アーキテクチャ

すべてのログを単一の SIEM インスタンスに集約します。次の場合に使用します。

• 単一リージョンへのデプロイ
• 小～中程度のデータ量（<1 TB/日）
• 単一のクラウドプロバイダーまたはオンプレミス
• セキュリティチームの規模が小さい（アナリスト1～10人）

アーキテクチャ：

Application Servers → Log Shippers (Filebeat/Fluentd)
                   ↓
              Log Aggregator (Logstash/Fluentd)
                   ↓
          SIEM Platform (Elasticsearch/Splunk/Sentinel)
                   ↓
            Security Analysts (Dashboard/Alerts)

分散アーキテクチャ（マルチリージョン）

グローバル集約を伴うリージョン別 SIEM インスタンス。次のような場合に使用します:

• マルチリージョンのグローバル展開
• データレジデンシー要件（GDPR、主権）
• 大量のボリューム（リージョンあたり 1 TB/日超）
• リージョン分析における低レイテンシ要件

アーキテクチャ:

Global SIEM (Correlation, Threat Intelligence)
    ↓
Regional SIEM (US-East) | Regional SIEM (EU-West) | Regional SIEM (APAC)
    ↓                        ↓                          ↓
Local Logs               Local Logs                 Local Logs

クラウドネイティブアーキテクチャ

マネージドクラウドサービスを活用します。次のような場合に使用します:

• クラウドファーストの組織（AWS/Azure/GCP）
• インフラストラクチャの管理を避けたい
• ログボリュームが変動する伸縮自在なワークロード
• クラウドサービスコストの予算がある

AWS の例:

CloudTrail + VPC Flow Logs + GuardDuty
              ↓
       AWS Security Lake (S3 Data Lake)
              ↓
    OpenSearch (Analysis) | Athena (SQL Queries)

デプロイの例については、次を参照してください:

• examples/architectures/elk-stack-docker-compose.yml
• examples/architectures/fluentd-kubernetes-daemonset.yaml
• examples/architectures/aws-security-lake-terraform/
• examples/architectures/wazuh-docker-compose.yml
• references/cloud-native-logging.md

ログ集約ツール

Fluentd（クラウドネイティブ）: Kubernetes およびマルチクラウド環境向けの CNCF プロジェクト。コンテナ化されたアプリケーションに使用します。

Logstash（Elastic Stack）: Elasticsearch とのネイティブ統合。高度な解析（grok パターン）とデータエンリッチメントに使用します。

完全な設定例については、examples/logstash-pipelines/ および references/cloud-native-logging.md を参照してください。

ログの保持とコンプライアンス

コンプライアンス要件

フレームワーク	最小保持期間	ホットストレージ	ウォームストレージ	コールドストレージ
GDPR	30〜90 日	7 日	30 日	60 日
HIPAA	6 年	30 日	180 日	6 年
PCI DSS	1 年	90 日	180 日	1 年
SOC 2	1 年	30 日	90 日	1 年

ストレージ階層化戦略

ホット階層（SSD、リアルタイム）:

• 直近 7〜30 日
• リアルタイムのインデックス作成と高速なクエリ
• 最も高コスト（$0.10/GB/月）

ウォーム階層（HDD、最近）:

• 30〜90 日
• 読み取り専用インデックス、時折の検索
• 中程度のコスト（$0.05/GB/月）

コールド階層（S3/Blob、アーカイブ）:

• 90 日から保持上限まで
• 検索可能なスナップショット、まれなクエリ
• 最も低コスト（$0.01/GB/月）

コスト最適化の例:

500 GB/day log volume, 1-year retention

Hot (30 days):   15 TB @ $0.10/GB = $1,500/month
Warm (60 days):  30 TB @ $0.05/GB = $1,500/month
Cold (275 days): 137.5 TB @ $0.01/GB = $1,375/month

Total: $4,375/month = $52,500/year

vs. Hot-only: $18,250/month = $219,000/year
Savings: 76% ($166,500/year)

詳細な保持ポリシーとコスト最適化については、次を参照してください:

• references/log-retention-policies.md
• references/cost-optimization.md
• scripts/cost-calculator.py

記録すべきもの（セキュリティイベント）

重要なイベント（必ず記録）:

• 認証: ログイン試行、MFA、パスワード変更、特権昇格
• 認可: 権限変更、ロール変更、アクセス拒否
• データアクセス: 機密データベース/ファイルへのアクセス、API 呼び出し、エクスポート
• ネットワーク: 接続、ファイアウォール拒否、VPN、DNS クエリ
• システム: サービス変更、設定変更、ソフトウェアのインストール

重大度レベル: 認証失敗（3 回以上）: HIGH アラート | 特権昇格: CRITICAL アラート | データエクスポート: HIGH アラート | 設定変更: MEDIUM（アラートなし）

アラートのチューニングとノイズ削減

アラートのライフサイクル

1. 検出ルールの作成 - 保守的なしきい値、本番環境にデプロイ
2. ベースライン期間（2〜4 週間） - アラートデータを収集し、真陽性/偽陽性をタグ付け
3. チューニングフェーズ - ホワイトリストの追加、しきい値の調整、相関の改良
4. 継続的改善 - 週次のメトリクスレビュー、月次の有効性レビュー

ノイズ削減テクニック

ホワイトリスト（既知の安全なパターン）:

# Example: Allow scanner IPs
- rule_id: brute_force_detection
  whitelist:
    - source_ip: "10.0.0.100"  # Security scanner
    - user_agent: "Nagios"      # Monitoring system

しきい値のチューニング:

# Before: Too sensitive (500 alerts/day, 5% true positive rate)
- rule: failed_login_attempts
  threshold: 3 attempts in 5 minutes

# After: Tuned (50 alerts/day, 40% true positive rate)
- rule: failed_login_attempts
  threshold: 10 attempts in 10 minutes

マルチイベント相関:

# Instead of: Single event alert
- alert_on: "Failed authentication"

# Use: Correlated pattern
- alert_on:
    - "Failed authentication (5+ times)"
    - AND "From new IP address"
    - AND "Successful authentication follows"
    - WITHIN: 30 minutes

目標とするアラートメトリクス

メトリクス	目標
アラート総数/日	<100
真陽性率	>30%
平均調査時間	<15 分
偽陽性率	<50%
重大アラート数/日	<10

包括的なアラートチューニング戦略については、references/alert-tuning-strategies.md を参照してください。

クイックスタート

Wazuh をデプロイする： git clone https://github.com/wazuh/wazuh-docker.git && cd wazuh-docker/single-node && docker-compose up -d（examples/architectures/wazuh-docker-compose.ymlを参照）

SIGMA ルールを作成する： SSH のブルートフォース検知テンプレートについては、examples/sigma-rules/brute-force-detection.ymlを参照してください。

Elastic Cloud： cloud.elastic.co で登録し、Security ティアのデプロイメントを作成して、エンドポイントに Elastic Agent をインストールします。

関連スキルとの連携

observability スキル：

• セキュリティログを SIEM に、パフォーマンスログをオブザーバビリティプラットフォームに送信します
• ログ集約インフラストラクチャを共有します（Fluentd／Logstash）
• 分析目的は異なります（セキュリティ対パフォーマンス）

incident-management スキル：

• SIEM アラートによってインシデント対応ワークフローを開始します
• PagerDuty、Opsgenie、ServiceNow と連携します
• 重大なセキュリティイベントについてインシデントを自動作成します

security-hardening スキル：

• SIEM でセキュリティ構成とコンプライアンスを監視します
• CIS ベンチマークからの構成ドリフトを検知します
• セキュリティポリシー違反をアラートで通知します

building-ci-pipelines スキル：

• CI／CD のセキュリティイベント（デプロイ、シークレットへのアクセス）を記録します
• GitHub Actions／GitLab CI と SIEM を連携します
• サプライチェーンのセキュリティを監視します

secret-management スキル：

• シークレットへのすべてのアクセス操作を監査します
• HashiCorp Vault／AWS Secrets Manager のログを SIEM に送信します
• 不正なシークレットアクセスの試行を検知します

参考ドキュメント

詳細ガイド

• references/platform-comparison.md - SIEM プラットフォーム機能の包括的な比較
• references/detection-rules-guide.md - 検知ルールの形式（SIGMA、EQL、KQL、SPL）
• references/log-retention-policies.md - コンプライアンス要件と保持戦略
• references/cloud-native-logging.md - AWS、Azure、GCP、Kubernetes のロギング設定
• references/alert-tuning-strategies.md - 誤検知の削減とアラートの最適化
• references/cost-optimization.md - ストレージの階層化とコスト管理

実用例

• examples/sigma-rules/ - 汎用 SIGMA 検知ルール（10 件以上の例）
• examples/elastic-eql/ - Elastic Event Query Language クエリ
• examples/microsoft-kql/ - Microsoft Sentinel の Kusto クエリ
• examples/splunk-spl/ - Splunk Search Processing Language
• examples/architectures/ - 完全なデプロイ例（Docker、Kubernetes、Terraform）
• examples/logstash-pipelines/ - Logstash パイプライン構成

ユーティリティスクリプト

• scripts/sigma-to-elastic.sh - SIGMA ルールを Elastic EQL に変換します
• scripts/cost-calculator.py - データ量と保持期間に基づいて SIEM コストを見積もります

公式ドキュメント

• Elastic SIEM： https://www.elastic.co/security
• Microsoft Sentinel： https://azure.microsoft.com/en-us/products/microsoft-sentinel
• Wazuh： https://wazuh.com/
• Splunk Enterprise Security： https://www.splunk.com/en_us/products/enterprise-security.html
• SIGMA ルールリポジトリ： https://github.com/SigmaHQ/sigma
• MITRE ATT&CK Framework： https://attack.mitre.org/