64b6c9261e
Current folder name New folder name Book title ---------------------------------------------------------- basic-install DELETE cli-guide DELETE common common NEW admin-guide-cloud Cloud Administrators Guide docbkx-example DELETE openstack-block-storage-admin DELETE openstack-compute-admin DELETE openstack-config config-reference OpenStack Configuration Reference openstack-ha high-availability-guide OpenStack High Availabilty Guide openstack-image image-guide OpenStack Virtual Machine Image Guide openstack-install install-guide OpenStack Installation Guide openstack-network-connectivity-admin admin-guide-network OpenStack Networking Administration Guide openstack-object-storage-admin DELETE openstack-security security-guide OpenStack Security Guide openstack-training training-guide OpenStack Training Guide openstack-user user-guide OpenStack End User Guide openstack-user-admin user-guide-admin OpenStack Admin User Guide glossary NEW OpenStack Glossary bug: #1220407 Change-Id: Id5ffc774b966ba7b9a591743a877aa10ab3094c7 author: diane fleming
92 lines
14 KiB
XML
92 lines
14 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" xmlns:db="http://docbook.org/ns/docbook" version="5.0" xml:id="ch064_certifications-compliance-statements"><?dbhtml stop-chunking?>
|
||
<title>Certification & Compliance Statements</title>
|
||
<para>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.</para>
|
||
<section xml:id="ch064_certifications-compliance-statements-idp44896">
|
||
<title>Commercial Standards</title>
|
||
<para>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.</para>
|
||
<para>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. </para>
|
||
<section xml:id="ch064_certifications-compliance-statements-idp47472">
|
||
<title>SOC 1 (SSAE 16) / ISAE 3402</title>
|
||
<para>Service Organization Controls (SOC) criteria are defined
|
||
by the <link xlink:href="http://www.aicpa.org/">American Institute of Certified Public Accountants</link> (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.</para>
|
||
<para>There are two types of SOC 1 reports:</para>
|
||
<itemizedlist><listitem>
|
||
<para>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.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>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</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
<para>For more details see the <link xlink:href="http://www.aicpa.org/InterestAreas/FRC/AssuranceAdvisoryServices/Pages/AICPASOC1Report.aspx">AICPA Report on Controls at a Service Organization Relevant to User Entities’ Internal Control over Financial Reporting</link>.</para>
|
||
</section>
|
||
<section xml:id="ch064_certifications-compliance-statements-idp53632">
|
||
<title>SOC 2</title>
|
||
<para>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.</para>
|
||
<para>There are two types of SOC 2 reports:</para>
|
||
<itemizedlist><listitem>
|
||
<para>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.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>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.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
<para>For more details see the <link xlink:href="http://www.aicpa.org/InterestAreas/FRC/AssuranceAdvisoryServices/Pages/AICPASOC2Report.aspx">AICPA Report on Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality or Privacy</link>.</para>
|
||
</section>
|
||
</section>
|
||
<section xml:id="ch064_certifications-compliance-statements-idp60416">
|
||
<title>SOC 3</title>
|
||
<para>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.</para>
|
||
<para>For more details see the <link xlink:href="http://www.aicpa.org/InterestAreas/FRC/AssuranceAdvisoryServices/Pages/AICPASOC3Report.aspx">AICPA Trust Services Report for Service Organizations</link>.</para>
|
||
</section>
|
||
<section xml:id="ch064_certifications-compliance-statements-idp62832">
|
||
<title>ISO 27001/2</title>
|
||
<para>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.</para>
|
||
<para>For more details see <link xlink:href="http://www.27000.org/iso-27001.htm">ISO 27001</link>.</para>
|
||
</section>
|
||
<section xml:id="ch064_certifications-compliance-statements-idp65296">
|
||
<title>HIPAA / HITECH</title>
|
||
<para>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.</para>
|
||
<para>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, do 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 reputational impact.</para>
|
||
<para>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 (e.g. with security controls and hardening) then they are subject to HIPAA fines and penalties.</para>
|
||
<para>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 Swift object encryption will facilitate HIPAA guidelines for compliance with the act.</para>
|
||
<para>For more details see the <link xlink:href="https://www.cms.gov/Regulations-and-Guidance/HIPAA-Administrative-Simplification/HIPAAGenInfo/downloads/HIPAALaw.pdf">Health Insurance Portability And Accountability Act</link>.</para>
|
||
<section xml:id="ch064_certifications-compliance-statements-idp4736">
|
||
<title>PCI-DSS</title>
|
||
<para>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. </para>
|
||
<para>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). </para>
|
||
<para>For more details see <link xlink:href="https://www.pcisecuritystandards.org/security_standards/">PCI security standards</link>.</para>
|
||
</section>
|
||
</section>
|
||
<section xml:id="ch064_certifications-compliance-statements-idp8448">
|
||
<title>Government Standards</title>
|
||
<section xml:id="ch064_certifications-compliance-statements-idp9088">
|
||
<title>FedRAMP</title>
|
||
<para>"The <link xlink:href="http://www.fedramp.gov">Federal Risk and Authorization Management Program</link> (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.</para>
|
||
<para>For more details see <link xlink:href="http://www.gsa.gov/portal/category/102371">http://www.gsa.gov/portal/category/102371</link>.</para>
|
||
</section>
|
||
<section xml:id="ch064_certifications-compliance-statements-idp10768">
|
||
<title>ITAR</title>
|
||
<para>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.</para>
|
||
<para>For more details see <link xlink:href="http://pmddtc.state.gov/regulations_laws/itar_official.html">http://pmddtc.state.gov/regulations_laws/itar_official.html</link>.</para>
|
||
</section>
|
||
<section xml:id="ch064_certifications-compliance-statements-idp89888">
|
||
<title>FISMA</title>
|
||
<para>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.</para>
|
||
<para>This process is broken apart into three primary categories:</para>
|
||
<itemizedlist><listitem>
|
||
<para><emphasis role="bold">System Categorization</emphasis>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.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
<itemizedlist><listitem>
|
||
<para><emphasis role="bold">Control Selection</emphasis>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.”</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para><emphasis role="bold">Control Tailoring</emphasis>Once system security controls are identified, an OpenStack architect will utilize NIST 800-53 to extract tailored control selection, e.g. specification of what constitutes a “secure password.”</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
</section>
|
||
</section>
|
||
</chapter>
|