Kibana Alertにおけるセキュリティールール (Security Detection Rules) とは

Posted at 2026-05-01

この記事はKibana Alertingについての連続記事の一部です。

Elastic Security（SIEM）のDetection Rulesに固有の設定項目・動作について解説します。

Security Detection Rules の共通概念

Security Detection RulesはKibana Alertingの汎用ルールとは異なり、セキュリティ監視に特化した仕組みを持っています。まず共通の概念を整理します。

Detection Alerts（セキュリティアラート）

Security Detection Rulesが生成するアラートは、通常のAlertingルールのAlertに相当しますが、Elastic Securityでは Detection Alert（または Signal）と呼ばれます。

Detection Alertsは以下の点で汎用ルールのアラートと異なります。

専用インデックスに保存される: .alerts-security.alerts-default インデックスに格納される
Elastic SecurityアプリのDetections画面でのみ管理できる: Stack ManagementのRules画面ではなく、Elastic SecurityアプリのDetections画面が管理の起点になる
アクショングループが default のみ: ObservabilityルールがALERT / WARNING / NO_DATA / Recovered など複数のアクショングループを持つのに対し、Security Detection RulesのアクショングループはAlertの発火時に対応する default のみである

ルールタイプ

Security Detection Rulesには複数のルールタイプが用意されており、検出ロジックやクエリの書き方が異なります。後続の記事で各ルールタイプの具体的な設定項目・動作を解説します。

以下のルールタイプが存在します。

利用基準	ルールタイプ	説明
脅威が「明確な条件で定義しにくい行動の逸脱」か？	Machine learning	機械学習の異常検知ジョブを使って通常行動をモデル化し、逸脱を検知します。クエリ作成は不要ですが、異常検知ジョブの作成または選択が必要です。
イベントを脅威インテリジェンスフィードと照合したいか？	Indicator match	ソースイベントのフィールドを脅威インテリジェンスインデックスと照合します。生成アラートにはインジケーターのメタデータが付与されます。
フィールド値の「初出現」を検知したいか？	New terms	値（または最大3フィールドの組み合わせ）が、指定した履歴ウィンドウ内で一度も出現していない場合にアラートを生成します。新規性のある挙動の検出に向きます。
検知にイベントの順序関係や「あるべきイベントの欠落」が必要か？	Event correlation (EQL)	EQLで時系列相関を記述し、共通フィールドで関連付けながら複数イベントを検知します。多段階攻撃や期待イベント欠落の検出に適しています。
イベント量がしきい値を超えたときに検知したいか？	Threshold	1つ以上のフィールドでグループ化した一致イベント数がしきい値以上になるとアラートを生成します。ブルートフォースなど件数ベースの検知に適しています。
集計・変換・計算フィールドが必要か？	ES\|QL	パイプ構文のES\|QLで集計・変換・フィルタを行った結果に対して検知します。結果の各行がアラートになります。
上記のどれにも当てはまらないか？	Custom query	KQLまたはLuceneでイベントをマッチさせる、最も柔軟で汎用的なルールタイプです。既知の値・パターン・論理条件の検知に向きます。

Severity（重大度）と Risk Score（リスクスコア）

Severity と Risk Score は、Security Detection Rules固有の重要な設定項目です。Observabilityルールには存在しない、Securityカテゴリ専用の概念であり、全ルールタイプで共通の必須設定です。

Severity（重大度）

ルール作成時に以下の4段階から選択します（必須）。

Severity	意味
Low	低重大度
Medium	中重大度
High	高重大度
Critical	致命的

生成されたDetection AlertにSeverityが付与され、Detections画面でのフィルタリング・ソートに利用できます。また、Actions設定で「特定のSeverity以上のときだけ通知する」という条件付き実行も設定可能です。

Risk Score（リスクスコア）

0〜100の数値で、検出されたイベントのリスクの高さを表します（必須）。SeverityとRisk Scoreの対応の目安は以下の通りです。

Severity	Risk Score の目安
Low	0〜21
Medium	22〜47
High	48〜73
Critical	74〜100

SeverityをUIで選択すると推奨値が自動設定されますが、手動で任意の値に変更できます。

Severity Override / Risk Score Override（オプション）

通常はルール定義時に固定値として設定しますが、ソースイベントが持つフィールドの値に基づいてSeverityやRisk Scoreを動的に上書きすることもできます。

例: イベントの重大度フィールドをKibanaのSeverityにマッピングして自動設定する
制限事項:
- Event Correlation（EQL）ルールではRisk Score Overrideはサポートされない
- Thresholdルールのリスクスコアオーバーライドでは「Group by」フィールドのみ使用可能

ルール共通の設定項目

全ルールタイプに共通して設定できる項目を説明します。

メタデータ

ルールの識別・分類に使う基本情報です。

設定項目	必須	説明
Rule Name	必須	ルール名
Description	必須	ルールの説明。脅威の概要・検出ロジックの説明を記載すると運用時に役立つ
Tags	オプション	カテゴリ化・フィルタリング用のタグ
References	オプション	脅威の参考情報や背景情報へのURL

スケジュール設定

Security Detection Rulesには以下のスケジュール設定があります。

Runs every（実行間隔）: ルールを定期実行する間隔
Additional look-back time（追加ルックバック時間）: 各実行時にクエリ対象とする遡及期間

たとえば実行間隔が1時間、ルックバックが1時間の場合、毎時間「直近2時間分」を検索します。これにより、前回の実行でカバーされなかった期間のイベントを取りこぼさない設計になっています。

ルール権限の注意点

ルールはバックグラウンドで「最後に編集したユーザーの権限」で実行されます。権限が不足しているユーザーがルールを編集すると、そのルールが機能しなくなる可能性があるため注意が必要です。

Response Actions（自動応答アクション）

Security Detection RulesにはConnector経由のAction（Slack通知など）とは別に、Response Actions と呼ばれるSecurity固有の機能があります。

通常のActionがConnectorを経由して外部システムへ通知するのに対し、Response Actionsはアラート発生時にエンドポイント上で自動的に対応処置を実行します。

前提条件

Elastic AgentおよびElastic Defendがエンドポイントにインストールされている必要がある

利用可能な対応処置

処置	説明
Isolate Host（ホスト隔離）	ホストをネットワークから切り離し、横展開を防ぐ
Kill Process（プロセス終了）	悪意あるプロセスを強制終了する
Suspend Process（プロセス一時停止）	プロセスを一時停止して調査の機会を確保する

設定方法の詳細は公式ドキュメントを参照してください。

Alert Suppression（アラート抑制）

Alert SuppressionはSecurity Detection Rulesに固有の抑制機能です。ObservabilityルールにはないSecurity専用の機能であり、Platinumライセンス以上で利用可能です。

Kibana Alerting共通の Action Frequency（通知頻度の制御）とは異なり、Detection Alertそのものの生成を抑制・グループ化します。

設定項目

グループ化フィールド

指定したフィールドの値が同じアラートをグループ化して抑制します。最大フィールド数はElastic Stackのバージョンによって異なります。

Elastic Stack 9.2以降: 最大5フィールド
Elastic Stack 9.0〜9.1: 最大3フィールド

抑制頻度

設定値	動作
Per rule execution（ルール実行ごと）	ルール実行のたびにグループごとに1件のアラートを生成する
Per time period（期間単位）	指定した期間内にグループごとに1件のアラートを生成する

欠落フィールドの処理

グループ化フィールドがイベントに存在しない場合の扱いを選択します。

設定値	動作
suppress	値なしのドキュメントもまとめて抑制する
doNotSuppress	値なしのドキュメントは抑制せず個別にアラートを生成する

ルールタイプ別の抑制上限

Alert Suppressionによって1回のルール実行で生成される抑制済みアラートの数は、ルールタイプによって上限が異なります。

ルールタイプ	抑制アラートの上限
Custom Query	上限なし
Threshold / EQL / ES\|QL / Machine Learning	Max alerts per run設定値（デフォルト100）
Indicator Match / New Terms	最大500件

Max alerts per run はルールごとに設定できる「1回の実行で生成するアラートの最大件数」です。Alert Suppressionを使用する場合、この上限がそのまま抑制済みアラートの上限にも適用されます。Custom Query Ruleにのみこの制限が適用されない理由は、内部的に異なる処理方式（イベントごとの個別評価）を採用しているためです。

Alert Suppression と Rule Exceptions の使い分け

Detection Rulesには重複排除・除外のための仕組みが2つあります。

機能	用途	アラートレコードへの影響
Alert Suppression	重複アラートをグループ化する	フォレンジック用の監査証跡はすべて保持される
Rule Exceptions	既知の安全なケースを永続的に除外する	アラートレコード自体が作成されない

「ノイズを減らしつつ証跡を残したい」場合はAlert Suppression、「特定の条件を完全に無視したい」場合はRule Exceptionsを使い分けます。

Custom Query Rule / Saved Query Rule

最も基本的なDetection Ruleです。KQL・Luceneクエリでイベントを検索し、マッチしたイベントをDetection Alertとして生成します。

Custom Query Rule の固有設定

データソースと検索条件を設定します。

設定項目	説明
query	KQLまたはLuceneクエリ（未指定時は全件マッチ）
language	クエリ言語（kuery / lucene）
index	検索対象インデックスパターン（未指定時はデフォルト設定を使用）
data_view_id	データビューIDでの指定も可能
filters	クエリに加えるフィルター条件

Saved Query Rule の固有設定

設定項目	説明
saved_id	Kibanaで保存済みのクエリへの参照ID（必須）

保存済みクエリを複数ルールで再利用できます。Saved Queryを変更すると、次のルール実行時に最新のクエリが適用されます。

Alert Suppression

Custom Query Rule・Saved Query Rule ともにAlert Suppressionをフルサポートします（グループ化フィールド / 抑制頻度 / 欠落フィールドの処理）。上限なし。

Threshold Rule

クエリにマッチしたイベントの件数（または特定フィールドのユニーク値の数）が閾値を超えた場合にアラートを生成するRule Typeです。個別のイベントではなく「集計結果」に対してアラートを生成する点が他ルールと異なります。ブルートフォース攻撃など「件数の多さ」がシグナルになるシナリオに適しています。

固有の設定

Threshold Ruleの集計条件と閾値を設定します。

設定項目	説明
query	集計対象を絞り込むKQL/Luceneクエリ
threshold.field	集計基準フィールド（空の場合はクエリ全体の件数で集計、最大5フィールドの複合集計が可能）
threshold.value	アラートを発火する件数の閾値
threshold.cardinality	ユニーク値の数でしきい値を設定する追加条件（オプション）

threshold.cardinality を使うと複合条件の設定が可能です。たとえば「同一IPから500件以上のリクエスト、かつ宛先ポートのユニーク数が10以上」のような検出シナリオを構成できます。

Alert Suppression

Threshold Ruleのみ、Alert Suppressionの設定方式が他のルールと異なります。

duration（期間）のみ設定可能: threshold.field がすでにグループ化の役割を担っているため、別途 group_by の設定は不要です
durationを設定すると、同一の集計グループのアラートを指定期間内に1件に抑制できます
上限: Max alerts per run設定値（デフォルト100）

Event Correlation Rule（EQL）

EQL（Event Query Language）を使って複数のイベントの相関関係を検知するRule Typeです。単一イベントの検出だけでなく、「AというイベントのあとにBというイベントが起きた」というシーケンスパターンの検出が可能です。多段階攻撃（APT等）の検知に適しています。

固有の設定

EQLクエリと、イベントの照合に使用するフィールドを設定します。

設定項目	説明
query	EQLクエリ（必須）
event_category_override	ECSの `event.category` フィールドの代わりに使用するフィールドを指定（オプション）
timestamp_field	イベントの順序付けに使用するタイムスタンプフィールド（デフォルト: `@timestamp`）
tiebreaker_field	同一タイムスタンプのイベント間での順序を決定するフィールド（オプション）

event_category_override はカスタムログなどで event.category 相当のフィールドが異なる場合に使用します。

EQLクエリの例

単一イベントの検出:

process where process.name == "powershell.exe"

シーケンス検出（多段階攻撃の例）:

sequence by host.id
  [process where process.name == "cmd.exe"]
  [network where destination.port == 443]

終了条件付きシーケンス:

sequence by host.id
  [process where process.name == "malware.exe"]
until [process where process.name == "cleanup.exe"]

制限事項

EQL Ruleには、他のルールタイプには存在しない以下の制約があります。

Severity Override / Risk Score Override はサポートされない
配列フィールドをAlert Suppressionのグループ化フィールドに使用する場合、配列全体が完全一致する必要がある

Alert Suppression

標準的なAlert Suppressionをサポートします（グループ化フィールド / 抑制頻度 / 欠落フィールドの処理）。上限: Max alerts per run設定値（デフォルト100）

ES|QL Rule

ES|QL（Elasticsearch Query Language）クエリを使ってセキュリティデータを検索・集計してアラートを生成するRule Typeです。KQLでは難しい複雑な集計・変換・計算フィールドの生成が可能です。

固有の設定と制約

ES|QL Ruleは設定がシンプルで、クエリ以外の設定項目はほとんどありません。ただし、他のルールタイプと異なる動作制約があります。

設定項目	説明
query	ES\|QLクエリ（必須）。インデックス指定はクエリ内で行う

他のルールタイプと異なり、インデックスパターンやデータビューを別途設定しません。集計クエリか通常クエリかはクエリの内容から自動判定されます。

Alert Suppression

標準的なAlert Suppressionをサポートします。上限: Max alerts per run設定値（デフォルト100）

Indicator Match Rule（脅威インテリジェンスとのマッチング）

イベントデータと脅威インテリジェンス（IOC: Indicators of Compromise）を照合してDetection Alertを生成するRule Typeです。既知の悪意あるIPアドレス、ドメイン、ファイルハッシュなどとイベントデータを突き合わせて検知します。

固有の設定

Indicator Match Ruleでは、イベント側のクエリ設定に加え、脅威インテリジェンスのインデックスとマッピング方法を定義します。

設定項目	説明
query / language	検索対象となるイベント側のクエリ設定
threat_index	脅威インテリジェンスが格納されているインデックスパターン（必須）
threat_query	脅威インテリジェンスインデックスに対するフィルタークエリ（必須）
threat_mapping	イベント側フィールドと脅威インテリジェンス側フィールドのマッピング定義（必須）
threat_indicator_path	脅威インテリジェンスデータのネスト構造に対応するパス（オプション）
concurrent_searches	並行検索数（オプション）
items_per_search	1回の検索あたりのインジケーター件数（オプション）

threat_mapping のマッチング制御

同一エントリ内の条件はAND、エントリ間の条件はORとして評価されます。これにより「送信元IPが脅威IPと一致する」OR「宛先ドメインが脅威ドメインと一致する」のような柔軟なマッチング条件を定義できます。

concurrent_searches と items_per_search は大量のインジケーターを処理する際のパフォーマンスチューニング用パラメータです。

運用上の注意点

ルックバック時間は最大24時間が推奨される
ワイルドカードの使用は避ける（リソース消費が増大する）
ルール実行間隔は1時間以上を推奨

Alert Suppression

標準的なAlert Suppressionをサポートします。上限: 最大500件

Machine Learning Rule

Elasticsearch MLの異常検知ジョブの結果を使ってセキュリティアラートを生成するRule Typeです。明確な定義が難しい「動作的逸脱（異常）」の検出に適しています。

固有の設定

機械学習による異常検知を利用するため、監視対象のML Jobと異常スコアの閾値を指定します。

設定項目	説明
machine_learning_job_id	監視対象のML Job ID（必須）。複数のJob IDを指定して1つのルールで複数のML Jobを同時に監視できる
anomaly_threshold	アラートを発火する異常スコアの閾値（0〜100、必須）。Elasticsearch MLが出力するanomaly scoreがこの値以上のときにアラートが生成される

前提条件

ML Jobが事前に作成・実行されている必要がある
ML機能の利用には適切なElasticサブスクリプションが必要

Alert Suppression

標準的なAlert Suppressionをサポートします。ML Jobが出力するフィールドをグループ化フィールドに使用することも可能です。上限: Max alerts per run設定値（デフォルト100）

New Terms Rule

過去に観測されたことのない「初出現」の値を検知するRule Typeです。新規ユーザーアカウントの出現、未知のプロセス名、初めての接続先など、ベースライン外の新規事象を検出するために使用します。

固有の設定

New Terms Ruleでは、初出現の監視対象フィールドと、「過去」として扱う参照期間を指定します。

設定項目	説明
query	検索対象を絞り込むKQL/Luceneクエリ
new_terms_fields	初出現を監視するフィールド名（必須、最大3フィールド）。複数フィールドを指定した場合はその組み合わせが初出現かどうかを判定する
history_window_start	「過去」の参照期間の開始日時（必須、相対日付形式）。例: `now-30d`

new_terms_fields に複数フィールドを指定した場合は、値の組み合わせ単位で初出現を判定します（例: ["host.ip", "host.id"] → この2つの値の組み合わせが初めて出現した場合にアラート）。

動作の仕組み

クエリ実行期間内でマッチしたイベントから、監視対象フィールドの値を収集する
history_window_start から現在までの履歴ウィンドウ内でその値が過去に存在したかを確認する
過去に存在しなかった値を含むイベントがDetection Alertの対象になる

history_window_start: now-30d の設定では、直近30日間に存在した値はすでに「既知」として扱われ、それ以外の値が「新規」として検出されます。

Alert Suppression

標準的なAlert Suppressionをサポートします。上限: 最大500件

ルールタイプの選択指針

検出したい脅威の性質に応じて適切なルールタイプを選択することが重要です。以下に各ルールタイプが得意とするシナリオをまとめます。

ルールタイプ	適している検出シナリオ
Custom Query	既知の攻撃パターン、特定のフィールド値や条件を検知する基本的な検出
Threshold	ブルートフォース攻撃など「件数の多さ」がシグナルになるシナリオ
Event Correlation（EQL）	多段階攻撃など複数イベントの順序・相関関係を検知するシナリオ
Indicator Match	脅威インテリジェンスフィードと突き合わせて既知の悪意あるIOCを検知するシナリオ
Machine Learning	正常な行動のベースラインからの逸脱を検知するシナリオ（明確な条件が定義しにくい場合）
New Terms	初めて出現した値（新規ユーザー、未知のプロセス等）を検知するシナリオ
ES\|QL	複雑な集計・変換・計算が必要なシナリオ

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up