脅威の状況は絶えず変化しており、セキュリティ運用は転換点に達しています。脅威の速度と複雑さが増すにつれて、チームは拡大し、管理される環境も増加します。一般的に、ルール管理に対する手動のアプローチはボトルネックになります。ここで、Detections as Code (DaC) がツールとしてだけでなく、方法論としても登場します。

DaC は方法論として、ソフトウェア開発プラクティスをセキュリティ検出ルールの作成、管理、展開に適用します。検出ルールをコードとして扱うことで、バージョン管理、自動テスト、展開プロセスが可能になり、脅威への対応におけるコラボレーション、一貫性、俊敏性が向上します。DaC は検出ルールのライフサイクルを合理化し、ピアレビューと自動テストを通じて高品質の検出を保証します。この方法論は、変更管理要件への準拠もサポートし、成熟したセキュリティ体制を促進します。

そのため、Elastic のセキュリティ検出ルールの作成、テスト、管理のためのオープンリポジトリである Elastic の検出ルールの最新アップデートをお知らせできることを嬉しく思います。これにより、独自のコードとしての検出 (DaC) フレームワークを作成することもできます。拡張機能を使用した注目の実装例と、Elastic の無料 Detections as Code ワークショップの発表については、引き続きお読みください。

Elastic Security DaC: アルファ版から一般公開までの道のり

検出ルールリポジトリで提供される機能により、ユーザーはすべての検出ルールをコードとして管理し、ルールのチューニングを確認し、ルールを自動的にテストおよび検証し、環境全体でルールの展開を自動化できます。

2024年以前: ElasticによるDaCの社内利用

Elastic の脅威研究および検出エンジニアリングチームは、DaC の原則 (チームとしてルールを確認し、テストとリリースを自動化する) に従って、検出ルールリポジトリを作成して使用し、事前構築されたルールを開発、テスト、管理、リリースしました。リポジトリにはルールを作成するための対話型 CLI も用意されているため、エンジニアはその場でルールの作成作業を開始できます。

セキュリティコミュニティの as-code 原則への関心が高まり、Elastic Security API でユーザーがカスタムの Detections as code ソリューションを実装できるようになったため、Elastic は検出ルールリポジトリ機能を拡張して、ユーザーがツールのメリットを享受し、DaC プロセスの作成を支援できるようにすることを決定しました。

ここでは、Elastic のユーザー重視の DaC 開発におけるアルファ版から一般公開までの主要なマイルストーンを紹介します。

2024年5月: 新しい「ロール・ユア・オウン」機能のアルファ版リリース

当社の検出ルールリポジトリは、顧客の使用に合わせて調整されており、カスタムルールの管理、ユーザーのニーズに合わせたテストスイートの調整、ルールと並行したアクションと例外の管理が可能になります。

主な追加点:

カスタムルールディレクトリのサポート
要件に応じて実行するテストを選択します
例外とアクションのサポート

また、検出ルールリポジトリを使用した Elastic Security の実装例を含む、コードとしての検出に関する詳細なガイダンスも公開しました。

2024年8月：「Roll Your Own」機能がベータ版に

機能が拡張され、Elastic Security とリポジトリ間でのカスタムルールのインポートとエクスポートが可能になり、より多くの構成オプションとバージョン管理機能がカスタムルールに拡張されました。

追加された新機能:

カスタムルールの一括インポート/エクスポート（Elastic Security API ベース）
完全に構成可能なユニットテスト、検証、スキーマ
カスタムルールのバージョンロック

2025年3月～8月：一般公開され、サポートされる

Elastic Security 8.18 以降で DaC を使用する:

事前に構築されたルール管理をサポートします。Elastic Security からすべての事前構築済みルールをエクスポートし、カスタムルールと一緒に保存できます。
エクスポートのルールフィルタリングのサポートが追加されました。

DaC の取り組みと並行して、2025 年 10 月から 12 月にかけて新しい Terraform リソース ( V0.12.0およびV0.13.0 ) もリリースされ、Terraform ユーザーは検出ルールと例外を管理できるようになりました。

この基礎を説明した上で、検出エンジニアリングプロセスを効率化するために利用できる強力な機能について詳しく見ていきましょう。

検出ルール DaC 機能のハイライト

前回の DaC 出版物以降、価値のある追加事項がいくつかあり、以下で詳しく説明します。

追加フィルター

Kibana からルールをエクスポートするときに使用できるフィルター機能が拡張され、DaC で同期するルールを正確に定義できるようになりました。新しいフラグは次のとおりです。

旗	説明
-クロ	エクスポートをフィルタリングして、ユーザーが作成したルール（Elastic の事前構築ルールではない）のみを含めます。
-eq	エクスポートされるルールにクエリフィルターを適用します。

データソースごとにルールを整理し、AWS ルールを特定のフォルダーにエクスポートする場合の例を見てみましょう。この場合、データソースのタグでフィルタリングし、 Data Source AWSタグが付いたすべてのルールをエクスポートします。

python -m detection_rules kibana export-rules -d dac_test/rules #add rules to the dac_test/rules folder
-sv #strip the version fields from all rules
-cro #export only custom rules
-eq "alert.attributes.tags: "Data Source: AWS"" # export only rules with "Data Source: AWS" tag

ここで使用されている基礎 API 呼び出しのクエリ文字列フィルタリングについては Kibana のドキュメントを参照してください。また、クエリフィルターを構築するために使用できるフィールドの例については、すべての検出ルールをリストする API 呼び出しを参照してください。

カスタムフォルダ構造

検出ルールリポジトリでは、プラットフォーム、統合、MITRE ATT&CK 情報に基づいたフォルダー構造を使用します。これは組織とルールの開発に役立ちます。これは決して唯一の組織化の方法ではありません。例として、顧客、日付、ソース別にルールを整理することができます。これは、使用ケースによって大きく異なります。

このエクスポートプロセスを使用する場合でも、手動で組織化する場合でも、ルールを任意の場所またはフォルダー構造に保存すると、ルールを再エクスポートする場合でもこのローカル構造を維持できるようになります。新しいルールは目的の場所に手動で配置する必要があることに注意することが重要です。ローカルルール読み込みメカニズムは、ルールが配置されている場所を検出し、ルールをどこに配置するかを判断します。ルールが存在しない場合は、指定された出力ディレクトリを使用して新しいルールを配置します。既存のルールを更新するためにローカルルールの読み込みを使用するには、 kibana export-rulesコマンドとimport-rules-to-repoコマンドの--load-rule-loading / -lrフラグを使用します。これらのフラグを使用すると、 config.yamlで指定されたローカルフォルダーを利用できるようになります。

ルールが次のようにフォルダーに整理されている例を見てみましょう。

rule_dirs:
- rules
my_test_rule.toml
- another_rules_dir
high_number_of_process_and_or_service_terminations.toml

config.yamlファイルでは次の内容を指定します。

rule_dirs:
- rules
- another_rules_dir

新しい-lrオプションを使用すると、Kibana からのルール更新では、指定されたディレクトリに直接エクスポートするのではなく、これらの追加パスが使用されるようになります。

python -m detection_rules kibana --space test_local export-rules -d dac_test/rules/ -sv -ac -e -lr,実行すると、 test_localスペースからルールがエクスポートされ、 my_test_rule.toml既にディスク上にある dac_test/rules/ に書き込まれ、 high_number_of_process_and_or_service_terminations.toml dac_test/another_rules_dir/.に書き込まれます。

これは、異なる顧客に対して異なるサブフォルダー構成で同じルールがある場合に特に役立ちます。たとえば、Elastic の事前構築されたルールフォルダー構造と同様に、ルールをプラットフォームと統合別に分類しているとします。顧客、SOC、または脅威ハンティングチームにとって、これらのプラットフォーム/統合フォルダーの下にルールを整理することは、ルールを管理するための最も便利なメカニズムになる可能性があります。ただし、情報セキュリティチームまたは主要な検出エンジニアリングチームでは、特定の個人またはチームが担当するすべてのルールが 1 か所に整理されるように、ルールをイニシアチブまたはルール作成者別に管理することが必要になる場合があります。ローカルルール読み込みフラグを使用すると、2 つの構成ファイルと各構造内の複製されたルールを簡単に持つことができます。ルールの更新をエクスポートするときは、環境変数を使用して適切な構成ファイルを選択し、ルールの更新をエクスポートします。これらの更新は、ディレクトリ構造を維持しながら、既存のルールに適用されます。

その他のローカル読み込みの更新

上記に加えて、検出ルールの TOML ファイルとスキーマにローカル情報を追加するユーザーを支援するために設計された 2 つの小さな新機能を追加しました。これらは次のとおりです。

ローカルファイルからのローカル日付のサポート。ローカル日付は元のファイルから維持されます。
既存のスキーマから既知のタイプを継承するための自動生成機能にアップグレードします。

ローカル日付コンポーネントは、ファイル内の日付フィールドをより手動で制御したい場合に役立ちます。オーバーライドを使用しない場合、日付は Kibana ルールの内容がエクスポートされた日付に基づきます。--local-creation-dateフラグを使用すると、ファイルの内容が再エクスポートされたときに日付は更新されません。

自動スキーマ生成が更新され、他のインデックス/統合からタイプが存在する場合はそれを継承するようになりました。これにより、より正確なスキーマが提供され、事後の手動更新の必要性が軽減されます。たとえば、次のフィールドでインデックス「new-integration*」を使用するルールがあるとします。

host.os.type.new_field
dll.Ext.relative_file_creation_time
process.name.okta.thread

これらの各フィールドは、デフォルトのタイプでスキーマに追加されるのではなく、既存のスキーマからタイプが継承されます。この場合、 dll.Ext.relative_file_creation_timeとprocess.name.okta.thread型が継承されます。

{
  "new-integration*": {
    "dll.Ext.relative_file_creation_time": "double",
    "host.os.type.new_field": "keyword",
    "process.name.okta.thread": "keyword"
  }
}

これをカスタムデータ型で使用する方法については、このブログの実装例の部分にあるカスタムスキーマの使用セクションを参照してください。

使用例の拡張

以下に、DaC 実装のさらなる例を示します。これらは、新しい機能の追加に焦点を当てたものではなく、コミュニティで議論されているトピックをさらに深く掘り下げたものです。

注目すべきは、コードとしての検出機能は、選択したプロセスとアーキテクチャのカスタム実装を構築するために使用できるコンポーネントとして提供されることです。DaC を本番環境に実装する場合は、それをエンジニアリングプロセスとして扱い、ベストプラクティスに従ってください。

GitlabによるDaC実装

DaC の実装を見ると、通常は、特定のトリガーに基づいてルール管理を自動的に実行するために、何らかの形式の CI/CD 製品を使用することが中心になります。これらのトリガーは、必要な設定、具体的にはルールの信頼できるソースとバージョン管理システム (VCS) の必要な状態によって大きく異なります。これらの考慮事項のいくつかについてさらに詳しく知りたい場合は、 DaC リファレンスマテリアルを参照してください。以下は、Gitlab を VCS プロバイダーとして使用し、Gitlab Actions を介してその組み込み CI/CD を使用する簡単な例です。

stages:                # Define the pipeline stages
  - sync               # Add a 'sync' stage

sync-to-production:    # Define a job named 'sync-to-production'
  stage: sync          # Assign this job to the 'sync' stage
  image: python:3.12   # Use the Python 3.12 Docker image
  variables:
    CUSTOM_RULES_DIR: $CUSTOM_RULES_DIR    # Set custom rules env var
  script:                                  # List of commands to run 
    - python -m pip install --upgrade pip  # Upgrade pip
    - pip cache purge                      # Clear pip cache
    - pip install .[dev]                   # Install package w/ dev deps
    - |  # Multi-line command to import rules                                        
      FLAGS="-d ${CUSTOM_RULES_DIR}/rules/ --overwrite -e -ac"
      python -m detection_rules kibana --space production import-rules $FLAGS
  environment:
    name: production   # Specify deployment environment as 'production'
  only:
    refs:
      - main           # Run this job only on the 'main' branch
    changes:
      - '**/*.toml'    # Run this job only if .toml files have changed

これは、Gitlab や Gitea などの他の Git ベースの VCS に組み込まれている CI/CD と非常によく似ています。主な違いは、トリガーイベントを決定する構文にあります。kibana import-rulesなどの DaC コマンドは、VCS に関係なく同じになります。この例では、検出ルールリポジトリのフォークから Kibana プロダクションスペースにルールを同期しています。これは、たとえば、ルールの更新をマージする前にユニットテストに合格する必要があることや、main のルールが本番環境の準備ができていることなど、事前に行われたいくつかの決定に基づいています。この特定のアプローチに関する考慮事項の Github ベースのウォークスルーについては、デモビデオをご覧ください。

カスタムユニットテストのヒントと例

DaC を検出ツールキットに追加する機能として検討する場合、ルールの品質と有用性を向上させる継続的なプロセスの最初のステップとして、CI/CD と基本インフラストラクチャのセットアップを検討する必要があります。「as code」ツールを使用する主な目的の 1 つは、ニーズや環境に合わせてツールをさらにカスタマイズする機能を追加することです。

その一例は、ルールのユニットテストです。基本的な機能テスト以外にも、既存のいくつかの主要な単体テストでは、ルールのパフォーマンスと最適化、メタデータとタグ付けの編成に関する Elastic 固有の考慮事項が適用されます。これにより、検出エンジニアと脅威研究者は、ルール開発の一貫性を保つことができます。この例を基にして、特定のニーズに基づいてカスタムユニットテストを追加することを検討することもできます。

これを説明するために、さまざまなドメインとタスクを担当する多数のアナリストがいるセキュリティオペレーションセンター (SOC) 環境を考えてみましょう。SIEM でアラートが発生した場合、誰が修復を処理すべきか、またはどのチームにインシデントを通知する必要があるかがすぐにはわからないことがあります。ルールにチームタグを付ける: 例:Team: Windows Servers Elastic がデータソースにタグを使用するのと同様に、修復を支援できる連絡先をアラート内で直接 SOC に提供できます。

DaC 環境では、新しいテストモジュールをすばやく作成して、これをすべてのカスタムルール (または事前構築済みルール) に適用できます。このテストでは、Elastic によって作成されていないすべての本番環境ルールにTeam: <some name>タグを強制的に設定する予定です。検出ルールリポジトリでは、テストはpytestと呼ばれる Python テストスイートを通じて処理され、そのためユニットテストは Python モジュール (ファイル) と、 tests/フォルダーの下のこれらのファイル内の後続のクラスと関数に編成されます。テストを追加するには、既存のファイルにクラスまたは関数を追加するか、新しいファイルを作成するだけです。一般的に、違いをマージせずに Elastic から既存のテストの更新を受け取ることができるように、新しいテストファイルを作成することをお勧めします。

まず、 tests/ディレクトリに次の内容のtest_custom_rules.pyという新しい Python ファイルを作成します。

# test_custom_rules.py

"""Unit Tests for Custom Rules."""

from .base import BaseRuleTest


class TestCustomRules(BaseRuleTest):
    """Test custom rules for given criteria."""

    def test_custom_rule_team_tag(self):
        """Unit test that all custom rules have a Team: <team_name> tag."""
        tag_format = "Team: <team_name>"
        for rule in self.all_rules:
            if "Elastic" not in rule.contents.data.author:
                tags = rule.contents.data.tags
                if tags:
                    self.assertTrue(
                        any(tag.startswith("Team: ") for tag in tags),
                        f"Custom rule {rule.contents.data.rule_id} does not have a {tag_format} tag",
                    )
                else:
                    raise AssertionError(
                        f"Custom rule {rule.contents.data.rule_id} does not have any tags, include a {tag_format} tag"
                    )

今後は、修復を担当するチームのために、各非 Elastic ルールに指定されたパターンのタグを付ける必要が生じます。例えば Team: Team A.

カスタムスキーマの使用

独自のデータタイプを導入できる Elastic の機能は、DaC 機能にも拡張されます。たとえば、ネットワークプロトコルのカスタムスキーマをいくつか見てみましょう。もちろん、スタック内にあるさまざまなデータはルールによってクエリできますが、これらのデータタイプに対するカスタムルールにも適用可能な検証とテストを活用する必要があります。ここでカスタムスキーマが役に立ちます。

クエリを検証する場合、クエリはそれぞれのフィールドに解析され、これらのフィールドの型が特定のスキーマで提供されているものと比較されます（例：ECS スキーマ、AWS データ用の AWS 統合など)。カスタムデータ型の場合、これは同じ検証パスに従い、ローカルに定義されたカスタムスキーマからプルする機能を備えています。これらのスキーマファイルは、1 つ以上の JSON ファイルとして手動で作成できます。ただし、スタック内に既にサンプルデータがある場合は、これを活用して検証として使用し、スキーマを自動的に生成できます。

すでにカスタムルールフォルダーが構成されている場合 (構成されていない場合は手順を参照してください)、構成ファイルにauto_gen_schema_file: <path_to_your_json_file>追加することで自動スキーマ生成をオンにできます。これにより、指定された場所にスキーマファイルが生成され、各フィールドとインデックスの組み合わせのエントリを追加するために使用されます。このファイルは、import-rules-to-repo、kibana export-rules、view-rule など、ルールの内容がスキーマに対して検証されるコマンドの実行中に更新されます。これにより、カスタムルールディレクトリと構成を使用するときに、stack-schema-map.yaml ファイルにも自動的に追加されます。

この権限により、クエリで使用されるすべてのフィールドが直ちに有効であるとみなされてスキーマに追加されるため、ルールレビュー担当者の責任が増大します。リスクを軽減する 1 つの方法は、データにアクセスできる開発スペースを活用することです。PR では、データ型のスタックレベルの検証を使用してクエリの正常な実行にリンクできます。これが承認されると、構成へのauto_gen_schema_file追加を削除でき、カスタムデータに基づく既知の有効なスキーマが得られます。これにより、他のルール作成者が必要に応じて構築するためのベースラインが提供され、型チェックの検証が維持されます。

DaCについて詳しく知り、ぜひお試しください

インタラクティブなInstruqtトレーニングで、Elastic Securityのコードとしての検出（DaC）機能を直接体験できます。このトレーニングでは、事前に構成されたテスト環境でコア DaC 機能を簡単に探索できるため、手動でセットアップする必要がなくなります。ぜひお試しください！

DaC を実装している場合は、コミュニティ Slack DaC チャネルで経験を共有し、質問し、他のユーザーを支援してください。

Elastic Security のトライアル

Elastic が検出エンジニアに提供するメリットをフルに体験するには、Elastic Security の無料トライアルを開始してください。詳細についてはelastic.co/securityをご覧ください。

本記事に記述されているあらゆる機能ないし性能のリリースおよびタイミングは、Elasticの単独裁量に委ねられます。現時点で提供されていないあらゆる機能ないし性能は、すみやかに提供されない可能性、または一切の提供が行われない可能性があります。

Elastic Detections as Code エンジニアガイド