[[["易于理解","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-03。"],[[["\u003cp\u003eYARA-L is a Google-developed detection rules language designed for event-driven security investigations, derived from the YARA language used in malware analysis.\u003c/p\u003e\n"],["\u003cp\u003eA GitHub repository with sample detection rules for Google Security Operations offers various categories, including Google Cloud CloudAudit, Google Workspace, Malware, and MITRE ATT&CK, each tailored to specific data sources and events.\u003c/p\u003e\n"],["\u003cp\u003eYARA-L rules utilize event variables to track specific field values and can use single or multiple events, correlate data from various sources, and employ regular expressions for matching.\u003c/p\u003e\n"],["\u003cp\u003eThe "outcome" section in YARA-L rules allows setting variables to enrich detections, such as applying severity scoring based on analyzed events and data, to provide downstream insights.\u003c/p\u003e\n"],["\u003cp\u003eTuning YARA-L rules by specifying exclusions and using reference lists is crucial for adapting them to specific environments, helping to manage detection events, and prioritize critical alerts.\u003c/p\u003e\n"]]],[],null,["# Default detection rules\n=======================\n\nSupported in: \nGoogle secops [SIEM](/chronicle/docs/secops/google-secops-siem-toc)\n\nYARA-L rules language\n---------------------\n\nYARA-L is a detection rules language developed by Google. The purpose of YARA-L\nis to move away from detections as just data queries to actual event-driven\ninvestigations. YARA-L is derived from the YARA language commonly used in\nmalware analysis. The *L* stands for logs. YARA-L enables you to take advantage\nof all the information from multiple sources within detections, and correlate\nthose events into actionable alerts. For more information, see the [Overview of\nthe YARA-L 2.0 language](../detection/yara-l-2-0-overview).\n\nGoogle Security Operations sample detection rules\n-------------------------------------------------\n\nTo help accelerate your adoption of the Google SecOps Detection Engine,\nthere is a [GitHub repository with sample\nrules](https://github.com/chronicle/detection-rules). This repository contains\nseveral different categories of detection rules, including the following:\n\n- Google Cloud CloudAudit\n- Google Workspace\n- Informational warnings\n- Malware\n- MITRE ATT\\&CK\n- SOC prime rules\n- Suspicious events\n\nEach category takes a specific approach in how it views data sources and\nspecifies what events and matching statements to use.\n\nExample rules and tuning\n------------------------\n\nThe following rule creates an event variable `$e1` which is used to track the\nevent type. The event variable can be any value which has meaning to the data\nbeing evaluated. The UDM field being evaluated in this event is\n`metadata.eventype` so it makes sense to just call it `e1`. The next lines\nsearches for specific occurrences of regular expression matches within `e1`. The condition that\ncreates a detection in Google SecOps is any time the event `$e1` takes\nplace. For tuning purposes, a `not` condition is provided to exclude certain\nnon-malicious paths for the command line argument. Further `not` conditions\ncould be added to this rule if you identify frequent false positives coming from\nother known file paths. \n\n rule suspicious_unusual_location_svchost_execution\n\n {\n meta:\n author = \"Google Cloud Security\"\n description = \"Windows 'svchost' executed from an unusual location\"\n yara_version = \"YL2.0\"\n rule_version = \"1.0\"\n\n events:\n $e1.metadata.event_type = \"PROCESS_LAUNCH\"\n re.regex($e1.principal.process.command_line, `\\bsvchost(\\.exe)?\\b`) nocase\n not re.regex($e1.principal.process.command_line, `\\\\Windows\\\\System32\\\\`) nocase\n\n condition:\n $e1\n }\n\nSpecify more than one event variable\n------------------------------------\n\nYARA-L enables you to have more than one event variable in a rule. In the\nfollowing example, the rule has events `$e1` and `$e2`. The condition states the\nlogical condition that triggers the detection. \n\n rule ExcludeZeroValues {\n meta:\n author = \"noone@google.com\"\n\n events:\n $e1.metadata.event_type = \"NETWORK_DNS\"\n $e1.principal.hostname = $hostname\n\n // $e1.principal.user.userid may be empty string.\n $e1.principal.user.userid != \"Guest\"\n\n $e2.metadata.event_type = \"NETWORK_HTTP\"\n $e2.principal.hostname = $hostname\n\n // $e2.target.asset_id cannot be empty string as explicitly specified.\n $e2.target.asset_id != \"\"\n\n match:\n // $hostname cannot be empty string.\n $hostname over 1h\n\n condition:\n $e1 and $e2\n }\n\nRules outcome section\n---------------------\n\nUse the outcome section to set holding variables within the rule detection to\nprovide enrichment for downstream consumption. For example, you can add severity\nscoring information that relies on data from the events being analyzed. The\nfollowing detection examines two events to attribute the `$hostname` value. If\nthe value `$hostnames` match over a 5 minute period, a severity score is\napplied. When using time periods, the Google SecOps Detection Engine only\nexamines the discrete blocks of time you specify. \n\n rule OutcomeRuleMultiEvent {\n meta:\n author = \"noone@google.com\"\n events:\n $u.udm.principal.hostname = $hostname\n $asset_context.graph.entity.hostname = $hostname\n\n $severity = $asset_context.graph.entity.asset.vulnerabilities.severity\n\n match:\n $hostname over 5m\n\n outcome:\n $risk_score =\n max(\n 100\n + if($hostname = \"my-hostname\", 100, 50)\n + if($severity = \"HIGH\", 10)\n + if($severity = \"MEDIUM\", 5)\n + if($severity = \"LOW\", 1)\n )\n\n $asset_id_list =\n array(\n if($u.principal.asset_id = \"\",\n \"Empty asset id\",\n $u.principal.asset_id\n )\n )\n\n $asset_id_distinct_list = array_distinct($u.principal.asset_id)\n\n $asset_id_count = count($u.principal.asset_id)\n\n $asset_id_distinct_count = count_distinct($u.principal.asset_id)\n\n condition:\n $u and $asset_context and $risk_score \u003e 50 and not arrays.contains($asset_id_list, \"id_1234\")\n }\n\nConclusion\n----------\n\nYARA-L is a flexible detection language which enables you to examine security\nevents and not simply just return a data query. The event variable is used to\ntrack what field values are being used in the condition section of the rule. You\ncan use a single event, multiple events over time, correlate sources for a\nsingle value (such as $hostname from different data sources), and even use tools\nsuch as regular expressions to provide matches. It is essential to tune the rules to your own\nenvironment and this can be done by specifying exclusions within the logic. You\ncan also use reference lists to group items together and then reference that\nlist in the rule. Don't forget that Google SecOps does not need every\ndetection to be alerted on. You can keep track of detections for multiple\npurposes and only alert on those you determine are most critical in your\nenvironment.\n\n**Need more help?** [Get answers from Community members and Google SecOps professionals.](https://security.googlecloudcommunity.com/google-security-operations-2)"]]