ログ検出ルール

概要

Datadog でログ検出ルールを作成するには、検出ルールページに移動し、New Rule をクリックします。

ルールタイプ

Cloud SIEM (Security Information and Event Management) の場合、取り込んだログをリアルタイムに分析するために、Log Detection を選択します。

検出方法

しきい値

イベントがユーザー定義のしきい値を超えるタイミングを定義します。たとえば、しきい値が >10 のトリガーを作成すると、条件が満たされたときにセキュリティシグナルが発生します。

新しい値

属性が新しい値に変更されたことを検出します。たとえば、countryIP address などの特定の属性に基づいてトリガーを作成すると、これまでに見られなかった新しい値が見られるたびにセキュリティシグナルが生成されます。

異常検知

特定のしきい値を構成することができない場合、代わりに異常検出ルールを定義することができます。異常検出では、イベントの過去の観測可能性から動的なしきい値が自動的に導き出されます。

不可能移動

不可能移動は、2 つのアクセスイベントの間に人間が移動できる距離よりも大きい距離の異なる場所からのアクセスを検出します。

Third Party

Third Party では、外部のベンダーやアプリケーションからのアラートを転送することができます。抑制クエリやシグナル発生時の通知先を設定してルールを更新することができます。

検索クエリを定義する

検索クエリ

検索クエリを定義する

ログエクスプローラーでの検索と同じロジックを使用して検索クエリを作成します。

オプションで、一意のカウントとシグナルのグループ化を定義します。特定の時間枠で属性に対して観測された一意の値の数をカウントします。定義されたグループ化は、値ごとに各グループ化のシグナルを生成します。 通常、グループ化はエンティティ (ユーザーや IP など) です。グループ化は、クエリを結合するためにも使用されます。

クエリを追加するには、Add Query をクリックします。

: このクエリは、すべての取り込みログに適用されます。

クエリを結合する

タイムフレームをまたぐログを結合すると、セキュリティシグナルの信頼性と重大度を強化することができます。たとえば、ブルートフォースアタックを検出するためには、成功した場合と失敗した場合の認証ログをユーザーと関連付ける必要があります。

検索クエリを定義する

検出ルールはグループ化の値をもとにログを結合します。グループ化の値は通常エンティティ (例えば、IP アドレスやユーザー) となりますが、必要に応じてすべての属性を使用できます。

グループ化

検出ルールケースは、グループ化の値に基づいてこれらのクエリを結合します。一致するケースと値が同じでなければならないため、グループ化属性には通常同じ属性が設定されます。グループ化の値が存在しない場合、ケースが一致することはありません。セキュリティシグナルはケースが一致した場合のみ、一意のグループ化値に対して生成されます。

failed_login が 5 を超え、successful_login が 0 を超える場合に、高重大度のシグナルをトリガーするように設定されたルールケースセクション

以下の例は、同じ @usr.name で 5 回を超えてログインに失敗した場合、および 1 回ログインに成功した場合のケースです。この場合、最初のケースに一致した場合はセキュリティシグナルが生成されます。

検索クエリ

検索クエリを定義する

同じロジックを使用して、ログエクスプローラー検索で検索クエリを構築します。各クエリには ASCII の小文字でラベルが付与されます。クエリ名を ASCII 文字から変更する場合は、鉛筆アイコンをクリックします。

: このクエリは、すべての取り込みログに適用されます。

学習済みの値

学習済みの値を定義する

検出する値 (複数可) を選択し、期間を学習し、オプションでシグナルのグループ化を定義します。定義されたグループ化は、値ごとに各グループ化のシグナルを生成します。通常、グループ化はエンティティ (ユーザーや IP など) です。

たとえば、ユーザー認証を成功させるためのクエリを作成し、Detect new valuecountry に設定し、グループ化を user に設定します。学習期間を 7 days に設定します。構成が完了すると、今後 7 日間に受信されるログは、設定された値で評価されます。学習期間の後にログに新しい値が入力されると、シグナルが生成され、新しい値が学習されて、この値で将来のシグナルが発生するのを防ぎます。

また、1 つのクエリで複数の値を使用して、ユーザーやエンティティを識別することができます。例えば、ユーザーが新しいデバイスからサインインしたときや、今までサインインしたことのない国からサインインしたときに検出したい場合は、device_idcountry_nameDetect new value に追加します。

検索クエリ

ログエクスプローラーでの検索と同じロジックを使用して検索クエリを作成します。

オプションで、一意のカウントとシグナルのグループ化を定義します。特定の時間枠で属性に対して観測された一意の値の数をカウントします。定義されたグループ化は、値ごとに各グループ化のシグナルを生成します。 通常、グループ化はエンティティ (ユーザーや IP など) です。

異常検出は、group by 属性が過去にどのような振る舞いをしたかを検査します。group by 属性が初めて見られ (例えば、ある IP が初めてシステムと通信したとき)、異常である場合、異常検出アルゴリズムには判断材料となる過去のデータがないため、セキュリティシグナルは生成されません。

: このクエリは、すべての取り込みログに適用されます。

検索クエリ

ログエクスプローラー検索と同じロジックで検索クエリを構築します。このクエリをマッチするすべてのログは、不可能移動の可能性を分析されます。現在のクエリにマッチするログを見るには、preview セクションを使うことができます。

ユーザー属性

user attribute には、解析したログのうち、ユーザー ID を含むフィールドを選択します。これは、メールアドレス、ユーザー名、またはアカウント識別子などの識別子にすることができます。

位置情報属性

location attribute は、ログの地理情報を保持するフィールドを指定します。唯一サポートされている値は @network.client.geoip で、これは GeoIP パーサーによって強化され、クライアントの IP アドレスに基づくログの位置情報を提供します。

ベースラインユーザーの位置

シグナルをトリガーする前に、Datadog に通常のアクセス場所を学習させたい場合は、チェックボックスをクリックします。

選択すると、最初の 24 時間はシグナルが抑制されます。その間に Datadog はユーザーの通常のアクセス場所を学習します。これは、ノイズを減らし、VPN の使用や資格情報による API アクセスを推論するのに役立ちます。

不可能移動の行動をすべて Datadog に検出させたい場合は、チェックボックスをクリックしないでください。

Root クエリ

ログエクスプローラー検索と同じロジックを使用して検索クエリを構築します。各新規属性の定義されたトリガーは、24 時間のロールアップ期間にわたってその属性の新規値ごとにシグナルを生成します。

クエリを追加するには、Add Query をクリックします。

: このクエリは、すべての取り込みログに適用されます。

ルールケースを設定する

トリガー

デフォルトの設定を示すセットルールケースセクション

例 (クエリ A が発生し、次にクエリ B が発生した場合) のシグナルをトリガーしたい場合は、Create rules cases with Then operator を有効にしてください。then 演算子は、1 つのルールケースにのみ使用できます。

すべてのルールケースは case ステートメントとして評価されます。したがって、ケースの順序は、最初にマッチしたケースがシグナルを生成するため、どの通知を送信するかに影響します。ルールケースをクリックしてドラッグすると、順序を変更できます。

ルールケースには、過去に定義されたクエリのイベント数に基づいてシグナルを生成すべきかを判断するための論理演算 (>、>=、&&、||) が含まれます。ここで ASCII 小文字の クエリラベルが参照されます。クエリ a のルールケースの例は a > 3 です。

: クエリラベルは演算子に先行しなければなりません。たとえば、a > 3 は使用できますが、3 < a は許容されません。

各ルールケースにつき、「ケース 1」のような名前を付与します。シグナルの生成時には、この名前がルールの名称に追加されます。

重大度および通知

Set severity to ドロップダウンメニューで、適切な重大度レベル (INFOLOWMEDIUMHIGHCRITICAL) を選択してください。

Notify セクションで、オプションで各ルールケースに対する 通知ターゲットを構成できます。

また、通知ルールを作成して、個々の検出ルールに対する通知設定の手動での編集を避けることが可能です。

タイムウィンドウ

An evaluation window is specified to match when at least one of the cases matches true. This is a sliding window and evaluates cases in real time.

After a signal is generated, the signal remains “open” if a case is matched at least once within the keep alive window. Each time a new event matches any of the cases, the last updated timestamp is updated for the signal.

A signal closes once the time exceeds the maximum signal duration, regardless of the query being matched. This time is calculated from the first seen timestamp.

ケースを追加する場合は、Add Case をクリックします。

: この evaluation window は、keep alive および maximum signal duration 以下でなければなりません。

ルールケースを定義する

重大度および通知

Set severity to ドロップダウンメニューで、適切な重大度レベル (INFOLOWMEDIUMHIGHCRITICAL) を選択してください。

Notify セクションで、オプションで各ルールケースに対する 通知ターゲットを構成できます。

また、通知ルールを作成して、個々の検出ルールに対する通知設定の手動での編集を避けることが可能です。

価値を忘れる

一定期間表示されない場合に値を忘れるには、ドロップダウンメニューからオプションを選択します。

同じシグナルを更新する

設定された時間枠内に新しい値が検出された場合にシグナルを更新し続ける最大期間を設定します。 たとえば、1 hour 以内に新しい値が検出されると、同じシグナルが更新されます。最大期間は 24 hours です。

: 新しい値ごとに一意のシグナルが必要な場合は、この値を 0 minutes に構成してください。

重大度および通知

Set severity to ドロップダウンメニューで、適切な重大度レベル (INFOLOWMEDIUMHIGHCRITICAL) を選択してください。

Notify セクションで、オプションで各ルールケースに対する 通知ターゲットを構成できます。

また、通知ルールを作成して、個々の検出ルールに対する通知設定の手動での編集を避けることが可能です。

タイムウィンドウ

Datadog は、データの季節性を自動的に検出し、異常と判断された場合にセキュリティシグナルを生成します。

一度シグナルが発生すると、データが異常な状態のまま、最終更新のタイムスタンプが異常な期間更新された場合、シグナルは「オープン」のままとなります。

異常が残っているかどうかにかかわらず、時間が最大シグナル継続時間を超えると、シグナルは「クローズ」します。この時間は、最初に見たタイムスタンプから計算されます。

不可能移動検出方式は、ルールケースの設定を必要としません。

重大度および通知

Set severity to ドロップダウンメニューで、適切な重大度レベル (INFOLOWMEDIUMHIGHCRITICAL) を選択してください。

Notify セクションで、オプションで各ルールケースに対する 通知ターゲットを構成できます。

また、通知ルールを作成して、個々の検出ルールに対する通知設定の手動での編集を避けることが可能です。

タイムウィンドウ

An evaluation window is specified to match when at least one of the cases matches true. This is a sliding window and evaluates cases in real time.

After a signal is generated, the signal remains “open” if a case is matched at least once within the keep alive window. Each time a new event matches any of the cases, the last updated timestamp is updated for the signal.

A signal closes once the time exceeds the maximum signal duration, regardless of the query being matched. This time is calculated from the first seen timestamp.

トリガー

すべてのルールケースは case ステートメントとして評価されます。したがって、ケースの順序は、最初にマッチしたケースがシグナルを生成するため、どの通知を送信するかに影響します。ルールケースをクリックしてドラッグすると、順序を変更できます。

ルールケースには、過去に定義されたクエリのイベント数に基づいてシグナルを生成すべきかを判断するための論理演算 (>、>=、&&、||) が含まれます。ここで ASCII 小文字の クエリラベルが参照されます。クエリ a のルールケースの例は a > 3 です。

: クエリラベルは演算子に先行しなければなりません。たとえば、a > 3 は使用できますが、3 < a は許容されません。

重大度および通知

Set severity to ドロップダウンメニューで、適切な重大度レベル (INFOLOWMEDIUMHIGHCRITICAL) を選択してください。

Notify セクションで、オプションで各ルールケースに対する 通知ターゲットを構成できます。

また、通知ルールを作成して、個々の検出ルールに対する通知設定の手動での編集を避けることが可能です。

ケースを追加する場合は、Add Case をクリックします。

非本番重大度の低減

信号のノイズを減らす方法の 1 つは、非本番環境の信号よりも本番環境の信号を優先させることです。Decrease severity for non-production environments チェックボックスを選択すると、非本番環境のシグナルの重大度を、ルールケースで定義されたものから 1 レベル下げることができます。

本番環境におけるシグナルの重大度非本番環境におけるシグナルの重大度
クリティカル
情報
情報情報

重大度の減少は、環境タグが stagingtest または dev で始まっているシグナルに適用されます。

Say what’s happening

Add a Rule name to configure the rule name that appears in the detection rules list view and the title of the Security Signal.

In the Rule message section, use notification variables and Markdown to customize the notifications sent when a signal is generated. Specifically, use template variables in the notification to inject dynamic context from triggered logs directly into a security signal and its associated notifications. See the Notification Variables documentation for more information and examples.

シグナルにタグを追加するには、Tag resulting signals ドロップダウンメニューを使用します。例えば、security:attacktechnique:T1110-brute-force のようになります。

: security タグはセキュリティシグナルの分類に用いられる特殊なタグです。attackthreat-intelcomplianceanomalydata-leak など他のタグの使用を推奨します。

抑制ルール

オプションで、シグナルの生成を防ぐための抑制ルールを追加できます。例えば、あるユーザー (john.doe) がシグナルをトリガーしているが、そのユーザーの行動が問題なく、このユーザーからシグナルがトリガーされることを望まない場合、次のクエリを Add a suppression query フィールドに追加します: @user.username:john.doe.

さらに、抑制ルールでは、ログを分析対象から除外するための除外クエリを追加できます。 これらのクエリは、ログ属性に基づきます。: 抑制は、以前はログ除外クエリに基づいていましたが、今後は抑制ルールの Add a suppression query ステップに含まれるようになりました。

ルール非推奨

すべてのすぐに使える検出ルールの定期的な監査を行い、忠実なシグナル品質を維持します。非推奨のルールは、改良されたルールに置き換えられます。

ルール非推奨のプロセスは以下の通りです。

  1. ルールに非推奨の日付が書かれた警告が表示されています。UI では、警告が以下に表示されます。
    • シグナルサイドパネルの Rule Details > Playbook セクション
    • その特定のルールのルールエディター
  2. ルールが非推奨になると、ルールが削除されるまでに 15 か月の期間があります。これは、シグナルの保持期間が 15 か月であるためです。この間、UI でルールの複製を行うと、ルールを再び有効にすることができます。
  3. 一度削除されたルールは、複製して再度有効にすることはできません。

その他の参考資料