Pattern Progress on Don't Trust. And Verify.

Last summer I gave a keynote at the Cloud Identity Summit (btw: you can register for this year) that described four security architecture elements that were essential for Cloud deployments. Last fall, I wrote these up in IEEE Security & Privacy paper call "Don't Trust. And Verify." I had a brief moment of fun with the IEEE editors who tried to change the headline to Don't Trust and Verify. You can see why they would, being masters of grammar and all. But my meaning in choosing the title was to not trust the Cloud *and* to verify that which you send to and receive from the Cloud. 

To do this we need new tools and we need to use existing security tools in different ways. The four tools I think are essential in anyone's Cloud Security stack are:

• Gateway: Don't trust your Attack surface to the Cloud, and do verify at the Gateway. Its a Defensive structure to limit attack surface and enforce policy.
• Security token service: Don't trust messages, implement verifiable security tokens. The STS handles Issue, validate, and exchange security tokens
• Monitor: Do implement monitors that record and publish auditable events
• Policy enforcement point/policy decision point: Use PEP/PDP to enable fine grained access control. Create, manage, and enforce policy across domains

Here is a collection of some resources on each of the above topics, as you can see there is a lot of momentum around these areas and it looks like we are distilling down to the core concerns and capabilities we need for Security groups to handle:

• Gateway
  • Intel: Security Gateway Buyer's guide
• STS
  • Cloud Security: The Identity Factor   
• Monitor
  • IEEE S&P: How to Do Application Logging Right
  • Securosis: Monitoring Up the Stack
• PEP/PDP
  • Security > 140 Conversation with Gerry Gebel Part 1 & 2

There is quite a lot happening in the Cloud Security space, the above areas each give Security teams a way to add value in the architecture and design of the systems and set the operations teams up for success. Each of these four security architecture patterns give a mix of access control and defensive architecture that aligns to Cloud deployment models. The precise mix and the process to deploy the architecture varies from SaaS, PaaS and IaaS, and I will explore these in future posts.

It goes without saying that none of this is a silver bullet, but what I think is important for Cloud Consuming enterprises to note is - what precise capabilities do they need to have working to make their Cloud journey as safe as possible. What is exciting to see is that a market is emerging and growing to deliver on security tools that target apps, data and identity for the Cloud. It has been a long wait, but we may now be seeing widespread adoption of the tools that help security teams address issues earlier on in the design and development lifecycle.