DEPARTMENT OF DEFENSE (DoD) CLOUD COMPUTING SECURITY REQUIREMENTS GUIDE (SRG) Version 1, Release 1 12 January, 2015
1 Introduction
Cloud computing technology and services provide the Department of Defense (DoD) with the opportunity to deploy an Enterprise Cloud Environment aligned with Federal Department-wide Information Technology (IT) strategies and efficiency initiatives, including federal data center consolidation. Cloud computing enables the Department to consolidate infrastructure, leverage commodity IT functions, and eliminate functional redundancies while improving continuity of operations. The overall success of these initiatives depends upon well executed security requirements, defined and understood by both DoD Components and industry. Consistent implementation and operation of these requirements assures mission execution, provides sensitive data protection, increases mission effectiveness, and ultimately results in the outcomes and operational efficiencies the DoD seeks.
The 15 December 2014 DoD CIO memo regarding Updated Guidance on the Acquisition and Use of Commercial Cloud Computing Services defines DoD Component responsibilities when acquiring commercial cloud services. The memo allows components to responsibly acquire cloud services minimally in accordance with the security requirements outlined in Federal Risk and Authorization Management Program (FedRAMP) FedRAMP and this Security Requirement Guide (SRG). DISA previously published the concepts for operating in the commercial cloud under the Cloud Security Model. Version 1 defined the overall framework and provided initial guidance for public data. Version 2.1 added information for Controlled Unclassified Information. This document, the Cloud Computing Security Requirements Guide (SRG), documents cloud security requirements in a construct similar to other SRGs published by DISA for the DoD. This SRG incorporates, supersedes, and rescinds the previously published Cloud Security Model.
The following terms will be used throughout this document:
CSP by itself refers to any or all Cloud Service Providers, DoD or non-DoD.
Non-DoD CSP will refer to a commercial or Federal Government owned and operated CSP.
Commercial CSP will refer to a Non-DoD Non-Federal Government organization offering cloud services to the public and/or government customers as a business, typically for a fee with the intent to make a profit.
DoD CSP will refer to a DoD owned and operated CSP.
CSO refers to a CSP’s Cloud Service Offering (recognizing that a CSP may have multiple offerings).
Commercial Cloud Service is a CSO offered by a Commercial CSP.
Mission Owners are entities such as program managers within the DoD Components responsible for instantiating information systems and applications leveraging a CSP’s Cloud Service Offering.
1.1 Purpose and Audience
FedRAMP is a Federal Government program focused on enabling secure cloud computing for the Federal Government. DoD, by the virtue of its warfighting mission, has unique information protection requirements that extend beyond the controls assessed via FedRAMP. This document outlines the security controls and additional requirements necessary for using cloud-based solutions within the DoD.
The Cloud Computing SRG serves several purposes:
Provides security requirements and guidance to non-DoD owned and operated Cloud Service Providers (CSPs) that wish to have their service offerings included in the DoD Cloud Service Catalog.
Establishes a basis on which DoD will assess the security posture of a non-DoD CSP’s service offering, supporting the decision to grant a DoD Provisional Authorization (PA) that allows a non-DoD CSP to host DoD missions.
Defines the policies, requirements, and architectures for the use and implementation of commercial cloud services by DoD Mission Owners.
Provides guidance to DoD Mission Owners and Assessment and Authorization officials (formerly Certification and Accreditation) in planning and authorizing the use of a CSP.
The audience for this Cloud Computing SRG includes:
Commercial and non-DoD Federal Government CSPs
DoD programs operating as a CSP
DoD Components and Mission Owners using, or considering the use of, commercial/non-DoD and DoD cloud computing services
DoD risk management assessment officials and Authorizing Officials (AOs)
1.2 Authority
This document is provided under the authority of DoD Instruction 8500.01 and DoD Instruction 8510.01.
DoDI 8500.01, entitled Cybersecurity, directs Director DISA, under the authority, direction, and control of the DoD CIO to develop and maintain Control Correlation Identifiers (CCIs), Security Requirements Guides (SRGs), Security Technical Implementation Guides (STIGs), and mobile code risk categories and usage guides that implement and are consistent with DoD cybersecurity policies, standards, architectures, security controls, and validation procedures, with the support of the NSA/CSS, using input from stakeholders, and using automation whenever possible.
DoDI 8500.01 further directs DoD Component heads to ensure that all DoD Information Technologies (IT) under their purview comply with applicable STIGs, [NSA] security configuration guides, and SRGs with any exceptions documented and approved by the responsible Authorizing Official (AO).
DoDI 8510.01 implements NIST SP 800-37, NIST SP 800-53, Committee on National Security Systems (CNSS) Instruction (CNSSI) 1253, and the Federal Information Security Management Act (FISMA) by establishing the DoD Risk Management Framework (RMF) for DoD IT, establishing associated cybersecurity policy, and assigning responsibilities for executing and maintaining the RMF.
1.3 Scope and Applicability
This Cloud Computing SRG establishes the DoD security objectives to host DoD missions up to and including SECRET on CSOs. Missions above SECRET must follow existing applicable DoD policies and are not covered by this SRG.
This SRG applies to all CSP offerings, regardless of who owns or operates the environments. This SRG also applies to any supporting cloud service provider or facilities provider that a CSP might leverage to provide a complete service. While the CSP's overall service offering may be inheriting controls and compliance from a third party, the prime CSP is ultimately responsible for complete compliance.
The assessment of security controls and other DoD requirements for commercial and non-DoD CSPs is based the use of FedRAMP, supplemented with DoD considerations as outlined in section 4 of this document. DoD enterprise service programs providing cloud capabilities or service offerings (e.g. milCloud, Defense Enterprise Email) use DoD's assessment and authorization process under the DoD RMF. Both processes utilize the NIST SP 800-53 security controls as the basis of the assessment; providing a common framework under which DoD can determine the level of risk.
This SRG establishes the DoD baseline security requirements for DoD Mission Owners when contracting for and using non-DoD Software as a Service (SaaS) offering, and when implementing their systems and applications on DoD or non- DoD Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) offerings. Since IaaS and PaaS involve CSP customers building a system or application on top of these service offerings, this SRG considers IaaS and PaaS as being similar and treats them in the same manner, unless stated otherwise. SaaS is addressed to the extent of the other service models, with specific application requirements being identified in other application-related SRGs and STIGs.
1.4 Security Requirements Guides (SRGs) / Security Technical Implementation Guides (STIGs)
Security Requirements Guides (SRGs) are collections of requirements applicable to a given technology family, product category, or an organization in general. SRGs provide non-product specific requirements to mitigate sources of security vulnerabilities consistently and commonly encountered across IT systems and applications.
While the SRGs define the high level requirements for various technology families and organizations, the Security Technical Implementation Guides (STIGs) are the detailed guidelines for specific products. In other words, STIGs provide product-specific information for validating, attaining, and continuously maintaining compliance with requirements defined in the SRG for that product's technology area.
A single technology related SRG or STIG is not all inclusive for a given system. Compliance with all SRGs/STIGs applicable to the system is required. This may result in a given system being subject to multiple SRGs and/or STIGs.
Newly published STIGs generally consist of a technology/product overview document and one or more .xml files in Extensible Configuration Checklist Description Format (XCCDF) containing the security requirements. Security requirements are presented in the form of Control Correlation Identifiers (CCIs) and include product specific configuration and validation procedures. Requirements in this SRG are not being published in an XCCDF XML format at this time.
The security requirements contained within SRGs and STIGs, in general, are applicable to all DoD-administered systems, all systems connected to DoD networks, and all systems operated and/or administrated on behalf of the DoD.
1.5 SRG and STIG Distribution
Interested parties can obtain the applicable SRGs and STIGs from the Information Assurance Support Environment (IASE) website. The unclassified website is http://iase.disa.mil and the classified website is http://iase.disa.smil.mil.
NOTE: Some content requires a PKI certificate for access. The IASE web site does NOT currently accept ECA certificates for entry into the PKI-protected area. Industry partners needing PKI restricted content may request it through their DoD sponsor.
1.6 Document Revisions and Update Cycle
DISA FSO develops, revises, updates, and publishes SRG and STIG documents in accordance with the DISA FSO quarterly maintenance release schedule. These publications reflect new or changed policies, requirements, threats, or mitigations; reorganize content; correct errors; and/or, provide additional clarity. The fiscal year based release schedule can be found at http://iase.disa.mil/stigs/Pages/fso-schedule.aspx.
Major updates to a SRG or STIG result in a version change rather than an incremental release. New SRGs and STIGs and major updates will be released as soon as they are approved and ready for publication at any time during the year.
Comments, proposed revisions, and questions are accepted via email at disa.stig_spt@mail.mil. DISA Field Security Operations (FSO) coordinates all change requests with relevant DoD organizations before inclusion.
1.7 Document Organization
This SRG is organized into six major sections with supporting appendices. Sections 1-4 address general information including the processes for authorizing a particular CSP's cloud offering. Remaining sections outline specific security requirements to be addressed in authorizing and operating cloud capabilities. In addition to specifics on SRG roles and responsibilities, and required control parameter values, the appendices provide the references and definitions used throughout the document.
Section 1 – Introduction: Provides general information on the purpose and use of this document.
Section 2 – Background: Contains a primer on several terms and supporting concepts used throughout the document.
Section 3 – Impact Levels and Security Objectives: Explains the concept of "Impact Levels" based on the type of data being hosted in the cloud and outlines security objective considerations in the areas of Confidentiality, Integrity, and Availability.
Section 4 – Risk Assessment of Cloud Service Offerings: Provides an overview of the assessment and authorization processes used for granting a DoD provisional authorization (PA) and explains how a PA can be leveraged by a Mission Owner and its Authorizing Official (AO) in support of an Authority to Operate (ATO) decision.
Section 5 – Security Requirements: Details the requirements associated with enabling CSP capabilities.
Section 6 – Computer Network Defense and Incident Response: Outlines the requirements for defending information systems operating in the cloud along with the Command and Control (C2) processes necessary to defend and operate DoD mission systems.
2 Background
This section outlines several concepts, terms, and supporting processes, providing a primer for the remainder of this document.
2.1 Cloud Computing, Cloud Service, and Cloud Deployment Models
The National Institute of Standards and Technology (NIST) Special Publication (SP) 800-145 defines cloud computing, five essential characteristics, three service models, and four deployment models. This SRG adheres to these NIST definitions to characterize and standardize the discussion of Cloud Computing.
"Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction."
Cloud service models include Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS). The components offered in IaaS form the basis for PaaS, while the components offered in PaaS form the basis of SaaS. Cloud deployment models include Public, Private, Community, and Hybrid. Please see NIST SP 800-145 for the detailed definitions of these models.
While vendors may market and name their offerings as they wish, DISA will categorize them into one of the three NIST cloud service models when listing them in the DoD Cloud Service Catalog. Vendors are encouraged to market their services using the NIST cloud service models. Service offerings that provide data storage without also providing computing services will be considered to be a subset of IaaS.As used in this SRG the terms cloud computing and cloud services refer to service offering from a provider organization to one or more organizational customers or tenant organizations. These terms do not refer to classic forms of IT services delivery where dedicated hardware (whether it is virtualized or not) is employed or assembled by organizations for their own use. A service offering from a provider organization to a customer must be part of the construct.
2.2 Cloud Service Provider (CSP) and Cloud Service Offering (CSO)
A Cloud Service Provider (CSP) is an entity that offers one or more cloud services in one or more deployment models. A CSP might leverage or outsource services of other organizations and other CSPs (e.g., placing certain servers or equipment in third party facilities such as data centers, carrier hotels / collocation facilities, and Internet Network Access Points (NAPs)). CSPs offering SaaS may leverage one or more third party CSP's (i.e., for IaaS or PaaS) to build out a capability or offering.
A Cloud Service Offering (CSO) is the actual IaaS/PaaS/SaaS solution available from a CSP. This distinction is important since a CSP may provide several different CSOs.
2.3 DoD Risk Management Framework (DoD RMF)
DoDI 8510.01 is the implementing policy for the DoD RMF, establishing associated cybersecurity policy, and assigning responsibilities for executing and maintaining the RMF. This DoD policy is consistent with NIST SP 800-37, Guide for Applying the Risk Management Framework, which defines RMF for the Federal Government. CNSSI 1253 and NIST SP 800-53, Security and Privacy Controls for Federal Information Systems and Organizations are incorporated into this DoD policy, which outline the controls and control baselines used in the assessment process. Of critical importance to this SRG, DODI 8510.01 "provides procedural guidance for the reciprocal acceptance of authorization decisions and artifacts within DoD, and between DoD and other federal agencies, for the authorization and connection of information systems (ISs)."
2.4 Federal Risk and Authorization Management Program (FedRAMP)
FedRAMP is a Federal Government program focused on enabling secure cloud computing for the Federal Government. FedRAMP is mandated for use by all Federal Agencies by the Office of Management and Budget (OMB) as their systems and applications are migrated to the commercial cloud under the Federal Government's Cloud-First initiatives. OMB policy requires Federal departments and agencies to utilize FedRAMP approved CSPs and share Agency Authority to Operate (ATO)s with the FedRAMP Secure Repository.
FedRAMP provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud services by incorporating the Federal Government RMF processes. FedRAMP uses a "do once, use many times" framework that intends to reduce cost, time, and staff required for security assessments and process monitoring reports. The FedRAMP Joint Authorization Board (JAB) is the primary governance and decision-making body for the FedRAMP program. JAB approved standards and processes result in the award and maintenance of a Provisional Authorization (PA) to host Federal Government missions.
DoD leverages FedRAMP PAs and U.S. Government Federal Agency ATO packages residing in the FedRAMP Secure Repository, including all supporting documentation.
2.5 FedRAMP Plus (FedRAMP+)
FedRAMP+ is the concept of leveraging the work done as part of the FedRAMP assessment, and adding specific security controls and requirements necessary to meet and assure DoD’s critical mission requirements. A CSP’s CSO can be assessed in accordance with the criteria outlined in this SRG, with the results used as the basis for awarding a DoD provisional authorization.
2.6 DoD Provisional Authorization
A DoD Provisional Authorization is an acceptance of risk based on an evaluation of the CSPs offering and the potential for risk introduced to DoD networks. It provides a foundation that Authorizing Officials (AOs) responsible for mission applications can leverage in determining the overall risk to the missions/applications that are executed as part of a CSO.
Cloud security information impact levels are defined by the combination of: 1) the level of information to be stored and processed in the CSP environment; and 2) the potential impact of an event that results in the loss of confidentiality, integrity or availability of DoD data, systems or networks. DoD Mission Owners categorize mission information systems in accordance with DoDI 8510.01 and CNSSI 1253 to select the impact level that most closely aligns with defined baselines.
Information Impact Levels consider the potential impact should the confidentiality or the integrity of the information be compromised.
According to Federal Information Processing Standards (FIPS) Publication 199, Standards for Security Categorization of Federal Information and Information Systems, confidentiality is "preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information..." [44 U.S.C., Sec. 3542]. A loss of confidentiality is the unauthorized disclosure of information.
FIPS Publication 199 defines integrity as "Guarding against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity..." [44 U.S.C., Sec. 3542]. A loss of integrity is the unauthorized modification or destruction of information. It is important to note that the unauthorized destruction of information will result in the loss of availability of that information.
FIPS-199 defined three levels to designate the impact of a loss of confidentiality or a loss of integrity (refer to Table 1). The security control baseline for all Impact Levels is based on moderate confidentiality and moderate integrity. If a Mission Owner has high potential impacts, specific requirements must be included in the contract/SLA to address/mitigate this risk or deploy to DoD facilities assessed using CNSSI 1253 high baselines through the DoD RMF. In the future DISA will consider incorporating a FedRAMP High Baseline into this SRG after one becomes available.
Table 1 - Potential Impact Definitions for Security Objectives
|
Potential Impact |
Security Objective |
Low |
Moderate |
High |
Confidentiality |
The unauthorized disclosure of information could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals. |
The unauthorized disclosure of information could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals. |
The unauthorized disclosure of information could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals. |
Integrity |
The unauthorized modification or destruction of information could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals. |
The unauthorized modification or destruction of information could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals. |
The unauthorized modification or destruction of information could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals. |
The baseline objectives do not address the impact of availability; it is expected that the Mission Owner will assess the CSP's stated availability rating(s) during CSP selection. Any specific or additional availability requirements must be included in the contract or a service level agreement with the CSP. Mission Owners must ensure the language is specific and inclusive for their required availability. For example, if the requirement is "CSP maintenance affecting system availability must be coordinated 4 weeks in advance and only conducted between 02:00 and 04:00 EST on Sunday morning," then the contract / SLA should detail the requirement. Recommended contract / SLA availability controls are provided under the FedRAMP+ Controls/Enhancements in Section 5.1.5, Controls/Enhancements to be Addressed in the Contract/SLA .
CSPs will be evaluated or queried as part of the assessment process to determine the level of availability they offer to be listed in the DoD Cloud Service Catalog. This evaluation does not prevent a CSP from receiving a PA or being included in the DoD Cloud Service Catalog; it is only used to facilitate the matching of a DoD Mission Owner to one or more appropriate cloud services meeting their needs.
The previously published Cloud Security Model defined 6 information Impact Levels. In order to simplify the selection process, the number of levels was reduced from 6 to 4. This was accomplished by integrating levels 1 (public information) and 3 (low impact Controlled Unclassified Information (CUI)) into levels 2 and 4, respectively. The numeric designators for the Impact Levels have not changed to remain consistent with previous versions of the Cloud Security Model, leaving Impact Levels 2, 4, 5, and 6. Note that a higher level can process data from a lower level.
Additionally, the security control baseline for all levels has been changed to moderate confidentiality and moderate integrity as defined by CNSSI 1253 and the FedRAMP Moderate Baseline. This modification from high confidentiality and high integrity is intended to better align with the categorization of most DoD customer systems that will be deployed to commercial CSP facilities. Mission owners with systems categorized at high confidentiality or integrity impact levels must deploy to DoD facilities assessed using CNSSI 1253 high baselines through the DoD RMF or contract for the added security. DISA will consider incorporating a FedRAMP High Baseline into this SRG after one becomes available.
The following subsections describe the impact levels, to include those used previously, and the type of information to be stored or hosted in CSOs.
Level 1 is no longer used and has been merged with Level 2.
Level 2 includes all data cleared for public release, as well as some DoD private unclassified information not designated as CUI or critical mission data, but the information requires some minimal level of access control.
Level 3 is no longer used and has been merged with Level 4.
Level 4 accommodates CUI which is the categorical designation that refers to unclassified information that under law or policy requires protection from unauthorized disclosure as established by Executive Order 13556 (November 2010) or other mission critical data. Designating information as CUI or critical mission data to be protected at Level 4 is the responsibility of the owning organization. Determination of the appropriate impact level for a specific mission with CUI and mission data will be the responsibility of the mission AO.
CUI contains a number of categories, including, but not limited to the following: