Microsoft Azure is Going Secure by Default. Are You Ready?

Let’s face it: Developers can sometimes be labeled as “laissez faire” when it comes to security. But is that really fair?

In reality, it’s not about being lax or lazy; it’s about the default configurations of many cloud services setting the security bar too low on initial deployment. When racing against the clock, it’s tempting to rely on these defaults, which can inadvertently open doors for malicious actors.

But as network attack surfaces grow wider from global expansions, edge integrations, and AI/ML, using these defaults puts more and more at stake.

In this blog, we’ll tell you what to look out for when it comes to cloud service defaults, how major players like Microsoft Azure are stepping up their security, and how you can keep up.

The problem with default security configurations

In the realm of cybersecurity, default configurations often prioritise ease of getting started over security, inadvertently creating vulnerabilities that can persist if left unmodified. Here are some notable examples of such “bar set too low” security defaults:

1. Unnecessarily opened ports: Sure, you can hit the web interface for the service, but what about the database ports? Do they really need to be world readable/writable?

2. Excessively lax permissions: Default settings might grant broader access than necessary, violating the principle of least privilege.

3. Revision fatigue: Failing to apply the latest security patches leaves these systems susceptible to exploits.

4. Disabled security features: Certain security features might be turned off by default to enhance performance or user experience. Worse yet, the dreaded line: “that might need a different license”.

And last, but not least:

5. Default credentials, default permissions, or default configuration settings: What’s the first userID/password combination you think of? Is it admin/admin? Services also may often run with elevated privileges or have overly permissive configurations, increasing the risk of an environment being exploited.

Azure’s secure-by-default networking: Don’t get caught out

Recognising these challenges, Microsoft Azure is making some major changes to move towards what they are terming a secure-by-default deployment model, particularly in its networking components.

With a currently advertised commencement date of September 30, 2025, this shift will bring a major change to Azure networking with Microsoft removing default outbound internet access for newly deployed virtual machines.

That’s big news for those deploying on cloud. And it doesn’t stop there, with the additional announcement that legacy multi-factor authentication (MFA) and self-service password reset (SSPR) policies will also be deprecated on September 30. This means cloud engineers must migrate any legacy policies to a new converged authentication methods policy for Microsoft Entra ID. Thankfully, the deprecation for the IP addressing is slightly less onerous than the above.

Here’s the exact wording on the scope of the change:

“On September 30, 2025, Basic SKU public IPs will be retired. If you are currently using Basic SKU public IPs, make sure to upgrade to Standard SKU public IPs prior to the retirement date."

It’s not that scary, but there could certainly be implications for the scenario of “rolling over” any existing addressing under the Basic SKU, as well as the non-availability of the Basic SKU in favour of the Standard SKU going forward past that date.

In the following section of this blog, we’ll dive into the key logical drivers behind these substantial changes and what they might mean for you.

What makes a secure-by-default model?

Beyond the buzzwords, a secure-by-default model ensures that services and resources are provisioned with security configurations already in place, reducing the risk of misconfigurations.

Key aspects include:

• Default security posture: Services are secure upon provisioning, minimizing the chance of misconfigurations.
• Minimised attack surface: By disabling unnecessary features and enforcing strong authentication, network segmentation, and data protection, the potential entry points for attackers are reduced.
• Ground up compliance: Default security settings often align with regulatory standards like ISO 27001 and PCI-DSS, simplifying compliance efforts.

The building blocks for secure by default on Azure

1. Network Security Groups (NSGs): By default, NSGs are configured in a “deny all” manner with regards to inbound traffic, allowing only outbound communications unless address(es) are specifically added to an allow group. This minimises exposure to potential threats in the out-of-box experience (OOBE).
2. Azure Firewall: This managed, cloud-based network service built to protect Azure Virtual Network (or VNet) resources allows for centralised creation, enforcement, and logging of application and network connectivity policies across subscriptions and virtual networks. Azure Firewall operates at OSI layers 3, 4 and 7 – that is the network, transport and application layers.
3. DDoS protection: Azure provides built-in Distributed Denial of Service (DDoS) protection to safeguard applications from overwhelming traffic flows, ensuring availability and resilience. There are three main types of attacks that the DDoS mitigation strategies defend against: Volumetric Attacks (e.g. UDP floods, amplification attacks), Protocol Attacks (e.g. SYN floors and reflection attacks) and Resource (or Application) Layer Attacks, which commonly compromise the upper layer protocols such as HTTP or SQL.

Diving deeper into default outbound access

In Azure, virtual machines (VMs) created in a virtual network without explicit outbound connectivity are assigned a default outbound public IP address. This IP address enables outbound internet connectivity, but can be subject to change and is not recommended for production workloads.

If you have existing VMs using default outbound access, they will continue to work after the scheduled change date and you will retain your Basic SKU IP addresses. However, it is strongly recommended to transition to an explicit method to avoid potential disruptions.

Let’s say you’re using a cloud-based security appliance that reaches out to the internet for threat intelligence feeds and other system updates. Unless you’re aware of the change and make an explicit connectivity configuration change, it’s likely your detection pipeline will stall and potentially leave an organisation open to zero-day threats.

In order to ensure a smooth transition, Microsoft recommends using explicit outbound connectivity methods such as:

• Azure NAT Gateway
• Azure Load Balancer outbound rules
• Enhanced Azure Firewall support
• Directly attached Azure public IP addresses
• Zone-redundant and zonal front ends for both inbound and outbound traffic.

Here’s a table that details the major changes, and availability of features between Basic and Standard SKU:

The specific configuration of these Microsoft items is beyond the scope of this article, but if you are interested in learning more about the changes and how they could potentially impact your connectivity, don't hesitate to reach out to see if myself or one of my colleagues would be able to walk this through on your specific scenarios.