Microsoft Sentinel Reviews

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.

Our first use case is related to centralized log aggregation and security management. We have a number of servers at the user level and data center level, and I cannot use multiple tools to correlate all the information. My overall infrastructure is on Azure. We have a hybrid approach for the security environment by using Sentinel. So, hybrid security is one of the use cases, and unified security management is another use case.

It has helped us in three ways. One is IT, one is security, and one is compliance. Before Sentinel, our IT was mature, but our security and compliance were not mature enough in terms of certain controls, client requirements, and global-level regulatory compliance. By implementing the SIEM along with Security Center, we have improved security to a mature level, and we are able to meet the compliance reporting and client requirements for security within the organization.

It has an in-depth defense strategy. It is not limited to giving an alert; it also does correlation. There are three things involved when it comes to a SIEM solution: threats, alerts, and incidents. Sentinel gives you granular and concise information in the UI format about where the log has been generated. It doesn't only not give the timestamp, etc. This information is useful for the L1 and L2 SOC managers.

It has good built-in threat intelligence tools. You can configure a policy set and connectors, and you don't need to have any extra tools to investigate a particular platform. We can directly use the built-in threat intelligence tools and investigate a particular threat and get the answers from that.

We are using Microsoft stack. We use SharePoint. We use OneDrive for cloud storage. We use Teams for our internal productivity and communication, and we use Outlook for emails. For us, it provides 100% visibility because our infrastructure is on Microsoft stack. That's the reason why I'm very comfortable with Sentinel and its security. However, that might not be the case if we were not in Microsoft's ecosystem.

We are using Microsoft Defender. The integration with Microsoft Defender takes a few seconds. In the connector, you just need to click a button, and it will automatically connect. However, for data ingestion, it will take some time to configure the backend log, workspaces, etc.

It is useful for comprehensive reporting. We need to prepare RFPs for our clients. We need to do reporting on particular threats and their resolution. So, it is useful for our RFPs and our internal security enhancements.

It is helpful for security posture management. It has good threat intelligence, and it provides deep analysis. The security engine of Microsoft Sentinel takes the raw data of the logs and correlates and analyses them based on the security rules that we have created. It uses threat-intelligence algorithms to map what's happening within a particular log. For example, if somebody is trying to log into an MS Office account, it will try to see what logs are available for this particular user and whether there is any anomaly or unwanted access. It gives you all that information, which is very important from the compliance perspective. It is mandatory to have such information if you have ISO 27001, HIPAA, or other compliances.

It enables us to investigate threats and respond holistically from one place. It is not only about detecting threats. It is also all about investigating and responding to threats. I can specify how the alerts should be sent for immediate response. Microsoft Sentinel provides a lot of automation capabilities around reporting.

With the help of incidents that we are observing and doing the analysis of the threats, we are able to better tune our infrastructure. When we come across an incident or a loophole, we can quickly go ahead and review that particular loophole and take action, such as closing the ports. A common issue is management ports being open to the public.

It saves time and reduces the response time to incidents. We have all the information on the dashboard. We don't need to go ahead and download the reports.

There are a lot of dashboards available out of the box, and we can also create custom dashboards based on our requirements. There is also one dashboard where we can see the summary of all incidents and alerts. Everything can be correlated with the main dashboard.

We can use playbooks and data analytics. We have one system called pre-policy definitions where our internal team can work on the usability of a particular product. We get a risk-based ranking. Based on this risk-based ranking, we will create policies and incorporate data analytics to get the threats and alerts. We are almost 100% comfortable with Sentinel in terms of the rules and threat detections.

It improves our time to detect and respond. On detecting a threat, it alerts us within seconds.

The AI and ML of Azure Sentinel are valuable. We can use machine learning models at the tenant level and within Office 365 and Microsoft stack. We don't need to depend upon any other connectors. It automatically provisions the native Microsoft products.

Playbooks are also valuable. When I compare it with the playbooks in other SIEM solutions, such as Splunk, AlienVault, or QRadar, the playbooks that Sentinel is providing are better.

The SOAR architecture is also valuable. We use productivity apps, such as Outlook and Teams. If a security breach is happening, we automatically get security alerts on Teams and Outlook. Automation is one of its benefits.

We are working with a number of products around the cybersecurity and IoT divisions. We have Privileged Identity Management and a lot of firewalls to protect the organizations, such as Sophos, Fortinet, and Palo Alto. Based on my experience over three years, if you have your products in the Microsoft or Azure environment or a hybrid environment around Microsoft, all these solutions work well together natively, but with non-Microsoft products, there are definitely integration issues. Exporting the logs is very difficult, and the API calls are not being generated frequently from the Microsoft end. There are some issues with cross-platform integration, and you need to have the expertise to resolve the issues. They are working on improving the integration with other vendors, but as compared to other platforms, such as Prisma Cloud Security, the integration is not up to the mark.

The second improvement area is log ingestion. Sometimes, we are observing large ingestion delays. We expect logs within 5 minutes, but it takes about 10 to 15 minutes.

They can work on their documentation. For Sentinel, not many user or SOP information documents are available on the internet. They should provide more information related to how to deploy your Sentinel and various available options. Currently, the information is not so accurate. They say something at one place, and then there is something else at other places.

It has been about two years.

It is stable. They are enhancing it and upgrading it as well.

It is scalable. It is being used across all departments. We took it for about 80 devices, but, within 24 hours, we mapped it to 240 devices.

Technical support is very straightforward. They will not help you out with your specific use cases or requirements, but they will give you a basic understanding of how a particular feature works in Sentinel.

Positive

We didn't use any other solution in this company. We went for this because as per our compliance requirements, we needed to have this installation in place. About 80% of our environment is on Microsoft, and we could just spin up Azure Sentinel.

It is straightforward. Usually, you can deploy within seconds, but in order to replicate an agent on your Sentinel, it will take about 12 to 24 hours.

We engaged Microsoft experts to deploy the agents across the devices on the cloud. It didn't take much time on the cloud, but for on-prem, it takes some time.

It has saved a lot of time. Implementing a SIEM solution from a third-party vendor, such as AlienVault OSSIM, can take about 45 days to 60 days of time, but we can roll out Sentinel within 15 days if everything is on Microsoft.

For implementation, we have about three people. One is from the endpoint security team. One is from the compliance team, and one is from the security operations team.

It is a cloud solution. So, no maintenance is required.

We have reached our compliance goals, and we have been able to meet our client's requirements. We are getting a lot of revenue with this compliance.

It has saved us money. It would be about $2,500 to $3,000 per month.

It varies on a case-by-case basis. It is about $2,000 per month. The cost is very low in comparison to other SIEMs if you are already a Microsoft customer. If you are using the complete Microsoft stack, the cost reduces by almost 42% to 50%.

Its cost depends on the number of logs and the type of subscription you have. You need to have an Azure subscription, and there are charges for log ingestion, and there are charges for the connectors.

I would strongly recommend it, but it also depends on the infrastructure. I would advise understanding your infrastructure and use cases, such as whether your use case is for compliance or for meeting certain client requirements. Based on that, you can go ahead and sign up for Sentinel.

If you have the native Microsoft stack, you can easily ingest data from your ecosystem. There is no need to think about all the other things or vendors. However, in a non-Microsoft environment where, for example, you have endpoint security from Trend Micro, email security for Mimecast, and IPS and IDS from Sophos, FortiGate, or any other solution, or cloud workloads on AWS, Microsoft Sentinel is not recommended. You can go for other solutions, such as Splunk or QRadar. If about 80% of your infrastructure is on Microsoft, you can definitely go with Microsoft Sentinel. It will also be better commercially.

I would rate it a 10 out of 10 based on my use case.

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.

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. 

Our two primary uses for the solution are incident management and threat hunting. We use Sentinel and other Microsoft security products for security investigations, threat, team, and incident management purposes. The tool is deployed across multiple departments and locations, with around 8,000 total end users.

We use multiple Microsoft security products, the full Defender suite including Defender for Cloud, Cloud Apps, and Identity, all integrated with Sentinel. 

Integrating multiple solutions is straightforward; as they are all Microsoft products, it's easy for Sentinel to ingest the logs and data connectors. The process is very simple, and we can configure log sources or data connectors in Sentinel in a couple of clicks.  

As a next-generation AI-powered SIEM and SOAR tool, Sentinel provides an all-encompassing cyber defense at the cloud scale. The solution's machine learning capabilities make threat hunting and identification rapid across the entire cloud environment.

The solution provides excellent visibility into threats; it's integrated with Microsoft's threat intelligence platform, which forwards information to Sentinel. We have robust threat detection 24/7.   

Sentinel helps us prioritize threats across our enterprise, an essential function that lets us focus on investigating and resolving high-priority incidents first. When the most significant threats are dealt with, we can move on to the medium and low-priority issues.  

The multiple Microsoft solutions work natively together to deliver coordinated detection and response across our environment; they work very well together, and we trust these products to investigate matters further. 

The Microsoft solutions provide comprehensive threat protection across our entire organization.  

Sentinel enables us to ingest data from our entire ecosystem, which is crucial to our security operation. We require the data not just from Microsoft products but also from different firewalls and other security products, including firewall proxies, web proxies, logs, etc. We can quickly integrate multiple data sources in just a few steps. 

The solution's threat intelligence helps prepare us for potential threats before they hit and take proactive steps. Sentinel's intelligent and fast threat detection allows us to respond rapidly to critical and high-priority incidents by leveraging built-in automation and orchestration tools. 

Using Sentinel gives us time savings of 30-40%.  

The solution also decreased our time to detect and respond by 30-40%. 

Sentinel is a SIEM and SOAR tool, so its automation is the best feature; we can reduce human interaction, freeing up our human resources.

The built-in AI and machine learning are excellent; they reduce the number of false positives by around 90%.

The centralized threat collection is a valuable feature. 

The solution is cloud-native, so it's faster and easier to deploy as there is no hardware or software to implement.

The product is flexible enough to deploy in the cloud and on-prem, which is an advantage over other SIEM tools.

Sentinel allows us to investigate threats and respond holistically from one place, which is crucial because time management is essential during a security investigation. Having all the relevant data in one place enables security analysts to investigate and resolve quickly.   

The solution's built-in SOAR, UEBA, and threat intelligence capabilities provide comprehensive protection. The SOAR capability is excellent and better than other products on the market, reducing our dependence on security analysts, and IT takes less investigation time. We can leverage the UEBA to focus on risky users and entities first during an investigation, which is an integral part of the process. 

Compared to standalone SIEM and SOAR products, Sentinel reduces infrastructure costs by around 50% due to the cloud and reduced maintenance relative to legacy solutions. Sentinel is also approximately 70% faster to deploy than legacy solutions with the same rules. 

The solution helped to automate routine tasks and the finding of high-value alerts. This reduced our dependency on security analysts and their workloads because the solution reduced false positive alerts by about 90%. This freed up our analysts and is the most significant benefit of automation.  

The product helped eliminate having to look at multiple dashboards and gave us one XDR dashboard, which provides us with greater visibility and a reduced time to investigate and resolve.  

The data connectors for third-party tools could be improved, as some aren't available in Sentinel. They need to be available in the data connector panel. 

The solution could have more favorable pricing; the cost is relatively high compared to other SIEM tools, which can be prohibitive for smaller organizations. 

We've been using the solution for over a year. 

Sentinel is stable. 

The solution is scalable. 

The technical support is good and responsive, but in some cases, it took a long time to resolve our issue.

Positive

We previously used IBM QRadar as a SIEM tool and switched because Sentinel is cloud-native and has more comprehensive capabilities, including SOAR capabilities. Sentinel fits our clients' requirements better, as many of them utilize the MS Defender security suite, which gives them a specific grant for free data ingestion. The solution also provides greater visibility.

I wasn't involved in the solution's initial setup, and in terms of maintenance, it's very lightweight; updates are Microsoft's responsibility, so we don't need to do anything.

Sentinel is expensive relative to other products of the class, so it often isn't affordable for small-scale businesses. However, considering the solution has more extensive capabilities than others, the price is not so high. Pricing is based on GBs of ingested daily data, either by a pay-as-you-go or subscription model.

The product saved us money, but actual savings depend on the project size, as the pricing is per GB of ingested data. Our savings are approximately 40-50%. 

We evaluated various solutions, including LogRhythm SIEM, Splunk, and Sumo Logic Security. We chose Sentinel because it's more advanced, cost-efficient has greater capabilities and fulfills our requirements better than the other products.

I rate Sentinel nine out of ten. 

To a security colleague who says it's better to go with a best-of-breed strategy over a single vendor's security suite, it's better to go with multiple vendors. This provides better visibility and avoids a single point of failure.

My advice to others considering the product is it depends on the project requirements. For larger organizations, I recommend Sentinel, as it's very advanced. However, for smaller-scale industries, Splunk and IBM QRadar are good options. For primarily cloud-based organizations with the majority of users in the cloud, then Sentinel is again an excellent choice.

My role thus far has been to integrate security log sources into the platform. This includes developing or troubleshooting some of the data connectors for different sources, such as web application firewall interfaces.

Sentinel is a SOAR platform. It represents the next generation beyond traditional SIM and SIEM platforms. Its powerful SOAR functionality orchestrates and automates responses to security events, eliminating the need for manual intervention. Instead of relying on human analysts to monitor events and react, Microsoft Sentinel leverages pre-defined automation rules. These rules correlate relevant events, generating a holistic understanding of the situation. Based on this analysis, automated responses are triggered, expediting the resolution process and eliminating any delays associated with manual identification and decision-making.

Sentinel provides us with a unified set of tools for detecting, investigating, and responding to incidents. This centralized approach offers both advantages and challenges. On the one hand, it grants us the flexibility to tailor Sentinel's capabilities to various situations. However, this flexibility demands a deep understanding of the environments and activities we're dealing with to effectively utilize Sentinel's features. While this presents a challenge, it also highlights the potential benefits of this unified approach. The unified view is important to me because I get all the information together in a single pane of glass instead of having to switch between multiple applications. The ability to consolidate all of that information into a single application or dashboard and to centrally evaluate its intelligence is a significant advantage.

Sentinel's ability to secure our cloud environment is of the utmost importance.

Sentinel Cloud Protection offers a collection of customizable content that caters to our specific requirements, demonstrating the solution's flexibility. The versatility of this content allows us to address a wide range of needs. However, in most instances, we need to adapt the material to suit our unique circumstances. While Sentinel Cloud Protection provides a comprehensive set of resources, including pre-written responses, it often requires tailoring to fit specific situations. This customization process is not a drawback but rather an essential aspect of effectively utilizing the tool. It's crucial to understand the nuances of each situation to apply the content appropriately. While I wouldn't consider this a negative aspect, I've encountered individuals who believe they can purchase a solution, implement it without modification, and achieve optimal results. However, such unrealistic expectations often lead to disappointment.

The Sentinel Content Hub is essentially the central repository where we acquire the content to build upon. Therefore, it serves as the starting point for our efforts. Some of the hunt rules have been quite beneficial in terms of what they provide from the Content Hub, allowing for a plug-and-play approach. This means we can immediately benefit from what's available without having to do any additional work. We can then build upon this foundation and extend the capabilities beyond what's provided by the Content Hub. The Content Hub itself is a valuable asset that gives us a head start in achieving our objectives.

Content Hub helps us centralize out-of-the-box SIM content. This has made our workload more manageable.

The ability to correlate and centralize all of that information together, rather than having to manage it across multiple platforms and potentially miss things between different platforms, makes it more likely that we will not miss anything. The workload and the missed threats that we need to respond to have been reduced because of that unified approach. The mean time to detect has been reduced, and the mean time to respond has been reduced.

Sentinel correlates signals from first- and third-party sources into a single, high-confidence incident. The third-party integrations provided through Microsoft offer all the tools we need to integrate those sources. In other cases, we have to build the integrations from the ground up. Currently, we are struggling to integrate some of the sources that don't have existing connectors. However, the platform is flexible enough to allow us to build these integrations. It is just a matter of finding the time to address this issue.

Our security team's overall efficiency has improved. The build phase is still ongoing. We have not yet fully transitioned to an operational model. We are still in the build implementation stage because we need to integrate some third-party sources into the existing platform and ensure that they are included in the scope of the analytics rules. However, this has significantly reduced the amount of time spent working between different platforms.

The automation capabilities are perhaps the platform's most significant advantage. The force multiplier capability is exceptional. Traditional SIM or SIEM-like platforms were effective in gathering and presenting security information to security personnel. However, security personnel were still responsible for evaluating the information and determining whether a response was necessary. One of the benefits of Sentinel's automation capabilities is the ability to automatically trigger an action or response activity, which is a significant advantage.

The automation capabilities have helped reduce our mean time to respond. Automated events can prevent a problem from escalating beyond a single incident to multiple occurrences before we have to respond to it. In this way, automation effectively catches problems right away.

Sentinel has helped to improve our visibility into user and network behavior. This is extremely important because it allows us to have a better understanding of how users and networks are behaving.

Sentinel has helped reduce our team's time.

Sentinel has streamlined our event investigation process by eliminating the need to manually track down specific event activities. The rules are now automatically identifying and processing these activities, significantly reducing the time required for investigation. Tasks that previously took half an hour can now be completed in under five minutes.

The analytic rule is the most valuable feature. It allows us to assess the various use cases we've developed and then automate those processes accordingly. I consider it a force multiplier. It empowers a small team to achieve a significant impact, whereas previously, I would have relied on multiple individuals. By utilizing it, we can accomplish more with fewer resources.

While I appreciate the UI itself and the vast amount of information available on the platform, I'm finding the overall user experience to be frustrating due to frequent disconnections and the requirement to repeatedly re-authenticate. Microsoft needs to address these usability issues to enhance the user experience.

I have been using Microsoft Sentinel for seven months.

The stability is exceptionally reliable. I tend to be quite vocal when things don't function as expected. The web interface requires using a browser for interaction, and I often find myself multitasking between Sentinel-related tasks and other activities, such as responding to emails. When I return to the Sentinel interface, I'm prompted to re-enter my credentials, which causes me to lose my previous work. If I'm using KQL to query data, I frequently have to restart my work from scratch. This can be frustrating, but I've learned to copy my work periodically to avoid losing it. I haven't encountered this issue with previous platforms, even those that use web interfaces.

Sentinel boasts exceptional scalability. While it's crucial to monitor data ingestion costs, Microsoft has effectively crafted a platform capable of expanding to accommodate far greater volumes than initially anticipated.

The technical support has room for improvement.

Neutral

The initial deployment was straightforward. Our strategy was to consolidate onto a common platform. We have a significant portion of our security information being handled through SysLog events. As a result, it was almost as straightforward as simply rerouting data from the old platform to the new one. This served as a preliminary test of the new platform to ensure it was functioning as intended and could effectively redirect and handle the increased volume.

The deployment likely involved six people, but not all at the same time. There were six people involved in the deployment overall, but we probably had four people working on it at any given time. From a headcount perspective, I believe four people is the appropriate number.

We employed a third-party company for the implementation because we sought expertise in Sentinel and the Azure platform, and we aimed to augment our existing staff.

We have achieved a positive return on our investment. In my previous jobs of comparable size, I would have needed approximately three people to manage the event activity and to handle and respond to it. Here, we can accomplish this with two people. As a result, we have saved at least one headcount with our current staffing levels. Additionally, as we expand the platform, we will not need to increase the headcount to manage the growth.

Microsoft Sentinel can be costly, particularly for data management. While Microsoft provides various free offerings to attract users, these benefits can quickly become overwhelmed by escalating data management expenses if proper precautions are not taken.

I don't think it's Microsoft engaging in underhanded tactics. I believe the issue lies with customers not paying close enough attention to what they're enabling. Initially, they're excited and eager to incorporate everything, but before they realize it, they've incurred unexpected costs.

Azure Monitor Log Analytics and Sentinel have different subscription plans and pricing tiers. This segmentation was implemented to accommodate the distinct business relationships within our organization. Sentinel costs are managed separately from Azure costs.

The decision to adopt Microsoft Sentinel was made before I joined the organization. I understand that they evaluated all the major solutions available, including Splunk and QRadar. However, due to the selection of a cloud-based solution, they opted for Microsoft Sentinel as it aligned with their overall strategy.

I would rate Microsoft Sentinel eight out of ten.

We've got a user base globally of about 5,000 people.

Microsoft Sentinel does require maintenance, which includes monitoring the incoming data and ensuring that everything is functioning as expected. While automation simplifies many tasks, it doesn't eliminate the need for oversight. We still need to verify that everything is working correctly. Part of the maintenance cycle involves ensuring that the automation agents are operational and performing their intended tasks and that events are being collected and evaluated properly.

Users need to have a clear understanding of their goals before selecting a solution. I have encountered too many people who believe that simply choosing a solution will resolve all of their problems. It is crucial to understand the desired outcome and the specific requirements of the use case to determine whether or not Sentinel is the appropriate fit.