General readability improvements
* Expand 'Univ' to 'University' for correctness. * Remove scattered instances of double-spacing between sentences so that guide is consistent. * Use '—' instead of '-' to improve appearance of list items. * Adjust preposition placements to improve grammar. * Add an xref instead of advising reader to "read below" so that we do a better job of guiding the reader through the document. * Remove stray, empty <emphasis> items to clean up code. * Remove unnecessary hyphens to improve grammar correctness. * Other minor grammar improvements. Change-Id: I0dffd2e05cf89e4a9421512cb4e24a2ee242e21d
This commit is contained in:
Scott Radvan
parent
96b72db1a8
commit
d782c62427
@ -25,7 +25,7 @@
|
||||
<section xml:id="ch002_why-and-how-we-wrote-this-book-idp123024">
|
||||
<title>How</title>
|
||||
<para>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.</para>
|
||||
<para>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.</para>
|
||||
<para>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.</para>
|
||||
<para><inlinemediaobject><imageobject role="html">
|
||||
<imagedata contentdepth="450" contentwidth="540" fileref="static/group.png" format="PNG" scalefit="1"/>
|
||||
</imageobject>
|
||||
@ -53,7 +53,7 @@
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis role="bold">Malini Bhandaru</emphasis>, Intel</para>
|
||||
<para>Malini Bhandaru is a security architect at Intel. She has a varied background, having worked on platform power and performance at Intel, speech products at Nuance, remote monitoring and management at ComBrio, and web commerce at Verizon. She has a Ph.D. in Artificial Intelligence from Univ of Massachusetts, Amherst.</para>
|
||||
<para>Malini Bhandaru is a security architect at Intel. She has a varied background, having worked on platform power and performance at Intel, speech products at Nuance, remote monitoring and management at ComBrio, and web commerce at Verizon. She has a Ph.D. in Artificial Intelligence from the University of Massachusetts, Amherst.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis role="bold">Gregg Tally</emphasis>, Johns Hopkins University Applied Physics Laboratory</para>
|
||||
@ -61,7 +61,7 @@
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis role="bold">Eric Lopez</emphasis>, Nicira / VMware</para>
|
||||
<para>Eric Lopez is Senior Solution Architect at VMware's Networking and Security Business Unit where he helps customer implement OpenStack and Nicira's Network Virtualization Platform. Prior to joining Nicira, he worked for Q1 Labs, Symantec, Vontu, and Brightmail. He has a B.S in Electrical Engineering/Computer Science and Nuclear Engineering from U.C. Berkeley and MBA from University of San Francisco.</para>
|
||||
<para>Eric Lopez is Senior Solution Architect at VMware's Networking and Security Business Unit where he helps customer implement OpenStack and Nicira's Network Virtualization Platform. Prior to joining Nicira, he worked for Q1 Labs, Symantec, Vontu, and Brightmail. He has a B.S in Electrical Engineering/Computer Science and Nuclear Engineering from U.C. Berkeley and MBA from the University of San Francisco.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis role="bold">Shawn Wells</emphasis>, Red Hat</para>
|
||||
|
||||
@ -3,7 +3,7 @@
|
||||
<title>Introduction to OpenStack</title>
|
||||
<para>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
|
||||
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
|
||||
@ -49,7 +49,7 @@
|
||||
</section>
|
||||
<section xml:id="ch004_book-introduction-idp125312">
|
||||
<title>Hybrid Cloud</title>
|
||||
<para>A hybrid cloud is defined by NIST as a composition of two or more distinct cloud infrastructures (private, community, or public) that remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load balancing between clouds). For example an online retailer may have their advertising and catalogue presented on a public cloud that allows for elastic provisioning. This would enable them to handle seasonal loads in a flexible, cost-effective fashion. Once a customer begins to process their order, they are transferred to the more secure private cloud backend that is PCI compliant.</para>
|
||||
<para>A hybrid cloud is defined by NIST as a composition of two or more distinct cloud infrastructures (private, community, or public) that remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load balancing between clouds). For example an online retailer may have their advertising and catalogue presented on a public cloud that allows for elastic provisioning. This would enable them to handle seasonal loads in a flexible, cost-effective fashion. Once a customer begins to process their order, they are transferred to the more secure private cloud backend that is PCI compliant.</para>
|
||||
<para>For the purposes of this document, we treat Community
|
||||
and Hybrid similarly, dealing explicitly only with the
|
||||
extremes of Public and Private clouds from a security
|
||||
@ -81,7 +81,7 @@
|
||||
</section>
|
||||
<section xml:id="ch004_book-introduction-idp138800">
|
||||
<title>OpenStack Object Storage</title>
|
||||
<para>OpenStack object storage service (Swift), provides support for storing and retrieving arbitrary data in the cloud. Swift provides both a native API and an Amazon Web Services S3 compatible API. The service provides a high degree of resiliency through data replication and can handle petabytes of data.</para>
|
||||
<para>OpenStack object storage service (Swift) provides support for storing and retrieving arbitrary data in the cloud. Swift provides both a native API and an Amazon Web Services S3 compatible API. The service provides a high degree of resiliency through data replication and can handle petabytes of data.</para>
|
||||
<para>It is important to understand that object storage differs from traditional file system storage. It is best used for static data such as media files (MP3s, images, videos), virtual machine images, and backup files.</para>
|
||||
<para>Object security should focus on access control and encryption of data in transit and at rest. Other concerns may relate to system abuse, illegal or malicious content storage, and cross authentication attack vectors.</para>
|
||||
</section>
|
||||
@ -96,7 +96,7 @@
|
||||
</section>
|
||||
<section xml:id="ch004_book-introduction-idp143424">
|
||||
<title>OpenStack Networking</title>
|
||||
<para>The OpenStack networking service (Neutron, previously called Quantum), provides various networking services to cloud users (tenants) such as IP address management, <glossterm>DNS</glossterm>, <glossterm>DHCP</glossterm>, load balancing, and security groups (network access rules, like firewall policies). It provides a framework for software defined networking (SDN) that allows for pluggable integration with various networking solutions.</para>
|
||||
<para>The OpenStack networking service (Neutron, previously called Quantum) provides various networking services to cloud users (tenants) such as IP address management, <glossterm>DNS</glossterm>, <glossterm>DHCP</glossterm>, load balancing, and security groups (network access rules, like firewall policies). It provides a framework for software defined networking (SDN) that allows for pluggable integration with various networking solutions.</para>
|
||||
<para>OpenStack Networking allows cloud tenants to manage their guest network configurations. Security concerns with the networking service include network traffic isolation, availability, integrity and confidentiality.</para>
|
||||
</section>
|
||||
<section xml:id="ch004_book-introduction-idp145600">
|
||||
@ -105,18 +105,18 @@
|
||||
</section>
|
||||
<section xml:id="ch004_book-introduction-idp147104">
|
||||
<title>Identity Management</title>
|
||||
<para>The identity management service (Keystone), is a <emphasis role="bold">shared service</emphasis> that provides authentication and authorization services throughout the entire cloud infrastructure. Keystone has pluggable support for multiple forms of authentication.</para>
|
||||
<para>The identity management service (Keystone) is a <emphasis role="bold">shared service</emphasis> that provides authentication and authorization services throughout the entire cloud infrastructure. Keystone has pluggable support for multiple forms of authentication.</para>
|
||||
<para>Security concerns here pertain to trust in authentication, management of authorization tokens, and secure communication.</para>
|
||||
</section>
|
||||
<section xml:id="ch004_book-introduction-idp149712">
|
||||
<title>Image Service</title>
|
||||
<para>The OpenStack image service (Glance), <emphasis role="bold"> </emphasis>provides disk image management services. Glance provides image discovery, registration, and delivery services to Nova, the compute service, as needed.</para>
|
||||
<para>Trusted processes for managing the life cycle of disk images are required. As are all the previously mentioned issues with respect to data security. </para>
|
||||
<para>The OpenStack image service (Glance) provides disk image management services. Glance provides image discovery, registration, and delivery services to Nova, the compute service, as needed.</para>
|
||||
<para>Trusted processes for managing the life cycle of disk images are required, as are all the previously mentioned issues with respect to data security.</para>
|
||||
</section>
|
||||
<section xml:id="ch004_book-introduction-idp152400">
|
||||
<title>Other Supporting Technology</title>
|
||||
<para>OpenStack relies on messaging for internal communication between several of its services. By default, OpenStack uses message queues based on the Advanced Message Queue Protocol (<glossterm>AMQP</glossterm>). Similar to most OpenStack services, it supports pluggable components. Today the implementation backend could be <glossterm>RabbitMQ</glossterm>, <glossterm>Qpid</glossterm>, or <glossterm>ZeroMQ</glossterm>.</para>
|
||||
<para>As most management commands flow through the message queueing system, it is a primary security concern for any OpenStack deployment. Message queueing security is discussed in detail later in this guide.</para>
|
||||
<para>OpenStack relies on messaging for internal communication between several of its services. By default, OpenStack uses message queues based on the Advanced Message Queue Protocol (<glossterm>AMQP</glossterm>). Similar to most OpenStack services, it supports pluggable components. Today the implementation backend could be <glossterm>RabbitMQ</glossterm>, <glossterm>Qpid</glossterm>, or <glossterm>ZeroMQ</glossterm>.</para>
|
||||
<para>As most management commands flow through the message queueing system, it is a primary security concern for any OpenStack deployment. Message queueing security is discussed in detail later in this guide.</para>
|
||||
<para>Several of the components use databases though it is not explicitly called out. Securing the access to the databases and their contents is yet another security concern, and consequently discussed in more detail later in this guide.</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<chapter xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://docbook.org/ns/docbook" xmlns:db="http://docbook.org/ns/docbook" version="5.0" xml:id="ch005_security-domains"><?dbhtml stop-chunking?>
|
||||
<title>Security Boundaries and Threats</title>
|
||||
<para>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.</para>
|
||||
<para>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.</para>
|
||||
<section xml:id="ch005_security-domains-idp39040">
|
||||
<title>Security Domains</title>
|
||||
<para>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.</para>
|
||||
@ -29,8 +29,8 @@
|
||||
</inlinemediaobject></para>
|
||||
<section xml:id="ch005_security-domains-idp50384">
|
||||
<title>Public</title>
|
||||
<para>The public security domain is an entirely untrusted area of the cloud infrastructure. It can refer to the Internet as a whole or simply to networks that you have no authority over. Any data that transits this domain with confidentiality or integrity requirements should be protected using compensating controls.</para>
|
||||
<para>This should always be considered <emphasis>untrusted</emphasis>.</para>
|
||||
<para>The public security domain is an entirely untrusted area of the cloud infrastructure. It can refer to the Internet as a whole or simply to networks over which you have no authority. Any data that transits this domain with confidentiality or integrity requirements should be protected using compensating controls.</para>
|
||||
<para>This domain should always be considered <emphasis>untrusted</emphasis>.</para>
|
||||
</section>
|
||||
<section xml:id="ch005_security-domains-idp52768">
|
||||
<title>Guest</title>
|
||||
@ -39,18 +39,18 @@
|
||||
</section>
|
||||
<section xml:id="ch005_security-domains-idp55632">
|
||||
<title>Management</title>
|
||||
<para>The management security domain is where services interact. Sometimes referred to as the "control plane" the networks in this domain transport confidential data such as configuration parameters, usernames, and passwords. Command and Control traffic typically resides in this domain, which necessitates strong integrity requirements. Access to this domain should be highly restricted and monitored. At the same time, this domain should still employ all of the security best practices described in this guide.</para>
|
||||
<para>In most deployments this domain is considered <emphasis>trusted</emphasis>. However, when considering an OpenStack deployment, there are many systems that bridge this domain with others potentially reducing the level of trust you can place on this domain. See the section on 'Bridging Security Domains' below for more information.</para>
|
||||
<para>The management security domain is where services interact. Sometimes referred to as the "control plane", the networks in this domain transport confidential data such as configuration parameters, usernames, and passwords. Command and Control traffic typically resides in this domain, which necessitates strong integrity requirements. Access to this domain should be highly restricted and monitored. At the same time, this domain should still employ all of the security best practices described in this guide.</para>
|
||||
<para>In most deployments this domain is considered <emphasis>trusted</emphasis>. However, when considering an OpenStack deployment, there are many systems that bridge this domain with others, potentially reducing the level of trust you can place on this domain. See <xref linkend="ch005_security-domains-idp61360" /> for more information.</para>
|
||||
</section>
|
||||
<section xml:id="ch005_security-domains-idp59216">
|
||||
<title>Data</title>
|
||||
<para>The data security domain is concerned primarily with information pertaining to the storage services within OpenStack. Much of the data that crosses this network has high integrity and confidentiality requirements and depending on deployment-type there may be also be strong availability requirements.</para>
|
||||
<para>The data security domain is concerned primarily with information pertaining to the storage services within OpenStack. Much of the data that crosses this network has high integrity and confidentiality requirements and depending on the type of deployment there may also be strong availability requirements.</para>
|
||||
<para>The trust level of this network is heavily dependent on deployment decisions and as such we do not assign this any default level of trust.</para>
|
||||
</section>
|
||||
</section>
|
||||
<section xml:id="ch005_security-domains-idp61360">
|
||||
<title>Bridging Security Domains</title>
|
||||
<para>A <emphasis>bridge</emphasis> is a component that exists inside more than one security domain. Any component that bridges security domains with different trust levels or authentication requirements must be carefully configured. These bridges are often the weak-points in network architecture. A bridge should always be configured to meet the security requirements of the highest trust level of any of the domains it is bridging. In many cases the security controls for bridges should be a primary concern due to likelihood of attack.</para>
|
||||
<para>A <emphasis>bridge</emphasis> is a component that exists inside more than one security domain. Any component that bridges security domains with different trust levels or authentication requirements must be carefully configured. These bridges are often the weak points in network architecture. A bridge should always be configured to meet the security requirements of the highest trust level of any of the domains it is bridging. In many cases the security controls for bridges should be a primary concern due to the likelihood of attack.</para>
|
||||
<para><inlinemediaobject><imageobject role="html">
|
||||
<imagedata contentdepth="266" contentwidth="222" fileref="static/bridging_security_domains_1.png" format="PNG" scalefit="1"/>
|
||||
</imageobject>
|
||||
@ -66,7 +66,7 @@
|
||||
<imagedata contentdepth="100%" fileref="static/bridging_domains_clouduser.png" format="PNG" scalefit="1" width="100%"/>
|
||||
</imageobject>
|
||||
</inlinemediaobject></para>
|
||||
<para>In some cases deployers may want to consider securing a bridge to a higher standard than any of the domains it resides within. Given the example above of an API endpoint, an adversary could potentially target the API endpoint from the public domain, leveraging it in the hopes of compromising or gaining access to the management domain.</para>
|
||||
<para>In some cases deployers may want to consider securing a bridge to a higher standard than any of the domains in which it resides. Given the above example of an API endpoint, an adversary could potentially target the API endpoint from the public domain, leveraging it in the hopes of compromising or gaining access to the management domain.</para>
|
||||
<para>The design of OpenStack is such that separation of security domains is difficult - as core services will usually bridge at least two domains, special consideration must be given when applying security controls to them.</para>
|
||||
</section>
|
||||
<section xml:id="ch005_security-domains-idp95264">
|
||||
@ -74,21 +74,21 @@
|
||||
<para>Most types of cloud deployment, public or private, are exposed to some form of attack. In this chapter we categorize attackers and summarize potential types of attacks in each security domain.</para>
|
||||
<section xml:id="ch005_security-domains-idp96560">
|
||||
<title>Threat Actors</title>
|
||||
<para>A threat actor is an abstract way to refer to a class of adversary that you may attempt to defend against. The more capable the actor the more expensive the security controls that are required for successful attack mitigation and prevention. Security is a tradeoff between cost, usability and defense. In some cases it will not be possible to secure a cloud deployment against all of the threat actors we describe here. Those deploying an OpenStack cloud will have to decide where the balance is for their deployment / usage.</para>
|
||||
<para>A threat actor is an abstract way to refer to a class of adversary that you may attempt to defend against. The more capable the actor, the more expensive the security controls that are required for successful attack mitigation and prevention. Security is a tradeoff between cost, usability and defense. In some cases it will not be possible to secure a cloud deployment against all of the threat actors we describe here. Those deploying an OpenStack cloud will have to decide where the balance lies for their deployment / usage.</para>
|
||||
<itemizedlist><listitem>
|
||||
<para><emphasis role="bold">Intelligence Services</emphasis> - The most capable adversary considered in this guide. Intelligence Services and other state actors can bring tremendous resources to bear on a target. They have capabilities beyond that of any other actor. It is very difficult to defend against these actors without incredibly stringent controls in place, both human and technical.</para>
|
||||
<para><emphasis role="bold">Intelligence Services</emphasis> — Considered by this guide as the most capable adversary. Intelligence Services and other state actors can bring tremendous resources to bear on a target. They have capabilities beyond that of any other actor. It is very difficult to defend against these actors without incredibly stringent controls in place, both human and technical.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis role="bold">Serious Organized Crime</emphasis> - Highly capable, financially driven, groups of attackers. Able to fund in-house exploit development and target research. In recent years the rise of organizations such as the Russian Business Network, a massive cyber-criminal enterprise have demonstrated how cyber-attacks have become a commodity. Industrial espionage falls within the SOC group.</para>
|
||||
<para><emphasis role="bold">Serious Organized Crime</emphasis> — Highly capable and financially driven groups of attackers. Able to fund in-house exploit development and target research. In recent years the rise of organizations such as the Russian Business Network, a massive cyber-criminal enterprise has demonstrated how cyber attacks have become a commodity. Industrial espionage falls within the SOC group.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis role="bold">Highly Capable Groups</emphasis> - This refers to 'Hacktivist' type organizations who are not typically commercially funded but can pose a serious threat to service providers and cloud operators.</para>
|
||||
<para><emphasis role="bold">Highly Capable Groups</emphasis> — This refers to 'Hacktivist' type organizations who are not typically commercially funded but can pose a serious threat to service providers and cloud operators.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis role="bold">Motivated Individuals</emphasis> - Acting alone, these attackers come in many guises, rogue or malicious employees, disaffected customers, small-scale industrial espionage.</para>
|
||||
<para><emphasis role="bold">Motivated Individuals</emphasis> — Acting alone, these attackers come in many guises, such as rogue or malicious employees, disaffected customers, or small-scale industrial espionage.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis role="bold">Script Kiddies</emphasis> - Automated vulnerability scanning/exploitation. Non-targeted attacks. Often only a nuisance, compromise by one of these actors presents a major risk to an organizations reputation.</para>
|
||||
<para><emphasis role="bold">Script Kiddies</emphasis> — Automated vulnerability scanning/exploitation. Non-targeted attacks. Often only a nuisance, compromise by one of these actors presents a major risk to an organization's reputation.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para><inlinemediaobject><imageobject role="html">
|
||||
@ -103,7 +103,7 @@
|
||||
<title>Public / Private Considerations</title>
|
||||
<para>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 <emphasis>untrusted</emphasis> state for public cloud providers.</para>
|
||||
<para>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.</para>
|
||||
<para>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.</para>
|
||||
<para>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.</para>
|
||||
</section>
|
||||
<section xml:id="ch005_security-domains-idp116736">
|
||||
<title>Outbound attacks and reputational risk</title>
|
||||
@ -119,7 +119,7 @@
|
||||
<imagedata contentdepth="100%" fileref="static/high-capability.png" format="PNG" scalefit="1" width="100%"/>
|
||||
</imageobject>
|
||||
</inlinemediaobject></para>
|
||||
<para>The prescriptive defense for each form of attack is beyond the scope of this document. The above diagram can assist you in making an informed decision about which types of threats, and threat actors, should be protected against. For commercial public cloud deployments this might include prevention against serious crime. For those deploying private clouds for government use, more stringent protective mechanisms should be in place, including carefully protected facilities and supply chains etc. In contrast those standing up basic development or test environments will likely require less restrictive controls (middle of the spectrum).</para>
|
||||
<para>The prescriptive defense for each form of attack is beyond the scope of this document. The above diagram can assist you in making an informed decision about which types of threats, and threat actors, should be protected against. For commercial public cloud deployments this might include prevention against serious crime. For those deploying private clouds for government use, more stringent protective mechanisms should be in place, including carefully protected facilities and supply chains. In contrast those standing up basic development or test environments will likely require less restrictive controls (middle of the spectrum).</para>
|
||||
</section>
|
||||
</section>
|
||||
</chapter>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user