The Security Blog

Clearing the Cloud Part II – A Ray of Sunshine On A Cloudy Day

• On-demand self-service, based upon
• Ubiquitous network access, using
• Location independent resource pooling, feature
• Rapid elasticity and provide
• A Measured Service.

Security Models

Figure 1: Jericho Forum's Cloud Layers

 

At about the same time, the Cloud Security Alliance, of which I am a member, designed a not-too-different view.

 

The CSA broke down Cloud computing into three delivery types:

1. Infrastructure as a Service (IaaS)
2. Platform as a Service (PaaS)
3. Software as a Service (SaaS)

 

And then proceeded to define the Cloud consumption models:

1. Private
2. Public
3. Managed
4. Hybrid

 

If I arrange those elements in a matrix, we will get a cube similar to Jericho’s work:

 

Figure 3: Cloud Computing Cube

 

The CSA’s model of service delivery stacks, however, is very complicated.    While I do not disagree with their reference model, I find it to be exceedingly complex. 

 

 

So, allow me here to define the problem statement a bit differently than above. Because these are the early days of any cloud discussion, and that translates usually into this time being the formative years, let’s expand the basic three tenets of security, which are:

1. Confidentiality
2. Availability and
3. Integrity

 

And add additional controls.   We will borrow from Donn Parker’s Hexad, and add:

4. Possession (or Control)
5. Authenticity and
6. Utility

 

Clearly, in the case of Cloud computing, and especially in the Public/External case, we no longer have any control. Once the bits “leave our network,” control passes elsewhere.   And then there were five.

 

 

Losing one control typically mandates an increase in the other controls. Here, we have another set of problems.    Let us explore the remaining controls:

 

• Confidentiality: Typically, we handle confidentiality through the usage of technologies such as Encryption and access Control.   We can still encrypt, but imagine what happens to a large data set.   It has to be sent, or assembled, in the Cloud, remain there in an encrypted form, and be transferred to us, for processing.

  Once the data is at our location, we have to decrypt it, perform the operations needed, then re-encrypt and resend to the Cloud.   Doable – yes. The performance tax here is huge. While today’s routers and servers no longer have their performance brought down to 1/6^th by encryption (a loss of 84%), we still pay a heavy price.

 

Figure 4: Lifecycle of Encrypted Data

 

Let us state once more: Having the data unencrypted at any point in the storage or transfer process exposes it to unauthorized disclosure. Unauthorized exposure, of course, is the opposite of any good security or compliance requirements, such as PCI or HIPAA. Even Amazon, with inherit interest in providing such services, announced that their Cloud is not PCI compliant nor intended for such work:

 

Hi,

Thank you for contacting Amazon Web Services. Our payment system is PCI compliant and it is an “alternative payment processing service” meaning your users re-direct to our platform to conduct the payment event using their credit cards or bank accounts. The benefit for you is that we handle all the sensitive customer data so you don’t have to. If you haven’t looked at it, I highly suggest you check out the features and functions of our Flexible Payment Service and our Payment Widgets ( http://aws.amazon.com/fps).

As for PCI level 2 compliance, that requires external scanning via a 3rd party, PCI-approved vendor. It is possible for you to build a PCI level 2 compliant app in our AWS cloud using EC2 and S3, but you cannot achieve level 1 compliance. And you have to provide the appropriate encryption mechanisms and key management processes. If you have a data breach, you automatically need to become level 1 compliant which requires on-site auditing; that is something we cannot extend to our customers. This seems like a risk that could challenge your business; as a best practice, I recommend businesses always plan for level 1 compliance. So, from a compliance and risk management perspective, we recommend that you do not store sensitive credit card payment information in our EC2/S3 system because it is not inherently PCI level 1 compliant. It is quite feasible for you to run your entire app in our cloud but keep the credit card data stored on your own local servers which are available for auditing, scanning, and on-site review at any time.

Regards,

Cindy S.
Amazon Web Services

Figure 5: From here

 

 

Figure 6: Encryption in Cloud Case Study

Try the following as an example: Suppose you have a volume of credit-card bearing transactions that you must preserve for a period of one year.   And let’s assume that the data is in SQL form.   If so, the steps needed would include: Exporting the relevant tables Encrypting these files with suitable encryption Uploading the encrypted files to your cloud “bucket” Storing the data in the cloud, in an encrypted form Downloading it, while encrypted Decrypting the data Importing the data, and finally Processing it

One other element within Confidentiality is the ability to destroy data.  In a cloud, that we do not own, and on storage media that we do not control, there is high –probability that the same media be used for other purposes.   These storage buckets are dynamic and the service/platform/application provider might allocate them to other users.

This sharing, and in many cases, repeated sharing, of storage media leads to the need for assured destruction. We must follow a strict regime that states how long is data to be kept, when and by whom destroyed, and how such destruction is verified.  Since degaussing tapes and shredding CD’s is out of the question, we must employ more agile software- (or, dare we say – hardware?) based methods to assure that destruction.

Figure 7: Chercher les …données?

This question becomes infinitely more complicated when we consider that data at rest does not necessarily “rest” on a certain platen of a certain hard drive. The data can, and usually does, move between storage locations on the drives.   The onus is still on us to assure confidentiality, but… we don’t manage the drives.   The only practical solution here is to demand regular scouring of storage media from the service providers.   Do we think that such a requirement is feasible?

• As for Integrity, we can detect changes after they were made. From hashing to redundancy checks, from digital signatures to trip-wiring we are able to ascertain that a change occurred.   But… we can no longer prevent changes.  

  The bastion of defense in depth has crumbled when we talk about Cloud computing. We do not own the moats, the walls, or the doors (see my paper about the Evolution of Defense in Depth).   Accepting data without verification should be unthinkable, verifying all inbound data will be complex and costly. Adding yet another layer to the mix of technologies and methodologies that we must rustle.

  Indeed, the Cloud unchecked could lead to a wave of new attacks aimed directly at data whose guardians (by virtue of possession) are not incentivized to protect it from change, only mostly to be able to speed it on its way.
   
  Cloud computing could be a gold rush to people designing man-in-the-middle attacks, too. While most hosting companies will boast of their monitoring and security, few, if any, can assure you that they have never been compromised.   In fact, a provision of Cloud data, with its already built in doorway (or tunnel) to you, makes their life easier. They can now both alter the data AND assure that it, and associated payloads, make their way to the intended destination.

• If we remember the example we used above, in the University case, Authenticity of data is a problem that must be addressed.   Sometimes seen as a combination of non-repudiation, integrity and accountability, Authenticity is a super-set that defines the reliability we assign and the trust we place, in our data.

Should data in/from a Cloud seen as less-trusted data? If so, is there any worth to it?   Would Cloud end up being used only for data we could care less about? Only time would tell.   But In the following article will offer some solution ideas.

In the next article I will put forward some ideas on how to resolve issues defined in this and the previous articles. I will also attempt to show some of the security related benefits that we can garner from the usage of Cloud Computing, especially those that we could not, or could not easily, do before the advent of the Cloud.

This article is my first in the series which I called "Clearing the Clouds" talking about security and Cloud computing.

Here it is, as published on May 19, 2009, on CSOOnline.com

In Depth

Cloud Security: Danger (and Opportunity) Ahead

In the first in his series of "Clearing the Cloud" columns, security expert Ariel Silverstone explores the dangers of cloud computing and outlines security best practices to make it work.

By Ariel Silverstone, CISSP

The dramatic change in the rate of adoption and the amount of discussion taking place regarding cloud computing demands that this technology, or rather a set of related technologies, continue to evolve utilizing a security-sensitive design.

We approach quickly the point in which the amount of data and of processing in the cloud will be not only unmanageable but also pose a security and related privacy risk to the users of the data, and to people who the data concerns. [Cisco CEO: Cloud Computing a 'Security Nightmare']

In this series of articles, I do not intend to solve the problem of security in the cloud. My intent is to define the problem and propose several salient ways to address it. As always, comments are welcome. [Related: Cloud Computing: Making the Right Choices]

Terminology

While the term "cloud computing" may be new, the idea certainly is not. Just look at the greatly varying definitions I found while researching this article. These include all of the following technologies:

• 1. The grid
• 2. VMWare and Xen-type virtual machines
• 3. IBM-type mainframes
• 4. Amazon-type flexible storage
• 5. Intel VTX-type hypervisors
• 6. Page files
• And many, many others

Instead of focusing on a specific technology, I propose we define the salient characteristics of cloud computing. For the purposes of this article series, I will define cloud computing as the technology having the characteristics of:

"Service-based data processing and storage capability which is flexible, extensible and virtual"

Some may add the following:

"and available via the Internet"

I will treat the second part of the definition as optional, for the purpose of discussing security. I find that the connectivity method here is secondary to the basic tenets of security, and thus am able to include locally virtualized machines in the discussion.

Generally, the purpose of cloud computing is to avoid the expense involved in building or acquiring the infrastructure. Similarly, when deploying virtual machines, one does not buy multiple servers or separate processors. I find the computing slice concept — which includes storage, processing power, etc. — to be a compelling one. In the near future, I predict that we will not even CARE whether the computing slice resides locally or across the world. As long as the computing service is provided in a timely and efficient manner, we will be satisfied.

When dealing with cloud-based delivery, the problem with security grows. Instead of having direct control over our concept of "defense in depth," we now have marginal control at best. Many times, such as with Amazon's EC2 service we have virtually no control, no pun intended. We sometimes do not have even the basic notification of something about to go wrong or something that has.

Both for Amazon's service and for our basic hypervisors, we no longer control ingress to the machine processing space. In the case of Amazon, it is Amazon's routers (and presumably firewalls). In the case of our virtual machine managers, we relegated the inter-memory systems and processes to the handling of a "black box," one that we seldom, if ever, have any control over. These are security problems and I also believe that these are legal problems. Allow me to explain.

What happens if and when data that we store or process on a virtualized machine gets compromised? Will we know? If WE do not know, how will we notify our constituents, especially when data breach notification laws are in place? How will we know to improve our security?

These are not idle words. If you look at the Amazon contract (and this is an example only, I do not wish to "pick on" Amazon, which I appreciate and respect), you will see the following sentences:

"4.3: We are not responsible for any unauthorized access to, alteration of, or the deletion, destruction, damage, loss or failure to store any of, Your Content (as defined in Section 10.2), your Applications, or other data which you submit or use in connection with your account or the Services."

"7.2: We will have no liability to you for any unauthorized access or use, corruption, deletion, destruction or loss of any of Your Content or Applications."

What you do not see is that the provider accepts any responsibility or duty to inform the data owner, you, of any breach, notify you of any attempt, nor responds to any incident. The agreements are worded such that the customers' of Cloud computing bear all responsibility for such risks. It therefore appears that any law requiring breach notification, and any regulation or requirement, such as PCI, cannot be complied with.

Since the concern above is present, and understanding the incredible potential of cloud computing to improve the performance of IT foundation and infrastructure, we must find a solution, or a set of solutions, to standardize and address security concerns communicating to the cloud, within the cloud, and to data elements which reside therein.

In the next article, I will discuss the requirements for such solutions, and will include the excellent proposals brought forth from the Jericho Group and from the Cloud Security Alliance. I will also issue a "call to action" for these and other organizations to address the issue of cloud security before the technology become either unmanageable or, conversely, be seen as too risk-laden for corporations to use.

Ariel Silverstone is a veteran of the Israeli Defense Forces with experience in physical and information security and regularly contributes to information technology certification exams and to newspapers, magazines and electronic publications while working on a Radio show. He holds both the CISSP (for security) and the CBCP (for business continuity planning) certifications, as well as many others. During his IT and management consulting career, he focused on providing IT strategy, engineering, and assimilation solutions for a portfolio of primarily Fortune 500 clients, including USAA, Chase Manhattan, Citibank, GTE, General Motors, Ford Motor Company, Vanguard Funds and others. He specializes in companies in the financial services, transportation, medical services and high-tech industries. He has also been a director at Symantec Corp. and CISO for Temple University and for Bell Canada's Teleglobe.

 Permalink