Using Att&ck framework in Azure Sentinel

The Mitre Att&ck framework is frequently utilized by Security Operation Centers to describe the behavior of the threat or to display detection capabilities. Because of the widespread use of the framework, a lot of Security vendors introduced it in their tooling. Azure Sentinel also has some capabilities related to Att&ck, but it does not provide every functionality a SOC needs. I created some solutions in the past (and present) to bypass Sentinel’s limitations which I am going to show in this article.

Azure Sentinel is constantly under development by Microsoft. When I first had to implement a solution to handle MITRE Att&ck technique-based alerts I had to do some nasty workarounds to circumvent the limitations in Sentinel. Nowadays, due to the added functionalities, adding technique information to an alert or incident is much easier but still limited. Thus, in this post, I’m going to explain my older solution and a more convenient newer one too.

Att&ck for SOC

The framework can be utilized for multiple purposes at a company. Here are a few examples of what I used it for in the past:

• Display the detection capabilities of the company and identify blind spots.
• Identify and describe the behavior of threats and threat actors.
• Provide better detections by using Tactics and Techniques.
• Detect heavily used Techniques against the company to identify improvement points.

And there are a lot of other things you can use Att&ck at a company. From the solutions explained later in this post not all of them can be used to achieve these purposes. Thus, you should carefully pick a solution or mix them together so they can satisfy your requirements.

Att&ck in Sentinel

Tactics inconsistency

In Sentinel, while creating an Analytics rule, you can assign one or more Tactics to the rule. These Tactics are going to be stored in the event of the generated alert (SecurityAlert table) and you can see them when you open an Incident. At the time of the writing of this post Sentinel supports 13 different Tactics:

Beside the first, PreAttack one, all of them are valid Mitre Att&ck Tactics in the Enterprise matrix. For a long time, Mitre used the 12 matching Tactics in its framework. Starting with version 8, they introduced the Reconnaissance and the Resource Development Tactics expanding the number of Tactics from 12 to 14. However, Microsoft did not follow this, and instead of the above-mentioned two solutions, they created a new one called PreAttack. PreAttack in Sentinel covers both the Reconnaissance and the Resource Development Tactic.

To be precise the Techniques in PreAttack are not new. Those techniques were already there under the Tactic name of Reconnaissance and Resource Development but they were not stored in the Enterprise matrix. They were in the PreAttack matrix. Later on, Mitre moved them to the Enterprise matrix under the Tactic name of Reconnaissance and Resource Development while Microsoft created the Tactic “PreAttack” for these Techniques.

This discrepancy is a slight inconvenience if you want to use these “new” Tactics in other security solutions, or when you already have your processes and tooling for Att&ck in place.

Missing Techniques

Even though there is a small difference between the Tactics offered by Sentinel and the one defined by Mitre, there is an even bigger challenge to solve in the case of Techniques. Namely, Techniques are not supported by Sentinel at all at this point. Since some of Microsoft’s other tools support Techniques, I think it is only a matter of time and they are going to be introduced to Sentinel. But even in the meantime, some companies need this functionality to utilize their rules and their dashboard at their finest.

Also, important to point out, that lot of providers who support Techniques do not utilize the newest versions of them. Recently, Mitre introduced the sub-techniques which are still not there in most of the tools. Also, techniques are constantly added to the list. Thus, if you utilize your own solution to use Att&ck framework you can always use the newest version you want to use, instead of relying on external providers.

Challenge to solve

So, the challenge when we are talking about Mitre Att&ck framework in Sentinel is to create a solution from scratch that supports all the Mitre Tactics as they were defined by Mitre and all the Techniques too.

Solution #1: Storing MITRE information in a file

I created this solution when other options were not available yet. I am merely going to explain the solution in theory without providing any code because the implementation is simple.

The idea behind this version is to store every Mitre Att&ck Tactic and Technique and Analytics rule association in a file that can be processed by Sentinel. In my initial solution, I used a blob storage for this purpose but there are other options too. For example, since then, Microsoft introduced and improved the Watchlist function in Sentinel which can be used to satisfy the same requirements.

Format of the blob file I used (csv) with 1 sample entry:

A high-level explanation of the method:

1. Create normal analytics rules the same way you would do otherwise.
2. ill a blob storage with the Analytics rule name – Mitre TTP information.
3. (Optional) Create a Playbook that triggers when an Alert is created, correlates the blob table with the given alert, and stores the alert with the additional information in a new table.
4. When you create new queries correlate the blob with the alerts or use the new events created in step 3.

In my MITRE analytics rules I have correlated this information with my already created alerts (or you can use the events created by your above-mentioned Playbook)):

let MitreInformation = externaldata(AlertName:string, Tactic: string, Technique: string, SubTechnique: string)[h'< link_to_blob >'] with (format="csv");  
SecurityAlert  
| join kind = leftouter (MitreInformation) on $left.AlertName == $right.AlertName  
| project TimeGenerated, DisplayName, AlertName, Tactic, Technique, SubTechnique 

One can see on the picture below that the Att&ck information is associated with the alerts now. At this point, you can use these events however you want.

Using these Mitre TTP infused logs, it is easy to create any query or Analytics rule based on Att&ck information. Also, just by querying the uploaded file and without using the SecurityAlerts table one can create a Workbook or Graph to display the detection capabilities and blind spots.

Limitations

There is one big drawback of this solution. Not that long time ago Microsoft introduced parameterized Alert and Incident creation. This means you can call an alert: Exfiltration to {service}. When this alert triggers the {service} part is going to be replaced dynamically based on the query. So, the name of the alert can be “Exfiltration to github” once and “Exfiltration to Google Drive” in another case. So, the AlertName field in the events can be different every time. On the other hand, the file you upload with the MITRE information in it is static, and most of the time you will not be able to create an entry for all the possible parameters. Thus, you won’t be able to correlate the Mitre file with the dynamically created Alert names.

It is not a lost cause though. One solution is to use the ID of the Analytics Rule for correlation instead of its name. This info also can be found in every SecurityAlert event.

The rule ID is generated when the rule is deployed in Sentinel. Thus, it is not possible to pre-define them and save them into a file before their deployment. You can only query this information from Sentinel after the creation of the rule. So, the Mitre file can only be put together after the rules are deployed. This is a long manual work if you recreate rules frequently in Sentinel. On the other hand, if you implement Sentinel as a Code, then this won’t be a problem, because in this case these steps can be automated. Therefore, you never have to open the Mitre file manually.

Another solution is to utilize the next method.

Solution #2: Utilize the Alert enrichment (Preview) / Custom details functionality

A few months ago, Microsoft introduced the Custom details option for Rule creation. This function can be used to add additional details to every SecurityAlert event. A year ago, we were only able to define 4 Entities. These were the information that we could additionally add to an event besides the default fields. Later on, Microsoft enhanced this option and let us add a lot more different Entities. Right now, we can choose from 18 different fields like Registry key, DNS, Process which were not there in the past.

But Microsoft also improved this and now we can add our Custom entities. This means we can add any information to an alert event we want to. This opens up a lot of options for us. For example, we don’t have to use a Playbook to enrich our data and then store it in a different table (unlike in case of the previous method). Now we can enrich our alert and incident events directly by defining these values during the Analytics rule creation.

You can define these Custom Details on the portal. During rule creation, you have to project the fields in your KQL query you want to use during Custom Details definition. You can do it in a hardcoded way (this is what I do for the sake of simplicity for now). Once they are projected, you can use them to define the custom information at the Alert enrichment part of the rule creation (see below). This is the second page of the rule creation wizard:

Once a rule like this is being triggered, you will be able to see this information in the alert event (SecurityAlert). Unfortunately, these values are not there in the SecurityIncident events. This is not a big deal though, because we can correlate the Incident events and Alert events based on a common property like this:

SecurityIncident 
| mv-expand AlertIds 
| extend AlertIds = tostring(AlertIds) 
| join (SecurityAlert 
    | extend CustomDetails = tostring(parse_json(ExtendedProperties).["Custom Details"]) 
    | project SystemAlertId, CustomDetails) on $left.AlertIds == $right.SystemAlertId 

(Be aware, this query returns 1 entry/AlertId/Incident and not 1 entry/Incident)

In the alert, one can find the relevant information in the ExtendedProperties field. The fields still need to be expanded to be completely useful:

You are also lucky if you want to deploy Sentinel as a Code and you have rules as template files. The template file can contain a tag called CustomDetails in which you can store the CustomDetails definitions. Here is my example, in which I store the Tactic values from the query in the Tactic field and the Technique values in the Technique field. Obviously, you still need to project these values in your KQL query,

"customDetails": {  
    "Tactic": "Tactic",  
    "Technique": "Technique"  
    }  

Compared to the previous solution, the parameterized alerts are not going to be a problem here, because no correlation needs to be done based on the name of the alert. Here, the necessary information is already in the alert without any additional steps.

Limitations

Unfortunately, this solution also has a limitation which comes from the fact that Analytics rules can’t be queried by KQL. While Alerts and Incidents are stored as events in a table, the Analytics Rules, their logic and metadata are not, therefore we can’t list them by using a KQL query. This means providing information about the existing detections or our blind spot is not directly possible by using this method.

The previous solution stored our Analytics Rules in a file together with their Mitre categorization. It was possible to query that file by using the externaldata operator to provide information about the existing detection capabilities. To solve this problem in a reliable way, you have to store your rules and the Att&ck information in a file. If you need to have a list of detections at your company, it can be a good method to mix the two solutions together, using files but also using Custom Details. (This way you still don’t have to use Playbooks.)

Also, a drawback of this solution is that if you already have a lot of alerts then you must modify all of them one-by-one. With the previous method, you simply had to upload a file to be able to utilize the Mitre information. And putting a csv file together is quicker and easier than modifying every existing rule in your system.

Summary

In this post, I wanted to show an effective way to assign Mitre Att&ck information to Analytics rules in Azure Sentinel. While using Custom Details is a really simple way to do this, it has some drawbacks. To solve these issues, you can create a workaround based on the first solution I explained in this post. Sentinel is continuously under development, so there is a chance that some of the problems we have today are not going to be an issue in the future.