openstack-manuals/doc/security-guide/ch063_compliance-activities.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="ch063_compliance-activities"><?dbhtml stop-chunking?>
    <title>Compliance Activities</title>
    <para>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.</para>
    <section xml:id="ch063_compliance-activities-idp44544">
      <title>Information Security Management System (ISMS)</title>
      <para>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 <link xlink:href="http://www.27000.org/iso-27001.htm">ISO/IEC 27001/2</link>, which creates a solid foundation of security controls and practices for achieving more stringent compliance certifications.</para>
    </section>
    <section xml:id="ch063_compliance-activities-idp46224">
      <title>Risk Assessment</title>
      <para>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.</para>
    </section>
    <section xml:id="ch063_compliance-activities-idp47920">
      <title>Access &amp; Log Reviews</title>
      <para>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.</para>
    </section>
    <section xml:id="ch063_compliance-activities-idp49392">
      <title>Backup and Disaster Recovery</title>
      <para>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.</para>
    </section>
    <section xml:id="ch063_compliance-activities-idp51008">
      <title>Security Training</title>
      <para>Annual, role-specific, security training is a mandatory requirement for almost all compliance certifications and attestations. To optimise 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.</para>
    </section>
    <section xml:id="ch063_compliance-activities-idp52592">
      <title>Security Reviews</title>
      <para>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 <link xlink:href="http://www.microsoft.com/security/sdl/process/release.aspx">Microsoft SDL</link>,
      created as part of the Microsoft
      Trustworthy Computing Initiative.</para>
    </section>
    <section xml:id="ch063_compliance-activities-idp54592">
      <title>Vulnerability Management</title>
      <para>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.</para>
    </section>
    <section xml:id="ch063_compliance-activities-idp56416">
      <title>Data Classification</title>
      <para>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.</para>
    </section>
    <section xml:id="ch063_compliance-activities-idp58256">
      <title>Exception Process</title>
      <para>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.</para>
    </section>
  </chapter>