Security Guide final spellcheck, duplicate word elimination, page break check.
Change-Id: I829d32396e638d07e47e2210ea3affd0a79e1a02
This commit is contained in:
annegentle
parent
b132332c97
commit
233d33e21d
@ -49,19 +49,20 @@
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis role="bold">Cody Bunch</emphasis>, Rackspace</para>
|
||||
<para>Cody Bunch is a Private Cloud architect with Rackspce. Cody has co-authored an update to "The OpenStack Cookbook" as well as books on VMware automation.</para>
|
||||
<para>Cody Bunch is a Private Cloud architect with Rackspace. Cody has co-authored an update to "The OpenStack Cookbook" as well as books on VMware automation.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis role="bold">Malini Bhandaru</emphasis>, Intel</para>
|
||||
<para>Malini Bhandaru is a security architect at Intel. She has a varied background, having worked on platform power and performance at Intel, speech products at Nuance, remote monitoring and management at ComBrio, and web commerce at Verizon. She has a Ph.D. in Artificial Intelligence from Univ of Massachusetts, Amherst.</para>
|
||||
</listitem>
|
||||
<?hard-pagebreak?>
|
||||
<listitem>
|
||||
<para><emphasis role="bold">Gregg Tally</emphasis>, Johns Hopkins University Applied Physics Laboratory</para>
|
||||
<para>Gregg Tally is the Chief Engineer at JHU/APL's Cyber Systems Group within the Asymmetric Operations Department. He works primarily in systems security engineering. Previously, he has worked at SPARTA, McAfee, and Trusted Information Systems where he was involved in cyber security research projects.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis role="bold">Eric Lopez</emphasis>, Nicira / VMware</para>
|
||||
<para>Eric Lopez is Senior Solution Architect at VMware's Networking and Security Business Unit where he helps customer implement Openstack and Nicira's Network Virtualization Platform. Prior to joining Nicira, he worked for Q1 Labs, Symantec, Vontu, and Brightmail. He has a B.S in Electrical Engineering/Computer Science and Nuclear Engineering from U.C. Berkeley and MBA from University of San Francisco.</para>
|
||||
<para>Eric Lopez is Senior Solution Architect at VMware's Networking and Security Business Unit where he helps customer implement OpenStack and Nicira's Network Virtualization Platform. Prior to joining Nicira, he worked for Q1 Labs, Symantec, Vontu, and Brightmail. He has a B.S in Electrical Engineering/Computer Science and Nuclear Engineering from U.C. Berkeley and MBA from University of San Francisco.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis role="bold">Shawn Wells</emphasis>, Red Hat</para>
|
||||
@ -106,6 +107,6 @@
|
||||
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: (http://wiki.openstack.org/Documentation/HowTo).</para>
|
||||
</section>
|
||||
</chapter>
|
||||
|
||||
@ -8,6 +8,12 @@
|
||||
</section>
|
||||
<section xml:id="ch006_introduction-to-case-studies-idp46720">
|
||||
<title>Case Study : Bob the public cloud provider</title>
|
||||
<para>Bob is a lead architect for a company deploying a large greenfield public cloud. This cloud will provide IaaS for the masses, allowing any consumer with a valid credit-card access to utility computing and storage but the primary focus is enterprise customers. Data privacy concerns are a big priority for Bob as it's seen as a major barrier to large-scale adoption of the cloud by Organizatons.</para>
|
||||
<para>Bob is a lead architect for a company deploying a large
|
||||
greenfield public cloud. This cloud will provide IaaS for the
|
||||
masses, allowing any consumer with a valid credit-card access to
|
||||
utility computing and storage but the primary focus is
|
||||
enterprise customers. Data privacy concerns are a big priority
|
||||
for Bob as they are seen as a major barrier to large-scale
|
||||
adoption of the cloud by organizations.</para>
|
||||
</section>
|
||||
</chapter>
|
||||
|
||||
@ -31,7 +31,14 @@
|
||||
</section>
|
||||
<section xml:id="ch008_system-roles-types-idp57520">
|
||||
<title>Services, Protocols and Ports</title>
|
||||
<para>The Service, Protocols and Ports table provides important additional detail of an OpenStack deployment. A table view of all services running within the cloud infrastructure can immediately inform, guide and check security procedures. Firewall configuration, service port conflicts, security remediation areas, and compliance requirements become easier to manage when you have concise information available. E.g. tablular information as shown below.</para>
|
||||
<para>The Service, Protocols and Ports table provides important
|
||||
additional detail of an OpenStack deployment. A table view of
|
||||
all services running within the cloud infrastructure can
|
||||
immediately inform, guide and check security procedures.
|
||||
Firewall configuration, service port conflicts, security
|
||||
remediation areas, and compliance requirements become easier to
|
||||
manage when you have concise information available. E.g. tabular
|
||||
information as shown below.</para>
|
||||
<para><inlinemediaobject><imageobject role="html">
|
||||
<imagedata contentdepth="166" contentwidth="967" fileref="static/services-protocols-ports.png" format="PNG" scalefit="1"/>
|
||||
</imageobject>
|
||||
|
||||
@ -9,6 +9,7 @@
|
||||
<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 here: https://launchpad.net/ossn/</para>
|
||||
<section xml:id="ch012_configuration-management-idp48592">
|
||||
<?hard-pagebreak?>
|
||||
<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 indicating. 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>
|
||||
|
||||
@ -68,7 +69,7 @@
|
||||
</tbody>
|
||||
</informaltable>
|
||||
|
||||
<para>We suggest cloud administrators customize and expand this table to suit their needs. Then work to define how to handle the various severity levels. For example, a critical-level security update might require the cloud to be upgraded on a specified timeline, whereas a low-level update might be more relaxed.</para>
|
||||
<para>We suggest cloud administrators customize and expand this table to suit their needs. Then work to define how to handle the various severity levels. For example, a critical-level security update might require the cloud to be upgraded on a specified time line, whereas a low-level update might be more relaxed.</para>
|
||||
</section>
|
||||
<section xml:id="ch012_configuration-management-idp100864">
|
||||
<title>Testing the Updates</title>
|
||||
|
||||
@ -102,7 +102,13 @@
|
||||
</section>
|
||||
<section xml:id="ch014_best-practices-for-operator-mode-access-idp76272">
|
||||
<title>OpenStack Management Utilities</title>
|
||||
<para>The Openstack Management Utilities are open-source Python command-line clients that make API calls. There is a client for each OpenStack service (nova, glance, etc.). In addition to the standard CLI client, most of the services have a management command line which makes direct calls to the database. These dedicated management utilities are slowly being deprecated.</para>
|
||||
<para>The OpenStack Management Utilities are open-source Python
|
||||
command-line clients that make API calls. There is a client for
|
||||
each OpenStack service (nova, glance, etc.). In addition to the
|
||||
standard CLI client, most of the services have a management
|
||||
command line which makes direct calls to the database. These
|
||||
dedicated management utilities are slowly being
|
||||
deprecated.</para>
|
||||
<section xml:id="ch014_best-practices-for-operator-mode-access-idp77728">
|
||||
<title>Security Considerations</title>
|
||||
<itemizedlist><listitem>
|
||||
|
||||
@ -156,7 +156,9 @@ server {
|
||||
Allow from all
|
||||
</Directory>
|
||||
</VirtualHost></screen>
|
||||
<para>Compute API SSL endpoint in Apache2, which needs to be paired with a short WSGI script</para>
|
||||
<?hard-pagebreak?>
|
||||
<para>Compute API SSL endpoint in Apache2, which needs to be paired with
|
||||
a short WSGI script.</para>
|
||||
<screen>
|
||||
<VirtualHost <ip address>:8447>
|
||||
ServerName <site FQDN>
|
||||
|
||||
@ -16,7 +16,8 @@
|
||||
<para> Openstack Network Node: Management, Guest, and possibly Public depending upon quantum-plugin in use.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para> SDN Services Node: Management, Guest and and possibly Public depending upon product used.</para>
|
||||
<para> SDN Services Node: Management, Guest and possibly
|
||||
Public depending upon product used.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para><inlinemediaobject><imageobject role="html">
|
||||
|
||||
@ -71,7 +71,8 @@
|
||||
<para> Track, document and verify media sanitization and disposal actions.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para> Test sanitiation equipment and procedures to verify proper performance.</para>
|
||||
<para> Test sanitation equipment and procedures to verify
|
||||
proper performance.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para> Sanitize portable, removable storage devices prior to connecting such devices to the cloud infrastructure.</para>
|
||||
|
||||
@ -30,7 +30,10 @@
|
||||
</section>
|
||||
<section xml:id="ch047_data-encryption-idp57488">
|
||||
<title>Network Data</title>
|
||||
<para>Tennant data for compute could be encrypted over IPSec or other tunnels . This is not functionality common or standard in OpenStack, but is an option available to motivated and interested implementors.</para>
|
||||
<para>Tenant data for compute could be encrypted over IPSec or
|
||||
other tunnels. This is not functionality common or standard in
|
||||
OpenStack, but is an option available to motivated and
|
||||
interested implementors.</para>
|
||||
<para>Cinder block storage supports a variety of mechanisms for supplying mountable volumes. It is outside the scope of this guide to specify recommendations for each Cinder backend driver. For the purpose of performance, many storage protocols are unencrypted. Some protocols such as iSCSI can provide authentication and encrypted sessions, it is our recommendation to enable these features.</para>
|
||||
</section>
|
||||
</chapter>
|
||||
|
||||
@ -4,7 +4,13 @@
|
||||
<para>Returning to Alice and Bob, we will use this section to dive into their particular tenant data privacy requirements. Specifically, we will look into how Alice and Bob both handle tenant data, data destruction, and data encryption.</para>
|
||||
<section xml:id="ch049_case-studies-tenant-data-idp44416">
|
||||
<title>Alice's Private Cloud</title>
|
||||
<para>As stated during the introduction to Alices's case study, data protection is of an extremely high priority. She needs to ensure that a compromise of one tenant's data does not cause loss of other tenant data. She also has strong regulator requirements that require documentation of data destruction activities. Alice does this using the following:</para>
|
||||
<para>As stated during the introduction to Alice's case study,
|
||||
data protection is of an extremely high priority. She
|
||||
needs to ensure that a compromise of one tenant's data
|
||||
does not cause loss of other tenant data. She also has
|
||||
strong regulator requirements that require documentation
|
||||
of data destruction activities. Alice does this using the
|
||||
following:</para>
|
||||
<itemizedlist>
|
||||
<listitem> <para> Establishing procedures to sanitize tenant data when a program or project ends</para> </listitem>
|
||||
<listitem> <para> Track the destruction of both the tenant data and metadata via ticketing in a CMDB</para> </listitem>
|
||||
|
||||
@ -20,7 +20,22 @@
|
||||
</section>
|
||||
<section xml:id="ch052_devices-idp488320">
|
||||
<title>Virtual Hardware (QEMU)</title>
|
||||
<para>When running a virtual machine, virtual hardware is a software layer that provides the hardware interface for the virtual machine. Instances use this functionality to provide network, storage, video, and and other devices that may be needed. With this in mind, most instances in your environment will exclusively use virtual hardware, with a minority that will require direct hardware access. The major open source hypervisors use QEMU for this functionality. While QEMU fills an important need for virtualization platforms, it has proven to be a very challenging software project to write and maintain. Much of the functionality in QEMU is implemented with low-level code that is difficult for most developers to comprehend. Furthermore, the hardware virtualized by QEMU includes many legacy devices that have their own set of quirks. Putting all of this together, QEMU has been the source of many security problems, including hypervisor breakout attacks.</para>
|
||||
<para>When running a virtual machine, virtual hardware is a
|
||||
software layer that provides the hardware interface for the
|
||||
virtual machine. Instances use this functionality to provide
|
||||
network, storage, video, and other devices that may be needed.
|
||||
With this in mind, most instances in your environment will
|
||||
exclusively use virtual hardware, with a minority that will
|
||||
require direct hardware access. The major open source
|
||||
hypervisors use QEMU for this functionality. While QEMU fills an
|
||||
important need for virtualization platforms, it has proven to be
|
||||
a very challenging software project to write and maintain. Much
|
||||
of the functionality in QEMU is implemented with low-level code
|
||||
that is difficult for most developers to comprehend.
|
||||
Furthermore, the hardware virtualized by QEMU includes many
|
||||
legacy devices that have their own set of quirks. Putting all of
|
||||
this together, QEMU has been the source of many security
|
||||
problems, including hypervisor breakout attacks.</para>
|
||||
<para>For the reasons stated above, it is important to take proactive steps to harden QEMU. We recommend three specific steps: minimizing the codebase, using compiler hardening, and using mandatory access controls, for example: sVirt, SELinux, or AppArmor.</para>
|
||||
<section xml:id="ch052_devices-idp490976">
|
||||
<title>Minimizing the Qemu Codebase</title>
|
||||
@ -79,7 +94,16 @@ CFLAGS="-arch x86_64 -fstack-protector-all -Wstack-protector --param ssp-buffer-
|
||||
<para><emphasis role="bold">Hypervisor threats</emphasis> A compromised application running within a virtual machine attacks the hypervisor to access underlying resources (e.g. the host OS, applications, or devices within the physical machine). This is a threat vector unique to virtualization and represents considerable risk as the underlying real machine can be compromised due to vulnerability in a single virtual application.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis role="bold">Virtual Machine (multi-tenant) threats</emphasis> A compromised application running within a VM attacks the hypervisor to access/control another virtual machine and its resources. This is a threat vector unique to virtualization and represents considerable risk as a multitide of virtual machine file images could be compromised due to vulnerability in a single application. This virtual network attack is a major concern as the administrative techniques for protecting real networks do not directly apply to the virtual environment.</para>
|
||||
<para><emphasis role="bold">Virtual Machine (multi-tenant)
|
||||
threats</emphasis> A compromised application running
|
||||
within a VM attacks the hypervisor to access/control another
|
||||
virtual machine and its resources. This is a threat vector
|
||||
unique to virtualization and represents considerable risk as
|
||||
a multitude of virtual machine file images could be
|
||||
compromised due to vulnerability in a single application.
|
||||
This virtual network attack is a major concern as the
|
||||
administrative techniques for protecting real networks do
|
||||
not directly apply to the virtual environment.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>Each KVM-based virtual machine is a process which is labeled by SELinux, effectively establishing a security boundary around each virtual machine. This security boundary is monitored and enforced by the Linux kernel, restricting the virtual machine's access to resources outside of its boundary such as host machine data files or other VMs.</para>
|
||||
|
||||
@ -24,7 +24,20 @@
|
||||
</section>
|
||||
<section xml:id="ch063_compliance-activities-idp52592">
|
||||
<title>Security Reviews</title>
|
||||
<para>As OpenStack is a popular open source project, much of the codebase and architecture has been scrutinized by individual contributors, organizations and enterprises. This can be advantageous from a security perspective, however the need for security reviews is still a critical consideration for service providers, as deployments vary, and security is not always the primary concern for contributors. A comprehensive security review process may include architectural review, threat modelling, source code analysis and penetration testing. There are many techniques and recommendations for conducting security reviews that can be found publically 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>
|
||||
<para>As OpenStack is a popular open source project, much of the
|
||||
codebase and architecture has been scrutinized by individual
|
||||
contributors, organizations and enterprises. This can be
|
||||
advantageous from a security perspective, however the need for
|
||||
security reviews is still a critical consideration for service
|
||||
providers, as deployments vary, and security is not always the
|
||||
primary concern for contributors. A comprehensive security
|
||||
review process may include architectural review, threat
|
||||
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>
|
||||
</section>
|
||||
<section xml:id="ch063_compliance-activities-idp54592">
|
||||
<title>Vulnerability Management</title>
|
||||
|
||||
@ -11,7 +11,32 @@
|
||||
</section>
|
||||
<section xml:id="ch066_case-studies-compliance-idp49712">
|
||||
<title>Bob's Public Cloud</title>
|
||||
<para>Bob is tasked with compliance for a new OpenStack public cloud deployment, that is focused on providing cloud services to both small developers and startup-ups, as well as large enterprises. Bob recognizes that individual developers are not necessarily concerned with compliance certifications, but to larger enterprises certifications are critical. Specifically Bob desires to achieve SOC 1, SOC 2 Security, as well as ISO 27001/2 as quickly as possible. Bob references the Cloud Security Alliance Cloud Control Matrix (CCM) to assist in identifying common controls across these three certifications (such as periodic access reviews, auditable logging and monitoring services, risk assessment activities, security reviews, etc). Bob then engages an experienced audit team to conduct a gap analysis on the public cloud deployment, reviews the results and fills any gaps identified. Bob works with other team members to ensure that these security controls and activities are regularly conducted for a typical audit period (~6-12 months).</para>
|
||||
<para>At the end of the audit period Bob has arranged for an external audit team to review in-scope security controls at randomly sampled points of time over a 6 month period.The audit team provides Bob with an official report for SOC 1 and SOC 2, and separately for ISO 27001/2. As Bob has been diligent in ensuring security controls are in place for his OpenStack public cloud, there are no additional gaps exposed on the report. Bob can now provide these official reports to his customers under NDA, and advertise that he is SOC 1, SOC 2 and ISO 27001/2 compliant on his website.</para>
|
||||
<para>Bob is tasked with compliance for a new OpenStack public
|
||||
cloud deployment, that is focused on providing cloud services to
|
||||
both small developers and startups, as well as large
|
||||
enterprises. Bob recognizes that individual developers are not
|
||||
necessarily concerned with compliance certifications, but to
|
||||
larger enterprises certifications are critical. Specifically Bob
|
||||
desires to achieve SOC 1, SOC 2 Security, as well as ISO 27001/2
|
||||
as quickly as possible. Bob references the Cloud Security
|
||||
Alliance Cloud Control Matrix (CCM) to assist in identifying
|
||||
common controls across these three certifications (such as
|
||||
periodic access reviews, auditable logging and monitoring
|
||||
services, risk assessment activities, security reviews, etc).
|
||||
Bob then engages an experienced audit team to conduct a gap
|
||||
analysis on the public cloud deployment, reviews the results and
|
||||
fills any gaps identified. Bob works with other team members to
|
||||
ensure that these security controls and activities are regularly
|
||||
conducted for a typical audit period (~6-12 months).</para>
|
||||
<para>At the end of the audit period Bob has arranged for an
|
||||
external audit team to review in-scope security controls at
|
||||
randomly sampled points of time over a 6 month period. The audit
|
||||
team provides Bob with an official report for SOC 1 and SOC 2,
|
||||
and separately for ISO 27001/2. As Bob has been diligent in
|
||||
ensuring security controls are in place for his OpenStack public
|
||||
cloud, there are no additional gaps exposed on the report. Bob
|
||||
can now provide these official reports to his customers under
|
||||
NDA, and advertise that he is SOC 1, SOC 2 and ISO 27001/2
|
||||
compliant on his website.</para>
|
||||
</section>
|
||||
</chapter>
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user