openstack-manuals/doc/security-guide/ch062_audit-guidance.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="ch062_audit-guidance"><?dbhtml stop-chunking?>
    <title>Understanding the Audit Process</title>
    <para>Information system security compliance is reliant on the completion of two foundational processes:</para>
    <orderedlist><listitem>
        <para><emphasis role="bold">Implementation and Operation of Security Controls</emphasis>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.</para>
      </listitem>
<listitem>
        <para><emphasis role="bold">Independent Verification and Validation</emphasis>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.  </para>
      </listitem>
</orderedlist>
    <section xml:id="ch062_audit-guidance-idp48608">
      <title>Determining Audit Scope</title>
      <para>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.</para>
      <para>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.</para>
      <para>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.</para>
      <para>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:</para>
      <para>The <link xlink:href="https://cloudsecurityalliance.org/research/ccm/">Cloud Security Alliance Cloud Controls Matrix</link> (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.</para>
      <para>The <link xlink:href="https://fedorahosted.org/scap-security-guide/">SCAP Security Guide</link> 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.</para>
      <para>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.</para>
    </section>
    <section xml:id="ch062_audit-guidance-idp55568">
      <title>Internal Audit</title>
      <para>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.</para>
      <para>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.</para>
    </section>
    <section xml:id="ch062_audit-guidance-idp57712">
      <title>Prepare for External Audit</title>
      <para>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:</para>
      <itemizedlist><listitem>
          <para>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.</para>
        </listitem>
<listitem>
          <para>Deploy automated testing tools to ensure that the cloud remains compliant over time.</para>
        </listitem>
<listitem>
          <para>Select an auditor.</para>
        </listitem>
</itemizedlist>
      <para>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.</para>
    </section>
    <section xml:id="ch062_audit-guidance-idp62672">
      <title>External Audit</title>
      <para>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.</para>
    </section>
    <section xml:id="ch062_audit-guidance-idp65008">
      <title>Compliance Maintenance</title>
      <para>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 <emphasis>and</emphasis> compliance. Failing on either of these fronts will significantly complicate future audits.</para>
    </section>
  </chapter>