Government Incompetence Led to Cloud Compromise

US government officials have demanded an investigation into the compromise of 52 government related websites being housed “in the cloud”.  According to an article: “the hackers may have gained access through the content management system of third-party vendor GovTrends, although it cannot confirm this until more information is made available.  It appears, however, that all the hacked websites are maintained through GovTrends.  Joomla CMS, but not all House websites managed through this service, were victims of the attack.” [1]  While Congress fiddles around demanding answers to “what happened?“, I sit wondering why a more specific question isn’t asked:  “Why did it happen?“  Not “why did the compromise happen?”, but “why in the world did the government get suckered into the cloud?”

There is a lot of hype surrounding the cloud and it is a shame that as a security professional I have seen the compromises coming a mile away.  I have commented on them, they are blatantly obvious and any time this has been done (i.e., calling security of “the cloud” into question), so called “cloud security evangelists” keep churning out marketing to paper over the risks associated with the cloud.  Marketing, marketing, marketing!  Not once to date have I seen a logical response to real world security threats in the cloud.  They have almost always been “template” responses. My comments about the insecurities of the cloud are posted here on this blog, in numerous emails, numerous responses to LinkedIn questions and answers, and numerous discussions with individuals who work for businesses in the cloud.  Yet the main “theme” in responses about cloud security from the evangelists seem to be one of marketing, not feasibility, not “security-minded.”  Cloud evangelists and supporters alike appear to be in a “dreamy” state. Peddling “dreamy” theories and factory-like templates on security, while they may sound good on paper, lack any true “security” value.

Here is a quote from a cloud evangelist: [2]

I’m not sure how to express *exactly* what I’m feeling, so I’m going
to just “shoot from the hip”.


The “Use Cases” project is starting to feel like a car that just slid
off the road into a swamp. It’s just my own personal POV, but since
Security entered the conversation it feels like we’ve just been
spinning our wheels, and getting further and further from being able
to create any tangible deliverables.

IMHO Security can’t be shoe-horned into a Use Case — it is too vast
and unbounded for us (as a group) to have any hope of adding to the
current body of knowledge or generating any meaningful and practical
work products within the scope of the project as presently
understood.

Of course it’s entirely possible that I’ve underestimated the scope
(or time frame) of the project, but if not, then I think we’re heading
straight into the bog.

The discussion went into providing “Use Cases” for the cloud and building from there. This to me may lead one to believe that a “Use Case” scenario applies to a “real world” scenario for their particular company.  Companies differ and while a “Use Case” may have worked for one company, it is not a “holy grail” sign to move into the cloud.  Too much can go wrong and the expectation that any provider will understand “risk” outside of their own business objectives is insanity.  For this statement I will once again quote John Engates of Rackspace:

“You have to treat it like a factory instead of like a custom shop. You have to think large-scale. It might be easy to do something for one customer, but you have to think about the next 1,000 customers behind them, because everything has to be replicable, both from an operational standpoint and from a technology standpoint.  You have to be able to do a lot of work with relatively few people.  You always want to make a customer happy, but sometimes you have to say no to be able to have a scalable product or service.  You need a menu of offerings; you can’t do one-offs–they’ll break the model.“

Moving back to the initial opening on the government and the cloud, the answer to the un-asked question of “why did it happen?” is simple:  Oversight and trust.  Someone in government “trusted” a cloud provider enough to believe the provider was capable of providing security.  The provider likely impressed upon “someone” that the provider had the capabilities of providing proper security controls.  This has to be the case otherwise there is no reasonable explanation outside of a temporary lapse of sanity, that the government would have allowed data to be placed on an insecure server. Translation:  *someone*, *somewhere* stated and showed they had security mechanisms and controls in place to protect data and services… “We’re compliant with your needs, we provide security…” This is the answer to “why it happened?” – trust – not: “well, it happened because someone used a XSS Injection in Joomla.”

Reality is harsh and the harsh reality of this incident is:  GovTrends and their security department are incompetent along with those in government that made the decision to use “the cloud.” Apologies for the harsh words, but the reality is what it is. Had the US government’s IT architect’s and engineers taken the time to validate any security risks prior to using GovTrends, there is a high likelihood that any Joomla and or other CMS system vulnerabilities would have been discovered and there would have been no compromise at all.  While some may say it is unfair for me or anyone else to speculate that the Joomla vulnerabilities would have been discovered, then I’ll choose to disagree and state: “Joomla or any other CMS should have been secured.”  This compromise could have absolutely been avoided with simple and free solutions.  An .htaccess file prohibiting users via IP addresses – do you really need someone in another country accessing the management interface of a US government website?  Cost? Two minutes to configure at most. Another means of authentication, mod_security and I could create a list of fixes that would have mitigated against this compromise. Quite easily I might add.  The security lapse at GovTrends is inexcusable.  Not only from the vendor’s point of view, but of Congress’ lack of judgment. Trust but verify.

Cloud security will be a huge business in the coming months and years, and Schneier was spot on with the statement “security is a process not a product.” [3]  You don’t “rent” security in the cloud. You don’t “buy” security in the cloud.  As a realist, one need only to look at John Engates’ statement and figure out the truth at the end of the day.  That truth and harsh reality is that a cloud provider is concerned with nothing more than revenue for their business.  Not your data, not your security.  They can never truthfully claim to be capable of securing your cloud.  What they can truthfully claim is that they will try their best to meet a SLA and perhaps they may have good intentions on attempting to provide security.  However, they will not go above and beyond a template model.  Government is not a template, nor is anyone’s business. The US government and others who fall victim to buying shares of the Brooklyn Bridge solely need to realize the risks which were blatantly pointed out by ENISA’s cloud security risk document on page 9 [4]:

MANAGEMENT INTERFACE COMPROMISE: customer management interfaces of a public cloud provider are accessible through the Internet and mediate access to larger sets of
resources (than traditional hosting providers) and therefore pose an increased risk, especially when combined with remote access and web browser vulnerabilities.

Luckily for Americans, this isn’t the only “cloud based” issue one needs to worry about (website defacements).  There is the hard push to move a lot to the cloud. As we’ve already seen with the US government in its infinite wisdom treading dangerous ground with its Apps.gov [5], which is partly “powered by Google” [6].  Now Google, as we have stated earlier [7], bears some of the blame for the attacks by the Chinese in the sense that they have the capabilities in place to have stopped the previous attack (Operation Aurora) and did not do so:

Had Google an idea of what was really occurring during the compromise phase, they could have easily inserted a script that when a user landed on Gmail, which would have redirected users of affected browsers to a warning page: “Beginning INSERT_DATE_HERE, you will no longer be able to access Gmail using IE6.  Please update your browser as it exposes you to a lot of risk (or something along those lines).  This would have given Google a more caring like approach.  Aww, Google cares for my security!  If anyone can make something move on the Internet it certainly is Google.  Google to their credit warned users in 2008 to drop IE6 [8], yet everyone is shifting the blame to Microsoft.  I say, blame the users. [7]

That however is neither here nor there. What is here now though is the cloud. Those beautiful clouds!  The ones you would sit around the lawn staring up into the sky at.  Dreamy like!  Making shapes out of them only to watch them disappear into another form.  Vapor.

[1] http://www.infosecurity-us.com/view/6936/us-house-websites-hacked-after-state-of-the-union-/
[2] http://groups.google.com/group/cloud-computing-use-cases/browse_thread/thread/54be79e75f2abea4
[3] http://www.schneier.com/crypto-gram-0005.html#1
[4] http://www.enisa.europa.eu/act/rm/files/deliverables/cloud-computing-risk-assessment
[5] http://www.whitehouse.gov/blog/Streaming-at-100-In-the-Cloud/
[6] http://mashable.com/2009/09/15/government-going-google/
[7] http://www.theaeonsolution.com/security/?p=190