Cyber Security Academy · レッスン

Detection-as-Codeの原則

Q: 「Detection-as-Codeの原則」で何を学びますか？

検知をソフトウェアとして扱います。 ブラウザで直接実行するハンズオンコードでCyber Security Academyを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

検知をソフトウェアとして扱います。

「Detection-as-Codeの原則」はCoddyKit上の無料Cyber Security Academyレッスンです。これはレッスン1/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはCyber Security Academy学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Cyber Security Academyコースには全4レッスンが含まれています。

Detection-as-Codeとは

Detection-as-Code (DaC)は、ソフトウェアエンジニアリングの規律をセキュリティ検知に適用します。アナリストがSIEMコンソール内のルールを手作業で編集するのではなく、検知をバージョン管理下のテキストファイルとして管理し、パイプラインを通じて配布します。

メリットは具体的です:

プルリクエストによって変更をレビュー可能にできる
環境間でのデプロイを再現可能にできる
本番環境に到達する前にロジックをテスト可能にできる
誰が何をなぜ変更したかという履歴を監査可能にできる

検知は、他のコードと同様に差分を比較し、ロールバックし、内容を検討できるアーティファクトになります。

検知をバージョン管理されたファイルとして管理する

各検知は通常、YAMLまたはベンダーのクエリ言語で記述した独立したファイルとして保存し、Gitリポジトリにコミットします。リポジトリのレイアウトは、カバレッジの整理方法を反映します。

一般的な構成では、プラットフォームと戦術ごとにルールを分けます:

detections/
  windows/
    credential_access/
      lsass_memory_dump.yml
    execution/
      suspicious_powershell.yml
  cloud/
    aws/
      root_account_usage.yml
tests/
  windows/
    lsass_memory_dump_test.yml

プルリクエストレビュー

新規または変更された検知はすべて、プルリクエストを通じて処理します。別のエンジニアが、マージ前にロジック、誤検知のリスク、ATT&CKのマッピングをレビューします。

レビュアーは次の点を確認します:

ロジックは説明されている脅威と一致していますか?
どのような正当なアクティビティがこれをトリガーする可能性がありますか?
重要度とATT&CKの参照は正しいですか?
真陽性と誤検知を対象とするテストがありますか?

これにより、午前2時にSIEMを編集する一人のアナリストでは見逃してしまうミスを検出できます。

CIによる検証

継続的インテグレーションパイプラインは、プッシュごとに自動実行されます。ルールをマージできるようになる前に、品質ゲートを適用します。

Sigmaベースのリポジトリにおける一般的なCIステージ:

# .github/workflows/validate.yml (excerpt)
steps:
  - name: Lint Sigma syntax
    run: sigma check ./detections
  - name: Validate against schema
    run: sigma check --validators all ./detections
  - name: Run unit tests
    run: pytest tests/

自動デプロイ

マージされると、デプロイジョブが移植可能なルールを対象のクエリ言語に変換し、API経由でSIEMまたはEDRにプッシュします。

Sigmaでは通常、プラットフォームに合ったバックエンド（Splunk、Elastic、Microsoft Sentinel）を指定して、sigma convertのようなコンバーターを実行します。次にパイプラインが、生成された保存済み検索または分析ルールをアップロードします。

人がコンソールにクエリを貼り付けることはありません。デプロイ済みの状態は常にmainの内容と一致します。

sigma convert -t splunk -p splunk_windows \
  detections/windows/execution/suspicious_powershell.yml

検知をテストする

テストのない検知は推測にすぎません。DaCでは各ルールにテストデータを対応付けます。検知を発火させるべきログサンプル（真陽性）と、発火させるべきでない無害なサンプル（誤検知）です。

テストはCIで実行されるため、カバレッジを壊したりノイズを再発させたりする変更は、マージ前にビルドを失敗させます。これは大規模にルールをリファクタリングする際に、信頼性をもたらす最大の要因です。

test:
  - log: { Image: 'C:\\Windows\\System32\\rundll32.exe', CommandLine: 'rundll32 javascript:...' }
    expected: match
  - log: { Image: 'C:\\Windows\\System32\\rundll32.exe', CommandLine: 'rundll32 shell32.dll,Control_RunDLL' }
    expected: no_match

ルールのメタデータとライフサイクル

メタデータを第一級の要素として扱います。各検知は、ライフサイクルの成熟に合わせてステータスを記録します:

experimental — 新規作成され、注意深く監視されている
test — 実行中ですが、アラートにはまだ信頼して使用していない
stable — 実績があり、誤検知率が低い
deprecated — 置き換え済みまたは廃止

ファイル内でステータスを追跡すれば、古いロジックを本番に残したままにするのではなく、ルールの昇格、降格、廃止を意図的に行えます。

バックエンド間の可搬性

DaCの大きな利点は、ベンダー中立の形式で検知ロジックを一度だけ記述し、多数のバックエンド向けにコンパイルできることです。Sigmaはログベースの検知におけるデファクトスタンダードです。

同じルールファイルから、パイプライン固有のフィールドマッピングを介して、Splunk SPL、Elastic Lucene/EQL、Microsoft Sentinel KQLなどを対象にできます。同じ考えを5回書き直す必要がなくなり、ベンダーロックインも避けられます。

sigma convert -t elasticsearch rule.yml
sigma convert -t microsoft365defender rule.yml
sigma convert -t splunk rule.yml

フィールドマッピングパイプライン

異なるログソースでは、同じデータに異なる名前が付けられています。Sysmonのプロセス作成イベントではImageが使われ、Windows SecurityログではNewProcessNameが使われる場合があります。処理パイプラインがその差を埋めます。

パイプラインは汎用的なSigmaのフィールド名を、データで使われている正確なフィールドへ変換します。これにより、1つの論理ルールを、SIEMが取り込むスキーマにきれいに対応付けられます。パイプラインを一元管理すれば、スキーマの変更をルールごとではなく一度だけ修正できます。

sigma convert -t splunk -p sysmon rule.yml

環境と昇格

アプリケーションコードと同様に、検知は本番環境に到達する前に複数の環境を移動します。通常は開発からステージングを経て本番へ進みます。

開発 — 作成し、CIで単体テストを実行する
ステージング — 監査モードで実際のテレメトリのコピーに対してデプロイする
本番 — 誤検知率が許容範囲になったら昇格する

昇格は、マージの偶然の結果ではなく、ルールのライフサイクルステータスに基づく、意図的にレビューされた手順です。この段階的なロールアウトは、インライン検知で用いられる、まずアラートを出してからブロックする運用規律を反映しています。

カバレッジとメトリクス

検知はコードとして扱えるため、カバレッジをプログラムで測定できます。各ルールを MITRE ATT&CK のテクニックに関連付け、カバーできている範囲とカバーできていない範囲をヒートマップで可視化します。

時間の経過とともに追跡すると役立つメトリクス：

脅威モデルに含まれる総テクニック数に対するカバレッジ済みテクニック数
ルールごとの誤検知率
ルールのアイデアから本番投入までの平均時間
各ライフサイクルステータスのルール数

これらの数値によって、検知エンジニアリングは経験談頼みの活動ではなく、管理対象のプログラムになります。

理解度チェック

Detection-as-Code の基本を理解できているか確認します。

まとめ

Detection-as-Code は、ソフトウェアエンジニアリングの厳密さを検知に取り入れます。

ルールは Git 上のバージョン管理されたファイルとして管理します
変更はプルリクエストレビューを受けます
CIが自動的に lint、検証、テストを実行します
マージされたルールはパイプライン経由でデプロイされ、本番環境を main と同期させます
テストによって誤検知やリグレッションを防ぎます
移植性（Sigma + パイプライン）により、1つのルールを複数のバックエンドで利用できます
メタデータ、ライフサイクル、メトリクスによって、検知を管理対象のプログラムにできます

次は、Sigma を使って移植可能なルール自体を作成します。

よくある質問

「Detection-as-Codeの原則」レッスンは無料ですか？

はい。「Detection-as-Codeの原則」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、Cyber Security Academyコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Cyber Security Academyコースには全4レッスンが含まれています。

「Detection-as-Codeの原則」で何を学びますか？

検知をソフトウェアとして扱います。ブラウザで直接実行するハンズオンコードでCyber Security Academyを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Cyber Security Academyを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのCyber Security Academyは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。これはレッスン1/4です。

「Detection-as-Codeの原則」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このCyber Security Academyレッスンでコードを書いて実行できますか？

はい。すべてのCyber Security Academyレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

← Cyber Security Academyに戻る