Defining Cloud Computing

Cloud computing is a very active community. The Google Group gets 600 posts per month and many bloggers are covering the space. However, “cloud computing” is impossible to define in a way that satisfies everyone (or even most). Cloud computing is not alone in this controversy, consider the definition and meaning of “Web 2.0″, “mashups” or “RESTful architecture”. All of these terms are relatively recent. According to Google Trends, these terms became popular to the general public sometime between 2005 and 2007:

• Web 2.0 - often confused with RIA, AKA Social Computing, Long-Tail Apps, Crowdware (2005 by O’Reilly Media)
• Mashup - made popular by Google Maps, AKA Composite/Situational Apps. (2005)
• REST - Has a strict definition, but many don’t understand it and abuse the term. (2006 by R. Fielding)
• Cloud computing - collides with many other terms, such as SaaS, Grid, Utility, PaaS, etc. (2007)

The definition of cloud computing is in progress:

There’s a Darwinian evolution of the exact definition of cloud computing running around. We’re about a country mile away from “knowing when I see it”, which is excellent progress. The cloud to everyone’s silver-lining has enough material to write a 3 volume desktop reference at this point. - Michael Cote, June 2008

Definition #1 - “Cloud computing is the realisation of Internet (”Cloud”) based development and use of computer technology (”Computing”) delivered by an ecosystem of providers. - Sam Johnston, July 2008

Definition #2 - “Cloud computing = network computing. I love the idea of cloud computing, the next evolution of the most network intensive architecture possible, but one that if it works well, is transparent. It’s all about the transparency.” - Douglas Gourlay, Cisco, May 2008

Definition #3 - “There seems to be a group myopia around so-called “cloud computing” and its definitions. What we’re really talking about are “cloud services” of which, “computing” is only a subset…Cloud services are not SaaS. They are far more akin to web services…” - Randy Bias, neoTactics, May 2008

(Anti-)Definition #4 - “Note that I refer to cloud services, not to the could. I am not interested in defining cloud as a term, because I don’t think it’s very useful. For those of us in the distributed computing’s pace

The Working Definition (Winner!):

“…the notion of providing easily accessible compute and storage resources on a pay-as-you-go, on-demand basis, from a virtually infinite infrastructure managed by someone else. As a customer, you don’t know where the resources are, and for the most part, you don’t care. What’s really important is the capability to access your application anywhere, move it freely and easily, and inexpensively add resources for instant scalability.” - Mitchell Crandell, Rightscale, June 2008

Taxonomies of the Cloud Space

Taxonomies are useful to provide insight into a market. It classifies a multitude of players into a smaller bucket.

Andreessen’s Platforms - September 2007

Provided an early taxonomy model for emerging cloud platforms

Platform being a system that can be programmed

• Access API - platform that provides web service endpoints
• Plug-In API - platform invokes your code, that you have deployed remotely
• Runtime Environment - your code runs inside the platform’s process space.

Mehta 11 Layer Stack, April 2008

1. Facilities (space, power, cooling)
2. Network
3. Hardware (e.g. servers Amazon EC2 runs)
4. Hardware virtualization (e.g. Xen for EC2) - optional
5. O/S (e.g. Linux)
6. Systems Management (e.g., tools to manage EC2 instances)
7. Application Middleware (e.g., MySQL on EC2)
8. Application Code
9. Application APIs / Web Services
10. GUI for Application
11. GUI for Application Development / Customization

Croll Cloud Stack, June 2008

7 layer stack within Turnkey app and Generic Platform.

Turnkey app

• SaaS
• Extensible app
• Generic IDE
• Constrained APIs
• App Cluster
• Virtual Data Center
• Virtual Servers

Generic Platform

The bottom of Alistair’s stack includes “root access “style compute clouds.

Robert Anderson, July 2008

3 layer stack

• Software (SaaS)
• Platform (PaaS)
• Infrastructure (IaaS)

This is the model taxonomy for this session.

Related Concepts and Terms

• Infrastructure as a Service (IaaS), Hardware as a Service (HaaS) are synonyms to cloud infrastructure.
• Virtualization
• Hosting
• Autonomic computing
• Distributed computing
• Grid computing

Cloud Applications

• SaaS
• S+S (Software+Services)
• Managed Service Provider (MSP)

Madison Wi-Fi network sold to Atlanta firm: Xiocom purchases Mad City Broadband, a firm that has suffered significant criticism over the performance of its Wi-Fi network in Madison, Wisc. The press release from Xiocom (some quoted in the Badger Herald article) are a bit over the top about a network that reportedly has few users, inconsistent performance, and covers only a fraction of the city.

I realize that security is a system level issue and it takes a long time to change things at that level, but what's more concerning to me is that the typical infosec mindset remains the same. Should we be surprised by rampant phishing and fraud? I am frankly surprised the numbers are so low given the opportunities that the attackers have via the glacial pace of security improvements. Its been three years since that list and I could write the same exact one today for SOAP, REST, SOA, Web 2.0 whatever. Maybe the main reason, beyond failure of imagination, why infosec is so far behind developers is that infosec lacks tools. Developers automate everything possible. Security doesn't. The most promising thing about static analysis is not the ability to find everything, its the ability to find many important things in an automated way. Infosec needs to stop giving people fish and teaching people to fish. Look at Fortify's vulncat site which has a Taxonomy of Coding Errors. Fortify's Seven (plus one) pernicious kingdoms are:

During the presentation I mentioned in some depth how to perform fuzz testing, and what parts of an application should be fuzz testing targets. I also introduced an idea (that's not new) to help people who have never performed fuzz testing begin fuzz testing with very little cost and friction. The idea is to add a small layer of code to an application to automatically mutate untrusted data as it comes into an application; I called that code layer "a layer of hurt."

Before I continue, I want to point out that fuzzing is an SDL requirement, but the idea in this blog post is not an SDL requirement, it's just another way to help meet SDL fuzzing requirements.

Adding a layer of hurt, as shown in the picture below, is pretty simple as it involves adding code to an application to tweak data as it comes into an application. You can work out where to place the fuzzing code by looking at your threat models to see where data crosses trust boundaries. You could also simply grep the code looking for APIs that read data, for example:

• Read from files: fread, ReadFile
• Reading from sockets: recv, recvfrom
• For .NET code, any stream.Read

You get the picture.

The fuzzing code should appear right after the API that reads that data.

For example, C or C++ code that reads from a UDP socket and then fuzzes the data before it's consumed by the rest of the application might look like this:

Or, in C#, code that reads from an untrusted file:

In both code examples, Fuzz() mutates the incoming data. In the C++ case, the fuzzing code looks like this:

The sample C# and C++ fuzzing code is available as a ZIP file at the end of this post.

This code is an example of dumb-fuzzing, which is fuzzing with little or no regard for the data structure being manipulated. If you've never performed any kind of fuzz testing in the past, then you will probably find bugs with this simple fuzzing technique. Once you have weeded out the low-hanging bugs, you may need to turn your attention to smarter fuzzers. For example, in theory, this code would find few if any bugs in a PNG parser, because PNG files have a built in check-sum, so if you fuzz a PNG file, you'd have to recalculate the checksum to get decent code coverage.

When I showed this code during my presentation, I urged people to add it to their applications today if they currently don't do fuzz testing, and simply run their applications through their normal testing processes. Within three days of my presentation I received emails from people saying they had found bugs. I have no doubt others did too.

One of the comments I made during the session was,"If you can't spend the time on great fuzzing, fuzz anyway" and adding a "layer of hurt" is a reasonable start.

Please feel free to sound off if you have ideas to help improve the code and let us know what you think, either through email or comments to this post.

Collaboration in the Cloud

Forward thinking companies use collaboration technologies to melt away the physical distance between disparate offices, remote workers and suppliers.  Investments in R&D projects to create the next generation of business collaboration technologies and starting to bear early fruits and are worth paying attention to - especially if you get paid to “do security”.  One major focus area is Virtual Worlds.

Teleporting Virgins

The big news in the Second Life research community is that avatars (”virtual people”) have successfully teleported between distinct virtual worlds.  The virgin teleporters went from a Second Life Preview Grid - an experimental grid completely disconnected from the Main Grid - to a virtual world running IBM OpenSIM.

At this stage there is intentionally no asset transfer going on at all - in other words, you can’t take your “stuff” from one world to another - but that will come in time as the Open Grid Protocol is extended.  Today just login and teleport are supported.  No stealing those trade secret “assets” yet ;-).

Linden Labs speaks to this issue:

Q: How will Linden Lab prevent property from being copied into other virtual worlds?
We’re paying extremely close attention to that question. We will be designing this with the Second Life community to ensure their needs are met. We want to stress that when it does become possible to move avatars between worlds, we will take the utmost care to protect the rights of Second Life property owners and creators. Linden Lab will not design a system that lets people openly violate the permissions of SL goods and take them to other worlds. We recognize that intellectual property is the engine that drives Second Life, and we are completely committed to preserving the qualities that make Second Life the unique, innovative and dynamic place that it is today.

With my “hacker-vision” ™ enabled I see *all kinds* of opportunities for mischief here.  I’m betting we’ll see imaginative attacks as the usual cat and mouse game of vulnerability research and vendor response plays out.  “Sorry boss, someone hijacked my avatar and now I’m stuck on this desert island for who knows how long!”.

Threat Profiling Second Life

Getting back to reality, people are already exploring Virtual World security.  Michael Thumann of ERNW in Germany is a pen-tester and security researcher and in this 10 minute video, Michael shares the result of his security research on Second Life.

He covers:

• In-game cheating
• Identity theft
• Attacking 3rd party servers using Linden Scripting Language (think about the liability issues and the providers ability to track abusers)

For those interested in more detail, the full presentation he gave at BlackHat Europe 2008 in Amsterdam is here (pdf).

Of particular note, Michael applied a formal threat model approach to the research - STRIDE from Microsoft.

In a future post I’ll talk more about threat profiling in the context of Cloud Computing vulnerability research and specific API security vulnerability classes we can expect to see exploited.

First, a quick clarification. I noticed that some of the readers who commented on that first post wanted to talk about improving security through the use of various development methodologies or coding frameworks. Those are interesting tangents (and ones that I may write about in the future), but my intention with this post is to discuss a very specific problem related to how people integrate third-party code — that is, the stuff you import or link in but didn’t write yourself.

As I mentioned previously, developers have a tendency to “bolt on” third-party components to applications without understanding the security implications. Often, these components are glossed over or ignored completely during threat modeling discussions. I attempted to illustrate this with my fictitious WhizBang library example in Part 1.

When integrating a third-party component, developers familiarize themselves with the API but generally don’t care how it’s implemented. Granted, that’s how an API is supposed to work; you don’t have to futz around with code beyond the API boundary, and you can blissfully ignore parts of the library that you don’t need. In past consulting gigs, I’ve sat in threat modeling discussions where nobody knew whether a particular library generated network traffic. “We just use the API,” they say. The fact that it works is good enough; nobody seems to care how it works.

That mindset is ideal for rapid development but problematic for security. Failing to understand the complete application, as opposed to just the part you wrote, prevents you from accurately assessing its security posture.

It’s also no coincidence that web app pen testers love third-party components — we get excited when we see “bolted on” interfaces, because we know that developers tend to leave extraneous functionality exposed. The resulting findings usually generate reactions such as “I didn’t even know that servlet had an upload function.”

An Example

Here’s a close-to-home example related to my post about DWR 2.0.5 from the other day. DWR is an Ajax framework that has a variety of operating modes. In-house, we use a subset of DWR’s full functionality — specifically, we interact with it using the “plaincall” method only, so we made sure that the features we didn’t need were disabled via the configuration file. As it turned out, there were vulnerable code paths prior to the “do you have this thing disabled” check. In hindsight, if we had taken more time to understand the exposed interfaces, we could have reduced the attack surface by filtering out unneeded request patterns before they even touched the third-party code.

But wait, you say. What about maintainability? If I whitelist using a point-in-time application profile, doesn’t this create the same maintenance headache as the reviled WAF? It doesn’t have to. Certainly, one option would be to whitelist each and every unique URL that references the DWR framework, e.g.

/dwr/call/plaincall/myMethod1
/dwr/call/plaincall/myMethod2
/dwr/call/plaincall/myMethod3

But then you’d have to update the whitelist every time you added or removed functionality from your application. Also, don’t lose sight of the security goal, which is to minimize the amount of exposed third-party code. If I add or remove URLs that list, provided they are still using the “plaincall” method, I’m hitting the same DWR dispatcher every time. So I’ve increased maintenance cost without any security benefit.

A better option is to simply tighten the URL pattern a bit in the J2EE container. Here’s the default configuration:

<servlet-mapping>
  <servlet-name>dwr-invoker</servlet-name>
  <url-pattern>/dwr/*</url-pattern>
</servlet-mapping>

Now, instead of allowing every URL starting with /dwr/ to be processed by the DWR library, you could be a little more restrictive:

<servlet-mapping>
  <servlet-name>dwr-invoker</servlet-name>
  <url-pattern>/dwr/call/plaincall/*</url-pattern>
</servlet-mapping>

In this configuration, you don’t have to worry about /dwr/call/someothercodepath any more. There is less third-party code exposed, thereby reducing the overall attack surface of the application. (NB: DWR also serves up a couple of Javascript files, so those URL patterns will have to be whitelisted too)

A Logical Extension

Even if you’re not a developer, you should still be thinking about attack surfaces. People download and install blogging platforms such as WordPress, Movable Type, etc. all the time, but how many take additional steps to harden their installations? The concept is the same as the OS hardening analogy I brought up at the very beginning of this discussion.

Similarly, people install third-party WordPress plugins or Joomla components without considering that most of them are written by some random programmer who is a whiz with the plugin API but knows nothing about security?

At the risk of sounding trite, always remember that security is only as strong as the weakest link.