tag:blogger.com,1999:blog-2511631377600597263.post7722361028262597991..comments2023-10-29T14:05:00.630-05:00Comments on Nick Coblentz: Cloud Computing Data SecurityNick Coblentzhttp://www.blogger.com/profile/02039723015167872217noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-2511631377600597263.post-12574300599182029722009-03-24T12:24:00.000-05:002009-03-24T12:24:00.000-05:00Andre,Those are some great points. When I wrote t...Andre,<BR/><BR/>Those are some great points. When I wrote this article I tried to limit the scope of my discussion, but it looks like I left out issues related to security controls or flaws in virtualization products themselves. Instead, I placed a lot of emphasis on operational security and external threats. Thanks for bringing those points up.Nick Coblentzhttps://www.blogger.com/profile/02039723015167872217noreply@blogger.comtag:blogger.com,1999:blog-2511631377600597263.post-4216611795954510262009-03-24T12:03:00.000-05:002009-03-24T12:03:00.000-05:00@ Nick:You are missing a few key arguments against...@ Nick:<BR/><BR/>You are missing a few key arguments against Amazon/GoGrid/Mosso/Azure/etc.<BR/><BR/>First of all: it's all about targets. Amazon/GoGrid/Mosso/Azure are HUGE targets, and well-known targets. Some no-name, quiet bank or hosting company with private infrastructure is a less-likely target. This is security by obscurity in a way, but it's the part that often works...<BR/><BR/><I>An administrator for Amazon S3 may be able to access the cipher-text for cardholder data; however the administrator would not have access to the secret key used to encrypt the data. It would be very difficult for that administrator to discover or brute force the secret key associated with that data</I><BR/><BR/>No. An administrator for Amazon EC2 can access the cipher-text and secret key because that administrator has control of the VM-guest MEMORY (i.e. what the VM-guest sees as physical RAM, but is really virtualized hardware). It is not difficult to discover or grep for this secret key, especially having loaded a hypervisor introspection layer such as XenAccess.<BR/><BR/><I>Customers can place bucket or object-level access controls around data within Amazon S3. Customers directly control the application of security patches to virtual images. Data can be encrypted prior to being placed within cloud storage, rendering stolen data useless for an attacker. Customers rely upon Amazon to apply patches to flaws identified within S3 or Amazon's API</I><BR/><BR/>Data-at-rest on disk that is never accessed by any OS process is safe. Data-in-motion, even data-in-motion on the local system is always at risk due to the memory issues outlined above. The data is not encrypted in RAM-memory, nor is it encrypted in the VM-guest paging file in many cases.<BR/><BR/><I>An administrator for Amazon S3 may be able to access and modify the cipher-text for cardholder data, however the administrator would not have access to the secret key used to encrypt the data. It would be very difficult for that administrator to discover or brute force the secret key associated with that data</I><BR/><BR/>Again, this is not the case. In fact, the situation is much more grave theoretically.<BR/><BR/>Theoretically, it is not only possible for an adversary to cross from VM-guest to VM-guest (or VM-guest to VMM-Host), but under some circumstances -- it could be capable of doing so without an attack at the application layer (i.e. what you considered out of scope for this thread). It could also be possible at the VM-guest proposed-virtualized-hardware layer!<BR/><BR/>Imagine a scenario where ccNUMA hardware shares processors across processors and memory across memory. We don't know about the access control models available in vCPUs or multi-core processors. Could a hardware-to-software feature such as "Core Parking" enable leakage of data? It certainly could from an architectural risk analysis perspective! Not only that, but there could be good access controls in the VMM (e.g. sHype) that prevent VM-guest to X jumps, but that do not prevent the same jumps from these hardware or psuedo-hardware layers.<BR/><BR/>This is almost like VLANs all over again. I proved along with ISS in 1997 that an adversary could jump from one VLAN to another, as well as that there was data leakage between VLANs even outside of a default VLAN. How is this any different other than the fact that there's plenty more channels and object-reuse? VMM and VM security is a TCSEC nightmare.drehttps://www.blogger.com/profile/17414510788948258195noreply@blogger.com