Trusted, Compliant Cloud: A Combined Solution for Trust in ...€¦ · establishes trust for secure...

Solution Blueprint Intel® Cloud BuildersTrusted, Compliant Cloud

Executive Summary

Enterprise is under constant pressure to reduce costs and yet increase value through innovation, agility, and competitiveness. To achieve these goals, business-es are rapidly moving to cloud infrastructures: public, private, and hybrid. Overall, this enables enterprise to achieve greater operational flexibility and agility. It also creates new challenges for security, privacy, and compliance.

Cloud infrastructures are built to be highly agile and dynamically assign resources to process workloads. This includes moving workloads across geographic boundar-ies, such as between data centers, or even between data centers on different con-tinents. Because of this, cloud computing introduces new security risks and raises issues with visibility and control of both manual administrator (admin) actions as well as with automated / virtualized tasks.

Intel, VMware, and HyTrust have collaborated extensively to create a solution that establishes trust for secure operations in the cloud. This solution resolves critical security challenges, provides a trusted foundation for virtualized workloads and storage; and enables compliance for data-location and privacy.

Trusted, Compliant Cloud: A Combined Solution for Trust in the Cloud, Provided by Intel®, HyTrust*, and VMware*

Authors:Martin Guttmann

Principal Solution ArchitectISG – Data Center WW Group Intel

Tamer ElsharnoubySolution Architect

ISG – Data Center WW Group Intel

2Solution Blueprint | A Combined Solution for Trust in the Cloud, Provided by Intel®, HyTrust*, and VMware*

Table of Contents

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Introduction to a Trusted, Compliant Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Architecture of a Trusted Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Blueprint for a Trusted Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Security Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 The Security Challenge of Change: The Agile, Flexible Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Security in The Virtual Cloud Requires New Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Establishing Trust in a Virtualized Cloud Via Intel Txt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Establishing the Root of Trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Performing Trust Attestation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Intel Txt: An Inherently Protected Trust Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Extending Trust, Security, and Compliance with HTCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Management Console and Appliance Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Web-Based Management Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 HTCC Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 HTCC Uses Same GUI as VMware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 HTCC Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Integration of Active Directory with HTCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Create Ad Groups and Users for HTCC Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Detailed Logging for Evidence-Based Audits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Extending Data Security with HTDC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 HTDC Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 HTDC Encryption Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 HTDC Encryption Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 HyTrust KeyControl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 HyTrust KeyControl Policy Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Decrypting Workloads and Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Administrative Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 ThreeRole-BasedDefinitionsforAdmins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Security Admins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Domain Admins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Cloud Admins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Establish Trusted Compute Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Geo-Location Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 DefineandAssignPolicyTags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Enable Data Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Enforce Boundary Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Use Geo-Fencing to Create Sub-Groups Within a Boundary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Compliance Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Best-Practice Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 HyTrust Integration with McAfee* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21


HTCCandHTDCSolutionsforSpecificUseCases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Sampling of Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Use Cases: Dynamic Root of Trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Use Cases: Platform Attestation with Intel TXT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Use Cases: Trusted Compute Pools and Secure Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Use Cases: Virtual Server Volume Decryption Based on Host Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Use Cases: Boundary Control With Geo-Tagging and Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Use Cases: KeyControl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Use Cases: Auditing and Alerting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22System and Solutions Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Hardware and Software Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Prerequisites for Overall Solution Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Server Requirements for Servers wth Intel® Xeon® Processors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Intel TXT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 TPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Upgrading An Existing Server to Support TPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Prerequisites for HTCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Server Requirements for HTCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Server Requirements for HTDC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Software Requirements for HTCC and HTDC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 PXE Server Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Requirements Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Deployment Worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Deploying The Solution Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Enable and Set Up Intel TXT and the TPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Enable Intel Txt and TPM Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Install and Set Up the Hypervisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Install HTCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Install HTDC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Test Connectivity and Compute Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 ConfigureforHighAvailability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Provision Policy Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Plan Your Policy Tags Carefully . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 DefinePolicyTagsinHTCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Assign Policy Tags to Host in HTCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Provision Policy Tags to a Physical Host, Via PXE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Provision a Host with Policy Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Provisioning Hosts with Policy Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Rules Enabled by Policy Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Use Policy Tags as Constraints to a Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 How Policy Tags are Evaluated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Appendix A: For More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Additional Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Intel Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34


TPM Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35VMware Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35HyTrust Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Documentation for Trust and Security Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35McAfee Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35For More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Appendix B: Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

List of Figures

Figure 1 . Elements of a Trusted, Virtualized Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Figure 2 . Intel® Trusted Execution Technology (Intel® TXT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Figure 3 . Architecture of a Trusted Platform Module (TPM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Figure 4 . Architecture of Trust Attestation in a Virtualized Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Figure 5 . HyTrust CloudControl* Virtual Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Figure 6 . HyTrust CloudControl* Provides Access Control to VMware Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Figure 7 . Authentication and Authorization Process for Virtual Administrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Figure8.HyTrustCloudControl*AllowsforRole-BasedDefinitionsofAdministrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Figure 9 . Trusted Compute Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Figure 10 . Hardware-Based Policy Tagging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Figure 11 . Data Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Figure 12 . Boundary Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Figure 13 . Geo-Fencing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Figure14.WorkflowtoEnableandActivateIntel®TrustedExecutionTechnologyandtheTPM . . . . . . . . . . . . . . . . . . . . . . . . . 26

Above: Host Not Yet Provisioned with Policy Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

List of Tables

Table 1 . Security Requirements and Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Table 2 . Compute Requirements for Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Table 3 . Server Requirements for HTCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Table 4 . Server Requirements for HTDC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Table 5 . HTCC and HTDC Software and OS Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Table 6 .Sample Deployment Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Table 7 . Sample Deployment Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

SAMPLE: HyTrust High Availability Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Checklist: HyTrust High Availability Checklist 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Checklist: HyTrust High Availability Checklist 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29


Preface

Welcome to the Intel blueprint for a trusted, compliant cloud.

This blueprint is the result of an exten-sive collaboration by Intel, VMware,* and HyTrust* to develop and describe the process for establishing a proof of concept (PoC) or full deployment of a trusted, virtualized cloud.

This blueprint will help you under-stand the issues involved in setting up a trusted cloud. This blueprint will also help you understand how to take full advantage of the capabilities enabled by a hardware-based chain of trust.

A trusted cloud is based on these criti-cal technologies:

• Intel® Trusted Execution Technology (Intel® TXT)

• Trusted Platform Module (TPM), v1.2

• VMware vCenter* management server

• VMware ESXi* hypervisor (the bare-metal OS and virtual machine moni-tor, or VMM)

• HyTrust CloudControl (HTCC)*

• HyTrust DataControl (HTDC)*

Terminology

This blueprint document uses these common terms:

• Intel TXT: Intel Trusted Execution Technology.

• TPM: Trusted platform module v1.2.

• VM: Virtual machine.

• Admin: Administrator. Unless other-wise noted, “admin” refers to admin-istrators working at the virtualization layer.

• Hypervisor: VMware ESXi.

• Management Server: VMware vCenter, which manages your virtual workloads.

• Virtual Appliance: HyTrust manage-ment application, such as HTCC or HTDC.

• Policy Tag: Hardware-based policy tag. Unless otherwise noted, “policy tag” refers only to hardware-based policy (or “asset”) tags.

Other terms are defined in the acronyms appendix.

Introduction to a Trusted, Compliant Cloud

Overview

Enterprise is under constant pressure to reduce costs. At the same time, they must increase value through innova-tion, agility, and competitiveness. To achieve both sets of goals, businesses are rapidly moving to cloud infra-structures: public, private, and hybrid. Overall, this enables enterprise to achieve greater operational flexibility and agility. However, it also creates new challenges for security, privacy, and compliance.

This section explains trust and security challenges. This section then shows how today’s technologies can address and resolve these challenges with a seamless, end-to-end solution deliv-ered by Intel®, VMware,* and HyTrust.*

Architecture of a Trusted Cloud

Cloud infrastructures are built to be highly agile and flexible in their use of compute and storage resources. They are specifically designed to dynamically assign resources to process workloads. For example, in the cloud, virtualized machines and workloads can dynami-cally move between servers to meet performance needs as business and user demands change. This includes moving workloads and data across geographic boundaries as server pools become available, including moving workloads between data centers, or even between data centers on different continents.

The inherent agility of cloud computing introduces new security risks. This agil-ity also raises issues with visibility and control of both manual administrator (admin) actions, as well as with auto-mated / virtualized tasks.

To address these new risks, Intel, VM-ware, and HyTrust have collaborated extensively, creating a solution that establishes trust for secure operations in the cloud. The combined solution re-solves security challenges and provides a trusted foundation for virtualized workloads and storage. This solution stack also enables use cases that tradi-tional security solutions cannot address in the virtualized cloud, including geo-location, privacy, and compliance.

The combined solution stack from Intel, VMware, and HyTrust includes:

• Intel® TXT

• Trusted Platform Module (TPM), v1.2

• VMware vCenter* management server, 5.5 or later

• VMware ESXi* hypervisor (the OS and virtual machine monitor, or VMM), v5.5 or later

• HyTrust CloudControl (HTCC)*

• HyTrust DataControl (HTDC)*

A trusted cloud solution delivers many benefits over a generic cloud:

• Trusted Platforms help assure that workload run on trusted platforms enabled with a hardware-roof-of trust.

• Improveefficiency by automating many trust- and security-related tasks, including evidence-based au-dits and reporting for compliance.

• Increase agility, to respond more quickly to dynamically changing workload demands.

• Reduce costs, by streamlining IT


FIGURE 1. Elements of a Trusted, Virtualized Cloud

budgets and improving management of computing resources to meet your actual needs when those needs arise.

• Increase visibility, of both authorized and unauthorized activity.

• Increaseflexibility, by offloading computing resources to the cloud, and enabling more focus on your business.

With trust-based cloud computing, you can deploy workloads in the most appropriate security environment, and take advantage of important security concepts. These include:

• Higher performance and availability requirements.

• System utilization.

• Security zones, based on boundary definitions in the system and policy tags assigned to individual hosts.

• Systems trust and security status.

• Geo-location information, which al-

lows you to identify the actual, physi-cal location of each host.

Blueprint for a Trusted Cloud

Security policies and compliance regulations are having an increasingly significant impact on enterprise. In particular, enterprise must know at all times where their data and workloads are located. In many cases, in order to comply with regulations, enterprise must keep workloads and data within a specified geographic boundary. En-terprise must also be able to prove that workloads and data are actually being processed within that boundary, and that they remain secure even if a breach occurs.

Traditional IT security solutions remain the backbone of basic enterprise secu-rity. However, these solutions are not as effective in the virtualized environment of the cloud. This is especially true when trying to secure the flexible, agile, and dynamic movement of virtualized workloads and data between hosts, in

order to meet rapidly changing re-source demands.

This blueprint document provides a new approach for creating the founda-tion of a trusted cloud. This trust foun-dation provides security controls that allow you to create and enforce policies at the virtual workload level. This solu-tion stack not only delivers effective cloud security, but also allows you to better comply with rules for security, governance, audit, and management, while still protecting sensitive data.

This blueprint highlights the functional capabilities of systems and solutions for a trusted cloud:

• Address in-house security, trust, and audit requirements.

• Create and enforce policies.

• Establish trust in a virtualized infra-structure.

• Meet compliance mandates for virtu-


TABLE 1. Security Requirements and Challenges

REQUIREMENTS CHALLENGES BENEFITS

• Software-based orchestration of workloads

• Dynamic allocation of virtual workloads

• Rapid provisioning of hosts

• Unrestricted workload migration

• Security’s limited visibility and control of virtual workloads in a virtualized network

• New security risks

• Migration of sensitive data and business-critical applications outside the view of security team

• Dynamic resource allocation

• Reduced CAPEX and OPEX

• Flexibility

alized computing and storage in the cloud.

This blueprint also describes sample use cases and architectures, along with system and solution deployments. This includes implementations that restrict sensitive data to a specified location (such as data location, boundary con-trol, and geo-fencing use cases).

In addition, this solution provides strong assurances that access to sensitive data is controlled and audi-tied. Requests to access, relocate, or change data are intercepted by a virtual appliance (HyTrust CloudControl, or HTCC), which can allow or refuse admin actions based on your policies and the trust status of the hosts. HTCC logs all requests, whether they are approved or refused. This allows enterprise to meet internal security policies, as well as meet external compliance laws, rules, and regulations.

Security Challenges

Effective governance of the virtual infrastructure for sensitive workloads and data is as critical as governance of the physical data center. The chal-lenge is meeting those requirements in the virtual cloud, with evidence-based management, auditing, and reporting.

The Security Challenge of Change: The Agile, Flexible Cloud

Server virtualization allows IT to do rapid provisioning, perform software-based orchestration, and dynamically move virtual workloads -- including

sensitive workloads -- based on user demands. In other words, in the cloud, server virtualization adds the challenge of constant change. The issue with that? Change is the enemy of strong security.

The main challenge comes from mov-ing business-critical applications and sensitive data outside the confines of the data center. In the cloud, workloads and data can move even beyond the visibility and management of the secu-rity team. Addressing security issues in the cloud -- such as data location, boundary control, privacy, and protec-tion issues -- require that admins have specialized knowledge in several areas:

• Compliance with in-house security regulations, as well as with industry, government, and other rules and regulations.

• Effective security management for a virtualized systems and network.

• Trust management.

• Automated enforcement of migration policies for virtual workloads.

• Automated enforcement of data loca-tion policies.

• Auditing.

Security in the Virtual Cloud Requires New Solutions

Enterprise is responsible for deploy-ing appropriate, effective solutions that ensure security to help prevent breaches of the sensitive data and workloads they handle. This includes keeping certain types of data within

defined geographic areas or borders. A critical challenge in this is that security management of virtualization and cloud computing is different from traditional IT data-center security operations.

In today’s clouds, effective manage-ment and security for virtualized cloud infrastructure and environments re-quires cloud-relevant security-enabled systems and cloud-aware solutions. New types of virtual security controls are needed to allow organizations to create and enforce policies at the virtual workload level. These controls must enable IT to define, monitor, and enforce security, trust, and regulatory compliance, including forensic-level audits, even in this virtualized structure. In addition, the solutions must provide trust capabilities, such as trusted boot, security management, and enforcement of geo-location requirements.

The solution stack of Intel TXT, TPM, VMware, HTCC, and HyTrust DataCon-trol (HTDC), deliver leading concepts and capabilities, such as trust attesta-tion and trusted compute pools. With those capabilities, the solution stack al-lows IT to determine the actual, physi-cal location of each server, and manage the workloads allowed on those servers based on their location and trusted status.

Establishing Trust in a Virtualized


Cloud Via Intel TXT

In a VMware-based cloud, HTCC and HTDC provide capabilities for visibility of admin actions, workload manage-ment, data security, and compliance. The effectiveness of these capabilities depends on being able to trust the un-derlying host system: Is the host in the location you expect? Is the host running an expected/ authorized BIOS and hypervisor -- or has it been compro-mised? Is your data crossing geographic boundaries that will put you out of compliance?

HTCC answers those and other ques-tions by taking advantage of a chain of trust built from the hardware level up.

Establishing the Root of Trust

A fundamental aspect of any cloud pro-vider’s solution is being able to prove to enterprise that workloads are running on platforms that can be trusted and secured. If the host cannot be trusted, the workload itself is at risk. In the same way, if you cannot trust the host, you

cannot be sure that the host is in the location it claims, or that you could risk authorizing decryption of sensitive data on that host. Trust in your hosts is the foundation of a trusted cloud.

In the cloud, the root of trust is estab-lished at the hardware level by Intel TXT. Intel TXT does this by measur-ing the host’s launch environment as it boots -- every time the host boots. Intel TXT measurements include the host’s BIOS, OS, and hypervisor; as well as the host’s VMkernel and a subset of the loaded modules (VMware vSphere installation bundles, or VIBs).

Intel TXT stores the measurements of the boot environment in the host’s TPM Platform Configuration Register (PCR). Each time the host boots, Intel TXT re-measures the entire launch environ-ment. In other words, with Intel TXT, the host re-measures and re-establish-es the status of its own configuration every time it boots.

Figures 2 and 3 (next page) show ele-

FIGURE 2. Intel® Trusted Execution Technology (Intel® TXT)

ments of Intel TXT and the architecture of a TPM.

Performing Trust Attestation

In order to attest to the trust of a host, you must first know whether it is in an authorized configuration. One of the best ways to do this is to compare the host configuration against a known or expected (white list) of authorized configurations.

When Intel TXT stores its measure-ments in the TPM, that information becomes available to HTCC via its trust attestation service, or TAS. The TAS cryptographically compares the Intel TXT measurements of the boot BIOS, OS, policy tags, and other host components against a database of known-good values (the TAS white list). If the measurements of the host’s latest launch environment match the expected values mapped to that host in the white list, the system is labeled “trusted” in the HTCC database. If the launch measurements do not match the expected values in the white list,


FIGURE 3. Architecture of a Trusted Platform Module (TPM)

the system is labeled “untrusted,” and can be flagged for maintenance or al-loweonly commodity or other low-level workloads.

For example, suppose a host has been patched since its last boot, and the TAS white list updated with the new con-figuration. When the host reboots, Intel TXT measures its boot environment again, as usual. If these new measure-ments match the expected values updated in the TAS white list, it is a good indicator that the patches were installed correctly. If the launch mea-surements do not match the expected values in the white list, then the differ-ence could indicate different issues. For example, the host might not have been patched correctly, the host could have been compromised by malware, or a user could have installed unauthorized software on the system.

Regardless of the reason for the differ-ence, if the host changes to an unau-thorized configuration, its launch mea-surements will not match the expected

measurements in the white list. Also, if the white list itself is compromised, the white list will not match the host’s launch measurements -- and again, the host will be labeled untrusted.

Note: The TAS can use Intel TXT infor-mation to establish trust on HTCC-man-aged ESXi hosts or keyboard-video-mouse (KVM) hosts.

HTCC can use Intel TXT information to label a host as trusted or untrusted (see Figure 4). Your HTCC and HTDC policies can then use that trust status to allow or refuse admin actions. For example, HTCC could allow the migration of a workload to a trusted host; while HTDC could refuse to decrypt data on an untrusted host. Your policies can also trigger other actions, such as removing an untrusted host for maintenance, no-tifying an admin that action is needed, and so on.

Note: By default, HTCC uses the TAS to check the trust status of the host once a day.

The value of trust attestation is that it allows a program or platform to au-thenticate itself and store its authenti-cation information in a secured location (the TPM). Trust attestation allows a host to make reliable statements about its own pre-launch environment and boot components even in a distributed system (such as a virtualized cloud).

Trust attestation is a critical component for a trusted cloud. Working together, trust attestation and policy tags can improve workload scheduling, verify platform integrity, schedule remedia-tion as required, improve automated reporting, and increase compliance in both public and private clouds.

Intel TXT: An Inherently Protected Trust Process

With Intel TXT, you have an inherently trusted and highly secure execution process for measuring and securing a host’s launch environment.

To maintain the integrity of its mea-surements, Intel TXT uses a combina-tion of hardware and software. This in-cludes Intel® Xeon® processors, chipset, I/O subsystem, Intel TXT-enabled BIOS, authenticated code modules (ACM), and other platform components. Also, hard-ware support for Intel TXT and the root of trust is fully tested and supported by VMware and its OEM partners.

For example, a hacker or malware might try to subvert and control the outcome of the trust attestation process. How-ever, because trust attestation is based in hardware, attestation helps prevent:

• Spoofing the trust agent to attain a fake TPM quote.

• Compromising the trust attestation service to subvert signed content.

• Spoofing the trust attestation service to fake a signed content.

• Hacking the white lists.

• Compromising the data on the net-work and repositories.


• Once your servers are Intel TXT-enabled, Intel TXT measurements are enabled by default.

Xtending Trust, Security, and Compliance with HTCC

HTCC is a virtual appliance that pro-vides a robust set of functional capa-bilities for trust, security, management, audit/reporting, and compliance.

HTCC is designed to work seamlessly and integrates with VMware vCenter 5.5 or later. HTCC works with vCenter to manage privileged access, ensure accountability, and enforce compliance for VMware vSphere-based infrastruc-tures.

HTCC is deployed between the virtual infrastructure and its admins. HTCC relies on the customer’s network topol-ogy to gain visibility of admin traffic in order to intercept it and authorize or deny activities based on your policies.

FIGURE 4: Architecture of trust attestation in a virtualized environment. VMware ships the trust agent as part of VMware ESXi. (The trust agent must be provisioned to Linux / KVM.)

For example, HTCC allows admins to create and apply fine-grained access policies and perform ESXi configuration management. Admin actions are con-trolled automatically by HTCC, which monitors and applies ESXi capabili-ties according to IT-defined, in-house security and management policies, and remediates deficiencies and discrepan-cies.

With HTCC, whenever an administra-tive request is submitted to the infra-structure, HTCC intercepts the request. HTCC then determines whether that request complies with the organiza-tion’s security policies before permit-ting or denying the action. HTCC also logs all requests in order to produce records that can be used for regulatory compliance and auditing, as well as for troubleshooting and forensic analysis.

With HTCC, IT has a centralized point of control for hypervisor configuration,

compliance, and access management (see figures 5 and 6):

• Policy enforcement, such as role-based access control, or RBAC.

• Infrastructure hardening, via the root of trust (via Intel TXT).

• Automated logging, including foren-sic-quality logging and alerting.

From a high-level perspective, HTCC provides all three AAA capabilities:

• Authentication, via capabilities that enable a trusted infrastructure and reliable oversight of admin actions.

• Authorization, via control over admins based on roles, objects, VM groupings, and geographic boundar-ies.

• Accounting/audit, via fine-grained, evidence-based auditing for compli-ance and security forensics.


FIGURE 5. HyTrust CloudControl* Virtual Appliance

FIGURE 6. HyTrust CloudControl* Provides Access Control to VMware Applications

Management Console and Appliance Dashboard

HTCC integrates two software compo-nents:

• HTCC management console (a Web-based console)

• Appliance dashboard

Web-based Management Console

HTCC includes a Web-based manage-ment console, which allows you to

customize HTCC configuration settings. The console is also used to set up poli-cies for safeguarding a managed virtual infrastructure. For example, the man-agement console lets you set authen-tication options for users, add vCenter Server-managed hosts to the protected infrastructure, define templates and policy checks/tests to enforce security of protected virtual infrastructure. You can also view and configure detailed activity logs.

After you complete the initial HTCC configuration, authorized users can ac-cess the console to set up the managed virtual infrastructure environment.

HTCC Dashboard

The HTCC dashboard provides you with access to critical operational informa-tion. Admins can use this information to monitor system usage and take ap-propriate actions as needed. The HTCC dashboard gives authorized admins access to this information:


• General information: Hostname, installed software version, network deployment type, management IP address, and policy enforcement status.

• License information: Customer name, entitlement number, status, maximum number of protected hosts allowed, type, maintenance schedule, and support expiration dates.

• Services: Status of all HTCC-related services.

• Resources: State and use of various HTCC-related resources (such as CPU, disk, and memory usage; certificate and network status), and other infor-mation.

HTCC Uses Same GUI as VMware

HTCC does not require that VMware administrators change their workflow or management tools. HTCC simply adds critical security controls and vis-ibility necessary to achieve security and compliance in a virtualized infra-

structure. HTCC uses the same GUI that VMware uses, so that VMware virtual-ization teams already understand the interface.

HTCC Capabilities

HTCC capabilities provides robust trust, security, audit/reporting, and compli-ance capabilities, including:

• Remote platform attestation and safer hypervisor launch. This helps ensures that workloads run only on trusted server platforms.

• Creating trusted compute pools based on the trust status of hosts

• Migration of workloads only between trusted platforms.

• Migration of workloads and data only between trusted hosts located in specific locations, such as within a specific geographic boundary or within a logical group.

• Management of policies for work-loads on trusted systems.

FIGURE 7. Authentication and Authorization Process for Virtual Administrators

• Real-time monitoring, threat detec-tion, and alerting of suspicious and/or unauthorized vCenter account activity.

• Fine-grained, role-based authoriza-tion for admin actions.

• Resource-based authorization for admin actions.

As shown in Figure 7, distinct manage-ment networks are used to isolate this ESXi traffic for HTCC; and HTCC relies on the customer’s network topology to gain visibility of this traffic in order to intercept it. The management network is connected to a dedicated, non-routable network. An additional non-routable network is used to support the automated migration of the VMs from different nodes across the trusted clus-ter. Integrated security includes Active Directory to manage common, role-base access to vSphere and HyTrust appliances.


Integration of Active Directory with HTCC

A critical functionality of HTCC is integration with directory service. Cur-rently, HTCC supports Microsoft Active Directory (AD)* and RSA SecurID* or CA Arcot.*

Note: Before you can integrate AD, you must create an HTCC service account within AD.

HTCC integrates directly with AD via lightweight directory service protocol (LDAP) using the HTCC service ac-count credentials. HTCC intercepts all requests destined for HTCC-protected hosts, such as ESXi, vCenter Server, Cisco UCS, and Nexus 1000V. HTCC then authenticates the user against the directory service.

HTCC uses an AD account to query AD and find out the appropriate group membership for the users. This interac-tion occurs each time a user attempts to access the virtual infrastructure. Af-ter HTCC authenticates the user, it per-forms an authorization check (based on local policies) for each request from the user. If a request is authorized, HTCC forwards the request (using a special service account) to the target server. Authentication of the user, including session ID, lasts for the full session.

Once a session is established, au-thorization to perform a particular operation, including directory group membership, can occur on multiple oc-casions per session. Add additional AD groups and assign users as required.

Create AD Groups and Users for HTCC Use Cases

HTCC uses roles to define authorized operations for a virtual environment. There are several predefined roles established within HTCC. You can also create new roles.

The roles within HTCC are mapped to existing user groups with Active Direc-tory.

• HTCC_NetworkAdmin: Users within this group will be permitted to man-age virtual switches, VLANs, and other network configurations

• HTCC_DCAdmin: This is an example datacenter admin group to be used for enforcing policy use cases during the evaluation.

Note: During installation and configura-tion, you should create an HTCC_Su-perAdmin security group within AD; and map that group to the ASC_Super-Admin role within HTCC. You can also create a superadminuser account, and add to the HTCC_SuperAdmin group in AD. The ASC_SuperAdmin Role within HTCC is allowed to perform any action.

Detailed Logging for Evidence-based Audits

HTCC captures highly detailed, real-time logs of every attempted, denied, and authorized admin action. HTCC enables integration of this informa-tion with McAfee ePolicy Orchestrator* and the McAfee Enterprise Security Manager*. In addition, HTCC can share the event logs and data with other leading security information and event management (SIEM) solutions, such as VMware LogInsight,* Symantec Control Compliance Suite,* RSA Envision,* HP ArcSight,* and Splunk* products.” For example, McAfee Enterprise Security Manager has been adapted to efficient-ly parse HyTrust log data.

SIEM software in particular creates a general security control point that ag-gregates real-time alerts, event infor-mation, and reports. This information is collected into a database from various security applications and activities. A key point is that SIEM software can now report on the trust status of compute pools based on Intel TXT and HTCC data. In this way, SIEM can help gener-ate reports that improve automated data gathering for compliance. This includes identifying patterns in event data, and increasing the automated analysis of alerts and correlated events.

Extending Data Security with HTDC

Effectively managing end-to-end encryption and key management in a cloud can be difficult, both in terms of deployment and in dealing with secu-rity and performance pain points for many organizations.

HTDC resolves those issues by deliv-ering easy-to-use encryption that is transparent to users. With HTDC, you don’t need to be an encryption expert. HTDC provides the robust key manage-ment and strong encryption for you, for both virtual and physical machines. HTDC encryption is also enhanced by taking advantage of Intel® Advanced Encryption Standard New Instructions (Intel® AES-NI), which are integrated into Intel Xeon processors.

Thiis discussion covers architecture and functional capabilities of:

• HTDC

• HyTrust KeyControl (HTKC)

HTDC Overview

HTDC is an intelligent solution for encryption of virtualized clouds. HTDC provides automated, centrally managed control over all encryption and key management policies. With HTDC, you have the flexibility to secure data across private, virtualized cloud computing en-vironments and both hybrid and public clouds. HTCC enables:

• Strong authentication and password vaulting.

• Two-factor authentication and multi-tenancy security.

• VM encryption and key management.

• On-the-fly encryption and rekeying

With HTDC, all data encrypted in the OS is protected it as it moves through the hypervisor and to storage. In other words, data is securely encrypted, both at rest and in motion, from the point of install until the VM is eventually se-curely retired. Because the encryption


software is part of the VM, encryption travels with the VM from one physical host to another.

Operationally, HTDC is transparent when requested by authorized VMs, encryption keys are securely retrieved, and the data is decrypted and present-ed back to the application.

In addition, on-the-fly encryption and rekeying take advantage of hardware-accelerated performance capabilities built into Intel Xeon processors. For example, HTDC detects and automati-cally uses Intel AES-NI, which speed up and make encryption smarter, increase maximum performance, and minimize encryption latency.

HTDC has two main components: en-cryption services and HyTrust KeyCon-trol.*

HTDC Encryption Frameworks

HTDC data encryption uses National Institute of Standards and Technology (NIST)-approved AES-128/256 algo-rithms. Encryption protects VMs and their data from the time they are cre-ated, wherever they go, until they are securely decommissioned.

HTDC Encryption Capabilities

HTDC provides robust encryption and policy-based key management that is both highly secure and easy to use. HTDC encryption capabilities include:

• On-the-fly encryption and rekeying with NIST-approved AES-128/256 algorithms.

• Portability to different cloud infra-structures that is transparent to users and applications.

• Multi-tenant administration capabili-ties that allow IT to create unique ac-counts and multiple levels of admin-istration.

• Role-based policy management that enables segmented encryption and administration by department.

• A simple policy agent that installs in each VM’s operating system, making encryption transparent to applica-tions.

• Truly mobile encryption, with the VM copied for backup or availability.

• Full RESTful* API that can easily au-tomate any task, such as provisioning new VMs or a new volume.

• A security audit stream that captures, logs, and alerts on a broad range of activity to monitor and track.

HyTrust KeyControl

HyTrust KeyControl enables a highly available, security-hardened key man-agement system that simplifies encryp-tion management.

The KeyControl server resides in the data center. This allows enterprise to control their own data, whether it resides in the public cloud, a private cloud /data center, or on a physical or virtual server. In a public cloud, the keys and encryption policies are managed and retained by the owner, not the cloud service provider. Once you have authenticated your VM with HyTrust KeyControl, you can begin encryption.

KeyControl capabilities include:

• Centralized key management and encryption policies.

• Strong, two-factor authentication to protect access to virtualization platforms.

• Policy-based key management automated from a Web browser or through APIs.

• Multi-tenant KeyControl, support-ing separation of duties and shared, secure administration.

• Encryption keys that can be applied per device within a VM, for standard data partitions and for Windows* boot.

• Online rekeying, which lets admins set policies to rekey data in accor-dance with industry standards.

• Distributed clusters for fail-overs and high availability.

HyTrust KeyControl Policy Agent

The HyTrust KeyControl policy agent is a software module that runs either locally or in the cloud. The policy agent is used to encrypt and decrypt virtual disks, individual files, virtual machines, or physical servers in the data center. For virtual machines, the agent runs inside Windows and Linux VMs, where it provides encryption of virtual disks and individual files. By running inside VMs, the agent can encrypt / decrypt any virtual machine or physical server within any data center in any cloud environment.

The KeyControl agent contains the HyTrust SecureOS* as its core operat-ing system. All VMs in which the policy agent is installed can securely share encrypted files. Encryption keys (key-IDs) can be used by authorized VMs to encrypt and decrypt files. For example, with the policy agent, you can send encrypted files to cloud storage service providers, and access those files only via authorized VMs.

With encryption, all administrative ac-tion takes place from within a standard Web browser, such as Apple Safari*, Microsoft Internet Explorer*, Google Chrome*, or Mozilla Firefox.* Adminis-tration occurs between the browser to any node in the KeyControl cluster or from a set of REST-based APIs.

KeyControl nodes typically reside in your data center. They can also be run from within the public cloud. KeyCon-trol features include:

• Communication between each policy agent and any KeyControl node, us-ing strict password controls/check-ing.


• Full encrypted path from the VM, through the hypervisor to the stor-age.

• Support for cloning and replication.

• Dynamic rekeying on Windows-based systems, which allows initial encryption or rekeying without taking the VM or applications offline.

• File system resizing for encrypted devices.

• Encryption of files, and support for external cloud storage.

• Migration of encrypted image be-tween VMs with HTCC support for Windows fail-over clusters.

• Root and swap encryption.

• Support for local authentication or RADIUS.

• Rich RESTful API.

Decrypting Workloads and Data

VMs that include the HTDC policy agent can share key IDs (encryption keys ref-erenced by a symbolic name) between VMs within the same cloud VM set. This allows you to encrypt data and move it between these VMs. Only VMs within the same cloud VM set as the Key IDs are allowed to decrypt the data.

Encryption is on a file-by-file basis. You can move larger amounts of data by zipping/tarring groups of files, and then encrypting them.

In today’s cloud, the virtual storage area network (SAN) does not include encryption as one of its data services. This is a critical issue when encryp-tion is required for compliance. HTDC resolves this issue by allowing you to encrypt data and move it to cloud storage, knowing that only you will be able to decrypt the data upon its return. Cloud storage service providers also offer interfaces for migrating encrypted data between VMs.

Administrative Model

HTCC uses a role-based administration model. This model provides greater oversight for virtualized clouds, and al-lows you to separate duties by need-to-know, security level, or other levels. The administrative model provides:

• Support for multiple roles per admin.

• Keys that are never exposed through the webGUI or any other mechanism.

• Alerts that can be sent via the web-GUI and email.

• Audit records that can be displayed in the webGUI, saved to local disk, or exported through syslog to an exter-nal log server.

The robust HTDC administrative frame-work can span multiple organizations in multiple clouds. This framework is use-ful for organizations that range in size from the single-admin IT shop to large, multi-tenant cloud service providers.

Three Role-based Definitions for Admins

The HTCC model offers three role-based admin definitions (see Figure 8): Security, Domain, and Cloud. The role-based model offers these features:

• Admin roles can be combined. For example, one admin can be assigned one, two, or all three roles.

• You can assign any number of admins to each type.

• Admins can be placed in groups to provide peer oversight.

• All objects in the system are owned by administrative groups, and not by individual admins.

FIGURE 8. HyTrust CloudControl* Allows for Role-based Definitions of Administrators


Security Admins

Authorizations allowed for security admins include:

• Create and delete users/groups, and assign users to groups. Groups allow for dual knowledge (no single person can cause problems by withholding information).

• Cannot see any storage, policies, and virtual machines, and cannot modify anything.

• Can see all audit records. These re-cords can be exported to an external syslog server.

Domain Admins

Authorizations allowed for domain admins include:

• Set up HyTrust KeyControl nodes, which are usually configured in a cluster. KeyControl is typically set up as an active-active cluster to protect against system failure.

• Can see only audit records based on that specific admin’s group actions.

Cloud Admins

Authorizations allowed for cloud ad-mins include:

• Manage sets of VMs where the HTDC Policy Agent is located (VMs that can be encrypted).

• Create and manage multiple cloud VM sets, which are logical groupings of VMs (such as VMs running in given location or data center).

• Create encryption keys to securely move encrypted data between speci-fied VMs.

• Create certificates for each VM that specify how long keys will be deliv-ered for that VM.

• Specify key expiration dates.

• Revoke access to individual encrypt-ed devices or to the whole VM. When access to a device is revoked, file systems are forcibly unmounted, thus removing access to clear-text data.

• Can see only audit records based on that specific admin’s group actions.

The rest of this blueprint document explains use cases, and provides high-level deployment instructions for the trusted cloud solution.

Use Cases

This section explains geo-location, compliance, and other trust-based use cases enabled by the combined solu-tion from Intel, VMware, and HyTrust.

Establish Trusted Compute Pools

Intel TXT and HTCC work together to enable the industry-leading concept of trusted compute pools. These are servers that have booted with a trusted (authorized) configuration -- trust at-testation. Once you know which servers have booted into an authorized con-figuration, you can group these hosts into trusted pools. HTCC can then use these trusted compute pools to control the placement of applications, sensitive workloads, and/or data. Using trusted compute pools, you can separate trusted hosts from untrusted resources.

FIGURE 9. Trusted Compute Pools. Group trusted hosts into trusted compute pools for sensitive workloads. Hosts that are unknown or untrusted can be excluded or not allowed to run such workloads.


For example, you could separate high-value workloads from commodity ap-plications and general data processing. In this case, Trusted Pool A could be a group of hosts configured and secured for sensitive, high-value workloads. Trusted Pool B could contain hosts on which only commodity applications are allowed.

Trusted compute pools help you gain the benefits of the dynamic cloud environment while still being able to enforce higher levels of protections for critical workloads.

Geo-Location Use Cases

Geo-location capabilities let you define, set, and enforce trust and security policies based on geographic areas, logical groupings of hosts, or other restrictions. Geo-location capabilities help make sure that sensitive appli-

cations and data workloads run only on authenticated, trusted hosts. This includes running only on hosts is a specific data center, within a country’s boundaries, or within a defined security zone. Intel TXT, TPM, HTCC, and HTDC enable geo-location capabilities via trust attestation and hardware-based policy tagging.

Geo-location concepts and use cases include:

• Hardware-based policy tags. Assign identifiers to hosts, in order to more easily group them or better identify their actual, physical locations.

• Trusted compute pools. Group trusted hosts by geographic area or logical grouping, in order to handle virtual workloads and data based on policies (such as security require-ments).

FIGURE 10. Hardware-based Policy Tagging. Policy tags are descriptors or identifiers which you can assign to hosts. Tag information is part of the Intel® Trusted Execution Technology measurement of the host’s boot environment, and can be used for trust attestation, data location, and other use cases.

• Data location. Identify the actual, physical location of the host.

• Boundary control. Define a geo-graphic boundary within which work-loads and/or data must run or reside. For example, boundary control lets you specify and enforce where vir-tualized applications and data may execute and/or be decrypted.

• Geo-fencing . Define sub-groups within a boundary to handle specific types of workloads and/or data.

The figures in the next several pages show policy tagging and geo-location use cases. For more information about geo-location use cases in a trusted cloud, refer to the document, NIST IR 7904 (Second Draft) 2 3 4; Trusted Geo-location in the Cloud.

http://csrc.nist.gov/publications/PubsNISTIRs.html




Define and Assign Policy Tags

HTCC lets you assign hardware-based policy tags to hosts. (HTCC also lets you assign software-based labels to hosts.)

Policy tags are admin-defined descrip-tors or identifiers. Typically, they are used to specify a host’s location by country, state, city, region, and/or other logical grouping. For example, you could define Host A to have geographic descriptors, such as: USA - Colorado - Denver. You could define Host B to have logical descirptors, such as: Data Center 2 - PCI. Host C could have both geographic and logical descriptors: USA - Texas - ClinicalRecords - HIPAA.

The combination of trust attestation and policy tags enables key use cases. For example, they enable enforcement of boundary control, placement of workloads, workload execution, data migration, and geolocation, geofenc-ing. With policy tags, you can group

trusted hosts in ways that better meet your business security and compli-ance needs. You can then more easily identify and manage those hosts in the HTCC database.

HTCC offers five levels of policy tag-ging. By default, these are listed as country, state, city, and so on. However. as shown in the examples above, you can use any identifier as the defined value for any level of tagging.

• Country

• State, province, or other major region

• City, physical data center, or other sub-region

• Logical grouping, such as the type of workload, or workload by security requirement

• Custom: a custom value or identifier

Policy tag information is part of the

FIGURE 11. Data location. Data location is the ability to identify the actual, physical location of a host. Data location is enabled by trust attestation of the host, including its policy tag.

measured boot environment of a host. This information is stored in the TPM with other launch environment data.

Hardware-based policy tags are typi-cally provisioned to the host during deployment.

Enable Data Location

Data location is the ability to identify that your data / workload is in a speci-fied, physical location, such as within a national boundary, region, city, data center, or even as being on a specific server. The location of your data is determined by the physical location of the server on which that data resides. Knowing the physical location of your data means your policies can better control who has access to that data.

Policy tags assigned to each host help


you group and identify hosts in terms of the data and workloads they are autho-rized to handle. Because trust attesta-tion of each host includes attestation of the host’s policy tags, you have accu-rate and precise visibility of the actual, physical locations of these hosts.

Enforce Boundary Control

HTCC leverages Intel TXT and the TPM to enable boundary control. Boundary control is the ability to define a geo-graphic region, inside which virtual-ized workloads and/or decryption are authorized or denied by HTCC. Bound-ary controls give you the ability to meet security, and regulatory requirements, including data location requirements for compliance. Once boundary policies are defined, they can be applied to any

FIGURE 12. Boundary control. Group trusted hosts by geographic or logical attributes. Hosts that are unknown or untrusted are excluded or not allowed to run sensitive workloads or data.

TPM-enabled, HTCC-managed host.

For example, Boundary A could be defined as a trusted pool in which all hosts must be physically located within the geographic boundaries of the country of Germany. Boundary B could be defined as hosts that are configured and managed for PCI compliance, and physically located in the state of Texas, USA. Boundary C could be defined as a set of only 5 hosts configured and managed for high security workloads, located at a specific data center.

Boundary control helps assure that:

• Servers are located in their autho-rized regions (such as an authorized country or city), so that the cloud provider is in compliance with the

appropriate data security and privacy laws.

• The cloud compute platform that hosts the workload has not been compromised or modified in an unau-thorized way.

• Sensitive workloads on a multi-tenancy cloud platform are isolated within a logically defined environ-ment, away from the workloads of other tenants.

• Workload migration occurs only within trusted compute pools and only between trusted, authorized hosts in trusted clusters.

• Sensitive applications and data are not migrated, removed from, or


decrypted from a secure data center without authorization.

• The company is in compliance with national/regional data location regu-lations.

To enforce boundary control policies, you simply add these policies to HTCC rules as a host attribute constraint type.

Boundary control is inclusive as well as exclusive. In other words, you can use the exclude-host attributes directive to exclude a host with matching policy tags values from the rule.

Use Geo-Fencing to Create Sub-Groups Within a Boundary

Geo-fencing is the ability to create subgroups of hosts within a specified boundary. For example, you could de-fine a trusted pool as 100 trusted hosts physically located in the state of Texas, USA. Within that pool, you could divide the hosts further, into hosts that handle accounting workloads, sales workloads, human resources (HR) workloads, and management workloads. Each sub-group can have its own set of security

FIGURE 13. Geo-fencing. Create sub-groups of hosts within trusted pools.This allows you to separate different types of workloads to better meet business, security, and compliance needs.

and management policies. With geo-fencing, you can meet business and security needs at a more detailed level.

Compliance Use Cases

Regulatory compliance requirements have a large impact on how enterprise plans, develops, and works in the cloud. To simplify and help to address compliance requirements, industry has developed a number of best practices. Enterprise can uses these best prac-tices to develop an effective cloud architecture that meets both in-house security needs as well as compliance requirements. For example, VMware, VCE, HyTrust, Coalfire, and Intel have developed an SDDC Validated Refer-ence Architecture for FedRAMP v2.0.

Best-Practice Frameworks

Some of the frameworks available for regulatory compliance include these:

• Frameworks were created for IT technology management by NIST, the Cloud Security Alliance (CSA), and the Control Objectives for Informa-

tion and Related Technology (COBIT). These frameworks were created to address security, compliance, and IT governance.

• Risk Management Framework was developed by NIST to ensure that managing information about system-related security risks is consistent and that information security require-ments, including necessary security controls, are integrated into the organization’s enterprise architecture and system development life cycle processes.

• NIST Trusted Geolocation in the Cloud Interagency Report 7904 outlines an approach for enterprise to address security and privacy considerations. This approach allows workloads, data, and applications to run in a certain geographical location and defines the solutions available in the marketplace to help provide the required functional and compliance capabilities.


HyTrust Integration with McAfee*

HyTrust and McAfee have specifically integrated several capabilities that miti-gate the challenges of meeting security and regulatory compliance for mission-critical workloads in a VMware environ-ment. These capabilities provide:

• End-to-end security for VMs and the virtual infrastructure.

• Verifiable compliance enabled by virtual infrastructure access controls and audit log data.

• Virtual platform hardening, including platform trust verification via Intel TXT.

• HyTrust integration with McAfee ePolicy Orchestrator (McAfee ePO)* software for integrated systems management

• HyTrust integration with McAfee En-terprise Security Manager* for SIEM and log management.

HTCC and HTDC Solutions for Specific Use Cases

HyTrust helps organizations address compliance challenges by providing bundled solutions (suites) designed for specific use cases. HTCC and HTDC capabilities are described earlier in this PoC blueprint. Some key notes of capabilities enabled by Intel TXT, HTCC, and/or HTDC:

• Access control, visibility, and security for virtualized, multi-tenant infra-structure.

• Strong authentication and root password vaulting, HTDC locks down critical applications and data with strong encryption and centralized key control. This allows you to lock down applications and data before deploying to a public cloud. You can then generate an encryption key which you manage, and prevent even the cloud service provider from ac-cessing your data.

• Encryption of data and encryption keys assigned to the data owner, to protect against unauthorized access or modification of customer data. FIPS-validated encryption ensures that the integrity of data is maintained according to FedRAMP requirements for security of sensitive information.

• Policy-based management of trusted hosts.

• Security policy and configuration checklists and benchmarks to moni-tor and enforce approved configura-tion settings. Enabled by Intel TXT, policies help enterprise automatically monitor and detect unauthorized software and firmware components on each managed host.

• Hypervisor hardening and protection of critical virtual assets to protect against malicious or accidental cor-ruption and denial of service, even within large, multi-tenant environ-ments.

• Policy-based access control and security templates to remotly moni-tor connections, and automatically enforce disconnect settings and remediation policies.

• Remediation actions that can be automatically (or manually) applied upon alerting.

• Fine-grained logging and alerting for audits, reporting, troubleshooting, and forensics.

Sampling Of Use Cases

The following lists highlight a small sampling of trust-based use cases supported by the solution stack of Intel TXT, TPM, VMware vCenter, VMware ESXi, HTTC, and HTDC for your virtual-ized cloud.

Use Cases: Dynamic Root of Trust

• Use HTCC to manually trigger a re-verification of the host’s trust status: Trust attestation. (By default, HTCC

performs this task automatically, once a day.)

∘ Check for possible changes to the server platforms.

∘ Check for possible changes to the VMM.

• Restrict application to run only on trusted hosts and locations.

• Control which hosts are initially cho-sen to start the application.

• Control which hosts VMs are allowed to migrate.

• Ensure only trusted hosts are used.

• Enable reporting, notification, com-pliance, and audits.

Use Cases: Platform Attestation with Intel TXT

• Measure launch of the server BIOS, low-level device drivers.

• Platform and VM hypervisor attesta-tion.

• Validate measured (host boot envi-ronment) vs. expected (TAS white list) server measurements.

• Report the trust status, utilize mea-sured launch process Trusted or Untrusted systems.

• Use the trust status to enable use cases, such as trusted pools.

• Use policy tag information to enable use cases, such as boundary control.

Use Cases: Trusted Compute Pools and Secure Migration

• Create a trusted compute pool:

∘ Create trusted compute pools, enabled by Intel TXT and HTCC.

∘ Place a trusted virtual machine on a host within a trusted com-pute pool, based on HTCC policy.

• Place workloads in trusted pools:

∘ Request a placement of the ser-vice in a trusted pool.


∘ Determining whether the request is in accordance with defined policy.

∘ Permit or deny the requests workload on servers in the trusted pool.

∘ Intercept all administrative requests for the virtual infra-structure.

∘ Record all activities, including audit and compliance reporting.

• Migrate workloads between hosts in trusted pools:

∘ Examine migration policies based on the trust status of hosts.

∘ Make sure secure, attested ESXi hosts are available.

∘ Attempt to migrate a sensitive VM to an untrusted host. HTCC enforces migration policies and denies the move.

∘ Attempt to migrate a sensi-tive VM to a trusted host. HTCC should allow the migration.

∘ Check the record of administra-tive access and change requests.

∘ Generate audit and compliance reports.

Use Cases: Virtual Server

volume decryption based on host loca-tion

• Encrypt data on available drives.

• Access the encrypted drive, and save a new file to the drive.

• Revoke access to the encrypted drive.

• Review key-management policies.

Use Cases: Boundary Control with Geo-tagging and Encryption

• Provision and apply geo-tags.

• Set up boundary controls for geo-location use cases.

• Apply platform trust:

∘ Validate the trust status of the host via trust attestation.

∘ Confirm that virtual workloads can be constrained to run only on trusted servers.

• Apply boundary control:

∘ Validate that a boundary can be established inside which only sensitive workloads are allowed to run.

∘ Disallow data decryption outside of a defined boundary.

∘ Restrict vMotion across unau-thorized boundaries.

• Label VMs and RBAC to provide fine-grained control of workload migra-tion, and enforce a least-privilege model of admin governance.

• Prove that data at rest is encrypted for any virtual workload and for any subsequent duplicates, clones, back-ups, etc.

Use Cases: KeyControl

• Establish key control:

∘ Create encryption keys and store them securely within the Key-Control cluster, separate from virtual workloads.

∘ Show that KeyControl operates according to proper key manage-ment practices (least privilege, key-strength, key rotation, key revocation, etc.).

∘ Show that KeyControl has been tested according to the NIST FIPS 140-2 standard.

∘ Show secure communication between an encrypted workload and KeyControl.

• Extend security

∘ Show that ESXi hosts have been hardened (trust attestation).

∘ Show that ESXi hosts are con-figured to meet PCI-specific standards (and/or other security standards).

• Demonstrate root-password-vaulting of ESXi hosts, to provide account-ability over root-privileged access to hosts.

• Integrate two-factor authentication to show that admin IDs are unique, and that accountability of admin ac-tions is attributable to individuals.

• Demonstrate RBAC of admin actions.

Use Cases: Auditing and Alerting

• Show how to monitor admin ac-cess, and how to receive alerts that indicate potential errors, misuse, or malfeasance.

• Fine-grained audit records are kept for all vAdmin actions and against creation and deletion of all system level (virtual) objects. This includes both successful and denied attempts.

• Use fine-grained auditing to detect certain anomalies or suspicious activ-ity by admins.

• Use alerting to provide continuous watch for repeated behavior that may be indicative of misuse.

System and Solutions Requirements

Hardware And Software Requirements

This section lists the hardware and software requirements for the trust-based solution for virtualized clouds.

Prerequisites for Overall Solution Deployment

The installation and configuration information in this section is intended for systems engineers and systems administrators with experience in VM-ware vSphere, networking and router configuration, Microsoft Active Direc-tory (AD),* and Microsoft policy man-agement.


In order to install this trusted cloud solution and provision hosts, you must have:

• Fundamental knowlege of sytems and networking

• Working knowlege of VMware solu-tions

• Working knowledge of HyTrust virtual appliances

• Administrative access

Server Requirements for Servers with Intel® Xeon® Processors

The following table provides informa-tion about the hardware and firmware requirements for Intel Xeon processor-based servers in this solution stack.

Intel TXT

Intel TXT is required for this solution stack. Intel TXT is an underlying and integrated set of capabilities available in select Intel Xeon processor-based servers. It is the root of trust. All leading server manufactures have enhanced their BIOS to provide direct support for Intel TXT functionality as default.

Make sure you order your Intel Xeon processor-based servers with Intel TXT.

TPM

TPM is required for Intel TXT. TPM are supported nearly every enterprise-level computer sold today. TPM is designed to keep information secure, and is a critical aspect of establishing the chain of trust.

Make sure you order your Intel Xeon processor-based servers with an pre-installed TPM. Although you can up-grade a server with TPM, upgrades can make deployment more complex and require additional configuration work.

Upgrading an Existing Server to Support TPM

If you are upgrading the TPM on a specific host, keep these considerations in mind:

Note: If you are upgrading servers to add TPM, work with your server supplier to make sure you acquire the correct version of TPM for this solution stack: TPM 1.2.

Note: OEM-specific instructions may be required for servers and individual server models. Also, TPM security and configuration can vary by server manufacturer. Make sure you follow the specific and detailed upgrade instal-lation instructions provided by your server manufacturer.

CAUTION: Once TPM has been fully provisioned and configured, it cannot be reused in another server. Removing the TPM erases all information in the component, rendering it useless. This helps assure the trust and security of any information stored in TPM memory.

The security specifications for TPM from the Trusted Computing Group (TCG) are comprehensive and detailed. TCG is an international industry stan-dards group that develops and publish-es specifications for use and implemen-tation by the industry. Refer to the TCG standards for further information about installing or using TPM.

Prerequisites for HTCC

Before installing HTCC, the following should be in place:

• Virtual infrastructure consisting of installed vCenter servers and, option-ally, ESXi hosts.

• Network connectivity and access to the HTCC host machine and the in-frastructure to be secured. The HTCC installation requires an ESXi host with at least one dedicated network interface (using VLANs).

• For Directory Service mode authen-tication, you must set up Microsoft Active Directory with an AD Service Account and the recommended HyTrust security groups, as described in the HyTrust CloudControl Adminis-tration Guide.

• Services used by virtual infrastruc-ture clients should be routable from the appropriate interface. For example, AD, DNS, and RSA services must be accessible from HTCC.

Server Requirements for HTCC

Table 3 (next page) lists the minimum server requirements for HTCC in this solution stack.

Server Requirements for HTDC

The most popular method of using HTDC is to install a KeyControl node as a virtual machine and have the hy-pervisor manage the storage directly. This has the advantage of using your underlying storage subsystems without having to change them. For example, you can simply assign each KeyControl node one disk, and have redundant storage underneath the hypervisor. Table 4 (next page) lists the minimum server requirements for HTDC.

Software Requirements for HTCC and HTDC

HTCC and HTDC is delivered in the open virtualization rormat (OVF) via a single .ovf file. The file contians the Hy-Trust virtual appliance descriptions and two virtual machine disk (VMDK) files that contain the HyTrust software.

PXE Server Requirements

Hardware-based policy tags are key to many trust-based use cases in the vir-tualized cloud. These tags are typically provisioned to the host during deploy-ment. This requires a PXE server as well as a few other elements. If you do not have a server configured for PXE boot, refer to the HyTrust PXE server Setup Tech Note for information about setting up a PXE server.

PXE server requirements consist of:

• A working PXE server, configured with supporting for DHCP, TFTP, and NFS share.


• The policy tag provisioning image (assettag.iso).

• Intel TXT must be enabled.

• The TPM for any host to be provi-sioned must be in the “clear” state.

To configure the PXE server, follow these steps:

1. Extract the contents of assettag.iso and copy the “casper” folder to the NFS share directory on the PXE server.

2. Copy the SSL certificate located at: /etc/intel/cloudsecurity/ssl.crt.pem from your policy tag management server to the PXE server.

TABLE 2. Compute Requirements for Servers

REQUIREMENTSFORINTEL®XEON®PROCESSOR-BASEDSERVERS NOTES

Intel® Xeon® processor with Intel® Trusted Execution Technology (Intel® TXT)

Intel® Xeon® processor E5 E7, E5 v2, E7 v2, E5 v3, or E7 v3 families

BIOS that supports Intel TXT and TPM The SINIT Authentication Code Module and tboot file are provided by the OEM

Trusted Platform Module (TPM) 1.2 This solution stack is designed to work with TPM 1.2

TABLE 3. Server Requirements for HTCC

HYTRUSTCLOUDCONTROL(HTCC)* HTCC VIRTUAL MACHINE: MINIMUM REQUIREMENTS

Processor: Intel® Xeon® processor E5 v3 or later, with support for Intel® Trusted Execution Technology, Intel® Virtualization Technology, and TPM 1.2

4 virtual CPUs

Memory 16 GB

Storage 30 GB

Network 1 NIC minimum, Intel® Multi-Port Server Ethernet adapters

Redundancy: High availability Deploy a secondary HTCC for high availability in a primary/secondary configuration. Promote the secondary HTCC to manually initiate a fail-over event .

3. Place the certificate in the NFS share directory of the PXE server.

4. On the PXE server, edit the ‘/tftp-boot/ipxe/bootloader.cfg’ file and add the following arguments:

atag_cert=’http://<PXE IP Address>/<nfsshare>/ssl.crt.pem’ atag_username=’admin’ atag_password=’password’ atag_server=’http://<IP Address>:<Port>/mtwilson/v2’

In the above arguments:

• Replace <PXE IP Address> with the IP address or hostname of the PXE server.

• Replace <nfsshare> with the path to the NFS share.

• Replace <IP Address> and <Port> with the IP address or hostname and port of the Asset Tag Management server on the PXE network.

Requirements Tables

The following tables summarize the hardware and software requirements for this solution stack.

TABLE 4. Server Requirements for HTDC

HYTRUST DATACONTROL* HYTRUST KEY CONTROL* VIRTUAL MACHINE: MINIMUM REQUIREMENTS

Processor: Intel® Xeon® processor E5 v3 or later 2 Virtual CPUs

Memory 16 GB

Storage 2 GB

Network VMware VMXNET2 or E1000*

High availability 2 or more KeyControl servers in a cluster is recommended for high availability


TABLE 5. HTCC and HTDC Software and OS Requirements

SOFTWARE VERSION COMMENTS

VMware vSphere* ESXi 5.5 or greater, and VMware vCenter Server* 5.5, update 1 or later

ESXi hosts must be managed by vCenter Server 5.5. The server must support VMware ESXi, and run 64-bit virtual machines.

Microsoft Windows Server 2008* with Microsoft Active Directory (AD)* and DNS enabled

16 GB Access to AD with DNS enabled

Network Time Protocol (NTP) server 2 GB Required for HTCC

Web browser (Mozilla Firefox,* Microsoft Internet Explorer,* or Google Chrome*);

VMware VMXNET2 or E1000* Display/operation of the HTCC and HTDC management console

HyTrust CloudControl (HTCC)* 4.5

HyTrust DataControl (HTDC)* 3.0

Microsoft Windows* operating system Server 2008 R2 or Server 2012 R2 For managed nodes

Linux* Any current Linux* x64 version For managed nodes

TABLE 6. Sample Deployment Worksheet

RESOURCE IP ADDRESS DNS HOSTNAME PUBLISHERIP(PIP) PUBLISHER DNS HOSTNAME

HyTrust HTCC N/A N/A

vCenter

ESXi host Optional Optional



DNS Server N/A N/A

NTP server N/A N/A

TABLE 7. Sample Deployment Worksheet

RESOURCE IP ADDRESS DNS HOSTNAME PUBLISHERIP(PIP) PUBLISHER DNS HOSTNAME

HyTrust HTCC N/A N/A

vCenter




DNS Server N/A N/A

NTP server N/A N/A

Deployment Worksheets

These worksheets can help you plan your deployment.


Deploying the Solution Stack

This section provides an overview of deployment for the trust solution in a VMware virtualized cloud.

Enable and Set Up Intel TXT and the TPM

When setting up your cloud, make sure your servers include both Intel TXT and TPM. Figure 14 shows the workflow for setting up Intel TXT and TPM.

Enable Intel TXT and TPM Settings

There are several high-level steps to provision Intel TXT and TPM on a host and install the HyTrust appliances. Be-cause each OEM implements hardware and firmware differently, the BIOS con-figurations settings, menu, and steps required to enable Intel TXT and TPM can vary from server to server.

To enable Intel TXT and TPM in the BIOS, follow these general steps:

FIGURE 14. Workflow to Enable and Activate Intel® Trusted Execution Technology and the TPM

1. Enable TXT and Intel® Virtualization Technology (Intel® VT) in the BIOS with these settings:

∘ Set Intel TXT to “Enabled”

∘ Set Intel VT to “Enabled”

∘ Set Intel® Virtualization Technol-ogy for Directed I/O to “Enabled”

2. Enable TPM in the BIOS:

3. Under the processor configuration in the system BIOS, select Intel TXT.

4. Enable and set the admin password (optional).

5. Under security, enable the TPM (for example, set to “on”), and “func-tioning.”

6. Confirm that the TPM is enabled and activated.

Note: To use TPM capabilities, the TPM chip must be enabled and activated in the BIOS, and TPM cannot be locked

Note: If TPM is not on and activated, reboot the BIOS to activate the TPM and enable its activated status.

7. Save the BIOS settings.

8. Reboot the system.

CAUTION: If the TPM is already on and active, do not clear the TPM unless you want to erase all data previously stored there.

Install and Set Up the Hypervisor

Follow these two general steps to set up the ESXi hypervisor:

1. Install and set up ESXi 5.5 (or later). Refer to the VMware ESXi Installation Process and Configura-tions Guide, as necessary, for this procedure.

2. Install and set up your virtual ma-chines (VMs).


Install HTCC

HTCC provides a centralized point of control for hypervisor configuration, compliance, and access management. Refer to the HyTrust CloudControl In-stallation Guide and HyTrust CloudCon-trol Administration Guide for detailed installation and configuration informa-tion for HTCC.

Note: To install and run HTCC as a vir-tual appliance, use the vSphere Client application or vSphere Web Client to access either vCenter Server or the ESXi host on which you want to deploy and configure the HTCC virtual machine.

Follow these general steps to install HTCC.

1. Install and configure HTCC 4.5 or greater:

∘ Disk space, memory, virtual CPU, andnetwork

∘ IP address: system IP and vCen-ter server 5.5, update 1 or later

2. Configure the HTCC environment:

∘ Configure DNS, including both forward and reverse DNS. Make sure that reverse DNS query works correctly.

∘ Configure and enable a Network Time Protocol (NTP) server for HTCC.

3. Set up the white list of known-good host measurements in the HTCC TAS.

4. Set up hardware-based policy tags for each HTCC-managed host.

Install HTDC

Refer to your HTDC Administration Guide for specific information about installing HTDC. Follow these general steps to install HTDC:

1. Install and configure HTDC 3.0 or greater.

2. Deploy the KeyControl server (a virtual appliance) inside the virtual environment.

3. Install the policy agent (a small software module) in each guest OS that is being encrypted.

4. Point the policy agent back to the KeyControl server.

5. Make sure the encryption service is configured and set up for encryp-tion.

Test Connectivity and Compute Requirements

Follow these general steps to test con-nectivity and compute requirements of the PoC environment:

1. Connect to the network

2. Verify connection to, access to, and configuration of DNS and Active Directory.

3. Verify connection to, access to, and configuration of vCenter.

4. Verify that Intel TXT and TPM are correctly enabled and set up:

5. Verify that Intel TXT and the TPM are enabled properly in the BIOS for all hosts you want to trust.

6. Verify that the hypervisor has taken ownership of the TPM on each host. Do this from the local host com-mand line, using the esxcli com-mand:

esxcli hardware trustedboot get

Note: If either the dynamic root of trust measurement (DRTM) or TPM shows as false, re-verify that Intel TXT and TPM are enabled properly on the host(s).

7. Verify that all host names are in lowercase.

8. Verify that each hosts’s domain name is listed in lower case, or add the domain name if it is not yet entered.

9. Verify DNS entries forward and re-verse lookup zones are correct and that entries are listed in lowercase.

Note: In some cases, Microsoft will translate a DNS or host entry into up-percase. If DNS is set up correctly, this translation should not cause problems. However, if you note that DNS records are in uppercase, verify that they are still correctly recognized.

10. Verify that the clocks on vCenter, ESXi hosts, HTCC, and HTDC are in sync and within five minutes of each other.

11. Make sure you have the correct VMM and BIOS versions in vCenter and PCR values. You can verify ver-sion information with the vCenter/managed object browser, or MOB. To navigate to these values, follow the links in the MOB.

Configure for High Availability

A common requirement for HTCC in a PoC or other deployment is high avail-ability (HA). To enable and configure high availability, HyTrust recommends that you isolate the HA network to es-tablish the Connection 3 (eth2) connec-tion between the primary and second-ary HTCCs.

For example, you can use vSphere Client to create and configure a virtual network connection for the two HTCC instances you want to use. Note that the primary and secondary HTCCs are on separate hosts. Because of that, you will have to create a new VLAN for HTCC HA, and then trunk the physi-cal switches that support the virtual infrastructure to handle the new VLAN. Also, the eth0 and eth2 IP addresses must not be on the same subnet. (Refer to the HyTrust CloudControl Admin-istration Guide for the full list of HA commands.)


Before deploying HTCC, complete the deployment checklists for high avail-ability. The checklists (which follow the procedure) include one filled-out sample, and two checklist worksheets.

Follow these general steps to set up high availability in HTCC:

SAMPLE: HYTRUST HIGH AVAILABILITY CHECKLIST

RESOURCE VALUE

Connection 3 of Primary HyTrust CloudControl (HTCC)

IP 192.160.20.1

Subnet mask 255.255.255.248

VLAN ID VLAN 20

Connection 3 of Secondary HTCC

IP 192.168.20.2

Subnet mask 255.255.255.248

VLAN ID VLAN 20

CHECKLIST: HYTRUST HIGH AVAILABILITY CHECKLIST 1

RESOURCE VALUE


IP

Subnet mask

VLAN ID

Connection 3 of Secondary HTCC

IP

Subnet mask

VLAN ID

1. Locate a second host on which to install the secondary HTCC.

2. Verify network connectivity of the host to the public and protected network segments.

3. Create an isolated VLAN for HyTrust HA, and create the necessary vSwitch for network connection 3 (eth2).


CHECKLIST: HYTRUST HIGH AVAILABILITY CHECKLIST 2

RESOURCE MAPPED MODE VALUE ROUTER MODE VALUE


IP

Subnet mask

Gateway

DNS server

VLAN ID


IP

Subnet mask


IP

Subnet mask

Connection 1 of secondary HTCC

IP

Subnet mask

Gateway

DNS server

VLAN ID


IP

Subnet mask


IP

Subnet mask


Provision Policy Tags

The procedures in this discussion explain the general requirements and components for deploying hardware-based policy tags. For detailed instruc-tions, refer to the HyTrust CloudControl Administration Guide.

Note: Policy tags are typically provi-sioned to the host using PXE. Systems engineers who are proficient with Linux administration, Preboot eXecution En-vironment (PXE), VMware ESXi or KVM hypervisors and related technologies should support the PXE process.

In general, you should follow these processes to provision policy tags:

• Plan your policy tags carefully. It can be tedious to re-provision a host.

• Use HTCC to define the tags in the HTCC system.

• Use HTCC to assign policy tags to the host.

• Provision the policy tags to hosts, us-ing the secure, trusted process.

• Set up your HTCC trust and manage-ment policies based on the policy tags.

• Evaluate your policy tagging over time, to make sure you continue to meet business, security, and compli-ance goals effectively.

Once policy tags are fully provisioned and set up in the host and HTCC, they are immediately enforced.

Note: After policy tags are assigned to hosts, if the tags are not actually pro-visioned to the hosts, then operations governed by related rules are denied until you provision the hosts.

Plan Your Policy Tags Carefully

Policy tags are used to address opera-tional, business, security, and compli-ance requirements. Because of this, it is strongly recommended that you carefully plan the descriptors to use, with input from all enterprise teams: business teams, security teams, and operational teams.

Define Policy Tags in HTCC

Once you know which policy tags you will be using, you can use the HTCC console to define the tags for your hosts:

1. Go to the Policy > PolicyTags page.

2. Click Add.

3. On the Policy > PolicyTags > Add PolicyTags page, select the PolicyTags Type.

4. Enter the value you want, and click OK.


Assign Policy Tags to Host in HTCC

Hardware-based policy tags can be ap-plied only to systems that are enabled with Intel TXT and TPM. To verify that an ESXi Host is enabled with Intel TXT and TPM, first use the following com-mand from an SSH session or from PowerCLI:

esxcli hardware trusted boot get

If the command returns true, then Intel TXT and TPM are enabled.

To assign a policy tag to a host, follow these steps:

1. In the HTTC, go to the Compliance > Hosts page.

2. Select the TPM-enabled host from the Hosts column.

3. Click the Edit button.

4. On the Edit Host page, select the PolicyTag tab.

5. Select appropriate policy tag values from the drop-down menus, and click OK.

6. HTCC should display a JGrowl error message, and should prompt you to boot the host to PXE in order to activate the policy tag assignment.

Provision Policy Tags to a Physical Host, via PXE

Figure 28 shows the workflow to provi-sion policy tags. In general, policy tag provisioning should be done during deployment of the systems. Although you can reprovision the tags later, it can be time-consuming to do so after the initial deployment.

Policy tags are part of the measured launch environment for the host, and so are part of the chain of trust. When policy tags are assigned to a physical host, the policy tag service creates a certificate on the TAS with the host UUID and the tags assigned to that host. (To help increase security and resist tampering, each host’s tags are binned with the UUID of that host.) When you provision the tags to the host, you apply the certificate to the physical host. This process is initiated by PXE-booting the host.

Provision a Host with Policy Tags

Provisioning policy tags to a host re-quires a PXE server.

Note: If you do not have a server configured for PXE boot, refer to the HyTrust PXE server Setup Tech Note for information about setting up a PXE server.

The following general steps explain how to provision a host with policy tags:

1. Extract the contents of assettag.iso, and copy the casper folder to the NFS share directory on the PXE server.

2. Copy the SSL certificate from your asset tag management server to the PXE server. The certificate is lo-cated at: /etc/intel/cloudsecurity/ssl .crt .pem

3. Place the certificate in the NFS share directory of the PXE server.

4. On the PXE server, edit the /tftp-boot/ipxe/bootloader.cfgfile, and add the following arguments:

atag_cert=’http://<PXE IP Address>/<nfsshare>/ssl.crt.pem’ atag_username=’admin’ atag_password=’password’ atag_server=’http://<IP Address>:<Port>/mtwilson/v2

When editing the file:

• Replace <PXE IP Address> with the IP address or host name of the PXE server.

• Replace <nfsshare> with the path to the NFS share.

• Replace <IP Address> and <Port> with the IP address or host name and port of the asset tag management server on the PXE network.


Provisioning Hosts with Policy Tags

The following general steps explain how to provision policy tags:

1. Reboot the host.

2. Clear the TPM in the BIOS.

3. Reboot the host and sign-in again if necessary, into BIOS settings.

4. Enable TPM in the BIOS.

5. Reboot the host to the PXE server. When the system boots, and the policy-tag provisioning image loads, the asset tag provisioning agent script will run. The script will contact the TAS and retrieve the latest valid certificate for the host’s hardware UUID.

6. Reboot the host again, and enable Intel TXT and the TPM in BIOS.

7. Reboot the host to its usual operat-ing system. The host’s TPM state will then be set to: ‘Enabled + Acti-vated + Owned.’

Note: Each POST takes about 3 to 5 minutes.

8. Open the Web browser that runs HTCC.

9. In HTCC, go to Policy > Resources.

10. Check to see if the policy tags have been provisioned for this host.

11. If the icon next to the host name is blue then the host has been provi-sioned with the policy tags. If the icon is yellow, the tags have not been provisioned to the host.

Above: Host Provisioned with Policy Tags

Above: Host Not Yet Provisioned with Policy Tag


Rules Enabled by Policy Tags

A rule is assigned to hosts and applied only to the hosts with the matching policy tag values. The values defined for each of the policy tag types are available under “Constraint Type: Match Host Attribute(s)” on the Rule Constraints page. Policy tag values are added to rules as constraints.

You can assign a rule hosts using con-straints, via the Exclude Host Attributes directive. If you do this, the hosts with the matching policy tag values are ignored or excluded from the rule.

Use Policy Tags as Constraints to a Rule

Follow these steps to use policy tags as a constraint:

1. Go to the Policy Rules page, and click Create Draft.

2. Click on the rule to which you want to assign policy tag constraints.

3. Under the Constraints panel, click Add.

4. On the Rule Constraints page, select Match Host Attribute(s) from the Constraint Type drop-down.

5. Select appropriate values for the policy tags.

6. If you want the rule to exclude hosts provisioned with tag values that match the selected tag values, check the Exclude Host Attributes checkbox.

7. Click OK. The selected policy tag values are then assigned to that rule.

8. Click OK.

9. Click Deploy.

How Policy Tags are Evaluated

For every policy rule that has policy tags constraints assigned to a host, the following logic is executed each time the rule is evaluated:

1. HTCC checks the configured policy tag values in the policy, and checks the provisioned policy tag values on the host.

2. If the configured values match the provisioned values, then HTCC proceeds to check the rule’s con-straints.

3. Depending on the rule, operations for that host are allowed or denied. If the rule’s constraint values match the provisioned values on the host, then HTCC enforces the rule on that host. If the host’s values do not match the rule’s constraint values, then the action is not applied to that host.

Note: If the Exclude Constraints direc-tive is used for the rule, the action defined in the rule is applied only to the hosts whose policy tag values do not match the rule’s policy tag constraint values.


Summary

The task of managing security for a virtual cloud is increasingly complex. No one company can provide a com-plete solution. Instead, companies must work together to seamlessly integrate security solutions that establish and maintain trust at each level in the cloud.

Intel, VMware, and HyTrust have teamed to deliver a full trust solution from hardware up through hypervi-sor. Intel, VMware, HyTrust, VCE, and Coalfire have also worked to together to deliver a comprehensive compliance framework for trust. This framework makes effective use of Intel Xeon pro-cessor-based servers, Intel TXT, HTCC, HTDC, VMware vSphere, and bound-ary control capabilities. Combined with configuration best practices, the combined solution and framework are fundamental to addressing and mitigat-ing risk in the virtualized cloud.

Today, many companies, agencies, and alliances are sharing best-known methods and collaborating to ad-dress security and compliance issues. Such collaborations are the strongest method to effectively address today's complex and growing requirements. These collaborations are needed even more, since enterprise is virtualizing more aspects of the network, not just servers. Today, enterprise is extending virtualization to networking and stor-age systems.

The resuls is increased operational effi-ciency, greater agility, more use of com-mon operational tools, and improved management of entire cloud infrastruc-tures. In addition, customers are focus-ing more on enabling software-defined infrastructure to effectively orchestrate and manage their compute, storage, and networking needs.

For example, VMware NSX* is a network virtualization platform for a software-defined data center (SDDC). When you bring the operational model of a virtual machine to your data center network,

it transforms the network. Using a policy-driven management approach can further change the security opera-tions and services attached to VMs. For example, software for the SDDC in-cludes the design of the cloud storage. Because of this, customers who deploy VMware Virtual SAN 6.0 must address associated data-storage regulations, such as HIPAA, PCI-DSS, FedRAMP, and Sarbanes-Oxley.

The increased level of virtualization ex-acerbates security risks and compliance for compute, storage, and networking components. In turn, this highlights the growing need for better trust, man-ageability, security, and compliance solutions for public, private, and hybrid clouds. It is this critical need which the Intel, VMware, and HyTrust solution ad-dresses, providing seamless, integrat-ed, end-to-end trust for the virtualized cloud.

For more information about the ele-ments of a trusted cloud, visit these Web sites:

Intel: www.intel.com

VMware: www.vmware.com/products/vsphere/

HyTrust: www.hytrust.com

For More Information

For more information about the ele-ments of a trusted cloud, as well as for additional documentation, visit these Web sites:

Intel: www.intel.com/cloud



Appendix A: For More Information

Additional Documentation

Detailed product installation and con-figuration information is available from Intel, SoftLayer, VMware, and HyTrust. This deployment guide refers to instal-lation and configuration guides from those companies. You will need to refer to those product guides at certain plac-es in the overall deployment process.

Additional guides are available to help you deploy a trusted cloud infrastruc-ture. For example, the Intel asset tag provisioning guide is available online. Links to these documents are also provided here.

Intel Documentation

Intel® Trusted Cloud Deployment GuideFebruary 2016

http://www.intel.com/txt

The Trusted Cloud Deployment Guide explains requirements, critical consid-erations, and the process for deploying a complete solution for a trusted cloud infrastructure. This guide also provides deployment information for specific use cases.

Intel® Trusted Execution Technology Asset Tag Provisioning Guide May 2015

http://download.intel.com/support/sftw/ds/cit/sb/intelcit20_asset_tag_provisioning_guide.pdf

The Asset Tag Management service leverages Intel TXT-enabled processors to securely write administrator-defined descriptors to hardware. There are two methods for provisioning asset tags: the push method, and the pull method. The push method involves creating an asset certificate using the asset's universal unique identifier (UUID) and a tag selection, and then pushing the cer-tificate from the asset tag service to the asset. The pull method involves booting the asset itself to a provisioning image, which requests a new asset certificate

http://www.intel.com

http://www.vmware.com/products/vsphere/


http://www.hytrust.com

http://www.intel.com/cloud




http://www.intel.com/txt





from the asset tag service using a given selection. This Intel guide explains both methods and how to automate them.

Intel® Trusted Execution Technology Server Platform Matrix http://www.intel.com/content/www/us/en/archi-tecture-and-technology/trusted-exe-cution-technology/trusted-execution-technology-server-platforms-matrix.html

TPM Documentation

TPM Main Specification Level 2 Version 1.2, Revision 116

http://www.trustedcomputinggroup.org/resources/tpm_main_specification

VMware Documentation

Installation and configuration docu-mentation for VMware vCenter, VMware vSphere, and VMware ESXi is available from the VMware Web site:

https://www.vmware.com/support/pubs/

Additional details on vSphere* sup-port for TPM, published by the Trusted Computing Group, are available in the VMware white paper vSphere Security.

Deploy VMware@SoftLayer

http://knowledgelayer.softlayer.com/procedure/deploy-vmwaresoftlayer

HyTrust Documentation

HyTrust Cloud Control Administration Guide

http://docs.hytrust.com/CloudCon-trol/4.6.0/HyTrust_CloudControl_Ad-ministration_Guide.pdf

HyTrust Cloud Control Installation Guide

http://docs.hytrust.com/CloudCon-trol/4.5.0/HyTrust_CloudControl_In-stallation_Guide.pdf

HyTrust Data Control Administration Guide

http://docs.hytrust.com/DataControl/Admin_Guide-3.0/Default.htm

Documentation for Trust and Security Frameworks

NIST IR 7904 Trusted Geolocation in the Cloud: Proof of Concept Implementation

http://dx.doi.org/10.6028/NIST.IR.7904

NIST IR 7904 (Second Draft) 2 3 4; Trusted Geolocation in the Cloud

http://csrc.nist.gov/publications/Pub-sNISTIRs.html

NIST Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Mod-ule Validation Program

http://csrc.nist.gov/groups/STM/cmvp/standards.html

Risk Management Framework NIST Spe-cial Publication 800-37 Revision 1

Follow the links to download the docu-ment, as well as additional reference information.

http://csrc.nist.gov/publications/PubsSPs.html

McAfee Documentation

McAfee Enterprise Security Manager

http://www.mcafee.com/us/products/enterprise-security-manager.aspx

For More Information

For more information about the ele-ments of a trusted cloud, as well as for additional documentation, visit these companies’ Web sites:

Intel: www.intel.com









http://docs.hytrust.com/CloudControl/4.6.0/HyTrust_CloudControl_Administration_Guide.pdf



http://docs.hytrust.com/CloudControl/4.5.0/HyTrust_CloudControl_Installation_Guide.pdf





http://dx.doi.org/10.6028/NIST.IR.7904









http://www.intel.com





APPENDIX B: ACRONYMS

ACRONYM DEFINITION

ACM Authenticated Code Module

AD Active Directory. In this guide, unless otherwise noted, AD refers to Microsoft Active Directory.

admin Administrator. Unless otherwise noted, “admin” in this guide refers to IT administrators working at the virtualization layer.

AES-NI Intel Advanced Encryption Set — New Instructions

AIK Attestation Identity Key

API Application Programming Interface

BIOS Basic Input-Output System

capex Capital Expenditure

CLI Command Line Interface

COBIT Control Objectives for Information and Related Technology

CSA Cloud Security Alliance

DHCP Dynamic Host Configuration Protocol

DNS Domain Name System

DRTM Dynamic Root of Trust for Measurement

ESXi The VMware vSphere hypervisor

EX Endorsement Key

FQDN Fully Qualified Domain Name

GRC Governance, Risk, and Compliance

HA High Availability

HIPAA Health Insurance Portability and Accountability Act

HR Human resources

HTCC HyTrust CloudControl, a virtual appliance

HTDC HyTrust DataControl, a virtual appliance

HTTP Hypertext Transfer Protocol

hypervisor Refers to the VMware ESXi hypervisor

Intel TXT Intel Trusted Execution Technology

IP Internet Protocol

iSCSI Internet Small Computer System Interface

IT Information Technology

KVM Keyboard, Video, and Mouse management server. Unless otherwise noted, this term refers to VMware vCenter

MLE Measured Launch Environment

MOB Managed Object Browser

Appendix B: Acronyms

This appendix lists acronyms that might be used in this document.


NFS Network File System

NIST National Institute of Standards Technology

NTP Network Time Protocol

NVRAM Nonvolatile Random Access Memory

OEM Original Equipment Manufacturer

opex Operational expenditure

OS Operating System

OVF Open Virtualization File

PCI Payment Card Industry

PCR Platform Configuration Register

PIP Published IP

PTR Pointer: a DNS pointer record

PXE Pre-execution Environment

RBAC Role-based Access Control

REST Representational State Transfer

RSA Rivest-Shamir-Adleman cryptosystem; a cryptosystem for public-key encryption

SAN Storage Area Network

SHA Secure Hash Algorithm 1

SIEM Security Information and Event Management

SME Safer Mode Extensions

SRK Storage Root Key

SSH Secure Shell

SSL Secure Sockets Layer, a cryptographic protocol

TA Trust Attestation

TAS Trust Attestation Service

TCG Trusted Computing Group. TCG is an international industry standards group that develops and publishes specifications for use and implementation by the industry.

TFTP Trivial File Transfer Protocol

TPM Trusted Platform Module

UUID Universal Unique Identifier

VIB VMware vSphere Installation Bundle

VLAN Virtual Large Area Network

VM Virtual Machine

VMDK Virtual Machine Disk

VMM Virtual Machine Monitor

VT Virtualization Technology; for example, Intel VT

Solution Blueprint | A Combined Solution for Trust in the Cloud, Provided by Intel®, HyTrust*, and VMware*

DisclaimersNo license (express or implied, by estoppel or otherwise) to any intellectual property rights is granted by this document.

Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade.

Intel technologies’ features and benefits depend on system configuration and may require enabled hardware, software or service activation. Performance varies depending on system configuration. No computer system can be absolutely secure. Check with your system manufacturer or retailer or learn more at Intel.com

This document contains information on products, services and/or processes in development. All information provided here is subject to change without notice. Contact your Intel representative to obtain the latest forecast, schedule, specifications and roadmaps.

Software and workloads used in performance tests may have been optimized for performance only on Intel microprocessors. Performance tests, such as SYSmark and MobileMark, are measured using specific computer systems, components, software, operations and functions. Any change to any of those factors may cause the results to vary. You should consult other information and performance tests to assist you in fully evaluating your contemplated purchases, including the performance of that product when combined with other products. For more complete information visit http://www.intel.com/performance.

Cost reduction scenarios described are intended as examples of how a given Intel- based product, in the specified circumstances and configurations, may affect future costs and provide cost savings. Circum-stances will vary. Intel does not guarantee any costs or cost reduction. Results have been estimated or simulated using internal Intel analysis or architecture simulation or modeling, and provided to you for informational purposes. Any differences in your system hardware, software or configuration may affect your actual performance.

The products and services described may contain defects or errors which may cause deviations from published specifications.

Intel, the Intel logo, Intel Xeon, Intel Virtualization Technology, Intel VT, Intel Trusted Execution Technology, and Intel TXT are trademarks of Intel Corporation in the U.S. and/or other countries.

* Other names and brands may be claimed as the property of others.

© 2016 Intel Corporation. All rights reserved.

Trusted, Compliant Cloud: A Combined Solution for Trust in ...€¦ · establishes trust for secure...

Documents

Transcript of Trusted, Compliant Cloud: A Combined Solution for Trust in ...€¦ · establishes trust for secure...