Security Operations Platform arrow_forward expand_more
Solutions arrow_forward expand_more
Why Chronicle arrow_forward expand_more
Why Chronicle

Rely on a modern approach to threat detection and response.

Why Chronicle
Partners arrow_forward expand_more
Resources arrow_forward expand_more
Security Operations Platform arrow_forward expand_more
Solutions arrow_forward expand_more
Why Chronicle arrow_forward expand_more
Why Chronicle

Rely on a modern approach to threat detection and response.

Why Chronicle
Partners arrow_forward expand_more
Resources arrow_forward expand_more
IDC Study: Customers cite 407% ROI with Google Chronicle. Learn More IDC Study: Customers cite 407% ROI with Google Chronicle. .
New to Chronicle: Safe Browsing Integration

"New to Chronicle" is a deep-dive series by Google Cloud Principal Security Strategist John Stoner which provides practical guidance for security teams that are either new to SIEM or replacing their SIEM with Chronicle. You can view the entire series here.

In our previous two blogs on contextual awareness, we showed you how to  enrich our UDM events and refine rules with entity data from users and assets. Today, we are going to continue working with data stored in the entity graph, specifically global entity data, to help drive our detections. This entity data is available to every Chronicle user and contains some of the most actively exploited known bad hashes that Google uses to help power the Safe Browsing API, which protects billions of devices globally. It does not take up additional space in your environment and is refreshed twice daily. We are going to look at Safe Browsing data and how this can be integrated into your Chronicle detections!

Safe Browsing 101

For those not familiar with Safe Browsing, it helps protect over five billion devices by warning users when they attempt to navigate to dangerous sites or download dangerous files. If you have seen a red screen interrupt your browsing in Chrome or had a file download blocked, you have been protected by Safe Browsing.

We aren’t going to deep dive on Safe Browsing itself, but we are going to discuss the data Safe Browsing provides to Chronicle and how you can build detections to leverage this data. The Safe Browsing capability has been available with Chronicle since October 2022, but in case you haven’t checked it out, let’s do that now.

Administrators and analysts do not need to import or load Safe Browsing data into their Chronicle instances. The Safe Browsing data is what we refer to as global contextual data. Much like entity context information (users and assets), it is available in the entity graph. This is just scratching the surface on the entity graph, so stay tuned for more goodness!

Safe Browsing is made up of many different blocklists and Chronicle ingests a subset of the SHA256 file hashes. These hashes are associated with files that have been assigned either a Malware or Unwanted Software classification. Google’s definition of Unwanted Software is available here. Now, you can imagine that given Google’s vantage point, there are a tremendous number of hashes that range from benign to mildly suspicious to clearly malicious. The hashes exposed to Chronicle users through Safe Browsing reside in the clearly malicious end of the spectrum, so if there is a match, there is a high confidence that the associated file is problematic.

Creating Rules with Safe Browsing Data

To take advantage of Safe Browsing data, we need to create a rule in Chronicle. Below is a good starter rule that will get you started.

On line 7, we are looking at PROCESS_LAUNCH and FILE_CREATION events, but if you want to extend this to other types of events, you can broaden the rule as you see fit. As long as the UDM event contains a SHA256 hash, we can compare it to the Safe Browsing entity data.

Because we are going to group our detection on $hostname, we declared a variable on line 8 to use in our match condition (line 19). Using a hostname or some other field that represents the asset is a pretty logical choice, but if you wanted to group by more than one field or some other grouping, you may. Line 9 is directing Chronicle to take the hash value in the target.process.file.sha256 field and match that to the entity graph using the variable name $sha256. If you wanted to add additional filtering conditions to your rule, you could do that as well, but this is what I would consider the bare minimum needed for the UDM events.

Starting on line 11 we are focused on the entity graph and narrowing our data set. For our join to work, we need to assign the same variable of $sha256 to the entity.file.sha256 field. From there, lines 12-13 are used to filter our entity data to focus just on Google Safe Browsing file hashes. Line 14, metadata.source_type describes different types of contextual data in the entity graph. By specifying Google Safe Browsing in metadata.product_name, we negate the need to define a value in the metadata.source_type field. However, we will be using metadata.source_type to narrow our focus in future entity graph contextual rules, so it is a good field to get in the habit of including it when describing and filtering our entity data.

I consider lines 15 and 16 to be optional, but they can be used if you want finer grain control on the severity and category fields. Because we are defining these hashes as being highly suspicious, we could probably start by leaving them out and then adding them back in if needed.

At the end of our YARA-L rule is a condition statement that  includes both the UDM event ($execution) and the entity data ($safebrowse).

rule safe_browsing_file_process_creation {

 meta:

   author = "Chronicle Security"

   description = "Identify file and process creation events that correlate with Safe Browsing malicious hashes"

   severity = "Medium"

 events:

   ($execution.metadata.event_type = "PROCESS_LAUNCH" or $execution.metadata.event_type = "FILE_CREATION")

   $execution.principal.hostname = $hostname

   $execution.target.process.file.sha256 = $sha256

   // join execution event with Safe Browsing graph

   $safebrowse.graph.entity.file.sha256 = $sha256

   $safebrowse.graph.metadata.entity_type = "FILE"

   $safebrowse.graph.metadata.product_name = "Google Safe Browsing"

   $safebrowse.graph.metadata.source_type = "GLOBAL_CONTEXT"

   $safebrowse.graph.metadata.threat.severity = "CRITICAL"

   $safebrowse.graph.metadata.threat.category = "SOFTWARE_MALICIOUS"

 match:

   $hostname over 1h

 condition:

   $execution and $safebrowse

}

When we test our rule, we can see that we have four detections but numerous events and entities under each one. Because we are grouping our events by hostname, there are multiple malicious hashes and associated events on each system. Like events, entities are going to be sampled in the Chronicle user interface when more than 10 supporting entities are returned. Let’s click on the first entity (in green) and see the associated entity information.

Here is the supporting information that Safe Browsing makes available in the entity graph. This includes those key values that we use to constrain our rule including the category and severity. Notice this hash has been in the Chronicle entity graph since September 29, 2022 based on the value in metadata.collected_timestamp. This roughly aligns to the time we added Safe Browsing global contextual data to our entity graph.

I’m excited about this addition and I hope you are as well! For some of you more cynical minded folk (and you know who you are), you are waiting for a catch…No, there isn’t a catch, the data is there for your use. However it is important to understand that while Safe Browsing data is in the entity graph, it does have a metadata.source_type of GLOBAL_CONTEXT which means that it is not available in your BigQuery instance. But hey, that’s ok, if you have a detection based on this data, those detections are still written to BigQuery and are available for use in dashboards, so you can still bubble up and report on those matches.

Safe Browsing integration with Chronicle provides analysts with a context rich list of SHA256 hashes that are continually updated with known bad files that can be easily applied to your environment today. All you need is a rule to get started with it (and I just gave that to you)! So, please take the time to add Safe Browsing to your YARA-L rules and add more context to your detections today.

New to Chronicle Series

Let’s work together

Ready for Google-speed threat detection and response?

Contact us Visit the contact us page