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.
Where would you place geo-location compliance in the above model?
Posted by: Bikram Barman | January 14, 2011 at 07:22 AM
@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
Posted by: Gunnar | January 14, 2011 at 09:05 AM