Device Stopped Sending Events
この記事の目的は、DSSE テストのより作業可能かつ使用可能な代替手段を説明することにあります。
- ペアになっているデバイス・グループ (アクティブ/バックアップ) 内の 1 つのデバイスが応答しなくなったときに、元の DSSE テストが不必要に実行される問題を解決します。
- 元の DSSE テストで使用不可になるアクションおよび応答の標準的な「CRE-isms」を有効にします。
概要
ジニブでは、カスタム・ルール・エンジン (CRE) は、イベントを処理し、定義されたルールと比較することにより、イベントの存在を処理します。 「デバイス停止送信イベント (DSSE) 」テストと呼ばれる CRE のバックグラウンドで実行される別のテストがあります。 CREとは異なり、DSSE はイベントがない状態で実行され、標準的な「CRE-ism」 (読み取り: アクション、応答、他のテスト、同じルール内のフィルター) の多くが使用不可になり、適切に呼び出されない場合に競合が発生します。 さらに、デバイス・グループまたはデバイス・リスト内の特定のタイプのデバイスが送信を停止すると、DSSE ルール (次の図に示されている) が問題を検出します。
図 1. DSSE ルール (デバイスがイベントの送信を停止した)
ソリューション
このソリューションは、トラッカー・ルールとウォッチャー・ルールと呼ばれる 2 つの汎用ルールを使用して、オリジナルの 3 つのテスト (前の画面キャプチャーで選択されたテスト) を置き換えます。 これらのルールは、2 つの別個の参照データ・コンテナーに対してテストを行います。 トラッカー・ルールは、リファレンス・セットに入力されたイベント・データに従って動作します。 その後、リファレンス・セット・エントリーの有効期限が切れると、イベントがそれに割り当てられなくなり、ウォッチャー・ルールがトリガーされます。
リファレンス・セットは、1 つのユニーク・キーを複数の値にマップするデータの集合であるという点に注意してください。 プロパティー値をリストと比較し、そのキーを特定する目的で設定します。 リファレンス・マップは、1 つの固有キーを 1 つの値にマップするデータの集合です。これらは、2 つのプロパティー値の固有の組み合わせを検証するために使用されます。 例えば、ネットワーク上のユーザー・アクティビティーを LoginID で相関させることができます。
Rule #1 - ラッカー・ルール
トラッカー・ルールは、システムを通過するときにイベントを追跡します。 SystemsToWatch リファレンス・マップにログ・ソース ID が存在する場合は、その値が ActiveSystemsSending リファレンス・セットに配置されます。
図 2. QRadar (Q) コンソールのトラッカー・ルール
次に、応答リミッターが値に付加されます。 この応答リミッターは、リファレンス・セットの TTL よりはるかに小さく、ログ・ソースで索引付けされています。
図3: トラッカー・ルールのルール応答選択。
Rule #2 - ウォッチャー・ルール
ウォッチャー・ルールはシステムを監視します。 開始後にログ・ソースから少なくとも 1 つのイベントがシステムを認識している限り、「リファレンス・セット」に値が設定されます。
図 4. QRadar (Q) コンソールでの Watcher ルール
リファレンス・セット・エントリーの有効期限が切れるとすぐに、リファレンス・マップ内の固有の名前に関連付けられたすべてのログ・ソースがイベントの送信を停止することを意味します。 この場合、オフェンスが生成され、その固有の名前に基づいて索引付けされます。
図 5. ウォッチャー・ルールのルール応答選択。
この手順で説明されているログ・ソース名は ExpiredReferenceElement で、以下のように構成されています。
図 6. QRadar (Q) コンソールでのプロパティー定義。