Thant Zin Phyo

 Azure landing zones are a vast topic that we could write a book on in terms of their design, implementation, and how they are assessed. In simple terms, an Azure landing zone talks about subscription democratization, where we have multiple subscriptions meant for different types of workloads. Following this architecture will help you build an architecture that is responsible for scalability, security, governance, compliance, networking, and identity. There are two types of landing zones: •  Platform landing zones: A central team for several central teams is split by functions, such as networking, identity, and others. It will deploy subscriptions to deliver unified services. These subscriptions are used for various applications and workloads. Platform landing zones are usually used to consolidate certain essential services for better efficiency and ease of operations. Examples of these essential services include networking components (ExpressRoute, VPNs, firewalls, NVA, ...

 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. Figure  – AWS connectors in Defender for Cloud's environment settings view 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 Pra...

 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. ...

 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 1.1: Figure 1.1 – Secure score, security controls, and recommendations Figure 1.1 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...

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.  Cl...

 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)

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 DDo...

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)

 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...

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 ...

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 ...

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 – Kee...

 From an administrator's perspective, MFA activation in Azure AD is straightforward: 1. In the Azure portal, navigate to Azure Active Directory and select the Users navigation pane. In the upper navigation pane, select Per-user MFA, as shown in Figure 1.1: Figure 1.1 – MFA activation in the Azure portal 2. You will be redirected to a retro-style portal at the windowsazure.com domain, in which you can enable or disable MFA for single users or bulk-update them by selecting several accounts or using a CSV file in the users tab. 3. Before you enable MFA for all user accounts, first switch from the users tab to the service settings tab to configure some custom settings for your environment, as shown in Figure 1.2: Figure 1.2 – Service settings for MFA The first option is to allow or disallow users to create app passwords for legacy non-browser apps that do not support MFA. Outlook used to be such an application back in the days; however, nowadays, most applications should be able to aut...

There are few technical features that protect your accounts more than using MFA. With MFA, it is not enough to know a username and a password; you are also challenged to prove who you are using another authentication factor. With MFA, you generally need to be able to log in with the following: • Something you are, such as your user account name or a biometric attribute • Something you know, such as a password • Something you have, such as an additional authentication factor (smartcard, smartphone app, or security key) Given the fact that an MFA challenge is only triggered following a successful login attempt, it is still reliant on passphrases that are not easy to guess. In other words, if an MFA challenge is triggered, the respective username/password combination has already been successfully validated (refer to the following screenshot for reference): Today, there are several options for using MFA in Azure AD: • A push message from the Microsoft Authenticator smartphone app • A one-t...

Dictionary attacks, such as brute-force and password spray attacks, still find success every  day. In a dictionary attack, attackers try combinations of usernames and well-known and  often-used passwords against an authentication service. The brute-force attack is more  noisy and easier to recognize. With brute force, an attacker will try lots of passwords for   a single user account, hoping that one of the attacks will be successful. In the backend, you  will see lots of failed login attempts, so you can easily react to them. However, a password   spray attack is way more sensitive since an attacker will only use a small set of passwords  against lots of user accounts. If the attacks are very slow and widely distributed, it is very  hard to notice an attack. To avoid successful password spray and brute-force attacks in the  cloud and, to be more precise, in Azure AD, there are some easy best practices: • Encourage your users to u...