GETTING SENTINENTAL:P0
This blog series will be beneficial for those who are planning or already working on getting to learn and know about the first and only cloud based SIEM — Microsoft Sentinel! This will also be much relevant for people who are preparing for the certification SC-200 (Security Operations Analyst) since this certification has the most weightage on Sentinel as a cloud security product.
I am currently in plan to do this in a 3 part series (excluding this part), hopefully covering all that ‘I KNOW’ about this awesome product going from the very basics in P1 to the advanced concepts till P3. I would strongly recommend the readers to go through the entire blog as we will be going through the fundamental concepts and then correlating them with the advanced features that Sentinel offers.
Structure:
You will find this section in every part of the blog series & after going through this section, you will be able to decide whether to proceed forward or not because I will be explaining what can you expect in the coming sections. With that said, let me quickly try to explain what the structure of this part will be:
Ø First we will learn all about the tool category that Sentinel lies in i.e. SIEM (P0.S1).
Ø Next up will be, what exactly a SIEM is supposed to do and how it does that (P0.S2).
Ø Next, we will try to understand what should we expect from a SIEM (P0.S3).
Ø What should be the best practices to establish a SIEM solution (P0.S4).
Ø And finally we will look at what SOAR is (P0.S5)!
P0.S1 (Part0.Section1)
SIEM abbreviation for Security Incident & Event Management is a cybersecurity tool that is designed to analyze events, logs and activities associated with users, devices and resources (cloud/on-prem) to detect any malicious attack patterns and/or a security breach. It is actually a combination of two (used to be) different products Security Information Management (SIM) & Security Event Management (SEM)! Pretty obvious, right?
But that’s not it, SIEM is the official tool to create, manage and investigate incidents/alerts. These incidents are an indication (not affirmation) that a suspicious activity has happened and might lead to a breach or attack. Now please note that SIEM is calling the activity ‘suspicious’ and not ‘malicious’ because it’s the job of a security analyst to investigate and confirm that is the activity indeed a threat or just a ‘False Positive’.
There is a lot to know about SIEMs but since our focus is Sentinel, this introduction should be enough to make you understand about the tool category.
P0.S2 (Part0.Section2)
SIEMs are supposed to collect data from various sources like user accounts, devices, cloud resources (databases, virtual machines, storage accounts, web apps etc.), firewalls, AVs/AMs etc. and correlate them to identify any abnormal activities or even activities that seems normal but are not secure. Once found, SIEMs produces alerts and incidents to notify these patterns to security team with as much information as possible.
SIEMs ingest, aggregate, normalize the data provided to them from various sources and then analyze them as per the use case rules defined by security analysts. Yes, that’s right, for a SIEM to identify and detect attack patterns, the security admins (us) will need to define logical rules understandable by the detection engine. Almost all SIEM vendors provides some OOTB rules as well to get started.
For example, you may define a rule to detect multiple failed login activities from specific (or all) user accounts within a specific timeframe, say 10 mins. For this, the SIEM will analyze the login activity data source, let’s say Azure AD, and check the failed logic activities through the event IDs in the past 10 mins. If found to be within the threshold, it will generate an incident including all the relevant details like user name, device, IP, location, timestamp and other details depending on the other related data sources.
P0.S3 (Part0.Section3)
From the explanation in the previous sections, you will also agree with me when I say that one should expect that much from a SIEM as much data sources and detection logic is provided to it. While the data sources part is majorly the responsibility of the vendor, the detection logic should be entirely decided and defined by the organization employing the SIEM. Now here, I am including the OOTB rules that a vendor has to offer, because all those rules might not be useful for your infrastructure and might end up creating nothing better than ‘noise’ in the SOC environment deviating your analysts from actual detections.
But still, what should you expect from a SIEM? Because the above was not really the answer, right?
The obvious expectation will be to get a precise correlation of logs to detect threats but a bigger expectation would be to get those detections as fast as possible or in other words, in real time. To be honest, the correct word should be in near-real-time. This is a fair expectation because nobody would want to be notified of a breach after 2–3 hours of the event.
The other expectation would be to get as much details as possible in the incident to provide a boost to the investigation. This is where the efficiency and reliability of a SIEM is tested on how well it can correlate the information from various data sources and normalize it to be presented as an evidence in an incident.
A SIEM should also be able to have knowledge of the current threats and their indicators so that if any user or device within your organization is found to be interacting with these indicators, a detection rule can detect it and inform the analyst in near-real-time. These kind of detections usually proves to be ‘True Positives’ because they involve an evidence that is already defined to be ‘malicious’. Remember my point from P0.S1?
SIEMs should provide options to automatically respond to incidents, right?
WRONG! Because that’s what SOARs do and we will get to know them is P0.S5.
P0.S4 (Part0.Section4)
Before discussing the best practices, please note that although these are recommended but that does not mean that they ‘will’ be applicable to your organization. Hence, you should adopt only those which checks the boxes of your needs and does not disrupt the functioning of your cloud estate.
1. The first recommendation is to create a deployment plan for the SIEM involving the important stakeholders, administrators, and security professionals considering the current (and probably the near future) infrastructure, it’s dependencies and most importantly the cost involved.
2. The next recommendation will be included in the first one but is important enough to be defined separately. You should choose your data sources carefully. Not every resource needs to send data to a SIEM. This is a very important consideration as messing up this will not only result in unnecessary cost but it may also result in irrelevant information being presented or important one being missed. You should also monitor these data sources over time for anomalies in their data sending rate.
3. The detection rules should not be either too restrictive to result into false positives (example: 3–4 login failures within an hour being reported as suspicious) neither too lenient to neglect a true detection (example: considering 10–15 login failures within 30 minutes as normal).
4. It is recommended to give your SIEM a test run for a few weeks and monitor the consistency of its detections. This way you will comes to know if you need to add/remove data sources and/or if you need to define new or update existing detection rules.
5. It is highly recommended to document your incident response plan especially for critical detection scenarios. This includes some important aspects like defining SLAs for various severities, SOP for initial troubleshooting, establishing war rooms for collaboration etc.
6. Categorizing incidents as either ‘True Positive’, ‘False Positive’ or ‘Benign Positive’ is a recommended best practice as it not only helps in handling similar future incidents but also helps SIEMs to rectify their detection logic (basically help learning them from their mistakes).
7. It is recommended to monitor, track and analyze the overall MTTD (Mean Time To Detect) and MTTR (Mean Time To Repair/Resolve/Recover) of your SOC operations over time that can help to reduce the reaction time to incidents.
8. Once a incident is found to be true positive, it is a recommended practice to add the involved evidences and/or artifacts in your organization’s threat intelligence directory & ensure that analysts are alarmed if they appear in any future incidents again.
P0.S5 (Part0.Section5)
I’ve already told you in P0.S3 that why do we need to know about SOAR. Security Orchestration and Automated Response is a tool designed to define automated actions in standard defined response to incidents which may help in responding and ultimately, containing the attack.
I’ll try to break the abbreviation of SOAR and explain what it actually does and how does it do that:
Ø Orchestration:
This means that a SOAR integrates different internal and external tools like firewalls, vulnerability scanners, EDRs, IDS/IPS, SIEMs etc. via built-in or custom integration methods and gathers data from these sources to perform response actions.
Ø Automation:
The data received from orchestration is then used to create pre-defined repeated processes. The main idea is to automate the repeated manual processes thus reducing the mean time to respond.
Ø Response:
Security response offers a single view for analysts into the planning, managing, monitoring and reporting of actions carried out after a threat is detected. It also includes post-incident response activities, such as case management and reporting.
& like that we have reached the end of Part 0! Hope you learned something valuable and worth your time! If so, 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!
