A lot of people have voiced concerns about the security and control of data within the cloud. Obviously organizations have significantly more control over data stored within their own infrastructure, but what about data hosted by a third party financial services organization that offers SaaS mobile banking or loan management services versus an implementation within a cloud computing provider's infrastructure? This article analyzes security concerns and the ability to control data in both of the service provider situations. This article will ONLY focus on the data storage aspect of this situation and will ignore things like vulnerabilities in developed applications. In future posts, I may expand the scope.
To set up the context in which these situations will be analyzed, we must first place each provider on equal footing. In this example, both service providers place cardholder data within storage over an encrypted connection (SSL/TLS). In addition, cardholder data is encrypted by the application before being placed within storage. It is assumed that the secret key for the encrypted data is stored on the application server using an appropriate framework such as Microsoft's DPAPI. This means that users with appropriate domain credentials and permissions for the application server may be able to access the secret key.
Threats
I have chosen to analyze data security issues based on potential threats to data within a provider's infrastructure. The following sections dig into each of these threats.
Data Loss or Destruction: Infrastructure Admin Deletes Data
A user with administrative privileges to the data storage infrastructure may maliciously or accidentally destroy the encrypted cardholder data.
Amazon S3 and Third Party Financial Services Provider: Viable Threat
This is a viable threat in both scenarios. A data administrator could delete data in each of these situations.
Data Loss or Destruction: One Data Center is Temporarily or Permanently Unavailable
A natural disaster, power failure, or other situation could render one data center unavailable.
Third Party Financial Services Provider:
My experience indicates that most of these providers utilize multiple data centers located in separate geographic locations within the United States. Depending on whether the additional data center is regarded as a cold, warm, or hot site, data may or may not be immediately available.
Amazon S3:
Data stored within Amazon S3 is stored and immediately available in at least two data centers [1] [2]. If one data center becomes unavailable, data will still be accessible to applications in the other data center.
All US Data Centers are Temporarily or Permanently Unavailable
If some kind of significant event affects the US's Internet infrastructure, multiple data centers could become unavailable.
Third Party Financial Services Provider:
Third party providers may or may not have data centers in locations outside of the US.
Amazon S3:
Data in Amazon S3 is not automatically backed up to data centers outside of the US; however as a mitigating control, organizations can choose to periodically backup data to Amazon S3 buckets within the UK [5].
Data Loss or Destruction: "Hacker" Destroys Data
A hacker could exploit a vulnerability within a system or network device that allows access to or control of data (remember, we are intentionally ignoring application level issues in this particular article). The attacker may choose to delete, destroy, or render that data inaccessible.
Third Party Financial Services Provider:
Customers rely on the third party providers to place appropriate access controls around data and to apply security patches to network and system devices in a timely manner.
Amazon S3:
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. Customers rely upon Amazon to apply patches to flaws identified within S3 or Amazon's API.
Unauthorized Data Access: Infrastructure Admin Accesses Data
A user with administrative privileges to the data storage infrastructure may attempt to access cardholder data for the purpose of financial gain.
Third Party Financial Services Provider:
Since the third party provider maintains the secret key for the encrypted data, it may be possible that an unauthorized individual may have domain privileges to access the secret key and the encrypted cardholder data. This would directly result in a compromise of customers' credit cards.
Amazon S3:
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.
Unauthorized Data Access: "Hacker" Accesses Data
A hacker could exploit a vulnerability within a system or network device that allows access to data (remember, we are intentionally ignoring application level issues in this particular article). The attacker may choose to read or steal that data for financial gain.
Third Party Financial Services Provider:
Customers rely on the third party providers to place appropriate controls around data, to apply security patches in a timely manner, and to encrypt data at rest and while in transit.
Amazon S3:
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.
Unauthorized Data Modification: Infrastructure Admin Modifies Data
A user with administrative privileges to the data storage infrastructure may attempt to modify cardholder data for the purpose of financial gain.
Third Party Financial Services Provider:
Since the third party provider maintains the secret key for the encrypted data, it may be possible that an unauthorized individual may have domain privileges to access the secret key and the encrypted cardholder data. This would allow an attacker to modify cardholder data or other assets within the data store.
Amazon S3:
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.
Unauthorized Data Modification: "Hacker" Modifies Data
A hacker could exploit a vulnerability within a system or network device that allows access to data (remember, we are intentionally ignoring application level issues in this particular article). The attacker may choose to modify that data for financial gain.
Third Party Financial Services Provider:
Customers rely on the third party providers to place appropriate controls around data, to apply security patches in a timely manner, and to encrypt data at rest and while in transit.
Amazon S3:
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. Customers rely upon Amazon to apply patches to flaws identified within S3 or Amazon's API.
Miscellaneous: Data Stored in Hostile Country
It is important for customers to ensure sensitive data or intellectual property is properly protected. Some countries do not have adequate laws or security standards in place to protect sensitive data or to restrict seizure of data by the government.
Third Party Financial Services Provider:
Third party providers typically are aware of these concerns and likely will not host data within a hostile country.
Amazon S3:
Customers of Amazon's S3 service may choose the country in which data is stored. Customers can choose to create a bucket in the US or in the UK [5].
Miscellaneous: Availability Issues
When data or services are unavailable, companies may lose revenue during the down time and may loose customers concerned with reliability of data or applications.
Third Party Financial Services Provider:
Availability and SLAs vary for each third party financial services providers.
Amazon S3:
The S3 storage system is highly available and stores data redundantly in multiple geographic locations. Amazon provides a SLA of 99.9% up time per month [4]; however they have had an issue or two in the past with availability [3].
Conclusions
To summarize the findings above, I created a table listing threats, mitigating factors, and risk levels.
(Click the image to enlarge)One major concern voiced regarding cloud computing is the control of data. Organizations do not want sensitive data accessed by service providers or disclosed/stolen due to security issues related to the provider's infrastructure. Surprisingly, the findings above show customers have a greater level of control over data stored within Amazon's S3 cloud storage service as compared to utilizing a third party financial services provider.
When analyzing threats to data security, findings show customers have the potential to implement stronger security controls around sensitive data stored in the cloud as compared to third party service providers. These finding my be misleading; however as many financial service providers invest heavily into developing strong information security programs, typically have a range of security experts in house, and engage in independent assessments to verify the security of networks, systems, and applications.
After considering all the data, I think the most important point to take away from this is actually not whether one solution is more secure than the other, but instead that data can be stored within the cloud in a secure and robust manner. Organizations should evaluate the choice to adopt cloud storage on the basis of whether it improves the business or generates additional revenue and should not make the decision based on fear of customer data being compromised or stolen.
References
- http://s3.amazonaws.com/aws_blog/AWS_Security_Whitepaper_2008_09.pdf
"Data stored in Amazon S3, Amazon SimpleDB, or Amazon Elastic Block Store is redundantly stored in multiple physical locations as a normal part of those services and at no additional charge."
- http://developer.amazonwebservices.com/connect/thread.jspa?threadID=11831&start=15&tstart=0
"I guess in my last message I neglected to clearly reiterate what we've said before, which is consistent with what Jeff said in his talk - we store multiple copies in multiple data centers. Yes, that means at least two. We don't ack a PUT until those multiple copies in multiple datacenters have been stored. The only exception to this is if a datacenter receiving your PUT is totally isolated from other datacenters due to a network issue. In that case, the multiple copies are stored in the single active datacenter, and then one or more of the copies are migrated to separate datacenters when connectivity is attained. This is a very rare occurance though."
- http://status.aws.amazon.com/s3-20080720.html
- http://aws.amazon.com/s3-sla/
- http://aws.amazon.com/s3/
"A bucket can be located in the United States or in Europe. All objects within the bucket will be stored in the bucket’s location, but the objects can be accessed from anywhere."
Posts
2 comments:
@ Nick:
You are missing a few key arguments against Amazon/GoGrid/Mosso/Azure/etc.
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...
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
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.
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
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.
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
Again, this is not the case. In fact, the situation is much more grave theoretically.
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!
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.
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.
Andre,
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.
Post a Comment