The Internet Kill Switch

Recently in response to the activism in Egypt, President Mubarak "shut down" the Internet. While there is some question as to how effective this was, to the extent that it worked at all, it was because there were only two Internet service providers and they were creatures of the decades old "emergency" government.

Currently, prompted by fearful but impotent bureaucrats, the US Congress is considering giving a similar authority to the President of the United States. Needless to say, there is organized opposition to any such expansion of government authority.

In response to the opposition, a colleague wrote as follows:

Editor's Note (Schultz): Opponents of giving the U.S. President the
right to shut down the Internet are like those who oppose a mayor of a city being flooded by broken water mains being given the right to shut off the water. As useful as it is, the Internet is also capable of being used as a destructive weapon, and at least to some degree it has already been used in this way numerous times. Someone must have the authority to make decisions concerning its continued operation in case it is used outright as a weapon.*

The overt premise here is that the Internet "can be used as a weapon." While I concede that any infrastructure, indeed any artifact, can be misused, it is absurd on its face to compare such misuse to weapons like bombs and shells. The implicit assumption is that shutting it down is an effective defense. My mother called such a defense "cutting off one's nose to spite one's face."

Moreover, the analogy does not hold. One does not need the mayor to shut off the water. The water department will do it; they need no additional authority to do so. What is perhaps more important, they can be relied upon to do so in the least disruptive way. They can be relied upon to preserve as much of the capacity as possible.

Think about SQLSlammer. First it did not respect national boundaries. Second, before the governments of the world were even aware there was a problem, the network operators recognized, identified, and filtered the disruptive traffic. They did not seek permission but their judgment was so good and their action so measured that no one has ever even questioned them, much less faulted them, for this preemptive, not to say precipitous, action.

I am unable to envision any attack against, or via, the Internet where killing it is not worse than the attack. Indeed, the closest thing that we have seen to an Internet attack was the denial of service attack against Estonia. While one can imagine a politician using a kill switch in such a situation, it would be a solution at least as bad as the problem.

Most of the use of the Internet in warfare will be for intelligence gathering. Most of this will use open sources; attacks against hidden sources will be covert and low-intensity but in no case sufficient justification for shutting down the Internet. Adversaries may wish to deny one another its use in time of crisis but killing it simply plays into this.

However, what we have been taught to fear is the use of the Internet to mis-operate the controls of other infrastructure. The Congress has heard testimony that this risk is overstated but in any case, the proper defense is local to those controls, not a global shut-down.

I am unable to envision any case where the POTUS is better equipped to make decisions about the operation of the Internet than those who operate it day to day. Can you envision any case in which such a decision would not be political?

Indeed, to the extent that one believes in "Cyber War," one might ask whether a political decision by one country to "kill" the Internet might not be seen as an act of war by it's neighbors. We certainly saw the political decision by the President of Egypt to shut down the Internet as an act of oppression, not to say war, against his citizens. Indeed, it is far easier to envision such a capability being used offensively against one's own citizens than defensively against any adversary.

The Internet is designed to resist any and all attempts to shut it down. It should, can, and does survive multiple simultaneous component failures. Moreover, it is a poor respecter of national boundaries. Where would you propose to place such a control?

On the other hand, it is quite easy, particularly in light of recent events, to envision such authority being used to manipulate, intimidate, or control for political reasons. Like the USA Patriot Act, this kind of authority simply begs for misuse and abuse. For my comfort, both T and VZ are already far too willing, not to say anxious, to cooperate with the political authorities.

Before you support this proposal further, I suggest that you go to YouTube and reprise Michael Chertoff's demonstration of government crisis decision making. Instead of listening to them whine about their lack of authority, watch the process. Then ask yourself what the network operators are doing while this process is going on.

Government is the tool one uses when one wants to kill hundreds of thousands of people. It is really terrible at, for example, surgery, or other measured responses. There is a reason that we divide and limit it's powers.

Be careful what you ask for; you might get it.


* Quoted with implied permission form SANS Newsbites.

What does it Mean to Say a System is Trusted?

Do not trust any computer that you cannot carry; prefer those that you can put in your pocket.

Nothing useful can be said about the security of a mechanism except in the context of a specific application and environment.
- Robert H. Courtney

That little aphorism of Bob Courtney's has become a habitual touchstone for me. If it has not given me gravitas, it has at least kept me from appearing foolish by opining on the "security" of systems without regard to the threat or what they are being used for. It keeps me from equating the security of the application with that of the system or vice versa. It enables me to use a system for one application that is not suitable for others. It enables me to recognize when the security of a system that has served well is no longer adequate. (Many seem to get by simply saying that no system or application is secure. One can clearly get one's name in the paper by saying that. It is not particularly helpful.)

The client was a property and casualty insurance company. They had some fairly progressive programs under way but both their IT and security programs were mature and stable. We were called in because they expected that they were going to have a number of new e-commerce applications done on the public network. They wanted a security management system to ensure that these applications would be done conservatively.

The method that we used was to propose a straw-man for the management system and then refine it in ever larger meetings. One of the practices that we recommended was that connected applications be done on dedicated hardware; we wanted to be sure that these applications were free from outside interference or contamination. In an early meeting the client asked that this recommendation be changed to say that these applications be done on "trusted systems." We quickly realized that that was a better way to say what we were trying to say. It included our recommendation but was stated as an objective rather than a specific practice.

Then we discovered that the reason that they wanted it restated was because they intended to run the application on their MVS mainframe. "MVS," we said. "You trust MVS?" "No," they said, "We trust our MVS. We have had it for twenty years, we manage it scrupulously, and we trust it." The auditors nodded their heads and then we nodded ours.

Part of the problem is that we came to the question the wrong way. In the early days of computers they were serially reused and had no shared resources. Most of the applications were not sensitive. The question simply did not arise. After a decade or so, we began to recognize that there was a small potential for information to leak from job to job because of the failure to wipe primary storage between jobs. Information left in memory by job n might be available to job n +1.

The problem really emerged with true shared-resource computing in the sixties. Even here the problem was tolerable. The systems were operated by a single enterprise, most of the users knew one another, and they shared similar goals and objectives.

By the late sixties, the size of user populations had begun to be numbered in the high tens to low hundreds and the modern question was on us. The potential for information to leak from one user to another was on us. One clear method by which it might happen was the interference of one process with another. The problem now had a name. Research began. While we thought that it was important, computer use was still so sparse that it wasn't really.

However, these were the days of Grosch's Law where we believed that shared resource systems were inevitable and the scale of sharing would continue to rise forever. We believed that one should always use the biggest computer one could afford. We believed that computers should be scaled to the enterprise. Thus, the problem of data security was framed as that of security in multi-user multi-application systems. We had framed the question in a way that made it almost impossible to talk about, much less answer. We knew that there was an objective called data security but the environment in which we wanted to talk about it was so complex that language failed us.

It was at about this time, 1968 or 1969 that I first met Dr. Willis Ware of the Rand Corporation. He came to White Plains for an IBM briefing on computer security. One item on the agenda was my master work, security for IBM's Advanced Administrative System. This system was intended for 5000 users and ultimately served several times that. It was a multi-user multi-application system but it was operated in a static mode, i.e., programs could not be changed while the system was operating. Users could not program and programmers could not use.

I was justifiably proud of the access control for the system. It was the largest and most complete system of its kind and it worked. The operating system was hidden from the users and the access controls for users to applications ran at the application layer. Dr. Ware listened politely and then dismissed the whole effort as trivial. Years later, when we had become friends, I found that he did not even remember it. He dismissed it on the basis that it did "not address the general case, the one where any user could write and execute a program of his own choice."

So the question of whether or not a system was secure or not had to be addressed not only in the context of sharing of arbitrary applications and data by an arbitrary number of users but there could be no assumptions about the flexibility or generality reserved to any of those users. One might well conclude that such a question excludes any useful answer but that did not keep us from trying.

Tomorrow we will look at some of the attempts.

Are you a target of "Advanced Persistent Threat," Sources, or Attacks

"Advanced Persistent Threat" (APT) is a term of art. It was coined by the USAF to label an attack pattern that they had identified and that they thought was emanating from a nation state. It came into the security jargon when it was used to describe an extended and resourceful attack reported by Google.

These attacks are "advanced" in the sense that they are coordinated and multi-phased. The phases begin with target selection and vulnerability identification, through domain contamination and information ex-filtration, to intelligence analysis and exploitation.

These attacks are also advanced in the sense that there are knowledge, skills, and abilities specific to each phase; no single individual is likely to be expert in all phases. One guy crafts the bait while another selects the malicious code. The attacks are advanced in that the threat source brings together the necessary experts and coordinates their activity across phases and time.

The attack is persistent in the sense that it continues through all the necessary phases, and the threat source is persistent in the sense that it will invest whateever time and resource in necessary for success.

While the term really refers to an attack, rather than a threat, to the extent that the attack has a rate and a source, it implies a "threat."

Is this something that you need to woory about? Is your enterprise a target?

The short answer is that if you are a Fortune Five Hundred enterprise with intellectual property, you are probably a target of choice of one or more nation states. If you are a financial services company or a payment card industry service provider, you are a target of choice for organized and resourceful criminal enterprises.

This is not to say that the rest of us might not be targets of opportunity for these threat sources, but only that their attacks against us are not persistent or continuing. Individuals may be "victims" of payment card fraud but it is the enterprise that is the "target."

It would be nice if one could detect such attacks early. Then one could at least determine whether or not one was currently under attack. However, the attacks usually begin with low intensity activities such as vulnerability probes or the distribution of bait messages. While intensive probes are easy to recognize, the same probes spread across enough time may not be obvious. If bait messages are not difficult to detect, they will not work at all. In fact, they will be as artfully crafted as necessary for them to work. There will also be a "sufficient" number of them that one or more victims will take the bait. Only after the bait has been taken are the other phases of the attack triggered. While it is somewhat easier to automate the detection of these later phases of the attack, it may also be only after some data has leaked and some systems compromised.

Note that while the compromise of your intellectual property may be a threat to the health and continuity of your enterprise, the consequences may not be limited to your enterprise. They may include damage to the vitality and growth of our economy and, perhaps, even to "homeland security." In this light, "best efforts" or "hit and miss" security is not good enough.

"Defense in depth" must be the order of the day; push your defenses up and out and your resources in and down. We can no longer afford an enterprise architecture that relies primarily on perimeter protection such that one person clicking on a bait message compromises the entire defense.

Electro-magnetic Emanations

During my last years at IBM, Wjm Van Eck published his paper about reading screens using TV receiving equipment. The press loved it. There were TV shows on the BBC demonstrating reading screens at a show and reading a document from outside Scotland Yard.

Van Eck's experiment was based in part on the following:

· The screens of the day were character only
· They were CRT
· The CRTs were noisy and
· the noise mimicked standard broadcast TV signals

Van Eck simply cobbled together antennas, amplifiers, and receivers and displayed the signals on a standard TV screen.

I decided to see if I could replicate Van Eck’s results. I purchased from him a replica of his experimental rig and gave it to two engineers, one senior and one junior, in the Raleigh lab next to the plant that manufactured 3270 terminals. They assured me that it would be a piece of cake to reproduce the experiment.

It proved to be much more difficult than they anticipated. On one trip, they did manage to show me a screen that lit up like the one that they were trying to read at a distance of two meters. It was clear that the image on the destination screen was related to the one on the origin screen but the content was less than readable. As often happens with engineers, these two lost interest in the effort after they were satisfied that, given enough time and resources, they could replicate the results but long before they had actually dome so.

In the more general case, in estimating the cost of attack, engineers often discount the value of their own special knowledge and skills. They think, “Everyone knows (or can do) that.” The also tend to think that if an attack is feasible, it will be used.

These are the esoteric attacks from which Mission Impossible is crafted. In fact, one can expect an attack to be used only if it is efficient. The set of cases in the world in which such an attack is both suitable for the intended application and environment and cheaper than all alternatives is vanishingly small.

The leakage of information via electromagnetic signals is a vulnerability without a threat, a non-problem. Not all vulnerabilities are problems, not all problems are the same size.

Of course, today the cost of attack is even higher. Screens are bit-mapped graphics, not character. They are LCD, not CRT. Their emanations do not mimic broadcast TV signals. While they still leak, they are much quieter than those of a generation ago. Unless your applications are very sensitive, your adversary a nation state, and the rest of your security so good that this is your weak link, Spend your security resources elsewhere. Remember that Mission Impossible style attacks are undertaken only against those targets that are very sensitive and that have very good security.

"Data leaks! Get over it."

On the Real Risk of Thumb-drives

The first disk drive that I ever saw was the size and weight of a refrigerator and gave off as much heat. It would hold one megabyte. It was so expensive that it was far more likely to be used for tables than for files or databases. At the same time, the storage medium of choice was punched paper, cards or tape. A gigabyte in punched cards would fill a railroad box car.

The first hard drive that I bought was 10mb and cost me $3000 at IBM employee price. I thought I would never use it up. One can now buy a terabyte in a cigar box for $115 (I kid you not!) and for $50 one can buy 320GB that will fit in one's shirt pocket.

This week I bought an 8GB micro-SDHC card. It is the size of my fingernail. I paid $18 plus $4 shipping and handling although it could have been sent first class mail for less than a $1. A great portion of the cost is in the transaction, not the materials nor even the technology.

I thought that the SD card, the size of a postage stamp, was as small as a storage device would ever get. Smaller than that, one can hardly label or keep up with. However, the devices in which the storage is used are getting smaller and thus the microSD.

About every decade or so, as storage gets smaller, denser, and cheaper, managers began to worry that its very existence will encourage data theft. One could carry a 2400' reel of tape in one's overcoat or send out half a dozen in the waste paper basket. Multiple diskettes could be carried in a shirt pocket. Said another way, it has been a long time since the weight or the volume of the data was a deterrent to its theft.

However, we are going through the panic again. This time it is "USB drives." For example, a recent press release said "Lumension’s 2008 Annual Report and Threat Predictions for 2009 finds removable media as “the leading cause of data breaches…."

Dr. Peter Tippett reports, "It is endless talk among very large company CIO’s and CSO/CISOs that I speak with every week.. I think the driver is that everyone has a small case that happened in their shop, or that they heard about among their peers.... Then they have a “wouldn’t it be horrible if” worst case scenario they dream up relative to their own data.. And voila! It is the worst thing."

The other hand, in the 500 cases that Verizon reports on in its Data Breach Report, there were no cases in which thumbdrives (or other small portable media) played more than an incidental role. In no case did it appear necessary to the success of the breach, much less was it “causal.”

Even DoD leadership has been panicked by ‘thumb drives.’ Rather than control access to the data, they are trying to resist the technology. They no longer permit, at least as a matter of policy, portable digital media inside secure computing facilities, only paper. In some commands they do not permit the use of thumbdrives on (user owned) laptops attached to their networks. Anyone else see the irony here?

Now we all understand the limits of such controls. Modern storage is now so dense that one can conceal and carry an entire database inside any body cavity. (Yes, in certain extreme instances, authorities do search body cavities; this is usually law enforcement, not security, and in no case is it routine.) One can no more resist leakage by resisting media, digital or analog, than one can resist the use of computers, networks, or, for that matter, paper. The economics are simply against it. We pay extra for small and dense.

The way to resist data leakage is to restrict access to the sensitive, proprietary, or personally identifiable information, near the source (e.g., at the database server) and hold people accountable for its use. It is difficult to do but it is orders of magnitude more efficient than chasing the new tiny media de jour. It is far easier to control what data is copied than to control where it is copied or what happens to the copy. Data access control is media independent. Said another way, it works for all media, including the network, now and in the future, not just the one that one that is topical.

When I was a small boy and first went out to play without supervision, my mother said, “Son, never ever take thumbdrives from strangers.” When I got a little older, my daddy said, “Son, never ever put your thumbdrive in a strange machine.” I assume that someone cautioned my sister not to let anyone put their thumbdrive in her machine.”

The real risk of portable media is not data leakage but system contamination.

Encryption by Default

A recent survey was reported as follows:

IDG News Service - Employees at many U.S. government agencies are using unsecure methods, including personal e-mail accounts, to transfer large files, often in violation of agency policy, according to a survey.

Pasted from www.computerworld.com/s/article/9176889/Survey_Gov_t_agencies_use_unsafe_methods_to_transfer_files?taxonomyId=17>

Stephen Northcutt, writing as an editor of SANS Newsbites, observes:

I agree that too many people use insecure means to move data; disagree the root cause is no access to encryption.

A lot of people have access to encryption for email at work and yet consistently send data in the clear. We discuss this in the class I author and teach, and I think we as a community are becoming numb to the dangers we face from the Internet. Pretty Good Privacy (PGP) has been around almost 20 years now. In the early days, when you went to conferences, they had PGP signing parties and almost all the security professionals I interacted with had PGP and a key. Now, almost nobody seems to use it outside of FIRST, AV Research and similar enclaves...(stephen@sans.edu).

In another context this week I was reminded of a lesson I learned a long time ago, "One must make the desired behavior at least marginally easier than the wrong behavior." Almost by definition, "harder to do it right" is too hard.

Twenty years ago we were very concerned that user credentials would be compromised in the network. Today with activity more than a 1000 times what it was twenty years ago, credentials are compromised at the end points, not in the network. The reason is that for data in motion we use encryption. We use SSL. Thanks to Netscape, we use it by default.

When we say our prayers at night we should say, "Thanks for Netscape." Netscape understood that encryption in the World Wide Web was essential, like brakes on a car, not optional. They made it standard, not a separately priced feature. It was included in the function and price of the server. Thinking back on my time at IBM, I have often thought that had IBM invented SSL, they might well have priced it as an option and it would have failed. The way we price things often influences how we think of them and how we use them.

Even though the software is not separately priced, SSL has to be turned on and, at the level of its current default use, it has a significant cost. Nonetheless, we use it pervasively and users have come to expect it. We use it by default. If either party expects it, the other party can hardly avoid it.

Note that the problem addressed by the survey is identified as "file transfer," much of which is not even done in the network but on portable media, on what we used to call the "sneaker net." Much of it is ad hoc, with no standard procedures. Management has not told employees how to transfer data, much less how to do it securely.

The data leaks in dozens of ways. It leaks when users make gratuitous copies and then loses them. It leaks when backup copies fall off the back of the truck. It leaks when hackers compromise servers. It leaks through the user interface of ftp servers and other ways too numerous to enumerate. The user does not even contemplate most of these leakage modes and believes that the ones that he does contemplate are too rare to worry about.

Stephen Northcutt points out that PGP can be used to resist most of these leaks. Even simpler tools like passwords on .doc and .pdf files would resist many of them. PKZip and sftp are powerful tools to help us. However, most of these solutions require user involvement and a high level of user knowledge, not to mention judgment and initiative.

The solution to the problem includes making using encryption on all data easier than not, to make the encryption of data at rest the default, not the exception. It includes providing encryption by default across enterprises. It includes resisting gratuitous copies at the end points, even where the use requires that the data must be in the clear. It includes management direction and automated procedures to implement that direction.

A tall order you say? Suppose I told you that encryption by default is routine, automagic, in many enterprise and government domains and even across domains? True. Just for an example, Lotus Notes protects files and databases at rest, by default, using encryption. Even if one makes a gratuitous copy of the file on one's laptop or thumb-drive, it is encrypted. Notes provides for automatic safe exchange across domains. It provides for automatic key management that is transparent to the users. Obtaining copies of these files and databases in the clear requires both privileges and work. In this environment, it is easier to do it the right way. Indeed, it is so easy that many, not to say most, users do not even know that it is happening.

Though I believe that it is under-sold and under-appreciated, I am not here to sell Lotus Notes. I use it merely as an example of "encryption by default." I believe that encryption by default should be the standard in all government agencies and most private enterprises, and that we have at least one successful model of how to achieve it.

Security in "The Cloud"

Plus ça change, plus c'est la même chose.

When T.V. Learson was leading IBM, he was asked by a customer whether his IT should be centralized or decentralized. Learson responded that whatever way he was currently organized he should change it. Said another way, "What goes around, comes around."

In the early days of shared resource computing, the computer and most of the data resources were owned by the enterprise. "Data security," as we called it then, meant that what the enterprise said it intended, what it intended it did. We tried to help them think about it by suggesting the properties of the data that the enterprise most wanted to conserve. In some proportion of one to the others, the enterprise wanted the data to exhibit confidentiality, integrity, and availability.

To the extent that Grosch's Law described the economics, i.e., efficiency increased with scale, the economics favored centralization. Similarly, protection and control was also centralized. The risk was information leakage. The control of interest was Data Access Control, usually implemented as an optional process of the operating system.

In some cases use was metered and cost allocated but often cost was simply absorbed by the enterprise. This was in part because the meters and metrics of cost and value were immature. Metering and cost allocation were expensive and often had perverse effects on usage and uses.

At some point, Grosch's Law gave way to Moore's Law. Efficiency began to favor the small. When the scale of computing changed, it was not so much that data in the glass house moved to departmental and personal systems, although copies clearly did, as that data in departmental paper files got sucked in to the departmental and personal system, increasing the number of electronic records. At the same time, all computers were being connected to the Internet, making them and their data more vulnerable to attack by outsiders.

At about the same time as the scale was changing, we went from talking about "data security" to "information assurance," reflecting a shift in priority from confidentiality to integrity. Protection and control moved from centralized to distributed. The risk shifted to system contamination with malicious code. While we still used data access control, we relied more upon control of access to systems and applications. Other controls of interest included anti-virus, firewalls, and cryptography.

At this writing, we are discussing what security means in "cloud" computing. The name, cloud, for this style of computing comes form the cloud symbol that we used in network diagrams to represent that which was not known or beneath the level of abstraction at which we were working.

NIST defines cloud computing as "a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources" (e.g., networks, servers, storage, applications, software, and other services) "that can be rapidly provisioned and released with minimal management effort or service provider interaction."

However useful one may find the definition, some examples may help to appreciate the concept. The earliest emergent examples really define the cloud. Perhaps the most important of these is the Domain Name Service (DNS). E-mail and the World Wide Web are also on the list. Note that these are collaborative services, instantiated by the cooperation of many edge processes. For most users, their cost is included in the cost of their connection.

An early example is Hotmail, an advertising supported personal e-mail service. A more recent competitor to Hotmail is gmail from Google. As a personal service gmail is ad supported but Google also offers a service to "outsource" corporate e-mail. Instead of operating its own e-mail servers, an enterprise contracts with Google.

E-mail is an example of an application level service Dropbox is an example of a private file service in the cloud. Carbonite is an example of a backup service. IBM and EMC offer segment level storage backup. Indeed, they will operate an enterprise's entire storage network for them. Amazon offers a complete web storefront Think about almost anything that is hidden behind a standard service interface; it is available as a service in the cloud.

Those of us who were around in the days of "shared resource computing" think "what goes around…." In this analysis, the "cloud" is simply another shared resource computer. After all, it looks the same to the end users. At some level or another cloud service protect what they offer from contamination, leakage, or loss.

However, it is really not quite, indeed nowhere near, that simple. The cloud is really not just a computer or use. Rather it is an abstraction, a model for looking at computers and computing. It is on the same list as serial re-use, time-sharing, host-guest, and client-server. However, unlike these, cloud computing is not designed and implemented top-down but emergent from the bottom up.

The computing resources may include any combination of connectivity, computing capacity, instantiated processes, servers, storage, and services, including software (SaaS) and application services. While the resources are rapidly, and usually automagically, allocated and provisioned, use is metered and cost is allocated.

Security in the cloud turns not only on the axis of centralization v decentralization but also on one of scale, and on another of organization. Let's think about the last first.

In the cloud, the services are used by multiple users or organizations but owned by none of them. While most of the data may belong to the users, the hardware, software, and many of the controls are owned and operated by another enterprise, the service provider.

Each organization's interest in the security of the data is different. For example, the owner of the data may rank confidentiality, integrity, and availability, in that order, might prefer that the data disappear before leaking. The service provider, on the other hand ranks availability, integrity, and confidentiality, would prefer that the data leak than that he not be able to deliver it when it is asked for. One can easily imagine a scenario in which the service provider has so many copies of the data that he cannot erase them all on demand, perhaps not ever.

Users of the T-Mobile smart phone, the Sidekick were offered a service to backup the names, phone numbers, calendars, to-do lists, and other data that they had stored in their phones. This service was implemented by an enterprise ironically named Danger. However, it was offered to the user by T-Mobile under the T-Mobile brand. That there was a second enterprise involved was not apparent to most users.

Danger had a server crash. The service was clearly down and user's data was at least temporarily unavailable, perhaps lost altogether. To complicate matters, Danger was in the process of being acquired by Microsoft.

The story had a happy ending. In less than a week, Microsoft/Danger recovered the data and made it available on a new server. However, it illustrates another aspect of the cloud that impacts security; that is, you may not know with whom you are doing business or upon whom they rely.

The abstraction, The Cloud, hides the fact that it, the cloud, is a mechanism for combining, composing, and connecting (other cloud) resources to provide services with those properties, i.e., on-demand, easily and rapidly provisioned, that are described in the NIST definition of the cloud. A cloud application may reside in a cloud virtual machine, using cloud connectivity, cloud storage, cloud data, and even other cloud applications. Each of these resources may be offered by a different vendor and components my be added or subtracted on the fly. The service level agreements (SLAs) for these resources are probably "best efforts," the default service level for most information technology.

This is potentially a security nightmare for both buyers and sellers. Of course, a proper understanding of the problem is an essential step to a solution. More on this later.