On February 28, Microsoft announced the public preview of Azure Sentinel. Somewhat simplistically stated, you could see Sentinel as Microsoft’s version of a SIEM (in the cloud).
Although the idea of a SIEM solutions (Security Information & Event Management), nor the availability thereof is something new (there’s plenty out there), I’m still very excited to see Microsoft come up with a solution in this area. One of the reasons I’m thrilled is because of the challenges I see with integrating 3rd-party SIEM solutions with “the cloud”.
A successful security strategy consists of many layers. One of those layers also includes monitoring security events and responding to them appropriately. Amongst other things, monitoring such events is typically part of what is called “SecOps” these days.
To be successful at monitoring security events and incidents, you not only need a lot of information (from various sources like the network infrastructure, user endpoints, etc.), but you also need to make sense of the information you have. The ability to quickly aggregate, correlate and analyze information in order to provide meaningful insights is what makes a SIEM solution good (or bad). Unfortunately getting to a point where your SIEM solution provides you all these insights can take up quit ea bit of time.
Today, there are a couple of well-known players in the SIEM market. For example, LogRythm, Splunk, and ArcSight are some solutions that you commonly encounter. And they can all ingest information from Office 365 to some degree. So, why am I excited about Azure Sentinel then? Well, one of the challenges I see with existing SIEM solutions is they lack the (native) capability to ingest information from various online sources (like in Office 365), and by extension online services in general is a bit of a challenge for traditional SIEM solutions. If not for ingesting the data, there aren’t always great dashboards/insights or queries readily available to correlate information and provide meaningful output to the SecOps engineer.
One of the biggest benefits of using Azure Sentinel is its native integration with the various data sources; no more fiddling around with service accounts etc. in order to get the right data. The fact that it’s so integrated with Microsoft’s online services is what makes it so powerful. In fact, that is the beauty of Microsoft’s overall security offering they have an end-to-end offering which integrates neatly with all components in the chain. Not just Office 365, also Azure Virtual Machines etc. And whilst individual solutions might be better as specific tasks, Microsoft’s solutions score better when looking at the end-to-end perspective, in my opinion. But that’s for another blog post.
At time of writing, the following data sources (both internal and external to Microsoft’s Online services) were available:
Like other solutions, analyzing ingested information can be done through the help of Machine Learning. Under the hood, events and other information are stored in an Azure Log Analytics workspace. From there, Microsoft offers various built-in dashboards that help visualize data from the environment. Of course, you can build your own queries and dashboards should you feel the need. The latter would be especially true if you have specific use cases or reports you’d like to see which aren’t part of the built-in dashboards. Although the list of data sources might seem limited at first, I love the fact there’s already support for a variety of external sources like some very common vendors like Cisco, Fortinet, CheckPoint etc. After all: a lot of the important events you need to hunt for threats come from your networking appliances etc.
Update: Another great feature of Sentinel is the ability to stream activity logs from various Office 365 tenants. Although technically doable in other solutions as well (using multiple accounts), it’s a lot easier in Sentinel and definitely aids customers that have multiple tenants and want/need to consolidate information.
Like WDATP, Azure Sentinel offers the ability to “hunt” for specific threats: you can build your own queries across the connected sources to find specific information or correlate relevant events and detect patterns which may indicate a breach or (ongoing) attack.
Last, but not least, Azure Sentinel also can manage alerts and incidents in true “SecOps” style. Alerts can be turned into cases which, in turn, can be managed for further follow-op. Investigating open alerts (or cases) will require some manual work. In the future, however, you should be able to get some visual aid from the investigation graph (still in private preview at this time).
Integrating a SIEM solution with Microsoft 365 isn’t new. Whilst some solutions can pull data from the Management Activity API, another option was to use MCAS which has the (native) capability to export information through its SIEM connector. Azure Sentinel, however, sets itself apart from MCAS in that it can not only aggregate information from various Microsoft sources, but also extends outside of its own realm, with more data collectors (sources) to follow in the future.
All-in-all, Azure Sentinel is a great way to start with “SecOps” (call it SecOps “light” if you will). If you already have a well-established SecOps team and are using a SIEM solution, adding Azure Sentinel might not be desirable because you – ideally – want to keep your data in a single location. This doesn’t mean it can’t prove valuable. Because of the ML-based analytics, and its native integrations, Sentinel is a lot easier to operate, and I can see how it could quickly become a replacement for an existing solutions –provided that 1) the costs are reasonable (free in preview) and Microsoft continues to add more data connectors.