[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-09-02。"],[[["\u003cp\u003eLive rules in Google Security Operations prioritize real-time data for immediate threat detection, and can be enabled by toggling the "Live Rule" option in the Rules Dashboard.\u003c/p\u003e\n"],["\u003cp\u003eGoogle SecOps enforces limits on live rules, with quotas for both multiple event rules and total live rules, indicated in the "Rules Capacity" section.\u003c/p\u003e\n"],["\u003cp\u003eDetection delays in live rules can be influenced by several factors, including rule type, run frequency, data ingestion delay, contextual joins, data enrichment, timezone discrepancies, and the use of reference lists.\u003c/p\u003e\n"],["\u003cp\u003eLive rules can have statuses such as Enabled, Disabled, Limited, or Paused, with Limited and Paused statuses indicating performance issues and potential service interruptions, requiring optimization or modifications.\u003c/p\u003e\n"],["\u003cp\u003eThe engine automatically removes duplicate detections from rules that rely on time-based windows and match variables.\u003c/p\u003e\n"]]],[],null,["# Learn how to apply a rule to live data\n======================================\n\nSupported in: \nGoogle secops [SIEM](/chronicle/docs/secops/google-secops-siem-toc)\n\nWhen you create a rule, it does not initially search for detections based on\nevents received in your Google Security Operations account in real time. However, you set the\nrule to search for detections in real time by setting the **Live Rule** toggle\nto enabled.\n\nWhen a rule is configured to search for detections in real time, it prioritizes\nlive data for immediate threat detection.\n\nTo set a rule to live, complete the following steps:\n\n1. Click **Detection** \\\u003e **Rules \\& Detections**.\n\n2. Click the **Rules Dashboard** tab.\n\n3. Click the more_vert **Rules** option icon for a rule and toggle the **Live Rule** to enabled.\n\n **Live Rule**\n4. Select **View Rule Detections** to view detections from a live rule.\n\nDisplay Rules quota\n-------------------\n\nAt the top right of the Rules dashboard, click **Rules capacity** to display the limits to the number of rules that can be enabled as live.\n\nGoogle SecOps imposes the following rule limits:\n\n- **Multiple Events Rules Quota** : Displays the current count of live-enabled Multiple Event rules and the maximum allowed. Learn more about the difference between [Single Event](/chronicle/docs/detection/yara-l-2-0-overview#single-event-rule) and [Multiple Event](/chronicle/docs/detection/yara-l-2-0-overview#multiple_event_rule) rules.\n- **Total Rules Quota** : Displays the current total count of rules enabled as live across all [rule types](#rule-types) and the maximum number of rules that can be enabled as live.\n\n| **Note:** Google SecOps indicates if you're over your rule quota in the **Rules Capacity** dialog. You won't be able to enable additional live rules until you reduce the number of enabled live rules.\n\nRules executions\n----------------\n\nLive rules executions for a given event time bucket are triggered with decreasing frequency. A final cleanup run occurs, after which no further executions start.\n\nEach execution runs over the latest versions of [reference lists](/chronicle/docs/reference/reference-lists) used in the rules, and against the latest [event and entity data enrichment](/chronicle/docs/event-processing/data-enrichment).\n\nSome detections can be retrospectively generated if they're detected only by later executions. For example, the last execution might use the latest version of the reference list, which now detects more events, and events and entity data can be reprocessed due to new enrichments.\n| **Note:** Rules trigger detections based on UDM events available when the rule runs. The system creates new detections when additional events arrive, but does not update existing detections.\n\n### Deduplication\n\nGoogle SecOps automatically identifies and removes duplicate detections from rules. This process applies only to rules with match variables, as they rely on time-based windows. Detections with identical match variable values, within overlapping time windows, are suppressed as duplicates.\n\nGoogle SecOps treats each rule version as distinct, new logic. As a result, when a rule is updated, it can trigger repeated detections based on past events. These detections are not removed, even if they appear to be duplicates.\n\nDetection latencies\n-------------------\n\nVarious factors determine how long it takes for a detection to be generated from a live rule. The following list includes the different factors that contribute to detection delays:\n\n- [Rule types](#rule-types)\n- [Run frequency](#run-frequency)\n- [Ingestion delay](#ingestion-delay)\n- [Contextual joins](#contextual-joins)\n- [Enriched UDM data](#enriched-udm-data)\n- [Timezone issues](#timezone-issues)\n- [Reference lists](#reference-lists)\n\n### Rule types\n\n- [Single-event rules](/chronicle/docs/detection/yara-l-2-0-overview#single-event-rule) are executed near-real time in a streaming approach. Use these rules, when possible, to minimize latency.\n- [Multi-event rules](/chronicle/docs/detection/yara-l-2-0-overview#multi-event-rule) execute on a scheduled basis, which results in higher latency due to the time between scheduled runs.\n\n### Run frequency\n\nTo achieve faster detections, use a shorter run frequency and smaller match window. Using shorter match windows (under one hour) enables more frequent runs.\n\n### Ingestion delay\n\nVerify that data is sent to Google Security Operations as soon as the event occurs. When reviewing a detection, carefully check the UDM event and ingestion timestamps.\n\n### Contextual joins\n\nMulti-event rules that use contextual data, such as UEBA or Entity Graph, might experience higher delays. The contextual data must first be generated by Google SecOps.\n\n### Enriched UDM data\n\nGoogle SecOps enriches events with data from other events. To identify if a rule is evaluating an enriched field, review the [Event Viewer](/chronicle/docs/investigation/udm-search#event-viewer). If the rule is evaluating an enriched field, the detection might be delayed.\n\n### Timezone issues\n\nRules execute more frequently for real-time data. Data might arrive in real-time, but Google SecOps might still treat it as late-arriving if the event time is incorrect due to timezone discrepancies.\n\nThe Google SecOps SIEM default timezone is UTC. If the original data has an event timestamp set to another timezone besides UTC, update the data timezone. If updating the timezone at the log source is not possible, then contact [Support](/chronicle/docs/getting-support), to override the timezone.\n\n### Non-existence rules\n\nRules that check for [non-existence](/chronicle/docs/detection/yara-l-2-0-syntax#bounded_and_unbounded_conditions) (for example, rules that contain `!$e` or `#e=0`) are executed with a minimum delay of one hour to verify that data has time to arrive.\n\n### Reference lists\n\nRule executions always use the most up-to-date version of a reference list. If the reference list was recently updated, a new detection might appear late. This happens because the detection might only be included in new contents of the updated list during later executions of the scheduled rule.\n\nTo achieve lower detection latencies, we recommend doing the following:\n\n- Send log data to Google SecOps as soon as the event occurs.\n- Review the audit rules to determine if it is necessary to use non-existence or context-enriched data.\n- Configure a smaller [run frequency](/chronicle/docs/detection/run-frequency).\n\nRule status\n-----------\n\nLive rules can have one of the following statuses:\n\n- **Enabled:** Rule is active and working normally as a live rule.\n\n- **Disabled:** Rule is disabled.\n\n- **Limited:** Live rules can be set to this status when they show\n unusually high resource usage. **Limited** rules are isolated from the other live\n rules in the system to maintain the stability of Google SecOps.\n\n For **Limited** live rules, successful rule executions aren't always possible.\n However, if the rule execution succeeds, detections are retained and available\n for you to review. **Limited** live rules always generate an error message,\n which includes recommendations about how to improve the performance of the rule.\n\n If the performance of a **Limited** rule doesn't improve within 3 days, its\n status is changed to **Paused**.\n\n **Note**: If there've been no recent changes to this rule, the errors might be intermittent\n and could resolve automatically.\n- **Paused:** Live rules enter this status when they've been in **Limited**\n status for 3 days and haven't shown any performance improvement. Executions for\n this rule have been paused and error messages with suggestions on how to\n improve the rule's performance are returned.\n\nTo return any live rule to the **Enabled** status, follow\n[YARA-L best practices](/chronicle/docs/detection/yara-l-best-practices) to\noptimize its performance of your rule and save the changes. After the rule has been saved,\nthe rule is reset to the **Enabled** state, and it will take at least an hour\nbefore it reaches the **Limited** status again.\n\nYou can potentially resolve performance issues with a rule by configuring it\nto run less frequently. For example, you could reconfigure a rule from running\nevery 10 minutes to running once an hour or once every 24 hours. However,\nchanging the execution frequency of a rule won't change its status back to\n**Enabled** . If you make a small modification to the rule and save it, you can\nautomatically reset its status to **Enabled**.\n\nRule statuses are displayed in the **Rules Dashboard** and are also accessible\nthrough the Detection Engine API. Errors generated by rules in the **Limited**\nor **Paused** status are available using the\n[`ListErrors`](/chronicle/docs/reference/detection-engine-api#listerrors) API method.\nThe error indicates that the rule is either in the **Limited** or **Paused** status,\nand provides a link to documentation on how to resolve the issue.\n\n**Need more help?** [Get answers from Community members and Google SecOps professionals.](https://security.googlecloudcommunity.com/google-security-operations-2)"]]