Sentinel & SOAR: Part 1
Introduction:
Hello there,
Welcome to part 1 of my multi-part series regarding Security Orchestration, Automation & Response (SOAR) within Sentinel. The goal of these blogs is to share the knowledge I’ve acquired over the past couple of years working with automation within Sentinel. I’m going to visit topics like the different identities you can use with playbooks, how to automate your playbook deployment from A to Z and how to properly monitor your automation stack. However, before we dive into the good stuff, we’ll need to bring everyone up-to-speed. That’s what this first blog is for: laying a foundation of knowledge upon which we’ll build in the next couple of blogs.
SOAR?
Most of you’ve probably heard the term SOAR in the hallways, but for those who’re unfamiliar: SOAR stands for Security Orchestration, Automation and Response. Let’s explore those terms a bit further:
· When thinking about orchestration, try to imagine an orchestra: a large collection of different instruments working together in harmony to produce a desired outcome. The same principle applies to security orchestration, the goal is to combine different tools and orchestrate them together in such a way to reach a desired outcome. An example might be to integrate a deception tool with Sentinel or integrating a ticketing system with Sentinel.
· Security automation is exactly what you think it is: automating processes which were previously done manually. These processes can be very simple, like tagging an incident or assigning an owner to an incident, or quite complex, like checking a specific URL and isolating a machine and disabling a user based on the outcome.
· Security response is the concept of providing the analyst with a single view containing all information, so that the analyst can easily plan, manage and respond based on the incident. We can achieve this by integrating different systems, automating incident enrichment and providing the analyst with the perfect tools to respond (playbooks).
Even though it might be quite the challenge to design and implement a proper SOAR approach (and procuring all the required skills within the team), the advantages make it worth the effort: Faster response times and less repetitive work for analysts, allowing them to spend time on incidents which truly matter.
Sentinel & SOAR:
Now that we’re all familiar with the theory it’s time to look at the actual application of those concepts within Sentinel. Sentinel has two components which together deliver the SOAR capabilities: Automation Rules and Playbooks.
· Automation Rules are the simplest and easiest to start with. Automation rules have a defined trigger, some if/and/or statements and then proceed to perform an action. Automation rules mainly have impact within Sentinel: changing properties of incidents like owners, tags, tasks, severities and statuses. However, Automation rules can also perform the action that is the gateway to having an impact outside of Sentinel: triggering Playbooks.
· A Playbook is a Logic App with a defined Sentinel trigger (incident, alert, entity). Being a Logic App, playbooks are capable of complex logic and operations which is outside the capabilities of Automation Rules. Playbooks can use loops, conditions, switches, manipulate data and interact with almost everything, as long as there’s an API to talk with.
It’s important to remember that you’re going to need both components to implement SOAR within Sentinel. Automation rules will be required to link analytic rules to playbooks, otherwise there’s no mechanism to trigger your playbooks automatically.
Playbooks in practice:
Now that we’ve had our introduction to the different components, we’re going to be playing around with them. Playbooks can be automatically triggered by automation rules, but it’s also possible to trigger playbooks manually from the incident page within Sentinel. This can be very handy for testing or when you’ve created a playbook for some action that you only want to run on-demand.
Imagine that you’re responding to an incident and you’ve concluded that the account is in fact compromised. You probably want to disable the user as quickly as possible. Luckily, you can use the example playbook we’ve showed above to do just that. Open up the incident actions and select “Run playbook (Preview)”
After selecting the action, another panel will open up. Here you can select whichever playbook you want to run. We’re going to run our Disable-AzureADAccount playbook.
After clicking the Run button, a notification appears that the playbook is being triggered. Once the playbook has successfully triggered, another pop-up is displayed.
Heading over to the Playbook’s resource page, there’s a new entry in the run history. In this example everything went fine and the Playbook’s run has succeeded.
Heading over to the account in Azure AD, we’ll find that it has been successfully disabled, thus resolving the immediate threat in our fictional incident.
What’s to come:
The example above is a very, very simple demonstration of automating processes within Sentinel, but it does show the value. Hopefully the example created more questions then answers, because it skips over a lot of important things.
In the next couple of blogs we’re going to dive into those questions in detail and highlight different elements of automation within Sentinel. Topics we’re going to visit include development of Playbooks, security of said Playbooks, the different identities usable within playbooks, their pro’s/con’s and monitoring your automation stack, thereby allowing for easy troubleshooting. Be sure to keep an eye out for the next entry in this series!
