From 2dad59797db28c396a7e599390ba965cdfc62072 Mon Sep 17 00:00:00 2001 From: Andreas Jaeger Date: Wed, 7 May 2014 20:03:08 +0200 Subject: [PATCH] Security guide editorial edits No textual changes, just markup and style, mainly: * Add missing markup * Change capitalization * Wrap some overly long lines * Remove extra whitespace before ":" * Replace "--" with emdash Change-Id: I9126a91c5d1f78feacb10c639b26f37fc6815a99 Partial-Bug: #1217503 --- .../ch006_introduction-to-case-studies.xml | 2 +- .../ch012_configuration-management.xml | 26 ++-- .../ch013_node-bootstrapping.xml | 12 +- ...est-practices-for-operator-mode-access.xml | 6 +- doc/security-guide/ch024_authentication.xml | 10 +- doc/security-guide/ch025_web-dashboard.xml | 6 +- doc/security-guide/ch026_compute.xml | 17 ++- doc/security-guide/ch027_storage.xml | 22 +-- ...ch028_case-studies-identity-management.xml | 11 +- .../ch033_securing-neutron-services.xml | 11 +- ...enant-secure-networking-best-practices.xml | 34 ++++- .../ch043_database-transport-security.xml | 24 +-- doc/security-guide/ch046_data-residency.xml | 2 +- .../ch049_case-studies-tenant-data.xml | 86 ++++++++--- doc/security-guide/ch051_vss-intro.xml | 139 +++++++++--------- doc/security-guide/ch052_devices.xml | 22 ++- .../ch055_security-services-for-instances.xml | 49 +++--- .../ch061_compliance-overview.xml | 92 +++++++++--- doc/security-guide/ch062_audit-guidance.xml | 4 +- .../ch063_compliance-activities.xml | 2 +- 20 files changed, 371 insertions(+), 206 deletions(-) diff --git a/doc/security-guide/ch006_introduction-to-case-studies.xml b/doc/security-guide/ch006_introduction-to-case-studies.xml index ea0a3d4ce9..d3beca5e5b 100644 --- a/doc/security-guide/ch006_introduction-to-case-studies.xml +++ b/doc/security-guide/ch006_introduction-to-case-studies.xml @@ -18,7 +18,7 @@ resources must be exposed to only systems within the department's network, which is entirely air-gapped from all other networks. The cloud can access other network services on - the Organization's Intranet. For example, the authentication and + the organization's intranet such as the authentication and logging services.
diff --git a/doc/security-guide/ch012_configuration-management.xml b/doc/security-guide/ch012_configuration-management.xml index b6731f13ed..790a0a45fd 100644 --- a/doc/security-guide/ch012_configuration-management.xml +++ b/doc/security-guide/ch012_configuration-management.xml @@ -93,22 +93,22 @@ - Attacker Position / - Privilege Level + Attacker position / + Privilege level External Cloud - User + user Cloud - Admin + admin Control - Plane + plane - Privilege Elevation (3 + Privilege elevation (3 levels) Critical n/a @@ -116,7 +116,7 @@ n/a - Privilege Elevation (2 + Privilege elevation (2 levels) Critical Critical @@ -124,7 +124,7 @@ n/a - Privilege Elevation (1 + Privilege elevation (1 level) Critical Critical @@ -133,7 +133,7 @@ Denial of - Service + service High Medium Low @@ -141,10 +141,10 @@ Information - Disclosure - Critical / High - Critical / High - Medium / Low + disclosure + Critical / high + Critical / high + Medium / low Low diff --git a/doc/security-guide/ch013_node-bootstrapping.xml b/doc/security-guide/ch013_node-bootstrapping.xml index e960357420..43f1ffdf48 100644 --- a/doc/security-guide/ch013_node-bootstrapping.xml +++ b/doc/security-guide/ch013_node-bootstrapping.xml @@ -1,4 +1,8 @@ + +%openstack; +]>
Secure bootstrapping - Nodes in the cloud -- including compute, storage, network, - service, and hybrid nodes -- should have an automated + Nodes in the cloud—including compute, storage, network, + service, and hybrid nodes—should have an automated provisioning process. This ensures that nodes are provisioned consistently and correctly. This also facilitates security patching, upgrading, bug fixing, and other critical changes. @@ -125,8 +129,8 @@ Register - What Is - Measured + What is + measured Context diff --git a/doc/security-guide/ch014_best-practices-for-operator-mode-access.xml b/doc/security-guide/ch014_best-practices-for-operator-mode-access.xml index b8a98cd097..70f3b50ebe 100644 --- a/doc/security-guide/ch014_best-practices-for-operator-mode-access.xml +++ b/doc/security-guide/ch014_best-practices-for-operator-mode-access.xml @@ -21,9 +21,9 @@ Secure shell (SSH) - OpenStack management utilities (for example, - nova-manage, - glance-manage) + OpenStack management utilities such as + nova-manage and + glance-manage Out-of-band management interfaces, such as IPMI diff --git a/doc/security-guide/ch024_authentication.xml b/doc/security-guide/ch024_authentication.xml index 86e946c254..8eea29dfa1 100644 --- a/doc/security-guide/ch024_authentication.xml +++ b/doc/security-guide/ch024_authentication.xml @@ -122,7 +122,7 @@ These include: - Password Policy Enforcement: Requires user passwords + Password policy enforcement: Requires user passwords to conform to minimum standards for length, diversity of characters, expiration, or failed login attempts. @@ -234,8 +234,8 @@
Policies - Each OpenStack service has a policy file in json format, - called policy.json. The policy + Each OpenStack service has a policy file in JSON format, + called policy.json. The policy file specifies rules, and the rule that governs each resource. A resource could be API access, the ability to attach to a volume, or to fire up instances. @@ -244,8 +244,8 @@ could also be further customized. Note that your users must be assigned to groups/roles that you refer to in your policies. - Below is a snippet of the Block Storage service policy.json - file. + Below is a snippet of the Block Storage service + policy.json file. Note the default rule specifies that the user must be either an admin or the owner of diff --git a/doc/security-guide/ch025_web-dashboard.xml b/doc/security-guide/ch025_web-dashboard.xml index 0c75743b90..5df1717405 100644 --- a/doc/security-guide/ch025_web-dashboard.xml +++ b/doc/security-guide/ch025_web-dashboard.xml @@ -53,13 +53,15 @@
HTTP Strict Transport Security (HSTS) It is highly recommended to use HTTP Strict Transport - Security (HSTS). - NOTE: If you are using an HTTPS proxy in front of your web + Security (HSTS). + + 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. + See the chapter on PKI/SSL Everywhere for more specific recommendations and server configurations for HTTPS configurations, including the configuration of HSTS. diff --git a/doc/security-guide/ch026_compute.xml b/doc/security-guide/ch026_compute.xml index 90ba9de3fd..c465aec88d 100644 --- a/doc/security-guide/ch026_compute.xml +++ b/doc/security-guide/ch026_compute.xml @@ -30,7 +30,7 @@ network. - + The nova command-line utility can return a URL for the VNC console for access by the nova Java VNC @@ -39,14 +39,18 @@ bridge from the public network to the management network. - +
Security considerations - The nova-novncproxyand nova-xvpvncproxy services by default open public-facing ports that are token authenticated. + The nova-novncproxy and + nova-xvpvncproxy + services by default open public-facing ports that are + token authenticated. - + By default, the remote desktop traffic is not encrypted. Havana is expected to have VNC connections secured by Kerberos. @@ -85,7 +89,10 @@
Security considerations - The nova-spicehtml5proxy service by default opens public-facing ports that are token authenticated. + The nova-spicehtml5proxy + service by default opens public-facing ports that are + token authenticated. The functionality and integration are still evolving. We will access the features in the next release and make recommendations. diff --git a/doc/security-guide/ch027_storage.xml b/doc/security-guide/ch027_storage.xml index 2d6a87186d..d7cc83ad7a 100644 --- a/doc/security-guide/ch027_storage.xml +++ b/doc/security-guide/ch027_storage.xml @@ -127,9 +127,10 @@
File permissions - /etc/swift contains information about the ring - topology and environment configuration. The following - permissions are recommended: + The /etc/swift directory + contains information about the ring topology and + environment configuration. The following permissions are + recommended: # chown -R root:swift /etc/swift/* # find /etc/swift/ -type f -exec chmod 640 {} \; # find /etc/swift/ -type d -exec chmod 750 {} \; @@ -147,7 +148,7 @@ - Service Name + Service name Port Type @@ -282,7 +283,7 @@ Group swift Create the file $YOUR_APACHE_DOC_ROOT/swift/proxy-server.wsgi: from swift.common.wsgi import init_request_processor application, conf, logger, log_name = \ - init_request_processor('/etc/swift/proxy-server.conf','proxy-server') + init_request_processor('/etc/swift/proxy-server.conf','proxy-server')
HTTP listening port @@ -363,11 +364,12 @@ Group swift
Other notable items - In /etc/swift/swift.conf on every service node there is - a "swift_hash_path_suffix" setting. This is provided to - reduce the chance of hash collisions for objects being - stored and avert one user overwriting the data of another - user. + In /etc/swift/swift.conf on every + service node there is a + setting. This is + provided to reduce the chance of hash collisions for objects + being stored and avert one user overwriting the data of + another user. This value should be initially set with a cryptographically secure random number generator and consistent across all service nodes. Ensure that it is diff --git a/doc/security-guide/ch028_case-studies-identity-management.xml b/doc/security-guide/ch028_case-studies-identity-management.xml index 2923f73ae6..27177208ba 100644 --- a/doc/security-guide/ch028_case-studies-identity-management.xml +++ b/doc/security-guide/ch028_case-studies-identity-management.xml @@ -42,7 +42,14 @@
Bob's public cloud Bob must support authentication by the general public, so he elects to use provide for username / password authentication. He has concerns about brute force attacks attempting to crack user passwords, so he also uses an external authentication extension that throttles the number of failed login attempts. Bob's Management network is separate from the other networks within his cloud, but can be reached from his corporate network via ssh. As recommended earlier, Bob requires administrators to use two-factor authentication on the Management network to reduce the risk from compromised administrator passwords. - Bob also deploys the Dashboard to manage many aspects of the cloud. He deploys the Dashboard with HSTS to ensure that only HTTPS is used. He has ensured that the Dashboard is deployed on a second-level domain due to the limitations of the same-origin policy. He also disables HORIZON_IMAGES_ALLOW_UPLOAD to prevent resource exhaustion. - Bob decides to use VNC for his virtual console for its maturity and security features. + Bob also deploys the dashboard to manage many aspects of + the cloud. He deploys the dashboard with HSTS to ensure that + only HTTPS is used. He has ensured that the dashboard is + deployed on a second-level domain due to the limitations of the + same-origin policy. He also disables + to prevent resource + exhaustion. + Bob decides to use VNC for his virtual console for its + maturity and security features.
diff --git a/doc/security-guide/ch033_securing-neutron-services.xml b/doc/security-guide/ch033_securing-neutron-services.xml index 395fb1fdc8..1860d33d41 100644 --- a/doc/security-guide/ch033_securing-neutron-services.xml +++ b/doc/security-guide/ch033_securing-neutron-services.xml @@ -9,20 +9,21 @@ In order to secure OpenStack Networking, an understanding of the workflow process for tenant instance creation needs to be mapped to security domains. There are four main services that interact with OpenStack Networking. In a typical OpenStack deployment these services map to the following security domains: - OpenStack Dashboard: Public and Management + OpenStack dashboard: Public and management OpenStack Identity: Management - OpenStack Compute Node: Management and Guest + OpenStack compute node: Management and guest - OpenStack Network Node: Management, Guest, and possibly Public depending upon neutron-plugin in use. + OpenStack network node: Management, guest, and possibly + public depending upon neutron-plugin in use. - SDN Services Node: Management, Guest and possibly - Public depending upon product used. + SDN services node: Management, guest and possibly + public depending upon product used. diff --git a/doc/security-guide/ch034_tenant-secure-networking-best-practices.xml b/doc/security-guide/ch034_tenant-secure-networking-best-practices.xml index dab3db4ea1..c4c3a12276 100644 --- a/doc/security-guide/ch034_tenant-secure-networking-best-practices.xml +++ b/doc/security-guide/ch034_tenant-secure-networking-best-practices.xml @@ -1,4 +1,8 @@ + +%openstack; +]> This section discusses OpenStack Networking configuration best practices as they apply to tenant network security within your OpenStack deployment.
Tenant network services workflow - OpenStack Networking provides users real self services of network resources and configurations. It is important that Cloud Architects and Operators evaluate their design use cases in providing users the ability to create, update, and destroy available network resources. + OpenStack Networking provides users real self services of network resources and configurations. It is important that cloud architects and operators evaluate their design use cases in providing users the ability to create, update, and destroy available network resources.
Networking resource policy engine @@ -27,19 +31,35 @@ xlink:href="http://docs.openstack.org/admin-guide-cloud/content/section_networking_auth.html">Authentication and authorization section in the OpenStack Cloud Administrator Guide. -
It is important to review the default networking resource policy and modify the policy appropriately for your security posture.
- 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 unforeseen 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. + It is important to review the default networking + resource policy and modify the policy appropriately for your + security posture. + 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 unforeseen 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.
Security groups The OpenStack Networking Service provides security group functionality using a mechanism that is more flexible and powerful than the security group capabilities built into OpenStack Compute. Thus, when using OpenStack Networking, nova.conf should always disable built-in security groups and proxy all security group calls to the OpenStack Networking API. Failure to do so will result in conflicting security policies being simultaneously applied by both services. To proxy security groups to OpenStack Networking, use the following configuration values: - firewall_driver : must be set to 'nova.virt.firewall.NoopFirewallDriver' so that nova-compute does not perform iptables-based filtering itself. + must be set to + nova.virt.firewall.NoopFirewallDriver so + that nova-compute + does not perform iptables-based filtering itself. - - security_group_api : must be set to 'neutron' so that all security group requests are proxied to the OpenStack Network Service. + + must be set to + neutron so that all security group + requests are proxied to the OpenStack Networking + service. - + Security groups and security group rules allow administrators and tenants the ability to specify the type of traffic and direction (ingress/egress) that is allowed to pass through a virtual interface port. A security group is a container for security group rules. When a virtual interface port is created in OpenStack Networking it is associated with a security group. If a security group is not specified, the port will be associated with a 'default' security group. By default this group will drop all ingress traffic and allow all egress. Rules can be added to this group in order to change the behaviour. When using the security group API through OpenStack Compute, security groups are applied to all virtual interface ports on an instance. The reason for this is that OpenStack Compute security group APIs are instance based and not virtual interface port based as OpenStack Networking.
diff --git a/doc/security-guide/ch043_database-transport-security.xml b/doc/security-guide/ch043_database-transport-security.xml index dfec9706d4..331333cc58 100644 --- a/doc/security-guide/ch043_database-transport-security.xml +++ b/doc/security-guide/ch043_database-transport-security.xml @@ -49,19 +49,25 @@ ssl-key=/path/to/ssl/server-key.pem ssl = true 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: ssl-ciphers = 'cipher:list' - The server certificate, key, and certificate authority (CA) files should be placed in the $PGDATA directory in the following files: + The server certificate, key, and certificate authority + (CA) files should be placed in the $PGDATA directory in the + following files: - $PGDATA/server.crt - Server certificate + $PGDATA/server.crt - Server + certificate - - $PGDATA/server.key - Private key corresponding to server.crt + + $PGDATA/server.key - Private key + corresponding to server.crt - - $PGDATA/root.crt - Trusted certificate authorities + + $PGDATA/root.crt - Trusted + certificate authorities - - $PGDATA/root.crl - Certificate revocation list + + $PGDATA/root.crl - Certificate + revocation list - +
diff --git a/doc/security-guide/ch046_data-residency.xml b/doc/security-guide/ch046_data-residency.xml index e9979ab889..73fe2084db 100644 --- a/doc/security-guide/ch046_data-residency.xml +++ b/doc/security-guide/ch046_data-residency.xml @@ -79,7 +79,7 @@
"Sanitization is the process used to remove information from system media such that there is reasonable assurance that the information cannot be retrieved or reconstructed. Sanitization techniques, including clearing, purging, and destroying media information, prevent the disclosure of organizational information to unauthorized individuals when such media is reused or released for disposal." [NIST Special Publication 800-53 Revision 3]
- General data disposal and sanitization guidelines as adopted from NIST recommended security controls. Cloud Operators should: + General data disposal and sanitization guidelines as adopted from NIST recommended security controls. Cloud operators should: Track, document and verify media sanitization and disposal actions. diff --git a/doc/security-guide/ch049_case-studies-tenant-data.xml b/doc/security-guide/ch049_case-studies-tenant-data.xml index c6b0a68528..d04cc74c1d 100644 --- a/doc/security-guide/ch049_case-studies-tenant-data.xml +++ b/doc/security-guide/ch049_case-studies-tenant-data.xml @@ -6,33 +6,77 @@ xml:id="ch049_case-studies-tenant-data"> Case studies: tenant data - 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. + + 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. +
Alice's private cloud - 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: + + 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: + - Establishing procedures to sanitize tenant data when a program or project ends - Track the destruction of both the tenant data and metadata via ticketing in a CMDB - For Volume storage: - Physical Server Issues - To provide secure ephemeral instance storage, Alice implements qcow2 files on an encrypted filesystem. - + + Establishing procedures to sanitize tenant data when + a program or project ends. + + + Track the destruction of both the tenant data and + metadata via ticketing in a CMDB. + + For Volume storage: + + + Physical server issues + + + To provide secure ephemeral instance storage, + Alice implements qcow2 files on an encrypted + filesystem. + + + +
Bob's public cloud - As stated during the introduction to Bob's case study, tenant privacy is of an extremely high priority. In addition to the requirements and actions Bob will take to isolate tenants from one another at the infrastructure layer, Bob also needs to provide assurances for tenant data privacy. Bob does this using the following: + + As stated during the introduction to Bob's case study, tenant + privacy is of an extremely high priority. In addition to the + requirements and actions Bob will take to isolate tenants from + one another at the infrastructure layer, Bob also needs to + provide assurances for tenant data privacy. Bob does this + using the following: + - Establishing procedures to sanitize customer data when a customer churns - Track the destruction of both the customer data and metadata via ticketing in a CMDB - For Volume storage: - Physical Server Issues - To provide secure ephemeral instance storage, Bob implements qcow2 files on an encrypted filesystems. + + Establishing procedures to sanitize customer data + when a customer churns. + + + Track the destruction of both the customer data and + metadata via ticketing in a CMDB. + + + For Volume storage: + + + Physical server issues + + + To provide secure ephemeral instance storage, Bob + implements qcow2 files on an encrypted filesystems. + + +
- + diff --git a/doc/security-guide/ch051_vss-intro.xml b/doc/security-guide/ch051_vss-intro.xml index dca92edfb2..52a4a313e0 100644 --- a/doc/security-guide/ch051_vss-intro.xml +++ b/doc/security-guide/ch051_vss-intro.xml @@ -47,27 +47,27 @@ Selection criteria As part of your hypervisor selection process, you will need to consider a number of important factors to help increase your security posture. Specifically, we will be looking into the following areas: - Team Expertise + Team expertise - - Product or Project maturity + + Product or project maturity - - Certifications, Attestations + + Certifications, attestations - - Additional Security Features + + Additional security features - - Hypervisor vs. Baremetal + + Hypervisor vs. baremetal - - Hardware Concerns + + Hardware concerns - + Common Criteria - + Additionally, the following security-related criteria are highly encouraged to be evaluated when selecting a hypervisor for OpenStack deployments: Has the hypervisor undergone Common Criteria certification? If so, to what levels? @@ -123,7 +123,7 @@ - Identification and Authentication + Identification and authentication Identification and authentication using pluggable authentication modules (PAM) based upon user passwords. The quality of the passwords used can be enforced through configuration options. @@ -158,23 +158,23 @@ Role-based access control (RBAC) allows separation of roles to eliminate the need for an all-powerful system administrator. - Object Reuse + Object reuse File system objects as well as memory and IPC objects will be cleared before they can be reused by a process belonging to a different user. - Security Management + Security management The management of the security critical parameters of the system is performed by administrative users. A set of commands that require root privileges (or specific roles when RBAC is used) are used for system management. Security parameters are stored in specific files that are protected by the access control mechanisms of the system against unauthorized access by users that are not administrative users. - Secure Communication + Secure communication The system supports the definition of trusted channels using SSH. Password based authentication is supported. Only a restricted number of cipher suites are supported for those protocols in the evaluated configuration. - Storage Encryption + Storage encryption The system supports encrypted block devices to provide storage confidentiality via dm_crypt. - TSF Protection + TSF protection While in operation, the kernel software and data are protected by the hardware memory protection mechanisms. The memory and process management components of the kernel ensure a user process cannot access kernel storage or storage belonging to other processes.Non-kernel TSF software and data are protected by DAC and process isolation mechanisms. In the evaluated configuration, the reserved user ID root owns the @@ -193,74 +193,71 @@ Several cryptography algorithms are available within OpenStack for identification and authorization, data transfer and protection of data at rest. When selecting a hypervisor, the following are recommended algorithms and implementation standards to ensure the virtualization layer supports: - - - - - + + + Algorithm + Key length + Intended purpose + Security function + Implementation standard + + - Algorithm - Key Length - Intended Purpose - Security Function - Implementation Standard + AES + 128, 192, or 256 bits + Encryption / decryption + Protected data transfer, protection for data at rest + RFC 4253 - AES - 128, 192, or 256 bits - Encryption / Decryption - Protected Data Transfer, Protection for Data at Rest - RFC 4253 + TDES + 168 bits + Encryption / decryption + Protected data transfer + RFC 4253 - TDES - 168 bits - Encryption / Decryption - Protected Data Transfer - RFC 4253 + RSA + 1024, 2048, or 3072 bits + Authentication, key exchange + Identification and authentication, protected data transfer + U.S. NIST FIPS PUB 186-3 - RSA - 1024, 2048, or 3072 bits - Authentication, Key Exchange - Identification and Authentication, Protected Data Transfer - U.S. NIST FIPS PUB 186-3 + DSA + L=1024, N=160 bits + Authentication, key exchange + Identification and authentication, protected data transfer + U.S. NIST FIPS PUB 186-3 - DSA - L=1024, N=160 bits - Authentication, Key Exchange - Identification and Authentication, Protected Data Transfer - U.S. NIST FIPS PUB 186-3 + Serpent + 128, 192, or 256 bits + Encryption / decryption + Protection of data at rest + http://www.cl.cam.ac.uk/~rja14/Papers/serpent.pdf - Serpent - 128, 192, or 256 bits - Encryption / Decryption - Protection of Data at Rest - http://www.cl.cam.ac.uk/~rja14/Papers/serpent.pdf + Twofish + 128, 192, or 256 bits + Encryption / decryption + Protection of data at rest + http://www.schneier.com/paper-twofish-paper.html - Twofish - 128, 192, or 256 bit - Encryption / Decryption - Protection of Data at Rest - http://www.schneier.com/paper-twofish-paper.html + SHA-1 + - + Message Digest + Protection of data at rest, protected data transfer + U.S. NIST FIPS 180-3 - SHA-1 - - - Message Digest - Protection of Data at Rest, Protected Data Transfer - U.S. NIST FIPS 180-3 - - - SHA-2 (224, 256, 384, or 512 bits) - - - Message Digest - Protection for Data at Rest, Identification and Authentication - U.S. NIST FIPS 180-3 + SHA-2 (224, 256, 384, or 512 bits) + - + Message digest + Protection for data at rest, identification and authentication + U.S. NIST FIPS 180-3 diff --git a/doc/security-guide/ch052_devices.xml b/doc/security-guide/ch052_devices.xml index b83334032a..e70707867c 100644 --- a/doc/security-guide/ch052_devices.xml +++ b/doc/security-guide/ch052_devices.xml @@ -1,4 +1,8 @@ + +%openstack; +]> Position Independent Executable (PIE): Produces a position independent executable, which is necessary for ASLR. - Address Space Layout Randomization (ASLR) : 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. + Address Space Layout Randomization + (ASLR): 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. Putting this all together, and adding in some additional useful protections, we recommend the following compiler options for gcc when compiling QEMU: @@ -151,8 +159,16 @@ - - As shown above, sVirt isolation is provided regardless of the guest Operating System running inside the virtual machine -- Linux or Windows VMs can be used. Additionally, many Linux distributions provide SELinux within the operating system, allowing the virtual machine to protect internal virtual resources from threats. + + + + As shown above, sVirt isolation is provided regardless of the + guest Operating System running inside the virtual + machine—Linux or Windows VMs can be used. Additionally, + many Linux distributions provide SELinux within the operating + system, allowing the virtual machine to protect internal + virtual resources from threats. +
Labels and categories KVM-based virtual machine instances are labelled with their own SELinux data type, known as svirt_image_t. Kernel level protections prevent unauthorized system processes, such as malware, from manipulating the virtual machine image files on disk. When virtual machines are powered off, images are stored as svirt_image_t as shown below: diff --git a/doc/security-guide/ch055_security-services-for-instances.xml b/doc/security-guide/ch055_security-services-for-instances.xml index 78ebdc6db6..40300a58c7 100644 --- a/doc/security-guide/ch055_security-services-for-instances.xml +++ b/doc/security-guide/ch055_security-services-for-instances.xml @@ -10,16 +10,16 @@ Deployers or users of OpenStack with strong security requirements may want to consider deploying these technologies. Not all are applicable in every situation, indeed in some cases technologies may be ruled out for use in a cloud because of prescriptive business requirements. Similarly some technologies inspect instance data such as run state which may be undesirable to the users of the system. In this chapter we explore these technologies and describe the situations where they can be used to enhance security for instances or underlying instances. We also seek to highlight where privacy concerns may exist. These include data pass through, introspection, or providing a source of entropy. In this section we highlight the following additional security services: - Entropy to Instances + Entropy to instances - - Scheduling Instances to Nodes + + Scheduling instances to nodes - - Trusted Images + + Trusted images - - Instance Migrations + + Instance migrations
@@ -64,7 +64,7 @@ partition up their compute host resources. Each node can have multiple aggregates (see the Host - Aggregates section of the OpenStack + aggregates section of the OpenStack Configuration Reference for more information on creating and managing aggregates).
@@ -179,35 +179,38 @@ Live migration risks At various stages of the live migration process the contents of an instances run time memory and disk are transmitted over the network in plain text. Thus there are several risks that need to be addressed when using live migration. The following in-exhaustive list details some of these risks: - Denial of Service (DoS) : If something fails during the migration process, the instance could be lost. + Denial of Service (DoS): If something fails during the migration process, the instance could be lost. - - Data Exposure : Memory or disk transfers must be handled securely. + + Data exposure: Memory or disk transfers must be handled securely. - - Data Manipulation : If memory or disk transfers are not handled securely, then an attacker could manipulate user data during the migration. + + Data manipulation: If memory or disk transfers are not handled securely, then an attacker could manipulate user data during the migration. - - Code Injection : If memory or disk transfers are not handled securely, then an attacker could manipulate executables, either on disk or in memory, during the migration. + + Code injection: If memory or disk transfers are not handled securely, then an attacker could manipulate executables, either on disk or in memory, during the migration. - +
Live migration mitigations There are several methods to mitigate some of the risk associated with live migrations, the following list details some of these: - Disable Live Migration + Disable live migration - - Isolated Migration Network + + Isolated migration network - - Encrypted Live Migration + + Encrypted live migration - +
Disable live migration - At this time, live migration is enabled in OpenStack by default. Live migrations can be disabled by adding the following lines to the nova policy.json file: + At this time, live migration is enabled in OpenStack + by default. Live migrations can be disabled by adding the + following lines to the nova policy.json + file: "compute_extension:admin_actions:migrate": "!", "compute_extension:admin_actions:migrateLive": "!",
diff --git a/doc/security-guide/ch061_compliance-overview.xml b/doc/security-guide/ch061_compliance-overview.xml index ed744f24ad..23e14c2bf0 100644 --- a/doc/security-guide/ch061_compliance-overview.xml +++ b/doc/security-guide/ch061_compliance-overview.xml @@ -22,25 +22,81 @@
Security principles - 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. - - Layered Defenses: 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. + 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. + + Layered defenses + + + 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. + + + Fail securely + + + 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. + + + Least privilege + + + Only the minimum level of access for users and system + services is granted. This access is based upon role, + responsibility and job function. This security principal + of least privilege is written into several international + government security policies, such as NIST 800-53 + Section AC-6 within the United States. + + + Compartmentalize + + + Systems should be segregated in a such way that if one + machine, or system-level service, is compromised the + security of the other systems will remain + intact. Practically, the enablement and proper usage of + SELinux helps accomplish this goal. - - Fail Securely: 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. + + + Promote privacy + + + The amount of information that can be gathered about a + system and its users should be minimized. + + + + Logging capability + + + Appropriate logging is implemented to monitor for + unauthorized use, incident response and forensics. It is + highly recommended that selected audit subsystems be + Common Criteria certified, which provides non-attestable + event records in most countries. - - Least Privilege: Only the minimum level of access for users and system services is granted. This access is based upon role, responsibility and job function. This security principal of least privilege is written into several international government security policies, such as NIST 800-53 Section AC-6 within the United States. - - - Compartmentalize: Systems should be segregated in a such way that if one machine, or system-level service, is compromised the security of the other systems will remain intact. Practically, the enablement and proper usage of SELinux helps accomplish this goal. - - - Promote Privacy: The amount of information that can be gathered about a system and its users should be minimized. - - - Logging Capability: Appropriate logging is implemented to monitor for unauthorized use, incident response and forensics. It is highly recommended that selected audit subsystems be Common Criteria certified, which provides non-attestable event records in most countries. - - + +
diff --git a/doc/security-guide/ch062_audit-guidance.xml b/doc/security-guide/ch062_audit-guidance.xml index 957f78dc94..8b50e69ddb 100644 --- a/doc/security-guide/ch062_audit-guidance.xml +++ b/doc/security-guide/ch062_audit-guidance.xml @@ -11,8 +11,8 @@ - Implementation and Operation of - Security Controls. Aligning the information + Implementation and operation of + security controls. Aligning the information system with in-scope standards and regulations involves internal tasks which must be conducted before a formal assessment. Auditors may be involved at this state to diff --git a/doc/security-guide/ch063_compliance-activities.xml b/doc/security-guide/ch063_compliance-activities.xml index b120754ec9..bcdde46912 100644 --- a/doc/security-guide/ch063_compliance-activities.xml +++ b/doc/security-guide/ch063_compliance-activities.xml @@ -13,7 +13,7 @@
Risk assessment - A Risk Assessment framework identifies risks within an organization or service, and specifies ownership of these risks, along with implementation and mitigation strategies. Risks apply to all areas of the service, from technical controls to environmental disaster scenarios and human elements, for example a malicious insider (or rogue employee). Risks can be rated using a variety of mechanisms, for example likelihood vs impact. An OpenStack deployment risk assessment can include control gaps that are described in this book. + A risk assessment framework identifies risks within an organization or service, and specifies ownership of these risks, along with implementation and mitigation strategies. Risks apply to all areas of the service, from technical controls to environmental disaster scenarios and human elements, for example a malicious insider (or rogue employee). Risks can be rated using a variety of mechanisms, for example likelihood vs impact. An OpenStack deployment risk assessment can include control gaps that are described in this book.
Access and log reviews