So the question is: what *kind* of security services should we build for the Cloud? What do want them to do? What are the goals?
Of course, as security professionals we know the goal is Confidentiality, Integrity and Availability. Right?
Wrong. The worst goal you can have when building security into a system is Confidentiality, Integrity and Availability. These are not actionable goals. How are you going to have get Confidentiality, Integrity and Availability across Data, App, Services, VM, Server, Storage, Network and Organizational layers? You're not. Its the old military saying - when you defend everywhere, you defend nowhere.
We have "information" this beautiful, messy, unpredictable, fractal-like thing. What is 3M's stock going to do tomorrow? Will it go up or go down? I don't know, but I can make model and use some information to make a guess, but its very unpredictable.
On the other side we have "security" which is an illusion that we can separate the good stuff from the bad stuff.
And in the middle we have this debate, and our job as security professionals is to make sure this is a constructive debate not a destructive debate as it so often becomes.
So the framework that I use has three parts
* Identity & Access Services: Letting good guys do their work - Claims enabled services. People think of authentication, authorization, and so on as security, but its really just ticketing that allows law abiding citizens to follow the rules.
* Defensive Services: keeping bad guys out - conservative services that deal with threats and vulnerabilities
If you study the brief history of access control models  you will see that it begins with the Reference Monitor which had three properties: 1) its always invoked, 2) its tamperproof, and 3) its small enough to be analyzed.
The way that this has rolled out in practice in the enterprise began with RACF a resource focused model, this means that controls are set on the resource or server side. So there is minimal knowledge at all about the client side computing environment, user or context. That lack of context is great for phisherfolk, because it gives them an ocean of space, but not so great for security .
The next step is typically Role Based Access Control (RBAC), where Subjects, Objects, Sessions, and Roles are mapped together. This accomplishes some basic context propagation from the client side to the role, but is at the same time 1) pretty coarse grained and 2) needs a tremendous amount of a priori knowledge.
A more constructive way to deal with access control in the Cloud is Claims Based Access Control (CBAC) where a Claim represents an assertion of truth that requires evaluation. The Subject making the Claim and the Object evaluating the Claim are executing independent operations. The way the claim is constructed and how its evaluated can vary and can be based on dynamic attributes. This model fits the current computing landscape much better.
There's a tremendous amount of ferment in the identity world, its one of the most active areas in computing. The weakness that is identity on the Web is being attacked and addressed by various standards like SAML, Information Cards, oauth, and others.
SAML is a good example of how this access control model plays out in the real world. SAML assertions are made by an Identity Provider on behalf of a subject and evaluated by a Relying Party on behalf of an Object. Again two independent operations, that then of course provide the glue to communicate security-critical information across the stacks.
SAML assertions can be authentication-related assertions (how a user was authenticated for example), attribute statements (name-value pairs), and authorization decisions assertions. The SAML Producer-Consumer model decouples these concerns and so by allowing for multiple authorities, SAML gives us a way to navigate the multiple namespace problem which is at the root of the Cloud.
So in the case of signing onto Google apps by using SAML, Google doesn't have any knowledge of your Identity Provider, and you don't own/control Google's SAML service provider. Protocols like SAML that allow for this are necessary conditions for access control in the Cloud.
But SAML is of course not a silver bullet, it has some nice properties but it doesn't fix everything. We can use the Threat Model + Attack Surface to see where SAML can play a role
Another Identity & Access Service is Information Cards, which I can sum up a problem statement for thusly "Passwords are Tired"
As Kim Cameron says, we've trained an entire generation of users to type in their username and password every time they see a prompt. And then we make fun of them for getting phished.
So Information Cards are one way to combat this, there are various Card managers out there like Cardspace, Azigo and DigitalMe, and basically the way it works is that instead of logging in with a username/password, we instead click on use an Information Card
Then once the user authenticates to their Identity Provider (IdP), the values are populated, digitally signed and encrypted and sent to the site (Relying Party).
This seems like a small thing but the differences are extraordinary. Think of how things typically work today. The Resources are on the server (data, apps and so on), the Subjects are on the server (users, groups), and THE SECRETS are stored on the server (passwords). Does anyone see a problem with this? Shipping dynamite and detonators in the same truck is not a good idea. But that's what we've been doing.
So what kinds of threats can Information Cards address?
oauth gives another axis to play, oauth is a standard that enables authorization on web services without requiring the dreaded username/password combination. So again we have a way to decouple authentication, authorization, and attribution.
So there is quite a bit of activity in identity and access, that is a quick recap of some of the main drivers and themes, but again Identity and Access is not the sum total of security its only about letting the good guys do what they need to do, its probably not even the most important part of security. Because the one thing that we infosec folks can really help developers and architects do is - design for failure. Developers and architects work to make sure the system does what its supposed to, but because of minimal focus on security and the fact that software development as a whole is quite immature, the rabbit holes that are not as often explored are the failure modes. This is where infosec can play a key role, if we can make our role a constructive one, we are in a great position to help bring more focus on the design for failure issue.
Access control can really look like security, there's a real beauty inherent in how say authorization is performed, but the reality is that people and systems do unexpected things, that designs and implementations didn't account for.
So this is why we need Defensive Services, to hedge our bets when the other Security Services might fail. To begin, remember the Claims we talked about in CBAC? It would be a lot more reliable to evaluate Claims that have some way to verify integrity and authenticity. So the Claims must be shipped with a Security token that we can use to hash, sign, encrypt and otherwise protect the Claim.
Another way to hedge our bets when designing for failure is audit logging , using a checklist of auditable events such as
Authentication, authorization, and access: Authentication/authorization decisions, system access, data access
Changes: System/application changes (especially privilege changes), data changes (including creation and destruction)
Threats: Invalid input (input, schema validation failures)
Exhausted resources, capacity: Limits reached (message throughput, replays), mixed availability issues
Startups and shutdowns: Startups and shutdowns of systems and services
Faults and errors, backup success/failure: Errors, faults, and other application issues
The Threat Model + Attack Surface matrix tracks what issues we've tried to deal with and where. And what we've deferred due to cost, complexity or other reason.
So Identity and Access Services enable the systems to work, the Defensive Services allow us to deal with inevitable failures. And finally, I will describe the role of Enablement Services.
And making this happen is a Governance problem, its not just delivering services, but integrating them correctly
One of the themes in Identity & Access Services is about enabling decentralized security services, this is required for our security services to form fit to something as decentralized as the Cloud. We have decent amount of experience in the field with this happening with SAML and other protocols. What we don't have yet is a lot of experience with decentralized policy.
As Bill Gates said security should depend on policy not topology, so what we need is a way to move policy around in the system. Now you might ask yourself - we have made it this far without decentralized policy, why does it matter now all of a sudden?
Think about how many layers require policies, and inside of each of these layers? How will you achieve consistency?
WS-SecurityPolicy has a slightly different approach than XACML, in WS-SecurityPolicy the policies are defined by security policy types such as Channel (like requiring TLS/SSL), message security (like requiring SAML tokens), and then attached to the inflow, outflow or creation of the service.
Actually it doesn't - its what makes the above work. More specifically, its what allows you to query the system after you have built it on your assumptions and see if they in fact hold up.
This is in tandem with the way that vulnerability scanning is likely to go in the Cloud. Because scans can cause disruption and be generally unpredictable, plus the providers' having to support many tenants, its not as simple as before to load up the vulnerability scanner of choice and fire it off. Policy will play a role in supporting decentralized access management by making it more predictable and it will likely play a role here too.
The last Enablement service I would like to address is the one that likely holds the most near to mid term promise: the Security Token Service (STS). The STS has three main functions: validating security tokens, issuing security tokens and revoking security tokens.
We have a Constanza wallet full of tokens, what we don't have yet, but need, is a policy-based way to move the Claims around in the systems. So a user logged on to Active Directory with a Kerberos ticket that needs to talk to a Unix web service that only speaks SAML, the client calls the STS with the kerberos ticket, the STS validates it, issues the SAML assertion and the Unix system performs authorization against SAML.
In almost every system there are impersonations, delegations and identity mapping across the board, but the STS gives us a way to do this utilizing security policies and through isolating the weakest link. How many times have you seen a system where someone says "the mainframe only supports six character password" so everything has to be six characters. Instead its better to isolate the weak link, use the highest security token you can in each case and only transform to the lowest for the last hop.
STS is also commonly associated with a IdP
Because technology evolutions and revolutions tend to combine the theoretical and practical (J2EE was cool idea, but Weblogic was the first big success story), my guess is that a number of these ideas I described here will land on a physical/logical system and that system will be an STS.
Tim O'Reilly said “Everything we think of as a computer today is really just a device that connects to the big computer that we are all collectively building”, and I would simply add …let’s collectively build security in
Thanks for your time.
11. A Survey of Access Control Models, NIST http://csrc.nist.gov/news_events/privilege-management-workshop/PvM-Model-Survey-Aug26-2009.pdf
12. Brian Krebs Notes from a System Melting Down Before Our Eyes, http://1raindrop.typepad.com/1_raindrop/2009/10/brian-krebs-notes-from-a-system-melting-down-before-our-eyes.html
13. "The Laws of Identity", Kim Cameron http://www.identityblog.com/?p=352
14. "Identity Venn", Eve Maler, http://www.xmlgrrl.com/blog/categories/venn/
15. A Conversation with Bruce Linsay, Steve Bourne, http://queue.acm.org/detail.cfm?id=1036486
16. Logging in the Age of Web Services, Anton Chuvakin & Gunnar Peterson, http://arctecgroup.net/pdf/82-85.pdf
17. Vulnerabilty Scanning and Clouds, Craig Balding, http://cloudsecurity.org/2009/06/28/vulnerability-scanning-and-clouds-an-attempt-to-move-the-dialog-on/