Welcome to another Security Analyst Diary entry. We are thrilled to cover one of our coolest feature releases with the launch of context-aware detections, alert prioritization, and risk scoring earlier this week. Check out the video podcast of this diary entry.
With context-aware detections in Google Chronicle, Google’s cloud-native SIEM, all the supporting information from authoritative sources (e.g. CMDB, IAM, and DLP) including telemetry, context, relationships, and vulnerabilities are available out of the box in one rule. With this launch, Google Chronicle customers can now incorporate context earlier in the detection authoring and execution workflow, enabling them to:
-
Enhance fidelity of alerting: Enabling analysts and detection engineers to filter out entire clusters of threats that may be expected or represent little-to-no danger to the enterprise (e.g. malware testing in a sandbox environment, vulnerabilities and anomalous activity in a development network with no sensitive data or access, and more). This reduces the need for post-detection enrichment which can add latency and increase MTTR for a given alert.
-
Prioritize threats with risk scoring: Making relevant context available for heuristic-driven contextual risk scoring of detections at detection execution time rather than at the human triage stage.
-
Respond to alerts faster: Enables them to respond to alerts faster by giving them a graphically integrated and interactive way to view context information from inside the alerts page. This includes information around IT security systems (e.g. EDR consoles, firewall/proxy logs, CMDB and IAM context, and vulnerability scan results).
These new features of the Chronicle Security platform build upon Chronicle’s Unified Data Model (UDM) and Chronicle Detect to enable: Relational modeling via an entity graph
In this diary entry, we’ll recap the basics of Chronicle’s context enrichment, drill into the new capabilities this release provides, and cover some examples of how Chronicle users have been using these capabilities so far.
Context is key
Chronicle’s context enrichment consumes asset, group, or user entity data (context enrichment has more supported types) from a customer’s source(s) of truth, such as Azure AD, Okta, Cloud Identity, and Workday, and enriches this data automatically into UDM events. This means that customers can:
-
Immediately see all contextual information about that entity, from a range of sources, directly in the UDM event itself
-
Search and detect upon values in the UDM event that would not otherwise be present in the original log
Take the following three logs below.
metadata.event_type = “PROCESS_LAUNCH” metadata.product_name = “ACME Unix” metadata.product_log_id “1” principal.user.userid = “bob” metadata.event_type = “EMAIL_TRANSACTION” metadata.product_name = “ACME Email” metadata.product_log_id “2” principal.user.email_addresses = “bob@acme.com” metadata.event_type = “USER_RESOURCE_ACCESS” metadata.product_name = “ACME AD” metadata.product_log_id “3” principal.user.windows_sid = “12345”
Without context enrichment in place In order to find all activity relating to the entity Bob it would require running a UDM Structured Search for each individual Entity attribute, e.g., UserId, Email Address, and Windows SID.
With context enrichment configured from a source of truth, Chronicle can evaluate every single log received (a feat possible courtesy of the compute power of Google) and inject all associated values for that entity into the UDM event.
The resultant UDM event, including all known entity attributes, would conceptually look as follows:
metadata.event\_type = “USER\_LOGIN”Metadata.product\_name = “ACME Unix”metadata.product\_log\_id “4”**principal.user.userid = “bob”****principal.user.windows\_sid = “12345”****principal.user.email\_addresses = “bob@acme.com”**
And a structured search for “principal.user.email_addresses = ‘bob@acme.com’” is in in effect the same as searching for “principal.user.email_addresses = ‘bob@acme.com’ OR principal.user.userid = ‘bob’ OR principal.user.windows_sid = ‘12345’”.
This concept also applies to detection engine YARA-L rules too, meaning you can detect or build single or chained multi-event rules from disparate entity identifiers. For example, you could join a log that only includes a windows_sid or their userid, all by the field email_addreses, even if not present in the original logs.
Now that we have recapped some of the fundamentals, let’s move on to how this is being used as part of our new release driving context-aware detections.
Say hello to Chronicle entity graph
Chronicle graph is a relational entity graph that can make use of joining UDM event data with context enriched data, and supports relational models too — e.g., entity user X owns entity asset Y that has access to entity resource Z (a database, firewall, storage bucket, etc.)
Let’s show some examples of this in action.
Privileged command monitoring via Chronicle graph
Take the following YARA-L detection rule that monitors privileged commands on production systems, a single event detection rule, using a reference list:
rule prod\_privileged\_command\_usage {meta:author = “ACME Detection Labs”description = “Detects privileged command activity on production services.”severity = “HIGH”events:**$prod.metadata.event\_type = “USER\_RESOURCE\_ACCESS”****$prod.metadata.vendor\_name = “ACME”****$prod.metadata.product\_name = “ACME Audit Daemon”****$prod.metadata.product\_event\_type = “Shell Activity”****$prod.security\_result.action = “ALLOW”****$prod.target.process.command\_line in %ACME\_highly\_privileged\_commands****$prod.principal.user.userid = $user**match:$user over 15mcondition:**$prod**}
This is a powerful detection as is; however, it can be made more powerful if we could make conditional results depending on the context of the command run, or the user running the command.
To start leveraging Chronicle’s graph capabilities via Detect, you need to join the UDM event data, the object named $prod, against graph data, the object named $context.
In order to join UDM event data against the Chronicle graph it requires a join key — a match variable $user.
rule prod\_privileged\_command\_usage {meta:author = “ACME Detection Labs”description = “Detects privileged command activity on production services.”severity = “HIGH”events:**$prod.metadata.event\_type = “USER\_RESOURCE\_ACCESS”****$prod.metadata.vendor\_name = “ACME”****$prod.metadata.product\_name = “ACME Audit Daemon”****$prod.metadata.product\_event\_type = “Shell Activity”****$prod.security\_result.action = “ALLOW”****$prod.target.process.command\_line in %ACME\_highly\_privileged\_commands****$prod.principal.user.userid = $user** **$context.graph.metadata.vendor\_name = “ACME”****$context.graph.metadata.product\_name = “CMDB”****$context.graph.metadata.entity\_type = “USER”****$context.graph.entity.user.userid = $user **match:$user over 15mcondition:**$prod and $context**}
And, the output of the above rule via Chronicle detection view.
Note, there is now not only the UDM events, but also entity events, in this case a user entity.
While context enriched information has been available via the UDM event — e.g., it’s injected into the UDM principal or target object — it is now also accessible as a dedicated object.
With a link to the graph in place we can start to leverage Chronicle graph via the new YARA-L capability — Outcomes.
Changing the Outcome, with conditional risk scoring
A new feature with this release is the ability to apply risk scoring to your threat modeling in YARA-L rules.
Continuing from the prior example you can now augment YARA-L rules with the new Outcomes: section.
rule prod\_privileged\_command\_usage {meta:author = “ACME Detection Labs”description = “Detects privileged command activity on production services.”severity = “HIGH”events:**$prod.metadata.event\_type = “USER\_RESOURCE\_ACCESS”****$prod.metadata.vendor\_name = “ACME”****$prod.metadata.product\_name = “ACME Audit Daemon”****$prod.metadata.product\_event\_type = “Shell Activity”****$prod.security\_result.action = “ALLOW”****$prod.target.process.command\_line in %ACME\_highly\_privileged\_commands****$prod.principal.user.userid = $user****$context.graph.metadata.vendor\_name = “ACME”****$context.graph.metadata.product\_name = “CMDB”****$context.graph.metadata.entity\_type = “USER”****$context.graph.entity.user.userid = $user**match: **$user** over 15m**outcome:****$risk\_score = max(****if ( $prod.metadata.product\_event\_type = “Shell Activity”, 50) +****// Privileged commands we wish to monitor****if ( $prod.target.file.full\_path = “/sbin/acme\_sql”, 20) +****if ( $prod.target.file.full\_path = “/sbin/acme\_backend”, 10) +****if ( $prod.target.file.full\_path = “/sbin/acme\_frontend”, 5) +****// Monitored users & groups who can have access****if ( $context.graph.entity.user.department = “IT”, 10) +****if ( $context.graph.entity.user.department = “SRE”, 5) +****// — empty values would denote ACME CMDB is not populating correctly, not expected****if ( $context.graph.entity.user.department = “”, 20) +****// Raise Risk for Contractors — not expected behavior****if ( $context.graph.entity.user.title = /contractor/ nocase , 20)****)**condition:**$prod** and **$context**}
Outcomes supports the variables $risk_score (only) at this time, and can make use of either SUM or MAX aggregate functions. Via a conditional IF statement you can call UDM Event, or UDM Entity Event data via Chronicle Graph to calculate a risk score.
In the above example specific commands ($prod.target.file.full_path) from UDM Event data are weighted, as well as business context information ($context.graph.entity.user.department).
And, an example of the output with the new risk modeling (risk_score) applied.
The keen eyed may have noticed in the YARA-L rule’s description mention of detections over 80 being routed to create a P1 ticket — that’s because the risk_score is now an exported field in the API output and can be used for logic based routing.
{“type”: “RULE\_DETECTION”,“detection”: \[{“ruleName”: “prod\_privileged\_command\_usage”,“urlBackToProduct”: “https://cmmartin2.backstory.chronicle.security/ruleDetections?ruleId=ru\_f05de1cc-6c25-44b5-9a7d-cb9169f46a67&selectedList=RuleDetectionsViewTimeline&selectedDetectionId=de\_03ff5dd8-0c48-3a4b-d46a-e3339cb6a9db&selectedTimestamp=2022-01-29T22:07:30Z&versionTimestamp=2022-01-31T09:15:57.839791Z",“ruleId”: “ru\_f05de1cc-6c25–44b5–9a7d-cb9169f46a67”,“ruleVersion”: “ru\_f05de1cc-6c25–44b5–9a7d-cb9169f46a67@v\_1643620557\_839791000”,“alertState”: “ALERTING”,“ruleType”: “MULTI\_EVENT”,“detectionFields”: \[{“key”: “user”,“value”: “elsa”}\],“ruleLabels”: \[{“key”: “author”,“value”: “ACME Detection Labs”},{“key”: “description”,“value”: “Detects privileged command activity on production services. Detections with a Risk Score of above 80 \*will\* raise a p1 ticket.”},{“key”: “severity”,“value”: “HIGH”}\],**“outcomes”: \[****{****“key”: “risk\_score”,****“value”: “100”****}****\]**}\],“createdTime”: “2022–01–31T09:16:55.671501Z”,“id”: “de\_03ff5dd8–0c48–3a4b-d46a-e3339cb6a9db”,“timeWindow”: {“startTime”: “2022–01–29T21:52:30Z”,“endTime”: “2022–01–29T22:07:30Z”},“collectionElements”: \[{“references”: \[{“event”: {“metadata”: {“eventTimestamp”: “2022–01–29T22:06:53.004150Z”,“eventType”: “USER\_RESOURCE\_ACCESS”,“vendorName”: “ACME”,“productName”: “ACME Audit Daemon”,“productEventType”: “Shell Activity”,“ingestedTimestamp”: “2022–01–29T22:06:54.011801Z”},“principal”: {“user”: {“userid”: “elsa”,“userDisplayName”: “Elsa”,“windowsSid”: “S-1–5–21–1180699209–877415012–3182924384–6127”,“emailAddresses”: \[“elsa@ext.example.com”\],“productObjectId”: “6127”,“firstName”: “elsa”,“phoneNumbers”: \[“+1 415 555 6127”\],“groupIdentifiers”: \[“it@acme.com”\],“title”: “IT Support \[Contractor\]”,“department”: \[“IT”\],“managers”: \[{“userDisplayName”: “Jamon”,“emailAddresses”: \[“ham@example.com”\],“productObjectId”: “1488”}\]},“ip”: \[“10.10.3.16”\],“namespace”: “production”},“target”: {“process”: {“pid”: “1748”,“commandLine”: “acme\_sql \\”select \* from db.production\\” > db.bak”},“ip”: \[“172.20.5.10”\],“file”: {“fullPath”: “/sbin/acme\_sql”},“resource”: {“name”: “\[172.20.5.10\]:/sbin/acme\_sql”}},“securityResult”: \[{“summary”: “Success”,“action”: \[“ALLOW”\]}\]}}\],“label”: “prod”},{“references”: \[{“entity”: {“metadata”: {“collectedTimestamp”: “2022–01–29T18:34:47.979140Z”,“vendorName”: “ACME”,“productName”: “CMDB”,“entityType”: “USER”,“interval”: {“startTime”: “2022–01–29T18:34:47.979140Z”,“endTime”: “2022–01–29T23:59:59Z”}},“entity”: {“user”: {“userid”: “elsa”,“userDisplayName”: “Elsa”,“windowsSid”: “S-1–5–21–1180699209–877415012–3182924384–6127”,“emailAddresses”: \[“elsa@ext.example.com”\],“productObjectId”: “6127”,“firstName”: “elsa”,“phoneNumbers”: \[“+1 415 555 6127”\],“groupIdentifiers”: \[“it@acme.com”\],“title”: “IT Support \[Contractor\]”,“department”: \[“IT”\],“managers”: \[{“userDisplayName”: “Jamon”,“emailAddresses”: \[“ham@example.com”\],“productObjectId”: “1488”}\]},“location”: {“city”: “Brussels”}},“relations”: \[{“entity”: {“asset”: {“hostname”: “Elsa-laptop”,“assetId”: “Elsa-6127”,“ip”: \[“10.10.3.16”\],“mac”: \[“dd:ee:ff:33:22:11”\],“category”: “LAPTOP”,“networkDomain”: “ext.acme.com”,“deploymentStatus”: “ACTIVE”}},“entityType”: “ASSET”,“relationship”: “OWNS”}\]}}\],“label”: “context”}\],“detectionTime”: “2022–01–29T22:07:30Z”}
Pretty neat.
In summary, with this rule for privileged command monitoring with Chronicle graph, we can:
-
Monitor for highly privileged commands on production systems, leveraging CMDB data to ensure we have accurate monitoring of required assets
-
Receive fully enriched alerts including the Asset’s info from the CMDB, and no need to perform secondary or tertiary lookups
Improving the Joiners, Movers, and Leavers process with Chronicle graph
Chronicle’s UDM supports a wide range of context fields, several of which we can use for common movers, leavers and joiners activities within a company, such as:
-
Hire and Termination dates
-
Time off
-
Department, Location, Employee IDs
-
Active Status
Let’s take an example UDM Entity event representing a user — our Doogler Chief Chaos Officer, Jamon.
In addition to common user context data, we also have annual leave, start date, automatically ingested from the CMDB (a popular source of this information is Workday):
metadata.collected\_timestamp = “2022–01–29T21:20:32.956874Z”metadata.vendor\_name = “ACME”metadata.product\_name = “CMDB”metadata.entity\_type = “USER”entity.user.userid = “jamon”entity.user.user\_display\_name = “Jamon”entity.user.windows\_sid = “S-1–5–21–1180699209–877415012–3182924384–1488”entity.user.email\_addresses = “jamon@acme.com”entity.user.product\_object\_id = “1488”entity.user.first\_name = “jamon”entity.user.phone\_numbers = “+123 415 555 1488”entity.user.group\_identifiers = “execs@acme.com”entity.user.title = “Chief Chaos Officer”entity.user.department = “Chief Chaos Officer”entity.user.managers.user\_display\_name = “Ping”entity.user.managers.email\_addresses = “ping@acme.com”entity.user.managers.product\_object\_id = “7327”**entity.user.time\_off.interval.start\_time = “2022–01–24T21:20:32Z”****entity.user.time\_off.interval.end\_time = “2022–02–03T21:20:32Z”****entity.user.time\_off.description = “Annual Leave. 10 Days.”**entity.location.city = “Amsterdam”relations.entity.asset.hostname = “Jamon-laptop”relations.entity.asset.asset\_id = “Jamon-1488”relations.entity.asset.ip = “10.1.2.15”relations.entity.asset.mac = “aa:bb:cc:22:22:22”relations.entity.asset.category = “LAPTOP”relations.entity.asset.network\_domain = “acme.com”relations.entity.asset.deployment\_status = “ACTIVE”relations.entity\_type = “ASSET”relations.relationship = “OWNS”
As this information is incorporated into the Chronicle graph, you can leverage it also via YARA-L, e.g., to alert if a user successfully authenticates while on leave.
rule prod\_auth\_activity\_while\_on\_leave {meta:author = “ACME Detection Labs”description = “Detects auth activity for users reported on annual leave.”severity = “INFORMATIONAL”events:**$auth.metadata.event\_type = “USER\_LOGIN”****$auth.metadata.vendor\_name = “ACME”****$auth.metadata.product\_name = “Acme SSO”****$auth.security\_result.action = “ALLOW”****$auth.target.user.userid = $userid**// login event should be after holiday start interval**$auth.metadata.event\_timestamp.seconds >****$context.graph.entity.user.time\_off.interval.start\_time.seconds**// and login event should be before holiday end interval**$auth.metadata.event\_timestamp.seconds <****$context.graph.entity.user.time\_off.interval.end\_time.seconds****$context.graph.metadata.vendor\_name = “ACME”****$context.graph.metadata.product\_name = “CMDB”****$context.graph.metadata.entity\_type = “USER”****$context.graph.entity.user.userid = $userid**match:**$userid** over 15m**outcome:****$risk\_score = max(****if ( $auth.metadata.event\_type = “USER\_LOGIN”, 10) +****// Monitor audited and/or high risk groups****if (****$context.graph.entity.user.department = “Chief Chaos Officer” or****$context.graph.entity.user.department = “Office of the Chief Executive Doogler”****, 25****)****)**condition:**$auth** and **$context**}
And, the YARA-L detection view results include the link to the UDM event and the context information, enabling not only the detection of such business context events against event data, but with all the context in the result itself!
Another example could be to alert on any authentication activity for a user that has left or their contract expired, e.g.,
metadata.collected\_timestamp = “2022–01–25T20:04:26.483053Z”metadata.vendor\_name = “Microsoft”metadata.product\_name = “Azure Active Directory”metadata.entity\_type = “USER”entity.user.userid = “dave”entity.user.user\_display\_name = “dave left”entity.user.windows\_sid = “S-1–5–21–2621619321–00000000002542681321–32132”entity.user.email\_addresses = “dave@example.com”entity.user.product\_object\_id = “daveleft”entity.user.first\_name = “dave”entity.user.last\_name = “left”entity.user.phone\_numbers = “+1 222 321 321”entity.user.title = “Remote”**entity.user.hire\_date = “2020–01–01T00:00:00Z”****entity.user.termination\_date = “2022–01–01T00:00:00Z”**
Applying this as a YARA-L rule, such as the below example:
rule entity\_graph\_left\_user\_auth {meta:author = “Chronicle Security”description = “Detects employees that are reported as having left the organization authenticating to a corporate resource.”severity = “HIGH”events:**$auth.metadata.event\_type = “USER\_LOGIN”****$auth.metadata.vendor\_name = “Acme”****$auth.metadata.product\_name = “Acme SSO”****$auth.target.user.userid = $user****$auth.metadata.event\_timestamp.seconds >****$context.graph.entity.user.termination\_date.seconds****$context.graph.metadata.vendor\_name = “Microsoft”****$context.graph.metadata.product\_name = “Azure Active Directory”****$context.graph.metadata.entity\_type = “USER”****$context.graph.entity.user.userid = $user**match:**$user** over 15m**outcome:****$risk\_score = max(****if ( $auth.metadata.event\_type = “USER\_LOGIN”, 50) +****if (****$context.graph.entity.user.title = “Remote” nocase or****$context.graph.entity.user.title = “Temp” nocase or****$context.graph.entity.user.title = “Vendor” nocase****, 40) +****if ( $context.graph.entity.user.title = “Legal” nocase, 10)****)**condition:**$auth** and **$context**}
IOC matching natively via UDM
Previously, Chronicle’s IOC matching took place either via our:
-
Native IOC matching for IP or Domain indicators
-
Using Chronicle YARA-L rules with Reference Lists
Chronicle graph now provides the capability to index IOC directly into the UDM schema enabling IOC matching beyond IP and Domains, and without the requirement of using Reference Lists.
So far we’ve seen UDM Context types of USER, ASSET, and GROUP, but there are further entity types now available for use, and ones that lend themselves perfectly to IOC matching:
Let’s take a common IOC detection rule for type of IP Address. The first part of the process is ingested the IOCs into the Chronicle Graph which can be achieved via
-
Using our pre-built Chronicle integrations
-
A custom CBN parser
-
Using the Chronicle Ingestion API
Here’s an example of a ACME Threat Co’s IOC ingested into a UDM
metadata.product\_entity\_id = “41f302b2-a5dc-411a-a339–29fe8366b46b”metadata.collected\_timestamp = “2022–02–06T22:07:36.724075Z”metadata.vendor\_name = “ACME Threat Co”metadata.product\_name = “ACME Intel”metadata.entity\_type = “IP\_ADDRESS”metadata.interval.start\_time = “2022–02–06T22:07:36.724093Z”metadata.interval.end\_time = “9999–12–31T23:59:59Z”metadata.threat.category\_details = “C2”metadata.threat.url\_back\_to\_product = “https://tc.acme.com/db/ioc?ba949e99-06bc-411a-a76a-e6314838f074"metadata.threat.threat\_id = “ba949e99–06bc-411a-a76a-e6314838f074”metadata.threat.threat\_feed\_name = “ACME-IOC-IP-C2”entity.ip = “172.217.169.42”
Now, having ingested the IOC into Chronicle’s UDM, we can start to leverage it via a YARA-l detection rule. Our event data (in yellow) can be joined against the Graph data, with the join keys (green) being the asset IP address, and the IOC ip address. A new feature of the graph entities is a start and end date, which is a useful element for IOCs as they often only have a relatively short lifespan of utility.
rule prod\_ioc\_ip\_from\_dns\_query\_match {meta:author = “ACME”description = “Match ACME Threat Co IOCs against DNS query (IP) responses.”severity = “MEDIUM”events:// DNS event data**$dns.metadata.event\_type = “NETWORK\_DNS”****$dns.metadata.vendor\_name = “ACME”****$dns.metadata.product\_name = “DNS”****$dns.metadata.product\_event\_type = “query”****$dns.principal.ip = $asset\_ip****$dns.network.dns.answers.data = $ip**// only match IOCs during active duration**$dns.metadata.event\_timestamp.seconds >****$ioc.graph.metadata.interval.start\_time.seconds****$dns.metadata.event\_timestamp.seconds <****$ioc.graph.metadata.interval.end\_time.seconds**// IOC Asset Entity**$ioc.graph.metadata.vendor\_name = “ACME Threat Co”****$ioc.graph.metadata.product\_name = “ACME Intel”****$ioc.graph.metadata.entity\_type = “IP\_ADDRESS”****$ioc.graph.entity.ip = $ip**// Corp Asset Entity**$corp\_asset.graph.metadata.vendor\_name = “ACME”****$corp\_asset.graph.metadata.product\_name = “CMDB”****$corp\_asset.graph.metadata.entity\_type = “ASSET”****$corp\_asset.graph.entity.asset.ip = $asset\_ip**match:**$ip, $asset\_ip** over 15mcondition:**$dns** and **$ioc** and **$corp\_asset**}
Here you see the output of the above detection. What’s neat about this is the context of the a) IOC, and b) the sour_ce Asset. If you want to trac_e attribution back on an IOC match that’s a trivial task as the IOC is included in the Detection.
Merging Vulnerability context with Asset context
The last of our use cases for this release shows how you can combine and leverage your corporate vulnerability data for your assets via detection rules.
Here’s an example of an Asset Entity event that has included the latest results from our Vulnerability scanner:
metadata.collected\_timestamp = “2022–02–08T12:37:24.769286Z”metadata.vendor\_name = “ACME”metadata.product\_name = “CMDB”metadata.entity\_type = “ASSET”entity.resource.attribute.labels.key = “sensitivity”entity.resource.attribute.labels.value = “Confidential”entity.asset.product\_object\_id = “prd-srv-02–7711”entity.asset.hostname = “prd-srv-02”entity.asset.ip = “172.21.2.5”entity.asset.mac = “aa:bb:cc:77:11:22”entity.asset.location.name = “ben-prd-dc-02”entity.asset.category = “SERVER”entity.asset.network\_domain = “prod.acme.com”entity.asset.deployment\_status = “ACTIVE”**entity.asset.vulnerabilities.description = “ACME CVE-1781–1234: Backend Service Buffer Overflow”****entity.asset.vulnerabilities.last\_found = “2022–02–08T12:37:24.769311Z”****entity.asset.vulnerabilities.severity = “HIGH”****entity.asset.vulnerabilities.cvss\_base\_score = 8****entity.asset.vulnerabilities.vendor = “ACME Vuln Scanner”****entity.asset.vulnerabilities.cve\_id = “CVE-1781–1234”****entity.asset.vulnerabilities.description = “ACME CVE-1781–5678: Frontend Service Out of date library”****entity.asset.vulnerabilities.last\_found = “2022–02–08T12:37:24.769316Z”****entity.asset.vulnerabilities.severity = “MEDIUM”****entity.asset.vulnerabilities.cvss\_base\_score = 6****entity.asset.vulnerabilities.vendor = “ACME Vuln Scanner”****entity.asset.vulnerabilities.cve\_id = “CVE-1781–5678”**
As this vulnerability data is indexed into the Chronicle graph we’re able to make use of this via YARA-L rules to generate an appropriate risk score for any alerts that impact the device, e.g., if an endpoint or anti-x alert is raised up against an asset with either several vulnerabilities, or with high risk (via cve_score) then adjust the risk scoring accordingly:
rule prod\_alert\_on\_assets\_with\_critical\_vulns\_max {meta:author = “ACME Labs”description = “Detects alerts against assets with active vulns as reported by ACME Vuln Scanner.”severity = “HIGH”events:**$alert.metadata.event\_type = “SCAN\_HOST”****$alert.metadata.vendor\_name = “ACME”****$alert.metadata.product\_name = “Endpoint Protection”****$alert.principal.ip = $ip****$vuln.graph.metadata.vendor\_name = “ACME”****$vuln.graph.metadata.product\_name = “CMDB”****$vuln.graph.metadata.entity\_type = “ASSET”****$vuln.graph.entity.asset.deployment\_status = “ACTIVE”****$vuln.graph.entity.asset.category = “SERVER”****$vuln.graph.entity.asset.ip = $ip**match:**$ip** over 15moutcome:**$risk\_score = max(****// CVE Score adjustments****if ( $vuln.graph.entity.asset.vulnerabilities.cvss\_base\_score = 1, 10) +****if ( $vuln.graph.entity.asset.vulnerabilities.cvss\_base\_score = 2, 20) +****if ( $vuln.graph.entity.asset.vulnerabilities.cvss\_base\_score = 3, 30) +****if ( $vuln.graph.entity.asset.vulnerabilities.cvss\_base\_score = 4, 40) +****if ( $vuln.graph.entity.asset.vulnerabilities.cvss\_base\_score = 5, 50) +****if ( $vuln.graph.entity.asset.vulnerabilities.cvss\_base\_score = 6, 60) +****if ( $vuln.graph.entity.asset.vulnerabilities.cvss\_base\_score = 7, 70) +****if ( $vuln.graph.entity.asset.vulnerabilities.cvss\_base\_score = 8, 80) +****if ( $vuln.graph.entity.asset.vulnerabilities.cvss\_base\_score = 9, 90) +****if ( $vuln.graph.entity.asset.vulnerabilities.cvss\_base\_score = 10, 100)****)**condition:**$alert** and **$vuln**}
And the output is a higher risk score alert as this particular server has a known high severity vulnerability.
Summary
We covered a lot in this diary entry around our context-aware detections, enabling enrichment, alert prioritization, risk scoring and the entity graph — what it is, and the challenges it’s solving for analysts today. One of the precursors for effective use of Chronicle graph is context aliasing. Make sure your context aliasing sources are all in scope — and working as expected — and focus on threat modeling your business workflows with Chronicle.
We’re excited about the kinds of detection that are possible with this launch. During our public preview, customers used these modules to detect various threats and took remedial actions to prevent threats earlier in their lifecycle.
Over the next months as we move these modules towards general availability, you can expect to see a steady release of new detection capabilities and integrations with other parts of Google Cloud and additional third party providers.
To learn more about these new capabilities, contact your Google Cloud Platform sales or CSM team. You can learn more about all these new capabilities in Google Chronicle in our product documentation. To learn more about our overall Google Chronicle vision please view our recorded sessions at Security Talks.
Looking forward to sharing another story in another Security Analyst Diary.