One of the fundamental prerequisites for any IT Infrastructure is that it is secure, and doubts about security have plagued Cloud vendors for as long as they’ve existed. While there have been data breaches, Cloud computing has proved secure enough over the past few years for it to be considered a valid option for many organizations. However, the destruction of Code Spaces on June 17th at the hands of hackers who gained access to their Control Panel at AWS was a worst case scenario brought to life, and brought Cloud security questions back into focus.
The hack at Code Spaces wasn’t targeted toward collecting confidential data, but rather to the control of the client’s Cloud resources. The hackers gained control of Code Spaces management utilities, demanded ransom, and then deleted data when Code Spaces tried to regain control. We’ve known these details since shortly after the incident occurred – what we don’t know is exactly how the hackers were able to get control of Code Spaces resources. Was there a flaw in Amazon’s security, or in Code Spaces implementation, or was this simply inevitable due to the intrinsically public nature of the Cloud?
We’re not likely to get a detailed answer for how this happened until investigations have been completed. What we do know is that management utilities in a public Cloud are by definition publicly accessible, and that they must be locked down to be secure. Amazon specifically states that security is a shared responsibility, and they provide detailed guidance on security practices for their public Cloud. Amazon provides the equivalent of an isolated IT environment in a locked room, and provides access to administrative tools for controlling that environment – it is up to the user to lock down administrative access using the provided role assignment and multifactor authentication (MFA) tools.
Building an environment in the Cloud is relatively easy – that’s one of the selling points. For new Cloud subscribers with very basic admin needs, a complex security model may seem to be overkill – but as sites grow in scale, complexity, and number of admin users, the need for locking down administrative access becomes more acute. In a small, relatively basic security model, roles may be configured too broadly, and administrative roles may have far more permissions than needed for basic daily tasks. If the security model is not updated as the site grows, a set of compromised administrator’s credentials could cripple the Cloud infrastructure.
Using MFA should prevent a hacker from accessing control tools even if they gain access to administrator credentials. The hacker should only be able to obtain an MFA access code if they had the device that generated the code. But, in a scenario where an administrator keeps password information on a device that is also used as an MFA device (e.g. a smartphone), all it would take would be one stolen phone to provide access to Cloud Management tools.
But even with roles defined properly and MFA in use, and administrator’s laptops and smartphones properly secured, there is always the possibility that something could go wrong with your Cloud environment. Maybe not through hacking – maybe through administrator error, or natural disaster, or a hosting company closing its doors. That’s where backups come in, and that was the fundamental flaw in Code Spaces infrastructure. They had backups in multiple locations, but the multiple locations were all within AWS, and under the control of the compromised control panel. Backups to an outside location would have allowed them to rebuild. There would have been downtime, and some lost data, but they would still be in business.
Keep in mind that while the data was deleted, it was not compromised. The hackers were able to delete the S3 buckets, but they didn’t read them. Code Spaces and AWS did succeed in maintaining the confidentiality of the data, if not its continued existence. In those terms, the Cloud did successfully maintain security. However in terms of maintaining data integrity, some as yet unidentified portion of the shared security architecture failed. The moral of this story will likely end up that the Cloud can indeed be used securely, but that both Cloud users and vendors need to pay strict attention to security guidelines. In the case of Code Spaces a detail was missed somewhere and they paid the price.