In Chapter 2, Governance and Security, you have learned that monitoring is essential for an organization to know what happens in their cloud environments. With Microsoft Defender for Cloud, this aspect is taken to the next level as it is meant to be the tool to give organizations a unified view into their hybrid and multi-cloud security configuration as well as inform them about current threats that are occurring in their environments.
In this chapter, you will learn about the following topics:
Let's get started!
With cloud computing being the main paradigm in the modern IT world, many benefits are associated with this new way of working. IT is no longer an end in itself and employees are way more productive than they were back in the day. But there are also new challenges when it comes to protecting modern IT environments.
In Chapter 3, Managing Cloud Identities, we covered advanced identity protection and that it is no longer enough to protect network boundaries; however, some other key security challenges come with cloud computing. How can you make sure you protect your ever-changing cloud services and applications? This is one of the value propositions of cloud computing and, in fact, probably the main benefit is that you can easily change and adapt in cloud environments. Be it continuous integration/continuous delivery (CI/CD), Virtual Machine (VM) upscaling, or service decommissioning, cloud environments are dynamic. But, at the same time, one of the main challenges is to keep track of these changes and to make sure that a company's services always adhere to its security baseline.
The threat landscape is evolving, and attacks are becoming increasingly sophisticated. Bad actors are using attack automation and evasion techniques, and at the same time, they are leveraging tools that help them to conduct attacks across the cyber kill chain. So, they no longer need to be highly trained technology experts, which results in an increasing number of sophisticated attacks, some of which are spearphishing and credential theft attacks. Also, attackers are using hijacked computers, tied to bot networks, to conduct widely spread password spray attacks, which can be hard to recognize.
We need human expertise, creativity, and adaptability to combat human threat actors. The downside is that security skills are in short supply. Currently (in 2021), there are 3.5 million open positions in the cybersecurity sector out there worldwide, with a prediction that this number will stay the same for the next 5 years. This includes not only cyber threat hunters but also security engineers and administrators with a focus on managing internal IT systems.
Tip
To learn more about the number of open positions in the cybersecurity sector, visit https://cybersecurityventures.com/jobs/.
Microsoft Defender for Cloud is a service that helps organizations fill the gap by helping them focus on two main pillars of protecting cloud environments:
Microsoft Defender for Cloud's main dashboard provides a unified view of the most important aspects of security coverage, as shown in Figure 7.1:
On top of the screen, Defender for Cloud provides a high-level overview of Azure subscriptions, AWS accounts, and GCP projects that are connected. It also shows the number of assessed resources, active recommendations, and active security alerts that have been raised during the last 30 days:
The tiles in the section underneath provide a more detailed representation of several aspects, including overviews of the secure score and regulatory compliance, but also an alert graph, an inventory view, and information about the integration with Azure Firewall Manager and Azure Purview.
Here's a brief description of each of these tiles:
The right side of the main dashboard provides different views of misconfiguration or critical alerts to catch an organization's interest, as well as further links to the Defender for Cloud GitHub community and TechCommunity blogs. On the left-hand side, the navigation menu is divided into three categories, as shown in Figure 7.4:
Now that you have gotten a quick overview of Microsoft Defender for Cloud and its Overview dashboard, let's dig a bit deeper and see how it works in technical terms.
Microsoft Defender for Cloud is not automatically enabled by default, so as a first step, we need to enable this service and provide initial configuration parameters. There are several key components we need to consider before starting.
Microsoft Defender for Cloud relies on some main Azure services that add benefit to the solution:
Important Note
If you want to connect Defender for Cloud with Microsoft Sentinel, you need to use a custom workspace, not the default one.
For Microsoft Defender for Cloud to be enabled on a subscription, you have several options. In general, you need to make sure that the Microsoft.Security resource provider is registered on a subscription. While this happens automatically whenever you open Defender for Cloud's portal in a particular subscription, or whenever you navigate through an Azure resource's security settings, this is not feasible for larger environments with several subscriptions. To enable Defender for Cloud at scale, you can follow the steps outlined in the next subsection
You can register the Microsoft.Security resource provider with the following PowerShell command:
Set-AzContext -Subscription "yourSubscriptionID"
Register-AzResourceProvider -ProviderNamespace 'Microsoft.Security'
With this command, you can enable the resource provider on all existing subscriptions, but in case there is a new subscription created, you would have to run the command for the new subscription, again. That's when a deploy-if-not-exists (DINE) policy comes into play.
Azure Policy comes with a variety of built-in policy definitions, one of which is used to enable Microsoft Defender for Cloud on the scope you chose. In order to enable the service on all existing and future subscriptions, it's enough to simply assign the Enable Azure Security Center on your subscription policy to your root management group. To onboard a management group and all its subscriptions to Defender for Cloud, follow these steps:
Now that you have enabled Microsoft Defender for Cloud on all of your subscriptions, let's move on and deploy mandatory agents and extensions to your IaaS.
Microsoft Defender for Cloud brings a set of extensions that are used to manage security for Azure VMs and non-Azure machines connected through Azure Arc. Azure Arc can be regarded as the vehicle being used to create a representative Azure resource of the non-Azure machine. That way, Azure governance and management capabilities, such as RBAC, policies, extensions, and more, can be used to manage and secure these on-premises or third-party cloud machines. The following extensions can be deployed to all machines in an Azure subscription by enabling auto-provisioning:
You can enable any of these extensions in Defender for Cloud when navigating to Environment Settings by selecting the management group, selecting the subscription, and then clicking the Auto provisioning button in the left navigation pane, as shown in Figure 7.10:
Once you enable one of the extensions to be deployed, you might need to add some configuration. For the Log Analytics workspace, you can either use the default workspace(s) created by Defender for Cloud or connect your machines to a custom workspace, as shown in Figure 7.11. In general, it is always a great idea to use a custom workspace because that way, you can make sure to connect all machines to the same workspace and use that workspace in Microsoft Sentinel.
In addition to the workspace setting, you can also configure raw event data collection for the Windows Server Security Event Log. You can decide to transfer none (default), minimum, common, or all security events to your Log Analytics workspace.
Important Note
Windows Security Event Data Collection is not used by Defender for Cloud. Even if you set the collection tier to none, Defender for Servers will create all security alerts that apply to a machine. The collection of raw events is used by SIEM solutions, such as Microsoft Sentinel. Also, data collection for security events is only available in case you enable the Defender for Servers enhanced protection plan, which is covered later in this chapter.
By enabling one of the auto-provisioning settings, a built-in DINE policy is assigned to the subscription and a remediation task is created to auto-remediate all applicable resources in that subscription. Since all settings apply to the whole subscription, it is not possible to use different settings for different machines in the same subscription when using auto-provisioning. However, you can use policy assignments on a resource group to make sure all extensions are automatically deployed and still adhere to the configuration that best suits your environment.
Microsoft Defender for Cloud offers free capabilities and advanced capabilities that are included in Defender for Cloud plans, as shown in Figure 7.12:
With enhanced security switched off, Defender for Cloud will continuously assess your Azure resources' current configuration and provide security recommendations for all of them. In addition to that, a secure score is calculated for each subscription, giving you an indication of your security posture's current state (the higher the score, the better your resources are protected). If you want to also protect on-premises servers or VMs running in another public cloud platform, or if you want to leverage other features, such as just-in-time VM access, adaptive application controls, adaptive network hardening, the regulatory compliance dashboards, and threat protection, you need to enable enhanced security by switching on the relevant Defender for Cloud plan.
Defender for Cloud is a subscription-based service, which is one of the reasons that Defender for Cloud plans can be enabled on a subscription-only basis when using the portal view shown in Figure 7.12. However, certain plans allow you to either be enabled on a subscription, or on a particular resource. This applies to the following plans:
There is a common misunderstanding that all Defender for Cloud plans can be enabled on a particular resource, only. Also, all Defender for Cloud plans can be enabled on a subscription, but not on a management group. However, there is a solution to this.
Enabling Microsoft Defender for Cloud plans on a subscription will basically change a setting on the subscription's Microsoft.Security/pricings API endpoint. In addition, there might be some additional configuration needed, but all of these settings can be enforced through Azure Resource Manager or an API. As one of the recent changes, Microsoft has added built-in policy definitions that can be used to enable Microsoft Defender for Cloud enhanced security plans on subscription. Figure 7.13 shows the current list of built-in definitions. Please note that the display names still refer to Azure Defender when writing this chapter, while the product has been renamed to Microsoft Defender for Cloud at Microsoft Ignite in November 2021.
As with all policy definitions, you can create an assignment on top of your root management group and, that way, make sure that the plans that are relevant for your environment are enabled on all existing and future Azure subscriptions within this scope.
Important Note
Microsoft Defender for Servers and Defender for SQL on machines need to be enabled on both the Azure subscription your machines are connected to and the Log Analytics workspace their agent is reporting to!
All policy definitions will leverage the Microsoft.Security/pricings API endpoint to set or change the pricingTier property from free to Standard. The following code shows the reference for enabling Microsoft Defender for Servers in the Configure Azure Defender for servers to be enabled policy:
{
"type": "Microsoft.Security/pricings",
"apiVersion": "2018-06-01",
"name": "VirtualMachines",
"properties": {
"pricingTier": "Standard"
}
}
The names for the different Defender for Cloud plans are as follows:
You can either use the built-in policy definitions or create a custom definition and select the prices you want to enable.
Tip
You can find a list of all built-in policy definitions for Microsoft Defender for Cloud at https://aka.ms/DefenderForCloudPolicies.
After enabling Microsoft Defender for Cloud, it will start assessing all connected resources for configuration issues and provide recommendations for closing these gaps. In the next section, you will learn about how to work with secure score and recommendations and how to improve your resources' security posture.
As you learned in the previous section, Cloud Security Posture Management (CSPM) is one of the two main pillars in Microsoft Defender for Cloud. CSPM is all about hardening your cloud resources and that is why Defender for Cloud will provide you with a large list of security recommendations to help you understand what is good and what can be improved in your resources' configuration. Secure score is the main Key Performance Indicator (KPI) when it comes to understanding how good (or bad) you have configured your resources. The idea of secure score is to show a percentage value based on fixed points that are given for remediating recommendations that are grouped in security controls, as shown in Figure 7.14:
Figure 7.14 shows an environment with a secure score of 48%. The higher this percentage value is, the better protected your resources are. Secure score is calculated based on the following formula:
In the preceding example, the calculation is as follows:
The maximum score is a fixed number, depending on the security controls that apply to your environment. In Figure 7.14, you see two security controls (Enable MFA and Secure management ports), which have a maximum score of 10 and 8. While Defender for Cloud has more than 200 recommendations, not all of them might apply to your environment. For example, in case you don't have any VMs in your Azure subscription, you won't see the Secure management ports control, and therefore might have a maximum secure score of only 50 instead of 58.
Tip
The maximum secure score when writing this book is 58 based on the maximum score of all 15 security controls. This number might change slightly when Microsoft is adjusting the maximum score per control, or when adding new controls.
In order to increase your secure score, you need to make sure to remediate all recommendations in a particular security control that apply to a single resource. Let's take a closer look at the Secure management ports control in Figure 7.15:
The total number of resources in this example is seven VMs, two of which need to remediate the Management ports should be closed on your virtual machines recommendation, and four of which need to remediate the last recommendation. For the whole control, you see that four out of seven resources are unhealthy, which means that three out of seven VMs in this control's scope are already completely remediated (and therefore count toward this environment's secure score). The maximum score per resource is the maximum score per control divided by the number of resources within a control, using this formula:
In our scenario, the per-resource score is as follows:
The current score is calculated as follows:
Using the numbers from our scenario, the current score is as follows:
That's why Figure 7.15 shows a current score of 3.43.
Now that you know how secure score is calculated, let's move on and focus on remediating recommendations.
As you have already learned, recommendations in Microsoft Defender for Cloud are grouped into security controls. This change compared to the initial concept of secure score was made to reflect the need to remediate all recommendations that belong to a particular protection idea. Those of you who have been working with Azure Security Center a few years back will remember that back then, secure score impact was calculated based on points for each recommendation. For example, for enabling a vulnerability assessment solution, you got 30 points, and an additional 30 points for remediating vulnerability findings in your machines. You will agree that by only enabling a solution but not taking care of remediating findings, your security posture is not really enhanced and, therefore, the change was made in favor of a secure score calculation based on controls.
Nowadays, you need to focus on remediating all applicable recommendations for a particular resource so your secure score will increase and, that way, indicate that your security posture is enhanced. Secure score recommendations are based on the Azure Security Benchmark, an initiative created by Microsoft to use industry standards and security best practices to highlight misconfigurations in an Azure environment. In the end, this benchmark is supposed to be the security baseline for securely deploying resources to Azure.
To get information about secure score and recommendations, the Azure Security Benchmark policy initiative needs to be assigned to either all Azure subscriptions or to one or several management groups in your environment. By default, once a subscription is onboarded to Defender for Cloud, the Azure Security Benchmark is automatically assigned as the default security policy. This is great for environments in which you have to work with different recommendations and want to disable some of them in some subscriptions. However, this might cause a lot of management overhead. As it's always a great idea to enable Defender for Cloud for all (existing and future) subscriptions, and to also get full recommendation and secure score coverage across the whole cloud estate, we recommend assigning the Azure Security Benchmark on your Tenant Root Group, similar to enabling Defender for Cloud, as described earlier in this chapter. In order to assign the benchmark to your root management group, simply follow these steps:
Once the Azure Security Benchmark initiative has been assigned, Microsoft Defender for Cloud will start assessing all resources in an Azure subscription and provide the results in the recommendations view. Microsoft Defender for Cloud comes with three different assessment status codes:
Although Microsoft Defender for Cloud's recommendations are based on a policy initiative (the Azure Security Benchmark), the assessments are not – at least not all of them. Defender for Cloud has its own capability to run assessments (configuration checks) in its backend. An assessment in this context will always be one check for a particular resource toward a particular recommendation. Once there is a result, the assessment status code (healthy, unhealthy, not applicable) is being sent to Azure Policy. Azure Policy, however, only knows two different health states for resources:
Therefore, all policy definitions used in the Azure Security Benchmark expect the assessment status code and flag resources as being compliant, in case the status code is healthy or not applicable, and as non-compliant if the assessment status code is unhealthy. That way, the recommendations view in Defender for Cloud and the Policy compliance dashboard will have similar results when taking a look at the corresponding policy setting/recommendation.
The following section is taken from the Management ports should be closed on your virtual machines policy definition:
"details": {
"type": "Microsoft.Security/assessments",
"name": "bc303248-3d14-44c2-96a0-55f5c326b5fe",
"existenceCondition": {
"field": "Microsoft.Security/assessments/status.code",
"in": [
"NotApplicable",
"Healthy"
]
}
}
As you can see, the existenceCondition value is not that assessment itself, which means that this policy definition is not being used to assess (audit) the VM configuration; it will audit a resource of the Microsoft.Security/assessments type with the name bc303248-3d14-44c2-96a0-55f5c326b5fe. That's the underlying assessment for the Management ports should be closed on your virtual machines recommendation. The policy will audit the status.code field and expect NotApplicable or Healthy as values. In these cases, the assessed resource will be flagged as being compliant.
As the Azure Security Benchmark comes with more than 200 recommendations (with more recommendations constantly being added), it might become challenging to prioritize remediation. Each recommendation comes with a lot of details that help you with this challenge. Figure 7.18 shows the details view of the Management ports should be closed on your virtual machines recommendation. Every recommendation contains a Remediation steps section that explains what needs to be done to make an unhealthy resource healthy. Freshness interval is an indicator of how long it can take after the remediation until the resource appears as being healthy. By clicking on the Open query button, you are redirected to the Azure Resource Graph explorer, where you can see (and run) a KQL query that will give you an ARG presentation of this recommendation and all connected resources.
The following list is a good starting point for prioritizing remediation in your environment:
Some recommendations come with a Quick Fix feature that will let you select resources and auto-remediate them by using built-in automation capabilities. Figure 7.20 shows one of these recommendations:
With a click on the Fix button, a dialog will appear that lets you configure the corresponding settings. Once you save, the selected resource(s) will be remediated.
There are cases in which some recommendations might not be applicable to your environment. You already know that you can disable one or several recommendations directly in the security policy assigned to your environment, but that has some disadvantages:
This is where Resource exemptions come into play. Resource exemptions are a great way to exempt a resource, or a whole scope from being assessed while still being able to react dynamically and keep track of these exemptions for auditing purposes.
From a technical perspective, the resource exemption capability in Microsoft Defender for Cloud leverages the policy exemptions feature in Azure Policy. Whenever you create a resource exemption, Defender for Cloud will trigger Azure Policy to create policy exemptions for all assignments that a particular recommendation is part of. Figure 7.21 shows a recommendation with the Exempt button on top:
To create a policy exemption, you need to follow these steps:
With all the information you have to add to a resource exemption, you will always be able to determine who created which exemption for what reason. Also, by selecting a particular scope from a single resource up to an entire management group, you can react dynamically to your organization's needs. Also, from an auditing perspective, it's a great idea to leverage resource exemptions versus entirely switching off a particular recommendation.
Note
Since resource exemptions rely on policy exemptions, which is a premium capability in Azure Policy, charges may apply in the future for customers that are not using Defender for Cloud's enhanced security plans. It is included at no additional cost with the Defender for Cloud plans, which include vulnerability assessments (Defender for Servers, SQL, Containers).
Now, that you know about Defender for Cloud's CSPM capabilities, let's take a look at custom recommendations and regulatory compliance.
Besides Azure Security Benchmark as the default security policy in Defender for Cloud, you can add custom policies for getting custom recommendations in addition to the built-in recommendations. Custom recommendations will appear in the Custom recommendations security control, which does not count toward the secure score.
To add custom recommendations to Defender for Cloud, you need to create a custom policy initiative that contains all custom policy definitions:
After some time, your custom initiative will appear in the Regulatory compliance dashboard within Defender for Cloud. Also, custom policies that apply to your resources will appear in the Custom recommendations control within the Recommendations view.
Now, after you have learned how to build and add custom recommendations to Defender for Cloud, let's move on to learn more about the regulatory compliance dashboard.
The regulatory compliance dashboard within Defender for Cloud provides a different perspective to resources and their configuration. While secure score and recommendations help you understand the impact of remediating insecure configurations, regulatory compliance will provide an auditing perspective based on regulatory compliance standards.
Note
The regulatory compliance dashboard is a premium offering within Defender for Cloud. In order to use it, you need to enable Defender for Cloud's enhanced security features.
Taking Azure Security Benchmark as one of these standards, it's easy to understand: While the same initiative is being used in both views within Defender for Cloud, the secure score and recommendations view are aimed at helping you focus on security misconfiguration. With every resource you remediate, your secure score will increase. At the same time, the number of open recommendations will decrease. The regulatory compliance view is more restrictive. It doesn't consider if you only have a few unhealthy resources, whereas the rest of your environment is secure. As long as all resources are not flagged as healthy, your environment does not comply with a regulatory standard. In other words: your whole environment is non-compliant.
Figure 7.27 shows the regulatory compliance representation of the Azure Security Benchmark Network Security (NS) control. As you can see, the control is shown as unhealthy, marked by a cross in a red circle. NS-1 is a sub-control that is also reflected as being unhealthy, although some of its recommendations do not contain any failed resources. The idea of the regulatory compliance dashboard is to give you a robust compliance view that you can use as proof of an audit. In case a (sub-)control is reflected as being healthy, you are good to go. As long as a control is unhealthy, you are not yet fully compliant and need to put more effort into your environment's configuration.
It's important to understand that there is no resource exemption capability for the regulatory compliance view – and that's for a good reason! As mentioned previously, the dashboard is supposed to give you resource configuration insights from a compliance perspective. In case you were to exempt a resource, recommendation, or control, your environment would still not be compliant in relation to the particular compliance standard, you would simply no longer see the assessment. Therefore, you cannot switch off settings you don't want to focus on in this view.
By default, Defender for Cloud shows a representation of the following regulatory compliance standards:
You can disable one or several of these standards or add more standards in Defender for Cloud's Environment settings. To disable ISO 27001 and add another standard, follow these steps:
Once you are done, the new compliance standard will appear in the regulatory compliance view after some time.
You have now learned how to add custom and additional built-in policies to Defender for Cloud and know about the differences between secure score and regulatory compliance perspectives. In the next section, you will learn about enhanced security capabilities within Microsoft Defender for Cloud.
The second main pillar of Microsoft Defender for Cloud is Cloud Workload Protection, which is all about enhanced security features and threat intelligence. These enhanced capabilities are activated once you enable one or several of the Defender for Cloud enhanced security plans, as highlighted earlier in this chapter. As Microsoft is constantly working on improving existing and adding future plans to Defender for Cloud, we can only cover some of them in this chapter to give you an idea of what additional capabilities they provide. In general, when enabling Defender for Cloud plans, this will enable threat detection capabilities for the workload that is being protected by a plan, but also other advanced cloud defense capabilities, such as vulnerability assessments.
One of the most popular Defender for Cloud plans is Microsoft Defender for Servers. Defender for Servers leverages the machine's Log Analytics agent to collect threat signals from inside the operating system and create security alerts based on these signals, whenever enough evidence has been collected for malicious behavior on a machine. Figure 7.29 shows alert details for a Successful SSH brute force attack alert that has been generated by Defender for Cloud:
The alert details might vary depending on the alert type, but in general, this section contains additional context. In case of a brute force attack, the alert will contain IP address and regional information about the attacker, the accounts that have been attacked, the host (the attacked machine), and more.
The second tab in each alert contains information about what to do next.
The first section explains how to mitigate the threat by conducting immediate steps, such as escalating the alert to your organization's Security Operations Center (SOC), blocking the attacking IP addresses, and others. It also contains a reference to additional alerts on the affected resource and, to provide future attacks, a direct connection to open recommendations that apply to this resource. You can also trigger an automated response by manually sending the alert details to a Logic app that will then take action or create an alert suppression rule to suppress similar alerts in the future. This, however, should only be used with caution as you don't want to leverage Defender for Servers but not have it create alerts whenever something suspicious is happening on your machines.
In addition, most security alerts contain information about the MITRE ATT&CK tactics a particular alert belongs to, as shown in Figure 7.31:
The security alerts dashboard is built on top of Azure Resource Graph. By clicking on Open query, you are redirected to Azure Resource Graph Explorer with a query that will present the same result as being pre-filtered in the dashboard. The Sample alerts button lets you create sample alerts for most Defender plans to get an idea of what alerts will look like and which information they contain.
Some alerts in Figure 7.31 are not generated by Defender for Servers, but by MDE. MDE is, by default, integrated with Microsoft Defender for Servers. With that being said, once you enable Defender for Servers on your subscription, Defender for Cloud will take care of onboarding all protected servers to MDE at no additional cost. MDE is an Endpoint Detection and Response (EDR) solution that helps you protect your operating systems. By integrating this solution into Defender for Cloud, you can make sure to have a first-class EDR solution on your machines and, at the same time, leverage a unified cloud security view by seeing all multi- and hybrid cloud resources in a unified dashboard.
You can easily see alerts that have been created by MDE as they will contain a link that takes you to the M365 Defender portal for further investigation, as shown in Figure 7.32.
Microsoft Defender for Cloud comes with two vulnerability assessment (VA) solutions – Qualys, and MDE's Threat and Vulnerability Management (TVM). Once one of these solutions has been enabled, for example, by using auto-provisioning as explained earlier in this chapter, it will start assessing a machine for installed software and configurations and provide a list of vulnerability findings within the scope of a recommendation in Defender for Cloud's recommendations view. In addition to that, Defender for Cloud offers filtering capabilities in the inventory view that let you easily find resources that are affected by a certain vulnerability; for example, the recently announced Log4j vulnerability. Figure 7.33 shows how to filter for resources that are affected by the Log4j vulnerability (CVE-2021-44228).
Within this scope, it doesn't make any difference if you use the Qualys or TVM integration. Qualys, however, is great for environments in which another EDR solution is being used. Since TVM relies on MDE, it can only be used when MDE integration has been enabled. On the other hand, TVM brings a unique capability to Defender for Cloud: the software inventory. Once enabled, TVM will provide information about installed software and software versions to the Defender for Cloud inventory, which lets you filter the view for installed applications and installed application versions. In addition to that, it will add software information to every machine's resource health blade.
By clicking on the number of known vulnerabilities, you are presented with a list and details of vulnerabilities that have been found on this particular resource and with corresponding remediation steps.
In addition to the integration with MDE and threat detection capabilities, Microsoft Defender for Servers offers additional advanced cloud defense capabilities.
Advanced cloud defense presents additional tooling for enhanced threat mitigation. Four additional tools are available:
Let's look at them in detail.
Adaptive application controls enable you to have control over which applications can run on servers protected by Defender for Cloud. This applies both to Azure and non-Azure VMs and servers. We can control what can run on servers by allowing only specific applications or types of applications to run and prevent any malicious or unauthorized software. We can create different groups that will track the file type protection based on location, operating system, and environment type. Servers can be added to multiple groups to track different protection modes. An example of a group to protect a Windows VM in Azure, located in the Europe location, with the audit option for any file, is shown in the following screenshot:
Azure VM management is another topic that needs to be taken very seriously. A best practice is to perform any management tasks only over a secure connection, using a P2S or S2S connection. An alternative is to use one VM as a jump box, and then perform management from there. But even in this situation, the connection must be secure. The recommended way today is to use Azure Bastion as a native service to connect to Azure VMs.
Just-in-time access for Azure VM is used to block inbound traffic to VMs until specific traffic is temporarily allowed. This reduces their exposure to attacks by narrowing down the surface and enabling access. Enabling Just In Time (JIT) will block inbound traffic on all ports that are usually used for management, such as RDP, SSH, or WinRM. The user must explicitly request access, which will be granted for a period of time, but only for a known IP address. This approach is the same as is used with Privileged Identity Management (PIM), where having rights doesn't necessarily mean that we can use them all the time; we have to activate/request for them to be used for a period of time.
Important Note
JIT access for Azure VMs supports only VMs deployed through Azure Resource Manager (ARM). It's not available for non-Azure VMs or legacy Azure VMs deployed through Azure Service Management (ASM).
JIT can be configured from the Defender for Cloud blade, or from the Azure VM blade. Configuring JIT for an Azure VM requires a few parameters to be defined, such as which ports we want to use, whether we want to allow access from a specific IP address or range in the Classless Inter-Domain Routing (CIDR) format, and the maximum period of time for which access will be available.
An example of configuring JIT is shown in the following screenshot:
By default, you have the most common management ports available. You can edit rules for these ports, and delete or add custom rules. Besides ports, we can change protocols, the allowed source, and the maximum request time (this can be between 1 and 24 hours). Once JIT is configured, access needs to be requested each time we want to access the VM. This, again, can be done from the Defender for Cloud blade or the Azure VM blade. While you are requesting, you can ask for a specific (or more than one) port to be opened, state whether you want to enable access from your current IP address or from an IP range that's been pre-defined by an administrator, and finally, you need to define the time range. The time range depends on the configuration. By default, the time ranges from 1 to 3 hours, but can be configured for up to 24 hours.
Requesting JIT access is shown in the following screenshot:
JIT uses NSGs to control traffic that is allowed or blocked. When JIT is configured for an Azure VM, NSG rules are created to block access over configured ports. Ports that are not configured for JIT should be automatically blocked unless configured otherwise. When JIT access is requested, another NSG is temporarily created that will allow access on the requested port. The new NSG rule will have a higher priority and override the block rule to enable access. Once the requested time period expires, the allow rule will be deleted, and access will be blocked again.
Important Note
If JIT is in use, no NSG rules for management ports should be created manually. Azure Security Center should control these ports at all times. If you create rules manually, you may override JIT rules, or you may create a rule that will allow one of the management ports at all times and use JIT for the rest of the management ports. Both situations render JIT pointless.
Advanced network hardening analyzes our traffic communication patterns. An analysis is performed to determine whether NSG rules are overly permissive and create a threat in the form of an increased attack surface. Three potential threats are tracked: a malicious insider, data spillage, and data exfiltration. Azure Security Center reports all threats and assesses the current rules to determine whether changes to NSG rules are required and offers recommendations that will increase security.
File integrity monitoring is used to validate files and registries of the operating system and application software. It tracks changes and compares the current checksum of the file with the last scan of the same file to see whether they are different. Information can be used to determine whether changes are valid or the result of a malicious modification.
Microsoft Defender for Containers is the latest plan that has been added to Defender for Cloud. It consolidates two deprecated plans (Defender for Container Registries and Defender for Kubernetes) and adds additional capabilities.
Within the scope of Container Registries, Defender for Containers can scan container images for vulnerabilities. Images are scanned when they are pushed to the registry, and regularly once a week after they have recently been pulled (within the last 30 days). In addition, the plan adds threat detection for cluster- and host-level protection.
One of the most interesting additions is the Daemon Set that's being used as a replacement for the Log Analytics agent. Before that, the agent had to be installed on all worker nodes and Defender for Servers had to be enabled to provide host-level detection. With the new plan, the Daemon Set runs inside the Kubernetes cluster so it can also protect clusters that use virtual machine scale sets (VMSS). It also no longer depends on Defender for Servers for host-level detection.
Defender for Cloud's threat detection provides information and reports on detected threats. It's very useful to have information on what is happening with our resources and whether anyone is trying anything against us. Information provided by the enhanced security plans can be eye-opening. You might not even be the intended target but still get attacked as a victim of opportunity or due to a moment of carelessness.
To provide an example, we created an experiment where we deployed five Azure VMs and left the RDP port accessible over a private IP address. These were five blank VMs with no data and nothing special about them. What happens is that bad guys scan public IP addresses in the hope of detecting open ports. After something like that is detected, a brute-force attack will begin. Brute-force attacks use a combination of most common usernames and passwords to try to connect. These five Azure VMs, running for a single month, got hit approximately 20,000 times each. All these attacks can be tracked and seen in Microsoft Defender for Cloud's security alerts view, as demonstrated earlier in this chapter. With that knowledge, it's always a great idea to enable Defender for Cloud's enhanced security plans so you get threat intelligence, vulnerability assessments, and additional cloud defense capabilities. In the end, these plans will provide you with useful information to stop an attack before it actually starts.
Finally, let's take a look at automation capabilities within Defender for Cloud that let you improve security coverage, automate responses, or remediate recommendations at scale in the next section.
Microsoft Defender for Cloud comes with several automation and export capabilities that help you further customize your experience and automatically react to alerts or recommendations.
With continuous export, Defender for Cloud offers a capability to export security alerts, recommendations, secure scores, and regulatory compliance assessment results to a Log Analytics workspace, or to an Azure event hub. By exporting this set of information, you are offered a huge set of capabilities. With data exported to an event hub, you can connect Defender for Cloud to a third-party SIEM solution, such as IBM QRadar, Splunk, SumoLogic, ArcSight, and others. By exporting information to a Log Analytics workspace, you can leverage the data to build your own, custom dashboards based on Power BI, or Azure Monitor Workbooks.
Tip
The Defender for Cloud portal will always provide a just-in-time view of your environment. In case you want access to historical information, for example, in a secure score over time report, you can leverage continuous export to have access to that data in a Log Analytics workspace.
To configure continuous export, follow these steps:
While continuous export is the perfect solution for exporting Defender for Cloud data, either whenever a change happens or based on a weekly schedule, you can also automatically react to these changes when using Workflow automation, a technology that is covered in the next section.
Workflow automation is a capability that lets you leverage Azure Logic Apps for automating responses to recommendations, regulatory compliance assessments, or security alerts.
Azure Logic Apps is a cloud service that helps you to schedule, automate, and orchestrate different tasks, processes, and workflows. It also offers the ability to integrate with different applications, datasets, systems, and services across organizations. This makes it very useful in a number of scenarios, whether you want to create a repetitive automated task, trigger an action whenever a condition happens, or connect different systems.
Logic apps have built-in trigger types to automatically react to alerts, changes in recommendations, or changes in regulatory compliance assessments, as shown in Figure 7.40:
In the end, workflow automation is the technology to connect Logic apps to Defender for Cloud. In case you want to automatically react to a particular alert type, you first need to create a Logic app that uses the When an Azure Security Center Alert is created or triggered Logic app trigger. After connecting the Logic app to Defender for Cloud whenever a new alert is created, it is evaluated. Based on some pre-filter configuration, the alert information is then sent to the Logic app. The Logic app in the end will do whatever it has been created for.
To create a workflow automation, you need to do the following:
Tip
You can find a list of all Microsoft Defender for Cloud security alerts in the Defender for Cloud alerts reference at https://aka.ms/DefenderForCloudAlerts.
Logic apps that are created with one of the built-in Defender for Cloud trigger types cannot only be used within the scope of workflow automation; you can also trigger them manually from alert or recommendation details. Every alert or recommendation comes with a Trigger logic app button. For recommendations, you need to select one or several affected resources and then click the button, as shown in Figure 7.42:
Once you click the Trigger logic app button, you can see that in the dialog that appears, you can only select Logic apps that use the Recommendations trigger. If you click the button from alert details, it will only show Logic apps with the alert trigger type.
Tip
Microsoft has published a sample automation to automatically block an incoming brute-force attack by creating a deny rule in a VM's NSG. You can find and deploy this Logic app at https://aka.ms/BlockBruteForce.
All Microsoft Defender for Cloud data is exposed by a REST API endpoint in the Microsoft.Security API. You can use all of its information in Logic apps, but also in your own applications.
Tip
You can find all Defender for Cloud REST API endpoints in the API reference at https://aka.ms/DefenderForCloudAPIRef.
As the new product name indicates, Microsoft Defender for Cloud is no longer an Azure-focused security solution. It's rather a CSPM and CWPP for both, multi- and hybrid cloud environments. At Microsoft Ignite in November 2021, Microsoft announced its new API-based multi-cloud CSPM for AWS. As of now, you no longer need to enable AWS Security Hub in order to connect your resources to Defender for Cloud. By integrating AWS in the native Defender for Cloud experience, it is now very easy to connect your resources from there and get recommendations and visibility into their security posture in the same, unified experience. In addition, you can opt in to use Microsoft Defender for Servers and/or Defender for Containers on your AWS resources, too.
Once you have connected an AWS account to Defender for Cloud, assessments will start, based on the AWS CIS 1.2.0 and AWS Foundational Security Best Practices compliance standards. Recommendations for AWS resources will appear in the recommendations view, and they will also affect your secure score. You can even filter for recommendations that apply to your AWS resources by using the Environment filter in the recommendations view. Just make sure you select AWS (preview) only, as shown in Figure 7.44:
For hybrid and multi-cloud machines (VMs, on-premises servers, and so on), Defender for Cloud leverages Azure Arc for making non-Azure resources Azure-like. Once a machine has been onboarded to Azure Arc, Defender for Cloud can use Azure-native capabilities to install agents, manage settings, and much more besides. From a Defender for Cloud perspective, it makes no difference if the machine is natively running on Azure, or if it has just been connected. All agents that are used within the scope of Defender for Cloud can be installed as Arc extensions, and so Defender for Servers, Containers, and SQL on machines can treat these machines as if they were part of the Azure environment.
Microsoft Defender for Cloud helps us to keep our hybrid and multi-cloud environment safe in various ways, from offering recommendations on what needs to be improved to detecting threats as they happen, to response automation to act on possible threats. With different settings and policies, we can define our focus, track the health of our resources, and create a more secure infrastructure.
In this chapter, we discussed how important Azure Security Center as a CSPM and CWPP tool is. The next chapter will focus on Microsoft Sentinel, which is Microsoft's cloud-based Security Information and Event Management (SIEM) and Security Orchestration, Automation, and Response (SOAR) solution.
B. Azure SQL Database
C. Log Analytics Workspace
A. Recommendations
B. Alerts
C. Issues
D. Fixes
A. Azure Monitor alerts
B. Logic apps
C. PowerShell
D. Azure CLI
A. Has the same level of access rights
B. Has fewer access rights
D. Has to request access
E. Both A and C
A. It will be automatically blocked.
B. The user can create an automated response to an attack.
C. A security alert is automatically created.
D. Both B and C.
A. Security Information and Event Management (SIEM)
B. Cloud Security Posture Management (CSPM)
C. Security Orchestration, Automation, and Response (SOAR)
D. Cloud Workload Protection (CWP)
E. Both B and D