Cloud Security. One Size Does Not Fit All

Transcription

1 Cloud Security One Size Does Not Fit All Matti Hiltunen Principal Member of Technical Staff Research AT&T Labs Research, Florham Park, NJ New Problems in Security in Cloud Computing NSF Workshop on Security for Cloud Computing Copyright 2012 AT&T Intellectual Property. All rights reserved.

2 Background Traditional business IT systems host variety of applications and data with varying security requirements: Confidentiality: Who is allowed to see what data, at what granularity, and when. Availability: How important it is that the data is always available (despite hardware and software failures). Integrity: How to ensure only authorized modifications to data. Regulatory requirements: Data retention periods, how long it must be retained, when it must be deleted; where can data be placed (e.g., which country); etc etc. Traditional IT systems protect different data and applications using a variety of techniques: Dedicated machines for highly confidential data - user account management, access control lists; rigorous process for determining who gets access to what; even air gap with the rest of the IT system. Firewalls/IDSs/antivirus/encryption/traffic monitoring/port scans/vulnerability scanning/etc depending on the application and data needs.

3 Cloud Cloud is homogeneous: limited customization of security properties (firewalls, access control) Cloud is opaque: where exactly are my VMs and data located data stored in the cloud may be widely distributed and automatically replicated how exactly the cloud provider provides the security/availability/etc properties Co-location: VMs of different security requirements co-located on the same physical machines Trust: The cloud user cannot protect data or applications from the cloud provider (must trust provider, hypervisor, and dom0.) Control: Thanks to the ease of use, employees may use cloud computing without the knowledge of the corporate security. Such cloud VM user is often also the administrator and may violate company security policies unknowingly. Result: Applications and data with low security requirements can be easily moved to the cloud but users must consider the risks/benefits with other apps/data.

4 Some challenges How to reduce the TCB provided by the cloud provider (hypervisor, dom0, cloud admins)? How to allow cloud users to customize their security services? How to guarantee that my data once stored in a cloud is really completely deleted from the cloud? How do I know my VM is hosted where I want it to be hosted (e.g., in Europe or US) and has not been outsourced to some other cloud provider in country X? How to ensure multiple levels of security policies in the client organization are enforced on any VMs created on behalf of the organization? Is it possible to the perform realistic confidential computations (secret algorithm and/or data) on untrusted cloud?

5 Important research directions Reducing the TCB by moving some of the hypervisor/dom0 functionality from the TCB to the cloud users. Nested VMs, decomposed hypervisor/dom0 Customizable (new) security mechanism: By cloud provider, cloud users, or third parties Anomaly detection, rootkit detection, firewalls, encryption, etc New security services that only the cloud provider can implement (based on holistic view of the whole cloud) Only pay (e.g., performance overhead) what you need. Improved transparency to cloud users (translucent cloud): Where is my data, where are my VMs Audit/proof/attestation of the provider security mechanisms (e.g., which firewall software and which rules) Audit/proof/attestation of actions (e.g., proof that all copies of data have been deleted) Automatic capturing of corporate security policies and translation to the cloud domain (who is authorized to do what, e.g., configuration of firewall rules, network configuration). Execution of encrypted algorithms, computation on encrypted data.