Author: Terry Kurzynski, ISO 27001 Auditor, CISSP, CISA, PCI QSA
The information security community is abuzz with the news of Code Spaces closing its doors after having all of its client’s data erased by an attacker who gained access to their environment. Code Spaces offered their clients a “code repository” service – think Subversion-as-a-Service – and convinced their clients that their code was safe from data loss when stored there. The failure is seen as the first “death” in the cloud. According to Dave Shackleford of Voodoo Security, “This thing is going to be a case study for everybody’s cloud security forever.” (Blevins, 2014)
Code Spaces built their service on Amazon’s Web Services (AWS) platform, using AWS for everything from their website to storage and, presumably, backup. Considering that the attacker got to Code Spaces’ data through an administrative console provided by AWS, and was able to delete data stored in the backup environment as well as the production environment, should Amazon share any of the blame for Code Spaces’ demise? Most experts seem to think that Amazon did enough by stating in their AWS Security Center that security is a shared responsibility. Rich Mogull of Securosis opined “…Amazon does a good job of emphasizing the importance of applying multi-factor authentication and [that] the company provides a range of options.” (Blevins, 2014)
Amazon AWS clearly outlines the security features of the AWS Infrastructure and also indicates that anything built on top of their infrastructure may be vulnerable and the responsibility of the user “…the security responsibilities will be shared: AWS has secured the underlying infrastructure and you must secure anything you put on the infrastructure…”
But is that enough? The AWS business model targets small organizations that very likely do not have in-house security personnel who understand where Amazon’s security assurances end and where the business customer’s security responsibilities begin. Let’s face it, most organizations are behind the curve in their security expertise. This does not absolve small businesses from their responsibility to assess their risks and to put appropriate safeguards in place to manage those risks. After all, lack of sophistication is not an excuse from liability. But if Amazon knows their client base is likely not security-savvy, what should they do to ensure that the lines of responsibility and security are clearly drawn?
One thought is … clearly draw the lines. Literally. Provide a diagram that demonstrates, at least conceptually, what AWS assures, and what their business customers must do for themselves to secure systems and data.
Conceptually, a “Figure 1” could show what a business customer’s applications and services look like in the AWS security model if they have not appropriately configured security. All of AWS’s security offerings could be illustrated in a model similar to the one below (Figure 1). They could provide a disclaimer stating to both business customers and the public that an application or service that is built into AWS may enjoy some security protections while still being vulnerable to some threats. This would depend on how well the business customer configured the security tools that AWS makes available to them.
Figure 1
And a second model (Figure 2) could show an application with an improved security configuration. In this model, the business customer’s application or service would be surrounded by security controls, indicating that these applications can be configured in a secure manner.
Figure 2
With these two conceptual models, or something similar, Amazon could very simply signal to their business customers and the public that applications in the cloud must be properly secured. Even if security tools are made available to business customers, these customers must configure those tools correctly in order to ensure security.
This isn’t to say that Amazon must provide drawings to describe their offerings, but shouldn’t they do their best to make a relatively complex concept simple to understand?
Another object lesson that AWS and other cloud providers could learn from is Apple’s insistence on high standards for apps sold in their app store.
Apple provides a platform where businesses can make money by selling their Apps in the Apple App Store. However, Apple views the relationship between the supplier of a service (Apple App Store) and the Developers (businesses) in a different manner than Amazon. Apple takes a stand on what it will and will not accept from Developers/Business in their App Store and has laid out a lengthy document summarizing all of Apple’s App Store rules. Apple has a guiding principle – to honor and protect its customers (including children) at all costs. Apple is not going to risk its own reputation by allowing a few shady Developers to take advantage of loyal and trusting Apple consumers. Apple lays out well-documented standards that Developers must follow, and bluntly tells them to “prepare to be rejected…” if they do not follow the guidelines.
Like Apple, Amazon should implement a security-based agreement with their AWS customers to protect its brand. And while Apple’s model would be too restrictive for Amazon and their AWS customers, Amazon could explicitly prohibit all of their customers from touting AWS-based security unless that customer adheres to the security principles that are provided through their “Trusted Advisor” services. This would significantly reduce the risk of AWS-based cloud services from inappropriate claims of security-through-association.
So where does this leave us with our original question of Amazon’s culpability in Code Spaces’ attack and demise?
While Amazon clearly communicates the limits of their security benefits, and they clearly communicate that their business customers bear their own responsibility for cyber security, their message is delivered to a largely unsophisticated audience. Their small-to-medium-sized customers are seeking out AWS because it is secure. In an environment in which security is still baffling to technicians and business people, it is very appealing to enshroud themselves within the protective cocoon of a reputation (if not a secure password policy or security information and event management (SIEM), for instance).
So what should all of these players do in the face of security realities in the cloud?
- Amazon should consider implementing cyber security standards and a certification process for customers who develop applications using their infrastructure. And they must enforce those standards in order to make the process meaningful. Unless a business can prove that they are following a rigorous risk management process, Amazon should state in their contractual relationships that businesses are forbidden from citing Amazon’s security features as proof of their own security.
- Code Spaces didn’t adequately secure their environment, and didn’t understand or mitigate the risks inherent in their back-up processes. Cloud customers, and cloud providers leveraging a larger cloud service, must understand where the cloud service’s security assurances end and where their own security responsibilities begin. Consulting with the cloud providers’ security team is a good start, but an assessment of the risks inherent in the architecture, technologies, and processes helps organizations design their appropriate security architecture. Just because their cloud provider is secure, doesn’t mean they are secure by association.
- Clients of Code Spaces must perform vendor risk assessments in order to understand the risk of doing business with, and placing their data in the custody of, their service providers. By performing a risk assessment, and asking the right questions, clients of Code Spaces could have uncovered the risks of doing business with them and realized that their code repository provider didn’t have a back-up plan for itself or its customers.
While the “cloud” is still a mysterious and confusing service model for businesses, it may be helpful to think of the cloud as vendors that use other vendors. When we hire a cloud service, we share risk with them and with the vendors they hire. If the chain of cloud services are not clear about the security assurances they provide, then their customers will inherit more risk than they expect.
When you engage cloud services for business, conduct a risk assessment and make sure that each vendor in the cloud service chain is able to demonstrate how their cyber security assurances are compatible with your risk needs. If they cannot clearly demonstrate their role in protecting your information, it’s best that you move on to a service that can.
What do you think? Should Amazon take a more active role in managing the security posture of their users? As a business, do you conduct vendor risk assessments with all of your vendors?