YARA-L은 Google에서 개발한 감지 규칙 언어입니다. YARA-L의 목적은 단순한 데이터 쿼리와 같은 규칙에서 실제 이벤트 중심의 조사로 이동하기 위한 것입니다. YARA-L은 멀웨어 분석에서 일반적으로 사용되는 YARA 언어에서 파생됩니다. L은 로그를 의미합니다. YARA-L을 사용하면 감지 내에 있는 여러 소스의 모든 정보를 활용하고 이러한 이벤트를 연결하여 실행 가능한 알림을 제공할 수 있습니다. 자세한 내용은 YARA-L 2.0 언어 개요를 참조하세요.
Google Security Operations 샘플 감지 규칙
Google SecOps 감지 엔진 채택을 가속화하기 위해 샘플 규칙이 포함된 GitHub 저장소가 존재합니다. 이 저장소에는 다음을 포함한 여러 카테고리의 감지 규칙이 있습니다.
Google Cloud CloudAudit
Google Workspace
정보 경고
멀웨어
MITRE ATT&CK
SOC 프라임 규칙
의심스러운 이벤트
각 카테고리는 특정한 접근 방법을 사용하여 데이터 소스를 열람하고, 어떤 이벤트 및 일치하는 문을 사용할지 지정합니다.
규칙 예시 및 조정
다음 규칙은 이벤트 유형을 추적하는 데 사용되는 이벤트 변수 $e1을 만듭니다. 이 이벤트 변수는 평가 중인 데이터와 관련된 모든 값으로 지정될 수 있습니다. 이 이벤트에서 평가되는 UDM 필드는 metadata.eventype이므로 e1이라고 불러도 무방할 것입니다. 다음 줄은 e1 내에서 정규 표현식과 일치하는 특정 항목을 검색합니다. Google SecOps에서 감지를 만드는 조건은 $e1 이벤트가 발생하는 모든 시간입니다. 조정 목적으로 명령줄 인수에 대해 악의적이지 않은 특정 경로를 제외하도록 not 조건이 제공됩니다. 다른 알려진 파일 경로에서 시작되는 거짓양성이 자주 식별되는 경우 이 규칙에 not 조건을 더 추가할 수 있습니다.
YARA-L을 사용하면 하나의 규칙에 이벤트 변수를 여러 개 포함할 수 있습니다. 다음 예시에서 규칙에는 $e1 및 $e2 이벤트가 포함됩니다. 이 조건은 감지를 트리거하는 논리적 조건을 나타냅니다.
rule ExcludeZeroValues {
meta:
author = "noone@google.com"
events:
$e1.metadata.event_type = "NETWORK_DNS"
$e1.principal.hostname = $hostname
// $e1.principal.user.userid may be empty string.
$e1.principal.user.userid != "Guest"
$e2.metadata.event_type = "NETWORK_HTTP"
$e2.principal.hostname = $hostname
// $e2.target.asset_id cannot be empty string as explicitly specified.
$e2.target.asset_id != ""
match:
// $hostname cannot be empty string.
$hostname over 1h
condition:
$e1 and $e2
}
규칙 결과 섹션
결과 섹션을 사용하여 규칙 감지 내의 저장 변수를 설정하고 다운스트림 소비를 위한 보강 기능을 제공할 수 있습니다. 예를 들어 분석 대상 이벤트의 데이터를 사용하는 심각도 점수 정보를 추가할 수 있습니다. 다음 감지는 2개의 이벤트를 검사하여 $hostname 값을 결정합니다. 5분 이상 동안 $hostnames 값이 일치하면 심각도 점수가 적용됩니다. 기간을 사용할 때 Google SecOps 감지 엔진은 사용자가 지정한 개별 시간 블록만 검사합니다.
YARA-L은 단순한 데이터 쿼리 반환 외에도 보안 이벤트를 검사할 수 있게 해주는 유연한 감지 언어입니다. 이벤트 변수는 규칙의 조건 섹션에 사용되는 필드 값을 추적하기 위해 사용됩니다. 단일 이벤트, 시간 경과에 따른 여러 이벤트, 단일 값의 소스(예: 여러 데이터 소스의 $hostname) 상관관계를 파악하고, 정규 표현식과 같은 도구를 사용하여 일치 항목을 제공할 수도 있습니다. 고유 환경에 맞게 규칙을 조정하는 것이 중요하며 논리 내에서 제외 항목을 지정하여 이를 수행할 수 있습니다. 또한 참조 목록을 사용해서 항목을 하나로 그룹화한 후 규칙에서 해당 목록을 참조할 수 있습니다. Google SecOps에서 모든 감지에 대해 알림을 표시할 필요는 없습니다. 여러 목적에 따라 감지를 추적하고 해당 환경에서 가장 중요한 항목에 대해서만 알림을 표시할 수 있습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-10(UTC)"],[[["\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)"]]
