As part of my work on the Trust Cloud Initiative, I’ve had so discussions with they folks at PGP about their Key Management Server. At first, I was “ho-hum, key management”, but there’s more going on here than I had assumed. The way this software manages keys is more like a key ring. The implication is that an identity can then have a set of additional keys associated with it and the server will manage these “identity encapsulated” keys. The notion of “identity encapsulation” is actually that of Liam Lynch from eBay who is heading up the TCI.

I’m speaking at the 2010 Colloquium in Baltimore on Tuesday 6/8 on Cloud Security. Here’s the abstract.

Cloud Security: Don’t Be Late to the Party

Cloud computing is here to stay. No amount of security whining will stop the cloud, and yet as the cloud revolution sweeps IT it behooves us to pay close attention to security and privacy concerns. If, as everyone says, security is a process and not a thing, what processes and procedures do we need to put in place to secure cloud computing? How do you build security in to something that you don’t entirely control? These and other important questions are the focus of this talk. I will discuss: how cloud computing changes the nature of software design and development, the cloud security threat-scape, different flavors of cloud implementation and their security ramifications. Whether your organization is just kicking the tires or moving into more serious pilot projects, it’s never too early to begin addressing the changes cloud computing will impose. I will discuss what can be done today in terms of both technical and contractual mechanisms.

I just moderated a panel on security within Cloud Computing environments. Many of the questions from the audience were about how to trust cloud computing environments. Trust is such a loaded word and I couldn’t tell from the participants if they were looking for a bunch of bolt-on controls or something more holistic.

At RSA, the Cloud Security Alliance announced the Trust Cloud Initiative (TCI). The purpose of the TCI is to take the CSA guidance a couple of steps forward in defining trust by defining both a reference architecture as well as a way to certify cloud services.

There are three sub-groups working on the distinct areas of trust we believe are needed:

• Architecture – definition of the required security controls as well as the relationships, constraints and patterns of usage
• Certification – ways of discovering the security controls provided by particular cloud computing environment and measuring their ongoing usage
• Reference Implementation – working prototypes and demos of the architecture to prove out the architecture

More information the TCI can be found on the CSA website.

Anyone interested in volunteering their time to work in one of the subgroups can contact me and I’ll help you get hooked into TCI effort.

My Saturday US Mail delivery (so sad if it goes the way of the dodo bird) arrived with several notifications of class action lawsuits for companies in which I’ve held equity positions. As I walked back from the mailbox, I had the thought:

HIPAA and PCI protect the consumer, but who/what is protecting the business that must comply?

I was thinking about all of the audit controls that get put in place to comply with these regulations. The controls are generating data that is going to be used to in one of these lawsuits someday. How is this going to look to a judge?

I suspect that there are fair number of judges that can figure out that any digital asset can be tampered with. Today, they can look at the people in an organization that have access to the data to determine the validity of the data. That may pass muster with today’s judges, but what happens when judges (in their youth) have doctored photos in Photoshop? Will such judges be willing accept that people working for a company didn’t tamper with the digital asset? Somehow, I don’t think Log4J is going to cut it.

And what happens when we factor in all of this cloud computing stuff? Where’s the chain of custody then?

At some point, the audit logs from IT are going to be presented as evidence and some judge is point out that there is reason to doubt their authenticity. At that point, I suspect that corporate attorneys are going to want to focus on meeting the letter of the regulation and also ensure that all of the work done to comply is admissible in a court of law.

Regulatory compliance, such as HIPAA and PCI, are strong business drivers for improving software security for many of our clients. The focus for most groups is to meet some audit deadline. Getting passed the auditors to ensure compliance is the first hurdle, providing audit logs that can pass legal muster can’t be far off.

I read a question on one of the cloud mailing lists asking which of the federated authentication protocols (SAML, OpenID, Oauth, WRAP, etc) would win. My initial reaction was to reply, “Isn’t the question which ones won’t lose?” Okay, that’s snarky and perhaps a double negative, but I find it a rather dubious notion to think that there will be one winner. Aren’t authentication protocols like camera lens mounts? There are several types and all that’s important is that you can share lenses with the people you hang with? Why does there have to be a winner?

If you’re consuming a SaaS, it would seem like the service will support N protocols and you can either support one of those N. It seems like the big SaaS vendors will have some set of standards in place and it will take a couple of big customers to get them to expand that set. What’s it going to take for Force.com to implement something other than SAML?

For PaaS and SaaS, your organization is in control of the application, so you can handle authentication by whatever scheme you choose. If you’re working with some business partners, then you implement whatever protocol you both can agree to.

The protocols/mechanisms so far is only for user authentication. What would be helpful is if there were some way to enable authentication to include the cloud service itself. Cloud services all require some form of account information to do anything. If it’s a service like Amazon, there are also the private keys that have to be maintained, managed and passed to just gain access to the infrastructure. What all of the different delivery models have in common is the problem of authenticating to the cloud service. Is this a problem for identity management or just a (not so) simple credential management problem?

So, the question is not which one protocol wins, but which ones lose since you can only hurt yourself by implementing something that dies off. Then you can turn your attention to the problem of securing the authentication to the cloud service itself.

I had been reading about Gartner’s prediction that 1 out of every 5 businesses were going to dump all of their physical IT infrastructure when Sammy Migues sent me a thread from LinkedIn about it. The thread contained many of the common sense views about Cloud Computing that you’d expect: IT should be based on strategic value and should outsource the commodity pieces. That day, I was also reading about the Forrester survey that states that 43% of their respondants said that they had no interest in cloud storage and another 43% (perhaps the same 43%) had no plans adopt it.

Some of the difference in these two reports has to do with hype versus reality. I recall in “the naughts” that SOA was touted as a way for IT to bring business agility. Then all of the vendors got on the SOA band-wagon. Now it seems like Cloud has taken up where SOA left off in terms of hype. On the reality side, I wish I could tell whether the lag is because of people’s increased awareness of security (the optimist) or whether it’s a reflection of the sorry state of storage implementations (the pessimist).

I’ve lived in a bubble all of my life. My parents created a bubble to grow up in and then I wrote commercial software products. It’s only recently that I’ve stepped out of that bubble and seen just how messy the real world is. Yes, I’ve looked at bubbles from both sides now (sorry, but I couldn’t resist the not so veiled reference to Joni Mitchell).

Application software lives in a bubble too. Quite literally, the bubble itself are all of the network security controls, but there’s also all of that airspace inside. That air space is the set of invisible assumptions that the software is built on.

One of the assumptions that’s been on the top of my mind is “our software runs behind the firewall”. This isn’t an indictment of this statement, it’s true and there’s a wonderful, liberating set of assumptions that a designer can make. Where do those assumptions materialize in software development artifacts? For many of them, the answer is nowhere. They are passed on through the airspace because everyone knows them. There’s no need to write them down.

What assumptions exist in the security of an application when it gets ported to a cloud computing environment? Multi-tenant versus Single-tenant infrastructure – check. Externalization of IAM for SSO – check. The 20 other “well duh” generic security items that pundits (myself included) will dwell and pontificate on. What are the important ones? Damned if I know.

But you know and only you will know. Why? Because you’re inside the bubble and we’re not. So, start writing them down. And when I come in a pull out my generic (I called tried and true) solution for migrating to the cloud pull out that list. It’s that list of assumptions that stand between you and migrating your application to a the cloud.

The European Network and Information Security Agency (ENISA) published their analysis of security risks from cloud computing. It’s a well thought through paper and it complements the work on cloud security guidance being written by the Cloud Security Alliance. What I like about both the ENISA report and the CSA Guidance (I’m an author of one of the sections and, yes, I like my eating my own cooking) is that both documents take the point of view that Cloud Computing is going to happen and that security is going to have to deal with it.

There are certainly security risk for applications migrating to the cloud. These risks involve both security concerns such as the confidentiality of the information stored in cloud services as well the legal implications concerning the liabilty if a system is unavailable. This focus of cloud computing risks on the consumers of cloud services by both of these organizations seems justified. After all, how many companies are going to be cloud service provides?

Well, that’s what I thought.

Now, I’m thinking that if Cloud Computing really catches on (beyond everyone writing about it and attaching the word “Cloud” to any product or service that’s connected to a network) then I suspect that most “consumers” of Cloud Computing will want to be service providers too.

What caused this change in thinking was the article I read about how Larry Ellison “created” the network computer back in the 90s. The network computer really is what we call Cloud Computing today. Combine that with how SOAs evolve within an enterprise. They start as disparate web services, but then eventually the business units provide services that are their key data to the organization. With Cloud Computing it will be your business (not just your business unit) providing services (data) to other businesses.

The question is how you’re going to do that. I suspect that youll be exposing some kind of PaaS environment that your partners will write application-lettes in. These application-lettes are going to be doing the combining of data from your two systems. On which PaaS the application-lette runs is going to depend on which the amount and sensitivity of the data.

AI had a second coming in the 80s, aren’t we ready for a second coming of “The Internet is the Computer” in the 10s?

Technorati Tags: software security, cloud computing