1. If cloud computing is so great,
why isn’t everyone doing it?
• The cloud acts as a big black box, nothing inside the
cloud is visible to the clients
• Clients have no idea or control over what happens
inside a cloud
• Even if the cloud provider is honest, it can have
malicious system admins who can tamper with the
VMs and violate confidentiality and integrity
• Clouds are still subject to traditional data
confidentiality, integrity, availability, and privacy
issues, plus some additional attacks
1
2. Causes of Problems Associated
with Cloud Computing
• Most security problems stem from:
– Loss of control
– Lack of trust (mechanisms)
– Multi-tenancy
• These problems exist mainly in 3rd
party
management models
– Self-managed clouds still have security issues, but
not related to above
3. Loss of Control in the Cloud
• Consumer’s loss of control
– Data, applications, resources are located with
provider
– User identity management is handled by the cloud
– User access control rules, security policies and
enforcement are managed by the cloud provider
– Consumer relies on provider to ensure
• Data security and privacy
• Resource availability
• Monitoring and repairing of services/resources
4. Lack of Trust in the Cloud
• A brief deviation from the talk
– (But still related)
– Trusting a third party requires taking risks
• Defining trust and risk
– Opposite sides of the same coin (J. Camp)
– People only trust when it pays (Economist’s view)
– Need for trust arises only in risky situations
• Defunct third party management schemes
– Hard to balance trust and risk
– Is the cloud headed toward the same path?
5. Multi-tenancy Issues in the Cloud
• Conflict between tenants’ opposing goals
– Tenants share a pool of resources and have opposing goals
• How does multi-tenancy deal with conflict of interest?
– Can tenants get along together and ‘play nicely’ ?
– If they can’t, can we isolate them?
• How to provide separation between tenants?
• Cloud Computing brings new threats
– Multiple independent users share the same physical
infrastructure
– Thus an attacker can legitimately be in the same physical
machine as the target
6. Taxonomy of Fear
• Confidentiality
– Fear of loss of control over data
• Will the sensitive data stored on a cloud remain
confidential?
• Will cloud compromises leak confidential client data
– Will the cloud provider itself be honest and won’t
peek into the data?
• Integrity
– How do I know that the cloud provider is doing the
computations correctly?
– How do I ensure that the cloud provider really
stored my data without tampering with it?
6
From [5] www.cs.jhu.edu/~ragib/sp10/cs412
7. Taxonomy of Fear (cont.)
• Availability
– Will critical systems go down at the client, if the
provider is attacked in a Denial of Service attack?
– What happens if cloud provider goes out of
business?
– Would cloud scale well-enough?
– Often-voiced concern
• Although cloud providers argue their downtime compares
well with cloud user’s own data centers
7
From [5] www.cs.jhu.edu/~ragib/sp10/cs412
8. Taxonomy of Fear (cont.)
• Privacy issues raised via massive data mining
– Cloud now stores data from a lot of clients, and
can run data mining algorithms to get large
amounts of information on clients
• Increased attack surface
– Entity outside the organization now stores and
computes data, and so
– Attackers can now target the communication link
between cloud provider and client
– Cloud provider employees can be phished
8
From [5] www.cs.jhu.edu/~ragib/sp10/cs412
9. Taxonomy of Fear (cont.)
• Auditability and forensics (out of control of data)
– Difficult to audit data held outside organization in
a cloud
– Forensics also made difficult since now clients
don’t maintain data locally
• Legal quagmire and transitive trust issues
– Who is responsible for complying with regulations?
• e.g., SOX, HIPAA, GLBA ?
– If cloud provider subcontracts to third party
clouds, will the data still be secure?
9
From [5] www.cs.jhu.edu/~ragib/sp10/cs412
10. Taxonomy of Fear (cont.)
10
Cloud Computing is a security
nightmare and it can't be handled
in traditional ways.
John Chambers
CISCO CEO
• Security is one of the most difficult task to implement in
cloud computing.
– Different forms of attacks in the application side and
in the hardware components
• Attacks with catastrophic effects only needs one
security flaw
(http://www.exforsys.com/tutorials/cloud-computing/cloud-computing-security.html)
11. Threat Model
• A threat model helps in analyzing a security problem,
design mitigation strategies, and evaluate solutions
•Steps:
– Identify attackers, assets, threats and other
components
– Rank the threats
– Choose mitigation strategies
– Build solutions based on the strategies
11
From [5] www.cs.jhu.edu/~ragib/sp10/cs412
12. Threat Model
• Basic components
– Attacker modeling
• Choose what attacker to consider
– insider vs. outsider?
– single vs. collaborator?
• Attacker motivation and capabilities
– Attacker goals
– Vulnerabilities / threats
12
From [5] www.cs.jhu.edu/~ragib/sp10/cs412
13. What is the issue?
• The core issue here is the levels of trust
– Many cloud computing providers trust their
customers
– Each customer is physically commingling its data
with data from anybody else using the cloud while
logically and virtually you have your own space
– The way that the cloud provider implements
security is typically focused on they fact that
those outside of their cloud are evil, and those
inside are good.
• But what if those inside are also evil?
13
From [5] www.cs.jhu.edu/~ragib/sp10/cs412
14. Attacker Capability: Malicious Insiders
• At client
– Learn passwords/authentication information
– Gain control of the VMs
• At cloud provider
– Log client communication
– Can read unencrypted data
– Can possibly peek into VMs, or make copies of VMs
– Can monitor network communication, application
patterns
– Why?
• Gain information about client data
• Gain information on client behavior
• Sell the information or use itself
14
From [5] www.cs.jhu.edu/~ragib/sp10/cs412
15. Attacker Capability: Outside attacker
• What?
– Listen to network traffic (passive)
– Insert malicious traffic (active)
– Probe cloud structure (active)
– Launch DoS
• Goal?
– Intrusion
– Network analysis
– Man in the middle
– Cartography
15
From [5] www.cs.jhu.edu/~ragib/sp10/cs412
16. Challenges for the attacker
• How to find out where the target is located?
• How to be co-located with the target in the same
(physical) machine?
• How to gather information about the target?
16
From [5] www.cs.jhu.edu/~ragib/sp10/cs412
17. Part II: Security and Privacy Issues
in Cloud Computing - Big Picture
• Infrastructure Security
• Data Security and Storage
• Identity and Access Management (IAM)
• Privacy
• And more…
17
From [6] Cloud Security and Privacy by Mather and Kumaraswamy
19. The Network Level
• Ensuring confidentiality and integrity of your
organization’s data-in-transit to and from your public
cloud provider
• Ensuring proper access control (authentication,
authorization, and auditing) to whatever resources
you are using at your public cloud provider
• Ensuring availability of the Internet-facing resources
in a public cloud that are being used by your
organization, or have been assigned to your
organization by your public cloud providers
• Replacing the established model of network zones and
tiers with domains
19
From [6] Cloud Security and Privacy by Mather and Kumaraswamy
20. The Network Level - Mitigation
• Note that network-level risks exist regardless of
what aspects of “cloud computing” services are being
used
• The primary determination of risk level is therefore
not which *aaS is being used,
• But rather whether your organization intends to use
or is using a public, private, or hybrid cloud.
20
From [6] Cloud Security and Privacy by Mather and Kumaraswamy
21. The Host Level
• SaaS/PaaS
– Both the PaaS and SaaS platforms abstract and
hide the host OS from end users
– Host security responsibilities are transferred to
the CSP (Cloud Service Provider)
• You do not have to worry about protecting hosts
– However, as a customer, you still own the risk of
managing information hosted in the cloud services.
21
From [6] Cloud Security and Privacy by Mather and Kumaraswamy
22. The Host Level (cont.)
• IaaS Host Security
– Virtualization Software Security
• Hypervisor (also called Virtual Machine Manager (VMM)) security is
a key
– a small application that runs on top of the physical machine
H/W layer
– implements and manages the virtual CPU, virtual memory, event
channels, and memory shared by the resident VMs
– Also controls I/O and memory access to devices.
• Bigger problem in multitenant architectures
– Customer guest OS or Virtual Server Security
• The virtual instance of an OS
• Vulnerabilities have appeared in virtual instance of an OS
• e.g., VMWare, Xen, and Microsoft’s Virtual PC and Virtual Server
• Customers have full access to virtual servers.
22
From [6] Cloud Security and Privacy by Mather and Kumaraswamy
23. Case study: Amazon's EC2 infrastructure
• “Hey, You, Get Off of My Cloud: Exploring Information Leakage in
Third-Party Compute Clouds”
– Multiple VMs of different organizations with virtual boundaries
separating each VM can run within one physical server
– "virtual machines" still have internet protocol, or IP, addresses,
visible to anyone within the cloud.
– VMs located on the same physical server tend to have IP
addresses that are close to each other and are assigned at the
same time
– An attacker can set up lots of his own virtual machines, look at
their IP addresses, and figure out which one shares the same
physical resources as an intended target
– Once the malicious virtual machine is placed on the same server
as its target, it is possible to carefully monitor how access to
resources fluctuates and thereby potentially glean sensitive
information about the victim
23
24. Local Host Security
• Are local host machines part of the cloud infrastructure?
– Outside the security perimeter
– While cloud consumers worry about the security on the cloud
provider’s site, they may easily forget to harden their own
machines
• The lack of security of local devices can
– Provide a way for malicious services on the cloud to attack
local networks through these terminal devices
– Compromise the cloud and its resources for other users
25. Local Host Security (Cont.)
• With mobile devices, the threat may be even stronger
– Users misplace or have the device stolen from them
– Security mechanisms on handheld gadgets are often times
insufficient compared to say, a desktop computer
– Provides a potential attacker an easy avenue into a cloud
system.
– If a user relies mainly on a mobile device to access cloud data,
the threat to availability is also increased as mobile devices
malfunction or are lost
• Devices that access the cloud should have
– Strong authentication mechanisms
– Tamper-resistant mechanisms
– Strong isolation between applications
– Methods to trust the OS
– Cryptographic functionality when traffic confidentiality is
required
25
26. The Application Level
• DoS
• EDoS(Economic Denial of Sustainability)
– An attack against the billing model that underlies
the cost of providing a service with the goal of
bankrupting the service itself.
• End user security
• Who is responsible for Web application security in
the cloud?
• SaaS/PaaS/IaaS application security
• Customer-deployed application security
26
From [6] Cloud Security and Privacy by Mather and Kumaraswamy
27. Data Security and Storage
• Several aspects of data security, including:
– Data-in-transit
• Confidentiality + integrity using secured protocol
• Confidentiality with non-secured protocol and encryption
– Data-at-rest
• Generally, not encrypted , since data is commingled with
other users’ data
• Encryption if it is not associated with applications?
– But how about indexing and searching?
– Then homomorphic encryption vs. predicate
encryption?
– Processing of data, including multitenancy
• For any application to process data, not encrypted
27
From [6] Cloud Security and Privacy by Mather and Kumaraswamy
28. Data Security and Storage (cont.)
– Data lineage
• Knowing when and where the data was located w/i cloud is
important for audit/compliance purposes
• e.g., Amazon AWS
– Store <d1, t1, ex1.s3.amazonaws.com>
– Process <d2, t2, ec2.compute2.amazonaws.com>
– Restore <d3, t3, ex2.s3.amazonaws.com>
– Data provenance
• Computational accuracy (as well as data integrity)
• E.g., financial calculation: sum ((((2*3)*4)/6) -2) = $2.00 ?
– Correct : assuming US dollar
– How about dollars of different countries?
– Correct exchange rate?
28
Where is (or
What was th
How would a
info?
From [6] Cloud Security and Privacy by Mather and Kumaraswamy
29. Data Security and Storage
• Data remanence: refers to the residual representation of data that
remains even after attempts have been made to remove or erase the data.
– Inadvertent disclosure of sensitive information is possible
• Data security mitigation?
– Do not place any sensitive data in a public cloud
– Encrypted data is placed into the cloud?
• Provider data and its security: storage
– To the extent that quantities of data from many companies
are centralized, this collection can become an attractive
target for criminals
– Moreover, the physical security of the data center and the
trustworthiness of system administrators take on new
importance.
29
From [6] Cloud Security and Privacy by Mather and Kumaraswamy
30. Why IAM?
• Organization’s trust boundary will become dynamic and will move
beyond the control and will extend into the service provider
domain.
• Managing access for diverse user populations (employees,
contractors, partners, etc.)
• Increased demand for authentication
– personal, financial, medical data will now be hosted in the
cloud
– S/W applications hosted in the cloud requires access control
• Need for higher-assurance authentication
– authentication in the cloud may mean authentication outside
F/W
– Limits of password authentication
• Need for authentication from mobile devices
30
From [6] Cloud Security and Privacy by Mather and Kumaraswamy
31. IAM considerations
• The strength of authentication system should be
reasonably balanced with the need to protect the privacy
of the users of the system
– The system should allow strong claims to be
transmitted and verified w/o revealing more
information than is necessary for any given transaction
or connection within the service
• Case Study: S3 outage
– authentication service overload leading to unavailability
• 2 hours 2/15/08
• http://www.centernetworks.com/amazon-s3-downtime-
update
31
32. What is Privacy?
• The concept of privacy varies widely among (and
sometimes within) countries, cultures, and jurisdictions.
• It is shaped by public expectations and legal
interpretations; as such, a concise definition is elusive if
not impossible.
• Privacy rights or obligations are related to the collection,
use, disclosure, storage, and destruction of personal data
(or Personally Identifiable Information—PII).
• At the end of the day, privacy is about the accountability
of organizations to data subjects, as well as the
transparency to an organization’s practice around personal
information.
32
From [6] Cloud Security and Privacy by Mather and Kumaraswamy
33. What is the data life cycle?
33
• Personal information should be
managed as part of the data used by
the organization
• Protection of personal information
should consider the impact of the
cloud on each phase
From [6] Cloud Security and Privacy by Mather and Kumaraswamy
34. What Are the Key Privacy Concerns?
• Typically mix security and privacy
• Some considerations to be aware of:
– Storage
– Retention
– Destruction
– Auditing, monitoring and risk management
– Privacy breaches
– Who is responsible for protecting privacy?
34
From [6] Cloud Security and Privacy by Mather and Kumaraswamy
35. Storage
• Is it commingled with information from other
organizations that use the same CSP?
• The aggregation of data raises new privacy issues
– Some governments may decide to search through
data without necessarily notifying the data owner,
depending on where the data resides
• Whether the cloud provider itself has any right to
see and access customer data?
• Some services today track user behaviour for a range
of purposes, from sending targeted advertising to
improving services
35
From [6] Cloud Security and Privacy by Mather and Kumaraswamy
36. Retention
• How long is personal information (that is transferred
to the cloud) retained?
• Which retention policy governs the data?
• Does the organization own the data, or the CSP?
• Who enforces the retention policy in the cloud, and
how are exceptions to this policy (such as litigation
holds) managed?
36
From [6] Cloud Security and Privacy by Mather and Kumaraswamy
37. Destruction
• How does the cloud provider destroy PII at the end of the
retention period?
• How do organizations ensure that their PII is destroyed by
the CSP at the right point and is not available to other cloud
users?
• Cloud storage providers usually replicate the data across
multiple systems and sites—increased availability is one of
the benefits they provide.
– How do you know that the CSP didn’t retain additional
copies?
– Did the CSP really destroy the data, or just make it
inaccessible to the organization?
– Is the CSP keeping the information longer than necessary
so that it can mine the data for its own use?
37
From [6] Cloud Security and Privacy by Mather and Kumaraswamy
38. Auditing, monitoring and risk management
• How can organizations monitor their CSP and provide
assurance to relevant stakeholders that privacy
requirements are met when their PII is in the cloud?
• Are they regularly audited?
• What happens in the event of an incident?
• If business-critical processes are migrated to a cloud
computing model, internal security processes need to
evolve to allow multiple cloud providers to participate
in those processes, as needed.
– These include processes such as security
monitoring, auditing, forensics, incident response,
and business continuity
38
From [6] Cloud Security and Privacy by Mather and Kumaraswamy
39. Privacy breaches
• How do you know that a breach has occurred?
• How do you ensure that the CSP notifies you when a
breach occurs?
• Who is responsible for managing the breach
notification process (and costs associated with the
process)?
• If contracts include liability for breaches resulting
from negligence of the CSP?
– How is the contract enforced?
– How is it determined who is at fault?
39
From [6] Cloud Security and Privacy by Mather and Kumaraswamy
40. Who is responsible for protecting privacy?
• Data breaches have a cascading effect
• Full reliance on a third party to protect personal
data?
• In-depth understanding of responsible data
stewardship
• Organizations can transfer liability, but not
accountability
• Risk assessment and mitigation throughout the data
life cycle is critical.
• Many new risks and unknowns
– The overall complexity of privacy protection in the
cloud represents a bigger challenge.
40
e.g., Suppose a hacker breaks into Cloud Provider A and steals data from Company X.
Assume that the compromised server also contained data from Companies Y and Z.
• Who investigates this crime?
• Is it the Cloud Provider, even though Company X may fear that
the provider will try to absolve itself from responsibility?
• Is it Company X and, if so, does it have the right to see other data on that server,
including logs that may show access to the data of Companies Y and Z?
From [6] Cloud Security and Privacy by Mather and Kumaraswamy
41. Part III. Possible Solutions
• Minimize Lack of Trust
– Policy Language
– Certification
• Minimize Loss of Control
– Monitoring
– Utilizing different clouds
– Access control management
– Identity Management (IDM)
• Minimize Multi-tenancy
41
42. Security Issues in the Cloud
• In theory, minimizing any of the issues would help:
– Loss of Control
• Take back control
– Data and apps may still need to be on the cloud
– But can they be managed in some way by the consumer?
– Lack of trust
• Increase trust (mechanisms)
– Technology
– Policy, regulation
– Contracts (incentives): topic of a future talk
– Multi-tenancy
• Private cloud
– Takes away the reasons to use a cloud in the first place
• VPC: its still not a separate system
• Strong separation
44. Minimize Lack of Trust:
Policy Language
• Consumers have specific security needs but don’t
have a say-so in how they are handled
– What the heck is the provider doing for me?
– Currently consumers cannot dictate their
requirements to the provider (SLAs are one-sided)
• Standard language to convey one’s policies and
expectations
– Agreed upon and upheld by both parties
– Standard language for representing SLAs
– Can be used in a intra-cloud environment to realize
overarching security posture
45. Minimize Lack of Trust:
Policy Language (Cont.)
• Create policy language with the following
characteristics:
– Machine-understandable (or at least processable),
– Easy to combine/merge and compare
– Examples of policy statements are, “requires
isolation between VMs”, “requires geographical
isolation between VMs”, “requires physical
separation between other communities/tenants
that are in the same industry,” etc.
– Need a validation tool to check that the policy
created in the standard language correctly
reflects the policy creator’s intentions (i.e. that
the policy language is semantically equivalent to
the user’s intentions).
45
46. Minimize Lack of Trust: Certification
• Certification
– Some form of reputable, independent, comparable
assessment and description of security features
and assurance
– Sarbanes-Oxley, DIACAP, DISTCAP, etc (are they
sufficient for a cloud environment?)
• Risk assessment
– Performed by certified third parties
– Provides consumers with additional assurance
47. - MONITORING
- UTILIZING DIFFERENT CLOUDS
- ACCESS CONTROL MANAGEMENT
- IDENTITY MANAGEMENT (IDM)
Minimize Loss of Control
47
48. Minimize Loss of Control:
Monitoring
• Cloud consumer needs situational awareness for
critical applications
– When underlying components fail, what is the
effect of the failure to the mission logic
– What recovery measures can be taken (by provider
and consumer)
• Requires an application-specific run-time monitoring
and management tool for the consumer
– The cloud consumer and cloud provider have
different views of the system
– Enable both the provider and tenants to monitor
the components in the cloud that are under their
control
49. Minimize Loss of Control:
Monitoring (Cont.)
49
– Provide mechanisms that enable the provider to
act on attacks he can handle.
• infrastructure remapping (create new or move
existing fault domains)
• shutting down offending components or targets
(and assisting tenants with porting if necessary
• Repairs
– Provide mechanisms that enable the consumer to
act on attacks that he can handle (application-level
monitoring).
• RAdAC (Risk-adaptable Access Control)
• VM porting with remote attestation of target
physical host
• Provide ability to move the user’s application to
another cloud
50. Minimize Loss of Control:
Utilize Different Clouds
• The concept of ‘Don’t put all your eggs in one basket’
– Consumer may use services from different clouds through an
intra-cloud or multi-cloud architecture
– Propose a multi-cloud or intra-cloud architecture in which
consumers
• Spread the risk
• Increase redundancy (per-task or per-application)
• Increase chance of mission completion for critical applications
– Possible issues to consider:
• Policy incompatibility (combined, what is the overarching policy?)
• Data dependency between clouds
• Differing data semantics across clouds
• Knowing when to utilize the redundancy feature (monitoring
technology)
• Is it worth it to spread your sensitive data across multiple clouds?
– Redundancy could increase risk of exposure
51. Minimize Loss of Control:
Access Control
• Many possible layers of access control
– E.g. access to the cloud, access to servers, access to
services, access to databases (direct and queries via web
services), access to VMs, and access to objects within a VM
– Depending on the deployment model used, some of these will
be controlled by the provider and others by the consumer
• Regardless of deployment model, provider needs to
manage the user authentication and access control
procedures (to the cloud)
– Federated Identity Management: access control management
burden still lies with the provider
– Requires user to place a large amount of trust on the
provider in terms of security, management, and maintenance
of access control policies. This can be burdensome when
numerous users from different organizations with different
access control policies, are involved
52. Minimize Loss of Control:
Access Control (Cont.)
52
• Consumer-managed access control
– Consumer retains decision-making process to retain
some control, requiring less trust of the provider
(i.e. PDP is in consumer’s domain)
– Requires the client and provider to have a pre-
existing trust relationship, as well as a pre-
negotiated standard way of describing resources,
users, and access decisions between the cloud
provider and consumer. It also needs to be able to
guarantee that the provider will uphold the
consumer-side’s access decisions.
– Should be at least as secure as the traditional
access control model.
– Facebook and Google Apps do this to some degree,
but not enough control
– Applicability to privacy of patient health records
53. PEP
(intercepts all
resource
access requests
from all client
domains)
PDP
for cloud
resource
on Domain A
Cloud Consumer in Domain B
ACM
(XACML
policies)
.
.
.
resources
Cloud Provider in Domain A
IDP
1. Authn request
2. SAML Assertion
3. Resource request (XACML Request) + SAML assertion
4. Redirect to domain of resource owner
7. Send signed and encrypted ticket
5. Retrieve policy
for specified resource
6. Determine whether user can access
specified resource
7. Create ticket for grant/deny
8. Decrypt and verify signature
9. Retrieve capability from ticket
10. Grant or deny access based on capability
Minimize Loss of Control:
Access Control
54. Minimize Loss of Control: IDM
Motivation
User on Amazon
Cloud
1. Name
2. E-mail
3. Password
4. Billing Address
5. Shipping Address
6. Credit Card
1. Name
2. E-mail
3. Shipping Address
1. Name
2. Billing Address
3. Credit Card
1. Name
2. E-mail
3. Password
4. Billing Address
5. Shipping Address
6. Credit Card
1. Name
2. E-mail
3. Shipping Address
55. Minimize Loss of Control: IDM
Identity in the Cloud
User on Amazon
Cloud
1. Name
2. E-mail
3. Password
4. Billing Address
5. Shipping Address
6. Credit Card
1. Name
2. Billing Address
3. Credit Card
56. Minimize Loss of Control: IDM
Present IDMs
• IDM in traditional application-centric IDM model
– Each application keeps track of identifying information of its
users.
• Existing IDM Systems
– Microsoft Windows CardSpace [W. A. Alrodhan]
– OpenID [http://openid.net]
– PRIME [S. F. Hubner]
These systems require a trusted third party
trusted third party and
do not work on an untrusted host
untrusted host.
.
If Trusted Third Party is compromised, all the identifying information
of the users is also compromised
[Latest: AT&T iPad leak
AT&T iPad leak]
57. Minimize Loss of Control: IDM
Issues in Cloud Computing
• Cloud introduces several issues to IDM
– Users have multiple accounts
multiple accounts associated with multiple
multiple
service providers.
service providers.
– Lack of trust
• Use of Trusted Third Party is not an option
• Cloud hosts are untrusted
– Loss of control
• Collusion between Cloud Services
– Sharing sensitive identity information
between services can lead to undesirable
mapping of the identities to the user.
mapping of the identities to the user.
IDM in Cloud needs to be user-centric
58. Minimize Loss of Control: IDM
Goals of Proposed User-Centric IDM for the Cloud
1. Authenticate without disclosing identifying information
2. Ability to securely use a service while on an untrusted
host (VM on the cloud)
3. Minimal disclosure and minimized risk of disclosure
during communication between user and service provider
(Man in the Middle, Side Channel and Correlation
Attacks)
4. Independence of Trusted Third Party
59. Minimize Loss of Control: IDM
Approach - 1
• IDM Wallet:
– Use of AB scheme to protect PII from untrusted
hosts.
• Anonymous Identification:
– Use of Zero-knowledge proofing for authentication
of an entity without disclosing its identifier.
60. Minimize Loss of Control: IDM
Components of Active Bundle (Approach – 1)
• Identity data: Data used during authentication, getting
service, using service (i.e. SSN, Date of Birth).
• Disclosure policy: A set of rules for choosing Identity
data from a set of identities in IDM Wallet.
• Disclosure history: Used for logging and auditing
purposes.
• Negotiation policy: This is Anonymous Identification,
based on the Zero Knowledge Proofing.
• Virtual Machine: Code for protecting data on untrusted
hosts. It enforces the disclosure policies.
61. Minimize Loss of Control: IDM
Anonymous Identification (Approach – 1)
Anonymous Identification
(Shamir's approach for Credit Cards)
• IdP provides Encrypted Identity Information to the
user and SP.
• SP and User interact
• Both run IdP's public function on the certain bits of
the Encrypted data.
• Both exchange results and agree if it matches.
63. Minimize Loss of Control: IDM
Approach - 2
• Active Bundle scheme
Active Bundle scheme to protect PII from untrusted
hosts
• Predicates over encrypted data
Predicates over encrypted data to authenticate
without disclosing unencrypted identity data.
• Multi-party computing
Multi-party computing to be independent of a
trusted third party
64. Minimize Loss of Control: IDM
Usage Scenario (Approach – 2)
• Owner O encrypts Identity Data(PII) using algorithm
Encrypt and O’s public key PK. Encrypt outputs CT—the
encrypted PII.
• SP transforms his request for PII to a predicate
represented by function p.
• SP sends shares of p to the n parties who hold the
shares of MSK.
• n parties execute together KeyGen using PK, MSK, and p,
and return TKp to SP.
• SP calls the algorithm Query that takes as input PK, CT,
TKp and produces p(PII) which is the evaluation of the
predicate.
• The owner O is allowed to use the service only when the
predicate evaluates to “true”.
65. Minimize Loss of Control: IDM
Representation of identity information
for negotiation
Token/Pseudonym
Identity Information in clear plain text
Active Bundle
Active Bundle
66. Minimize Loss of Control: IDM
Motivation-Authentication Process using PII
Problem: Which information to disclose and how to
disclose it.
67. Proposed IDM:
Mechanisms
• [16] Protection of Identity Information in Cloud Computing
without Trusted Third Party - R. Ranchal, B. Bhargava, L.B.
Othmane, L. Lilien, A. Kim, M. Kang, Third International
Workshop on Dependable Network Computing and Mobile
Systems (DNCMS) in conjunction with 29th IEEE Symposium on
Reliable Distributed System (SRDS) 2010 (To Appear)
• [17] A User-Centric Approach for Privacy and Identity
Management in Cloud Computing - P. Angin, B. Bhargava, R.
Ranchal, N. Singh, L. Lilien, L.B. Othmane 29th IEEE Symposium
on Reliable Distributed System (SRDS) 2010 (To Appear)
• Active Bundle
• Anonymous Identification
• Computing Predicates with encrypted data
• Multi-Party Computing
• Selective Disclosure
68. Proposed IDM:
Active Bundle
• Active bundle
Active bundle (AB
AB)
– An encapsulating mechanism protecting
protecting data
data carried
within
within it
– Includes data
data
– Includes metadata
metadata used for managing confidentiality
• Both privacy of data and privacy of the whole AB
– Includes Virtual Machine (VM)
• performing a set of operations
operations
• protecting
protecting its confidentiality
confidentiality
69. Proposed IDM:
Active Bundle (Cont.)
• Active Bundles—Operations
Active Bundles—Operations
– Self-Integrity check
Self-Integrity check
E.g., Uses a hash function
– Evaporation/ Filtering
Evaporation/ Filtering
Self-destroys (a part of) AB’s sensitive data when
threatened with a disclosure
– Apoptosis
Apoptosis
Self-destructs AB’s completely
69
70. Proposed IDM:
Active Bundle Scheme
– Metadata:
Metadata:
• Access control policies
• Data integrity checks
• Dissemination policies
• Life duration
• ID of a trust server
• ID of a security server
• App-dependent information
• …
– Sensitive Data:
Sensitive Data:
• Identity
Information
• ...
– Virtual Machine
Virtual Machine
(algorithm):
(algorithm):
• Interprets metadata
• Checks active bundle integrity
• Enforces access and
dissemination control policies
• …
• E(Name)
• E(E-mail)
• E(Password)
• E(Shipping Address)
• E(Billing Address)
• E(Credit Card)
• …
* E( ) - Encrypted Information
71. Proposed IDM:
Anonymous Identification
User on Amazon
Cloud
1. E-mail
2. Password
1. E-mail
2. Password
User Request for service
Function f and number k
fk(E-mail, Password) = R
ZKP Interactive Protocol
Authenticated
• Use of Zero-knowledge proofing for user authentication
without disclosing its identifier.
72. Proposed IDM:
Interaction using Active Bundle
Active
Bundle (AB)
Security Services
Agent (SSA)
Active Bundle Services
User Application
Active Bundle Coordinator
Active Bundle
Creator
Directory
Facilitator
Active Bundle Destination
Trust Evaluation
Agent (TEA)
Audit Services
Agent (ASA)
Active Bundle
AB information
disclosure
74. Proposed IDM:
Multi-Party Computing
• To become independent of a trusted third party
• Multiple Services hold shares of the secret key
• Minimize the risk
• E(Name)
• E(Billing
Address)
• E(Credit Card)
Key Management Services
K’
1 K’
2 K’
3 K’
n
Predicate Request
* Decryption of information is handled by the Key Management services
75. Proposed IDM:
Multi-Party Computing
• To become independent of a trusted third party
• Multiple Services hold shares of the secret key
• Minimize the risk
• Name
• Billing Address
• Credit Card
Key Management Services
K’
1 K’
2 K’
3 K’
n
Predicate Reply*
*Age Verified
*Credit Card Verified
76. Proposed IDM:
Selective Disclosure
• E-mail
• Password
• E(Name)
• E(Shipping Address)
• E(Billing Address)
• E(Credit Card)
Selective disclosure*
• E(E-mail)
• E(Name)
• E(Shipping
Address)
• User Policies in the Active Bundle dictate dissemination
*e-bay shares the encrypted information based on the user policy
77. Proposed IDM:
Selective Disclosure
• E-mail
• Password
• E(Name)
• E(Shipping Address)
• E(Billing Address)
• E(Credit Card)
Selective disclosure*
• E-mail
• E(Name)
• E(Shipping
Address)
• User Policies in the Active Bundle dictate dissemination
Decryption handled by Multi-Party Computing as in the previous slides
78. Proposed IDM:
Selective Disclosure
• E-mail
• E(Name)
• E(Shipping Address)
Selective disclosure*
• E(Name)
• E(Shipping
Address)
*e-bay seller shares the encrypted information based on the user policy
79. Proposed IDM:
Selective Disclosure
• E-mail
• E(Name)
• E(Shipping Address)
Selective disclosure
• Name
• Shipping Address
• Decryption handled by Multi-Party Computing as in the previous slides
80. Proposed IDM:
Selective Disclosure
• E-mail
• E(Name)
• E(Shipping Address)
Selective disclosure
• Name
• Shipping Address
• Fed-Ex can now send the package to the user
81. Proposed IDM:
Identity in the Cloud
User on Amazon
Cloud
1. Name
2. E-mail
3. Password
4. Billing Address
5. Shipping Address
6. Credit Card
1. Name
2. Shipping Address
1. Name
2. Billing Address
3. Credit Card
1. E-mail
2. Password
1. E-mail
82. Proposed IDM:
Characteristics and Advantages
• Ability to use Identity data on untrusted hosts
• Self Integrity Check
• Integrity compromised- apoptosis or evaporation
• Data should not be on this host
• Independent of Third Party
– Prevents correlation attacks
• Establishes the trust of users in IDM
– Through putting the user in control of who has his data
– Identity is being used in the process of authentication,
negotiation, and data exchange.
• Minimal disclosure to the SP
– SP receives only necessary information.
83. Proposed IDM:
Conclusion & Future Work
• Problems with IDM in Cloud Computing
– Collusion of Identity Information
– Prohibited Untrusted Hosts
– Usage of Trusted Third Party
• Proposed Approaches
– IDM based on Anonymous Identification
– IDM based on Predicate over Encrypted data
• Future work
– Develop the prototype, conduct experiments and
evaluate the approach
85. Minimize Multi-tenancy
• Can’t really force the provider to accept less
tenants
– Can try to increase isolation between tenants
• Strong isolation techniques (VPC to some degree)
– C.f. VM Side channel attacks (T. Ristenpart et al.)
• QoS requirements need to be met
• Policy specification
– Can try to increase trust in the tenants
• Who’s the insider, where’s the security boundary? Who
can I trust?
• Use SLAs to enforce trusted behavior
86. Conclusion
• Cloud computing is sometimes viewed as a
reincarnation of the classic mainframe client-server
model
– However, resources are ubiquitous, scalable, highly
virtualized
– Contains all the traditional threats, as well as new ones
• In developing solutions to cloud computing security
issues it may be helpful to identify the problems and
approaches in terms of
– Loss of control
– Lack of trust
– Multi-tenancy problems
87. References
1. NIST (Authors: P. Mell and T. Grance), "The NIST Definition of Cloud Computing (ver. 15)," National Institute of Standards
and Technology, Information Technology Laboratory (October 7 2009).
2. J. McDermott, (2009) "Security Requirements for Virtualization in Cloud Computing," presented at the ACSAC Cloud Security
Workshop, Honolulu, Hawaii, USA, 2009.
3. J. Camp. (2001), “Trust and Risk in Internet Commerce,” MIT Press
4. T. Ristenpart et al. (2009) “Hey You Get Off My Cloud,” Proceedings of the 16th ACM conference on Computer and
communications security, Chicago, Illinois, USA
5. Security and Privacy in Cloud Computing, Dept. of CS at Johns Hopkins University.
www.cs.jhu.edu/~ragib/sp10/cs412
6. Cloud Security and Privacy: An Enterprise Perspective on Risks and Compliance by Tim Mather and Subra Kumaraswamy
7. Afraid of outside cloud attacks? You're missing the real threat.
http://www.infoworld.com/d/cloud-computing/afraid-outside-cloud-attacks-youre-missing-real-threat-894
8. Amazon downplays report highlighting vulnerabilities in its cloud service.
http://www.computerworld.com/s/article/9140074/Amazon_downplays_report_highlighting_vulnerabilities_in_its_cloud_ser
vice
9. Targeted Attacks Possible in the Cloud, Researchers Warn.
http://www.cio.com/article/506136/Targeted_Attacks_Possible_in_the_Cloud_Researchers_Warn
10. Vulnerability Seen in Amazon's Cloud-Computing by David Talbot.
http://www.cs.sunysb.edu/~sion/research/sion2009mitTR.pdf
11. Cloud Computing Security Considerations by Roger Halbheer and Doug Cavit. January 2010.
http://blogs.technet.com/b/rhalbheer/archive/2010/01/30/cloud-security-paper-looking-for-feedback.aspx
12. Security in Cloud Computing Overview.http://www.halbheer.info/security/2010/01/30/cloud-security-paper-looking-
for-feedback
13. Hey, You, Get Off of My Cloud: Exploring Information Leakage in Third-Party Compute Clouds by T. Ristenpart, E.
Tromer, H. Shacham and Stefan Savage. CCS’09
14. Cloud Computing Security. http://www.exforsys.com/tutorials/cloud-computing/cloud-computing-security.html
15. Update From Amazon Regarding Friday’s S3 Downtime by Allen Stern. Feb. 16, 2008.
http://www.centernetworks.com/amazon-s3-downtime-update
16. R. Ranchal, B. Bhargava, L.B. Othmane, L. Lilien, A. Kim, M. Kang, “Protection of Identity Information in Cloud Computing
without Trusted Third Party,“ Third International Workshop on Dependable Network Computing and Mobile Systems
(DNCMS) in conjunction with 29th IEEE Symposium on Reliable Distributed System (SRDS) 2010
17. P. Angin, B. Bhargava, R. Ranchal, N. Singh, L. Lilien, L.B. Othmane, “A User-Centric Approach for Privacy and Identity
Management in Cloud Computing,” 29th IEEE Symposium on Reliable Distributed System (SRDS) 2010
88. Other References for Cloud Security
• M. Armbrust, et al., "Above the Clouds: A Berkeley View of Cloud Computing," UC Berkeley
Reliable Adaptive Distributed Systems LaboratoryFebruary 10 2009.
• Cloud Security Alliance, "Security Guidance for Critical Areas of Focus in Cloud Computing,
ver. 2.1," 2009.
• M. Jensen, et al., "On Technical Security Issues in Cloud Computing," presented at the 2009
IEEE International Conference on Cloud Computing, Bangalore, India 2009.
• P. Mell and T. Grance, "Effectively and Securely Using the Cloud Computing Paradigm," ed:
National Institute of Standards and Technology, Information Technology Laboratory, 2009.
• N. Santos, et al., "Towards Trusted Cloud Computing," in Usenix 09 Hot Cloud Workshop,
San Diego, CA, 2009.
• R. G. Lennon, et al., "Best practices in cloud computing: designing for the cloud," presented
at the Proceeding of the 24th ACM SIGPLAN conference companion on Object oriented
programming systems languages and applications, Orlando, Florida, USA, 2009.
• P. Mell and T. Grance, "The NIST Definition of Cloud Computing (ver. 15)," National
Institute of Standards and Technology, Information Technology LaboratoryOctober 7
2009.
• C. Cachin, et al., "Trusting the cloud," SIGACT News, vol. 40, pp. 81-86, 2009.
• J. Heiser and M. Nicolett, "Assessing the Security Risks of Cloud Computing," Gartner
2008.
• A. Joch. (2009, June 18) Cloud Computing: Is It Secure Enough? Federal Computer Week.
Editor's Notes
#2:Data mobility: the ability to share data between cloud services
Where does data reside?
- out-of-state, out-of-country issues
Security Concerns for government in particular
FISMA
How to certify and accredit cloud computing providers under FISMA
(e.g. ISO 27001)
#4:Chiles and McMakin (1996) define trust as increasing one’s vulnerability to the risk of opportunistic behavior of another whose behavior is not under one’s control in a situation in which the costs of violating the trust are greater than the benefits of upholding the trust.
Trust here means mostly lack of accountability and verifiability
#5:Who are my neighbors? What is their objective? They present another facet of risk and trust requirements
#24:The lack of security of local devices can disrupt the consumer and also provide a way for malicious services on the cloud to attack local networks through these terminal devices. In today’s ubiquitous computing environment, the local host machine may well be a desktop computer, a portable laptop or mobile device. While cloud consumers worry about the security on the cloud provider’s site, they may easily forget to harden their own machines. The lack of security of a local host can compromise the cloud and its resources for other users. With mobile devices, the threat may be even stronger, as users misplace or have the device stolen from them. The security mechanisms on handheld gadgets are often times insufficient compared to say, a desktop computer, providing a potential attacker an easy avenue into a cloud system. If a user relies mainly on a mobile device to access cloud data, the threat to availability is also increased as mobile devices malfunction or are lost.
Devices that access the cloud should have strong authentication mechanisms, should be tamper-resistant, and have cryptographic functionality when traffic confidentiality is required. Since this places a part of the security burden onto the consumer, the provider may need to stipulate in its policy or SLA. New approaches to mobile cloud computing in which applications lie in the cloud as opposed to on a smart phone, enable more sophisticated security mechanisms.
Users connect to the cloud from their local host machines.
In particular, many secure cloud data storing technologies require users to generate master keys (used to encrypt data or session keys) and store them on the local machine. If a malicious service in the cloud can tamper with the local machine and access these keys, confidentiality of data stored in the cloud is at risk.
For example, a user’s computer can be a zombie that can be used to attack the cloud. Or it can contain malicious code that damages provider-side resources, affecting not only the provider, but all its other consumers as well.
In today’s battle space, new technologies enable war fighters to use handheld devices to gather data for analysis at command centers. Therefore, the durability and robustness of these devices is a major concern not only for cloud computing but for general-purpose military use as well.
Memory curtaining techniques for sensitive areas of memories such as those places where keys are stored (i.e. provides isolation of sensitive memory areas). Remote attestation or TPM type requirements.
#42:While VPC providers argue that they provide superior isolation, the fact of the matter is that your data is not a separate physical system: your data is still stored on actual servers along with other consumers’ data, but logically separated. If the actual server fails, your data and applications stored on it are lost. Also, there needs to be a high level of trust as to the degree of isolation provided.
#44:These SLAs typically state the high level policies of the provider (e.g. Will maintain uptime of 98%) and do not allow cloud consumers to dictate their requirements to the provider. COI clouds in particular have specific security policy requirements that must be met by the provider, due to the nature of COIs and the missions they are used for. These requirements need to be communicated to the provider and the provider needs to provide some way of stating that the requirements can be met. Cloud consumers and providers need a standard way of representing their security requirements and capabilities. Consumers also need a way to verify that the provided infrastructure and its purported security mechanisms meet the requirements stated in the consumer’s policy (proof of assertions). For example, if the consumer’s policy requires isolation of VMs, the provider can create an assertion statement that says it uses cache separation to support VM isolation.
#48:When the underlying components fail in the cloud, the effect of the failures to the mission logic needs to be known so that correct recovery measures can be performed. We propose an application-specific run-time monitoring and management tool. With this tool, the application logic can remain on the consumer’s host computer. This allows the consumer to centrally monitor all aspects of the application as well as data flow. Since all outputs from underlying services are sent to the application logic, any data incompatibility between services is not an issue. The capabilities of the run-time monitoring and management tool are as follows: 1) Enable application user to determine the status of the cloud resources that may be used to run the application (across multiple clouds), 2) Enable application user to determine the real-time security posture and situational awareness of the application, 3) Provide the application user with the ability to move user’s application (or part of it) to another site (other VM in same cloud or different cloud altogether), 4) Provide the application user with the ability to change the application logic on the fly, 5) Provide communicate capabilities with cloud providers. There are a few cloud vendors such as NimSoft [41] and Hyperic [42] that provide application-specific monitoring tools that provide some of the above functionality. These monitoring tools may be further enhanced or used in conjunction with other tools to provide the degree of monitoring required. However, any tool that is to be used for military purposes must also receive some type of accreditation and certification procedure.
#50:Differering data semantics example: does a data item labeled secret in one cloud have the same semantics as another piece of data also labeled secret in a different cloud?
#51:In cloud computing (as well as other systems), there are many possible layers of access control. For example, access to the cloud, access to servers, access to services, access to databases (direct and queries via web services), access to VMs, and access to objects within a VM. Depending on the deployment model used, some of these will be controlled by the provider and others by the consumer.
For example, Google Apps, a representative SaaS Cloud controls authentication and access to its applications, but users themselves can control access to their documents through the provided interface to the access control mechanism. In IaaS type approaches, the user can create accounts on its virtual machines and create access control lists for these users for services located on the VM.
Regardless of the deployment model, the provider needs to manage the user authentication and access control procedures (to the cloud). While some providers allow federated authentication – enabling the consumer-side to manage its users, the access control management burden still lies with the provider. This requires the user to place a large amount of trust on the provider in terms of security, management, and maintenance of access control policies. This can be burdensome when numerous users from different organizations with different access control policies, are involved. This proposal focuses on access control to the cloud. However, the concepts here could be applied to access control at any level, if deemed necessary. We propose a way for the consumer to manage the access control decision-making process to retain some control, requiring less trust of the provider.
Approach:
This approach requires the client and provider to have a pre-existing trust relationship, as well as a pre-negotiated standard way of describing resources, users, and access decisions between the cloud provider and consumer. It also needs to be able to guarantee that the provider will uphold the consumer-side’s access decisions. Furthermore, we need to show that this approach is at least as secure as the traditional access control model.
This approach requires the data owner to be involved in all requests. Therefore, frequent access scenarios should not use this method if traffic is a concern. However, many secure data outsourcing schemes require the user to grant keys/certificates to the query side, so that every time the user queries a database, the owner needs to be involved. Therefore, not much different than that so may not be a problem.