Microsoft Sentinel Reviews

Our use cases range from more complex configurations, looking at things like playbooks, workbooks, and threat-hunting, for which we rolled out architectures in some departments in the Government of Canada, to a more streamlined functionality and looking at things from a correlation perspective. 

We work in tandem with a couple of departments that have products called cloud sensors and those sensors feed telemetry into Sentinel. In its simplest form, we're using it for the ingestion of all that telemetry and looking for anomalies.

The anomalous behavior can include anonymous IPs and geolocation that might indicate bad actors are trying to access a system. If I'm located in Ottawa, Ontario and somebody from Russia is trying to access our tenant, that's going to be pretty suspicious.

Just like the US government has FedRAMP, there is a similar approach, here, for the Government of Canada where the funding for projects takes a cloud-first approach. Most of the departments in the government are now on some kind of cloud journey. When I look at the various projects I've worked on, every single one, to some degree, has an IaaS in Azure environment, and most of those deployments incorporate Sentinel and the log analytics workspace into the solution.

Sentinel helps automate the finding of important alerts as well as routine tasks. When your KQL queries are well-defined, and your threat hunting becomes more routine for parsing through a volume of ingested information, it becomes more of an established process. There would likely be some kind of documentation or procedures for how Sentinel would be managed. The idea is to catch any threat before it actually impacts your organization. Using Sentinel workbooks and playbooks and doing threat-hunting to find things before they actually affect a particular system is the optimal approach. It may depend on the size of the team that is supporting the tool and the knowledge level required to appropriately configure the tool.

I have one department that has quite a mature and robust Sentinel implementation, and they are absolutely doing that. They're using threat-hunting and the ability to create rules to be proactive.

A fully functioning Sentinel system configured properly so that you're doing advanced threat-hunting and trying to catch malware and other kinds of attacks before they impact your systems, could result in enormous cost savings if you're able to identify threats before they actually impact you. I'm sure that Sentinel has saved money for most departments in terms of forensic, digital investigations. But it would be hard for me to put a dollar figure on that. As the Government of Canada is becoming more capable of managing this system, the ability to leverage all of the bells and whistles to help to create a better security posture, and to catch things in advance, will absolutely result in dollar savings.

Similarly, for time to detection, a fully deployed Sentinel system that is properly managed and has a good, robust configuration, would absolutely save time in terms of pinpointing systems where a problem may exist, and employing alternative tools to do scans and configure reviews. But specific savings would depend on the department, the size of the team, and the configuration of the tool.

There are some very powerful features in Sentinel, such as the integration of various connectors. We have a lot of departments that use both IaaS and SaaS services, including M365 as well as Azure services. The ability to leverage connectors into these environments allows for large-scale data injection. We can then use KQL (Kusto Query Language) queries. It queries the telemetry for anomalies. The ability to parse out that information and do specific queries on it, and look for very specific things, is quite a valuable function.

The large-scale data ingestion and the ability to use KQL queries to establish connectors into various data sources provide very expansive visibility. With playbooks into which you incorporate rules, you can be very granular or specific about what you're looking for. It provides a great deal of visibility into that telemetry coming in from various services across your tenant.

In terms of data ingestion from an entire ecosystem, there might be some services for which Microsoft has not built a connector yet for Sentinel. But for most of the major services within Azure, including M365, those connectors do exist. That's a critical piece. As a SIEM, the way that it identifies anything anomalous is by correlating all those sources and searching the telemetry for anomalies. It's critical to ensure that you can ingest all that information and correlate it accordingly.

The comprehensiveness of Sentinel's security protection is highly effective and it scales well. It has the ability to do automated responses that are based on rules and on Sentinel's ability to learn more about the environment. The AI piece allows for behavioral and learning processes to take place, but the underlying logic is in the rules that you create via playbooks and workbooks. That whole functionality is highly effective, as long as you have good KQL literacy, how your alerts are configured, and where your alerts are configured. Are they via email or SMS? There are a lot of variables for how you want or expect Sentinel to behave. It's quite a comprehensive architecture to make sure that you've got all those pieces in place. When configured properly, Sentinel is a very powerful tool, and it's very beneficial.

My only complaint about Sentinel has to do with how you leverage queries. If you have good knowledge of KQL, things are fine. But if you're looking to use canned queries, the interface could be a little more straightforward. It's not immediately intuitive regarding how you use it. You have to take a canned query and paste it into an operational box and then you hit a button. Then it does the analysis of the telemetry. If things could be improved anywhere, it might be there. They could improve the ease of deploying these queries.

I have been using Sentinel since 2018.

Sentinel is very good if you have the right support tier in place. If you don't have the right support tier, then it can become quite laborious to find a technician who is knowledgeable, because the tier-one support might be out-of-country. You have to pay for the ability to get to a senior guy who is quite knowledgeable. That's an area of cost that may be impactful to the proper operation of the tool itself. But when you do talk to somebody who's knowledgeable, it's great.

It's expensive, but it's beneficial.

Because of the way that the Government of Canada allows access to the Azure marketplace, we don't typically employ other cloud SIEMs. However, many departments of the government use on-prem SIEMs. When I consider the licensing and the functionality for those on-prem SIEMs, Sentinel is fairly pricey. That being said, for an Azure tenant, it's really the only game in town, unless you're pulling in information or you're exporting information from Sentinel to a third-party source on-prem for further analysis or storage.

Cost-wise, Sentinel is based on the volume of information being ingested, so it can be quite pricey. The ability to use strategies to control what data is being ingested is important.

Because it's expensive, I've seen other departments that have on-prem SIEMs that reanalyze telemetry that is exported from the Azure cloud. It's not like-for-like, though.

Many organizations leverage the MITRE ATT&CK framework. Within MITRE there are all kinds of tactics that could be brought to bear on any unsuspecting department or target. Or they align with something like OWASP. But with Sentinel, you're able to delineate what categories you want to prioritize. For anything web-based, because everything is based on APIs and is based on a web interface, you might want to prioritize OWASP-based threats. But if you look at things like APTs, advanced, persistent threats, and various bad actors that MITRE categorizes, that gives you a really good source of information in terms of what to prioritize.

There are a lot of Microsoft security products: Defender for Cloud, Security Center, Azure Monitor. On the SaaS side, we leverage Compliance Manager. And within the dashboards for M365, you've got the ability to leverage policies. For some clients I've worked on, we have things like DLP policies, to prevent unauthorized exfiltration of data. But for IaaS, where Azure typically resides, Defender for Cloud is a big one.

With the use of connectors, if you're looking to provide data telemetry from various services back into Sentinel to do threat-hunting, it is quite a straightforward process. If you're looking to look at things like logging and auditing and how storage accounts integrate, that's a bit more complex, but it's not rocket science. It's certainly quite feasible.

Because they're all services incorporated into Azure, and into IaaS from a broader perspective, there's fairly straightforward integration. Everything is API driven. As long as you can take advantage of that within your dashboard and your admin center, you can enable them very simply through that. If you're looking for historical data through login auditing, it's a matter of parsing through some of that information to get some of those key nuggets of information. But the broader ability to spin up a bunch of services through Azure and have them communicate and work together to build a better security posture is very straightforward.

Cloud platforms, whether Microsoft or AWS or Google, are always in flux. There are always services coming down the line, as well as updates or upgrades, and refinements to these services. Very rarely do you find a static service. When I look at the comprehensiveness of Sentinel from when I started to use it back in 2018 and through to early 2023, there have been a fair number of changes to the functionality of the tool. There are more connectors coming online all the time. It's evolving to make it more and more comprehensive in terms of what kind of information you can pull into Sentinel. It's more and more comprehensive as time goes on; the tool just improves.

Microsoft Defender for Cloud's bi-directional sync capabilities are important in the following way. If you have an issue that shows in Defender for Cloud, an incident on your dashboard, and you look into Sentinel and see the same alert has been triggered, after someone on your team looks into it and fixes it, if bi-directional is not enabled, you will still have the alert showing. If someone is looking at the Defender for Cloud dashboard, that alert will still show as active. That's why it's important to have bi-directional sync. It helps make sure that people work on the right cases.

Sentinel enables you to investigate threats and respond holistically in one place. It gives you a central repository where you can have a historical view and see the access point where something started, where it went, and how things were accessed. For instance, if someone was anomalously accessing keywords, with everything in one place you can see where it started, where it went, who was involved in it, what kind of endpoints were involved, what IP address was involved, and what devices were involved. In this way, you have complete historical data to investigate the root cause.

Previously, I worked with a number of different tools to pull the data. But having one pane of glass has obviously helped. When you consider the time it takes to go into each and every dashboard and look into alerts, and take the necessary actions, Sentinel saves me a minimum of 15 minutes for each dashboard. If you have three to four dashboards altogether, it saves you around one hour.

And when it comes to automating routine tasks, if you want to notify the right people so that they can look into a P-1 incident, for example, Sentinel can automatically tag the respective SOC or security incident teams through a team chart and they can directly jump into a call.

Another point to consider is multi-stage attack detection. We have a granular view into the incident. We can investigate which IPs, user entities, and endpoints are involved in the alert. If you have to look at multiple, separate points, it could take one hour to see what happened at a particular point in time. With Sentinel, we can directly look into a certain person and points and that saves a lot of time. And then we can take action on the incident.

Among the valuable features of Sentinel are that it 

• has seamless integration with Azure native tools 
• has out-of-the-box data connectors available
• is user-friendly
• is being expanded with more updates.

The visibility into threats that the solution provides is pretty good. We can see a live attack if something is going wrong; we can see the live data in Sentinel.

I work on the complete Azure/Microsoft stack. With Azure native, we can integrate the various products in a few clicks. It doesn't require configuring a server, pulling of logs, or other heavy work. It's very easy, plug-and-play. The data collectors are available with Azure native so you can deploy policies or it will take care of everything in the backend. If various tools have different priorities for issues, monitoring everything is a hectic task. You have to go into each tool and look into the alerts that have been triggered. It's a big task. If you can integrate them into a single pane of glass, that helps you to find out everything you need to know.

And in terms of the comprehensiveness of the threat protection that these products provide, I would give it a 10 out of 10.

Microsoft Sentinel enables you to ingest data from the entire ecosystem and that connection of data helps you to monitor critical resources and to know what's happening in the environment. At a minimum, we should monitor the servers that are critical in the environment.

It also has hunting capabilities so that you can proactively hunt for things, but a different team looks after that in our organization.

In terms of features I would like to see in future releases, I'm interested in a few more use cases around automation. I do believe a lot of automation is available, and more is in progress, but that would be my area of interest.

I have been using Microsoft Sentinel for more than two and a half years.

It's a stable solution.

It's a scalable model but as you scale up you pay for it.

Microsoft technical support is responsive and helpful. And their technical documents are pretty detailed and well-explained.

Positive

The initial deployment was pretty straightforward.

The number of people involved in the deployment is completely dependent upon the environment and the access we have. If there's something to be done with a third-party application—for instance, Cisco Meraki or ASA—for those, we require support from the networking team to open up ports and forwarding of logs from the firewalls to Sentinel. If it is a native Azure environment, we don't need any support.

As for maintenance, if there are any updates they will pop up in your alerts and you can then upgrade to the latest version. It doesn't take much effort and there is no downtime. You simply update and it takes a few seconds. If someone is experienced, that person can handle the maintenance. If the environment is very big and it requires injecting more logs, then it requires some helping hands.

The pricing is fair.

With a traditional SIEM, people are required for SOC operations and investigations and they require licenses. With Sentinel, people in SOC operations are still required to investigate, but we don't need any licenses for them. With a traditional SIEM, you pay a lump sum for licenses. But with Sentinel, it's pay-as-you-go according to the amount of data you inject.

I would recommend Microsoft Sentinel.

It's always good to compare against other tools when it comes to the value, to get an idea of what you are paying for. Compare the market strategies and the new capabilities that are coming out and whether you're able to unlock the full capabilities or not. Double-check that. As for best-of-breed versus one vendor, you should stick with one vendor only and take whatever they gave.

We use it to protect our Office 365 environment. We can also deploy it for the entire infrastructure, including on-premises, firewalls, and also users' devices.

I'm a partner with many customers using Sentinel. Some are small companies but I also have many banks that have implemented the solution.

It has helped to improve security posture because it's based on machine learning. You can protect the whole environment. While other solutions are based on rules, and you have to put rules in place to protect things, Sentinel is smarter because of the machine learning.

For example, one of my customers is a bank that was attacked by ransomware. They were using Symantec and it could not detect the attack. When we put in Sentinel, within 15 minutes it detected the malware and stopped the attack.

The most valuable features are its threat handling and detection. It's a powerful tool because it's based on machine learning and on the behavior of malware.

I have been using Microsoft Sentinel for one and a half years.

It's a stable solution.

It's a cloud solution so Microsoft handles the scaling. We haven't had a problem with performance because Microsoft is in charge. It's done automatically.

It's definitely the best technical support. When you open a new ticket you get a response within a maximum of one hour. You can open a case with Microsoft 24/7.

Positive

I used QRadar. I switched because QRadar is not smart and there was too much manual work.

It's easy to implement and not very hard to put it into production.

The deployment time depends on the customer's needs. It can be deployed in one hour. But if they have many end users and many servers, it can take one week. After that, you have to wait for the machine learning to learn the environment and start the detection.

The implementation strategy also depends on the environment. If it is an Office 365 environment, we can start by protecting email, the shares, and the docs. After that, we can move to the end-user machines. But it depends on the project.

Deployment and maintenance requires a maximum of three people. One would be an admin, one would be a security leader to maintain the solution, and the third would be a project manager. It also depends on the project, but in general, there will be two or three people involved.

It is certainly the most expensive solution. The cost is very high. We need to do an assessment using the one-month trial so that we can study the cost side. Before implementing it, we must do a careful calculation.

Something that could be improved is the documentation of the cost because there is none. All the other features are documented, but the pricing is not very clear.

The Office 365 connectors to Sentinel are free, as is the support.

Sentinel is generally the last option we go with because of the cost. Customers have their solutions but they contact us and say, "Okay, we have our solution but it's not smart. Can we move to Sentinel?"

I recommend implementing Sentinel because it's certainly the most powerful SIEM tool. It detects all malware based on the behavior of many things, including the files and anomalies. It detects things automatically.

The primary use case of Microsoft Sentinel is for user and entity behaviors, detecting unauthorized access to services, identifying malicious IP addresses, and preventing brute force attacks on services. These are generic security use cases.

The AI-driven analytics of Microsoft Sentinel have significantly improved our customers' incident detection and response. It reduces the workload and decreases the number of tickets and incidents to triage.

The query language of Microsoft Sentinel is easy to understand and use. It allows querying across numerous agents quickly and efficiently. Being cloud-based, it does not require much hardware to utilize.

While I have not used Microsoft Sentinel extensively to suggest specific improvements, there is always room for improvement. The pricing could be improved, as it is considered quite expensive, especially considering the costs for workspace, Sentinel, and storage.

I have been working with Microsoft Sentinel for a good three years.

The stability of Microsoft Sentinel is rated ten out of ten. It is considered highly stable.

Microsoft Sentinel is very scalable because it is a cloud service and does not rely on our own resources. It depends on the payment capacity, however, it is considered very scalable overall.

The customer service and support for Microsoft Sentinel are quite good. They provide numerous articles and training materials and are quick to respond, usually within an SLA of two to three hours.

Neutral

The initial setup of Microsoft Sentinel can be challenging, with a learning curve. Configuring a workspace and adding connectors can be complex, especially for those not familiar with Azure or Microsoft. I would rate the setup around five or six out of ten.

The pricing of Microsoft Sentinel is considered expensive, particularly due to the cloud-related costs for workspace, Sentinel, and storage.

I am still quite new to Microsoft Sentinel, so I can't provide specific advice or recommendations. It is a good product with capabilities that might not be found in other SIEM solutions.

I'd rate the solution eight out of ten.

We provide managed security services to customers in Myanmar using Microsoft Sentinel as a cloud media SIEM. Most of the use cases involve retention, and we use all the features of Microsoft Sentinel. We also use other Microsoft security products like Defender for Endpoint, and most of them are integrated with Sentinel. 

Microsoft Sentinel is a cloud-native SIEM solution, so it helped us reduce our infrastructure costs and deliver better services to our customers. We don't need to pay upfront costs because it is in the cloud. We used an open-source SIEM solution before implementing Microsoft Sentinel, but that wasn't satisfactory for our customers. Sentinel helped us provide more robust managed security services to our customers.

It consolidated multiple dashboards into one and helped us be more proactive. However, our team is still trying to mature to a level that we can adopt a more preventative approach to security. Sentinel significantly reduced our detection time. Without Microsoft Sentinel, our SOC analyst might take 30 minutes to an hour to detect an issue, but now it's practically in real-time. 

The biggest advantage of Sentinel is scalability. In addition, we don't need to worry about paying for infrastructure costs upfront. It gives us the flexibility to choose the kind of infrastructure based on each client's needs. Sentinel is also much simpler than other SIEM solutions. The UI is smoother and easier to use.

Native integration with Microsoft security products or other Microsoft software is also crucial. For example, we can integrate Sentinel with Office 365 with one click. Other integrations aren't as easy. Sometimes, we have to do it manually. 

The bi-directional sync is helpful. For example, we have one client using our managed security service, but they don't want to use Microsoft Sentinel. If those products are not syncing or if the solution is not bi-directional, some alerts may be missed. It's essential for both portals and the two folders to be in the same channel it's pushing. The UEBA features are also perfect. We don't see the same caliber of user behavior analytics in other SIEM. Microsoft's UEBA is great for our SOC analysts. 

Microsoft threat intelligence and UEBA still have some room for improvement. There are currently only two connectors available for Microsoft threat intelligence. the threat intelligence platform and the FTIA commander.
Sentinel should offer another option for a third-party threat intelligence platform. There are lots of open-source threat intelligence solutions available. 

Threat handling could be great for our team and for our SOC analyst, but some are unusable depending on our SOC analytics.

Sentinel can ingest data from most of our ecosystem, but some data cannot be called up. For example, if an SAP product is hosted, it will do a specific version, but it cannot be called back to Sentinel. It cannot be directly connected to Sentinel.

Our team has been using Microsoft Sentinel for about two and a half years.

I rate Microsoft support a seven out of ten. They take too long to respond, but sometimes they are great. 

Neutral

We previously had an open-source SIEM, but it lacked the detection and automation capabilities of Sentinel.

The initial deployment was straightforward but configuring integration for some of our projects was challenging because there are few connectors for solutions like Cisco. I rate Sentinel a five out of ten for ease of setup. 

We performed our integration in-house, but sometimes we get support from Microsoft.

Sometimes, it is hard for us to estimate the costs of Microsoft Sentinel.

I rate Microsoft Sentinel a nine out of ten. I recommend it, but it takes time to evaluate because Sentinel is unlike other cloud solutions. 

Microsoft Sentinel is basically a major log, on top of which you can build queries that can analyze the data you get. It's used to build up security operations centers. In addition, it is a SIEM and SOAR solution.

The first benefit is that you have one place to close incidents. That's definitely an advantage. 

Another benefit is KQL, Kusto Query Language, and the analytic rules with which you can spot suspicious behavior of all kinds. It's definitely a step up when it comes to security. You see the benefits almost instantly.

In addition, automation helps prioritize what needs to be looked at, and what can just be closed and forgotten.

And when you combine the threat intelligence with Defender for Endpoint's recommendations, it's a really strong way to protect things or be proactive when it comes to security, with the CVEs, et cetera.

Overall, our Microsoft solution saves time. Without it, you might have to navigate six or seven portals, but with it, you only have to look at one place, and that saves some time. Most of the time, it eliminates having to look at multiple dashboards and gives you one XDR dashboard. Ideally, that should make working with IT security easier. It also decreases the time it takes to detect and respond.

As a consultant, none of the customers I work for has been hacked or has been close to being hacked. That would be the best way to judge if it saves money because just putting Sentinel on top of all these security products doesn't save you money. It's possible it saves you money. 

I like the unified security console. You can close incidents using Sentinel in all other Microsoft Security portals when it comes to incident response.

The solution helps prioritize threats across your enterprise and that is quite important. There is a concept called "alert fatigue," and Sentinel can also cause that because it detects so many false positives. But usually, the high and medium risks it identifies are things you need to take a look at. So prioritization is quite important.

We also use Defender for Cloud, Defender for Endpoint, and Defender for Cloud Apps. It's quite easy to integrate these Microsoft products because they can easily communicate with other Microsoft products. The tricky part is to integrate other vendors' products, like Cisco or Linux, with Microsoft Sentinel. The actual integration is easy, but they generate a lot of data. But with its entire Defender suite, Microsoft is trying to cover everything in Azure and that is a really strong point.

Sentinel enables you to ingest data from your entire ecosystem and that is vital, but sometimes it's a bit hard to figure out what data you actually need.

Also, the UEBA is a neat feature.

The built-in SOAR is not really good out-of-the-box. The SOAR relies on logic apps and you almost need to have some kind of developer background to be able to make these logic apps. Most security people cannot develop anything, but if you want to make full use of the SOAR part of Microsoft Sentinel, you need to be able to develop these logic apps. You can say, "Okay, that's simple," but it's not simple for someone who doesn't develop.

Also, the bi-directional sync in Microsoft Defender for Cloud should be enabled out-of-the-box. Otherwise, while you can close incidents in Sentinel, they will not be closed in all the other portals. That is really important.

In addition, the watch list could be improved. Microsoft could develop some analytic templates based on these watch lists, for example.

And if you don't have any KQL knowledge, Sentinel is actually quite hard to use or to get the most out of.

I have been working with Microsoft Sentinel for approximately one year.

It's a stable solution.

My clients are looking to increase their usage of Sentinel. Every time I look, there is a new data connector, so it seems like it's a product that is constantly in development.

I haven't used their technical support.

The initial deployment, for me, is not really complex. It takes one hour or less. But to be able to use Sentinel to its full capabilities, you must definitely know something.

In terms of an implementation strategy, you need to really think ahead about who should be able to do this, and who should be able to do that, and respond to that, et cetera. A proof of concept would include dealing with the architecture, gathering initial data sources and/or automation, and then learning how to navigate in Sentinel. One person can do it.

My clients are enterprise-level companies and the solution requires maintenance. It includes updating analytics, importing, and creating new analytics. It depends on the company. If you have 100 employees, one employee might be enough to maintain things, but if you have 10,000 employees and 10,000 devices, you might need more employees.

No license is required to make use of Sentinel, but you need to buy products to get the data. In general, the price of those products is comparable to similar products.

My advice is to start out with a little bit of data and build on top of that. Don't enable too many data connectors in the beginning. Get familiar with the product, and remember to work with Sentinel every day. That's the only way the product gets better.

It comes with some out-of-the-box analytics, but to get the full and best usage out of it, you have to really keep developing it with hunting queries, analytics, et cetera. The visibility provided by the built-in analytics rules, what they detect, is rather good, but Microsoft Sentinel requires ongoing work. It helps automate routine tasks as well, but that's not something that comes "for free." It also requires ongoing work.

Threat intelligence is something that you must be more than just a novice in Sentinel to make use of.

Overall, I find Sentinel to be a really strong solution. Sentinel is where you can see the overall security status of your company. I really enjoy working with Microsoft Defender and the entire suite, combined with Microsoft Sentinel.

We use it to monitor the cloud for any security issues. We are using it as a SIEM for our cloud workspace.

The most valuable feature is the UEBA. It's very easy for a security operations analyst. It has a one-touch analysis where you can search for a particular entity, and you can get a complete overview of that entity or user.

There is also something called workbooks in Sentinel that help us to monitor the complete cloud data and it gives knowledge about, and visibility into, our security posture.

It integrates seamlessly with Microsoft products, especially Office 365 and our Azure workspace, whether it's the Application Gateway or Azure DDoS or Azure Firewall. It has native integration that works very well.

You can also monitor Zero Trust security from Microsoft Sentinel.

There are a number of points they can improve. For example, if I see an alert and I want to drill down and get more details about the alert, it's not just one click. In other SIEM tools, you just have to click the IP address of the entity and they give you the complete picture. In Sentinel, you have to write queries or use saved queries to get details. For a security analyst, when there is an incident, it takes a lot of time to write queries, investigate, and then execute.

For example, if you want to search a particular entity or an IP address, or search the complete log instead of just the security alerts, it takes time to write a query for that. The MTTR is a little high, as is the mean time to investigate, compared to other SIEM tools.

I would also like to have more resources on KQL queries.

And using the data connectors is not straightforward when you want to create a use case that is not out-of-the-box. Creating a custom use case is a challenging process. You need to understand KQL queries and the support for regex is limited.

I've been using Microsoft Sentinel for between six months and a year.

The availability is good. But when you compare the stability with Splunk or ELK or QRadar, it still needs to be more reliable and stable, not from an installation or administration perspective, but when it comes to security operations.

We collect data from between 3,000 and 4,000 users, and our cloud workspace is somewhere around 100 or 200 servers.

The scalability is good because it has Azure in the back end.

We are still deciding whether to migrate completely to Sentinel or not. We are using two SIEM solutions in parallel. The other solution is LogRhythm. From an analyst perspective, Sentinel has to evolve more. Once it does, we can think of migrating to it fully.

The installation was straightforward and easy. With Azure Resource Manager, it was easy to deploy, and it was a straightforward integration, in terms of configuration, to connect the Log Analytics workspace with Sentinel and the solutions that Sentinel has.

Deploying the solution hardly took four hours, and the initial configuration took a single person one day, meaning eight hours.

We used to have an on-prem solution and we moved our workload to the cloud. Our users did not face any challenges or difficulties as a result.

We are still in the process of getting our ROI. We are waiting for the solution to improve and mature.

Sentinel is pretty competitive. The pricing is at the level of other SIEM solutions.

I have experience with Splunk and QRadar and they are the best. They are equivalent, one with the other. Both the solutions are mature enough, having been in the market for quite some time. They know what they're doing and are easy to use from an analyst's perspective. Both are scalable solutions as well.

The drawback of these two solutions is that it takes a little bit of time to do integrations, especially for Azure workloads, as they're not in-built in Azure.

Always record your KQL queries and stick to the basics.

We use Microsoft Sentinel for providing managed services and for security use cases, which include detecting anomalies or security events and collecting security events from various data sources.

What is most useful, is that it has a good connection to the Microsoft ecosystem, and I think that's the key part. If you are running the Microsoft ecosystem, you are running Azure and Microsoft 365 and have all of the security providers in that environment, for example, the E5 license, then Sentinel can easily collect those events and handle them within the same Azure environment. That, I believe, is the key point here.

Multi-tenancy, in my opinion, needs to be improved. I believe it can do better as a managed service provider.

It's a fairly mature product now.

Pricing could also improve, it's a bit expensive.

I have been working with Microsoft Sentinel for approximately two years.

There are private tenants, but it is deployed in a public Cloud.

Microsoft Sentinel is a stable solution.

Microsoft Sentinel is scalable. As it is in the cloud, you simply pay more. It's expensive, but it's very easy to scale.

We haven't used Microsoft's technical support. We rely on the online knowledge base. Essentially, the entire internet is based on the information they have. As a result, we have never contacted technical support. It hasn't been required. I suppose it's fine. We didn't use technical support in that sense. I would say that it's good.

I am familiar with SIEM. 

We run several CM systems as well as a security operation center.

I have worked with Microsoft, IBM, and McAfee. McAfee has an older CM, and we use Elastic as well.

Within the same cloud environment, it is very simple to set up and begin collecting data.

Microsoft Sentinel is expensive.

If you have the funds, I would recommend it. I think the pricing is important; it's quite expensive, but if you have that, I think I would recommend it. The advice is to think carefully about what data you send to the platform because it is costly. The price is data-driven, so make sure you know how much data you will send and that you only send what is required. That, I believe, is the key point.

We are Microsoft partners.

I would rate Microsoft Sentinel a seven out of ten.