openstack/openstack-manuals
Code Issues Proposed changes

Merge "Added Intel before references to TXT .. per Intel marketing request."

Browse Source
This commit is contained in:
Jenkins 2013-08-10 00:50:24 +00:00 committed by Gerrit Code Review
commit d18a6cf671
6 changed files with 11 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
doc/src/docbkx/openstack-security/ch008_system-roles-types.xml
View File

@ -22,7 +22,7 @@
</section>
<section xml:id="ch008_system-roles-types-idp53536">
<title>Software Inventory</title>
<para>Just as with hardware, all software components within the OpenStack deployment should be documented. Components here should include system databases; OpenStack software components and supporting sub-components; and, supporting infrastructure software such as load-balancers, reverse proxies and network address translators. Having an authoritative list like this may be critical toward understanding total system impact due to a compromise or vulnerability of a specific class of software.</para>
<para>Just as with hardware, all software components within the OpenStack deployment should be documented. Components here should include system databases; OpenStack software components and supporting sub-components; and, supporting infrastructure software such as load-balancers, reverse proxies, and network address translators. Having an authoritative list like this may be critical toward understanding total system impact due to a compromise or vulnerability of a specific class of software.</para>
</section>
</section>
<section xml:id="ch008_system-roles-types-idp55328">
@ -34,7 +34,7 @@
<para>The Service, Protocols and Ports table provides important
additional detail of an OpenStack deployment. A table view of
all services running within the cloud infrastructure can
immediately inform, guide and check security procedures.
immediately inform, guide, and help check security procedures.
Firewall configuration, service port conflicts, security
remediation areas, and compliance requirements become easier to
manage when you have concise information available. E.g. tabular
@ -46,6 +46,6 @@
<imagedata contentdepth="100%" fileref="static/services-protocols-ports.png" format="PNG" scalefit="1" width="100%"/>
</imageobject>
</inlinemediaobject></para>
<para>Referencing a table of services, protocols and ports can help in understanding the relationship between OpenStack components. It it highly suggested that OpenStack deployments have information similar to this on record.</para>
<para>Referencing a table of services, protocols and ports can help in understanding the relationship between OpenStack components. It is highly recommended that OpenStack deployments have information similar to this on record.</para>
</section>
</chapter>

4
doc/src/docbkx/openstack-security/ch013_node-bootstrapping.xml
View File

@ -5,7 +5,7 @@
<section xml:id="ch013_node-bootstrapping-idp44768">
<title>Secure Bootstrapping</title>
<para>Nodes in the cloud -- including compute, storage, network, service, and hybrid nodes -- should have an automated provisioning process. This ensures that nodes are provisioned consistently and correctly. This also facilitates security patching, upgrading, bug fixing, and other critical changes. Since this process installs new software that runs at the highest privilege levels in the cloud, it is important to verify that the correct software is installed. This includes the earliest stages of the boot process.</para>
<para>There are a variety of technologies that enable verification of these early boot stages. These typically require hardware support such as the trusted platform module (TPM), trusted execution technologies (TXT), dynamic root of trust measurement (DRTM), and Unified Extensible Firmware Interface (UEFI) secure boot. In this book, we will refer to all of these collectively as <emphasis>secure boot technologies</emphasis>. We recommend using secure boot, while acknowledging that many of the pieces necessary to deploy this require advanced technical skills in order to customize the tools for each environment. Utilizing secure boot will require deeper integration and customization than many of the other recommendations in this guide. TPM technology, while common in most business class laptops and desktops for several years, is not found in all servers. Proper planning is essential to a successful secure boot deployment.</para>
<para>There are a variety of technologies that enable verification of these early boot stages. These typically require hardware support such as the trusted platform module (TPM), Intel Trusted Execution Technology (TXT), dynamic root of trust measurement (DRTM), and Unified Extensible Firmware Interface (UEFI) secure boot. In this book, we will refer to all of these collectively as <emphasis>secure boot technologies</emphasis>. We recommend using secure boot, while acknowledging that many of the pieces necessary to deploy this require advanced technical skills in order to customize the tools for each environment. Utilizing secure boot will require deeper integration and customization than many of the other recommendations in this guide. TPM technology, while common in most business class laptops and desktops for several years, and is now becoming available in servers together with supporting BIOS. Proper planning is essential to a successful secure boot deployment.</para>
<para>A complete tutorial on secure boot deployment is beyond the scope of this book. Instead, here we provide a framework for how to integrate secure boot technologies with the typical node provisioning process. For additional details, cloud architects should refer to the related specifications and software configuration manuals.</para>
<section xml:id="ch013_node-bootstrapping-idp48720">
<title>Node Provisioning</title>
@ -94,7 +94,7 @@
</tbody>
</informaltable>
<para>At the time of this writing, very few clouds are using secure boot technologies in a production environment. As a result, these technologies are still somewhat immature. We recommend planning carefully in terms of hardware selection (e.g., ensure that you have a TPM and TXT support). Then verify how the node hardware vendor populates the PCR values (e.g., which values will be available for validation). Typically the PCR values listed under the software context in the table above are the ones that a cloud architect has direct control over. But even these may change as the software in the cloud is upgraded.  Configuration management should be linked into the PCR policy engine to ensure that the validation is always up to date.</para>
<para>At the time of this writing, very few clouds are using secure boot technologies in a production environment. As a result, these technologies are still somewhat immature. We recommend planning carefully in terms of hardware selection (e.g., ensure that you have a TPM and Intel TXT support). Then verify how the node hardware vendor populates the PCR values (e.g., which values will be available for validation). Typically the PCR values listed under the software context in the table above are the ones that a cloud architect has direct control over. But even these may change as the software in the cloud is upgraded.  Configuration management should be linked into the PCR policy engine to ensure that the validation is always up to date.</para>
<para>Each manufacturer must provide the BIOS and firmware code for their servers. Different servers, hypervisors, and operating systems will choose to populate different PCRs.  In most real world deployments, it will be impossible to validate every PCR against a known good quantity ("golden measurement"). Experience has shown that, even within a single vendor's product line, the measurement process for a given PCR may not be consistent. We recommend establishing a baseline for each server and monitoring the PCR values for unexpected changes. Third-party software may be available to assist in the TPM provisioning and monitoring process, depending upon your chosen hypervisor solution.</para>
<para>The initial program loader (IPL) code will most likely be the PXE firmware, assuming the node deployment strategy outlined above. Therefore, the secure boot or boot attestation process can measure all of the early stage boot code (e.g., bios, firmware, etc), the PXE firmware, and the node kernel. Ensuring that each node has the correct versions of these pieces installed provides a solid foundation on which to build the rest of the node software stack.</para>
<para>Depending on the strategy selected, in the event of a failure the node will either fail to boot or it can report the failure back to another entity in the cloud. For secure boot, the node will fail to boot and a provisioning service within the management security domain must recognize this and log the event. For boot attestation, the node will already be running when the failure is detected. In this case the node should be immediately quarantined by disabling its network access. Then the event should be analyzed for the root cause. In either case, policy should dictate how to proceed after a failure. A cloud may automatically attempt to reprovision a node a certain number of times. Or it may immediately notify a cloud administrator to investigate the problem. The right policy here will be deployment and failure mode specific.</para>

2
doc/src/docbkx/openstack-security/ch015_case-studies-management.xml
View File

@ -18,7 +18,7 @@
<section xml:id="ch015_case-studies-management-idp48432">
<title>Alice's Private Cloud</title>
<para>When building her private cloud, while air-gapped, Alice still needs to consider her service management interfaces. Before deploying her private cloud, Alice has completed her system documentation. Specifically she has identified which OpenStack services will exist in each security domain. From there Alice has further restricted access to management interfaces by deploying a combination of IDS, SSL encryption, and physical network isolation. Additionally, Alice requires high availability and redundant services. Thus, Alice sets up redundant infrastructure for various OpenStack API services.</para>
<para>Alice also needs to provide assurances that the physical servers and hypervisors have been built from a known secure state into a well-defined configuration. To enable this, Alice uses a combination of a Configuration Management platform to configure each machine according to the standards and regulations she must comply with. It will also enable Alice to report periodically on the state of her cloud and perform remediation to a known state should anything be out of the ordinary. Additionally, Alice provides hardware assurances by using a PXE system to build her nodes from a known set of base images. During the boot process, Alice provides further assurances by enabling TXT and related trusted boot technologies provided by the hardware.</para>
<para>Alice also needs to provide assurances that the physical servers and hypervisors have been built from a known secure state into a well-defined configuration. To enable this, Alice uses a combination of a Configuration Management platform to configure each machine according to the standards and regulations she must comply with. It will also enable Alice to report periodically on the state of her cloud and perform remediation to a known state should anything be out of the ordinary. Additionally, Alice provides hardware assurances by using a PXE system to build her nodes from a known set of base images. During the boot process, Alice provides further assurances by enabling Intel TXT and related trusted boot technologies provided by the hardware.</para>
</section>
<section xml:id="ch015_case-studies-management-idp51424">
<title>Bob's Public Cloud</title>

6
doc/src/docbkx/openstack-security/ch051_vss-intro.xml
View File

@ -237,8 +237,8 @@
<td><para>Required for protecting PCI-passthrough</para></td>
</tr>
<tr>
<td><para>Trusted Execution Technology</para></td>
<td><para>TXT / SEM</para></td>
<td><para>Intel Trusted Execution Technology</para></td>
<td><para>Intel TXT / SEM</para></td>
<td><para>Required for dynamic attestation services</para></td>
</tr>
<tr>
@ -264,7 +264,7 @@
</section>
<section xml:id="ch051_vss-intro-idp401408">
<title>Additional Security Features</title>
<para>Another thing to look into when selecting a hypervisor platform is the availability of specific security features. In particular, we are referring to features like Xen Server's XSM or Xen Security Modules, sVirt, TXT, and AppArmor. The presence of these features will help increase your security profile as well as provide a good foundation.</para>
<para>Another thing to look into when selecting a hypervisor platform is the availability of specific security features. In particular, we are referring to features like Xen Server's XSM or Xen Security Modules, sVirt, Intel TXT, and AppArmor. The presence of these features will help increase your security profile as well as provide a good foundation.</para>
<para>The following table calls out these features by common hypervisor platforms. </para>
<informaltable rules="all" width="80%"><colgroup><col/><col/><col/><col/><col/><col/><col/><col/></colgroup>

2
doc/src/docbkx/openstack-security/ch053_case-studies-instance-isolation.xml
View File

@ -6,7 +6,7 @@
<title>Alice's Private Cloud</title>
<para>Alice chooses Xen for the hypervisor in her cloud due to a strong internal knowledge base and a desire to use the Xen security modules (XSM) for fine-grained policy enforcement.</para>
<para>Alice is willing to apply a relatively large amount of resources to software packaging and maintenance. She will use these resources to build a highly customized version of QEMU that has many components removed, thereby reducing the attack surface. She will also ensure that all compiler hardening options are enabled for QEMU. Alice accepts that these decisions will increase long-term maintenance costs.</para>
<para>Alice writes XSM policies (for Xen) and SELinux policies (for Linux domain 0, and device domains) to provide stronger isolation between the instances. Alice also uses the TXT support in Xen to measure the hypervisor launch in the TPM.</para>
<para>Alice writes XSM policies (for Xen) and SELinux policies (for Linux domain 0, and device domains) to provide stronger isolation between the instances. Alice also uses the Intel TXT support in Xen to measure the hypervisor launch in the TPM.</para>
</section>
<section xml:id="ch053_case-studies-instance-isolation-idp482832">
<title>Bob's Public Cloud</title>

2
doc/src/docbkx/openstack-security/ch055_security-services-for-instances.xml
View File

@ -57,7 +57,7 @@
</section>
<section xml:id="ch055_security-services-for-instances-idp148000">
<title>Trusted Compute Pools</title>
<para>There exists a scheduler filter which integrates with the Open Attestation Project (OATS, https://github.com/OpenAttestation/OpenAttestation) to define scheduler behavior according to the attestation of PCRs received from a system using TXT.</para>
<para>There exists a scheduler filter which integrates with the Open Attestation Project (OATS, https://github.com/OpenAttestation/OpenAttestation) to define scheduler behavior according to the attestation of PCRs received from a system using Intel TXT.</para>
<para>It is unclear if this feature is compatible with AMD's similar SEM, although the OpenAttestation agent relies on the vendor-agnostic TrouSerS library (http://trousers.sourceforge.net/).</para>
</section>
</section>