openstack/security-doc
Code Issues Proposed changes

Update Compliance section to RST

Browse Source 
Migrated Compliance section, added ref hook to case study intro.

Renamed following sections:

section_compliance-overview.xml to compliance/overview.rst
section_understanding-the-audit-process.xml to
compliance/understanding-the-audit-process.rst
section_compliance-activities.xml to
compliance/compliance-activities.rst
section_privacy.xml to compliance/privacy.rst
section_case-studies-compliance.xml to compliance/case-studies.rst

Change-Id: I5bb2c0f52bc875e470283b0f8c3bcb7542855a93
This commit is contained in:
Doug Chivers
2015-07-23 15:53:15 +01:00
parent 99b97c34d5
commit c4395b9a09
11 changed files with 758 additions and 30 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
security-guide-rst/source/compliance.rst
View File

@@ -23,3 +23,13 @@ This chapter has several objectives:
- Introduce privacy considerations specific to OpenStack and cloud
environments.
.. toctree::
:maxdepth: 2
compliance/overview.rst
compliance/understanding-the-audit-process.rst
compliance/compliance-activities.rst
compliance/certification-and-compliance-statements.rst
compliance/privacy.rst
compliance/case-studies.rst

82
security-guide-rst/source/compliance/case-studies.rst Normal file
View File

@@ -0,0 +1,82 @@
============
Case studies
============
Earlier in :doc:`../introduction/introduction-to-case-studies`
we introduced the Alice and Bob case studies where Alice is
deploying a private government cloud and Bob is deploying a public cloud
each with different security requirements. Here we discuss how Alice and
Bob would address common compliance requirements. The preceding chapter
refers to a wide variety of compliance certifications and standards.
Alice will address compliance in a private cloud, while Bob will be
focused on compliance for a public cloud.
Alice's private cloud
~~~~~~~~~~~~~~~~~~~~~
Alice is building an OpenStack private cloud for the United States
government, specifically to provide elastic compute environments for
signal processing. Alice has researched government compliance
requirements, and has identified that her private cloud will be required
to certify against FISMA and follow the FedRAMP accreditation process,
which is required for all federal agencies, departments and contractors
to become a Certified Cloud Provider (CCP). In this particular scenario
for signal processing, the FISMA controls required will most likely be
FISMA High, which indicates possible "severe or catastrophic adverse
effects" should the information system become compromised. In addition
to FISMA Moderate controls Alice must ensure her private cloud is
FedRAMP certified, as this is a requirement for all agencies that
currently utilize, or host federal information within a cloud
environment.
To meet these strict government regulations Alice undertakes a number of
activities. Scoping of requirements is particularly important due to the
volume of controls that must be implemented, which will be defined in
NIST Publication 800-53.
As the U.S. Department of Defense is involved, Security Technical
Implementation Guides (STIGs) will come into play, which are the
configuration standards for DOD IA and IA-enabled devices and systems.
Alice notices a number of complications here as there is no STIG for
OpenStack, so she must address several underlying requirements for each
OpenStack service; for example, the networking SRG and Application SRG
will both be applicable (list of SRGs). Other critical controls include
ensuring that all identities in the cloud use PKI, that SELinux is
enabled, that encryption exists for all wire-level communications, and
that continuous monitoring is in place and clearly documented. Alice is
not concerned with object encryption, as this will be the tenant's
responsibility rather than the provider.
If Alice has adequately scoped and executed these compliance activities,
she may begin the process to become FedRAMP compliant by hiring an
approved third-party auditor. Typically this process takes up to six
months, after which she will receive an Authority to Operate and can
offer OpenStack cloud services to the government.
Bob's public cloud
~~~~~~~~~~~~~~~~~~
Bob is tasked with compliance for a new OpenStack public cloud
deployment, that is focused on providing cloud services to both small
developers and startups, as well as large enterprises. Bob recognizes
that individual developers are not necessarily concerned with compliance
certifications, but to larger enterprises certifications are critical.
Specifically Bob desires to achieve SOC 1, SOC 2 Security, as well as
ISO 27001/2 as quickly as possible. Bob references the Cloud Security
Alliance Cloud Control Matrix (CCM) to assist in identifying common
controls across these three certifications (such as periodic access
reviews, auditable logging and monitoring services, risk assessment
activities, security reviews, etc). Bob then engages an experienced
audit team to conduct a gap analysis on the public cloud deployment,
reviews the results and fills any gaps identified. Bob works with other
team members to ensure that these security controls and activities are
regularly conducted for a typical audit period (~6-12 months).
At the end of the audit period Bob has arranged for an external audit
team to review in-scope security controls at randomly sampled points of
time over a 6 month period. The audit team provides Bob with an official
report for SOC 1 and SOC 2, and separately for ISO 27001/2. As Bob has
been diligent in ensuring security controls are in place for his
OpenStack public cloud, there are no additional gaps exposed on the
report. Bob can now provide these official reports to his customers
under NDA, and advertise that he is SOC 1, SOC 2 and ISO 27001/2
compliant on his website.

231
security-guide-rst/source/compliance/certification-and-compliance-statements.rst Normal file
View File

@@ -0,0 +1,231 @@
=======================================
Certification and compliance statements
=======================================
Compliance and security are not exclusive, and must be addressed
together. OpenStack deployments are unlikely to satisfy compliance
requirements without security hardening. The listing below provides an
OpenStack architect foundational knowledge and guidance to achieve
compliance against commercial and government certifications and
standards.
Commercial standards
~~~~~~~~~~~~~~~~~~~~
For commercial deployments of OpenStack, it is recommended that SOC 1/2
combined with ISO 2700 1/2 be considered as a starting point for
OpenStack certification activities. The required security activities
mandated by these certifications facilitate a foundation of security
best practices and common control criteria that can assist in achieving
more stringent compliance activities, including government attestations
and certifications.
After completing these initial certifications, the remaining
certifications are more deployment specific. For example, clouds
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.
SOC 1 (SSAE 16) / ISAE 3402
---------------------------
Service Organization Controls (SOC) criteria are defined by the
`American Institute of Certified Public
Accountants <http://www.aicpa.org/>`__ (AICPA). SOC controls assess
relevant financial statements and assertions of a service provider, such
as compliance with the Sarbanes-Oxley Act. SOC 1 is a replacement for
Statement on Auditing Standards No. 70 (SAS 70) Type II report. These
controls commonly include physical data centers in scope.
There are two types of SOC 1 reports:
- Type 1 - report on the fairness of the presentation of management's
description of the service organization's system and the suitability
of the design of the controls to achieve the related control
objectives included in the description as of a specified date.
- Type 2 - report on the fairness of the presentation of management's
description of the service organization's system and the suitability
of the design and operating effectiveness of the controls to achieve
the related control objectives included in the description throughout
a specified period
For more details see the `AICPA Report on Controls at a Service
Organization Relevant to User Entities' Internal Control over Financial
Reporting <http://www.aicpa.org/InterestAreas/FRC/AssuranceAdvisoryServices/Pages/AICPASOC1Report.aspx>`__.
SOC 2
-----
Service Organization Controls (SOC) 2 is a self attestation of controls
that affect the security, availability, and processing integrity of the
systems a service organization uses to process users' data and the
confidentiality and privacy of information processed by these system.
Examples of users are those responsible for governance of the service
organization; customers of the service organization; regulators;
business partners; suppliers and others who have an understanding of the
service organization and its controls.
There are two types of SOC 2 reports:
- Type 1 - report on the fairness of the presentation of management's
description of the service organization's system and the suitability
of the design of the controls to achieve the related control
objectives included in the description as of a specified date.
- Type 2 - report on the fairness of the presentation of management's
description of the service organization's system and the suitability
of the design and operating effectiveness of the controls to achieve
the related control objectives included in the description throughout
a specified period.
For more details see the `AICPA Report on Controls at a Service
Organization Relevant to Security, Availability, Processing Integrity,
Confidentiality or
Privacy <http://www.aicpa.org/InterestAreas/FRC/AssuranceAdvisoryServices/Pages/AICPASOC2Report.aspx>`__.
SOC 3
-----
Service Organization Controls (SOC) 3 is a trust services report for
service organizations. These reports are designed to meet the needs of
users who want assurance on the controls at a service organization
related to security, availability, processing integrity,
confidentiality, or privacy but do not have the need for or the
knowledge necessary to make effective use of a SOC 2 Report. These
reports are prepared using the AICPA/Canadian Institute of Chartered
Accountants (CICA) Trust Services Principles, Criteria, and
Illustrations for Security, Availability, Processing Integrity,
Confidentiality, and Privacy. Because they are general use reports, SOC
3 Reports can be freely distributed or posted on a website as a seal.
For more details see the `AICPA Trust Services Report for Service
Organizations <http://www.aicpa.org/InterestAreas/FRC/AssuranceAdvisoryServices/Pages/AICPASOC3Report.aspx>`__.
ISO 27001/2
-----------
The ISO/IEC 27001/2 standards replace BS7799-2, and are 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 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.
For more details see `ISO 27001 <http://www.27000.org/iso-27001.htm>`__.
HIPAA / HITECH
--------------
The Health Insurance Portability and Accountability Act (HIPAA) is a
United States congressional act that governs the collection, storage,
use and destruction of patient health records. The act states that
Protected Health Information (PHI) must be rendered "unusable,
unreadable, or indecipherable" to 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 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 compliant, the
cloud provider can expect on-site audit teams, fines, potential loss of
merchant ID (PCI), and massive reputation impact.
Users or organizations that possess PHI must support HIPAA requirements
and are HIPAA covered entities. If an entity intends to use a service,
or in this case, an OpenStack cloud that might use, store or have access
to that PHI, then a Business Associate Agreement must be signed. The BAA
is a contract between the HIPAA covered entity and the OpenStack service
provider that requires the provider to handle that PHI in accordance
with HIPAA requirements. If the service provider does not handle the
PHI, such as with security controls and hardening, then they are subject
to HIPAA fines and penalties.
OpenStack architects interpret and respond to HIPAA statements, with
data encryption remaining a core practice. Currently this would require
any protected health information contained within an OpenStack
deployment to be encrypted with industry standard encryption algorithms.
Potential future OpenStack projects such as object encryption will
facilitate HIPAA guidelines for compliance with the act.
For more details see the `Health Insurance Portability And
Accountability
Act <https://www.cms.gov/Regulations-and-Guidance/HIPAA-Administrative-Simplification/HIPAAGenInfo/downloads/HIPAALaw.pdf>`__.
PCI-DSS
-------
The Payment Card Industry Data Security Standard (PCI DSS) is defined by
the Payment Card Industry Standards Council, and created to increase
controls around card holder data to reduce credit card fraud. Annual
compliance validation is assessed by an external Qualified Security
Assessor (QSA) who creates a Report on Compliance (ROC), or by a
Self-Assessment Questionnaire (SAQ) dependent on volume of card-holder
transactions.
OpenStack deployments which stores, processes, or transmits payment card
details are in scope for the PCI-DSS. All OpenStack components that are
not properly segmented from systems or networks that handle payment data
fall under the guidelines of the PCI-DSS. Segmentation in the context of
PCI-DSS does not support multi-tenancy, but rather physical separation
(host/network).
For more details see `PCI security
standards <https://www.pcisecuritystandards.org/security_standards/>`__.
Government standards
~~~~~~~~~~~~~~~~~~~~
FedRAMP
-------
"The `Federal Risk and Authorization Management
Program <http://www.fedramp.gov>`__ (FedRAMP) is a government-wide
program that provides a standardized approach to security assessment,
authorization, and continuous monitoring for cloud products and
services". NIST 800-53 is the basis for both FISMA and FedRAMP which
mandates security controls specifically selected to provide protection
in cloud environments. FedRAMP can be extremely intensive from
specificity around security controls, and the volume of documentation
required to meet government standards.
For more details see http://www.gsa.gov/portal/category/102371.
ITAR
----
The International Traffic in Arms Regulations (ITAR) is a set of United
States government regulations that control the export and import of
defense-related articles and services on the United States Munitions
List (USML) and related technical data. ITAR is often approached by
cloud providers as an "operational alignment" rather than a formal
certification. This typically involves implementing a segregated cloud
environment following practices based on the NIST 800-53 framework, as
per FISMA requirements, complemented with additional controls
restricting access to "U.S. Persons" only and background screening.
For more details see
https://www.pmddtc.state.gov/regulations_laws/itar.html.
FISMA
-----
The Federal Information Security Management Act requires that government
agencies create a comprehensive plan to implement numerous government
security standards, and was enacted within the E-Government Act of 2002.
FISMA outlines a process, which utilizing multiple NIST publications,
prepares an information system to store and process government data.
This process is broken apart into three primary categories:
System categorization:
The information system will receive a security category as defined in
Federal Information Processing Standards Publication 199 (FIPS 199).
These categories reflect the potential impact of system compromise.
Control selection:
Based upon system security category as defined in FIPS 199, an
organization utilizes FIPS 200 to identify specific security control
requirements for the information system. For example, if a system is
categorized as "moderate" a requirement may be introduced to mandate
"secure passwords".
Control tailoring:
Once system security controls are identified, an OpenStack architect
will utilize NIST 800-53 to extract tailored control selection. For
example, specification of what constitutes a "secure password".

108
security-guide-rst/source/compliance/compliance-activities.rst Normal file
View File

@@ -0,0 +1,108 @@
=====================
Compliance Activities
=====================
There are a number of standard activities that will greatly assist with
the compliance process. In this chapter we outline some of the most
common compliance activities. These are not specific to OpenStack,
however we provide references to relevant sections in this book as
useful context.
Information Security Management system (ISMS)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
An Information Security Management System (ISMS) is a comprehensive set
of policies and processes that an organization creates and maintains to
manage risk to information assets. The most common ISMS for cloud
deployments is `ISO/IEC 27001/2 <http://www.27000.org/iso-27001.htm>`__,
which creates a solid foundation of security controls and practices for
achieving more stringent compliance certifications. This standard was
updated in 2013 to reflect the growing use of cloud services and places
more emphasis on measuring and evaluating how well an organization's
ISMS is performing.
Risk assessment
~~~~~~~~~~~~~~~
A risk assessment framework identifies risks within an organization or
service, and specifies ownership of these risks, along with
implementation and mitigation strategies. Risks apply to all areas of
the service, from technical controls to environmental disaster scenarios
and human elements, for example a malicious insider (or rogue employee).
Risks can be rated using a variety of mechanisms, for example likelihood
vs impact. An OpenStack deployment risk assessment can include control
gaps that are described in this book.
Access and log reviews
~~~~~~~~~~~~~~~~~~~~~~
Periodic access and log reviews are required to ensure authentication,
authorization, and accountability in a service deployment. Specific
guidance for OpenStack on these topics are discussed in-depth in the
logging section.
Backup and disaster recovery
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Disaster Recovery (DR) and Business Continuity Planning (BCP) plans are
common requirements for ISMS and compliance activities. These plans must
be periodically tested as well as documented. In OpenStack key areas are
found in the management security domain, and anywhere that single points
of failure (SPOFs) can be identified. See the section on secure backup
and recovery for additional details.
Security training
~~~~~~~~~~~~~~~~~
Annual, role-specific, security training is a mandatory requirement for
almost all compliance certifications and attestations. To optimize the
effectiveness of security training, a common method is to provide role
specific training, for example to developers, operational personnel, and
non-technical employees. Additional cloud security or OpenStack security
training based on this hardening guide would be ideal.
Security reviews
~~~~~~~~~~~~~~~~
As OpenStack is a popular open source project, much of the codebase and
architecture has been scrutinized by individual contributors,
organizations and enterprises. This can be advantageous from a security
perspective, however the need for security reviews is still a critical
consideration for service providers, as deployments vary, and security
is not always the primary concern for contributors. A comprehensive
security review process may include architectural review, threat
modelling, source code analysis and penetration testing. There are many
techniques and recommendations for conducting security reviews that can
be found publicly posted. A well-tested example is the `Microsoft
SDL <http://www.microsoft.com/security/sdl/process/release.aspx>`__,
created as part of the Microsoft Trustworthy Computing Initiative.
Vulnerability management
~~~~~~~~~~~~~~~~~~~~~~~~
Security updates are critical to any IaaS deployment, whether private or
public. Vulnerable systems expand attack surfaces, and are obvious
targets for attackers. Common scanning technologies and vulnerability
notification services can help mitigate this threat. It is important
that scans are authenticated and that mitigation strategies extend
beyond simple perimeter hardening. Multi-tenant architectures such as
OpenStack are particularly prone to hypervisor vulnerabilities, making
this a critical part of the system for vulnerability management. See the
section on instance isolation for additional details.
Data classification
~~~~~~~~~~~~~~~~~~~
Data Classification defines a method for classifying and handling
information, often to protect customer information from accidental or
deliberate theft, loss, or inappropriate disclosure. Most commonly this
involves classifying information as sensitive or non-sensitive, or as
personally identifiable information (PII). Depending on the context of
the deployment various other classifying criteria may be used
(government, health-care etc). The underlying principle is that data
classifications are clearly defined and in-use. The most common
protective mechanisms include industry standard encryption technologies.
See the data security section for additional details.
Exception process
~~~~~~~~~~~~~~~~~
An exception process is an important component of an ISMS. When certain
actions are not compliant with security policies that an organization
has defined, they must be logged. Appropriate justification, description
and mitigation details need to be included, and signed off by
appropriate authorities. OpenStack default configurations may vary in
meeting various compliance criteria, areas that fail to meet compliance
requirements should be logged, with potential fixes considered for
contribution to the community.

131
security-guide-rst/source/compliance/overview.rst Normal file
View File

@@ -0,0 +1,131 @@
===================
Compliance Overview
===================
Security principles
~~~~~~~~~~~~~~~~~~~
Industry standard security principles provide a baseline for compliance
certifications and attestations. If these principles are considered and
referenced throughout an OpenStack deployment, certification activities
may be simplified.
Layered defenses
----------------
Identify where risks exist in a cloud architecture and apply controls
to mitigate the risks. In areas of significant concern, layered
defences provide multiple complementary controls to manage risk down to
an acceptable level. For example, to ensure adequate isolation between
cloud tenants, we recommend hardening QEMU, using a hypervisor with
SELinux support, enforcing mandatory access control policies, and
reducing the overall attack surface. The foundational principle is to
harden an area of concern with multiple layers of defense such that if
any one layer is compromised, other layers will exist to offer
protection and minimize exposure.
Fail securely
-------------
In the case of failure, systems should be configured to fail into a
closed secure state. For example, TLS certificate verification should
fail closed by severing the network connection if the CNAME doesn't
match the server's DNS name. Software often fails open in this
situation, allowing the connection to proceed without a CNAME match,
which is less secure and not recommended.
Least privilege
---------------
Only the minimum level of access for users and system services is
granted. This access is based upon role, responsibility and job
function. This security principal of least privilege is written into
several international government security policies, such as NIST 800-53
Section AC-6 within the United States.
Compartmentalize
----------------
Systems should be segregated in a such way that if one machine, or
system-level service, is compromised the security of the other systems
will remain intact. Practically, the enablement and proper usage of
SELinux helps accomplish this goal.
Promote privacy
----------------
The amount of information that can be gathered about a system and its
users should be minimized.
Logging capability
------------------
Appropriate logging is implemented to monitor for unauthorized use,
incident response and forensics. It is highly recommended that selected
audit subsystems be Common Criteria certified, which provides
non-attestable event records in most countries.
Common control frameworks
~~~~~~~~~~~~~~~~~~~~~~~~~
The following is a list of Control Frameworks that an organization can
use to build their security controls.
`Cloud Security Alliance (CSA) Common Control Matrix
(CCM) <https://cloudsecurityalliance.org/media/news/csa-releases-new-ccm-caiq-v3-0-1/>`__
The CSA CCM is specifically designed to provide fundamental security
principles to guide cloud vendors and to assist prospective cloud
customers in assessing the overall security risk of a cloud provider.
The CSA CCM provides a controls framework that are aligned across 16
security domains. The foundation of the Cloud Controls Matrix rests on
its customized relationship to other industry standards, regulations,
and controls frameworks such as: ISO 27001:2013, COBIT 5.0, PCI:DSS v3,
AICPA 2014 Trust Service Principles and Criteria and augments internal
control direction for service organization control reports attestations.
The CSA CCM strengthens existing information security control
environments by enabling the reduction of security threats and
vulnerabilities in the cloud, provides standardized security and
operational risk management, and seeks to normalize security
expectations, cloud taxonomy and terminology, and security measures
implemented in the cloud.
`ISO 27001/2:2013 <http://www.27000.org/iso-27001.htm>`__
The ISO 27001 Information Security standard and certification has been
used for many years to evaluate and distinguish an organizations
alignment with information Security best practices. The standard is
comprised of two parts: Mandatory Clauses that define the Information
Security Management System (ISMS) and Annex A which contains a list of
controls organized by domain.
The information security management system preserves the
confidentiality, integrity, and availability of information by applying
a risk management process and gives confidence to interested parties
that risks are adequately managed.
`Trusted Security
Principles <http://www.aicpa.org/InterestAreas/InformationTechnology/Resources/TrustServices/Pages/Trust%20Services%20Principles%E2%80%94An%20Overview.aspx>`__
Trust Services are a set of professional attestation and advisory
services based on a core set of principles and criteria that address
the risks and opportunities of IT-enabled systems and privacy programs.
Commonly known as the SOC audits, the principles define what the
requirement is and it is the organizations responsibility to define the
control that meets the requirement.
Audit reference
~~~~~~~~~~~~~~~
OpenStack is innovative in many ways however the process used to audit
an OpenStack deployment is fairly common. Auditors will evaluate a
process by two criteria: Is the control designed effectively and if the
control is operating effectively. An understanding of how an auditor
evaluates if a control is designed and operating effectively will be
discussed in the section called :doc:`understanding-the-audit-process`.
The most common frameworks for auditing and evaluating a cloud
deployment include the previously mentioned ISO 27001/2 Information
Security standard, ISACA's Control Objectives for Information and
Related Technology (COBIT) framework, Committee of Sponsoring
Organizations of the Treadway Commission (COSO), and Information
Technology Infrastructure Library (ITIL). It is very common for audits
to include areas of focus from one or more of these frameworks.
Fortunately there is a lot of overlap between the frameworks, so an
organization that adopts one will be in a good position come audit
time.

43
security-guide-rst/source/compliance/privacy.rst Normal file
View File

@@ -0,0 +1,43 @@
=======
Privacy
=======
Privacy is an increasingly important element of a compliance program.
Businesses are being held to a higher standard by their customers, who
have increased interest in understanding how their data is treated from
a privacy perspective.
An OpenStack deployment will likely need to demonstrate compliance with
an organization's Privacy Policy, with the U.S.-E.U. Safe Harbor
framework, the ISO/IEC 29100:2011 privacy framework or with other
privacy-specific guidelines. In the U.S. the AICPA has `defined 10
privacy areas of
focus <http://www.aicpa.org/interestareas/informationtechnology/resources/privacy/generallyacceptedprivacyprinciples/>`__,
OpenStack deployments within a commercial environment may desire to
attest to some or all of these principles.
To aid OpenStack architects in the protection of personal data, it is
recommended that OpenStack architects review the NIST publication
800-122, titled "*Guide to Protecting the Confidentiality of Personally
Identifiable Information (PII)*." This guide steps through the process
of protecting:
"any information about an individual maintained by an agency,
including (1) any information that can be used to distinguish or
trace an individual's identity, such as name, social security
number, date and place of birth, mother's maiden name, or biometric
records; and (2) any other information that is linked or linkable to
an individual, such as medical, educational, financial, and
employment information"
Comprehensive privacy management requires significant preparation,
thought and investment. Additional complications are introduced when
building global OpenStack clouds, for example navigating the differences
between U.S. and more restrictive E.U. privacy laws. In addition, extra
care needs to be taken when dealing with sensitive PII that may include
information such as credit card numbers or medical records. This
sensitive data is not only subject to privacy laws but also regulatory
and governmental regulations. By deferring to established best
practices, including those published by governments, a holistic privacy
management policy may be created and practiced for OpenStack
deployments.

131
security-guide-rst/source/compliance/understanding-the-audit-process.rst Normal file
View File

@@ -0,0 +1,131 @@
===============================
Understanding the audit process
===============================
Information system security compliance is reliant on the completion of
two foundational processes:
Implementation and operation of security controls
Aligning the information system with in-scope standards and
regulations involves internal tasks which must be conducted before
a formal assessment.
Auditors may be involved at this state to conduct gap analysis,
provide guidance, and increase the likelihood of successful
certification.
Independent verification and validation
Demonstration 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.
Determining audit scope
~~~~~~~~~~~~~~~~~~~~~~~
Determining audit scope, specifically what controls are needed and how
to design or modify an OpenStack deployment to satisfy them, should be
the initial planning step.
When scoping OpenStack deployments for compliance purposes, consider
prioritizing controls around sensitive services, such as command and
control functions and the base virtualization technology. Compromises of
these facilities may impact an OpenStack environment in its entirety.
Scope reduction helps ensure OpenStack architects establish high quality
security controls which are tailored to a particular deployment, however
it is paramount to ensure these practices do not omit areas or features
from security hardening. A common example is applicable to PCI-DSS
guidelines, where payment related infrastructure may be scrutinized for
security issues, but supporting services are left ignored, and
vulnerable to attack.
When addressing compliance, you can increase efficiency and reduce work
effort by identifying common areas and criteria that apply across
multiple certifications. Much of the audit principles and guidelines
discussed in this book will assist in identifying these controls,
additionally a number of external entities provide comprehensive lists.
The following are some examples:
The `Cloud Security Alliance Cloud Controls
Matrix <https://cloudsecurityalliance.org/research/ccm/>`__ (CCM)
assists both cloud providers and consumers in assessing the overall
security of a cloud provider. The CSA CMM provides a controls framework
that map to many industry-accepted standards and regulations including
the ISO 27001/2, ISACA, COBIT, PCI, NIST, Jericho Forum and NERC CIP.
The `SCAP Security
Guide <https://fedorahosted.org/scap-security-guide/>`__ is another
useful reference. This is still an emerging source, but we anticipate
that this will grow into a tool with controls mappings that are more
focused on the US federal government certifications and recommendations.
For example, the SCAP Security Guide currently has some mappings for
security technical implementation guides (STIGs) and NIST-800-53.
These control mappings will help identify common control criteria across
certifications, and provide visibility to both auditors and auditees on
problem areas within control sets for particular compliance
certifications and attestations.
Internal audit
~~~~~~~~~~~~~~
Once a cloud is deployed, it is time for an internal audit. This is the
time compare the controls you identified above with the design,
features, and deployment strategies utilized in your cloud. The goal is
to understand how each control is handled and where gaps exist. Document
all of the findings for future reference.
When auditing an OpenStack cloud it is important to appreciate the
multi-tenant environment inherent in the OpenStack architecture. Some
critical areas for concern include data disposal, hypervisor security,
node hardening, and authentication mechanisms.
Prepare for external audit
~~~~~~~~~~~~~~~~~~~~~~~~~~
Once the internal audit results look good, it is time to prepare for an
external audit. There are several key actions to take at this stage,
these are outlined below:
- Maintain good records from your internal audit. These will prove
useful during the external audit so you can be prepared to answer
questions about mapping the compliance controls to a particular
deployment.
- Deploy automated testing tools to ensure that the cloud remains
compliant over time.
- Select an auditor.
Selecting an auditor can be challenging. Ideally, you are looking for
someone with experience in cloud compliance audits. OpenStack experience
is another big plus. Often it is best to consult with people who have
been through this process for referrals. Cost can vary greatly depending
on the scope of the engagement and the audit firm considered.
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.
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.

10
security-guide-rst/source/data-processing/case-studies.rst
View File

@@ -2,12 +2,10 @@
Case studies
============
.. TODO (elmiko) fixup the introduction chapter link to point to case studies
intro
Continuing with the studies described in :doc:`../introduction`, we
present Alice and Bob's approaches to deploying the Data
processing service for their users.
Continuing with the studies described in
:doc:`../introduction/introduction-to-case-studies` present Alice and
Bob's approaches to deploying the Data processing service for their
users.
Alice's private cloud
~~~~~~~~~~~~~~~~~~~~~

13
security-guide-rst/source/databases/case-studies.rst
View File

@@ -2,13 +2,12 @@
Case studies
============
.. TODO (pdesai) fix link to introduction-to-case-studies
Earlier in :doc:`../introduction` we introduced the Alice and Bob case
studies where Alice is deploying a private government cloud and Bob is
deploying a public cloud each with different security requirements. Here
we discuss how Alice and Bob would address database selection and
configuration for their respective private and public clouds.
Earlier in :doc:`../introduction/introduction-to-case-studies` we
introduced the Alice and Bob case studies where Alice is deploying a
private government cloud and Bob is deploying a public cloud each with
different security requirements. Here we discuss how Alice and Bob
would address database selection and configuration for their respective
private and public clouds.
Alice's private cloud
~~~~~~~~~~~~~~~~~~~~~

15
security-guide-rst/source/instance-management/case-studies.rst
View File

@@ -2,15 +2,12 @@
Case studies
============
.. TODO (elmiko) fixup the introduction chapter link to point to case studies
intro
Earlier in :doc:`../introduction` we introduced the Alice and Bob case
studies where Alice is deploying a private government cloud and Bob is
deploying a public cloud each with different security requirements.
Here we discuss how Alice and Bob would architect their clouds with
respect to instance entropy, scheduling instances, trusted images, and
instance migrations.
Earlier in :doc:`../introduction/introduction-to-case-studies` we
introduced the Alice and Bob case studies where Alice is deploying
a private government cloud and Bob is deploying a public cloud each
with different security requirements. Here we discuss how Alice and
Bob would architect their clouds with respect to instance entropy,
scheduling instances, trusted images, and instance migrations.
Alice's private cloud
~~~~~~~~~~~~~~~~~~~~~

14
security-guide-rst/source/secure-communication/case-studies.rst
View File

@@ -2,14 +2,12 @@
Case studies
============
.. TODO (elmiko) fixup link to introduction chapter to point to case studies
section
Earlier in :doc:`../introduction` we introduced the Alice and Bob case
study where Alice is deploying a government cloud and Bob is deploying
a public cloud each with different security requirements. Here we
discuss how Alice and Bob would address deployment of PKI certification
authorities (CA) and certificate management.
Earlier in :doc:`../introduction/introduction-to-case-studies` we
introduced the Alice and Bob case study where Alice is deploying a
government cloud and Bob is deploying a public cloud each with
different security requirements. Here we discuss how Alice and Bob
would address deployment of PKI certification authorities (CA) and
certificate management.
Alice's private cloud
~~~~~~~~~~~~~~~~~~~~~