SUMMARY
Having a SIEM solution in place is an essential part of the security arsenal of the modern Security Operations, but it’s only the starting point of detecting and preventing threats in your environment. I’m using Microsoft Sentinel (a Cloud-Native SIEM solutions) for more than a year already and I can gladly state that it provides the engineering teams with flexible tooling for orchestration and automation of the ingested data. But It’s always hard to keep up with the new threats and create new detection queries and automation rules, isn’t it? Recently, Microsoft released a new feature in Microsoft Sentinel that maps all available query rules:
Active (Scheduled, NRT and Anomaly query rules)
Simulated (Hunting queries, Analytics and Anomaly rule templates)
into a single table that represents the MITRE ATT&CK Framework that is a huge step in the right direction of helping the security teams to fill the gaps:
As Microsoft is already taking advantage of the MITRE ATT&CK Framework in a lot of its products, all the analytics templates and hunting queries in Sentinel are already mapped using the respective Tactics and Techniques. So, the only missing piece of having the entire MITRE table in Microsoft Sentinel fully functional is to make sure the existing custom analytics (Scheduled and NRT) query rules are properly mapped as well.
If you still don't know how to do that, hold on tight, I’ll give you a quick example in the end of the post.
THE CREATIVE PROCESS
Knowing that all the rules in my Cloud-Native SIEM are properly mapped against the MITRE ATT&CK Framework, the main question that remain was: NOW WHAT? And the answer was rather obvious – Having the visibility of all active and potentially useful queries, rules, and templates in the environment give me the freedom of taking a deep breath and start thinking of everything that is not there yet.
Going back to the MITRE tab in Microsoft Sentinel outlined both the techniques (separated in Tactics sections) that are still not covered by any of the existing rules, and the ones that are not as dense as the Account Manipulation or Valid Accounts for instance. Taking this as a starting point helped me to identify the most critical Tactics and Techniques that the analysts must pay attention on.
Every organisation refract that criticality based on their own prism, based on various factors like Risk Appetite, Business requirements, etc.
Let’s start with something relatively easy and doable. Forced Authentication looked like the best candidate, as it uses well known ports (TCP 139, 445 and UDP 137) and protocols (SMB and WebDAV) and the only requirement was to have knowledge of the internal infrastructure.
Full Disclosure: I’m ingesting data from a Next-Generation Firewall with enabled Layer 7 filtering, so the query that I’m about to develop will be centered around that specific vendor. Based on the firewall technology of choice, the query may vary:
Network Appliance (Check Point, Fortinet, Palo Alto Network)
Host-based Firewall (Windows Firewall, Linux Firewall, AV Firewall)
Other
Despite MITRE’s recommendations to review only traffic that attempts to exit the internal networks and systems, I’ve decided to obtain a snapshot of all the traffic and to separate the results, filtering by Application (Protocol). To minimise the noise and gain better visibility over the traffic, I’ve decided to create three different queries, to fully cover the Forced Authentication Technique:
Filtered traffic, based on WebDAV application
Filtered traffic, based on TCP 139, 445 and UDP 137 ports
Filtered Microsoft Events by EventID 4663 (may requires additional logging configuration)
To start reviewing the WebDAV traffic, I’ve selected the Firewall logs (DeviceVendor) and filtering them by webdav protocol (ApplicationProtocol):
// MITRE ATT&CK
// Forced Authentication
// Monitor for WebDAV network traffic to unknown or suspicious systems.
CommonSecurityLog
| where DeviceVendor == “Device Vendor Name”
| where ApplicationProtocol == "webdav" As a result, I got almost 600 records for the past 24 hours, so the next step was to either remove the internal traffic (so it could reduce the results) using one of the above filters:
| where DeviceCustomString1 !in ("Users-to-LAN", "Users-to-PatchMGMT") // Use that filter if you have the names of the rules that explicitly allow WebDAV traffic. | where not (ipv4_is_private(DestinationIP)) // Use that filter if you want to remove all destination traffic to private networks , or to continue processing the results, which was truly beneficial in my case, because I got some more details about my environment and found some security concerns that will not be covered in this post.
| extend URL = split(AdditionalExtensions, '"')[1] // Required, as some of the RequestURL fields were not properly populated (discovered during result analysis)
| extend RequestURL = iff(isempty(RequestURL), URL ,RequestURL) // Add URL data where missing
| summarize count() by RequestURL Spoiler alert: too permissive directory shares containing software licenses, configurations, and credentials:
Despite the discovered security issues, all the traffic was recognised as legitimate, so I added it to an exception list, expanded the time frame and did the same exercise again. After a few iterations I was able to filter a few suspicious records to external locations that were detected and allowed by the firewall:
Even though, these records were not identified as malicious during the analysis phase, the traffic could be considered at least as suspicious, and because I’ve already filtered most of the noise (and most importantly the legitimate part of it), my query was ready to be added to rule set.
IMPLEMENTING THE LOGIC
Microsoft Sentinel provides with multiple ways of usage for Kusto queries, so the question that you may ask is what’s better, to add the query as an Analytics or Hunting rule. To be honest, both are pretty good options, but the Hunting queries (in my opinion) will be more suitable in cases where the results are a lot of noisier, and the hard work of analysing and filtering the legitimate entries is not done yet. As I’ve already did that, my query should generate an alert approximately every two weeks, which was more than acceptable rate and it’s not expected to increase the load of the Analysts on automatic Incident creation. Due to that, I went to Analytics -> Create -> NRT query rule (near-real-time) and added all required information, incl. the mapping against the MITRE ATT&CK Framework.
The rest of the scenarios could be developed using the same approach and depending on the goal that should be achieved, they could be implemented as either Analytics or Hunting queries.
Once created and enabled, the rules were already visible in the MITRE tab in Sentinel, under Credential Access -> Forced Authentication:
TAKE-AWAY POINTS
Considering the experience I have with that relatively new functionality in Microsoft Sentinel, I can conclude my impressions in a few key points:
Microsoft Sentinel is focusing its detection strategy around MITRE ATT&CK Framework which makes it easier to identify where in the kill chain a potential attack was detected or even mitigated.
Introducing the MITRE table in Microsoft Sentinel provides the Security Operations units with better visibility and understanding of their current blind sports.
Developing SIEM use cases is no longer head-banging experience to perform and demonstrate, as it’s now truly connected to an actual framework that provides the engineering teams with mitigation and detection details and guidance during the development process.
コメント