Some Thoughts on Threat Modeling for the Cloud

Like any other set of applications Cloud applications can benefit from Threat Modeling. Of course the goal of Threat Modeling is not to enumerate threats, but rather to identify and locate countermeasures. If we use the STRIDE threat model we have six threat categories that yield six or more security architecture concerns

 

Threat	Countermeasure
Spoofing	Authentication
Tampering	Integrity Hash
Repudiation	Audit Logging
Information Disclosure	Encryption
Denial of Service	Availability
Elevation of Privilege	Authorization, Hardened Interfaces

Note the above is not a complete set but is a starting position for thinking about pairing Countermeasures with Threats. What does delivering these Countermeasures mean in the Cloud? Depending on the Cloud deployment model the answer of who is responsible for what can vary, and again we see that security multi-dimensional requiring architecture and standard patterns for it to work together.

For IaaS we could get an array of Countermeasure responsibility along these lines.

Threat	Countermeasure	IaaS
Spoofing	Authentication	Identity Provider: Cloud Consumer Relying Party: Cloud Consumer
Tampering	Integrity Hash	Cloud Consumer
Repudiation	Audit Logging	Cloud Consumer
Information Disclosure	Encryption	Cloud Consumer
Denial of Service	Availability	Cloud Provider
Elevation of Privilege	Authorization, Hardened Interfaces	Infrastructure: Cloud provider Infostructure: Cloud Consumer

So far, there is not too much outsourced responsibility for security or runtime collaboration, the Cloud Provider is mainly responsible to ensure availability and that the Infrastructure boundaries remain in tact but what about PaaS and SaaS?

In PaaS, we would expect the Relying Party responsibility for the Identity and Authentication to move to the Cloud Provider. There is a shared responsibility for both the Cloud Provider and Cloud Consumer to verify data and message integrity. Audit logging services are also shared in that the PaaS provider and Cloud consumer generate audit records, the review of those logs still lies in all likelihood with the Cloud Consumer. In dealing with authorization and hardened interfaces, that responsibility is now shared between Cloud Provider and Cloud Consumer.

Threat	Countermeasure	PaaS
Spoofing	Authentication	Identity Provider: Cloud Consumer Relying Party: PaaS Provider
Tampering	Integrity Hash	Hash generation & verification shared Cloud Consumer, PaaS Provider
Repudiation	Audit Logging	Record events: shared PaaS Provider, Cloud Consumer Event review: Cloud Consumer
Information Disclosure	Encryption	Cloud Consumer
Denial of Service	Availability	PaaS Provider
Elevation of Privilege	Authorization, Hardened Interfaces	Infrastructure: PaaS provider Infostructure: Shared PaaS Provider,  Cloud Consumer

If we look at SaaS, the man difference from Paas is that SaaS provider is responsible for authorization and hardended interfaces for applications and data

Threat	Countermeasure	SaaS
Spoofing	Authentication	Identity Provider: Cloud Consumer Relying Party: SaaS Provider
Tampering	Integrity Hash	Hash generation & verification shared Cloud Consumer, SaaS Provider
Repudiation	Audit Logging	Record events: shared SaaS Provider, Cloud Consumer Event review: Cloud Consumer
Information Disclosure	Encryption	Cloud Consumer
Denial of Service	Availability	SaaS Provider
Elevation of Privilege	Authorization, Hardened Interfaces	Infrastructure: SaaS provider Infostructure: SaaS provider

Threat modeling is a good way to "see" security architecture, distill the patterns out of the noise and divide responsibilities. Depending on the deployment model, how infosec will need to engage, what tool sets and skills are required can vary. There are subtle differences in the above tables as well, in terms of the required standards and patterns that facilitate sharing the responsibilities and working together at runtime. 

Comments

[Bikram Barman]

Where would you place geo-location compliance in the above model?

[Gunnar]

@Bikram

I see Compliance and Threat modeling as separate but related activities, I just finished a paper on exactly that topic. If you would like a draft please lmk, otherwise will blog it once its available