ルールの理解

概要

このページでは、セキュリティ分析で使用される 3 種類のルール、すなわち、基本的なイベントフィルタリングを行う標準ルール、異常な単一イベントの挙動を検出する異常検知ルール、および複雑な攻撃シーケンスを特定する高度なルールについて説明します。

各ルールタイプには、柔軟な監視と正確な脅威検出を実現するための設定フィールド、フィルター、しきい値、および異常モデルが用意されています。

標準ルール

標準ルールは、選択されたアクションに応じて、収集されたログから特定のイベントを識別し、フィルタリングするだけの基本的なルールです。 このシンプルな構成では、オプションのフィルターやしきい値を使用して、目的のアクションを選択します。標準ルールには、異常モデルや行動のベースライン設定は含まれません。これらは、特定の条件に完全に一致したログデータを表示および監視するためのものであり、これにより、ユーザーは関心のある他のイベントに集中することができます。

ルール設定フィールドの理解

• ルール名：識別のために、ルールに一意の名前を付けます。
• 説明（オプション）：ルールとその目的に関する簡単な説明を入力します。
• 重大度：このルールに関連付ける重大度レベルを選択します。たとえば、「トラブル」レベルの基準は、中程度の重大度を示します。重大度には以下の3つのレベルがあります：
  • 重大
  • トラブル
  • 注意
• アクション：ルールで監視するログイベントの種類を選択します。600以上のアクションに関連付けられた3つのルールタイプすべてでサポートされているログタイプの詳細な一覧については、以下をご覧ください。

  カスタムアクションを作成する場合は、「カスタムルールの作成」ヘルプドキュメントを参照してください。

• フィルター（オプション）：ログイベントをフィルタリングするための条件を1つ以上追加します。これにより、ルールが適用されるログイベントが絞り込まれます。ルール処理中にフィルターがどのように評価・適用されるかについては、こちらを参照してください。
  注：

  Log360では、1つのルールに対して設定できるフィルターは最大5つまでです。

  Log360 Cloudでは、1つのルールにつき最大15個のフィルターのみ設定可能です。

• しきい値（オプション）：
  • 一定期間内のイベントの発生回数（個数またはカウント）に基づく閾値を定義します。この閾値を超えると、ルールがトリガーされます。
  • カウントベースのしきい値に加え、「合計」および「平均（Avg）」のしきい値を設定することもできます。
  • しきい値条件は、特定のフィールドによるグループ化に基づいて適用できるため、よりきめ細かな検出と制御が可能になります。ルール作成時にしきい値条件がどのように評価・適用されるかについては、こちらを参照してください。
• ルールメッセージ：ルールがトリガーされた際にアラートメッセージとして表示させたいテキストを入力します。

異常ルール

セキュリティ分析の「ルール」カテゴリにある異常検知ルールは、ルール条件に含まれる単一のアクションにのみ関連する、異常検知に特化した設定です。各異常検知ルールは、選択された 1 つのイベントタイプ（アクション）に適用されます。例：「ファイルアクセス失敗」、「アカウント削除」、「グループ削除」など。

ルール設定フィールドの理解

• ルール名：識別のために、ルールに一意の名前を付けます。
• 説明（任意）：ルールとその目的に関する簡単な説明を入力します。
• 重大度：このルールに関連付ける重大度レベルを選択します。たとえば、「トラブル」レベルの基準は、中程度の重大度を示します。重大度には以下の3つのレベルがあります：
  • 重大
  • トラブル
  • 注意
• アクション：ルールで監視したいログイベントの種類を選択してください。Log360で利用可能な600以上のアクションに関連付けられた3つのルールタイプすべてでサポートされているログタイプの詳細な一覧については、以下をご覧ください。

  カスタムアクションを作成する場合は、「カスタムルールの作成」ヘルプドキュメントを参照してください。

  注：異常ルールごとに選択できるアクションは1つだけです。
• フィルター（オプション）：フィルタリングの基準となるログイベントの条件を1つ以上追加します。これにより、ルールが適用されるログイベントが絞り込まれます。これにより、ルールが適用されるログイベントが絞り込まれます。ルール処理中にフィルターがどのように評価・適用されるかについては、こちらを参照してください。
• 異常モデルの基準：正常な動作からの逸脱をどのように検出するかを定義する異常モデルを選択します。設定された各モデルおよび 2 つの動作コンストラクタ（「ホスト上」、「ユーザー別」）について、異常がトリガーされます。主な異常モデルは 5 つあります：
  • 通常とは異なる時間帯のユーザー：ユーザーの通常のログイン／アクセス時間外に発生するユーザーアクティビティを検出します。
  • 異常な実行回数のユーザー：通常の行動パターンよりも頻繁に、または稀にアクションを実行するユーザーを検出します。
  • 通常とは異なる時間帯のログソース：通常の稼働時間または予想されるアクティビティ時間帯外でイベントを生成するログソースを検出します。
  • イベント数が異常なログソース：通常よりも著しく多い、または少ない量のイベントを生成するログソースを検出します。
  • 不審なユーザー名を持つログソース：そのログソースに通常関連付けられているものとは異なる特定のユーザー名に関連付けられているログソースを検出します。
  • カスタム異常モデルを作成する場合は、[カスタムモデルの追加] をクリックしてください。
    注：カスタム異常モデルは、作成されたルールだけでなく、特定のアクションに関連付けられます。つまり：

    1. カスタムモデルは、設定されたアクションにのみ適用されます。
    2. 同じアクションを使用しているルールであれば、他のルールでも同じカスタムモデルを再利用できます。
  • 「モデル元」および「モデル名」のフィールドを設定し、「保存」をクリックしてこのカスタム異常モデルを保存します。保存したこの異常モデルは、今後ルールを作成する際にも使用できます。
    注：1つのルールに設定できる異常モデルは最大5つまでです。
• ルールメッセージ：ルールがトリガーされた際に表示されるアラートメッセージとして表示したいテキストを入力してください。

高度なルール

異常検知ルールが主に単一のアクションのみに焦点を当てているのとは異なり、高度なルールは、複数のアクションに対応する一連のイベントを相関させることで、複雑で多段階にわたるインシデントの検知に役立ちます。さらに、アクションを順番にリンクさせることで、複数のイベントタイプにまたがる攻撃パターン（たとえば、数回のログオン失敗の後にログインが成功するといったパターン）を特定することができます。

アクションのシーケンスは順序通りに定義され、アクションのパターン全体が発生した際にルールがトリガーされます。各アクションについては、フィールドベースのフィルターを設定して、指定されたすべての条件を満たすイベントに絞り込むことで、さらに微調整を行うことができます。

ルール設定フィールドの理解

• ルール名：識別のために、ルールに一意の名前を付けます。
• 説明（任意）：ルールとその目的に関する簡単な説明。
• 重大度：このルールに関連付ける重大度レベルを選択します。たとえば、「トラブル」レベルの基準は、中程度の重大度を示します。重大度には以下の3つのレベルがあります：
  • 重大
  • トラブル
  • 注意
• ルールの条件
• アクション：ルールで監視するログイベントの種類を選択します。「詳細ルール」では、複数のアクションを選択できます。Log360 で利用可能な 600 以上のアクションに関連付けられた 3 種類のルールすべてでサポートされているログタイプの詳細なリストについては、以下をご覧ください。

  カスタムアクションを作成する場合は、「カスタムルールの作成」ヘルプドキュメントを参照してください

• フィルター（オプション）：フィルタリングの基準となるログイベントの条件を1つ以上追加します。これにより、ルールが適用されるログイベントが絞り込まれます。これにより、ルールが適用されるログイベントが絞り込まれます。ルール処理中にフィルターがどのように評価・適用されるかについては、こちらを参照してください。
• アクションへのリンク：複数のアクションを選択した場合、それらのアクションを相互にリンクさせることができます。これにより、それらのアクションに関連するイベントを相関付け、不審なアクティビティの監視が可能になります。
• しきい値／異常モデル：
  • しきい値（オプション）：一定期間内の繰り返しについて、個数または発生回数に基づくイベント発生制限を定義します。制限を超えると、ルールがトリガーされます。
  • 異常モデル：通常の動作からの逸脱をどのように検出するかを定義するために、異常モデルを選択します。設定された各モデルについて、異常がトリガーされます。異常ルールの設定と同様に、詳細なルール設定中にカスタム異常モデルを作成することもできます。
  注：しきい値と異常モデルの設定は、互いに併用できないため、どちらか一方のみを選択する必要があります。この制限はルール全体に適用され、すべてのアクションを通じて1つのオプションのみが許可されます。
• 「次のアクションまでの時間間隔（Followed by within）」：各アクションについて、「次のアクションまでの時間間隔（Followed by within）」フィールドを使用して、そのアクションの後に次のアクションが実行されるまでの時間間隔を指定します。利用可能なドロップダウンメニューを使用して、秒、分、または時間で時間間隔を定義できます。
• 実行設定：「実行設定」オプションを使用すると、要件に応じてルールのスケジュール設定を行うことができます。このオプションは、高度なルールでのみ利用可能です。

この設定には、「連続」および「5分」「10分」「30分」「1時間」などの事前定義されたスケジュール時間範囲に加え、追加のカスタムオプションが含まれます。カスタムオプションを選択した場合は、「スケジュール頻度」と「追加のルックバック時間」を設定する必要があります。

注：ルールに「異常時アクション」が選択されている場合、実行設定はインテリジェントモードで動作し、ルールとその基準に基づいて実行モードが自動的に割り当てられます。実行設定を手動で構成することはできません。
• ルールメッセージ：ルールがトリガーされた際にアラートメッセージとして表示したいテキストを入力してください。

アクション - サポートされているログタイプ

以下は、Log360で利用可能な600以上のアクションに関連付けられた3つのルールタイプすべてでサポートされているログタイプのリストです。

すべてのログタイプを一度に選択したい場合は、「すべて選択」チェックボックスをクリックしてください。

その他のフィールド

1. マクロの追加

3 つのルールタイプすべてにおける [マクロ] フィールドには、フィールド名のリストが含まれています。ルールに対して 1 つを選択すると、そのルールがトリガーされた際に、その特定のフィールド名を使用してルールメッセージが生成されます。[マクロ] 内の利用可能なフィールドオプションは、ルール作成時に選択されたアクションによって異なります。

2. ルールインサイト：MITRE ATT&CK マッピングなど

このオプションは、選択したルールを関連する MITRE ATT&CK のテクニックや戦術にマッピングすることで、そのルールのコンテキストを提供します。 これにより、このルールが対応する脅威の挙動を理解でき、結果として脅威の調査と対応を効果的に行うことができます。すべてのルールタイプに対してタグ付け、MITREマッピング、および充実したコンテキスト詳細を提供することで、システムは、セキュリティのニーズに合わせた堅牢で整理された、実用的なルールを作成できるようにします。

これをクリックすると、「ルールインサイト」のフィールドボックスがスライドして開きます。

ルールの属性

「ルール属性」を使用すると、特定の属性に基づいてルールをマッピングおよびタグ付けし、整理を向上させ、実用的な洞察を得ることができます。これらは、ルールの効率的な管理やデータの充実化に役立ちます。

MITRE ATT&CK

• 戦術のリストは、検索オプション付きのドロップダウンメニューとして表示されます。
• 戦術が選択されると、それに関連するテクニックがテクニックのドロップダウンに一覧表示されます。
• テクニックにサブテクニックがある場合、そのテクニックの下に一覧表示されます。
• 戦術とテクニックの両方が選択されている場合、「追加」オプションが表示され、リストに追加されます。
• 「キャンセル」アイコンをクリックすると、追加されたリストから行が削除されます。

詳細については、「MITRE ATT&CK TTP(S) フレームワークの統合」を参照してください。

[ルール情報の追加] をクリックすると、画面に以下の内容が表示されます。

ルール情報

ルール情報には、ルールの実行や緩和戦略に関する追加のコンテキスト情報が記載されています。これにより、技術者は設定変更や予防措置を講じ、検知能力を向上させ、環境のセキュリティを維持することができます。

• 前提条件
  • 前提条件とは、セキュリティルールが効果的に機能するために満たすべき条件や要件を定義したものです。これにより、ルールが意図したとおりに機能し、正確な検知が行われることが保証されます。
  • これは、特定のレポートに関するデータが見つからない場合に、セキュリティルールのレポートページに表示されるほか、ルール概要のドリルダウンでも表示されます。
• 緩和策
  • 緩和策とは、セキュリティルールによって検出された脅威に対応したり、無力化したりするための手順を概説したものです。セキュリティインシデントの影響を最小限に抑えるための、実行可能な指針を提供します。

3. ルールのプレビュー

• [ルールのプレビュー] オプションは、ルール設定でアクションが選択された後にのみ表示されます。
• カレンダーを使用して日付範囲を選択するオプションも利用できます。
• 追加の条件を追加または削除した場合、「プレビューの再読み込み」オプションを使用してプレビューを再読み込みできます。
• 検出レポートは、ルール作成後にトリガーされたデータにのみ適用されますが、ルールのプレビューは、すでに収集済みのログも基に表示されます。
• 「詳細ルール」の作成では、まずルール全体のプレビューが表示され、必要に応じて対応するアクションのプレビューに切り替えることができます。

4. しきい値の設定

特定の条件が満たされた場合にのみルールをトリガーする必要がある場合、しきい値を設定できます（標準および／または詳細なルール作成時のみ）。しきい値が有効になっている場合、そのルールは計算負荷が高いとみなされ、ライセンスの算定対象となります。このようなルールは「高計算負荷ルール」としてマークされます。

しきい値ベースのルールでは、集計機能もサポートされています。

利用可能なしきい値オプション

アクションで選択したフィールド名に基づいて、以下のオプションが利用可能です：

• n分以内に（同一のフィールド名において）カウントがnを超える
• n分以内にフィールド名の最小値がnより大きい（同じフィールド名の場合）
• n分以内にフィールド名の最大値がnを超える（同じフィールド名の場合）
• n分以内にフィールド名のユニーク件数が n を超える（同じフィールド名の場合）
• n分以内にフィールド名の平均がnより大きい（同じフィールド名の場合）
• n 分以内に、フィールド名の合計が n より大きい（同じフィールド名の場合）

しきい値条件における「グループ化」および「一意」フィールドの挙動

グループ化フィールド：

このオプションは、特定のフィールドを定数として扱うために使用されます。このオプションが選択されている場合、選択されたフィールドの値がすべての反復を通じて一定である場合にのみ、一連の繰り返しアクションがルールによって受け入れられます。

たとえば、「ターゲットユーザー」フィールドが定数として扱われる場合、このフィールドの値がすべての反復を通じて変更されない場合にのみ、アクションがトリガーされます。このフィールドの値が異なるイベントが生成された場合、アクションはトリガーされません。

以前は、このオプションは「isConstant」と呼ばれていました。

Distinct:

「Distinct」条件は、フィールドを変数として扱うために使用されます。この条件が選択されている場合、アクションは、評価のたびにフィールドの値が変更された場合にのみトリガーされます。

たとえば、アクション内の「ターゲットユーザー」フィールドに「Distinct」条件が適用されている場合、そのフィールドの値が各反復ごとに異なる場合にのみ、アクションがトリガーされます。

以前は、このオプションは「isVariable」と呼ばれていました。

5. フィルター

フィルタは、デバイスのポスチャ、脆弱性のステータス、設定ミス、および脅威インテリジェンスの指標に基づいてルールの評価を絞り込むことができる、複数の条件タイプをサポートしています。

脆弱性および設定ミスの比較演算子の使用

これらの比較演算子は、Endpoint Central との統合が正常に完了した後にのみ利用可能になり、デバイス関連のフィールドで使用できます。

• 「脆弱である」：Endpoint Central でデバイスが「脆弱」としてタグ付けされているかどうかを確認します。
• 「～に対して脆弱」：特定の攻撃（例：CVE-2023-38831）に対して脆弱なデバイスを特定します。
• 設定ミス：Endpoint Central によって特定された設定ミス（例：Windows Credential Guard が無効になっている）があるデバイスを検出します。

悪意あり

「悪意あり」条件は、IP アドレスフィールドでのみ利用可能です。これは、検出された IP アドレスが、製品の内部データベースに保持されている悪意のある IP アドレスの事前定義リストに含まれているかどうかを確認します。

実行モード：オペレーターモードの違い（継続的 vs. スケジュール済み）

ルックバック期間

定義：

ルックバック時間は、スケジュールされたルールのログ検索ウィンドウを拡張するために設定される追加期間です。たとえば、スケジュール間隔が5分に設定され、ルックバック時間も5分に設定されている場合、システムは合計10分間のログ（現在の5分間と過去5分間）を分析します。

目的：

これにより、スケジュールされた間隔の直前に発生したイベントもルールの評価対象に含まれるようになり、スケジュールの境界をまたぐ検出漏れリスクを最小限に抑えることができます。

デメリット：

ルックバックを有効にすると、連続するスケジュール間でデータが重複する可能性があります。同じログセットが複数の間隔で再評価される可能性があるため、検出結果が重複する結果となる場合があります。

標準ルール（単一アクションルール）

高度なルール（複数のアクションを含むルール）

ルール固有のユースケース

異常ルール

1. ブルートフォースによるログイン試行

ユースケース

あるサービスアカウントで、極めて短い時間内に20件のログイン失敗イベントが記録されました。これは、ブルートフォース攻撃またはクレデンシャルスタッフィング攻撃が現在行われていることを強く示唆しています。

異常検知ルールによる対応

「ログオン失敗」アクションを持つアクティブな異常検知ルールと、カウントベースの異常検知モデルを組み合わせることで、アカウント乗っ取りの試みを迅速に検知することができます。脅威への対応として、攻撃者がネットワーク内に侵入する機会を阻止できる可能性があります。

2. サードパーティアカウントの不審な活動

ユースケース

マネージドサービスベンダーのアカウントが、通常の業務時間外に設定変更を開始した。

異常検知ルールとの併用

「設定変更」というアクションを、時間ベースの異常検知モデルと組み合わせることで、営業時間外に発生するアクティビティを集中的に監視できます。 例えば、このユーザーの通常の勤務時間は午前9時から午後6時までですが、現在は午前3時に操作を行っています。さらに、位置情報に基づく異常検知モデルを活用することで、予期しない地理的位置からの変更を検知することができます。

こうした確立されたベースラインからの逸脱が異常として検知され、セキュリティチームが迅速に調査を行い、認証情報の漏洩やセッションハイジャックの可能性を未然に防ぐのに役立ちます。

高度なルール

1. 一括変更によるデータ流出

ユースケース

権限のないユーザーが、重要なファイルサーバー上の大量のファイルを削除または名前変更しました。

高度なルール
を使用する場合「ファイルの削除」アクションと「ファイルの一括リネーム」イベントを関連付け、10 分間のウィンドウ内でのファイルアクセス総数に対するしきい値とフィルタを組み合わせた高度なルールを使用することで、重要サーバーへの不正アクセスの範囲を絞り込むことができます。

2. QA環境における不正なアプリケーションのデプロイ

ユースケース

DevOps ユーザー以外のユーザーが、ステージング環境で許可されていない実行可能ファイルをデプロイまたは実行した。

高度なルール
を使用する場合 QA タグが付けられたマシン上で「実行ファイルの作成」と「スケジュールされたタスクの作成」を関連付け、ユーザーロールによるフィルタリングと 10 分以内のイベントシーケンスに対するしきい値を設定した高度なルールを使用することで、このような不正なデプロイ活動を早期に検知できます。

あわせて読む

このドキュメントでは、標準ルール、異常検知ルール、および高度なルールの仕組み、それらの設定オプション、ならびにブルートフォース攻撃、不審なアカウント活動、データ流出などの実用的なユースケースについて説明しました。

• ルール管理の概要
• カスタムルールの作成
• クエリ文法
• ルールの管理
• 定期的な検知レポート