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.

Positive

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.

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.

As a security engineer, I help onboard with Sentinel. I enable all the connectors and tune the analytics to minimize the number of false positives.

We're a Microsoft house and it provides very good visibility into all the threats a company might be facing. 

The connectivity and analytics are great.

It allows people to connect to different data sources under a single pane of glass.

The visibility is great in terms of having the notebook features. By using the notebook features, people can generate different graphs, which helps create greater visibility on the front end.

We've been able to integrate other products, including Defender. It's super easy to integrate them. All Microsoft products easily connect with each other. They coordinate together to help with detection and response across our network. This is critical. 

This allows me to have better visibility to understand what is happening on each endpoint.

The threat protection is pretty comprehensive across Microsoft products. Having dependable endpoints and other security tools ensures good security overall. In terms of compliance, you have a lot of data that can help ensure comprehensive information is available and transparent. 

We like that it's on the cloud.

Sentinel does allow us to ingest data from our entire ecosystem. This plays an important security role.

We can investigate threats holistically from one place. Having everything centralized makes security easier and helps us better understand what is happening. 

Sentinel's security protection helps us to better identify anomalies or erratic user behavior. It helps me minimize false positives. 

There is good automation. They do an okay job.

Consolidating into one dashboard has made it possible to have a holistic view of security. I can investigate issues and have better visibility.

Overall, the solution has saved me time. I'm not sure if I can quantify it, as I'm on the engineering side. 

The product has helped save the organization money. 

It has decreased our time to detect and time to respond. 

They only classify alerts into three categories: high, medium, and low. So, from the user's point of view, having another critical category would be awesome. That would minimize the level of high alerts and break them down so we understand which are truly critical. We should be able to prioritize more effectively. Right now, this doesn't necessarily help users to prioritize when it comes to the alert or triage.

The bi-directional capabilities are okay. However, sometimes I need to fall back on Defender for cloud.

I've been using the solution for two or three years now.

The stability is okay. I've only experienced one outage.

We have about 200 staff on the solution. 

The scalability is very good. All I have to do is enable data sources in order to expand. 

I haven't had much contact with technical support. My one experience was okay. 

Neutral

I did not previously use a different solution.

The initial deployment is straightforward. The entire process was as simple as following clear steps. We basically create a workspace and push the pipeline.

As long as a person has relevant access to Azure, one person would be enough in terms of handling the deployment. 

We did a deployment in a single location, not across multiple locations. 

There is a bit of maintenance, in terms of ensuring logs are being digested. The number of people involved depends on the situation. We have two to three people who may check logs or connectors. 

We are consultants for clients. We help SMEs deploy the solution. 

We have witnessed an ROI while using the solution, however, I cannot quantify the amount exactly.

Sentinel charges based on ingestion. If Microsoft would allow us to view the logs before ingesting something we don't want, that would make the pricing better. Sometimes we don't want to pass illegitimate data into Sentinel, yet I don't have a choice. 

It's not cheap. However, it's okay pricing.

I did not evaluate any other options previously.

I'd rate the solution eight out of ten.

I'd tend to go with a single vendor over best of breed. A company like Microsoft allows everything to easily link various products together. 

If you are using Microsoft Sentinel, go for the XDR solutions as well. 

We are using Microsoft Sentinel for our traditional SOC. So previously, we had multiple products, like VM products, log analytics products, and analysts. We are making so much effort to analyze incidents and events in the security operation center., after which we decide whether it's an incident or an event, and we take action. After Sentinel's implementation, it would be much better and much simpler. For instance, we can now save much more time since in Sentinel, there is artificial intelligence, so the system will decide for you instead of a human. The system will learn what kind of thing you should take action on, and it will save some time since you do not need much human power. In traditional SOC systems, there were three or four people. But in Sentinel, it's much easier, and you do not need so many people in the SOC. So you will save time and keep it cost-effective.

Previously, we were incurring a huge cost being paid to a person. But in Sentinel, you do not hire anyone because the system provides system insights through the cloud applications. So you do not need to put effort, or you don't need to hire either of the senior people. So in, in your SOC team, would be mid-level people, and it would be fine. Also, you do not need so many people. So, one or two people left the organization after the central implementation. So we just have an agreement with one company at a professional level since they're also managing Sentinel. We do not need to pay for the maintenance of applications. So that's also a benefit for us. So, in this case, we are only paying Sentinel yearly or annual costs.

Previously, we could not do some automation. So in Sentinel, we create some playbooks, and with some features in the playbooks, we have some capabilities. For example, when a virus enters the system, we will take action to keep the system safe. So, the machine with the virus can be automatically isolated from the network, and this might be a pretty cool feature in the solution currently.

Microsoft Sentinel has improved our entire SOC, like our log system and incident response. So we are able to quickly respond to incidents and take action. Even though Microsoft Sentinel has already improved our system, it should further improve for on-premises systems or traditional systems, especially to get or collect logs from the legacy systems. Also, Microsoft should improve Sentinel, considering that from the legacy systems, it cannot collect logs.

I have been using Microsoft Sentinel for about six months. My company has a partnership with Microsoft.

I have not contacted technical support.

We are using Microsoft Intune. From the mobile device management point of view, it makes work very easy. We are just planning that with Microsoft Intune, we can easily export some logs to Sentinel to analyze them. We are not using this feature right now, but we are planning. If you are using Microsoft applications, it's very easy to integrate them with other Microsoft products.

Defender is something that we are using as an antivirus for Android applications, but we are not using it on the cloud.

From a cost point of view, it is not a cheap product. It's, like, an enterprise-level application. So if you compare it with a low-level application, it's expensive, but if you compare it with the same-level application, it's pretty much cost-effective, I think. Because for other products, you need to purchase them by paying thousands of dollars. In Sentinel, you pay for how much you use, or you just pay for how much you consume storage, log interface, or system. It will not be a one-time cost, but it will be like a continuous rental system, where you subscribe to an application, and then you use it. That's very easy. I think the company got the solution for a long time. If you purchase some products, you need to invest in something, and it increases your investment budgeting. Many enterprises do not like investments. But this is not a one-time cost, to be honest, since continuously, we will pay. This is maybe a negative point of view, but considering from company to company, it entirely depends on a company's strategy.

Previously, it was a little bit difficult to find where an incident came from, including which IP address and which country. So in Sentinel, it's very easy to find where the incident came from since we can easily get the information from the dashboard, after which we take action quickly.

Sentinel does provide me with the ability to set priorities on all the threats across your entire enterprise. So, it is very important because we were previously getting the service from the outside. It would be yes. Sentinel is a next-generation SOC. So, Sentinel also still develops some applications on Sentinel's site, so maybe in the next release, they will introduce a much more effective version for the company. I'm not sure how many companies use it right now. Maybe in the future, more companies will use Sentinel because its features are such that compared to the traditional SOC systems, they are not affected since the system is a cloud-based system. So it's easy to manage. Also, you don't need to care about it from an infrastructure point of view. Additionally, we don't need to take care of products, and we don't need to take care of maintenance. From a product point of view, we do not need to manage since we just need to focus on the incident event.

Right now, we are using very traditional applications, so there is no use of native Microsoft applications right now.

Sentinel enables me to ingest or collect data from my entire ecosystem, but not all of them, because some traditional applications cannot provide some data needed for export. It cannot allow you to get reports or logs from outside. It's a challenging point, so this might be an opportunity for us to change the traditional application. In traditional applications, and sometimes in IT systems, it might be very difficult to get data insight. In some cases, we need to change the application since, in traditional applications, you cannot get support. To fix it, you need to decide something, or maybe you need to decide on the application change. It might be an opportunity for you. But in the next-generation application, there is no problem. With a new application, you can easily integrate with Sentinel. In Sentinel, the negative point is just related to cloud applications. With cloud applications, maybe sometimes you cannot get data from the on-prem application. So if you use a cloud system, like Sentinel, which is a cloud system, then it's very easy. If you are using an on-prem system, Microsoft Sentinel sometimes may not be easy to integrate.

Sentinel allows me to investigate threats and respond quickly and thoroughly from just one place. It accelerates our investigation, especially our event investigation and incident investigation. Using Sentinel, we take quick actions and get quick insights after its standard implementation. So it is time-efficient.

Previously, we had no SOAR applications. In Sentinel, if you want to take action quickly, you need to create playbooks so that if something happens, you can just develop an application like a playbook in Sentinel so that if something happens, you can tell Sentinel to take action. You can freely create your own playbooks since it's very easy. In my opinion, this is the best feature of one product. Normally, you need to purchase two applications or two products. But in Sentinel, they combine everything together. This is the most beautiful feature for me.

Sentinel helps automate routine tasks and help automate the finding of high-value alerts. We do not need to create manual operations like when our system engineers see the incident and they do a system analysis. So after Sentinel, the system analysis is not done by anyone since Sentinel can already make decisions and then take action by itself. So at this point, there's no human power. Sometimes human power is needed, but maybe eighty percent or ninety percent of the time, there is no human power needed. So, it has caused significant improvements in our entire company.

Sentinel has helped eliminate having to look at multiple dashboards and giving us just one XDR dashboard. Previously, we had to check multiple dashboards, especially in relation to whether logs were coming and other things, like incidents and events. In Sentinel, you do not need to check many dashboards. So you are just designing one dashboard, and then, on the entire dashboard, you will see everything. So, it now saves time since previously there were multiple dashboards causing our engineers and our analysts to get confused at times. So they used to ask our managers to understand better. Currently, it is very easy to understand since one needs to check in on one dashboard, and there's no confusion among the engineers. But they do not need to ask anyone to understand. Apart from better understanding, it has improved our systems.

From a security point of view, you need to go with multiple vendors, but this is a traditional system. But right now, if you want to create a good security system, you need to implement each product with one vendor. Because vendors currently state that, if you want to have a high-level security system. You need to implement each product on a security level from one vendor. Microsoft-level vendors offer many features, but people only just purchase or use one product, and that's all. It's not good for security infrastructure. So, you need to implement all security products from just one vendor. I think one vendor and the needed security products will be enough for a company. Sentinel is our next-generation SOC. Currently, I don't see any competitors at this level.

I rate the overall solution a nine out of ten.

We use Sentinel to monitor logs, build alarms, correlate events, and fire up specific automation boards in the event of a security incident. 

Sentinel creates a focal point for cybersecurity incidents, so it's much easier to correlate logs and incidents to get a more comprehensive view of our security posture. Microsoft provides many educational resources, so onboarding new people is easy. 

It took us about a month to realize the benefits of Sentinel. Integrating all the Microsoft security products into the solution was straightforward. It seamlessly integrates with Microsoft Logic Apps, so it's easy to develop custom playbooks and automate many manual tasks. 

Automation has made us more efficient and effective because we're free to focus on priority alerts. Sentinel has reduced the time spent on menial security tasks by 30-40 percent. Sentinel consolidates our dashboards into a single XDR console, one of our strategic goals. We're moving all of the data into Microsoft Sentinel to create a single point of truth for security incidents.

Microsoft provides some threat intelligence for significant incidents. They provide us with remediation and mitigation controls we can implement to react to these potential threats much faster.

I like the ability to run custom KQL queries. I don't know if that feature is specific to Sentinel. As far as I know, they use technology built into Azure's Log Analytics app. Sentinel integrates with that, and we use this functionality heavily.

Threat prioritization is a crucial feature. It already has them in order, so we know we should investigate high alerts first and move down the line to the less urgent ones. 

We use all of the other Microsoft security solutions in addition to Sentinel. They all can be integrated together seamlessly to deliver comprehensive threat detection and response. 

I would like to see additional artificial intelligence capabilities. They're already working on this with new features like Microsoft Security Copilot. This will help us investigate incidents much faster. 

When we pass KPIs to the governance department, there's no option to provide rights to the data or dashboard to colleagues. We can use Power BI for this, but it isn't easy or convenient. They should just come up with a way to provide limited role-based access to auditing personnel 

I have used Sentinel for two years.

We haven't experienced any downtime, so I think Sentinel is highly stable. 

Sentinel runs on the cloud, so it scales automatically. 

I rate Microsoft's support a 10 out of 10. They can connect you with the developers, and you get answers quickly. 

Positive

I also worked with RSA enVision at my previous company. Sentinel has advantages because of its tight integration with the Microsoft ecosystem. It's effortless to set up because you don't need specific connectors. Sentinel works out of the box. It makes sense for a company that primarily works with Microsoft products to use Sentinel for security monitoring.

Sentinel runs on the Microsoft Azure Cloud, so it was easy to set up. It took about two days to set it up. You start by integrating the Microsoft security solutions using the available connectors and move on to the firewall, SysTalk databases, and application-specific logs. 

It's a bit more complicated to come up with custom rules and alarms, so that's the last part of our implementation strategy. We completed the deployment with two or three people and the help of Microsoft support. Because Sentinel is deployed in the cloud, it doesn't require any maintenance. 

Our ROI comes from automating lots of tasks. 

Microsoft Sentinel is pretty expensive, and they recently announced that they will increase the price of all Microsoft services running in Azure by 11 percent. Luckily, I'm not responsible for the financial side. For one of my clients, the estimated cost is 880,000 euros for one year. There are additional costs for the service agreement. 

I rate Microsoft Sentinel an eight out of ten. I recommend taking advantage of the virtual training before you implement Sentinel. Familiarize yourself with the product, dashboards, features, integration, etc., before you decide to use it. 

A single-vendor strategy is preferable because it's easier to integrate them. Otherwise, it can get complicated.

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 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.

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%.

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.

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.

I've been using Microsoft Sentinel for about one year, but more heavily over the past five months.

It's pretty stable. We don't have any performance or capacity issues with it.

It's scalable when using solutions like Lighthouse.

I haven't needed to use technical support yet, but the documentation in the community is very good.

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.

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.

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.

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.

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.

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.

We have had various use cases depending on the needs of our customers.

It is a SaaS-based solution. It does not have any versions.

In traditional SIEM solutions, there is a lot of hardware, and there is a lot of maintenance around it. We require a lot of resources for administrative tasks, whereas with Microsoft Sentinel, we don't have to get into all those details straight away. We can concentrate on the use cases such as detection and start ingesting our logs, and right away, get insights from those logs. In addition, traditional SIEM solutions, such as Splunk, QRadar, LogRhythm, or ArcSight, do not support cloud-based logs much. This is where Microsoft Sentinel comes into the picture. Nowadays, everyone is moving to the cloud, and we need solutions like Sentinel to easily ingest logs and then get insights from those logs.

It has definitely helped to improve the security posture.

The in-built SOAR of Sentinel is valuable. Kusto Query Language is also valuable for the ease of writing queries and ease of getting insights from the logs. Schedule-based queries within Sentinel are also valuable. I found these three features most useful for my projects.

Microsoft Sentinel has many native connectors, which are plug-and-play connectors. You don't have to do any kind of analysis before starting. Taking Azure Cloud logs as an example, once you enable Sentinel and the connector, you start getting the logs straight away. You get a visualization within Sentinel through dashboards, which are called workbooks. So, right from day one, you can have security for Azure Cloud. If you have other clouds, such as AWS and GCP, even they can be included right away.

There is not much guidance on the in-built SOAR solution that uses Azure Logic Apps as a service. For people coming from traditional SIEM solutions, it is difficult to understand how SOAR works. Because the security teams are not from a programming or coding background, they cannot directly jump into SOAR. For Kusto Query Language within Sentinel, Microsoft provides a lot of documents and articles, and they also have a community, but when it comes to SOAR, other than a few open articles, there isn't much information. The documentation part of SOAR should be improved.

The dashboards can be improved. Creating dashboards is very easy, but the visualizations are not as good as Microsoft Power BI. People who are using Microsoft Power BI do not like Sentinel's dashboards.

I have been using this solution since October of 2019.

It is stable.

It is a SaaS-based solution. So, as end-users or customers, we don't have to think about scalability. 

Sentinel Contributor and Sentinel Responder are the primary roles of its users. Users with the Sentinel Contributor role can perform anything on Sentinel. The Sentinel Responder role is allocated to L1 and L2 monitoring teams. They actively monitor the Sentinel console for any triggered incidents and remediate those tickets.

In terms of the number of users, it is a typical SOC team, which depends on the number of incidents. We calculate the full-time employees based on how many alerts are being triggered per month. If 1,000 alerts are being triggered per month, we would need eight FTE to run 24/7 operations.

We definitely have plans to increase its usage. Microsoft is continuously improving this product, and we also have private access where we can see what features are being launched and provide input to them.

Microsoft Sentinel is a SaaS-based solution. They are improving it all the time. You can see new features every month and week. They are bringing more and more features based on customer feedback. That's one of the things that I liked the most about Microsoft Sentinel, which I did not see in other products.

I like their support. When you raise a ticket with Microsoft, you'll get a response within four hours or so. A support person is assigned who then directly reaches out to you on Teams to troubleshoot.

They send the ticket to the right team. They reach out and guide appropriately. They inform me that they are taking care of the issue, and if a meeting is required, they ask about a suitable time so that they can block the calendar. I have never encountered any issues with the support team where I had to escalate anything to someone else. I would rate them a nine out of ten.

Positive

I have worked with QRadar and NetIQ Sentinel. These traditional SIEM solutions are not equipped to effectively handle API integrations on the cloud. Nowadays, most organizations are on the cloud. For Microsoft-heavy or cloud-heavy environments, it is very easy to manage and very easy to ingest logs with Microsoft Sentinel.

It was straightforward. Deploying Sentinel doesn't take much time, but the initial design required for any solution takes time. Once you have planned the design, deployment involves using toggle buttons or bars.

In terms of the implementation strategy, being a cloud solution, not all customers are there in a single subscription. There could be various tenants and various subscriptions. We have to consider all the tenants and subscriptions and accordingly design and place Sentinel.

Ideally, it takes two to three months to onboard log sources, and for implementation, three to four resources are required.

We have definitely seen an ROI. In traditional SIEM solutions, we need to have people to maintain those servers and work on the upgrades, whereas when it comes to the SaaS-based solution, we don't need resources for these activities. We can leverage the same resources for Sentinel monitoring and building effective detection rules for threat hunting.

There are no additional costs other than the initial costs of Sentinel.

We didn't evaluate other solutions.

I would recommend this solution. Before implementing it, I will also suggest carefully designing it based on your requirements.

You have two options when it comes to ingesting the logs. If you aren’t bothered about the cost and you need the features, you can ingest all logs into Sentinel. If you are cost-conscious, you can ingest only the required logs into Sentinel.

I would rate it a seven out of ten.