Recently I posted some thoughts on cloud security (here), (here), and (here). The bottom line still holds true…
When we allow services to be delivered by a third party we lose all control over how they secure and maintain the health of their environment and in many cases we lose all visibility into the controls themselves, that being said…Cloud Computing platforms have the potential to offer adequate security controls, but it will require a level of transparency the providers will most likely not be comfortable providing.
In September of 2008 Amazon released a paper entitled “Amazon WebServices: Overview of Security Processes” which discusses, at a high-level, aspects of Amazon’s AWS (Amazon Web Services) security model. Essentially it says that they will provide a base-level of reasonable security controls against their infrastructures and the enterprise is required to provide the required security controls against their guest OS instance and other attributes of the customer environmental variables, including data backup, controls, and secure development.
The biggest problem is that you, as the consumer of this technology, will not be able to audit the security controls. You, as the consumer of this technology, will need to rely on their assertions of the controls and static (SAS 70) audits that these controls are actually in place – sans details of course.
The other big problem with the “joint” security model Amazon proposes is that it adds a level of complexity to the organization utilizing the services. They now have to manage, report against, and provide accountability for the tsunami of compliance audits in a mixed environment where infrastructure is maintained and secured by Amazon and other parts must be maintained and secured by the customer, this is in addition to, but not necessarily in cooperation with the customers current operational security models.
The rest of the paper weaves its way through traditional security mechanisms like they use firewalls and require SSH access to remote boxes, and they will totally ban someone from port scanning as well as less traditional security mechanisms, but also far less mature or proven, such as relying on the control within the Xen hypervisor.
So what are the salient aspects of the paper? Well you can read the gory details – or lack thereof – (here)
Something, something this way blogs 
You, as the consumer of this technology, will need to rely on their assertions of the controls and static (SAS 70) audits that these controls are actually in place – sans details of course.
Just like any commodity service – for instance, credit card companies – we have to rely on their security practices. Nevertheless are ways of encrypting data – which is yours.
Right, but the difference with credit card transactions and banking is that there is recourse available to deal with fraud and other malicious activity…I seriously doubt that same level of recourse would ever be available to consumers of the Amazon AWS cloud technology.
Do you think that a cloud provider would compensate for lost revenue due to an operational failure – accidental or malicious? What if the operational failure resulted from them not responding quickly to a need to say upgrade/patch?
Of course not…
Do you think that a cloud provider would compensate for lost revenue due to an operational failure – accidental or malicious?
Would ? No! It should ? Yes, just like and other “datacenter” that has rules and compensates when problems occur.
What if the operational failure resulted from them not responding quickly to a need to say upgrade/patch?
Actually, we cannot say for sure that any slice/vm service is really secure. These are the new physical structures of cloud datacenters, which should audited regularly.
Currently and aiming for AWS, I’m worried about the Xen VM security – what happens while the VM is running ? who can access that ? -, key infrastructure – do they audit it? – and access to S3 private storage – do they sign and encrypt it ?.
So we are in agreement =)
Pingback: Friday Summary: 12-12-2008 | securosis.com