SCCA_FRD_v2-9.pdf_safe.pdf

i

DEPARTMENT OF DEFENSE (DoD) Secure Cloud Computing Architecture (SCCA)

Functional Requirements

1/31/2017 V2.9

Developed by the

Defense Information Systems Agency (DISA) for the

Department of Defense (DoD) i

TABLE OF CONTENTS

Executive Summary

1 Introduction

Scope

DISN Boundary Security

DoD Cloud Hosted System Security

Cloud Governance

Implementation Guidance

Secure Cloud Computing Architecture Technical Components and Topology

DoD Cloud Security Guidance

Networks and Topology

Cybersecurity Capabilities

Roles and Responsibilities

Capability Modularity, Decoupling and Applicability

Applicable Security Policies

Reference Documents

2 Functional Requirements

Security Requirements

Cloud Access Point

Virtual Datacenter Security Stack

Virtual Datacenter Managed Service

Trusted Cloud Credential Manager

System Connectivity Requirements

DISN Connectivity

Mission Application Connectivity

Management Network Connectivity for Off-Premise CSO

Management Network Connectivity for On-Premise CSO

Optional Cyber Security and Interface Translation

Mission Support System Requirements

Mission Applications

Component Management

Performance Management

Draft ii

20141015 UNCLASSIFIED

FOR OFFICIAL USE ONLY

PDCN

Requirements

PDCN

Requirements

Version 2.9 UNCLASSIFIED PDCN

Requirements

PDCN

Requirements

SCCA

Requirements

Security Information & Event Management (SIEM)

Full Packet Capture (FPC)

Performance Requirements

BCAP/ICAP Performance

VDSS Performance

VDMS Performance

Continuity of Operations Requirements

BCAP/ICAP Continuity of Operations

VDSS Continuity of Operations

VDMS Continuity of Operations

System Scalability Requirements

BCAP/ICAP Scalability

VDSS Scalability

VDMS Scalability

Backup and Restoration Requirements

BCAP/ICAP Backup and Restoration

VDSS Backup and Restoration

VDMS Backup and Restoration

Appendix A: Acronyms and Abbreviations

Appendix B: Threat Definitions

Appendix C: Cloud Component Terminology

TABLE OF TABLES

Table 1. Initial SCCA Threat Considerations

Table 2. BCAP Security Requirements

Table 3. ICAP Security Requirements

Table 4. VDSS Security Requirements

Table 5: VDMS Security Requirements

Table 6. TCCM Security Requirments

Table 7. DISN Connectivity Requirements

Table 8. Mission Application Connectivity

Table 9. Off-Premise Management Network Connectivity

Table 10. On-Premise Management Network Connectivity

Table 11. Optional Cyber Security and Interface Translation

Table 12. Integration with Mission Applications iii

20141015 UNCLASSIFIED

FOR OFFICIAL USE ONLY

PDCN

Requirements

PDCN

Requirements

Version 2.9 UNCLASSIFIED PDCN

Requirements

PDCN

Requirements

SCCA

Requirements

Table 13. Component Management Requirements

Table 14. Performance Management Requirements

Table 15. Security Information & Event Management Requirements

Table 16. Full Packet Capture (FPC) Requirements

Table 17. BCAP/ICAP Performance Requirements

Table 18. VDSS Performance Requirements

Table 19. VDMS Performance Requirements

Table 20. BCAP/ICAP Continuity of Operations Requirements

Table 21. VDSS Continuity of Operations Requirements

Table 22. VDMS Continuity of Operations Requirements

Table 23. BCAP/ICAP Scalability Requirements

Table 24. VDSS Scalability Requirements

Table 25. VDMS Scalability Requirements

Table 26. BCAP/ICAP Backup and Restoration Requirements

Table 27. VDSS Backup and Restoration Requirements

Table 28. VDMS Backup and Restoration Requirements

TABLE OF FIGURES

Figure 1. Cloud Computing Foundations

Figure 2. Secure Cloud Computing Architecture (SCCA) Components

Figure 3. Notional Cloud Service Provider Infrastructure & Networks

Figure 4. Notional DISN Management Networks

Figure 5. SCCA Component Alignment to Cybersecurity Organizations

Figure 6. SCCA Component Applicability

Figure 7. Notional SCCA System & Connectivity

Figure 8. Management Network Connectivity for Off-Premise CSO

Figure 9. Management Network Connectivity for On-Premise CSO iv

20141015 UNCLASSIFIED

FOR OFFICIAL USE ONLY

PDCN

Requirements

PDCN

Requirements

Version 2.9 UNCLASSIFIED PDCN

Requirements

PDCN

Requirements

SCCA

Requirements

DOCUMENT INFORMATION

CHANGE / REVISION RECORD

Date Description of Change

01/16/2015 Initial functional requirements description

02/02/2015 Update on functional requirements document

02/09/2015 Updates to address results of 2/7/15 review with DISA leadership

2/13/2015 Updates to address results of 2/10/15 review with DISA leadership and MITRE Team Review

3/17/2015 Updates to address comments

4/2/2015 Update to address RE comments

4/10/2015 Update to address RE & CTO comments

4/22/2015 Update to address RE comments

6/15/2015 Update to address RE & CC/S/A comments

6/24/2015 Update to add network requirements

6/30/2015 Update to add CAP Extension Appendix

7/15/2015 Update to address administrative comments from PAO and removed FOUO marking.

10/30/2015 Update to address DoD community and CSP comments

2/23/2016 Renamed CAP FRD to SCCA FRD and updated to include SCCA components

10/31/2016 Update to address industry and DoD Component comments

1/31/2017 SCCA Pilot Team Inputs

Version 2.9 UNCLASSIFIED

SCCA

Requirements

Executive Summary

As the Department of Defense (DoD) strives to meet the objectives of the DoD CIO to maximize the use of commercial cloud computing, the Defense Information System Network (DISN) perimeter and DoD

Information Network (DoDIN) systems must continue to be protected against cyber threats. DISA is responsible for developing the DISN protection requirements and guidance to secure the connection point to the Cloud Service Provider (CSP). DISA is well positioned to provide enterprise capabilities to secure

DoD Mission Owner systems deployed to the commercial cloud.

The purpose of the Secure Cloud Computing Architecture (SCCA) is to provide a barrier of protection between the DISN and commercial cloud services used by the DoD while optimizing the cost-performance trade in cyber security. The SCCA will proactively and reactively provide a layer of overall protection against attacks upon the DISN infrastructure and mission applications operating within the commercial cloud. It specifically addresses attacks originating from mission applications that reside within the Cloud

Service Environment (CSE) upon both the DISN infrastructure and neighboring tenants in a multi-tenant environment. It provides a consistent CSP independent level of security that enables the use of commercially available Cloud Service Offerings (CSO) for hosting DoD mission applications operating at all

DoD Information System Impact Levels (i.e. 2, 4, 5, & 6).

Requirements defined herein cover the array of CSOs to include Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and Software-as-a-Service (SaaS). However, the authors have been careful to word requirements with sufficient specificity to address the DoD cloud security posture while enabling innovation and allowing flexibility in implementations. The shared responsibility model is assumed to persist so that, where important for cost savings, identified security capabilities can be delivered by either

DoD, commercial CSP, or 3rd party organizations.

SCCA

Requirements

1 Introduction The DoD has made great strides in protecting the DoD Information System Network (DISN) from security threats at its boundary through Non-secure Internet Protocol Router Network (NIPRNet) hardening initiatives. As the DoD move to maximize the use of commercial cloud computing, the DISN perimeter must continue to be protected against cyber threats from external connections. As such, DISA is responsible for developing the requirements to support the DoD in implementing DISN perimeter protection at the connection point to multiple Cloud Service Providers (CSP). DISA is also well positioned to provide enterprise protection capabilities for mission applications and Mission Owner

(MO) data hosted within the commercial Cloud Service Environment (CSE).

This document provides a summary of the Secure Cloud Computing Architecture (SCCA) and its requirements based upon and analysis of possible attack vectors. The boundary requirements that were developed apply to all cloud service offerings including: Infrastructure as a Service (IaaS), Platform as a

Service (PaaS), and Software as a Service (SaaS). SCCA requirements have been developed based upon the DoD experiences covering successful implementations of commercial and other non-DoD systems.

Such systems have included Internet Access Points (IAPs), NIPRNet Federated Gateway (NFG), and direct connections to approved contractor facilities. SCCA requirements are intended to be consistent with

Joint Information Environment (JIE) objectives1.

Scope This document addresses functional requirements necessary to enable detection, protection, and response to cyber security threats against the DISN from Non-DoD on- or off-premise CSPs. It also provides functional requirements for the protection, detection, and response to cyber security threats against DoD systems deployed into commercial CSEs for all DoD Information System Impact Levels (i.e., 2, 4, 5, & 6). The requirements currently specified within this document pertain only to the security and associated interoperability necessary to facilitate secure deployment and operations of DoD IT systems incorporating commercially owned cloud based Information Technology (IT) services.

The SCCA provides a capability and governance model, which is built upon guidance and requirements provided by the DoD Cloud Computing Security Requirements Guide (SRG)2. As such, it is based upon the handling of systems and information categorized by all DoD mission Impact levels.

DISN Boundary Security The SCCA is designed to meet the boundary protection needs of the DISN by protecting the DISN from cyber-attacks originating from within the CSP’s CSE. A CSE may be comprised of an array of CSOs from a particular CSP; wherein, a CSO is one or a bundle of cloud services offered for sale by the CSP.

Implementing the SCCA will mitigate potential damages to the DISN and will provide the ability to detect and prevent an attack before reaching the DISN. It will provide a consistent level of security that facilitates the implementation of commercial provided cloud services to support DoD mission applications.

1 DoD Cybersecurity RA 2 DoD CC SRG

SCCA

Requirements

DoD Cloud Hosted System Security The SCCA establishes the capabilities and governance models through which to protect DoD mission owner enclaves, application servers, virtual systems, and information hosted within the commercial cloud. Functional requirements defined herein are applicable for all CSO environments (i.e., IaaS, PaaS, SaaS). However, use of the SCCA is not a mandate. It is recognized that commercial CSPs, 3rd Party

Providers, and DoD Mission Owners may deliver DoD compliant security solutions with the approval of the assigned Authorization Official (AO).

Cloud Governance The SCCA addresses the need for specialized DoD governance over IT systems and operations that employ commercial CSOs. While existing DoD data center STIGs and emerging JIE requirements apply, the SCCA specifically addresses the need to tightly control privileged user access (including root) to the commercial CSP’s CSO management and configuration systems. Unlike typical on-premise DoD data centers, these systems are generally accessible from the internet or other non-DoD controlled communication networks. Additionally, these systems employ the CSP’s Identity and Access

Management (IdAM) systems which may not be federated with an authorized DoD IdAM system. While the governance model typically applies well for IaaS and some PaaS offerings, it may not apply to SaaS and some PaaS offerings where cloud consumers are excluded from CSO administration systems. The

SCCA privileged cloud user access governance model applies specifically to the use of access control systems provided and managed by the CSP.

Implementation Guidance SCCA functional requirements are intended to provide DoD-wide capabilities for the secure implementation and employment of commercial CSOs. This document does not specify the DoD

Organization responsible to deliver or operate SCCA technical components. However, DISA is responsible for protection of the DISN and will therefore provide for enterprise boundary defense and associated DISN connection services. While DISA will develop and deliver SCCA enterprise services, DoD

Components and Mission Owner elements may develop and deliver their own SCCA technical components in accordance with requirements specified herein. However, DISA’s SCCA enterprise services are intended to reduce the cost of deployment and operations of DoD cloud hosted systems. It is generally expected that SCCA technical components implemented by one DoD organization could be made available to other DoD organizations and mission partners. Accordingly, capability and operational consistency across technical component implementations is desired.

Secure Cloud Computing Architecture Technical Components and Topology The SCCA is specifically architected and intended to deliver the security capabilities defined by the DoD

Cloud Computing Requirements Guide (CC SRG) as necessary to support secure deployment of DoD systems and information into the commercially owned and operated CSP industry segment. A DoD

Provisional Authorization (PA) provides a validation of a CSP’s compliance with the DoD CC SRG guidance for hosting systems operating at an indicated DoD System Impact Level. Assuming a CSP has achieved a

DoD PA, the SCCA defines DoD system implementation and governance requirements necessary to protect the DISN boundary and commercial cloud hosted DoD mission systems and information;

illustrated in Figure 1. The construction of the SCCA is intended to levy no additional requirements upon the commercial CSP industry other than those related to secure connectivity.

SCCA

Requirements

Figure 1. Cloud Computing Foundations

The SCCA is broken into four technical components to allow flexible implementation and DoD IT organization ownership. As illustrated in

Figure 2, it is comprised of:

• Cloud Access Point (CAP):

The CAP provides access to the Cloud, boundary protection of DISN from the Cloud, and cyber defense capabilities such as firewall and intrusion detection and prevention (IDS/IPS) at the DISN boundary. Full packet capture (FPC) and interface translation may be provided, as needed, to support secure connectivity and access to individual commercial cloud hosting systems. The CAP is specifically tailored to operate at DoD Impact levels 4 and 5. In order to support both on-premise and off-premise Non-DoD CSPs, CAP requirements are decomposed into Internal-CAP (ICAP) and

Boundary-CAP (BCAP) requirements.

• Virtual Datacenter Security Stack (VDSS):

The VDSS provides DoD Core Data Center (CDC)-like network security capabilities such as firewall, intrusion detection, and intrusion prevention systems. It also provides application security capabilities such as web application firewall (WAF) and proxy systems. The VDSS can reside within or outside of the CSP’s infrastructure (virtually or physically). VDSS capabilities can also be provided as-a-Service by a third party vendor (for IaaS) or a CSP (for IaaS and SaaS). VDSS feeds should be provided to a DoD Cybersecurity Service Provider (CSSP) performing enclave boundary defense. The

VDSS also supports sharing of security event data among cyber security stakeholders. The VDSS is specifically tailored to operate at all DoD Information Impact Levels.

DoD Cloud Computing SRG

DoD Provisional

Authorization

DoD Mission Systems SCCA Systems

SCCA

Requirements

• Virtual Datacenter Managed Services (VDMS):

The VDMS provides system management network and mission owner system support services necessary to achieve JIE management plane connectivity and mission owner system compliance. It provides secure management network connectivity to the DISN, virtual host based management services, and identity and access management services for DoD Controlled Access Card (CAC) authentication to virtual systems. The VDMS is specifically tailored to operate at all DoD mission

Impact Levels. VDMS functionality applies directly to IaaS environments but may not be specifically applicable to PaaS and SaaS CSOs as such functionality may be inherent to the associated CSP and validated through the DoD PA

• Trusted Cloud Credential Manager (TCCM):

The TCCM is an individual or entity appointed by the DoD mission owner’s Authorizing Official (AO) to establish plans and policies for the control of privileged user access (to include root account credentials) used to establish, configure, and control a mission owner’s Virtual Private Cloud (VPC) configuration once connected to the DISN. The TCCM establishes and manages Least-Privilege

Attribute-Based Access Control (ABAC) accounts and credentials used by privileged DoD users and systems to administer and control DoD CSO configurations. The role of TCCM is intended to operate at all DoD information Impact Levels. However, the TCCM may not apply to some SaaS solutions where DoD account owners are not required to use the CSP’s Identity and Access Management

(IdAM) system to administer user accounts and service configurations.

Figure 2. Secure Cloud Computing Architecture (SCCA) Components

SCCA

Requirements

With the exception of the TCCM, SCCA component functional requirements are considered applicable to all cloud service models (i.e., IaaS, PaaS, and SaaS). However, requirements are not specific to provider.

SCCA technical capabilities may be delivered by the responsible DoD organization, a DoD authorized CSP, or an authorized 3rd party Security-as-a-Service (Sec-aaS) provider. Users of the SCCA are intended to be responsible DoD Mission Owners or DoD Components accredited as a CSSPs by USSTRATCOM IAW DoD O-8530.01-M. For typical IaaS and PaaS solutions, all CAP, VDSS, VDMS, and TCCM requirements are considered applicable. However, for some SaaS solutions, VDSS and VDMS functionality may be delivered by the CSP and authorized under the DoD Provisional Authorization (PA). For CSOs where DoD consumers are not given privileged user access control and management capabilities, the TCCM is not applicable.

DoD Cloud Security Guidance In accordance with the DoD Cloud Computing SRG, DoD cloud access systems will enable CSP connections to the DISN consistent with security objectives identified by the information impact levels described therein. The SRG provides guidance for the implementation of cloud access systems3. An

Internal CAP (ICAP) allows connectivity between the DISN and a non-DoD (US Commercial) “On-Premise”

CSP such as milCloud 2.0. JIE requirements and DoD Data Center architectures govern security capabilities for “On-Premise” CSP connectivity and to the DISN.4 The Boundary CAP (BCAP) allows connectivity between the DISN and a non-DoD (US Commercial) “Off-Premise” CSP.

Networks and Topology There are several networks in use when hosting a DoD mission application within a CSP as illustrated by

Figure 3. There are the CSP’s private networks that are used by the CSP to manage the underlying infrastructure and CSO implementation, such as the physical host systems, network infrastructure, the virtualization layer, and service hosts. Access to these networks is limited to authorized CSP privileged user staff and are isolated from the Internet.

3 DoD CC SRG

4 JIE CDC EDS

User Plane: Non-Privileged User Environment The User Plane is the network plane where user and data traffic flow.

Management/Data Plane: Privileged-User Environment The Management Plane carries DoD privileged users (e.g.

BCND, MCND, System Administrators), maintenance, and monitoring traffic.

Customer Portal: Ordering & Provisioning The Customer Portal is the interface where the TCCM and Mission Owner access to provision accounts, instantiate systems and/or applications, and monitor user activity.

Cloud Service Offering: CSP Owned Private Network The CSP Owned CSO is the network plane where the various CSOs reside, including the customer portal, SaaS, and CSP-provided capabilities to support IaaS/PaaS environments (e.g. identity management, domain services).

Cloud Service Provider: CSP Infrastructure Private Network The CSP Owned Infrastructure is the network plane where physical hosts of CSOs reside. Access to this network is out of band and is only accessible by the CSP.

Figure 3. Notional Cloud Service Provider Infrastructure & Networks

The DoD User, Data, and Management networks are virtually isolated from the CSP’s private networks.

The Management Plan is established inside the CSE virtual network layer and provides Mission Owner

(MO) administrators and security operations personnel access to MO virtual systems. The Data Plane is a network used for back-end communications between applications system tiers. The Production Plane establishes the user environment. Each of these is virtually segmented from the others. Access to these networks is via the CAP. As such, these networks appear to a DoD user as an extension of the DoDIN.

For typical IaaS and PaaS offerings, the Customer Portal is used by CSO account holders to provision CSP services and deploy mission owner systems into the CSE (this may not be the case with SaaS offerings).

CSO accounts are generated by the CSP and associated credentials are created by the CSP’s DoD authorized IdAM system. The CSP’s IdAM system is also be used to establish credentials and for interacting with Application Program Interface (API) and Command Line Interface (CLI) services. These systems and services are not assumed to be federated with DoD IdAM systems. Customer Portals and

API/CLI service end-points are typically internet accessible. As a result, the TCCM establishes and manages the CSP originated authentication and authorization credentials for DoD users having CSO account privileges. The TCCM may employ functions of the VDMS to accomplish this role.

SCCA

Requirements

The DISN management network (illustrated in Figure 4) is used to manage DoD Systems and perform

CND service provider operations in accordance with JIE JMN design5. The DISN management network and the mission owner management network will be integrated to facilitate DoD privileged user access to mission owner virtualized systems. The CAP will support connections to the mission owner management networks.6

The CAP will provide direct dedicated and secure network connectivity to the CSP as well as isolation for all traffic planes: User/Data, and Management. These planes may translate into Subnets, Zones or

Virtual Routing & Forwarding (VRF) segments within the CSE. Within the CSE of the CSP, traffic separation will be achieved using the CSP’s networking services.

Figure 4. Notional DISN Management Networks

5 DoD JMN EDS 6 DoD CC SRG

SCCA

Requirements

Cybersecurity Capabilities The SCCA provides an array of cyberspace defensive capabilities to provide DISN boundary defense and protect DoD systems and information deployed to a Commercial CSP. It has been designed to extend the

DISN common security posture into the authorized commercial CSP segment while leveraging and interoperating with the broader DoD cyber security defenses. Its design achieves the DoD requirements for traffic inspection7 and cyber security8 while minimizing communication bandwidth demand and duplication of defenses.

Roles and Responsibilities The SCCA is architected to support three (3) primary roles and responsibilities for which entity definition is provided within the DoD Cloud Computing SRG:

• Mission Owner (MO)

A MO is a DoD entity responsible for delivering and operating a DoD mission system. MOs are responsible for the procurement, deployment, and secure operations of their mission systems deployed to the cloud environment. Accordingly, MOs are expected to maintain trusted configuration baselines and to perform continuous monitoring for deployed mission systems.

Capabilities by the VDMS have been specifically selected to support this operational requirement. Additionally, the MO is required to establish or assign an entity to fulfill the requirements of the TCCM.

• Mission Cyberspace Protection (MCP)

The MCP organization is the DoD entity charged with the responsibility of securing a MO’s enclave and networked systems by establishing and delivering cybersecurity capabilities. The

MCP is specifically responsible for cyber defense of MO systems. The security capabilities of the

VDSS have been specifically selected to support this operational requirement. The MCP can also be the MO themselves or a certified CSSP providing MCP capabilities.

• DISN Boundary Cyberspace Protection (BCP)

The DISN BCP organization is the DoD entity charged with the responsibility to establish and deliver cybersecurity capabilities to protect the DISN. This entity will be DISA. It is assumed that

DISA will deliver CAP systems and services.

The alignment of SCCA components to cybersecurity mission is illustrated in Figure 5. Cyber security information from the CAP supports the mission of the organization providing BCD. However, cyber security information from the VDSS supports the missions of organizations providing both BCD and

MCD. The VDMS acts similarly to support the missions of organizations providing both MCD and

Missions. Establishment and execution of TCCM governance activities is specifically a MO responsibility.

7 NDAA 2015

8 DoDI 8530.01

SCCA

Requirements

Figure 5. SCCA Component Alignment to Cybersecurity Organizations

Capability Modularity, Decoupling and Applicability The SCCA security capabilities are considered modular and decoupled components. However, regardless of the owner or operator of the capability, each SCCA function is required for a comprehensive cyberspace defense capability. Additionally, individual requirements need not be specifically achieved within a given component if they can be achieved at some other point in the cybersecurity architecture.

Therefore, if requirements can be met by non-SCCA systems, it is not necessary to deploy redundant systems to achieve SCCA component capabilities. For this reason, it may be possible to employ security systems and services of the CSP or other DoD systems to meet SCCA component capability requirements.

Furthermore, specification is not made regarding the division of virtual versus physical system implementation of SCCA component capabilities. As a result, SCCA components may be implemented as either physical or virtual systems. This allows for the virtualization and colocation of SCCA component systems.

Moreover, the SCCA is built upon the assumption of DoD cybersecurity information sharing. This implies that sensor data derived from SCCA component is sharable among cybersecurity service provider organizations to achieve the DoD cybersecurity mission. For example, event data derived from a Web

Application Firewall (WAF), performing Secure Socket Layer/Transport Layer Security (SSL/TLS) traffic break and inspect, could be retrieved and employed by both the BCD and MCD organizations to accomplish their respective cybersecurity missions.

The SCCA is established to provide a set of components to assist DoD Mission Owners in achieving the requirements of the DoD Cloud Computing SRG. As illustrated in Figure 6, SCCA component capabilities

SCCA

Requirements apply to both DoD on-premise (e.g. milCloud 2.0) and off-premise CSP systems as well as IaaS, PaaS, and

SaaS CSOs operating at all Impact Levels.

Figure 6. SCCA Component Applicability

Applicable Security Policies Security and risk management policies applicable to any IT system deployed in a DoD environment are pertinent to the SCCA. In addition, the SCCA must comply with all privacy and Health Insurance

Portability and Accountability Act (HIPAA) laws and regulations if traffic involves any personal or medical information. Guiding DoD policies are:

Chairman of the Joint Chiefs of Staff Instruction (CJCSI) 6211.02D Defense Information Systems Network

(DISN) Responsibilities, 4 August 2015

Committee on National Security Systems Instruction (CNSSI) 1253 Security Categorization and Control

Selection for National Security Systems, 15 Mar 2012

DoD Cloud Way Forward, V 1.0; 23 Jul 2014

DoD Cloud Computing Security Requirements Guide (CC SRG), Version 1, Release 2; 18 Mar 2016.

DoD CIO Memo, Updated Guidance on the Acquisition and Use of Commercial Cloud Computing Services, 15 Dec 2014

DoD OSD Memo: Procedures for Operational Test and Evaluation of Cybersecurity in Acquisition

Programs; 1 Aug 2014

SCCA

Requirements

DoDI 5000.02 Operation of the Defense Acquisition System, 7 Jan 2015

DoDI 5000.44 Protection of Mission Functions to Archive Trusted Systems and Networks (TSN), 5 Nov

DoDI 8500.01 Cybersecurity, 14 Mar 2014

DoDI 8550.01 Internet Services and Internet-Based Capabilities; 11 Sep 2012.

DoD Instruction 8510.01 Risk Management Framework (RMF) for DoD Information Technology (IT), dated 12 March 2014

DHS Trusted Internet Connections (TIC) Reference Architecture Document Version 2.0 Federal

Interagency Technical Reference Architectures, 1 Oct 2013

National Defense Authorization Action (NDAA), 2015

NIST SP 500-292 Cloud Computing Reference Architecture, Sep 2011

NIST SP 500-293 US Government Cloud Computing Technology Roadmap Volume I, Oct 2014

NIST SP 800-53 Security and Privacy Controls for Federal Information Systems and Organizations, Revision 4, Apr 2013

NIST SP 800-160 Systems Security Engineering Considerations for a Multidisciplinary Approach in the

Engineering of Trustworthy Secure Systems, Second Public Draft, May 2016

Reference Documents Technical reference materials used for the creation of this document is as follows:

DoD Program Manager’s Guidebook for Integrating the Cybersecurity Risk Management Framework

RMF) into the System Acquisition Lifecycle, 26 May 2015

DoD Cloud Industry Day, Roger Greenwell & Peter Dinsmore; 29 Jan 2015

DoD Cybersecurity Reference Architecture, V4.0, dated 17 June 2016

DoD Security Architecture Reference Model (SARM) Description, V 3.0 (Final); 24 Sep 2014.

DoD JIE) Core Data Center (CDC) Engineering Design specification (EDS), Version 2.0; 15 Dec 2014

DoD Joint Information Environment (JIE) Enterprise Operations Center (EOC) Engineering Design

Specification (EDS), Version 3.0: 13 August 2015

DoD Joint Information Management Network (JMN) Engineering Design Specification, v3.6 (draft), 30

June 2016

DoD Unified Capabilities Requirements 2013 (UCR 2013); Jan 2013

DoD Internet-NIPRNet DMZ Inc. 1, Phase 2, Technology Overview, v3, Release 1; 6 Jul 2015

DoD Enterprise Cloud Service Broker Cloud Security Model, V 2.1; 13 Mar 2014

DoDI 8551.01, Ports, Protocols, and Services Management (PPSM); 28May 2014

SCCA

Requirements

DoDI 8530.01 Cybersecurity Activities Support to DoD Information Network Operations, 7 March 2016

DISA NIPRNet DOD DMZ Policy Requirements Version, V 2 Release; 08 Aug 2014

DISA Network Services Telecommunications Service Level Agreement (SLA); 12 Mar 2014

DISA Network Services Virtual Private Network (VPN) Customer Ordering Guidance, V 2.4; 12 Mar 2013

DISA NIPR Federated Gateway (NFG) Network Design, V 1.4 (Draft); 12 Nov 2012

DISA Enclave Checklist V4, Release 5; 27 July 2012

DISA Secure Remote Computing Security Technical Implementation Guide (STIG) V2, Release 5; 29 July

DISA Remote Access Policy Security Technical Implementation Guide (STIG) V2 Release 11; 22 Apr 2016

2 Functional Requirements Requirements decompose into security, connectivity, and specific capabilities, such as full packet capture and integration with management system. The requirements describe the capabilities required for the SCCA to protect the DISN, establish connectivity between the DISN and the CSO, operational aspects (e.g., Disaster Recovery Plan), component management, and mission cyber defense. The SCCA requirements are a logical representation of various component capabilities.

In order to identify the security requirements, the requirements analysis process considered possible threats against the DISN from a malicious attacker on a compromised CSO virtual infrastructure component or hosted mission application. Threats were then assessed for their applicability to attacks against DISN assets. Once a threat was shown to be possible, a requirement to detect and protect was written. Further requirements were derived from the threat analysis to address the data handling requirements necessary to provide effective cyber security response. Table 1 identifies the initial threats considered for derivation of SCCA security requirements. The NIPRNet/SIPRNet Cyber Security

Architecture Review (NSCSAR) Joint Task Force (JTF) will further refine and assess cyber threats to DoD cloud assets.

The following assumptions are made with respect to the threat environment for a Non-DoD CSP Cloud

Service Environment (CSE):

• CSE networks and systems are owned and operated by the commercial CSP

• The CSO holds a DoD Provisional Authorization (PA) for Impact Levels 2, 4 and/or 5 in accordance with the SRG

• The CSO is accessible from the Internet for impact level 2 applications

• The CSO is only accessible from the NIPRNet via a CAP for impact level 4/5 applications

• The CSO is only accessible from the SIPRNet for impact level 6 applications

• CSP management personnel have controlled access to physical, hypervisor, and virtual environment layers

SCCA

Requirements

Table 1. Initial SCCA Threat Considerations

Threat Source Information Systems Threat9

CSP Virtual Machine (VM) Escape10

CSP Cross VM Attack

CSP CSP Resource Denial of Service

CSP Session Hijack/Man-In-The Middle

CSP Service Account Hijack

CSP Virtual Machine Hijack

CSP Unauthorized Virtual Machine Management Console Access

CSP Data Exfiltration

CSP Advanced Persistent Threat

CSP/Perimeter Malicious Code/Malware

CSP/Perimeter SQL Injection

CSP/Perimeter VoIP Call Eavesdropping

CSP/Perimeter VoIP Call Modification

CSP/Perimeter VoIP Call Hijacking

Perimeter VoIP System DOS

Perimeter Network Enumeration

Perimeter Botnet Denial of Service

Perimeter Unauthorized IP Source/Destination

Perimeter Virtual Local Area Network (VLAN) Hopping

Perimeter DNS Hijacking (CSE hosted application DNS request)

Perimeter IP Route Hijacking

Perimeter IP Address Spoofing

Perimeter Rogue Access Device/Access Point Hijack (com carrier traffic interception or adding to IaaS Local Area Network (LAN))

9 Appendix B: Threat Definitions 10 Virtualization layer threats are not assumed to exist for CSPs employing not virtualized hosting environments

SCCA

Requirements

Threat Source Information Systems Threat9

Perimeter Unauthorized CAP Privileged User Account Access

Security Requirements Below are the security requirements allocated to each of the SCCA components. They are judiciously selected to achieve the following objectives:

1. DISN Boundary Defense (CAP)

2. Mission Owner Enclave and Application Defense (VDSS)

3. Mission Application End-Point Defense (VDMS)

4. DISN and Mission Defense (TCCM)

The following assumptions are made with respect to implementation of a CAP solution:

• System requirements for the implementation of the DoD Enterprise Recursive Service (ERS) to support Domain Name Service (DNS) Resolution are addressed, as needed, by the ERS Program

Office; associated requirements are not the responsibility of the SCCA system.

• DISN network routing to support specific and Mission Owner connectivity is addressed, as needed, by DISA Network Operations and Network Engineering Offices; associated requirements are not the responsibility of the SCCA system.

• Network requirements to enable Cloud service operations in the event of Internet Access Point

(IAP) cutoff are address, as needed, by DISA Network Operations/Engineering and the individual

CSP.

• Identity Federation requirements to enable CAC authentication of non-privileged DoD users to cloud hosted DoD (e.g., IaaS and PaaS) or SaaS provided systems and services is the responsibility of the CSO procuring DoD Component or Program Office; associated requirements are not the responsibility of the SCCA system.

Cloud Access Point Below is a list of requirements derived from the threat risk analysis. These requirements define threat mitigation capabilities necessary to protect the DISN. As threats evolve, the CAP security requirements will also evolve to deliver risk-based defense capabilities. CAP security requirements are not specific to physical location nor logical-physical implementation. This means that the option to locate the CAP within a Cloud Service Environment (CSE) is allowed. Further, the ability to collocate the CAP with other components of the SCCA to leverage infrastructure and system sharing is permitted. CAP requirements are composed of BCAP and ICAP requirements.

2.1.1.1 Boundary Cloud Access Point

Table 2 provides BCAP security requirements. The main purpose of the BCAP is to protect the DISN. It serves as a point defense to detect and prevent intrusion, unauthorized routes, known malicious code, and malicious network activity. It security event capture data is intended for use by JFHQ-DoDIN

Situational Awareness (SA) systems.

SCCA

Requirements

Table 2. BCAP Security Requirements

Req. ID BCAP Security Requirements

2.1.1.1.1 The BCAP shall provide the capability to detect and prevent malicious code injection into the DISN originating from the CSE

2.1.1.1.2 The BCAP shall provide the capability to detect and thwart single and multiple node DOS attacks

2.1.1.1.3 The BCAP shall provide the ability to perform detection and prevention of traffic flow having unauthorized source and destination IP addresses, protocols, and Transmission Control Protocol (TCP)/User Datagram Protocol (UDP) ports

2.1.1.1.4 The BCAP shall provide the capability to detect and prevent IP Address Spoofing and IP Route Hijacking

2.1.1.1.5 The BCAP shall provide the capability to prevent device identity policy infringement (prevent rogue device access)

2.1.1.1.6 The BCAP shall provide the capability to detect and prevent passive and active network enumeration scanning originating from within the CSE

2.1.1.1.7 The BCAP shall provide the capability to detect and prevent unauthorized data exfiltration from the DISN to an end-point inside CSE

2.1.1.1.8 The BCAP and/or BCAP Management System shall provide the capability to sense, correlate, and warn on advanced persistent threats

2.1.1.1.9 The BCAP shall provide the capability to detect custom traffic and activity signatures

2.1.1.1.10 The BCAP shall provide an interface to conduct ports, protocols, and service management (PPSM) activities in order to provide control for BCND providers

2.1.1.1.11 The BCAP shall provide full packet capture (FPC) for traversing communications

2.1.1.1.12 The BCAP shall provide network packet flow metrics and statistics for all traversing communications

2.1.1.1.13 The BCAP shall provide the capability to detect and prevent application session hijacking

SCCA

Requirements

2.1.1.2 Internal Cloud Access Point

Table 3 provides ICAP security requirements. The ICAP provides a combination of DISN boundary protection and Mission Owner enclave protection similar to what would be expected within a Core Data

Center (CDC). As such, its’ requirements set is larger than that of the BCAP. From a security perspective, the ICAP must additionally protect against the possible internet backdoor connection that may be present within an on-premise commercial cloud service implementation.

The following assumption with respect to ICAP security requirements are made:

• Existing and planned CDC security systems are capable of delivering ICAP security functionality

• ICAP requirements can be achieved by deployment of any combination of physical and/or virtual systems.

Table 3. ICAP Security Requirements

Req. ID ICAP Security Requirements

2.1.1.2.1 The ICAP shall provide the capability to detect and prevent malicious code injection into the DISN originating from the CSE

2.1.1.2.2 The ICAP shall provide the capability to detect and thwart single and multiple node DOS attacks

2.1.1.2.3 The ICAP shall provide the ability to perform detection and prevention of traffic flow having unauthorized source and destination IP addresses, protocols, and Transmission Control Protocol (TCP)/User Datagram Protocol (UDP) ports

2.1.1.2.4 The ICAP shall provide the capability to detect and prevent IP Address Spoofing and IP Route Hijacking

2.1.1.2.5 The ICAP shall provide the capability to prevent device identity policy infringement (prevent rogue device access)

2.1.1.2.6 The ICAP shall provide the capability to detect and prevent passive and active network enumeration scanning originating from within the CSE

2.1.1.2.7 The ICAP shall provide the capability to detect and prevent application session hijacking

2.1.1.2.8 The ICAP shall provide the capability to detect and prevent unauthorized data exfiltration from the DISN to an end-point inside CSE

2.1.1.2.9 The ICAP and/or ICAP Management System shall provide the capability to sense, correlate, and warn on advanced persistent threats

2.1.1.2.10 The ICAP shall provide the capability to write and detect custom traffic and activity signatures

SCCA

Requirements

Req. ID ICAP Security Requirements

2.1.1.2.11 The ICAP shall provide the capability to detect and/or prevent VoIP call eavesdropping, modification, and hijacking

2.1.1.2.12 The ICAP shall provide an interface to conduct ports, protocols, and service management (PPSM) activities in order to provide bi-directional control.

2.1.1.2.13 The ICAP shall maintain separation of all management, user, and data traffic.

2.1.1.2.14 The ICAP shall allow the use of encryption for segmentation of management traffic.

2.1.1.2.15 The ICAP shall provide a reverse proxy capability to handle service access requests from client systems

2.1.1.2.16 The ICAP shall provide a capability to inspect and filter application layer conversations based on a predefined set of rules (including HTTP) to identify and block malicious content

2.1.1.2.17 The ICAP shall provide a capability that can distinguish and block unauthorized application layer traffic

2.1.1.2.18 The ICAP shall provide a capability that monitors network and system activities to detect and report malicious activities

2.1.1.2.19 The ICAP shall provide a capability that monitors network and system activities to stop or block detected malicious activity

2.1.1.2.20

The ICAP shall perform break and inspection of Secure Socket Layer (SSL)/Transport Layer Security (TLS) communication traffic supporting single and dual authentication for traffic destined to systems hosted within the CSE. Decryption of message payloads is not implied.

2.1.1.2.21 The ICAP shall provide a monitoring capability that captures log files and event data for cyberspace analysis

2.1.1.2.22 The ICAP shall provide an archiving system for common collection, storage, and access to event logs by Boundary and Mission cyberspace privileged users

2.1.1.2.23

The ICAP shall provide a FIPS-140-2 compliant encryption key management system for storage of DoD generated and assigned server private encryption key credentials for access and use by the Web Application Firewall (WAF) in the execution of SSL/TLS break and inspection of encrypted communication sessions

2.1.1.2.24 The ICAP shall provide a DoD DMZ Extension to support connection from the NIPRNet DoD DMZ COI of supported mission owners

SCCA

Requirements

Req. ID ICAP Security Requirements

2.1.1.2.25 The ICAP shall provide full packet capture (FPC) for traversing communications

2.1.1.2.26 The ICAP shall provide network packet flow metrics and statistics for all traversing communications

2.1.1.2.27 The ICAP shall provide for the inspection of traffic entering and exiting the CSE.

Virtual Datacenter Security Stack The Virtual Data Center Security Stack (VDSS) serves to protect Mission Owner enclaves and applications hosted in an off-premise CSO. VDSS services may be offered by a DoD Component, Mission Owner, or

Enterprise Service Provider. Such services may be provisioned from application CSP, the CSP market place, or other third party authorized provider. VDSS functionality may be deployed within the CSE, the

MeetMe Point, CAP, or supporting Core Data Center (CDC), as required. VDSS requirements apply to all

IaaS, PaaS, and SaaS offerings of a CSP.

The VDSS will maintain the separation of communication traffic between virtual subnets operating within the user, data, and management planes of the DISN11. The VDSS will perform traffic inspection and filtering of traffic to provide cybersecurity for cloud resident enclaves and mission owner applications. The VDSS will support the Cyber Security Service Provider (CSSP) organizations having either Boundary or Mission Owner defense objectives. VDSS security requirements are provided in Table

4. VDSS requirements are anticipated to apply to all cloud service models including IaaS, PaaS, and SaaS.

VDSS requirements are not specific as to provider and can be delivered by either the responsible DoD organization, a DoD authorized CSP, or an authorized 3rd party provider.

The following assumptions are made with respect to implementation of a VDSS solution:

• Routing within the CSP is accomplished via CSP’s Software Defined Networking (SDN).

• Routing of public IP space within the DISN for the purpose of application advertisement and whitelisting is prohibited, unless specifically authorized.

• Security information and event data from the VDSS can be made available to either the DISN

Boundary CSSP, the Mission owner defense objectives. For example, SSL/TLS session data could be used to support both the MO CSSP to protect the end-point system and the Boundary CSSP to protect the DISN.

• A single DoD-managed network security enclave deployed to a IaaS or PaaS CSE may support multiple Mission Owners while maintaining virtual separation between Mission Owner virtual

11 DoD CC SRG

SCCA

Requirements environments. For SaaS providers, this assumption is validated by the DoD Provisional

Authorization.

Table 4. VDSS Security Requirements

Req. ID VDSS Security Requirements

2.1.2.1 The VDSS shall maintain virtual separation of all management, user, and data traffic.

2.1.2.2 The VDSS shall allow the use of encryption for segmentation of management traffic.

2.1.2.3 The VDSS shall provide a reverse proxy capability to handle access requests from client systems

2.1.2.4 The VDSS shall provide a capability to inspect and filter application layer conversations based on a predefined set of rules (including HTTP) to identify and block malicious content

2.1.2.5 The VDSS shall provide a capability that can distinguish and block unauthorized application layer traffic

2.1.2.6 The VDSS shall provide a capability that monitors network and system activities to detect and report malicious activities for traffic entering and exiting Mission Owner virtual private networks/enclaves

2.1.2.7 The VDSS shall provide a capability that monitors network and system activities to stop or block detected malicious activity

2.1.2.8 The VDSS shall inspect and filter traffic traversing between mission owner virtual private networks/enclaves.

2.1.2.9 The VDSS shall perform break and inspection of SSL/TLS communication traffic supporting single and dual authentication for traffic destined to systems hosted within the CSE12.

2.1.2.10 The VDSS shall provide an interface to conduct ports, protocols, and service management (PPSM) activities in order to provide control for MCD operators

2.1.2.11 The VDSS shall provide a monitoring capability that captures log files and event data for cybersecurity analysis

2.1.2.12 The VDSS shall provide or feed security information and event data to an allocated archiving system for common collection, storage, and access to event logs by privileged users performing Boundary and Mission CND activities

12 Management of FIPS 140-2 compliance for cryptographic components deployed to virtualized systems is the responsibility of the VDSS system owner in collaboration with the CSP and applicable 3rd party vendors. Associated risks should be addressed at Authorization.

SCCA

Requirements

Req. ID VDSS Security Requirements

2.1.2.13

The VDSS shall provide a FIPS-140-2 compliant encryption key management system for storage of DoD generated and assigned server private encryption key credentials for access and use by the Web Application Firewall (WAF) in the execution of SSL/TLS break and inspection of encrypted communication sessions.

2.1.2.14 The VDSS shall provide the capability to detect and identify application session hijacking

2.1.2.15 The VDSS shall provide a DoD DMZ Extension to support to support Internet Facing Applications (IFAs)

2.1.2.16 The VDSS shall provide full packet capture (FPC) or cloud service equivalent FPC capability for recording and interpreting traversing communications

2.1.2.17 The VDSS shall provide network packet flow metrics and statistics for all traversing communications

2.1.2.18 The VDSS shall provide for the inspection of traffic entering and exiting each mission owner virtual private network.

Virtual Datacenter Managed Service The VDMS is the SCCA component responsible for application host security. VDMS provides the security systems that manage the security posture of the Mission Owner Enclave. VDMS will provide common

DoD Core Data Center (CDC) services13 Such as common security and utility services, as specified in

Table 5. VDMS requirements are anticipated to apply to IaaS and PaaS service models. VDMS requirements are not specific as to provider and can be delivered by either the responsible DoD organization, a DoD authorized CSP, or an authorized 3rd party provider. Associated SaaS provider requirements are considered to be validated by the DoD Provisional Authorization.

Table 5: VDMS Security Requirements

Req. ID VDMS Security Requirements

2.1.3.1

The VDMS shall provide Assured Compliance Assessment Solution (ACAS), or approved equivalent, to conduct continuous monitoring for all enclaves within the

CSE

2.1.3.2 The VDMS shall provide Host Based Security System (HBSS), or approved equivalent, to manage endpoint security for all enclaves within the CSE

13 JIE CDC STIG

SCCA

Requirements

Req. ID VDMS Security Requirements

2.1.3.3

The VDMS shall provide identity services to include an Online Certificate Status

Protocol (OCSP) responder for remote system DoD Common Access Card (CAC)…