Why you should be using Azure Security Benchmark

You start deploying new workloads into public cloud, then start migrating some workloads from on-premises, and all of a sudden what used to be a small part of your entire IT infrastructure is business-critical and hosted in the cloud. And your boss, and her boss, are asking you uncomfortable questions about security and control. Sound familiar?

Fear not – this article will lay out foundations for how to think about security in Azure, steps to take and how to think differently about security in the cloud.

Is the Cloud secure?

The short answer is yes, at least if you look at the major cloud providers. They spend significantly more resources than most enterprises, and definitely more than SMBs, on securing their clouds. After all, the whole premise of handing over parts of your IT environment to someone else to host requires trust. A major breach at any of the three big public clouds would set the whole industry back years and give ammunition to old-timers who hug the servers in their basement like it’s 2005.

But security in the cloud requires a shift in mindset and understanding the shared responsibility model. Parts of the security tasks fall on the cloud provider but parts of it are your duty.

The shared responsibility model (Courtesy of Microsoft)

This diagram from Microsoft’s documentation shows clearly that for all three cloud models (SaaS, PaaS and IaaS), the information and data, endpoint devices and accounts and identities are always your responsibility.

We’re going to focus on IaaS and PaaS in this article and for IaaS, the identity directory Azure Active Directory (AAD), which is possibly connected to your on-premises Active Directory (AD), is yours to manage. So too are the applications in your VMs, the network controls and firewalls around them and the OS running in those VMs. You have to patch them, back them up, protect them with anti-malware and other security solutions and monitor their performance and any security breaches.

In PaaS workloads, on the other hand, there’s more grey area and it varies between different services. For instance, if you run your code in containers in Azure Kubernetes Services (AKS), you’re responsible for the code you run in the containers, configuring the network controls accurately to provide access to the right people and applications and setting up Role Based Access Control (RBAC), using the Least Privilege principle for the people that should have access to the cluster.

The fact that Azure takes over more of the security tasks as you move to PaaS also means that as you look to modernize your applications and “how you do IT” in your business, look to these more modern platform services to provide you with some extra security that you don’t get with running traditional VMs.

Azure Security Benchmark

Microsoft has a comprehensive framework called Azure Security Benchmark (ASB) currently in Version 2. Together with the Cloud Adoption Framework (CAF) which provides strategic guidance; security best practices guides and a reference implementation; the Azure Well-Architected Framework assessments and Microsoft Security Best Practices, the ASB benchmarks builds on the Center for Internet Security (CIS) controls and focus on cloud centric security.

The ASB covers controls for Network, Identity, Privileged Access, Data Protection, Asset Management, Logging and Threat Detection, Incident Response, Posture and Vulnerability Management, Endpoint Security, Backup and Recovery and Governance and Strategy. In a bit, I’ll show you what’s included in the Network controls, but each of the links above leads to the individual controls for each domain. You can also download the entire benchmark as an Excel spreadsheet.

In case you’re not familiar with CIS they’re a not-for-profit that provides security benchmarks for Ubuntu, Windows, Cisco, Docker and many, many more platforms for free. Microsoft has worked closely with them to nail down the CIS 1.1.0 benchmark that surfaces in ASC, in this screenshot from a production deployment with specific guidance for which controls have failed audit and need to be remediated.

ASC Regulatory compliance – CIS

For example, the ASB Network Security control domain recommends implementing security for internal traffic (using NSGs and/or Firewall), using ExpressRoute or VPN to connect on-premises networks to Azure plus using Virtual network peering to connect Azure virtual networks together and Azure Private Link to isolate application traffic from the internet. The next network control stipulates protecting applications using DDoS protection, Azure Firewall and Azure WAF as part of Application Gateway, Azure Front Door or Azure CDN. Deploying intrusion detection (IDS) and intrusion prevention (IDPS) is provided by third-party services or Microsoft Defender for Endpoint. The next recommendation is to simplify network security rules using Application Security Groups (ASG) to group different tiers of your application together and to use service tags to route traffic to different PaaS services securely. The final recommendation is to secure your DNS infrastructure in Azure.

I urge you to read the ASB carefully and understand the concepts and features and why they should be used. But what you really need is actionable guidance for your particular resources, tracking as you continue to improve your security. This solution is called Azure Security Center.

Azure Security Center

Once the ASB is under your belt, start securing your Azure deployments with Azure Security Center (ASC). This central portal for all things security gives you an insight into your Cloud Security Posture and can be extended to your hybrid resources, both on-premises and in AWS and GCP.

Azure Security Center Overview blade

Using security policies (built on Azure Policy), ASC applies a default policy that audits current settings such as if RBAC used on Kubernetes Services, if Vulnerability Assessment is enabled on your SQL servers or if Windows Defender Exploit Guard is enabled in your Windows VMs, along with another 64 policies (at the time of writing).

Azure Security Center Recommendations

On top of that – under the Recommendations blade you’ll find Secure Score – a list of improvements you can make in your deployment ranked based on which step will advance your security posture the most. The challenge for most under-resourced IT departments isn’t the availability of security tools and configurations, it’s knowing where to start and what impact turning on security feature X will have. This is where Secure Score shines – giving you insight into exactly what configuration changes to make, which risks it will mitigate and the likely impact on your resources. Here’s an example of a production IaaS Windows Server 2016 SQL Server VM and it’s associated vulnerabilities.

ASC SQL Server vulnerability list

ASC also provides Security alerts for all monitored assets, an Inventory blade of all Azure deployed resources (if you don’t know what you have, you can’t protect it) and a Workflow automation blade to build Logic Apps, low or no-code apps that can be triggered from an ASC alert or recommendation to automatically remediate the issue.

Furthermore, if you have specific regulations that your cloud deployments must adhere to you can use the Regulatory compliance blade to take steps to comply with PCI DSS 3.2.1, ISO 27001, SOC TSP or Azure CIS 1.1.0.

As mentioned, there is also a Cloud connector blade where you can add an AWS and/or a GCP account, this is currently in preview. This uses Azure Arc to deploy the Log Analytics agent to the AWS or GCP instances and also connects to the AWS Security Hub or the GCP Security Command, so you are not only getting Azure’s recommendations but also alerts from the other platforms.

The free tier of ASC is a good place to start, but for production, deployments look to what used to be called ASC Standard tier and is now known as Azure Defender, pricing available in the official documentation.

Azure Security Best Practices

Providing comprehensive guidance on how to secure your Azure resources is beyond the scope of this article, and I don’t want to duplicate excellent official guidance, but here are my recommendations for you.

First of all, be prepared to change your mindset. Bringing your traditional, on-premises security lens to the cloud will not work. Read up on Zero Trust, understand the concept of identity being the new firewall, and see the possibilities that Azure brings to the table for securing your IT assets. Take micro-segmentation for instance, which is creating isolated networks for each application or service within your private network with limited communication with other parts. The idea is that when an attacker manages to get a foothold in your network, the blast radius is limited, and they have to work hard to move laterally to another part of the network. This is VERY hard to do on-premises but relatively easy in the cloud.

Make sure all your administrators are using MFA, there’s no excuse not to protect every privileged account with strong authentication (and no – a long password is not “strong authentication”). Using biometrics with Windows Hello for Business is better, and FIDO 2 hardware authentication is better yet.

For administration of your cloud resources, ensure that Windows VMs aren’t having the RDP port open to the internet, nor Linux servers publishing SSH, either use Just in Time (JIT) access or better still – use Azure Bastion.

Use the security monitoring provided by ASC and definitely connect your workload logs to a SIEM for in-depth visibility, if you don’t have a SIEM already, Azure Sentinel is an option that Microsoft is putting a lot of resources into.

Make sure you backup all your workloads and for business-critical services, have replication to a secondary region, in case of a major outage in one region. All Azure regions have another region as a pair in the same geography, so you can comply with any data residency regulations whilst still ensuring business continuity.

Conclusion

A question I sometimes get (as an IT Consultant) is whether AWS is more secure than Azure which reminds me of the debates from yesteryear about whether Linux or Windows (or Hyper-V vs VMware) is more secure. The answer is – if you configure it correctly and use the provided security features and measurements wisely – either AWS or Azure can be secure, neither platform is inherently more secure.