5 SECURITY REQUIREMENTS

This section of the CC SRG defines the security requirements for DoD’s use of cloud computing. It covers several areas as follows:

• Security requirements for assessing CSOs for the award of a DoD PA and inclusion in the DoD Cloud Service Catalog.
• Security requirements for CSP’s/CSOs while hosting DoD missions.
• Security requirements for Mission Owner’s systems/applications using or built on CSOs.

NOTICE: All CSP and CSO requirements in this CC SRG apply to all CSPs and CSOs offered to or contracted by the DoD.  DoD recognizes that CSOs may be offered by a CSP or an Integrator as the prime contractor on a DoD contract.  DoD also recognizes that prime contractors may subcontract for multiple CSOs to meet contract capabilities requirements and may subcontract systems maintenance.  Therefore all requirements in this CC SRG apply to all CSOs provided by prime contractors and their subcontractors to include systems maintenance contractors who may have access to CSP customer information or who may have the capability of affecting the security of the CSO.  This flow down to subcontractors is also covered in cloud and contractor associated DFARS clauses. 

5.1 DoD Policy Regarding Security Controls

DoDI 8500.01 requires all DoD Information Systems to be categorized in accordance with CNSSI 1253 and implement a corresponding set of security controls and control enhancements (C/CEs) that are published in NIST SP 800-53, regardless of whether they are National Security Systems (NSS) or non-NSS.

The CNSSI 1253 baselines are tailored from the NIST SP 800-53 recommended baselines, as are the FedRAMP baselines.  These baselines are a starting point for securing all DoD systems, which can be tailored further to address specific systems and situations. 

See NIST SP 800-59, Guideline for Identifying an Information System as a National Security System,^[39] for a definition of NSS and further information. 

5.1.1 DoD use of FedRAMP Security Controls

The FedRAMP Low and Moderate baselines are a tailored set of C/CEs based on the Low and Moderate baselines recommended in NIST SP 800-53 catalog of security controls.

The 15 December 2014 DoD CIO memo regarding Updated Guidance on the Acquisition and Use of Commercial Cloud Computing Services states “FedRAMP will serve as the minimum security baseline for all DoD cloud services.”  This SRG uses the FedRAMP v2 Moderate baseline at all information impact levels. 

The 2014 DoD CIO memo further states “components may host Unclassified DoD information that has been publicly released on FedRAMP approved cloud services”.  Using the definitions defined in Section 3.2, Impact Level 2 information may be hosted in a CSP that minimally holds a FedRAMP Moderate PA (with or without a DoD PA); subject to compliance with the personnel security requirements outlined in Section 5.6.2, CSP Personnel Requirements and acceptance by the Mission Owner and the responsible AO.  The FedRAMP v2 Moderate baseline, supplemented with DoD FedRAMP+ C/CEs and requirements in this SRG, are used to assess CSPs toward awarding a DoD PA at information impact levels 4 and above.  Only FedRAMP v2 Moderate baseline controls will be assessed for DoD PAs for impact level 2. This in no way alleviates the CSP from meeting the security requirements for CSP’s/CSOs while hosting DoD IT missions or the Mission Owner from securing their systems/web sites/applications in Level 2 CSOs.

5.1.2 DoD FedRAMP+ Security Controls/Enhancements

DoD FedRAMP+ refers to a tailored baseline of security C/CEs which has been developed for each DoD information impact level, except for level 2.  These baselines incorporate, but are not limited to, the FedRAMP Moderate baseline.  The FedRAMP+ C/CEs include NIST 800-53 security controls and enhancements not included in the FedRAMP Moderate baseline.  FedRAMP+ also includes tailored values and selections for most FedRAMP and FedRAMP+ C/CEs which require definition.  The FedRAMP+ C/CEs were selected primarily because they address issues such as the Advanced Persistent Threat (APT) and/or Insider Threat, and because the DoD, unlike the rest of the Federal Government, must categorize its systems in accordance with CNSSI 1253, use its baselines, and then tailor as needed.

The CNSSI 1253 baseline used in support of DoD PAs is based on Moderate Confidentiality and Moderate Integrity.  It does not include a baseline for Availability (categorization designated as M-M-x).  Availability is addressed in the FedRAMP baseline and may also  be addressed by the Mission Owner in the contract/SLA.  The resulting M-M-x baseline was compared to the FedRAMP Moderate baseline to derive a tailored set of FedRAMP+ security controls/enhancements for each level.  This comparison indicated that the FedRAMP Moderate Baseline includes approximately thirty two (32) C/CEs that are also contained in the CNSSI 1253 M-M-x baseline, but not in the NIST 800-53 Moderate baseline incorporated in both.  The comparison also indicated that eighty-eight (88) of the C/CEs in the CNSSI 1253 M-M-x baseline are not in the FedRAMP Moderate baseline.  These 88 were analyzed for their security benefit in the CSP environment and projected cost if the CSP were required to implement the C/CE. Approximately half were selected for the DoD cloud baselines for assessing CSPs.  The number of control enhancements selected varies by impact level.

Table 2 provides a listing of the FedRAMP+ C/CEs applicable to each information impact level, which includes only one additional base control.  The rest are control enhancements.  This table does not include controls added by the Classified Information or Privacy overlays.  More information on the assessment of the C/CE in these overlays is provided in the sections following this one.

NOTE: This table does not include the FedRAMP Moderate baseline C/CEs, a table of which can be obtained from the FedRAMP website on the Documents page^[40].

Table 2 - DoD FedRAMP+ Security Controls/Enhancements

NOTE: CSPs may offer equivalent controls or mitigations which will be considered on a case-by-case basis.

5.1.3 Parameter Values for Security Controls and Enhancements

Both FedRAMP and the DoD have defined minimum requirements in security controls and enhancement parameters.  However, in some circumstances, the specifics of the implementation are left to the CSP and assessed as to whether the implementation is appropriate for the CSO and government.  For those controls required by FedRAMP and the DoD, the parameter values are defined in Appendix D - CSP Assessment Parameter Values for PA. Also see Section 5.1.5.2, Effects of the Privacy Overlay on CSPs and Mission Owners for additional parameter guidance.

5.1.4 National Security Systems (NSS)

Although the control baselines for all levels are based on those from CNSSI 1253, only impact Level 5 and 6 are designed to accommodate NSS categorized up to M-M-x.  NSS-specific C/CEs have been included at these levels along with those required for the slightly higher impact of these systems at the moderate level (short of a full high baseline).  Thus, unclassified NSS must be instantiated at level 5 if a CSO is used.  This, however, does not preclude an unclassified non-NSS from operating at Level 5 if the mission/information owner requires the added security. 

5.1.4.1 NSS Level 6 Classified Overlay Applicability

Impact Level 6 is for classified systems which by definition are NSS. As such and IAW the DoD RMF, on-premises CSOs  are subject to the CNSSI 1253 Classified Information Overlay in addition to FedRAMP and FedRAMP+.  This overlay is an attachment to Appendix F of the CNSSI 1253 entitled CNSSI 1253F, Attachment 5, Classified Information Overlay.^[41]  It is available from the CNSS Library on the Instructions page.

This overlay imposes 94 additional C/CEs which must be assessed for a CSP’s CSO Level 6 PA.  For all CSOs, there may only be a portion of these C/CEs applicable to the CSP with the balance of the C/CEs being fulfilled by the Mission Owner.  This division of responsibility will be addressed in a future release of this document or in a companion document.

5.1.5 CNSSI 1253 Privacy Overlay

The CNSSI 1253 Privacy Overlay is an attachment to Appendix F of the CNSSI 1253 entitled CNSSI 1253F, Attachment 6, Privacy Overlay.^[42]  It is available from the CNSS Library on the Instructions page. 

The Privacy Overlay was developed in accordance with Federal privacy requirements found in laws, policies, and standards that apply to government agencies, such as the Privacy Act of 1974 ^[43]and HIPAA^[44], leveraging experts and lawyers in both fields.  Legal references are included as the basis for all control specifications in the Privacy Overlay, including whether to select or exclude C/CE as well as the provision of supplemental guidance and control extensions.  It is supported by DoD and the IC as well as other Federal agencies that are part of the CNSS.  The Privacy Overlay was written by CNSS to protect PII and PHI in NSS, however, many of the requirements the overlay specifications are based on apply to any Federal information system that contains PII or PHI, regardless of whether the system is an NSS or not. All Federal agencies including DoD must comply with public laws that apply to the Federal government’s collection, use and maintenance of PII, thus DoD invokes the CNSS Privacy Overlay since it is the best resource we know of. 

This overlay addresses Low, Moderate, and High sensitivity PII and PHI. It invokes most of the 36 privacy specific C/CEs from NIST SP 800-53 rev4, Appendix J, Privacy Control Catalog and invokes additional C/CEs from the Security Control Catalog.  It also modifies many of the already selected C/CEs in the FedRAMP Moderate and FedRAMP+ baselines by providing supplemental guidance along with parameter value changes and control extensions.  Quantities of additional C/CEs and guidance depend on both the PII sensitivity level and whether the PII meets the definition of PHI.

5.1.5.1 PII/PHI at Level 2

PII and PHI are categorized as CUI and as such must minimally be stored and processed in a Level 4 CSO.  While the Privacy Overlay provides a Business Rolodex Exception (BRE) which exempts a subset of low sensitivity PII from the protection of the overlay, this does not remove this PII from the CUI category.  Therefore at this time, no PII/PHI is permitted to be processed or stored in Level 2 CSOs. 

5.1.5.2 Effects of the Privacy Overlay on CSPs and Mission Owners

To limit the affect the listing of Privacy Overlay C/CE and their Parameter Values on the size of the main portion of the CC SRG, this section provides pointers to tables in Appendix E of Privacy Overlay C/CE in the following categories:

• FedRAMP Moderate and FedRAMP+ C/CE that are modified through Control Extensions or altered via implementation guidance or value specifications. These tables also include C/CE that are required by law or regulation:
• Table 10 - FedRAMP M C/CE Modified or Required by Regulation
• Table 11- FedRAMP+ C/CE Modified or Required by Regulation
• C/CE not included in the DoD cloud baseline which includes FedRAMP Moderate and FedRAMP+ C/CE.  This includes some C/CE designated as SLA C/CE as shown in Section 5.1.6, Security Controls/Enhancements to be optionally addressed in the Contract/SLA and some CNSSI 1253 C/CE that were not selected for inclusion in the FedRAMP+ or SLA C/CE sets:
• Table 12 - Privacy Overlay C/CE Not Included In FedRAMP M or FedRAMP+
• C/CE that are in the FedRAMP Moderate and FedRAMP+ C/CE baselines that have parameter values defined by the overlay which may modify the parameter values defined in Table 8 – FedRAMP M / FedRMP+ Control / Enhancement Parameter Values for PA Assessment:
• Table 13 - PII/PHI Parameter Values for FedRAMP and FedRAMP+ C/CE
• C/CE not included in the DoD cloud baseline which includes FedRAMP Moderate and FedRAMP+ C/CE that have parameter values defined by the overlay.
• Table 14 - PII/PHI Parameter Values for C/CE Not Included In FedRAMP M or FedRAMP+

NOTE: a comparative analysis of the Privacy Overlay C/CE to various other baselines is provided in Appendix F.  This comparison provides statistics or counts of C/CE in various categories.  This is provided for informational purposes only and may be removed from the final document or a future release of the CC SRG. 

5.1.5.3 CSO Assessment of Privacy Overlay Control/Control Enhancements

CSP CSOs that are intended to store and process PII and/or PHI (e.g., certain SaaS and PaaS offerings and potentially others) must be additionally assessed against the C/CEs that the Privacy Overlay adds to, or modifies in, the FedRAMP Moderate baseline as well as the FedRAMP+ C/CEs to receive a DoD PA for the CSO.  This includes all SLA C/CEs and the Deselected C/CE from the CNSSI 1253 M-M-x baseline (used to select the FedRAMP+ C/CEs) that show a + symbol in the overlay which are to be added to the FedRAMP+ table at the appropriate level. 

Successful Privacy Overlay assessments will result in a rider or qualifier to the DoD PA that will reference the level of PII or PHI the CSO was successfully assessed for.  E.g., CSO xyz is granted a Level 4 PA with the additional provisional authorization to handle up to Moderate sensitivity PII, or to handle some level of PII and PHI.  Privacy Overlay C/CE that are clearly the responsibility of the CSP’s customer i.e., DoD Mission / Information Owner (e.g., the required Systems of Record Notice (SORN) per TR-2), will not be assessed and will not affect the award of a DoD PA. 

It is also recognized that while IaaS and some PaaS CSOs have the potential to store and process PII and/or PHI, this is mostly at the customer’s discretion, and is not typically the intent of the CSP.  As such, Privacy Overlay assessment will not be required for the IaaS and some PaaS CSO to receive a DoD PA.

Additionally, while a CSP’s IaaS and some PaaS CSOs will not normally be assessed against the Privacy Overlay, it is recognized that there may be some C/CE that may become the responsibility of the CSP if the Mission Owner chooses to store and process PII and/or PHI in the CSO.  Typically, assessment of these C/CEs would be negotiated by the Mission Owner with the CSP.  There is also the potential that a CSP might want a DoD PA rider so that their IaaS/PaaS CSO could be pre-approved to handle such missions. 

NOTE: Some PaaS CSOs are intended to handle PII/PHI like some SaaS CSOs. These are typically very much like a SaaS CSO and as such must be assessed against the Privacy Overlay.

NOTE: more specific guidance regarding what Privacy overlay C/CEs apply to CSPs vs Mission Owners will be provided in a future release of this SRG.

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

If the Mission Owner’s cloud system/application is intended to store and process PII and/or PHI, the system/application must already comply with the privacy requirements which are codified in the Privacy Overlay.  Therefore, Privacy Overlay assessment to include PA riders must be incorporated into a Mission Owner’s CSP evaluation /selection/acquisition process and into their assessment process for their mission system’s ATO. 

NOTE: more specific guidance regarding what Privacy overlay C/CEs apply to CSPs vs Mission Owners will be provided in a future release of this SRG.

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

Table 3 shows the C/CEs designated for the Mission Owner to optionally address in the contract or SLA, over and above the FedRAMP and FedRAMP+ C/CEs which must be included by default.  While these C/CEs generally address system availability, they apply to the availability of information related to continuous monitoring, incident response, and other security issues.  It must be noted that this listing does not preclude the Mission Owner from addressing any control or enhancement from any CNSSI 1253 baseline or the NIST SP 800-53 rev4 in the contract/SLA if they need the control/enhancement to be provided/met by the CSP to secure their system or application.  Assessment and continuous monitoring of compliance with these C/CEs is the responsibility of the Mission Owner as negotiated with the CSP in attaining and maintaining the mission’s ATO.  These C/CEs are not assessed toward the award of a DoD PA at this time.

Table 3 Security Controls/Enhancements to be addressed in the Contract/SLA

5.2 Legal Considerations

This section deals with legal requirements revolving around the location of DoD information as well as who may have access to it in CSP facilities and CSOs. 

5.2.1 Jurisdiction/Location Requirements

Legal jurisdiction over information controls where DoD and US government data can be located. This is nuanced by the information being on DoD Premises.

Corresponding Security Controls: SA-9(5)

5.2.1.1 Jurisdiction/Location Requirements for DoD Off-Premises Locations

To protect against seizure and improper use by non-US persons and government entities, all data  stored and processed by/for the DoD must reside in a facility under the exclusive legal jurisdiction of the US.  CSPs will maintain all government data that is not physically located on DoD premises within the 50 States, the District of Columbia, and outlying areas of the US (as defined at FAR 2.101^[45]), unless otherwise authorized by the responsible AO, as described in DoDI 8510.01.  The contracting officer shall provide written notification to the contractor when the contractor is permitted to maintain Government data at a location outside the 50 States, the District of Columbia, and outlying areas of the United States. 

CSPs will provide the agency a list of the physical locations where the data could be stored at any given time and update that list as new physical locations are added.

5.2.1.2 Jurisdiction/Location Requirements for DoD On-Premises Locations

DoD on-premises includes DoD data centers, other facilities located on a DoD B/C/P/S, or in a commercial or another government facility (or portions thereof) under the direct control of DoD personnel and DoD security policies.  A commercial facility, in this sense, means a building or space leased and controlled by DoD.  Physical facilities may be permanent buildings or portable structures such as transit/shipping containers.  An example of the latter might be a container housing a commercial CSP’s infrastructure located adjacent to a Core Data Center (CDC) and connected to its network as if it was inside the building.

DoD CSPs will, and commercial CSPs may (under DoD contract), instantiate their cloud service architecture on DoD premises (DoD on-premises).  Interconnection with DoD networks will be interoperable IAW engineering requirements that meet cybersecurity guidance and controls.  Such implementations will be considered DoD Private. 

On-premises CSOs implemented by a DoD or non-DoD CSP which utilizes a hybrid model employing off-premises CSPs and CSOs to augment the on-premises CSO must meet the location requirements stated in Section 5.2.1.1, Jurisdiction/Location Requirements for DoD Off-Premises Locations. 

5.2.2 Cloud Deployment Model Considerations / Separation Requirements

The risks and legal considerations in using virtualization technologies further restrict the types of tenants that can obtain cloud services from a virtualized environment on the same physical infrastructure and the types of cloud deployment models (i.e., public, private, community, and hybrid) in which the various types of DoD information may be processed or stored. 

While shared cloud environments provide significant opportunities for DoD entities, they also present unique risks to DoD data and systems that must be addressed.  These risks include exploitation of vulnerabilities in virtualization technologies, interfaces to external systems, APIs, and management systems.  These have the potential for providing back door connections and CSP privileged user access to customer’s systems and data.  While proper configuration of the virtual and physical environment can mitigate many of these threats, there is still residual risk that may or may not be acceptable to DoD.  Legal concerns such as e-discovery and law enforcement seizure of non-government CSP customer/tenant’s data pose a threat to DoD data if it is in the same storage media.  Due to these concerns, DoD is currently taking a cautious approach with regard to Level 5 information. 

Infrastructure (as related to cloud services), is the physical hardware (i.e., servers and storage), and the network interconnecting the hardware that supports the cloud service and its virtualization technology (if used).  This includes the systems and networks used by the CSP to manage the infrastructure.  While the physical space in which this infrastructure is housed is part of the CSP’s infrastructure, this is not a factor in DoD’s separation restrictions except at Level 6. 

Dedicated infrastructure (as related to cloud services) refers to the cloud service infrastructure being dedicated to serving a single customer organization or a specific group of customer organizations.  A private cloud service implements dedicated infrastructure to serve one customer organization.  This SRG considers DoD as the organization which consists of all DoD components.  This SRG restricts private cloud for DoD as meaning dedicated infrastructure that serves DoD users and tenants, and designates this as a DoD private cloud.  DoD private clouds or cloud service offerings may be multi-tenant serving all or some DoD components or may be single tenant serving a single mission.  A community cloud service implements dedicated infrastructure to serve a specific group or class of customer organizations.  Since the definition of DoD private could also be considered a DoD community cloud, this SRG will use the term DoD private/community.  This SRG will also use the term Federal Government community, meaning dedicated multi-tenant infrastructure that serves both DoD components and mission owners as well as other Federal Government agencies and their mission owners. 

Corresponding Security Controls: SC-4

5.2.2.1 Impact Level 2 Location and Separation Requirements

Impact Level 2 cloud services can be offered on any of the four deployment models.  Information that may be processed and stored at Impact Levels 2 can be processed on-premises or off-premises, as long as the physical location of the information is restricted as described in Section 5.2.1, Jurisdiction/Location Requirements.

For a Level 2 PA, at this time, DoD is accepting the risk that this is adequately covered by a FedRAMP Moderate PA such that the requirement will not be additionally assessed for a Level 2 PA.   

5.2.2.2 Impact Level 4 Location and Separation Requirements

Impact Level 4 cloud services can be offered on any of the four deployment models.  Information that may be processed and stored at Impact 4 can be processed on-premises or off-premises, as long as the physical location of the information is restricted as described in Section 5.2.1, Jurisdiction/Location Requirements.  

For a Level 4 PA, the CSP must provide evidence of strong virtual separation controls and monitoring in support of the ability to meet “search and seizure” requests for non-DoD information and data without the release of DoD information and data and vice-versa. Additionally the strong virtual separation controls must prevent/mitigate/eliminate the potential vulnerability whereby one CSP customer using the same physical hardware as another CSP customer can gain access to the other’s information/data, virtual network, or virtual machines.      Monitoring must detect such unauthorized accesses and/or attempts so that incident response can occur.

5.2.2.3 Impact Level 5 Location and Separation Requirements

Information that must be processed and stored at Impact Level 5 can only be processed in a DoD private/community or federal government community cloud, on-premises or off-premises in any cloud deployment model that restricts the physical location of the information as described in Section 5.2.1, Jurisdiction/Location Requirements.  

The following also applies:

• Only DoD private/community or Federal Government community clouds are eligible for Impact Level 5.
• Each deployment model may support multiple missions or tenants / missions from each customer organization.
• Virtual/logical separation between DoD and Federal Government tenants / missions is sufficient.  Virtual/logical separation between tenant/mission systems is minimally required.
• Physical separation from non-DoD/non-Federal Government tenants (i.e., public, local/state government tenants) is required. 
• The CSP restricts potential access to DoD’s and the community’s information to CSP employees that are U.S. Citizens

NOTE: While multi-tenant CSOs marketed as ITAR compliant”, “government clouds”, or “clouds for government” might restrict data location to US jurisdiction, and might restrict the personnel that manage the CSO to , they do not necessarily meet the standard for “dedicated” to the Federal Government or DoD.  If the cloud service, or the underlying infrastructure it resides on, hosts any non-Federal US government tenant, (such as state, local, or tribal governments, industry/academic partners, or foreign governments) it is considered a public cloud for purposes of this SRG. As such, while DoD sees this as adequate for Level 4, this alleged attribute is not sufficient for CSP selection by DoD Mission Owners for Level 5 missions. This restriction might be waived by DoD if the CSP and CSO can demonstrate sufficient separation between tenant’s workloads and data and/or the general government community and Federal Government Community.

5.2.2.4 Impact Level 6 Location and Separation Requirements

Impact Level 6 is reserved for the storage and processing of information classified up to SECRET.  Information that must be processed and stored at Impact Level 6 can only be processed in a DoD private/community or Federal Government community cloud, on-premises or off-premises in any cloud deployment model that restricts the physical location of the information as described in Section 5.2.1, Jurisdiction/Location Requirements. 

The following applies:

• Impact Level 6 information up to the SECRET level must be stored and processed in a dedicated cloud infrastructure located in facilities approved for the processing of classified information, rated at or above the highest level of classification of the information being stored and/or processed.
• Impact Level 6 CSO infrastructure is considered to be a SIPRNet enclave and as such will be a closed self-contained environment for the CSO processing, storage, and management planes only connected to SIPRNet.
• Each deployment model may support multiple SECRET missions from multiple customer organizations.
• Virtual/logical separation between DoD and Federal Government tenants / SECRET missions is sufficient.
• Virtual/logical separation between tenant/mission systems is minimally required.
• Physical separation from non-DoD/non-Federal Government tenants (i.e., public, local/state government tenants) is required.

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

Under Federal law, the Federal government reserves the right for law enforcement officials to perform criminal investigations of Federal Government employees and elected officials as well as anyone with access to Federal Government information for misconduct, misuse of such data, or for incident investigation.  Such criminal investigations may include a need for E-Discovery on Federal government information to collect digital evidence. As such the CSP must be able to segregate Federal government information from non-Federal Government information within the CSO.  The granularity of separation must be at the Federal government Mission Owner level.  The CSP must also ensure this segregation requirement flows down to all CSP/Integrator subcontracted CSP/CSOs.  The CSP and subcontractors must then be capable, upon request of the contracting officer(s) or in response to a subpoena, of isolating one or more Federal Government Mission Owner’s data into an environment where it may be reviewed, scanned, or forensically evaluated in a secure space or via secure remote connection with access limited to authorized Government personnel identified by the Contracting Officer, and without the CSP’s involvement or provide a forensic digital image of the requested Federal government information. See Section 6.4.4, Digital Forensics in the Cloud and Support for Law Enforcement/Criminal Investigation for additional information on capturing and protecting forensic digital images.  

5.2.3 DoD Data Ownership and CSP Use of DoD Data

All DoD information/data placed or created by DoD users in a CSP’s CSO is owned by the DoD, the Mission Owner, and/or their Information Owner unless otherwise stipulated in the CSP’s contract with the DoD.  The CSP has no rights to the DoD’s information/data.  DoD information/data includes logs and monitoring data created within and by a Mission Owner’s system/application implemented in IaaS/PaaS CSOs as well as logs created for and provided to the Mission Owner related to their usage and management of the CSO.  DoD also maintains ownership of all information/data created by the CSP/CSO for DoD if such activities are part of the contract.  CSPs seeking a DoD PA must agree that DoD remains the owner of all DoD data in a CSO. 

CSPs are prohibited from using DoD data in any way other than that required to provide contracted services to DoD (e.g., customer access/usage logs used for billing)  This means that the CSP may not “data mine” DoD email, files, information in data bases, or communications for any purpose other than that stipulated in the contract.  

The CSP maintains ownership of all logs and monitoring data created within the CSO related to the Mission Owner’s usage and management of the CSO.  This includes logs related to customer access and usage used for billing, data used for capacity planning for the CSO, monitoring data related to malicious activities or CSO health. This also includes all audit content specified by the AU-2 security control for the time period specified by AU-11. While the CSP retains ownership of this information, some or all must be shared with the Mission Owner for the purpose of planning, forensics, billing validation, retention, etc.  The ownership of the copies of this information shared with the DoD/Mission Owner is maintained by the DoD/Mission Owner.

Additionally, all DoD information/data and CSP information/data shared with the Mission Owner must be made available for off-boarding and backup IAW sections 5.8, Data Retrieval and Destruction for Off-boarding from a CSO and 5.12 - Backup. 

Mission Owners must address data ownership in the contract.

Related Security Controls: AC-23

5.3 Ongoing Assessment

Both FedRAMP and DoD require an ongoing assessment and authorization capability for CSOs providing services to the DoD.  This capability is built upon the DoD RMF and the FedRAMP continuous monitoring strategy, as described in the Guide to Understanding FedRAMP^[46]and FedRAMP Continuous Monitoring Strategy Guide.^[47]  These ongoing assessment processes which are discussed in the following sections include continuous monitoring and change control.

Ongoing assessment processes do not differ by impact level, though the artifacts produced as part of those processes may.  (e.g., Level 2 CSOs will have fewer controls to monitor than Level 4 CSOs.)  These processes will differ, however, based on whether or not CSOs are part of the FedRAMP catalog or have a FedRAMP JAB PA.  These differences are based on the division of responsibility over the set of security controls and the ability of DoD to access the artifacts produced as part of the FedRAMP processes.

Ongoing assessment responsibility mirrors the divided responsibilities and control inherent in cloud systems.  FedRAMP’s processes will be leveraged for all CSOs in the FedRAMP catalog. This process, however, only covers the portion of the system that is governed by the FedRAMP PA, such as the FedRAMP Moderate security controls.  The DoD change control process will cover the portion of the system that is governed by the DoD PA, such as the FedRAMP+ security controls.  Ongoing assessment of controls that are levied by the Mission Owner, such as those specified in the SLA, and do not fall under the FedRAMP or DoD PAs is the responsibility of the Mission Owner.  This division of responsibility is shown in Figure 3.

Figure 3 - Ongoing Assessment Division of Responsibility

5.3.1 Continuous Monitoring

This section pertains specifically to continuous monitoring of security controls, as defined by CNSSI 4009 and NIST SP 800-137.  Further information on monitoring activities performed as part of Computer Network Defense, are described in Section 6, Cyber Defense and Incident Response.

Once a DoD PA is granted, the CSP is expected to maintain the security posture of the CSO through continuous and periodic vulnerability scans, DoD annual assessments, incident management, and effective implementation of operational processes and procedures.  Integral to this is periodic reporting to the appropriate AO. The continuous monitoring artifacts required to maintain a DoD PA are the same as those required by FedRAMP. (Annual assessments, monthly vulnerability scans, etc.)  However, those artifacts must include additional information for FedRAMP+ controls and DoD requirements.

Continuous monitoring data flows will differ for CSPs depending on whether their CSOs have a FedRAMP JAB PA, a 3PAO assessed non-DoD Federal Agency ATO, or DoD Assessed PA (as described in Section 4).  These data flows are reflected in Figure 4, Figure 5, and Figure 6 respectively.

In some cases, CSPs such as, but not limited to, DoD Private CSOs or CSOs in the FedRAMP catalog with a non-DoD Agency ATO will provide continuous monitoring artifacts directly to DISA.    In such cases, the CSP will utilize commercial standard formats (e.g., comma-separated values, XML) that enable DoD to automate the ingest of continuous monitoring data. 

NOTE: For XML exchanges, National Information Exchange Model (NIEM) based XML is the preferred format IAW DoDI 8320.07^[48], August 3, 2015. Additional information regarding this format can be found at www.niem.gov. 

All CSP CSOs are required to have FedRAMP annual assessments performed by a 3PAO for the maintenance of their FedRAMP PA.  DoD also requires annual assessments performed by a 3PAO or approved DoD SCA organization for the maintenance of their Level 4 and above DoD PA.  It is expected that CSOs in both the FedRAMP and DoD catalogs will have a single annual assessment to cover this requirement for both FedRAMP and DoD.  CSOs in the FedRAMP catalog will follow the process described in the FedRAMP Continuous Monitoring Strategy Guide^[49].  DoD Annual assessments will minimally include the set of controls listed in Appendix A of that document, as well as any other controls specified by the DISA AO.  CSOs with a DoD PA that are not in the FedRAMP catalog will follow the DoD RMF process for continuous monitoring and associated assessments.

Corresponding Security Controls: CA-7

5.3.1.1 CSOs in the FedRAMP Catalog

As described in Section 4.1, Assessment of Commercial/Non-DoD Cloud Services, the CSOs in the FedRAMP catalog that are eligible for DoD PAs include CSOs having a JAB PA (which is 3PAO assessed) or a 3PAO assessed Federal Agency ATO.  All reports required by the FedRAMP Continuous Monitoring Strategy Guide, including self- assessments, for these CSOs will be provided to the FedRAMP Information System Security Officer (ISSO).  These will be reviewed by the FedRAMP TRs (which include DoD personnel) and approved by the JAB if necessary. 

Continuous monitoring requirements for DoD are the same as those for FedRAMP, except that all reports and artifacts for FedRAMP+ C/CEs will be provided directly to DISA AO representatives as the DoD single point of CSP contact for this information.  DISA will share appropriate continuous monitoring information (FedRAMP and FedRAMP+) with Mission Owners, AOs, and Cyber Defense Service Providers (CDSPs). 

The information will be used by Mission Owners, their AOs, and the DISA AO to assess and authorize the CSO.  Those evaluations will inform decisions to continue the ATO for the Mission Owner’s system and the PA for the CSP respectively.  The DISA AO will coordinate closely with Mission Owners in the event that the withdrawal of a PA must be considered upon the basis of this requirement.

Figure 4 shows the normal flow of continuous monitoring information if the CSP has a FedRAMP JAB PA. 

Figure 4 – DoD Continuous Monitoring for CSOs with a FedRAMP JAB PA

Figure 5 shows the flow of continuous monitoring information if the CSO has a 3PAO assessed non-DoD Federal Agency ATO listed in the FedRAMP catalog. Since the FedRAMP JAB does not control the Agency ATO, information may not flow from the CSP to the FedRAMP PMO.

Figure 5 – DoD Continuous Monitoring for FedRAMP CSOs with a 3PAO assessed Non-DoD Federal Agency ATO

5.3.1.2 DoD Assessed CSOs

Figure 6 shows the flow of continuous monitoring information for DoD private/community CSOs that have a DoD PA and ATO, but are not in the FedRAMP catalog. Continuous monitoring will be directed by the DoD RMF, rather than the FedRAMP Continuous Monitoring Strategy Guide.  As part of the RMF authorization process, CSPs will create a continuous monitoring strategy that meets DoD requirements in the System Security Plan.  All reports and artifacts required by that continuous monitoring strategy will be provided by the CSP to DISA.  DISA will, in turn, disseminate those artifacts to all Mission Owners utilizing that CSO, the DISA AO, and the Computer Network Defense Service Provider (CDSP) entities as defined in Section 6, Cyber Defense and Incident Response.

Figure 6 – DoD Continuous Monitoring for DoD Assessed CSOs

5.3.2 Change Control

The DoD change control process for CSOs mirrors that of FedRAMP, with a focus on how changes affect the DoD PA and the security of hosted mission systems/applications and information.

The FedRAMP Continuous Monitoring Strategy Guide, dated June 6, 2014, states:

“Systems are dynamic and FedRAMP anticipates that all systems are in a constant state of change.  Configuration management and change control processes help maintain a secure baseline configuration of the CSP’s architecture.  Routine day-to-day changes are managed through the CSP’s change management process described in their Configuration Management Plan.

However, before a planned major significant change takes place, CSP’s must perform a Security Impact Analysis, consistent with control CM-4, to determine if the change will adversely affect the security of the system.  The Security Impact Analysis is a standard part of a CSP’s change control process as described in the CSP’s Configuration Management Plan.”

As with FedRAMP, CSPs must give DoD 30-day notice prior to major significant changes.  If a change is made without approval that affects the risk posture of the system, the DISA AO can revoke the DoD PA.  As with continuous monitoring, the change control process will differ for CSPs depending on if they are in the FedRAMP catalog and if they have a DoD assessed PA or ATO.  Figure 7, Figure 8, and Figure 9 show these change control processes.

Corresponding Security Controls: CM-3

5.3.2.1 CSOs in the FedRAMP Catalog

The FedRAMP Continuous Monitoring Guide defines a major significant change as a change to the scope of an approved PA or an impact to the authorization boundary of the CSO.  The FedRAMP Significant Change Security Impact Analysis Form (provided by the FedRAMP ISSO to CSPs reporting a significant change) enumerates major significant changes.  The review of major significant changes will be performed at multiple layers, as reflected in Figure 7. As part of the FedRAMP process, when the CSO has a FedRAMP PA, the CSP will notify their AO of any planned major significant change and subsequently provide a Security Impact Analysis for the planned change.  The planned change will be reviewed by the ISSO and/or JAB Technical Representatives (TRs), and then forwarded to the JAB for approval.  During ISSO review, the DoD JAB TR will inform the FedRAMP ISSO if planned changes will adversely affect the security of the information hosted by the CSO for DoD cloud customers.  The DoD JAB TR will notify DISA, who will in turn notify all Mission Owners utilizing that CSO, the DISA AO, and the Cyber Defense Service Provider (CDSP) entities as defined in Section 6, Cyber Defense and Incident Response.

When a CSO is included in the FedRAMP catalog, but does not have a JAB PA, the CSP will notify DISA directly in addition to any other required points of contact.  (E.g. A CSP with a non-DoD agency ATO would notify both that agency and DISA).   This is required because the FedRAMP JAB does not control the Agency ATO, and information may not flow from the CSP to the FedRAMP PMO and DISA.  DISA will in turn notify all Mission Owners utilizing that CSO, the DISA AO, and the CDSP entities as defined in Section 6, Cyber Defense and Incident Response. The Security Impact Analysis must additionally cover the FedRAMP+ C/CEs.  Once informed, DISA will review the proposed change to assess if it will, and ensure it will not, adversely affect the security of the DoD Information Network (DoDIN) as a whole or the DISN with respect to the impact level at which it is authorized.  Any updates to the FedRAMP Security Package will be forwarded to DISA.

FedRAMP requires a security assessment be performed by a 3PAO after a major significant change is implemented, with a corresponding Security Assessment Report created.  CSPs must also include all FedRAMP+ C/CEs in post-change assessments to meet DoD requirements.  DISA will notify affected Mission Owners of proposed major significant changes and provide its assessment of the change within the scope of the CSO PA.  Mission Owners are responsible for assessing the effects of proposed changes for effects that fall within the scope of their SLAs. 

Figure 7 shows the normal flow of major significant change information if the CSP has a FedRAMP JAB PA. 

Figure 7 - DoD Change Control Process for CSPs CSOs with a FedRAMP JAB PA

Figure 8 shows the normal flow of significant change information if the CSO has a 3PAO assessed Non-DoD Federal Agency ATO listed in the FedRAMP catalog. Since the FedRAMP JAB does not control the Agency ATO, information from the CSP may not flow from the authorizing agency to the FedRAMP PMO.  To avoid the possibility of DoD not being informed of potential changes, CSPs must send change requests to DISA in addition to the authorizing agency.

Figure 8 - DoD Change Control Process for FedRAMP CSPs CSOs with a 3PAO assessed Federal Agency ATO

5.3.2.2 DoD Assessed CSOs

Figure 9 shows the flow of significant change for non-FedRAMP CSOs having a DoD PA or ATO assessed by a DoD SCA organization and authorized by a DoD AO.  The review of significant change information will be directed by the DoD RMF, rather than the FedRAMP change control process.  CSPs will have similar responsibilities, but will report directly to DISA.  DISA will, in turn, disseminate those artifacts to all Mission Owners utilizing that CSO, the DISA AO, and the CDSP entities as defined in Section 6, Cyber Defense and Incident Response. These entities will review the proposed change to ensure it will not adversely affect the security posture of the CSO with respect to its PA or ATO.  The planned change will also be reviewed by the Mission Owners utilizing the CSO for any adverse impact with regard to their specific usage of the CSO.

Figure 9 - DoD Change Control Process for DoD Self-Assessed CSPs/CSOs

5.4 CSP use of DoD Public Key Infrastructure (PKI)

In accordance with FedRAMP's selection of IA-2(12) which states “The information system accepts and electronically verifies Personal Identity Verification (PIV) credentials” and the FedRAMP supplemental guidance which states “Include Common Access Card (CAC), i.e., the DoD technical implementation of PIV/FIPS 201/HSPD-12”, CSPs are required to integrate with and use the DoD PKI for DoD entity authentication.  (E.g., A web portal that DoD and Federal Government Mission Owner’s privileged users log into to configure the CSO.) 

The following sections describe how the CSP fulfills its responsibilities with additional detail in the supporting subsections:

Impact Level 2:Whenever a CSP is responsible for authentication of entities and/or identifying a hosted DoD information system, the CSP will use DoD PKI certificates in compliance with DoDI 8520.03.  CSPs will enforce the use of a physical token referred to as the “Common Access Card (CAC)” or “Alt Token” for the authentication of DoD privileged users.  CSPs must make use of DoD Online Certificate Status Protocol (OCSP) or Certificate Revocation List (CRL) resources for checking revocation of DoD certificates and DoD Certificate Authorities; and must follow DoD instructions and industry best practices for the management and protection of cryptographic keys.

Impact Levels 4/5: Whenever a CSP is responsible for authentication of entities and/or identifying a hosted DoD information system, the CSP will use DoD PKI certificates in compliance with DoDI 8520.03.  CSPs will enforce the use of a physical token referred to as the “Common Access Card (CAC)” or “Alt Token” for the authentication of DoD privileged and DoD non-privileged users.  CSPs must make use of DoD OCSP or CRL resources for checking revocation of DoD certificates and DoD Certificate Authorities; and must follow DoD instructions and industry best practices for the management and protection of cryptographic keys.  DoD 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. 

Impact Level 6: Whenever an on-premises CSO is responsible for authentication of DoD entities and/or identifying a hosted DoD information system, the CSP will use NSS PKI certificates in compliance with DoDI 8520.03 and CNSSP-25.  CSPs will enforce the use of a physical token referred to as the CNSS Secret Internet Protocol Router Network (SIPRNet) Hardware Token for the authentication of DoD Mission owner and CSP privileged and non-privileged end users.  When implementing NSS PKI, CSPs must make use of NSS OCSP or CRL resources for checking revocation of NSS certificates and NSS Certificate Authorities; and must 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. 

NOTE: A CSP must PK enable their customer ordering/service management portals for all service offerings and their SaaS service offerings for general DoD user access at levels 4 and up or provide a customer configurable service offering to permit PK enabling and integration with the required PKI.  For complete compliance the CSP will integrate with the DoD PKI and the Federal PKI for levels 2 through 5.  For Level 6 the CSP will integrate with the NSS (SIPRNet) PKI.  Both the DoD and NSS PKI are operated by DISA^[50] while the Federal PKI is operated by GSA^[51].  PK enabled customer ordering/service management portals may require a separate URL or dedicated application / application interface as best determined by the CSP to meet the Federal Government requirement.

Corresponding Security Controls: IA-2, IA-2(1), IA-2(2), IA-2(3), IA-2(8), IA-2(11), IA-2(12), IA-5(2), IA-5(11), IA-7, IA-8

NOTE: NSS PKI and SIPRNet token requirements for off-premises Level 6 CSPs and CSOs need to be coordinated with OUSD(I) and DSS. Associated policies are addressed above in Section 4.2, Assessment of DoD Cloud Services and Enterprise Services Applications under the Impact Level 6 topic.  Coordinated guidance and requirements for off-premises CSPs and their CSOs for a DoD Level 6 provisional authorization may appear in a future release of the CC SRG. This note applies to all subsections in Section 5.4.

5.4.1 Identification, Authentication, and Access Control Credentials

DoDI 8520.03, Identity Authentication for Information Systems is the DoD policy that defines the credentials that DoD privileged and non-privileged users must use to identify themselves to DoD information systems to be authenticated before being granted access.  It also defines the credentials that DoD information systems use to identify themselves to each other.  This is fully applicable to DoD information systems instantiated on cloud services.  Additionally, CNSS Policy #25 and CNSSI 1300 provide similar guidance for NSS.  For the purpose of this discussion, the process of identification and authentication will be referred to as I&A. 

5.4.1.1 Mission Owner Credentials for CSP and Mission System Interfaces

This section defines the Mission Owner access control credentials required at each information impact level IAW DoDI 8520.03 in the following categories:

• Mission Owner privileged user access to the CSP’s customer ordering and service management interfaces or portals for all service offerings (IaaS/PaaS, SaaS).
  • Integration with DoD PKI is typically a CSP responsibility.  Minimally, the CSP is responsible for providing capabilities that enable Mission Owners to configure a CSP service offering that integrates with DoD PKI.
• Mission Owner Non-privileged user (i.e., mission application end-users) access to CSP SaaS offerings.
  • Integration with DoD PKI is typically a CSP responsibility.  Minimally, the CSP is responsible for providing capabilities that enable Mission Owners to configure a CSP service offering that integrates with DoD PKI.
• Non-privileged user access to Mission Owner’s systems and applications instantiated on IaaS/PaaS.  (i.e., mission application end-users)
  • Implementation is a Mission Owner responsibility.
• Mission Owner privileged user access to their systems and applications instantiated on IaaS/PaaS for the purpose of administration and maintenance. 
  • Implementation is a Mission Owner responsibility.

Table 4 lists the Mission Owner credential types required at each impact level for various use cases and the policy under which they are required.  The DoD Policy column identifies the authentication methods that Mission Owners must implement for use in the systems and applications they instantiate in a CSP’s CSO.  This is primarily applicable to IaaS/PaaS.  The IA-2(12) column identifies the authentication methods that CSPs must implement for use in the service offerings they provide to their DoD customer.  This primarily applies to SaaS and CSP's customer ordering/service management portals.

Table 4 - Mission Owner Credentials

Impact Level	Implemented by Mission Owner  IAW DoD policy	Implemented by CSP IAW FedRAMP's selection of IA-2(12):
Level 2	Non-privileged user access to publicly released information requires no I&A, unless the information owner requires it.  If required, the Mission Owner determines the type of I&A to be used.  Non-privileged user access to non-publicly released non-CUI and non-critical mission information minimally requires I&A through the use of a User Identifier (UID) and password that meets DoD length and complexity requirements.  The Mission Owner is encouraged to require the use of a stronger I&A technology in accordance with the sensitivity of the private information (e.g., UID/Password with two-step verification, two-factor token based onetime password, DoD-approved PKI token/certificate, CAC/PKI, etc.) Mission Owner Privileged users’ access to administer Mission Owner systems/applications instantiated on IaaS/PaaS requires the use of DoD CAC/PKI or Alt Token/PKI.	Non-privileged user access to non-publicly released non-CUI and non-critical mission information in the CSP’s SaaS offering minimally requires I&A through the use of a User Identifier (UID) and password that meets DoD length and complexity requirements.  The Mission Owner is encouraged to require the use of a stronger I&A technology in accordance with the sensitivity of the private information (e.g., two-factor token based onetime password, DoD-approved[52] PKI token/certificate, CAC/PKI, etc.) Mission Owner’s privileged users’ access to the CSP's customer ordering/service management portals for all service offerings requires the use of DoD CAC/PKI or Alt Token/PKI.
Level 4 & 5	Non-privileged user access to CUI, non-CUI critical mission data, and/or unclassified NSS (L5) requires the use of DoD CAC/PKI or other DoD-approved PKI[53].  Mission Owner Privileged users’ access to administer Mission Owner systems/applications instantiated on IaaS/PaaS requires the use of DoD CAC/PKI or Alt Token/PKI.	Non-privileged user access to CUI, non-CUI critical mission data, and/or unclassified NSS (L5) information in the CSP’s SaaS offering requires the use of DoD CAC/PKI or other DoD-approved PKI[54].  Mission Owner’s privileged users’ access to the CSP's customer ordering/service management portals for all service offerings requires the use of DoD CAC/PKI or Alt Token/PKI.
Level 6	Non-privileged user access to classified information requires the use of NSS SIPRNet Token/PKI. Mission Owner Privileged users’ access to administer Mission Owner systems/applications instantiated on IaaS/PaaS requires the use of NSS SIPRNet Token/PKI.	Non-privileged user access to classified information in the CSP’s SaaS offering requires the use of NSS SIPRNet Token/PKI. Mission Owner’s privileged users’ access to the CSP's customer ordering/service management portals for all service offerings requires the use of NSS SIPRNet Token/PKI.

NOTE: Mission Owner personnel that are involved in managing any portion of a CSP’s service offering or who are able to order services from the CSP (i.e., possesses accounts on the CSP’s customer ordering and service management interfaces or portals for any service offering (IaaS/PaaS, SaaS)), are considered Privileged Users by DoD and therefore are required to authenticate using DoD CAC, or Alt Token IAW DoDI 8520.03.

NOTE: It is recognized that some Level 4/5 systems must support some non-privileged user populations (e.g., retirees) that cannot receive a DoD CAC/PKI or other DoD-approved PKI authenticator to gain access to CUI (e.g., PII/PHI) for which they have a legal right to access.  In cases such as these the Mission Owner will seek AO approval to categorize such data as Unclassified Sensitivity Level 1 IAW DoDI 8520.03, which would permit the use of Credential Strength A.  (E.g. A password as an authenticator)  While such populations must typically use a UID and strong password managed IAW DoD password policy, the Mission Owner is encouraged to implement stronger measures such as two-step verification where an access code is sent to the user via a different communications path than the one accessing the web site or application after entering the UID/password combination.  In effect, this becomes a two-factor authentication system.

5.4.1.2 CSP Privileged User Credentials

This section defines the I&A and access control credentials that the CSP privileged users must use when administering the CSP’s infrastructure supporting Mission Owner’s systems.

Impact Levels 2/4: IAW the separation requirements for Levels 2 and 4 described in Section 5.2.2.1, Impact Level 2 Location and Separation Requirements, and 5.2.2.2 ,Impact Level 4 Location and Separation Requirements, and FedRAMP's selection of IA-2(1) and IA-2(3), the CSP must minimally implement two factor authentication for CSP privileged user access to administer and maintain CSP infrastructure supporting Federal and DoD contracted services.  While the best practice of using a hardware token technology implementing a multi-factor one-time password or PKI certificate technology solution similar to DoDI 8520.03 Credential Strength D is preferred, these identity credentials minimally use a multi-token solution or a multi-factor one-time password solution similar to DoDI 8520.03 Credential Strength C. 

Impact Level 5: IAW the separation requirements for Level 5 described in Section 5.2.2.3, Impact Level 5 Location and Separation Requirements and DoD policy, the CSP must implement a strong two-factor I&A capability for CSP privileged user access to administer and maintain dedicated CSP infrastructure supporting Federal and DoD contracted services.  The strong two-factor I&A capability must be dedicated to the dedicated CSP infrastructure.  These identity credentials minimally use a hardware token technology implementing a multi-factor one-time password or PKI certificate technology solution similar to DoDI 8520.03 Credential Strength D. 

NOTE: While DoDI 8520.03 requires that all administrators of DoD or partner managed systems use identity Credential Strength E (i.e., hardware token PKI technology issued by an identity credential service provider that is either a Federal agency, an approved shared service provider under the Federal PKI Policy Authority Program, or an identity credential service provider that has been specifically approved by the DoD CIO as a Credential Strength E service provider e.g., DoD CAC or ALT) for privileged access to DoD systems, DoD is not enforcing this requirement on CSP infrastructure administrators / privileged users managing CSP assets at this time.

Impact Level 6: IAW the separation requirements for Level 6 described in Section 5.2.2.4, Impact Level 6 Location and Separation Requirements and CNSS policy, the CSP must implement SIPRNet Token/PKI authentication for CSP privileged user access to administer and maintain dedicated CSP infrastructure supporting Federal and DoD contracted Level 6 services connected to SIPRNet.

5.4.2 Public Key (PK) Enabling

Public Key (PK) enabling refers to the process through which hosts and applications are enabled to hold or use PKI certificates for the following:

• Identifying themselves to other hosts. 
• Establishing secure communications paths.
• Accepting DoD PKI certificates for system and user authentication. 
• Validating the validity of PKI certificates while making use of the DoD OCSP responder resources and/or CRL resources.

The IASE web site page Public Key Infrastructure (PKI) and Public Key Enabling (PKE)^[55] provides information needed to PK-enable Mission Owner’s systems/applications instantiated on CSP’s IaaS/PaaS offerings and CSP’s PK-enabling of SaaS offerings and service ordering/management portals/interfaces. 

5.5 Policy, Guidance, Operational Constraints

DoD-specific policy, guidance and operational constraints must be followed as appropriate by CSPs.  DISA will evaluate CSP submitted equivalencies to any specific security control, SRG, or STIG requirement on a case by case basis.

5.5.1 SRG/STIG Complianc

Mission Owners must utilize all applicable DoD SRGs and STIGs to secure all Mission Owner systems and applications instantiated on CSP’s IaaS and PaaS at all levels.

CSP’s CSOs are subject to the FedRAMP selected SP 800-53 security control CM-6.  This is applicable to all infrastructure, hardware and software, which constitutes and supports the CSP’s CSO whether it is IaaS, PaaS, or SaaS.  CSOs are assessed under FedRAMP in accordance with the security configuration checklists specified in the FedRAMP value. 

All STIGs and SRGs can be found on DISA’s IASE web site^[56] along with an SRG/STIG Applicability Guide^[57].

DoD recommends that STIGs and/or SRGs be used to fulfill the CM-6 baseline configuration requirement for systems that support DoD systems as follows:

Impact Level 2:  While the use of STIGs and SRGs is preferable, industry standard baselines such as those provided by the Center for Internet Security are an acceptable alternative to the STIGs and SRGs. 

Impact Levels 4/5/6:  STIGs are applicable if the CSP utilizes the product a STIG addresses.  SRGs are applicable in lieu of STIGs if a product specific STIG is not available.  However, the SP 800-53 control applies whether or not a STIG or SRG is available. 

For dedicated infrastructure that only serves DoD tenants, CSPs must utilize all applicable DoD STIGs and/or SRGs to secure all DoD contracted cloud computing services.  This applies at levels 4 and above for IaaS, PaaS, and SaaS offerings.

Corresponding Security Controls: CM-6

5.6 Physical Facilities and Personnel Requirements

The following sections discuss facility and personnel requirements as they align to the impact levels. 

5.6.1 Facilities Requirements

Impact Level 2:CSP data processing facilities supporting Level 2 information will meet the physical security requirements defined in the FedRAMP Moderate baseline.

Impact Levels 4 and 5:CSP data processing facilities supporting Level 4 and 5 CSOs/information will meet the physical security requirements defined in the FedRAMP Moderate baseline as well as any FedRAMP+ C/CEs related to physical security. 

Impact Level 6:DoD data on-premises processing facilities that support cloud services infrastructure and classified service offerings will be housed in facilities (designated as a secure room) designed, built, and approved for open storage commensurate with the highest classification level of the information stored, processed, or transmitted as defined in DoDM 5200.01 Volume 3, DoD Information Security Program: Protection of Classified Information^[58]. 

<5.6.2 CSP Personnel Requirements

The concept of cloud operations, given the shared responsibilities between multiple organizations along with the advanced technology being applied within this space, can impact personnel security requirements.  The ability for a CSP’s personnel to alter the security controls/environment of a provisioned offering and the security of the system/application/data processing within the offering may vary based on the processes/controls used by the CSP.  The components of the underlying infrastructure (e.g., hypervisor, storage subsystems, network devices) and the type of service (e.g., IaaS, PaaS, SaaS) provided by the CSP will further define the access and resulting risk that CSP’s employees can pose to DoD mission or data.  While CSP personnel are typically not approved for access to customer data/information for need-to-know reasons (except for information approved for public release), they are considered to be able to gain access to the information through their duties.

Access to DoD information at the various levels above Level 2 is limited by national affiliation. For other than US Citizens or Non-Citizen US Nationals as defined in 8 U.S. Code § 1408^[59], national affiliation is defined in 22 CFR 120.15^[60] – US person and 120.16 – Foreign person. 

The limitations by Information Impact Level are as follows:

Impact Level 2: CSP personnel having access to the systems processing/storing DoD public information may be US Citizens, US Nationals, US persons, or Foreign persons. i.e., there is no restriction.

Impact Level 4/5: CSP personnel having access to the systems processing/storing DoD CUI information or to the information itself at Impact Level 4/5 must be US Citizens, US Nationals, or US Persons. No Foreign persons may have such access.

Impact Level 6: CSP personnel having access to systems processing/storing classified information or to the information itself must be US Citizens.

Corresponding Security Controls: PS-2, PS-3

5.6.2.1 CSP Personnel Requirements – PS-2: Position Categorization  

The FedRAMP Moderate baseline includes the personnel security controls PS-2, PS-3, and enhancement PS-3(3).  Under PS-2, the CSP is required to “assign a risk designation to all organizational positions” and “Establish screening criteria for individuals filling those positions”.  Supplemental guidance states “Position risk designations reflect Office of Personnel Management (OPM) policy and guidance.”  The OPM position designation process takes into account the duties, level of supervision, and the scope over which misconduct might have an effect (i.e., worldwide/government-wide, multi-agency, or agency).  For IT system and information access it also takes into account the sensitivity level of the information accessed (i.e., non-CUI, CUI, and classified). 

The OPM Position Designation System October 2010 document^[61] and OPM Position Designation Tool^[62] are provided to enable Federal Agencies a methodical and consistent means to determine position sensitivity for National Security Positions (e.g., positions concerned with the protection of the Nation from foreign aggression or espionage or positions that require regular access to classified information) and Public Trust Positions (e.g., positions at the high or moderate risk levels, which includes responsibility for protection of information security systems).  Position risk levels are determined using the Position Designation Tool.  A position may have both National Security and Public Trust considerations that will jointly impact the sensitivity level and ultimately the type of security investigation required.  The Position Sensitivity Tool will be used to determine position sensitivity, position risk levels and investigation requirements for key CSP personnel.

DoD’s primary concern is CSP personnel with direct access to or the ability to gain access to DoD information, or that have responsibilities that can affect the security of the information technology processing, storing, or transmitting that information.  Under OPM policy, such a person with access to CUI or classified information is designated as filling a position designated as “critical-sensitive” or “high risk”.  However, if the person’s “work is carried out under technical review of a higher authority” (i.e., a person holding a “critical-sensitive” or “high risk” position), then the position may be designated as “noncritical-sensitive” or “moderate risk”.  Positions only having access to non-CUI and publicly released information could have a designation of “non-sensitive” or “low risk”.  All positions are considered to have some level of “public trust”.

From a DoD policy perspective under PS-2 and IAW DoD 5200.2-R, Personnel Security Program^[63] Category I automated data processing (ADP) (ADP-1 or IT-1), positions include those in which an individual is responsible for the planning, direction, and implementation of a computer security program; has major responsibility for the direction, planning and design of a computer system, including the hardware and software; or can access a system during the operation or maintenance in such a way and with a relatively high risk for causing grave damage or realize a significant personal gain.  These positions are designated “critical-sensitive”.  Category II automated data processing (ADP) (ADP-2 or IT-2) positions include those in which an individual may have the same responsibilities listed for ADP-1 but whose work is technically reviewed by a higher authority of the ADP-I category to insure the integrity of the system.  These positions are designated “noncritical-sensitive”.  These designations are consistent with the OPM Position Designation System document and automated tool.

To receive a DoD PA, the CSP must demonstrate that their personnel position categorization and compliance with PS-2 is equivalent to the OPM position designations for the similar CSP positions to the “critical-sensitive” (e.g., DoD’s ADP-1) or “high risk”; “noncritical-sensitive” (e.g., DoD’s ADP-2) or “moderate risk”; and/or “non-sensitive” or “low risk” (i.e., access to only non-CUI and public information) position designations.  These designations drive the level of screening to be established IAW the second half of PS-2 and for PS-3.

5.6.2.2 CSP Personnel Requirements – PS-3: Background Investigations

Under PS-3 and PS-3(3), the CSP is required to “Screen individuals prior to authorizing access to the information system”, and re-screen IAW an organizational defined frequency.  PS-3(3) addresses “additional personnel screening criteria” for information “requiring special protection” such as CUI. 

Per the FedRAMP supplemental guidance for PS-3, found in the FedRAMP Control Specific Contract Clauses v2, June 6, 2014 document^[64], an agency must stipulate, “IAW OPM and OMB requirements”, the type of background investigation required for CSP personnel having access to or who can gain access to information.  For DoD, the minimum designations are defined by level as follows:

Impact Level 2:CSP personnel supporting Level 2 cloud service offerings will meet the personnel security requirements and undergo background checks as defined in OPM policy IAW the FedRAMP Moderate baseline.  As such the minimum background investigation required for CSP personnel having access to Level 2 information based on a “non-sensitive” or “low risk” position designation (i.e., position only has access to public and non-CUI non-critical mission information), is a National Agency Check and Inquiries (NACI).  The position sensitivity or risk level and resulting investigation may be elevated beyond the minimum requirement as determined by the Mission Owner / AO, based on additional risk considerations.  For instance if the Confidentiality, Integrity or Availability (CIA) of information is determined to be based on a “noncritical-sensitive” or “moderate risk” position using the tool, a National Agency Check with Law and Credit (NACLC) (for “noncritical-sensitive” contractors), or a Moderate Risk Background Investigation (MBI) (for “moderate risk” positions) may be required.

Impact Levels 4/5:CSP personnel supporting Level 4 and 5 cloud service offerings will meet the personnel security requirements and undergo background checks as defined in OPM policy IAW the FedRAMP Moderate baseline, the FedRAMP+ CEs related to personnel security, and DoD personnel security policies.  As such the minimum background investigation required for CSP personnel having access to Level 4 and 5 information based on a “critical-sensitive” (e.g., DoD’s ADP-1) position designation, is a Single Scope Background Investigation (SSBI) or a Background Investigation (BI) for a “high risk” position designation.  The minimum background investigation required for CSP personnel having access to Level 4 and 5 information based on a “noncritical-sensitive” (e.g., DoD’s ADP-2) is a National Agency Check with Law and Credit (NACLC) (for “noncritical-sensitive” contractors), or a Moderate Risk Background Investigation (MBI) for a “moderate risk” position designation.

To receive a DoD PA for Level 2, 4, or 5, the CSP must comply with the investigation requirements as listed for personnel requiring access to systems and data (e.g., above the hypervisor).  Personnel who have access to the CSP infrastructure (e.g. at the hypervisor or below) must comply with OPM investigation requirements or the CSP must demonstrate that their personnel background investigations and compliance with PS-3 and PS-3(3) are consistent with OPM investigation requirements for each position designation. 

NOTE: DoD suggests that the CSP request equivalent investigations to those noted above from an investigation contractor listed on the GSA Federal Acquisition Service Contractor Listing for Category 595 27 HR Support: Pre-Employment Background Investigations web site.^[65] In using such a contractor and requesting equivalent investigations the CSP can demonstrate equivalency toward receiving a DoD PA, and preparing for the needed investigations following contract award. 

Impact Level 6:In accordance with PS-3(1), invoked by the CNSSI 1253 Classified Information Overlay, personnel having access to a secure room, the infrastructure supporting classified processing, or handling classified information, in addition to meeting the public trust position suitability/investigation requirements (e.g., a favorably adjudicated SSBI for a system administrator in a DoD ADP-1 position) must have a security clearance at the appropriate level.  Systems and network administrators (i.e., privileged users), while typically not approved to handle classified information for need-to-know reasons, are considered to have access to classified information through their duties.  Therefore these individuals require a clearance at the appropriate level for the classified information stored, processed, or transmitted.

DoD personnel clearances are granted through DoD processes as defined in DoDI 5200.02^[66] and the DoD 5200.2-R^[67], both entitled DoD Personnel Security Program (PSP).  Commercial CSPs’ personnel clearances are granted through the Industrial Personnel Security Clearance Process^[68]. 

Contracts for both on-premises and off-premises Level 6 CSOs will include language related to the contractor requiring access to classified information IAW 48 Code of Federal Regulations (CFR) Subpart 4.4 - Safeguarding Classified Information within Industry^[69] and Federal Acquisition Regulations (FAR) section 52.204-2 - Security Requirements ^[70] Such contractors are required to comply with NISP policies as discussed as cited above WRT organizational facilities clearances and cleared personnel.

To receive a DoD PA for Level 6, the CSP must either have a facility clearance and cleared personnel who will manage the CSO (including top level corporate management), or demonstrate the ability to meet the requirements for such, as defined in Industrial Personnel Security Clearance Process. 

For on-premises Level 6 CSOs facilities and personnel clearances will be handled as with any other DoD contract where the contractor needs access to classified information or as required for other purposes.

For off-premises Level 6 CSO facilities and personnel clearances, will be handled through the contracting process as with any other Defense Industrial Base (DIB) contractor. This process is the purview of OUSD(I) and DSS. 

5.6.2.3 Mission Owner Responsibilities Regarding CSP Personnel Requirements 

In addition to the above requirements, the FedRAMP Control Specific Contract Clauses v2^[71], also states the following: “Agencies leveraging FedRAMP Provisional Authorizations will be responsible for conducting their own Background Investigations and or accepting reciprocity from other agencies that have implemented Cloud Service Provider systems.”  It also states Agencies are responsible for the screening process, and may want to stipulate additional screening requirements.  As part of the FedRAMP+ assessment, the processes used by the CSP will be evaluated and discussed in the PA as appropriate.  DoD Components and/or Mission Owners must review the investigation type required for all position designations and address investigation requirements as well as funding in their contracts with the CSP.

5.6.2.4 Training Requirements

DoD 8570.01-M, Information Assurance Workforce Improvement Program, Change 3, January 24, 2012^[72] describes the DoD IA Workforce Improvement Program.  This manual requires DoD IA personnel to be categorized and sets experience, training, and certification standards.  DoD CSPs and Mission Owners must comply with DoD 8570.01-M.

CSPs operating at impact level 6 are also required to meet the requirements of DoD 8570.01-M for their personnel.  However, non-DoD CSPs at impact levels 2-5 are not subject to these requirements.  CSPs at all impact levels are however, required to train security personnel as described in security control AT-3.  The determination to not levy DoD 8570.01-M on commercial CSPs is based on the complexities of attempting to change how a commercial CSP that serves customers outside of DoD hires and trains personnel.  Commercial CSP security personnel training will be assessed for compliance with security control AT-3 as part of the FedRAMP and DoD PA assessments. 

5.7 Data Spill

Per CNSSI 4009, CNSS Glossary^[73], a data spill or “spillage” is an unauthorized transfer of classified information or Controlled Unclassified Information to an information system that is not accredited for the applicable security level of the data or information.

A data spill is a cyber-incident that requires immediate reporting and response from both the Mission Owner and CSP in order to minimize the scope of the spill and the risk to DoD data.  Mission owners will report the incident via their normal channels; the CSP must report the spill to the mission/information owner as well as follow the requirements in section 6.4Cyber Incident Reporting and Response.  While the Mission Owner will most likely detect a spillage within their own dataset, the CSP might also detect a spillage.  CSP detection may depend on a particular service offering where the CSP might have intentional access to the content of a Mission Owner information system.

Cloud environments present a unique challenge for data spill response.  Data spills are typically remediated or “cleaned” by sanitizing affected hardware to ensure that reconstruction of spilled data is impossible or impractical.  This process requires access to physical storage media and frequently involves storage resources being taken offline until the cleanup is complete.  Such loss of availability is not acceptable in a cloud environment with multiple tenants sharing the same infrastructure.  CSP use of storage virtualization can generate numerous, dynamic instantiations of data and makes physical data locations difficult to ascertain.  This makes physical sanitization methods non-viable for data spill remediation in cloud services. 

These challenges require a method for mitigating data spill cyber incidents that occur in the cloud.  Cryptographic erase described in Section 5.11.1, Cryptographic Erase, provides such a method.  Cryptographic erase is a high-assurance way of ensuring data at rest can no longer be read.  CE is faster and more practical than physical sanitization methods in large-scale virtualized environments used by cloud services.  Further, DoD control of encryption keys permits mission owners to address data spill incidents without alerting the CSP to the presence of unauthorized data. 

However, CE is only an option for data that is encrypted.  Mission owners should ensure all data is encrypted at rest consistent with Section 5.11, Encryption of Data-at-Rest in Commercial Cloud Storage.

Upon discovery of a data spill, mission owners should cryptographically erase unauthorized data by deleting the associated decryption key(s), consistent with NIST SP 800-88 Rev 1.  Mission owners must also take any necessary steps to remove unauthorized data that may exist in an unencrypted state, such as in memory of a running VM.

Due to data backup and disaster recovery methods used by Mission Owners and CSPs, data spills could affect associated storage.  Data spills remediation must extend to storage media where the spilled data might migrate.  All backups and mirrored storage affected by the spill must be remediated.  Mission owners are responsible for ensuring that all copies of spilled data are cryptographically erased.  Timely detection, reporting, and response are key to limiting the migration of spilled data under these circumstances. 

Data spills that involve unauthorized data being stored in an unencrypted state in a CSO must be mitigated by the Mission Owner utilizing any available option to make such data unrecoverable.  The response to such an event will likely be limited to methods that provide less assurance than cryptographic erase.  Mission Owners that do not or cannot utilize encryption at rest must create data spill response procedures that enumerate all data erasure options in a given CSO.  Upon discovery of such an incident, a risk analysis should be performed to determine the best course of action to mitigate the risk of reconstruction of unauthorized data.  This may or may not include alerting the CSP to the presence of unauthorized data in order to gain cooperation in mitigating the incident.

Alternate innovative methods for cloud data spill protection/remediation will be assessed for equivalency to standard methods and approved if found sufficient. 

Corresponding Security Controls: IR-9, MP-6

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

Off-boarding is the set of activities that take place when a Mission Owner terminates use of a CSO.  An off-boarding process is required when a Mission Owner migrates to a new cloud service, a mission reaches end of life, a contract ends, or a CSP ceases operations.  The off-boarding process is split into two stages: 1- data retrieval/migration and 2- data sanitization or destruction.   Mission owners must prepare for an eventual CSO off-boarding, and CSPs must support the capability in a timely manner. 

Upon request by the Mission Owner, the CSP will make all Mission Owner data stored in a CSO available for electronic transfer out of the CSP environment in a standard, non-proprietary format.  CSPs must also make available all audit logs relevant to the Mission Owner’s use of the CSO.  This includes all audit content specified by the AU-2 security control for the time period specified by AU-11.  See Section 5.2.3, DoD Data Ownership and CSP Use of DoD Data for additional information.  CSOs that enable Mission Owners to download their data on demand and delete or request destruction of data may not require specific CSP action to fulfill this requirement. Each Mission Owner may also request different means of data transfer (for example, as called out in the SLA), at its discretion. 

Cryptographic Erase, described in Section 5.11.1, Cryptographic Erase, provides a high-assurance way of ensuring data at rest can no longer be read.  Upon successful transfer of data out of a CSO, mission owners with data that is encrypted at rest must cryptographically erase all such mission data and take action to ensure that no data remains in the CSO in an unencrypted state.  All backups maintained in the CSO’s infrastructure, from which the Mission owner is departing, must also be cryptographically erased.  Mission owners should also request that all mission data be deleted or made logically inaccessible as per normal CSP procedure for departing customers.  Upon verification of successful Mission Owner transfer of data, CSPs must immediately delete or otherwise make all Mission Owner data irretrievable.  CSPs remain responsible for sanitizing or destroying all storage devices that held DoD data at the hardware’s end-of-life, even after off-boarding is complete IAW Section 5.9, Reuse and Disposal of Storage Media and Hardware.

DoD Mission Owners using non-DoD service offerings must be capable of migrating their data at any time.  This means that mission owners must have the ability to receive their data from a cloud service on short notice.  This capability can be supported in the form of available local storage infrastructure, or a cloud service offered by a different CSP capable of accepting data in a short time frame.  This is to ensure that mission owners can quickly retrieve their data in case of a sudden shutdown of a CSO.  (e.g. A CSP declares bankruptcy and plans to shut down services). This concern is also mitigated by the mission owner’s use of effective backup procedures as described in Section 5.12, Backup.  

Corresponding Security Controls: DM-2, MP-6

5.9 Reuse and Disposal of Storage Media and Hardware

CSPs will ensure that no residual DoD data exists on all storage devices decommissioned and disposed of, reused in an environment not governed by an agreement between the CSP and DoD, or transferred to a third party; as required by the FedRAMP selected security control MP-6. 

Impact Levels 4/5: CSPs may not reuse or dispose of storage hardware until all DoD data has been successfully removed.  The CSP will minimally ensure this by “Purging” all data on devices prior to decommissioning, disposal, reuse, or transfer, in accordance with NIST SP 800-88, Revision 1, Guidelines for Media Sanitization^[74].  Devices that are unable to be cleared or purged must be physically destroyed, as defined in NIST SP 800-88 Rev 1.  When there is any doubt to the success of the cleared or purged process, the storage device must be destroyed in accordance with NIST SP 800-88 Rev 1.

Impact Level 6: On-premises CSP’s may not dispose of or reuse storage hardware at a lower sensitivity or classification level but will ensure classified data is irretrievable from decommissioned devices by sanitizing them in accordance with NSA/CSS Storage Device Declassification Manual 9-12^[75].

Corresponding Security Controls: DM-2, MP-6

5.10 Architecture

This section of the CC SRG provides guidance on the various architectural considerations related to DoD’s use of DoD and commercial cloud services in the following areas:

• The connection between the CSP’s infrastructure/network and the  DISN
• CSP service protections and integration into required DoDIN Cyber Defense and access control services
• Mission system/application protections and integration into required DoDIN Cyber Defense and access control services

5.10.1 Cloud Access Point (CAP)

The 15 December 2014 DoD CIO memo regarding Updated Guidance on the Acquisition and Use of Commercial Cloud Computing Services, states “Commercial cloud services used for Sensitive Data must be connected to customers through a Cloud Access Point (CAP).”

For the purpose of this SRG, Sensitive Data as referenced in the in the DoD CIO memo means CUI as handled at Levels 4/5 or Classified up to SECRET information as handled at Level 6.

A DoD Cloud Access Point (CAP) is a system of network boundary protection and monitoring devices, otherwise known as an IA stack, through which CSP infrastructure and networks will connect to the NIPRNet.  A BCAP does not provide for direct internet access to or by Level 4/5 CSP CSOs or other NIPRNet users.

The primary purpose of a NIPRNet CAP is the protection of the DISN from and detection of unauthorized DISN access from the CSP’s infrastructure, CSO management plane, CSP corporate networks, CSP connections to the Internet, and from compromised Mission Owner systems/applications and virtual networks.  The secondary purpose is to the protection of the DoDIN and DoD information in general by facilitating protected connections for NIPRNet users (and Internet users for internet facing applications) to access Level 4/5 Mission Owner systems/applications instantiated on IaaS/PaaS (or using SaaS) without exposing such traffic to the Internet.  These purposes also apply to any other CAP on any other Mission Partner or COI network for the protection of those networks and the sensitive information they contain.

CAP architecture will change depending on whether the cloud infrastructure is on-premises or off-premises.  There are internal CAPs (ICAPs) and DISN/NIPRNet Boundary CAPs (BCAPs).  Some CAPs will leverage existing infrastructure and some will be a new capability. 

In general, the BCAP will provide the following protections:

Provides DISN perimeter defenses and Boundary Cyber Defense sensing for traffic to and from applications hosted in the cloud service.

Protects DoD missions [within the DISN] along with the DISN and its network services from incidents that affect a particular CSP's infrastructure or supported missions.

Protects DoD systems/applications instantiated in one CSP's infrastructure from incidents that affect a different CSP's infrastructure or supported missions.

Extends the DoD demilitarized zone (DMZ) architecture via traffic segregation to externally (e.g., Internet) facing mission systems and applications in Level 4/5 CSOs.  (i.e., implements a connection, physical or logical (e.g., MPLS VPN), between the CAP and the NIPRNet IAPs for Mission Owner applications providing their own application protections or leveraging an enterprise level application protection service provided by DISA or a DoD Component in the cloud. A CAP does not support/provide direct internet access to a Level 4/5 CSO. Such access must be via the IAPs

May also terminate physical or logical connections from the internal side of a DoD Component’s DMZ extension such that the DoD Component’s existing DMZ/DMZ-extension protections may be leveraged).

The implementation of the DISN BCAP capability for NIPRNet is ultimately a DISA responsibility as part of its mission to protect the DoDIN and DoD information.  Per the 15 December 2014 DoD CIO memo, initial capability may temporarily be provided by DoD Components other than DISA, as approved by the DoD CIO.  This requirement is applicable to Boundary CAPs to the NIPRNet, not ICAPs.  Specific CAP architectural requirements are beyond the scope of this SRG and will be published separately in the Cloud Access Point Functional Requirements Document (FRD)^[76]. 

An ICAP capability for NIPRNet provides interconnection between CSP infrastructure at any impact Level 2-5 (dedicated to DoD) located inside the B/C/P/S “fence-line.” (i.e., on-premises) The architecture of ICAPs may vary and may leverage existing capabilities such as the IA Stack protecting a DoD Data center today, JIE Core Data Center (CDC) tomorrow, or may be part of a Joint Regional Security Stack (JRSS).  On the other hand, an ICAP may have special capabilities to support specific missions, CSP types (commercial or DoD), or specific cloud services. Since the CSP infrastructure and ICAP are both on-premises directly connected to the NIPRNet or indirectly via a DoD data center network, BCAP boundary protections are not needed. Alternate protections may apply.  ICAP implementation and the connection of on-premises CSP infrastructure to the NIPRNet will follow normal NIPRNet connection approval guidance and requirements as is the case with any NIPRNet enclave or application infrastructure in a DoD data center.

Connection of a mission system to the DISN via an ICAP or BCAP will be approved and recorded by the DISA Connection Approval Office in accordance with normal connection approval procedures.  This requires all Mission Owners to register all Cloud based applications, their CSP/CSO, and connection method in the DISA Systems/Network Approval Process (SNAP)^[77] database Cloud Module. Initial connections (physical or virtual) to a CSP’s network will occur during onboarding of the CSP’s first Mission Owner customer.  Additional connections will be made or capacity will be scaled as more Mission Owners use the given CSP.  Specific processes and procedures regarding connection approval and Mission Owner connections via a BCAP are beyond the scope of this SRG and will be published separately. 

Impact Level 2:Since off-premises CSP infrastructure having a Level 2 PA is directly connected to the Internet, all traffic to and from a Level 2 CSO serving Level 2 missions and their mission virtual networks will connect via the Internet.  The NIPRNet BCAP is not used.  See sections 5.10.2.2, User/Data Plane Connectivity and 5.10.2.3, Management Plane Connectivity for additional details.  

Impact Levels 4/5: All DoD traffic from NIPRNet to and from off-premises CSP infrastructure serving Level 4 and level 5 missions and the mission virtual networks must traverse one or more NIPRNet BCAPs. No direct traffic is permitted to/from the Internet except via the NIPRNet IAPs and DoD DMZ capabilities provided by the Mission Owner, a DoD Component, or DISA. The BCAP terminates dedicated circuits and VPN connections originating within the CSP’s network infrastructure and/or Mission Owner’s virtual networks.  This includes the production plane for non-privileged user access and the management plane for privileged user access and deployed IA/Cyber Defense tool connectivity to internal Cyber Defense monitoring systems.  See Sections 5.10.2.2, User/Data Plane Connectivity  and 5.10.2.3, Management Plane Connectivity for additional details.  High availability Mission Owner systems and their supporting CSP network infrastructure must connect through two or more NIPRNet BCAPs.  The NIPRNet BCAP will support Internet facing Mission Owner systems by minimally providing a physically or logically isolated path between the BCAP and the IAPs IAW the DMZ STIG. Some DMZ STIG capabilities/protections are the responsibility of the Mission Owner until such time as they are provided by the Mission Owner’s agency or DISA as an enterprise service.

NOTICE: Level 5 CSP/CSO infrastructure/applications and DoD Mission Owner applications must be designed such that there is no dependence on Internet based resources such that traffic must traverse the IAPs to/from the Internet to make the CSO function. As such the CSO and DoD Mission Owner applications connected through a BCAP must be able to fully function, serving NIPRNet connected users in the event DoD decides to cut off NIPRNet access to the Internet. Of course in this situation, Internet connected users will not be able to utilize the Level 5 service/resource. Mission Owners that need this restriction for Level 4 CSOs must add the requirement to their SLA/contract.

NOTE: The Level 4/5 CAP connectivity requirements are intended for Mission Owner’s systems migrating from on-premises DoD data centers on NIPRNet to a commercial CSO in an off-premises data center.  Level 4/5 missions currently implemented and approved for having/utilizing direct internet connectivity (under DoD CIO waiver) (i.e., not internal to the DISN/NIPRNet behind the IAPs) are not required to utilize a NIPRNet BCAP as they migrate from physical infrastructure to the Cloud.  However, such missions must use a CSO with a Level 4/5 PA and must minimally implement the same boundary protections as defined in this SRG for Level 2 missions due to being directly connected to the Internet. 

Impact Level 6:

Since DoD on-premises Impact level 6 CSOs and their supporting infrastructure are required to be closed SIPRNet enclaves, they must comply with all SIPRNet connection approval requirements which include the appropriate enclave boundary protections and CDSP requirements.  The DoD Mission Owner systems/applications instantiated in these Impact Level 6 CSO enclaves will be assessed and authorized the same way any other DoD SIPRNet enclave connection IAW the DISA Connection Process Guide.  Approval for connection to the SIPRNet will be processed through the DISA classified connection approval process like any other SIPRNet enclave. 

In accordance with CNSS architectural recommendations for the National Secret Fabric, DoD SECRET enclaves and virtual networks instantiated in DoD on-premises Impact level 6 CSOs will be considered as an enclave within the DoD provider network, (i.e., the SIPRNet). As such no SIPRNet BCAP is required for the connection of these DoD enclaves (physical or virtual) to the SIPRNet.

Corresponding Security Controls: SC-7, SC-7(3), SC-7(4)

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

For the purpose of this CC SRG, mission partner refers to DoD Components, Federal agencies, and potentially their contractors operating networks that include DoD and other entities. This section does not include or refer to war fighting coalition partners or the networks they use or are implemented for them.  Coalition networks may be addressed in a future release of the CC SRG, however the use of cloud computing on these networks should be implemented in the same manner as this CC SRG provides for NIPRNet or SIPRNet depending on the classification level of the network.   

Mission Partner Environments (MPEs) include mission partners that utilize networks other than NIPRNet or SIPRNet (e.g., DREN) and mission partner Communities of Interest (COI) that utilize network overlays and extensions that leverage (e.g., ride on or overlay) the NIPRNet or SIPRNet (e.g., MilCOI).  Additionally, DoD Component mission partners (e.g., commissaries, exchanges, educational entities) typically operate networks that are not part of the DISN or .mil domain.  These mission partners and their networks are typically in the .gov/.org/.com/.edu domains and may be directly accessed from the Internet through a boundary similar to a DoD IAP which they operate or a contracted third party DHS/GSA Trusted Internet Connection (TIC).  Such other networks and COI may interconnect with NIPRNet or SIPRNet and may interconnect with other DoD and Non-DoD mission partner/Agency networks. 

MPEs that utilize network(s) other than NIPRNet or SIPRNet (e.g., DRSN), will need to implement BCAPs or ICAPs for those network(s) that provide equivalent protections to those defined in the CAP Functional Requirements Document (FRD)^[78] when connecting CSP infrastructure to their networks.  MPEs implemented as a COI overlay on NIPRNet or SIPRNet can utilize the DISA-provided CAPs to fulfill the CAP requirement or may provide their own CAP capability IAW the CAP FRD.  Mission Partners that are external to NIPRNet or SIPRNet, however, are responsible for providing an equivalent capability to protect DoD data and MPEs from vulnerabilities associated with a connection to an external service provider. 

All MPE CAP instantiations must be approved by the DoD CIO.

5.10.2 Network Planes

A plane, in a networking context, is one of three integral components of network architectures.  These three elements – the data synchronization/control or network plane, the user/data or production plane, and the management plane – can be thought of as different areas of operations.  Each plane carries a different type of traffic and is conceptually an overlay network on top of the network plane.

5.10.2.1 Network Plane Connectivity

The network or data sync/control plane carries signaling traffic and data replication between servers/data centers.  Network control packets originate from or are destined for a network transport device (virtual or physical).  The network plane in general is subject to network related DoD SRGs and STIGs.  This CC SRG does not contain additional requirements related to network plane connections to the cloud computing infrastructure.

5.10.2.2 User/Data Plane Connectivity

The user/data plane (also known as the forwarding plane, carrier plane, or bearer plane) carries the network user traffic.  Table 5 details the DoD user/data plane connectivity by impact level for DoD on-premises and off-premises CSOs. 

NOTE: While this table does apply to non-DoD Federal Government tenants using a DoD on-premises CSO, it does not apply to non-DoD Federal Government tenants using an off-premises CSO that is a Federal Government community cloud having DoD tenants.

Table 5 - User/Data Plane Connectivity

Impact Level	Off-Premises Non-DoD CSP Service Offering Infrastructure	On-Premises DoD and Non-DoD CSP Service Offering Infrastructure
Level 2	User connectivity will leverage commercial infrastructure (i.e., Internet).  Users connecting from the Internet will connect directly while users connecting from inside the DISN (i.e., NIPRNet) will connect to the Internet via the DISN Internet Access Points (IAPs) then to the CSP infrastructure.  CSO connections will be assessed and authorized using the same external connection requirements as any other Internet-facing connection.	User connectivity will use existing infrastructure (Government owned) for its user/data plane when the user is within the B/P/C/S fence-line (on-premises) and directly connected to the local Base Area Network (BAN) and NIPRNet.  User traffic to/from the NIPRNet to/from the CSO infrastructure will traverse an ICAP.  When the user is outside the B/P/C/S fence-line (off-premises) connected to the Internet, user traffic must enter/leave the NIPRNet via the DISN Internet Access Points (IAPs) then an ICAP via DoD DMZ extension.  CSO connections will be assessed and authorized the same as any other internal connection.
Level 4 And 5	DoD and external user connectivity will leverage a DISN extension to the commercial facility using government network infrastructure within government boundaries (i.e.  NIPRNet) and commercial infrastructure beyond government boundaries (i.e.  commercial carrier infrastructure / connectivity service offerings).  The DISN extension will traverse a BCAP.  Users connecting from inside the DISN (i.e., NIPRNet) will connect via a BCAP while users connecting from the Internet will traverse the IAPs then a BCAP via a DoD DMZ extension.  CSO connections will be assessed and authorized through the Connection Approval Process the same as any other internal connection using the same requirements as any other DoD-facing or Internet-facing connection.  Internet-facing connections are assessed and authorized IAW the DMZ STIG.
Level 6	User connectivity will leverage a DISN extension to the commercial facility using government SECRET network infrastructure within government boundaries (i.e.  SIPRNet) and commercial infrastructure beyond government boundaries (i.e.  commercial carrier infrastructure / connectivity service offerings).  The DISN extension to a commercial facility can be accomplished with a Multiprotocol Label Switching (MPLS) router and optical switch (referred to as a Service Delivery Node).  The DISN extension to a commercial facility will use NSA Type 1 encryption or commercial equivalent (Commercial Solutions for Classified Programs (CSfC)[79] Suite B).  User traffic to/from the Internet (e.g., executive travel kits users) will use NSA Type 1 encryption or commercial equivalent (CSfC Suite B) and must enter/leave the SIPRNet via the approved gateways.	User connectivity will use existing SECRET network infrastructure (Government owned) for its user/data plane (i.e., SIPRNet).  User traffic to/from the SIPRNet will traverse an ICAP.  User traffic to/from the Internet (e.g., executive travel kits users) will use NSA Type 1 encryption or commercial equivalent (CSfC Suite B) and must enter/leave the SIPRNet via the approved gateways. CSO connections will be assessed and authorized the same as any other internal connection using the same requirements as any other  SIPRNet -facing connection (i.e., IAW the DMZ STIG).

5.10.2.3 Management Plane Connectivity

The management plane carries network/server/system privileged user (administrator) traffic along with maintenance and monitoring traffic. 

Table 6 details the management plane connectivity by impact level for Mission Owner’s systems/applications and CSP’s CSOs.  The Mission Owner management plane includes connectivity for DoD personnel or DoD contractors managing Mission Owner systems (i.e., virtual machines and networks) instantiated on IaaS/PaaS as well as for DoD personnel or DoD contractors access to / use of CSP service ordering/management portals for all service offering types (IaaS/PaaS/SaaS).  The CSP management plane includes connectivity for CSP personnel managing the CSP’s service offering infrastructure.

All encryption identified, except as stated otherwise, must be accomplished using FIPS 140-2 validated cryptography modules operated in FIPS mode.

IAW standard practice and security requirements, management interfaces on VMs and protective appliances (virtual or physical) located in a Mission Owner’s virtual network, must not be exposed to direct access from the production network (e.g., Internet or NIPRNet/SIPRNet).  To the extent possible, CSP service ordering/management portals through which VMs and virtual networks are instantiated and configured must also be protected from direct access from the production network to prevent compromise of mission systems and DoD information.

All management transactions must be audited.

Table 6 - Management Plane Connectivity

Impact Level	Mission Owner Management Plane	CSP Management Plane
Level 2	Management connectivity from outside the NIPRNet (e.g., for off-premises contractor personnel) requires an encrypted, tunneled connection via the Internet to the mission system/application and virtual network.  Management traffic to CSP service ordering / service management portals must be encrypted if not in an encrypted VPN.  Monitoring traffic must traverse a VPN connection.  All traffic entering/leaving the NIPRNet must be via the DISN Internet Access Points (IAPs). Management connectivity from inside the NIPRNet (e.g., for on-premises DoD or contractor personnel) must be restricted to a defined set of IP addresses and requires an encrypted, tunneled connection through the NIPRNet to the Internet via the IAPs to manage the mission system/application and virtual network.  Management traffic to CSP service ordering / service management portals must be encrypted if outside an encrypted VPN.  Monitoring traffic must traverse a VPN connection.  All traffic must enter/leave the NIPRNet via the DISN Internet Access Points (IAPs).	Non-DoD CSP off-premises service offering infrastructure and off-premises management: CSP management connectivity leverages CSP service offering and management plane infrastructure which should be logically or physically separate from production.  NOTE: DoD cannot dictate how a CSP architects their commercial service offerings that are not dedicated to DoD.  DoD recommends logical or physical separation of service offering production and management plane infrastructure as a well-known industry best practice.  Such separation will be assessed as a bullet point for DoD risk acceptance.  Non-DoD CSP on-premises service offering infrastructure and management:  The CSP may directly connect their management infrastructure to their service offering infrastructure if collocated.  An encrypted, tunneled connection from the CSP’s on-premises management infrastructure to the service provider’s on-premises service offering infrastructure is also permitted locally but must be used to access remote service offering infrastructure.  Non-DoD CSP on-premises service offering infrastructure and off-premises management: CSP management connectivity must leverage an encrypted, tunneled connection from the CSP’s off-premises management infrastructure to the service provider’s on-premises service offering infrastructure. DoD CSP on-premises service offering infrastructure and management: CSP management connectivity will utilize existing infrastructure such as the Enterprise Services Directorate (ESD) Out of Band (OOB) management network.  No service provider security stack is required.
Level 4 And 5	Management connectivity from inside the NIPRNet must be restricted to a defined set of IP addresses and requires an encrypted, tunneled connection through the NIPRNet and an ICAP or BCAP to manage the mission system/application and virtual network.  Management traffic to CSP service ordering / service management portals must be encrypted if not in an encrypted VPN.  Monitoring traffic must traverse a VPN connection.  All traffic must enter/leave the NIPRNet via a BCAP.  Management connectivity by DoD personnel or DoD contractors from outside the NIPRNet must be restricted to a defined set of IP addresses and requires an encrypted, tunneled connection from the Internet via an IAP and an ICAP or BCAP to the mission system/application and virtual network.  Per remote administration policy, the remote management terminal must be Government Furnished Equipment (GFE).   Management traffic to CSP service ordering / service management portals must be encrypted if outside an encrypted VPN.  Monitoring traffic must traverse a VPN connection via a BCAP and NIPRNet.
Level 6	All management and monitoring connectivity is via the SIPRNet.  Management and monitoring traffic will be encrypted using FIPS 140-2 validated cryptography[80] to accommodate separation for Need-to know reasons.	DoD CSP on-premises service offering infrastructure and management: CSP management connectivity will utilize existing SECRET network infrastructure such as the SECRET Out of Band (OOB) management network.  No service provider security stack is required. Non-DoD CSP on-premises service offering infrastructure and management: The CSP may directly connect their management infrastructure to their service offering infrastructure if personnel are collocated using their SECRET LAN.  An encrypted, tunneled connection using FIPS 140-2 validated cryptography over SIPRNet from the CSP’s on-premises management infrastructure to the service provider’s on-premises service offering infrastructure is also permitted and will be used to access remote service offering infrastructure.  Non-DoD CSP on-premises service offering infrastructure and off-premises management: CSP management connectivity must leverage a SIPRNet extension or a DoD approved encrypted, tunneled connection from the CSP’s dedicated SECRET off-premises management infrastructure to the service provider’s on-premises service offering infrastructure.  Non-DoD CSP off-premises service offering infrastructure and off-premises management: CSP management connectivity leverages CSP’s dedicated SECRET service offering and management plane infrastructure which must be logically or physically separate.

5.10.3 CSP Service Architecture

DoD uses the concept of defense-in-depth when protecting its networks and data/information.  This includes, but is not limited to, hardening host OSs and applications, implementing host firewalls and intrusion detection, strong access control, robust auditing of events, while protecting the networks with application layer firewalls, proxies, web content filters, email gateways, intrusion detection / prevention, and a DMZ /gateway  architecture, along with robust network traffic monitoring. The concept must not be lost when moving Mission Owners systems/applications and their data/information to the commercial cloud.  As such, if virtualization is used, the above measures must also be used to protect the virtual environment along with the use of hypervisor based firewall/filtering/routing mechanisms or virtual security appliances.

This section details the defense-in-depth security concepts and requirements that both CSPs and Mission Owners must implement to protect DoD data/information and mission systems/applications.  DoD recognizes that there are innovative approaches that can be implemented in the virtual environment that may replace some of the defense-in-depth mitigations that have been developed over the years for physical networks and servers.  DoD looks forward to evaluating equivalent alternative measures which will be assessed by DISA on a case by case basis.

5.10.3.1 CSP Service Architecture - SaaS

Mission Owner use of CSP’s SaaS offerings are reliant on the defense-in-depth measures implemented by the CSP for the protection of the service application and the infrastructure that supports it.  This includes the protection of all sensitive information stored and processed in the CSP infrastructure.  In other words, the Mission Owner relies on the CSP and the security posture of its SaaS offering for the protection of DoD information.  During the ATO assessment process for SaaS offerings, defense-in-depth security / protective measures must be assessed for adequacy and potential risk acceptance by DoD.  This may be in addition to assessing security controls.  The following guidance is reflected in the DoD DMZ STIG and Application Security and Development STIG along with other operating system (OS) and application specific STIGs, but is highlighted here to emphasize instances where an authoritative reference (e.g., product specific STIG) is not available. 

The defense-in-depth security / protective measures to be established by the CSP for SaaS are, but are not limited, to the following:

• Application Layer Firewall (properly configured) and  intrusion detection and/or prevention protection of the CSP’s infrastructure supporting the SaaS application offering, as well as segmentation (logical or physical) from the CSP’s other offerings and corporate networks.
• Application / network architecture which provides unrestricted/restricted DMZ zones with appropriate protections IAW the DoD DMZ STIG for internet/externally facing servers and private / “back end” zones with appropriate protections for application/database servers and other supporting systems/servers.  This includes but is not limited to Web Application Firewalls, Reverse Web Proxies, FTP Proxies, etc. as necessary for the protection of the application and the customer’s data/information stored/processed within.
• Customer data-at-rest encryption protections using FIPS 140-2 validated cryptographic modules operated in FIPS mode where only the Mission Owner has control of the keys.  This requirement addresses the persistent storage of customer data on various media and in databases, not customer data that requires real time processing without retention.  If such data is retained then the retained data storage is persistent. 
• Customer data-in-transit encryption protections using FIPS 140-2 validated cryptographic modules operated in FIPS mode.  This requirement addresses customer data transiting public and private Wide Area Networks (WAN) (i.e., Internet, NIPRNet, CSP’s WAN) and Local Area Networks (LANs) from the customer terminal to the CSP’s service offering enclave LAN.  Encryption may be native at the protocol level or be at the VPN/tunnel level.  This requirement is also applicable to CSP replication of customer data and systems between primary locations and backup Continuity of Operations (COOP) / Disaster Recovery (DR) locations.
• Hardening / patching / maintenance of OSs and applications IAW industry standards. DoD SRGs and STIGS or DoD-accepted equivalents must be used if the service is private or community cloud used by DoD.  For Information Assurance (IA) Vulnerability Management (IAVM) message compliance, the CSP will be expected to comply with industry best practice by applying patches identified in the CVE that would be referenced in the DoD IAVM message.  Innovative alternatives such as implementing a behavioral based or software integrity protection model for all systems may be viable and will be assessed on a case by case basis.
• Implement PIV/DoD CAC / PKI authentication for all customer user access on all SaaS offerings that process information at impact Levels 4 and 5 in accordance with IA-2 (12).  This includes regular non-privileged users accessing the service and privileged customer users accessing service ordering / management interfaces/portals.  SaaS offerings that process information at impact Level 6 must use the CNSS SIPRNet Token.  Alternate authentication measures for those user communities that cannot use the required PKI token will be assessed on a case by case basis and may require a waiver.

NOTE: Equivalencies to the vulnerability mitigations provided in DoD SRGs and STIGS may be viable and acceptable but must be approved by the DISA AO.

NOTE: IAVM messages include IA Vulnerability Alerts (IAVA), IA Vulnerability Bulletins (IAVB), and Technical Advisories (TA).  For the remainder of this SRG, the term IAVMs will be used to refer to all IAVM message types.

5.10.3.2 CSP Service Architecture - IaaS/PaaS

Mission Owners build systems and applications on virtualized infrastructure provided by the CSO under IaaS/PaaS.  There must be a clear delineation of responsibility for security between the CSP and the Mission Owner, which depends on how the CSP presents the security features it supports in the CSO.  Under IaaS the Mission Owner is fully responsible for securing the guest operating systems and applications that they build; the CSP will be responsible for securing the virtualization OS (i.e., hypervisor) and supporting infrastructure.  Under PaaS, the Mission Owner is fully responsible for securing the guest operating systems and the platform applications and applications that they build.  Depending upon how the CSP CSO presents the security features it supports in the CSO, the delineation of responsibility may partially shift from the Mission Owner to the CSP with respect to the guest operating systems and the platform applications.  The CSP might take responsibility for securing these areas of a PaaS CSO as part of the core service or as an add-on component. 

For the purpose of the remainder of Section 5 of this SRG, IaaS and PaaS offerings are generally treated the same with the responsibility of securing the OS and platform applications being that of the Mission Owner.  Mission Owners must assess inherited mitigations that the CSP provides to determine that defense-in-depth security / protective requirements are fully met.

CSP IaaS and PaaS offerings must support the defense-in-depth security / protective measures that the Mission Owner must implement to secure the systems and applications that they build on the service offering. These measures are defined in Section 5.10.6, Mission Owner System/Application Requirements using IaaS/PaaS.

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

As a best business practice, CSPs plan for Disaster Recovery (DR) and Continuity of Operations (COOP) and implement their infrastructures to support it. This typically includes geographically separate facilities/data centers. Furthermore, FedRAMP assess several C/CE related to Contingency Planning (i.e., DR and COOP).

Data replication between CSP geographically separate facilities/data centers is typically required for Disaster Recovery (DR) and/or Continuity of Operations (COOP) which includes backup. 

All Data replication must traverse a CSP’s private internal network (physical or virtual) from CSP offering site/location to the DR/COOP facility and protect the data in transit.  If this network traverses the Internet, the network connection must be encrypted end-to-end in an IPsec tunnel implemented using FIPS 140-2 validated cryptography.  Separation requirements implemented in the CSO between DoD data and non-DoD data at the CSP offering site/location must be replicated at the DR/COOP facility.  Such separation is not specifically required in transit unless its implementation is required to support separation at the endpoint facilities. 

NOTE: For Level 4/5 CSOs such transfers do not route through the DISN BCAP unless the DR/COOP facility is on-premises or is another CSP’s CSO.

Related Controls: CP-6, CP-7, CP-9

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

DoDI 8410.01, Internet Domain Name Use and Approval, 4 December, 2015^[81] provides DoD policy on the use of Top Level Domain (TLD) names by DoD organizations, their ISs and networks.

DoDI 8410.01 requires DoD to conduct DoD public andprivate Internet-based communications (e.g., electronic mail and Web operations) under the TLD established for the DoD—the .mil TLD”.  Exceptions are provided for some DoD organizations which may use the .gov, .edu, and .com domains if necessary and approved by the Mission Owner’s CIO.  This means that the end user accessing a DoD web site or other resource using a URL will see “.mil” at the end of the URL (e.g., name.mil is required vs name.com).

DoDI 8410.01 additionally requires DoD to only use the .mil domain to provide names for IP addresses allocated or assigned to the DoD by the American Registry for Internet Numbers (ARIN) and specifically states that these IPs are to be assigned in accordance with the DoD NIC Registry Protocol 9802.  DoD NIC Registry Protocol 9802 then goes on to state that

a. ... IP address space is assigned by the DoD NIC for use on a DoD common user data network and may not be used to obtain access to the Internet via a commercial Internet Service Provider.

And

b. IP address space will only be used on the common user network to which it is registered. IP address space or subnets of IP address space will not be shared amongst different common user networks. For example, IP address space assigned for SIPRNET use must be used only on the SIPRNET while IP address space assigned for NIPRNET use must be used only on the NIPRNET.

Interpret this to mean that DoD IP addresses are to only be used on DoD systems located on registered DoD networks.

Furthermore it requires that a .mil URL not redirect to non-.mil domain named hosts (e.g., name.mil will not redirect to name.com) with the only exception being for an approved and accredited service that provides redirection not readily apparent to the end user (e.g., use of a content delivery service or cloud service). This exception permits the use of a Canonical Name (CNAME) in the system’s DNS record within the DoD DNS servers that redirects the URL to the CSP assigned URL associated with the commercial IP address.  As such the end user must not be made readily aware of the redirection.

NOTE: The example of electronic mail (email) in DoDI 8410.01 paragraph 3.a and previously in this section does not negate the use of an external commercial cloud email service by DoD Components providing the URL to access the service ends in “.mil” and the redirection is not readily apparent to the user.

NOTE: IP addresses assigned by ARIN to the DoD NIC which are then assigned to DoD Components for their networks and information systems (e.g., NIPRNet addresses)  are unique publicly routable addresses. Only within DoD enclaves are “private” (non-publicly routable) RFC 1918 addresses permitted/used.

5.10.4.1 IP Addressing

Off-Premises Impact Level 2: 

Due to off-premises Impact Level 2 IaaS/PaaS/SaaS CSOs being directly accessed from the Internet, DoD Mission Owner systems/applications using the .mil domain that are implemented in an Impact Level 2  IaaS, PaaS, or SaaS CSO will be addressed using public IP addresses assigned and managed by the CSP.  This also applies to DoD Mission Owner systems/applications approved to use non-.mil domain names. In this case the DoD DNS server will use a CNAME to point to the commercial URL and its IP address.

NOTE: The use of “private” RFC 1918 IP addresses internal to the virtual network enclave with commercial addresses on the Internet facing interfaces is acceptable and is recommended minimally for topology hiding. 

Off-Premises Impact Level 4/5:

DoD IP addresses are assigned/managed by the DoD Network Information Center (NIC) and may be further managed and assigned to networks and ISs by DoD component NICs. In accordance with DoD policy NIPRNet, subtended Component enclave networks, and their internally connected endpoints are addressed using DoD NIPRNet IP addresses. 

NOTE: The following is NOT applicable to DoD systems that are not connected to, or not part of, the NIPRNet and are already approved to use Non-DoD, Non-NIPRNet, IP addresses.  There is no intent to force such DoD systems to become part of the NIPRNet.

Since, by default, Mission Owners systems/applications instantiated in IaaS and in some PaaS CSOs have full control over the IP addressing of their systems/applications instantiated in the CSO, and since they are connected to NIPRNet through a NIPRNet BCAP, DoD NIPRNet IP addresses will be used. This also applies to SaaS where the Mission Owner has control over the IP addressing used in their portion of the CSO.  As such these systems/applications are within a network enclave that is considered an extension of the NIPRNet.  The DoD NIC has set aside a range of NIPRNet IP addresses for CSOs connected to the NIPRNet BCAP.  This requirement applies similarly to networks other than NIPRNet where a BCAP is required. In such cases IP addresses used on that network will be used.

NOTE:  As with any DoD enclave, The use of “private” RFC 1918 IP addresses internal to the virtual network enclave with NIPRNet addresses on the NIPRNet/Internet facing interfaces connected via the CAP is acceptable. 

DoD recognizes that with some off-premises commercial SaaS and some PaaS CSOs today, the Mission Owner may not have control over the IP addressing of the CSO and CSP managed IP addresses must be used and interfaced with the NIPRNet via the BCAP.   The preferred solution is for the CSP to provide a NAT or proxy between the CSO and NIPRNet BCAP.  Alternately the routing of CSP managed commercial IP addresses must be segregated from other routing and traffic on the NIPRNet by using a Multiprotocol Label Switching (MPLS) VPN or similar method. Since such a solution is not scalable for all Mission Owner’s to have their own MPLS VPN, such VPNs will be shared.  CSP managed IP addresses used for DoD missions must be dedicated to DoD and must not be accessible from the Internet.  This is in support of DoD Cyber Defense, network routing, and the prevention of unauthorized access and back doors.

NOTE: DoD’s objective requirement for all off-premises Level 4/5 CSP’s CSOs serving the DoD is for the CSO to offer a “bring your own” IP address capability for all customer facing interfaces so that DoD NIPRNet IP addresses may be used.  In this case, customer facing interfaces includes general user interfaces and customer management interfaces including customer service management/ordering portals. This IP addressing request does not include CSP systems instantiated within the CSO infrastructure that are not directly accessible from the NIPRNet (or other mission partner network) which may use CSP assigned and managed IP addresses.

Off-premises Impact Level 6:

All off-premises CSP’s Level 6 CSOs will be treated, designed, and addressed as an extension of the SIPRNet (i.e., a SIPRNet enclave) or other SECRET mission partner network. 

All Mission Owner systems/applications instantiated in IaaS/PaaS (i.e., VMs and virtual network device interfaces) and connected to SIPRNet will be addressed using SIPRNet IP addresses.  This includes management plane systems and interfaces. 

All off-premises CSP Level 6 SaaS and some PaaS service offerings connected to SIPRNet must utilize DoD assigned and managed SIPRNet IP addresses throughout.  Alternate addressing will require a waiver. 

On-premises Impact Level 2/4/5:

All on-premises Level 2/4/5 IaaS/PaaS/SaaS CSOs and Mission Owner systems/applications will be addressed using DoD NIPRNet IP addresses.

On-premises Impact Level 6:

All on-premises Level 6 IaaS/PaaS/SaaS CSOs and Mission Owner systems/applications will be addressed using DoD SIPRNet IP addresses.

5.10.4.2 Domain Name Services (DNS)

DoD .mil DNS servers on NIPRNet (and .smil.mil DNS servers on SIPRNet) are authoritative for DoD IP addresses provided through the DoD NIC and subtended Component NICs. This means that the DoD .mil DNS servers resolve .mil URLs to their destination IP address. DoD .mil DNS servers on NIPRNet must also be used to host .mil URLs which cannot have a specific IP address associated with it. In this case, a CNAME is used in the DoD .mil DNS servers on NIPRNet to point to a commercial URL used by the CSO.

DoD .mil DNS servers on NIPRNet are protected using various security measures such as the DoD DNS proxies, the Enterprise Recursive service, and DNSSec. As such DoD DNS is protected from many DNS threats and DoD DNS and associated protective services must be used for DoD .mil URLs and address resolution as appropriate. 

General Rule, All On-Premises and Off-Premises Impact Levels 2/4/5:

In general and IAW DoDI 8410.01 Mission Owner systems/applications using the .mil domain instantiated in an IaaS/PaaS/SaaS CSO where the Mission Owner has control over the IP addressing and is using DoD NIPRNet IP addresses, must host their .mil DNS records in the DoD .mil NIPRNet authoritative DNS servers, not public or commercial DNS servers.  Therefore, such Mission Owners are not authorized to utilize DNS services offered by the CSP or any other non-DoD DNS provider unless otherwise approved to use another domain.  

NOTE: Mission Owners using non-.mil URLs may utilize CSP managed or other commercial/public DNS servers (not the DoD DNS servers) for the domains in which they are authorized to operate.

The following exceptions to the general rule noted above apply:

Exception for Off-Premises Impact Level 2: 

DoD Mission Owners using an off-Premises Impact Level 2 CSO which by default uses CSP managed commercial IP addresses and URLs must host their .mil DNS records in the DoD .mil NIPRNet DNS servers and use a CNAME to point to the commercial URL or IP address as appropriate. CSP DNS servers will be authoritative for commercial IP address resolution.

Exception for Off-Premises Impact Levels 4/5 SaaS and some PaaS: 

DoD Mission Owners using an off-premises Impact Level 4/5 CSO (IaaS and some PaaS) where the Mission Owner does not have control over the IP addressing and therefore is dependent upon CSP managed commercial IP addresses and URLs must host their .mil DNS records in the DoD .mil NIPRNet DNS servers and use a CNAME to point to the commercial URL for IP address resolution as appropriate. CSP DNS servers will be authoritative for their commercial IP address resolution.

In the event their use is required CSP DNS services including URL redirection and dynamic DNS solutions along with implemented DNS protections will be assessed and approved as appropriate for the CSO’s DoD PA. CSP DNS services must be protected using a DNS proxy and must support DNSSec. The DoD PA will also include a risk assessment of the CSP’s DNS management architecture or outsourced services.

All On-Premises and Off-Premises Impact Level 6: 

DoD Mission Owners using an on-premises or off-premises Impact Level 6 CSO will use smil.mil URLs whose DNS records will be hosted on the DoD authoritative DNS servers on the SIPRNet (or other SECRET mission partner network).  SIPRNet addresses are assigned by the DoD NIC. 

Corresponding Security Controls: SC-20, SC-21, SC-22

5.10.5 Mission Owner Requirements using SaaS (All Levels)

While protecting/securing/defending the SaaS architecture is the responsibility of the CSP, Mission Owners contracting for and using CSP’s SaaS offerings must minimally address the following to meet DoD policy:

• Register the Protocols and Services along with their related UDP/TCP IP Ports used by the SaaS service that will traverse the DISN in the DoD PPSM registry. This includes all user and management plane traffic for Levels 4, 5, and 6 as well as management plane traffic for Level 2 if managed/monitored from within a DoD network.  See Section 5.15, Ports, Protocols, Services, Management and Cloud for additional information.
• Register the service/application with the DoD whitelist for both inbound and outbound traffic if traffic will cross the IAPs.

Register the CSP’s CSO in the DISA SNAP database for the connection approval which also includes the designation of a certified CDSP as the Mission Cyber Defense (MCD) as defined in Section 6, Cyber Defense and Incident Response.

This step is required at all levels for SaaS, including level 2 (even though there is no production connection to the DISN) so that the DoD CDSP community is aware and informed such that they can perform their Cyber Defense duties described in Section 5.18, Supply Chain Risk Management Assessment.

As discussed in Section 5.10.3, CSP Service Architecture, the Mission Owner is reliant on the security posture of the CSP and their SaaS offering for the protection of DoD data/information. 

5.10.6 Mission Owner System/Application Requirements using IaaS/PaaS

Mission Owners must address defense-in-depth security / protective measures across all information impact levels when implementing systems/applications on IaaS / PaaS which include, but are not limited to, the following:

• Implement Virtual Machines (VMs) in one or more virtual networks in which data-flows between VMs and between VMs and external networks (both physical and virtual) may be controlled. 
  NOTE: Virtual networks are typically a feature of the virtualization hypervisor which supports the VMs. 
• Implement virtual network(s) in accordance with the approved architecture for the type of application as defined in the DoD DMZ STIG and the Application Security and Development STIG, along with other operating system and application specific STIGs.   For example, a web service or application is typically required to have a tiered architecture with unrestricted/restricted DMZ zones with appropriate protections for internet/externally facing servers and private / “back end” zones with appropriate protections for application/database servers and other supporting systems/servers. 
• In the event the mission system/application is internet facing, implement (in addition to a zoned architecture described above) DMZ protections IAW the DMZ STIG. For example the DMZ STIG requires the following (adapted for Cloud):
  • Web server in a  public virtual network zone
  • Application and database servers in a private virtual network zone
  • Two Routers (virtual for cloud):
    • Outer – public zone to Internet
    • Inner public zone to private zone
  • Reverse Web Proxy (RWP)
  • FTP proxy if FTP is used
  • Web Application Firewall (WAF)
  • Security Information Manager (SIM)
  • Syslog server
  • Two Active directory servers
    • Public zone
    • Private zone

Impact Level 2: DMZ boundary protection requirements (i.e., proxies and firewalls) must be implemented by the mission owner for their application(s) or leverage a common boundary service provided by a larger entity like DoD Component or the DoD enterprise.  This will most likely occur on a CSP by CSP basis.  Other common services may also be available.

Impact Level 4: DMZ boundary protection requirements (i.e., proxies, firewalls, etc.) will be provided by the  Mission Owner in their system/application environment until such time as these protections are provided by the Mission Owner’s agency or DISA as an enterprise service. 

• When infrastructure has direct Internet access, implement virtual application level firewall and virtual intrusion detection and/or prevention capabilities IAW the applicable DoD SRGs and STIGs to protect the virtual network(s) and interconnected VMs.  The Mission Owner and/or their CDSP must be able to control firewall rules and monitor the virtual network boundary, reporting same to the Tier 1.  For dedicated infrastructure with a DISN connection (Levels 4-5): implement firewall, IPS, and/or routing methods that restrict traffic flow inbound and outbound to/from the virtual network to the DISN connection IAW DoDI 8551.  Block all traffic from all other sources such as the CSP’s network which is most likely connected to the Internet. 
• Implement a secure (encrypted) connection or path (i.e., encrypted VPN) between the virtual firewall, the virtual IDS capabilities and the CDSP responsible for the mission system/application.  See Section 6, Cyber Defense and Incident Response. for more specific information. 
• IaaS: Securely configure (harden / STIG) / patch / maintain each VM’s OS and IAW DoD policy and CYBERCOM direction.  The use of DoD STIGs and SRGs is required for secure configuration as is compliance with IAVMs.
• PaaS: For those VM OSs and applications under direct management of the Mission Owner (not the CSP per contract), securely configure (harden /STIG) / patch / maintain each VM’s OS and application provided by the CSP IAW DoD policy and United States Cyber Command (USCYBERCOM) direction.  The use of DoD STIGs and SRGs is required for secure configuration as is compliance with IAVMs.
• IaaS/PaaS: Securely configure (harden / STIG) / patch / maintain each application provided/installed by the Mission Owner IAW DoD policy and USCYBERCOM direction.  The use of DoD STIGs and SRGs is required for secure configuration as is compliance with IAVMs.
• Implement data-at-rest encryption on all DoD files housed in CSP IaaS storage service offerings.  A CSP may offer one or more services or methods to accomplish this.  Data-at-rest encryption may help mitigate issues with data/information spillage.  See Section 5.11, Encryption of Data-at-Rest for more information
• If the DoD information is sensitive government information (e.g., FOUO or CUI), FIPS 140-2 validated software cryptography modules operated in FIPS mode must be used.
• All encryption services for data-at-rest must be implemented such that the Mission Owner has sole control over key management and use.
• Implement Host Based Security System (HBSS) IAW DoD policy.
  • Implement HBSS agents on all VMs with a supported general purpose OS.
  • Utilize an HBSS agent control server within NIPRNet.
  • Implement a secure (encrypted) connection or path (i.e., encrypted VPN) between the HBSS agents and their control server. 
  • Provide visibility by the Mission Owner’s CDSP entities as defined in Section 6, Cyber Defense and Incident Response.
• Implement scanning using an Assured Compliance Assessment Solution (ACAS) server IAW USCYBERCOM TASKORD 13-670. 
  • Implement a secure (encrypted) connection or path (i.e., encrypted VPN) between the ACAS server and its assigned ACAS Security Center.
• Provide visibility by the Mission Owner’s CDSP entities as defined in Section 6, Cyber Defense and Incident Response.
  • Implement DoD PKI server certificates for establishing secure connections. 
• Implement all required data-in-transit encryption protections using FIPS 140-2 validated cryptography modules operated in FIPS mode.
• Implement DoD CAC / PKI authentication as follows:
  • For all privileged user access to VM operating systems and applications for Levels 2, 4, and 5 IAW DoD policy.  Level 6 must use the CNSS SIPRNet Token.
  • For all general DoD users of the implemented systems/applications for Levels 4 and 5 IAW DoD policy.  Level 6 must use the CNSS SIPRNet Token.
  • Implement a secure (encrypted) connection or path (i.e., encrypted VPN) between the implemented systems/applications and the DoD OCSP responders on NIPRNet or SIPRNet as applicable
• Secure Active Directory (AD) (if used) and any associated trusts IAW the DoD Windows OS STIGs and/or other applicable DoD STIGs.  This includes trusts between DoD AD forests and CSP CSO AD forests.  If such trusts are required, the implementation must be approved by the AO responsible for the DoD AD forest.  See Section 5.10.7, Active Directory Integration for Cloud for more information.
• Register the Protocols and Services along with their related UDP/TCP IP Ports used by the Mission Owner’s system/service/application that will traverse the DISN.  This includes all traffic for Levels 4, 5, and 6 as well as management/monitoring plane traffic for Level 2.  See Section 5.15, Ports, Protocols, Services, Management and Cloud for additional information.
• Register the Mission Owner’s system/service/application with the DoD whitelist for both inbound and outbound traffic if traffic will cross the IAPs. 
• Register the Mission Owner’s system/service/application and CSP’s CSO in the DISA SNAP database for the connection approval which also includes designating a certified CDSP as the Tier 2 MCD.  This step is required at all levels for IaaS/PaaS, including level 2 (even though there is no production connection to the DISN) so that the DoD CDSP community is aware and informed such that they can perform their Cyber Defense duties described in Section 6, Cyber Defense and Incident Response.
• Implement Computer Network Defense and Incident Response for monitoring issues across all CSPs used by DoD.

NOTE: Under PaaS (and potentially IaaS) where CSPs may be under contract to securely configure (harden / STIG) / patch / maintain Mission Owner’s VMs, OSs, applications, or maintain STIGed and patched VM images for their use, such services must be validated to DoD standards IAW all applicable policies (e.g., privileged access).  If the CSP is contracted by the Mission Owner to securely configure OSs and applications, then the CSP is expected to comply with all applicable DoD STIGs.  For IAVA compliance, the CSP will be expected to comply with industry best practice by applying patches identified in the CVE that would be referenced in the DoD IAVA.   Equivalencies will be assessed and approved on a case by case basis. 

5.10.7 Active Directory Integration for Cloud

Active Directory (AD) implementations (if needed) will be configured IAW the Active Directory Domain and Forest STIGs^[82] along with the following guidance related to Cloud services:

• DoD/Commercial CSP CSO on premises private/community (e.g., milCloud) managed AD:
  • AD servers and forests may establish trust relationships with other DoD managed AD servers and forests IAW established DoD guidelines.
• DoD Mission Owner managed AD instantiated in DoD/Commercial CSP CSO on premises private/community IaaS/PaaS (e.g., milCloud):
  • AD servers and forests may establish trust relationships with other DoD managed AD servers and forests IAW established DoD guidelines.
• DoD Mission Owner managed AD instantiated in Commercial off-premises IaaS/PaaS:
  • DoD AD forests will not trust Mission Owner managed AD servers or forests instantiated in Commercial IaaS/PaaS.
  • AD servers and forests may trust other DoD managed AD servers and forests IAW established DoD guidelines.  This trust must be one way.  Alternate methods than a direct trust such as those described in the following subsections should be used.
    NOTE: this mitigates the potential for a compromised Mission Owner’s AD in the commercial CSO being able to compromise a DoD AD on the DISN
• Non-DoD CSP CSO managed AD:
  • A Non-DoD CSP’s AD may be used to provide access control services to the CSO if it is an integral part of the CSO.  (e.g., for SaaS)
  • DoD AD forests will not trust a Non-DoD CSP’s AD servers or forest.
  • Only if absolutely required, a Non-DoD CSP’s AD forest may trust a DoD AD forest.  This trust must be one way.  Alternate methods than a direct trust such as those described in the following subsections should be used.
    NOTE: this mitigates the potential for a compromised CSP’s AD being able to compromise a DoD AD on the DISN.
    NOTE: Established DoD guidelines for AD implementation are found in the AD Domain and Forrest STIGs noted above.

5.10.7.1 Active Directory Federation Services (ADFS)

Active Directory Federation Services (ADFS) is used to extend on-premises Active Directory access control credential use and single sign-on (SSO) capabilities to web servers located in another organization such as a CSP’s SaaS CSO.  This capability will enable access control to multiple web applications over the life of a single browser session.  This is also applicable to providing SSO capabilities to a mission owner’s own web application instantiated in IaaS/PaaS CSO without placing an AD server in the virtual environment.  Since ADFS in essence allows the CSP’s CSO or external web application to trust the DoD identity claim asserted on behalf of the DoD AD, the use of ADFS meets the intent of the AD requirements stated above. 

5.10.7.2 Active Directory DirSync (Directory Synchronization)

Active Directory DirSync is a Microsoft Azure tool which is specific to a specific Microsoft SaaS CSO.  DirSync is installed on a domain-joined server (on-premises or on a Microsoft Azure VM) to “synchronize your on-premises Active Directory users to Office 365 for professionals and small businesses”^[83].Since this tool provides user information to the Office 365 AD as a push, then the Office 365 AD is used to provide access control to the CSO for those users, this tool meets the intent of the Non-DoD CSP managed AD requirements stated above. 

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

Mission systems at all impact levels must have the capability for DoD data to be encrypted at rest with exclusive DoD control of encryption keys and key management.  Some CSOs may facilitate this by providing a Hardware Security Module (HSM) or offering customer dedicated HSM devices as a service.  CSOs that do not provide such a capability may require Mission Owners to utilize encryption hardware/software on the DISN or a cloud encryption service that provides DoD control of keys and key management. 

Data-at-rest (DAR) encryption with customer controlled keys and key management protects the DoD data stored in CSOs with the following benefits:

• Maintains the integrity of publicly released information and web sites at Level 2 where confidentiality is not an issue.
• Maintains the confidentiality and integrity of CUI at levels 4 and 5 with the following benefits:
  • Limits the insider threat vector of unauthorized access by CSP personnel through increasing the work necessary to compromise/access unencrypted DoD data.
  • Limits the external threat vector of unauthorized access by hackers trough increasing the work necessary to compromise/access unencrypted DoD data.
  • Enables high-assurance data destruction for CSP off-boarding through cryptographic erasure and file deletion without the involvement or cooperation of a CSP. 
  • Enables high-assurance data spill remediation through cryptographic erasure and file deletion without the involvement or cooperation of a CSP. 
  • See Section 5.11.1, Cryptographic Erase for additional information. 

NOTE: Mission Owners and their AOs should consider the benefits of DAR encryption for data destruction and/or spill remediation at Level 2 in addition to the benefit of maintaining integrity of the information. 

For all Information Impact levels:

• Encrypt all Data at Rest (DAR):
  • Stored in virtual machine virtual hard drives or
  • Stored in mass storage facilities/services whether at the block or file level
  • Stored in database records (whether PaaS, SaaS where the MO does not have sole control over the DB and DBMS)
• Using FIPS 140-2 validated cryptography modules^[84] (minimally Level 1) operated in FIPS Mode in accordance with Federal government policy / standards for the protection of all CUI. 
  • Cryptography modules include cryptographic algorithm, RNG, KMI, HASH, etc. (all approved functions)
• CSP Customer / Mission Owner (MO) maintains control of the keys, from creation through storage and use to destruction
  • Implement Hardware Security Modules (HSM) or Key Management Servers as needed to store, generate, and manage keys within the DISN
• OR Order a CSP service that provides a dedicated HSM that is managed solely by the customer/MO

For cloud applications where encrypting DAR with DoD key control is not possible, Mission Owners must perform a risk analysis with relevant data owners before transferring data into a CSO.  This analysis must take into account that there may be no high-assurance method available to remediate data spills or ensure destruction of data at the application’s end of life and CSO off-boarding.  Mission Owner AOs are responsible for accepting these risks.

NOTE: CSPs CSOs DAR encryption capabilities and ability to support Mission Owner’s DAR encryption requirements will be assessed and documented toward the award of their DoD PA.

Corresponding Security Controls: SC-28, SC-28(1)

5.11.1 Cryptographic Erase

Cryptographic erase is described in NIST SP 800-88 Rev 1^[85]:

“Cryptographic Erase is an emerging sanitization technique that can be used in some situations when data is encrypted as it is stored on media. With CE, media sanitization is performed by sanitizing the cryptographic keys used to encrypt the data, as opposed to sanitizing the storage locations on media containing the encrypted data itself. CE techniques are typically capable of sanitizing media very quickly and could support partial sanitization, a technique where a subset of storage media is sanitization. Partial sanitization, sometimes referred to as selective sanitization, has potential applications in cloud computing.”

While much of the CE guidance in SP 800-88 is related to self-encrypting devices, this section expands on NIST’s acknowledgement that CE has applicability in cloud computing.

DAR encryption, coupled with exclusive customer control of cryptographic key management, provides DoD the ability to cryptographically erase data at rest without CSP assistance or cooperation.  This capability coupled with standard CSP provided data deletion provides the following benefits described for DAR encryption in Section 5.11 above.

Data deletion refers to normal file or data record deletion methods used in file systems and data bases.  Deletion before or after cryptographic erase will restore resources to the CSP and will permit for the eventual overwriting of the data under normal operations.

To support cryptographic erase and the various benefits it provides DAR encryption must be performed at an appropriate level of granularity.  This means that one key should not be used to encrypt all or large chunks of mission owner data. 

Related Security Controls: MP-6(3), MP-6(8)

5.12 Backup

CSPs are responsible for providing backups of data in a CSO consistent with the CP-9 security control.  Mission Owners are also responsible for assuring their data is backed up consistent with the CP-9.  However, mission owners must also consider the risk of entrusting their data to a single non-DoD CSP.  Section 5.8, Data Retrieval and Destruction for Off-boarding from a CSO discusses the importance of Mission Owners being ready to recover and/or migrate their data on short notice in case of CSO shutdown.  This readiness, along with CSP backup requirements, may be sufficient for DoD data of low to moderate impact value.  However, Mission Owners with higher impact value data should consider conducting regular backups of their data and storing them in DoD-owned infrastructure/media or a cloud storage service offered by a different CSP.

Backups stored with a different provider reduce the risk of data loss/corruption in the case of a CSO ceasing operations or catastrophic event that affects a CSP’s entire infrastructure.  Maintenance of such backups may also mitigate the risk of data loss sustained from of a data spillage response.  Mission Owners should determine the potential need for such risk mitigation as part of the contingency planning required by the CP-2 security control.

NOTE: In the case of IaaS/PaaS backups, “data” as used in this section includes VM snapshots or images of the fully configured VMs including their virtual hard drives so that restoration of the computational base is as easy as the restoration of the information processed. 

NOTE: This section is provided for consideration by Mission Owners.  It does not affect CSPs or DoD PA assessments.

Corresponding Security Controls: CP-2, CP-9

5.13 DoD Contractor / DoD Component Mission Partner Use of CSOs

This section focuses specifically on Non-CSP DoD contractors or mission partners (e.g., Defense Industrial Base (DIB) contractors) and DoD Component mission partners (e.g., commissaries, exchanges, educational entities) whose networks that are not part of the DoDIN .mil domain.  These mission partners and their networks are typically in the .gov, .org, .com, .edu domains. 

When using cloud services, mission partners and contractors are responsible for following all guidance in this CC SRG related to the Mission Owner that is not specific to a DISN-provided capability (e.g. CAP) or an enterprise service.  The appropriate impact level must be selected based on the DoD data being processed.  A trusted means of communication that encrypts all DoD data transferred between mission partners and contractor internal networks and CSPs must be utilized.  Mission partners and contractors are also responsible for working with the appropriate DoD data owner or designated agency (e.g. DSS) to create incident response procedures for incidents that occur in a CSO. 

NOTE: the term “Non-CSP DoD Contractors” as used below does not include DoD Contractors that are not a CSP but aggregate CSOs (i.e., integrators) in the fulfilment of a contract for cloud services. As such, and as noted elsewhere in this CC SRG, the CSOs these non-CSP integrators are providing via subcontracts must follow all guidance related to CSOs and DoD’s usage of them.

5.13.1 DoD Component mission partners

DoD Component mission partners in the .gov, .org, .com, .edu domains must only use CSPs or CSOs that have a DoD PA for the Information Impact Level that best matches the CNSSI 1253 categorization of the information to be processed/stored/transmitted by the CSP/CSO.  If the information is public, then a Level 2 CSO will be used with direct Internet access. Otherwise, accessing Level 4/5 services depends on how their organizational network/enclave is connected today. This is as follows:

• The organizational network/enclave: Is part of NIPRNet; connectivity to the CSO will be via the NIPRNet BCAP
• Is part of a Mission partner or CIO network with a BCAP; connectivity to the CSO will be via that BCAP
• Is directly connected to the Internet via one or more approved organizational IAPs; connectivity to the CSO will be via the Internet or a private direct connection

DoD Component mission partners are responsible for implementing appropriate boundary protections for their networks.

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

Non-CSP DoD contractors and DIB partners may store,  process, and use or create sensitive DoD data/information outside of the DoDIN in conjunction with a DoD contract not associated with providing cloud services. Such contractors are required to protect unclassified sensitive DoD data/information while it is in their environment IAW DoDI 8582.01, Security of Unclassified DoD Information on Non-DoD Information Systems^[86] and NIST SP 800-171, Protecting Controlled Unclassified Information in Nonfederal Information Systems and Organizations^[87]which mainly focuses primarily on confidentiality.

Non-CSP DoD contractors and DIB partners may wish to utilize Cloud Services in the fulfilment of their contract or for the protection/processing of DoD data they possess.  Thus, for the protection of sensitive DoD information, it is highly recommended that Non-CSP DoD contractors utilize CSOs that have been granted a DoD Level 4/5 PA that best matches the CNSSI 1253 categorization of the information to be processed/stored/transmitted by the CSP/CSO.  Such CSOs must not be dedicated to DoD which would mean the CSO is only connected to the NIPRNet.  That said, access to the CSP/CSO will be via the Internet or a private direct connection. The NIPRNet will not be used as a connection path.  DoD contractors are responsible for implementing appropriate boundary protections for their networks.

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

A Non-CSP DoD Contractor might choose to integrate a third party CSO as a component of a contracted Non-CSO product or service (e.g., a weapons system or major application).  Such contractors may only utilize third party CSPs or CSOs that have a DoD PA for the Information Impact Level that best matches the CNSSI 1253 categorization of the information to be processed/stored/transmitted by the CSP/CSO.  Furthermore, the CSO and its use must follow the CC SRG guidance related to the Mission Owner that is not specific to a DISN-provided capability (e.g. CAP) or an enterprise service to the greatest extent possible. Connectivity to the CSO will be determined by where the contracted product or service will be used and related guidance in this CC SRG. For example if the user base for the product or service is NIPRNet based and the Information Impact Level is 4 or 5, then the NIPRNet BCAP must be used. If the Information Impact Level is 2, then the Internet may be used. All CC SRG requirements apply to the product and flow down to the sub-contracted CSO IAW various DFARS clauses.

In the event the Non-CSP DoD contractor chooses to provide/host the CSO themselves, the CC SRG requirements for the Information Impact Level that best matches the CNSSI 1253 categorization of the information to be processed/stored/transmitted by the CSO applies. If the CSO is dedicated to the product, A&A will handled IAW normal DoD contract A&A requirements.  Consideration for awarding a DoD PA in this case will depend on the results of the A&A processes, compliance with the CC SRG, and the potential for other DoD Component’s Mission Owners to use the CSO.

5.14 Mission Owner DoD Test and Development in the Cloud

Cloud environments are a good place Mission Owners to do application development and testing as well as research.  Furthermore, test and development activities associated with application lifecycle management for cloud based applications are best performed in the same environment as the production application.  This section addresses DoD Test and Development (T&D) activities in IaaS and PaaS CSOs.

Security requirements for DoD T&D and laboratory environments are defined in the suite of Enclave T&D STIGs^[88].  Refer to these STIGs on IASE for the latest guidance. 

The Enclave T&D STIG Overview document defines four (4) T&D Zones.  These zones are briefly described as follows:

• Zone A: Instrumental in application lifecycle management for final end stage testing prior to implementation into a production environment.  This environment is connected to the production network to replicate the final production environment supporting the application.  The use of VPNs for remote access for developers and administrators may be implemented, but must be terminated in the T&D DMZ for inspection.  The assets in the environment are secured the same as the production environment to include STIG and IAVM compliance.  Minimal development is permitted for final revisions and minor updates in the final testing phase.
• Zone B: Instrumental in application lifecycle management for application development activities such as coding, compliance, and testing. This environment provides connectivity to the production network with access controls in place to protect the production network for application testing.    Provides an isolated network segment for the use of tools and capabilities to facilitate application development that would not be permitted in the production environment.  Implements remote access to the testing segment of the environment for developers and administrators.  Is secured WRT STIG and IAVA compliance at the discretion of the IAM.
• Zone C: Closed test environment not connected to DoD production networks but interconnects multiple testing environments through the use of direct connections or tunneling mechanisms.  This environment can be used for testing systems, devices, applications, tools, and/or protocols where their security posture or potential to threaten DoD production networks is unknown or known to be risky while needing long-haul network connectivity. 
• Zone D: A fully closed and physically separate network from any DoD live operational network for the purpose of extensive testing using prohibited tools, working with malicious code, virus samples, working with Ports, Protocols, and Services (PPS) that are otherwise restricted via DoD policy.  Development within this environment is generally not an encouraged practice.

All DoD test and development performed in cloud infrastructure must be categorized IAW the T&D Zone descriptions in the Enclave T&D STIG Overview document and comply with the security requirements in the associated Enclave T&D STIG.

Since Zones A and B are instrumental in application lifecycle management and able to be connected to the production network, it is reasonable that these zones can be implemented in the same IaaS/PaaS cloud infrastructure as the production applications they support.  Due to the robust routing and filtering capabilities inherent in today’s virtual networks, the segmentation of these zones can easily be implemented IAW the related Zone A and B STIG requirements using VLANs or distinct virtual networks. 

DoD application development Zone B instantiated in cloud infrastructure must minimally be implemented in a CSP’s CSO that has a Level 2 PA.  Consideration for implementing Zone B in a Level 4/5 CSO will depend on the sensitivity of the application itself and its code.  If the Zone B is used for the lifecycle management of a production application, then it should be implemented in the same CSP/CSO as the production application. 

DoD application test Zone A instantiated in cloud infrastructure must be implemented in the same CSP/CSO as the production application to support lifecycle management of the application.  The sensitivity of the information processed by the production application determines the information impact level of the CSP and their PA IAW this SRG, thus the test environment using similar data must be at the same information impact level. 

It is highly recommended to realize the efficiencies of the Cloud that Zones A and B be implemented in the same CSO and impact level where the final production application will operate in support of its lifecycle management and ease of migrating the application from Zone B through Zone A to production.  As such, access to these zones will be via the same path (i.e., Internet or DISN BCAP) as is used for the production zone with the exception that access to zone B will use the management plane only. 

While Zones C and D are typically implemented in physical facilities and while various aspects may use virtualization, these zones may only be implemented in cloud services providing the required lack of connectivity to DoD production networks.  This generally precludes on-premises cloud services which are intended for wide usage by multiple DoD tenants such as milCloud as designed today.  Alternately Zones C and/or D might be implemented in an off-premises commercial cloud environment where there is no direct connectivity to DoD networks, providing the testing activities do not threaten the CSP’s CSO and/or network, other CSP tenants’ systems/applications or the Internet.  Exceptions and requirements for these use cases may be provided in a future release of this or another SRG.    Zones C and D which might be categorized at Levels 4/5/6 and implemented in off-premises CSOs are not permitted to connect to the DISN.

Corresponding Security Controls: CM-4, CM-4 (1)

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

Mission Owners using CSOs of any service type (I/P/SaaS) must comply with DoDI 8551.01: Ports, Protocols, and Services Management (PPSM)^[89] when implementing and operating their systems/applications in an IaaS/PaaS CSO or when using a SaaS offering.  DoDI 8551.01 is the DoD policy that provides policy guidance for DoD Mission Owner compliance with CM-7, CM-7 (1), and SA-9 (2).  While CSPs must comply with these C/CE for their internal networks and service offerings, DoDI 8551.01 does not apply to CSPs as the policy applies to Protocols And Services (PS) traversing the DISN.

The DISA PPSM office^{[90] [91]}, along with the PPSM Change Control Board (CCB) and Technical Advisory Group (TAG) publish a Category Assignment List (CAL) which lists the PS permitted to cross certain DISN boundaries and Vulnerability Assessments (VAs) for each PS listed.   Compliance with VAs is the key to the secure usage of the PS listed in the CAL. In other words, PS used on the DISN must comply with the associated VA.  Mission Owners must utilize the mitigations presented in the PPS VAs when building their systems.  Additionally all Mission Owners must register their cloud CSO based systems/applications in the DoD PPSM Registry (only available on SIPRNet) to include systems/applications in an I/PaaS CSO or when using a SaaS offering.  Registration includes all PS along with their related UDP/TCP IP Ports used by the application that will traverse the DISN.  This includes all user and management plane traffic for Levels 4, 5, and 6 as well as management plane traffic for Level 2 if managed/monitored from within a DoD network. 

The remainder of this section of the CC SRG provides guidance to mission owners when registering their applications in the PPSM database.

Level 2 Off-premises CSO: A Level 2 Mission Owner virtual network, virtual machines, and applications in IaaS/PaaS CSOs constitute a DoD enclave within and accessed via an external network.  Similarly a SaaS CSO is an enclave within and accessed via an external network.  This external network is the Internet.  So for Level 2 the Mission Owner should leverage PPSM guidance for PPSM boundaries 1-5.  This is only applicable to Mission Owner’s management traffic for their virtual networks and systems/applications in IaaS/PaaS and CSO management traffic for I/P/SaaS.  When registering the application in the PPSM database the Mission Owner should register on boundaries 1-5.  Since non-privileged user traffic will be via the Internet, registration is not required even if a portion of this traffic is to/from non-privileged users within the DoDIN.  Such traffic will traverse the DISN IAPs as any other web based traffic.

NOTE: This guidance may change with regard to user plane traffic pending a decision of the PPSM CCB.  Since firewalls and sensors are required at the boundary of a Mission Owner’s virtual enclave and since the sensors will be monitored by the MCD protecting the Mission Owner’s system/application, the same or similar guidance as is provided for Level 4/5/6 below may be applicable.

Level 2/4/5/6 On-premises CSO: On-premises CSOs at any level will be treated as normal DoD enclaves.  PPSM Registrations will utilize boundary designations 7-11 if directly connected or 10-12 and 15 if connected via an IPSEC tunnel.

Levels 4/5/6 Off-premises CSO: IAW the CC SRG, Levels 4/5/6 Off-premises CSOs will be treated as normal DoD enclaves since they are architected as extensions of the DoDIN/DISN even though the CSO is in an external network (the CSP’s network) and are connected via a BCAP.   As such, PPSM Registrations will utilize boundary designations 7-11 if directly connected or 10-12 and 15 if connected via an IPSEC tunnel.

NOTE: PS designated as local services may be used within the Mission Owner’s system/application virtual enclave in IaaS/PaaS CSOs as with any other enclave providing they do not traverse the virtual enclave’s boundary.

5.16 Mobile Code

Mobile code is defined as software programs or parts of programs obtained from remote information systems, transmitted across a network, and executed on a local information system without explicit installation or execution by the recipient.  Some examples of software technologies that provide the mechanisms for the production and use of mobile code include Java, JavaScript, ActiveX, VBScript, etc.

Mobile Code presents a great number of attack vectors to both CSPs and DoD Mission Owners.   CSP organizational IT systems as well as the infrastructure that supports CSOs are vulnerable to malicious mobile code, and if compromised, the security of DoD Mission Owner’s systems/applications/information/data can be negatively affected.  Additionally compromised CSOs and DoD Mission Owner’s systems/applications can negatively affect a customer’s endpoint and network if malicious mobile code is served by (downloaded from) these systems.  

While DoD mobile code policies are under revision, CNSS and DoD has identified mobile code in categories as follows:

“Category 1: Mobile code technologies that exhibit a broad functionality, allowing unmediated access to the workstation, server, and remote system services and resources. Category 1 mobile code technologies have and pose known security vulnerabilities with few or no countermeasures once executing.

Category 2: Mobile code technologies that have full functionality, allowing mediated access to the workstation, server, and remote system services and resources. Category 2 mobile code technologies have and pose known security vulnerabilities, however, known fine grained, periodic, or continuous countermeasures/safeguards exist.

Category 3: Mobile code technologies that have limited functionality, with no capability for unmediated access to the workstation, server, and remote system services and resources. Category 3 mobile code technologies may have a history of having and posing known security vulnerabilities, but also support known fine grained, periodic, or continuous countermeasures/safeguards.

Emerging Mobile Code Technologies: All mobile code technologies, systems, platforms, or languages whose capabilities and threat level have not yet undergone a risk assessment and been categorized as described above.”

While most of the compliance with DoD Mobile Code policy is the responsibility of the Mission Owner, SC-18 (2) states “The organization ensures that the acquisition, development, and use of mobile code to be deployed in information systems meets organization-defined mobile code requirements”. The following applies to DoD IS:

1. “(a) Emerging mobile code technologies that have not undergone a risk assessment and been assigned to a Risk Category by the CIO are not used.
2. (b) Category 1 mobile code is signed with a code signing certificate; use of unsigned Category 1 mobile code is prohibited; use of Category 1 mobile code technologies that cannot block or disable unsigned mobile code (e.g., Windows Scripting Host) is prohibited.
3. (c) Category 2 mobile code which executes in a constrained environment without access to system resources (e.g., Windows registry, file system, system parameters, and network connections to other than the originating host) may be used.
4. (d) Category 2 mobile code that does not execute in a constrained environment may be used when obtained from a trusted source over an assured channel (e.g., SIPRNet, SSL connection, S/MIME, code is signed with an approved code signing certificate).
5. (e) Category 3 (mobile code having limited functionality, with no capability for unmediated access to the services and resources of a computing platform) mobile code may be used."

DoD expects the CSP to enact similar Mobile Code Policies for SC-18 (2) for their organizational IT systems and the infrastructure supporting their CSO(s) for the protection of the CSO(s), Mission Owners’ systems/applications/information/data in the CSO. Furthermore DoD expects that the CSP’s CSO will not enable or permit the download of unapproved/risky mobile code, for the protection of the CSO’s end users as well as Mission Owner’s and their end user’s systems and networks. SC-18 (2) is under consideration for addition to the FedRAMP+ baseline for all impact levels.

Similarly SC-18 (3) and SC-18 (4) have been assigned values in Table 9. These are currently in the set of SLA controls to be considered by Mission Owners for inclusion in the SLA/Contract. These too, are under consideration for addition to the FedRAMP+ baseline for all impact levels.

Mission Owners systems/applications must not download and execute mobile code except as permitted above, and must not enable or permit the download of unapproved/risky mobile code, for the protection of the system’s/application’s end users as well as their end user’s systems and networks.

5.17 Registration and Connection Approval for Cloud Based Systems/Applications

This section provides information on the various registrations required for cloud based systems/applications in addition to PPSM registration discussed in Section 5.15, Ports, Protocols, Services, Management and Cloud Based Systems/Applications.

5.17.1 DISA Systems/Network Approval Process (SNAP)

All Mission Owners are required to register all Cloud based systems/applications; their CSP/CSO, MCD, and connection method in the DISA Systems/Network Approval Process (SNAP)^[92] database Cloud Module.  This registration will enable these systems/applications to be connected to the DISN and is crucial for the situational awareness of the Cyber Defense community tasked with protecting the DoDIN, DoD information, and the Mission Owners Cloud based systems/applications.

5.17.2 DoD Whitelist

In the event the Mission Owners Cloud based systems/applications requires traffic to traverse the DISN IAPs, the systems/applications URLs/IP addresses must be registered with the DoD DMZ Whitelist.  Traffic that will typically traverse the IAP is management traffic for Level 2 off-premises systems/applications and for user plane traffic to/from Level 4/5 systems/applications that are internet facing (i.e., accessed from the Internet via the DoD DMZ extension connected to a BCAP). Such traffic and IP addresses may be blocked if not registered in the Whitelist. Mission Owners must contact their DoD Component’s point of contact to have their entry added to the Whitelist.

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

In compliance with the DoD Memo, "Updated Guidance on the Acquisition and Use of Commercial Cloud Computing Services," 15 Dec 2014, DoD Components will report all appropriate information within the Select and Native Programming Data Input System- Information Technology (SNaP-IT)^[93] as directed in DoD CIO annual IT budget guidance for each utilized cloud computing service.  SNaP-IT is the authoritative DoD database used for publishing the DoD IT Budget estimates to Congress and the OMB Circular A-11 Section 53 and Section 300 exhibits to OMB for Information Technology.  To comply, Components MUST respond to the SNaP-IT Profile questions for the Exhibit 53 into two submissions; the Exhibit 53A, 'Agency IT Investment Portfolio Summary', and the Exhibit 53C, the 'Agency Cloud Computing Spending Summary'.  Components must identify whether a cloud computing option was evaluated for each investment, and provide detail as instructed.  Components fulfill their requirement for all Exhibits 53s by completing their SNaP-IT Profile, Resource, and Budget Support Data for each component investment. 

5.18 Supply Chain Risk Management Assessment

The DoD selected FedRAMP+ control SA-12 addresses Supply Chain Risk Management (SCRM) while SA-19 deals with component authenticity. The acquisition of system components and software that are counterfeit, unreliable, or contain malicious logic or code is of great concern to DoD for all products supporting the processing, storage, and transmission of CUI and classified information. This concern extends to Cloud Computing.

As part of the CSO’s DoD PA assessment package, the CSP will provide a SCRM plan outlining their supply chain assessment/management and component authenticity process and measures taken such that they are not acquiring system components and software that are counterfeit, unreliable, or contain malicious logic or code and incorporating them into the CSO infrastructure or its management plane.

The CSP’s SCRM plan for how the CSP implements SA-12 and SA-19 will be assessed and approved during the DoD PA assessment process for all Impact Level 4, 5, and 6 CSOs.

5.19 Electronic Mail Protections IAW TASKORD 12-0920

US CYBERCOM Task Order (TASKORD) 12-0920 requires the use of the Enterprise E-Mail Security Gateway (EEMSG) for all email inbound from, or outbound to, the Internet. It further requires email outbound from one DoD Component’s email servers to another Component’s email servers to pass through the EEMSG. The EEMSG only deals with server to server email traffic, it does not deal with client to server traffic. All DoD Components are required to use the EEMSG unless a waiver is in place. In the event a waiver is in place, the DoD Component must use their own email security gateway.

Therefore IAW the full TASKORD:

• All email transfers inbound through the IAP from an external email server destined to a L4/5 email server in a Mission Owner’s enclave within a CSO via a BCAP must pass through the EEMSG inbound protections.
• All email transfers sent from a L4/5 email server in a Mission Owner’s enclave within a CSO via a BCAP and through the IAP to an external email server must pass through the EEMSG outbound protections
• All email transfers sent from a L4/5 email server in a Mission Owner’s enclave within a CSO via a BCAP to email servers in a DoD Component’s data center enclave must pass through the EEMSG outbound protections.
• All Email transfers sent from email servers in DoD Component's data center enclave to a L4/5 email server in a Mission Owner’s enclave within a CSO via a BCAP must pass through the EEMSG outbound protections.

This requirement and interpretation of the TASKORD is based on the fact that the Mission Owner’s environment in any CSO is considered a DoD enclave that may include an email server either as the primary service SaaS offering or as an adjunct service to a PaaS/SaaS, or may be instantiated by the Mission Owner in IaaS. 

In the event two Mission Owners utilize the same email SaaS and email servers, there is no need for EEMSG protections for email between the different Mission Owners’ users. However, in the event the CSO implements different servers/enclaves for different Mission Owners, the CSO must include an email hygiene/protective service through which email transfers between these servers/enclaves will route. In this case the server-to-server email traffic will remain within the CSP’s infrastructure and not traverse the CAP or EEMSG. Similarly, Mission Owners that implement email servers in IaaS or leverage a PaaS feature within their CSO based enclaves will follow the same rules as above for SaaS and must provide for email hygiene/protective service within the CSO for enclave to Mission Owner enclave to Mission Owner enclave traffic or route such traffic through the BCAP and EEMSG.

All BCAPs must support Mission Owner’s and implement the appropriate routing of server-to-server email traffic to/from the EEMSG capability at the CAP end of the connection for all CSOs that contain an email server. This includes routing to/from such servers and the IAP for email servers that are external and Internet connected. This is a CSO connection approval requirement. However it is ultimately a Mission Owner responsibility for TASKORD compliance when they use a CSO or implement a system/application in IaaS/PaaS. 

NOTE: As of this release of the CC SRG, EEMSG does not currently inspect intra-enclave email. Therefore the above requirements do not apply to email traffic that remains within the DISN and Mission Owner enclaves in a CSO, until EEMSG does inspect intra-enclave email. That said, the requirement for EEMSG to inspect all email traffic to/from the Internet based email servers still applies.

Appendix A - sReferences

1. Public Law 93-579, as codified at 5 U.S.C. 552a, Privacy Act of 1974
   http://www.archives.gov/about/laws/privacy-act-1974.html
2. Public Law 104-191, Health Insurance Portability and Accountability (HIPAA) Act of 1996
   http://www.gpo.gov/fdsys/pkg/PLAW-104publ191/content-detail.html
3. Public Law 83-703, Atomic Energy Act of 1954, as amended,
   http://pbadupws.nrc.gov/docs/ML1327/ML13274A489.pdf#page=23
4. 22 Code of Federal Regulations (CFR), 22 CFR 120.15 – US Persons, 120-16 – Foreign persons,
   https://www.gpo.gov/fdsys/pkg/CFR-2011-title22-vol1/pdf/CFR-2011-title22-vol1-sec120-15.pdf
5. 8 U.S. Code § 1408 - Nationals but not citizens of the United States at birth,
   https://www.gpo.gov/fdsys/pkg/USCODE-2010-title8/pdf/USCODE-2010-title8-chap12-subchapIII-partI-sec1408.pdf
6. Executive Order 13526:  Classified National Security Information, dated 29 December 2009.
   http://www.archives.gov/isoo/policy-documents/cnsi-eo.html
7. Executive Order 12829 – National Industrial Security Program, January 1993. 
   http://www.archives.gov/isoo/policy-documents/eo-12829.html
8. Executive Order 13556 - Controlled Unclassified Information. 
   https://www.whitehouse.gov/the-press-office/2010/11/04/executive-order-13556-controlled-unclassified-information
9. EO 12958, Classified National Security Information (April 17, 1995) as amended by EO 13292.
   http://www.archives.gov/isoo/policy-documents/eo-12958-amendment.html
10. 48 Code of Federal Regulations (CFR) Subpart 4.4 - Safeguarding Classified Information within Industry. 
    https://www.gpo.gov/fdsys/granule/CFR-2011-title48-vol1/CFR-2011-title48-vol1-part4-subpart4-4
11. Federal Acquisition Regulations (FAR) section 52.204-2 - Security Requirements. 
    https://www.gpo.gov/fdsys/pkg/CFR-2002-title48-vol2/pdf/CFR-2002-title48-vol2-sec52-204-1.pdf
12. NIST FIPS 199:  Standards for Security Categorization of Federal Information and Information Systems, dated February 2004.
    http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf
13. NIST SP 500-292:  NIST Cloud Computing Reference Architecture, dated September 2011.
    http://www.nist.gov/customcf/get_pdf.cfm?pub_id=909505
14. NIST SP 800-53:  Recommended Security Controls for Federal Information Systems and Organizations, Revision 4, dated April 2013.
    http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf
    Note:  http://csrc.nist.gov/publications/PubsSPs.html contains additional documents relating to SP 800-53.
15. NIST SP 800-59:  Guideline for Identifying an Information System as a National Security System, dated August 2003.
    http://csrc.nist.gov/publications/nistpubs/800-59/SP800-59.pdf
16. NIST SP 800-66, Revision 1:  An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule, dated October 2008.
    http://csrc.nist.gov/publications/nistpubs/800-66-Rev1/SP-800-66-Revision1.pdf
17. NIST SP 800-88, Revision 1: Guidelines for Media Sanitization, dated September 2012. 
    http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-88r1.pdf
18. NIST SP 800-122:  Guide to Protecting the Confidentiality of Personally Identifiable Information (PII), dated April 2010.
    http://csrc.nist.gov/publications/nistpubs/800-122/sp800-122.pdf
19. NIST SP 800-144:  Guidelines on Security and Privacy in Public Cloud Computing, dated December 2011.
    http://csrc.nist.gov/publications/nistpubs/800-144/SP800-144.pdf
20. NIST SP 800-145: The NIST Definition of Cloud Computing, dated September 2011. 
    http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf
21. NIST SP 800-37, Revision 1: Guide for Applying the Risk Management Framework to Federal Information Systems, dated February 2010.  http://csrc.nist.gov/publications/nistpubs/800-37-rev1/sp800-37-rev1-final.pdf  
22. NIST SP 800-171, Protecting Controlled Unclassified Information in Nonfederal Information Systems and Organizations, dated June 2015. 
    http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-171.pdf   
23. CNSS Instruction 4009:  National Information Assurance (IA) Glossary, dated 30 April 2010.   
    https://www.cnss.gov or www.cnss.gov/cnss/issuances/Instructions.cfm
24. CNSS Instruction 1253:  Security Categorization and Control Selection for National Security
    Systems, dated 27 March 2014.
    https://www.cnss.gov or www.cnss.gov/cnss/issuances/Instructions.cfm
25. CNSS Instruction No.1253F, Attachment 5: Classified Information Overlay dated 09 May 2014. 
    https://www.cnss.gov  or www.cnss.gov/cnss/issuances/Instructions.cfm
26. CNSS Instruction No.1253F, Attachment 6: Privacy Overlay dated 20 April 2015. 
    https://www.cnss.gov  or www.cnss.gov/cnss/issuances/Instructions.cfm
27. DoD Chief Information Officer, Updated Guidance on the Acquisition and Use of Commercial Cloud Computing Services, 15 December 2014.
    http://iase.disa.mil/Documents/commercial_cloud_computing_services.pdf
28. DoD Instruction 8500.01: Cybersecurity, dated 14 March 2014. 
    http://dtic.mil/whs/directives/corres/pdf/850001_2014.pdf
29. DoD Instruction 8510.01: Risk Management Framework (RMF) For DoD Information Technology (IT), dated 12 March 2014. 
    http://dtic.mil/whs/directives/corres/pdf/851001_2014.pdf
30. DoD Instruction 8520.03: Identity Authentication for Information Systems, dated 13 May, 2011.
    http://dtic.mil/whs/directives/corres/pdf/852003p.pdf
31. DoD Instruction 8551.01: Ports, Protocols, and Services Management (PPSM), May 28, 2014.
    http://www.dtic.mil/whs/directives/corres/pdf/855101p.pdf
32. DoD Instruction 8410.01, Internet Domain Name Use and Approval, dated April 14, 2008.
    http://www.dtic.mil/whs/directives/corres/pdf/841001p.pdf
33. DoD Instruction O-8530.2, "Support to Computer Network Defense (CND)", March 9, 2001.
    https://whsddpubs.dtic.mil/corres/pdf/O85302p.pdf (PKI required)
    NOTE: DoD Instruction O-8530.2 has been updated and is soon to be replaced with the following:
34. DoD Instruction 8530.01, "Cybersecurity Activities Support to DoD Information Network Operations”
    http://www.dtic.mil/whs/directives/corres/pdf/853001p.pdf
35. DoD Joint Publication 3-12 (R), "Cyberspace Operations"
    http://www.dtic.mil/doctrine/new_pubs/jp3_12R.pdf
36. 36.  DoD Instruction 8582.01, Security of Unclassified DoD Information on Non-DoD Information Systems, June 6, 2012.
    http://www.dtic.mil/whs/directives/corres/pdf/858201p.pdf
37. DoD Instruction 8320.07, Implementing the Sharing of Data, Information, and Information Technology (IT) Services in the Department of Defense
    http://www.dtic.mil/whs/directives/corres/pdf/832007p.pdf
38. DoD 5220.22-R: Industrial Security Regulation (ISR), dated December 1985. 
    http://www.dtic.mil/whs/directives/corres/pdf/522022r.pdf
39. DoD Instruction 5220.22: National Industrial Security Program, dated March 2011. 
    http://www.dtic.mil/whs/directives/corres/pdf/522022p.pdf
40. DoD Manual 5220.22 Manual: National Industrial Security Program: Operating Manual (NISPOM), dated march 2013.
    http://www.dtic.mil/whs/directives/corres/pdf/522022m.pdf
41. DoD Instruction 5200.01: DoD Information Security Program and Protection of SCI, dated June 2011.
    http://www.dtic.mil/whs/directives/corres/pdf/520001p.pdf
42. DoD Manual 5200.01 Vol 1: DoD Information Security Program: Overview, Classification and Declassification, dated February 2012.
    http://www.dtic.mil/whs/directives/corres/pdf/520001_vol1.pdf
43. DoD Manual 5200.01 Vol 2: DoD Information Security Program: Marking of Classified Information, dated March 2013.
    http://www.dtic.mil/whs/directives/corres/pdf/520001_vol2.pdf
44. DoD Manual 5200.01 Vol 3: DoD Information Security Program: Protection of Classified Information, dated March 2013.
    http://www.dtic.mil/whs/directives/corres/pdf/520001_vol3.pdf
45. DoD Instruction 5200.02: DoD Personnel Security Program (PSP), Change 1 dated September 2014.
    http://www.dtic.mil/whs/directives/corres/pdf/520002_2014.pdf
46. DoD Manual 5200.2-R: Personnel Security Program, dated February 1996. 
    http://www.dtic.mil/whs/directives/corres/pdf/520002r.pdf
47. CJCSM 6510.01B:  Chairman of the Joint Chiefs of Staff Manual: Cyber Incident Handling Program, dated 10 July 2012.  (Current as of 18 December 2014).
    http://www.dtic.mil/cjcs_directives/cdata/unlimit/m651001.pdf
48. DSS Facility Clearance Branch.
    http://www.dss.mil/isp/fac_clear/fac_clear.html   
49. DoD ECA PKI Certificate.
    http://iase.disa.mil/pki/eca/Pages/index.aspx  
50. OPM Position Designation System 2010.
    http://www.opm.gov/investigations/background-investigations/position-designation-tool/oct2010.pdf  
51. Federal Risk and Authorization Management Program (FedRAMP) Home Page.
    https://www.fedramp.gov/
52. FedRAMP Control Specific Contract Clauses v2, June 6, 2014.
    http://www.fedramp.gov/resources/documents
53. Defense Information Systems Agency, the Security Technical Implementation Guide (STIG) Home Page. 
     http://iase.disa.mil/stigs/Pages/index.aspx
54. Defense Information Systems Agency, DoD Cloud Services Support website.
    http://disa.mil/Services/DoD-Cloud-Broker  
55. Guide to Understanding FedRAMP.
    https://www.fedramp.gov/resources/documents/
56. FedRAMP Continuous Monitoring Strategy Guide.
    https://www.fedramp.gov/resources/documents/
57. FedRAMP Control Specific Contract Clauses v2, June 6, 2014. 
    https://www.fedramp.gov/resources/documents/
58. OPM Position Designation System document, Oct 2010. 
    http://www.opm.gov/investigations/background-investigations/position-designation-tool/oct2010.pdf
59. OPM Position Designation Tool. 
    http://www.opm.gov/investigations/background-investigations/position-designation-tool/