By Jamie Doherty
Microsoft has been making huge strides in the security space and one of those products is Microsoft Sentinel. The beauty of Sentinel is its foundation on Azure’s Log Analytics Platform, but that is also where things get a little hairy. If you want to read in-depth on how the product works, Microsoft has a ton of resources right here: What is Microsoft Sentinel? | Microsoft Docs
That documentation is great and extensive and like every product from a manufacturer or developer only tells a small fraction of the story. SIEM, SOAR, Analytics, Threat Hunting, I could go on and on with keywords and marketing fluff all day but let’s get right to the heart of why you *might* need a Managed Security Services Provider (MSSP) for Microsoft Sentinel.
It isn’t complicated and it’s an old answer – garbage in, garbage out.
The biggest task in Sentinel is also the most underappreciated task: data collection. While most organizations are touting their ability to respond, we focus on our ability to collect the data that matters so that those responses count. Sounds easy, right? Trust me, I wish it was. When the volume of security data trumps actual data by 100:1, it presents a few challenges:
- Cost Yep, it's always there and it will always be a factor. SIEM products are mostly structured around ingestion of data or EPS, but in the end, it is about volume. You can opt to throw everything at it, but the costs might be preventative.
- Machine Learning I’m going to say something controversial here, but I’m done using the term AI until there is actual AI to talk about in IT. It is ML (machine learning) and it most likely will always be. We know there are practical limitations to ML, so we need to understand that you can’t just shove any data type, any data set and expect ML to give you results. This blog is being written in 2021 (just in case anyone decides to refer to this as inaccurate in 2321).
- Response capabilities If you don’t define what’s going in, the automated action options are limited. Sure, you can take alarm data and manipulate it, email it, store it, etc. but you are limiting how deeply you can associate the source to the action.
Microsoft Sentinel has a significant amount of analytics out of the box, with the large majority being “scheduled” analytics. Those are not ML, they are KQL (Kusto Query Language) queries looking for a quantity of events or specific IP’s/domain’s, etc... You can run them yourself, modify them, learn with them amongst other things. R2 has also built a number of custom scheduled queries as part of our MSSP package to help clean the noise that Sentinel brings on its own – or access data sets that Sentinel doesn’t consider to be relevant – yet.
Here is where it gets interesting…Sentinel manages its own “ML” analytics. You turn them on or off, there is no in between. In fact, I can’t really call them all ML because we don’t know exactly what Microsoft is doing behind the scenes (read about one of these types here: https://docs.microsoft.com/en-us/azure/sentinel/fusion). These analytics drive functions with Incidents, Hunting and Automation. Some are interactive, some are purely items we look to automate. This trust in ML, or trust in Microsoft, is what drives our focus on data collection. The absolute best thing we can do is make sure that we feed the ML in a way that yields the best results possible.
Managing ingestion is a full-time job. Software changes, items get reconfigured, new analytics are developed and published and unless you are all over it, you might miss the one moment that you need your SIEM for – a hack.
