GETTING SENTINENTAL:P1
Welcome to the next part of ‘Getting Sentinental’. In the previous part, we explored the fundamentals of a SIEM and SOAR, their functionalities, use cases and best practices. In case you want to go through that, please have a look here.
So without further delay, let’s start with this part’s structure so that you can know whether this will be relevant for you or not.
Structure
Starting with this part, we will understand the features or offerings of Sentinel in greater depth including details related to their deployment, usage, configurations (if any) and recommended practices to use them as a part of your security arsenal.
There are many features which are related to the others in some way or another because that only makes sense! Hence, I’ll try my best to not confuse you folks and keep it as much simply chronological as possible.
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 which will also give you the idea that which part or section of the blogs you should refer for understanding about that feature.
S-F1:
Data Connections
This is the first and the most important feature to be enabled in Sentinel in order to generate events and logs from various solutions and/or products. It’s only logical to keep this feature at the top of the hierarchy since almost everything in terms of deployment will be possible only after enabling data connections.
Deployment:
The deployment of data connectors takes place through the ‘Content Hub’ menu that contains ‘Solutions’. A Solution is a package of different types of Sentinel contents (data connectors, analytic rules, playbooks, workbooks, hunting queries) for a specific product or solution, bundled together for the ease of deployment. In order to get these contents enabled, you will need to install the solution withing the Sentinel instance.
Usage:
Simply said, data connectors are the gateway to ingest logs and events into Sentinel which are then queried through logical manipulations to detect any suspicious and/or potentially malicious activities throughout the organization (depending on the products connected to Sentinel).
Configuration:
It is important to note that just installing the solutions won’t enable the contents within it as everybody’s use case might be different for the OOTB offerings. Hence, you will need to configure each content individually (other than workbooks and hunting queries) in order to make use of them. Also, since Microsoft keeps providing new contents over time, you should also look out if there are any updates available for the already installed solutions.
Recommended Practices:
1. The solutions in ‘preview’ should be installed with caution and preferably tested in a non-production environment.
2. Some solutions may incur some additional pricing and/or resource deployment requirements along with the cost of log ingestion (which is common for all solutions). Hence, it should be well checked before installation.
S-F2:
Incidents
Since almost everything in Sentinel revolves around incidents, we will cover this section next. Incidents, simply put, are a notification to the security analysts that something is not right in the organization. This is required because that’s what anybody would like to know so that the probable disruption can be contained and minimized.
As much as being notified is important, it is pretty useless if we do not have the relevant and (most importantly) enough information about the suspicious event. That’s where Sentinel stands out from other security products. The real USP of Sentinel is it’s ability to go very granular in terms of logs inspection and provide us with the most useful information possible for our investigation.
Deployment:
There is no dedicated procedure of deploying this feature in Sentinel. Although, it is mandatory to mention that it heavily (or should I say solely) relies on S-F1 and S-F3 for its existence. Hence, there is nothing much to mention here.
Usage:
I think it goes without saying that this will be the highly used feature in Sentinel for most of the people out there. You will mostly use this feature/menu to get the essential details about an incident like timestamp, affected user(s) and/or device(s), and related entities like IP addresses, URLs, mailboxes, SharePoint sites, cloud resources etc.
An important point to note is that if an incident is generated from another Microsoft security product like M365 Defender, Defender for Cloud and even any 3rd party product like Prisma Cloud, you will most probably get enough (if not all) details within the Sentinel investigation page making it a single pane of glass for all your security oversights.
Recommended Practices:
1. You should cater incidents as per their severity (High, Medium, Low & Informational).
2. You should create email notification playbooks for critical incident categories and/or for high severity incidents in order to be notified as soon as they are generated.
3. You should classify the incidents (True Positive, False Positive & Benign Positive) very carefully and properly to strengthen Sentinel’s intelligence and provide a reliable reference for similar future incidents.
4. The helpful utilities like ‘Tasks’, ‘Comments’, ‘Activity Log’ and ‘Tags’ (self explanatory by names) should be used to the fullest to have an enriched incident management experience.
5. Incident operations should be monitored and reviewed on a recurring basis to identify the gaps and rectifying them for reducing the mean time to triage.
S-F3:
Analytic Rules
Sentinel cannot create incidents on it’s own unless we tell it what to look for. Hence, Analytic rule is what you will have to create in order to generate incidents in Sentinel. These are the logical queries that runs in various frequencies (minute, hour or day) and look for the suspicious events defined in the rule through the language called KQL (Kusto Query Language). I will cover KQL in a separate section S-FX, sooooooon!
For example: I want to know if someone within my organization or even outside of my organization is doing any sensitive operation (deleting, modifying, stopping, installing etc.) on one of the storage accounts in Azure.
Deployment:
While you can definitely create your own custom analytic rules by defining a custom query, the initial deployment of this feature is usually done during the enablement of S-F1. Microsoft provides a set of OOTB (Out-Of-The-Box) analytic rules with almost all the data connections that are possible in Sentinel to make the incident creation process a bit easier. You should check the ‘Rule Templates’ tab to check the available templates at your disposal.
Usage:
While the use case of this feature is pretty straight forward and already explained above, it is important to note that there are multiple types of analytic rules. The most used or the usual one is called as ‘Scheduled Query’ rule. The next type is called ‘NRT query rule’ in which you will not be define the running frequency as it will run in near real time (NRT). The third type is called the ‘Microsoft incident creation rule’ which should be used for any incidents from a Microsoft security product like M365 Defender or Defender for Cloud.
Configuration:
You will have to define some important parameters while deploying an analytic rule like severity, MITRE tactics and techniques (optional), grouping of events and/or alerts generated from those events, suppression rule (if required), automation rule to be run (if required), and the schedule at which to run the query. It is very important to keep these setting optimal and precise in order to get as accurate results as possible.
Recommended Practices:
1. Alert grouping should be defined based on similar entities to reduce the number of incidents and keep the queue much cleaner.
2. The rule logic should be well scoped and tested to ensure less false positives.
3. Query scheduling should always be checked before deploying the rule to make sure that you are not missing on any important events and also not getting too many events from the rule logic.
4. Associating a MITRE tactic and technique with the rule eventually helps in building a more resilient and reliable rule queue ensuring a good attack coverage.
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!
