Enabling Microsoft Defender for Cloud via Azure Policy

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:

1.  Make sure to log in with an account that has Security Admin permissions, open Azure Policy, and search for the Enable Azure Security Center on your subscription policy definition. 

Figure 1.1 – Policy definition to enable Defender for Cloud

2.  Select the definition, and then click Assign:

Figure 1.2 – Assigning the policy definition

3.  Select Tenant Root Group as the assignment scope. There are no other parameters you need to change. 

Figure 1.3 – Assigning the policy definition to your Tenant Root Group

4.  Click Review + create and then Create.

5.  After the definition has been assigned, navigate to the Assignments blade in Azure Policy and select the assignment you have just created. In the assignment, click on Create Remediation Task. This remediation task is necessary to make sure Defender for Cloud will not only be enabled for future subscriptions, but also for all subscriptions that already exist.

Figure 1.4 – Create Remediation Task

6.  Select all applicable resources (if any) and click on Remediate.

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.

Thant Zin Phyo@Cracky (MCT, MCE, MVP)

Understanding Azure Front Door

 Azure Front Door works very similarly to Application Gateway but on a different level. Like Application Gateway, it's an L-7 load balancer with an SSL offload. The difference is that Application Gateway works with services in a single region, whereas Azure Front Door allows us to define, manage, and monitor routing on a global level. With Azure Front Door, we can ensure the highest availability using global distribution. A similar thing can be achieved with Azure Traffic Manager (in terms of global distribution),  but this service lacks L-7 load balancing and SSL offloading.

What Azure Front Door provides actually combines Application Gateway and Traffic Manager to enable an L-7 load balancer with global distribution. It's also important to mention that a WAF is also available on Azure Front Door. Using a WAF on Azure Front Door, we can provide web application protection for globally distributed applications.

Thant Zin Phyo@Cracky (MCT, MCE, MVP)

Hub-and-spoke network topology

For large and enterprise organizations, a hybrid cloud can become complex, and hard to manage and secure. With multiple VNets and hybrid cloud implementation, it can become difficult to monitor network traffic or even know the exact traffic flow. For complex network topologies, it is recommended to implement the hub-and-spoke model. In this model, we have a central point (hub) to which all on-premises connections and VNets (spokes) are connected. This way, traffic is easy to monitor, inspect, and manage.

There are two possible implementations for the hub-and-spoke topology in Azure.

Hub VNet

Hub VNet implementation has a single VNet and a central network where everything else is connected:

Figure – Hub virtual network

All other networks (spokes) are connected to the hub VNet. On-premises networks are connected over VPN Gateway (or ExpressRoute) and VNets are connected with peering. A hub network can come with other network resources, such as Azure Firewall, Azure Bastion, and Azure DDoS Protection. All traffic needs to go through the hub network and it enables us to easily manage network traffic and monitor  it in a central location.

Let's say we need to connect from an on-premises network to one of the VNets in Azure. The on-premises network is connected to the hub over VPN, and the VNet is connected to the hub over peering. If traffic needs to go from one network to another, it needs to go through the hub network. Using the hub network, we can define what types of traffic are allowed as well as monitor and inspect network packages.

A similar process can be applied when only VNets are in place. All VNets are only connected to hub networks over peering. If traffic needs to go from one network to another, it needs to go through the hub network.

Azure Virtual WAN is an alternative to the previous design, replacing the hub VNet with a managed service. All on-premises and VNets are still connected to the hub, but instead of managing hub networks ourselves, we have a managed service in place. Besides not managing hub networks, another benefit of this design is easier connectivity of networks across regions. Under Azure Virtual WAN, we can have multiple hubs in different regions for connecting VNets in the corresponding region. Communication between regions is done over a connection between hubs (over the  Azure backbone network). All hubs are still managed in a central location, in Azure Virtual WAN.

Let's move on to networking in PaaS and see what else is available, besides securing PaaS with service endpoints. We can have better network control and prevent unwanted traffic even with publicly available endpoints. 

Thant Zin Phyo@Cracky (MCT, MCE, MVP)

Azure Bastion

When running IaaS, exposing management ports such as RDP (port 3389) or SSH  (port 22) is not a good idea. Bad actors are constantly scanning public networks in  the search for exposed endpoints. If they detect such a port open, they will trigger  a brute-force attack in the hope of gaining access to a service. This is usually mitigated by creating a jump box, a VM that enables us to securely connect to it before connecting to other VMs on the network.

Azure Bastion is a service that provides the ability to connect to our VMs using the browser and Azure portal. Similar to a jump box, it provides a secure way to connect  to our virtual network. But unlike a jump box (which we need to maintain and update), Azure Bastion is a fully managed service. With Azure Bastion, we are able to securely access VMs over RDP/SSH from the Azure portal over TLS. 

Thant Zin Phyo@Cracky (MCT, MCE, MVP)

Azure DDoS protection

 Distributed Denial of Service (DDoS) is one of the most common cyber attacks. A DDoS attack attempts to overload system resources and make a system unavailable to legitimate users. An attack can target any endpoint that is publicly reachable through the internet. 

Azure DDoS protection comes in two different flavors: Basic and Standard. 

Every property in Azure is protected by DDoS Basic protection at no additional cost.  To protect customers and prevent impacts on other customers, Basic protection provides defense against network layer attacks with always-on traffic monitoring and real-time mitigation. It requires no additional configuration or any user action; it is a built-in service protecting all Azure services, both IaaS and PaaS.

The standard plan provides additional functionalities, including the following:

•  Guaranteed availability

•  Cost protection

•  Custom mitigation policies

•  Metrics and alerts

•  Mitigation reports and flow logs 

•  DDoS rapid response support

Azure DDoS Standard protection is a tenant-wide service protecting up to 100 public IP addresses by default, with an additional charge for each public IP address over 100. There is no need to deploy an instance in each subscription; one instance can protect all endpoints across tenants in multiple subscriptions.

However, the Standard plan comes in a bundle of 100 IP addresses by default and should be used only when multiple endpoints require protection. 

Azure DDoS Protection reference architectures

Thant Zin Phyo@Cracky (MCT, MCE, MVP)

Connecting on-premises networks with Azure

In most cases, we already have some sort of local infrastructure and want to use the cloud as a hybrid where we combine cloud and on-premises resources. In such cases, we need to think about how we are going to access VNet from our local network.

There are three options available:

• Point-to-Site connection (P2S) is usually used for management and/or end use connections. It enables you to create a connection from a single on-premises computer to Azure VNet. It has a secure connection, but not the most persistent one, and shouldn't be used for production purposes, only to perform management and maintenance tasks, or to access applications.

•  Site-to-Site connection (S2S) is a persistent connection that enables a network-to- network connection. In this case, that would be from an on-premises network to  a VNet, where all on-premises devices can connect to Azure resources and vice versa. Using S2S enables you to expend local infrastructure to Azure, use a hybrid cloud, and take advantage of the best things both on-premises and cloud networks can offer. 

•  ExpressRoute is a direct connection from a local data center to Azure. It doesn't go over the internet and offers a much better connection. Compared to an S2S connection, ExpressRoute offers more reliability and speed with lower  network latency.

Thant Zin Phyo@Cracky (MCT, MCE, MVP)

Introducing security defaults

Security defaults are a rather new capability that will enforce basic identity security mechanisms across an Azure AD. These capabilities will ensure that user and administrator accounts are better protected from common identity-related attacks, such as brute force, or password spray.

Security defaults are enabled by default on new Azure AD enrollments but might need to be manually enabled on existing ones. To manage security defaults, navigate to Azure Active Directory and click the Properties option in the left navigation pane. Then, click the Manage Security defaults link and switch the Enable Security defaults setting to Yes , as shown in Figure 1.1:

Figure 1.1 – Enable Security defaults

Security defaults will require all users and administrators to use MFA and block legacy authentication protocols. Once security defaults have been enabled, users will be asked to proceed through the MFA procedure you already know from the previous section.  However, the first screen that users are presented with will look slightly different, as shown  in Figure 1.2:

Figure 1.2 – Security defaults have been enabled

Besides the Use a different account option, or to proceed by clicking Next, there is a third option that will let users skip the MFA configuration for now. However, 14 days after the first sign-in event, every user is required to configure MFA, so this option will no longer be available as of then. The rest of the configuration is the same as you learned about in the MFA activation from a user's perspective section. Security defaults are a great and easy way to protect all accounts with the same setting across your Azure AD directory. Now that you know how to enable MFA, and how to configure the settings from a user's perspective, let's move one step further and learn how Conditional Access can be used to fine-tune the MFA process according to your company's business needs.

Thant Zin Phyo@Cracky (MCT, MCE, MVP)

MFA activation from a user's perspective

After enforcing MFA for Cracky, a new window will appear after his next successful login, telling him that his organization needs more information to protect his account, as shown in Figure 1.1:

Figure 1.1 – New message at the first login after enforcing MFA

Cracky now only has two options: Use a different account to log in or click Next to proceed through the MFA activation process. With that being said, you should inform your users before activating MFA to let them know what's going to happen and to reduce the number of support tickets required!

Let's look at what happens if Cracky decides to complete the process:

1. Cracky decides to proceed, so he clicks the Next button.

2. On the following screen, Cracky is asked to download the Microsoft Authenticator app to his smartphone. Once finished, he clicks Next.

Figure 1.2 – Downloading the Microsoft Authenticator app

3. The next screen gives Cracky a short intro into what's coming, and he presses Next again.

Figure 1.3 – Keep your account secure

4. Cracky is asked to use his authenticator app to scan the QR code. This will set up his account in the Microsoft Authenticator app on his phone.

Figure 1.4 – Scanning the QR code to set up the account in the Microsoft Authenticator app

5. After the account has been set up in the app, clicking on the Next button will trigger an MFA challenge in the app. Cracky approves the login attempt and the account has been set up successfully.

Figure 1.5 – Notification has successfully been approved

Now that you know how to configure MFA from an administrator's and a user's perspective, let's move one step further and take a look at security defaults in Azure AD.

Thant Zin Phyo@Cracky (MCT, MCE, MVP)