By yokhaldi and Azure Sentinel News
« Time is money » I like that old phrase 🙂
Security teams are often burdened with a growing number and complexity of security incidents. A Security Orchestration, Automation and Response (SOAR) solution offers a path to handling the long series of repetitive tasks involved in incident triage, investigation and response, letting analysts focus on the most important incidents and allowing SOCs to achieve more with the resources they have.
Azure Sentinel, in addition to being a Security Information and Event Management (SIEM) system, is also a platform for Security Orchestration, Automation, and Response (SOAR). One of its primary purposes is to automate any recurring and predictable enrichment, response, and remediation tasks that are the responsibility of your Security Operations Center and personnel (SOC/SecOps), freeing up time and resources for more in-depth investigation of, and hunting for, advanced threats.
Automation takes a few different forms in Azure Sentinel, from automation rules that centrally manage the automation of incident handling and response, to playbooks that run predetermined sequences of actions to provide powerful and flexible advanced automation to your threat response tasks.
Here are some use cases a SOAR solution can help in analyst journey:
In this Blog post I will try to present some practical use cases around automation.
Use case 1: Threat Intelligence gathering
- SOC team gets threat intelligence feeds and log data from 3rd party solutions via Azure Sentinel connectors and correlate data.
- Some of the alerts match patterns of suspicious activities that were seen before and trigger Azure Sentinel playbooks (designed to automatically respond to known threats).
The goal here is to import threat intelligence feeds from AlienVault OTX platform to enrich logs stored in Azure Sentinel
Why it’s important: is there recent intelligence that suggests an URL or IP in your environment is part of command-and-control infrastructure? Are you concerned your domain is being used to serve malware? Threat intelligence can help quickly recognize the existence of these threats, allowing you to begin the remediation process. This intelligence is directly related to alerts from Azure Sentinel, enabling you to make faster, more informed, risk-based decisions.
To address this use case, I used this Logic App to import threat indicators from AlienVault into Azure Sentinel using the Graph Security API.
Here the procedure to implement playbooks in Azure Sentinel:
View AlienVault TI in Azure Sentinel
The logs will go to a native Azure Sentinel table called ‘ThreatIntelligenceIndicator’ as shown below.
These malicious URLs can be correlated with other data generated from Endpoint security or proxy solutions. In this use case, I will use Microsoft Defender for Endpoint raw data collected by the new Microsoft 365 Defender connector to detect which devices in my network communicates with URLs known as malicious based on AllienVault threat indicators:
From here you can easily transform your hunting query to a detection rule (reactive way):
and assign any playbook for remediation:
Use case 2: Reducing false positive
- The activities that are deemed normal “use case” are filtered to avoid SOC team wasting time on false positives.
The goal here is to use the new feature in Azure Sentinel which is called « Automation rules » to resolve incidents that are known false or benign positives without the use of playbooks.
For example, during a tests the Dev team is using new agent browser and testing automation procedures, many false-positive incidents may be created that the SOC wants to ignore. A time-limited automation rule can automatically close these incidents as they are created while tagging them with a descriptor of their generation’s cause.
Here we can see a new incident generated in Azure Sentinel based on a specific detection rule:
Our goal is to avoid this kind of false positive and close the incident based on specific criteria.
As an alternative, we can edit the detection rule and apply a filter based on IP address or username, but we should maintain this rule and update it after tests finish. More details can be found here: Handling false positives in Azure Sentinel – Microsoft Tech Community
The advantage of using automation rules is that we can apply an expiration time to remove this rule!
Use case 3: Incident enrichment
- SOC team starts investigating incidents by simply clicking on them to see threat details such as the activity logs, devices involved, or identities used.
- Add information (GEO IP, IOC) to the incident during the investigation process
In this example, Microsoft cloud app security (MCAS) triggered an alert about an activity which is detected from a location that was not recently or was never visited by any user in the organization.
This alert is imported in Azure Sentinel through the Microsoft 365 Defender connector and generate an incident :
The security analyst can use Azure Sentinel playbook to enrich this incident with information about the associated entities, in this case our goal is to get more information about the IP associated to the incident.
To address this use case, I create a playbook based on the official Logic App connector for Virus Total
For more details on how implement the playbook, you can see this blog written by my colleague Rod Trent How to Take Advantage of the New Virus Total Logic App Connector for Your Azure Sentinel Playbooks –…
Once the playbook is created, you can run it from the incident page:
Then select the right playbook from the list:
After few seconds, you will be able to see information about this IP in the comment section:
As I said at the beginning « Time is money » so have a fun playing with these use cases 🙂
Special thanks to Clive Watson and Alp Babayigit for their support.