openstack/openstack-manuals
Code Issues Proposed changes

Security Guide: Markup of links

Browse Source 
The guide does not use markup of links at all, I've started adding
markup to the first chapters. I've also did some minor cleanups I
noticed.

Patch set 2:
Diane, thanks for the review, I've followed all your suggestions.

Patch set 3:
I've fixed the name of the OpenStack Compute Adminstration Guide
everywhere in my patch set.

Patch set 4:
Fix whitespace

Patch set 5:
Fix remaining chapters

Change-Id: I3c11aab2bafadd7f2ee3742fbfcaa7f937102d0d
This commit is contained in:
Andreas Jaeger 2013-08-09 21:14:59 +02:00
parent 254cb26e31
commit 7f3e118dc0
29 changed files with 191 additions and 169 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
doc/src/docbkx/openstack-security/ch002_why-and-how-we-wrote-this-book.xml
View File

@ -2,7 +2,7 @@
<chapter xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://docbook.org/ns/docbook" xmlns:db="http://docbook.org/ns/docbook" version="5.0" xml:id="ch002_why-and-how-we-wrote-this-book"><?dbhtml stop-chunking?>
<title>Why and How We Wrote This Book</title>
<para>As OpenStack adoption continues to grow and mature, security has become a priority.  The OpenStack Security Group has recognized the need for a comprehensive and authoritative security guide. The <emphasis role="bold">OpenStack Security Guide</emphasis> has been written to provide an overview of security best practices, guidelines, and recommendations for increasing the security of an OpenStack deployment. The authors bring their expertise from deploying and securing OpenStack in a variety of environments.</para>
<para>The guide augments the OpenStack Operations Guide (http://docs.openstack.org/ops/) and can be referenced to harden existing OpenStack deployments or to evaluate the security controls of OpenStack cloud providers.</para>
<para>The guide augments the <link xlink:href="http://docs.openstack.org/ops/"><citetitle>OpenStack Operations Guide</citetitle></link> and can be referenced to harden existing OpenStack deployments or to evaluate the security controls of OpenStack cloud providers.</para>
<section xml:id="ch002_why-and-how-we-wrote-this-book-idp117696">
<title>Objectives</title>
<itemizedlist><listitem>
@ -98,7 +98,9 @@
brings together a group to produce a book in 3-5 days. It is a
strongly facilitated process with a specific methodology founded
and developed by Adam Hyde. For more information visit the book
sprint web page at http://www.booksprints.net.</para>
sprint web page at
<link xlink:href="http://www.booksprints.net">http://www.booksprints.net</link>.
</para>
</section>
<section xml:id="ch002_why-and-how-we-wrote-this-book-idp150816">
<title>How to Contribute to This Book</title>
@ -106,6 +108,7 @@
air-conditioned room that served as our group office for the
entirety of the documentation sprint.</para>
<para>Learn more about how to contribute to the OpenStack
docs: (http://wiki.openstack.org/Documentation/HowTo).</para>
docs: <link xlink:href="http://wiki.openstack.org/Documentation/HowTo">http://wiki.openstack.org/Documentation/HowTo</link>.
</para>
</section>
</chapter>

6
doc/src/docbkx/openstack-security/ch004_book-introduction.xml
View File

@ -6,7 +6,7 @@
<para>We briefly introduce the kinds of clouds: private, public, and hybrid before presenting an overview of the OpenStack components and their related security concerns in the remainder of the chapter.</para>
<section xml:id="ch004_book-introduction-idp117824">
<title>Cloud Types</title>
<para>OpenStack is a key enabler in adoption of cloud technology and has several common deployment use cases. These are commonly known as Public, Private, and Hybrid models. The following sections use the National Institute of Standards and Technology (NIST) definition of cloud (http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf) to introduce these different types of cloud as they apply to OpenStack.</para>
<para>OpenStack is a key enabler in adoption of cloud technology and has several common deployment use cases. These are commonly known as Public, Private, and Hybrid models. The following sections use the National Institute of Standards and Technology (NIST) <link xlink:href="http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf">definition of cloud</link> to introduce these different types of cloud as they apply to OpenStack.</para>
<section xml:id="ch004_book-introduction-idp119328">
<title>Public Cloud</title>
<para>According to NIST, a public cloud is one in which the infrastructure is open to the general public for consumption. OpenStack public clouds are typically run by a service provider and can be consumed by individuals, corporations, or any paying customer. A public cloud provider may expose a full set of features such as software defined networking, block storage, in addition to multiple instance types. Due to the nature of public clouds, they will be exposed to a higher degree of risk. As a consumer of a public cloud you should validate that your selected provider has the necessary certifications, attestations, and other regulatory considerations. As a public cloud provider, depending on your target customers, you may be subject to one or more regulations. Additionally, even if not required to meet regulatory requirements, a provider should ensure tenant isolation as well as protecting management infrastructure from external attacks.</para>
@ -40,8 +40,8 @@
<para>OpenStack compute (Nova) provides services to support the management of virtual machine instances at scale, instances that host multi-tiered applications, dev/test environments, "Big Data" crunching Hadoop clusters, and/or high performance computing.</para>
<para>Nova facilitates this management through an abstraction layer that interfaces with supported hypervisors, which we address later on in more detail.</para>
<para>Later in the guide, we will focus generically on the virtualization stack as it relates to hypervisors.</para>
<para>Also refer to the OpenStack's Hypervisor Support Matrix for the current state of feature support at https://wiki.openstack.org/wiki/HypervisorSupportMatrix</para>
<para>The security of Nova is critical for an OpenStack deployment.  Hardening techniques should include support for strong instance isolation, secure communication between Nova sub-components, and resiliency of public facing API endpoints.</para>
<para>For information about the current state of feature support, see <link xlink:href="https://wiki.openstack.org/wiki/HypervisorSupportMatrix">OpenStack's Hypervisor Support Matrix</link>.</para>
<para>The security of Nova is critical for an OpenStack deployment. Hardening techniques should include support for strong instance isolation, secure communication between Nova sub-components, and resiliency of public facing API endpoints.</para>
</section>
<section xml:id="ch004_book-introduction-idp138800">
<title>OpenStack Object Storage</title>

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

@ -5,7 +5,7 @@
<section xml:id="ch009_case-studies-idp44480">
<title>Alice's Private Cloud</title>
<para>Alice needs detailed documentation to satisfy FedRamp requirements.  She sets up a configuration management database (CMDB) to store information regarding all of the hardware, firmware, and software versions used throughout the cloud. She also creates a network diagram detailing the cloud architecture, paying careful attention to the security domains and the services that span multiple security domains.</para>
<para>Alice also needs to record each network service running in the cloud, what interfaces and ports it binds to, the security domains for each service, and why the service is needed. Alice decides to build automated tools to log into each system in the cloud over secure shell (SSH) using the Python Fabric library (http://fabfile.org). The tools collect all of this information and store it into the CMDB to help simplify the audit process.</para>
<para>Alice also needs to record each network service running in the cloud, what interfaces and ports it binds to, the security domains for each service, and why the service is needed. Alice decides to build automated tools to log into each system in the cloud over secure shell (SSH) using the <link xlink:href="http://fabfile.org">Python Fabric library</link>. The tools collect and store the information in the CMDB, which simplifies the audit process.</para>
</section>
<section xml:id="ch009_case-studies-idp47344">
<title>Bob's Public Cloud</title>

31
doc/src/docbkx/openstack-security/ch012_configuration-management.xml
View File

@ -4,10 +4,27 @@
<para>A cloud will always have bugs. Some of these will be security problems. For this reason, it is critically important to be prepared to apply security updates and general software updates. This involves smart use of configuration management tools, which are discussed below. This also involves knowing when an upgrade is necessary.</para>
<section xml:id="ch012_configuration-management-idp44720">
<title>Vulnerability Management</title>
<para>There is an OpenStack Announce mailing list (http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce) that you should subscribe to for announcements regarding security relevant changes. The security notifications are also posted through the downstream packages (e.g., through Linux distributions) that you may be subscribed to as part of the package updates.</para>
<para>For announcements regarding security relevant changes,
subscribe to the <link
xlink:href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce">OpenStack
Announce mailing list</link>.
The security notifications are also posted through the downstream packages for example through Linux distributions that you may be subscribed to as part of the package updates.</para>
<para>The OpenStack components are only a small fraction of the software in a cloud. It is important to keep up to date with all of these other components, too. While the specific data sources will be deployment specific, the key idea is to ensure that a cloud administrator subscribes to the necessary mailing lists for receiving notification of any related security updates. Often this is as simple as tracking an upstream Linux distribution.</para>
<para>NOTE: OpenStack releases security information through two channels. OpenStack Security Advisories (OSSA) are created by the OpenStack Vulnerability Management Team (VMT). They pertain to security holes in core OpenStack services. More information on the VMT can be found here: https://wiki.openstack.org/wiki/Vulnerability_Management</para>
<para>OpenStack Security Notes (OSSN) were created by the OpenStack Security Group (OSSG) to support the work of the VMT. OSSN address issues in supporting software and common deployment configurations. They're referenced throughout this guide. Security Notes are archived at: https://launchpad.net/ossn/</para>
<note><para>OpenStack releases security information through two
channels.
<itemizedlist><listitem><para>OpenStack Security Advisories (OSSA) are created by
the OpenStack Vulnerability Management Team (VMT). They pertain
to security holes in core OpenStack services. More information
on the VMT can be found here: <link xlink:href="https://wiki.openstack.org/wiki/Vulnerability_Management">https://wiki.openstack.org/wiki/Vulnerability_Management</link></para></listitem>
<listitem><para>OpenStack Security Notes (OSSN) were created by the
OpenStack Security Group (OSSG) to support the work of the
VMT. OSSN address issues in supporting software and common
deployment configurations. They're referenced throughout this
guide. Security Notes are archived at <link xlink:href="https://launchpad.net/ossn/">https://launchpad.net/ossn/</link></para>
</listitem>
</itemizedlist>
</para>
</note>
<section xml:id="ch012_configuration-management-idp48592">
<title>Triage</title>
<para>After receiving notification about a security update, the next step is to determine how critical this update is to a given cloud deployment. In this case, it is useful to have a pre-defined policy. Existing vulnerability rating systems such as the common vulnerability scoring system (CVSS) v2 do not properly account for cloud deployments. The table below provides an example scoring matrix.</para>
@ -125,20 +142,20 @@
<section xml:id="ch012_configuration-management-idp128032">
<title>References</title>
<itemizedlist><listitem>
<para>http://docs.openstack.org/folsom/openstack-ops/content/backup_and_recovery.html</para>
<para><citetitle>OpenStack Operations Guide</citetitle> on <link xlink:href="http://docs.openstack.org/folsom/openstack-ops/content/backup_and_recovery.html">backup and recovery</link></para>
</listitem>
<listitem>
<para>http://www.sans.org/reading_room/whitepapers/backup/security-considerations-enterprise-level-backups_515</para>
<para><link xlink:href="http://www.sans.org/reading_room/whitepapers/backup/security-considerations-enterprise-level-backups_515">http://www.sans.org/reading_room/whitepapers/backup/security-considerations-enterprise-level-backups_515</link></para>
</listitem>
<listitem>
<para>http://www.music-piracy.com/?p=494 (OpenStack Security Primer) </para>
<para><link xlink:href="http://www.music-piracy.com/?p=494">OpenStack Security Primer</link></para>
</listitem>
</itemizedlist>
</section>
</section>
<section xml:id="ch012_configuration-management-idp131856">
<title>Security Auditing Tools</title>
<para>Security auditing tools can complement the configuration management tools.  Security auditing tools automate the process of verifying that a large number of security controls are satisfied for a given system configuration. These tools help to bridge the gap from security configuration guidance documentation (e.g., the STIG and NSA Guides) to a specific system installation. For example, SCAP (https://fedorahosted.org/scap-security-guide/) can compare a running system to a pre-defined profile.  SCAP outputs a report detailing which controls in the profile were satisfied, which ones failed, and which ones were not checked.</para>
<para>Security auditing tools can complement the configuration management tools.  Security auditing tools automate the process of verifying that a large number of security controls are satisfied for a given system configuration. These tools help to bridge the gap from security configuration guidance documentation (for example, the STIG and NSA Guides) to a specific system installation. For example, <link xlink:href="https://fedorahosted.org/scap-security-guide/">SCAP</link> can compare a running system to a pre-defined profile. SCAP outputs a report detailing which controls in the profile were satisfied, which ones failed, and which ones were not checked.</para>
<para>Combining configuration management and security auditing tools creates a powerful combination. The auditing tools will highlight deployment concerns. And the configuration management tools simplify the process of changing each system to address the audit concerns. Used together in this fashion, these tools help to maintain a cloud that satisfies security requirements ranging from basic hardening to compliance validation.</para>
<para>Configuration management and security auditing tools will introduce another layer of complexity into the cloud.  This complexity brings with it additional security concerns. We view this as an acceptable risk trade-off, given their security benefits. Securing the operational use of these tools is beyond the scope of this guide.</para>
</section>

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

@ -17,7 +17,7 @@
<imagedata contentdepth="100%" fileref="static/node-provisioning-pxe.png" format="PNG" scalefit="1" width="100%"/>
</imageobject>
</inlinemediaobject></para>
<para>We recommend using a separate, isolated network within the management security domain for provisioning. This network will handle all PXE traffic, along with the subsequent boot stage downloads depicted above. Note that the node boot process begins with two insecure operations: DHCP and TFTP. Then it downloads subsequent stages (e.g., an initramfs, kernel, etc) over SSL. This concludes by downloading the remaining information needed to deploy the node. This may be an operating system installer, a basic install managed by Chef (http://www.opscode.com/chef/) or Puppet (https://puppetlabs.com/), or even a complete file system image that is written directly to disk.</para>
<para>We recommend using a separate, isolated network within the management security domain for provisioning. This network will handle all PXE traffic, along with the subsequent boot stage downloads depicted above. Note that the node boot process begins with two insecure operations: DHCP and TFTP. Then the boot process downloads over SSL the remaining information required to deploy the node. This information might include an initramfs and a kernel. This concludes by downloading the remaining information needed to deploy the node. This may be an operating system installer, a basic install managed by <link xlink:href="http://www.opscode.com/chef/">Chef</link> or <link xlink:href="https://puppetlabs.com/">Puppet</link>, or even a complete file system image that is written directly to disk.</para>
<para>While utilizing SSL during the PXE boot process is somewhat more challenging, common PXE firmware projects (e.g., iPXE) provide this support. Typically this involves building the PXE firmware with knowledge of the allowed SSL certificate chain(s) so that it can properly validate the server certificate.  This raises the bar for an attacker by limiting the number of insecure, plaintext network operations.</para>
</section>
<section xml:id="ch013_node-bootstrapping-idp58144">
@ -101,7 +101,7 @@
</section>
<section xml:id="ch013_node-bootstrapping-idp3728">
<title>Node Hardening</title>
<para>At this point we know that the node has booted with the correct kernel and underlying components. There are many paths for hardening a given operating system deployment. The specifics on these steps are outside of the scope of this book.  We recommend following the guidance from a hardening guide specific to your operating system.  For example, the security technical implementation guides (STIG, http://iase.disa.mil/stigs/) and the NSA guides (http://www.nsa.gov/ia/mitigation_guidance/security_configuration_guides/) are useful starting places.</para>
<para>At this point we know that the node has booted with the correct kernel and underlying components. There are many paths for hardening a given operating system deployment. The specifics on these steps are outside of the scope of this book.  We recommend following the guidance from a hardening guide specific to your operating system.  For example, the <link xlink:href="http://iase.disa.mil/stigs/">security technical implementation guides</link> (STIG) and the <link xlink:href="http://www.nsa.gov/ia/mitigation_guidance/security_configuration_guides/">NSA guides</link> are useful starting places.</para>
<para>The nature of the nodes makes additional hardening possible. We recommend the following additional steps for production nodes:</para>
<itemizedlist><listitem>
<para>Use a read-only file system where possible. Ensure that writeable file systems do not permit execution.  This can be handled through the mount options provided in <literal>/etc/fstab</literal>.</para>
@ -113,7 +113,7 @@
<para>Remove any unnecessary software packages. This should result in a very stripped down installation because a compute node has a relatively small number of dependencies.</para>
</listitem>
</itemizedlist>
<para>Finally, the node kernel should have a mechanism to validate that the rest of the node starts in a known good state. This provides the necessary link from the boot validation process to validating the entire system. The steps for doing this will be deployment specific. As an example, a kernel module could verify a hash over the blocks comprising the file system before mounting it using dm-verity (https://code.google.com/p/cryptsetup/wiki/DMVerity).</para>
<para>Finally, the node kernel should have a mechanism to validate that the rest of the node starts in a known good state. This provides the necessary link from the boot validation process to validating the entire system. The steps for doing this will be deployment specific. As an example, a kernel module could verify a hash over the blocks comprising the file system before mounting it using <link xlink:href="https://code.google.com/p/cryptsetup/wiki/DMVerity">dm-verity</link>.</para>
</section>
</section>
<section xml:id="ch013_node-bootstrapping-idp11376">
@ -126,20 +126,20 @@
<para>False positives occur when the security monitoring tool produces a security alert for a benign event. Due to the nature of security monitoring tools, false positives will most certainly occur from time to time. Typically a cloud administrator can tune security monitoring tools to reduce the false positives, but this may also reduce the overall detection rate at the same time. These classic trade-offs must be understood and accounted for when setting up a security monitoring system in the cloud.</para>
<para>The selection and configuration of a host-based intrusion detection tool is highly deployment specific. We recommend starting by exploring the following open source projects which implement a variety of host-based intrusion detection and file monitoring features.</para>
<itemizedlist><listitem>
<para>OSSEC (http://www.ossec.net/)</para>
<para><link xlink:href="http://www.ossec.net/">OSSEC</link></para>
</listitem>
<listitem>
<para>Samhain (http://la-samhna.de/samhain/)</para>
<para><link xlink:href="http://la-samhna.de/samhain/">Samhain</link></para>
</listitem>
<listitem>
<para>Tripwire (http://sourceforge.net/projects/tripwire/)</para>
<para><link xlink:href="http://sourceforge.net/projects/tripwire/">Tripwire</link></para>
</listitem>
<listitem>
<para>AIDE (http://aide.sourceforge.net/)</para>
<para><link xlink:href="http://aide.sourceforge.net/">AIDE</link></para>
</listitem>
</itemizedlist>
<para>Network intrusion detection tools complement the host-based tools. OpenStack doesn't have a specific network IDS built-in, but OpenStack's networking component, Neutron, provides a plugin mechanism to enable different technologies via the Neutron API. This plugin architecture will allow tenants to develop API extensions to insert and configure their own advanced networking services like a firewall, an intrusion detection system, or a VPN between the VMs.</para>
<para>Similar to host-based tools, the selection and configuration of a network-based intrusion detection tool is deployment specific. Snort (http://www.snort.org/) is the leading open source networking intrusion detection tool, and a good starting place to learn more.</para>
<para>Similar to host-based tools, the selection and configuration of a network-based intrusion detection tool is deployment specific. <link xlink:href="http://www.snort.org/">Snort</link> is the leading open source networking intrusion detection tool, and a good starting place to learn more.</para>
<para>There are a few important security considerations for network and host-based intrusion detection systems.</para>
<itemizedlist><listitem>
<para>It is important to consider the placement of the Network IDS on the cloud (e.g., adding it to the network boundary and/or around sensitive networks). The placement depends on your network environment but make sure to monitor the impact the IDS may have on your services depending on where you choose to add it. Encrypted traffic, such as SSL, cannot generally be inspected for content by a Network IDS. However, the Network IDS may still provide some benefit in identifying anomalous unencrypted traffic on the network.</para>

8
doc/src/docbkx/openstack-security/ch014_best-practices-for-operator-mode-access.xml
View File

@ -62,7 +62,7 @@
</section>
<section xml:id="ch014_best-practices-for-operator-mode-access-idp62384">
<title>References</title>
<para>Grizzly Release Notes - https://wiki.openstack.org/wiki/ReleaseNotes/Grizzly</para>
<para><link xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/Grizzly"><citetitle>Grizzly Release Notes</citetitle></link></para>
</section>
</section>
<section xml:id="ch014_best-practices-for-operator-mode-access-idp63760">
@ -121,8 +121,8 @@
</section>
<section xml:id="ch014_best-practices-for-operator-mode-access-idp80496">
<title>References</title>
<para>http://docs.openstack.org/cli/quick-start/content/client_overview.html</para>
<para>http://docs.openstack.org/cli/quick-start/content/getting_credentials_cli.html</para>
<para><citetitle>OpenStack End User Guide</citetitle> section <link xlink:href="http://docs.openstack.org/user-guide/content/section_cli_overview.html">command line clients overview</link></para>
<para><citetitle>OpenStack End User Guide</citetitle> section <link xlink:href="http://docs.openstack.org/cli/quick-start/content/cli_openrc.html">OpenStack RC file</link></para>
</section>
</section>
<section xml:id="ch014_best-practices-for-operator-mode-access-idp82336">
@ -147,7 +147,7 @@
</section>
<section xml:id="ch014_best-practices-for-operator-mode-access-idp89920">
<title>References</title>
<para>Hacking servers that are turned off - https://isc.sans.edu/diary/IPMI%3A+Hacking+servers+that+are+turned+%22off%22/13399</para>
<para><link xlink:href="https://isc.sans.edu/diary/IPMI%3A+Hacking+servers+that+are+turned+%22off%22/13399">Hacking servers that are turned off</link></para>
</section>
</section>
</chapter>

14
doc/src/docbkx/openstack-security/ch017_threat-models-confidence-and-confidentiality.xml
View File

@ -32,28 +32,28 @@
<title>Cryptographic Algorithms, Cipher Modes, and Protocols</title>
<para>We recommend only using TLS v1.1 or v1.2, but suggest SSLv3 and TLSv1.0 may be used for compatibility. Other SSL/TLS versions, explicitly older versions, should not be used. These older versions include SSLv1 and SSLv2. As this book does not intend to be a thorough reference on cryptography we do not wish to be prescriptive about what specific algorithms or cipher modes you should enable or disable in your OpenStack services. However, there are some authoritative references we would like to recommend for further information:</para>
<itemizedlist><listitem>
<para>National Security Agency, Suite B Cryptography - http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml</para>
<para><link xlink:href="http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml">National Security Agency, Suite B Cryptography</link></para>
</listitem>
<listitem>
<para>OWASP Guide to Cryptography - https://www.owasp.org/index.php/Guide_to_Cryptography</para>
<para><link xlink:href="https://www.owasp.org/index.php/Guide_to_Cryptography">OWASP Guide to Cryptography</link></para>
</listitem>
<listitem>
<para>OWASP Transport Layer Protection Cheat Sheet - https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet</para>
<para><link xlink:href="https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet">OWASP Transport Layer Protection Cheat Sheet</link></para>
</listitem>
<listitem>
<para>http://www.ieee-security.org/TC/SP2013/papers/4977a511.pdf</para>
<para><link xlink:href="http://www.ieee-security.org/TC/SP2013/papers/4977a511.pdf">SoK: SSL and HTTPS: Revisiting past challenges and evaluating certificate trust model enhancements</link></para>
</listitem>
<listitem>
<para>http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf</para>
<para><link xlink:href="http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf">The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software</link></para>
</listitem>
<listitem>
<para>http://www.openssl.org/docs/fips/fipsnotes.html</para>
<para><link xlink:href="http://www.openssl.org/docs/fips/fipsnotes.html">OpenSSL and FIPS 140-2</link></para>
</listitem>
</itemizedlist>
</section>
<section xml:id="ch017_threat-models-confidence-and-confidentiality-idp64128">
<title>Summary</title>
<para>It is important to note given the many components that make up OpenStack and the different deployment and implementation choices, care should be taken to look at each component to ensure the appropriate configuration of SSL certificates, keys, and CAs. The following services will be discussed in later sections of this book where SSL and PKI is available (either natively or possible via SSL proxy):</para>
<para>Given the complexity of the OpenStack components and the number of deployment possibilities, you must take care to ensure that each component gets the appropriate configuration of SSL certificates, keys, and CAs. The following services will be discussed in later sections of this book where SSL and PKI is available (either natively or possible via SSL proxy):</para>
<itemizedlist><listitem>
<para>Compute API endpoints</para>
</listitem>

10
doc/src/docbkx/openstack-security/ch020_ssl-everywhere.xml
View File

@ -4,16 +4,16 @@
<para>OpenStack endpoints are HTTP services providing APIs to both end-users on public networks and to other OpenStack services within the same deployment operating over the management network. It is highly recommended these requests, both those internal and external, operate over SSL.</para>
<para>In order for API requests to be encrypted by SSL it's necessary to position the API services behind a proxy that will establish and terminate SSL sessions. The following table offers a non-exhaustive list of software services that can proxy SSL traffic for API requests:</para>
<itemizedlist><listitem>
<para>Pound (http://www.apsis.ch/pound)</para>
<para><link xlink:href="http://www.apsis.ch/pound">Pound</link></para>
</listitem>
<listitem>
<para>Stud (https://github.coapm/bumptech/stud)</para>
<para><link xlink:href="https://github.coapm/bumptech/stud">Stud</link></para>
</listitem>
<listitem>
<para>nginx (http://nginx.org/)</para>
<para><link xlink:href="http://nginx.org/">nginx</link></para>
</listitem>
<listitem>
<para>Apache httpd (http://www.apache.org/)</para>
<para><link xlink:href="http://www.apache.org/">Apache httpd</link></para>
</listitem>
<listitem>
<para>Hardware appliance SSL acceleration proxies</para>
@ -179,7 +179,7 @@ server {
<section xml:id="ch020_ssl-everywhere-idp59152">
<title>HTTP Strict Transport Security</title>
<para>We recommend that all production deployments use HSTS. This header prevents browsers from making insecure connections after they have made a single secure one. If you have deployed your HTTP services on a public or an untrusted domain, HSTS is especially important. To enable HSTS, configure your web server to send a header like this with all requests:</para>
<screen> 
<screen>
Strict-Transport-Security: max-age=31536000; includeSubDomains</screen>
<para>Start with a short timeout of 1 day during testing, and raise it to one year after testing has shown that you haven't introduced problems for users. Note that once this header is set to a large timeout, it is (by design) very difficult to disable.</para>
</section>

5
doc/src/docbkx/openstack-security/ch021_paste-and-middleware.xml
View File

@ -35,7 +35,7 @@ s3_use_ssl=True</screen>
</section>
<section xml:id="ch021_paste-and-middleware-idp47184">
<title>Configuration Example #2: Cinder</title>
<screen> 
<screen>
glance_host='https://glance-server'</screen>
</section>
</section>
@ -44,7 +44,8 @@ glance_host='https://glance-server'</screen>
<title>Paste and Middleware</title>
<para>Most API endpoints and other HTTP services in OpenStack utilize the Python Paste Deploy library. This is important to understand from a security perspective as it allows for manipulation of the request filter pipeline through the application's configuration. Each element in this chain is referred to as <emphasis>middleware</emphasis>. Changing the order of filters in the pipeline or adding additional middleware may have unpredictable security impact.</para>
<para>It is not uncommon that implementors will choose to add additional middleware to extend OpenStack's base functionality. We recommend implementors make careful consideration of the potential exposure introduced by the addition of non-standard software components to their HTTP request pipeline.</para>
<para>Additional information on Paste Deploy may be found at http://pythonpaste.org/deploy/.</para>
<para>Additional information on Paste Deploy may be found at
<link xlink:href="http://pythonpaste.org/deploy/">http://pythonpaste.org/deploy/</link>.</para>
</section>
<section xml:id="ch021_paste-and-middleware-idp52496">
<title>API Endpoint Process Isolation &amp; Policy</title>

10
doc/src/docbkx/openstack-security/ch024_authentication.xml
View File

@ -28,8 +28,10 @@
<para>Authentication and authorization policy in OpenStack may be delegated to an external LDAP server. A typical use case is an organization that seeks to deploy a private cloud and already has a database of employees, the users. This may be in an LDAP system. Using LDAP as a source of authority authentication, requests to Keystone are delegated to the LDAP service, which will authorize or deny requests based on locally set policies. A token is generated on successful authentication.</para>
<para>Note that if the LDAP system has attributes defined for the user such as admin, finance, HR etc, these must be mapped into roles and groups within Keystone for use by the various OpenStack services. The <emphasis>etc/keystone.conf</emphasis> file provides the mapping from the LDAP attributes to Keystone attributes.</para>
<para>Keystone <emphasis role="bold">MUST NOT</emphasis> be allowed to write to LDAP services used for authentication outside of the OpenStack deployment as this would allow a sufficiently privileged keystone user to make changes to the LDAP directory. This would allow privilege escalation within the wider organization or facilitate unauthorized access to other information and resources. In such a deployment, user provisioning would be out of the realm of the OpenStack deployment.</para>
<para>NOTE: There is an OpenStack Security Note (OSSN) regarding keystone.conf permissions: https://bugs.launchpad.net/ossn/+bug/1168252</para>
<para>There is an OpenStack Security Note (OSSN) regarding potential DoS attacks: https://bugs.launchpad.net/ossn/+bug/1155566</para>
<note>
<para>There is an <link xlink:href="https://bugs.launchpad.net/ossn/+bug/1168252">OpenStack Security Note (OSSN) regarding keystone.conf permissions</link>.</para>
<para>There is an <link xlink:href="https://bugs.launchpad.net/ossn/+bug/1168252">OpenStack Security Note (OSSN) regarding potential DoS attacks</link>.</para>
</note>
</section>
<section xml:id="ch024_authentication-idp251520">
<title>External Authentication Methods</title>
@ -53,11 +55,11 @@
<para>The Policy enforcement middleware enables fine-grained access control to OpenStack resources. Only admin users can provision new users and have access to various management functionality. The cloud tenant would be able to only spin up instances, attach volumes, etc.</para>
<section xml:id="ch024_authentication-idp259168">
<title>Establish Formal Access Control Policies</title>
<para>Prior to configuring roles, groups, and users, document your required access control policies for the OpenStack installation. The policies should be consistent with any regulatory or legal requirements for the organization. Future modifications to access control configuration should be done consistently with the formal policies.  The policies should include the conditions and processes for creating, deleting, disabling, and enabling accounts, and for assigning privileges to the accounts. Periodically review the policies and ensure that configuration is in compliance with approved policies.</para>
<para>Prior to configuring roles, groups, and users, document your required access control policies for the OpenStack installation. The policies should be consistent with any regulatory or legal requirements for the organization. Future modifications to access control configuration should be done consistently with the formal policies. The policies should include the conditions and processes for creating, deleting, disabling, and enabling accounts, and for assigning privileges to the accounts. Periodically review the policies and ensure that configuration is in compliance with approved policies.</para>
</section>
<section xml:id="ch024_authentication-idp261600">
<title>Service Authorization</title>
<para>As described in the OpenStack Compute Admin Guide (http://docs.openstack.org/trunk/openstack-compute/admin/content/index.html), cloud administrators must define a user for each service, with a role of Admin.  This service user account provides the service with the authorization to authenticate users.</para>
<para>As described in the <link xlink:href="http://docs.openstack.org/trunk/openstack-compute/admin/content/index.html"><citetitle>OpenStack Compute Administration Guide</citetitle></link>, cloud administrators must define a user for each service, with a role of Admin. This service user account provides the service with the authorization to authenticate users.</para>
<para>The Nova and Swift services can be configured to use either the "tempAuth" file or Keystone to store authentication information. The "tempAuth" solution MUST NOT be deployed in a production environment since it stores passwords in plain text.</para>
<para>Keystone supports client authentication for SSL which may be enabled. SSL client authentication provides an additional authentication factor, in addition to the username / password, that provides greater reliability on user identification. It reduces the risk of unauthorized access when usernames and passwords may be compromised.  However, there is additional administrative overhead and cost to issue certificates to users that may not be feasible in every deployment.</para>
<para>NOTE: We recommend using client authentication using SSL for the authentication of services to Keystone.</para>

31
doc/src/docbkx/openstack-security/ch025_web-dashboard.xml
View File

@ -2,16 +2,13 @@
<chapter xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://docbook.org/ns/docbook" xmlns:db="http://docbook.org/ns/docbook" version="5.0" xml:id="ch025_web-dashboard"><?dbhtml stop-chunking?>
<title>Dashboard</title>
<para>Horizon is the OpenStack dashboard, providing access to a majority of the capabilities available in Openstack. These include provisioning users, defining instance flavors, uploading VM images, managing networks, setting up security groups, starting instances, and accessing the instances via a console.</para>
<para>Horizon is based on the Django web framework, therefore secure deployment practices for Django apply directly to Horizon. This guide provides a popular set of Django security recommendations, further information can be found by reading the Django deployment and security documentation:</para>
<para>https://docs.djangoproject.com/en/1.5/#security</para>
<para>Horizon ships with reasonable default security settings, and has good deployment and configuration documentation:</para>
<para>http://docs.openstack.org/developer/horizon/topics/deployment.html</para>
<para>Horizon is based on the Django web framework, therefore secure deployment practices for Django apply directly to Horizon. This guide provides a popular set of Django security recommendations, further information can be found by reading the <link xlink:href="https://docs.djangoproject.com/en/1.5/#security">Django deployment and security documentation</link>.</para>
<para>Horizon ships with reasonable default security settings, and has good <link xlink:href="http://docs.openstack.org/developer/horizon/topics/deployment.html">deployment and configuration documentation</link>.</para>
<section xml:id="ch025_web-dashboard-idp237648">
<title>Basic Web Server Configuration</title>
<para>Horizon should be deployed as a Web Services Gateway Interface (WSGI) application behind an HTTPS proxy such as Apache or nginx. If Apache is not already in use, we recommend nginx since it is lighter weight and easier to configure correctly.</para>
<para>When using nginx, we recommend gunicorn as the wsgi host with an appropriate number of synchronous workers. We strongly advise against deployments using fastcgi, scgi, or uWSGI. We strongly advise against the use of synthetic performance benchmarks when choosing a wsgi server.</para>
<para>http://docs.gunicorn.org/en/latest/deploy.html</para>
<para>When using Apache, we recommend mod_wsgi to host Horizon.https://docs.djangoproject.com/en/1.5/howto/deployment/wsgi/modwsgi/</para>
<para>When using nginx, we recommend <link xlink:href="http://docs.gunicorn.org/en/latest/deploy.html">gunicorn</link> as the wsgi host with an appropriate number of synchronous workers. We strongly advise against deployments using fastcgi, scgi, or uWSGI. We strongly advise against the use of synthetic performance benchmarks when choosing a wsgi server.</para>
<para>When using Apache, we recommend <link xlink:href="https://docs.djangoproject.com/en/1.5/howto/deployment/wsgi/modwsgi/">mod_wsgi</link> to host Horizon.</para>
</section>
<section xml:id="ch025_web-dashboard-idp240704">
<title>HTTPS</title>
@ -21,8 +18,7 @@
<section xml:id="ch025_web-dashboard-idp242624">
<title>HTTP Strict Transport Security (HSTS)</title>
<para>It is highly recommended to use HTTP Strict Transport Security (HSTS).</para>
<para>NOTE: If you are using an HTTPS proxy in front of your web server, rather than using an HTTP server with HTTPS functionality, follow the Django documentation on modifying the SECURE_PROXY_SSL_HEADER variable.</para>
<para>https://docs.djangoproject.com/en/1.5/ref/settings/#secure-proxy-ssl-header</para>
<para>NOTE: If you are using an HTTPS proxy in front of your web server, rather than using an HTTP server with HTTPS functionality, follow the <link xlink:href="https://docs.djangoproject.com/en/1.5/ref/settings/#secure-proxy-ssl-header">Django documentation on modifying the SECURE_PROXY_SSL_HEADER variable</link>.</para>
<para>See the chapter on PKI/SSL Everywhere for more specific recommendations and server configurations for HTTPS configurations, including the configuration of HSTS.</para>
</section>
<section xml:id="ch025_web-dashboard-idp245456">
@ -32,15 +28,15 @@
<section xml:id="ch025_web-dashboard-idp246880">
<title>Domain Names</title>
<para>Many organizations typically deploy web applications at subdomains of an overarching organization domain. It is natural for users to expect a domain of the form openstack.example.org. In this context, there are often many other applications deployed in the same second-level namespace, often serving user-controlled content. This name structure is convenient and simplifies nameserver maintenance.</para>
<para>We strongly recommend deploying horizon to a <emphasis>second-level domain</emphasis> (e.g. https://example.com) and advise against deploying horizon on a<emphasis> shared subdomain</emphasis> of any level (e.g. https://openstack.example.org, https://horizon.openstack.example.org). We also advise against deploying to bare internal domains (e.g. https://horizon/).</para>
<para>We strongly recommend deploying horizon to a <emphasis>second-level domain</emphasis>, for example <uri>https://example.com</uri>, and advise against deploying horizon on a<emphasis> shared subdomain</emphasis> of any level, for example <uri>https://openstack.example.org</uri> or <uri>https://horizon.openstack.example.org</uri>. We also advise against deploying to bare internal domains like <uri>https://horizon/</uri>.</para>
<para>This recommendation is based on the limitations browser same-origin-policy. The recommendations in this guide cannot effectively protect users against known attacks if Horizon is deployed on a domain which also hosts user-generated content (e.g. scripts, images, uploads of any kind) even if the user-generated content is on a different subdomain. This approach is used by most major web presences (e.g. googleusercontent.com, fbcdn.com, github.io, twimg.com) to ensure that user generated content stays separate from cookies and security tokens.</para>
<para>Additionally, if you decline to follow this recommendation above about second-level domains, it is vital that you avoid the cookie backed session store and employ HTTP Strict Transport Security (HSTS). When deployed on a subdomain, Horizon's security is only as strong as the weakest application deployed on the same second-level domain.</para>
</section>
<section xml:id="ch025_web-dashboard-idp251760">
<title>Static Media</title>
<para>Horizon's static media should be deployed to a subdomain of the Horizon domain and served by the web server. The use of an external content delivery network (CDN) is also acceptable. This subdomain should not set cookies or serve user-provided content. The media should also be served with HTTPS.</para>
<para>Django media settings are documented here:https://docs.djangoproject.com/en/1.5/ref/settings/#static-root</para>
<para>Horizon's default configuration uses django_compressor (http://django-compressor.readthedocs.org/) to compress and minify css and JavaScript content before serving it. This process should be statically done before deploying Horizon, rather than using the default in-request dynamic compression and copying the resulting files along with deployed code or to the CDN server. Compression should be done in a non-production build environment. If this is not practical, we recommend disabling resource minification entirely. Online compression dependencies (less, nodejs) should not be installed on production machines.</para>
<para>Django media settings are documented at <link xlink:href="https://docs.djangoproject.com/en/1.5/ref/settings/#static-root">https://docs.djangoproject.com/en/1.5/ref/settings/#static-root</link>.</para>
<para>Horizon's default configuration uses <link xlink:href="http://django-compressor.readthedocs.org/">django_compressor</link> to compress and minify css and JavaScript content before serving it. This process should be statically done before deploying Horizon, rather than using the default in-request dynamic compression and copying the resulting files along with deployed code or to the CDN server. Compression should be done in a non-production build environment. If this is not practical, we recommend disabling resource minification entirely. Online compression dependencies (less, nodejs) should not be installed on production machines.</para>
</section>
<section xml:id="ch025_web-dashboard-idp255696">
<title>Secret Key</title>
@ -50,12 +46,12 @@
<title>Session Backend</title>
<para>Horizon's default session backend (<emphasis>django.contrib.sessions.backends.signed_cookies</emphasis>) stores user data in <emphasis>signed</emphasis> but <emphasis>unencrypted </emphasis>cookies stored in the browser. This approach allows the most simple session backend scaling since each Horizon instance is stateless, but it comes at the cost of <emphasis>storing sensitive access tokens in the client browser</emphasis> and transmitting them with every request. This backend ensures that session data has not been tampered with, but the data itself is not encrypted other than the encryption provided by HTTPS.</para>
<para>If your architecture allows it, we recommend using <emphasis>django.contrib.sessions.backends.cache</emphasis> as your session backend with memcache as the cache. Memcache must not be exposed publicly, and should communicate over a secured private channel. If you choose to use the signed cookies backend, refer to the Django documentation understand the security tradeoffs.</para>
<para>For further details, consult the Django session backend documentation:https://docs.djangoproject.com/en/1.5/topics/http/sessions/#configuring-the-session-engine</para>
<para>For further details, consult the <link xlink:href="https://docs.djangoproject.com/en/1.5/topics/http/sessions/#configuring-the-session-engine">Django session backend documentation</link>.</para>
</section>
<section xml:id="ch025_web-dashboard-idp262288">
<title>Allowed Hosts</title>
<para>Configure the ALLOWED_HOSTS setting with the domain or domains where Horizon is available. Failure to configure this setting (especially if not following the recommendation above regarding second level domains) opens Horizon to a number of serious attacks. Wildcard domains should be avoided.</para>
<para>For further details, see the Django documentation on settings:https://docs.djangoproject.com/en/1.5/ref/settings/#allowed-hosts</para>
<para>For further details, see the <link xlink:href="https://docs.djangoproject.com/en/1.5/ref/settings/#allowed-hosts">Django documentation on settings</link>.</para>
</section>
<section xml:id="ch025_web-dashboard-idp264272">
<title>Cookies</title>
@ -73,7 +69,7 @@ SESSION_COOKIE_SECURE = True</screen>
</section>
<section xml:id="ch025_web-dashboard-idp268448">
<title>Cross Site Request Forgery (CSRF)</title>
<para>Django has a dedicated middleware for cross-site request forgery (CSRF):https://docs.djangoproject.com/en/1.5/ref/contrib/csrf/#how-it-works</para>
<para>Django has a dedicated middleware for <link xlink:href="https://docs.djangoproject.com/en/1.5/ref/contrib/csrf/#how-it-works">cross-site request forgery</link> (CSRF).</para>
<para>Horizon is designed to discourage developers from introducing cross-site scripting vulnerabilities with custom dashboards. However, it is important to audit custom dashboards, especially ones that are javascript-heavy for inappropriate use of the @csrf_exempt decorator. Dashboards which do not follow these recommended security settings should be carefully evaluated before restrictions are relaxed.</para>
</section>
<section xml:id="ch025_web-dashboard-idp270608">
@ -84,14 +80,13 @@ SESSION_COOKIE_SECURE = True</screen>
<section xml:id="ch025_web-dashboard-idp272832">
<title>Cross Origin Resource Sharing (CORS)</title>
<para>Configure your web server to send a restrictive CORS header with each response, allowing only the Horizon domain and protocol:</para>
<screen> 
<screen>
Access-Control-Allow-Origin: https://example.com/</screen>
<para>Never allow the wildcard origin.</para>
</section>
<section xml:id="ch025_web-dashboard-idp275056">
<title>Horizon Image Upload</title>
<para>We recommend that implementers disable HORIZON_IMAGES_ALLOW_UPLOAD unless they have implemented a plan to prevent resource exhaustion and denial of service.</para>
<para>http://docs.openstack.org/developer/horizon/topics/deployment.html#file-uploads</para>
<para>We recommend that implementers <link xlink:href="http://docs.openstack.org/developer/horizon/topics/deployment.html#file-uploads">disable HORIZON_IMAGES_ALLOW_UPLOAD</link> unless they have implemented a plan to prevent resource exhaustion and denial of service.</para>
</section>
<section xml:id="ch025_web-dashboard-idp276864">
<title>Upgrading</title>

8
doc/src/docbkx/openstack-security/ch026_compute.xml
View File

@ -31,7 +31,7 @@
</section>
<section xml:id="ch026_compute-idp54592">
<title>References</title>
<para>Secure Connections to VNC ports - http://blog.malchuk.ru/2013/05/21/47</para>
<para><link xlink:href="http://blog.malchuk.ru/2013/05/21/47">Secure Connections to VNC ports</link></para>
</section>
<section xml:id="ch026_compute-idp55824">
<title>Simple Protocol for Independent Computing Environments (SPICE)</title>
@ -68,9 +68,9 @@
</section>
<section xml:id="ch026_compute-idp86912">
<title>References</title>
<para>SPICE Console - http://docs.openstack.org/trunk/openstack-compute/admin/content/spice-console.html</para>
<para>https://bugzilla.redhat.com/show_bug.cgi?id=913607</para>
<para>http://openstack.redhat.com/forum/discussion/67/resolved-spice-support-in-rdo-grizzly/p1 </para>
<para><link xlink:href="http://docs.openstack.org/trunk/openstack-compute/admin/content/spice-console.html">SPICE Console</link></para>
<para><link xlink:href="https://bugzilla.redhat.com/show_bug.cgi?id=913607">Red Hat bug 913607</link></para>
<para><link xlink:href="http://openstack.redhat.com/forum/discussion/67/resolved-spice-support-in-rdo-grizzly/p1">SPICE support in RDO Grizzly</link></para>
</section>
</section>
</section>

2
doc/src/docbkx/openstack-security/ch031_neutron-architecture.xml
View File

@ -53,7 +53,7 @@
<para><emphasis role="bold">API network</emphasis> Exposes all OpenStack APIs, including the OpenStack Networking API, to tenants. The IP addresses on this network should be reachable by anyone on the Internet. This may be the same network as the external network, as it is possible to create a subnet for the external network that uses IP allocation ranges to use only less than the full range of IP addresses in an IP block. This network is considered the Public Security Domain.</para>
</listitem>
</itemizedlist>
<para>For additional information see http://docs.openstack.org/grizzly/openstack-network/admin/content/arch_overview.html.</para>
<para>For additional information see the <link xlink:href="http://docs.openstack.org/grizzly/openstack-network/admin/content/arch_overview.html"><citetitle>OpenStack Networking Administration Guide</citetitle></link>.</para>
</section>
</section>
</chapter>

4
doc/src/docbkx/openstack-security/ch032_networking-best-practices.xml
View File

@ -68,8 +68,8 @@
<section xml:id="ch032_networking-best-practices-idp74544">
<title>Network Services Extensions</title>
<para>Here is a list of known plugins provided by the open source community or by SDN companies that work with OpenStack Networking:</para>
<para>    Big Switch Controller Plugin    Brocade Neutron Plugin Brocade Neutron Plugin    Cisco UCS/Nexus Plugin    Cloudbase Hyper-V Plugin    Extreme Networks Plugin    Juniper Networks Neutron Plugin    Linux Bridge Plugin    Mellanox Neutron Plugin Mellanox Neutron Plugin    MidoNet Plugin    NEC OpenFlow Plugin    Nicira Network Virtualization Platform (NVP) Plugin    Open vSwitch Plugin    PLUMgrid Plugin    Ruijie Networks Plugin    Ryu OpenFlow Controller Plugin</para>
<para>For a more detail comparison of all features provided by plugins as of the Folsom release, http://www.sebastien-han.fr/blog/2012/09/28/quantum-plugin-comparison/</para>
<para>Big Switch Controller Plugin, Brocade Neutron Plugin Brocade Neutron Plugin, Cisco UCS/Nexus Plugin, Cloudbase Hyper-V Plugin, Extreme Networks Plugin, Juniper Networks Neutron Plugin, Linux Bridge Plugin, Mellanox Neutron Plugin, MidoNet Plugin, NEC OpenFlow Plugin, Nicira Network Virtualization Platform (NVP) Plugin, Open vSwitch Plugin, PLUMgrid Plugin, Ruijie Networks Plugin, Ryu OpenFlow Controller Plugin</para>
<para>For a more detailed comparison of all features provided by plugins as of the Folsom release, see <link xlink:href="http://www.sebastien-han.fr/blog/2012/09/28/quantum-plugin-comparison/">Sebastien Han's comparison</link>.</para>
</section>
<section xml:id="ch032_networking-best-practices-idp78032">
<title>Networking Services Limitations</title>

2
doc/src/docbkx/openstack-security/ch034_tenant-secure-networking-best-practices.xml
View File

@ -8,7 +8,7 @@
</section>
<section xml:id="ch034_tenant-secure-networking-best-practices-idp46080">
<title>Networking Resource Policy Engine</title>
<para>A policy engine and its configuration file, <emphasis>policy.json</emphasis>, within OpenStack Networking provides a method to provide finer grained authorization of users on tenant networking methods and objects. It is important that cloud architects and operators evaluate their design and use cases in providing users and tenants the ability to create, update, and destroy available network resources as it has a tangible effect on tenant network availability, network security, and overall OpenStack security. For a more detail explanation of Openstack Networking policy definition, please refer to the Authentication and Authorization chapter in the Openstack Networking Administration Guide: http://docs.openstack.org/grizzly/openstack-network/admin/content/ch_auth.html </para>
<para>A policy engine and its configuration file, <emphasis>policy.json</emphasis>, within OpenStack Networking provides a method to provide finer grained authorization of users on tenant networking methods and objects. It is important that cloud architects and operators evaluate their design and use cases in providing users and tenants the ability to create, update, and destroy available network resources as it has a tangible effect on tenant network availability, network security, and overall OpenStack security. For a more detail explanation of Openstack Networking policy definition, please refer to the <link xlink:href="http://docs.openstack.org/trunk/openstack-network/admin/content/ch_auth.html">Authentication and Authorization chapter</link> in the <citetitle>OpenStack Networking Administration Guide</citetitle>.</para>
<address>It is important to review the default networking resource policy and modify the policy appropriately for your security posture.</address>
<para>If your deployment of Openstack provides multiple external access points into different security domains it is important that you limit the tenant's ability to attach multiple vNICs to multiple external access points -- this would bridge these security domains and could lead to unforseen security compromise. It is possible mitigate this risk by utilizing the host aggregates functionality provided by Openstack Compute or through splitting the tenant VMs into multiple tenant projects with different virtual network configurations.</para>
</section>

26
doc/src/docbkx/openstack-security/ch038_transport-security.xml
View File

@ -24,10 +24,10 @@
<para>Note, the 'tcp_listeners' option is set to '[]' to prevent it from listening an on non-SSL port. 'ssl_listeners' option should be restricted to only listen on the management network for the services.</para>
<para>For more information on RabbitMQ SSL configuration see:</para>
<itemizedlist><listitem>
<para>RabbitMQ Configuration - http://www.rabbitmq.com/configure.html</para>
<para><link xlink:href="http://www.rabbitmq.com/configure.html">RabbitMQ Configuration</link></para>
</listitem>
<listitem>
<para>RabbitMQ SSL - http://www.rabbitmq.com/ssl.html</para>
<para><link xlink:href="http://www.rabbitmq.com/ssl.html">RabbitMQ SSL</link></para>
</listitem>
</itemizedlist>
</section>
@ -35,7 +35,7 @@
<title>Qpid Server SSL Configuration</title>
<para>The Apache Foundation has a messaging security guide for Qpid. See:</para>
<itemizedlist><listitem>
<para>Apache Qpid SSL - http://qpid.apache.org/books/0.22/AMQP-Messaging-Broker-CPP-Book/html/chap-Messaging_User_Guide-Security.html#sect-Messaging_User_Guide-Security-Encryption_using_SSL</para>
<para><link xlink:href="http://qpid.apache.org/books/0.22/AMQP-Messaging-Broker-CPP-Book/html/chap-Messaging_User_Guide-Security.html#sect-Messaging_User_Guide-Security-Encryption_using_SSL">Apache Qpid SSL</link></para>
</listitem>
</itemizedlist>
</section>
@ -57,22 +57,22 @@ rabbitmqctl add_user compute01 password
rabbitmqctl set_permissions compute01 ".*"".*"".*"</screen>
<para>For additional configuration information see:</para>
<itemizedlist><listitem>
<para>RabbitMQ Access Control - http://www.rabbitmq.com/access-control.html</para>
<para><link xlink:href="http://www.rabbitmq.com/access-control.html">RabbitMQ Access Control</link></para>
</listitem>
<listitem>
<para>RabbitMQ Authentication - http://www.rabbitmq.com/authentication.html</para>
<para><link xlink:href="http://www.rabbitmq.com/authentication.html">RabbitMQ Authentication</link></para>
</listitem>
<listitem>
<para>RabbitMQ Plugins - http://www.rabbitmq.com/plugins.html</para>
<para><link xlink:href="http://www.rabbitmq.com/plugins.html">RabbitMQ Plugins</link></para>
</listitem>
<listitem>
<para>RabbitMQ SASL External Auth - http://hg.rabbitmq.com/rabbitmq-auth-mechanism-ssl/file/rabbitmq_v3_1_3/README</para>
<para><link xlink:href="http://hg.rabbitmq.com/rabbitmq-auth-mechanism-ssl/file/rabbitmq_v3_1_3/README">RabbitMQ SASL External Auth</link></para>
</listitem>
</itemizedlist>
</section>
<section xml:id="ch038_transport-security-idp59648">
<title>OpenStack Service Configuration - RabbitMQ</title>
<screen> 
<screen>
[DEFAULT]
rpc_backend=nova.openstack.common.rpc.impl_kombu
rabbit_use_ssl=True
@ -83,22 +83,22 @@ rabbit_password=password
kombu_ssl_keyfile=/etc/ssl/node-key.pem
kombu_ssl_certfile=/etc/ssl/node-cert.pem
kombu_ssl_ca_certs=/etc/ssl/cacert.pem</screen>
<para>NOTE: A bug exists in the current version of OpenStack Grizzly where if 'kombu_ssl_version' is currently specified in the configuration file for any of the OpenStack services it will cause the following python traceback error: 'TypeError: an integer is required'. The current workaround is to remove 'kombu_ssl_version' from the configuration file. Refer to the following bug report for status: https://bugs.launchpad.net/oslo/+bug/1195431</para>
<para>NOTE: A bug exists in the current version of OpenStack Grizzly where if 'kombu_ssl_version' is currently specified in the configuration file for any of the OpenStack services it will cause the following python traceback error: 'TypeError: an integer is required'. The current workaround is to remove 'kombu_ssl_version' from the configuration file. Refer to <link xlink:href="https://bugs.launchpad.net/oslo/+bug/1195431">bug report 1195431</link> for current status.</para>
</section>
<section xml:id="ch038_transport-security-idp62112">
<title>Authentication Configuration Example - Qpid</title>
<para>For configuration information see:</para>
<itemizedlist><listitem>
<para>Apache Qpid Authentication - http://qpid.apache.org/books/0.22/AMQP-Messaging-Broker-CPP-Book/html/chap-Messaging_User_Guide-Security.html#sect-Messaging_User_Guide-Security-User_Authentication</para>
<para><link xlink:href="http://qpid.apache.org/books/0.22/AMQP-Messaging-Broker-CPP-Book/html/chap-Messaging_User_Guide-Security.html#sect-Messaging_User_Guide-Security-User_Authentication">Apache Qpid Authentication</link></para>
</listitem>
<listitem>
<para>Apache Qpid Authorization - http://qpid.apache.org/books/0.22/AMQP-Messaging-Broker-CPP-Book/html/chap-Messaging_User_Guide-Security.html#sect-Messaging_User_Guide-Security-Authorization</para>
<para><link xlink:href="http://qpid.apache.org/books/0.22/AMQP-Messaging-Broker-CPP-Book/html/chap-Messaging_User_Guide-Security.html#sect-Messaging_User_Guide-Security-Authorization">Apache Qpid Authorization</link></para>
</listitem>
</itemizedlist>
</section>
<section xml:id="ch038_transport-security-idp65584">
<title>OpenStack Service Configuration - Qpid</title>
<screen> 
<screen>
[DEFAULT]
rpc_backend=nova.openstack.common.rpc.impl_qpid
qpid_protocol=ssl
@ -107,7 +107,7 @@ qpid_port=5671qpid_username=compute01
qpid_password=password</screen>
<para>Optionally, if using SASL with Qpid specify the SASL mechanisms in use by adding:</para>
<screen> 
<screen>
qpid_sasl_mechanisms=&lt;space separated list of SASL mechanisms to use for auth&gt;</screen>
</section>
</section>

10
doc/src/docbkx/openstack-security/ch041_database-backend-considerations.xml
View File

@ -9,21 +9,21 @@
<para>Those deploying MySQL or PostgreSQL are advised to refer to existing security guidance. Some references are listed below:</para>
<para>MySQL:</para>
<itemizedlist><listitem>
<para>OWASP MySQL Hardening - https://www.owasp.org/index.php/OWASP_Backend_Security_Project_MySQL_Hardening</para>
<para><link xlink:href="https://www.owasp.org/index.php/OWASP_Backend_Security_Project_MySQL_Hardening">OWASP MySQL Hardening</link></para>
</listitem>
<listitem>
<para>http://dev.mysql.com/doc/refman/5.5/en/pluggable-authentication.html</para>
<para><link xlink:href="http://dev.mysql.com/doc/refman/5.5/en/pluggable-authentication.html">MySQL Pluggable Authentication</link></para>
</listitem>
<listitem>
<para>Security in MySQL - http://downloads.mysql.com/docs/mysql-security-excerpt-5.1-en.pdf</para>
<para><link xlink:href="http://downloads.mysql.com/docs/mysql-security-excerpt-5.1-en.pdf">Security in MySQL</link></para>
</listitem>
</itemizedlist>
<para>PostgreSQL:</para>
<itemizedlist><listitem>
<para>OWASP PostgreSQL Hardening - https://www.owasp.org/index.php/OWASP_Backend_Security_Project_PostgreSQL_Hardening</para>
<para><link xlink:href="https://www.owasp.org/index.php/OWASP_Backend_Security_Project_PostgreSQL_Hardening">OWASP PostgreSQL Hardening</link></para>
</listitem>
<listitem>
<para>Total security in a PostgreSQL database - http://www.ibm.com/developerworks/opensource/library/os-postgresecurity</para>
<para><link xlink:href="http://www.ibm.com/developerworks/opensource/library/os-postgresecurity">Total security in a PostgreSQL database</link></para>
</listitem>
</itemizedlist>
</section>

13
doc/src/docbkx/openstack-security/ch043_database-transport-security.xml
View File

@ -31,23 +31,24 @@ listen_addresses = &lt;ip address or hostname of management network interface&g
<title>MySQL SSL Configuration</title>
<para>The following lines should be added in the system-wide MySQL configuration file:</para>
<para>In my.cnf:</para>
<screen> 
<screen>
[[mysqld]]
...
ssl-ca=/path/to/ssl/cacert.pem
ssl-cert=/path/to/ssl/server-cert.pem
ssl-key=/path/to/ssl/server-key.pem</screen>
<para>Optionally, if you wish to restrict the set of SSL ciphers used for the encrypted connection. See http://www.openssl.org/docs/apps/ciphers.html for a list of ciphers and the syntax for specifying the cipher string:</para>
<screen> 
<para>Optionally, if you wish to restrict the set of SSL ciphers
used for the encrypted connection. See <link xlink:href="http://www.openssl.org/docs/apps/ciphers.html">http://www.openssl.org/docs/apps/ciphers.html</link> for a list of ciphers and the syntax for specifying the cipher string:</para>
<screen>
ssl-cipher='cipher:list'</screen>
</section>
<section xml:id="ch043_database-transport-security-idp50288">
<title>PostgreSQL SSL Configuration</title>
<para>The following lines should be added in the system-wide PostgreSQL configuration file, <literal>postgresql.conf</literal>.</para>
<screen> 
<screen>
ssl = true</screen>
<para>Optionally, if you wish to restrict the set of SSL ciphers used for the encrypted connection. See http://www.openssl.org/docs/apps/ciphers.html for a list of ciphers and the syntax for specifying the cipher string:</para>
<screen> 
<para>Optionally, if you wish to restrict the set of SSL ciphers used for the encrypted connection. See <link xlink:href="http://www.openssl.org/docs/apps/ciphers.html">http://www.openssl.org/docs/apps/ciphers.html</link> for a list of ciphers and the syntax for specifying the cipher string:</para>
<screen>
ssl-ciphers = 'cipher:list'</screen>
<para>The server certificate, key, and certificate authority (CA) files should be placed in the $PGDATA directory in the following files:</para>
<itemizedlist><listitem>

4
doc/src/docbkx/openstack-security/ch046_data-residency.xml
View File

@ -105,7 +105,7 @@
<section xml:id="ch046_data-residency-idp75184">
<title>Instance memory scrubbing</title>
<para>Specific to various hypervisors is the treatment of instance memory. This behavior is not defined in OpenStack Compute, although it is generally expected of hypervisors that they will make a best effort to scrub memory either upon deletion of an instance, upon creation of an instance, or both.</para>
<para>Xen explicitly assigns dedicated memory regions to instances and scrubs data upon the destruction of instances (or domains in Xen parlance). KVM depends more greatly on Linux page management; A complex set of rules related to KVM paging is defined in KVM documentation: http://www.linux-kvm.org/page/Memory</para>
<para>Xen explicitly assigns dedicated memory regions to instances and scrubs data upon the destruction of instances (or domains in Xen parlance). KVM depends more greatly on Linux page management; A complex set of rules related to KVM paging is defined in the <link xlink:href="http://www.linux-kvm.org/page/Memory">KVM documentation</link>.</para>
<para>It is important to note that use of the Xen memory balloon feature is likely to result in information disclosure. We strongly recommended to avoid use of this feature.</para>
<para>For these and other hypervisors, we recommend referring to hypervisor-specific documentation.</para>
</section>
@ -124,7 +124,7 @@
</section>
<section xml:id="ch046_data-residency-idp85040">
<title>Bare metal server sanitization</title>
<para>A bare metal server driver for Nova was under development and has since moved into a separate project called Ironic (https://wiki.openstack.org/wiki/Ironic).  At the time of this writing, Ironic does not appear to address sanitization of tenant data resident the physical hardware.</para>
<para>A bare metal server driver for Nova was under development and has since moved into a separate project called <link xlink:href="https://wiki.openstack.org/wiki/Ironic">Ironic</link>. At the time of this writing, Ironic does not appear to address sanitization of tenant data resident the physical hardware.</para>
<para>Additionally, it is possible for tenants of a bare metal system to modify system firmware. TPM technology, described in ##link:Management/Node Bootstrapping##, provides a solution for detecting unauthorized firmware changes.</para>
</section>
</section>

6
doc/src/docbkx/openstack-security/ch048_key-management.xml
View File

@ -2,16 +2,16 @@
<chapter xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://docbook.org/ns/docbook" xmlns:db="http://docbook.org/ns/docbook" version="5.0" xml:id="ch048_key-management"><?dbhtml stop-chunking?>
<title>Key Management</title>
<para>To address the often mentioned concern of tenant data privacy and limiting cloud provider liability, there is greater interest within the OpenStack community to make data encryption more ubiquitous. It is relatively easy for an end-user to encrypt their data prior to saving it to the cloud, and a this is a viable path for tenant objects such as media files, database archives among others. However, when client side encryption is used for virtual machine images, block storage etc, client intervention is necessary in the form of presenting keys to unlock the data for further use. To seamlessly secure the data and yet have it accessible without burdening the client with having to manage their keys and interactively provide them calls for a key management service within OpenStack. Providing encryption and key management services as part of OpenStack eases data-at-rest security adoption, addresses customer concerns about the privacy and misuse of their data with the added advantage of limiting cloud provider liability. Provider liability is of concern in multi-tenant public clouds with respect to handing over tenant data during a misuse investigation.</para>
<para>A key management service is in the early stages of being developed and has a way to go before becoming an official component of OpenStack. Refer to https://github.com/cloudkeep/barbican/wiki/_pages for details.</para>
<para>A key management service is in the early stages of being developed and has a way to go before becoming an official component of OpenStack. Refer to <link xlink:href="https://github.com/cloudkeep/barbican/wiki/_pages">https://github.com/cloudkeep/barbican/wiki/_pages</link> for details.</para>
<para>It shall support the creation of keys, and their secure saving (with a service master-key). Some of the design questions still being debated are how much of the Key Management Interchange Protocol (KMIP) to support, key formats, and certificate management.  The key manager will be pluggable to facilitate deployments that need a third-party Hardware Security Module (HSM).</para>
<para>OpenStack Block Storage, Cinder, is the first service looking to integrate with the key manager to provide volume encryption.</para>
<section xml:id="ch048_key-management-idp47776">
<title>References:</title>
<itemizedlist><listitem>
<para>Barbican - https://github.com/cloudkeep/barbican</para>
<para><link xlink:href="https://github.com/cloudkeep/barbican">Barbican</link></para>
</listitem>
<listitem>
<para>KMIP -https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=kmip</para>
<para><link xlink:href="https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=kmip">KMIP</link></para>
</listitem>
</itemizedlist>
</section>

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

@ -57,15 +57,15 @@
</listitem>
</itemizedlist>
<para>One of the biggest indicators of a hypervisor's maturity is the size and vibrancy of the community that surrounds it. As this concerns security, the quality of the community will affect the availability of expertise should you need additional cloud operators. It is also a sign of how widely deployed the hypervisor is, in turn leading to the battle readiness of any reference architectures and best practices.</para>
<para>Further, the quality of community, as it surrounds an open source hypervisor like KVM or Xen, will have a direct impact on the timeliness of bug fixes and security updates. When investigating both commercial and open source hypervisors, you will want to look into their release and support cycles as well as the time delta between the announcement of a bug or security issue and a patch or response. Lastly, the supported capabilities of OpenStack compute vary depending on the hypervisor chosen. Refer to the OpenStack Hypervisor Support Matrix (https://wiki.openstack.org/wiki/HypervisorSupportMatrix) for OpenStack compute feature support by hypervisor.</para>
<para>Further, the quality of community, as it surrounds an open source hypervisor like KVM or Xen, will have a direct impact on the timeliness of bug fixes and security updates. When investigating both commercial and open source hypervisors, you will want to look into their release and support cycles as well as the time delta between the announcement of a bug or security issue and a patch or response. Lastly, the supported capabilities of OpenStack compute vary depending on the hypervisor chosen. Refer to the <link xlink:href="https://wiki.openstack.org/wiki/HypervisorSupportMatrix">OpenStack Hypervisor Support Matrix</link> for OpenStack compute feature support by hypervisor.</para>
</section>
<section xml:id="ch051_vss-intro-idp260720">
<title>Certifications and Attestations</title>
<para>One additional consideration when selecting a hypervisor is the availability of various formal certifications and attestations. While they may not be requirements for your specific organization, these certifications and attestations speak to the maturity, production readiness, and thoroughness of the testing a particular hypervisor platform has been subjected to. </para>
<para>One additional consideration when selecting a hypervisor is the availability of various formal certifications and attestations. While they may not be requirements for your specific organization, these certifications and attestations speak to the maturity, production readiness, and thoroughness of the testing a particular hypervisor platform has been subjected to.</para>
</section>
<section xml:id="ch051_vss-intro-idp262672">
<title>Common Criteria</title>
<para>Common Criteria is an internationally standardized software evaluation process, used by governments and commercial companies to validate software technologies perform as advertised. In the government sector, NSTISSP No. 11 mandates that U.S. Government agencies only procure software which has been Common Criteria certified, a policy which has been in place since July 2002. It should be specifically noted that OpenStack has not undergone Common Criteria certification, however many of the available hypervisors have. </para>
<para>Common Criteria is an internationally standardized software evaluation process, used by governments and commercial companies to validate software technologies perform as advertised. In the government sector, NSTISSP No. 11 mandates that U.S. Government agencies only procure software which has been Common Criteria certified, a policy which has been in place since July 2002. It should be specifically noted that OpenStack has not undergone Common Criteria certification, however many of the available hypervisors have.</para>
<para>In addition to validating a technologies capabilities, the Common Criteria process evaluates <emphasis>how</emphasis> technologies are developed.</para>
<itemizedlist><listitem>
<para>How is source code management performed?</para>
@ -147,19 +147,19 @@
<td><para><emphasis role="bold">Key Length</emphasis></para></td>
<td><para><emphasis role="bold">Intended Purpose</emphasis></para></td>
<td><para><emphasis role="bold">Security Function</emphasis></para></td>
<td><para><emphasis role="bold">implementation Standard</emphasis></para></td>
<td><para><emphasis role="bold">Implementation Standard</emphasis></para></td>
</tr>
<tr>
<td><para>AES</para></td>
<td><para>128 bits,192 bits,</para><para>256 bits </para></td>
<td><para>Encryption / Decryption </para></td>
<td><para>Protected Data Transfer,Protection for Data at Rest </para></td>
<td><para>128 bits,192 bits,</para><para>256 bits</para></td>
<td><para>Encryption / Decryption</para></td>
<td><para>Protected Data Transfer, Protection for Data at Rest</para></td>
<td><para>RFC 4253</para></td>
</tr>
<tr>
<td><para>TDES</para></td>
<td><para>168 bits</para></td>
<td><para>Encryption /Decryption </para></td>
<td><para>Encryption / Decryption</para></td>
<td><para>Protected Data Transfer</para></td>
<td><para>RFC 4253</para></td>
</tr>
@ -167,14 +167,14 @@
<td><para>RSA</para></td>
<td><para>1024 bits,2048 bits,</para><para>3072 bits </para></td>
<td><para>Authentication,Key Exchange </para></td>
<td><para>identification andAuthentication, ProtectedData Transfer</para></td>
<td><para>Identification and Authentication, Protected Data Transfer</para></td>
<td><para>U.S. NIST FIPS PUB 186-3</para></td>
</tr>
<tr>
<td><para>DSA</para></td>
<td><para>L=1024,N=160 bits </para></td>
<td><para>Authentication,Key Exchange </para></td>
<td><para>Identification andAuthentication, ProtectedData Transfer </para></td>
<td><para>Identification and Authentication, Protected Data Transfer</para></td>
<td><para>U.S. NIST FIPS PUB 186-3</para></td>
</tr>
<tr>
@ -182,28 +182,28 @@
<td><para>128, 196, or256 bit </para></td>
<td><para>Encryption /Decryption </para></td>
<td><para>Protection of Data at Rest</para></td>
<td><para>http://www.cl.cam.ac.uk/~rj a14/Papers/serpent.pdf</para></td>
<td><para><link xlink:href="http://www.cl.cam.ac.uk/~rja14/Papers/serpent.pdf">http://www.cl.cam.ac.uk/~rja14/Papers/serpent.pdf</link></para></td>
</tr>
<tr>
<td><para>Twofish</para></td>
<td><para>128, 196, or256 bit </para></td>
<td><para>Encryption /Decryption </para></td>
<td><para>Protection of Data at Rest</para></td>
<td><para>http://www.schneier.com/paper-twofish-paper.html</para></td>
<td><para><link xlink:href="http://www.schneier.com/paper-twofish-paper.html">http://www.schneier.com/paper-twofish-paper.html</link></para></td>
</tr>
<tr>
<td><para>SHA-1</para></td>
<td><para>-</para></td>
<td><para>MessageDigest </para></td>
<td><para>Protection of Data at Rest,Protected Data Transfer </para></td>
<td><para> U.S. NIST FIPS 180-3</para></td>
<td><para>Protection of Data at Rest,Protected Data Transfer</para></td>
<td><para>U.S. NIST FIPS 180-3</para></td>
</tr>
<tr>
<td><para>SHA-2(224-, 256-,</para><para>384-, 512 bit)</para></td>
<td><para>-</para></td>
<td><para>MessageDigest </para></td>
<td><para>Protection for Data at Rest,Identification and Authentication </para></td>
<td><para>U.S. NIST FIPS 180-3 </para></td>
<td><para>U.S. NIST FIPS 180-3</para></td>
</tr>
</tbody>
</informaltable>
@ -260,7 +260,7 @@
<para>To wrap up our discussion around hypervisor selection, it is important to call out the differences between using LXC (Linux Containers) or Baremetal systems vs using a hypervisor like KVM. Specifically, the focus of this security guide will be largely based on having a hypervisor and virtualization platform. However, should your implementation require the use of a baremetal or LXC environment, you will want to pay attention to the particular differences in regard to deployment of that environment. In particular, you will need to provide your end users with assurances that the node has been properly sanitized of their data prior to re-provisioning. Additionally, prior to reusing a node, you will need to provide assurances that the hardware has not been tampered or otherwise compromised.</para>
<para>It should be noted that while OpenStack has a baremetal project, a discussion of the particular security implications of running baremetal is beyond the scope of this book.</para>
<para>Finally, due to the time constraints around a book sprint, the team chose to use KVM as the hypervisor in our example implementations and architectures.</para>
<para>Note: There is an OpenStack Security Note pertaining to the use of LXC in Nova: https://bugs.launchpad.net/ossn/+bug/1098582</para>
<note><para>There is an OpenStack Security Note pertaining to the <link xlink:href="https://bugs.launchpad.net/ossn/+bug/1098582">use of LXC in Nova</link>.</para></note>
</section>
<section xml:id="ch051_vss-intro-idp401408">
<title>Additional Security Features</title>
@ -330,12 +330,12 @@
</tbody>
</informaltable>
<para>KSM: Kernel Samepage Merging - http://www.linux-kvm.org/page/KSM</para>
<para>XSM: Xen Security Modules - http://wiki.xen.org/wiki/Xen_Security_Modules_:_XSM-FLASK</para>
<para>xVirt: Mandatory Access Control for Linux-based virtualization - http://selinuxproject.org/page/SVirt</para>
<para>TXT: Intel Trusted Execution Technology - http://www.intel.com/txt</para>
<para>AppArmor: Linux security module implementing MAC - http://wiki.apparmor.net/index.php/Main_Page</para>
<para>cGroups: Linux kernel feature to control resource usage - https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt</para>
<para><link xlink:href="http://www.linux-kvm.org/page/KSM">KSM: Kernel Samepage Merging</link></para>
<para><link xlink:href="http://wiki.xen.org/wiki/Xen_Security_Modules_:_XSM-FLASK">XSM: Xen Security Modules</link></para>
<para><link xlink:href="http://selinuxproject.org/page/SVirt">xVirt: Mandatory Access Control for Linux-based virtualization</link></para>
<para><link xlink:href="http://www.intel.com/txt">TXT: Intel Trusted Execution Technology</link></para>
<para><link xlink:href="http://wiki.apparmor.net/index.php/Main_Page">AppArmor: Linux security module implementing MAC</link></para>
<para><link xlink:href="https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt">cgroups: Linux kernel feature to control resource usage</link></para>
<para>MAC Policy: Mandatory Access Control; may be implemented with SELinux or other operating systems</para>
<para>* Features in this table may not be applicable to all hypervisors or directly mappable between hypervisors.</para>
</section>

26
doc/src/docbkx/openstack-security/ch052_devices.xml
View File

@ -7,13 +7,15 @@
<para>Many hypervisors offer a functionality known as PCI passthrough. This allows an instance to have direct access to a piece of hardware on the node. For example, this could be used to allow instances to access video cards offering the compute unified device architecture (CUDA) for high performance computation. This feature carries two types of security risks: direct memory access and hardware infection.</para>
<para>Direct memory access (DMA) is a feature that permits certain hardware devices to access arbitrary physical memory addresses in the host computer. Often video cards have this capability. However, an instance should not be given arbitrary physical memory access because this would give it full view of both the host system and other instances running on the same node. Hardware vendors use an input/output memory management unit (IOMMU) to manage DMA access in these situations. Therefore, cloud architects should ensure that the hypervisor is configured to utilize this hardware feature.</para>
<itemizedlist><listitem>
<para>KVM: http://www.linux-kvm.org/page/How_to_assign_devices_with_VT-d_in_KVM</para>
<para>KVM: <link xlink:href="http://www.linux-kvm.org/page/How_to_assign_devices_with_VT-d_in_KVM">How to assign devices with VT-d in KVM</link></para>
</listitem>
<listitem>
<para>Xen: http://wiki.xen.org/wiki/VTd_HowTo</para>
<para>Xen: <link xlink:href="http://wiki.xen.org/wiki/VTd_HowTo">VTd Howto</link></para>
</listitem>
</itemizedlist>
<para>Note: The IOMMU feature is marketed as VT-d by Intel and AMD-Vi by AMD.</para>
<note>
<para>The IOMMU feature is marketed as VT-d by Intel and AMD-Vi by AMD.</para>
</note>
<para>A hardware infection occurs when an instance makes a malicious modification to the firmware or some other part of a device. As this device is used by other instances, or even the host OS, the malicious code can spread into these systems. The end result is that one instance can run code outside of its security domain. This is a potential problem in any hardware sharing scenario. The problem is specific to this scenario because it is harder to reset the state of physical hardware than virtual hardware.</para>
<para>Solutions to the hardware infection problem are domain specific. The strategy is to identify how an instance can modify hardware state then determine how to reset any modifications when the instance is done using the hardware. For example, one option could be to re-flash the firmware after use. Clearly there is a need to balance hardware longevity with security as some firmwares will fail after a large number of writes. TPM technology, described in <literal>link:Management/Node Bootstrapping</literal>, provides a solution for detecting unauthorized firmware changes. Regardless of the strategy selected, it is important to understand the risks associated with this kind of hardware sharing so that they can be properly mitigated for a given deployment scenario.</para>
<para>Additionally, due to the risk and complexities associated with PCI passthrough, it should be disabled by default. If enabled for a specific need, you will need to have appropriate processes in place to ensure the hardware is clean before re-issue.</para>
@ -51,18 +53,18 @@ glance image-update \
<section xml:id="ch052_devices-idp494336">
<title>Compiler Hardening</title>
<para>The next step is to harden QEMU using compiler hardening options. Modern compilers provide a variety of compile time options to improve the security of the resulting binaries. These features, which we will describe in more detail below, include relocation read-only (RELRO), stack canaries, never execute (NX), position independent executable (PIE), and address space layout randomization (ASLR).</para>
<para>Many modern linux distributions already build QEMU with compiler hardening enabled, so you may want to verify your existing executable before proceeding with the information below. One tool that can assist you with this verification is called <literal>checksec.sh</literal> (http://www.trapkit.de/tools/checksec.html).</para>
<para>Many modern linux distributions already build QEMU with compiler hardening enabled, so you may want to verify your existing executable before proceeding with the information below. One tool that can assist you with this verification is called <link xlink:href="http://www.trapkit.de/tools/checksec.html"><literal>checksec.sh</literal></link>.</para>
<itemizedlist><listitem>
<para><emphasis>RELocation Read-Only (RELRO)</emphasis> : Hardens the data sections of an executable. Both full and partial RELRO modes are supported by gcc. For QEMU full RELRO is your best choice. This will make the global offset table read-only and place various internal data sections before the program data section in the resulting executable.</para>
<para><emphasis>RELocation Read-Only (RELRO)</emphasis>: Hardens the data sections of an executable. Both full and partial RELRO modes are supported by gcc. For QEMU full RELRO is your best choice. This will make the global offset table read-only and place various internal data sections before the program data section in the resulting executable.</para>
</listitem>
<listitem>
<para><emphasis>Stack Canaries</emphasis> : Places values on the stack and verifies their presence to help prevent buffer overflow attacks.</para>
<para><emphasis>Stack Canaries</emphasis>: Places values on the stack and verifies their presence to help prevent buffer overflow attacks.</para>
</listitem>
<listitem>
<para><emphasis>Never eXecute (NX)</emphasis> : Also known as Data Execution Prevention (DEP), ensures that data sections of the executable can not be executed.</para>
<para><emphasis>Never eXecute (NX)</emphasis>: Also known as Data Execution Prevention (DEP), ensures that data sections of the executable can not be executed.</para>
</listitem>
<listitem>
<para><emphasis>Position Independent Executable (PIE)</emphasis> : Produces a position independent executable, which is necessary for ASLR.  </para>
<para><emphasis>Position Independent Executable (PIE)</emphasis>: Produces a position independent executable, which is necessary for ASLR.  </para>
</listitem>
<listitem>
<para><emphasis>Address Space Layout Randomization (ASLR)</emphasis> : This ensures that both code and data regions will be randomized. Enabled by the kernel (all modern linux kernels support ASLR), when the executable is built with PIE.</para>
@ -74,16 +76,16 @@ CFLAGS="-arch x86_64 -fstack-protector-all -Wstack-protector --param ssp-buffer-
<para>We recommend testing your QEMU executable file after it is compiled to ensure that the compiler hardening worked properly.</para>
<para>Most cloud deployments will not want to build software such as QEMU by hand. It is better to use packaging to ensure that the process is repeatable and to ensure that the end result can be easily deployed throughout the cloud. The references below provide some additional details on applying compiler hardening options to existing packages.</para>
<itemizedlist><listitem>
<para>DEB packages: http://wiki.debian.org/HardeningWalkthrough </para>
<para>DEB packages: <link xlink:href="http://wiki.debian.org/HardeningWalkthrough">Hardening Walkthrough</link></para>
</listitem>
<listitem>
<para>RPM packages: http://fedoraproject.org/wiki/How_to_create_an_RPM_package</para>
<para>RPM packages: <link xlink:href="http://fedoraproject.org/wiki/How_to_create_an_RPM_package">How to create an RPM package</link></para>
</listitem>
</itemizedlist>
</section>
<section xml:id="ch052_devices-idp508032">
<title>Mandatory Access Controls</title>
<para>Compiler hardening makes it more difficult to attack the QEMU process. However, if an attacker does succeed, we would like to limit the impact of the attack. Mandatory access controls accomplish this by restricting the privileges on QEMU process to only what is needed. This can be accomplished using sVirt / SELinux or AppArmor. When using sVirt, SELinux is configured to run every QEMU process under a different security context.  AppArmor can be configured to provide similar functionality. We provide more details on sVirt in the instance isolation section below.</para>
<para>Compiler hardening makes it more difficult to attack the QEMU process. However, if an attacker does succeed, we would like to limit the impact of the attack. Mandatory access controls accomplish this by restricting the privileges on QEMU process to only what is needed. This can be accomplished using sVirt / SELinux or AppArmor. When using sVirt, SELinux is configured to run every QEMU process under a different security context. AppArmor can be configured to provide similar functionality. We provide more details on sVirt in the instance isolation section below.</para>
</section>
</section>
<section xml:id="ch052_devices-idp510512">
@ -125,7 +127,7 @@ system_u:object_r:svirt_image_t:SystemLow image3
system_u:object_r:svirt_image_t:SystemLow image4</screen>
<para>The svirt_image_t label uniquely identifies image files on disk, allowing for the SELinux policy to restrict access. When a KVM-based Nova image is powered on, sVirt appends a random numerical identifier to the image. sVirt is technically capable of assigning numerical identifiers to 524,288 virtual machines per hypervisor node, however OpenStack deployments are highly unlikely to encounter this limitation.</para>
<para>An example of the sVirt category identifier is shown below:</para>
<screen> 
<screen>
system_u:object_r:svirt_image_t:s0:c87,c520 image1
system_u:object_r:svirt_image_t:s0:419,c172 image2</screen>
</section>

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

@ -21,13 +21,13 @@
<title>Entropy To Instances</title>
<para>We consider entropy to refer to the quality and source of random data that is available to an instance. Cryptographic technologies typically rely heavily on randomness, requiring a high quality pool of entropy to draw from. It is typically hard for a virtual machine to get enough entropy to support these operations. Entropy starvation can manifest in instances as something seemingly unrelated for example, slow boot times because the instance is waiting for ssh key generation. Entropy starvation may also motivate users to employ poor quality entropy sources from within the instance, making applications running in the cloud less secure overall.</para>
<para>Fortunately, a cloud architect may address these issues by providing a high quality source of entropy to the cloud instances. This can be done by having enough hardware random number generators (HRNG) in the cloud to support the instances. In this case, "enough" is somewhat domain specific. For everyday operations, a modern HRNG is likely to produce enough entropy to support 50-100 compute nodes. High bandwidth HRNGs, such as the RdRand instruction available with Intel Ivy Bridge and newer processors could potentially handle more nodes. For a given cloud, an architect needs to understand the application requirements to ensure that sufficient entropy is available.</para>
<para>Once the entropy is available in the cloud, the next step is getting that entropy into the instances. Tools such as the entropy gathering daemon (EGD, http://egd.sourceforge.net/) provide a way to fairly and securely distribute entropy through a distributed system. Support exists for using the EGD as an entropy source for LibVirt.</para>
<para>Once the entropy is available in the cloud, the next step is getting that entropy into the instances. Tools such as the entropy gathering daemon (<link xlink:href="http://egd.sourceforge.net/">EGD</link>) provide a way to fairly and securely distribute entropy through a distributed system. Support exists for using the EGD as an entropy source for LibVirt.</para>
<para>Nova support for these features is not generally available, but it would only require a moderate amount of work for implementors to integrate this functionality.</para>
</section>
<section xml:id="ch055_security-services-for-instances-idp128240">
<title>Scheduling Instances to Nodes</title>
<para>Before an instance is created, a host for the image instantiation must be selected. This selection is performed by the <systemitem class="service">nova-scheduler</systemitem> which determines how to dispatch compute and volume requests.</para>
<para>The default nova scheduler in Grizzly is the Filter Scheduler, although other schedulers exist (http://docs.openstack.org/trunk/openstack-compute/admin/content/other-schedulers.html). The filter scheduler works in collaboration with 'filters' to decide where an instance should be started. This process of host selection allows administrators to fulfil many different security requirements. Depending on the cloud deployment type for example, one could choose to have tenant instances reside on the same hosts whenever possible if data isolation was a primary concern, conversely one could attempt to have instances for a tenant reside on as many different hosts as possible for availability or fault tolerance reasons. The following diagram demonstrates how the filter scheduler works:</para>
<para>The default nova scheduler in Grizzly is the Filter Scheduler, although other schedulers exist (see the section <link xlink:href="http://docs.openstack.org/trunk/openstack-compute/admin/content/other-schedulers.html">Other Schedulers</link> in the <citetitle>OpenStack Compute Administration Guide</citetitle>). The filter scheduler works in collaboration with 'filters' to decide where an instance should be started. This process of host selection allows administrators to fulfil many different security requirements. Depending on the cloud deployment type for example, one could choose to have tenant instances reside on the same hosts whenever possible if data isolation was a primary concern, conversely one could attempt to have instances for a tenant reside on as many different hosts as possible for availability or fault tolerance reasons. The following diagram demonstrates how the filter scheduler works:</para>
<para><inlinemediaobject><imageobject role="html">
<imagedata contentdepth="400" contentwidth="550" fileref="static/filteringWorkflow1.png" format="PNG" scalefit="1"/>
</imageobject>
@ -36,12 +36,12 @@
</imageobject>
</inlinemediaobject></para>
<para>The use of scheduler filters may be used to segregate customers, data, or even discard machines of the cloud that cannot be attested as secure. This generally applies to all OpenStack projects offering a scheduler. When building a cloud, you may choose to implement scheduling filters for a variety of security-related purposes.</para>
<para>Below we highlight a few of the filters that may be useful in a security context, depending on your requirements, the full set of filter documentation is available here: http://docs.openstack.org/trunk/openstack-compute/admin/content/scheduler-filters.html</para>
<para>Below we highlight a few of the filters that may be useful in a security context, depending on your requirements, the full set of filter documentation is documented in the <link xlink:href="http://docs.openstack.org/trunk/openstack-compute/admin/content/scheduler-filters.html">Scheduler Filters</link> section of the <citetitle>OpenStack Compute Administration Guide</citetitle></para>
<para><emphasis role="bold">Tenant Driven Whole Host Reservation</emphasis></para>
<para>There currently exists a blueprint for whole host reservation - https://blueprints.launchpad.net/nova/+spec/whole-host-allocation This would allow a tenant to exclusively reserve hosts for only it's instances, incurring extra costs.</para>
<para>There currently exists a <link xlink:href="https://blueprints.launchpad.net/nova/+spec/whole-host-allocation">blueprint for whole host reservation</link> - This would allow a tenant to exclusively reserve hosts for only it's instances, incurring extra costs.</para>
<section xml:id="ch055_security-services-for-instances-idp140080">
<title>Host Aggregates</title>
<para>While not a filter in themselves, host aggregates allow administrators to assign key-value pairs to groups of machines. This allows cloud administrators, not users, to partition up their compute host resources. Each node can have multiple aggregates. See http://docs.openstack.org/trunk/openstack-compute/admin/content/host-aggregates.html for more information on creating and managing aggregates.</para>
<para>While not a filter in themselves, host aggregates allow administrators to assign key-value pairs to groups of machines. This allows cloud administrators, not users, to partition up their compute host resources. Each node can have multiple aggregates (see the <link xlink:href="http://docs.openstack.org/trunk/openstack-compute/admin/content/host-aggregates.html">Host Aggregates</link> section of the <citetitle>OpenStack Compute Administration Guide</citetitle> for more information on creating and managing aggregates).</para>
</section>
<section xml:id="ch055_security-services-for-instances-idp142048">
<title>AggregateMultiTenancyIsolation</title>
@ -57,8 +57,8 @@
</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 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>
<para>There exists a scheduler filter which integrates with the <link xlink:href="https://github.com/OpenAttestation/OpenAttestation">Open Attestation Project</link> (OATS) 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 <link xlink:href="http://trousers.sourceforge.net/">TrouSerS library</link>.</para>
</section>
</section>
<section xml:id="ch055_security-services-for-instances-idp150416">
@ -77,7 +77,7 @@ wget http://mirror.anl.gov/pub/ubuntu-iso/CDs/precise/SHA256SUMS.gpg
gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 0xFBB75451
gpg --verify SHA256SUMS.gpg SHA256SUMSsha256sum -c SHA256SUMS 2&gt;&amp;1 | grep OK
</screen>
<para>The second option is to use the OpenStack guide for building images (http://docs.openstack.org/trunk/openstack-compute/admin/content/creating-custom-images.html). In this case, you will want to follow your organizations OS hardening guidelines or those provided by a trusted third-party such as the RHEL6 STIG (http://iase.disa.mil/stigs/os/unix/red_hat.html).</para>
<para>The second option is to use the <link xlink:href="http://docs.openstack.org/trunk/openstack-compute/admin/content/creating-custom-images.html">OpenStack guide for building images</link>. In this case, you will want to follow your organizations OS hardening guidelines or those provided by a trusted third-party such as the <link xlink:href="http://iase.disa.mil/stigs/os/unix/red_hat.html">RHEL6 STIG</link>.</para>
<para>The final option is to use an automated image builder. The following example uses the Oz image builder. The OpenStack community has recently created a newer tool worth investigating: disk-image-builder. We have not evaluated this tool from a security perspective.</para>
<para>Example of RHEL 6 CCE-26976-1 which will help implement NIST 800-53 Section <emphasis>AC-19(d) in</emphasis> Oz.</para>
<screen> 

10
doc/src/docbkx/openstack-security/ch058_forensicsincident-response.xml
View File

@ -3,7 +3,7 @@
<title>Forensics and Incident Response</title>
<para>A lot of activity goes on within a cloud environment. It is a mix of hardware, operating systems, virtual machine managers, the OpenStack services, cloud-user activity such as creating instances and attaching storage, the network underlying the whole, and finally end-users using the applications running on the various instances.</para>
<para>The generation and collection of logs is an important component of securely monitoring an OpenStack infrastructure. Logs provide visibility into the day-to-day actions of administrators, tenants, and guests, in addition to the activity in the compute, networking, and storage and other components that comprise your OpenStack deployment.</para>
<para>The basics of logging: configuration, setting log level, location of the log files, and how to use and customize logs, as well as how to do centralized collections of logs is well covered in the OpenStack Operations Guide (http://docs.openstack.org/ops/).</para>
<para>The basics of logging: configuration, setting log level, location of the log files, and how to use and customize logs, as well as how to do centralized collections of logs is well covered in the <link xlink:href="http://docs.openstack.org/ops/"><citetitle>OpenStack Operations Guide</citetitle></link>.</para>
<para>Logs are not only valuable for proactive security and continuous compliance activities, but they are also a valuable information  source for investigating and responding to incidents.</para>
<para>For instance, analyzing the access logs of Keystone or its replacement authentication system would alert us to failed logins, their frequency, origin IP, whether the events are restricted to select accounts etc. Log analysis supports detection.</para>
<para>On detection, further action may be to black list an IP, or recommend strengthening user passwords, or even de-activating a user account if it is deemed dormant.</para>
@ -41,9 +41,9 @@
</section>
<section xml:id="ch058_forensicsincident-response-idp60512">
<title>References</title>
<para>http://www.mirantis.com/blog/openstack-monitoring/</para>
<para>http://blog.sflow.com/2012/01/host-sflow-distributed-agent.html</para>
<para>http://blog.sflow.com/2009/09/lan-and-wan.html</para>
<para>http://blog.sflow.com/2013/01/rapidly-detecting-large-flows-sflow-vs.html</para>
<para><link xlink:href="http://www.mirantis.com/blog/openstack-monitoring/">http://www.mirantis.com/blog/openstack-monitoring/</link></para>
<para><link xlink:href="http://blog.sflow.com/2012/01/host-sflow-distributed-agent.html">http://blog.sflow.com/2012/01/host-sflow-distributed-agent.html</link></para>
<para><link xlink:href="http://blog.sflow.com/2009/09/lan-and-wan.html">http://blog.sflow.com/2009/09/lan-and-wan.html</link></para>
<para><link xlink:href="http://blog.sflow.com/2013/01/rapidly-detecting-large-flows-sflow-vs.html">http://blog.sflow.com/2013/01/rapidly-detecting-large-flows-sflow-vs.html</link></para>
</section>
</chapter>

8
doc/src/docbkx/openstack-security/ch062_audit-guidance.xml
View File

@ -13,11 +13,11 @@
<title>Determining Audit Scope</title>
<para>Determining audit scope, specifically what controls are needed and how to design or modify an OpenStack deployment to satisfy them, should be the initial planning step.</para>
<para>When scoping OpenStack deployments for compliance purposes, consider prioritizing controls around sensitive services, such as command and control functions and the base virtualization technology. Compromises of these facilities may impact an OpenStack environment in its entirety.</para>
<para>Scope reduction helps ensure OpenStack architects establish high quality security controls which are tailored to a particular deployment, however it is paramount to ensure these practices do not omit areas or features from security hardening. A common example is applicable to PCI-DSS guidelines, where payment related infrastructure may be scrutinized for security issues, but supporting services are left ignored, and vulnerable to attack. </para>
<para>Scope reduction helps ensure OpenStack architects establish high quality security controls which are tailored to a particular deployment, however it is paramount to ensure these practices do not omit areas or features from security hardening. A common example is applicable to PCI-DSS guidelines, where payment related infrastructure may be scrutinized for security issues, but supporting services are left ignored, and vulnerable to attack.</para>
<para>When addressing compliance, you can increase efficiency and reduce work effort by identifying common areas and criteria that apply across multiple certifications. Much of the audit principles and guidelines discussed in this book will assist in identifying these controls, additionally a number of external entities provide comprehensive lists. The following are some examples:</para>
<para>The Cloud Security Alliance Cloud Controls Matrix (CCM, https://cloudsecurityalliance.org/research/ccm/) assists both cloud providers and consumers in assessing the overall security of a cloud provider. The CSA CMM provides a controls framework that map to many industry-accepted standards and regulations including the ISO 27001/2, ISACA, COBIT, PCI, NIST, Jericho Forum and NERC CIP.</para>
<para>The SCAP Security Guide (https://fedorahosted.org/scap-security-guide/) is another useful reference.  This is still an emerging source, but we anticipate that this will grow into a tool with controls mappings that are more focused on the US federal government certifications and recommendations.  For example, the SCAP Security Guide currently has some mappings for security technical implementation guides (STIGs) and NIST-800-53.</para>
<para>These control mappings will help identify common control criteria across certifications, and provide visibility to both auditors  and auditees on problem areas within control sets for particular compliance certifications and attestations.</para>
<para>The <link xlink:href="https://cloudsecurityalliance.org/research/ccm/">Cloud Security Alliance Cloud Controls Matrix</link> (CCM) assists both cloud providers and consumers in assessing the overall security of a cloud provider. The CSA CMM provides a controls framework that map to many industry-accepted standards and regulations including the ISO 27001/2, ISACA, COBIT, PCI, NIST, Jericho Forum and NERC CIP.</para>
<para>The <link xlink:href="https://fedorahosted.org/scap-security-guide/">SCAP Security Guide</link> is another useful reference. This is still an emerging source, but we anticipate that this will grow into a tool with controls mappings that are more focused on the US federal government certifications and recommendations. For example, the SCAP Security Guide currently has some mappings for security technical implementation guides (STIGs) and NIST-800-53.</para>
<para>These control mappings will help identify common control criteria across certifications, and provide visibility to both auditors and auditees on problem areas within control sets for particular compliance certifications and attestations.</para>
</section>
<section xml:id="ch062_audit-guidance-idp55568">
<title>Internal Audit</title>

8
doc/src/docbkx/openstack-security/ch063_compliance-activities.xml
View File

@ -4,7 +4,7 @@
<para>There are a number of standard activities that will greatly assist with the compliance process. In this chapter we outline some of the most common compliance activities. These are not specific to OpenStack, however we provide references to relevant sections in this book as useful context.</para>
<section xml:id="ch063_compliance-activities-idp44544">
<title>Information Security Management System (ISMS)</title>
<para>An Information Security Management System (ISMS) is a comprehensive set of policies and processes that an organization creates and maintains to manage risk to information assets. The most common ISMS for cloud deployments is ISO/IEC 27001/2 (http://www.27000.org/iso-27001.htm), which creates a solid foundation of security controls and practices for achieving more stringent compliance certifications.</para>
<para>An Information Security Management System (ISMS) is a comprehensive set of policies and processes that an organization creates and maintains to manage risk to information assets. The most common ISMS for cloud deployments is <link xlink:href="http://www.27000.org/iso-27001.htm">ISO/IEC 27001/2</link>, which creates a solid foundation of security controls and practices for achieving more stringent compliance certifications.</para>
</section>
<section xml:id="ch063_compliance-activities-idp46224">
<title>Risk Assessment</title>
@ -35,9 +35,9 @@
modelling, source code analysis and penetration testing. There
are many techniques and recommendations for conducting security
reviews that can be found publicly posted. A well-tested example
is the Microsoft SDL, created as part of the Microsoft
Trustworthy Computing Initiative
(http://www.microsoft.com/security/sdl/process/release.aspx).</para>
is the <link xlink:href="http://www.microsoft.com/security/sdl/process/release.aspx">Microsoft SDL</link>,
created as part of the Microsoft
Trustworthy Computing Initiative.</para>
</section>
<section xml:id="ch063_compliance-activities-idp54592">
<title>Vulnerability Management</title>

27
doc/src/docbkx/openstack-security/ch064_certifications-compliance-statements.xml
View File

@ -8,7 +8,8 @@
<para>After completing these initial certifications, the remaining certifications are more deployment specific. For example, clouds processing credit card transactions will need PCI-DSS, clouds storing health care information require HIPAA, and clouds within the federal government may require FedRAMP/FISMA, and ITAR, certifications. </para>
<section xml:id="ch064_certifications-compliance-statements-idp47472">
<title>SOC 1 (SSAE 16) / ISAE 3402</title>
<para>Service Organization Controls (SOC) criteria are defined by the American Institute of Certified Public Accountants (AICPA, http://www.aicpa.org/). SOC controls assess relevant financial statements and assertions of a service provider, such as compliance with the Sarbanes-Oxley Act. SOC 1 is a replacement for Statement on Auditing Standards No. 70 (SAS 70) Type II report. These controls commonly include physical data centers in scope.</para>
<para>Service Organization Controls (SOC) criteria are defined
by the <link xlink:href="http://www.aicpa.org/">American Institute of Certified Public Accountants</link> (AICPA). SOC controls assess relevant financial statements and assertions of a service provider, such as compliance with the Sarbanes-Oxley Act. SOC 1 is a replacement for Statement on Auditing Standards No. 70 (SAS 70) Type II report. These controls commonly include physical data centers in scope.</para>
<para>There are two types of SOC 1 reports:</para>
<itemizedlist><listitem>
<para>Type 1 – report on the fairness of the presentation of management’s description of the service organization’s system and the suitability of the design of the controls to achieve the related control objectives included in the description as of a specified date.</para>
@ -17,31 +18,31 @@
<para>Type 2 – report on the fairness of the presentation of management’s description of the service organization’s system and the suitability of the design and operating effectiveness of the controls to achieve the related control objectives included in the description throughout a specified period</para>
</listitem>
</itemizedlist>
<para>For more details see http://www.aicpa.org/InterestAreas/FRC/AssuranceAdvisoryServices/Pages/AICPASOC1Report.aspx.</para>
<para>For more details see the <link xlink:href="http://www.aicpa.org/InterestAreas/FRC/AssuranceAdvisoryServices/Pages/AICPASOC1Report.aspx">AICPA Report on Controls at a Service Organization Relevant to User Entities’ Internal Control over Financial Reporting</link>.</para>
</section>
<section xml:id="ch064_certifications-compliance-statements-idp53632">
<title>SOC 2</title>
<para>Service Organization Controls (SOC) 2 is a self attestation of controls that affect the security, availability, and processing integrity of the systems a service organization uses to process users' data and the confidentiality and privacy of information processed by these system. Examples of users are those responsible for governance of the service organization; customers of the service organization; regulators; business partners; suppliers and others who have an understanding of the service organization and its controls.</para>
<para>There are two types of SOC 2 reports:</para>
<itemizedlist><listitem>
<para>Type 1 – report on the fairness of the presentation of management’s description of the service organization’s system and the suitability of the design of the controls to achieve the related control objectives included in the description as of a specified date.  </para>
<para>Type 1 – report on the fairness of the presentation of management’s description of the service organization’s system and the suitability of the design of the controls to achieve the related control objectives included in the description as of a specified date.</para>
</listitem>
<listitem>
<para>Type 2 – report on the fairness of the presentation of management’s description of the service organization’s system and the suitability of the design and operating effectiveness of the controls to achieve the related control objectives included in the description throughout a specified period.</para>
</listitem>
</itemizedlist>
<para>For more details see http://www.aicpa.org/InterestAreas/FRC/AssuranceAdvisoryServices/Pages/AICPASOC2Report.aspx.</para>
<para>For more details see the <link xlink:href="http://www.aicpa.org/InterestAreas/FRC/AssuranceAdvisoryServices/Pages/AICPASOC2Report.aspx">AICPA Report on Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality or Privacy</link>.</para>
</section>
</section>
<section xml:id="ch064_certifications-compliance-statements-idp60416">
<title>SOC 3</title>
<para>Service Organization Controls (SOC) 3 is a trust services report for service organizations. These reports are designed to meet the needs of users who want assurance on the controls at a service organization related to security, availability, processing integrity, confidentiality, or privacy but do not have the need for or the knowledge necessary to make effective use of a SOC 2 Report. These reports are prepared using the AICPA/Canadian Institute of Chartered Accountants (CICA) Trust Services Principles, Criteria, and Illustrations for Security, Availability, Processing Integrity, Confidentiality, and Privacy. Because they are general use reports, SOC 3 Reports can be freely distributed or posted on a website as a seal.</para>
<para>For more details see http://www.aicpa.org/InterestAreas/FRC/AssuranceAdvisoryServices/Pages/AICPASOC3Report.aspx.</para>
<para>For more details see the <link xlink:href="http://www.aicpa.org/InterestAreas/FRC/AssuranceAdvisoryServices/Pages/AICPASOC3Report.aspx">AICPA Trust Services Report for Service Organizations</link>.</para>
</section>
<section xml:id="ch064_certifications-compliance-statements-idp62832">
<title>ISO 27001/2</title>
<para>The ISO/IEC 27001/2 standards replace BS7799-2, and are specifications for an Information Security Management System (ISMS). An ISMS is a comprehensive set of policies and processes that an organization creates and maintains to manage risk to information assets.  These risks are based upon the confidentiality, integrity, and availability (CIA) of user information. The CIA security triad has been used as a foundation for much of the chapters in this book.</para>
<para>For more details see http://www.27000.org/iso-27001.htm.</para>
<para>For more details see <link xlink:href="http://www.27000.org/iso-27001.htm">ISO 27001</link>.</para>
</section>
<section xml:id="ch064_certifications-compliance-statements-idp65296">
<title>HIPAA / HITECH</title>
@ -49,26 +50,26 @@
<para>HIPAA is not a certification, rather a guide for protecting healthcare data.  Similar to the PCI-DSS, the most important issues with both PCI and HIPPA is that a breach of credit card information, and health data, do not occur. In the instance of a breach the cloud provider will be scrutinized for compliance with PCI and HIPPA controls. If proven compliant, the provider can be expected to immediately implement remedial controls, breach notification responsibilities, and significant expenditure on additional compliance activities.  If not compliant, the cloud provider can expect on-site audit teams, fines, potential loss of merchant ID (PCI), and massive reputational impact.</para>
<para>Users or organizations that possess PHI must support HIPAA requirements and are HIPAA covered entities. If an entity intends to use a service, or in this case, an OpenStack cloud that might use, store or have access to that PHI, then a Business Associate Agreement must be signed. The BAA is a contract between the HIPAA covered entity and the OpenStack service provider that requires the provider to handle that PHI in accordance with HIPAA requirements. If the service provider does not handle the PHI (e.g. with security controls and hardening) then they are subject to HIPAA fines and penalties.</para>
<para>OpenStack architects interpret and respond to HIPAA statements, with data encryption remaining a core practice. Currently this would require any protected health information contained within an OpenStack deployment to be encrypted with industry standard encryption algorithms. Potential future OpenStack projects such as Swift object encryption will facilitate HIPAA guidelines for compliance with the act.</para>
<para>For more details see https://www.cms.gov/Regulations-and-Guidance/HIPAA-Administrative-Simplification/HIPAAGenInfo/downloads/HIPAALaw.pdf.</para>
<para>For more details see the <link xlink:href="https://www.cms.gov/Regulations-and-Guidance/HIPAA-Administrative-Simplification/HIPAAGenInfo/downloads/HIPAALaw.pdf">Health Insurance Portability And Accountability Act</link>.</para>
<section xml:id="ch064_certifications-compliance-statements-idp4736">
<title>PCI-DSS</title>
<para>The Payment Card Industry Data Security Standard (PCI DSS) is defined by the Payment Card Industry Standards Council, and created to increase controls around card holder data to reduce credit card fraud. Annual compliance validation is assessed by an external Qualified Security Assessor (QSA) who creates a Report on Compliance (ROC), or by a Self-Assessment Questionnaire (SAQ) dependent on volume of card-holder transactions.  </para>
<para>OpenStack deployments which stores, processes, or transmits payment card details are in scope for the PCI-DSS. All OpenStack components that are not properly segmented from systems or networks that handle payment data fall under the guidelines of the PCI-DSS. Segmentation in the context of PCI-DSS does not support multi-tenancy, but rather physical separation (host/network). </para>
<para>For more details see https://www.pcisecuritystandards.org/security_standards/.</para>
<para>For more details see <link xlink:href="https://www.pcisecuritystandards.org/security_standards/">PCI security standards</link>.</para>
</section>
</section>
<section xml:id="ch064_certifications-compliance-statements-idp8448">
<title>Government Standards</title>
<section xml:id="ch064_certifications-compliance-statements-idp9088">
<title>FedRAMP</title>
<para>"The Federal Risk and Authorization Management Program (FedRAMP) is a government-wide program that provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services" (http://www.fedramp.gov). NIST 800-53 is the basis for both FISMA and FedRAMP which mandates security controls specifically selected to provide protection in cloud environments. FedRAMP can be extremely intensive from specificity around security controls, and the volume of documentation required to meet government standards.</para>
<para>For more details see http://www.gsa.gov/portal/category/102371.</para>
<para>"The <link xlink:href="http://www.fedramp.gov">Federal Risk and Authorization Management Program</link> (FedRAMP) is a government-wide program that provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services". NIST 800-53 is the basis for both FISMA and FedRAMP which mandates security controls specifically selected to provide protection in cloud environments. FedRAMP can be extremely intensive from specificity around security controls, and the volume of documentation required to meet government standards.</para>
<para>For more details see <link xlink:href="http://www.gsa.gov/portal/category/102371">http://www.gsa.gov/portal/category/102371</link>.</para>
</section>
<section xml:id="ch064_certifications-compliance-statements-idp10768">
<title>ITAR</title>
<para>The International Traffic in Arms Regulations (ITAR) is a set of</para>
<para>United States government regulations that control the export and import of defense-related articles and services on the United States Munitions List (USML) and related technical data. ITAR is often approached by cloud providers as an "operational alignment" rather than a formal certification. This typically involves implementing a segregated cloud environment following practices based on the NIST 800-53 framework, as per FISMA requirements, complemented with additional controls restricting access to "U.S. Persons" only and background screening.</para>
<para>For more details see http://pmddtc.state.gov/regulations_laws/itar_official.html.</para>
<para>The International Traffic in Arms Regulations (ITAR) is a set of
United States government regulations that control the export and import of defense-related articles and services on the United States Munitions List (USML) and related technical data. ITAR is often approached by cloud providers as an "operational alignment" rather than a formal certification. This typically involves implementing a segregated cloud environment following practices based on the NIST 800-53 framework, as per FISMA requirements, complemented with additional controls restricting access to "U.S. Persons" only and background screening.</para>
<para>For more details see <link xlink:href="http://pmddtc.state.gov/regulations_laws/itar_official.html">http://pmddtc.state.gov/regulations_laws/itar_official.html</link>.</para>
</section>
<section xml:id="ch064_certifications-compliance-statements-idp89888">
<title>FISMA</title>

2
doc/src/docbkx/openstack-security/ch065_privacy.xml
View File

@ -2,7 +2,7 @@
<chapter xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://docbook.org/ns/docbook" xmlns:db="http://docbook.org/ns/docbook" version="5.0" xml:id="ch065_privacy"><?dbhtml stop-chunking?>
<title>Privacy</title>
<para>Privacy is an increasingly important element of a compliance program. Businesses are being held to a higher standard by their customers, who have increased interest in understanding how their data is treated from a privacy perspective.</para>
<para>An OpenStack deployment will likely need to demonstrate compliance with an organization’s Privacy Policy, with the U.S. – E.U. Safe Harbor framework, the ISO/IEC 29100:2011 privacy framework or with other privacy-specific guidelines. In the U.S. the AICPA has defined 10 privacy areas of focus, OpenStack deployments within a commercial environment may desire to attest to some or all of these principles. (http://www.aicpa.org/interestareas/informationtechnology/resources/privacy/generallyacceptedprivacyprinciples/).</para>
<para>An OpenStack deployment will likely need to demonstrate compliance with an organization’s Privacy Policy, with the U.S. – E.U. Safe Harbor framework, the ISO/IEC 29100:2011 privacy framework or with other privacy-specific guidelines. In the U.S. the AICPA has <link xlink:href="http://www.aicpa.org/interestareas/informationtechnology/resources/privacy/generallyacceptedprivacyprinciples/">defined 10 privacy areas of focus</link>, OpenStack deployments within a commercial environment may desire to attest to some or all of these principles.</para>
<para>To aid OpenStack architects in the protection of personal data, it is recommended that OpenStack architects review the NIST publication 800-122, titled "<emphasis>Guide to Protecting the Confidentiality of Personally Identifiable Information (PII)</emphasis>." This guide steps through the process of protecting:</para>
<blockquote>
<para>"<emphasis>any information about an individual maintained by an agency, including (1) any information that can be used to distinguish or trace an individual‘s identity, such as name, social security number, date and place of birth, mother‘s maiden name, or biometric records; and (2) any other information that is linked or linkable to an individual, such as medical, educational, financial, and employment information</emphasis>"</para>

2
doc/src/docbkx/openstack-security/ch066_case-studies-compliance.xml
View File

@ -6,7 +6,7 @@
<title>Alice's Private Cloud</title>
<para>Alice is building an OpenStack private cloud for the United States government, specifically to provide elastic compute environments for signal processing. Alice has researched government compliance requirements, and has identified that her private cloud will be required to certify against FISMA and follow the FedRAMP accreditation process, which is required for all federal agencies, departments and contractors to become a Certified Cloud Provider (CCP). In this particular scenario for signal processing, the FISMA controls required will most likely be FISMA High, which indicates possible "severe or catastrophic adverse effects" should the information system become compromised. In addition to FISMA Moderate controls Alice must ensure her private cloud is FedRAMP certified, as this is a requirement for all agencies that currently utilize, or host federal information within a cloud environment.</para>
<para>To meet these strict government regulations Alice undertakes a number of activities. Scoping of requirements is particularly important due to the volume of controls that must be implemented, which will be defined in NIST Publication 800-53.</para>
<para>All technology within her private cloud must be FIPS certified technology, as mandated within NIST 800-53 and FedRAMP. As the U.S. Department of Defense is involved, Security Technical Implementation Guides (STIGs) will come into play, which are the configuration standards for DOD IA and IA-enabled devices / systems. Alice notices a number of complications here as there is no STIG for OpenStack, so she must address several underlying requirements for each OpenStack service, e.g. the networking SRG and Application SRG will both be applicable (http://iase.disa.mil/srgs/index.html). Other critical controls include ensuring that all identities in the cloud use PKI, that SELinux is enabled, that encryption exists for all wire-level communications, and that continuous monitoring is in place and clearly documented. Alice is not concerned with object encryption, as this will be the tenants responsibility rather than the provider.</para>
<para>All technology within her private cloud must be FIPS certified technology, as mandated within NIST 800-53 and FedRAMP. As the U.S. Department of Defense is involved, Security Technical Implementation Guides (STIGs) will come into play, which are the configuration standards for DOD IA and IA-enabled devices / systems. Alice notices a number of complications here as there is no STIG for OpenStack, so she must address several underlying requirements for each OpenStack service, e.g. the networking SRG and Application SRG will both be applicable (<link xlink:href="http://iase.disa.mil/srgs/index.html">list of SRGs</link>). Other critical controls include ensuring that all identities in the cloud use PKI, that SELinux is enabled, that encryption exists for all wire-level communications, and that continuous monitoring is in place and clearly documented. Alice is not concerned with object encryption, as this will be the tenants responsibility rather than the provider.</para>
<para>If Alice has adequately scoped and executed these compliance activities, she may begin the process to become FedRAMP compliant by hiring an approved third-party auditor. Typically this process takes up to 6 months, after which she will receive an Authority to Operate and can offer OpenStack cloud services to the government.</para>
</section>
<section xml:id="ch066_case-studies-compliance-idp49712">