01 - 検出エンジニアリング: 規律からスクリプト、パイプラインまで
進化し続けるサイバー脅威の状況において、 検出する 重大な損害を引き起こす前の悪意のあるアクティビティは、 回復力のある組織と脆弱な組織。何十年もの間、脅威の検出は アドホックな文書化されたルール、ウイルス対策署名、および SOC アナリストの個人的な直感に委ねられています。今日、 この職人技的なアプローチは、丸太の量、複雑さなどにより、もはや持続可能ではありません。 クラウドネイティブのインフラストラクチャと攻撃者の高度化にはアプローチが必要 工学的かつ体系的な.
こうして誕生したのです 検出工学: 原則を適用する学問 ソフトウェアエンジニアリングからソフトウェアの作成、テスト、展開、保守のプロセスまで 検出ルール。もはや SIEM で個別のクエリを記述することではなく、構築することが重要です。 自動化されたパイプライン、検出をコードとしてバージョン管理し、データを使用してテストします それらをシミュレートし、客観的な指標で測定します。
この記事で学べること
- 検出エンジニアリングとは何ですか、そしてなぜそれが自律的な学問になったのか
- アドホック スクリプトから検出用の CI/CD パイプラインへの進化
- 検出の完全なライフサイクル: 仮説、開発、テスト、展開、調整
- 主な検出タイプ: シグネチャベース、動作ベース、異常ベース
- 品質指標: 真陽性率、偽陽性率、MTTD、MTTR
- SIEM/SOAR エコシステムと主要なデータ ソース
- セキュリティ ルールのコードとしての検出と CI/CD パイプラインの概念
- シグマ ルール、Python スクリプト、YAML 構成を使用した実践的な例
検出工学とは
La 検出工学 設計、開発の体系的なプロセス、 テレメトリ内の悪意のあるアクティビティを特定するロジックのテストとメンテナンス 組織の。このテレメトリには、エンドポイント、クラウド インフラストラクチャ、 ID プロバイダー、Web アプリケーション、ネットワーク システムなど。
SOC アナリストが SIEM にクエリを書き込む従来のアプローチとは異なります。 特定のインシデントに対応して、Detection Engineering は ワークフロー 構造化された 現代のソフトウェア開発を彷彿とさせます: コードのバージョン管理、コード レビュー、 自動化されたテスト、継続的な導入、実稼働環境でのパフォーマンス監視。
「SOC に対する検出エンジニアリングは、ソフトウェア エンジニアリングがコーディングに相当するものです。アドホックなコードを変換し、 事後対応的な活動を体系的で測定可能な、継続的に改善する規律に変えます。」
- SANS Institute、2025 年検出工学調査
検出エンジニアリングの 3 本柱
この規律は、その成熟度を定義する 3 つの相互に関連する柱に基づいています。
- 脅威インテリジェンス - 対戦相手が誰で、どのようなテクニックを使用するかを理解する (MITRE ATT&CK)、組織のどの資産が危険にさらされているか。理解が無いままに 脅威の深さが深い場合、検出は一般的なものになり、あまり効果的ではなくなります。
- データエンジニアリング - 必要なログが収集され、正規化されていることを確認します。 そして分析に利用できます。操作対象のデータが正しくない場合、完璧で役に立たない検出 存在するか、品質が悪い。
- ソフトウェアエンジニアリング - ソフトウェア開発のベスト プラクティスを適用します。 バージョン管理、テスト、CI/CD、ドキュメント、メトリクス。検出された場合は対処する必要があります プロダクションコードとして。
進化: アドホック スクリプトからエンジニアリング分野へ
現代の検出エンジニアリングに至るまでの道のりは 4 つに分けられます。 異なるフェーズに分かれており、それぞれのフェーズは成熟度と自動化のレベルが高まっていることを特徴としています。
フェーズ 1: 署名の時代 (1990 ～ 2005 年)
初期の検出形式は以下に基づいていました 静的署名: 既知のパターン マルウェア、悪意のあるファイルのハッシュ、ネットワーク ペイロード内の特定の文字列。すべてのウイルス対策と IDS (侵入検知システム) は、定期的に更新されるシグネチャのデータベースを維持しました。 このアプローチは既知の脅威に対してはかなりうまく機能しましたが、完全に顔が見えませんでした。 新しいバリエーションやカスタマイズされた攻撃に対応します。
フェーズ 2: SIEM スクリプトの時代 (2005 ～ 2015)
前者の普及に伴い、 シェムリアップ (セキュリティ情報とイベント管理)、 アナリストはカスタム クエリと相関関係を作成し始めました。各アナリストは、 独自のアプローチ、独自のスクリプト、独自の命名規則。ルールが作成されました SIEM Web インターフェイスで直接、バージョン管理なし、テストなし、ドキュメントなし 標準化された。アナリストが組織を離れると、多くの場合、そのアナリストの検出結果は次のようになります。 後継者には理解不能。
フェーズ 3: 検出エンジニアリングの誕生 (2015 ～ 2022)
2015 年から 2022 年にかけて、セキュリティ コミュニティは、 より構造化されたアプローチ。などの標準フォーマットが誕生します。 シグマ (2017) 検出ルール、フレームワーク マイターアタック&CK 参考になります 対戦相手のテクニックをマッピングするための汎用性と、初の専用の検出チーム エンジニアリングは、より成熟した組織に現れます。
フェーズ 4: コードとしての検出と CI/CD パイプライン (2022 年から現在)
現在、最も先進的な組織は、検出をソフトウェア コードとまったく同じように扱っています。 ルールは宣言形式 (Sigma、YAML) で記述され、Git リポジトリでバージョン管理されます。 シミュレートされたデータを使用して自動的にテストされ、CI/CD パイプライン経由でデプロイされ、監視されます。 専用のダッシュボードを備えています。によると、 SANS 2025 検出エンジニアリング調査、 組織の 60% が専任の検出エンジニアリング チームを維持しており、組織の 70% は 従業員数が 5,000 名を超える企業のうち、すでに構造化されたチームを確立している企業の割合。
| 段階 | 期間 | アプローチ | 楽器 | 限界 |
|---|---|---|---|---|
| 静的署名 | 1990 ～ 2005 年 | 既知の署名のパターン マッチング | ウイルス対策、IDS (Snort) | 目に見えないゼロデイ、高遅延 |
| SIEMスクリプト | 2005-2015 | SIEM のアドホック クエリ | Splunk、ArcSight、QRadar | バージョン管理されておらず、テストされておらず、知識がサイロ化されている |
| 検出工学 | 2015～2022年 | 標準を備えた構造化されたワークフロー | シグマ、ATT&CK、ELK | まだ手作業が多い |
| コードとしての検出 | 2022年～現在 | CI/CD パイプライン、すべてバージョン管理 | Git、CI/CD、シグマ、SOAR | 組織の成熟度が必要 |
検出のライフサイクル
各検出は、品質、有効性、および品質を保証する明確に定義されたライフサイクルに従います。 長期にわたるメンテナンス性。このサイクルは 6 つの基本フェーズで構成されており、それぞれのフェーズは 成果物と特定の品質基準。
1. 仮説（仮説）
すべては 1 つから始まります 脅威仮説。アナリストまたは検出エンジニア 特定の攻撃手法を識別します (例: 「攻撃者が利用する可能性があるのは、 悪意のあるペイロードをダウンロードして実行するための PowerShell」）そしてその方法についての仮説を立てます このアクティビティは、利用可能なログに現れます。仮説のソースには次のものがあります。
- 脅威インテリジェンス - アクティブなキャンペーン、観察された TTP に関するレポート
- マイターアタック&CK - 特定の戦術にマッピングされたテクニック
- 死後の事故 - 過去の事件から学んだ教訓
- レッドチームの調査結果 - 侵入テストとパープル チーミングの結果
- ギャップ分析 - 検出範囲のない ATT&CK テクニック
2.開発（開発）
仮説を定義したら、検出エンジニアは検出ルールを作成します。これ 形式 (シグマ、SIEM ネイティブ クエリ、Python スクリプト) の選択、定義が含まれます。 必要なソース ログ、選択およびフィルタリング ロジック、およびドキュメントのドキュメント メタデータ (作成者、重大度、ATT&CK マッピング、既知の誤検知)。
3. テストと検証 (テスト)
導入前に、実際のデータとシミュレートされたデータに対して検出を検証する必要があります。 テストには次のものが含まれます。 真陽性検査 (ルールはシミュレートされた攻撃を検出しますか?)、 偽陽性検査 (ルールは正当なアクティビティに対してアラートを生成しますか?)、e パフォーマンステスト (このルールは、 制作ログ?)。
4. 導入
導入は、ルールを形式に変換する自動パイプラインを通じて行われます。 ターゲット SIEM にネイティブであり、実稼働環境にデプロイして、その正確性を検証します。 操作。成熟した環境では、このプロセスは CI/CD によって完全に自動化されます。
5. モニタリングとメトリクス
本番環境に入ると、検出は常に監視されます。主要な指標 生成されたアラートの量、真陽性/偽陽性の比率、平均時間が含まれます。 検出 (MTTD)、および SOC アナリストの負荷への影響。
6. チューニングとメンテナンス
本番環境で収集されたデータに基づいて、検出は継続的に改良されます。の チューニングには、再発する誤検知に対する例外の追加、範囲の拡大などが含まれる場合があります。 テクニックのバリエーション、またはそれ以上ではないにしてもルールの非推奨をカバーするためのロジックの追加 関連性のある。
ベスト プラクティス: パープル チーミング
Il 紫色のチーミング のフィードバック ループを大幅に加速します。 検出ライフサイクル。レッドチームの攻撃スキルと防御スキルを組み合わせる ブルー チームの場合、実際の攻撃手法をシミュレートし、検出を検証することが可能です。 リアルタイムなので、仮説から検証された検出までの時間が数週間から数時間に短縮されます。
検出の種類: IOC から動作まで
検出は、使用される検出ロジックに基づいて分類できます。 各タイプには特定の利点と制限があり、成熟した検出プログラムはそれらを組み合わせます。 すべて階層化された方法で。
1. シグネチャベースの検出
シグネチャベースの検出検索 正確なパターン データ内: ファイルハッシュ コマンド内の既知の特定の文字列、IP アドレス、または既知の悪意のあるドメイン (IOC - インジケーター) 妥協の)。最もシンプルかつ高速なタイプで、誤検知率が非常に低いですが、 新しい脅威や亜種の脅威に対してはまったく効果がありません。
title: Emotet Loader Hash Detection
id: a1b2c3d4-e5f6-7890-abcd-ef1234567890
status: stable
description: Detects known Emotet loader by file hash
author: Detection Engineering Team
date: 2025/10/15
references:
- https://attack.mitre.org/software/S0367/
logsource:
category: file_event
product: windows
detection:
selection:
Hashes|contains:
- 'SHA256=e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855'
- 'SHA256=a7ffc6f8bf1ed76651c14756a061d662f580ff4de43b49fa82d80a4b80f8434a'
- 'MD5=d41d8cd98f00b204e9800998ecf8427e'
condition: selection
falsepositives:
- Unlikely, known malicious hashes
level: critical
tags:
- attack.execution
- attack.t1204.0022. 行動の検出
行動検出で求められるのは アクションシーケンス またはのパターン 特定の IOC に関係なく、不審なアクティビティを示す動作。 たとえば、Mimikatz の特定のハッシュを探す代わりに、動作検出 資格情報を抽出するために LSASS メモリにアクセスするプロセスを探すことができます。 このアプローチは、攻撃者が変更できるため、回避に対する耐性がはるかに高くなります。 独自のツールはありますが、基礎となる技術をほとんど変更することはできません。
title: Suspicious LSASS Process Access - Credential Dumping
id: b2c3d4e5-f6a7-8901-bcde-f12345678901
status: experimental
description: |
Detects process access to LSASS memory, a common technique
for credential dumping (T1003.001). Focuses on behavior
rather than specific tool signatures.
author: Federico Calo
date: 2025/11/20
references:
- https://attack.mitre.org/techniques/T1003/001/
logsource:
category: process_access
product: windows
detection:
selection:
TargetImage|endswith: '\lsass.exe'
GrantedAccess|contains:
- '0x1010' # PROCESS_QUERY_LIMITED_INFORMATION + PROCESS_VM_READ
- '0x1038' # Read memory access
- '0x1FFFFF' # PROCESS_ALL_ACCESS
filter_legitimate:
SourceImage|endswith:
- '\MsMpEng.exe' # Windows Defender
- '\csrss.exe' # Client Server Runtime
- '\wmiprvse.exe' # WMI Provider
- '\svchost.exe' # Service Host
filter_system:
SourceUser|contains: 'SYSTEM'
SourceImage|startswith: 'C:\Windows\System32\'
condition: selection and not filter_legitimate and not filter_system
falsepositives:
- Legitimate security tools performing memory scanning
- EDR solutions with high-privilege access
level: high
tags:
- attack.credential_access
- attack.t1003.0013. 異常ベースの検出
異常ベースの検出により、 正常性のベースライン e 重大な逸脱を報告します。たとえば、ユーザーが通常、 営業時間中にイタリアに拠点を置く場合、午前 3 時に中国からログインすると、 異常です。このアプローチでは、まったく未知の (ゼロデイ) 脅威を検出できます。 ただし、特に動的環境では、より多くの誤検知が発生する傾向があります。
4. 脅威ハンティング
脅威ハンティングはプロセスです 積極的かつ仮説主導型 その中で、 アナリストは、自動検出を逃れた可能性のある脅威を積極的に探します。 自動検出とは異なり、脅威ハンティングは探索的なものであり、多くの場合、 新しい検出はコード化され、自動化されます。
| 検出タイプ | 精度 | ゼロデイカバレッジ | 誤検知 | メンテナンス | Esempio |
|---|---|---|---|---|---|
| 署名ベース | 非常に高い | なし | 非常に低い | 高 (IOC を更新) | ハッシュファイル、悪意のあるIP |
| 行動的 | 高い | 良い | 穏健派 | 平均 | LSASS アクセス、横方向の移動 |
| 異常ベース | 変数 | 素晴らしい | 高い | 高 (ベースラインチューニング) | 異常なログイン、異常なトラフィック |
| 脅威ハンティング | 非常に高い | 素晴らしい | 最小値（手動） | 高 (アナリストが必要) | 探索的分析、仮説 |
検出の品質指標
そうでない場合、検出は役に立ちません。 測定可能な。品質指標 検出ルールの有効性を評価し、プロセスをガイドできるようにします 検出エンジニアリング プログラムへの投資を調整し、正当化する。
基本的な運用指標
| メトリック | 説明 | ターゲット | 改善方法 |
|---|---|---|---|
| MTTD (平均検出時間) | 悪意のあるアクティビティの瞬間からアラートが生成されるまでの平均時間 | 4 時間未満 (トップチーム: 30 分未満) | ログカバレッジの向上、リアルタイム検出 |
| MTTR (平均応答時間) | 検出から封じ込め/解決までの平均時間 | 4時間未満 | SOAR オートメーション、定義されたプレイブック |
| 真陽性率 (TPR) | 実際の脅威に対応するアラートの割合 | クリティカルで > 80%、高で > 60% | 継続的なチューニング、高度なフィルタリング |
| 誤検知率 (FPR) | 正当なアクティビティに対して生成されたアラートの割合 | クリティカルの場合 < 25% | ホワイトリスト、強化されたコンテキスト、相関関係 |
| 偽陰性率 (FNR) | 検出されなかった本当の脅威の割合 | < 1% | パープル チーミング、脅威ハンティング |
| ATT&CK の対象範囲 | 少なくとも 1 つの検出でカバーされる MITRE ATT&CK 技術の割合 | > 関連技術の 70% | 定期的なギャップ分析、優先順位付け |
検出スコアの計算
検出プログラムの全体的な品質を評価するための実践的なアプローチと 検出成熟度スコア、複数の指標を 1 つのスコアに結合します 正規化された。 Python での計算例を次に示します。
from dataclasses import dataclass
from typing import List
@dataclass(frozen=True)
class DetectionMetrics:
"""Immutable snapshot of detection performance metrics."""
rule_id: str
true_positives: int
false_positives: int
false_negatives: int
total_alerts: int
avg_detection_time_minutes: float # MTTD
avg_response_time_minutes: float # MTTR
@property
def precision(self) -> float:
"""TP / (TP + FP) - How many alerts are real threats."""
denominator = self.true_positives + self.false_positives
return self.true_positives / denominator if denominator > 0 else 0.0
@property
def recall(self) -> float:
"""TP / (TP + FN) - How many real threats are caught."""
denominator = self.true_positives + self.false_negatives
return self.true_positives / denominator if denominator > 0 else 0.0
@property
def f1_score(self) -> float:
"""Harmonic mean of precision and recall."""
p, r = self.precision, self.recall
return 2 * (p * r) / (p + r) if (p + r) > 0 else 0.0
def calculate_maturity_score(metrics_list: List[DetectionMetrics]) -> dict:
"""Calculate overall detection program maturity score.
Returns an immutable dict with aggregated metrics.
"""
if not metrics_list:
return {"score": 0, "grade": "F", "details": {}}
avg_precision = sum(m.precision for m in metrics_list) / len(metrics_list)
avg_recall = sum(m.recall for m in metrics_list) / len(metrics_list)
avg_f1 = sum(m.f1_score for m in metrics_list) / len(metrics_list)
avg_mttd = sum(m.avg_detection_time_minutes for m in metrics_list) / len(metrics_list)
avg_mttr = sum(m.avg_response_time_minutes for m in metrics_list) / len(metrics_list)
# Weighted maturity score (0-100)
precision_score = avg_precision * 25 # 25% weight
recall_score = avg_recall * 25 # 25% weight
f1_component = avg_f1 * 20 # 20% weight
mttd_score = max(0, (240 - avg_mttd) / 240) * 15 # 15% weight (240min = 4h target)
mttr_score = max(0, (240 - avg_mttr) / 240) * 15 # 15% weight
total_score = (precision_score + recall_score + f1_component
+ mttd_score + mttr_score) * 100
grade_thresholds = [
(90, "A"), (80, "B"), (70, "C"), (60, "D")
]
grade = next(
(g for threshold, g in grade_thresholds if total_score >= threshold),
"F"
)
return {
"score": round(total_score, 1),
"grade": grade,
"details": {
"avg_precision": round(avg_precision, 3),
"avg_recall": round(avg_recall, 3),
"avg_f1": round(avg_f1, 3),
"avg_mttd_minutes": round(avg_mttd, 1),
"avg_mttr_minutes": round(avg_mttr, 1),
"total_rules_evaluated": len(metrics_list),
},
}
# Esempio di utilizzo
sample_metrics = [
DetectionMetrics("SIGMA-001", 45, 5, 2, 50, 15.0, 35.0),
DetectionMetrics("SIGMA-002", 120, 30, 8, 150, 8.5, 22.0),
DetectionMetrics("SIGMA-003", 200, 15, 5, 215, 3.2, 12.0),
]
result = calculate_maturity_score(sample_metrics)
print(f"Detection Maturity Score: {result['score']} ({result['grade']})")
print(f"Details: {result['details']}")注意: バニティメトリクス
検出プログラムの成功を測定することは避けてください。 総数 ルールの または 生成されたアラートの数。これらは指標です 深刻な問題を覆い隠してしまう可能性がある虚栄心の指標。 50人いる組織 忠実度の高い検出であり、生成される 5,000 のルールよりもはるかに安全です。 何千もの誤検知が発生し、アナリストの警戒疲れを引き起こしています。
SIEM/SOAR エコシステム
Il シェムリアップ （セキュリティ情報とイベント管理）と心 検出エンジニアリングインフラストラクチャの。そして、収集し、正規化するプラットフォームは、 組織内のすべてのソースからのログを関連付けて分析します。の 舞い上がる (セキュリティ オーケストレーション、自動化、および対応) が SIEM を補完します 事前定義されたプレイブックを通じてアラートへの応答を自動化します。
主要な SIEM プラットフォームの概要
| プラットフォーム | タイプ | クエリ言語 | 強み | 理想的な使用例 |
|---|---|---|---|---|
| Splunk エンタープライズ | オンプレミス/クラウド | SPL | 成熟度、アプリのエコシステム、柔軟性 | 複雑な企業、成熟した SOC |
| 弾性SIEM | オープンソース / クラウド | KQL / EQL / ES|QL | オープンソース、スケーラビリティ、コスト | 低予算のクラウドネイティブ チーム |
| マイクロソフトセンチネル | クラウド(アズール) | KQL | Azure/M365統合、AI内蔵 | Microsoft中心の組織 |
| Google SecOps (クロニクル) | クラウド（GCP） | ヤラ・エル | 無制限の保持、スピード | 大量のデータ、GCP |
| CrowdStrike Falcon LogScale | Cloud | LogScale クエリ | 急速摂取、圧縮 | クラウドストライク組織 |
| 相撲ロジック | Cloud | Sumo ロジック クエリ | ネイティブ SaaS、使いやすさ | クラウドファースト、SaaS重視 |
基本的なデータソース
検出の品質はデータの品質と完全性に直接依存します。 利用可能です。効果的な検出プログラムの基本的なデータ ソースは次のとおりです。
- エンドポイントテレメトリ - プロセス ログ、ファイル システム イベント、レジストリの変更、 ネットワーク接続。出典: EDR (CrowdStrike、SentinelOne、Microsoft Defender)、Sysmon
- ネットワークテレメトリー - NetFlow、DNS クエリ、HTTP/TLS メタデータ、PCAP 選択的。ソース: ファイアウォール、IDS/IPS、プロキシ、DNS リゾルバー
- アイデンティティとアクセス - 認証イベント、権限昇格、 グループのメンバーシップが変更されます。ソース: Active Directory、Entra ID、Okta、CyberArk
- クラウド監査ログ - API 呼び出し、構成変更、リソースの作成。 ソース: AWS CloudTrail、Azure アクティビティ ログ、GCP 監査ログ
- アプリケーションログ - Webサーバーのアクセスログ、アプリケーションエラー、WAFイベント。 ソース: Nginx、Apache、CloudFront、カスタム アプリケーション
- 電子メールセキュリティ - フィッシングの試み、悪意のある添付ファイル、BEC の検出。 ソース: Microsoft Defender for O365、Proofpoint、Mimecast
データの正規化: 目に見えない基盤
それなし データの正規化、検出は壊れやすく、ポータブルではありません。
すべての SIEM とすべてのソースは、同じ概念、つまり「ログイン失敗」に対して異なる形式を使用します。
のように見えるかもしれません EventID 4625 Windows では、 sshd: Failed password
Linux の場合、または {"eventType": "user.session.start", "outcome": "FAILURE"}
オクタで。次のような正規化スキームを採用します。 ECS (エラスティック共通スキーマ),
OCSF (オープン サイバーセキュリティ スキーマ フレームワーク) または Sigma のデータ モデルにより、
検出を 1 回だけ書き込み、任意のソースに適用します。
コードとしての検出: 現代のパラダイム
コードとしての検出 (DaC) 開発プラクティスを適用したアプローチ 検出ルールを管理するためのソフトウェア。ルールを作成および変更する代わりに SIEM グラフィカル インターフェイスを介して、検出はコードとして記述され、バージョン管理されます。 Git リポジトリ内で、プル リクエストによるコード レビューの対象となり、自動的にテストされます CI/CD パイプラインを通じて配信されます。
コードとしての検出の利点
従来のアプローチとの比較
- バージョン管理 - すべての変更は Git で追跡され、ロールバックの可能性があります
- コードレビュー - 検出は展開前にピアレビューを受けます
- 自動テスト - 正および負のデータによる自動検証
- 再現性 - 検出の全体的なステータスをリポジトリから再構築できます。
運用上のメリット
- スピード - 検出は数日ではなく数分で本番環境に移行します
- 一貫性 - 品質基準が均一に適用される
- 監査証跡 - コンプライアンスのための完全なトレーサビリティ
- コラボレーション - 複数のチームが同じリポジトリに貢献できる
コードとしての検出リポジトリの構造
detections/
rules/
credential_access/
lsass_memory_access.yml
brute_force_login.yml
kerberoasting.yml
execution/
powershell_encoded_command.yml
suspicious_wmi_execution.yml
lateral_movement/
psexec_usage.yml
rdp_from_unusual_source.yml
persistence/
scheduled_task_creation.yml
registry_run_key.yml
tests/
credential_access/
lsass_memory_access_test.json
brute_force_login_test.json
execution/
powershell_encoded_command_test.json
config/
sigma_config.yml
siem_mappings.yml
exclusions.yml
pipelines/
ci.yml
cd.yml
docs/
CONTRIBUTING.md
STYLE_GUIDE.md
REVIEW_CHECKLIST.md
README.md検出用の CI/CD パイプライン
CI/CD 検出パイプラインは、コミットから運用までのプロセス全体を自動化します。 GitHub Actions の設定例を次に示します。
name: Detection CI/CD Pipeline
on:
pull_request:
paths: ['rules/**', 'tests/**']
push:
branches: [main]
paths: ['rules/**']
jobs:
validate:
name: Validate Sigma Rules
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install sigma-cli
run: pip install sigma-cli pySigma-backend-splunk pySigma-backend-elasticsearch
- name: Lint Sigma Rules
run: |
sigma check rules/ --validation-config config/sigma_config.yml
echo "All rules pass validation"
- name: Verify ATT&CK Mapping
run: |
python scripts/verify_attack_tags.py rules/
echo "All rules have valid ATT&CK mappings"
test:
name: Test Detection Logic
needs: validate
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run True Positive Tests
run: |
python scripts/run_tests.py \
--rules-dir rules/ \
--tests-dir tests/ \
--test-type true_positive
- name: Run False Positive Tests
run: |
python scripts/run_tests.py \
--rules-dir rules/ \
--tests-dir tests/ \
--test-type false_positive
- name: Generate Coverage Report
run: python scripts/coverage_report.py --output reports/coverage.json
deploy:
name: Deploy to SIEM
needs: test
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
environment: production
steps:
- uses: actions/checkout@v4
- name: Convert Sigma to Splunk SPL
run: |
sigma convert \
--target splunk \
--pipeline splunk_windows \
rules/ \
--output converted/splunk/
- name: Deploy to Splunk via API
env:
SPLUNK_TOKEN: ${{ secrets.SPLUNK_API_TOKEN }}
SPLUNK_URL: ${{ secrets.SPLUNK_URL }}
run: |
python scripts/deploy_splunk.py \
--rules-dir converted/splunk/ \
--splunk-url "$SPLUNK_URL" \
--token "$SPLUNK_TOKEN"
- name: Update ATT&CK Coverage Map
run: python scripts/update_attack_coverage.py完全なコードとしての検出フロー
- 検出エンジニアは Git ブランチに新しい Sigma ルールを作成します
- ルールと関連テストを含むプルリクエストを開きます
- CI パイプラインは構文検証、TP/FP テスト、ATT&CK マッピング検証を実行します。
- 査読者はロジック、文書、適用範囲をチェックした後、PR を承認します。
- main にマージすると、ルールを変換して SIEM に配布する CD パイプラインがアクティブになります。
- 監視ダッシュボードは実稼働環境での検出パフォーマンスを追跡します
効果的な検出の作成: 原則とパターン
平凡な検出と優れた検出の違いは検出の深さにあります 誤検知フィルタリングの品質における攻撃手法の理解 そしてドキュメントの完全性においても。基本原則は次のとおりです。
原則 1: ツールではなくテクニックから始める
「Mimikatz」の検出を書き込まないでください。「Mimikatz」の検出を書きます。 技術 di LSASS メモリ アクセスによる認証情報のダンプ (T1003.001)。このアプローチはそれをカバーします 同じ手法を実装するすべてのツール (これらを含む) が自動的に実行されます。 将来はまだわかりません。
原則 2: レイヤー検出 (検出ピラミッド)
同じ手法に対してマルチレベル検出を実装します。ハッシュベースの検出 (簡単に回避可能) はまだ洗練されていない攻撃者を捕らえることができますが、 行動検出は、より高度な行動検出を捕捉します。この多層的なアプローチと として知られている 徹底的な検出.
原則 3: 常にコンテキストを文書化する
各検出には次のものが含まれている必要があります。 モチベーション (なぜこの検出が 存在します）、 ATT&CK マッピング (どのテクニックがカバーされていますか)、私は 偽 既知の陽性反応 (どの正当なアクティビティがルールをトリガーする可能性があるか)、および 応答プレイブック (検出がトリガーされたときにアナリストが実行する必要があること)。
完全な例: ログ分析 Python による検出
"""
Brute Force Detection Module
MITRE ATT&CK: T1110.001 - Brute Force: Password Guessing
Detects multiple failed login attempts followed by a success.
"""
from dataclasses import dataclass, field
from datetime import datetime, timedelta
from collections import defaultdict
from typing import Optional
@dataclass(frozen=True)
class LoginEvent:
"""Immutable representation of a login event."""
timestamp: datetime
username: str
source_ip: str
success: bool
service: str # 'ssh', 'rdp', 'web', 'vpn'
@dataclass(frozen=True)
class BruteForceAlert:
"""Immutable alert generated by the detector."""
username: str
source_ip: str
failed_count: int
time_window_minutes: int
first_attempt: datetime
last_attempt: datetime
successful_login: bool
severity: str # 'medium', 'high', 'critical'
mitre_technique: str = "T1110.001"
@dataclass(frozen=True)
class DetectionConfig:
"""Immutable configuration for brute force detection."""
failed_threshold: int = 5
time_window_minutes: int = 10
lockout_threshold: int = 20
whitelist_ips: tuple = ()
monitored_services: tuple = ('ssh', 'rdp', 'web', 'vpn')
class BruteForceDetector:
"""Stateless brute force detection engine.
Analyzes login events and produces alerts when
brute force patterns are detected.
"""
def __init__(self, config: Optional[DetectionConfig] = None):
self._config = config or DetectionConfig()
def analyze(self, events: list[LoginEvent]) -> list[BruteForceAlert]:
"""Analyze a batch of login events for brute force patterns.
Returns a new list of alerts (no mutation of input).
"""
# Group events by (source_ip, username)
grouped = defaultdict(list)
for event in events:
if (event.service in self._config.monitored_services
and event.source_ip not in self._config.whitelist_ips):
key = (event.source_ip, event.username)
grouped[key].append(event)
alerts = []
for (source_ip, username), user_events in grouped.items():
sorted_events = sorted(user_events, key=lambda e: e.timestamp)
alert = self._check_brute_force(source_ip, username, sorted_events)
if alert is not None:
alerts.append(alert)
return alerts
def _check_brute_force(
self, source_ip: str, username: str, events: list[LoginEvent]
) -> Optional[BruteForceAlert]:
"""Check if events match a brute force pattern."""
window = timedelta(minutes=self._config.time_window_minutes)
failed_events = [e for e in events if not e.success]
if len(failed_events) < self._config.failed_threshold:
return None
# Check if failures cluster within the time window
for i, start_event in enumerate(failed_events):
window_end = start_event.timestamp + window
window_failures = [
e for e in failed_events[i:]
if e.timestamp <= window_end
]
if len(window_failures) >= self._config.failed_threshold:
# Check for subsequent successful login
success_after = any(
e.success and e.timestamp >= start_event.timestamp
for e in events
)
severity = self._calculate_severity(
len(window_failures), success_after
)
return BruteForceAlert(
username=username,
source_ip=source_ip,
failed_count=len(window_failures),
time_window_minutes=self._config.time_window_minutes,
first_attempt=window_failures[0].timestamp,
last_attempt=window_failures[-1].timestamp,
successful_login=success_after,
severity=severity,
)
return None
def _calculate_severity(self, failed_count: int, success: bool) -> str:
"""Determine alert severity based on pattern characteristics."""
if success and failed_count >= self._config.lockout_threshold:
return "critical" # Many failures + success = likely compromised
if success:
return "high" # Fewer failures + success = suspicious
if failed_count >= self._config.lockout_threshold:
return "high" # Many failures = active attack
return "medium" # Moderate failures = possible attackMITRE ATT&CK: 参照フレームワーク
枠組み マイターアタック&CK (敵対的な戦術、テクニック、および一般的なもの) 知識) と、対戦相手のテクニックをマッピングして分類するための普遍的なリファレンスです。 ATT&CK は、検出エンジニアリングについて説明するための共通言語を提供します。 cosa を測定するための行列を探します。 カバレッジ 私たちの 検出。
検出エンジニアリングに ATT&CK を使用する方法
- 優先順位付け - すべての ATT&CK テクニックが同じように作成されるわけではありません あなたの組織に関連するもの。対戦相手が最もよく使用するテクニックを特定する あなたのセクター（脅威インテリジェンス）を調査し、それらにリソースを集中させます。
- ギャップ分析 - 既存の検出を ATT&CK 技術にマッピングする カバーされていない領域を表示します。を使用します。 ATT&CKナビゲーター のために 現在のカバレッジを示すヒートマップを作成します。
-
タグ付け - 各シグマと検出ルールには ATT&CK タグが含まれている必要があります
対応する（例：
attack.t1003.001）。これにより、 技術と戦術の指標。 - 測定 - 各戦術でカバーされたテクニックの割合を追跡します (初期アクセス、実行、永続性など)、現実的なカバレッジ目標を定義します。
| 戦術 | テクニックの例 | 主要なデータソース | 検出の困難さ |
|---|---|---|---|
| 初期アクセス | T1566 フィッシング、T1190 公開アプリの悪用 | メール、WAF、プロキシ | 平均 |
| 実行 | T1059 コマンドライン、T1204 ユーザー実行 | Sysmon、EDR、プロセスログ | 低～中 |
| 持続性 | T1053 スケジュールされたタスク、T1547 ブート自動開始 | レジストリ、ファイルシステム、EDR | 平均 |
| 権限昇格 | T1068 エクスプロイト、T1078 有効なアカウント | EDR、ADログ、クラウド監査 | 高い |
| 防御回避 | T1070 インジケーターの削除、T1027 難読化 | EDR、シスモン、AMSI | 非常に高い |
| 資格情報へのアクセス | T1003 OS 資格情報ダンプ、T1110 ブルート フォース | EDR、ADログ、認証ログ | 平均 |
| 横方向の動き | T1021 リモート サービス、T1570 側面ツール転送 | ネットワーク、ADログ、EDR | 高い |
| 窃盗 | T1048 Alt プロトコル経由の漏洩、T1567 Web サービス | DLP、プロキシ、DNS、NetFlow | 非常に高い |
チーム構成と役割
効果的な検出エンジニアリング プログラムにはスキルの組み合わせが必要です それは一人の人間ではめったに見つかりません。チーム構成は以下によって異なります 組織の規模は大きいですが、主要な役割は明確に定義されています。
主な役割
- 検出エンジニア - 中心的な役割。ルールを作成、テスト、保守します 検出の。脅威インテリジェンス、SIEM クエリ言語、スクリプトのスキルが必要 (Python)、およびターゲット プラットフォームのログに精通していること。 2025 年の SANS 調査によると、 組織の 60% には、少なくとも 1 人の専任の検出エンジニアがいます。
- 脅威インテリジェンスアナリスト - 脅威に関するコンテキストを提供します: どの脅威か APT グループが活発に活動しているか、彼らがどのようなテクニックを使用しているか、どのような指標を探す必要があるか。それは彼らに栄養を与える 実用的なインテリジェンスを備えた検出仮説。
- データ エンジニア / ログ アーキテクト - 品質と入手可能性に関する取り組み データの: 新しいログ ソースのオンボーディング、正規化、解析、および管理 収集インフラストラクチャの。
- SOCアナリスト - 検出のエンド ユーザー。フィードバックを提供します アラートの品質の基本: 誤検知が多すぎませんか?アラートは実行不可能ですか? コンテキスト情報が欠落していますか?
- 赤チーム / 紫チーム - 対戦相手のテクニックをシミュレートして検証します 検出。レッドチームのフィードバックは改善のための最も効果的なメカニズムです 報道範囲とルールへの忠実さ。
小規模チームのための組織
すべての組織に専任の検出エンジニアリング チームを置く余裕があるわけではありません。 小規模なセキュリティ チーム (3 ～ 5 人) の場合、推奨されるアプローチは次のとおりです。
- を割り当てる 20～30%の確率で Detection Engineering の SOC アナリストの数
- 採用する シグマコミュニティルール ベースラインとして (SigmaHQ リポジトリ)
- を実装します。 構造化されたフィードバックプロセス アラートトリアージから
- 使用 コードとしての検出 単純なパイプライン (Git + デプロイメント スクリプト) であっても
- 焦点を当てる 10 ～ 15 個の最も関連性の高い ATT&CK テクニック あなたの分野のために
実際のケース: 事故から検出パイプラインまで
説明する概念を具体的にするために、現実的な例を見てみましょう。 ギャップの発見から本番環境での検出までの全パス。
シナリオ: PowerShell でエンコードされたコマンドによる侵害
パープルチームの演習中、レッドチームは悪意のあるペイロードの実行に成功しました。
Base64 エンコードされたコマンドで PowerShell を使用する (-EncodedCommand）。
既存の検出では検索のみを行っていたため、攻撃は検出されませんでした。
一般的なエンコード パターンではなく、既知の PowerShell コマンドの特定の文字列。
ステップ 1: 仮説と分析
検出エンジニアは次の仮説を立てます。 「PowerShell のあらゆる使用
エンタープライズ環境の -EncodedCommand は疑わしいと考えるべきです。
正規のソフトウェアがコマンドをエンコードする必要はほとんどありません。」 分析
過去 30 日間のログの確認: 50,000 回の PowerShell 実行のうち、使用されたのは 12 回のみ
-EncodedCommand、およびすべては既知の IT 自動化スクリプトに起因します。
ステップ 2: シグマの法則
title: Suspicious PowerShell Encoded Command Execution
id: f4a3b2c1-d5e6-7890-abcd-ef0123456789
status: test
description: |
Detects execution of PowerShell with encoded commands (-enc,
-EncodedCommand). Legitimate use is rare in enterprise environments.
Attackers commonly use this to obfuscate malicious payloads.
author: Federico Calo
date: 2025/12/01
modified: 2025/12/15
references:
- https://attack.mitre.org/techniques/T1059/001/
- https://attack.mitre.org/techniques/T1027/010/
logsource:
category: process_creation
product: windows
detection:
selection_powershell:
Image|endswith:
- '\powershell.exe'
- '\pwsh.exe'
selection_encoded:
CommandLine|contains:
- '-enc '
- '-EncodedCommand'
- '-encodedcommand'
- '-ec '
filter_known_automation:
ParentImage|endswith: '\sccm_agent.exe'
User|contains: 'SVC_AUTOMATION'
condition: selection_powershell and selection_encoded and not filter_known_automation
falsepositives:
- SCCM automation scripts (filtered)
- Custom IT automation using encoded commands (add to filter)
level: high
tags:
- attack.execution
- attack.t1059.001
- attack.defense_evasion
- attack.t1027.010ステップ 3: テスト、展開、結果
このルールは、5 つの真陽性シナリオ (エンコードされたコマンドの変形) と 20 のシナリオでテストされます。 偽陰性シナリオ (正当な PowerShell 実行)。パイプライン経由のデプロイ後 CI/CD、最初の 30 日間に、検出により 8 つのアラートが生成されます: 6 つの真陽性 (不審なスクリプト) 分析する)、1 つの誤検知 (フィルターに追加する新しい自動スクリプト) 不正アクセスの発見につながる重大な真陽性が 1 件あります。
測定可能な結果
- 精度: 87.5% (アラート合計 8 件中 7 TP)
- MTTD: 「未検出」から 4.2 分に短縮されました (アラート生成時間の平均)
- ATT&CK の対象範囲: +2 テクニック (T1059.001、T1027.010) がマップに追加されました
- 実際の影響: 1 件の活動的な障害が発見され、45 分以内に封じ込められた
結論と次のステップ
Detection Engineering represents a fundamental paradigm shift in security 稼働中。 It's not just about writing better rules in the SIEM, it's about building ある 完全なエンジニアリングプロセス ライフサイクル全体にわたる of detections: from the threat hypothesis to validation in production.
覚えておくべき重要なポイント:
- 質は量に勝る - 50 個の高忠実度検出を無限に実行可能 アラート ノイズを生成する 5,000 のルールよりも便利です。
- 検出をコードとして扱う - バージョン管理、コードレビュー、自動テスト CI/CD パイプラインはオプションではなく、基本的なものです。
- すべてを測定する - MTTD、MTTR、精度、リコール、ATT&CK カバレッジ。なし 継続的な改善は不可能です。
- まずはテクニックから - 検出を MITRE ATT&CK にマッピングし、集中します 組織に最も関連する技術に関するリソース。
- データ品質への投資 - それがなければ完璧で役に立たない検出 操作するデータ。ログ ソースの正規化とオンボーディングは、 プログラム全体の目に見えない基盤。
次の記事で
シリーズの次の記事では、それらについてさらに詳しく説明します。 シグマの法則: の ポータブル検出を書き込むための標準形式。完全な構文を見てみましょう。 高度なモディファイア、主要な SIEM 用の変換バックエンド、そして私たちは構築します 最も重要な ATT&CK テクニックの完全なルール セット。