Spelling updates to openstack-security-guide.
Fixes a number of minor spelling issues picked up by running the aspell en-US dictionary against the guide. Note that although the en-US dictionary was used I have shied away from fixing issues where the only cause of issue is en-GB V en-US but rather stuck to what I consider appear to be clear mistakes. Change-Id: I0bf73d31edbd0e8c42387716b4358934c78f7306
This commit is contained in:
Stephen Gordon
parent
1bb197cc93
commit
f8410ee893
@ -16,7 +16,7 @@
|
||||
</section>
|
||||
<section xml:id="ch032_networking-best-practices-idp50512">
|
||||
<title>L2 Tunneling</title>
|
||||
<para>Network tunneling encapsulates each tenant/network combination with a unqiue "tunnel-id" that is used to identify the network traffic belonging to that combination. The tenant's L2 network connectivity is independent of physical locality or underlying network design. By encapsulating traffic inside IP packets, that traffic can cross Layer-3 boundaries, removing the need for preconfigured VLANs and VLAN trunking. Tunneling adds a layer of obfuscation to network data traffic, reducing the visibility of individual tenant traffic from a monitoring point of view.</para>
|
||||
<para>Network tunneling encapsulates each tenant/network combination with a unique "tunnel-id" that is used to identify the network traffic belonging to that combination. The tenant's L2 network connectivity is independent of physical locality or underlying network design. By encapsulating traffic inside IP packets, that traffic can cross Layer-3 boundaries, removing the need for preconfigured VLANs and VLAN trunking. Tunneling adds a layer of obfuscation to network data traffic, reducing the visibility of individual tenant traffic from a monitoring point of view.</para>
|
||||
<para>OpenStack Networking currently only supports GRE encapsulation with planned future support of VXLAN due in the Havana release.</para>
|
||||
<para>The choice of technology to provide L2 isolation is dependent upon the scope and size of tenant networks that will be created in your deployment. If your environment has limited VLAN ID availability or will have a large number of L2 networks, it is our recommendation that you utilize tunneling.</para>
|
||||
</section>
|
||||
|
||||
@ -4,11 +4,11 @@
|
||||
<para>This section discusses OpenStack Networking configuration best practices as they apply to tenant network security within your OpenStack deployment.</para>
|
||||
<section xml:id="ch034_tenant-secure-networking-best-practices-idp44592">
|
||||
<title>Tenant Network Services Workflow</title>
|
||||
<para>Openstack Networking provides users real self services of network resources and configurations. It is important that Cloud Architects and Operators evaluate the their design use cases in providing users the ability to create, update, and destory available network resources.</para>
|
||||
<para>Openstack Networking provides users real self services of network resources and configurations. It is important that Cloud Architects and Operators evaluate the their design use cases in providing users the ability to create, update, and destroy available network resources.</para>
|
||||
</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 explaination 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 Authentication and Authorization chapter in the Openstack Networking Administration Guide: http://docs.openstack.org/grizzly/openstack-network/admin/content/ch_auth.html </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>
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<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="ch051_vss-intro"><?dbhtml stop-chunking?>
|
||||
<title>Hypervisor Selection</title>
|
||||
<para>Virtualization provides flexibility and other key benefits that enable cloud building. However, a virtualization stack also needs to be secured appropriately to reduce the risks associated with hypervisor breakout attacks. That is, while a virtualization stack can provide isolation between instances, or guest virtual machines, there are situations where that isolation can be less than perfect. Making intelligent selections for virtualization stack as well as following the best practices outlined in this chapter can be included in a layered approach to cloud security. Finally, securing your virtualization stack is critical in order to deliver on the npromise of multitennancy, either between customers in a public cloud, between business units in a private cloud, or some mixture of the two in a hybrid cloud.</para>
|
||||
<para>Virtualization provides flexibility and other key benefits that enable cloud building. However, a virtualization stack also needs to be secured appropriately to reduce the risks associated with hypervisor breakout attacks. That is, while a virtualization stack can provide isolation between instances, or guest virtual machines, there are situations where that isolation can be less than perfect. Making intelligent selections for virtualization stack as well as following the best practices outlined in this chapter can be included in a layered approach to cloud security. Finally, securing your virtualization stack is critical in order to deliver on the promise of multitennancy, either between customers in a public cloud, between business units in a private cloud, or some mixture of the two in a hybrid cloud.</para>
|
||||
<para>In this chapter, we discuss the hypervisor selection process. In the chapters that follow, we provide the foundational information needed for securing a virtualization stack.</para>
|
||||
<section xml:id="ch051_vss-intro-idp236592">
|
||||
<title>Hypervisors in OpenStack</title>
|
||||
|
||||
@ -16,7 +16,7 @@
|
||||
<para>Note: The IOMMU feature is marketed as VT-d by Intel and AMD-Vi by AMD.</para>
|
||||
<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 assciociated with PCI passthrough, it should be disabled by default. If enabled for a specific need, you will need to have approiate processes in place to ensure the hardware is clean before re-issue.</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>
|
||||
</section>
|
||||
<section xml:id="ch052_devices-idp488320">
|
||||
<title>Virtual Hardware (QEMU)</title>
|
||||
@ -74,7 +74,7 @@ CFLAGS="-arch x86_64 -fstack-protector-all -Wstack-protector --param ssp-buffer-
|
||||
<section xml:id="ch052_devices-idp510512">
|
||||
<title>sVirt: SELinux + Virtualization</title>
|
||||
<para>With unique kernel-level architecture and National Security Agency (NSA) developed security mechanisms, KVM provides foundational isolation technologies for multitenancy. With developmental origins dating back to 2002, the Secure Virtualization (sVirt) technology is the application of SELinux against modern day virtualization. SELinux, which was designed to apply separation control based upon labels, has been extended to provide isolation between virtual machine processes, devices, data files and system processes acting upon their behalf.</para>
|
||||
<para>OpenStack's sVirt implimentation aspires to protect hypervisor hosts and virtual machines against two primary threat vectors:</para>
|
||||
<para>OpenStack's sVirt implementation aspires to protect hypervisor hosts and virtual machines against two primary threat vectors:</para>
|
||||
<itemizedlist><listitem>
|
||||
<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>
|
||||
|
||||
@ -21,7 +21,7 @@
|
||||
<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 deamon (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 (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>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">
|
||||
|
||||
@ -29,7 +29,7 @@
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<itemizedlist><listitem>
|
||||
<para> Other events that are actionable are networking bridges going down, ip tables being flushed on nova compute nodes and consequentl loss of access to instances resulting in unhappy customers. </para>
|
||||
<para> Other events that are actionable are networking bridges going down, ip tables being flushed on nova compute nodes and consequential loss of access to instances resulting in unhappy customers. </para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<itemizedlist><listitem>
|
||||
|
||||
@ -19,7 +19,7 @@
|
||||
<title>Security Principles</title>
|
||||
<para>Industry standard security principles provide a baseline for compliance certifications and attestations. If these principles are considered and referenced throughout an OpenStack deployment, certification activities may be simplified.</para>
|
||||
<orderedlist><listitem>
|
||||
<para> <emphasis>Layered Defenses</emphasis>: Identify where risks exist in a cloud architecture and apply controls to mitigate the risks. In areas of significant concern, layered defences provide multiple complementary controls to further mitigate risk. For example, to ensure adequate isolation between cloud tenents, we recommend hardening QEMU, using a hypervisor with SELinux support, enforcing mandatory access control policies, and reducing the overall attack surface. The foundational principle is to harden an area of concern with multiple layers of defense such that if any one layer is compromised, other layers will exist to offer protection and minimize exposure.</para>
|
||||
<para> <emphasis>Layered Defenses</emphasis>: Identify where risks exist in a cloud architecture and apply controls to mitigate the risks. In areas of significant concern, layered defences provide multiple complementary controls to further mitigate risk. For example, to ensure adequate isolation between cloud tenants, we recommend hardening QEMU, using a hypervisor with SELinux support, enforcing mandatory access control policies, and reducing the overall attack surface. The foundational principle is to harden an area of concern with multiple layers of defense such that if any one layer is compromised, other layers will exist to offer protection and minimize exposure.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para> <emphasis>Fail Securely</emphasis>: In the case of failure, systems should be configured to fail into a closed secure state. For example, SSL certificate verification should fail closed by severing the network connection if the CNAME doesn't match the server's DNS name. Software often fails open in this situation, allowing the connection to proceed without a CNAME match, which is less secure and not recommended.</para>
|
||||
|
||||
@ -41,7 +41,7 @@
|
||||
</section>
|
||||
<section xml:id="ch062_audit-guidance-idp62672">
|
||||
<title>External Audit</title>
|
||||
<para>This is the formal audit process. Auditors will test security controls in scope for a specific certification, and demand evidentiary requirements to prove that these controls were also in place for the audit window (for example SOC 2 audits generally evaluate security controls over a 6-12 months period). Any control failures are logged, and will be documented in the external auditors final report. Dependant on the type of OpenStack deployment, these reports may be viewed by customers, so it is important to avoid control failures. This is why audit preparation is so important.</para>
|
||||
<para>This is the formal audit process. Auditors will test security controls in scope for a specific certification, and demand evidentiary requirements to prove that these controls were also in place for the audit window (for example SOC 2 audits generally evaluate security controls over a 6-12 months period). Any control failures are logged, and will be documented in the external auditors final report. Dependent on the type of OpenStack deployment, these reports may be viewed by customers, so it is important to avoid control failures. This is why audit preparation is so important.</para>
|
||||
</section>
|
||||
<section xml:id="ch062_audit-guidance-idp65008">
|
||||
<title>Compliance Maintenance</title>
|
||||
|
||||
@ -36,6 +36,6 @@
|
||||
</section>
|
||||
<section xml:id="ch063_compliance-activities-idp58256">
|
||||
<title>Exception Process</title>
|
||||
<para>An exception process is an important component of an ISMS. When certain actions are not compliant with security policies that an organization has defined, they must be logged. Appropriate justification, description and mitigation details need to be included, and signed off by appropriate authorities. OpenStack default configurations may vary in meeting various compliance criteria, areas that fail to meet compliance requirements should be logged, with potential fixes considered for contirbution to the community.</para>
|
||||
<para>An exception process is an important component of an ISMS. When certain actions are not compliant with security policies that an organization has defined, they must be logged. Appropriate justification, description and mitigation details need to be included, and signed off by appropriate authorities. OpenStack default configurations may vary in meeting various compliance criteria, areas that fail to meet compliance requirements should be logged, with potential fixes considered for contribution to the community.</para>
|
||||
</section>
|
||||
</chapter>
|
||||
|
||||
@ -52,7 +52,7 @@
|
||||
<para>For more details see https://www.cms.gov/Regulations-and-Guidance/HIPAA-Administrative-Simplification/HIPAAGenInfo/downloads/HIPAALaw.pdf.</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) dependant on volume of card-holder transactions. </para>
|
||||
<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>
|
||||
</section>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user