Cloud-Trust A Cloud Security Model
Sponsored by the Institute for Information and Infrastructure Protection (I3P) and the Department of Homeland Security (DHS) Dan Gonzales, Jeremy Kaplan, Evan Saltzman, Zev Winkelman, and Dulani Woods
[email protected] May 2014
Objectives • Identify key elements of Cloud Computing System (CCS) design, standards, security features, and design patterns – Relevant to the security status of the CCS – i.e., a cloud reference model
• Identify CCS security risk metrics to assess the security status of CCSs
• Develop a security model that can be used to quantitatively assess the security status of a CCS and Cloud Service Providers (CSPs)
Gonzales-2 09/03
Outline
• Cloud reference model • Node classes • Attack paths • Cloud security controls and architectures • Cloud-Trust • Summary
Gonzales-3 09/03
Physical and Logical Layers for the IaaS Cloud
Guest OS
VM
Root | VMM HV
Hypervisor Kernel | Drivers | BIOS Physical Machine
PM
CPU
Cache
RAM
Disk
Net Gonzales-4 09/03
Segmenting Virtual Networks into Trust Zones
Gonzales-5 09/03
Cloud Reference Model
Gonzales-6 09/03
Outline
• Cloud reference model • Node classes • Attack paths • Cloud security controls and architectures • Cloud-Trust • Summary
Gonzales-7 09/03
CCS Node Classes • CCS contain a large number of hardware and software components – e.g., perhaps 10,000 or more servers
• Many will or should be identical – e.g., physical servers, hypervisors, VMs, etc.
• We define a class node for each distinct entity in the CCS – Each has unique functionality – Each will have specified by its parent trust zone
• Each node class represents its class in the Cloud-Trust Bayesian network model
Gonzales-8 09/03
CCS Reference Model Node Classes
Gonzales-9 09/03
Outline • Objectives • Cloud reference model • Node classes • Attack paths • Cloud security controls and architectures • Cloud-Trust • Summary
Gonzales-10 09/03
APT Target is the Same in All Attacks
Gonzales-11 09/03
Spanning the Attack Space • We use APT ingress paths to develop APT attack classes – – – –
Agency enclave Tenant B enclave CSP enclave Other enclaves
• Attack paths are comprised of vertices and arcs – A class node is associated with each vertex – A conditional probability is associated with each arc
• Each path maps to a probability of vulnerability or compromise associated with the path end point
Gonzales-12 09/03
APT Cloud Attack Stages
• Therefore, attack paths in the class node graph may have arcs with additional probability scores – Probability of APT surveillance – Probability of APT movement to target – co-residency
Gonzales-13 09/03
Outline
• Cloud reference model • Node classes • APT attack paths • Cloud security controls and architectures • Cloud-Trust • Summary
Gonzales-14 09/03
Information System Security System – IS3 • Every attack attempts to do something to the information system – e.g., makes changes, inserts malware, exfiltrates data…
• Thus every attack, in principle, leaves a trace on a fully monitored information system
– This enables detection of APTs for which there is no known software signature
• A modern information system is protected by both hardening its components and detecting attacks
• The IS3 is defined as the subset of the information system that protects it by hardening measures or by monitoring
• The system that combines IS3 information is often called the Security Incident Event Manager (SIEM)
– It is capable of fusing monitoring and config data from multiple sources Gonzales-15 09/03
Candidate Cloud IS3 Components Internet R1
TAP
• •
IPDS
IS3 components are indicated in Blue Agency TZ access controlled by MultiFactor authenticaion (MFA) (time limited token codes, X.509 certs, etc.) CSP tenant servers access controlled by MFA IAM
•
F1
R2 Agency A Secure Trust Zone Agency Users VMs
Agency Database Servers
Cloud IS3 and Management
Agency IS3 MFA IAM
Log Files
Central FAM Software appliance Dist
…
Cloud Mngt
Cloud Monitoring
Other Users
Signed Hypervisor w security extensions R 3v R3
SDN w/ virtual firewalls TPM enabled CPUs
Trusted CPUs with TPM, TxT, SGX, etc. Trusted Hypervisor with signed software components, verified at boot up with TPM NIST hardened BIOS, verified at boot up with TPM Virus scanning, IAVA, and FAM security appliances run inside agency VMs Integrated IS3 monitoring and logging (Agency and CSP). All logs available to Agency Gonzales-16 09/03
Cloud Architecture Security Controls
Gonzales-17 09/03
Outline
• Cloud reference model • Node classes • Attack paths • Cloud security controls and architectures • Cloud-Trust • Summary
Gonzales-18 09/03
Cloud-Trust Bayesian Network
Gonzales-19 09/03
Cloud-Trust Confidentiality and Integrity Metrics Let V^IN={A_i }_(i=1)^n be the sequence of random variables representing the nodes of V^IN such that binary random variable A_i denotes whether node i∈{1, …,n} has been accessed by an APT to infiltrate the gold data. !
Pr !! = 1 −
!
1 − Pr !! !! Pr !! !!!,!!!
=1−
1 − !!" × Pr !! !!!,!!!
Where a_ij = Pr(A_i│A_j ) is the probability that node i is accessed by the APT given that node j is accessed by the APT Then the probability of Gold data access is
a_ij≠a_ji Note the condition must hold In other words, the graph must be directed (acyclic) Therefore, we define two acyclic graphs for the complete APT attack – the ingress graph and the exfiltration graph Gonzales-20 09/03
Cloud-Trust Results for Cloud Architectures 1-4
• Architectures 1 and 2 are relatively insecure • Architectures 4 is the most secure because multiple security controls protect Agency data in all storage and processing states • MFA IAM • Gold data encrypted at rest, FAM • VMs encrypted during migration, etc. • Architecture 4 relatively insensitive to hypervisor vulnerability because signed HV and BIOS enable malware detection during reboot • assumes aggressive HV reboot CONOPs by CSP) Gonzales-21 09/03
Summary • We have developed a cloud security model – Cloud-Trust – that
provides quantitative assessments of IaaS cloud or CSP security status – Based on an acyclic graph that spans the space of all possible data ingress paths • Provides estimates of probability of – unauthorized access to high value data (confidentiality and integrity violations) – APT detection • Model depends on conditional probabilities that can be estimated using multiple methods – Security control functionality, APT literature, CVSS scores, etc. • Mathematical formalism completed for computing – Probability of high value data exfiltration – Work remains to span the space of all possible exfiltration exploits and associated conditional probability estimates Gonzales-22 09/03
Possible Extensions and Applications of Cloud-Trust • Apply Cloud-Trust to CSPs that comply with FEDRAMP • Provide confidential assessments of candidate CSP offerings • Extend Cloud-Trust to the data exfiltration attack stage – Estimate the probability of data exfiltration
• Extend Cloud-Trust to a full set of insider attacks • Evaluate the value of adding new or additional security controls of cloud architectures
Gonzales-23 09/03
Physical and Virtual Trust Zones • We define a trust zone (TZ) as a combination of network segmentation and identity and access management (IAM) controls – TZs define physical, logical, or virtual boundaries that must be compromised to achieve sensitive data access and exfiltration • Cloud TZs can be implemented using physical hardware, virtual firewalls and v-switches, or using both physical and virtual appliances • TZ security control examples: – IAM with usernames, passwords, and access control lists (ACLs) – Active Directory domain controllers – Federated trusts and multifactor authentication mechanisms using time limited codes and/or X.509 certificates. • IAM servers can use hardware based information when making access decisions in enterprise networks – e.g., devices without a pre-validated MAC address prevented from joining a network – Routers using ACLs and IP address white listing can deny network access to unauthorized devices – Above are examples of hardware based TZ enforcement
Gonzales-25 09/03
IaaS Cloud APT Attack Paths
Gonzales-26 09/03
