はじめに
本記事は、Packt Publishing刊行の技術書 「Automating Security Detection Engineering（セキュリティ検出エンジニアリングの自動化）」 の内容を、エンジニア向けに要約・解説したものです。
サイバーセキュリティの文脈で「検出エンジニアリング」という領域が急速に注目を集めています。SIEM・EDR・NIDSといったエンタープライズセキュリティツールに対して、検出ルール（ユースケース）を設計・テスト・デプロイする一連のプロセスを、ソフトウェア開発と同様に自動化するのがこの分野の本質です。
本書は全3パート・10章構成で、実践的なラボを通じて概念を体得できる設計になっています。
パート1：検出入力と展開の自動化
第1章：コードアーキテクチャとライフサイクルとしての検出
検出ライフサイクルとは
フレームワークなしで検出ルールを作成すると、時間の経過とともにカバレッジにギャップが生じます。本書では検出ライフサイクルを以下の5フェーズで整理しています。
- 要件を確立する — TTPのスコープ設定と優先順位付け
- 開発（Development） — ロジックの設計と実装
- テスト（Test） — ユニットテスト・統合テスト
- 実装（Implementation） — CI/CDパイプラインによるデプロイ
- 廃止（Retirement） — 定期評価とアーカイブ
優先順位付けにはMITRE ATT&CKフレームワークが有効で、TTP識別子（例：T1562.001）をYAMLメタデータに付与することで、カバレッジを定量的に追跡できます。
tags:
mitre_attack_id:
- T1562
- T1562.001
コードとしての検出に必要な技術コンポーネント
| コンポーネント | 役割 |
|---|---|
| バージョン管理システム（VCS） | GitHubなどのCI/CDランナー付きサービス |
| APIサポート | SIEM・EDRへのCRUD操作を提供するRESTful API |
| ユースケース構文 | YARA、YARA-L、Splunk SPL、KQLなど |
| テスト計装 | Python/pytest、GoLangなどでの自動テスト |
| シークレット管理 | HashiCorp Vault、AWS Secrets ManagerなどAPIキーの安全な管理 |
MVPチェックリスト
| プログラムコンポーネント | 意思決定の例 |
|---|---|
| ユースケースの対象範囲 | SIEM・EDR・クラウドワークロードなどAPIサポートが確認できるもの |
| CI/CDスタック | GitHub Teams（クラウド版）など低コストで始められるもの |
| テストの成熟度 | 最初はリンティングとユニットテストのみ |
| レビュー段階 | プルリクエスト承認者を1名以上必須とする |
ポイント
「パイプラインなし」より「シンプルなパイプラインあり」の方が価値があります。段階的な自動化から始めることが推奨されています。
第2章：脅威情報に基づく防御入力のスコープ設定と自動化
脅威インテリジェンスの種類と自動化の難易度
| タイプ | 例 | 自動化難易度 |
|---|---|---|
| IOC（侵害指標） | IPアドレス・ドメイン・ハッシュ | 低 |
| IOA（攻撃指標） | エクスプロイトペイロード | 中 |
| TTP（戦術・技術・手順） | 行動パターン | 高 |
人員やリソースが限られている組織では、シンプルなIOCから着手し、段階的にTTPへと進む戦略が推奨されています。
主要な無料脅威インテリジェンスソース
| ソース | 用途 |
|---|---|
| Threatview.io | ドメイン・ハッシュベースのIOC |
| SigmaHQ | ベンダー非依存のエクスプロイトルール |
| CISAアドバイザリ（STIX2 JSON形式） | TTPの詳細とIOC |
ハンズオンラボの概要
本章のラボでは以下を段階的に実装しています。
- ラボ2.1：CISAのSTIX2 JSON形式アドバイザリをPythonで解析するカスタムパーサー作成
-
ラボ2.2：解析したドメインリストをFlaskでホストし、pfSenseの
pfBlockerNGに自動連携してDNSブロックリストとして適用 - ラボ2.3：ThreatviewのハッシュフィードをWazuh EDRのCDBリスト形式に変換して取り込み
- ラボ2.4（オプション）：CrowdStrike FalconPy SDKを使ってIOCをプログラム的にデプロイ
- ラボ2.5：Google Chronicle（パブリックサンドボックス）でのYARA-L検出とIOC相関分析
CISAのSTIX2 JSONを解析し、ドメインをファイルに書き出す処理のイメージは以下のとおりです。
def ioc_extract(url_arg):
cisa_feed = requests.get(url_arg)
json_payload = cisa_feed.json()
domain_list = []
for obj in json_payload["objects"]:
if obj["type"] == "indicator":
# 正規表現でドメインを抽出
...
return domain_list, ...
Google Chronicleの特徴
IOCフィードとYARA-L検出ルールを独立したモジュールとして相関させる設計になっており、他のSIEMと比べてスケーラビリティに優れています。
第4章：ユースケース開発におけるAIの活用
生成AIの効果的な活用方法
本書では生成AI（LLM）をペアプログラマーとして位置付けています。完全自律型の汎用AIとしてではなく、検出ルールの初稿生成や構文提案など、開発を加速させる補助ツールとして活用するのが現実的なアプローチです。
LLMに対するプロンプトのガイドラインとして、以下が挙げられています。
- 発言はできるだけ明確かつ簡潔にする
- プロンプトを「関数」として扱い、正確な入力形式を意識する
- Markdown形式のトップダウン構造でプロンプトを整理する
- 参照させたい「正しい情報（ナレッジベース）」を添付する
- 温度パラメータは 0.25 程度に下げることで、事実ベースの回答が得られる
活用ツールの紹介
Poe（poe.com）
複数LLMを試せるプラットフォームです。カスタムボットを作成し、ナレッジベース（Splunk SPLのPDFやOWASPガイドなど）を登録することで、ドメイン特化した回答精度が向上します。
SOC Prime Uncoder AI
コミュニティ提供のSigmaルールをSplunk SPLやKQLなど各SIEMの構文に自動変換するツールです。検出の妥当性検証も行います。
# Poeへのプロンプト例
次の要件に基づいてトリガーされる Splunk 相関関係を記述してください。
イベント1 = リモートファイルのインクルード
イベント2 = PHPウェブシェルの証拠
ログソースは標準的な Apache HTTPDログです。
イベント1がイベント2より15分以内に発生し、
各イベントに対してHTTP 200 OKステータス応答があった場合にのみ発生すること。
ラボ4.3：RSSフィードからSplunk SPLを自動生成
セキュリティニュースアグリゲーターのRSSフィードを取り込み、過去24時間以内の記事を反復処理してPoe APIに送信します。IOCやプロセスパターンを解析し、Splunk SPL相関検索を自動生成するパイプラインです。
# メインドライバーの概略
fresh_urls = get_urls('https://allinfosecnews.com/feed/')
file_handle = open("ai-recommended-spl.txt", "w")
for url in fresh_urls:
bot_response = asyncio.run(get_responses(api_key, url))
file_handle.write(bot_response + "\n")
file_handle.close()
APIキーはOS環境変数経由で注入し、CI/CDパイプラインのシークレットとして管理します。
パート2：CI/CDパイプライン内での検証の自動化
第5〜7章の概要
このパートでは自動化パイプライン内でのテスト戦略を扱っています。
| 章 | テストレベル | 概要 |
|---|---|---|
| 第5章 | ユニットテスト | 構文リンティングと合成ログによる期待出力の検証 |
| 第6章 | 統合テスト | 非本番SIEMインスタンスを使ったリアルな入出力でのテスト |
| 第7章 | AIテスト | LLMを使って真陽性・偽陽性ペイロードを動的生成してCI/CDに組み込む |
GitHubのビルドスクリプトでは、以下のようにPythonバージョンをマトリックス指定してpytestを実行します。
name: Python Package
on: [push]
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
python-version: ["3.10", "3.11"]
steps:
- uses: actions/checkout@v4
- name: Setup Python
uses: actions/setup-python@v4
with:
python-version: ${{ matrix.python-version }}
- name: Install dependencies
run: pip install pytest
- name: Run tests
run: pytest /path/to/unittest/directory/
パート3：プログラムの有効性の監視
第8〜9章の概要
- 第8章：Chronicle Detection Engine APIなどを活用して検出ルールのヘルス状態を継続監視
- 第9章：Splunk Security EssentialsなどのカバレッジマトリックスによるMITRE ATT&CKマッピングの可視化とプログラム効率の測定
第10章：成熟度別の運用パターン
本書のまとめとして、組織のリソースに応じた3段階の成熟度モデルが定義されています。
L1（基礎）：1〜3名のチーム向け
| コンポーネント | 推奨ツール | 費用目安 |
|---|---|---|
| ワークフロー管理 | Atlassian Jira Cloud 無料プラン | 無料 |
| バージョン管理 | GitHub Organization 無料/チームプラン | 無料〜$150 |
| CI/CDパイプライン | Terraform Cloud + GitHub Actions | 無料 |
| 開発環境 | VS Code + lint拡張機能 | 無料 |
まずアジャイル「ライト」から始め、2週間スプリントで少しずつ追跡可能な作業を増やしていくアプローチが推奨されています。
L2（中級）：5〜10名のチーム向け
| コンポーネント | 推奨ツール | 費用目安 |
|---|---|---|
| ワークフロー管理 | Jira Cloud 標準プラン | $110〜$1,100 |
| バージョン管理 | GitHub Org チームプラン | 約$150 |
| CI/CDパイプライン | Terraform/SDK対応ランナー | 無料〜$150 |
| 開発環境 | IDE + SASTツール（例：Bandit） | 無料〜$2,000 |
ユニットレベルのテストをすべての検出タイプに必須化し、プリコミットフックにSASTツールを組み込みます。
シフトレフトの重要性
L2ではローカルのgitコミット段階でリンティング・シークレットスキャン・SASTを実行し、CIビルド時間を節約することが推奨されています。
L3（上級）：10名以上の分散チーム向け
| コンポーネント | 推奨ツール | 費用目安 |
|---|---|---|
| バージョン管理 | GitHub Org Enterprise + Advanced Security | $2,000〜 |
| CI/CDパイプライン | BASツール + AIインライン合成テスト | $25,000〜$100,000 |
| 開発環境 | クラウドIDE + Jupyter Notebook | $10,000〜$22,000 |
Atomic Red Team・Stratus Red Team・MITRE Calderaなどのブレーチ＆アタックシミュレーション（BAS）フレームワークをパイプラインに統合し、ハードフェイル/パスロジックで品質ゲートを設けます。
また、Google ColabのようなJupyterスタイルのノートブックを活用したフォロー・ザ・サンモデルにより、タイムゾーンをまたぐ分散チームでの共同開発が実現できます。
# Google Colab + GitHub シークレットの取得例
from google.colab import userdata
token = userdata.get('GITHUB_TOKEN')
まとめ
本書のアプローチをひと言で表すなら、「検出ルールをソフトウェアとして開発・テスト・デプロイする」ということです。以下の原則に基づいた体系的なプログラムを構築することが、セキュリティ組織の成熟度向上につながります。
- 検出ルールはコードとして管理し、バージョン管理システムに置く
- テストはユニットレベルから統合レベルまで自動化する
- 脅威インテリジェンスの取り込みと検出ルールの生成を可能な限り自動化する
- LLMはあくまで開発加速のための補助ツールとして活用する
- 組織の規模やリソースに応じたL1〜L3の成熟度モデルから無理なく始める
DevOpsのプラクティスとセキュリティドメインの知識を橋渡しする本書は、インフラ・バックエンド系のエンジニアがセキュリティ領域に踏み込む際の入口としても非常に有用です。