Microsoft Defender for Cloud Reviews

We are primarily using Azure Security Center to bring a level of security into the environment. Before I started to work with this solution, I was a Kubernetes and Azure Cloud architect. I was working for a service provider where I did not get the opportunity to look at how do they secure the resources, but in the last one and a half years, I had to get into those aspects because the organization I was working for wanted to introduce Kubernetes into the ecosystem, and the main concern was regarding all the hacking that was going on. For introducing Kubernetes as a platform, all business managers wanted to know if it was secure or how to make it secure. We started to look at Azure Security Center and its capabilities because Azure was their main solution. We also used AWS and GCP to some extent, but predominantly, we had Azure. So, we first took Azure Security Center and started to leverage its features.

Azure gives access to a lot of policies and allows you to group those policies into initiatives. There were about 170 subscriptions spread across sandbox, dev, test, non-prod, and prod environments, which were spread across India, Canada, and the USA. Each geography had its own data resiliency requirements, so these policies had to be applied stringently. For example, if somebody created a virtual machine, it had to be in a specific region, or if someone was storing the data in a database, it had to be only in that region. It could not cross the border. So, we had to first enforce policies at the level where we had to identify where the storage resources were, which network could talk to which network, and who could do what, and then it went on to all levels. Azure provided very good, robust, and built-in policies for each resource, and we had to set some to audit and some to enforce. 

While setting policies for about 170 subscriptions, we needed to ensure consistency. We needed to apply them consistently across all subscriptions. Azure Security Center helped us in ensuring that we audit certain policies, and we also enforce certain policies. We had set some policies to audit because we wanted to see what's going on, and we had set some policies to enforce because of regulatory purposes or because of the way the entire network and all the systems were designed. We used Azure Security Center as our central place to administer policies. We had to group all the subscriptions into management groups, and there was a hierarchy of groups. We could apply the policies at one specific level, and any subscription that we would create under that group would have the same set of policies. It helped us in getting a bird's-eye view through dashboards. We could see what was happening across the enterprise.

We started using it for Kubernetes, but it expanded into a wider initiative of more stringent policies across the board. In terms of lift and shift, a lot of people get tempted to go to GCP because it is cheaper, but we were primarily using Microsoft products. So, we started adopting Azure, and we did not pay attention to Azure Security Center at the beginning. When we looked at Azure Security Center for the first time, it had already been three years, and we had done almost 100% lift and shift, but we could recover from any aspect of security. Azure Security Center helped us in recovering from our mistake. If we had worked with it at the start of our journey, it would have been easier, and even though we were looking at it halfway through our journey, it still helped us. I consider it halfway because lift and shift is only one part of the process. You are saving a lot of money, but you are still not cloud-based. The real power of the cloud comes when you start using the platform services, and before starting to use them, we were able to get into a secured environment. Kubernetes was the first platform that we were looking at, and when we were able to secure it, everything else was pretty simple. That's because, with Kubernetes, there is a shared responsibility model where the cloud provider takes care of some of the aspects, and you have to take care of a lot of things. Azure Security Center helps in ensuring that you have taken care of and secured everything.

Its recommendations are really good. Most of the time, they are appropriate. Azure comes with a lot of default policies that are set to audit only. As the enterprise grew and we started adopting the cloud, initially, we didn't pay much attention to Azure Security Center. For us, Azure Security Center was like an afterthought; it was not planned from day one. In our enterprise journey, when we started looking at it halfway through, we realized that there were so many violations. We started with auditing. We found policies that nobody was using, and then we started enforcing them. It was really good in terms of built-in policies, recommendations, and then applying them across the board with a minimal set of actions.

It is very intuitive when it comes to policy administration, alerts and notifications, and ease of setting up roles at different hierarchies. It has also been good in terms of the network technology maps. It provides a good overview, but it also depends on the complexity of your network.

For Kubernetes, I was using Azure Kubernetes Service (AKS). To see that whatever is getting deployed into AKS goes through the correct checks and balances in terms of affinities and other similar aspects and follows all the policies, we had to use a product called Stackrox. At a granular level, the built-in policies were good for Kubernetes, but to protect our containers from a coding point of view, we had to use a few other products. For example, from a programming point of view, we were using Checkmarx for static code analysis. For CIS compliance, there are no CIS benchmarks for AKS. So, we had to use other plugins to see that the CIS benchmarks are compliant. There are CIS benchmarks for Kubernetes on AWS and GCP, but there are no CIS benchmarks for AKS. So, Azure Security Center fell short from the regulatory compliance point of view, and we had to use one more product. We ended up with two different dashboards. We had Azure Security Center, and we had Stackrox that had its own dashboard. The operations team and the security team had to look at two dashboards, and they couldn't get an integrated piece. That's a drawback of Azure Security Center. Azure Security Center should provide APIs so that we can integrate its dashboard within other enterprise dashboards, such as the PowerBI dashboard. We couldn't get through these aspects, and we ended up giving Reader security permission to too many people, which was okay to some extent, but when we had to administer the users for the Stackrox portal and Azure Security Center, it became painful.

We were also using it for just-in-time access for developer VMs. Many a time, developers need certain administrative privileges to perform some actions, and that's where we had to use just-in-time privileges. Administering them out of Azure Security Center is good, but it also means that you have to give those permissions to lots of people, which is very cumbersome. So, I ended up giving permissions to the entire Ops team, which defeats the purpose and is also not acceptable at a lot of places.

These were the two use cases where I felt that I really had to get into the depth of Azure Security Center to figure out how I can use it much better.

I have been working with this solution for the last one and a half years. 

I didn't find any issues with its stability. When you start using Azure Security Center to look at your on-prem application or resources, you might have issues with monitoring these on-prem resources, but it is not related to the stability or reliability of Azure Security Center. It has nothing to do with Azure Security Center; it is related to how you have configured, what kind of resources you have, and what permissions you have given. 

Sometimes, the network operations team and security operations team are not in tandem with each other. We had done lift and shift for most of the resources, but there were still some resources that were on-prem. For on-prem resources, people are comfortable with Dynatrace and other similar tools, but they are not really security tools; they come under the observation and monitoring tools. It can be very hard to sell Azure Security Center for something that is on-prem, and because of the corporate silos, someone might not give you access to an on-prem resource. For example, your Oracle Database is still on-prem, and you are systematically strangulating the application and moving it to Cosmos DB or SQL Server on the cloud, but you are not allowed to monitor it. In such situations, Azure Security Center can only report one part of the application, which makes it tough to tell business managers

why this application is down, what went wrong, why there is latency, what is the problem, etc. So, more than the product, it has to do with ensuring that the SOC team works with the NOC team and ensures that they have the required access so that they can also observe on-prem resources from the security aspect. Otherwise, you won't know what's happening. You won't know if any hacking is going on, or if somebody is doing SQL injections to the on-prem Oracle Database. You wouldn't have a clue.

I'm an architect. I don't deal with the regular operations aspects.

There is nothing in terms of the setup. It comes by default. It is only about paying attention to the Azure Security Center in terms of giving correct roles to subscription owners, security administrators, etc. It is only about properly setting up those roles.

It only required going through the documentation in detail and having a couple of brainstorming sessions. We didn't have to hire any special consultants. We could do it ourselves. We spent a week properly going through the documentation. Having a word with the product managers also helped. Many times, such implementations have more to do with the way organizations are structured in terms of departmental silos. So, it helps to get everybody on board and ensure that everybody has the same understanding. It is related to an organization's culture; it has nothing to do with the product. It is more related to outsiders and insiders and different levels of knowledge and backgrounds, but the product itself is pretty simple to start with.

We did it ourselves.

It is bundled with our enterprise subscription, which makes it easy to go for it. It is available by default, and there is no extra cost for using the standard features.

I don't know if any other solution was evaluated. Most probably, we didn't because Azure Security Center is available by default, and there is no extra charge for using the standard features.

When you're using such platform services, you've got to be a little bit careful because the products are always getting updated. You need to keep an eye on the product roadmap in terms of what's coming up so that you are not duplicating. That's what we had to do with Stackrox. We discussed with Microsoft's technical support team, and we got a confirmation that they're not going to take care of CIS benchmarks in the near future. It was a little bit disheartening, but at least, we knew upfront that Microsoft is not going to look into this area. They were open and candid about what they were going to do and what they were not going to do. So, we started looking at other products. Microsoft keeps on updating its products to keep them relevant. So, you need to know what they are implementing in the next three months or six months so that you can at least tell the security teams that a certain feature is coming up.

We didn't have to do it for Azure Security Center, but for Azure Firewall, we had to request certain features, and there are a lot of features that are still pending. For example, if I use Azure Firewall, just-in-time permissions do not work. If VMs are behind Azure Firewall, then through Azure Security Center, I can't give permissions, but if I use the Palo Alto firewall, I can do the same. So, we had to set up our VMs by using the Palo Alto firewall. Sometimes, Microsoft does strange things, and they don't talk to the Azure Firewall team. After one and a half years of asking for that feature, it is still a no-go. We want to use Azure Firewall because it is not VM-based. With the Palo Alto firewall, I have to provide one more VM in between and start administering it. So, I have one extra resource that needs to be administered, and it is non-Azure or non-Microsoft.

When you start enforcing policies across multiple subscriptions, you need to be very careful. You need to pay attention to the notifications that come out. The notification details were where we had to do some customization. We had to prioritize the notifications and then put them into a group mailbox so that instead of one person, a group of teams gets notified. We could write an Azure function around it to integrate with Microsoft Teams. We could push them to the Microsoft Teams channel. It took some amount of effort. It took about a week of tinkering, but we were able to notify the entire development team. As we started auditing and enforcing from our sandbox to the development environment, we started discovering a lot more things. We got formal requests on why we had to disable some policies. We got more specific feedback. When we are able to catch such things early in the life cycle, it becomes easier to protect the higher-level environments properly. It was very good in terms of the dashboard, converting from non-compliance to audit, or enforcing policies across multiple subscriptions. We had to customize the notifications, and it would've been nice if there was a more intuitive way of customizing the notification, but it might also be because of our knowledge level at that time. We could have also integrated it with Slack because it supports integration with Slack, but we predominantly use Microsoft Teams.

I would advise others to start playing with it. They can start with a sandbox environment. If an enterprise has multiple resources, such as VMs, databases, they should put all of them in different resource groups in a subscription and categorize their resources properly. All resources should be structured properly. Otherwise, it is really difficult to administer policies at the resource level. They have to group them properly so that they are managing resource groups or subscriptions rather than individual resources. So, structuring of the resources is the key to the administration of policies. It took quite some time for us. It was not an easy task. We create Terraform scripts for setting the entire infrastructure. So, we had to reorganize our Terraform scripts to ensure that the resources were created in appropriate resource groups and communication can happen across resource groups. We had to set up the NSGs properly from the network point of view so that they all were accessible. It took us quite some time, but organizing the resources pays very well when it comes to spinning the higher-level environments and ensuring that they're compliant or they work.

I would rate it an eight out of 10.

Security is at the forefront of everything that we have been doing, fundamentally. Both in my previous organization and the current one, Azure Security Center has given us a great overview of the current state of security, through the recommendations given by Microsoft. There are potential situations where risk exists because you're not compliant with a specific recommendation, or to specific regulatory compliance. Such guidance is critical for us.

We implement a wide range of solutions in our environment. We have solutions that are purely SaaS. We have some things that are just purely IaaS, and, of course, we have PaaS for services as well. So, we really have a wide range of deployments on all services as a service.

Overall, Azure Security Center has greatly improved our company's security posture. At a very quick glance, you can see where you are the most vulnerable. I'm greatly oversimplifying what the tool does, but at the very minimum, at a quick glance, even if you are not an expert, or even if you have just started using it, this tool will give you a basic idea of where the biggest problems are.

Security Center has not affected our end-user experience in a negative way. To my thinking, security is something that if your users don't experience it then it's great because there are no problems. Since I have been in this company, there have not been any security incidents. The only experience that the end-users have is the fact that there have not been any disruptions due to security issues. We have been monitoring what has been going on.

The most valuable feature is the recommendations. Azure Security Center is a product that can be useful in various grades and stages, depending on the state of maturity of both your application and your organization.

The alerts are also valuable, and they go hand-in-hand with the recommendations.

With respect to our security posture, there are at least two features that have been very useful. The first of these is the inventory section, where you can quickly see everything that you have. Especially in a larger organization where there have been mergers and acquisitions, it can be difficult to readily see everything that has been deployed. Using Security Center, you have a full view, at any given time, of what's deployed, and that is something that is very useful.

The security score has been very useful. This is another numeric metering system that basically tells you how well you have been doing.

Consistency is the area where the most improvement is needed. For example, there are some areas where the UI is not uniform across the board. You can create exemptions, but not everywhere are the exemptions the same. In some areas, we can do quick fixes, but that is not true across the board. So in general, consistency is the number one item that needs attention.

We have been using Azure Security Center for approximately three years.

With respect to stability, so far I have not encountered any specific issues with the way it behaves. I cannot say that it has performed badly in any way.

It's a really scalable product, fundamentally, the way Microsoft designed it. I don't think that scalability is an issue at all.

We have implemented this solution in environments that differ quite significantly in terms of scope and in range but, given the way that it works, within 24 hours it discovers everything in the environment, no matter what it is. 

We only used technical support once, and it was for an item that was behaving in a strange way. It ended up being a known issue, and they said that they were going to fix it. Overall, it was a very good interaction.

In both companies where I have used this solution, there was no other cloud-based tool that was handling security. It was done using traditional security products that basically examined the logs and raised alerts.

We switched because it gives us an expansive view of everything which is deployed. It is really unparalleled by anything else that you could potentially use. The moment you turn it on for a subscription, it will identify, almost immediately, every component that you have. From there, it will also identify what is at risk in that component.

The initial setup was pretty straightforward, although I came to this product from a network and security background. When I started working with a Security Center, it was not like a tool that I had never seen before.

Fundamentally, it takes 24 hours before you start to see everything accurately. From the moment you turn Security Center on for your subscription, within the 24-hour range, you have a full view of what's going on.

Our implementation strategy includes turning it on for every subscription that we have. Security is critical for us, so the cost, in this case, was not a factor. The benefit was definitely outpacing any potential financial cost. Once we turn the feature on for a subscription, we look at every recommendation that we see in the list. In cases where it is not compliant with our security policy, we fix the issue and have been doing that ever since we started using it.

My in-house team was responsible for the deployment, and this was true for both organizations where I have used it.

On average, three people can deploy it. There should be an architect and principal engineers.

Although I am outside of the discussion on budget and costing, I can say that the importance of security provided by this solution is of such importance that whatever the cost is, it is not a factor.

Microsoft does a good job with respect to the pricing model, so anything comparable will cost almost the same. I don't think that there is really an alternative.

We are perfectly satisfied with what this product gives us. So, there's really no reason to even look at anything else.

The first piece of advice that I would give somebody who's going to try to use Security Center is to try to understand their environment as much as possible, and then try to match their environment with the recommendation section of the tool and start remediating from there.

There are going to be recommendations in Security Center that will make sense if the team looking at the security infrastructure understands what is going on. If the team does not have a full understanding then it will be very difficult to know what to do, or how to remedy it.

The fact that I had to deal with many components, of which I don't know very much about, has been really great because it forced me to learn about their security. Typically, I don't have to deal with that. My learning has definitely increased, and of course, that's always good.

I would rate this solution a nine out of ten.

We use Microsoft Defender for Cloud for our cloud security.

I like Defender's bidirectional sync. It's a behind-the-scenes feature, but it's very important. I like how it's integrated with and collaborates with other products by design. This is especially true between Sentinel, Security Center, and Defender.

The entire Defender Suite is tightly coupled, integrated, and collaborative. This allows me to have more flexibility in the roles and responsibilities of my teams, the access to their tooling, and the ability to report accurately on the current threat posture. For example, if I have Sentinel and CloudApp, and someone closes an incident in CloudApp, it will also close in Sentinel. However, if I had CloudApp in Splunk, this would not be the case. This integration is what I like.

The documentation could be much clearer. I also think that Microsoft should stop rebranding everything constantly. I'm tired of every name changing every 90 days. It's ridiculous. I understand that they're coupling tools together but look at AIP. It has had over 14 names in the last five years. That's absurd. Microsoft needs to stop rebranding everything and stick with one brand. They can build them out from there.

I like the fact that the dashboards are integrated, but I don't like that the CloudApp is now mapped to the Security dashboard. I hate that. I should be able to map dashboards myself. Having one dashboard is great for some people, but I have people who do Endpoint Management and they don't do Incident Management. They're two different groups. I should be able to send them to different portals if I want to. They're not all working out of the same portal. I do like that the dashboards have the option to be put into one portal, the Security portal, but I don't like that now I have to figure out where Microsoft moved everything. I liked it better when they were separate, so I could isolate and assign groups to each tool. Now that they're putting all the portals together, it's more complicated. I like the idea of a single pane of glass, but I think they're adding too much change too quickly without explaining the main purpose or mission of each product. And they're not making a clear distinction between them. When we put them all in one portal, it just adds more confusion. For example, in CloudApps, I see incidents in the "Incidents" section, but in the new Security portal, incidents are not in the CloudApp section. People don't need to search for stuff. They knew how to do it before. Microsoft needs to stop changing things so often. I believe in change, but not every other month.

Defenders threat intelligence is useless, I think, because it didn't see SolarWinds coming. After SolarWinds, if we even mention their analytics and threat intelligence, it's just evidence that it doesn't exist. It didn't even see SolarWinds coming. The only value I see in their threat intelligence, from a marketing perspective, is that it allows me to leave logs in their native location and tell clients to leave them longer. So if they find something like SolarWinds later on, they can go back and look through older logs and find it again. After SolarWinds, I'm not impressed at all by anything Microsoft says about their multi-billion dollar login.

I have been using Microsoft Defender for Cloud for over ten years since it was part of the Defender Suite.

We have not had any complaints from our clients about the stability of Microsoft Defender for Cloud.

I've questioned Microsoft's claims about the scalability of Defender for Cloud. I don't think their claims are accurate. I don't think we could scale Defender for Cloud to the level that Microsoft claims. Microsoft tells me that I could let my Log Analytics scale, but I think there must be a limit.

We have always had good experiences with the technical support through the portal.

Positive

The deployment is easy as long as we understand the licensing and what we are doing. The deployment was completed as a team.

Our clients complain about the cost of Microsoft Defender for Cloud. Microsoft needs to bring the cost down. What we're doing to their detriment is simply lowering the amount of log retention we're keeping, which is not what I want to do. Storage is so cheap in every other aspect of Azure except for Log Analytics, which makes it even more difficult to explain to clients why we're charging them so much for terabytes of storage. In comparison, data lakes and storage accounts store terabytes of data for much less cost.

I would rate Microsoft Defender for Cloud eight out of ten, mostly because of documentation and availability of information. The difference between the Azure Active Directory Premium P1 and P2 licenses lies not only in their capabilities but also in the amount of logging that is performed for each user. I need to know what is and is not being logged, and which security events are not being logged. I can't find a list of these events anywhere. What is the difference between a one-year retention license and a 180-day license? What additional logging is performed with the one-year license? Microsoft has mentioned that advanced auditing is occurring, but I don't know which events they are getting. I would like to see a list of all the events that are logged, from least to most. This list would probably look like a triangle, with a few items at the top and more and more items as we go down. I would like to see this list for both the AAD Premium P1 and P2 licenses. I can't get this list. My client has asked me what events we are not capturing, and my answer is that I don't know because I can't find it. Microsoft won't give me a list of the events that are logged, either. They can only reference the services that the events map to. I want to know the events. The uncertainty and doubt around this is a security feature. Microsoft is trying to make me buy the product because they know that if I get hacked, I could be liable for malpractice. But I'm not going to buy it without more details. I'm very upset that they didn't provide more information.

There were many use cases. We were monitoring auto IT applications and creating internal processes to understand which ones were going to be allowed and which were going to be blocked. We created the policies internally. 

It's an IT tool to monitor employees' usage on the internet and of web apps. We created policies so that, for example, when employees reached certain websites, like games, they would be blocked. We created a message for the email that they would receive, and there were links for whom to contact if they needed to override it. We created all the processes behind it.

From a security perspective, it reduced the amount of risk for employees, contractors, and users who might try to go to dangerous sites, as we blocked them. It helped us to identify dangerous sites so that we could make decisions on blocking them or not.

The effect on time to detection using Microsoft Defender for Cloud was very positive. The policies we created were providing information as threats arrived. When someone clicked on a website or on a link that was dangerous, it detected that and our team was able to control the situation right away. It was very highly effective because they got a live notification as soon as it happened. It improved things very positively.

It also had a positive effect on time to respond. As soon as an alert was received or something potentially dangerous happened, a process behind the scenes that we created helped them to react immediately.

The first valuable feature was the fact that it gave us a list of everything that users were surfing on the web. Having the list, we could make decisions about those sites. 

Second, it tried to categorize the apps, from riskier to less risky, with a behind-the-scenes algorithm. Even though we didn't use that, it was a starting point for our first review of the applications. We started with the riskiest ones and decided whether each one should be blocked or not. The fact that it provided a risk rating was very valuable. 

And it's very easy to use. Those are the top three.

Six months to a year ago, which was the last time I used the solution, the algorithm that was designed to define whether or not a site is dangerous or not needed to be improved. It didn't have enough variables to make the decision. 

Another thing that could be improved was that they could recommend processes on how to react to alerts, or recommend best practices based on how other organizations do things if they receive an alert about XYZ. 

Also, the complexity in the amount of information for this process could be reduced to facilitate those of us who are implementing and using the system, and guide us as to exactly what is needed.

I used Microsoft Defender for Cloud for a year and a half.

The stability was very high. We never had any issues with it.

With Microsoft products, you can keep adding more information if needed. For the purposes of the tool, it covers everything.

We never used their technical support.

We didn't replace anything with this solution. It was something we added to what was already in place. Our threat department continued to use all the products that it had been using. This one was additional and brought more alerts.

The initial setup was straightforward because the platform was already in place. It comes with the system and you just activate it.

The first phase was creating all of the policies. Then we did a total review of the more than 10,000 apps and we started categorizing them in a different way than the tool does. It was a challenge because what the tool recommended was different from what we wanted to implement. We created our own policies.

We used a security consultant to help us, but that was for the processes we put in place, not for the tool, per se. It was along the lines of, "Okay, when we receive this, what do we do?" They helped us create policies and told us what the best practices are; everything that the tool doesn't give you.

It's very expensive in terms of the need to maintain it actively. You need a group of people in the organization to do the job because if the tool is sending information, a bunch of alerts on policies that we created, and nobody is reviewing it, it is doing nothing. Once you create policies, you have to have a very established group that, based on the design of all of the policies, will follow a process to take action on each of them. Some of them were very complex and some of them were very simple. Some of them were automated and others were escalated, depending on the danger. So it can be very complex, depending on how you implement it in your organization.

The tool doesn't solve the problem, it just gives you the information so that you can solve the problem. Solving the problem takes a lot of resources, a lot of time and, it turns out, money. So it's expensive.

I don't think it saves time because it discovers things that would never have been discovered in any other way.

We have a managed detection and response solution, a type of SOC/SIEM/SOAR product, and we are adding data sources to our solution. We want to have data for our Azure cloud environment as well, so we use Microsoft Defender for Cloud as one of the sources for our Azure environment.

We use it as an extra way to gain trust for our environment. We have purposely secured the total Azure cloud environment with firewalls, application gateways, et cetera, but we also want to have trust in our resource groups. That's an extra line of defense we have for our security.

It helps our teams to have more security awareness because, first of all, they have to think about setting up Defender for Cloud, and the cost of Defender for Cloud is borne by those teams. So they are more aware of protecting their own environments.

It also helps automate routine tasks and the finding of high-value alerts because the alerts sit in the data source itself. It's easier to prioritize alerts.

The main advantage is the detection and response. Threat intelligence helps you prepare for potential threats before they hit. If something is there, we will detect it. And there are special teams threat-hunting through the data.

We have our data sources everywhere, on endpoints and in the cloud. When we find something anywhere, we can act everywhere, because it's an integrated solution. It gives us more possibilities to take action automatically.

We like the security aspect. Most importantly, it's an integrated solution. We not only have Defender for Cloud, but we also have Defender for Endpoint, Defender for Office 365, and Defender for Identity. It's an integrated, holistic solution. In our MDR solution, it's not a Microsoft Sentinel SOC, rather we have a third-party SOC/SIEM and they also do threat hunting for us.

It's really easy to integrate these products. It's just an interface, the Microsoft Graph Security API. We can collect all the data and forward it to our solution. We don't only use Microsoft products as a data source, but all kinds of security products. We have data about our firewalls, our gateways, and our event collections from Windows, but also from Unix.

Sometimes, it's very difficult to determine when I need Microsoft Defender for Cloud for a special resource group or certain kinds of products. That's not an issue directly with the product, though.

I have been using Microsoft Defender for Cloud for less than a year.

It's a very stable solution. I haven't heard of any problems.

It is a scalable solution.

We use it across multiple regions including Europe and Oceania. We have multiple solutions for our data analysis and system development platforms. Our web shops are using it. It's used for almost everything in the cloud. We have about 2,000 endpoints.

Microsoft's technical support is fine. We don't have any issues with it.

Positive

We have a lot of other products, like McAfee, but we are changing everything to Microsoft Defender. We are switching because, enterprise-wide, we want to have one standard for everything to make everything easier to manage. And we want all the data it delivers to be the same. We want one view of the truth for everything.

It's very easy to deploy. That is the least of any problems. It's just a simple yes or no in the cloud. It took 10 seconds.

We have an Enterprise Agreement with Microsoft but we also have a Cloud Service Provider contract with several parties so we can easily get the licenses we need. It's very easy to install. It's almost by default.

The solution itself doesn't require maintenance in the traditional way, but everything we're doing with it is about innovation. We are trying to innovate each platform, and each solution. Innovation is an ongoing business process.

It hasn't saved us money, as it's a cost to our company, but we're safe. It's the same as insurance: If there are no burglars then you don't need it. So it doesn't save costs but it might save you costs if something happens. Safety will cost money, but it shouldn't be too much.

The pricing is very difficult because every type of Defender for Cloud has its own metrics and pricing. If you have a Cloud for Key Vault, the pricing is different than it is for storage. Every type has its own pricing list and rules.

We don't use the full capabilities of Defender for Cloud so I don't know if it is the same as Defender for Endpoint. That solution is autonomous and acts on incidents immediately, based on playbooks for a type of incident behavior. Defender for Endpoint is capable of acting immediately when an attacker wants to encrypt a disk, for instance. I don't know if Defender for Cloud has the same capabilities, but it should.

In the discussion about going with a best-of-breed strategy or a single vendor's security suite, we have a mix. My thought is that I would like to have at least two big vendors, rather than one for everything. That way they can challenge each other.

Overall, I'm happy with Defender for Cloud. We're just at the beginning of using it but we want to extend our own solutions with Defender for Cloud as much as possible.

Our use case for the solution is focused on cost management and security in a multi-cloud environment. We use it alongside solutions like SIEM tools and deploy it as part of a broader security strategy.

The platform has improved our security posture by providing comprehensive threat detection and response capabilities. It helps in managing security across various environments effectively. However, we occasionally encounter issues when on-site products conflict with this solution.

The product's most valuable features offer the latest threat detection and response capabilities. These features are crucial for our SMB customers, especially given the high inflation in Turkey, which impacts cost considerations.

The product's advanced analytics and reporting features could be improved.

I have been using Microsoft Defender for Cloud for about three to four years.

The product performs reliably across various environments.

The platform's scalability is excellent. It is well-suited for both small and large organizations.

The support team is responsive and offers valuable assistance.

Positive

The initial setup can vary in complexity depending on the existing environment and the number of users. It's relatively straightforward for smaller setups, but larger deployments can be more complex.

We handle the deployment and integration ourselves.

The solution's ROI is positive, given its comprehensive security features and integration capabilities, which justify the investment.

The product's pricing policy is generally favorable.

We evaluated other options, but Microsoft Defender for Cloud was chosen for its strong integration with other Microsoft products and comprehensive feature set.

The solution is robust, but staying updated with the latest features and best practices is crucial to maximize its benefits.

Overall, I rate it a nine out of ten. 

We use Microsoft Defender for Cloud security, including endpoint detection and response, and user monitoring. We utilize every feature and functionality that Defender provides.

The threat detection capabilities of Microsoft Defender for Cloud have positively impacted our overall security posture. We can sleep soundly at night knowing that it is causing the system.

The most valuable features are the monitoring of users, endpoint detection and response, and the adaptability of the AI threat intelligence engine, which quickly adapts to customizations.

The pricing could be better. Additionally, while Microsoft Defender for Cloud adapts well to customizations, it does generate a lot of false positives if the agent is not running. We would also appreciate portion management specifically for Microsoft 365.

We have been working with Microsoft Defender for Cloud for three years.

Most of the features are in preview, which sometimes causes issues, but overall, it works well.

Microsoft Defender for Cloud is highly scalable. We have not faced any challenges with scalability.

Microsoft's documentation is very comprehensive, resolving 95% of issues. Thus, we haven't had much need to engage their support team. The documentation is sufficient for resolving most issues.

Positive

We handled the installation in-house with a team of two engineers.

The solution is subscription-based, and while it is generally affordable, there are often hidden costs. The overall pricing could be more competitive.

I highly recommend the product due to its comprehensive features and easy management, especially if your stack is on Microsoft. I'd rate the solution eight out of ten.

We use Azure Security Center in our own company, and we have also deployed it for one of our clients. Our biggest use case is the enforcement of regulatory compliance on our cloud.

Security Center has helped us really well in terms of regulatory compliance enforcement on our cloud. We were able to deploy the inbuilt policies, and we were also able to build our own initiatives and policies. There were certain things that we wanted to check to see if our VMs were compliant. We also wanted to ensure that our storage and databases are compliant, and Security Center helped us in doing that.

This product has features that have helped us improve our security posture because we have a large estate of servers or VMs in Azure, and with Security Center, we were able to find out that a lot of our VMs were not compliant. This would have caused us a lot of trouble if there was an audit in the near future. The issues that it flagged for us gave us the opportunity to fix the problems, which was really helpful. Essentially, it was a preventative measure that allowed us to identify and rectify issues before they got out of hand.

One way that this solution has helped to improve our organization is that we have a better view of the entire security status, including how compliant our systems are and whether there are any open issues that need our attention. There are also reports that we generate periodically, so everyone is aware of the overall status of the environment.

When we started out, our secure score was pretty low. We adopted some of the recommendations that Security Center set out and we were able to make good progress on improving it. It had been in the low thirties and is now in the upper eighties.

Our overall security posture has been enhanced. A lot of the time, our cloud is accessed by people in the organization and they keep spinning up virtual machines, creating resources. Often, there are ports that open or there are certain security issues that are not handled. Because there are so many people and so many new resources coming up, it is difficult to track all of them. With the help from Security Center, we are able to see exactly what has come up.

If there are new issues that arise, which could happen if someone has not followed the proper protocol before bringing up a VM or another network resource, we can see this because we have a better local view of exactly what is there in the environment. So in that regard, we can say that it has helped us improve our security posture.

Using this product does not affect the end-user in any major way. Its usage is mostly relevant to the backend, and of interest to administrators.

The most valuable features are regulatory compliance and security alerts. The security score is very helpful, as well. Together, these let us know the state of each subscription and whether there are any actions that we need to take. This functionality is pretty helpful in audits.

We would like to have better transparency as to how the security score is calculated because as it is now, it is difficult to understand. We showed it to a couple of our clients, and they had trouble understanding it and an explanation or breakdown is not readily available. The score includes different weightage for certain controls. For example, if there is a "Control A" and it has a weight of 10 then it would affect the score more than "Control B", which has a weight of five. Being able to see the weights that are assigned to each control would be an improvement.

We have been using Azure Security Center for between eight and nine months.

This is a pretty stable solution and we haven't run into any issues as of yet.

I don't think there should be problems with scalability. It supports more than a hundred subscriptions, with multiple thousands of resources. I expect that we will be fine in that regard.

There are between 10 to 15 users that are currently using the security center. We have only two to three administrators and the rest of them have a highly localized role. Some of them are working on the policies, whereas others take care of compliance issues. They try to remedy issues and also try to improve our security score.

Our client has data centers that are divided into various regions and various business units. They are onboarding new business owners every couple of months, so it is in the process of expansion. They want all of their business units to be onboarded.

I have not had the chance to speak with technical support from Microsoft but from what I have heard from my colleagues, they are pretty responsive and give you good information with respect to fixing issues.

We had another tool, Morpheus, which was a multi-cloud manager. We did some work on it but because it wasn't native to Azure, we didn't go any further with it.

The initial setup is pretty straightforward. We just had to enable it for our subscriptions.

Deployment does not take a long time. The maximum is 24 hours if you have a lot of subscriptions but otherwise, it's pretty quick.

We have several subscriptions so we initially started by deploying some for testing. When we were sure that we knew how to go about it, we deployed the remaining ones.

We completed the deployment in-house and two people were required.

There are two other people in charge of maintenance.

The cost of the license is based on the subscriptions that you have.

As we were on Azure, we didn't look to other vendors for similar solutions.

We use between 80% and 90% of the functionality within the solution. We don't use workbooks as of now but otherwise, we use pretty much everything.

There are a few options that are included but not enabled out of the box. One example of this is Azure Defender.

Maintenance-wise, one thing that we do is keep up to date on policies and compliance. Microsoft provides a lot of out-of-the-box compliance initiatives, and sometimes they can go out of date and are replaced. We have to make sure that the new ones are correctly enabled and that the older ones are no longer active. Essentially, we want to disregard the old policies and ensure that the new ones are enforced.

The biggest lesson that I have learned is to keep an eye on your resource usage in Azure, because if it's a large environment with a lot of users then you might not know who opens the door to the outside. Using Security Center lets you keep track of what's going on in your environment.

I would rate this solution an eight out of ten.