Attestation of Trust in Cloud Architectures for federal systems

1. Attestation of Trust in Cloud Architecturesfor federal systems Joel Wilbanks, Associate, Booz Allen Hamilton, CISSP Chief Security Architect , Sr. Systems Engineer

2. Overview Part 1 • Defining the environment Part 2 • Trust in the cloud Part 3 • Government cloud security guidance Part 4 • Attested trust in cloud architectures

3. Part 1: Current State – Security Perspective 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.

4. Cloud Space Defined Software Services Platform Services Infrastructure Services Cloud Software

5. Part 2: Defining Trust • “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

6. Cloud Deployment Model Responsibility If two people are responsible then no one is at fault. - Murphy’s Law

7. Data Trust Context for Cloud Deployment Models Governance Policy Responsible Accountable Custodian Interest Architecture Private Organization approved Everyone in the organization Everyone has the same Meets with organization needs Community Community approved Everyone in the community Everyone has the same Meets with community needs External Driven by market force Not everyone Not everyone is the same Meets with market needs Hybrid Depends on the models used Depends on governance policy Depends on the architecture Requirement Driven

8. Abstraction • “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

9. What does abstraction do to trust? • It can hide it. • It can dilute it.

10. Consolidation • “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

11. Consolidation: The not so far off near future • Physical boundaries are no longer sufficient arbitrators for or guarantors of trust in cloud system’s design.

12. Part 3: Federal security, policy, process, and MSL/MLS • 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 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

13. Risk based security • 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

14. There is fundamentally nothing new about security in the cloud • 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 '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

15. Federal Cloud Security Guidance • Proposed Security Assessment & Authorization for U.S. Government Cloud Computing – Draft 0.96Nov 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 The Federal Risk and Authorization Management Program (FedRAMP) is designed to solve the security authorization problems highlighted by cloud computing. - Exec Overview pg II

16. FedRAMP • 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

17. Mind the gap • 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

18. An attested cloud architecture

19. Attestations of trust from the hardware through to the software • 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

20. What does attestation of trust provide us through the cloud architecture? • 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

21. Current work on hardware to software trust (1/2) • 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

22. MTCEM Architecture

23. Current work on hardware to software trust (2/2) • 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

24. Intel/VMware/RSA’s Solution

25. Attestations of trust from the data owner to the consumer • 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

26. Data Provenance • 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

27. Data Provenance in Cloud - Research (1/3) Data provenance in SOA: security, reliability, and integrity. Tsai et al., Published 20 Nov 2007 • Restates 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 integrity • Provides a granular categorization of provenance data capture, 7 levels • Discusses multilevel data provenance security and notes that RBAC can also be applied • Briefly discusses using provenance information to determine the reliability of information and provides criteria • Provides a repeatable engineering process for architecting the use of and discovering provenance information in a system’s process

28. Data Provenance in Cloud - Research (2/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

29. Data Provenance in Cloud - Research (3/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

30. Attestations of trust of –illities to business policy • 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

31. Conclusions • 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

32. Next Steps to an Attested Cloud • 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

33. Questions?