Building out or enabling Analytics Rules in Azure Sentinel allows customers the ability to automate analysis of the data that is being ingested and stored in the Log Analytics workspace. These are important for exposing security events and potential threats to the environment. Analytics Rules produce Incidents (if you’ve allowed the defaults during the rule enablement) when they find that something you told it to look for and alert you to.
From an investigative analyst perspective, these Incidents should contain enough context to help in eventually solving the “case” or at least enabling first steps toward that direction. A vitally important piece of that context is supplied through the Entities that get associated with the Incident. These Entities are discovered through the Analytics Rule logic (KQL) and recorded as part of the Incident.
An Incident without Entities is nearly worthless. Here’s a few reasons why.
1. Lack of Evidence Makes for a Sad Detective
The best example of how to explain this is to use regular law enforcement. When a crime is committed, the more facts that can be gathered ensures that detective (or investigative analyst) can begin the investigation. A suspect, a phone number, an address, an action, and anything else that is important to carrying out an investigation should be included if possible.
Think of this from a detective’s perspective. A case file is handed to the detective. The detective begins perusing the file’s contents to find that there’s no suspect, no witness, and no evidence. How would they proceed? This is probably what makes the TV detectives so snarky and bad tempered. I can just hear it: “Oh, thanks Sarge.”
Currently, Azure Sentinel allows enabling of the following Entities (or facts/artifacts). I’ve matched each Entity to it’s law enforcement relative to better understand the relation:
- Account = Suspect or witness
- Host = Home or business address
- IP = Phone number (sometimes there are multiple, i.e., cell, home, business)
- URL = Suspect action (might contain an alibi, might incriminate)
- FileHash = Evidence (the smoking gun)
As with law enforcement, a lack of a suspect or any type of evidence makes an Azure Sentinel Investigation just as painful. But, our goal is also to provide as much context as possible. The more context (the more evidence, facts, etc.) the quicker an Investigation can be closed. Missing Incident collateral can lead to undetermined and cold cases.
No Entities makes for a sad detective
2. No Investigation Graph
Did you know that without at least one Entity associated with an Incident the super-cool Investigation Graph is not available?
The Investigation Graph is a graphical component that turns our Entities into a timeline or story of how a potential threat progressed. It provides huge value for analysts to be able to view the in a more meaningful way and a way to visualize the progression. For example, it could build out that a user click on a link in an email that downloaded content from a nefarious website that compromised the account. Without the Account, URL, and IP entities, we’d have a much more difficult time figuring out the storyline. It could still be done, but there’d be a lot of manual work and we might end up missing something important.
3. No Automation for Additional Context
For every Investigation I help with, I always supply a bit of automation through a couple Playbooks. Once submits IP Addresses to IP-API.com to return geographical location and submits the information to the Comments section of the Incident. Another thing I do (if there’s also an Account Entity) is submit an email address to the Haveibeenpwned service to determine if the account is clean (not publicly compromised). Without Entities, you can’t supply this additional context. Knowing the location and who manages the IP Address and knowing that the account is safe, is important context.
Why the PSA?
I talk about how important Entities are during my workshops, but what brought this up specifically for this PSA was the recent availability of free content for Azure Sentinel customers from SOC Prime. (See: SOC Prime O365 rules and more now offered free, exclusively to Azure Sentinel users).
After a bit of initial investigation, there are no Entities assigned in the KQL logic for the Analytics Rules provided. So, you’ll need to add your own.
It’s easy to do. Just go back into the Analytics Rule and on the Set Rule Logic tab in the Analytics Rule wizard, click the dropdown for each Entity Type and select the appropriate value.
The one’s supplied by SOC Prime (thank you, SOC Prime!) are for Office 365, so I know at least the Account entity is available to assign.
UPDATE November 3, 2020: This post raised enough awareness of the incomplete SOC Prime Analytics Rules that the organization is working to fix them. Updates will come in the “next flight” – which is sometime in the next 2 weeks.
4. EXTRA: No URL Detonation
After posting this, my colleague, Matt Egen (super, excellent Azure Sentinel resource, btw) pointed out something I’d forgotten to include.
Unique to Azure Sentinel, in the Investigation Graph, we have the ability to display a “screen capture” of the URL the user clicked on (or, that was used in execution of a crime). This screen capture gets associated and attached as evidence to the Incident/Investigation. This provides the best sand-boxing environment for an analyst to ensure that they can see exactly what the perpetrator saw without compromising the rest of the environment. Try this with a competing security tool.
P.S. There’s other cool aspects of this “Sonar” technology for our URL detonation that I’ll cover in depth in a future blog post.
Can you think of other reasons why Entities are important? Let me know.
