diff --git a/doc/admin-guide-cloud/networking/section_networking_adv_features.xml b/doc/admin-guide-cloud/networking/section_networking_adv_features.xml index 9786cbd212..c952016d3b 100644 --- a/doc/admin-guide-cloud/networking/section_networking_adv_features.xml +++ b/doc/admin-guide-cloud/networking/section_networking_adv_features.xml @@ -14,8 +14,8 @@ credentials, specifying the details of how the network is physically realized, usually to match some existing network in the data center. Provider networks enable cloud administrators to create Networking networks that map - directly to the physical networks in the data center. This is commonly used to give - tenants direct access to a public network that can be used to reach the Internet. It + directly to the physical networks in the data center. This is commonly used to give + tenants direct access to a public network that can be used to reach the Internet. It might also be used to integrate with VLANs in the network that already have a defined meaning (for example, enable a VM from the "marketing" department to be placed on the same VLAN as bare-metal marketing hosts in the same data center). @@ -437,7 +437,7 @@ Networking network associated with the subnet. The router also gets a gateway interface to the specified external network. This provides SNAT connectivity to the external network as well as support for - floating IPs allocated on that external networks. Commonly an + floating IPs allocated on that external networks. Commonly an external network maps to a network in the provider diff --git a/doc/common/section_cli_nova_host_aggregates.xml b/doc/common/section_cli_nova_host_aggregates.xml index c6302a7279..77ef335117 100644 --- a/doc/common/section_cli_nova_host_aggregates.xml +++ b/doc/common/section_cli_nova_host_aggregates.xml @@ -9,7 +9,7 @@ xml:id="host-aggregates"> Host aggregates Host aggregates are a mechanism to further partition an - availability zone; while availability zones are visible to + availability zone; while availability zones are visible to users, host aggregates are only visible to administrators. Host Aggregates provide a mechanism to allow administrators to assign key-value pairs to groups of machines. Each node can diff --git a/doc/config-reference/block-storage/drivers/coraid-driver.xml b/doc/config-reference/block-storage/drivers/coraid-driver.xml index bc162f1e06..a31bb71dd2 100644 --- a/doc/config-reference/block-storage/drivers/coraid-driver.xml +++ b/doc/config-reference/block-storage/drivers/coraid-driver.xml @@ -123,7 +123,7 @@ Download the latest Coraid AoE driver. - $ wget http://support.coraid.com/support/linux/aoeXXX.tar.gz + $ wget http://support.coraid.com/support/linux/aoeXXX.tar.gz diff --git a/doc/config-reference/object-storage/section_object-storage-features.xml b/doc/config-reference/object-storage/section_object-storage-features.xml index cb76cf1000..a7483b3d29 100644 --- a/doc/config-reference/object-storage/section_object-storage-features.xml +++ b/doc/config-reference/object-storage/section_object-storage-features.xml @@ -76,7 +76,7 @@ OpenStack Object Storage works best on the XFS file system, and this document assumes that the hardware being used is configured appropriately to be mounted with the - nobarriers option.   For more + nobarriers option. For more information, refer to the XFS FAQ: http://xfs.org/index.php/XFS_FAQ diff --git a/doc/image-guide/ch_creating_images_automatically.xml b/doc/image-guide/ch_creating_images_automatically.xml index 093eba41f1..b665a8c22b 100644 --- a/doc/image-guide/ch_creating_images_automatically.xml +++ b/doc/image-guide/ch_creating_images_automatically.xml @@ -134,7 +134,7 @@ echo -n > /lib/udev/rules.d/75-persistent-net-generator.rules BoxGrinder BoxGrinder  is another tool for creating + >BoxGrinder is another tool for creating virtual machine images, which it calls appliances. BoxGrinder can create Fedora, Red Hat Enterprise Linux, or CentOS images. BoxGrinder is currently only supported on diff --git a/doc/image-guide/ch_creating_images_manually.xml b/doc/image-guide/ch_creating_images_manually.xml index f20c2c0924..1224aeeec8 100644 --- a/doc/image-guide/ch_creating_images_manually.xml +++ b/doc/image-guide/ch_creating_images_manually.xml @@ -61,7 +61,7 @@ default active yes interact with the guest's graphical console. If you are building the image on a headless server, and you have an X server on your local machine, you can launch - virt-manager  using ssh X11 + virt-manager using ssh X11 forwarding to access the GUI. Since virt-manager interacts directly with libvirt, you typically need to be root to access it. If you can ssh directly in as root (or with a diff --git a/doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml b/doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml index aa16b590f9..87e151e138 100644 --- a/doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml +++ b/doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml @@ -1,7 +1,7 @@ Why and how we wrote this book - As OpenStack adoption continues to grow and the product matures, security has become a priority. The OpenStack Security Group has recognized the need for a comprehensive and authoritative security guide. The OpenStack Security Guide 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. + As OpenStack adoption continues to grow and the product matures, security has become a priority. The OpenStack Security Group has recognized the need for a comprehensive and authoritative security guide. The OpenStack Security Guide 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. The guide augments the OpenStack Operations Guide and can be referenced to harden existing OpenStack deployments or to evaluate the security controls of OpenStack cloud providers.
Objectives @@ -25,7 +25,7 @@
How As with the OpenStack Operations Guide, we followed the book sprint methodology. The book sprint process allows for rapid development and production of large bodies of written work. Coordinators from the OpenStack Security Group re-enlisted the services of Adam Hyde as facilitator. Corporate support was obtained and the project was formally announced during the OpenStack summit in Portland, Oregon. - The team converged in Annapolis, MD due to the close proximity of some key members of the group. This was a remarkable collaboration between public sector intelligence community members, silicon valley startups and some large, well-known technology companies. The book sprint ran during the last week in June 2013 and the first edition was created in five days. + The team converged in Annapolis, MD due to the close proximity of some key members of the group. This was a remarkable collaboration between public sector intelligence community members, silicon valley startups and some large, well-known technology companies. The book sprint ran during the last week in June 2013 and the first edition was created in five days. diff --git a/doc/security-guide/ch004_book-introduction.xml b/doc/security-guide/ch004_book-introduction.xml index d64394bd4f..d7de435ae6 100644 --- a/doc/security-guide/ch004_book-introduction.xml +++ b/doc/security-guide/ch004_book-introduction.xml @@ -7,8 +7,8 @@ Introduction to OpenStack This guide provides security insight into OpenStack - deployments. The intended audience is cloud architects, deployers, - and administrators. In addition, cloud users will find the guide + deployments. The intended audience is cloud architects, deployers, + and administrators. In addition, cloud users will find the guide both educational and helpful in provider selection, while auditors will find it useful as a reference document to support their compliance certification efforts. This guide is also recommended @@ -60,7 +60,7 @@
Private cloud At the opposite end of the spectrum is the private cloud. - As NIST defines it, a private cloud is provisioned for + As NIST defines it, a private cloud is provisioned for exclusive use by a single organization comprising multiple consumers, such as business units. It may be owned, managed, and operated by the organization, a third-party, or some @@ -71,7 +71,7 @@
Community cloud NIST defines a community cloud as one whose -  infrastructure is provisioned for the exclusive use by a + infrastructure is provisioned for the exclusive use by a specific community of consumers from organizations that have shared concerns. For example, mission, security requirements, policy, and compliance considerations. It may be owned, @@ -218,7 +218,7 @@ between several of its services. By default, OpenStack uses message queues based on the Advanced Message Queue Protocol (AMQP - ). Similar to most OpenStack services, it supports + ). Similar to most OpenStack services, it supports pluggable components. Today the implementation backend could be RabbitMQ, Qpid, or diff --git a/doc/security-guide/ch005_security-domains.xml b/doc/security-guide/ch005_security-domains.xml index ef3d4a670a..af093c0886 100644 --- a/doc/security-guide/ch005_security-domains.xml +++ b/doc/security-guide/ch005_security-domains.xml @@ -1,7 +1,7 @@ Security Boundaries and Threats - A cloud can be abstracted as a collection of logical components by virtue of their function, users, and shared security concerns, which we call security domains. Threat actors and vectors are classified based on their motivation and access to resources. Our goal is to provide you a sense of the security concerns with respect to each domain depending on your risk/vulnerability protection objectives. + A cloud can be abstracted as a collection of logical components by virtue of their function, users, and shared security concerns, which we call security domains. Threat actors and vectors are classified based on their motivation and access to resources. Our goal is to provide you a sense of the security concerns with respect to each domain depending on your risk/vulnerability protection objectives.
Security Domains A security domain comprises users, applications, servers or networks that share common trust requirements and expectations within a system. Typically they have the same authentication and authorization (AuthN/Z) requirements and users. @@ -35,7 +35,7 @@
Guest Typically used for compute instance-to-instance traffic, the guest security domain handles compute data generated by instances on the cloud but not services that support the operation of the cloud, such as API calls. - Public cloud providers and private cloud providers who do not have stringent controls on instance use or who allow unrestricted internet access to VMs should consider this domain to be untrusted. Private cloud providers may want to consider this network as internal and therefore trusted only if they have controls in place to assert that they trust instances and all their tenants. + Public cloud providers and private cloud providers who do not have stringent controls on instance use or who allow unrestricted internet access to VMs should consider this domain to be untrusted. Private cloud providers may want to consider this network as internal and therefore trusted only if they have controls in place to assert that they trust instances and all their tenants.
Management @@ -101,13 +101,13 @@
Public / Private Considerations - Private clouds are typically deployed by enterprises or institutions inside their networks and behind their firewalls. Enterprises will have strict policies on what data is allowed to exit their network and may even have different clouds for specific purposes. Users of a private cloud are typically employees of the organization that owns the cloud and are able to be held accountable for their actions. Employees often attend training sessions before accessing the cloud and will likely take part in regular scheduled security awareness training. Public clouds by contrast cannot make any assertions about their users, cloud use-cases or user motivations. This immediately pushes the guest security domain into a completely untrusted state for public cloud providers. + Private clouds are typically deployed by enterprises or institutions inside their networks and behind their firewalls. Enterprises will have strict policies on what data is allowed to exit their network and may even have different clouds for specific purposes. Users of a private cloud are typically employees of the organization that owns the cloud and are able to be held accountable for their actions. Employees often attend training sessions before accessing the cloud and will likely take part in regular scheduled security awareness training. Public clouds by contrast cannot make any assertions about their users, cloud use-cases or user motivations. This immediately pushes the guest security domain into a completely untrusted state for public cloud providers. A notable difference in the attack surface of public clouds is that they must provide internet access to their services. Instance connectivity, access to files over the internet and the ability to interact with the cloud controlling fabric such as the API endpoints and dashboard are must-haves for the public cloud. Privacy concerns for public and private cloud users are typically diametrically opposed. The data generated and stored in private clouds is normally owned by the operator of the cloud, who is able to deploy technologies such as data loss prevention (DLP) protection, file inspection, deep packet inspection and prescriptive firewalling. In contrast, privacy is one of the primary barriers to adoption for the public cloud, as many of these controls do not exist.
Outbound attacks and reputational risk - Careful consideration should be given to potential outbound abuse from a cloud deployment.  Whether public or private, clouds tend to have lots of resource available. An attacker who has established a point of presence within the cloud, either through hacking in or via entitled access (rogue employee), can bring these resources to bear against the internet at large. Clouds with Compute services make for ideal DDoS and brute force engines. This is perhaps a more pressing issue for public clouds as their users are largely unaccountable, and can quickly spin up numerous disposable instances for outbound attacks.  Major damage can be inflicted upon a company's reputation if it becomes known for hosting malicious software or launching attacks on other networks. Methods of prevention include egress security groups, outbound traffic inspection, customer education and awareness, and fraud and abuse mitigation strategies. + Careful consideration should be given to potential outbound abuse from a cloud deployment. Whether public or private, clouds tend to have lots of resource available. An attacker who has established a point of presence within the cloud, either through hacking in or via entitled access (rogue employee), can bring these resources to bear against the internet at large. Clouds with Compute services make for ideal DDoS and brute force engines. This is perhaps a more pressing issue for public clouds as their users are largely unaccountable, and can quickly spin up numerous disposable instances for outbound attacks. Major damage can be inflicted upon a company's reputation if it becomes known for hosting malicious software or launching attacks on other networks. Methods of prevention include egress security groups, outbound traffic inspection, customer education and awareness, and fraud and abuse mitigation strategies.
Attack Types diff --git a/doc/security-guide/ch008_system-roles-types.xml b/doc/security-guide/ch008_system-roles-types.xml index 42effff293..219380b467 100644 --- a/doc/security-guide/ch008_system-roles-types.xml +++ b/doc/security-guide/ch008_system-roles-types.xml @@ -79,7 +79,7 @@ between the security domains. Network ingress and egress points should be identified along with any OpenStack logical system boundaries. Multiple diagrams may be needed to provide complete - visual coverage of the system.  A network topology document + visual coverage of the system. A network topology document should include virtual networks created on behalf of tenants by the system along with virtual machine instances and gateways created by OpenStack. diff --git a/doc/security-guide/ch009_case-studies.xml b/doc/security-guide/ch009_case-studies.xml index b82386394b..bfb8d6d422 100644 --- a/doc/security-guide/ch009_case-studies.xml +++ b/doc/security-guide/ch009_case-studies.xml @@ -4,7 +4,7 @@ In this case study we discuss how Alice and Bob would address their system documentation requirements. The documentation suggested above includes hardware and software records, network diagrams, and system configuration details.
Alice's Private Cloud - 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. + 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. 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. The tools collect and store the information in the CMDB, which simplifies the audit process.
diff --git a/doc/security-guide/ch012_configuration-management.xml b/doc/security-guide/ch012_configuration-management.xml index 9b8a882c0b..dc875013ca 100644 --- a/doc/security-guide/ch012_configuration-management.xml +++ b/doc/security-guide/ch012_configuration-management.xml @@ -92,12 +92,12 @@ -   + Attacker Position / Privilege Level -   + External Cloud @@ -237,7 +237,7 @@ Whenever a policy or configuration management is changed, it is good practice to log the activity, and backup a copy of the new set. Often, such policies and configurations are - stored in a version controlled repository such as git. + stored in a version controlled repository such as git.
@@ -288,7 +288,7 @@ OpenStack Security Primer + >OpenStack Security Primer
@@ -296,7 +296,7 @@
Security Auditing Tools Security auditing tools can complement the configuration - management tools.  Security auditing tools automate the process + 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 @@ -315,7 +315,7 @@ help to maintain a cloud that satisfies security requirements ranging from basic hardening to compliance validation. Configuration management and security auditing tools will - introduce another layer of complexity into the cloud.  This + introduce another layer of complexity into the cloud. This complexity brings additional security concerns with it. We view this as an acceptable risk trade-off, given their security benefits. Securing the operational use of these tools is beyond diff --git a/doc/security-guide/ch013_node-bootstrapping.xml b/doc/security-guide/ch013_node-bootstrapping.xml index 6b03ec7e38..f2d9a677a0 100644 --- a/doc/security-guide/ch013_node-bootstrapping.xml +++ b/doc/security-guide/ch013_node-bootstrapping.xml @@ -84,7 +84,7 @@ as 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 + server certificate. This raises the bar for an attacker by limiting the number of insecure, plain text network operations.
@@ -100,7 +100,7 @@ In both cases, the first step is to measure each piece of code before it is run. In this context, a measurement is effectively a SHA-1 hash of the code, taken before it is - executed.  The hash is stored in a platform configuration + executed. The hash is stored in a platform configuration register (PCR) in the TPM. Note: SHA-1 is used here because this is what the TPM chips support. @@ -143,50 +143,50 @@ PCR-02 - Option ROM Code  + Option ROM Code Hardware PCR-03 - Option ROM Configuration and Data  - Hardware  + Option ROM Configuration and Data + Hardware PCR-04 Initial Program Loader (IPL) Code. For example, master boot record. - Software  + Software PCR-05 - IPL Code Configuration and Data  - Software  + IPL Code Configuration and Data + Software PCR-06 - State Transition and Wake Events  - Software  + State Transition and Wake Events + Software PCR-07 - Host Platform Manufacturer Control  - Software  + Host Platform Manufacturer Control + Software PCR-08 Platform specific, often Kernel, Kernel Extensions, and Drivers - Software  + Software PCR-09 Platform specific, often Initramfs - Software  + Software PCR-10 to PCR-23 - Platform specific  - Software  + Platform specific + Software @@ -201,12 +201,12 @@ validation. Typically the PCR values listed under the software context in the table above are the ones that a cloud architect has direct control over. But even these may change as the - software in the cloud is upgraded.  Configuration management + software in the cloud is upgraded. Configuration management should be linked into the PCR policy engine to ensure that the validation is always up to date. Each manufacturer must provide the BIOS and firmware code for their servers. Different servers, hypervisors, and - operating systems will choose to populate different PCRs.  In + operating systems will choose to populate different PCRs. In most real world deployments, it will be impossible to validate every PCR against a known good quantity ("golden measurement"). Experience has shown that, even within a single @@ -245,8 +245,8 @@ 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 + book. We recommend following the guidance from a hardening + guide specific to your operating system. For example, the security technical implementation guides (STIG) and the Use a read-only file system where possible. Ensure - that writeable file systems do not permit execution.  This + that writeable file systems do not permit execution. This can be handled through the mount options provided in /etc/fstab. Use a mandatory access control policy to contain the instances, the node services, and any other critical - processes and data on the node.  See the discussions on + processes and data on the node. See the discussions on sVirt / SELinux and AppArmor below. @@ -384,7 +384,7 @@ In some deployments it may be required to add host-based IDS on sensitive components on security domain - bridges.  A host-based IDS may detect anomalous activity + bridges. A host-based IDS may detect anomalous activity by compromised or unauthorized processes on the component. The IDS should transmit alert and log information on the Management network. diff --git a/doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml b/doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml index 3d1b1f86d7..b9ef3d3099 100644 --- a/doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml +++ b/doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml @@ -36,7 +36,7 @@ Cryptographic Algorithms, Cipher Modes, and Protocols We recommend only using TLS v1.1 or v1.2. SSLv3 and TLSv1.0 may be used for compatibility but we recommend using caution and only enabling these protocols if you have a strong requirement to do so. 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: - National Security Agency, Suite B Cryptography + National Security Agency, Suite B Cryptography OWASP Guide to Cryptography diff --git a/doc/security-guide/ch020_ssl-everywhere.xml b/doc/security-guide/ch020_ssl-everywhere.xml index 830ee63a31..a70b5c1ed0 100644 --- a/doc/security-guide/ch020_ssl-everywhere.xml +++ b/doc/security-guide/ch020_ssl-everywhere.xml @@ -94,7 +94,7 @@ ciphers = "kEECDH:kEDH:kRSA:HIGH:!RC4:!MD5:!aNULL:!eNULL:!EXP:!LOW:!MEDIUM"
Pound - with AES-NI acceleration -   + ## see pound(8) for details daemon 1 ###################################################################### @@ -147,8 +147,8 @@ End
Stud - This stud example enables SSL v3 for client compatibility.  The ciphers line can be tweaked based on your needs, however this is a reasonable starting place. -   + This stud example enables SSL v3 for client compatibility. The ciphers line can be tweaked based on your needs, however this is a reasonable starting place. + # SSL x509 certificate file. pem-file = " # SSL protocol. @@ -187,7 +187,7 @@ write-proxy = off
nginx This nginx example requires TLS v1.1 or v1.2 for maximum security. The ssl_ciphers line can be tweaked based on your needs, however this is a reasonable starting place. -   + server { listen : ssl; ssl_certificate ; @@ -204,7 +204,7 @@ server { }
Apache -   + <VirtualHost <ip address>:80> ServerName <site FQDN> RedirectPermanent / https://<site FQDN>/ @@ -231,7 +231,7 @@ server { </VirtualHost> Compute API SSL endpoint in Apache2, which needs to be paired with a short WSGI script. -   + <VirtualHost <ip address>:8447> ServerName <site FQDN> SSLEngine On diff --git a/doc/security-guide/ch021_paste-and-middleware.xml b/doc/security-guide/ch021_paste-and-middleware.xml index b28724c1d2..e7dc03c483 100644 --- a/doc/security-guide/ch021_paste-and-middleware.xml +++ b/doc/security-guide/ch021_paste-and-middleware.xml @@ -5,12 +5,12 @@
Internal API Communications OpenStack provides both public facing and private API endpoints. By default, OpenStack components use the publicly defined endpoints. The recommendation is to configure these components to use the API endpoint within the proper security domain. - Services select their respective API endpoints based on the OpenStack service catalog.  The issue here is these services may not obey the listed public or internal API end point values. This can lead to internal management traffic being routed to external API endpoints. + Services select their respective API endpoints based on the OpenStack service catalog. The issue here is these services may not obey the listed public or internal API end point values. This can lead to internal management traffic being routed to external API endpoints.
Configure Internal URLs in Identity Service Catalog The Identity Service catalog should be aware of your internal URLs. While this feature is not utilized by default, it may be leveraged through configuration. Additionally, it should be forward-compatible with expectant changes once this behavior becomes the default. To register an internal URL for an endpoint: -   + $ keystone endpoint-create \ --region RegionOne \ --service-id=1ff4ece13c3e48d8a6461faebd9cd38f \ @@ -20,11 +20,11 @@ $ keystone endpoint-create \
Configure Applications for Internal URLs - Some services can be forced to use specific API endpoints.  Therefore, it is recommended that each OpenStack service communicating to the API of another service must be explicitly configured to access the proper internal API endpoint. + Some services can be forced to use specific API endpoints. Therefore, it is recommended that each OpenStack service communicating to the API of another service must be explicitly configured to access the proper internal API endpoint. Each project may present an inconsistent way of defining target API endpoints. Future releases of OpenStack seek to resolve these inconsistencies through consistent use of the Identity Service catalog.
Configuration Example #1: Nova -   + [DEFAULT] cinder_catalog_info='volume:cinder:internalURL' glance_protocol='https' @@ -56,13 +56,13 @@ glance_host='https://glance-server'
Network Policy - API endpoints typically bridge multiple security domains, as such particular attention should be paid to the compartmentalization of the API processes.  See the Security Domain Bridging section for additional information in this area. + API endpoints typically bridge multiple security domains, as such particular attention should be paid to the compartmentalization of the API processes. See the Security Domain Bridging section for additional information in this area. With careful modeling, network ACLs and IDS technologies can be use to enforce explicit point to point communication between network services. As critical cross domain service, this type of explicit enforcement works well for OpenStack's message queue service. Policy enforcement can be implemented through the configuration of services, host-based firewalls (such as IPTables), local policy (SELinux or AppArmor), and optionally enforced through global network policy.
Mandatory Access Controls - API endpoint processes should be isolated from each other and other processes on a machine. The configuration for those processes should be restricted to those processes not only by Discretionary Access Controls, but through Mandatory Access Controls. The goal of these enhanced access control is to aid in the containment and escalation of API endpoint security breaches.  With mandatory access controls, such breaches will severely limit access to resources and provide earlier alerting on such events. + API endpoint processes should be isolated from each other and other processes on a machine. The configuration for those processes should be restricted to those processes not only by Discretionary Access Controls, but through Mandatory Access Controls. The goal of these enhanced access control is to aid in the containment and escalation of API endpoint security breaches. With mandatory access controls, such breaches will severely limit access to resources and provide earlier alerting on such events.
diff --git a/doc/security-guide/ch022_case-studies-api-endpoints.xml b/doc/security-guide/ch022_case-studies-api-endpoints.xml index fb69127e61..4ef91dacd8 100644 --- a/doc/security-guide/ch022_case-studies-api-endpoints.xml +++ b/doc/security-guide/ch022_case-studies-api-endpoints.xml @@ -1,7 +1,7 @@ Case Studies: API Endpoints - In this case study we discuss how Alice and Bob would address endpoint configuration to secure their private and public clouds. Alice's cloud is not publicly accessible, but she is still concerned about securing the endpoints against improper use.  Bob's cloud, being public, must take measures to reduce the risk of attacks by external adversaries. + In this case study we discuss how Alice and Bob would address endpoint configuration to secure their private and public clouds. Alice's cloud is not publicly accessible, but she is still concerned about securing the endpoints against improper use. Bob's cloud, being public, must take measures to reduce the risk of attacks by external adversaries.
Alice's Private Cloud Alice's organization requires that the security architecture protect the access to the public and private endpoints, so she elects to use the Apache SSL proxy on both public and internal services. Alice's organization has implemented its own certificate authority. Alice contacts the PKI office in her agency that manages her PKI and certificate issuance. Alice obtains certificates issued by this CA and configures the services within both the public and management security domains to use these certificates. Since Alice's OpenStack deployment exists entirely on a disconnected from the Internet network, she makes sure to remove all default CA bundles that contain external public CA providers to ensure the OpenStack services only accept client certificates issued by her agency's CA. Alice has registered all of the services in the Keystone Services Catalog, using the internal URLs for access by internal services. She has installed host-based intrusion detection on all of the API endpoints. diff --git a/doc/security-guide/ch024_authentication.xml b/doc/security-guide/ch024_authentication.xml index 1e933dc637..fdc1aa3ce1 100644 --- a/doc/security-guide/ch024_authentication.xml +++ b/doc/security-guide/ch024_authentication.xml @@ -95,7 +95,7 @@ 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 + such a deployment, user provisioning would be out of the realm of the OpenStack deployment. There is an Cookies Session Cookies should be set to HTTPONLY: -   + SESSION_COOKIE_HTTPONLY = True Never configure CSRF or session cookies to have a wild card domain with a leading dot. Horizon's session and CSRF cookie should be secured when deployed with HTTPS: -   + Code CSRF_COOKIE_SECURE = True SESSION_COOKIE_SECURE = True
diff --git a/doc/security-guide/ch026_compute.xml b/doc/security-guide/ch026_compute.xml index 5fc519837a..1c83723fff 100644 --- a/doc/security-guide/ch026_compute.xml +++ b/doc/security-guide/ch026_compute.xml @@ -1,7 +1,7 @@ Compute - The Compute service (nova) is one of the more complex OpenStack services.  It runs in many locations throughout the cloud and interacts with a variety of internal services.  For this reason, most of our recommendations regarding best practices for Compute service configuration are distributed throughout this book. We provide specific details in the sections on Management, API Endpoints, Messaging, and Database. + The Compute service (nova) is one of the more complex OpenStack services. It runs in many locations throughout the cloud and interacts with a variety of internal services. For this reason, most of our recommendations regarding best practices for Compute service configuration are distributed throughout this book. We provide specific details in the sections on Management, API Endpoints, Messaging, and Database.
Virtual Console Selection One decision a cloud architect will need to make regarding @@ -11,12 +11,12 @@ the differences between these options.
Virtual Network Computer (VNC) - OpenStack can be configured to provide remote desktop console access to instances for tenants and/or administrators using the Virtual Network Computer (VNC) protocol.   + OpenStack can be configured to provide remote desktop console access to instances for tenants and/or administrators using the Virtual Network Computer (VNC) protocol.
Capabilities - The OpenStack Dashboard (Horizon) can provide a VNC console for instances directly on the web page using the HTML5 noVNC client.  This requires the nova-novncproxy service to bridge from the public network to the management network. + The OpenStack Dashboard (Horizon) can provide a VNC console for instances directly on the web page using the HTML5 noVNC client. This requires the nova-novncproxy service to bridge from the public network to the management network. The nova command-line utility can @@ -50,7 +50,7 @@
Capabilities - SPICE is supported by the OpenStack Dashboard (Horizon) directly on the instance web page.  This requires the nova-spicehtml5proxy service. + SPICE is supported by the OpenStack Dashboard (Horizon) directly on the instance web page. This requires the nova-spicehtml5proxy service. The nova command-line utility can return a URL for SPICE console for access by a SPICE-html client. @@ -60,7 +60,7 @@
Limitations - Although SPICE has many advantages over VNC, the spice-html5 browser integration currently doesn't really allow admins to take advantage of any of the benefits. To take advantage of SPICE features like multi-monitor, USB pass through, etc. admins are recommended to use a standalone SPICE client within the Management Network. + Although SPICE has many advantages over VNC, the spice-html5 browser integration currently doesn't really allow admins to take advantage of any of the benefits. To take advantage of SPICE features like multi-monitor, USB pass through, etc. admins are recommended to use a standalone SPICE client within the Management Network.
diff --git a/doc/security-guide/ch028_case-studies-identity-management.xml b/doc/security-guide/ch028_case-studies-identity-management.xml index 9d8deb30f9..02f988a5a0 100644 --- a/doc/security-guide/ch028_case-studies-identity-management.xml +++ b/doc/security-guide/ch028_case-studies-identity-management.xml @@ -5,13 +5,13 @@
Alice's Private Cloud Alice's enterprise has a well-established directory service with two-factor authentication for all users. She configures Keystone to support an external authentication service supporting authentication with government-issued access cards. She also uses an external LDAP server to provide role information for the users that is integrated with the access control policy. Due to FedRAMP compliance requirements, Alice implements two-factor authentication on the Management network for all administrator access. - Alice also deploys the Dashboard to manage many aspects of the cloud.  She deploys the Dashboard with HSTS to ensure that only HTTPS is used.  The Dashboard resides within an internal subdomain of the private network domain name system. - Alice decides to use SPICE instead of VNC for the virtual console.  She wants to take advantage of the emerging capabilities in SPICE. + Alice also deploys the Dashboard to manage many aspects of the cloud. She deploys the Dashboard with HSTS to ensure that only HTTPS is used. The Dashboard resides within an internal subdomain of the private network domain name system. + Alice decides to use SPICE instead of VNC for the virtual console. She wants to take advantage of the emerging capabilities in SPICE.
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 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.
diff --git a/doc/security-guide/ch031_neutron-architecture.xml b/doc/security-guide/ch031_neutron-architecture.xml index 987838657f..16e4dbe94b 100644 --- a/doc/security-guide/ch031_neutron-architecture.xml +++ b/doc/security-guide/ch031_neutron-architecture.xml @@ -29,7 +29,7 @@
OS Networking Service placement on Physical Servers - In this guide, we focus primarily on a standard architecture that includes a cloud controller host, a network host, and a set of compute hypervisors for running VMs. + In this guide, we focus primarily on a standard architecture that includes a cloud controller host, a network host, and a set of compute hypervisors for running VMs.
Network Connectivity of Physical Servers @@ -50,7 +50,7 @@ External network Used to provide VMs with Internet access in some deployment scenarios. The IP addresses on this network should be reachable by anyone on the Internet and is considered to be in the Public Security Domain. - API network 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. + API network 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. For additional information see the Networking chapter in the diff --git a/doc/security-guide/ch032_networking-best-practices.xml b/doc/security-guide/ch032_networking-best-practices.xml index a824efd4d1..c227254dbf 100644 --- a/doc/security-guide/ch032_networking-best-practices.xml +++ b/doc/security-guide/ch032_networking-best-practices.xml @@ -9,7 +9,7 @@
VLANs VLANs are realized as packets on a specific physical network containing IEEE 802.1Q headers with a specific VLAN ID (VID) field value. VLAN networks sharing the same physical network are isolated from each other at L2, and can even have overlapping IP address spaces. Each distinct physical network supporting VLAN networks is treated as a separate VLAN trunk, with a distinct space of VID values. Valid VID values are 1 through 4094. - VLAN configuration complexity depends on your OpenStack design requirements. In order to allow OpenStack Networking to efficiently use VLANs, you must allocate a VLAN range (one for each tenant) and turn each compute node physical switch port into a VLAN trunk port. + VLAN configuration complexity depends on your OpenStack design requirements. In order to allow OpenStack Networking to efficiently use VLANs, you must allocate a VLAN range (one for each tenant) and turn each compute node physical switch port into a VLAN trunk port. NOTE: If you intend for your network to support more than 4094 tenants VLAN is probably not the correct option for you as multiple 'hacks' are required to extend the VLAN tags to more than 4094 tenants. @@ -39,7 +39,7 @@
Quality of Service (QoS) - The ability to set QoS on the virtual interface ports of tenant instances is a current deficiency for OpenStack Networking. The application of QoS for traffic shaping and rate-limiting at the physical network edge device is insufficient due to the dynamic nature of workloads in an OpenStack deployment and can not be leveraged in the traditional way.  QoS-as-a-Service (QoSaaS) is currently in development for the OpenStack Networking Havana release as an experimental feature. QoSaaS is planning to provide the following services: + The ability to set QoS on the virtual interface ports of tenant instances is a current deficiency for OpenStack Networking. The application of QoS for traffic shaping and rate-limiting at the physical network edge device is insufficient due to the dynamic nature of workloads in an OpenStack deployment and can not be leveraged in the traditional way. QoS-as-a-Service (QoSaaS) is currently in development for the OpenStack Networking Havana release as an experimental feature. QoSaaS is planning to provide the following services: Traffic shaping via DSCP markings @@ -57,11 +57,11 @@
Load Balancing - An experimental feature in the Grizzly release of OpenStack Networking is Load-Balancer-as-a-service (LBaaS). The LBaaS API gives early adopters and vendors a chance to build implementations of the technology. The reference implementation however, is still experimental and should likely not be run in a production environment. The current reference implementation is based on HA-Proxy. There are third-party plug-ins in development for extensions in OpenStack Networking to provide extensive L4-L7 functionality for virtual interface ports. + An experimental feature in the Grizzly release of OpenStack Networking is Load-Balancer-as-a-service (LBaaS). The LBaaS API gives early adopters and vendors a chance to build implementations of the technology. The reference implementation however, is still experimental and should likely not be run in a production environment. The current reference implementation is based on HA-Proxy. There are third-party plug-ins in development for extensions in OpenStack Networking to provide extensive L4-L7 functionality for virtual interface ports.
Firewalls - FW-as-a-Service (FWaaS) is currently in development for the OpenStack Networking Havana release as an experimental feature. FWaaS will address the need to manage and leverage the rich set of security features provided by typical firewall products which are typically far more comprehensive than what is currently provided by security groups. There are third-party plug-ins in development for extensions in OpenStack Networking to support this. + FW-as-a-Service (FWaaS) is currently in development for the OpenStack Networking Havana release as an experimental feature. FWaaS will address the need to manage and leverage the rich set of security features provided by typical firewall products which are typically far more comprehensive than what is currently provided by security groups. There are third-party plug-ins in development for extensions in OpenStack Networking to support this. It is critical during the design of an OpenStack Networking infrastructure to understand the current features and limitations of network services that are available. Understanding where the boundaries of your virtual and physical networks will help you add the required security controls in your environment.
diff --git a/doc/security-guide/ch033_securing-neutron-services.xml b/doc/security-guide/ch033_securing-neutron-services.xml index 6a6b346502..b5b1f4b8b0 100644 --- a/doc/security-guide/ch033_securing-neutron-services.xml +++ b/doc/security-guide/ch033_securing-neutron-services.xml @@ -1,7 +1,7 @@ Securing OpenStack Networking Services - In order to secure OpenStack Networking, an understanding of the workflow process for tenant instance creation needs to be mapped to security domains.  + 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 @@ -33,7 +33,7 @@
Restrict Bind Address of the API server: neutron-server To restrict the interface or IP address on which the OpenStack Networking API service binds a network socket for incoming client connections, specify the bind_host and bind_port in the neutron.conf file as shown: -   + # Address to bind the API server bind_host = <ip address of server> 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 afa9da2833..e92080b082 100644 --- a/doc/security-guide/ch034_tenant-secure-networking-best-practices.xml +++ b/doc/security-guide/ch034_tenant-secure-networking-best-practices.xml @@ -41,7 +41,7 @@
Quotas Quotas provide the ability to limit the number of network resources available to tenants. You can enforce default quotas for all tenants. -   + /etc/neutron/neutron.conf [QUOTAS] # resource name(s) that are supported in quota features @@ -68,7 +68,7 @@ quota_security_group_rule = 100 # default driver to use for quota checks quota_driver = neutron.quota.ConfDriver OpenStack Networking also supports per-tenant quotas limit via a quota extension API. To enable per-tenant quotas, you need to set quota_driver in neutron.conf. -   + quota_driver = neutron.db.quota_db.DbQuotaDriver
diff --git a/doc/security-guide/ch038_transport-security.xml b/doc/security-guide/ch038_transport-security.xml index 1f3ed68437..7141fc13f4 100644 --- a/doc/security-guide/ch038_transport-security.xml +++ b/doc/security-guide/ch038_transport-security.xml @@ -9,7 +9,7 @@
RabbitMQ Server SSL Configuration The following lines should be added to the system-wide RabbitMQ configuration file, typically /etc/rabbitmq/rabbitmq.config: -   + [ {rabbit, [ {tcp_listeners, [] }, @@ -49,10 +49,10 @@
Authentication Configuration Example - RabbitMQ On the RabbitMQ server, delete the default 'guest' user: -   + rabbitmqctl delete_user quest On the RabbitMQ server, for each OpenStack service or node that communicates with the message queue set up user accounts and privileges: -   + rabbitmqctl add_user compute01 password rabbitmqctl set_permissions compute01 ".*"".*"".*" For additional configuration information see: @@ -117,7 +117,7 @@ qpid_sasl_mechanisms=<space separated list of SASL mechanisms to use for auth
Namespaces Network namespaces are highly recommended for all services running on OpenStack Compute Hypervisors. This will help prevent against the bridging of network traffic between VM guests and the management network. - When using ZeroMQ messaging, each host must run at least one ZeroMQ message receiver to receive messages from the network and forward messages to local processes via IPC. It is possible and advisable to run an independent message receiver per project within an IPC namespace, along with other services within the same project. + When using ZeroMQ messaging, each host must run at least one ZeroMQ message receiver to receive messages from the network and forward messages to local processes via IPC. It is possible and advisable to run an independent message receiver per project within an IPC namespace, along with other services within the same project.
Network Policy diff --git a/doc/security-guide/ch042_database-overview.xml b/doc/security-guide/ch042_database-overview.xml index f9e9e27133..3cd787f509 100644 --- a/doc/security-guide/ch042_database-overview.xml +++ b/doc/security-guide/ch042_database-overview.xml @@ -5,7 +5,7 @@
OpenStack Database Access Model All of the services within an OpenStack project access a single database. There are presently no reference policies for creating table or row based access restrictions to the database. - There are no general provisions for granular control of database operations in OpenStack. Access and privileges are granted simply based on whether a node has access to the database or not.  In this scenario, nodes with access to the database may have full privileges to DROP, INSERT, or UPDATE functions. + There are no general provisions for granular control of database operations in OpenStack. Access and privileges are granted simply based on whether a node has access to the database or not. In this scenario, nodes with access to the database may have full privileges to DROP, INSERT, or UPDATE functions.
Granular Access Control By default, each of the OpenStack services and their processes access the database using a shared set of credentials. This makes auditing database operations and revoking access privileges from a service and its processes to the database particularly difficult. @@ -45,7 +45,7 @@
Database Authentication and Access Control - Given the risks around access to the database, we strongly recommend that unique database user accounts be created per node needing access to the database. Doing this facilitates better analysis and auditing for ensuring compliance or in the event of a compromise of a node allows you to isolate the compromised host by removing access for that node to the database upon detection. When creating these per service endpoint database user accounts, care should be taken to ensure that they are configured to require SSL.  Alternatively, for increased security it is recommended that the database accounts be configured using X.509 certificate authentication in addition to usernames and passwords. + Given the risks around access to the database, we strongly recommend that unique database user accounts be created per node needing access to the database. Doing this facilitates better analysis and auditing for ensuring compliance or in the event of a compromise of a node allows you to isolate the compromised host by removing access for that node to the database upon detection. When creating these per service endpoint database user accounts, care should be taken to ensure that they are configured to require SSL. Alternatively, for increased security it is recommended that the database accounts be configured using X.509 certificate authentication in addition to usernames and passwords.
Privileges A separate database administrator (DBA) account should be created and protected that has full privileges to create/drop databases, create user accounts, and update user privileges. This simple means of separation of responsibility helps prevent accidental misconfiguration, lowers risk and lowers scope of compromise. @@ -56,13 +56,13 @@ Require User Accounts to Require SSL Transport
Configuration Example #1: (MySQL) -   + GRANT ALL ON dbname.* to 'compute01'@'hostname' IDENTIFIED BY 'password' REQUIRE SSL;
Configuration Example #2: (PostgreSQL) In file pg_hba.conf: -   + hostssl dbname compute01 hostname md5 Note this command only adds the ability to communicate over SSL and is non-exclusive. Other access methods that may allow unencrypted transport should be disabled so that SSL is the sole access method. The 'md5' parameter defines the authentication method as a hashed password. We provide a secure authentication example in the section below. @@ -70,17 +70,17 @@ hostssl dbname compute01 hostname md5
Authentication with X.509 Certificates - Security may be enhanced by requiring X.509 client certificates for authentication.  Authenticating to the database in this manner provides greater identity assurance of the client making the connection to the database and ensures that the communications are encrypted. + Security may be enhanced by requiring X.509 client certificates for authentication. Authenticating to the database in this manner provides greater identity assurance of the client making the connection to the database and ensures that the communications are encrypted.
Configuration Example #1: (MySQL) -   + GRANT ALL on dbname.* to 'compute01'@'hostname' IDENTIFIED BY 'password' REQUIRE SUBJECT '/C=XX/ST=YYY/L=ZZZZ/O=cloudycloud/CN=compute01' AND ISSUER '/C=XX/ST=YYY/L=ZZZZ/O=cloudycloud/CN=cloud-ca';
Configuration Example #2: (PostgreSQL) -   + hostssl dbname compute01 hostname cert
@@ -109,7 +109,7 @@ charset=utf8&ssl_ca=/etc/mysql/cacert.pem&ssl_cert=/etc/mysql/server-cer Note, as nova-conductor only applies to OpenStack Compute, direct database access from compute hosts may still be necessary for the operation of other OpenStack components such as Telemetry (Ceilometer), Networking, and Block Storage. Implementors should weigh the benefits and risks of both configurations before enabling or disabling the nova-conductor service. We are not yet prepared to recommend the use of nova-conductor in the Grizzly release. However, we do believe that this recommendation will change as additional features are added into OpenStack. To disable the nova-conductor, place the following into your nova.conf file (on your compute hosts): -   + [conductor] use_local = true
diff --git a/doc/security-guide/ch043_database-transport-security.xml b/doc/security-guide/ch043_database-transport-security.xml index 29ea20a18d..416d86b70b 100644 --- a/doc/security-guide/ch043_database-transport-security.xml +++ b/doc/security-guide/ch043_database-transport-security.xml @@ -8,7 +8,7 @@
Restricting Bind Address for MySQL In my.cnf: -   + [mysqld] ... bind-address <ip address or hostname of management network interface> @@ -16,13 +16,13 @@ bind-address <ip address or hostname of management network interface> Restricting Listen Address for PostgreSQL In postgresql.conf: -   -listen_addresses = <ip address or hostname of management network interface> + +listen_addresses = <ip address or hostname of management network interface>
Database Transport - In addition to restricting database communications to the management network, we also strongly recommend that the cloud administrator configure their database backend to require SSL. Using SSL for the database client connections  protects the communications from tampering and eavesdropping. As will be discussed in the next section, using SSL also provides the framework for doing database user authentication via X.509 certificates (commonly referred to as PKI). Below is guidance on how SSL is typically configured for the two popular database backends MySQL and PostgreSQL. + In addition to restricting database communications to the management network, we also strongly recommend that the cloud administrator configure their database backend to require SSL. Using SSL for the database client connections protects the communications from tampering and eavesdropping. As will be discussed in the next section, using SSL also provides the framework for doing database user authentication via X.509 certificates (commonly referred to as PKI). Below is guidance on how SSL is typically configured for the two popular database backends MySQL and PostgreSQL. NOTE: When installing the certificate and key files, ensure that the file permissions are restricted, for example chmod 0600, and the ownership is restricted to the database daemon user to prevent unauthorized access by other processes and users on the database server. diff --git a/doc/security-guide/ch044_case-studies-database.xml b/doc/security-guide/ch044_case-studies-database.xml index 91977290b0..3b31ef9cf7 100644 --- a/doc/security-guide/ch044_case-studies-database.xml +++ b/doc/security-guide/ch044_case-studies-database.xml @@ -8,6 +8,6 @@
Bob's Public Cloud - Bob is concerned about strong separation of his tenants' data, so he has elected to use the Postgres database , known for its stronger security features.  The database resides on the Management network and uses SSL with mutual authentication with the services. Since the database is on the Management network, the database uses certificates signed with the company's self-signed root certificate. Bob creates separate user accounts for each database user, and configures the database to use both passwords and X.509 certificates for authentication. He elects not to use the nova-conductor sub-service due to a desire for fine-grained access control. + Bob is concerned about strong separation of his tenants' data, so he has elected to use the Postgres database , known for its stronger security features. The database resides on the Management network and uses SSL with mutual authentication with the services. Since the database is on the Management network, the database uses certificates signed with the company's self-signed root certificate. Bob creates separate user accounts for each database user, and configures the database to use both passwords and X.509 certificates for authentication. He elects not to use the nova-conductor sub-service due to a desire for fine-grained access control.
diff --git a/doc/security-guide/ch046_data-residency.xml b/doc/security-guide/ch046_data-residency.xml index 02ae12c02e..69000f9edb 100644 --- a/doc/security-guide/ch046_data-residency.xml +++ b/doc/security-guide/ch046_data-residency.xml @@ -100,7 +100,7 @@
Data not securely erased - Within OpenStack some data may be deleted, but not securely erased in the context of the NIST standards outlined above. This is generally applicable to most or all of the above-defined metadata and information stored in the database. This may be remediated with database and/or system configuration for auto vacuuming and periodic free-space wiping. + Within OpenStack some data may be deleted, but not securely erased in the context of the NIST standards outlined above. This is generally applicable to most or all of the above-defined metadata and information stored in the database. This may be remediated with database and/or system configuration for auto vacuuming and periodic free-space wiping.
Instance memory scrubbing diff --git a/doc/security-guide/ch047_data-encryption.xml b/doc/security-guide/ch047_data-encryption.xml index 8deceeebdd..21be6bee16 100644 --- a/doc/security-guide/ch047_data-encryption.xml +++ b/doc/security-guide/ch047_data-encryption.xml @@ -18,7 +18,7 @@
Object Storage Objects - The ability to encrypt objects in Object Storage is presently limited to disk-level encryption per node. However, there does exist third-party extensions and modules for per-object encryption. These modules have been proposed upstream, but have not per this writing been formally accepted. Below are some pointers:  + The ability to encrypt objects in Object Storage is presently limited to disk-level encryption per node. However, there does exist third-party extensions and modules for per-object encryption. These modules have been proposed upstream, but have not per this writing been formally accepted. Below are some pointers: https://github.com/Mirantis/swift-encrypt http://www.mirantis.com/blog/on-disk-encryption-prototype-for-openstack-swift/
@@ -26,7 +26,7 @@ Block Storage Volumes & Instance Ephemeral Filesystems The ability to encrypt volumes depends on the service backends chosen. Some backends may not support this at all. As both block storage and compute support LVM backed storage, we can easily provide an example applicable to both systems. In deployments using LVM, encryption may be performed against the backing physical volumes. An encrypted block device would be created using the standard Linux tools, with the LVM physical volume (PV) created on top of the decrypted block device using pvcreate. Then, the vgcreate or vgmodify tool may be used to add the encrypted physical volume to an LVM volume group (VG). - A feature aimed for the Havana release provides encryption of the VM's data before it is written to disk. This allows the privacy of data to be maintained while residing on the storage device. The idea is similar to how self-encrypting drives work. This feature presents a normal block storage device to the VM but encrypts the bytes in the virtualization host before writing them to the disk. The block server operates exactly as it does when reading and writing unencrypted blocks, except special handling will be required for Block Storage features such as snapshots and live migration.  Note that this feature uses an independent key manager. + A feature aimed for the Havana release provides encryption of the VM's data before it is written to disk. This allows the privacy of data to be maintained while residing on the storage device. The idea is similar to how self-encrypting drives work. This feature presents a normal block storage device to the VM but encrypts the bytes in the virtualization host before writing them to the disk. The block server operates exactly as it does when reading and writing unencrypted blocks, except special handling will be required for Block Storage features such as snapshots and live migration. Note that this feature uses an independent key manager.
Network Data diff --git a/doc/security-guide/ch048_key-management.xml b/doc/security-guide/ch048_key-management.xml index 26657c981c..8442c03ad8 100644 --- a/doc/security-guide/ch048_key-management.xml +++ b/doc/security-guide/ch048_key-management.xml @@ -3,7 +3,7 @@ Key Management 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 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. 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. - 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). + 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). OpenStack Block Storage, Cinder, is the first service looking to integrate with the key manager to provide volume encryption.
References: diff --git a/doc/security-guide/ch051_vss-intro.xml b/doc/security-guide/ch051_vss-intro.xml index a34f97e81f..0f812cd3fd 100644 --- a/doc/security-guide/ch051_vss-intro.xml +++ b/doc/security-guide/ch051_vss-intro.xml @@ -19,7 +19,7 @@ to deliver on the promise of multi-tenant, either between customers in a public cloud, between business units in a private cloud, or some mixture of the two in a hybrid cloud. - 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. + 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.
Hypervisors in OpenStack Whether OpenStack is deployed within private data centers @@ -123,7 +123,7 @@ Audit - The system provides the capability to audit a large number of events including individual system calls as well as events generated by trusted processes. Audit data is collected in regular files in ASCII format. The system provides a program for the purpose of searching the audit records.The system administrator can define a rule base to restrict auditing to the events they are interested in. This includes the ability to restrict auditing to specific events, specific users, specific objects or a combination of all of this. Audit records can be transferred to a remote audit daemon. + The system provides the capability to audit a large number of events including individual system calls as well as events generated by trusted processes. Audit data is collected in regular files in ASCII format. The system provides a program for the purpose of searching the audit records.The system administrator can define a rule base to restrict auditing to the events they are interested in. This includes the ability to restrict auditing to specific events, specific users, specific objects or a combination of all of this.Audit records can be transferred to a remote audit daemon. Discretionary Access Control @@ -171,7 +171,7 @@ 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 + process isolation mechanisms. In the evaluated configuration, the reserved user ID root owns the directories and files that define the TSF configuration. In general, files and directories @@ -266,7 +266,7 @@
Products validated as conforming to FIPS 140-2 are accepted by the Federal agencies of both countries [United States and Canada] for the protection of sensitive information (United States) or Designated Information (Canada). The goal of the CMVP is to promote the use of validated cryptographic modules and provide Federal agencies with a security metric to use in procuring equipment containing validated cryptographic modules.
- When evaluating base hypervisor technologies, consider if the hypervisor has been certified against FIPS 140-2. Not only is conformance against FIPS 140-2 mandated per U.S. Government policy, formal certification indicates that a given implementation of a cryptographic algorithm has been reviewed for conformance against module specification, cryptographic module ports and interfaces; roles, services, and authentication; finite state model; physical security; operational environment; cryptographic key management; electromagnetic interference/electromagnetic compatibility (EMI/EMC); self-tests; design assurance; and mitigation of other attacks. + When evaluating base hypervisor technologies, consider if the hypervisor has been certified against FIPS 140-2. Not only is conformance against FIPS 140-2 mandated per U.S. Government policy, formal certification indicates that a given implementation of a cryptographic algorithm has been reviewed for conformance against module specification, cryptographic module ports and interfaces; roles, services, and authentication; finite state model; physical security; operational environment; cryptographic key management; electromagnetic interference/electromagnetic compatibility (EMI/EMC); self-tests; design assurance; and mitigation of other attacks.
@@ -317,7 +317,7 @@
Additional Security Features Another thing to look into when selecting a hypervisor platform is the availability of specific security features. In particular, we are referring to features like Xen Server's XSM or Xen Security Modules, sVirt, Intel TXT, and AppArmor. The presence of these features will help increase your security profile as well as provide a good foundation. - The following table calls out these features by common hypervisor platforms.  + The following table calls out these features by common hypervisor platforms. @@ -330,7 +330,7 @@ -   + KSM XSM sVirt @@ -342,7 +342,7 @@ KVM &CHECK; -   + &CHECK; &CHECK; &CHECK; @@ -351,33 +351,33 @@ Xen -   + &CHECK; -   + &CHECK; -   -   + + &CHECK; ESXi -   -   -   + + + &CHECK; -   -   -   + + + Hyper-V -   -   -   -   -   -   -   + + + + + + + diff --git a/doc/security-guide/ch052_devices.xml b/doc/security-guide/ch052_devices.xml index 551da5deb8..e49a2ef32f 100644 --- a/doc/security-guide/ch052_devices.xml +++ b/doc/security-guide/ch052_devices.xml @@ -14,7 +14,7 @@ - The IOMMU feature is marketed as VT-d by Intel and AMD-Vi by AMD. + The IOMMU feature is marketed as VT-d by Intel and AMD-Vi by AMD. 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. 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 link:Management/Node Bootstrapping, 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. @@ -47,10 +47,10 @@ Minimizing the Qemu Code base One classic security principle is to remove any unused components from your system. QEMU provides support for many different virtual hardware devices. However, only a small number of devices are needed for a given instance. Most instances will use the virtio devices. However, some legacy instances will need access to specific hardware, which can be specified using glance metadata: glance image-update \ -    --property hw_disk_bus=ide \ -    --property hw_cdrom_bus=ide \ -    --property hw_vif_model=e1000 \ -    f16-x86_64-openstack-sda + --property hw_disk_bus=ide \ + --property hw_cdrom_bus=ide \ + --property hw_vif_model=e1000 \ + f16-x86_64-openstack-sda A cloud architect should decide what devices to make available to cloud users. Anything that is not needed should be removed from QEMU. This step requires recompiling QEMU after modifying the options passed to the QEMU configure script. For a complete list of up-to-date options simply run ./configure --help from within the QEMU source directory. Decide what is needed for your deployment, and disable the remaining options.
@@ -67,7 +67,7 @@ Never eXecute (NX): Also known as Data Execution Prevention (DEP), ensures that data sections of the executable can not be executed. - Position Independent Executable (PIE): Produces a position independent executable, which is necessary for ASLR.   + 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. @@ -134,7 +134,7 @@ CFLAGS="-arch x86_64 -fstack-protector-all -Wstack-protector --param ssp-buffer- - 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: @@ -159,7 +159,7 @@ system_u:object_r:svirt_image_t:s0:419,c172 image2 sVirt SELinux Boolean -  Description + Description virt_use_common diff --git a/doc/security-guide/ch053_case-studies-instance-isolation.xml b/doc/security-guide/ch053_case-studies-instance-isolation.xml index b951f1e760..0d137f8979 100644 --- a/doc/security-guide/ch053_case-studies-instance-isolation.xml +++ b/doc/security-guide/ch053_case-studies-instance-isolation.xml @@ -1,7 +1,7 @@ Case Studies: Instance Isolation - In this case study we discuss how Alice and Bob would ensure that  their instances are properly isolated. First we consider hypervisor selection, and then techniques for hardening QEMU and applying mandatory access controls. + In this case study we discuss how Alice and Bob would ensure that their instances are properly isolated. First we consider hypervisor selection, and then techniques for hardening QEMU and applying mandatory access controls.
Alice's Private Cloud Alice chooses Xen for the hypervisor in her cloud due to a strong internal knowledge base and a desire to use the Xen security modules (XSM) for fine-grained policy enforcement. diff --git a/doc/security-guide/ch055_security-services-for-instances.xml b/doc/security-guide/ch055_security-services-for-instances.xml index 2002c51a63..b13062c454 100644 --- a/doc/security-guide/ch055_security-services-for-instances.xml +++ b/doc/security-guide/ch055_security-services-for-instances.xml @@ -48,7 +48,7 @@ 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. - 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 Filter Scheduler section of the OpenStack Configuration Reference. + 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 Filter Scheduler section of the OpenStack Configuration Reference. Tenant Driven Whole Host Reservation There currently exists a blueprint for whole host reservation - This would allow a tenant to exclusively reserve hosts for only it's instances, incurring extra costs.
@@ -73,7 +73,7 @@
GroupAntiAffinityFilter - The GroupAntiAffinityFilter ensures that each instance in a group is on a different host. To take advantage of this filter, the requester must pass a scheduler hint, using group as the key and a list of instance uuids as the value. + The GroupAntiAffinityFilter ensures that each instance in a group is on a different host. To take advantage of this filter, the requester must pass a scheduler hint, using group as the key and a list of instance uuids as the value.
Trusted Compute Pools @@ -88,18 +88,18 @@ Image Creation Process The OpenStack Documentation provides guidance on how to create and upload an image to Glance. Additionally it is assumed that you have a process by which you install and harden operating systems. Thus, the following items will provide additional guidance on how to ensure your images are built securely prior to upload. There are a variety of options for obtaining images. Each has specific steps that help validate the image's provenance. The first option is to obtain boot media from a trusted source. -   + mkdir -p /tmp/download_directorycd /tmp/download_directory wget http://mirror.anl.gov/pub/ubuntu-iso/CDs/precise/ubuntu-12.04.2-server-amd64.iso wget http://mirror.anl.gov/pub/ubuntu-iso/CDs/precise/SHA256SUMS wget http://mirror.anl.gov/pub/ubuntu-iso/CDs/precise/SHA256SUMS.gpg -gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 0xFBB75451 +gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 0xFBB75451 gpg --verify SHA256SUMS.gpg SHA256SUMSsha256sum -c SHA256SUMS 2>&1 | grep OK The second option is to use the OpenStack Virtual Machine Image Guide. 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. 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. - Example of RHEL 6 CCE-26976-1 which will help implement NIST 800-53 Section AC-19(d) in Oz. + Example of RHEL 6 CCE-26976-1 which will help implement NIST 800-53 SectionAC-19(d) in Oz. <template> <name>centos64</name> @@ -198,7 +198,7 @@ gpg --verify SHA256SUMS.gpg SHA256SUMSsha256sum -c SHA256SUMS 2>&1 | grep
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: -   + "compute_extension:admin_actions:migrate": "!", "compute_extension:admin_actions:migrateLive": "!",
diff --git a/doc/security-guide/ch058_forensicsincident-response.xml b/doc/security-guide/ch058_forensicsincident-response.xml index de7066d69e..2014b5e77a 100644 --- a/doc/security-guide/ch058_forensicsincident-response.xml +++ b/doc/security-guide/ch058_forensicsincident-response.xml @@ -4,12 +4,12 @@ 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. 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. 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. - 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. + 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. For instance, analyzing the access logs of Identity Service 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. 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.
Monitoring Use Cases - Monitoring events is more pro-active and provides real-time detection and response.  There are several tools to aid in monitoring. + Monitoring events is more pro-active and provides real-time detection and response. There are several tools to aid in monitoring. In the case of an OpenStack cloud instance, we need to monitor the hardware, the OpenStack services, and the cloud resource usage. The last stems from wanting to be elastic, to scale to the dynamic needs of the users. Here are a few important use cases to consider when implementing log aggregation, analysis and monitoring. These use cases can be implemented and monitored through various commercial and open source tools, homegrown scripts, etc. These tools and scripts can generate events that can then be sent to the administrators through email or integrated dashboard. It is important to consider additional use cases that may apply to your specific network and what you may consider anomalous behavior. @@ -29,11 +29,11 @@ - Other events that are actionable are networking bridges going down, ip tables being flushed on compute nodes and consequential loss of access to instances resulting in unhappy customers.  + Other events that are actionable are networking bridges going down, ip tables being flushed on compute nodes and consequential loss of access to instances resulting in unhappy customers. - To reduce security risks from orphan instances on a user/tenant/domain deletion in the Identity service there is discussion to generate notifications in the system and have OpenStack components respond to these events as appropriate such as terminating instances, disconnecting attached volumes, reclaiming CPU and storage resources etc.  + To reduce security risks from orphan instances on a user/tenant/domain deletion in the Identity service there is discussion to generate notifications in the system and have OpenStack components respond to these events as appropriate such as terminating instances, disconnecting attached volumes, reclaiming CPU and storage resources etc. A cloud will host many virtual instances, and monitoring these instances goes beyond hardware monitoring and log files which may just contain CRUD events. diff --git a/doc/security-guide/ch061_compliance-overview.xml b/doc/security-guide/ch061_compliance-overview.xml index fe15cb4f72..5d9ac7c7fb 100644 --- a/doc/security-guide/ch061_compliance-overview.xml +++ b/doc/security-guide/ch061_compliance-overview.xml @@ -1,7 +1,7 @@ Compliance Overview - An OpenStack deployment may require compliance activities for many purposes, such as regulatory and legal requirements, customer need, privacy considerations, and security best practices. Compliance, when done correctly, unifies and strengthens the other security topics discussed in this guide. This chapter has several objectives: + An OpenStack deployment may require compliance activities for many purposes, such as regulatory and legal requirements, customer need, privacy considerations, and security best practices. Compliance, when done correctly, unifies and strengthens the other security topics discussed in this guide. This chapter has several objectives: Review common security principles. @@ -25,7 +25,7 @@ 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.  + 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. diff --git a/doc/security-guide/ch062_audit-guidance.xml b/doc/security-guide/ch062_audit-guidance.xml index ae26df52ce..cd12e3991a 100644 --- a/doc/security-guide/ch062_audit-guidance.xml +++ b/doc/security-guide/ch062_audit-guidance.xml @@ -6,7 +6,7 @@ Implementation and Operation of Security ControlsAligning 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 conduct gap analysis, provide guidance, and increase the likelihood of successful certification. - Independent Verification and ValidationDemonstration to a neutral third-party that system security controls are implemented and operating effectively, in compliance with in-scope standards and regulations, is required before many information systems achieve certified status. Many certifications require periodic audits to ensure continued certification, considered part of an overarching continuous monitoring practice.   + Independent Verification and ValidationDemonstration to a neutral third-party that system security controls are implemented and operating effectively, in compliance with in-scope standards and regulations, is required before many information systems achieve certified status. Many certifications require periodic audits to ensure continued certification, considered part of an overarching continuous monitoring practice.
@@ -41,10 +41,10 @@
External Audit - 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. + 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.
Compliance Maintenance - The process doesn't end with a single external audit. Most certifications require continual compliance activities which means repeating the audit process periodically.  We recommend integrating automated compliance verification tools into a cloud to ensure that it is compliant at all times. This should be in done in addition to other security monitoring tools. Remember that the goal is both security and compliance. Failing on either of these fronts will significantly complicate future audits. + The process doesn't end with a single external audit. Most certifications require continual compliance activities which means repeating the audit process periodically. We recommend integrating automated compliance verification tools into a cloud to ensure that it is compliant at all times. This should be in done in addition to other security monitoring tools. Remember that the goal is both security and compliance. Failing on either of these fronts will significantly complicate future audits.
diff --git a/doc/security-guide/ch064_certifications-compliance-statements.xml b/doc/security-guide/ch064_certifications-compliance-statements.xml index c76dc272c0..7cf77d724e 100644 --- a/doc/security-guide/ch064_certifications-compliance-statements.xml +++ b/doc/security-guide/ch064_certifications-compliance-statements.xml @@ -28,7 +28,7 @@ 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.  + certifications.
SOC 1 (SSAE 16) / ISAE 3402 @@ -130,7 +130,7 @@ 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 + 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. @@ -149,14 +149,14 @@ unauthorized persons and that encryption for data 'at-rest' and 'inflight' should be addressed. HIPAA is not a certification, rather a guide for protecting - healthcare data.  Similar to the PCI-DSS, the most important + 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, does 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 + 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 reputation impact. @@ -192,14 +192,14 @@ 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.   + transactions. 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 + guidelines of the PCI-DSS. Segmentation in the context of PCI-DSS does not support multi-tenancy, but rather physical - separation (host/network).  + separation (host/network). For more details see PCI security standards. diff --git a/doc/user-guide-admin/section_cli_nova_manage_flavors.xml b/doc/user-guide-admin/section_cli_nova_manage_flavors.xml index 7e7470aba6..407a889cb0 100644 --- a/doc/user-guide-admin/section_cli_nova_manage_flavors.xml +++ b/doc/user-guide-admin/section_cli_nova_manage_flavors.xml @@ -111,7 +111,7 @@ To create a flavor, specify a name, ID, RAM size, disk size, and the number of VCPUs for the flavor, as follows: - $ nova flavor-create FLAVOR_NAME FLAVOR_ID RAM_IN_MB ROOT_DISK_IN_GB NUMBER_OF_VCPUS + $ nova flavor-create FLAVOR_NAME FLAVOR_ID RAM_IN_MB ROOT_DISK_IN_GB NUMBER_OF_VCPUS The flavor ID is a number from 1 to 255 and cannot contain special characters or