Attachment 3 Risk Management Framework by Acquisition Phase.pdf

UNCLASSIFIED

DEPARTMENT OF DEFENSE

CLOUD COMPUTING

SECURITY REQUIREMENTS GUIDE

Version 1, Release 3

6 March, 2017

Developed by the Defense Information Systems Agency

For the Department of Defense

DoD Cloud Computing SRG v1r3 DISA Risk Management, Cybersecurity Standards 6 March, 2017 Developed by DISA for DoD ii

Trademark Information

Names, products, and services referenced within this document may be the trade names, trademarks, or service marks of their respective owners. References to commercial vendors and their products or services are provided strictly as a convenience to our users, and do not constitute or imply endorsement by DoD, DISA, the DISA Risk Management Executive (RME), or DISA RME Cybersecurity Standards Branch of any non-Federal entity, event, product, service, or enterprise.

iii

Table of Contents

1 INTRODUCTION

1.1 Key Terminology

1.2 Purpose and Audience

1.3 Authority

1.4 Scope and Applicability

1.4.1 Applicability of CC SRG vs DoDI 8550.01

1.5 Security Requirements Guides (SRGs) / Security Technical Implementation Guides (STIGs)

1.6 SRG and STIG Distribution

1.7 Document Revisions and Update Cycle

1.7.1 Comments, Proposed Revisions, and Questions

1.8 Document Organization

2 BACKGROUND

2.1 Cloud Computing, Cloud Service, and Cloud Deployment Models

2.2 Cloud Service Provider (CSP) and Cloud Service Offering (CSO)

2.3 DoD Risk Management Framework (DoD RMF)

2.4 Federal Risk and Authorization Management Program (FedRAMP)

2.5 FedRAMP Plus (FedRAMP+)

2.6 DoD Provisional Authorization

3 INFORMATION SECURITY OBJECTIVES / IMPACT LEVELS

3.1 Security Objectives (Confidentiality, Integrity, Availability)

3.2 Information Impact Levels

3.2.1 Level 1: Unclassified Information approved for Public release

3.2.2 Level 2: Non-Controlled Unclassified Information

3.2.3 Level 3: Controlled Unclassified Information

3.2.4 Level 4: Controlled Unclassified Information

3.2.5 Level 5: Controlled Unclassified Information

3.2.6 Level 6: Classified Information up to SECRET

4 RISK ASSESSMENT OF CLOUD SERVICE OFFERINGS

4.1 Assessment of Commercial/Non-DoD Cloud Services

4.2 Assessment of DoD Cloud Services and Enterprise Services Applications

4.3 Cloud Service Offering and Mission Owner Risk Management

4.3.1 Cloud Computing, Authorization Boundaries

4.3.2 Cloud Service Offering (CSO) Risk

4.3.3 Mission Risk

4.4 CSP Transition from CSM v2.1 to CC SRG v1r1 and Subsequent Updates

4.4.1 CSP Transition from CC SRG Version/Release to Updated CC SRG Version/Release

4.5 DoD PA in Relation to RFP Response and Contract Award; DFARS Interpretation .. 40

4.6 Cloud Service vs a Managed IT Service

5 SECURITY REQUIREMENTS

5.1 DoD Policy Regarding Security Controls

5.1.1 DoD use of FedRAMP Security Controls

iv

5.1.2 DoD FedRAMP+ Security Controls/Enhancements

5.1.3 Parameter Values for Security Controls and Enhancements

5.1.4 National Security Systems (NSS)

5.1.4.1 NSS Level 6 Classified Overlay Applicability

5.1.5 CNSSI 1253 Privacy Overlay

5.1.5.1 PII/PHI at Level 2

5.1.5.2 Effects of the Privacy Overlay on CSPs and Mission Owners

5.1.5.3 CSO Assessment of Privacy Overlay Control/Control Enhancements

5.1.5.4 Mission System / Application Assessment of Privacy Overlay Control/Control Enhancements

5.1.6 Security Controls/Enhancements to be optionally addressed in the Contract/SLA .. 50

5.1.7 Additional Considerations and/or Requirements for L4/5 DoD PA Award

5.2 Legal Considerations

5.2.1 Jurisdiction/Location Requirements

5.2.1.1 DoD Off-Premises Vs On-Premises Vs Virtually On-Premises

5.2.2 Cloud Deployment Model Considerations / Separation Requirements

5.2.2.1 Impact Level 2 Location and Separation Requirements

5.2.2.2 Impact Level 4 Location and Separation Requirements

5.2.2.3 Impact Level 5 Location and Separation Requirements

5.2.2.4 Impact Level 6 Location and Separation Requirements

5.2.2.5 Separation in Support of Law Enforcement and Criminal Investigation and E- Discovery

5.2.3 DoD Data Ownership and CSP Use of DoD Data

5.3 Ongoing Assessment

5.3.1 Continuous Monitoring

5.3.1.1 Continuous Monitoring for CSOs in the FedRAMP Catalog with a DoD PA . 60

5.3.1.2 Continuous Monitoring for DoD Assessed CSOs

5.3.2 Change Control

5.3.2.1 Change Control for CSOs in the FedRAMP Catalog with a DoD PA

5.3.2.2 Change Control for DoD Assessed CSOs

5.4 CSP use of DoD Public Key Infrastructure (PKI)

5.4.1 Identification, Authentication, and Access Control Credentials

5.4.1.1 Mission Owner Credentials for CSP and Mission System Interfaces

5.4.1.2 CSP Privileged User Credentials

5.4.2 Public Key (PK) Enabling

5.5 Policy, Guidance, Operational Constraints

5.5.1 SRG/STIG Compliance

5.6 Physical Facilities and Personnel Requirements

5.6.1 Facilities Requirements

5.6.2 CSP Personnel Requirements

5.6.2.1 CSP Personnel Requirements – PS-2: Position Categorization

5.6.2.2 CSP Personnel Requirements – PS-3: Background Investigations

5.6.2.3 Mission Owner Responsibilities Regarding CSP Personnel Requirements

5.6.2.4 Training Requirements

5.7 Data Spill

5.8 Data Retrieval and Destruction for Off-boarding from a CSO v

5.9 Reuse and Disposal of Storage Media and Hardware

5.10 Architecture

5.10.1 Cloud Access Point (CAP)

5.10.1.1 Boundary CAP (BCAP)

5.10.1.1.1 NIPRNet BCAP

5.10.1.1.2 NIPRNet BCAP Meet-Me Points

5.10.1.1.3 CSP Support for BCAP Connectivity

5.10.1.1.4 CSP/CSO Network Connectivity to Internet and BCAP

5.10.1.2 Internal CAP (ICAP)

5.10.1.3 SIPRNet BCAP/ICAP

5.10.1.4 Mission Partner Environments or Communities of Interest Network Cloud Access Points

5.10.1.5 Mission Partner Environment Access to NIPRNet Services Hosted in the Cloud 93

5.10.1.6 Mission System Connection Approval through DISN BCAPs

5.10.2 Network Planes

5.10.2.1 Network Plane Connectivity

5.10.2.2 User/Data Plane Connectivity

5.10.2.3 Management Plane Connectivity

5.10.3 CSP Service Architecture

5.10.3.1 CSP Service Architecture - SaaS

5.10.3.2 CSP Service Architecture - IaaS/PaaS

5.10.3.3 CSP Disaster Recovery (DR) - Continuity of Operations (COOP)

5.10.4 Internet Protocol (IP) Addressing and Domain Name Services (DNS)

5.10.4.1 IP Addressing

5.10.4.2 Domain Name Services (DNS)

5.10.5 Mission Owner Requirements using SaaS (All Levels)

5.10.6 Mission Owner System/Application Requirements using IaaS/PaaS

5.10.7 Active Directory Integration for Cloud

5.10.7.1 Active Directory Federation Services (ADFS)

5.10.7.2 Active Directory DirSync (Directory Synchronization)

5.11 Encryption of Data-at-Rest in Commercial Cloud Storage

5.11.1 Cryptographic Erase

5.12 Backup

5.13 DoD Contractor / DoD Component Mission Partner Use of CSOs

5.13.1 DoD Component Mission Partners

5.13.2 Non-CSP DoD Contractors and DIB Partners Use of CSOs for the Protection of Sensitive DoD Information

5.13.3 Non-CSP DoD Contractors Use of CSOs as a Portion of a Non-CSO Product or Service 115

5.14 Mission Owner DoD Test and Development in the Cloud

5.14.1 Workstation Connectivity to Cloud Based T&D Zones

5.15 Ports, Protocols, Services, Management and Cloud Based Systems/Applications

5.16 Mobile Code

5.17 Registration and Connection Approval for Cloud Based Systems/Applications vi

5.17.1 DISA Systems/Network Approval Process (SNAP)

5.17.2 DoD DMZ Whitelist

5.17.3 Select and Native Programming Data Input System- Information Technology (SNaP-IT)

5.18 Supply Chain Risk Management Assessment

5.19 Electronic Mail Protections IAW TASKORD 12-0920

6 CYBERSPACE DEFENSE AND INCIDENT RESPONSE

6.1 Overview of Cyberspace Defense

6.2 Concept Changes for Information Impact Levels for Cloud Computing

6.2.1 Boundary Cyberspace Defense Actions

6.2.2 Mission Cyberspace Defense Actions

6.3 Cyberspace Defense Actions

6.4 Cyberspace Defense Roles and Responsibilities

6.5 Cyber Incident Reporting and Response

6.5.1 Incident Response Plans and Addendums

6.5.2 Information Requirements, Categories, Timelines, and Formats

6.5.3 Incident Reporting Mechanism

6.5.4 Digital Forensics in the Cloud and Support for Law Enforcement/Criminal Investigation

6.5.4.1 Malicious Software

6.5.4.2 Incident Information Collection, Preservation, and Protection

6.5.4.3 Forensics/Incident Information Chain-of-Custody for LE/CI

6.5.4.4 Digital Forensics Support by CSP toward PA Award

6.6 Warning, Tactical Directives, and Orders

6.7 Continuous Monitoring / Plans of Action and Milestones (POA&Ms)

6.8 Notice of Scheduled Outages

6.9 PKI for Cyberspace Defense Purposes

6.10 Vulnerability and Threat Information Sharing

Appendix A References

Appendix B Glossary

Appendix C Roles and Responsibilities

Appendix D CSP Assessment Parameter Values for PA

Appendix E Privacy Overlay Comparative C/CE Tables and Value Tables

Appendix F FUTURE Privacy Overlay Guidance vii

List of Tables Table 1 - Potential Impact Definitions for Security Objectives (FIPS-199) Table 2 - DoD FedRAMP+ Security Controls/Enhancements Table 3 - Security Controls/Enhancements to be addressed in the Contract/SLA Table 4 - Mission Owner Credentials Table 5 - User/Data Plane Connectivity Table 6 - Management Plane Connectivity Table 7 - Roles and Responsibilities Table 8 – FedRAMP M / FedRMP+ Control / Enhancement Parameter Values for PA Assessment Table 9 - Parameter Values for SLA controls/Enhancements Listed in Table 3 Table 10 - FedRAMP M C/CE Modified or Required by Regulation Table 11- FedRAMP+ C/CE Modified or Required by Regulation Table 12 - Privacy Overlay C/CE Not Included In FedRAMP M or FedRAMP+ Table 13 - PII/PHI Parameter Values for FedRAMP and FedRAMP+ C/CE Table 14 - PII/PHI Parameter Values for C/CE Not Included In FedRAMP M or FedRAMP+ 236

List of Figures Figure 1 – Impact Level Comparison Figure 2 – Notional Division of Security Inheritance and Risk Figure 3 - Ongoing Assessment Division of Responsibility Figure 4 – DoD Continuous Monitoring for CSOs with a FedRAMP JAB PA Figure 5 – DoD Continuous Monitoring for FedRAMP CSOs with a 3PAO assessed Non-DoD Federal Agency ATO Figure 6 – DoD Continuous Monitoring for DoD Assessed CSOs Figure 7 - DoD Change Control Process for CSPs CSOs with a FedRAMP JAB PA Figure 8 - DoD Change Control Process for FedRAMP CSPs CSOs with a 3PAO assessed Federal Agency ATO Figure 9 - DoD Change Control Process for DoD Self-Assessed CSPs/CSOs Figure 10 – NIPRNet/Commercial/Federal Cloud Ecosystem viii

This page is intentionally blank.

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. 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) and this Cloud Computing Security Requirements Guide (CC SRG). Defense Information Systems Agency (DISA) previously published the concepts for operating in the commercial cloud in 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. The CC 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

(CSM).

1.1 Key Terminology

This CC SRG introduces terminology and concepts that are unique to cloud computing and DoD’s usage of the technology. While this section lists some of the key terms, please refer to 0;

Glossary for their definitions before, or as, reading this document to realize a full understanding of the content and requirements.

The following is a list of key terminology which is used throughout this document:

• Cloud Service Provider (CSP)

• Commercial CSP

• DoD CSP

• Non-DoD CSP

• Cloud Service Offering (CSO)

• DoD Cloud Service Catalog1

• DoD Component

• Mission Owner (MO)

• DoD Private CSO

• C/CE (Control/Control Enhancement)

1 DoD Cloud Service Catalog:

https://disa.deps.mil/ext/CloudServicesSupport/Pages/Catalog-DoD-Approved-Commercial.aspx (DoD CAC/PKI required) http://www.disa.mil/~/media/Files/DISA/Services/Cloud-Broker/AuthorizedCloudServicesCatalog.pdf (Public) https://disa.deps.mil/ext/CloudServicesSupport/Pages/Catalog-DoD-Approved-Commercial.aspx http://www.disa.mil/%7E/media/Files/DISA/Services/Cloud-Broker/AuthorizedCloudServicesCatalog.pdf

• DoD Off-Premises

• DoD On-Premises

• DoD Virtually On-Premises

1.2 Purpose and Audience

This CC SRG outlines the security model by which DoD will leverage cloud computing along with the security controls and requirements necessary for using cloud-based solutions.

This CC SRG applies to DoD provided cloud services and those provided by a contractor on behalf of the Department.

The CC SRG serves several purposes:

• Provides security requirements and guidance to DoD and commercial Cloud Service Providers (CSPs) (DoD contractors) that wish to have their Cloud Service Offerings CSO(s) included in the DoD Cloud Service Catalog2.

• Establishes a basis on which DoD will assess the security posture of a DoD or non-DoD CSP’s CSO, supporting the decision to grant a DoD Provisional Authorization (PA) that allows a CSP to host DoD missions.

• Establishes a basis on which a DoD Component’s Authorizing Official (AO) will assess the security posture of a DoD CSP’s CSO, supporting the decision to grant a DoD Component’s Authorization to Operate (ATO) for the CSP/CSO, and a DoD PA if the CSO might be leveraged by other DoD Components. (e.g., DISA’s ATO/PA for milCloud)

• Defines the requirements and architectures for the use and implementation of DoD or commercial cloud services by DoD Mission Owners.

• Provides guidance to DoD Mission Owners, Security Control Assessors (SCA), Authorizing Officials, (formerly Certification and Accreditation (C&A) officials), and others in planning and authorizing the use of a CSO.

• Supports the DoD Chief Information Officer’s (CIO) Cloud initiative to migrate DoD web sites and applications from physical servers and networks within DoD networks and data centers into lower cost commodity IT services which typically include virtual servers and networks that are an integral part of most cloud services provided by both DoD and commercial CSPs.

• Supports the DoD CIO’s and Federal Government’s Data Center Reduction initiatives.

The audience for this CC 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)

2 DoD Cloud Service Catalog:

https://disa.deps.mil/ext/CloudServicesSupport/Pages/Catalog-DoD-Approved-Commercial.aspx (DoD CAC/PKI required) http://www.disa.mil/~/media/Files/DISA/Services/Cloud-Broker/AuthorizedCloudServicesCatalog.pdf (Public)

1.3 Authority

This document is provided under the authority of DoD Instruction 8500.01 and DoD Instruction 8510.01.

DoD Instruction (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 National Security Agency Central Security Service (NSA/CSS), using input from stakeholders, and using automation whenever possible.

DoDI 8500.01 further directs DoD Component heads to ensure that all DoD IT under their purview comply with applicable STIGs, [NSA] security configuration guides, and SRGs with any exceptions documented and approved by the responsible AO.

DoDI 8510.01 implements NIST Special Publication (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.4 Scope and Applicability

DoDI 8510.01, para 2a states: “This instruction applies to: (2) All DoD IT that receive, process, store, display, or transmit DoD information. These technologies are broadly grouped as DoD IS, platform IT (PIT), IT services, and IT products. This includes IT supporting research, development, test and evaluation (T&E), and DoD-controlled IT operated by a contractor or other entity on behalf of the DoD.”

DoDI 8510.01, Encl 3, para 3b (page 13) defines internal and external IT Services (formerly "Outsourced IT-based Processes"). Cloud computing by its nature fits this definition which is as follows:

"3b. IT Services. IT services are outside the service user organization's authorization boundary, and the service user's organization has no direct control over the application or assessment of required security controls. DoD organizations that use IT services are typically not responsible for authorizing them (i.e., issue an authorization decision).

(1) Internal IT services are delivered by DoD ISs. DoD organizations that use internal IT services must ensure the categorization of the IS delivering the service is appropriate to the needs of the DoD IS using the service, and that written agreements describing the roles and responsibilities of both the providing and the receiving organization are in place.

(2) DoD organizations that use external IT services provided by a non-DoD federal government agency must ensure the categorization of the IS delivering the service is appropriate to the confidentiality, integrity, and availability needs of the information and mission, and that the IS delivering the service is operating under a current authorization from that agency. In accordance with Reference (h) [ed. DoDI 8500.01], interagency agreements or government statements of work for these external services must contain requirements for service level agreements (SLAs) that include the application of appropriate security controls.

(3) DoD organizations that use external IT services provided by a commercial or other non-federal government entity must ensure the security protections of the IS delivering the service is appropriate to the confidentiality, integrity, and availability needs of the DoD organization's information and mission. DoD organizations must perform categorization in accordance with Reference (e) [ed. CNSSI 1253] and tailor appropriately to determine the set of security controls to be included in requests for proposals. DoD organizations will assess the adequacy of security proposed by potential service providers, and accept the proposed approach, negotiate changes to the approach to meet DoD needs, or reject the offer. The accepted security approach must be documented in the resulting contract or order.

(4) DoD organizations contracting for external IT services in the form of commercial cloud computing services must comply with DoD cloud computing policy and procedural guidance as published."

This CC SRG, in support of DoDI 8510.01, Encl 3, para 3b, establishes the DoD security objectives to host DoD mission applications and DoD information in internal and external IT services in the form of CSP’s CSOs. The sensitivity of the DoD information may range from publicly releasable up to and including SECRET. Missions above SECRET must follow existing applicable DoD and Intelligence Community (IC) policies and are not covered by this CC SRG.

NOTE: The IC offers approved Cloud Services at classification levels above SECRET. Contact the DoD CIO Cloud team for additional information at: osd.cloudcomputing@mail.mil.

This CC SRG applies to all CSPs/CSOs hosting DoD systems/information/data/applications, regardless of who owns or operates the environments. Owners/operators can be DoD Components, Federal Government agencies, or commercial entities.

This CC SRG supports the responsibilities of DoD Component heads, per 44 USC 3534 (a) (1)

(ii) (Federal Information Security Management Act (FISMA)), to provide protections for "information systems used or operated by an agency or by a contractor of an agency or other organization on behalf of an agency". CSPs not operated by the Mission Owner are essentially “a contractor of an agency” which operates an information system on “behalf of an agency".

Mission Owners contracting with a CSP are outsourcing all or a portion of their information technology workloads to the CSP. This is the same as the use of “IT services” under DoDI 8510.01, Encl 3, para 3b.

This CC SRG also applies to all DoD mission owners using cloud services and all parties involved in the provisioning of cloud services to DoD mission owners. This includes integrators or brokers and CSPs serving as prime contractor as well as any supporting CSP or facilities provider (i.e., sub-contractor) that an integrator/broker/CSP might leverage or contract with to provide a complete service or set of services under a DoD contract. For example, if CSP A instantiates their SaaS offering in CSP B’s IaaS offering, which is located in CSP C’s data center, the CC SRG is applicable to all three CSP/CSO entities for the applicable requirements.

Similarly, for a cloud services integrator/broker which uses or resells one or more CSPs/CSOs to full contract requirements, the CC SRG is applicable to all cloud services. While the CSP’s overall service offering may be inheriting controls and compliance from a third party, the prime CSP, the CSP with a DoD contract for service, is ultimately responsible for complete compliance. This applicability statement and associated requirements are consistent with DoD and Federal acquisition requirements and clauses which state that DoD contractors, in this case integrators/brokers/CSPs must include all security requirements incumbent upon them in all subcontracts.

mailto:osd.cloudcomputing@mail.mil

The authorization process for commercial and non-DoD CSPs is based on FISMA and NIST RMF processes through the use of FedRAMP, supplemented with DoD considerations as outlined in Section 4, RISK ASSESSMENT OF CLOUD SERVICE OFFERINGS of this document. These requirements and considerations are a subset of the requirements in the DoD RMF. The authorization process for DoD enterprise service programs providing cloud capabilities or service offerings (e.g. milCloud, Defense Enterprise Email) is based on the DoD RMF requirements and processes which are similar to the FISMA and NIST RMF processes.

Both processes utilize similar baselines of 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 release of this CC 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.

NOTE: Recognizing that PaaS CSOs can range from very close to IaaS where the mission owner is only provided with a few unsecured programming environments and an OS that the Mission Owner must secure to very close to SaaS where the CSO is a mostly complete application that mission owner can only customize its interface, PaaS will be better addressed in a future release of this CC SRG.

NOTE: While this CC SRG applies to all DoD use cases of cloud computing, one of the primary focus points of this SRG is to facilitate the migration of DoD systems and applications hosted on physical infrastructure (virtualized or not) owned by DoD Components and connected to DoD Defense Information System Network (DISN) services (i.e., Non-secure Internet Protocol Router Network (NIPRNet) and Secret Internet Protocol Router Network (SIPRNet) to DoD or non- DoD Cloud Services (as defined by NIST. See Section 2.1, Cloud Computing, Cloud Service, and Cloud Deployment Models for this definition). This SRG does not address all DoD systems and applications unless they are migrating to or leveraging DoD or non-DoD Cloud Services nor does it address approved DoD or non-DoD systems and applications used by DoD that are already approved for direct access via the Internet (not traversing the DISN) unless they are migrating to commercial cloud services directly accessed via the Internet. While this SRG may be used to assess/approve such cloud services and the applications that use them, it is not intended to change the approved network access or connectivity methods they use.

1.4.1 Applicability of CC SRG vs DoDI 8550.01

DoDI 8550.01, “DoD Internet Services and Internet-Based Capabilities,” September 11, 2012,3 addresses the “Use of Internet-based capabilities (IbC) to collect, disseminate, store, and otherwise process unclassified DoD information.” The intent of this policy is to permit the use of various established public services on the Internet by DoD Components and users. One of the primary use cases is for the dissemination of publicly released information on these services

3 DoDI 8550.01: http://www.dtic.mil/whs/directives/corres/pdf/855001p.pdf

(e.g., Facebook and Twitter) as part of a Public Affairs communications campaign. Secondary use cases include the publication of Blogs. The DoD Information Impact Level of all information covered by the DoDI 8550.01 is Impact Level 2.

While the services addressed by the DoDI 8550.01 may be considered cloud services, the typical funding model is that such services are free to use and are widely used by the general public under that model. Additionally these services are not managed by DoD or managed by the provider for DoD, therefore DoD RMF requirements do not apply and such services do not require an ATO for DoD to use them. Conversely, the CC SRG is applicable to all cloud services that require a DoD ATO under DoD policy. This includes all IaaS and PaaS CSOs on which a DoD system is built (by or for DoD).

1.5 Security Requirements Guides (SRGs) / Security Technical Implementation Guides (STIGs)

Security Requirements Guides (SRGs) are collections of security 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 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 typically results in a given system being subject to multiple SRGs and/or STIGs.

Newly published SRGs and STIGs generally consist of a technology/product overview document and one or more eXtensible Markup Language (XML) (.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 CC 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. This requirement remains in force for all Mission Owners building systems in a cloud service. CSP systems must comply with configuration guidance consistent with the NIST SP 800-53 control CM-6 by utilizing STIGs/SRGs or a configuration guide deemed equivalent by DoD.

1.6 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.

http://iase.disa.mil/ http://iase.disa.smil.mil/

NOTE: Some content requires a DoD Public Key Infrastructure (PKI) certificate for access. The IASE web site does NOT currently accept External Certificate Authority (ECA) certificates for entry into the PKI-protected area. Industry partners needing PKI restricted content may request it through their DoD sponsor.

1.7 Document Revisions and Update Cycle

DISA Risk Management Executive, Cybersecurity Standards Branch develops, revises, updates, and publishes SRG and STIG documents on a quarterly maintenance release schedule as needed.

These publications reflect new or changed policies, requirements, threats, or mitigations;

reorganized content; corrected errors; and/or, to 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 an 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.

1.7.1 Comments, Proposed Revisions, and Questions

Comments, proposed revisions, and questions are accepted at any time via email at disa.stig_spt@mail.mil.

DISA Risk Management Executive, Cybersecurity Standards Branch coordinates all change requests with relevant DoD organizations before inclusion and subsequent publication in a maintenance release or major update.

1.8 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, Information Security Objectives / Impact Levels: Explains the concept of “Information 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 RMF processes used for granting a DoD PA and explains how a PA can be leveraged by a Mission Owner and its AO in support of an ATO decision.

Section 5, Security Requirements: Details the requirements associated with enabling CSP capabilities.

http://iase.disa.mil/stigs/Pages/fso-schedule.aspx

Section 6, Cyberspace 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 NIST SP 800-1454 defines cloud computing as having 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 defined as follows:

“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.”

The Essential Characteristics are:

“On-demand self-service. A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service provider.

Broad network access. Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, tablets, laptops, and workstations).

Resource pooling. The provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. There is a sense of location independence in that the customer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter). Examples of resources include storage, processing, memory, and network bandwidth.

Rapid elasticity. Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be appropriated in any quantity at any time.

Measured service. Cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer of the utilized service.”

The NIST defined cloud service models include Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS) and are defined as follows:

“Software as a Service (SaaS). The capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure. The applications are accessible from various client devices through either a thin client interface, such as a web browser (e.g., web-based email), or a program interface. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

4 NIST SP 800-145: http://csrc.nist.gov/publications/PubsSPs.html http://csrc.nist.gov/publications/PubsSPs.html

Platform as a Service (PaaS). The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment.

Infrastructure as a Service (IaaS). The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, and deployed applications; and possibly limited control of select networking components (e.g., host firewalls). ”

NIST defines cloud deployment models as follows.

“Private cloud. The cloud infrastructure is provisioned for exclusive use by a single organization comprising multiple consumers (e.g., business units). It may be owned, managed, and operated by the organization, a third party, or some combination of them, and it may exist on or off premises.

Community cloud. The cloud infrastructure is provisioned for exclusive use by a specific community of consumers from organizations that have shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It may be owned, managed, and operated by one or more of the organizations in the community, a third party, or some combination of them, and it may exist on or off premises.

Public cloud. The cloud infrastructure is provisioned for open use by the general public.

It may be owned, managed, and operated by a business, academic, or government organization, or some combination of them. It exists on the premises of the cloud provider.

Hybrid cloud. The cloud infrastructure is a composition of two or more distinct cloud infrastructures (private, community, or public) that remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load balancing between clouds). ”

This SRG uses private and community to mean the following: “DoD private/community cloud” refers to a cloud service that is built for the exclusive use of DoD users or tenants. “Federal Government Community cloud” is one that includes both DoD and other Federal Government tenants. For example, a cloud used exclusively by Army and Air Force tenants would be considered DoD private/community, while one utilized by DISA and the Department of State would be a Federal Government community cloud.

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 model terminology. Service offerings that provide data storage without also providing computing services will be considered to be a subset of IaaS. Furthermore any other service models proposed by the vendor (such as Data as a Service (DaaS)) will have to be aligned to one the three standard service delivery models and meet the appropriate controls. As used in this SRG the terms cloud computing and cloud services refer to a 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 Exchange Points (IXPs)). CSPs offering SaaS may leverage one or more third party CSO’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) The Federal Risk and Authorization Management Program5, or FedRAMP, is a government-wide program that provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services used by the Federal Government. The use of FedRAMP is mandated for 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. The December 2011 OMB FedRAMP policy memo6 requires Federal departments and agencies to utilize FedRAMP approved CSPs and share Agency ATOs with the FedRAMP Secure Repository.

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 PA to host Federal Government missions.

DoD leverages FedRAMP JAB PAs and non-DoD U.S. Government Federal Agency ATO packages residing in the FedRAMP Secure Repository, including all supporting documentation

5 FedRAMP: https://www.fedramp.gov/ 6 December 2011 OMB Policy Memo: https://www.fedramp.gov/files/2015/03/fedrampmemo.pdf https://www.fedramp.gov/ https://www.fedramp.gov/files/2015/03/fedrampmemo.pdf when assessing a CSO for a DoD PA. However, DoD will only accept non-DoD Agency ATOs where the CSP/CSO was assessed by a FedRAMP accredited Third Party Assessor Organization

(3PAO).

NOTE: The American Association for Laboratory Accreditation7 (A2LA) accredits FedRAMP 3PAOs with the FedRAMP Program Management Office (PMO) providing final approval.

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 (PA) is an acknowledgement of risk based on an evaluation of the CSP’s CSO and the potential for risk introduced to DoD networks. The DoD PA process follows the same “do once, use many times” framework as FedRAMP does. DoD PAs are granted at all information impact levels. A PA provides a foundation that AOs responsible for mission applications must leverage in determining the overall risk to the missions/applications that are executed as part of a CSO.

Since all CSOs offered by a CSP may not have been submitted for assessment, a DoD PA is granted to the CSP for a CSO, not the CSP itself. Furthermore, if a CSP’s CSO leverages another CSP’s CSO (e.g., CSP A instantiates their SaaS offering in CSP B’s IaaS offering) then the DoD PA for CSP A’s CSO includes inherited compliance of CSP B. In this case, CSP A will be contractually responsible for CSP B and must have accountability for controls in their sub-contracts. It is therefore highly recommended that CSPs offering service to DoD only utilize other CSOs that have a DoD PA. In the event a leveraged CSP/CSO does not have a PA, it will be assessed as part of the prime CSO. Such subtended assessments will not automatically grant the leveraged CSP/CSO an independent PA. CSPs must disclose subcontracted CSOs used in the CSOs offered to DoD when assessed for a DoD PA.

NOTE: DoD PAs are not granted to physical facilities by themselves (e.g., a data center) that support cloud infrastructure even if it might be considered a CSO if the facility supports multiple CSPs or multiple tenants’ equipment. These are assessed for the physical and environmental controls as part of the CSP’s CSO by the 3PAO for unclassified facilities. Classified processing facilities are addressed later in this CC SRG.

A DoD PA is revocable in the event a CSP/CSO loses its FedRAMP PA or if the CSP does not maintain compliance with its security responsibilities identified in this CC SRG, associated requirements found in other referenced documents, or contract requirements. Additionally, a CSP’s CSO with a DoD PA which leverages another CSP’s CSO with a DoD PA may lose their PA if the leveraged CSO loses its PA. CSPs acting as prime contractor must maintain the PA for their CSO and require all sub contracted CSPs to maintain the PA for their CSOs for the term of the contract. This flow-down is also applicable to cloud services integrators and brokers acting as prime contractors. If a prime or subcontracted CSO losing a PA and refuses to correct or

7 American Association for Laboratory Accreditation: https://www.a2la.org/ https://www.a2la.org/ cannot correct the reason(s) for it, such a condition may constitute a breach of contract. While revoking a PA is an extreme measure, DoD will work with the CSP to resolve the issues leading to revocation. Consistent with the December 2014 DoD CIO Memo,8 the DISA AO is responsible for approving and revoking DoD PAs.

CSOs possessing a DoD PA are listed in the DoD Cloud Service Catalog9. DoD Component services may also implement approved CSP/CSO listings for their agency’s use.

8Updated Guidance on the Acquisition and Use of Commercial Cloud Computing Services: http://dodcio.defense.gov/Portals/0/Documents/Cloud/DoD%20CIO%20-%20Updated%20Guidance%20- %20Acquisition%20and%20Use%20of%20Commercial%20Cloud%20Serviices_20141215.pdf 9 DoD Cloud Service Catalog:

https://disa.deps.mil/ext/CloudServicesSupport/Pages/Catalog-DoD-Approved-Commercial.aspx (DoD CAC/PKI required) http://www.disa.mil/~/media/Files/DISA/Services/Cloud-Broker/AuthorizedCloudServicesCatalog.pdf (Public) http://dodcio.defense.gov/Portals/0/Documents/Cloud/DoD%20CIO%20-%20Updated%20Guidance%20-%20Acquisition%20and%20Use%20of%20Commercial%20Cloud%20Serviices_20141215.pdf http://dodcio.defense.gov/Portals/0/Documents/Cloud/DoD%20CIO%20-%20Updated%20Guidance%20-%20Acquisition%20and%20Use%20of%20Commercial%20Cloud%20Serviices_20141215.pdf

3 INFORMATION SECURITY OBJECTIVES / IMPACT LEVELS

Cloud security information impact levels are defined by the combination of: 1) the sensitivity or confidentiality level of information (e.g., public, private, classified, etc.) 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 that information. DoD Mission Owners must categorize mission information systems in accordance with DoDI 8510.01 and CNSSI 1253 then identify the Cloud Information Impact level that most closely aligns with the defined categorization and information sensitivity. The Cloud Information Impact Levels are further defined in Section 3.2, Information Impact Levels.

3.1 Security Objectives (Confidentiality, Integrity, Availability) 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,10 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]11. 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.