バッチ検知ルール

概要

バッチ検知は、スケジュールに従ってLogpressoクエリまたはデータセットを実行し、一定期間蓄積されたログやテーブルデータを分析する機能です。Policies > Batch Rules でルールを管理してください。検知結果は検知状況、チケット、釈明、プレイブックなどの後続対応機能に連携できます。

リアルタイム検知が即時反応に適している一方、バッチ検知は低頻度の攻撃、長期間にわたる異常行動、多数のログを横断して判定する必要があるパターンの検知に適しています。たとえば、一定期間に蓄積されたアクセス記録やファイアウォールログをもとに、ポートスキャン、繰り返し失敗、内部移動の兆候を検知するような用途に活用できます。ルールを MITRE ATT&CK の技術・戦術に関連付けて、検知目的を構造的に管理することもできます。

次の図は、バッチ検知ルールの動作を示したものです。バッチ検知ルールは通常、テーブルに保存されたデータソースを対象に適用されます。

バッチ検知ルールはLogpressoクエリのコマンドおよび関数を利用するため、柔軟なルール作成が可能です。たとえば、特定ユーザーの活動関係を把握し、関連する潜在的脅威を予測して不審な活動を検知できます。

多くの場合、バッチ検知ルールはイベント検知時にチケットを発行したり、イベント実行者に釈明を要求します。過剰なチケット発行はマルウェア分析担当者やセキュリティ運用担当者の負担を増やすため、重複チケットの発生を最小限に抑える必要があります。Logpresso Sonar は、イベント検知時にアラームメッセージやチケットタイトルとして使用されるメッセージ、または重複判定フィールドを基準に、同一内容のイベントを1件のチケットとして処理する機能を提供します。

クラスタ管理者と管理者ロールのアカウントは、バッチ検知ルールを表示し、追加・編集・削除・複製・実行できます。バージョンの復元と例外条件の管理も同じ権限で行います。ユーザーロールのアカウントは一覧と設定の表示のみ可能です。

バッチ検知ルールの検索

Policies > Batch Rules で、バッチ検知ルールの一覧を表示・検索できます。一覧はルール名の順に並びます。

App: ルールに関連するアプリのアイコン。デフォルトルールやユーザーが追加したルールは Logpresso アイコンで、アプリがインストールしたルールは該当アプリのアイコンで表示されます。
Enabled: ルールの有効化トグルボタン（: 有効、: 無効）
Priority: ルールの重要度。 High、 Medium、 Low で表示します。
Category: ルールに適用されたカテゴリ
Scenario: バッチ検知ルールの名前
Schedule: ルールの実行周期
Ticket: チケット発行設定の有無（: 設定あり、: 設定なし）
Explanation: 釈明要求設定の有無（: 設定あり、: 設定なし）
Modified At: ルールが最後に変更された日時（変更したことがなければ作成日時）

一覧から特定のバッチ検知ルールを探すには、ツールバーの検索ボックスを使用します。キーワードはルールの名前、説明、クエリ文から検索します。件名やカテゴリ名は検索対象ではありません。

ツールバーの Category、Enabled、Ticket、Explanation ドロップダウンを使うと、必要なルールだけをすばやく絞り込めます。Enabled は Enabled/Disabled、Ticket と Explanation は Active/Inactive から選択します。

ルールの有効化/無効化

バッチ検知ルールを有効または無効にするには、ルールの Enabled 列にあるトグルボタンをクリックしてください（: 有効、: 無効）。スケジュールによる実行は、有効なルールにのみ適用されます。

一覧のダウンロード

バッチ検知ルールの一覧をローカル PC に保存するには、ツールバーのをクリックし、Download Batch Rule List ダイアログでファイル名、ダウンロードする列、ファイル形式、エンコーディング、範囲を指定して Download をクリックしてください。列には、一覧に表示されない件名、所有者、作成日、説明、担当者、釈明設定、アラームグループも含めることができます。

一覧のリフレッシュ

最新のバッチ検知ルール一覧を表示するには、ツールバーのをクリックしてください。

許容可能リスクの設定

XDR ライセンスが有効化されている環境では、許容可能なリスクスコアを設定して予想チケット数を推定できます。許容可能なリスクスコアは個々のルールではなく システム全体に1つだけ 設定する値で、リアルタイム検知とバッチ検知が同じ値を共有します。

このスコアはルール設定画面の下部にある Ticket condition と組み合わせて動作します。チケット発生条件を Occur when acceptable risk score is exceeded に指定したルールは、検知されたイベントのリスクスコアがここで設定したスコアを超えた場合にのみチケットを発行します。この選択肢も XDR ライセンスが有効な場合にのみ表示されます。

許容可能なリスクスコアを設定するには、

ツールバーにあるをクリックし、表示されるメニューで Accept Risk をクリックしてください。このメニューは XDR ライセンスが有効化されている環境でのみ表示されます。
Acceptable Risk Setting ダイアログで 許容可能なリスクスコア（1-100）を入力し、発生件数を予測 をクリックしてください。予測結果 に前日 0 時から当日 0 時までの1日分の チケット発生件数 が表示されます。適用するには Save、取り消すには Cancel をクリックしてください。

バッチ検知ルールの追加

バッチ検知ルールを追加するには、

Policies > Batch Rules でツールバーの Add をクリックしてください。
New Batch Rule 画面で共通設定の項目を設定してください。
- Name: ルールの名前（必須、最大255文字）。他のルールと重複する名前は指定できません。
- Category: ルールのカテゴリ（デフォルト: Uncategorized）。カテゴリは Analysis > Event Summary の検知一覧に Category として表示されます。必要なカテゴリはルールカテゴリで事前に追加しておけます。
- Subject: イベント検知時にチケットへ付与されるタイトル（必須、最大2,000文字）
  - ログスキーマで定義されたフィールド名を $フィールド名 または $フィールド名$ の形式で入力すると、検知の根拠となったログからフィールド値を取得して件名を生成します（例: $src_ip）。フィールド名に韓国語が含まれる場合は、必ず $フィールド名$ の形式を使用してください。韓国語以外の非 ASCII 文字（日本語など）を含むフィールド名はどちらの形式でもサポートされないため、フィールド名は ASCII で付けてください。
  - Detect Duplicates on を設定しない場合、生成された件名が同一かどうかを基準に重複チケットの発生を防止します。
- Priority: 検知イベントの重要度（High、Medium、Low）
- Time Window: 分析対象とするデータの期間。時間単位（秒、分、時、日）を選択して数値を入力してください（デフォルト: 空欄、単位のデフォルト: day(s)、最大365日）。単位にかかわらず、換算した期間が365日を超えると保存できません。期間を指定すると、実行するたびに実行時刻から逆算した開始時刻と実行時刻がそれぞれパラメータ from、to として渡されます。この期間を適用するには、クエリ内でデータを取得するコマンド（例: table）に from=$("from") to=$("to") オプションを指定してください。
  
  たとえば、Time Window に30日を指定すると、table from=$("from") to=$("to") *:FW_FLOW で始まるクエリを実行するたびに、実行時刻から逆算して30日前以降に収集されたデータを FW_FLOW テーブルから取得します。
- Truncation: from、to パラメータに適用する時間精度（デフォルト: Not selected、選択肢: by sec.、by min.、by hr.、by Day）。選択した単位より小さい時間情報は切り捨てます。Time Window が空欄の場合、切り捨ても適用されません。
  
  たとえば、Time Window が1日、Truncation が by hr. で、ルールが 09:07 に実行された場合、前日の 09:00 から当日の 09:00 までを分析します。
- Assign to: 発行されたチケットを割り当てる担当者のアカウント。検索ボックスに名前を入力してアカウントを1つ以上選択できます。未指定の場合は、担当者なしでチケットが作成されます。
- Schedule: ルールの実行周期（デフォルト: 毎年1月1日 0時0分）。... ボタンをクリックすると Task Cronizer ダイアログが表示されます。Basic タブで Every Min.、Every Hr.、Every DoM、Every Mth. ボタンから周期を選んで分・時・日・月・曜日を調整するか、Advanced タブで CRON 構文を直接入力してから OK をクリックしてください。
- Alarm Groups: 新しいチケットが発行されたときに通知を受け取る通知グループ
  
  Note
  
  アラームの受信方法はアラームグループで選択してください。
イベント検知時に攻撃者の IP アドレスまたは異常な実行者の IP アドレスを個別に管理したり、ファイアウォールや IPS などと連携してアドレスグループ情報を受け渡す場合は、次の項目を設定してください。
- Address Group: IP Field に指定したフィールドの値（IP アドレス）を追加するアドレスグループ
- Retention (min.): Address Group に追加した IP アドレスを保持する時間（単位: 分）。設定した期間が経過すると、IP アドレスは自動的にアドレスグループから削除されます。未指定の場合はアドレスグループに永久に保持されます（範囲: 1-100,000,000）。
- IP Field: イベント検知時にアドレスグループに追加する IP アドレスのフィールド。クエリ結果に含まれる IP アドレスのフィールド名を入力してください（例: src_ip、dst_ip）（最大50文字）。
他社の情報セキュリティシステムとのブロック連携設定については、レスポンスターゲットを参照してください。
Analysis Method でスケジュールに従って実行するデータ分析方式を選択し、その下に表示される項目を設定してください（必須、デフォルト: Query）。
- Dataset: 検索ボックスで実行するデータセットを選択してください。選択したデータセットのクエリが実行されます。
- Query: クエリエディターにクエリ文を直接入力してください（分析方式が Query のとき必須、最大10,000文字）。クエリ文は保存前に検査され、実行できないクエリ文は保存できません。
クエリ結果の各行が1つのイベントになります。Subject や Detect Duplicates on で参照するフィールド、IP Field、Auditee のフィールドは、クエリ結果に含まれている必要があります。たとえば、次のクエリは業務時間外にリモートデスクトップで3回以上ログオンしたアカウントを1日単位で集計します。
```
table from=$("from") to=$("to") *:AD_SECURITY
| search event_id == 4624 and logon_type == 10
| eval hour = int(string(_time, "HH"))
| search hour < 7 or hour >= 22
| stats count, values(src_ip) as src_ip, min(_time) as first_seen by user
| search count >= 3
```
バッチ検知ルールを特定のアプリおよび MITRE ATT&CK の技術・戦術に関連付けて管理するには、次の項目を設定してください。
- Signature App: 検知イベントのsignatureフィールド値をどのアプリのシグネチャから探すかを決めます(インストール済みアプリの一覧から選択)。この項目は XDR ライセンスが有効化されている環境でのみ表示されます。
- MITRE ATT&CK 技術: ルールが検知対象とする MITRE ATT&CK の技術。検索ボックスに T1078 のような技術 ID または技術名を入力し、一覧から選択するとタグとして追加されます。1つ以上選択できます。
- MITRE ATT&CK 戦術: ルールが対応する MITRE ATT&CK の戦術。技術を選択すると、その技術が属する戦術が自動的に追加され、戦術タグをクリックして除外または再度含めることができます。技術を選択していない場合は、検索ボックスに TA0001 のような戦術 ID または戦術名を入力して直接選択します。
- Description: ルールの詳細説明（最大2,000文字）
検知されたイベントが組織の従業員に関連する場合、該当従業員に釈明を要求できます。Explanations 項目の Explanation Request Enable チェックボックスを選択すると、次の項目が表示されます。
- Auditee: 釈明対象の従業員の社員番号が入っているフィールド（必須、デフォルト: emp_key、最大50文字）。クエリ結果にこのフィールドが必要です。ない場合は、クエリでアカウントや IP アドレスを社員番号に変換するフィールドを作成してください。
  
  脅威が検知されると、該当する社員番号にマッピングされた従業員に釈明要求メールが自動的に送信されます。この場合、Users > Employees で従業員情報（社員番号、アカウント、メール）をあらかじめ設定しておく必要があります。
- Category: 釈明のカテゴリ（必須）。必要なカテゴリは釈明カテゴリで事前に追加しておけます。
- Manager、Auditor: 釈明の一次レビュアーと二次レビュアー。従業員の検索ボックスから選択します。Manager を指定しない場合は釈明対象者の上司が一次レビュアーになり、上司の情報がない場合は釈明要求が作成されません。Auditor を指定しない場合は二次レビューなしで終結します。詳細は釈明を参照してください。
- Due Date (day(s)): 釈明の処理期限（必須、デフォルト: 7日、最大255日）。期限を過ぎると、釈明対象者は釈明を提出できません。
- Explanation Request Message: 釈明要求時に伝えるメッセージ（最大10,000文字）。入力した内容は、メール/SMS テンプレート本文のテキストマクロ $user_note の位置に挿入されます。$src_ip のようにフィールドマクロを含めて、検知根拠を併せて案内できます。
イベント検知時にチケットを発行するには、次の項目を設定してください。
- Ticket condition: イベント検知時にチケットを発行する条件（デフォルト: Never）
  - Always: イベントが検知されるたびにチケットを発行します。
  - Occur when acceptable risk score is exceeded: 検知されたイベントのリスクスコアが許容可能リスクの設定で指定したスコアを超えた場合にのみチケットを発行します。この選択肢は XDR ライセンスが有効化されている環境でのみ表示されます。
  - Never: チケットを発行しません。イベントは Analysis > Event Summary にのみ記録されます。
- Ticket Repository: 発行するチケットを分類するチケット分類。Ticket condition が Never 以外の場合は必ず選択する必要があり、Never の場合は選択できません。
  
  Note
  
  イベントをトリガーとして動作するプレイブックでチケット生成の可否を決定するには、チケット発生条件を Never にしておいてください。
- Detect Duplicates on: チケットの重複確認に使用するフィールド名を、カンマ（,）区切りで $フィールド名 のマクロ形式で入力（最大2,000文字）。未設定の場合は、Subject の文字列を基準に判定します。
  
  たとえば、Subject を C&C サーバー接続: $src_ip -> $dst_ip に設定しているが、同一ホストから別の C&C サーバーへ接続するイベントやチケットが不必要に多数発生しないようにするには、Detect Duplicates on を $src_ip に設定してください。
- Detect Duplicates for (sec.): チケット発行後に同一イベントが連続して発生したとき、重複イベントを無視する期間（必須、デフォルト: 0、範囲: 0 - 86,400秒）
  - 0 のとき: Reassign Tickets for の設定に従って動作
  - 0 以外のとき: 指定期間内は同一イベントを無視し、該当チケットの根拠資料にも使用しない
- Reassign Tickets for (sec.): チケット発行後に同一イベントが発生したとき、新しいチケットを発行せず、既発行のチケットに根拠資料と発生回数のみを追加する期間（必須、デフォルト: 3,600、範囲: 0 - 86,400秒）
  - 0 のとき: イベント発生ごとに同一件名のチケットを作成
  - 0 以外のとき: 指定期間内は既存チケットに根拠資料と発生回数のみを記録
- Field Order: チケットの根拠資料と通知メールに表示するフィールドの順序。フィールド名を表示順にカンマ（,）で区切って入力（最大2,000文字）。
- On Closing Ticket: Reassign Tickets for が設定されたチケットが完了した後の処理方式（デフォルト: Reset Ticket Timer）
  - Keep Ticket Timer: チケットが完了処理された後も、集約タイマーが満了するまでに同一の脅威イベントが発生すると、完了したチケットに根拠資料と発生回数を記録
  - Reset Ticket Timer: チケットが完了処理されると集約タイマーも満了したものとみなし、次に同一の脅威イベントが発生した際に新しいチケットを発行
保存する前にクエリが意図した結果を返すか確認するには、画面最下部のシミュレーション項目を使用してください。
- Simulated Date & Time: ルールが実行されると仮定する時刻。空欄のままにすると現在時刻を基準にします。
- Run: シミュレーションクエリを実行し、結果を Simulated Data に表示します。実行するには Analysis Method のクエリが有効である必要があります。
- Open Query Window: シミュレーションクエリを新しいウィンドウのクエリ画面で実行します。Run と同様に、クエリが有効なときだけ使用できます。
- Query to Simulate: 実際に実行されるクエリ文。Time Window と Truncation から計算した from、to の値を設定する set コマンドが前に、Field Order に従って並べ替える order コマンドが後ろに自動的に付きます。直接編集はできません。
- Simulated Data: シミュレーションクエリの結果表。
シミュレーションは結果を表示するだけで、イベントやチケットは作成しません。
入力した項目が正しいか確認し、Save をクリックしてください。追加したルールは有効な状態で保存されます。

バッチ検知ルールの複製

既存のバッチ検知ルールを複製するには、

バッチ検知ルール一覧で、複製するルールの行のチェックボックスを選択すると、ツールバーにアクションメニューが表示されます。
ツールバーで Duplicate をクリックしてください。
Clone Scenario ダイアログで、複製するルールの一覧を確認して Duplicate をクリックしてください。複製しない場合は Cancel をクリックしてください。
複製元のルール名의 사본 という名前の新しいルールが無効な状態で追加されます。この接尾辞はサーバーが付ける固定文字列で、日本語コンソールでも韓国語で表示されます。同じ名前がすでにある場合は、名前の後に (2) のように番号が付きます。

バッチ検知ルールの編集

バッチ検知ルールを編集するには、

バッチ検知ルール一覧で、編集するルールの名前をクリックしてください。
Edit Batch Rule 画面の Settings タブで情報を修正し、Save をクリックしてください。編集可能な項目の説明については、バッチ検知ルールの追加を参照してください。

編集画面には Settings のほかに Version history、Exception Conditions タブがあります。保存していない変更がある状態で他のタブに移動すると、変更を破棄するか確認するダイアログが表示されます。

バッチ検知ルールの実行

スケジュールを待たずにバッチ検知ルールをすぐに実行するには、

バッチ検知ルール一覧で、実行するルールの行のチェックボックスを選択してください。
ツールバーにアクションメニューが表示されます。アクションメニューで Run Now をクリックしてください。
Run Batch Rule ダイアログで実行するルールの一覧を確認し、Run をクリックしてください。
ルールに従ってイベントが検知されると、Response > Tickets および Analysis > Event Summary で検知結果を確認できます。

Note

Run Now は有効かどうかにかかわらず、ルールをすぐに1回実行します。スケジュールによる実行は有効なルールにのみ適用されます。

バッチ検知ルールのバージョン履歴の表示

バッチ検知ルールを追加または編集するたびに、新しいバージョンが自動的に作成されます。ルール編集画面の Version history タブで過去のバージョンを確認し、特定のバージョンに復元したり、別のルールとして複製したりできます。

バッチ検知ルール一覧で、バージョン履歴を確認するルールの名前をクリックしてください。
ルール編集画面上部の Version history タブをクリックしてください。最新バージョンから時系列の逆順でバージョンカードが表示されます。カードは10件ずつ読み込まれ、さらにある場合は一覧の下の Load More をクリックしてください。

各バージョンカードには次の情報が表示されます。

バージョンを変更した時刻、変更したアカウント、バージョン番号（例: Changed by James Miller at 2026-04-12 17:30:00. - Version 3）
該当バージョン時点のバッチクエリ本文
Change History: 前のバージョンと比較して変更された項目を Item is changed to New value. (previous: Previous value) の形式で表示します。変更された項目が3つを超える場合は、Show N more + ボタンですべての項目を展開して確認でき、Show Less で再び折りたためます。変更された項目がない場合は No changes to show. と表示されます。
復元によって作成されたバージョンの場合は、Change History の見出しの横に基準となったバージョン番号（例: Restored to version 2.）

以前のバージョンへの復元

以前のバージョンの設定にルールを戻すには、

Version history タブで復元するバージョンのカードを探してください。現在使用中のバージョンや、変更のないバージョンのカードには Restore ボタンは表示されません。
カードの Restore をクリックしてください。
確認ダイアログで復元するバージョンを確認し、復元を実行してください。
復元に成功すると、復元した設定が新しいバージョンとして作成され、Settings タブに戻ります。検証に失敗した場合は、失敗理由を示すダイアログが表示され、Edit Scenario をクリックすると、復元しようとした設定を Settings タブに読み込んで直接修正できます。

以前のバージョンを新しいルールとして複製

以前のバージョンの設定をもとに別のルールを作成するには、

Version history タブで複製するバージョンのカードの Duplicate をクリックしてください。変更のないバージョンには Duplicate ボタンは表示されません。
Clone Scenario ダイアログで新しいルールの名前を入力し、複製を実行してください。名前のデフォルト値は Clone of ルール名 Version N です。
入力した名前で新しいルールが一覧に追加されます。複製したバージョンの有効化状態がそのまま引き継がれるため、一覧の Enabled 列を確認してください。

バッチ検知ルールの例外条件

特定の条件に該当するイベントを検知から除外するには、例外条件を登録します。例外条件はルールごとに管理され、指定した有効期間の間だけ適用されます。

バッチ検知ルール一覧で、例外条件を管理するルールの名前をクリックしてください。
ルール編集画面上部の Exception Conditions タブをクリックしてください。
- Rule: 登録した例外条件です。保存された条件をフィールド、比較演算子、値の順の文字列に展開して表示し、条件が複数ある場合は AND または OR でまとめて表示します。
- Memo: 例外条件を登録した理由などの説明です。
- Validity Period: 例外が適用される開始日時と終了日時です。
- Author: 例外条件を登録したアカウントです。列の右端にあるため、パネルの幅によっては横にスクロールしないと表示されません。
検索ボックスにキーワードを入力すると、Memo と保存された条件からキーワードを探して一覧を絞り込みます。画面に表示される文字列ではなく保存された条件を照合するため、比較演算子の記号のように表示上にしかない文字では検索できません。

例外条件の追加

例外条件を追加するダイアログは、リアルタイム検知ルールと同じです。

Exception Conditions タブで Add をクリックしてください。
ダイアログで Type を選択してください。
- Source IP: 送信元 IP アドレスのフィールドだけで条件を作成します。
- Destination IP: 宛先 IP アドレスのフィールドだけで条件を作成します。
- Source IP / Destination IP: 両方のフィールドの条件を AND でまとめます。
- Custom: 条件ビルダーでフィールドと条件を直接構成します。
Rule に条件を入力してください。Custom を選択すると条件ビルダーが表示されます。
- グループの AND、OR をクリックして、配下の条件を結合する方法を決めます。
- フィルター行は値の種類（String、Number、Boolean、IP address）、フィールド名、比較方法、値で構成されます。フィールド名はクエリ結果のフィールド名と一致させてください。
- Filter をクリックすると同じグループに条件を追加し、AND group または OR group をクリックすると入れ子のグループを作成します。グループは3段階まで作成でき、フィルター条件は最大50個、条件グループは最大10個まで追加できます。
Memo に例外を登録した理由を入力してください（最大2,000文字）。
Validity Period に開始日時と終了日時を指定してください（デフォルト: 当日から7日）。終了日時は開始日時より前にはできず、現在時刻より後である必要があります。
Add をクリックしてください。取り消すには Cancel をクリックしてください。

例外条件の削除

個別の条件を削除するには、一覧で条件のチェックボックスを選択し、ツールバーのをクリックしてください。
有効期間が過ぎた条件をまとめて整理するには、Delete expired rules をクリックしてください。確認ダイアログで削除対象の一覧を確認してから削除を実行してください。

バッチ検知ルールの削除

バッチ検知ルールを削除するには、

バッチ検知ルール一覧で、削除するルールの行のチェックボックスを選択してください。
ツールバーにアクションメニューが表示されます。アクションメニューで Delete をクリックしてください。
Delete batch rule(s) ダイアログで削除するルールの一覧を確認し、Delete をクリックしてください。削除しない場合は Cancel をクリックしてください。