Seven Technical Security Myths of the Cloud

CloudSecurity.org [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.30 “Loss 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:

Salesforce.com outage
http://www.datacenterknowledge.com/archives/2010/01/04/salesforce-com-hit-by-one-hour-outage/

Rackspace Outage
http://www.thaindian.com/newsportal/tech-news/rackspace-outage-affects-several-sites_100291843.html

Blackberry Outage
http://www.pcworld.com/article/185397/blackberry_outage_rim_should_compensate_users.html

Twitter Outage
http://www.themoneytimes.com/featured/20091218/twitter-restored-after-being-hacked-id-1094523.html

Amazon Outage
http://searchcloudcomputing.techtarget.com/news/article/0,289142,sid201_gci1376673,00.html

Microsoft Sidekick Outage
http://tech.blorge.com/Structure:%20/2009/10/11/microsofts-sidekick-cloud-outage-gets-worse/

Microsoft snafu calls into question its cloud reliability
http://www.infoworld.com/t/cloud-computing/microsoft-snafu-calls-question-its-cloud-reliability-513

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 CloudSecurity.org 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

* Why continue to beat a dead horse? R.20 CONFLICTS BETWEEN CUSTOMER HARDENING PROCEDURES AND CLOUD ENVIRONMENT

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.

JO
blog [@] theaeonsolution dot com

[1] http://www.cloudsecurity.org
[2] http://cloudsecurity.org/2008/07/21/assessing-the-security-benefits-of-cloud-computing/
[3] http://www.computer.org/portal/web/csdl/doi/10.1109/AINA.2008.109
[4] http://www.h-online.com/open/features/Linux-and-TPM-747063.html
[5] http://technet.microsoft.com/en-us/library/cc766015%28WS.10%29.aspx
[6] http://www.enisa.europa.eu/act/rm/files/deliverables/cloud-computing-information-assurance-framework
[7] http://news.softpedia.com/news/The-World-Bank-Denies-Compromise-of-Employee-Records-95545.shtml
[8] http://www.debian.org/News/2006/20060713
[9] http://www.enisa.europa.eu/act/rm/files/deliverables/cloud-computing-risk-assessment