ライブデータに対するルールの実行
ルールを作成すると、最初は Google Security Operations アカウントで受信したイベントに基づいて検出がリアルタイムで検索されることはありません。ただし、[ライブルール] を [有効] に設定して、検出をリアルタイムで検索するルールを設定します。
ルールをライブにするには、次の手順を行います。
ルール ダッシュボードに移動します。
ルールの [Rules] オプション アイコンをクリックし、[Live Rule] を有効にします。
ライブルール
ライブルールによって生成された検出結果を表示するには、[View Rule Detections] を選択します。
ルールの割り当て
容量ボタンをクリックすると、ライブにできるルール数の上限が表示されます。ルール ダッシュボードの右上にあります。
Google Security Operations には、次のルールの上限があります。
- マルチイベントルールの割り当て - ライブとして有効な複数のイベントルールの現在の数と、ライブとして有効にできるルールの最大数が表示されます。単一イベントルールとマルチイベントルールの違いについて詳しくは、こちらをご覧ください。
- ルールの合計割り当て - すべてのルールの種類でライブとして有効なルールの現在の合計数と、ライブとして有効にできるルールの最大数が表示されます。
各種のルールについて詳しくは、こちらをご覧ください。
ルールの実行
頻度の低下に伴い、特定のイベント時間バケット用のライブルール実行がトリガーされます。最終的なクリーンアップが行われ、その後、実行はもう開始されません。
各実行は、ルールで使用される最新バージョンの参照リストを確認し、最新のイベントとエンティティのデータ拡充に対して行われます。
つまり、一部の検出結果は、後の実行でのみ検出される場合、遡及的に生成されます。たとえば、最後の実行では、より多くのイベントを検出する最新バージョンの参照リストが使用される場合があり、新しい拡充によってイベントとエンティティ データが再処理されます。
検出のレイテンシ
ライブルールから検出が生成されるまでの時間は、さまざまな要因によって決まります。検出の遅延の原因となるさまざまな要因は次のとおりです。
- ルールの種類
- 実行頻度
- 取り込みの遅延
- コンテキスト結合
- 拡充された UDM データ
- タイムゾーンに関する問題
- リファレンス リスト
ルールの種類
- 単一イベントルールは、準リアルタイムのストリーミング方式で実行されます。可能な場合は、これらのルールを使用してレイテンシを最小限に抑えます。
- マルチイベントのルールはスケジュールに沿って実行されるため、スケジュールされた実行の間隔によってレイテンシが高くなります。
実行頻度
検出を高速化するには、実行頻度と一致ウィンドウを短くします。一致ウィンドウを短く（1 時間未満）すると、実行頻度を上げることができます。
取り込みの遅延
イベントが発生したらすぐに Google Security Operations にデータが送信されるようにします。検出を確認するときは、UDM イベントと取り込みのタイムスタンプに注意してください。
コンテキスト結合
UEBA や Entity Graph などのコンテキスト データを使用するマルチイベント ルールでは、遅延が大きくなる可能性があります。コンテキスト データはまず Google SecOps で生成する必要があります。
拡充された UDM データ
Google SecOps は、他のイベントのデータを使ってイベントを拡充します。ルールが拡充されたフィールドを評価しているかどうかを確認するには、イベント ビューアを確認します。ルールが拡充されたフィールドを評価している場合は、検出が遅延する可能性があります。
タイムゾーンに関する問題
リアルタイム データに対するルールは、より頻繁に実行されます。データはリアルタイムで届く可能性がありますが、タイムゾーンに関する問題が原因でイベント時間が正しくない場合、Google SecOps ではそのデータが受信遅延データとして扱われる可能性があります。Google SecOps SIEM のデフォルトのタイムゾーンは UTC です。元のデータのイベント タイムスタンプが UTC 以外のタイムゾーンに設定されている場合は、データのタイムゾーンを更新します。ログソースでタイムゾーンを更新できない場合は、サポートに連絡して、タイムゾーンのオーバーライドを依頼してください。
不在ルール
存在しないことを確認するルール（!$e または #e=0 を含むルールなど）は、データの受信時間を確保するために、少なくとも 1 時間遅れて実行されます。
リファレンス リスト
ルールの実行では、常に最新バージョンのリファレンス リストが使用されます。リファレンス リストが最近更新された場合、スケジュールされたルールを後で実行する際に、更新されたリストの新しい内容に検出が含まれる可能性があるため、新しい検出が遅れて表示されることがあります。
検出のレイテンシの短縮を実現するには、次のようにすることをおすすめします。
- イベントが発生したらすぐに Google Security Operations にログデータを送信します。
- 存在しないデータまたはコンテキストが拡充されたデータを使用する必要があるかどうかを確認する監査ルール。
- 実行頻度を低くする。
ルールのステータス
ライブルールのステータスは次のいずれかになります。
[有効]: ルールは有効で、ライブルールとして正常に動作しています。
[無効]: ルールは無効です。
[制限付き]: リソースルールの使用が異常に多い場合に、ライブルールをこのステータスに設定できます。[制限付き] のルールは、システム内の他のライブルールから分離されており、Google Security Operations の安定性を維持します。
[制限付き] のライブルールの場合、ルールが正常に実行されるかどうかは保証されません。ただし、ルールの実行が成功した場合、検出は保持され、ユーザーが確認できます。[制限付き] のライブルールは常にエラー メッセージを生成します。エラーメッセージには、ルールのパフォーマンスを改善する方法に関する情報が含まれています。
[制限付き] のルールのパフォーマンスが 3 日以内に改善されない場合、ステータスは [一時停止] に変更されます。
[一時停止]: ライブルールは、3 日間 [制限付き] ステータスでパフォーマンスの改善が見られない場合、このステータスになります。このルールの実行が一時停止し、ルールのパフォーマンスを改善する方法に関する情報が記載されたエラー メッセージが返されます。
ライブルールを [有効] ステータスに戻すには、YARA-L のベスト プラクティスに沿ってルールのパフォーマンスを向上させ、保存します。ルールが保存されると、[有効] ステータスにリセットされ、ルールが再度 [制限付き] になるまでに少なくとも 1 時間かかります。
ルールの実行頻度を少なくするように構成することで、ルールのパフォーマンスの問題を解決できる可能性があります。たとえば、ルールを 10 分ごとの実行から、1 時間に 1 回、または 24 時間に 1 回実行するように再構成できます。ただし、ルールの実行頻度を変更しても、ステータスが [有効] に戻ることはありません。ルールに少し変更を加えて保存すると、ステータスは自動的に [有効] にリセットされます。
ルールのステータスは [ルール ダッシュボード] に表示され、Detection Engine API を介してアクセスすることもできます。[制限付き] または [一時停止] ステータスのルールによって生成されたエラーは、ListErrors API メソッドを使用して確認できます。エラーには、ルールのステータスが [制限付き] または [一時停止] であることが示され、問題の解決方法を示すドキュメントが表示されます。