コンテンツにスキップ

検出の抑止ルール🔗

デフォルトでは Detection Triage Dashboard に表示されないものの、検索では引き続き見つけられるように、作成時に検出を 抑止済み として解決する検出の抑止 ルール を作成できます。

重要

抑止済みの検出は、Secureworksのアナリストによってトリアージされません。

ヒント

より高いレベルのサポートをご希望の場合、SecureworksプロフェッショナルサービスチームがTaegis XDRへの投資から最大限の価値を引き出すお手伝いをいたします。高度なスキルを持つコンサルタントが、迅速な展開、最適化、価値実現までの時間短縮をサポートします。詳細については、 Professional Services Overview。

検出の抑止の仕組み🔗

抑止ルールが詳細検索と異なる動作をすることがある理由を理解するには、抑止の実行がどのように処理されるかを理解することが重要です。

検出の抑止は、検出が生成されている途中の早い段階で適用され、確定されて Detection Triage Dashboard に公開される前に実行されます。これは意図的なものです。公開前に検出を抑止済みとして解決することで、自動化プレイブックやホスト隔離などの下流の自動対応アクションがトリガーされるのを防ぎます。抑止が検出の公開後に実行された場合、検出が抑止される前に自動ワークフローが実行される可能性があります。

ルールを作成する際に留意すべき結果が 3 つあります。

1. すべてのフィールドが抑止ルールで利用できるわけではありません。 一部のデータは、追加のエンリッチメント、デコードされた値、概要メタデータなど、検出の生成後に追加されます。これらのフィールドは、抑止ルールの実行時点では利用できないため、抑止ルールに含めることはできません。具体例については FAQ を参照してください。

2. 抑止と詳細検索は異なるシステムによって評価されます。 詳細検索は、完了して完全にエンリッチされた検出をクエリします。抑止ルールは、上記で説明したより早い時点の検出データに対して、別のエンジンで評価されます。その結果、次のようになります。

  • クエリは詳細検索で結果を返しても、抑止では何も一致しないことがあり、その逆もあります。
  • See potential matches with current data プレビューは詳細検索を使用するため、有用なガイドではありますが、抑止ルールが同じ検出に一致することを保証するものではありません。
  • 一部のフィールド名と構文は両者で異なります。異なる場合は、このページで説明している抑止の構文を使用してください。

注意

このタイミングのため、抑止ルールへの変更は即座には適用されません。ルールを作成、編集、有効化、または無効化した後は、変更が有効になるまで少なくとも 10 分待ってください。ルール変更の直後に作成された検出には、その変更が反映されない場合があります。

3. 抑止条件は、検出全体のどこかで真であるだけでなく、すべてが同時に真である必要があります。 検出は、時間の経過とともに別々に真になった一致条件を組み合わせることがあります。詳細検索は、完成した検出全体に対してクエリを評価するため、source_entities.x = a AND source_entities.y = z のようなクエリは、x と z が後で同じ検出にまとめられた別々の時点で真になった場合でも一致することがあります。抑止ルールでは、すべての条件が同時に真である必要があります。x と z が別々にしか真でなかった場合、同じクエリで詳細検索ではその検出が見つかっても、ルールは一致しません。

注意

現時点では、検出またはそのエンティティから、お客様の条件が同時に真だったのか別々だったのかを判断する方法はありません。詳細検索では見つかるのに抑止ルールが検出に一致しない場合は、一度に 1 つの条件でテストしてみてください。

検出の抑止ルールを表示する🔗

  1. Taegis Menu から、Detections > Customization Rules を選択します。Custom Rules テーブルが表示されます。
  2. Suppression Rules タブを選択して、現在のすべての抑止ルールを表示します。

抑止ルール

テナントルールはそのテナント固有であり、その個別のテナントに対する検出のみを抑止します。グローバルルールは、すべての XDR テナントに適用されます。グローバルルールは、一般に、検出ルールまたは検知機が調整されるまでの間、検出の大量発生をトリアージするために作成されます。グローバルルールは読み取り専用です。グローバルルールについて質問がある場合は、サポートにお問い合わせください。

抑止ルールを作成する🔗

次のいずれかの方法で検出の抑止ルールを作成できます。

ヒント

クエリ言語の方法 を推奨します。検出の方法 では、今後のリリースで廃止予定の古い regex ベースの条件形式を使用します。

クエリ言語の方法🔗

抑止ルールでは、詳細検索のクエリ言語 を使用して、検出の基になるイベントデータに対する一致をサポートしています。たとえば、抑止ルールでは process.commandline、process、parent_image_path、その他のイベントスキーマなどのクエリ言語要素を使用できます。

注意

詳細については FAQ を参照してください。

抑止ルールを作成する前に、まず詳細検索を使用して、目的の検出を対象とするクエリを作成してください。

  1. 詳細検索クエリ を作成して、今後抑止する対象となる過去の検出を確認します。結果に問題がなければ、そのクエリをコピーしてルールビルダーに貼り付けます。
  2. Detections > Customization Rules に移動し、Suppression Rules タブを選択します。
  3. Suppression Rules テーブルの上にある Create Rule をクリックします。

  4. Create Suppression Rule で、目的の検出を対象とする詳細検索クエリを Rule Criteria フィールドに貼り付けます。

    ヒント

    右ペインの See potential matches with current data をクリックすると、現在お客様のクエリが対象としている検出をプレビューできます。このプレビューは詳細検索を使用するため、保証ではなくガイドとして扱ってください。詳細は 検出の抑止の仕組み を参照してください。

  5. ルールの Name と Description を入力します。

  6. このルールに一致する検出に付ける解決ステータスを選択します。

    クエリ言語で抑止ルールを作成する

  7. Create Rule をクリックします。

検出の方法🔗

注意

検出の方法では、今後のリリースで廃止予定の古い regex ベースの条件形式を使用します。新しいルールには、クエリ言語の方法 を推奨します。

  1. 抑止したい 検出の詳細を開きます。
  2. 検出の詳細ページで、Actions > Create Suppression Rule を選択します。

  3. Create Suppression Rule フォームには、検出のエンティティが入力済みで表示されます。1 つ以上のエンティティを選択してルールを作成するか、条件を手動で追加します。

    • 複数の条件は AND 演算子で結合されます。

    • 条件では、一致の実行に PCRE 正規表現を使用します。

      注意

      手動で追加した条件では、パイプ記号 | は論理 OR としてサポートされていません。

    • 抑止ルールはストリーミングデータに対してクエリを実行し、Primitive Fields にはデフォルト値が自動的に設定されません。これは、Taegis データレイクに保存されて データレイク検索 でクエリされるデータとは異なります。抑止ルールでは、これらの Primitive Fields が設定されているかどうかを確認するために NULL 演算子を使用できます。

    • 入力済みのエンティティを使用する場合、正規表現の特殊文字は自動的にエスケープされます。条件を手動で追加する場合は、これらの文字をエスケープする必要があります。詳細は次の注意を参照してください。

    注意

    正規表現内で次の文字は特別な意味を持ちます: . ^ $ * + - ? ( ) [ ] { } \ | /。IPアドレスやドメイン名などの場合、これらの文字はバックスラッシュでエスケープしてください: 1\.1\.1\.1。
    複数の特殊文字を含む長い文字列をエスケープする場合は、文字列全体を \Q と \E で囲むことで、正規表現の特殊文字として評価されないようにできます。例えば、次の文字列全体をエスケープする場合:
    \Q${jndi:ldap://log4shell-smb-21yg3cbuy21gbcy21gc321uc${lower:ten}.w.nessus.org/nessus}\E
    これは次のようにエスケープした場合と同等です:
    \$\{jndi:ldap:\/\/log4shell\-smb\-21yg3cbuy21gbcy21gc321uc\$\{lower:ten\}\.w\.nessus\.org\/nessus\}

  4. ルールの Name と Description を入力します。

  5. このルールに一致する検出に付ける解決ステータスを選択します。

    特定の検出から抑止ルールを作成する

  6. Create Rule をクリックします。

抑止ルールの詳細と履歴を表示する🔗

Suppression Rules テーブルからルール名を選択すると、その詳細と履歴を表示できます。

抑止ルールの詳細🔗

抑止ルールの Details タブには、ルールが一致する条件とともに、そのルールの概要情報が表示されます。このビューから、ルール名、条件、説明、解決ラベルを編集できます。

抑止ルールの詳細を表示する

ルールが過去 7 日間に検出に一致して抑止している場合は、次が表示されます。

  • 過去 7 日間のヒット数
  • 最終ヒット日時
  • ヒット数を可視化した折れ線グラフ

過去 7 日間にアクティビティがない場合、このセクションは表示されません。

抑止ルールの履歴🔗

抑止ルールの History タブには、ルールの編集に関する変更ログが含まれます。左側のリストから監査ログを選択すると、右ペインに差分が表示されます。

ルールの変更ログを表示する

抑止ルールをアーカイブおよびリストアする🔗

抑止ルールをアーカイブおよびリストアする

抑止ルールを表示しているときに、Archive を選択してアクションを確認すると、そのルールをアーカイブできます。これにより、ルールは無効化され、アーカイブ済みとしてマークされ、Suppression Rules テーブルのデフォルトビューから削除されます。

アーカイブ済みルールを表示するには、テーブルの上にある Showing Archived Rules を選択します。

アーカイブ済みの抑止ルールを表示しているときに、Restore を選択してアクションを確認すると、そのルールをリストアできます。これにより、ルールは無効状態でリストアされ、Suppression Rules テーブルのデフォルトビューに戻ります。トグルを選択してルールを有効にします。

抑止ルールを共有する🔗

テナント内の別のユーザーと抑止ルールを共有するには、ルールの詳細から Copy share link アイコンを選択して直接 URL を取得します。

共有ルールへのリンクをコピーする

一般的な検出の抑止ルール🔗

承認済みスキャナー🔗

承認済みスキャナーから発生する検出を抑止するには、Source IP Address を使用します。

承認済みスキャナーが複数ある場合は、正規表現を使用してすべての IP アドレスを 1 つの抑止ルールに含めます。

ゲストネットワーク範囲🔗

ゲストネットワーク範囲からの検出を抑止するには、Source IP Address を使用し、正規表現でネットワーク範囲全体に一致させます。

エンドポイントでの承認済みプロセス実行🔗

エンドポイントとプロセスの両方に一致させるために、パターンを組み合わせて使用します。

  • エンドポイントに一致させるには、次のいずれかを使用します。

    • Sensor Host ID
    • IP Address（ホストが固定 IP アドレスを持ち、エンドポイントエージェントがインストールされていない場合）

  • プロセスに一致させるには、次のいずれかを使用します。

    • File Name
    • File (MD5|SHA1|SHA256|SHA512)
    • Program Name
    • Program (MD5|SHA1|SHA256|SHA512)
    • Script SHA1（これは実行されたスクリプトのハッシュです）

FAQ🔗

検出が抑止されたかどうかはどのように確認できますか？

抑止済みの検出には、フィードバックラベル Suppressed が付けられます。

抑止済みの検出

抑止済みの検出を検索するにはどうすればよいですか？

抑止済みの検出には、フィードバックラベル Suppressed が付けられます。次のクエリを使用して検索できます。

FROM detection WHERE suppressed = true

結果から抑止済みの検出を除外するには、labelName 条件の一致に NOT を追加します。

FROM detection WHERE suppressed = false

別の方法として、ルール自体からピボットサーチを実行することもできます。ルールを開き、Search for all alerts suppressed by this rule の横にある新しいタブのアイコンを選択します。これにより、この特定のルールによって抑止された検出をクエリする詳細検索が開きます。

抑止済みの検出をケースに追加できますか？

はい、抑止済みの検出も新規または既存のケースに追加できます。

抑止済みの検出のフィードバックラベルを変更できますか？

はい。検出の詳細ビューで、フィードバックラベルを削除するか、ラベルを変更できます。

ルールマネージャーのアクティビティを監査できますか？

はい。ルールマネージャーでのアクションは、Tenant Settings > Audit Logs に移動すると表示できます。監査ログのカテゴリは Rules です。

さらに、ルールの編集に関する変更ログはルール自体から確認できます。抑止ルールの詳細と履歴を表示する を参照してください。

検出が抑止されたとき、どのルールがその検出を抑止したかはどのように確認できますか？

検出の詳細を表示しているときに、Suppression Rule フィールドのルール名をクリックすると、サイドパネルでそのルールを表示できます。

ルールではどの正規表現機能がサポートされていますか？

検出の抑止エンジンでは、正規表現の適用に Hyperscan を使用しています。Hyperscan は、http://www.pcre.org/ で説明されている PCRE ライブラリ libpcre で使用されるパターン構文をサポートしています。ただし、libpcre で利用可能なすべての構文がサポートされているわけではありません。サポートされていない構文を使用すると、コンパイルエラーになります。

詳細については、Hyperscan Developer Reference Compilation を参照してください。

ドメイン名や IP アドレスでは、ドットを扱うために何か特別なことをする必要がありますか？

はい。バックスラッシュを使用してドットをエスケープする必要があります。正規表現では、ドットは改行を除く任意の 1 文字に一致することを意味します。

例: 192\.168\.1\.1 または www\.secureworks\.com

どのエンティティに対して一致させることができ、どのように使用しますか？

抑止ルールで検出エンティティに一致させる方法は 3 つあります。論理型、構造化エンティティ、レガシーエンティティ です。論理型または構造化エンティティを推奨します。レガシーエンティティも引き続きサポートされていますが、廃止が予定されています。

論理型

値を保持する特定のフィールドを知る必要なくエンティティに一致させるには、論理型 を使用します。hostname で抑止するには、@host を使用します。

FROM detection WHERE @host = 'somehostname'

構造化エンティティ

抑止ルールでは、次の形式を使用した構造化エンティティへの一致をサポートしています。

source_entities.<entity_type>.<field_name>
target_entities.<entity_type>.<field_name>

抑止ルールでは、<entity_type> は 特定のエンティティタイプ である必要があります。たとえば、ip_address、auth_domain、user、cloud_user などです。

これはよく混乱の原因になります。詳細検索と抑止では、同じエンティティに対して異なる構文を使用します。詳細検索では汎用の properties セグメントを使用しますが、抑止ルールでは特定のエンティティタイプが必要です。詳細検索からクエリをコピーする場合は、properties セグメントを特定のエンティティタイプに変換してください。そうしないと、抑止ルールは検証に失敗します。

詳細検索の構文 抑止ルールの構文
source_entities.properties.cloud_user_type source_entities.cloud_user.cloud_user_type
source_entities.properties.ip_geo_auto_system_org source_entities.ip_address.ip_geo_auto_system_org

例（抑止ルール）:

FROM detection WHERE title CONTAINS 'Detected suspected stolen user credential for user' AND source_entities.ip_address.ip_geo_auto_system_org CONTAINS 'Cato' AND severity > 0.6

ヒント

ルールを作成するとき、エディターは入力に応じて有効なエンティティフィールドを提案します。正しいエンティティタイプとフィールド名を見つけるためにこれを使用してください。

レガシーエンティティ

レガシーエンティティは、検出の entities JSON オブジェクトに一覧表示されるエンティティです。検出の詳細を表示しているときにこれらを確認するには、次の手順を実行します。

  1. JSON タブに移動します。
  2. entities JSON オブジェクトを展開します。

  3. 検出に一覧表示されているエンティティを確認します。

    検出エンティティ

ルールを作成するときに、ドロップダウンからこれらのエンティティを選択することもできます。

レガシーエンティティに直接一致させるには、entities.entities の文字列全体を使用します。宛先 IP アドレスで抑止するには、次を使用します。

FROM detection WHERE entities = 'destIpAddress:128.206.10.3'

注意

レガシーエンティティ形式は現在もサポートされていますが、今後のリリースで廃止する予定です。新しいルールでは、論理型または構造化エンティティを使用してください。

次のレガシーエンティティを使用して、検出の抑止ルールを作成できます。一意のエンティティは、検出に含まれる個々のイベントから解析されます。

Entity Prefix Entity Description
authDomainName Active Directory ドメイン
sourceUserName Auth ソースユーザー名
sourceAuthDomainName Auth ソースドメイン名
targetUserName Auth ターゲットユーザー名
targetAuthDomainName Auth ターゲットドメイン名
computerName コンピューター名
decodedScriptSha1 デコードされたスクリプト SHA1
destHostName 宛先ホスト名
destIpAddress 宛先 IP アドレス
destIpGeo 宛先 IP ジオロケーション
destMacAddress 宛先 MAC アドレス
dnsName DNS 名
fileMd5 ファイル MD5
fileName ファイル名
fileSha1 ファイル SHA1
fileSha256 ファイル SHA256
fileSha512 ファイル SHA512
ipAddress IP アドレス
city IP アドレスのジオロケーション都市
country IP アドレスのジオロケーション国
latLon IP アドレスの緯度,経度
macAddress MAC アドレス
programMd5 プログラム MD5
programName プログラム名
programSha1 プログラム SHA1
programSha256 プログラム SHA256
programSha512 プログラム SHA512
registryName Registry 名
registryPath Registry パス
scriptSha1 スクリプト SHA1
sensorHostId Sensor Host ID
sensorId Sensor ID
sourceIpAddress ソース IP アドレス
sourceIpGeo ソース IP ジオロケーション
sourceMacAddress ソース MAC アドレス
topPrivateIpDomain トッププライベート IP ドメイン
userName ユーザー名
workstationName ワークステーション名
どの検知機が検出の抑止をサポートしていますか？

すべての検知機と検出ソースが抑止をサポートしています。

抑止ルールでクエリ言語を使用する場合に制限はありますか？

現時点では、次の検出スキーマフィールドはサポートされていません。

  • enrichment_details
  • third_party_details — 代わりに thirdparty イベントスキーマを使用してください
  • status
  • case

また、次のものは検出の生成 後 に追加または更新されるため、抑止ルールでは利用できません（抑止はより早い段階で実行されます）。

  • デコード済み / 派生フィールド（例: commandline_decoded）— 代わりに生の（エンコードされた）値に一致させてください。デコードされた値は完成した検出と詳細検索には引き続き表示されるため、利用可能に見えます。
  • events_metadata フィールド（例: events_metadata.total_events）— 公開後に生成され、継続的に更新されるため、値は静的ではありません。
特定の commandline を含む検出に対する抑止ルールはどのように作成できますか？

commandline で抑止するには、高度な抑止ルールのクエリ言語で process.commandline スキーマを使用します。

FROM detection WHERE process.commandline CONTAINS 'your_string'

フィールドが検出 JSON に表示されていません。その場合でも抑止ルールで使用できますか？

多くの場合、はい。検出は基になるイベントから構築され、検出 JSON にはその概要のみが表示されます。検出 JSON に一覧表示されていないフィールドも、それらの基になるイベントの一部であるため、詳細検索と抑止ルールの両方で 一致条件として使用できます。たとえば、auth.application_name は検出 JSON に表示されない場合がありますが、基になるイベントに存在するため、抑止ルール（および詳細検索）で使用できます。

詳細検索では同じ条件で検出が見つかるのに、抑止ルールが一致しません

これは、ルールの条件が別々の時点で真になり、後で 1 つの検出にまとめられた場合に発生することがあります。検出の抑止の仕組み を参照してください。

例:

FROM detection WHERE source_entities.user.user_name = 'jsmith' AND source_entities.host.hostname = 'somehost'

これは、検出のデータ内のどこかに jsmith と somehost の両方が含まれていれば、たとえ同時に真であったことがなくても、詳細検索では一致します。抑止されるのは、両方が同時に真であった場合のみです。検出の詳細からこれを確認する方法はないため、一致するはずのルールが一致しない場合は、一度に 1 つの条件でテストしてみてください。

ユーザー名、ドメイン、ホスト、または IP アドレスに一致させる最適な方法は何ですか？

論理型（たとえば @user、@domain、@host、@ip）ではなく、特定の 構造化エンティティ のプロパティまたはイベントフィールドに一致させることを推奨します。例:

  • FROM detection WHERE source_entities.user.user_name CONTAINS 'jsmith'
  • FROM detection WHERE source_entities.host.hostname = 'somehostname'
  • FROM detection WHERE auth.target_host_name = 'somehostname'
  • FROM detection WHERE process.username CONTAINS 'jsmith'

使用する特定のフィールドを見つけるには、スキーマライブラリー を使用してください。その Fields タブにはスキーマごとの検索可能なすべてのフィールドが一覧表示され、Logical Types タブには特定の論理型がどのスキーマとフィールドに展開されるかが表示されるため、論理型が一致させるフィールドを正確に選択できます。

注意

ドメインは複数の構造化エンティティに現れることがあり、どれを使用するかは、抑止したい検出に存在するエンティティによって異なります。

  • user.domain_name — 特定のユーザーエンティティに関連付けられたドメイン。たとえば "SYS\j.doe@scwx.com" の "scwx.com" です。（user.auth_domain は非推奨です。代わりに user.domain_name を使用してください。）
  • auth_domain.auth_domain — 特定のユーザーに関連付けられていない、スタンドアロンの認証ドメインエンティティです。

抑止したい検出上のエンティティを確認し（FAQ の「どのエンティティに対して一致させることができ、どのように使用しますか？」を参照）、どの構造化エンティティ、したがってどのフィールドが該当するかを判断してください。

条件の間に AND 演算子を含める必要がありますか？

はい。必ず明示的な AND を使用してください。別々の行にある条件が現在は AND で結合されているかのように動作する場合がありますが、これは保証されていません。必ず明示的な AND 演算子で条件を結合してください。

regex ベースの条件形式を使用する古い抑止ルールも引き続き編集できますか？

はい。古い regex ベースの条件形式で作成されたルール、たとえば 検出の方法 で作成されたルールも、引き続き完全に編集可能です。

今後は、クエリ言語の方法 でルールを作成することを推奨します。regex ベースの条件形式は今後のリリースで廃止する予定であるため、新しいルールはクエリ言語で作成するのが最適です。

抑止に IP CIDR 範囲を使用するにはどうすればよいですか？

ルールのクエリで IPv4 CIDR 範囲を使用できるようになりました。

注意

検出の検索では CIDR 範囲をサポートしていないため、これらのクエリは詳細検索を使用して作成できません。CIDR 範囲を含めずに詳細検索でクエリを作成し、抑止ルールを作成する準備ができたら範囲を追加することを推奨します。

注意

現時点では、抑止ルールで IPv6 CIDR 範囲はサポートされていません。

IPv6 アドレスを含む検出を抑止するにはどうすればよいですか？

抑止ルールは IPv6 アドレスをサポートしています。抑止ルールで IPv6 アドレスを使用すると、ルールはアドレスを自動的に正規化し、同等の表現に一致するようにします。たとえば、圧縮形式を使用するルールは非圧縮形式にも一致し、その逆も同様です。

抑止ルールで IPv6 アドレスに一致させる方法は 3 つあります。

  1. 論理型（例: @ip）:

    FROM detection WHERE @ip = '2001:db8:85a3::8a2e:370:7334'

  2. スキーマフィールド（例: auth.source_address）:

    FROM detection WHERE auth.source_address = '2001:db8:abcd:1234:0:1::'

  3. エンティティ（例: sourceIpAddress）:

    FROM detection WHERE entities = 'sourceIpAddress:2001:db8:abcd:1234:0:1::'

3 つのいずれの場合でも、アドレスが圧縮形式（例: 2001:db8:abcd:1234:0:1::）、部分展開形式（例: 2001:db8:abcd:1234:0:1:0:0）、または完全展開形式（例: 2001:db8:abcd:1234:0000:0001:0000:0000）のどれで保存されていても、ルールはイベントに一致します。

注意

  • 現時点では、抑止ルールは IPv4 マップド IPv6 アドレス（::ffff:192.0.2.47 など）をサポートしていません。
  • 現時点では、抑止ルールは IPv6 CIDR 範囲をサポートしていません。IPv6 アドレスの範囲を抑止するには、個別のルールを作成するか、検出の方法 で正規表現パターンを使用してください。