Once upon a time there was a company called Code Spaces. Founded in 2007, it offered Subversion and Git hosting, and clients used the company for project management and development needs. According to various sources, Code Spaces wasn’t doing too bad.
One day, not unlike the same vein as the children’s story “The Three Little Pigs,” the Big Bad Wolf, metaphorically, knocked on Code Spaces’ door and said if the company didn’t meet his demands, he was going to huff and puff and blow their house down.
And blow it down he did. You can read the full account here and here, but essentially, a hacker gained access to Code Spaces’ Amazon EC2 control panel, leaving some messages for company execs to contact him. When they did, the person attempted to blackmail them by asking for a large fee in exchange for the return of the control panel.
Code Spaces tried to take back its control panel by changing passwords, but the hacker was not to be toyed with, and he began deleting things from the panel. The company managed to get access back, but not before the hacker had deleted much of the things Code Spaces needed to function, this causing the company to cease its operations.
As InfoWorld’s Pau Venezia noted in his June 23 article: “I’m sure this scenario never occurred to those poor souls at Code Spaces. More than likely they kept up their security measures, ensured that their server security was tight, and relied on Amazon for the bulk of their infrastructure — not unlike thousands of other companies. Yet the attack that brought Code Spaces under was as simple as gaining access to its AWS control panel. All the security in the world is immaterial when the threat comes from within, and that appears to be what has happened here.”
So what sort of measures are in place from Amazon or other hosting companies to prevent what happened to Code Spaces from happening to other companies?
I went right to the source – AWS – and received an answer from a spokesperson: “The current problems with the companies mentioned in the press the past couple days are not related to any AWS service issue. Our services are operating as designed. Customers who have questions about security best practices can find information at our Security Resources page.
Shortly after the incident, AWS posted an article with tips on how to secure an AWS account. Among its advice, AWS recommends using multi-factor authentication for the account and users who will be working in the account.
So is the cloud still a lawless Tombstone in need of a Wyatt Earp? Speaking to eSecurity Planet back in June, Patrick Thomas, a security consultant at Neohapsis, said, “Offsite backups have been considered a necessary operating procedure for any sensitive data, but in the age of cloud infrastructure many organizations think that they can simply pass the buck on backups, getting their geographic distribution and redundancy ‘for free’ as part of going to the cloud.”
In Code Spaces’ defense, it did say it had a recovery plan in place.
So this doesn’t happen to you, the same eSecurity Planet article offered some advice such as focusing on DDoS (distributed denial-of-service) attacks as well as security breaches. And when designing your site in the cloud, make sure the security is there as well as continued monitoring of the infrastructure.
Photo credit: Andrew Mager via Flickr