The threat landscape

Azure Security

There are two aspects of Azure Security. One is platform security—that is, how Microsoft keeps its Azure platform secure against attackers. The other is the Azure Security capabilities that Microsoft offers to customers who use Azure.

The Azure infrastructure uses a defense-in-depth approach by implementing security controls in different layers. This ranges from physical security, to data security, to identity and access management, and to application security, as shown in Figure 1-6.

FIGURE 1-6 Multiple layers of defense

From the Azure subscription-owner perspective, it is important to control the user’s identity and roles. The subscription owner or account administrator is the person who signed up for the Azure subscription. This person is authorized to access the Account Center and to perform all available management tasks. With a new subscription, the account administrator is also the service administrator and inherits rights to manage the Azure Portal. Customers should be very cautious about who has access to this account. Azure administrators should use Azure’s role-based access control (RBAC) to grant appropriate permission to users.

Once a user is authenticated according to his or her level of authorization, that person will be able to manage his or her resources using the Azure Portal. This is a unified hub that simplifies building, deploying, and managing your cloud resources. The Azure Portal also calculates the existing charges and forecasts the customer’s monthly charges, regardless of the amount of resources across apps.

A subscription can include zero or more hosted services and zero or more storage accounts. From the Azure Portal, you can provision new hosted services, such as a new VM. These VMs will use resources allocated from compute and storage components in Azure. They can work in silos within the Azure infrastructure, or they can be publicly available from the Internet. You can securely publish resources that are available in your VM, such as a web server, and harden access to these resources using access control lists (ACLs). You can also isolate VMs in the cloud by creating different virtual networks (VNets) and controlling traffic between VNets using network security groups (NSGs).

VM Protection

When you think about protecting VMs in Azure, you must think holistically. That is, not only must you think about leveraging built-in Azure resources to protect the VM, you must also think about protecting the operating system itself. For example, you should implement security best practices and update management to keep the VMs up to date. You should also monitor access to these VMs.

Some key VM operations include the following:

• Configuring the monitoring and export events for analysis

• Configuring Microsoft antimalware or an AV/AM solution from a partner

• Applying a corporate firewall using site-to-site VPN and configuring endpoints

• Defining access controls between tiers and providing additional protection via the OS firewall

• Monitoring and responding to alerts

Network protection

Azure virtual networks are very similar to the virtual networks you use on-premises with your own virtualization platform solutions, such as Hyper-V or VMware. Azure uses Hyper-V, so you can take advantage of the Hyper-V virtual switch for networking. You can think of the Hyper-Virtual switch as representing a virtual network interface to which a VM’s virtual network interface connects. Figure 1-7 illustrates how Azure virtual networks are distributed in a multitenant environment.

FIGURE 1-7 Azure network provides isolation even within the same tenant virtual network

One thing in Azure that might be different from what you use on-premises is how it isolates one customer’s network from another’s. On-premises, you might use different virtual switches to separate different networks from each other. That’s perfectly reasonable. You can do that because you control the entire network stack and the IP addressing scheme on your network, as well as the entire routing infrastructure. Azure can’t give each customer that level of control because it needs to reuse the same private IP address space among all the different customers, and it can’t tell each customer what segment of the private IP address space to use for their VMs. It can, however, apply isolation between tenants to better manage the private IP space.

Network access control is as important on Azure virtual networks as it is on-premises. The principle of least privilege applies both on-premises and in the cloud. One way to enforce network access controls in Azure is by taking advantage of NSGs. An NSG is equivalent to a simple stateful packet-filtering firewall or router, which is similar to the type of firewalling done in the 1990s. (I say this not to be negative about NSGs, but to make it clear that some techniques for network access control have survived the test of time.)

Azure DDoS protection

Azure can provide scale and expertise to protect against large and sophisticated DDoS attacks. However, following the share responsibility model that we have in cloud computing, customers must also design their applications to be ready for a massive amount of traffic. Some key capabilities for applications include high availability, scale out, resiliency, fault tolerance, and attack surface area reduction. Azure DDoS protection is part of the defense in depth for Azure Networks approach, as shown in Figure 1-8.

FIGURE 1-8 Azure network defense in depth approach

By default, Azure provides continuous protection against DDoS attacks as part of the DDoS Protection Basic, which is not charged. However, if you want extra metrics, alerts, mitigation reports, mitigation flow logs, policy customization, and support, you need to go to Azure Protection Standard. You can provision Azure DDoS on a Virtual Network using the Azure Portal or PowerShell. If you don’t have Azure DDoS Standard enabled on your subscription, Azure Security Center will trigger a recommendation, like the one shown in Figure 1-9.

FIGURE 1-9 Azure Security Center recommendation to enable Azure DDoS Standard

Storage protection

Azure Disk Encryption is a technology that enables you to encrypt the VM disk files for your Azure VMs. Azure uses Windows Hyper-V as its virtualization platform, so the VMs you run on Azure use the VHD file format. With Azure Disk Encryption, you can encrypt both the operating system VHD and any data disk VHD files that you have attached to your VMs. Figure 1-10 shows the encryption options for the various Azure services that use storage.

FIGURE 1-10 Azure network provides isolation even within the same tenant virtual network

Keep in mind that if an attacker somehow manages to access and copy your VM disk files, he or she would not be able to mount them. This is because the disks are encrypted, and the attacker likely does not have the key required to decrypt them. Microsoft recommends that you use this powerful security technology on any VM you run on Azure. You should use similar technology on any VMs you run on-premises as well.

Another option is to use Azure Storage Service Encryption (SSE) for data at rest. This service helps you protect your data. When you use this feature, Azure Storage automatically encrypts the data prior to persisting to storage and decrypts it prior to retrieval. The encryption, decryption, and key-management processes are totally transparent to users.

Advanced Threat Protection for Azure Storage

When you enable Advanced Threat Protection (ATP) for Azure Storage, you can be notified via alerts when anomalous access and data exfiltration activities occur. These alerts include detections such as:

• Access from unusual location

• Unusual data extraction

• Unusual anonymous access

• Unexpected delete

• Access permission change

• Upload Azure Cloud Service package

You enable this capability on the Storage Account that you want to protect by just turning it ON, as shown in Figure 1-11. Advanced Threat Protection (ATP) for Azure Storage Alerts will be streamed to Azure Security Center, which allows you to keep all security-related alerts in a single location.

FIGURE 1-11 Enabling ATP for Storage account in Azure

Identity

Azure Identity Protection is part of Azure Active Directory (AD), and it is widely used because of its capabilities to detect potential identity-related vulnerabilities and suspicious actions related to the identity of your users; it’s also widely used because of its capability to investigate incidents. Azure AD Identity Protection alerts will also be streamed to Azure Security Center.

Logging

Throughout the years, it has become more and more important to always have logs available to investigate security-related issues. Azure provides different types of logs; understanding their distinctions can help during an investigation. Data plane logs will reflect events raised as part of using an Azure resource; an example of this type of log would be writing a file in storage. The control plane logs reflect events raised by Azure Resource Manager (ARM); an example of this log would be creating a storage account.

Those logs can be extracted from different services in Azure. The diagram in Figure 1-12 shows how the different logging tiers.

FIGURE 1-12 Different tiers of logging in Azure

It is very important to understand this tier model in order to have a better idea of the areas you should focus on when trying to extract logs. For example, if you want to see the VM activities (provisioning, deprovisioning, and so on), you need to look at the logs in the Azure Resource Manager level. To visualize activity logs for operations on a resource from the “control plane” perspective, use Azure Activity Log. Diagnostics Logs are emitted by a resource and provide information about the operation of that resource (the “data plane”).

Because this book is focused on Azure Security Center, it is important to highlight the need to visualize actions performed in the Security Center configuration. Let’s use a very simple example: I noticed that my security contact information only has one e-mail listed, though I used to have three email addresses. When did that happen? To investigate when this change took place, you can use Azure Activity Log. For this particular case, you should see an entry similar to the one shown in Figure 1-13.

FIGURE 1-13 Azure Activity Log

If you click one of the completed Delete Security Contact actions, you will have access to the JSON content. There, you will be able to see more info regarding who performed this action and when it was done.