Embracing "native" security in Azure

If immutability and agility might look like Russia and the US during the Cold War, there are ways to make them work synergistically, resulting in a efficient and frugal cybersecurity posture.

When I made this comparison between AWS and Azure security postures, I explained how Azure Policy can be leveraged to enforce in-band control over resources life-cycle.

Remember this diagram? It shows how a typical customer security framework made of out of band controls provides an awkward and low resolution oversight.

A native control offers a much better paradigm because it fits into the build phase seamlessly, with the highest possible resolution and without breaking anything: this is what we need in an agile world. But the native way is truly valuable if it also prevents deviation in the run phase and I didn’t expand on the idea. Time to look into it a little bit today. 

Deviation management in run/maintenance - Azure perspective

Whether native or not, there are two ways to approach and deal with deviation: either through frequent evaluations, or through control plane[*] locking. Both provide some kind of immutability: the first one in an eventually consistent way, the second one in a "truce"-like way.

In its current state, Azure proposes a native mix of both with various pros and cons.

• Azure Policy is heavily focused on frequent evaluations: if a gap is spotted during a policy evaluation, it will roll back to the desired state. Depending on the complexity of the deviation, it might take a while and might even fail (and notify you of course). There is a time frame when immutability is broken: it could be exploited by an adversary to run havoc into your business. You have to take this into account during the risk analysis of each workload you plan to run off premises.
• Azure Blueprints eases the eventually consistent deployment of your policies in a scalable and devOps friendly way over your whole in-Cloud organization. We might see it as the orchestrator, or the state machine, of Azure Policy.
• Azure PIM is heavily focused on lock management. It is, however, mostly user-centric meaning that CD/CI platforms somehow elude it. What’s more, as of today it does not cover all services. For obvious operational reasons, providing Just In Time (JIT) access to resources is inevitable, and one of the main reasons why PIM exists is exactly for that: removing the lock in a supervised and time-bound way. When the lock is put back, the control plane becomes immutable again but it might end up in a different state as the initial state, so Azure Policy must be implemented on top of PIM to roll back undesired changes.

Keeping immutability natively on track is summed up in the picture below. (Note that loss of immutability only makes sense during the run phase of an Azure service)

Deviation management in run/maintenance - Customer perspective

Azure Policy, Blueprints and PIM are managed services that will help you make native controls actionable by offering a form of immutability that has been thought for devOps and agility from day zero.

One important thing to keep in mind is that

there is no way to make Azure immutable by making custom, non-native controls. That's because custom code won't have access to the many resources aliases supported by Azure Policy.

If you define proper in-band controls and if you set clear IT security criteria for your Cloud workloads, you cover a lot of your residual risks by design: a good part of the burden for preventing deviations rests on your Cloud Provider’s shoulders.

Needless to say, for your control framework to be efficient, the architecture and security teams will have to do a lot of homework though...

A Cloud provider will never compensate for customer-side, context dependent organizational constraints and technical limitations.

If fellow architects and risks managers consider that “HIPAA”, “CIS benchmark”, "CSA" or “FedRamp” control sets will do the work out of the box, kindly remember them these are quite valuable but generic helpers meant to be meticulously carved to fit into an organization.

Also, we should debunk the enticing idea that compliance to industrial standards makes a business safe: in the field, compliance and cybersecurity are only very loosely coupled.

[*]: Some kind of data plane locking is also necessary, but this is out of scope for today’s discussion.