Seven Technical Security Myths of the Cloud

Monday, January 11, 2010 [1] staff wrote a document called “Assessing the Security Benefits of Cloud Computing” [2] and within the article they listed the “Seven Technical Security Benefits of the Cloud.” The article was well written and intentioned however, I decided to place a realistic view on the CloudSecurity’s content and in turn I present the “Seven Technical Security Myths of the Cloud.”

Beating a Dead Horse

Seven Technical Security Benefits Myths of the Cloud
1. Centralized (useless) Data

Increased data leakage: Laptops and other forms of storage devices are lost almost on a daily basis irrespective of the cloud and the cloud will not minimize this risk. In fact, I was a little confused by CloudSecurity’s point when they state: “Small, temporary caches on handheld devices or Netbook computers pose less risk than transporting data buckets in the form of laptops” Where in a cloud environment is this a benefit exactly, I surely seem to miss their point. Small and even temporary caches on ANY device don’t necessarily pose less or more risk. The risk is simply moved to the cloud and away from your visibility. Are you sure a cloud provider is defending against this? Aside from this, companies have taken note of timing attacks [3] – which are attacks that can lead to viewing the data that is in cache – and are defending against it already [4] [5],

In ENISA’s “Benefits, risks and recommendations for information security” [6], they clearly labeled data leakage [R.13] as a risk “in the cloud” which makes CloudSecurity’s initial take on data loss moot. Not only was that contradictory to CloudSecurity’s “Seven Technical Security Benefits…” article, so was R.30Loss or Compromise of Operational Logs” So we can now state that in CloudSecurity’s article, their: “Centralized Data” clause is flawed.

2. Incident Response and Forensics

While CloudSecurity touted forensic readiness, ENISA also addresses that risk (R.30) to debunk CloudSecurity’s first point on incident response. Therefore we can conclude that there will be the increased chances of a case to be thrown out of court before it is even heard. This is due to the attackability of shoddy evidence. Because ENISA listed the risks – and there are many – I’ll offer three in relation to Incident Response and Forensic without getting too far into detail. R.21 SUBPOENA AND E-DISCOVERY, R.12 INTERCEPTING DATA IN TRANSIT (how can we be absolutely sure there weren’t any cross cloud logging issues, contamination or loss – especially when ENISA points out: R.30 LOSS OR COMPROMISE OF OPERATIONAL LOGS) Downtime, shmowntime… CloudSecurity stated decrease downtime. They even offered spin on Amazon checksumming on the fly. Yet, it would be pointless if the data and logs are worthless. If ENISA listed “COMPROMISE OF OPERATIONAL LOGS” we can infer that any checksums are not to be trusted. Besides how can CloudSecurity realistically mention downtime. Haven’t they been reading the news: outage

Rackspace Outage

Blackberry Outage

Twitter Outage

Amazon Outage,289142,sid201_gci1376673,00.html

Microsoft Sidekick Outage

3. Password assurance testing

CloudSecurity mentions decreased password cracking time. I’d like to know how they factor this as a benefit to begin with. Not everyone is using a dictionary based password which is often the easiest to crack. In my company, we’ve mandated strong password policies which are changed every thirty days. In utilizing the cloud in this fashion (password cracking) we’d be wasting processor space thereby potentially increasing our cost. “You could crack passwords faster now!” Who honestly cares. This to me does not seem to be a benefit of using the cloud given the FACT that when there are proper written policies and those policies are adhered to, using strong passwords renders the use of the cloud for this purpose moot.

4. Logging

CloudSecurity stated “unlimited storage, improved log indexing and searching and compliance as a benefit. Yet ENISA called logging a risk – that along with: R.3 COMPLIANCE CHALLENGES, R.8 RESOURCE EXHAUSTION, R.21 SUBPOENA AND E-DISCOVERY, R.30 LOSS OR COMPROMISE OF OPERATIONAL LOGS, R.32 BACKUPS LOST, STOLEN

5. Improve the state of (in)security and (useless) software.

If the cloud can’t be trusted to properly store encryption keys (R.17 LOSS OF ENCRYPTION KEYS), they can’t properly address covert channels (R.27 MODIFYING NETWORK TRAFFIC) and can’t even ensure I can use the software (R.25 NETWORK BREAKS) I really don’t see an improved state of security. Can you?

6. (in)Secure builds
Where the lists “Secure builds” as a plus, ENISA debunks that notion with: R.10 CLOUD PROVIDER MALICIOUS INSIDER – ABUSE OF HIGH PRIVILEGE ROLES – how can I be sure someone didn’t do something in their cloud. Perhaps backdoor it to gain access at another point in time? [7] R.11 MANAGEMENT INTERFACE COMPROMISE (remember, the logs could be compromised so you’d never know the interface was “pwned”). R.17 LOSS OF ENCRYPTION KEYS – remember Debian? [8] R.19 COMPROMISE SERVICE ENGINE R.20 CONFLICTS BETWEEN CUSTOMER HARDENING PROCEDURES AND CLOUD ENVIRONMENT R.23 DATA PROTECTION RISKS R.25 NETWORK BREAKS R.27 MODIFYING NETWORK TRAFFIC R.28 PRIVILEGE ESCALATION R.29 SOCIAL ENGINEERING ATTACKS (IE, IMPERSONATION) R.30 LOSS OR COMPROMISE OF OPERATIONAL LOGS

7. (lack of) Security testing


I’d also like to point out a statement amidst the writings and pie charts from ENISA’s “Cloud Computing Information Assurance Framework” [9] where it states: “The use of public clouds – even with favourable responses from the following questionnaire – is not recommended for anything but the lowest assurance classes of data. ” That should be the nail in the coffin however, I’m almost positive “cloud evangelists” will work on some carefully constructed wording to counter this writing.

blog [@] theaeonsolution dot com

Original Post:
Possibly Related Articles:
Cloud Security
Cloud Security
Post Rating I Like this!
John Theos Interesting article and I tend to agree with ENISA's assessment that "is not recommended for anything but the lowest assurance classes of data."

The question however is, what qualifies for as lowest assurance classes of data? I can see where I wouldn't want to store confidential information on the cloud - instead opting to keep it in my internal servers - but if my own policies are poorly laid out I may have a false sense of security and the data could be just as vulnerable as if it were on the cloud.

Additionally does one put on their email servers on the cloud? The first reaction (by many) would be that this is sensitive info and should not be on the cloud. But how many of the internal Exchange servers are now accessed through a web based front end (for travelling employees)? Aren't those servers just as vulnerable to hacking as the servers that are on the cloud?

Most Liked