Microsoft Sentinel Reviews

I'm an IT consultant, and I use Sentinel with two of my clients to monitor all their security signals and get alerts when things are happening that might be suspicious.

The fact that the solution helps automate routine tasks and the finding of high-value alerts has made it possible for me to provide security operations. If I didn't have automation, I wouldn't be able to do that. Nobody is going to pay me to sit and stare at a screen for eight hours a day. But with the automation built in to let me know about and fix things, it becomes viable. The automations have an email option, and all the alerts show up as emails in my inbox. I'm busy with other things, and I'm not looking at Sentinel all day. And the automation in those emails is available to deal with things automatically. Automation is incredibly important.

Sentinel gives me one XDR dashboard. In terms of security operations, it's improved them and makes it easy for me to do my job.

It saves my clients time, on the order of 30 percent.

It also saves costs for me and my clients. If we didn't have Sentinel in place, and they were to get compromised, it could cost them tens of thousands of dollars due to ransomware, a BEC scam, or another type of attack. Without Sentinel in place, that could be a very big cost.

And it decreases the time it takes to detect and respond by days, if not weeks.

My clients are small businesses, and mine is also a small business. Traditionally, even the concept of using a SIEM in most small businesses was unheard of. It was an on-premises product, and you needed to install servers, and most normal IT consultants wouldn't even look at it because it would be very complex for them. The standout feature of Sentinel is that, because it's cloud-based and because it's from Microsoft, it integrates really well with all the other Microsoft products. It's really simple to set up and get going. You don't have to set up a server or do a lot of configuring and setting up storage. It just lives in the cloud, you turn it on, and connecting most things to it is really easy.

It's fantastic when it comes to integration with other Microsoft products. It's so easy. I've been in IT for 30 years, and integrating products was, up until a few years ago, something we would never want to do. It was so hard, we wouldn't want to touch it. We would have to write custom code and configure things. It was just horrible. Now, it's literally a couple of sliders in the interface, and you're done.

And once these solutions are integrated, they work natively together to deliver coordinated detection and response across my clients' environments. I follow this space very closely, but I am not an expert in any other solution. Still, at least for my clients, with the threats they are facing and the alerts we get from the real world, Sentinel's detection and response are very comprehensive.

Sentinel enables you to ingest data from the entire ecosystem. I have integrated some non-Microsoft products with Sentinel, and, predictably, it's not as simple as one click because these are third-party products. But it is definitely quite easy. For cloud products and services, it's still very simple. It might be three or four clicks. But for on-premises products, it's a bit more work.

My clients also use Defender for Cloud, and its bi-directional sync capabilities are very important. It makes things much easier.

Sentinel provides a clear view into the threats that are coming in, and, compared to what I had before, it is night and day. I heard somebody say on a podcast, "The solution we had prior to Sentinel was like a dark room and you had a torch, and you could shine the torch in different directions and see some things. Having Sentinel, combined with Microsoft 365 Defender, the XDR solution, is like turning on the lights and seeing everything." I completely agree. That's exactly what it feels like.

Another incredibly important factor is the solution's ability to investigate threats and respond holistically from one place. Again, as a small business, I wouldn't have the time and energy to look in several different places. I need one place where it all shows up, and that's what Sentinel provides.

And with built-in SOAR, UEBA, and threat intelligence, the comprehensiveness of Sentinel's security protection is good.

Given that I am in the small business space, I wish they would make it easier to operate Sentinel without being a Sentinel expert. Examples of things that could be easier are creating alerts and automations from scratch and designing workbooks. All of those are available as templates and community-produced content, but doing all that from scratch and keeping it up-to-date, is not easy. Because I have lots of other things on my plate, it would really improve things for me if they would make it more accessible for small businesses and non-experts.

I have been using Microsoft Sentinel since it was in public preview, so that's at least three and a half years.

It's a very stable solution—rock-solid.

It's also very scalable.

I have only ever contacted them about Sentinel once, but I have certainly dealt with Microsoft support in various ways. Their response time is pretty good. But they have a difficult time providing good support, at the level that would cause me to give them a higher score than six out of 10, because things change so fast. And it's so much wider than it used to be 10 years ago. There's so much to cover, and that's difficult for them.

Neutral

We used ESET for one client, but it wasn't a SIEM, it was just endpoint protection. We replaced that with Defender for Endpoint, Defender for Identity, Defender for Cloud Apps, and Sentinel. It's not an apples-to-apples comparison.

The initial deployment is very straightforward. It took me four or five hours to set it up.

The product itself, obviously, does not require maintenance, but the alerts and rules require work.

Sentinel is fairly priced and pretty cost-effective. Compared to on-premises solutions, Sentinel is very cost-effective.

It's certainly possible, if you're not careful about what you connect, to shoot yourself in the foot by ending up with large data sources being ingested that cost you a fair bit of money. You do need to think about what data sources you actually need, which ones will lead to the detection of actual attackers, and how much of that data you need. You also have to consider how you're going to store it, because Sentinel has different levels. You don't have to store it all in the expensive "this will give me alerts" tiers. But, as I said, my clients are small businesses. They certainly don't have a budget for anything expensive, and they're very happy with the costs.

Do a proof of concept. It's really easy to set up and get started. You don't have to turn everything on to start. Do a small proof of concept, get familiar with it, and you'll see how easy it is.

Does it help prioritize threats across the enterprise? The short answer is, "Yes, it does." The slightly longer answer is that it is not a set-and-forget solution. And no SIEM is. You do need to configure Sentinel and fine-tune it. I have a calendar reminder every two weeks to go back in and make sure the right analytics rules are in place and change the ones that need changing, et cetera. It does prioritize threats, but it's not an automatic process that you never have to worry about again.

Sentinel's threat intelligence doesn't really help with proactive steps. The threat intelligence has indicators of compromise, such as IP addresses, URLs, and file hashes. They get detected, but that's not really proactive. Perhaps it's "proactive" in the sense that somebody else has figured out that those things are bad and let the system know. But Microsoft 365 Defender does the proactive part because it has threat intelligence in it. It will tell you, "A new threat that we have a report on seems to be targeting your type of client." That's proactive, but Sentinel isn't proactive. Meaning, if you read about a threat and then protect yourself before that threat reaches you, Sentinel doesn't really do that.

In the debate about best-of-breed versus a single-vendor security solution, if you pick best-of-breed individual security solutions and you have to integrate them, now you're an integrator. And that is hard. It's not easy to integrate different security products. And that's why, at least for my clients, Sentinel and Microsoft 365 Defender have been a huge shift. They're so easy to integrate. My clients could license separate products and then try to integrate them to get the same level of integration, but that would never work.

We have multiple use cases based on the data sources we have onboarded, like Sophos UTM or Firewall.

We also use Microsoft Defender for cloud and Microsoft Office.

We have integrated MD with Sentinel to receive alerts. If there are any suspicious activities in any of our resources, MD will create an alert. Once an alert comes through MDC, it is converted to Sentinel.

It was easy to integrate the solutions. It took about two or three clicks. The solutions work natively together, specifically to give us coordinated detection and response across our environment.

There is a correlation with the mail-based algorithm. We have an AML model algorithm in Sentinel. It has the capability to catch the pattern of attacks and shows that to us in the Sentinel app.

We mostly have cloud-based solutions, so Sentinel gives us better security. There's a feature that allows us to capture all the data in a single console, which we can analyze from the cloud itself.

We don't have to use third-party services to check these activities. If we see that one of our accounts is compromised or anything has happened, we can remove that person from other groups.

There's a feature that allows us to see what is in a secure state and what is in a critical state.

Sentinel helps automate routine tasks and find high-value alerts. We can have a custom playbook and create automation rules through that. If there is a false positive address, we can do the automation from there. If we want an email notification based on high-activated rules, we can provide the automation rules that will notify us on Outlook or through Teams.

It minimizes our analyst's workload. Once a high activity comes up, we'll get a notification on Teams. As analysts, they will validate and send us the email or notification within 10 to 15 minutes with more valid data. If there's a playbook with the top 10 critical rules, we can create multiple playbooks and attach them with the data that we want to protect.

Once that incentive is triggered, we'll get notifications with the full details of that incentive. If high severity comes up, that email is sent to the client, and we do more analysis on that rather than wasting time on the first analysis. We can directly get into the deeper version of the automation.

If an incident comes up, we have to validate the load and find out the correlation of the users. We can focus on the advanced test rather than wasting time on the previous one. This saves five to ten minutes.

On a monthly basis, the analyst team saves at least three to four hours with automation. We have multiple rules based on our more critical test. From that perspective, analysts don't want to work more on low priorities because we'll be automatically notified of low and high priorities. We focus more on critical users where the threat is high. By focusing on what is a high priority, our analysts save five to six hours per week.

We have multiple dashboard views that allow us to see logs coming from different solutions and users who were involved in the previous incident.

The best feature is that onboarding to the SIM solution is quite easy. If you use cloud-based solutions, it's just a few clicks to migrate it.

The console is user-friendly. We have almost 120 different types of data, so the solution helps us to onboard different types of third-party services to the SIM solution. We have UB features, and the SOAR capability in the Sentinel server is also a good feature.

Sentinel's visibility into threats is very good. We have an investigation graph that allows us to see the correlation between the incident and the users. We can see if there are multiple incidents with the same IP address and if there are multiple breaches. We can correlate with the rules and check if any inside threat activities are going on with the malicious site or the malicious URL link that we have onboarded. The threat view provides good visibility.

We can prioritize threats based on our investigation assets. It's very fast. We're able to see the rest of the threat activities and how impactful they are. Based on the AML algorithm, we can get all the stages of the attack as well.

Sentinel enables us to ingest data from our entire ecosystem.

The importance of this ingestion of data to our security operations depends on the data and the type of solutions we have to onboard. We onboard our critical servers and assets to the same solution so we'll have good visibility.

We're able to investigate threats and respond holistically from one place.

We can validate the logs from where the logs have been received. By doing the log analysis, we'll be able to find them. It's a straightforward function and isn't very hard.

There's an incident pane in Sentinel. We have a query package, and we can have a deep dive alert through that, or we can have a deep look into the log. From the console itself, we have a great view of our threats and the current phase we're in.

We have multiple source features. There are between 20 to 30 in addition to data. Microsoft provides custom features through which we can connect with third-party solutions and correlate the incident. For example, if we have multiple incidents, we can use the SOAR capabilities and correlate them with multiple third-party threats. It's an easier way of understanding whether or not we have a malicious bug.

We can see how much time our analysts have taken to raise the ticket and how much time they have taken to resolve the issue assets. We can create a dashboard for that. They're able to notify us within five or ten minutes for high priorities. For the medium priorities, it is 10 to 12 minutes. Our detection time for low priorities is within three hours, but our team still performs under 15 to 18 minutes.

If we want to use more features, we have to pay more. There are multiple solutions on the cloud itself, but the pricing model package isn't consistent, which is confusing to clients.

We have been using this solution for almost two years.

The stability is very good.

I would rate the scalability an eight out of ten.

I would rate technical support a six out of ten. Technical support doesn't understand the features well enough. They will give us links to reference, so we go through those links as a team or Google the solution. We reach out to them if we can't find the solution, but they provide us with the same links and URLs that we've already referred to. It's a hassle because it wastes a week and a half of our time. Their solutions and response time aren't very good.

Neutral

The setup is based on our data sources. We have a segregated timeframe of two payments. It depends on the client or who is doing the operation. Onboarding on the cloud is pretty easy. It takes just a few clicks from migrating the data sources to getting the logs.

For an on-premises or third-party software servicer, it will take more time and troubleshooting to do the setup. It won't be hard if you have a good team for the onboarding process. It can be complicated initially, but the rest of the timeframe will involve fine-tuning the logs and creating the custom rules based on your requirement.

It doesn't require a lot of maintenance. It's pretty simple. We just had to play with it for a couple of months.

We haven't seen any financial ROI.

Sentinel is the best solution that we use. It's a pay-as-you-go model. We can fine-tune the features we want and choose if we want to remove logs. We can also segregate logs, which helps us minimize costs. Sentinel provides free Office 365 and Azure-based logs without pricing assets. When it comes to the third-party solution or our server logs, we just have to do the fine-tuning of the logs.

The pricing isn't very high. It depends on the number of logs you have. If you're expecting to ingest 50 to 60G in a day, but you're only ingesting 20 to 25G per day at first and you have a good team to analyze the logs, then you can segregate the ingestion at under 15G.

I would rate this solution a nine out of ten.

It's very user-friendly. The only issue is that Microsoft's technical support isn't very good. If you have a good team who can onboard the resources to the solution, then you'll be happy with the solution itself.

For us, it's better to go for multiple solutions rather than a single suite because we cannot strictly trust one client. If you only have one cloud-based solution, it's better to use Sentinel to secure it. It's helpful to have a good team that can do the monitoring and onboarding smoothly. You can go with one solution if you have a trusted partner. If you don't, then I would use multiple solutions.

You should purchase the features that Microsoft provides. It's a configured network, so they will correlate with the end resources, RMD, and receiver identity. The fusion-based algorithm rule will detect advanced multistage attacks to stop the attack.

It's mostly used for cloud-based analytics for proactive incident response. As an enterprise product, it falls under next-gen SIEM.

An advantage of Sentinel is that Microsoft has acquired RiskIQ as a threat intel platform and they've amalgamated it into the platform. When any analytical (or correlation) rule triggers, the enrichment is bundled within the solution. We don't need to input anything, it is there by default. Every rule is enriched right at the triggering or detection stage, which eases the job of the SOC analyst. The platform has become so intelligent compared to other solutions. When an alert is triggered, the enrichment happens so that we know exactly at that moment the true or false posture. This is a mature feature compared to the rest of the providers.

Most of our customers use M365 with E3 or E5 licenses, and some use Business Premium, which provides the entire bundle of M365 Security including EDR, DLP, Zero Trust, and email security. There are two native advantages for customers that use M365 Security and Sentinel. The first advantage is that the log or security-event ingestion into Sentinel is free. Cost-wise, they're saving a lot and that is a major advantage.

The other advantage is that when you use M365 Security with Sentinel, you get multi-domain visibility. That means when attacks happen with different kill-chains, in different stages through the email channel or a web channel, there is intelligence-sharing and that is a missing piece when customers integrate non-Microsoft solutions with Sentinel. With Microsoft, it is all included and the intelligence is seamlessly shared. The moment an email security issue is detected, it is sent to the Sentinel platform as well as to the M365 Defender platform. The moment it is flagged, it can trigger.

That way, if the email security missed something, the EDR will pick up a signal triggered by a payload or by a script being shared and will trigger back to the email security to put that particular email onto a blacklist. This cross-intelligence is happening without even a SIEM coming into play.

And a type of SOAR functionality is found within M365 Defender. It can run a complete, automated investigation response at the email security level, meaning the XDR platform level. When M365 Security is combined with Sentinel it gives the customer more power to remediate attacks faster. Detection and response are more powerful when M365 Defender and Sentinel are combined, compared to a customer going with a third-party solution and Sentinel.

Sentinel has an investigation pane to investigate threats and respond holistically from one place, where SOC analysts can drill down. It will gather all the artifacts so that the analysts can drill down without even leaving the page. They can see the start of the attack and the sequence of events from Sentinel. And on the investigation page, SOC analysts can create a note with their comments. They can also call for a response action from that particular page.

Also, most of the next-gen cloud analytics vendors don't provide a common MSSP platform for the service provider to operate. That means we have to build our own analytics in front of those solutions. Sentinel has something called Lighthouse where we can query and hunt and pull all the metadata into an MSSP platform. That means multi-customer threat prioritization can be done because we have complete visibility of all our customers. We can see how an attack pattern is evolving in different verticals. Our analysts can see exactly what the top-10-priority events are from all of our customers. Even if we have a targeted vertical, such as BFSI, we can create a use case around that and apply it to a customer that has not been targeted. We can leverage multiple verticals and multiple customers and see if a new pattern is emerging around it. Those processes are very easy with Sentinel as an MSSP platform.

Because we use 75 percent of the automation possible through the platform we are able to reduce MTTA. It is also helpful that we get all the security incidents including the threat, vulnerability, and security score in one place of control. We don't have to go to one place for XDR, another for email, another for EDR, and a fourth for CASB. Another time saver is the automated investigation response playbooks that are bundled with the solution. They are available for email, EDR, and CASB. As soon as a threat is detected, they will contain it and it will give you a status of partially or fully remediated. Most of our customers have gone for 100 percent automation and remediation. These features save at least 50 percent of the time it would otherwise take.

In terms of cost savings, in addition to the savings on log-ingestion, Microsoft Sentinel uses hyperscaler features with low-tier, medium-tier, and hot storage. For customers that need long-term data storage, this is the ideal platform. If you go with Securonix or Palo Alto, you won't see cost savings. But here, they can choose how long they want to keep data in a hot tier or a low or medium tier. That also helps save a lot on costs.

It's a Big Data security analytics platform. Among the unique features is the fact that it has built-in UEBA and analytical capabilities. It allows you to use the out-of-the-box machine learning and AI capabilities, but it also allows you to bring your own AI/ML, by bringing in your own IPs and allowing the platform to accept them and run that on top of it.

In addition, the SOAR component is a pay-per-use model. Compared to any other product, where customization is not available, you can fine-tune the SOAR and you'll be charged only when your playbooks are triggered. That is the beauty of the solution because the SOAR is the costliest component in the market today. Other vendors charge heavily for the SOAR, but with Sentinel it is upside-down: the SOAR is the lowest-hanging fruit. It's the least costly and it delivers more value to the customer.

The SOAR engine also uniquely helps us to automate most of the incidents with automated enrichment and that cuts out the L1 analyst work.

And combining M365 with Sentinel, if you want to call it integration, takes just a few clicks: "next, next finish." If it is all M365-native, it is a maximum of three or four steps and you'll be able to ingest all the logs into Sentinel.

That is true even with AWS or GCP because most of the connectors are already available out-of-the-box. You just click, put in your subscription details, include your IAM, and you are finished. Within five to six steps, you can integrate AWS workloads and the logs can be ingested into Sentinel. When it comes to a third party specifically, such as log sources in a data center or on-premises, we need a log collector so that the logs can be forwarded to the Sentinel platform. And when it comes to servers or something where there is an agent for Windows or Linux, the agent can collect the logs and ship them to the Sentinel platform. I don't see any difficulties in integrating any of the log sources, even to the extent of collecting IoT log sources.

Microsoft Defender for Cloud has multiple components such as Defender for Servers, Defender for PaaS, and Defender for databases. For customers in Azure, there are a lot of use cases specific to protecting workloads and PaaS and SaaS in Azure and beyond Azure, if a customer also has on-premises locations. There is EDR for Windows and Linux servers, and it even protects different kinds of containers. With Defender for Cloud, all these sources can be seamlessly integrated and you can then track the security incidents in Microsoft's XDR platform. That means you have one more workspace, under Azure, not Defender for Cloud, where you can see the security incidents. In addition, it can be integrated with Sentinel for EDR deep-dive analytics. It can also protect workloads in AWS. We have customers for whom we are protecting their AWS workloads. Even EKS, Elastic Kubernetes Service, on AWS can be integrated, as can the GKE (Google Kubernetes Engine). And with Defender for Cloud, security alert ingestion is free

Only one thing is missing: NDR is not available out of the box. The competitive cloud-native SIEM providers have the NDR component. Currently, Sentinel needs NDR to be powered from either Corelight or some other NDR provider. It needs a third-party OEM. Other than that, it supports the entire gamut of solutions.

Also, we are helping customers build custom data-source integration. Microsoft needs to look at some strategic development on the partner front for out-of-the-box integration.

We are an MSSP and we have offered Microsoft Sentinel as a service to our customers for close to one and half years. Before I joined this organization, I worked with another organization that provided Microsoft Sentinel as a service for close to one year.

The platform is pretty stable. I generally do not have any problems with it unless an issue arises while deploying a playbook. The platform is 98 percent stable. That other 2 percent only happens when you start working deep on customization. Out-of-the-box, everything has been tested and there aren't any problems. But when you try to create something on your own, that's where you may need Microsoft support.

You can scale it as much as you want. There are no limitations on scaling it.

It supports multi-region environments. Even if it is a large organization with multiple regions and multiple subscriptions, it can collect the data within the regions. With GDPR, logs should stay within the country. The solution can comply with the law of the land and still serve multiple locations.

Sentinel Lighthouse is not only meant for MSSPs. A large organization with diverse geography can meet the local data-residency laws, and Lighthouse will still act as a platform to connect all the regions and provide a centralized dashboard and visibility as an organization. So it can work if the customer has only one region and if there are multiple regions. It is a unique platform.

Also, every six months they develop a lot of playbooks as well as from the marketplace, the Microsoft Sentinel Content hub. MSSPs like us can use it to create content and put it into the marketplace so that other customers or service providers can use them. Similarly, when those parties develop things, they are available to us.

Microsoft is almost too active. We receive something new to offer to our customers every month or two. We also operate Splunk and QRadar but we see a lot of activity from Microsoft compared to the other vendors. That means we have a lot of value-adds to offer to our customers. These updates do not go to the customer by default. As a service provider, that helps us. We are the enablers, and a lot of these updates are free of cost for Sentinel users.

I would rate Microsoft technical support at five out of 10 because we have to go through a lot of steps before we get to the right technical stakeholder. They have to improve a lot.

Neutral

As an MSSP we also use Splunk, Qradar, and Micro Focus ArcSight. We added Microsoft as well because of customer demand. 

Existing customers that are doing a tech refresh are going for cloud-native. Digital transformation has been the driving factor. A lot of our customers have embraced microservices and they're looking for a new-age, cloud-native SIEM to support cloud-native solutions. For most of our customers that are looking at migrating to Sentinel, the major factor is the cloud. They have moved their data center servers to AWS or GCP or Azure.

The initial deployment is straightforward. There are only two or three methods, depending on whether it is on-premises log collection or M365 all-cloud, in which case it is API-based with out-of-the-box APIs. Within a few clicks, we can integrate it. It is simple and fast.

If we're dealing with all-M365 components and Azure components, we can complete deployment within a day. If we're dealing with the customer-log collection, it depends on the customer. There are some prerequisites required, but if the prerequisites are ready, then it takes, again, a day or so.

The number of people involved depends on the situation, but if there is not much more than out-of-the-box deployment, a maximum of two L1 engineers can complete all the activity.

From my perspective, the ROI is good because Microsoft keeps getting new things done without any additional cost. Every quarter there is at least a 10 to 15 percent increase with add-on components and content that are free. That is a type of enrichment that customers receive that they do not get from any other platform.

Microsoft gives a discount of 50 percent but only for customers that are clocking 100 GB and above. They should also look at medium and SMB customers in that regard.

There are a lot of advantages for customers with a Microsoft ecosystem. They need to know the tricks for optimizing the cost of Microsoft Sentinel. They need to work with the right service provider that can help them to go through the journey and optimize the cost.

For Microsoft security products there is a preview mode of up to six months, during which time they are non-billable. The customer is free to take that subscription and test it. If they like it, they will be billed but they have six months where they can evaluate the product and see the value. That is the best option and no other vendor gives a free preview for six months.

Other solutions will have two updates a year, maximum. And most of them are not updates to the features but are security or platform-stability updates. Microsoft is completely different. Because the platform is managed by them, they don't give platform updates. They give updates on the content that are free. They keep adding this data, which is helping customers to stay relevant and updated.

Our customers see a lot of value from that process. Some 60 to 70 percent move from preview mode to production.

The challenge with competitive products, or any SIEM, is that they are use-case specific: You define some correlation and they will detect it. Some of the next-gen solutions today work with analytics but the analytics are limited to the logs that have been registered. Other platforms are also not able to pinpoint the inception point of the attack. Once the attack is being reviewed, they will use log sources of that particular attack and will drill down into that particular attack scenario, but they're not able to group the attack life cycle: the initiation of that attack, and the different stages of the attack. The visibility is limited when it comes to other SIEMs.

But Sentinel has something called Fusion, which can give you multi-stage attack visibility. That is not something available from other SIEM vendors. Fusion is a very special kind of detection. It will only trigger when it sees the linkage between multiple attacks detected by multiple data sources. It will try to relate all the attacks and see if there is a link between them. It gives you a complete footprint of how that attack started, how it evolved, how it is going, and which phase it is in now. It will give a complete view of the attack, and that is a missing link compared with other SIEM vendors. This is a unique feature of Microsoft Sentinel.

Sentinel's UEBA is around 90 percent effective, and the threat intel is a 10 out of 10, but it is an add-on. If a customer takes that add-on package, it will give complete threat intel and visibility into the deep and dark web. In addition, it helps a customer to track the external attack surface. It is a comprehensive threat intel platform. 

The Sentinel SOAR is a 10 out of 10 and, if I could, I would rate it higher. Other SOAR platforms do not help reduce the price. A customer may not be able to use them after some time because they charge per SOC analyst. With Microsoft, there is no limitation on SOC analysts. It is purely billed based on consumption, which is a great advantage. Every customer can use it. It is free for up to 4,000 actions. Even if a customer goes to 50,000 actions per day, which is normally what a large-volume customer will do, he'll be charged $50, and no competitive SOAR vendor is in that league.

Understand the product capabilities first and, before finalizing your product, see how we can optimize your solutions. Also, try to see a roadmap. Then plan your TCO. Other SIEMs do not give you the advantage of free log ingestion, but if you want to understand the TCO, you need to know what your organization is open to adopting. If you integrate Microsoft solutions in different places, like cloud or CASB, it is going to give you more free ingestion and your TCO is going to be reduced drastically.

Organizations that have a Microsoft E5 license have an advantage because all the Microsoft components we have talked about are free. Unfortunately, we have also witnessed that most of our customers with an E5 license are not using the product features effectively. They need to see how they can leverage these services at the next level and then start integrating with Sentinel. That will give them a better return on investment and a proper TCO.

The platform gives you the ability to do 100 percent automation, but it is up to the service provider or the customer to decide what the percentage should be. The percentage varies from organization to organization. In our organization, we are using 75 percent of the automation before it reaches a SOC analyst. At a certain point, we want to see our SOC Analyst intervene. We want to do that remaining 25 percent manually, where the analyst can call for further responses.

Threat intelligence, in my opinion, is not generally going to work in a predictive mode. It is more a case of enrichment and indicators of compromise. It can only help in direction and correlation, but may not take you to a predictive mode, except if we talk about external attack surface management. The threat intel feed is going to give you an indicator of compromise and that will help you to be proactive but not predictive.

Whereas the external attack surface management and deep and dark web monitoring will monitor all your public assets. If a hacker is doing something in your public-facing assets, it will give a proactive alert that suspicious activities are happening in those assets. That will help my SOC analysts to be predictive, even before an attack happens. If somebody is trying brute force, that's where the predictive comes into play. The deep and dark web monitoring will help to monitor my brand and my domain. If hackers discuss my critical assets or my domain within a dark web chat, this intel can pick that up. In that case, they can say something predictively and that they are planning for an attack on your assets.

In terms of going with a best-of-breed strategy rather than a single vendor's security suite, customers need to be smart. Every smart solution keeps its intelligence within the solution. If the landscape includes email, web, EDR, et cetera, at a bare minimum there are eight different attack surfaces and everyone can have different controls. A SOC analyst will have to manage eight different consoles and have eight unique skill sets with deep knowledge of each product. So although individual solutions bring a lot of things to the table, the customer is not able to use those features 100 percent. We are failing when we go with individual products. An individual product may be more capable, but an organization will not be able to use the product effectively. The silos of intelligence, the number of different consoles, and the right skill sets to apply to each product are problems.

In addition, attacks are evolving and the software is evolving along with them. A product vendor may release some new features but the customer won't have the right skill set internally to understand them and apply them.

But with a single-vendor situation like Microsoft, the SOC analyst has nowhere else to go. It is one XDR platform. All the policies, all the investigation, and everything they need to apply is right in one place. There are also more Microsoft-Certified resources in the market, people who are certified in all the Microsoft products. All of a sudden, my skill set problem is solved and there is no need to look at multiple consoles, and the silos of intelligence are also solved. All three pain points are resolved.

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.

We primarily use the solution for security purposes, to record events, and generate alerts, so that our security team can review the items and take proper action.

We work jointly with an MSSP, we have about 14 people working on a 24/7 schedule, around 25 people might use our Sentinel workspace regularly, and more than 40 people benefit directly from the output of this solution.

With Microsoft Sentinel we have detected threats in early stages of an attack through custom detection rules, helping us prevent escalation and further compromise.

Sentinel has provided visibility of administration events, which allows us to audit security processes and discover misconfigurations and errors.

Using Sentinel we have definitely saved time in our detection and response efforts.

Microsoft Sentinel as a SIEM uses KQL (Kusto Query Language) in their detection rules, which is an optimized query language with some really powerful functions. Generally SIEM vendors use different query languages. KQL queries can use complex logic and be executed in a few seconds, which would not be possible or may take up several minutes in other SIEMs, and now some vendors are trying to implement their own version of KQL.

Sentinel provides us with good visibility of threats. The different kinds of logs it ingests are good as long as the log sources are correct. It can integrate some out-of-the-box log sources in a short time, and log data fields are usually very complete. We don't have experience integrating custom log sources, but it should be possible.

Out-of-the-box log sources have the same data structure in all Sentinel workspaces, which allows queries and detection rules to be shared easily between Sentinel customers. We could rapidly adapt to a new threat with public detection rules created by Microsoft or other security professionals.

We work with Microsoft Sentinel and other Microsoft security solutions like Defender. We've integrated all of them together easily from their web portals. As long as you have the right privileges, integrating these solutions might be as simple as a click. Microsoft security solutions work natively together to deliver coordinated detection and response, which is important to us.

Sentinel allows us to ingest data from our entire ecosystem, wether it might be an on-prem or cloud service. It allows us to correlate different data tables, to create complex threat detections, and to investigate holistically across our infrastructure.

I like the automation portion of the product, it helps us automate routine tasks. We have created some automation playbooks in Microsoft Sentinel, however, in our environment these are not specific to security tasks.

Microsoft Sentinel has a lot of out-of-the-box detection rules. Many of these rules have not been tested, they may execute but they have errors or do not work as expected. Due to this I've made more than 80 requests for modifications in Microsoft Sentinel public repository. If you want to ensure that Sentinel detection works, you need to review the logic of the detection rules one by one, and this shouldn't be the case.

Sentinel does not seem to have rules by default that check and notify of execution errors. I have had to create custom rules to detect when a log source or automation rule stops working as expected.

There can be discrepancies between Microsoft tools. Not all information appears in Sentinel. Sometimes there are items provided in Microsoft 365 Defender that you could search for in Sentinel and you would not find them and therefore assume they do not exist.

The solution is powerful but it can be expensive. Other solutions that are on-premises should be cheaper.

I've been using the solution for more than three years.

The solution is largely stable but not completely. I have had issues with some log sources that stop being ingested or are delayed, and also with automation rules not responding to incidents. Sometimes automation rules stop working intermittently, and this issue might happen during a month or two, and then they go back to working as expected without being notified of any issue by Microsoft.

The scalability is excellent, Sentinel has some limits regarding the amount of ingested data and enabled Sentinel resources, but these limits exist for extreme cases, which our workspace and organization are not even close to.

I'd rate it ten out of ten.

I've opened many support tickets. When you open a support ticket, it will typically be resolved within the first interaction. And they've solved all of my support tickets quite quickly. Even if I have made a mistake when opening support tickets, it's always been a positive experience.

Positive

I've used a few different solutions, including ArcSight, LogRhythm, and QRadar. 

I don't have much insight into ArcSight.

LogRhythm did not let me create complex detection rules.

With QRadar, when we are looking at queries, they can be slow. However, IBM is trying to create its own KQL implementation for QRadar in order to make them faster. 

But I don't have the same level of administration experience with these tools than with Sentinel.

We had some cloud engineers who created our instance on Azure. They enabled the connectors for some out-of-the-box log sources, and created other kinds of neccesary resources, specially to connect on-premises resources to Sentinel. We did not have issues that didn't depend directly on us.

At first we enabled all the detection rules we could, without deeply inspecting them, we assumed they would work. We would not take this approach again, detection rules should be reviewed and enabled one by one.

Maintenance is minimal. It's all on the cloud. If something does not work as expected, we open a support ticket. Since the tool is supported by Microsoft, you are paying them to also maintain it, basically.

Our implementation was handled in-house.

I would recommend to check regularly for deviations or unexpected surges of ingested events, which will affect the cost. I do not directly handle the pricing portion of the solution. There is a calculator in Azure that helps you estimate the cost. 

It's ideal to go with a best-in-breed strategy rather than a single vendor. You need to know what is available in the market. Companies should be free to use any security tool that they consider to fit their needs. 

For companies considering Sentinel, they need to ensure a threat detection engineer will be available to manage their detection rules, you shouldn't enable all of them blindly. You may get value from Microsoft Sentinel, however, you need to continuously invest time and ensure everything is set up and working as expected. 

I'd rate the solution nine out of ten. 

My customers mainly want to correlate logs so that they have a single point for their log information. In addition to correlating logs, they want to automate tasks.

Microsoft Sentinel is just a "watch tower" to get all the logs and manage threats. After that, you have the Microsoft Defender products that help to reduce threats. For example, Microsoft Defender for Endpoint is an anti-virus and EDR that helps to eliminate threats on devices such as laptops and smartphones. Microsoft Defender for Office 365 enables protection for Teams, Mail, or SharePoint, and Microsoft Defender for Identity helps to reduce risk on Active Directory or Azure AD. So Microsoft Defender products are the tools for reducing threats, and Microsoft Sentinel is the tool for analyzing incidents and threats.

Each time I deploy Sentinel, it helps the client get information about the overall security of their IT system. It brings together all the logs in a single place, so it's easy to track attacks and get information about breaches.

It also eliminates having to look at multiple dashboards. If you centralize the logs, you don't need to go to the firewall to get alerts or to the antivirus console or to a network device. You get everything in a single place, which means you have incidents in a single place, and then you can have a dashboard. You can check the built-in dashboard, or you can create one on your own, and these dashboards can be refreshed automatically or you can refresh them whenever you want.

The solution is well integrated with the Microsoft environment, so if a customer has a lot of Microsoft services, such as M365 or Azure, the solution fits well in their environment. Because I deploy solutions in general, I also use Microsoft Defender for Endpoint, Microsoft Defender for Identity, Microsoft Defender for Cloud Apps, and Microsoft Defender for Office 365. It's really straightforward to integrate these products. You have just to check a box and all the logs from these products go to Sentinel. And if the customer has a Microsoft 365 E5 license, the Defender logs are free.

It also helps to prioritize threats across an enterprise. When you receive an alert of an incident, you can categorize it as a low, medium, or high priority. That's really important because sometimes low-priority incidents are just false positives. We need to categorize incidents to get to the high-risk incidents.

Sentinel also enables you to ingest data from your entire ecosystem and not just from the Microsoft ecosystem. It can receive data from third-party vendors' products such as firewalls, network devices, and antivirus solutions. It's not only a Microsoft solution, it's for everything. There are native connectors to get information from third-party vendors, but if you don't have a connector for something, you can get information from protocols such as syslog.

It's really important that Sentinel allows you to investigate threats and respond holistically from one place. It's important to know where an attacker went. For example, an attacker could go through a firewall and then to a specific application, and you need to know where the attacker started first.

When you enable this feature, Sentinel automatically gets information about the users and devices, and you can then search for specific entities. For example, if you know that a specific user is at risk, you can enter the username and get all the information about the user: on which device he's connected, to which servers he's connected, and what he did on these devices, among other things. This ability is important to a breach.

With Sentinel, you have some built-in rules to automate tasks. You can also create your own automation based on Logic Apps in Azure. You can do what you want with scripting with PowerShell or Python. The first time you have a given incident, you do some troubleshooting and when you write up this incident you can create a knowledge base. Once this knowledge base is done, you can try to automate the troubleshooting. If you do it via automation, you can close this incident because the incident will be managed automatically with Sentinel. And that helps you to save time.

Sentinel should be improved with more connectors. At the moment, it only covers a few vendors. If I remember correctly, only 100 products are supported natively in Sentinel, although you can connect them with syslog. But Microsoft should increase the number of native connectors to get logs into Sentinel. Each time we have a connector, it eases the configuration of Sentinel, and we don't need custom deployments to get the information from a specific vendor. 

The second thing they should do is create more built-in rules for the dashboard, automation, and hunting. The first time you use Sentinel, it's not easy to use the product because, beyond the dashboards, you need to know the Kusto Query Language (KQL) to create the right requests.

I have been using Microsoft Sentinel for two years. I implemented the solution for a customer a couple of months ago.

There is no problem with the stability of Sentinel. It's really stable. I have never experienced an issue with accessing the product.

It's a SaaS solution, so you don't need to scale it. It scales by itself. 

If you need a multi-tenant implementation, for example, if you have a SOC and you have several customers, you can get your own Sentinel, and you can ask the customers to deploy Sentinel in their environments. You can then gather logs from several Sentinels in a single point.

I haven't contacted Microsoft for support of Sentinel, but each time I contacted them for other products, it was a bad experience. The technical support of Microsoft is a negative point because, most of the time, they don't have the answer.

I used QRadar and a Symantec solution, but that was 10 years ago.

The first deployment was not complex. The first step, when you want to connect a solution to Sentinel, is pretty straightforward. When you want to use the built-in dashboard, it's also straightforward. But once you want to do some customization, like a custom dashboard, custom automation, or custom hunting rule, it can be complex because you have to know several languages, how Log Analytics works, and how Logic Apps works for automation.

Most of the time, I deploy a single Sentinel in a single location because it is a worldwide SaaS solution. And most of the time I deploy Sentinel to be used on-premises and in Azure, and I deploy Azure Sentinel for a SOC team. I have never deployed a multi-tenant Azure Sentinel setup, although it's possible to do.

In the beginning, when a customer uses Sentinel, they cannot use it on their own. They require some assistance. That is why, after deployment, a consultant is usually onsite two days per month to add some connectors and custom rules, and to end some incidents.

Sentinel is a pay-as-you-go solution. To use it, you need a Log Analytics workspace. This is where the logs are stored and the cost of Log Analytics is based on gigabytes. You can get a discount of 10 percent if you get to 100 terabytes of data. On top of that, there is the cost of Sentinel, which is about €2 per gigabyte.

If a customer has an M365 E5 license, the logs that come from Microsoft Defender are free.

The solution is really easy to deploy compared to other solutions such as Splunk.

Taking proactive steps to prevent breaches is a default. It's not like competitors on the market. Sentinel doesn't give you advice about how to set some settings on your device to protect them from a specific breach. But you can use Microsoft Defender for Endpoint for devices and it helps you to know if a device is breachable from a specific attack and how to be protected against it.

The cost and ease of use of Sentinel compared with other standalone SIEM and SOAR solutions depends on whether the customer has the whole stack, meaning an M365 E5 license. If so, they get a really good discount because all the logs from Microsoft Defender are free. But if they don't have an M365 E5 license, those logs are not free and the solution can be expensive.

We haven't evaluated other options recently because our customer wanted Sentinel. But one of the differences I see between Sentinel and competitors' solutions is in the normalization of logs. With Sentinel, normalization is done automatically, whereas with other solutions, you need time to do the normalization manually. By "normalization" I mean lining up the fields. For example, in some logs, the time is in the first field, while in other logs, the description is in the first field. You need to sort the fields, but this task is done automatically by Sentinel.

Before using Sentinel, I recommend reading the documentation and watching the YouTube Ninja Training channel. They go through all options for Sentinel. 

In addition, I recommend knowing KQL—it's a requirement—and how to automate tasks in Azure. Other than these points, Sentinel is easy to enter because if you have a native connector, it's just "next, next, next." But when you want to do customization, it can sometimes be hard to do what you want.

When you look at going with a best-of-breed strategy versus a single vendor's security stack, it depends on the strategy of the customer. Sometimes, the customer prefers to get all its security products from a single vendor because they get discounts when they do that. Other customers prefer to have several vendors for security reasons. From my point of view, there is no correct answer. If I were responsible for the security of a company, I think I would prefer to use an all-Microsoft security stack because it's easier to interconnect the solutions and you get more information as a result.

We use Sentinel to manage data based on data connectors and log sources. We have to build the use cases. I create policies and periodically fine-tune them. There are a lot of cloud applications for that, like Microsoft Active Directory, Office 365, and Microsoft Identity Protection.

For instance, when a privileged account's password is changed frequently, it should trigger an alert and will create an incident. Another use case is the ability to summarize all DB activity.

We also use Defender for Endpoint, and I have experience with Defender for Cloud and Microsoft Identity Protection.

The cloud-native solution covers an entire IT organization. It could be located in China, Russia, Pakistan, or India. It doesn't matter.

This solution is mostly deployed on the cloud. The solution is used across our entire organization. There are more than 1,000 end users.

The solution increases security. It also reduces complexity because we can monitor everything from a single solution. We can manage a firewall, servers,  connected DOS, etc. Even if it's a third-party application, we can manage it.

The solution helps automate routine tasks and find high-value alerts. For example, we can create analytical rules and build the use cases so that any suspicious incoming traffic is blocked.

The solution has eliminated the need to look at multiple dashboards. Everything is accessible from a single dashboard.

Our team is currently being trained on how to use threat intelligence to help prepare and take proactive steps for potential threats before they hit. If there are any zero-day vulnerabilities, Microsoft will update the platform, so that all of the organizations that use Sentinel will have coverage. 

I like the KQL. It simplifies getting data from the table and seeing the logs. All you need to know are the table names. It's quite easy to build use cases by using KQL.

Sentinel provides visibility into threats. It provides anonymous IP and URL detection in our environment. We can easily get the logs.

It helps prioritize threats in the organization. We can build analytic rules. Microsoft Sentinel provides a lot of alternative use cases, but we have to prepare them.

Sentinel enables us to ingest data from our entire ecosystem because it's a cloud-native SIEM. We can integrate everything into Sentinel. In any organization, log management is an important aspect. For auditing and compliance, an organization has to validate the logs.

Sentinel enables us to investigate threats and respond holistically from one place. There's an incident option that allows us to view information about a specific instance, an anomaly, and activities that have happened in the last 24 hours. It will show the specific incident, the host, the time, and what the user is accessing. It shows everything in a single pane, which is very useful.

There's a lot of technical documentation for automation. It's easy to understand. You can build it according to your needs. You can automate playbooks. You can integrate a number of digital platforms into your environment.

The performance could be improved. If I create 15 to 20 lines for a single-use case in KQL, sometimes it takes more time to execute. If I create use cases within a certain timeline, the result will show in .01 seconds. A complex query takes more time to get results.

I have used this solution for two years.

The solution is very stable. We haven't experienced any outages so far. There is a failover function. If a region has an outage, there is backup support, which is advertised in the software on SIEM.

The solution is scalable.

I would rate technical support as nine out of ten. 

We previously used Splunk. We switched because of the cost.

I wasn't involved in deployment. Maintenance isn't needed often.

Sentinel saves us time. KQL is fast. The response of the query output is quick compared to other products. We can create a lot of automation in that particular environment, which reduces the workload for a lot of false positives. 

Logic App allows us to create mini-automations. XOR plays a huge role in Microsoft Sentinel. It automates soft operations workloads.

The solution saves us time by 75%. By using automation instead of working on a specific incident for 30 minutes, it takes a maximum of five minutes. 

This solution saves us money. Microsoft offers discounts if you purchase GB per day.

Sentinel decreases the time it takes to detect and the time it takes to respond by 70%.

In a protected cloud, Microsoft is quite manageable. It allows you to pay as you go. If you're replacing cloud resources, you'll eventually have thousands of virtual machines, but you'll be able to pay for only 500 virtual machines.

The pay-as-you-go model is beneficial to customers.

My organization tried an open-source platform, but it didn't give a proper output, so we compiled some other solutions. We prefer Microsoft products, so we went with Sentinel. 

I would rate this solution as nine out of ten. 

To a security colleague who says it's better to go with a best-of-breed strategy rather than a single-vendor security suite, I would say that if you have a single-bundle security solution, you can cover all of your security needs in an IT organization. It's beneficial for support, makes data visibility clearer, and improves security. I would recommend a single-bundle security solution as a better way to go for deployment.

My client has a huge environment in Azure. They have around 30,000 resources spread across the globe. They also have a huge presence on-premises itself. So, for on-prem, they have a SIEM solution already in place. But for the cloud, they didn't have anything. So, basically, no visibility into any kind of attacks or any kind of logging or monitoring in the cloud. We could not scale up our on-prem counterpart for it due to various reasons of cost and how much resources it would take. Microsoft Sentinel seemed like a pretty good solution since it's cloud-native, it's hosted by Azure itself. So we went ahead with the solution.

Microsoft Sentinel has given us great visibility into our cloud workloads and cloud environment as a whole. And not just that, but even, in fact, with the MCAS and email-security solutions also. We get a lot of visibility into what kind of emails we are getting and how many of them are malicious versus legitimate. From a visibility and compatibility perspective, it's really a nice product to have as a SIEM solution for your cloud environment. In fact, we have integrated this with our AWS, as well. At this point in time, it's just one account, but we plan on expanding more. So all the logs from our AWS environment flow to the solution. Microsoft Sentinel performs the analytics and gives us the alert for that.

The comprehensiveness and coverage of multiple different solutions, on-prem solutions, and cloud solutions, are the two aspects, Microsoft Sentinel really has an edge over other products.

Visibility into threats is above average. Since I also went through some slides of Microsoft and they receive a lot of telemetry because of their Windows platform, because of Azure. What I saw in those slides is that they benefit from this telemetry and create a rich threat-intelligence, kind of a backend service, which supports Sentinel and literally enriches the detection capabilities for Microsoft Sentinel.

Correlation is something that helps us instead of looking at every single alert. So, if we get a phishing email and five users click on it, instead of going through five individual detections, it correlates all of that and presents it in one single incident correlating all these five events. So, in terms of that correlation, it is pretty good. In terms of responding to these alerts, I know there is some automation. There were multiple calls with Microsoft when we were setting up this solution. They showed us how we can do this and they gave us a demo, which was really nice to see the automation. But from the response point of view, we haven't enabled any automation as of now because we are still in the nascent stages of setting this up. We have done multiple integrations, but, still, there's a lot of ground to cover. So, the response is something we would look at last. I think the response side also has a lot of automation and correlation, but we haven't worked on that as of now.

The time to detect and time to respond has been reduced considerably. Detect, because the analytics that is done by Microsoft Sentinel is near real-time, and response is based on us. So, when we see the alert, we respond to it, and we wait on the teams to receive an answer. Previously, the SOC guys were doing this. It was really slow and, sometimes, proceeded at a snail's pace. With Microsoft Sentinel, at least one part of it got addressed, which was running these queries with the SIEM and getting to analyze multiple events to go onto a specific security incident. That time has been saved by Sentinel. I would say 20 to 30% of the time to respond and detect has been saved.

In terms of Microsoft Sentinel, I think a large part of it has been automated by Azure itself. From a customer point of view, all you have to do is just run some queries and get the data. In terms of connections or the connectors for multiple data sources or multiple log sources, it's very easy to just set it up, be it Azure-native services or something customized, like some connection with the on-prem servers or things like that, or even connections with the other cloud platforms, such as AWS. The connectors are really one thing I appreciate. I think it sets Microsoft Sentinel apart from other solutions. Apart from that, the analytics that it performs and the built-in queries that it has, are valuable. A lot of automation on part of Microsoft Sentinel is really commendable.

Microsoft Sentinel definitely helps prioritize threats across our enterprise. I think Microsoft Defender for Cloud would also come in when we talk about this because Microsoft Defender for Cloud and Microsoft Sentinel work in conjunction with each other. We can set it up that way so any alerts that are found in Microsoft Defender for Cloud are forwarded to Microsoft Sentinel. Then, the prioritization is set based on the standard criticality, high, medium, low and informational. So, from our sense, what we can do is, we can simply target the high incidents.

Another thing is that it very efficiently correlates all the events. So if multiple emails have been sent from a single email ID, which is supposed to be a phishing email, Sentinel identifies it, flags all the emails, and it can very beautifully track all of it from their console such as who clicked it, when did they click it, which ID was it, who received it. So, in terms of all that, correlation also helps us prioritize those events.

Prioritization is important. If we have a bunch of alerts and we started investigating some alerts that are not of that much value, some alerts would get ignored if the prioritization was not set correctly. So if it's a phishing attempt and, in another area, we find that there's a brute-force attack going on, we would first want to address the phishing attempt since, in my opinion, in my experience, the probability of getting a link clicked is high rather than a password getting compromised by a brute-force attack. So, in those terms, prioritization really helps us.

Microsoft Sentinel definitely enables us to ingest data from the entire ecosystem. Microsoft Sentinel has around 122 or 123 connectors. Although we haven't set up the solution for our whole ecosystem, be it on-prem, Azure Cloud, AWS cloud, or any other cloud for that matter, looking at the connectors, I feel like there's a whole lot of support, and possibly, we can cover our whole ecosystem, with some exceptions for some solutions. Exceptions are always there. From a coverage point of view, I think it's pretty good. We can cover at least 80 to 90% of our ecosystem. Obviously, it comes at a cost. So at that point in time, it could get very costly. That is one downside.

From the SOC point of view, everything depends on how good the data you are ingesting is and the amount of data you are ingesting. So, the more data we have, the better insights we would have into what activities are going on in our cloud environment, and in our on-prem environment. So it's very critical to have the right data ingested into things like Microsoft Sentinel. Otherwise, you could have a great solution but an ineffective solution in place if you don't have data ingestion configured in the right manner.

Investigations are something really remarkable. We can drill down right to the raw logs by running different queries and getting those on the console itself.

The number one area of improvement for Sentinel would be the cost. 
At this point in time, I feel like, simply because we are a huge organization spread across the globe, we can afford it, but small and medium businesses cannot afford it. Maybe it's not meant for them? I don't know; that's a debatable topic. But even for organizations like ours, a problem that we face and for some of my other friends that I have talked to, it's a great solution, but we cannot deploy it everywhere because, frankly, we overrun our budget.

One thing that would really help or benefit would be the alerts that get thrown up. I've seen multiple alerts. For example, external file activity or external user activity. I open those alerts and there is absolutely no information in them. If there's external user activity, then who is that user, what is something that they are doing, how did Microsoft Sentinel detect this, or what were the analytics based on this outcome that it was a malicious activity or there was something anomalous or something like that? There is some particular type of alerts where a bit more data enrichment would help us.

The alerts get thrown out, and this is something we generally see with any kind of SIEM or any kind of other detection-based solution. For example, in an EDR solution or a vulnerability solution, the typical problem is alert fatigue. We get so many alerts that we start to see a large amount of them, and then we don't know where to start. Although here, we have the prioritization already shared by Microsoft Sentinel, so we have a starting point, but then it never ends. Perhaps tweaking and reducing the number of alerts that get thrown out, and enriching those alerts with more data would help. A lot of these alerts are just very normal things. They are not security incidents in their truest form, but it does take up our time just viewing those alerts. And sometimes, it also lacks a lot of information, like who did what, at exactly what time, and why did Microsoft Sentinel think that it was a malicious incident. That is one question I see a lot of times myself and don't get an answer for, like, "Okay, I get this a lot, but why do you think it's a security event?" So, enriching those alerts with more data might be a good area of improvement for Microsoft Sentinel.

The number of dashboards is something we complained a lot to Microsoft about, "You have great solutions, but you have a different console or a different dashboard for everything. So, as a person who is responding to these alerts, it really becomes overwhelming juggling between multiple different screens, dashboards, tabs, and windows." They have acknowledged this and they have mentioned to us that a lot of other customers made the same complaint and they're working on integrating these dashboards. So, for example, if you are using Microsoft Defender for Cloud, in one click you can reach a Microsoft Sentinel page wherein it would show you the raw logs. It sometimes gets overwhelming viewing the same alert on multiple different dashboards. In one sense, if I had to give an example, you might see an alert on Microsoft Sentinel, but it won't have much data to it. To drill down to the very specific raw data, you would have to go to some other console. You would have to go to the source of that event or detection, be it Microsoft Defender for Cloud, MDI, or MCAS. So in those terms, we have to sometimes juggle through all these dashboards and tabs of multiple solutions.

I have been using the solution for eight months.

I think the solution is pretty stable. I didn't see any aberrations or anomalous behavior of Microsoft Sentinel. And that's the benefit of having a managed service. Downtime is quite less. Especially from providers like Microsoft. With Microsoft Sentinel, we didn't feel like there were any hiccups in the operations or any sort of problems we faced with the solution, as of now.

This is something good about having a managed product, you don't have to worry about scaling. And this is exactly the problem we felt with our existing on-prem solution LogRhythm: the scaling was not possible because of the cost included. With Microsoft Sentinel, you have to pay extra, but you don't have to worry about setting up more servers, configuring them, patching them, doing all the maintenance, and doing additional administrative work. The solution is pretty scalable.

Based on our interactions at the time of setup, after that, we didn't really require that much assistance from Microsoft. So, at the time of setup, they really helped us with insights and with decisions that we had to take based on our organization type and how we work. We have teams distributed globally across multiple time zones, and similarly, we have data and operations distributed all over the world. So this becomes a challenge when dealing with anything related to IT. So, Microsoft did really help us with setting it up. From a technical-assistance point of view, at the initial stages, it was a good experience.

Neutral

Our on-prem solution is LogRhythm and the reason we decided to add Microsoft Sentinel was scaling up of LogRhythm would have been a huge cost to us. Because right now, on-prem LogRhythm is running on multiple VMs, so their cost structure is very different. If you run the same setup on Azure, it's just an exorbitant amount of money. So that was one factor that we chose not to scale up LogRhythm to our cloud environment and looked for some other solution. The other reason we went for Microsoft Sentinel was that it is cloud-native. Since it's a managed service from Microsoft and from Azure themselves, not just time but also a lot of responsibility on our end gets transferred to the cloud provider of just setting up and maintaining that infrastructure, updating and patching all those systems, and doing that maintenance work. That overhead gets taken off our heads. That's why we were looking for a cloud-native solution. And hence, in our comparison, in our multiple rounds of discussion with internal stakeholders within the cybersecurity team, Microsoft Sentinel seemed like a perfect fit, so we went ahead with the solution.

The initial setup is pretty straightforward. We didn't face many problems or complexity. We had everything running in a couple of weeks. The deployment was just me and one other person from the security team. She had a lot more experience with Microsoft 365 and the MCAS side of things. And I was more from an Azure infrastructure point of view, Defender for Cloud and the like.

We started the deployment from scratch and we brought on Microsoft for assistance. We already have a huge presence in Azure, so we already had a Microsoft contact. We reached out to them. We mentioned that we want Microsoft Sentinel on board. We got in touch with their own cloud security and Microsoft Sentinel experts. They advised us, but I can say all the setup and all the operational side of things we did because if Microsoft did it then that would be handled by the consulting arm of Microsoft and that would be a full-fledged project, which would have its own cost. So Microsoft had to play a role as an advisor. We used to get about four IT calls to set it up. Whatever Microsoft recommended us to do, we went ahead with that.

First of all, we enabled everything that was free of cost. When you onboard Microsoft Sentinel, you pay some fee for the solution itself, and with that, you get some free connectors. So Azure AD sign-in and audit logs are one thing, Azure activity logs, and Microsoft Defender for Cloud are another. All these integrations don't cost anything extra over and above. So we started off with integrating all of that, and later on, slowly and steadily, we scaled up our integrations. There's still a lot of ground to cover. We aren't there yet with what we envisioned initially.

At this time I don't have an answer about a return on investment but it is something we have been contemplating inside our own team and we have been thinking of since we talked about how good a solution Microsoft Sentinel is. We cannot enable it across the organization, so we are thinking about creating a story of how much value, not in just terms of money but how much value in terms of security has the solution brought for us, and communicating this idea to other stakeholders in other teams and probably to the leadership, and maybe getting a little more budget for this project.

Microsoft Sentinel is definitely costly. If we factor in the cost of other services, MCAS, MDI, and Microsoft Defender for Cloud, it gets seriously costly, to the extent that we cannot enable it across the organization. It simply overshoots the budget by a huge margin. When talking about the Microsoft Sentinel piece itself, let's say we have set up custom integrations and it does not cost us that much, it is definitely costly. If we talk about log retention, then it is even more costly. Comparing it to the other solutions, in fact, when we started off with the SIEM solutions for the cloud, we did do a comparison between which one would be the best: the classic Splunk, like we used in our on-prem, or maybe Microsoft Defender for Cloud. So, for our use case, Splunk was also a bit costly but less than Microsoft Sentinel. We went ahead with Microsoft Sentinel being a cloud-native platform on our side, the effort would be a lot less. Splunk would require to be set up from scratch. From a cost perspective, Microsoft Sentinel is quite costly.

We compared Splunk with Microsoft Sentinel.

I give the solution an eight out of ten.

We have used and tested additional Microsoft solutions. At one point in time, we used Microsoft Defender for Identity, MDI solution, but it was for three to four months only. We discontinued it because it was more of an experiment and the guys from Microsoft gave us the license for that product for a limited time for testing. We were short on budgets, hence we could not leverage or we could not go ahead and purchase it. Another product was MCAS, Microsoft Cloud App Security. Primarily, we use Microsoft Sentinel. Microsoft Defender for Cloud is also used, but it has not been enabled on a lot of resources because it has a cost implication. So cost is a huge factor that we have to think about every time we do anything in security related to all these four products. 

Wherever it is possible, wherever we have identified some critical resources and we had the budget, we enabled Microsoft Defender for Cloud and then integrated it with Microsoft Sentinel. Integration is super easy for anything which is an Azure service. It's mostly about doing a couple of clicks or maybe running a couple of commands. For Azure-native services, it's very easy, be it integrating the Azure AD logs or Microsoft Defender for Cloud or things like that. If I remember correctly, I integrated Microsoft Defender simply by flipping a toggle on the console. So it was easy to integrate Microsoft Defender for Cloud.

The coordination among all these tools is really marvelous. Although my role is not exactly that of an incident responder or from a SOC point of view, if I was a SOC person or an incident responder, it really takes the load off of my work to look around and to correlate that, and open four, five tabs and just juggling through them and trying to make a story. Microsoft Defender for Cloud, Microsoft Sentinel, and MCAS, all of them do it for us. So you just have a single pane of glass. Although these are four different products and you sometimes do have to juggle around, but not to that extent. Many times, it happens that your job gets done with just a single pane of glass.

I think the coverage is comprehensive from a protection point of view for all these four, or five products from Microsoft.

The bi-directional sync capabilities of Microsoft Defender is an option that we get at the time of integrating the solution. This is exactly what I mean by using the toggle button to integrate Microsoft Defender for Cloud with Microsoft Sentinel.

I would say the sync capabilities are both critical and a nice add-on to have. Even if it's not critical and there was no sync between Microsoft Defender for Cloud and Microsoft Sentinel, we would still be doing our job of looking at two multiple portals. But since Microsoft does it for us, then it's really good to have. It takes the load off our shoulders and we could do other tasks and possibly look at more alerts instead of juggling through these portals between Microsoft Defender for Cloud, Microsoft Sentinel, MCAS, and MDI.

Investigations are something really remarkable. We can drill down right to the raw logs by running different queries and getting those on the console itself.
In terms of response, I do not have that much experience in automating the responses or letting Azure handle it, because we feel like the automation here might go wrong and we might have to face another incident caused by some sort of misconfiguration. So, at this point in time, we respond manually to the alerts. We don't use many of the response capabilities of Microsoft Sentinel. I did have a look at what I think, these are called playbooks, which are based on LogicHub. They do seem very promising, but we haven't used those functionalities as of now.

If I had to rank the three capabilities in terms of comprehensiveness, at the top would be SOAR. I would put threat intelligence and UEBA second. I haven't used both of these capabilities that much. We haven't enabled UEBA in our environment. Threat intelligence is the default one. Again, this is something we haven't enabled on a custom basis or something add-on; it's the default one that Microsoft provides.

In regards to proactiveness, I don't feel like there is anything proactive about the solution. It's mostly reactive. The nature of the whole SIEM is reactive: you analyze the logs, you get some alerts, and then you react to those alerts. I think in terms of prediction, I don't see it like that. But in terms of using threat intelligence, I definitely think that it really adds value when, for example, there's something legitimate in the email, there's something malicious. But when it comes to the unknown, when you cannot determine if it's good or bad, it adds value there, its threat intelligence, by simply stating that. Just a couple of days back, we had an alert that said that "URL was clicked," and it wasn't able to determine the nature of the URL: Was it malicious? Was it bad? So it gave us a low or an informational alert. Threat intelligence helps us in those situations.

The solution has saved us time in two aspects. A tremendous amount of time is saved in terms of integration. Nowadays every organization across any sector you talk about has a lot of IT solutions and security solutions in place. You talk about network devices, VPNs, security devices, these collaboration services, et cetera, all of these generate a lot of data integrating and investing all of that data into SIEM is really critical for the SIEM to function properly. That is something that Microsoft Sentinel does quite well. And I see that they are always working on not just creating those integrations but also making them very easy to configure, from a customer point of view. So, those integrations are one thing that I really like about Microsoft Sentinel. The second is the correlation of these alerts across multiple of these integrations. So, integrations and correlations are two aspects that I really like about the solution. I would say the solution saved me around 50% of the time. Simply, it's less of running the queries on a standard SIEM solution and more of clicking on the dashboards. So the typing time gets taken off and the loading time of getting the results back, and doing this over and over again with a typical SIEM solution, that has been absorbed, by the solution. Microsoft Sentinel does it for us. Our time has been saved in that sense.

I would say that, since the solution saved us time, and time is money, in that sense, the solution has saved us money. On the other, hand the solution's cost is such that it might have balanced out. So, I can say it saved us money in one sense, but I don't think it's because of the solution, it's because of how the processes are set up in our firm. When we find some detections primarily from Microsoft Defender for Cloud, we share it with the team and we get to know that "XYZ resource is not in use anymore," and it probably gets deleted. So, in that sense, resource getting deleted, obviously, would stop incurring the money and the extra cost that we would have been paying. In that sense, our money is saved, but I wouldn't really put Microsoft Sentinel there because if there was any other solution that would also do the same, the resource would eventually get deleted.

Microsoft Sentinel runs on top of Log Analytics. And right now, we have it just hosted in the European region, but logs get ingested from all over the world, and the logs are of all types. Such as Microsoft Defender for Cloud, Azure AD sign-in logs, audit logs, Azure activity logs, and MCAS. We stopped using MDIs. We also have AWS. From AWS, there is a couple of log types. I think it's the CloudTrail, and events around S3 buckets and Kubernetes, although we don't use Kubernetes. That is all that is configured as of now with Microsoft Sentinel.

Four people in our organization use the solution. We have a dedicated SOC team, two guys are from the SOC team: one is me, and one is another person who has experience with Microsoft 365, and two people from the cybersecurity team.

I don't think there is any maintenance required. But there is overhead administration. So far, what I have experienced, it's just about integration. If you have to get started with the integration, then that's the overhead administrative effort on your head. Otherwise, it's not much of a problem. Everything is pretty smooth and automated with regard to maintenance.

There's one guy in our organization who for some reason, doesn't really like Microsoft and its products. He thinks that it's a way for them to catch us in a net and then upsell all their services to us. But I have a different, opposing view. I think, yes, they do have their own strategy of upselling and cross-selling all their products and solutions, but I think they are pretty good when working with them with those solutions, be it Azure as a whole cloud service, or just one part of it like Microsoft Sentinel. It takes off a lot of overhead, also, in terms of when you want some support, since it's a one-vendor-based solution, they would be much more helpful to support you and give you the right resolution in comparison to having three different products from three different vendors. What happens is, more often than not, they all start blaming each other, and then there's a blame game going on, and we, as a customer, have to suffer with whatever problem we are dealing with. So, I would go with having one vendor's solution, provided the vendor is not the kind of vendor that just sees you as a cash cow.

The only advice I would give to someone is that when you are evaluating the solution, if possible, you onboard people from Microsoft so they can help you and guide you. It's their product, they know how to best use it. So you would be in a better position right from the get-go, and it would also save a lot of time and effort in case you did something wrong or you chose a bad design decision, which might end up wasting a lot of time in the future. So, one piece of advice I would say is, simply to onboard Microsoft and it won't cost you extra. I don't think it would cost you extra. If you are already using any good Azure service or Azure itself, then that could be possible with the help of the account manager and the relationship that you have already with Microsoft.