The Importance of Access Intelligence – Code Spaces Shutdown as an Object Lesson
June 19, 2014 | DevOps |
As many of our friends and customers in the cloud and devops world know, Git and Subversion provider Code Spaces has gone offline, presumably permanently, as a result of a combined DDoS and malicious deletion of data attack levied against their Amazon Web Services accounts.
First and foremost, we extend our sympathies and condolences to anyone adversely impacted, from the team at Code Spaces to their customers, many of whom lost not only a provider but likely data as well. This is, in the words of some of the journalists who are covering the story, a “nightmare scenario” around cloud security.
It is also a wake up call. There are significant warning signs in the Code Spaces attack that the rest of us need to learn from, identify in our own organizations, and take steps to remediate. Among them:
- Ensure least privilege access controls are in place. One of the the primary problems with the Code Spaces attack was that even as the attack was occurring, the team was unable to lock down their AWS environment owing to root AWS account access. Accounts had been created across the board that the malicious party (who is still unidentified) was able to access and modify the AWS environment to bypass initial response attempts. The root account should be used “in case of emergency” and access should be strictly limited with strong separation of duties among the various infrastructure team members.
- Embrace and implement defense in depth. The EC2 panel was a single point of failure, and when it was breached, it yielded access to the entire Code Spaces data stack: production systems, backup data, customer information, and so on. Had a properly segmented, independently protected set of user and system authentication and authorization systems been in place, it would have been much more difficult for an attacker to have done as much damage (or to have wreaked havoc so quickly).
- Think “access intelligence”, not just “access management”. Complementing access management technologies (SSO, primarily) with access intelligence systems that are capable of protecting access to critical infrastructure can help to avoid this type of vulnerability. A singular reliance on authentication systems as guardians of the AWS console, even with 2FA, does not fully mitigate the risk associated with unauthorized access to AWS console accounts and their related assets. And there are many “other doors” into cloud hosted systems such as Code Space’s.
As an industry and as security professionals, we need to recognize that there is a foundational difference between how data is protected when it resides in an environment that we own and control, and when it resides in cloud systems (be it AWS or Azure, Rackspace or Google’s Cloud Platform) where we cannot simply unplug and manage a response offline.
The analyst community has been shifting their focus towards a “zero trust” model for handling privileges and responding to cyberthreats. As dramatic as Code Spaces’ failure was when compared against even the most sharply written research, perhaps we would all do well to spend some time reviewing their recommendations and asking if we’re applying them to our own cloud environments.
If you want to learn more about how to implement access intelligence in your cloud environment, we would be happy to help. Drop us a line at [email protected].