Before the panel, we came up with a number of questions to help drive conversation and discussion. Since this is a blog, I will reproduce the original questions with my somewhat quirky short form answers in full below. Note that Cigital Principal Consultant Scott Matsumoto who heads up Cloud Security at Cigital was instrumental in helping to formulate these thoughts. You want some cloud security? We got some.

For more on the panel and on cloud security see a complete video of the panel and read my informIT article Partly Cloudy with a Chance of Security

The title of this panel is whether we can ever trust the cloud. Starting with a big general question: in a nutshell, -what- can we reasonably trust the cloud to do, or not to do?

The question of trusting the cloud should be the same as asking the question “can I trust distributed architectures (as opposed to a mainframe architecture)”. Put this way, it’s a silly question. A better question might be “what is the cost of creating a secure computing environment for <insert cloud platform name here>?”

There are two components to worry about:

1. One of the main drivers for Cloud is cost. Creating a secure computing environment requires some level of cost to compensate for security that may well be different from one’s current computing environment.

2. The answer to the cost question can only be answered WRT a specific platform since the nature (pros and cons) of the platform-provided secure controls and the weaknesses (not necessarily vulnerabilities) both vary across the plethora of platforms lumped under “Cloud.”

Remembering the answer to the last question, how does that compare with how we can reasonably trust traditional shrink wrapped software?

Wrong analogy. This probably should be (as stated above) can you trust distributed architectures over mainframe architectures?

A security perimeter is a well-known idea from computer and network security; it’s a boundary with an inside and an outside and a regulated access point; e.g., you can’t access the systems inside my security perimeter unless you are allowed by my firewall rules. From a customer’s view, how can we have meaningful security perimeters in a cloud?

Could you ever really trust the perimeter? Trusting the perimeter was an urban myth. Will that help this discussion go somewhere useful?

To the extent that a cloud is an aggregation of many very similar systems under one administrative authority, there seems to be an opportunity for an expert security team to use automated techniques to implement more consistent security practices than are likely outside a cloud. Do you buy that? Is it possible that cloud security policies may be better?

This is a good question.

The analogy to COTS software may well apply to this question. While the Cloud provider may get a boost from a critical mass of humans working on a common set of problems; it means that the solution must be generalized to apply to the broadest number of use-cases. With COTS software you get a more cost-effective solution IFF the solution designed by the COTS solves your problem. You also get a lot of other people’s baggage.

Prediction:
Cloud-Bloatware.

From the 1970s we have the concept of the reference monitor. It is a protective layer that regulates access to resources, like data stored in a cloud. As traditionally formulated in the seminal Anderson report, a reference monitor can be trustworthy because it is: 1) protected from tampering, 2) non-bypassable, and 3) simple. Can there be reference monitors in the cloud? Or is this just an outdated concept?

This is also a useful question.

From the NIST cloud definition, in a public cloud, “the cloud infrastructure is made available to the general public or a large industry group and is owned by an organization selling cloud services.” For a private cloud, “the cloud infrastructure is operated solely for an organization. It may be managed by the organization or a third party and may exist on premise or off premise.” So a private cloud -could- be behind a protective firewall. In your view how do public and private clouds compare security wise?

Private VS Public should probably be evaluated through Single-tenant VS Multi-tenant.

As software people, we know that complexity is the enemy of security, and that, traditionally, for every thousand lines of good code we should expect multiple flaws. For similar features delivered to customers, are clouds more complex, less complex, about the same?

It’s the type of code that’s the issue (as opposed to LOCs). What the Web should have taught us is that we don’t want application programmers writing security controls like authentication/authorization, session mgmt., etc. We’ve become ever so slightly more secure as these controls have been sunk back into the application infrastructure (app-servers, middleware, etc) and pulled out of the apps.

Cloud means that some of security controls required to compensate for platform weaknesses are pushed into the application. That is a problem.

What is even more worrisome is that for SaaS, the controls push through the application layer and into the legal agreements. Lawyers… draw your own conclusions.

Generally, cloud-based applications depend on reliable and secure networking. Anecdotally, I seem to experience more network glitches than local freeze-ups, and networks need working DNS, routers, etc. A few thousand smartphones suddenly turned on in a conference center is also an issue. Can the network really be as reliable as the local client?

Meh.

Search engines sometimes seem to know us better than we know ourselves. They aggregate data from our searches. With a scale of aggregation in the data center that is perhaps unique to cloud computing, malicious insiders in the data center might pose a unique and sobering threat to privacy. How concerned should we be?

Also meh. Expect everybody to watch everything. Act accordingly.

The Cloud Security Alliance lists account hijack as one of the top 7 threats for the cloud. For most people, the browser is the access point to the cloud, but browsers seem always to be getting smacked down at contests. E.g., see http://cansecwest.com/, with a macbook already owned this week and more likely on the way. Can we be confident that our cloud accounts are safe?

Weakest link, yadda yadda.

Multi-tenancy is a high-profile feature of clouds. It seems similar to process separation in operating systems, which has a checkered history security wise. What should give us confidence that cloud-implemented multi-tenancy will keep customer workloads really separated.

goto QUESTION 6

Considering the data replication practiced by some cloud providers and the inherent difficulty of erasing data authoritatively even when the local storage device is in hand, can we have real data delete in the cloud? Do you think it matters much?

Deletion is the most important part of backup.

What is your number 1 most important security challenge or opportunity in the cloud?

Software security uber alles.

The “Cloud Computing Roundtable” hits this “lawyering” topic pretty well. As long as you read the discussion with the “these guys mostly represent the perspective of service providers,” you’ll get good understanding of the macro issues involved: lack of technological sophistication of regulations, cross-border/jurisdiction regulation, and standards are still evolving to catch up. These are my macro takeaways. One perspective that I have had and was glad to have “confirmed” was Eric Grosse’s comment on the insider threat, “We [Google] have zero tolerance for the insiders abusing that trust…”. I’ve felt that for a XaaS vendor, they have a lot riding on protecting against the insider threat in their data centers.

Mom wanted me to be a lawyer, but I became an engineer, so I’m more interested in some of the more technical aspects that we not talked about. These interests have been keeping me too busy to write about them. But here are some of the perspectives that are a bit more technical in nature. Each probably deserves a longer discussion. I guess that should be my first 2011 resolution.

1. Cloud Security is more than worrying about your XaaS platform. See points 2 and 4. Many times Cloud = AWS and it’s the mere mention of AWS that sends chills up and down peoples’ spines.
2. Application architectures are using Cloud as a component in an overall solution.
1. The security problems from other parts of the application are often just as bad (if not worse) the ones in the Cloud components.
2. The potential problems of “finger pointing” between the multiple organizations scares me more than the technical vulnerabilities.
3. The application architectures are starting to be Cloud+Mobile and not Cloud and/or Mobile.
4. The integration of “Security from Cloud” (SaaS security services) creates new security challenges – they are not “plug and play” for their traditional counterparts in all cases. One example is that cloud-based intermediaries necessitate the need to implement WS-SecureConversation rather than just WS-Security alone.

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.

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.

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.

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.

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).

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.

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?

[tags]software security,cloud computing[/tags]