Microsoft Sentinel Reviews

It is a tool for compliance for us. Every department and agency in the government is trying to get to the cloud as fast as they can. Because of that, there's a lot of SA&A work—service authorization and accreditation. In that, you're assessing the environment against a set of controls. We use Sentinel to provide us with a core piece of evidence that ensures these environments are compliant.

If you know how to do KQL (kusto query language) queries, which are how you query the log data inside Sentinel, the information is pretty rich. You can get down to a good level of detail regarding event information or notifications. It's all about how detailed and accurate your queries need to be and what log sources you are actually ingesting log information from. Sentinel is that central piece that allows you to correlate security events across your Azure environment. It's a pretty critical piece of the puzzle.

You can create both custom connectors as well as use the canned connectors that Sentinel ships with. When you start the service, those connectors will look at on-prem log sources and ingest them. So Sentinel works both in the cloud and on-prem.

There is some relatively advanced knowledge that you have to have to properly leverage Sentinel's full capabilities. I'm thinking about things like the creation of workbooks, how you do threat-hunting, and the kinds of notifications you're getting. There are a lot of pieces in motion with Sentinel to use it effectively. It takes time for people to ramp up on that and develop a familiarity or expertise with it.

Does it need to be simplified? There is that old saying: "The simpler the front end, the more complex the back end." A novice would probably not be able to effectively use Sentinel unless they were able to ramp up pretty quickly on a lot of its functionality. You need to understand the interfaces and all the components that are part and parcel of the service.

I've been involved with Sentinel since early 2018. Sentinel was only acquired by Microsoft four or five years ago.

I own a professional services company and I do a lot of government consulting and engineering work for clients. I've had good exposure to Microsoft technology, whether through their support services, or through Azure, or through a myriad of on-prem solutions as well. My partnership efforts have really been around AWS because, outside of government, AWS has a far larger footprint than Microsoft, as far as the cloud is concerned.

The stability of Sentinel is fine, as long as those who are configuring the service and using it have a good grasp of its operational nature. It takes time to develop that knowledge, but it's a pretty stable service.

Microsoft has a service called FastTrack, which basically pairs my clients up with a local Microsoft partner. That FastTrack partner is the intermediary between the client and Microsoft. If there's a problem or a support issue, that partner will typically be the client-facing entity.

Larger departments will purchase Premium Support and that provides them with a more face-to-face support experience with Microsoft personnel, specifically. Many of my clients are larger departments and, generally speaking, there is pretty good support in place for them from Microsoft.

Most clients are looking at getting E5 licensing, which opens up a whole bunch of security features and support services. But E5 licensing is pretty darn expensive. So bigger departments with bigger pockets have a very good support experience with Microsoft. The smaller departments, which may need to take advantage of services like FastTrack, assuming that the Microsoft partner has good resources available, may not have a problem at all. But I have heard some feedback that FastTrack is not a great program. Support is only as good as the weakest link in the chain.

My job as a consultant is to work with many different departments and agencies, whether it's on their architecture or assessing their environments, as they all move to the cloud. I've seen many different environments and a lot of them have some common overlaps in terms of security services. Sentinel can be expensive. When you ingest data from sources that are outside of the cloud, you're paying a fair amount for that data ingestion. When you're ingesting data sources from within the cloud, depending on what your retention periods are, it's not that expensive. For certain customers, depending on the requirements, it can be a pricey service.

Personally, I like the tool. From a SOC perspective, the visibility into government operations in particular is key, and I'm seeing a lot of advanced usage of it for some of my clients.

The federal government, here in Canada, has primarily centralized on Azure as opposed to AWS. That's because most of these departments also have SaaS environments that are M365-centric. As a result, because they are already Microsoft on the SaaS side, a lot of departments maintain that Microsoft synergy, even if, in my opinion, AWS is a better platform.

As a cloud SIEM, I would rate Sentinel at an eight out of 10. The only reason I'm not ranking it higher is that, as I said, there is some complexity with it. You have to tweak the service to get the outputs you want, by doing things like creating workbooks or rules for Sentinel, doing the threat-hunting, setting up the connectors, the log analytics, and workspaces. There's a lot of "heavy lifting" done to get Sentinel into a state where you can effectively use it. But as far as the actual outputs are concerned, if you know what you're doing with the queries, Sentinel is a great tool.

Microsoft offers training around Sentinel. In our region, among the support guys that deal with the government departments and agencies, there are some Sentinel subject matter experts available. And when more advanced knowledge is needed, Microsoft can provide what are called "support ninjas." They have more advanced knowledge and can be flown in from wherever. There are a lot of opportunities to learn how to properly use Sentinel's tools. Once you get that familiarity, Sentinel is a valuable tool for your cloud security posture.

On Azure, we have workloads on virtual machines, Kubernetes clusters, and SQL Servers. The way Sentinel works is that logs from our Kubernetes services, virtual machines, and database servers go into what is called Log Analytics on Azure. Log Analytics connects to Azure Sentinel, then all the logs move from the resources to Log Analytics down to Sentinel. Sentinel is configured to do some form of threat detection on these logs. For example, there is a firewall log connected to Log Analytics. Sentinel looks at those firewall logs for repeated IPs that are trying to either do an attack on our system or get access into our system. There is some form of machine learning and AI implemented in it to be able to tell us which particular IP address is trying to do this. 

It is mainly used for securing our platform. As the infrastructure person who works on it, I have some automated ways of seeing threats. We have seen a few possible issues that might come up. So, our customers are safe on some level when we are using Sentinel.

It improves our security posture by using automated threat detection.

Having your logs put all in one place with machine learning working on those logs is a good feature. I don't need to start thinking, "Where are my logs?" My logs are in a centralized repository, like Log Analytics, which is why you can't use Sentinel without Log Analytics. Having all those logs in one place is an advantage. 

We have not really had any major threats. We have had alarms about four times. In the end, they were false positive alarms. Over time, the machine learning feature understands that something is a false positive, then you don't see them anymore. So, it reduces the number of false positives.

The learning curve could be improved. I am still learning it. We were able to implement the basic features to get them up and running, but there are still so many things that I don't know about all its features. They have a lot of features that we have not been able to use or apply. If they could work on reducing the solution's learning curve, that would be good. While there is a training course held by Microsoft to learn more about this solution, there is a cost associated with it. 

We have been using it in our organization for six months.

It is quite stable. It is one of the most mature SIEM solutions that I know.

Currently, I am the person maintaining the solution since we are a startup. However, it probably needs a team of four people to work on it. It needs an infrastructure person to configure it, a security analyst to tell us what they want configured, and a business person to tell us what kind of security targets are needed.

Scalability is good. We are increasing usage for different use cases. For compliance reasons, we will probably expand usage in the future.

Also, there are a lot of features that we have still not tested.

I have not had to use the technical support yet.

We were starting from scratch with Azure Sentinel.

We started using it because we were trying to get PCI certified. The updated PCI requirements requested that we have a security information and event management tool. If it wasn't for PCI compliance, then we probably would not have used Sentinel.

The initial setup was complex, not straightforward. Connecting it is easy once you have an Azure resource on the cloud. We also have on-prem resources, but we have not been able to connect those. Trying to create your on-prem resource with Azure Sentinel is not straightforward. I have not seen many implementation videos that I can watch on YouTube to learn how to do it. 

It is not just Azure. Other SIEMs solutions are a bit complex when trying to connect them. 

Deployment took no more than 10 minutes. Configuring it in our workloads was the major issue, not the deployment. The configuration timeframe depends on the number of resources that you are connected to and your prior knowledge of Sentinel before starting your configuration. 

I did the deployment.

From a cost perspective, there are certain Azure resources that we don't need to additionally pay for when using Sentinel.

When we looked at other SIEM tools, they were quite expensive. Sentinel is also expensive for a startup, but we were able to configure it so there are some logs that Azure frees up, like your firewall, Office 365, or Kubernetes logs. From a cost perspective, this works well financially for us.

Sentinel is a bit expensive. If you can figure a way of configuring it to meet your needs, then you can find a way around the cost.

We looked at so many tools, like Elastic Search and IBM. We went with Sentinel because the majority of our workloads were on Azure already, so the integration was easier rather than going with something external and integrating it. 

If you are purely on Azure, Sentinel is the way to go. Also, it easily works with on-premise workloads from what I have been able to determine. When I look at connectors, it integrates with other cloud providers. I see it integrates with GCP. 

I would rate Sentinel as seven out of 10.

We internally do not use this solution. We provide advisory for Azure Sentinel because we are Microsoft's partner.

Our clients use it for Security Operations Centers. Some of the clients wish to build a Security Operation Center. They want to perform threat analysis and see that the environment is secure and monitor it. That's why we deploy SIEM solutions.

In terms of deployment, what we see here in Asia, specifically in Malaysia, are hybrid and public cloud deployments.

It helps our clients in enhancing their security. 

It is quite efficient. It helps our clients in identifying their security issues and respond quickly. Our clients want to automate incident response and all those things.

Its documentation is not so simple. It is easy for somebody who is Microsoft certified or more closely attached to Microsoft solutions. It is not easy for those who are working on open-source platforms. There isn't a central point where everything is documented, and there is no specific training or certification.

It has been almost three years.

It is stable. Those who have adopted it are okay with it.

It is a cloud solution, so it is scalable.

Most of us know how Microsoft operates. They are quite good at that.

Its setup is of moderate complexity for me, but I have heard it is complex for others because of the query language and other things.

There is documentation, but I don't think Microsoft is providing a central point where everything is documented. In fact, there is no specific training or certification. There is Microsoft Secure training, but it is not so dedicated. All these things make it moderate.

I have had mixed feedback. At one point, I heard a client say that it sometimes seems more expensive. Most of the clients are on Office 365 or M365, and they are forced to take Azure SIEM because of the integration.

We see that a lot of clients are trying to explore more apart from Azure. Some of the clients are interested in Splunk. Some of the clients are interested in seeing what's available from AWS. This year is quite different in Malaysia because the government has opened up the adoption of public cloud in all sectors, especially in the financial sector. So, we are seeing new requirements coming up. 

I would rate Azure Sentinel a seven out of 10.

We are running an MDR service for our customers and use Azure Sentinel as the SIEM product to allow us to have an overview of all our customers, but also to easily push configurations to different customers.

We use Azure Sentinel as an alert aggregator to import all of the incidents/alerts from the different (Microsoft) security products in order to have a single pane of glass. On top of that, we create our own custom Analytics Rule that can be used to add our own added value. This enables us to create our own IP to protect customers. 

It's really convenient for us to aggregate the logs/alerts from all our customers into a single pane of glass. By using the automation capabilities, it's relatively easy to sync all incidents to our ITSM tool which we can use to follow up on incidents. As it's based on the Microsoft stack, it's convenient for our engineers to learn the product. As Azure Sentinel is also a big focus for Microsoft, we have the ability to work with them on certain products. This creates visibility within the community and for new customers.

There are three valuable aspects of the solution: MSSP support, integration with Microsoft, and Automation. By using Azure Lighthouse, an MSSP can easily integrate their applications into their own baseline of policies/configurations.

Because Sentinel is built as an MS-first product, it integrates natively with other Microsoft products, which is really convenient as we are standardized on it. Without much work, you can connect any Microsoft product to it. 

Last, but not least, Sentinel uses Azure Logic Apps for automation, which is really powerful. This allows us to easily automate responses to incidents.

Azure Sentinel is constantly growing. Throughout the two years we have been using it, we have seen it expand tremendously. A lot of the limitations we had originally seen have already been mitigated. A couple of potential improvements could be: allow for a streamlined CI/CD procedure. Now it's a combination of using API/Powershell and ARM which is not ideal. Also, it should allow us to ingest on-prem logs by using a SaaS platform to ingest CEF/Syslog logs that also allow for prefiltering. This would allow us to minimize the cost of the solution.

I've been using the solution for 1.5 years.

We didn't use another SIEM product before Azure Sentinel. 

The cost can be a little confusing at first, but the Azure calculator is a great place to start. I would advise to start with integrating Microsoft products first, as this is the most convenient way forward and allows you to learn the product as you go.

In general, Azure Sentinel can be set up really quickly.

We use this solution for analyzing Microsoft cloud-based log services and for security data. The services include Microsoft 365, Azure Security Center logs and Microsoft cache logs. We are gold security partners with Azure. 

The UI-based analytics are excellent, it's something I haven't seen with any other SIEM products. Microsoft has excellent tools for cleaning data, sorting out irrelevant log data and even fixing log data.

There's not much that needs improvement but the on-prem log sources still require a lot of development. It's clear that there are limitations there. I also think that the implementation and on-prem data sources could be done in a better way. We've used some functions with Python and whole scripting on FortiSIEM, which is something that Microsoft could easily provide, but so far hasn't.

The product has been very reliable. I don't know that there have been any service outbreaks. We haven't had any problems. 

We have 700 users and from our perspective, it has unlimited processing power, but this is quite common for cloud services. I think the scalability has to be some kind of ABM and feeding all of the log stats, which could possibly have limits, but Azure has huge computing power behind it.

The support is good, the only issue is getting past the level one people who ask if you've tried rebooting. If you have Microsoft's Unified Support, the most expensive support, then you'll be very happy. It's not the best support in the industry, but it's pretty good and they also support Sentinel. 

The initial setup was extremely straightforward. It was the easiest I have seen because it's an SaaS service. I think anybody can do it by just clicking and clicking and saying yes. Straight out of the box and that's the strength of the SaaS service because there's no installation, you just use it. 

We compared Azure to Splunk and to our current mainstream implementation, FortiSIEM. If you have a lot of security data, then you feel that Azure is quite expensive but it's nowhere near as costly as Splunk which is four or five times more expensive. FortiSIEM wasn't good enough and Splunk was way to expensive. 

I would definitely recommend this solution. If you have cloud-based workloads and different cloud or cloud lookalike services that require security data, or if you are looking for SOAR functionalities, then it's a no brainer. It's the best in that market. On the other hand, if you are mainly working and operating with on-prem stuff then there's no advantage over FortiSIEM or other solutions. 

I rate this solution a nine out of 10. 

Security incident and event management. Threat detection and automated response.

It is a software as a service from Microsoft.

Reduced mean time to detect and resolve

Quickly able to cover a majority of mitre att&ck techniques

Free to ingest Azure logs with E5 license

Free ingestion for Azure logs (with E5 licence)

It is easy to implement (turn on) - does need a skilled analyst to develop queries and playbooks.

It has basic out-of-the-box integrations with multiple log sources.

Add more out-of-the-box connectors with other SaaS platforms/applications.

12 months

No stability issues encountered.

It is scalable as a SaaS offering, but there is a consumption cost to consider.

Cybersecurity team uses this on a daily basis.

We work together very well with local MS Team.

The initial setup was simple. All that was needed was to put agents onto our infrastructure.

Integration more complex for non-MS SaaS and OS, but do-able using middleware.

It was done in-house.

It is an evergreen service.

What is the cost of lack of visibility?  Average cost of breach = $$$

It is a consumption-based license model. bands at 100, 200, 400 GB per day etc. Azure Sentinel Pricing | Microsoft Azure

Good monthly operational cost model for the detection and response outcomes delivered, M365 logs don't count toward the limits which is a good benefit.

Others were considered however being an E5 M365 and Azure user this was by far the preferred solution.

It is fairly new but making a charge up the market anayses.  Should be considered if you have E5 licence due to native and 'free' ingestion of M365 logs.

We haven't used all of its capability yet because we haven't had the time yet to implement it all, and it appears that the MS roadmap for Sentinel is being actively invested in.

We primarily use the solution for security operations. 

It has a lot of great features. 

The integrations on offer are very good. They have a lot of frequent updates on the integrations as well. 

We also use other Microsoft products with it, such as Active Directory and Defender for Endpoint and Identity. Everything is well integrated together. The integration itself is seamless.

Its connectors are helpful.

We get good logs from the solution.

Threat visibility is good so far. We are able to prioritize threats based on many factors.

The comprehensiveness of the solution is good. 

The alert response could be better. We'd also like a better ticketing system, which is older.

I've been using the solution for two years.

I'd rate the solution nine out of ten.

It is for tracking the logs. I'm working on automation. So, the use case basically includes logs, incidents, automation, UEBA, and endpoint integration with Office 365 Defender.

We didn't have anything similar. So, it really provides value from the incidents and automation point of view. The overview of the security fabric is most valuable.

Its implementation could be simpler. It is not really simple or straightforward. It is in the middle. Sometimes, connectors are a little bit complex. 

I just started using it. I have just set it up.

It is stable.

It is scalable.

I haven't dealt with Microsoft's tech support. I haven't reached out to them.

It was of medium complexity. It wasn't too bad, but it can be complex because of the connectors.

I don't know yet because they gave us a 30-day test window for free. 

Because it is mainly artificial intelligence and machine learning, you would need some time to learn it. It is a good solution, and it is straightforward.

I would rate it a six out of 10. I haven't really dealt with other ones.