Skip to content
ATO Pathways
Log In
Overview
Search
Catalogs
SCAP
OSCAL
Catalogs
Profiles
Resources
Documents
Publishers
References
Knowledge Base
Platform Documentation
Compliance Dictionary
Platform Changelog
About
Catalogs
XCCDF
Cloud Computing Mission Owner Network Security Requirements Guide
Cloud Computing Mission Owner Network Security Requirements Guide
An XCCDF Benchmark
Details
Profiles
Items
Prose
File Metadata
9 rules organized in 9 groups
SRG-NET-000205
1 Rule
The Infrastructure as a Service (IaaS)/Platform as a Service (PaaS) must implement a security stack that restricts traffic flow inbound and outbound between the IaaS and the Boundary Cloud Access Point (BCAP) or Internal Cloud Access Point (ICAP) connection.
High Severity
DOD users on the internet may first connect to their assigned Defense Information Systems Network (DISN) Virtual Private Network (VPN) before accessing DOD private applications. The virtual environment may be composed of an array of cloud service offerings from a particular cloud service provider (CSP). The DISN security architecture provides the users with connectivity to the cloud service environment. The architecture mitigates potential damages to the DISN and provides the ability to detect and prevent an attack before it reaches the DISN. Note: Off-premise CSP infrastructure having a Level 2 Provisional Authorization (PA) is directly connected to the internet. All traffic to and from a Level 2 cloud service offering (CSO) serving Level 2 missions and their mission virtual networks will connect via the internet. CSP infrastructure (dedicated to DOD) located inside the Base, Camp, Post, and Station (B/C/P/S) "fence line" (i.e., on premise) connects via an ICAP. The architecture of ICAPs may vary and may leverage existing capabilities, such as the information assurance stack protecting a DOD data center or a Joint Regional Security Stack (JRSS). An ICAP may also have special capabilities to support specific missions, CSP types (commercial or DOD), or cloud services. CSP infrastructure (shared with non-DOD or dedicated to the DOD) located outside the B/C/P/S fence line that connects to the DODIN/NIPRNet does so via one or more BCAPs. The BCAP terminates dedicated circuits and VPN connections originating within the CSP's network infrastructure and/or Mission Owner's virtual networks. All connections between a CSP's network infrastructure or Mission Owner's virtual networks that is accessed via or from the NIPRNet/SIPRNet must connect to the DODIN via a BCAP. For dedicated infrastructure with a DODIN connection (Levels 4–6), the Mission Owner will ensure a virtual security stack is configured in accordance with DODI 8551.
SRG-NET-000205
1 Rule
The Mission Owner's internet-facing applications must be configured to traverse the Cloud Access Point (CAP) and Virtual Datacenter Security Stack (VDSS) prior to communicating with the internet.
High Severity
The CAP and VDSS architectures mitigate potential damages to the Defense Information Systems Network (DISN) and provide the ability to detect and prevent an attack before it reaches the DISN. All traffic bound for the internet will traverse the BCAP/ICAP and IAP. Mission applications may be internet facing; internet-facing applications can be unrestricted or restricted (requiring CAC authentication). DOD users on the internet may first connect to their assigned DISN Virtual Private Network (VPN) before accessing Mission Owner enclave or private applications.
SRG-NET-000205
1 Rule
The Mission Owner of the Infrastructure as a Service (IaaS)/Platform as a Service (PaaS) must configure scanning using an Assured Compliance Assessment Solution (ACAS) server or solution that meets DOD scanning and reporting requirements.
Medium Severity
Without the use of automated mechanisms to scan for security flaws on a continuous and/or periodic basis, the operating system or other system components may remain vulnerable to the exploits presented by undetected software flaws. Implement scanning using an ACAS server in accordance with USCYBERCOM TASKORD 13-670. - Use an ACAS Security Center server within NIPRNet or within an associated common virtual services environment in the same cloud service offering (CSO). - Implement a secure (encrypted) connection or path between the ACAS server and its assigned ACAS Security Center. Impact Level 2: Applies to IaaS/PaaS CSOs where the Mission Owner has control over the environment. In this case, Mission Owners must provide their own enclave boundary protections or leverage an enterprise-level application protection service instantiated within the same CSO.
SRG-NET-000205
1 Rule
The Infrastructure as a Service (IaaS)/Platform as a Service (PaaS) must be configured to maintain separation of all management and data traffic.
Medium Severity
The Virtual Datacenter Management system provides a management plane for privileged access and communications. Separation of management and user traffic, including access to the customer service portal, is provided to the DOD Mission Owner by the cloud service provider (CSP) to provision and configure cloud service offerings. Additionally, service endpoints for application program interfaces (APIs) and command line interfaces (CLIs) are available as part of the Customer Portal network. These systems can be accessed through the internet by DOD privileged users only (e.g., DOD system and network administrators).
SRG-NET-000383
1 Rule
For Infrastructure as a Service (IaaS)/Platform as a Service (PaaS), the Mission Owner must configure an intrusion detection and prevention system (IDPS) to protect DOD virtual machines (VMs), services, and applications.
High Severity
Network environments and applications installed using an IaaS/PaaS cloud service offering where the Mission Owner has control over the environment must comply with DOD network infrastructure and host policies. Putting an application in the cloud does not take care of all security responsibilities. Without coordinated reporting between cloud service environments used for the DOD mission, it is not possible to identify the true scale and possible target of an attack. An IDPS protects Mission Owner enclaves and applications hosted in an off-premise cloud service offering and may be deployed within the cloud service environment, cloud access point, or supporting Core Data Center (CDC). Additionally, an IDPS facilitates the reporting of incidents and aids in the coordination of response actions between all stakeholders of the cloud service offering and/or mission owner applications. The Mission Owner and/or their cybersecurity service provider (CSSP) must be able to monitor the virtual network boundary. For dedicated infrastructure with a DODIN connection (Levels 4–6), implement an IDPS that monitors and works with the virtual security infrastructure (e.g., firewall, routing tables, web application firewall, etc.) to protect traffic flow inbound and outbound to/from the virtual network to the DODIN connection.
SRG-NET-000390
1 Rule
The Mission Owner of the Infrastructure as a Service (IaaS) or Platform as a Service (PaaS) must continuously monitor and protect inbound communications from external systems, other IaaS within the same cloud service environment, or collocated mission applications for unusual or unauthorized activities or conditions.
Medium Severity
Evidence of malicious code is used to identify potentially compromised information systems or information system components. Unusual/unauthorized activities or conditions related to information system inbound communications traffic include, for example, internal traffic that indicates the presence of malicious code within organizational information systems or propagating among system components, the unauthorized exporting of information, or signaling to external information systems. Anomalies within organizational information systems include, for example, large file transfers, long-time persistent connections, unusual protocols and ports in use, and attempted communications with suspected malicious external addresses. This function may be deployed within the cloud service environment cloud access point or supporting Core Data Center (CDC).
SRG-NET-000391
1 Rule
The Mission Owner of the Infrastructure as a Service (IaaS) must continuously monitor outbound communications to other systems and enclaves for unusual or unauthorized activities or conditions.
Medium Severity
Evidence of malicious code is used to identify potentially compromised information systems or information system components. Unusual/unauthorized activities or conditions related to outbound communications traffic include, for example, internal traffic that indicates the presence of malicious code within organizational information systems or propagating among system components, the unauthorized exporting of information, or signaling to external information systems. Anomalies within organizational information systems include, for example, large file transfers, long-time persistent connections, unusual protocols and ports in use, and attempted communications with suspected malicious external addresses. This function may be deployed within the cloud service environment, the meet-me point, cloud access point, or supporting Core Data Center (CDC).
SRG-NET-000580
1 Rule
The Mission Owner must configure the Infrastructure as a Service (IaaS)/Platform to use certificate path validation to ensure revoked user credentials are prohibited from establishing a user or machine session.
High Severity
A certificate's certification path is the path from the end entity certificate to a trusted root certification authority (CA). Certification path validation is necessary for a relying party to make an informed decision regarding acceptance of an end entity certificate. Certification path validation includes checks such as certificate issuer trust, time validity, and revocation status for each certificate in the certification path. Revocation status information for CA and subject certificates in a certification path is commonly provided via certificate revocation lists (CRLs) or online certificate status protocol (OCSP) responses.
SRG-NET-000580
1 Rule
The Mission Owner must configure the Infrastructure as a Service (IaaS)/Platform as a Service (PaaS) Cloud Service to use DOD-approved OCSP responder or CRL to validate certificates used for PKI-based authentication.
High Severity
To provide assurances that certificates are validated by the correct responders, the Mission Owner must ensure they are using a valid DOD OCSP responder for remote system DOD Common Access Card (CAC) two-factor authentication of DOD privileged users to systems instantiated within the cloud service environment. When a Mission Owner is responsible for authenticating entities and/or identifying a hosted DOD information system, the Mission Owner must configure CAC/PKI for remote access for privileged users at all Impact Levels. CAC/PKI access is required for nonprivileged users of access to Impact Levels 4–6. Impact Level 6: When an on-premises, use NSS PKI. Enforce the use of a physical token referred to as the CNSS NSS Hardware Token for the authentication of DOD Mission Owner and CSP privileged and nonprivileged end users. When implementing NSS PKI, use NSS OCSP or CRL resources for checking revocation of NSS certificates and NSS Certificate Authorities and follow CNSS/NSA instructions for the management and protection of cryptographic keys. CNSS-issued PKI server certificates will be used to identify the CSP's DOD customer ordering/service management portals and SaaS applications and services contracted by and dedicated to DOD use.