GETTING SENTINENTAL:P2
Welcome to the next part of ‘Getting Sentinental’. In the previous part, we explored the features ‘Data Connections’, ‘Incidents’ and ‘Analytic Rules’. If you’re here after going through the first two parts, I’m very grateful that my content has been helpful and/or sensible to you.
Following a similar structure of the previous parts, let’s get down to the ‘Structure’ section, GET IT!? 😉
Structure
We will continue to explore the other features or offerings of Sentinel in depth and in a similar format of understanding them in terms of deployment, usage, configurations (if any) and recommended practices.
If you are new to this series, you should have an understanding of the structure as below:
I will name the sections as Sentinel — FeatureX (S-FX) so that it is easier for me to refer the particular feature in subsequent sections rather than using the whole name. Yes, you guessed it right, I’m LAZY! This counting of features will be carry forwarded to the subsequent parts AND hence will also be back referenced from previous parts which will also give you the idea that which part or section of the blogs you should refer for understanding that feature.
S-F4:
UEBA
While this feature is now renamed as ‘Entity Behavior’ in Sentinel, I personally prefer the older name of UEBA which stands for User and Entity Behavior Analytics. As complex as it may sound, this feature is pretty straight forward and very useful as well.
Simply put, this feature creates a behavioral standard by analyzing and correlating all the user related data from Sentinel’s various data connections. Sentinel uses machine learning algorithms for creating this standard and provide some worthy actionable intelligence.
Usage:
For this particular feature, let me first explain the usage rather than deployment. The main use case for employing this feature would be to reduce the manual investigation to some extent by providing an overview of a user’s or an entity’s security estate. In other words, I would turn to UEBA if I want to know which are the users that have most number of incidents associated to them or which IP address has been found in more than 10 incidents or which hosts (endpoint or servers) have been the most affected in my organization.
The user accounts, hosts, IP addresses in the above example are collectively referred to as ‘Entities’. This is what will be the name of the section under an incident investigation page of Sentinel where you will find the affected and/or associated resources for an incident.
Another unique capability of UEBA is to identify and provide insights on the peer groups of a particular resource thus helping you to estimate the blast radius of that resource which eventually helps in understanding the criticality of it.
Deployment:
Enabling UEBA requires the ‘Microsoft Entra ID’ connector to be enabled and connected to Sentinel. UEBA primarily consumes the ‘Audit’ and ‘Signin’ logs from this connector. You can also connect your on-premises Active Directory instance to UEBA but for that you will have to configure and on-board those forests to Microsoft Defender for Identity (While this is completely out of scope for this blog, but you can connect with me if you come across any doubts or blockers around its deployment).
Note: Only a user with ‘Global Admin’ or ‘Security Admin’ role can enable and configure UEBA for a Sentinel instance.
Configuration:
You can also define some critical activities that you want to keep track of. This is a relatively new feature in UEBA that let’s you to be more vigilante about the type of activities that you or your organization are sensitive about. Sentinel provides some OOTB activity templates to be used in this context and also provides a provision of defining an custom activity query from scratch as well.
Recommended Practices:
1. For much better results, it is recommended to enable the ‘Security Events’ and ‘Azure Activity’ connectors in Sentinel and then connect them to UEBA.
2. UEBA stats monitoring should be included as a monthly or weekly SOC activity.
3. A thorough training and use case analysis of UEBA should be provided to the Level 1 analysts of a SOC team to improve their triaging skills.
S-F5:
Automation
I will cover ‘Automation Rules’ and ‘Playbooks’ in this same section since they together constitute the SOAR component of Sentinel. As the name suggests, these features are there to fasten the triaging and response for an incident by automating the process to variable extent.
S-F5.1 — Automation Rules
Automation rules can be seen as a flow chart that lets us define what actions should be performed for a particular incident or alert category. For example, if I want all the incidents generated from Microsoft Defender for Cloud to be assigned to a specific user or group, I can make use of automation rule.
Usage:
Directly set incident status (New, Active, Closed), severity (High, Medium, Low), assign an owner (user account or security groups), add a tag, running a playbook or add a task when an incident is created or updated. For alert creation, the only action allowed is running a playbook.
Configuration:
To configure an analytic rule, you can define a variety of conditions like user account involved, security product that created the incident, affected host name, a specific URL, MITRE tactic, affected registry key and a lot more.
Once we have identified our target incident and/or entity, we can define actions as explained in the ‘Usage’ section. You can even run two playbooks (one after the other) for a specific incident through the same automation rule.
After the main configurations are done, you can define if you want to run this rule for a specific time (days, months or years) by providing a rule expiration window or indefinitely.
You can define the order of automation rules if you have created more than one automation rule to be able to prioritize one over the other.
Recommended Practices:
1. You should be very specific while defining the conditions for an automation rule to filter as precise incident type or category as possible.
2. The use of ‘And’ & ‘Or’ filters in the ‘Conditions’ should be made wisely.
3. Rule order should be defined very carefully to to ensure that correct actions are being executed in the desired manner.
4. If the playbooks defined in the ‘Actions’ section takes more than 2 minutes to complete running, then the automation rule will proceed to the next step without waiting for it to be completed. If that’s your use case, then you should define two different automation rules in order one after the other.
I’d suggest you take some time to observe the below screenshot thoroughly and try to spot the feature that we discussed above.
S-F5.2 — Playbooks
Playbook is the Sentinel synonym of logic apps in Azure. As with logic apps used in Azure, playbooks in Sentinel are used to automate a certain action or task by defining a logical workflow of triggers, conditions and actions. Playbooks can get very complex and tactical in nature especially when interacting with external products or services.
Usage:
Defining a logical workflow of remediation and/or mitigation actions in response to a security alert or incident in order to automate the threat response process.
Deployment:
A playbook can either be deployed from the OOTB templates provided by Microsoft or can also be created from scratch as an logic app.
It follows the same deployment process as of any other Azure resource where you will need to define the resource group, region and name. You can optionally provide a log analytics workspace to store the diagnostic logs of the playbook runs. Another optional feature is the association with an ISE, in case you have one.
Configuration:
Broadly speaking, there can be three categories of components in a playbook workflow.
The first and the most important is a trigger. Currently, you can create a playbook with an alert trigger (alert is created), incident trigger (incident is created) and entity trigger (a specific entity is involved in an alert or incident). You can also create a blank playbook which can be an entirely different use case such as running the playbook every 1 hour.
Once the trigger is sorted, you should define a filter. This section of the workflow will focus on narrowing down the entities of the incident and/or retrieving the necessary information about the entities. For example: I want to get the manager (information) of the user involved in the incident if he/she is from the ‘Sales’ department (narrowing).
The next part is the obvious one, action. Here you can make use of various playbook connectors provided in-built by Microsoft for a variety of solutions and products (native and non-native to Microsoft) like Microsoft Entra ID (disable a user account, reset password etc.), Microsoft Outlook (send email, create event etc.), Microsoft Defender for Endpoint (isolate a device, run antivirus scans etc.), Slack (post a message, join/create a channel etc.), Service Now (create, delete, update record etc.) and many more.
Please note that playbooks can become very complex and deep as per your use case, hence the information given above should only be considered as the tip of the iceberg. If you have a specific use case in mind and would like to discuss its implementation, feel free to reach out on LinkedIn.
Recommended Practices:
1. You should provide relevant permissions for a playbook to be allowed to run from an automation rule. For this your account should have the ‘Microsoft Sentinel Contributor’ role assigned.
2. You should consider the playbook run pricing which varies depending on the frequency, triggers, types of connectors, actions defined and runs happening. You can make use of the ‘Automation Health’ workbook in Sentinel for this information.
3. You should test the execution of the logic app on a test device, user account or a non-production environment to make sure nothing is getting broken.
4. You can also run playbooks on demand for a specific incident and can also attach playbooks to an analytic rule as well.
S-F6:
Workbooks
This section will be significantly shorter than the rest since this feature while being an important one is very straightforward to explain. Workbooks are nothing but dashboards created for having a birds eye view of the different operations going on within Sentinel. Its worth noting that ‘Workbooks’ are not limited only to Sentinel but can also be seen in solutions like Defender for Cloud, Azure Monitor, Conditional Access etc.
Usage:
Creation of rich visual reports by querying different data sources (discussed in SF-1) from across Sentinel and combining them to portrait information that can help as a driving force in improving the process efficiency. Majorly used by security operations team as the main data source for recurring (quarterly, monthly weekly etc.) reporting exercises.
Deployment:
A one click deployment by just clicking on ‘Save’ from the OOTB templates menu. Its important to note that the ‘template’ section will only show the workbooks for which the relevant solutions has been installed (refer S-F1).
You can also create workbooks from scratch if there is none available for your requirement or even modify an existing one. You should have good knowledge of KQL and the log tables used in Sentinel to manipulate data and getting the insights needed.
Recommended Practices:
1. Once an workbook is created from the OOTB templates, make sure to look for occasional updates by Microsoft.
2. You should ensure that your queries do not reveal any sensitive and user information through the results.
3. Workbooks should be created with version control and should be stored in a central repository (in JSON format) to be able to use in other Sentinel instances.
Hoping that this was useful to you, I’ll start working on the next part of this series. Please leave your thoughts, feedback, questions or concerns, if any. I’d also love to catch up on LinkedIn. Meet you in the next part!!
Till then BE SAFE, BE YASHURED!
