2015-2025: a decade of preventive Cloud security!

Since its birth in 2015, preventive Cloud security has proven a formidable achievement. By raising the security bar of hundreds of thousands of workloads over the past decade, what started as a simple opportunity to support business transformation evolved into one of CISOs' most valuable ally.

A quick overview of preventive Cloud security

The key principles are easy to understand, yet they are extremely mighty:

• Customers don't pay for the build/maintenance/evolution of security controls, they come by design
• Controls scale proportionally to assets
• The scope can be total, no single asset in the scope you define is left aside
• Development and production environments are treated equal
• Evil is blocked before it occurs, avoiding costly human-in-the-loop forensics and considerably improving the security TCO
• Speaking of TCO: execution is often free of charge (and if not, costs are generally included in the pay-per-use bill)

Still to this date, preventive Cloud security is an active research area, notably in the data plane: initially a monopoly of Cloud providers themselves, it has enjoyed a timid but increasing support from CSPM third party tools.

Although it's way too early to tell, let's hope it will enjoy a similar success in DSPM and runtime security spaces which are still way too much detection-based.

Where does it come from?

For those of us who were born in 2015, let's remember the Cloud landscape:

• An IaaS world, almost devoid of PaaS (with the notable exception of object storage and some serverless compute capabilities)
• Undisputed commercial leadership of AWS
• IAM authorization and logs were coarse and brittle
• In the data plane, virtual network privacy was nascent
• In the control plane, endpoints were internet-exposed
• Security controls were more advanced in AWS, but except for IAM they were mostly detective

At that time, Microsoft's Cloud was a challenger: it did enjoy a solid year-on-year business growth, but it was dwarfed by AWS volumes. Its future was uncertain, as was Oracle's or IBM's.

2015, the tipping point

I think that 2015 was a business-critical year for Azure: Microsoft worked very hard to catch up with AWS, they did that through innovation and exploration. Their main advantage was the close relationship they had entertained for several decades with their many customers worldwide, via their Windows and Office support and expertise channels.

Unlike some of its competitors, the customer voice is deeply anchored into Microsoft's DNA. Granted, it might not always be the case for cybersecurity! But for business development, it has always been remarkable.

So, Microsoft naturally expanded its will to capture customer voice from the software they licensed to the service they rented in Azure, its new flagship. For that, they leveraged a special network of "black belts" called the Customer Advisory Team (CAT).

Business meets security

I said that cybersecurity is something Microsoft tend to work on their own. The truth is, the mixed results they get is often a cause of rant from their customers. But sometimes, when planets align, miracles happen. This is I think exactly what happened 10 years ago: Azure was eager to develop its business, and there were opportunities to make money by offering a first-class, cloud native offerings that would differentiate Azure from AWS.

One such opportunity sparkled from fruitful conversations between Microsoft CAT engineers and SocGen engineers. After a series of workshops, we were able to outline a security posture which was to be entirely preventive.

From early blockers...

Right from the start, the main roadblock to overcome during this early design phase was clearly not to ruin developers experience. Security shouldn't harm Cloud adoption by imposing barriers and constraints (a common pitfall when aiming at prevention).

So there was a paradox: on one hand, developers were to keep unimpeded access to native portal and APIs. On the other hand, their leeway was to be limited by the most restrictive form of controls enforcement one can think of: preventive controls!

The solution we found can be best thought as an architecture security pattern: Microsoft would implement security controls as customizable "hooks" within Azure backend's pipelines. Hooks would perform on-the-fly remediation whenever a condition was triggered (typically: a drift from customer desired-state), almost "unbeknownst" to the developer who initiated the action from Azure Portal, the CLI or the ARM API.

Incidentally, now you know why I have been keen on having my job position stick to "Cloud security architect": the three words matter equally and summarize much of my daily activities.

...to where we stand today

It took a couple of years for Microsoft to implement preventive security as part of their PaaS catalog: the result was the well-known Azure Policy.

I am very grateful for Microsoft to have lead this project to its conclusion, and I'm also deeply impressed, because the roadblock that we identified a decade ago was nothing compared to the hardships talented Microsoft engineers must have gone through to implement Azure Policy effects in a consistent way across the many Resource Providers that make up the core of Azure's backbone.

What's more, over the years Microsoft has made a product richer and much more far-reaching than what we initially envisioned: to this day, Azure Policy is leveraged not just for native security but also for compliance and architecture standards, representing an amazing success story that delivers a win-win for both Microsoft and its customers. It does marvels in conjunction with Azure Deployment Stacks or Entra ID.

I would like to express my warmest thanks to Ulrich Homann , Hatay Tuna , Philippe Ouensanga , Christophe Louvel and Eric Grenon for their commitment and key contribution in making what was to become one of the most mission-critical service of the Public Cloud.