How to start handling Azure network security
Before adopting Microsoft Azure, it's important to consider how to secure the cloud network. That's where network security groups and Azure Firewall come in.
The COVID-19 pandemic hastened the move to the cloud for many organizations. Security, however, was often not considered. Cloud security requires different techniques and tools than on-premises security, which left many security teams learning how to protect the cloud on the fly.
To help security teams secure Microsoft Azure, author Steve Miles wrote Azure Security Cookbook, a book of "recipes" security professionals can use to immediately protect the cloud.
Miles said one area that especially needs security considerations is the Azure network. His book has the recipes security teams need to get the job done, from implementing Azure Firewall to using network security groups (NSGs).
Miles sat down with TechTarget Editorial to discuss some quick and easy ways to implement Azure network security. Read on to learn what NSGs are and why he recommends using a hub-and-spoke topology to protect Azure.
Editor's note: The following interview has been edited for clarity and length.
What is the most difficult aspect of securing Microsoft Azure?
Steve Miles: Changing one's mindset. In the public cloud, it's about protecting resources that have moved into cloud provider data centers and are not in control of your own environments. While it's a little cliché to say, the perimeter has moved to the cloud. When everything was on premises, you secured it by network location and trusted that location. You knew exactly where your data and applications were and could secure them like a castle. Anybody inside was safe and trusted, while anything or anyone outside was untrusted. You didn't let anyone from the outside into the perimeter, and if you did, you added layers of security, authentication and authorization. But now -- thanks to COVID-19 -- many workforces are remote or hybrid. That poses a whole new challenge because the traditional data center-based trusted network perimeter no longer exists. So, the question becomes: How do you secure resources when you can't trust the network like in the past?
You must start looking at other ways to secure the cloud. Refocus your mindset to go beyond the defense-in-depth approach and adopt zero trust. Now more than ever, it's important to understand the mindset that everybody is outside the safety and trust of the firewall and the corporate network perimeter. Reinforce the mindset of zero trust, and focus on verifying users and their access rights before allowing them to access cloud resources.
What are some quick and easy ways to start securing Azure networks?
Miles: First, figure out how to handle IP addresses. Ensure you are not overusing public IP addresses, especially when it comes to VMs, storage and databases, for example. If you use public IP addresses, it should only be for a load balancer or a network virtual appliance, such as a network firewall, web application firewall [WAF] or a VPN gateway. Remove any public IP addresses used that are not needed.
Second, look at management ports. When everyone started working from home when COVID-19 hit, IT departments needed remote access to systems, which they got by opening management ports, such as Remote Desktop Protocol and SSH. This bypassed security governance in the process and led to a massive rise in brute-force attacks. IT needs to lock down and secure management ports. This can be done in a number of ways, such as using Azure Bastion. Bastion is the best way to handle remote access to VMs. It gives you a jump host service that can be used in combination with just-in-time access to lock down management port access.
Once IP addresses and management ports are handled, turn to other tasks. Use NSGs and Azure Firewall for network traffic flow filtering. For protocol attacks and Layer 7 traffic, deploy a WAF, combine it with Azure Front Door and look at DDoS measures.
From there, segment the network to protect against lateral attacks so that, if one VM is compromised, attackers don't have access to anything else on the virtual network or on-premises networks. To do this, use NSGs in combination with a network virtual appliance from a vendor, or use Azure Firewall. This gives you a segmented network where you can create a network DMZ and different trust zones.
You mentioned NSGs. What are they, and how do they provide Azure network security?
Miles: NSGs can be considered a network packet filter and perform a similar function to a network access control list. An NSG says, 'This traffic can go here but not there.' NSGs are applied in-depth behind the firewall to protect lateral east-west traffic and provide network segmentation, and Azure Firewall handles inbound north-south traffic. Think of it like a front door and corridors. NSGs protect every room in the corridor behind that front door. Attackers may get through the firewall, so NSGs ensure they don't then have access to everything on the network to conduct a lateral attack.
NSGs enable granular access to provide the least amount of access any application or workload traffic needs. Azure Firewall and NSGs create a solid defense-in-depth approach.
In the book, you recommended following a hub-and-spoke topology when creating Azure Firewall. Why is that?
Miles: The hub acts as a centralized control point, segments the network and allows the control of traffic between the spokes. This approach creates a perimeter network, where each spoke is a zone to manage workload network traffic. This is analogous to a traditional on-premises VLAN [virtual LAN] design behind a network firewall.
Isolating the network spokes enables you to control and manage the spoke networks' workloads and traffic. This gives autonomy and granularity of control at the spoke level, while inheriting a governance model from the hub with centralized protection and control through a shared services hub.
Think of your security layout as a castle. At the front is the portcullis, which means you only have one point of entry to secure. If you had 20 spokes, you don't need to protect each one from the internet because you have one point of entry to guard. From there, you can segment the network behind that entry point. If you didn't take the hub-and-spoke approach -- say, you had 10 environments -- you would have 10 entry points, 10 things to protect, 10 attack surface areas and 10 areas to control. This would impact operations and costs. A hub-and-spoke topology allows you to have shared services -- for example, a highly restricted zone in front of multiple different environments, such as product, user acceptance testing, development, testing, etc. This approach allows you to segment the network and use central compliance, control and enforcement to secure it but with autonomy at the spoke level.
More on Azure Security Cookbook
Security professionals need to implement identity to protect Azure. Check out an excerpt from Chapter 1 of Azure Security Cookbook to learn how to deploy the principle of least privilege for administrator accounts.
How easy is it to implement multispoke network security?
Miles: It's simple enough. You're not trying to cater to everything in one design. Fitting that into one model is difficult if you have 20 different network requirements -- you'd end up making everything restrictive, which is not productive, or too open, which is not secure. Hub and spoke enables multilayer network security. You can apply different policies and cater to a specific spoke's needs. This is easier to secure than lumping everything together.
In Part 2 of Azure Security Cookbook, you cover Azure security tools. What's the top tool to use for Azure network security?
Miles: Traffic Analytics because you want to know what is happening within the network -- what traffic is coming to your network, what resources are communicating with each other and, more importantly, what traffic is leaving the network. You can see common remote hosts and resources different VMs communicate with, as well as the ports and protocols they use, to ensure they aren't quietly communicating to someone you don't expect.
Traffic Analytics uses NSG flow logs -- a collection of all the network packets NSGs collect. From there, you can do some analysis and put it into a dashboard. Say it tells you that, for the last three months, three hosts spoke only to each other, but they're now communicating with a public IP address based in an unexpected foreign nation-state. Traffic Analytics can flag anomalous behavior that just started happening.
In summary, NSG flow logs give you the signals to do analytics. Traffic Analytics gives you a bird's-eye view of network traffic flow.