Welcome to a new year, and with it comes a two-part blog on the Chronicle Security Operations platform alert graph. I thought I was going to be able to squeeze it all into a single post, but as I dug further and further, I realized we couldn’t do it justice in a single blog. So, in this first post we’ll cover what the alert graph is, what we can find in it and how we can make the alert graph work for us as security practitioners. The subsequent post will build on this and cover how we can use the alert graph during investigations.
Simply put, the alert graph visualizes alerts that are generated from a YARA-L rule in Chronicle. This provides detection engineers with a good deal of flexibility around the data points to put in front of an analyst while also enabling the analyst to visualize not just this alert, but additional alerts that are associated with entities found in the alert.
The alert graph is populated based on what is in the YARA-L rule that generated the alert. If you take nothing else away from this blog, keep that in mind. The quality of what is in the alert graph is tied to the context that is built into the YARA-L rule.
In the image above, we can see three sections of the alert graph; the alert and entity cards on the left side of the screen, the graph that visualizes the relationships between the entities and the alert in the middle, and a set of three sub-tabs at the bottom of the page. The events sub-tab contains the supporting events that triggered this rule, the entities sub-tab contains entities associated with the alert (more on that below) and the alert context section contains a list of values that provide an analyst additional context about the alert.
Where does this context come from? I’m glad you asked. Notice on the left side of the Alert Context subtab that there is a column called Type which will contain one of the following terms: match or outcome. The next column is called Variable. These variable names are based on the names of the match and outcome variables defined within the rule. Finally, the far right column is UDM Field. Variables that have a UDM Field listed are also hyperlinked in the Values column. The subset of UDM fields that are hyperlinked includes the following:
This is not an exhaustive list, but as you can see all of these fields are associated with entities and supporting information around files and processes. The specific UDM nouns that are associated with these fields are principal, target, and src. If we click on any of these hyperlinked values, a search will be triggered, passing the value along with the time range of the past day.
In our example alert, the context is quite rich, giving the analyst an immediate understanding that the impacted instance is a BigQuery table named customers, that the detection came from Security Command Center, its risk score, the compromised account and a suspicious IP address. The writer of this rule incorporated outcome variables into their YARA-L rule to make this context available to the analyst. We discussed outcome variables over a year ago, and the concepts still apply, they’ve just become even more useful. In our last post before the holidays on Community Rules, we provided links to our GitHub repo and style guide that provide examples of rules, all of which (should) have outcome variables in them that can take advantage of the alert graph as well!
Let’s talk about the entities in the alert graph. When an alert is triggered, entities associated with the alert are displayed on the graph and on the left side of the screen; each with its own card. When we use the term entities, we are referring to assets, users, file hashes, URLs, domains and resources. Examples of resources include datasets and tables in BigQuery. All of these are on the bulleted list above, so think of the items displayed in the graph and the cards as a subset of the broader field list above.
Cards display information about the alert including its status, severity, priority and risk score in addition to metadata about the rule and when the detection was triggered. Cards for assets and users include first and last seen values and the ability to drill into search to get more information about the specific entity.
When writing rules, detection engineers need to determine the appropriate fields to include in the rule. After all, there are multiple file hash, user and asset fields. Chronicle handles this heavy lifting for you so that analysts are not saturated with entities. What do I mean by that? Let's look at a few examples.
This example is using the Google Cloud Threat Intelligence (GCTI) list of remote access tools along with process and file creation events to detect these tools. I modified the rule and added to the outcome section a set of variables to capture the fields principal.process.file.sha256, principal.process.file.sha1 and principal.process.file.md5. Just because we have all three of these fields in the outcome section of our rule does not mean that we are going to get cards and entities on the graph for each one. If many different hashes were detected within a single time window, that view would be difficult to work with. Instead, Chronicle de-duplicates the hashes and displays the card for the SHA256 hash and entity value on the graph. However, in the alert context sub-tab, all three hashes values are displayed and each one can be drilled into.
If we apply this same concept to user fields, we see that even though we have principal.user.email_addresses and principal.user.employee_id in our alert context, we get a single user card represented on the left side of the screen and only the user’s display name in the graph. When we use multiple outcome variables to describe our user like userid and windows_sid, Chronicle resolves them to a single user and displays a single value. This same concept applies to assets as well.
By default, Chronicle only displays five entities when the alert graph is viewed. The intent is to not overwhelm the analyst with too much information. In the entities sub-tab, all entities are listed and the analyst has the option of adding (or removing) assets from the card and graph views as they conduct their analysis by clicking the checkbox in the On Graph column.
With that overview of the alert graph in place, I’m going to stop here for now. Next time, we will look at how we can use the alert graph to investigate alerts and detections.
LinkedIn
Twitter