このトピックでは、さまざまなタイプの転送データの重複を認識する方法について説明します。
アラートの重複
最も単純なケースでは、同じ alert_id を含む 2 つのレコードが表示されるときに、アラートが重複していることがわかります。ただし、Carbon Black Cloud アラート サービスは、Carbon Black Cloud がアラートのイベントに関連する新しく疑わしいエンドポイント アクティビティを短期間監視するときはいつでも、特定のアラート（たとえば、Carbon Black 分析アラート）を意図的に更新します。これにより、更新されたアラートを再転送して、更新された状態を必要とするユーザーが更新されたアラート属性を使用できるようにする必要があります。最も極端な状況では、アラート サービスは特定のアラートを最大 60 回更新します。この更新動作は、ウォッチリスト アラートやデバイス制御アラートなどの他の種類のアラートには当てはまりません。
アラート サービスがアラートの更新されたコピーを意図的に発行する場合、同じ alert_id の last_update_time フィールドは常に増加し、そのアラート レコード内の他の 1 つ以上のフィールドも更新されます。
データ フォワーダがアラートの複製を作成すると、すべてのデータ フィールドが同じになります。これには、「alert_id」フィールドと「last_update_time」フィールドの両方が含まれます。
イベントの重複：NGAV オリジン
Carbon Black Cloud データ フォワーダによって発行されたすべての NGAV イベントには、一意の識別子 event_id が含まれています。
イベントの重複：EDR オリジン
Carbon Black Cloud データ フォワーダによって発行された EDR イベントには、一意の識別子が含まれています。
イベントの重複：NGAV + EDR サイドバイサイド
センサーの NGAV 機能と EDR 機能は、設計上、レポート可能と見なされるイベントを個別に計測します。これは一般に、（たとえば、Carbon Black Cloud Enterprise EDR 専用の modloads と fileless scriptloads を除く、両方の機能によって計測されたイベントの場合）同じアクティビティに対して個別に報告されるイベントが発生する可能性があることを意味します。
さらに、EDR event_id の欠如のため、NGAV イベントを同等の EDR に関連付けることができる明確な単一フィールドはありません。 type=endpoint.event.procstart の場合、childproc_guid と type の組み合わせで十分ですが、他のイベント タイプの場合でも、process_guid と type は複数のイベントを意味します。このような場合、device_timestamp による関連付けが役立つ場合がありますが、センサーの 2 つのスレッドがミリ秒単位の精度でまったく同じタイムスタンプを生成することはめったにありません。
たとえば、センサーはプロセスに対して 4 つの filemod（1 つは NGAV filemod、3 つは EDR filemod）を報告します。NGAV イベントと 3 つの EDR イベントのうちの 1 つは ACTION_FILE_CREATE 用です。EDR は ACTION_FILE_CREATE | ACTION_FILE_MOD_OPEN | ACTION_FILE_OPEN_WRITE を報告します。FILE_CREATE の場合、filemod_name は「同じ」イベント間で明確に一致しますが、多くの regmod イベントには同じことが当てはまりません。
