Cloud-based Solutions, Threat Modeling and Shared Security Responsibility

Almost 100% of my security work these days involves helping customers deploy their solutions on Microsoft Azure with confidence. It’s an interesting, subtle twist on the use of the Microsoft Security Development Lifecycle (SDL). My SDL work has gone from being “it’s the right thing to do” (which it still is, but humor me) to “make sure all the correct defenses are in place so we can deploy on Azure confidently.”

That’s a long way of saying that SDL, most notably threat modeling, is a way to break down some of the potential security impediments to deploying in the cloud. In other words, threat modeling can help drive Azure adoption because threat modeling can allay security concerns with structured threat and risk analysis.

Many conversations I have with customers go like this:

Customer: “We cannot deploy on Azure until we know that appropriate defenses are in place.”

Me: “I agree 100%, so let’s build a threat model for the proposed design and see what you need to do, and what Microsoft provides.”

A couple of days pass as we build and iterate on the threat model.

Now here’s when the customer has an “a-ha” moment. At the end of the process we have a list of defenses for each part of the architecture and we all agree that the defenses are correct and appropriate.

It’s at that point the customer realizes that they can deploy a cloud-based solution securely.

The feedback from customers building threat models for their Azure solutions has been overwhelmingly positive and has helped customers confidently move workloads to Azure.

As noted in “Microsoft Incident Response and shared responsibility for cloud computing” some of the Azure defenses are provided by Microsoft, such as DDoS defenses, Azure SQL database encryption and much more. Some of the defenses are provided by the customer, such as Azure SQL column encryption and blob store secure access signatures, and more. The threat model makes the delineation explicit, and this is more pronounced when considering IaaS defenses and PaaS defenses, which can often be quite different.

TL;DR.

Build a threat model for every Azure solution before you complete the architecture to make sure the correct defenses are in place and you understand where the responsibility for the defenses lie – Microsoft or you – and you can then deploy on Azure with confidence. There are plenty of threat modeling resources at the end of this page.

Comments

• Anonymous
  May 14, 2016
  Thanks for the notable mention. Great explanation about the 'customer' responsibility. I could not agree more, that if cloud adopters review their solution with a threat based approach it's really clear that moving to the cloud can be safe, and effective.
• Anonymous
  May 16, 2016
  Hi Michael,Absolutely agree and that's been our experience with customers too. We've just completed a 3+ year Cloud adoption project with one of our clients - Microsoft customer case study here: https://vimeo.com/159680921/328b6cb9b4 because they are a Financial Services organisation, risk & compliance was one of their top concerns. We created a risk & mitigation analysis process, which we've documented here: https://blogs.endjin.com/2016/04/cloud-adoption-risks-mitigations-analysis/