What is our primary use case?
We use Microsoft Sentinel to monitor many different environments for cybersecurity incidents, and we use it as our main alerting tool to let us know when this activity happens. It also interfaces with all of our other Defender products, such as Defender for Office 365, Defender for Endpoint, et cetera.
Almost all of our solutions are based in Azure. We use Defender for Endpoint, Defender for Office 365, Defender for cloud, Sentinel, and Azure Active Directory Identity Protection.
I use the latest version of Sentinel.
Sentinel is mostly used within our security operations center and our security team. We have about 50 endpoint users.
How has it helped my organization?
The backbone of our organization is built on Microsoft Sentinel, its abilities, and the abilities of our Defender stack. Ideally, we'd have more data, but a lot of data and functionality are in one place. The Lighthouse feature is outside Sentinel, but it allows us to have multiple environments integrated into one and to access lots of different Sentinel environments through that. It's very easy to manage a security workload with Sentinel.
I would like to see better integration with CICD. It should be easier to use GitHub, Jenkins, or whatever our code management stack looks like. Whether or not you use Azure DevOps, being able to manage the code you have is fairly important.
Since using Sentinel, we've experienced a faster response time and easier development features. There aren't as many hurdles to moving a configuration.
I'm not sure how long it took to realize the benefits because it was deployed before my time here. It took me about three months to get familiar with what Sentinel has to offer and how we could leverage it, so it will be about three months before you start getting proper value from it.
There are still elements of Sentinel that I haven't used to their fullest potential, like the Jupyter Notebooks and internet hunting queries.
The solution is good at automating routine tasks and alleviating the burden for analysts.
Automation has moderately affected our security operations, although there is scope for it to significantly affect SecOps. There is definitely the capability for Sentinel to do pretty much all of your first-line response, which would be a significant improvement. It's a moderate effect because we only use automation in a few areas.
There are a few different dashboards for each of the Microsoft tools. We have a dashboard for Defender, one for Sentinel, and one for Active Directory Identity Protection. It consolidated alerts in some aspects, but a lot of information is still scattered.
It's fairly good for being reactive and responding to threats and looking for indicators of compromise. Overall, it helped us prepare for potential threats before they hit.
Sentinel saves us time. The automation feature especially saves us time because we can automate a lot of menial tasks. If other businesses could do that, it would eliminate a lot of their first-line response.
Sentinel saves us about 20 hours per week, which is the equivalent of a part-time staff member.
It saved us money. It's a very cost-efficient SIEM to use and still provides a good level of coverage despite that.
Sentinel saved us about 50% of the cost of Splunk. It decreased our time to detect and respond by about 10-15%.
What is most valuable?
The automation rules and playbooks are the most useful that I've seen. A number of other places segregate the automation and playbook as separate tools, whereas Microsoft is a SIEM and SOAR tool in one.
It provides us with very high visibility. It allows us to see a lot holistically across our environment in Azure. It integrates very well with other products like Defender.
It helps us prioritize threats across our enterprise. There are many things we can do to deal with prioritizing threats, such as having automation rules that automatically raise the priority of certain incidents. We're also able to make changes to the rule sets themselves and say, "I believe this to be a higher priority than is listed in the tool."
Prioritization is probably the most important thing to us because as an organization, we have a number of threats coming in at any moment, and each of them has its own valid investigation path. We need to know which ones are business critical and which ones need to be investigated and either ruled out or remediated as soon as possible. Prioritizing what to work on first is the biggest thing for us.
If you have the right licenses and access to all the products, it's fairly easy to integrate these products into Sentinel. Sometimes they don't pull as much information as possible, and I've noticed that there is a cross-functional issue where these tools will flag and alert themselves.
We can have it configured to create an alert in Microsoft Sentinel, but sometimes it doesn't create a bridge between them. When we finish our investigation and close the ticket on Sentinel, it sometimes doesn't go back to the tool and update that. That's the only issue that I have found with the integration. Everything else is straightforward and works well.
The solutions work natively together to deliver coordinated detection responses across our environment. It's probably one of the better-engineered suites. In other places, I've experienced an endpoint detection and response system that's completely different: proprietary coupled with a proprietary and different SIEM tool or maybe a different sort of tool. They are individual tools, and it can sometimes feel like they're engineered differently, but at the same time, they integrate better than anything else on the market as a suite of tools.
These solutions provide pretty comprehensive threat protection. A lot of them are technology agnostic, so you can have endpoints on Linux and Mac OS. It's pretty comprehensive. There's always a little oversight in any security program where you have to balance the cost of monitoring everything with the risk of having some stuff unmonitored, but that's probably an issue outside of this tool.
It enables us to ingest data from our entire ecosystem. It's difficult to ingest non-native data. It's not as easy as in Splunk because Splunk is probably the leading SIEM tool. If you have a native tool that's out of the Microsoft security stack, you can bring it into Sentinel and have an alert on it.
This ingestion of data is vital for our security operations. It's the driver behind everything we do. We can do threat hunting, but if we don't have logs or data to run queries, then we're pretty much blind. I've worked in places where compliance and regulatory adherence are paramount and having logs, log retention, and evidence of these capabilities is extremely important. One of the more vital things that our organization needs to operate well, is good data.
A lot of the alerts come in from other tools, so sometimes we have to actually use that tool to get the proper information. For example, if we get an alert through Defender for Office 365, to actually see an offending email or attachment or something like that, we have to go into the Defender console and dig that out, which is inconvenient. As an aggregator, it's not bad compared to the other solutions on the market. In an ideal scenario, having more information pulled through in the alerts would be an improvement.
A lot of Sentinel's data is pretty comprehensive. The overarching theme with Sentinel is that it's trying to be a lot of things in one. For a UEBA tool, people will usually have separate tools in their SIEM to do this, or they'll have to build their own complete framework from scratch. Already having it in Sentinel is pretty good, but I think it's just a maturity thing. Over the next few years, as these features get more fleshed out, they will get better and more usable. At the moment, it's a bit difficult to justify dropping a Microsoft-trained UEBA algorithm in an environment where it doesn't have too much information. It's good for information purposes and alerting, but we can't do a lot of automation or remediation on it straight away.
What needs improvement?
Although the integrations are good, it can sometimes be information overload. A number of the technologies run proprietary Microsoft algorithms, like machine learning algorithms and detection algorithms, as well as having out-of-the-box SIEM content developed by Microsoft. As an engineer that focuses on threat detection, it can sometimes be hard to see where all of the detections are coming from. Although the integrations are good, it can sometimes be information overload.
Documentation is the main thing that could be improved. In terms of product usage, the documentation is pretty good, but I'd like a lot more documentation on Kusto Query Language. They could replicate what Splunk has in terms of their query language documentation. Every operator and sub-operator has its own page. It really explains a lot about how to use the operators, what they're good for, and what they're not good for in terms of optimizing CPU usage.
In Splunk, I would like to see some more advanced visualization. There are only some basic ones in Sentinel.
For how long have I used the solution?
I've been using Microsoft Sentinel for about one year, but more heavily over the past five months.
What do I think about the stability of the solution?
It's pretty stable. We don't have any performance or capacity issues with it.
What do I think about the scalability of the solution?
It's scalable when using solutions like Lighthouse.
How are customer service and support?
I haven't needed to use technical support yet, but the documentation in the community is very good.
Which solution did I use previously and why did I switch?
I previously used Splunk. The move to Sentinel was definitely cost-based. A lot of people are moving away from Splunk to a more cost-effective SIEM like Sentinel. We also chose Sentinel because of the ease of maintenance. Splunk's enterprise security has some good queries out of the box, but if I were a small organization, I would use Sentinel because it has more out-of-the-box features.
How was the initial setup?
The log collection facilities must be maintained. Maintaining the solution requires a team of fewer than five people. It mainly involves ensuring that the rules are up to date, the connectors and log collection mechanisms are working correctly, and that they're up to date. It also involves ensuring that the right rules are deployed and the automation rules are in place.
What was our ROI?
Our ROI is 50% over and above what we spend on it in terms of what we can get back from Microsoft Sentinel, everything we use it for, and the time we save.
What's my experience with pricing, setup cost, and licensing?
Some of the licensing models can be a little bit difficult to understand and confusing at times, but overall it's a reasonable licensing model compared to some other SIEMs that charge you a lot per data.
There are additional fees for things like data usage and CPU cycles. When you're developing queries or working on queries, make sure that they're optimized so you don't use as much CPU when they run.
Which other solutions did I evaluate?
We spoke with Google about Chronicle Backstory. It looks pretty powerful, but it wasn't mature enough for what we were looking for at that time.
The only other real standalone solution I've had a good experience with is Splunk and Splunk Phantom. In terms of cost, it's astronomically different. Microsoft Sentinel can sometimes be expensive depending on how many logs you're taking, but it will never be in the same realm as Splunk. Sentinel is easy to use, but Splunk is so expensive because it's very easy to use.
Microsoft Sentinel is a better SOAR solution than Phantom. Phantom has good integrations, but it isn't really built for custom scripting. If you're going to be paying more, you would expect that to be better. Sentinel is better in that aspect. Sentinel's cost-effectiveness blows a lot of other solutions out of the water, especially if you're already in Azure and you can leverage some relationships to bring that cost down.
What other advice do I have?
I would rate this solution eight out of ten. It's heading in the right direction, but it's already pretty good and mature.
If a security colleague said it's better to go with the best-of-breed strategy rather than a single vendor security suite, I would understand that completely. Some people see tying yourself into a single vendor as a vulnerability. It's not quite spread out, but I think you can manage a single vendor security solution if you have a good relationship with the vendor and you really leverage your connections within that business.
It's good to diversify your products and make sure that you have a suite of products available from different companies and that you use the best that's available. In terms of this technology stack, it's pretty good for what it does.
My advice is to really focus on what's possible and what you could do with the SIEM. There are a lot of features that don't get used and maximized for their purpose from day one. It takes a couple of months to properly deploy the solution to full maturity.
Which deployment model are you using for this solution?
Public Cloud
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Microsoft Azure
Disclosure: My company does not have a business relationship with this vendor other than being a customer.