Attestation of Trust in Cloud Architecturesfor federal systems

Joel Wilbanks, Associate, Booz Allen Hamilton, CISSPChief Security Architect , Sr. Systems Engineer

Part 1 Defining the environment

Part 2 Trust in the cloud

Part 3 Government cloud security guidance

Part 4 Attested trust in cloud architectures

Overview

Cloud architectures permit the transference of responsibilities for data security outside the organization while leaving the data owner accountable for data security.

Organization’s and their accreditors don’t understand how to “gracefully lose control while maintaining accountability” and available COTS products have not evolved to provide this accountability.

Puts us in a weird middle ground where we try to make a square peg fit in a round hole.

Part 1: Current State – Security Perspective

Cloud Space Defined

Infrastructure ServicesInfrastructure Services

Cloud SoftwareCloud Software

Platform ServicesPlatform Services

Software ServicesSoftware Services

Storage Compute

Broker Services Mgnt

File Storage Compute

Data Cloud Mgnt

SaaS Data Security

Gen Purpose Database

Bus Intel Integration

Development and Testing

Financials Content Mgnt

CRM Sales

Social Nets Billing

Doc Mgnt Desktop

“Assured reliance on the character, ability, strength, or truth of someone or something.”

Human and System trust– To human relationships, within, and between social groups.– To systems it relates to a quality of failure

• Trusted, if failure negatively affects the security of the system• Trustworthy, if it will not fail

Social tendencies– Trust increases over time, given a consistent positive interaction– Trust diminishes at a very slow rate between positive interactions – The higher value of trust, the more egregious a transgression must be

to diminish it– Negative interactions outweigh positive ones– Indirect negative interactions will reduce trust– Discrete entities, external to a group, identified as having similar

attributes to the group, will regard existing members of the group with higher trust

Part 2: Defining Trust

Cloud Deployment Model Responsibility

If two people are responsible then no one is at fault.

- Murphy’s Law

Data Trust Context for Cloud Deployment Models

Private

Community

External

Hybrid

GovernancePolicy

ResponsibleAccountable

Custodian Interest

Architecture

Organization approved

Organization approved

Community approved

Community approved

Driven by market force

Driven by market force

Depends on the models

used

Depends on the models

used

Everyone in the

organization

Everyone in the

organization

Everyone in the

community

Everyone in the

community

Not everyone

Not everyone

Depends on governance

policy

Depends on governance

policy

Everyone has the same

Everyone has the same

Everyone has the same

Everyone has the same

Not everyone is the same

Not everyone is the same

Depends on the

architecture

Depends on the

architecture

Meets with organization

needs

Meets with organization

needs

Meets with community

needs

Meets with community

needs

Meets with market needs

Meets with market needs

Requirement Driven

Requirement Driven

“to consider apart from application to or association with a particular instance”– Language is abundant with abstractions

– Insight is an abstraction of data

Abstraction in technology is not new– Cloud architectures are an institualization of the traditional system’s

model at a macro scale• Legacy model: Hardware, Programming Language, Application• Cloud model: IaaS, PaaS, SaaS

Provides capabilities to consumers at a higher level without the burden of details

Abstraction

It can hide it. It can dilute it.

What does abstraction do to trust?

“the process of uniting : the quality or state of being united;” Consolidation is not new to technology Infrastructure enhancements have removed physical

boundaries– Network Devices, Protocols, Processing, Storage

What does consolidation to do trust?– Fundamentally nothing, as it only moves the guarantor or arbitrator to

another logical location in the system’s design

Consolidation

Physical boundaries are no longer sufficient arbitrators for or guarantors of trust in cloud system’s design.

Consolidation: The not so far off near future

Federal agencies are governed by– NIST 800-53

– FIPS

– Internal polices (ICD 500, DCID – 6/3, AR 25-1/2, etc…)

– OBM guidance and mandates

– GSA guidance and mandates

C&A Processes– Dealing with cloud architectures

There is a functional need for an Multi-Security Level (MSL) systems and at some point Multi-Level Security (MLS)– MSL utilizes data and system labeling to separate security domains

– MLS will execute multiple operations simultaneously at differing classification levels in a secure resource sharing method

Part 3: Federal security, policy, process, and MSL/MLS

It is good to obey all the rules when you're young, so you'll have the strength to break them when you're old. – Mark Twain

Nothing about cloud architectures should cause a full rewrite of governance policy– We only need to learn how to apply the existing policy to cloud

architectures

No agency can feasibly perform all security activities as prescribed or recommended by any governance policy, regulation, or industry best practice

Nor should they– The agency should understand and weigh its own risks then apply

appropriate controls

Risk based security

Cloud is another architecture for information processing Fundamental security requirements have not changed

– Secure the hardware

– Secure the data

– Monitor both

Cloud does require the fundamental security requirements to be restated as attestations of trust– From the hardware through to the software

– From the data producer/owner to the consumer

– From the actual –ilities to business polices

The challenge is that the methods and tools we use to apply security to systems are not fully compatible with the architecture of the cloud

There is fundamentally nothing new about security in the cloud

'cloud' isn't any different than what we've been doing since the dawn of the internet it just allows more people to be experts at something… Rob Fuller, security researcher, room362.com

Proposed Security Assessment & Authorization for U.S. Government Cloud Computing – Draft 0.96 Nov 2. 2010 by CIO Council– A request for input from industry, academic, and federal SMEs

• The overall FedRAMP architecture• Security Baseline• Introduction to continuous monitoring• Proposes Potential Assessment and Authorization Approach

Federal Cloud Security Guidance

The Federal Risk and Authorization Management Program (FedRAMP) is designed to solve the security authorization problems highlighted by cloud computing. - Exec Overview pg II

The Federal Risk and Authorization Management Program (FedRAMP) has been established to provide a standard approach to Assessing and Authorizing (A&A) cloud computing services and products.

Security Baseline is steeped in NIST 800-53R3 with additional guidance for cloud

In a nut shell it is a proposal to apply government C&A processes to CSPs.

Comments are open until December 2nd 2010 via www.fedramp.gov

FedRAMP

Each layer of the cloud architecture has independence via abstraction

Disparate understanding between stakeholders exacerbated by cloud architectures– Inability to assess and agree on business risk

– Ridged application of policy

Inability to provide attestations of trust– From the hardware through to the software

– From the data producer/owner to the consumer

– From the actual –ilities to business polices

Cloud architectures cannot yet deliver MSL/MLS but we can have systems that have a common trust

Mind the gap

An attested cloud architecture

By providing a value of trust from the hardware through the architecture to the software allows for each layer to ensure it is executing on a trusted platform

The hardware layer is trusted if it is executing the trusted code with the correct configuration in the correct manor– The hardware executes a hypervisor (VMM) then we need to ensure

that the correct hypervisor is functioning in the correct way– If the hardware control mechanisms are not content with the level of

trust shown by the hypervisor then it should not be executed The infrastructure layer shall provide the platform layer a value

that indicates an internal measurement of trust and the platform should make a business appropriate decision– Stop executing, inform the software layer, alert an administrator, etc…

The platform layer can build on the integrity value provided by the hardware for use in the software layers

Attestations of trust from the hardware through to the software

Assurance – To the data owner that the data is being handled in an appropriate

manor consistent with configured policies

– To the infrastructure owner that the hardware is executing as configured

– To the software (application) consumer that the underlying layers are executing on a known good platform

Trust in this context is regarded as integrity control for the loading of software at each layer and its related configuration

Provides a known good and provable state

What does attestation of trust provide us through the cloud architecture?

MTCEM (Multi-Tenancy Trusted Computing Environment Model)– National University of Defense Technology, Changsha, China

– Described in A Trusted Computing Environment Model in Cloud Architecture 11-14 July 2010

– Describes the use of a Trusted Platform Module’s (TPM) platform configuration registers (PCR), attestation identity key (AIK) and core root of trust for measurement (CRTM) to boot VirtualBox and execute CentOS virtual machines

– Set in the context of a multi-tenant environment

– Functional Prototype

Current work on hardware to software trust (1/2)

MTCEM Architecture

VMware, RSA, and Intel jointly presented at VMworld 2010: How to Attest Host Platform Security for Cloud Deployments (Aug 31, 2010)

Uses TPM(s) and Intel TXT technologies RSA showed a product concept to use trust and information

stored in the TPM for compliance tools to, such as enVision and Archer eGRC

Current work on hardware to software trust (2/2)

Intel/VMware/RSA’s Solution

The data owner has a need for assurances that – their data is going to be processed in a specific way

– where the data is processed, physical location

– only authorized users had access to the data

– auditing is preformed on who did access the data

– only authorized systems contained the data while in process

– auditing is preformed on the confidentiality and integrity of the data and any discrepancies are reported

– data is destroyed upon request

– access to the data is removed at the time of request

In some cases it is required that the trust and related metadata be transportable to other systems as the data is processed

Attestations of trust from the data owner to the consumer

Provenance, from the French provenir, "to come from", means the origin, or the source of something, or the history of the ownership or location of an object. - Oxford English Dictionary– Not a new concept, pedigree or lineage– Equal ramifications for tangible and in-tangible items

Nutshell for computing: To know where data came from as to assert its integrity and reliability

Can be used to provide assurances on how the data was processed and who consumed it

Provenance data can go very large for full capture of the manipulation of a single data item, performance can suffer– The granularity and frequency of collection must be options for the data

owner to decide

Authenticity and accessibility of the provenance data is also a concern

Data Provenance

Data provenance in SOA: security, reliability, and integrity. Tsai et al., Published 20 Nov 2007Restates some of the requirements for a provenance system (Groth et al.)

– Verifiability, Accountability, Reproducibility, Preservation, Scalability, Generality, Customizability

Provides a list of SOA services for a provenance system and notes issues with operational data (Hwang)Discusses data reliability and integrityProvides a granular categorization of provenance data capture, 7 levelsDiscusses multilevel data provenance security and notes that RBAC can also be appliedBriefly discusses using provenance information to determine the reliability of information and provides criteriaProvides a repeatable engineering process for architecting the use of and discovering provenance information in a system’s process

Data Provenance in Cloud - Research (1/3)

The EU Provenance Project (gridprovenance.org) Defined an architecture that provides recording, maintenance,

visualization, reasoning, and analysis of the documentation of the process that underpins the notion of provenance

Built for a SOA implementation and is complete with metadata schema definitions

Introduces the notion of p-assertations as a given element of the provenance representation

Inspects processing at the exchange from one service to the next Describes the concept of a provenance data store that can be

queried, updated, and modified to inform other services that can make use of provenance information from previous processing activities

Published the final research report on Dec 6, 2006

Data Provenance in Cloud - Research (2/3)

Trusted Computing Group (TCG) Practical Applications of Trusted Computing in the Cloud,

Jesus Molina, Sept 2010.– Points out you can verify then trust or just trust. Latter requires lawyers.

– Compares Trusted Clients, Trusted Storage, Trusted Networks with CSA guidance

– Discusses practical applications of trusted components

Expanded IF-MAP 2.0 Address a Broader Set of Applications, TCG, Nov 2010.– IF-MAP = Interface for Metadata Access Points

– Protocol to exchange network metadata about network security via an open standard to support standardized, dynamic data sharing through SOAP exchanges among a wide variety of networking and security components

Data Provenance in Cloud - Research (3/3)

All stakeholders in cloud architecture need a shared repository for access to information about how the environment is configured and performing

The granularity of information will differ depending on the stakeholder’s role

This shared repository will need to support traditional security requirements of its own such as AAA and operational requirements such as configurable retention polices

Attestations of trust of –illities to business policy

The cloud computing architecture does interesting things to trust

Federal agencies will benefit from any system that provides transitive trust in cloud system where validation of the system and processes provides trust

Federal security guidance will evolve with industry Security tools and practitioners will adapt (after the industry

chooses the right method to provide cloud security) Lots of research and experiments have been preformed over

the past six years and more mature solutions are emerging

Conclusions

Maturity of PaaS and SaaS to take advantage of trust attestations from the IaaS via technologies like TXT and TPM

Understanding the integration of existing federal information security programs (like PKI) into this type of cloud

Understanding provenance metadata management and portability issues (and how to do this across agency boundaries)

Development of a flexible but defined method to digitally represent provenance metadata

Development of a standard way to articulate risk for federal agencies in a digital representation that can be validate and enforce in the cloud environment

Integration of all of the above

Next Steps to an Attested Cloud

Questions?