rulewindows_defender_av_monitored_events{meta:author="Chronicle"description="Migration of CBN alerts to Google SecOps YARA-L detection engine rule alert."// Severity is set at the Outcome level via security_result.severityseverity="INFORMATIONAL"priority="INFORMATIONAL"events:$windows_defender_av.metadata.vendor_name="Microsoft"$windows_defender_av.metadata.product_name="Windows Defender AV"$windows_defender_av.metadata.product_event_type="MALWAREPROTECTION_STATE_MALWARE_DETECTED"$windows_defender_av.principal.asset.hostname=$host// optionally tune to only detection on ALLOW, i.e., failure to BLOCK//$windows_defender_av.security_result.action = "ALLOW"// optionally tune on severity of detection//$windows_defender_av.security_result.severity != "LOW"outcome:$risk_score=max(if($windows_defender_av.security_result.severity="UNKNOWN_SEVERITY",0)+if($windows_defender_av.security_result.severity="LOW",25)+if($windows_defender_av.security_result.severity="MEDIUM",50)+if($windows_defender_av.security_result.severity="HIGH",75)+if($windows_defender_av.security_result.severity="CRITICAL",100))$severity=array_distinct($windows_defender_av.security_result.severity)condition:$windows_defender_av}
events:// Corelight : Weird Log($corelight.metadata.vendor_name="Corelight"and$corelight.metadata.product_name="Zeek"and// this requires a custom parser extension to extract notice$corelight.metadata.product_event_type="weird"and$corelight.additional.fields["notice"]="true")
[[["易于理解","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-08-21。"],[[["\u003cp\u003eCBN (Configuration Based Normalization) alerts and the Enterprise Insights page are deprecated; users should now utilize the Alerts and IOCs page for alerts.\u003c/p\u003e\n"],["\u003cp\u003eMigrating to the YARA-L detection engine is recommended, because it offers better detection logic transparency and tuning compared to CBN alerts.\u003c/p\u003e\n"],["\u003cp\u003eExisting CBN alerts can be found and reviewed using UDM search, which helps identify sources generating alerts by vendor and product names.\u003c/p\u003e\n"],["\u003cp\u003eUsers can download default CBN alerts using the Tools API, allowing for a manual review of parser logic to find \u003ccode\u003eis_alert\u003c/code\u003e or \u003ccode\u003ealert_state\u003c/code\u003e based alerts that have not been previously seen.\u003c/p\u003e\n"],["\u003cp\u003eParser extensions can be used to map non-UDM fields from legacy alerts to YARA-L rules, ensuring a seamless transition and maintaining alert functionality.\u003c/p\u003e\n"]]],[],null,["# Migrate CBN alerts to YARA-L detection rule alerts\n==================================================\n\n| **Caution:** The **Enterprise Insights** page and CBN alerts are deprecated. Use the **Alerts and IOCs** page to view alerts. We recommend that you migrate the existing CBN alerts to the YARA-L detection engine as described in this guide. Google Security Operations's YARA-L detection engine is the preferred option for detection alerts because it offers enhanced transparency in detection logic and robust tuning capabilities. For more information see [Overview of the YARA-L 2.0 language](/chronicle/docs/detection/yara-l-2-0-overview).\n\nThis document provides details on how you can migrate Configuration Based Normalization (CBN)\nalerts to YARA-L detection alerts. As a security analyst, with the help of this\ndocument, you can continue getting notifications for alerts from third-party systems using the\n**Alerts and IOCs** page.\n\nMigrate CBN alerts to the YARA-L detection engine\n-------------------------------------------------\n\nTo migrate CBN alerts, you can ensure that your prior CBN alerts are\navailable as detection rule alerts using the following options.\n\n### Use UDM search\n\nUsing the UDM search option, you can view events with the `alert_state` set in the parsers: \n\n security_result.alert_state = \"ALERTING\"\n\nFrom the UDM search results, you can explore the following fields to understand\nwhich sources are generating CBN alerts in your environment:\n\n- `Metadata` \\\u003e `Vendor Name`\n\n- `Metadata` \\\u003e `Product Name`\n\n### Download default CBN alerts using the Tools API and manually review\n\nThe previous approach helps you to find alerts that have fired, but does not\ncover the scenario of alerts that you have not seen before.\nYou can use the `backstory.googleapis.com/v1/tools/cbn` parsers method to download\ndefault, select, or all CBNs, and manually review the parser logic applied to\nfind `is_alert` or `alert_state` based alerts.\n\nYou can port CBN alerts to YARA-L detection engine rule alerts which you actively\nuse.\n\n#### Migrate Windows Defender antivirus alerts that were previously displayed in Enterprise Insights as CBN alerts\n\nThe following example shows how you can migrate Windows Defender antivirus alerts that were previously displayed in Enterprise Insights as CBN alerts.\n\n1. Find an example alert using any one of the approaches explained previously.\n\n2. Using the Raw Log / UDM Event viewer, copy select UDM fields that will provide reliable detection. See the following example.\n\n metadata.vendor_name = \"Microsoft\"\n metadata.product_name = \"Windows Defender AV\"\n metadata.product_event_type = \"MALWAREPROTECTION_STATE_MALWARE_DETECTED\"\n principal.asset.hostname = \"client02.example.local\"\n security_result.action = \"BLOCK\"\n security_result.severity = \"MEDIUM\"\n\n3. Create a new YARA-L detection engine rule.\n\n rule windows_defender_av_monitored_events {\n meta:\n author = \"Chronicle\"\n description = \"Migration of CBN alerts to Google SecOps YARA-L detection engine rule alert.\"\n // Severity is set at the Outcome level via security_result.severity\n severity = \"INFORMATIONAL\"\n priority = \"INFORMATIONAL\"\n events:\n $windows_defender_av.metadata.vendor_name = \"Microsoft\"\n $windows_defender_av.metadata.product_name = \"Windows Defender AV\"\n $windows_defender_av.metadata.product_event_type = \"MALWAREPROTECTION_STATE_MALWARE_DETECTED\"\n $windows_defender_av.principal.asset.hostname = $host\n // optionally tune to only detection on ALLOW, i.e., failure to BLOCK\n //$windows_defender_av.security_result.action = \"ALLOW\"\n // optionally tune on severity of detection\n //$windows_defender_av.security_result.severity != \"LOW\"\n outcome:\n $risk_score = max(\n if ($windows_defender_av.security_result.severity = \"UNKNOWN_SEVERITY\", 0) +\n if ($windows_defender_av.security_result.severity = \"LOW\", 25) +\n if ($windows_defender_av.security_result.severity = \"MEDIUM\", 50) +\n if ($windows_defender_av.security_result.severity = \"HIGH\", 75) +\n if ($windows_defender_av.security_result.severity = \"CRITICAL\", 100)\n )\n $severity = array_distinct($windows_defender_av.security_result.severity)\n condition:\n $windows_defender_av\n }\n\n#### CBN alert appears to use a field that was not parsed into UDM\n\nUsing the parser extensions option you can quickly address this scenario.\n\nFor example, Corelight CBN alert uses the `notice` field and conditionally alerts only if true: \n\n if [notice] == \"true\" {\n mutate {\n replace =\u003e {\n \"is_significant\" =\u003e \"true\"\n \"is_alert\" =\u003e \"true\"\n }\n }\n }\n\nBecause this value isn't normalized into UDM by default you can use a parser\nextension Grok as follows to add that value as a UDM field of type `Additional`: \n\n filter {\n mutate {\n replace =\u003e {\n \"notice\" =\u003e \"\"\n }\n }\n grok {\n match =\u003e { \"message\" =\u003e [ \"(?P\u003cmessage\u003e\\{.*\\})$\" ] }\n on_error =\u003e \"_grok_not_syslog\"\n overwrite =\u003e [ \"message\" ]\n }\n json {\n on_error =\u003e \"not_json\" \n source =\u003e \"message\"\n array_function =\u003e \"split_columns\"\n }\n if ![not_json] {\n if [notice] != \"\" {\n mutate {\n convert =\u003e {\n \"notice\" =\u003e \"string\"\n }\n }\n mutate {\n replace =\u003e {\n \"additional_notice.key\" =\u003e \"notice\"\n \"additional_notice.value.string_value\" =\u003e \"%{notice}\"\n }\n }\n mutate {\n merge =\u003e {\n \"event1.idm.read_only_udm.additional.fields\" =\u003e \"additional_notice\"\n }\n }\n mutate {\n merge =\u003e {\n \"@output\" =\u003e \"event1\"\n }\n }\n }\n }\n }\n\nYou can then utilize this in a YARA-L detection engine rule as follows, and using the [Maps function](/chronicle/docs/detection/yara-l-2-0-syntax#maps): \n\n events:\n // Corelight : Weird Log\n (\n $corelight.metadata.vendor_name = \"Corelight\" and\n $corelight.metadata.product_name = \"Zeek\" and\n // this requires a custom parser extension to extract notice\n $corelight.metadata.product_event_type = \"weird\" and\n $corelight.additional.fields[\"notice\"] = \"true\"\n )\n\nYou must enable and turn on the authored rules for alerting. For more information, see [Run rule live data](/chronicle/docs/detection/run-rule-live-data)."]]