6bf4dedafc
Change all titles to sentence style capitalization (some were already, majority not) Adjust project and service name spelling. Minor edits Fix links to TPM section Change-Id: Ic8cc709b068d2273762f074daa5ac30ebe9aaf20 Partial-Bug: #1217503
325 lines
16 KiB
XML
325 lines
16 KiB
XML
<?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"
|
|
version="5.0"
|
|
xml:id="ch012_configuration-management">
|
|
<?dbhtml stop-chunking?>
|
|
<title>Continuous systems management</title>
|
|
<para>A cloud will always have bugs. Some of these will be security
|
|
problems. For this reason, it is critically important to be
|
|
prepared to apply security updates and general software updates.
|
|
This involves smart use of configuration management tools, which
|
|
are discussed below. This also involves knowing when an upgrade is
|
|
necessary.</para>
|
|
<section xml:id="ch012_configuration-management-idp44720">
|
|
<title>Vulnerability management</title>
|
|
<para>For announcements regarding security relevant changes,
|
|
subscribe to the <link
|
|
xlink:href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce"
|
|
>OpenStack Announce mailing list</link>. The security
|
|
notifications are also posted through the downstream packages
|
|
for example through Linux distributions that you may be
|
|
subscribed to as part of the package updates.</para>
|
|
<para>The OpenStack components are only a small fraction of the
|
|
software in a cloud. It is important to keep up to date with all
|
|
of these other components, too. While the specific data sources
|
|
will be deployment specific, the key idea is to ensure that a
|
|
cloud administrator subscribes to the necessary mailing lists
|
|
for receiving notification of any related security updates.
|
|
Often this is as simple as tracking an upstream Linux
|
|
distribution.</para>
|
|
<note>
|
|
<para>OpenStack releases security information through two
|
|
channels. <itemizedlist>
|
|
<listitem>
|
|
<para>OpenStack Security Advisories (OSSA) are created by
|
|
the OpenStack Vulnerability Management Team (VMT). They
|
|
pertain to security holes in core OpenStack services.
|
|
More information on the VMT can be found here: <link
|
|
xlink:href="https://wiki.openstack.org/wiki/Vulnerability_Management"
|
|
>https://wiki.openstack.org/wiki/Vulnerability_Management</link></para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>OpenStack Security Notes (OSSN) were created by the
|
|
OpenStack Security Group (OSSG) to support the work of
|
|
the VMT. OSSN address issues in supporting software and
|
|
common deployment configurations. They're referenced
|
|
throughout this guide. Security Notes are archived at
|
|
<link xlink:href="https://launchpad.net/ossn/"
|
|
>https://launchpad.net/ossn/</link></para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
</note>
|
|
<section xml:id="ch012_configuration-management-idp48592">
|
|
<title>Triage</title>
|
|
<para>After you are notified of a security update, the next step
|
|
is to determine how critical this update is to a given cloud
|
|
deployment. In this case, it is useful to have a pre-defined
|
|
policy. Existing vulnerability rating systems such as the
|
|
common vulnerability scoring system (CVSS) v2 do not properly
|
|
account for cloud deployments.</para>
|
|
<para>In this example we introduce a scoring matrix that places
|
|
vulnerabilities in three categories: Privilege Escalation,
|
|
Denial of Service and Information Disclosure. Understanding
|
|
the type of vulnerability and where it occurs in your
|
|
infrastructure will enable you to make reasoned response
|
|
decisions.</para>
|
|
<para>Privilege Escalation describes the ability of a user to
|
|
act with the privileges of some other user in a system,
|
|
bypassing appropriate authorization checks. For example, a
|
|
standard Linux user running code or performing an operation
|
|
that allows them to conduct further operations with the
|
|
privileges of the root users on the system.</para>
|
|
<para>Denial of Service refers to an exploited vulnerability
|
|
that may cause service or system disruption. This includes
|
|
both distributed attacks to overwhelm network resources, and
|
|
single-user attacks that are typically caused through resource
|
|
allocation bugs or input induced system failure flaws.</para>
|
|
<para>Information Disclosure vulnerabilities reveal information
|
|
about your system or operations. These vulnerabilities range
|
|
from debugging information disclosure, to exposure of critical
|
|
security data, such as authentication credentials and
|
|
passwords.</para>
|
|
<informaltable rules="all" width="80%">
|
|
<colgroup>
|
|
<col/>
|
|
<col/>
|
|
<col/>
|
|
<col/>
|
|
<col/>
|
|
</colgroup>
|
|
<tbody>
|
|
<tr>
|
|
<td><para> </para></td>
|
|
<td colspan="4"><para><emphasis>Attacker Position /
|
|
Privilege Level</emphasis></para></td>
|
|
</tr>
|
|
<tr>
|
|
<td><para><emphasis role="bold"> </emphasis></para></td>
|
|
<td><para><emphasis role="bold"
|
|
>External</emphasis></para></td>
|
|
<td><para><emphasis role="bold">Cloud
|
|
User</emphasis></para></td>
|
|
<td><para><emphasis role="bold">Cloud
|
|
Admin</emphasis></para></td>
|
|
<td><para><emphasis role="bold">Control
|
|
Plane</emphasis></para></td>
|
|
</tr>
|
|
<tr>
|
|
<td><para><emphasis role="bold">Privilege Elevation (3
|
|
levels)</emphasis></para></td>
|
|
<td><para>Critical</para></td>
|
|
<td><para>n/a</para></td>
|
|
<td><para>n/a</para></td>
|
|
<td><para>n/a</para></td>
|
|
</tr>
|
|
<tr>
|
|
<td><para><emphasis role="bold">Privilege Elevation (2
|
|
levels)</emphasis></para></td>
|
|
<td><para>Critical</para></td>
|
|
<td><para>Critical</para></td>
|
|
<td><para>n/a</para></td>
|
|
<td><para>n/a</para></td>
|
|
</tr>
|
|
<tr>
|
|
<td><para><emphasis role="bold">Privilege Elevation (1
|
|
level)</emphasis></para></td>
|
|
<td><para>Critical</para></td>
|
|
<td><para>Critical</para></td>
|
|
<td><para>Critical</para></td>
|
|
<td><para>n/a</para></td>
|
|
</tr>
|
|
<tr>
|
|
<td><para><emphasis role="bold">Denial of
|
|
Service</emphasis></para></td>
|
|
<td><para>High</para></td>
|
|
<td><para>Medium</para></td>
|
|
<td><para>Low</para></td>
|
|
<td><para>Low</para></td>
|
|
</tr>
|
|
<tr>
|
|
<td><para><emphasis role="bold">Information
|
|
Disclosure</emphasis></para></td>
|
|
<td><para>Critical / High</para></td>
|
|
<td><para>Critical / High</para></td>
|
|
<td><para>Medium / Low</para></td>
|
|
<td><para>Low</para></td>
|
|
</tr>
|
|
</tbody>
|
|
</informaltable>
|
|
<para>This table illustrates a generic approach to
|
|
measuring the impact of a vulnerability based on where it
|
|
occurs in your deployment and the effect. For example, a
|
|
single level privilege escalation on a Compute API node
|
|
potentially allows a standard user of the API to escalate to
|
|
have the same privileges as the root user on the node.</para>
|
|
<para>We suggest that cloud administrators use this table as a
|
|
model to help define which actions to take for the various
|
|
security levels. For example, a critical-level security update
|
|
might require the cloud to be upgraded on a specified time
|
|
line, whereas a low-level update might be more relaxed.</para>
|
|
</section>
|
|
<section xml:id="ch012_configuration-management-idp100864">
|
|
<title>Testing the updates</title>
|
|
<para>You should test any update before you deploy it in a
|
|
production environment. Typically this requires having a
|
|
separate test cloud setup that first receives the update. This
|
|
cloud should be as close to the production cloud as possible,
|
|
in terms of software and hardware. Updates should be tested
|
|
thoroughly in terms of performance impact, stability,
|
|
application impact, and more. Especially important is to
|
|
verify that the problem theoretically addressed by the update,
|
|
such as a specific vulnerability, is actually fixed.</para>
|
|
</section>
|
|
<section xml:id="ch012_configuration-management-idp102976">
|
|
<title>Deploying the updates</title>
|
|
<para>Once the updates are fully tested, they can be deployed to
|
|
the production environment. This deployment should be fully
|
|
automated using the configuration management tools described
|
|
below.</para>
|
|
</section>
|
|
</section>
|
|
<section xml:id="ch012_configuration-management-idp104464">
|
|
<title>Configuration management</title>
|
|
<para>A production quality cloud should always use tools to
|
|
automate configuration and deployment. This eliminates human
|
|
error, and allows the cloud to scale much more rapidly.
|
|
Automation also helps with continuous integration and
|
|
testing.</para>
|
|
<para>When building an OpenStack cloud it is strongly recommended
|
|
to approach your design and implementation with a configuration
|
|
management tool or framework in mind. Configuration management
|
|
allows you to avoid the many pitfalls inherent in building,
|
|
managing, and maintaining an infrastructure as complex as
|
|
OpenStack. By producing the manifests, cookbooks, or templates
|
|
required for a configuration management utility, you are able to
|
|
satisfy a number of documentation and regulatory reporting
|
|
requirements. Further, configuration management can also
|
|
function as part of your BCP and DR plans wherein you can
|
|
rebuild a node or service back to a known state in a DR event or
|
|
given a compromise.</para>
|
|
<para>Additionally, when combined with a version control system
|
|
such as Git or SVN, you can track changes to your environment
|
|
over time and re-mediate unauthorized changes that may occur.
|
|
For example, a <filename>nova.conf</filename> file or other
|
|
configuration file falls out of compliance with your standard,
|
|
your configuration management tool can revert or replace the
|
|
file and bring your configuration back into a known state.
|
|
Finally a configuration management tool can also be used to
|
|
deploy updates; simplifying the security patch process. These
|
|
tools have a broad range of capabilities that are useful in this
|
|
space. The key point for securing your cloud is to choose a tool
|
|
for configuration management and use it.</para>
|
|
<para>There are many configuration management solutions; at the
|
|
time of this writing there are two in the marketplace that are
|
|
robust in their support of OpenStack environments:
|
|
<glossterm>Chef</glossterm> and <glossterm>Puppet</glossterm>.
|
|
A non-exhaustive listing of tools in this space is provided
|
|
below:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Chef</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Puppet</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Salt Stack</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Ansible</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<section xml:id="ch012_configuration-management-idp8400">
|
|
<title>Policy changes</title>
|
|
<para>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.</para>
|
|
</section>
|
|
</section>
|
|
<section xml:id="ch012_configuration-management-idp10160">
|
|
<title>Secure backup and recovery</title>
|
|
<para>It is important to include Backup procedures and policies in
|
|
the overall System Security Plan. For a good overview of
|
|
OpenStack's Backup and Recovery capabilities and procedures,
|
|
please refer to the OpenStack Operations Guide.</para>
|
|
<section xml:id="ch012_configuration-management-idp123104">
|
|
<title>Security considerations</title>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Ensure only authenticated users and backup clients
|
|
have access to the backup server.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Use data encryption options for storage and
|
|
transmission of backups.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Use a dedicated and hardened backup servers. The logs
|
|
for the backup server must be monitored daily and
|
|
accessible by only few individuals.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Test data recovery options regularly. One of the
|
|
things that can be restored from secured backups is the
|
|
images. In case of a compromise, the best practice would
|
|
be to terminate running instances immediately and then
|
|
relaunch the instances from the images in the secured
|
|
backup repository.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</section>
|
|
<section xml:id="ch012_configuration-management-idp128032">
|
|
<title>References</title>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><citetitle>OpenStack Operations Guide</citetitle> on
|
|
<link
|
|
xlink:href="http://docs.openstack.org/trunk/openstack-ops/content/backup_and_recovery.html"
|
|
>backup and recovery</link></para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><link
|
|
xlink:href="http://www.sans.org/reading_room/whitepapers/backup/security-considerations-enterprise-level-backups_515"
|
|
>http://www.sans.org/reading_room/whitepapers/backup/security-considerations-enterprise-level-backups_515</link></para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><link xlink:href="http://www.music-piracy.com/?p=494"
|
|
>OpenStack Security Primer</link></para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</section>
|
|
</section>
|
|
<section xml:id="ch012_configuration-management-idp131856">
|
|
<title>Security auditing tools</title>
|
|
<para>Security auditing tools can complement the configuration
|
|
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
|
|
documentation (for example, the STIG and NSA Guides) to a
|
|
specific system installation. For example, <link
|
|
xlink:href="https://fedorahosted.org/scap-security-guide/"
|
|
>SCAP</link> can compare a running system to a pre-defined
|
|
profile. SCAP outputs a report detailing which controls in the
|
|
profile were satisfied, which ones failed, and which ones were
|
|
not checked.</para>
|
|
<para>Combining configuration management and security auditing
|
|
tools creates a powerful combination. The auditing tools will
|
|
highlight deployment concerns. And the configuration management
|
|
tools simplify the process of changing each system to address
|
|
the audit concerns. Used together in this fashion, these tools
|
|
help to maintain a cloud that satisfies security requirements
|
|
ranging from basic hardening to compliance validation.</para>
|
|
<para>Configuration management and security auditing tools will
|
|
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
|
|
the scope of this guide.</para>
|
|
</section>
|
|
</chapter>
|