Since May 20221,2, Sekoia.io indicators can be integrated into Microsoft Sentinel. In this blogpost, we will cover how to take advantage of this integration and extend it using a playbook to ease access to the indicators’ context in Sekoia.io Intelligence Center.
Threat intelligence in Microsoft Sentinel and analytics rules
Sekoia.io indicators are ingested in Microsoft Sentinel through the “Threat intelligence —TAXII data” connector3. You can follow the steps detailed in our documentation4 to setup the ingestion.
Once enabled, this data connector will start ingesting the indicators in Microsoft Sentinel. A dedicated Threat Intelligence page in Microsoft Sentinel allows analysts to explore the imported indicators and view the indicators’ confidence, status and validity periods.
Microsoft Sentinel comes with predefined analytics rules that allow matching between collected events and indicators. These rules contain the KQL query and can be found in the “Rule Templates” tab of the “Analytics” section, by filtering on the “Threat Intelligence – TAXII” and “Threat Intelligence Platforms” data sources.
Rules can be created from these templates depending on your needs and on the logs ingested in Microsoft Sentinel (for example there are 2 different versions of the “TI map Domain entity to DnsEvents” rule, depending on whether your logs are ingested using the ASIM DNS Schema or not).
If an event matches an indicator, an incident will be opened in Microsoft Sentinel and will contain the relevant information about the indicator.
As we can see in the above screenshot, the analyst is lacking context around the threat that the indicator characterizes. He would have to copy the indicator and switch to Sekoia.io Intelligence Center to research the indicator and obtain the context.
We will see later how we can use a playbook to ease that pivot by providing, in the incident’s comments, a direct link to the indicator’s details in the Sekoia.io Intelligence Center.
Under the hood
Microsoft Sentinel “Threat intelligence – TAXII data” connector will ingest the Sekoia.io indicators in a specific table named “ThreatIntelligenceIndicator”.
In this table, imported indicators will have:
- an identifier internal to Microsoft Sentinel, stored in the “IndicatorId” field;
- a Sekoia.io identifier, stored in the “ExternalIndicatorId” field.
The ThreatIntelligenceIndicator table also contains other information about the indicators5 like the confidence level, the kill chain phase… The “IndicatorId” and “ExternalIndicatorId” fields are the most interesting to us here, as we will use them in the playbook.
If we dive into the details of the Analytics rules, we can see that the “IndicatorId” is an output of the KQL query used to match the events with the indicators.
We can also find the “IndicatorId” field in the Custom Details section of the rule so that it is added to the incidents created by the rule.
Warning : some of the analytics rule templates do not contain this configuration, it must be added manually so that the playbook works for them.
Piecing it together – the playbook
Now that we have seen how the Sekoia.io indicators are ingested and used in Microsoft Sentinel’s analytics rules, let’s take a look at how we can write a playbook to use the “IndicatorId” in the incident details to generate a link to the indicator’s context in Sekoia.io Intelligence Center.
The pseudo code logic of the playbook is the following:
- When the playbook is triggered, extract the content of the Incident Body
- For each alert aggregated in the Incident, extract the content of the Custom Details.
- For each IndicatorId in the Custom Details, run a KQL query against the ThreatIntelligenceIndicator table to obtain the ExternalIndicatorId linked to the IndicatorId
- For each result of the KQL query, add a comment to the Incident with a link to the Sekoia.io Intelligence Center
As you can see, the result in a Microsoft Sentinel playbook is based on very few steps, making it easy enough to implement and maintain.
Once implemented, you can test this playbook by executing it on a specific incident manually using the “Run playbook” action.
After a few seconds (and a refresh), the comments will appear in the incident:
As you can see in the short video below, when the analyst clicks on the link, the indicator’s object is opened in Sekoia.io Intelligence Center. From there, the analyst has the ability to obtain information about the threat linked to the indicator (Cobalt Strike in our example), the original source of the indicator.
By pivoting on the threat, the analyst will be able to obtain context about the threat, the way it works and a section “Course of Actions” that will give him information on how to continue his investigation of the alert.
It is also possible to execute the playbook every time an incident is created, using a simple “Automation rule”.
Possible improvements
An additional step could be added to the playbook to perform a request against the Sekoia.io Intelligence Center API6 to retrieve more context (like the malware name or the campaign an indicator characterizes) and add that information to the comment.
The comment added to the incident could also be improved by retrieving more information from the ThreatIntelligenceIndicator table, like the indicator value, the confidence level…
If you are using multiple Threat Intelligence sources in Microsoft Sentinel, an additional check would be required in the playbook to make sure that the indicator(s) that triggered the incident comes from Sekoia.io, otherwise it would lead analysts to an unexisting or incorrect object in the Sekoia.io Intelligence Center.
In its current state, this playbook does not account for similar alerts or duplicated entries in the ThreatIntelligenceIndicator table7, which can lead to a large number of comments being added to the incident.
Another approach that could be explored would be to send the alerts from Microsoft Sentinel to the Sekoia.io XDR platform. This approach could be interesting in a multi-cloud or hybrid setting to reduce the costs of centralizing all of the logs and to provide a single pane of glass for the SOC analysts.
In Sekoia.io XDR, analysts have access to the indicators’ context directly inside the alerts triggered by detection rules, based on the threat related to the indicator.
References
4https://docs.sekoia.io/cti/features/integrations/microsoft-sentinel/
5https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/threatintelligenceindicator
6https://docs.sekoia.io/cti/develop/rest_api/intelligence
7Duplicated entries are possible with the same IndicatorId but different ExternalIndicatorId as indicators can have the same value (domain name for example) but different STIX patterns.
Chat with our team!
Would you like to know more about our solutions?
Do you want to discover our XDR and CTI products?
Do you have a cybersecurity project in your organization?
Make an appointment and meet us!
Read other blogpost :