Cloud Security, Cloud Security

Why Microsoft’s product volatility creates security risk in Azure

Today’s columnist, Andy Robbins of SpecterOps, offers three tips to help security teams more effectively manage the frequent security changes in Microsoft Azure. (Stephen Brashear/Getty Images)

Microsoft recently announced a host of updates at Ignite 2021, including changes to Azure Arc, Azure SQL, and Azure Synapse. Changes to Azure Active Directory included an expanded Identity governance feature, the ability to migrate more applications from Active Directory Federation Services and token theft detection for Azure AD Identity Protection.

While many of these changes are welcome and help solve legitimate security issues, they have a downside that often gets overlooked. This high level of volatility in Azure – merging some products, rebranding others, and making foundational changes to important pieces of software – increases security risk because it forces cloud and security IT professionals to relearn these tools after every major change.

This prevents security experts, whether they work in-house, for a service provider, or as a consultant, from understanding Azure in detail. Even the most talented practitioners need time to learn the intricacies of each update. Without that time, they’re more likely to make mistakes and implement insecure misconfigurations, which may create attack paths in their environment. Or IT might decide to hold off on implementing critical security fixes until they understand the new software better to avoid interfering with an important business process by accident. Either route can degrade the overall security of the Azure environment. While it’s somewhat backwards, frequent, significant updates to Azure may actually work against the security team.

Volatility in Azure affects security in several ways:

  • Lost expertise: Engineers must re-learn every detail whenever a component within Azure changes in a serious and/or fundamental way (patches and bug fixes don’t count for this). Time spent re-learning takes person-hours away from other projects.
  • Lack of third-party resources: Generally, the longer a piece of software has existed, the more third-party blogs, resources, GitHub repositories and custom tools are available for it. These make it easier for newcomers to educate themselves. With constant changes, these resources can immediately become irrelevant and obsolete. Re-education can take even longer without this supplemental material.
  • Azure is still new: Azure wasn’t really taken seriously in the security industry until the last few years. That means security researchers and engineers likely don’t have a huge amount of Azure expertise. The constant product churn and need to re-learn Azure components only makes the issue worse.
  • Small talent pool: There’s still a small talent pool for people who understand  any specific component of Azure. While Azure has been utilized for some time, professionals with deep knowledge in configurations are much scarcer than their on-premises Active Directory counterparts. Azure’s volatility exacerbates this talent shortage. As a result, organizations may struggle to find the expertise they need, and the security of their Azure environments may suffer as a result.

In comparison, Microsoft Active Directory has been used for identity and access management on-premises for two decades. While it too has been updated over the years, the changes are typically smaller in scope and occur with less frequency than what’s been happening to Azure. There are a huge number of AD admins who understand how to use the software, a broad number of security professionals whounderstand how to harden it, and an enormous library of third-party resources to help both groups do their job quickly and safely.

An identity or AD admin tasked with securing on-premise AD has many resources available to them and can find dozens of detailed guides to fixing common AD security issues. For example, my colleagues and I have created or contributed to more than 20 free and open-source projects focused on securing on-premise AD. This same level of knowledge and support does not currently exist for Azure Active Directory and the steady, fundamental changes Microsoft makes to the software make developing these libraries even more difficult.  

Security teams can mitigate this issue in a few ways:

  • Engage with their peers. Many cities and industries have Azure user groups where members can discuss Azure with others working in different industries, or the same industry as themselves. These meetups frequently discuss the latest changes in Azure and often include discussions on working around those issues.
  • Leverage free resources to keep track of changes. AzAdvertizer is a free website that automatically documents the daily changes to Azure role definitions, including the addition of new roles.
  • Lean on free resources to understand the impact of configurations in the Azure tenant. Active Directory and identity security tools can help teams understand how changes in Azure may or may not translate into security risks. For example, I am a co-creator of an open-source project called BloodHound that supports Azure and gets used by thousands of defenders to find and mitigate dangerous attack paths in their tenants.

Security teams should use these strategies – after all, security professional must always learn the latest trends as technology evolves. I’m sure Microsoft has good reasons for many of the changes they make to Azure. But confusion and volatility favor adversaries, not defenders. Necessary or not, Microsoft’s steady product changes can make the task of securing Azure environments much more difficult – so security teams should do everything they can to stay ahead of the learning curve.

Andy Robbins, technical product architect, SpecterOps

Andy Robbins

Andy Robbins (_wald0 on Twitter) is the co-creator of BloodHound, the free and open source security tool for mapping Active Directory. He is currently the technical product architect for BloodHound Enterprise at SpecterOps, and has a background in red teaming and penetration testing. He used to be an Adversary Resilience Lead at SpecterOps and a Team Lead for Offensive Network Services at the Veris Group, TrustCC and Alluvien.

Get daily email updates

SC Media's daily must-read of the most current and pressing daily news

By clicking the Subscribe button below, you agree to SC Media Terms and Conditions and Privacy Policy.