Cloud Computing

Concerns of the U.S. Government

Compiled and Edited by

Michael Erbschloe
Connect with Michael on LinkedIn

©2018 Michael Erbschloe

 Table of Contents
Page
Section
Number
About the Editor 2
Introduction 4
Guidance on HIPAA & Cloud Computing 7
Cloud Computing at the Veterans Administration 20
Cloud Computing Concerns at GSA 26
NIST Security and Privacy in Public Cloud Computing 44
DoD Guidance on Commercial Cloud Services 46
Cloud Computing Studies by the GAO 52
Department Of Defense (Dod) Cloud Computing Security
55
Requirements Guide (SRG)

54
About the Editor

Michael Erbschloe has worked for over 30 years performing analysis of the
economics of information technology, public policy relating to technology, and
utilizing technology in reengineering organization processes. He has authored
several books on social and management issues of information technology that
were published by McGraw Hill and other major publishers. He has also taught at
several universities and developed technology-related curriculum. His career has
focused on several interrelated areas:

• Technology strategy, analysis, and forecasting

• Teaching and curriculum development
• Writing books and articles
• Publishing and editing
• Public policy analysis and program evaluation

Books by Michael Erbschloe

Threat Level Red: Cybersecurity Research Programs of the

U.S. Government (CRC Press)
Social Media Warfare: Equal Weapons for All (Auerbach Publications)
Walling Out the Insiders: Controlling Access to Improve Organizational
Security (Auerbach Publications)
Physical Security for IT (Elsevier Science)
Trojans, Worms, and Spyware (Butterworth-Heinemann)
Implementing Homeland Security in Enterprise IT (Digital Press)
Guide to Disaster Recovery (Course Technology)
Socially Responsible IT Management (Digital Press)
Information Warfare: How to Survive Cyber Attacks (McGraw Hill)
The Executive's Guide to Privacy Management (McGraw Hill)
Net Privacy: A Guide to Developing & Implementing an e-business
Privacy Plan (McGraw Hill)
Introduction

Cloud computing is a model for enabling convenient, on-demand network access to a shared
pool of configurable computing resources (e.g., networks, servers, storage, applications, and
services) that can be rapidly provisioned and released with minimal management effort or
service provider interaction. The Cloud Computing model offers the promise of massive cost
savings combined with increased IT agility. It is considered critical that government and industry
begin adoption of this technology in response to difficult economic constraints. However, cloud
computing technology challenges many traditional approaches to datacenter and enterprise
application design and management. Cloud computing is currently being used; however,
security, interoperability, and portability are cited as major barriers to broader adoption.

The National Institute of Standards and Technology (NIST) has defined cloud computing as a
model for enabling ubiquitous, convenient, on-demand network access to a shared pool of
configurable computing resources (e.g., networks, servers, storage, applications, and services)
that can be rapidly provisioned and released with minimal management effort or service provider
interaction. This cloud model is composed of five essential characteristics, three service models,
and four deployment models.

Essential Characteristics:

On-demand self-service. A consumer can unilaterally provision computing capabilities, such as

server time and network storage, as needed automatically without requiring human interaction
with each service provider.

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

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

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

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

Service Models:

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

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

Infrastructure as a Service (IaaS). The capability provided to the consumer is to provision

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

Deployment Models:

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

Public cloud. The cloud infrastructure is provisioned for open use by the general public. It may
be owned, managed, and operated by a business, academic, or government organization, or some
combination of them. It exists on the premises of the cloud provider.

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

Source: https://csrc.nist.gov/publications/detail/sp/800-145/final#pubs-abstract-header
Guidance on HIPAA & Cloud Computing
With the proliferation and widespread adoption of cloud computing solutions, HIPAA covered
entities and business associates are questioning whether and how they can take advantage of
cloud computing while complying with regulations protecting the privacy and security of
electronic protected health information (ePHI). This guidance assists such entities, including
cloud services providers (CSPs), in understanding their HIPAA obligations.

Cloud computing takes many forms. This guidance focuses on cloud resources offered by a CSP
that is an entity legally separate from the covered entity or business associate considering the use
of its services. CSPs generally offer online access to shared computing resources with varying
levels of functionality depending on the users’ requirements, ranging from mere data storage to
complete software solutions (e.g., an electronic medical record system), platforms to simplify the
ability of application developers to create new products, and entire computing infrastructure for
software programmers to deploy and test programs. Common cloud services are on-demand
internet access to computing (e.g., networks, servers, storage, applications) services. We
encourage covered entities and business associates seeking information about types of cloud
computing services and technical arrangement options to consult a resource offered by the
National Institute of Standards and Technology; SP 800-145, The NIST Definition of Cloud
Computing - PDF.[1]

The HIPAA Privacy, Security, and Breach Notification Rules (the HIPAA Rules) establish
important protections for individually identifiable health information (called protected health
information or PHI when created, received, maintained, or transmitted by a HIPAA covered
entity or business associate), including limitations on uses and disclosures of such information,
safeguards against inappropriate uses and disclosures, and individuals’ rights with respect to
their health information. Covered entities and business associates must comply with the
applicable provisions of the HIPAA Rules. A covered entity is a health plan, a health care
clearinghouse, or a health care provider who conducts certain billing and payment related
transactions electronically. A business associate is an entity or person, other than a member of
the workforce of a covered entity, that performs functions or activities on behalf of, or provides
certain services to, a covered entity that involve creating, receiving, maintaining, or transmitting
PHI. A business associate also is any subcontractor that creates, receives, maintains, or transmits
PHI on behalf of another business associate.

When a covered entity engages the services of a CSP to create, receive, maintain, or transmit
ePHI (such as to process and/or store ePHI), on its behalf, the CSP is a business associate under
HIPAA. Further, when a business associate subcontracts with a CSP to create, receive, maintain,
or transmit ePHI on its behalf, the CSP subcontractor itself is a business associate. This is true
even if the CSP processes or stores only encrypted ePHI and lacks an encryption key for the data.
Lacking an encryption key does not exempt a CSP from business associate status and obligations
under the HIPAA Rules. As a result, the covered entity (or business associate) and the CSP
must enter into a HIPAA-compliant business associate agreement (BAA), and the CSP is both
contractually liable for meeting the terms of the BAA and directly liable for compliance with the
applicable requirements of the HIPAA Rules.

This guidance presents key questions and answers to assist HIPAA regulated CSPs and their
customers in understanding their responsibilities under the HIPAA Rules when they create,
receive, maintain or transmit ePHI using cloud products and services.

Questions

1. May a HIPAA covered entity or business associate use a cloud service to store or process
ePHI?

Yes, provided the covered entity or business associate enters into a HIPAA-compliant business
associate contract or agreement (BAA) with the CSP that will be creating, receiving,
maintaining, or transmitting electronic protected health information (ePHI) on its behalf, and
otherwise complies with the HIPAA Rules. Among other things, the BAA establishes the
permitted and required uses and disclosures of ePHI by the business associate performing
activities or services for the covered entity or business associate, based on the relationship
between the parties and the activities or services being performed by the business associate. The
BAA also contractually requires the business associate to appropriately safeguard the ePHI,
including implementing the requirements of the Security Rule. OCR has created guidance on the
elements of BAAs[2]

A covered entity (or business associate) that engages a CSP should understand the cloud
computing environment or solution offered by a particular CSP so that the covered entity (or
business associate) can appropriately conduct its own risk analysis and establish risk
management policies, as well as enter into appropriate BAAs. See 45 CFR §§
164.308(a)(1)(ii)(A); 164.308(a)(1)(ii)(B); and 164.502. Both covered entities and business
associates must conduct risk analyses to identify and assess potential threats and vulnerabilities
to the confidentiality, integrity, and availability of all ePHI they create, receive, maintain, or
transmit. For example, while a covered entity or business associate may use cloud-based
services of any configuration (public, hybrid, private, etc.),[3] provided it enters into a BAA with
the CSP, the type of cloud configuration to be used may affect the risk analysis and risk
management plans of all parties and the resultant provisions of the BAA.

In addition, a Service Level Agreement (SLA)[4] is commonly used to address more specific
business expectations between the CSP and its customer, which also may be relevant to HIPAA
compliance. For example, SLAs can include provisions that address such HIPAA concerns as:

System availability and reliability;

Back-up and data recovery (e.g., as necessary to be able to respond to a ransomware attack or
other emergency situation);

Manner in which data will be returned to the customer after service use termination;

Security responsibility; and

Use, retention and disclosure limitations.[5]

If a covered entity or business associate enters into a SLA with a CSP, it should ensure that the
terms of the SLA are consistent with the BAA and the HIPAA Rules. For example, the covered
entity or business associate should ensure that the terms of the SLA and BAA with the CSP do
not prevent the entity from accessing its ePHI in violation of 45 CFR §§ 164.308(b)(3),
164.502(e)(2), and 164.504(e)(1).[6]

In addition to its contractual obligations, the CSP, as a business associate, has regulatory
obligations and is directly liable under the HIPAA Rules if it makes uses and disclosures of PHI
that are not authorized by its contract, required by law, or permitted by the Privacy Rule. A CSP,
as a business associate, also is directly liable if it fails to safeguard ePHI in accordance with the
Security Rule, or fails to notify the covered entity or business associate of the discovery of a
breach of unsecured PHI in compliance with the Breach Notification Rule.

For more information about the Security Rule, see OCR and ONC tools for small entities[7] and
OCR guidance on SR compliance.[8]
2. If a CSP stores only encrypted ePHI and does not have a decryption key, is it a HIPAA
business associate?

Yes, because the CSP receives and maintains (e.g., to process and/or store) electronic protected
health information (ePHI) for a covered entity or another business associate. Lacking an
encryption key for the encrypted data it receives and maintains does not exempt a CSP from
business associate status and associated obligations under the HIPAA Rules. An entity that
maintains ePHI on behalf of a covered entity (or another business associate) is a business
associate, even if the entity cannot actually view the ePHI.[9] Thus, a CSP that maintains
encrypted ePHI on behalf a covered entity (or another business associate) is a business associate,
even if it does not hold a decryption key [10] and therefore cannot view the information. For
convenience purposes this guidance uses the term no-viewservices to describe the situation in
which the CSP maintains encrypted ePHI on behalf of a covered entity (or another business
associate) without having access to the decryption key.

While encryption protects ePHI by significantly reducing the risk of the information being
viewed by unauthorized persons, such protections alone cannot adequately safeguard the
confidentiality, integrity, and availability of ePHI as required by the Security Rule. Encryption
does not maintain the integrity and availability of the ePHI, such as ensuring that the information
is not corrupted by malware, or ensuring through contingency planning that the data remains
available to authorized persons even during emergency or disaster situations. Further, encryption
does not address other safeguards that are also important to maintaining confidentiality, such as
administrative safeguards to analyze risks to the ePHI or physical safeguards for systems and
servers that may house the ePHI.

As a business associate, a CSP providing no-view services is not exempt from any otherwise
applicable requirements of the HIPAA Rules. However, the requirements of the Rules are
flexible and scalable to take into account the no-view nature of the services provided by the CSP.

Security Rule Considerations

All CSPs that are business associates must comply with the applicable standards and
implementation specifications of the Security Rule with respect to ePHI. However, in cases
where a CSP is providing only no-view services to a covered entity (or business associate)
customer, certain Security Rule requirements that apply to the ePHI maintained by the CSP may
be satisfied for both parties through the actions of one of the parties. In particular, where only
the customer controls who is able to view the ePHI maintained by the CSP, certain access
controls, such as authentication or unique user identification, may be the responsibility of the
customer, while others, such as encryption, may be the responsibility of the CSP business
associate. Which access controls are to be implemented by the customer and which are to be
implemented by the CSP may depend on the respective security risk management plans of the
parties as well as the terms of the BAA. For example, if a customer implements its own
reasonable and appropriate user authentication controls and agrees that the CSP providing no-
view services need not implement additional procedures to authenticate (verify the identity of) a
person or entity seeking access to ePHI, these Security Rule access control responsibilities would
be met for both parties by the action of the customer.

However, as a business associate, the CSP is still responsible under the Security Rule for
implementing other reasonable and appropriate controls to limit access to information systems
that maintain customer ePHI. For example, even when the parties have agreed that the customer
is responsible for authenticating access to ePHI, the CSP may still be required to implement
appropriate internal controls to assure only authorized access to the administrative tools that
manage the resources (e.g., storage, memory, network interfaces, CPUs) critical to the operation
of its information systems. For example, a CSP that is a business associate needs to consider and
address, as part of its risk analysis and risk management process, the risks of a malicious actor
having unauthorized access to its system’s administrative tools, which could impact system
operations and impact the confidentiality, integrity and availability of the customer’s ePHI.
CSPs should also consider the risks of using unpatched or obsolete administrative tools. The
CSP and the customer should each confirm in writing, in either the BAA or other documents,
how each party will address the Security Rule requirements.

Note that where the contractual agreements between a CSP and customer provide that the
customer will control and implement certain security features of the cloud service consistent with
the Security Rule, and the customer fails to do so, OCR will consider this factor as important and
relevant during any investigation into compliance of either the customer or the CSP. A CSP is
not responsible for the compliance failures that are attributable solely to the actions or inactions
of the customer, as determined by the facts and circumstances of the particular case.

Privacy Rule Considerations

A business associate may only use and disclose PHI as permitted by its BAA and the Privacy
Rule, or as otherwise required by law. While a CSP that provides only no-view services to a
covered entity or business associate customer may not control who views the ePHI, the CSP still
must ensure that it itself only uses and discloses the encrypted information as permitted by its
BAA and the Privacy Rule, or as otherwise required by law. This includes, for example,
ensuring the CSP does not impermissibly use the ePHI by blocking or terminating access by the
customer to the ePHI.[11]

Further, a BAA must include provisions that require the business associate to, among other
things, make available PHI as necessary for the covered entity to meet its obligations to provide
individuals with their rights to access, amend, and receive an accounting of certain disclosures of
PHI in compliance with 45 CFR § 164.504(e)(2)(ii)(E)-(G). The BAA between a no-view CSP
and a covered entity or business associate customer should describe in what manner the no-view
CSP will meet these obligations – for example, a CSP may agree in the BAA that it will make
the ePHI available to the customer for the purpose of incorporating amendments to ePHI
requested by the individual, but only the customer will make those amendments.

Breach Notification Rule Considerations

As a business associate, a CSP that offers only no-view services to a covered entity or business
associate still must comply with the HIPAA breach notification requirements that apply to
business associates. In particular, a business associate is responsible for notifying the covered
entity (or the business associate with which it has contracted) of breaches of unsecured PHI. See
45 CFR § 164.410. Unsecured PHI is PHI that has not been destroyed or is not encrypted at the
levels specified in HHS’ Guidance to Render Unsecured Protected Health Information Unusable,
Unreadable, or Indecipherable to Unauthorized Individuals [12] If the ePHI that has been
breached is encrypted consistent with the HIPAA standards set forth in 45 CFR § 164.402(2) and
HHS’ Guidance [13] the incident falls within the breach “safe harbor” and the CSP business
associate is not required to report the incident to its customer. However, if the ePHI is
encrypted, but not at a level that meets the HIPAA standards or the decryption key was also
breached, then the incident must be reported to its customer as a breach, unless one of the
exceptions to the definition of “breach” applies. See 45 CFR § 164.402. See also 45 CFR §
164.410 for more information about breach notification obligations for business associates.

3. Can a CSP be considered to be a “conduit” like the postal service, and, therefore, not a
business associate that must comply with the HIPAA Rules?&

Generally, no. CSPs that provide cloud services to a covered entity or business associate that
involve creating, receiving, or maintaining (e.g., to process and/or store) electronic protected
health information (ePHI) meet the definition of a business associate, even if the CSP cannot
view the ePHI because it is encrypted and the CSP does not have the decryption key.

As explained in previous guidance,[14] the conduit exception is limited to transmission-only

services for PHI (whether in electronic or paper form), including any temporary storage of PHI
incident to such transmission. Any access to PHI by a conduit is only transient in nature. In
contrast, a CSP that maintains ePHI for the purpose of storing it will qualify as a business
associate, and not a conduit, even if the CSP does not actually view the information, because the
entity has more persistent access to the ePHI.

Further, where a CSP provides transmission services for a covered entity or business associate
customer, in addition to maintaining ePHI for purposes of processing and/or storing the
information, the CSP is still a business associate with respect to such transmission of ePHI. The
conduit exception applies where the only services provided to a covered entity or business
associate customer are for transmission of ePHI that do not involve any storage of the
information other than on a temporary basis incident to the transmission service.

4. Which CSPs offer HIPAA-compliant cloud services?

OCR does not endorse, certify, or recommend specific technology or products.

5. What if a HIPAA covered entity (or business associate) uses a CSP to maintain ePHI without
first executing a business associate agreement with that CSP?

If a covered entity (or business associate) uses a CSP to maintain (e.g., to process or store)
electronic protected health information (ePHI) without entering into a BAA with the CSP, the
covered entity (or business associate) is in violation of the HIPAA Rules. 45 C.F.R
§§164.308(b)(1) and §164.502(e). OCR has entered into a resolution agreement and corrective
action plan with a covered entity that OCR determined stored ePHI of over 3,000 individuals on
a cloud-based server without entering into a BAA with the CSP.[15]

Further, a CSP that meets the definition of a business associate – that is a CSP that creates,
receives, maintains, or transmits PHI on behalf of a covered entity or another business associate
– must comply with all applicable provisions of the HIPAA Rules, regardless of whether it has
executed a BAA with the entity using its services. See 78 Fed. Reg. 5565, 5598 (January 25,
2013). OCR recognizes that there may, however, be circumstances where a CSP may not have
actual or constructive knowledge that a covered entity or another business associate is using its
services to create, receive, maintain, or transmit ePHI. The HIPAA Rules provide an
affirmative defense in cases where a CSP takes action to correct any non-compliance within 30
days (or such additional period as OCR may determine appropriate based on the nature and
extent of the non-compliance) of the time that it knew or should have known of the violation
(e.g., at the point the CSP knows or should have known that a covered entity or business
associate customer is maintaining ePHI in its cloud). 45 CFR 160.410. This affirmative defense
does not, however, apply in cases where the CSP was not aware of the violation due to its own
willful neglect.

If a CSP becomes aware that it is maintaining ePHI, it must come into compliance with the
HIPAA Rules, or securely return the ePHI to the customer or, if agreed to by the customer,
securely destroy the ePHI. Once the CSP securely returns or destroys the ePHI (subject to
arrangement with the customer), it is no longer a business associate. We recommend CSPs
document these actions.

While a CSP maintains ePHI, the HIPAA Rules prohibit the CSP from using or disclosing the
data in a manner that is inconsistent with the Rules.

6. If a CSP experiences a security incident involving a HIPAA covered entity’s or business

associate’s ePHI, must it report the incident to the covered entity or business associate?

Yes. The Security Rule at 45 CFR § 164.308(a)(6)(ii) requires business associates to identify
and respond to suspected or known security incidents; mitigate, to the extent practicable, harmful
effects of security incidents that are known to the business associate; and document security
incidents and their outcomes. In addition, the Security Rule at 45 CFR § 164.314(a)(2)(i)(C)
provides that a business associate agreement must require the business associate to report, to the
covered entity or business associate whose electronic protected health information (ePHI) it
maintains, any security incidents of which it becomes aware. A security incident under 45 CFR
§ 164.304 means the attempted or successful unauthorized access, use, disclosure, modification,
or destruction of information or interference with system operations in an information system.
Thus, a business associate CSP must implement policies and procedures to address and
document security incidents, and must report security incidents to its covered entity or business
associate customer.
The Security Rule, however, is flexible and does not prescribe the level of detail, frequency, or
format of reports of security incidents, which may be worked out between the parties to the
business associate agreement (BAA). For example, the BAA may prescribe differing levels of
detail, frequency, and formatting of reports based on the nature of the security incidents – e.g.,
based on the level of threat or exploitation of vulnerabilities, and the risk to the ePHI they pose.
The BAA could also specify appropriate responses to certain incidents and whether identifying
patterns of attempted security incidents is reasonable and appropriate.

Note, though, that the Breach Notification Rule specifies the content, timing, and other
requirements for a business associate to report incidents that rise to the level of a breach of
unsecured PHI to the covered entity (or business associate) on whose behalf the business
associate is maintaining the PHI. See 45 CFR § 164.410. The BAA may specify more stringent
(e.g., more timely) requirements for reporting than those required by the Breach Notification
Rule (so long as they still also meet the Rule’s requirements) but may not otherwise override the
Rule’s requirements for notification of breaches of unsecured PHI.

For more information on this topic, see the FAQ about reporting security incidents (although
directed to plan sponsors and group health plans, the guidance is also relevant to business
associates); [16] as well as OCR breach notification guidance [17]

7. Do the HIPAA Rules allow health care providers to use mobile devices to access ePHI in a
cloud?

Yes. Health care providers, other covered entities, and business associates may use mobile
devices to access electronic protected health information (ePHI) in a cloud as long as appropriate
physical, administrative, and technical safeguards are in place to protect the confidentiality,
integrity, and availability of the ePHI on the mobile device and in the cloud, and appropriate
BAAs are in place with any third party service providers for the device and/or the cloud that will
have access to the e-PHI. The HIPAA Rules do not endorse or require specific types of
technology, but rather establish the standards for how covered entities and business associates
may use or disclose ePHI through certain technology while protecting the security of the ePHI by
requiring analysis of the risks to the ePHI posed by such technology and implementation of
reasonable and appropriate administrative, technical, and physical safeguards to address such
risks. OCR and ONC have issued guidance on the use of mobile devices and tips for securing
ePHI on mobile devices. [18]
8. Do the HIPAA Rules require a CSP to maintain ePHI for some period of time beyond when it
has finished providing services to a covered entity or business associate?

No, the HIPAA Rules generally do not require a business associate to maintain electronic
protected health information (ePHI) beyond the time it provides services to a covered entity or
business associate. The Privacy Rule provides that a business associate agreement (BAA) must
require a business associate to return or destroy all PHI at the termination of the BAA where
feasible. 45 CFR § 164.504(e)(2)(J).

If such return or destruction is not feasible, the BAA must extend the privacy and security
protections of the BAA to the ePHI and limit further uses and disclosures to those purposes that
make the return or destruction of the information infeasible. For example, return or destruction
would be considered ‘‘infeasible’’ if other law requires the business associate CSP to retain ePHI
for a period of time beyond the termination of the business associate contract.[19]

9. Do the HIPAA Rules allow a covered entity or business associate to use a CSP that stores
ePHI on servers outside of the United States?

Yes, provided the covered entity (or business associate) enters into a business associate
agreement (BAA) with the CSP and otherwise complies with the applicable requirements of the
HIPAA Rules. However, while the HIPAA Rules do not include requirements specific to
protection of electronic protected health information (ePHI) processed or stored by a CSP or any
other business associate outside of the United States, OCR notes that the risks to such ePHI may
vary greatly depending on its geographic location. In particular, outsourcing storage or other
services for ePHI overseas may increase the risks and vulnerabilities to the information or
present special considerations with respect to enforceability of privacy and security protections
over the data. Covered entities (and business associates, including the CSP) should take these
risks into account when conducting the risk analysis and risk management required by the
Security Rule. See 45 CFR §§ 164.308(a)(1)(ii)(A) and (a)(1)(ii)(B). For example, if ePHI is
maintained in a country where there are documented increased attempts at hacking or other
malware attacks, such risks should be considered, and entities must implement reasonable and
appropriate technical safeguards to address such threats.

10. Do the HIPAA Rules require CSPs that are business associates to provide documentation, or
allow auditing, of their security practices by their customers who are covered entities or business
associates?
No. The HIPAA Rules require covered entity and business associate customers to obtain
satisfactory assurances in the form of a business associate agreement (BAA) with the CSP that
the CSP will, among other things, appropriately safeguard the protected health information (PHI)
that it creates, receives, maintains or transmits for the covered entity or business associate in
accordance with the HIPAA Rules. The CSP is also directly liable for failing to safeguard
electronic PHI in accordance with the Security Rule [20] and for impermissible uses or
disclosures of the PHI. [21]. The HIPAA Rules do not expressly require that a CSP provide
documentation of its security practices to or otherwise allow a customer to audit its security
practices. However, customers may require from a CSP (through the BAA, service level
agreement, or other documentation) additional assurances of protections for the PHI, such as
documentation of safeguards or audits, based on their own risk analysis and risk management or
other compliance activities.

11. If a CSP receives and maintains only information that has been de-identified in accordance
with the HIPAA Privacy Rule, is it is a business associate?

No. A CSP is not a business associate if it receives and maintains (e.g., to process and/or store)
only information de-identified following the processes required by the Privacy Rule. The
Privacy Rule does not restrict the use or disclosure of de-identified information, nor does the
Security Rule require that safeguards be applied to de-identified information, as the information
is not considered protected health information. See the OCR guidance on de-identification for
more information.[22]

[1] See http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf

[2] See http://www.hhs.gov/hipaa/for-professionals/covered-entities/sample-business-associate-

agreement-provisions/index.html.

[3] As adapted from NIST Special Publication 800-144, vi:

A Public cloud is open for use by the general public and may be owned, managed, and operated
by any organization. Examples are the message storage services offered by major email
providers, photo-sharing sites, and certain EMR providers. Many large organizations use Private
clouds that exclusively serve their business functions. A Community cloud serves exclusively a
specific community of users from organizations that have shared concerns. A Hybrid cloud is a
combination of any of the above, bound together by standardized or proprietary technology that
enables data and application portability.
[4] See NIST SP 800-144, Guidelines on Security and Privacy in Public Cloud Computing
(December 2011). Available at http://www.nist.gov/manuscript-publication-
search.cfm?pub_id=909494

[5] For more information see NIST SP 800-146, Cloud Computing Synopsis and
Recommendations (May 2012). Available at http://www.nist.gov/manuscript-publication-
search.cfm?pub_id=911075

[6] See OCR FAQ http://www.hhs.gov/hipaa/for-professionals/faq/2074/may-a-business-

associate-of-a-hipaa-covered-entity-block-or-terminate-access/index.html

[7] See http://www.healthit.gov/providers-professionals/ehr-privacy-security.

[8] See
http://www.hhs.gov/ocr/privacy/hipaa/administrative/securityrule/securityruleguidance.html.

[9] 78 Fed. Reg. 5,566, 5,572 (January 25, 2013).

[10] A key used to encrypt and decrypt data, also called a cryptographic key, is “[a] parameter
used in conjunction with a cryptographic algorithm that determines its operation in such a way
that an entity with knowledge of the key can reproduce or reverse the operation, while an entity
without knowledge of the key cannot.” See NIST SP 800-47 Part 1 Revision 4,
Recommendation for Key Management Part 1: General (January 2016). Available at
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf - PDF

[11] See OCR FAQ regarding impermissible blocking of covered entity access to ePHI by a
business associate http://www.hhs.gov/hipaa/for-professionals/faq/2074/may-a-business-
associate-of-a-hipaa-covered-entity-block-or-terminate-access/index.html.

[12] See OCR guidance regarding unsecured PHI that is subject to the Breach Notification Rule
requirements http://www.hhs.gov/hipaa/for-professionals/breach-
notification/guidance/index.html.

[13] Ibid.

[14] See 78 Fed. Reg. 5,566, 5,572 (January 25, 2013). Also see http://www.hhs.gov/hipaa/for-
professionals/faq/245/are-entities-business-associates/

[15] See http://www.hhs.gov/about/news/2016/07/18/widespread-hipaa-vulnerabilities-result-in-

settlement-with-oregon-health-science-university.html.

[16]See http://www.hhs.gov/hipaa/for-professionals/faq/2016/under-the-security-rule-must-plan-
sponsors-report-security-incidents-to-the-group-plan/.
[17] See http://www.hhs.gov/ocr/privacy/hipaa/understanding/coveredentities/contractprov.html;
http://www.hhs.gov/hipaa/for-professionals/breach-notification/index.html.

[18] See http://www.healthit.gov/providers-professionals/how-can-you-protect-and-secure-

health-information-when-using-mobile-device.

[19] 67 Fed. Reg. 53181, 53254 (August 14, 2002).

[20] See Section 13401 of the HITECH Act.

[21] See 45 CFR § 164.502(a)(3).

[22] See http://www.hhs.gov/hipaa/for-professionals/privacy/special-topics/de-identification/.

Source: https://www.hhs.gov/hipaa/for-professionals/special-topics/cloud-computing/index.html
Cloud Computing at the Veterans Administration
Cloud computing enables the sharing, storage, and accessibility of data via the Internet, rather
than through individual, limited-access hard drives. It is an evolution toward the “renting” of
integrated services as needed without the high risk and capital costs of development and
infrastructure.

Scope

The adoption of cloud computing offers many benefits to Veterans, their families and
dependents, VA personnel, and VA partners. Using cloud, Veterans and their families will have
access to VA services on any device, anywhere, and at any time. They will experience improved
mission services and capabilities, and will be able to access information seamlessly, globally,
securely, cost effectively, and reliably.

VA has been pursuing various IT infrastructure evolution initiatives for some time. The adoption
of utility cloud computing models has numerous advantages. Fundamentally, the capability
supports rapid delivery of VA business capabilities. Thus, it provides agile, scalable, and reliable
infrastructure needed to keep pace with an explosive growth of information and the increased
variety and uses of VA’s strategic information assets.

VA’s efforts to this end align with the Office of Management and Budget (OMB)’s 25 Point
Implementation Plan to Reform Federal Information Technology Management. (December 9,
2010) and the priority of the current VA Chief Information Officer (CIO) to adopt cloud
computing to better support VA’s mission to serve Veterans and their families.

By definition, cloud computing is “a model for enabling ubiquitous, convenient, on-demand

network access to a shared pool of configurable computing resources (e.g., networks, servers,
storage, applications, and services) that can be rapidly provisioned and released with minimal
management effort or service provider interaction.” (NIST SP 800-145)

Usage

VA has several cloud initiatives already in use that correspond to the Service Models identified
above:
 Infrastructure as a Service (IaaS) capabilities are available after implementing the Adaptive
Cloud Environment (ACE). IaaS includes support for on-demand, self-service provisioning,
broad network access, resource pooling, rapid elasticity, and measured service.

After expanding the internal Platform as a Service (PaaS) offerings, VA continues to

investigate the viability of using external Software as a Service (SaaS) providers to deliver Email
as a Service.

Additionally, externally hosted providers and cloud implementers (e.g. Terremark, Century
Link) were adopted to host some of VA’s mission critical VA IT systems such as Veterans
Benefits Management System (VBMS), My HealtheVet, and Customer Relationship
Management Unified Desktop (CRM-UD).

Future Enhancements & Strategy

VA has developed an implementable enterprise cloud strategy to realize the greatest benefits of
cloud computing across VA and to prevent the potential risk of diverging approaches or
overlapping efforts.

The strategy is consistent with the CIO’s vision and aligned with VA policies. The purpose of
the strategy is to deliver more responsive IT services at lower cost to the Department and to
promote adoption of the following concepts:

“Cloud first” Policy. Systems are to use cloud computing unless specific criteria are met that
demonstrate the solution is not yet cloud ready.

VA Cloud Broker and Central Cloud Consumer. An Enterprise Cloud Services Broker (ECSB)
solution has been established to support business and technical governance and overall migration
to cloud service. The ECSB also provides a gateway to centralized intermediation, aggregation,
and arbitrage of cloud services.

Cloud Service Contract Vehicles. A contract vehicle will be established to acquire cloud
services on a consumption-based model that supports elasticity and incrementally funded
contracts.

Public/Community/Private Cloud Criteria. The use of FedRAMP-approved public and

community cloud solutions will be allowed for systems that are classified up to Federal
Information Security Modernization Act of 2014 (FISMA) Moderate and promote use of VA
private cloud solutions for FISMA High systems.

Cloud Pilots. Pilots will be conducted to support iterative implementation of the Cloud
Strategy, quantify benefits using key performance indicators, and reduce potential risks. Needed
changes in procedures, programs, and technical standards to accelerate cloud services migration
will be instituted through a lessons-learned process.

Cloud Computing Enterprise Design Patterns. Guiding principles, best practice approaches,
and constraints will be established for acquiring cloud services and incorporating them as
reusable enterprise capabilities.

Enterprise Design Patterns

Enterprise Design Patterns (EDPs) are developed by the Office of Technology Strategies (TS) in
coordination with internal and external subject matter experts (SME) and stakeholders.
Enterprise Design Patterns are incorporated into the Design, Engineering, & Architecture
(DE&A) Compliance and provide reusable, enterprise-level capabilities guidance. They provide
a standardized framework of capabilities and constraining principles to aid all integrated project
teams (IPT) in the development, acquisition, and/or implementation of IT systems and services.
Each signed Enterprise Design Pattern is listed below by topic area.

VA Directive 6551

On March 17, 2016, the CIO and Deputy CIO for Architecture Strategy and Design signed VA
Directive 6551 regarding VA Enterprise Design Patterns. This directive establishes a mandatory
policy for establishing and utilizing Enterprise Design Patterns by all Department of Veterans
Affairs (VA) projects developing information technology (IT) systems in accordance with the
VA’s Office of Information and Technology (OI&T) integrated development and release
management process, the Veteran-focused Integration Process (VIP).

Enterprise Design
Title Description Patterns/Executive
Summary

Privacy and Security Enterprise Design Patterns

This Enterprise Design Pattern describes the “to-be” state

for VA internal (PIV-enabled VA employees, contractors, and
User Identity volunteers) and external (business partners, veterans and
Authentication others who access VA resources from outside the VA
network) user identity authentication. In addition to
describing the “static” rules for authentication, this
document describes “adaptive” authentication tools that
 will be implemented and the need for authentication
protocols.

This Enterprise Design Pattern implements the standards

and protocols required for message-level security and
expounds on the message-level security standards needed
Enterprise Secure to integrate the enterprise IT infrastructure and Enterprise
Messaging Shared Services (ESS). It outlines the capabilities and
standards achievable through the use of enterprise
middleware solutions such as Enterprise Messaging
Infrastructure (eMI) and XML/API Gateways.

This Enterprise Design Pattern provides enterprise-level

Mobile Veteran
capability guidance that identifies security best practices for
Facing
Veteran-facing mobile applications accessing VA IT
Applications
resources. It will guide projects to implementation resources
Security
that will support detailed design specifications.

This Enterprise Design Pattern describes the "to-be" state

for VA NPE security. It describes "adaptive" authentication
tools that need to be implemented and the need for
Non-Person Entity authentication protocols that can support attribute- and
Security risk-based access controls. This document will assist the VA
in establishing policy and methodology related to 'user
identity' propagation across all architectural tiers of system
design.

This Enterprise Design Pattern establishes the official

enterprise guideline for enterprise-wide auditing across all
Enterprise lines of business in accordance with Federal Information
Auditing Security Management Act (FISMA), National Institute of
Standards and Technology (NIST) 800-53 and VA 6500
security policies (see Appendix D).

This Enterprise Design Pattern identifies a centralized

method for ensuring a consistent authorization process
Enterprise across all VA applications; identifies best practices for
Authorization migrating to new authorization processes; and provides
guidance on preparations required by application owners to
integrate with the authorization service.

Cloud Security This Enterprise Design Pattern provides a vendor-agnostic

 approach to cloud security by reviewing the highest risk
areas first. It discusses how comprehensive monitoring
through the TIC Gateways, managed encryption of sensitive
data, auditing of activity in the cloud, and proper
architecture design can reduce the risk of inadequate
controls or incidents within a fully compliant boundary. This
Design Pattern can be used to guide decisions around
compliance and critical controls as they begin the process of
cloud adoption.

This Enterprise Design Pattern defines an enterprise medical

device security model that addresses all phases of the
medical device lifecycle beginning with the assessment of
Medical Device
medical devices procured to the disposal of the device. This
Security
model will help stakeholders meet VA security requirements
for medical devices and avoid integrity and availability issues
due to compromise.

Technology (Tech) Insights

The monthly Technology (Tech) Insights series aims to help readers make better decisions and
be more informed customers by providing them with high-level overviews of technology issues
that impact or will impact VA’s IT environment. These Tech Insights introduce topics in an
easily digestible fashion by presenting background information on the topic, clearly explaining
its importance within VA, and providing recommendations for success.

Design Thinking (May 2017) Design thinking is the formal process of creating new, innovative
ideas and solving problems. This Tech Insight provides an introduction to design followed by a
history and overview of design thinking and Human-Centered Design (HCD) and explores how
these concepts are being applied within VA. It also includes a supplemental toolkit overview
from the VA Center for Innovation’s (VACI) “Toolkit for Human-Centered Design.”

Enterprise Design Patterns (April 2017) An Enterprise Design Pattern (EDP) is a reusable
capability guidance document that identifies best practice approaches and resources for
achieving VA IT strategic objectives. This Tech Insight provides a basic explanation of the
purpose of EDPs and the IT topics they address. It also provides a deeper understanding of the
importance of EDPs as key components of the VA Enterprise Architecture (EA), and how VA
project teams can benefit from using them.
Technology in Healthcare Recap (March 2017) VA Telehealth Services uses health
informatics, disease management, care/case management, and telehealth technologies to increase
access to care and improve the health of Veterans. This Tech Insight Recap revisits three
previous Tech Insights and combines their highlights to specifically address telehealth,
nanomedicine, and three dimensional (3D) printing. It examines how technological updates and
innovations are beneficial to healthcare.

Anatomy of a Computer (March 2017) The computer is the pinnacle device for the
evolution of modern products, like Internet of Things (IoT) and small devices. This Tech Insight
introduces the basic parts of a computer and describes the more recent applications of the basic
parts to small devices, IoT, and applications in healthcare. It also focuses on how VA is
managing security risks associated with computers.

Big Data Analytics II (February 2017) Big data as a concept refers to the high velocity
collection of data in large volumes coming from a variety of sources, resulting in different forms
of data collected with great speed in great frequency. In this second Tech Insight on the topic, we
present the key steps and tools commonly used in this form of analytics and address the
Department of Veterans Affairs’ (VA) actions toward improving and leveraging big data
analytics capabilities.

Hackathons (January 2017) Hackathons use brainstorming and coding sessions to stir up new
ideas on a topic by creative problem solving. This Tech Insight explores how hackathons work,
offers guidelines for organizing a hackathon, and presents examples of how Federal agencies are
employing hackathons to drive innovation.

Source: https://www.ea.oit.va.gov/EAOIT/VA_EA/Cloud_Computing.asp
Cloud Computing Concerns at GSA

STATEMENT OF DR. DAVID MCCLURE ASSOCIATE ADMINISTRATOR OFFICE OF

CITIZEN SERVICES AND INNOVATIVE TECHNOLOGIES GENERAL SERVICES
ADMINISTRATION BEFORE THE HOUSE COMMITTEE ON OVERSIGHT AND
GOVERNMENT REFORM SUBCOMMITTEE ON GOVERNMENT MANAGEMENT,
ORGANIZATION, AND PROCUREMENT JULY 1, 2010

Chairman Towns, Chairwoman Watson, and Members of the Committee, I am David McClure,
Deputy Administrator, Office of Citizen Services and Innovative Technologies at the General
Services Administration (GSA). Thank you for the opportunity to appear before you today to
discuss GSA’s role in supporting development and deployment of cloud computing technology.

Cloud computing enables convenient, rapid, and on-demand computer network access—most
often via the Internet--to a shared pool of configurable computing resources (in the form of
servers, networks, storage, applications, and services). Quite simply, it is the way computing
services are delivered that is revolutionary. Cloud computing allows users to provision
computing capabilities rapidly and as needed; that is, to scale out and scale back as required, and
to pay only for services used. Users can provision software and infrastructure cloud services on
demand with minimal, if any, human intervention. Because cloud computing is based on
resource pooling and broad network access there is a natural economy of scale that can result in
lower costs to agencies. In addition, cloud computing offers a varied menu of service models
from a private cloud operated solely for one organization to a public cloud that is available to a
large industry group and the general public and owned by an organization that is selling cloud
computing services.

At GSA, we think the adoption of safe and secure cloud computing by the Federal government
presents an opportunity to close the IT performance gap. Various forms of cloud computing
solutions are already being used in the federal government today to save money and improve
services. Let me illustrate with just a few examples:

The Department of the Army Experience Center in Philadelphia is piloting the use of a
customer relationship management (CRM) tool. The Center is a recruiting center that reaches out
to young people who are interested in joining our armed forces. The Center wants to move to real
time recruiting and to use tools and techniques that are familiar and appeal to its young
demographic. They are using a CRM provided by SalesForce to track recruits as they work with
the Center. Since the tool integrates directly with e-mail, Twitter and Facebook, recruiters can
maintain connections with potential candidates directly after they leave the Center. The Army
estimated that to implement a traditional CRM would have cost $500,000. The cloud-based
solution has been implemented at the cost of $54,000.

The Department of Energy is evaluating the cost and efficiencies resulting from leveraging
cloud computing solution across the enterprise to support business and scientific services. The
Lawrence Berkeley Lab has deployed over 5,000 mailboxes on Google Federal Premiere Apps
and they are now evaluating the use of Amazon Elastic Compute Cloud (EC2) to handle excess
capacity for computers during peak demand. The Lab estimates that they will save $1.5 million
over the next five year in hardware, software and labor costs from the deployments they have
made.

Finally, my own agency – GSA has moved the primary information portal, USA.gov, to a
cloud-based host. This enabled the site to deliver a consistent level of access to information as
new data bases are added, as peak usage periods are encountered, and as the site evolves to
encompass more services. By moving to a cloud, GSA was able to reduce site upgrade time from
nine months to one day; monthly downtime improved from two hours to 99.9% availability; and
GSA realized savings of $1.7M in hosting services.

In addition to improved services, GSA anticipates that cloud computing will be a major factor in
reducing the environmental impact of technology and help achieve important sustainability
goals. Effective use of cloud computing can be part of an overall strategy to reduce the need for
multiple data centers and the energy they consume. Currently, GSA is supporting OMB in
working with agencies to develop plans to consolidate their data centers. Using the right
deployment model – private cloud, community cloud, public cloud, or a hybrid model – can help
agencies buy improved services at a lower cost within acceptable risk levels, without having to
maintain expensive, separate, independent and often needlessly redundant brick and mortar data
centers.

In February 2010, the Federal CIO announced the Federal Data Center Consolidation Initiative.
In it, he designated two Federal agency CIOs -- Richard Spires (DHS) and Michael Duffy
(Treasury) – to lead the effort inside the Federal CIO Council. It also highlighted the following
goals:
• Reduce the cost of data center hardware, software and operations

• Increase the overall IT security posture of the government

• Shift IT investments to more efficient computing platforms and technologies

• Promote the use of Green IT by reducing the overall energy and real estate footprint of
government data centers

GSA has a significant leadership role in supporting the adoption of cloud computing in the
federal government. We have concentrated our efforts on facilitating easy access to cloud based
solutions from commercial providers that meet federal requirements, enhancing agencies’
capacity to analyze viable cloud computing options that meet their business and technology
modernization needs, and addressing obstacles to safe and secure cloud computing. In particular,
GSA facilitates innovative cloud computing procurement options, ensures effective cloud
security and standards are in place, and identifies potential multi-agency or government-wide
uses of cloud computing solutions. GSA is also the information “hub” for cloud use case
examples, decisional and implementation best practices, and sharing exposed risks and lessons
learned. We have set up the Info.Apps.Gov site as an evolving knowledge repository for all
government agencies to use and contribute their expertise.

Let me briefly highlight how GSA is specifically providing execution capabilities to empower
sensible cloud computing adoption in the federal government.

Federal Cloud Computing Project Management Office

In March of 2009, the Federal Chief Information Officer (CIO) Council identified cloud
computing as a priority for meeting the growing need for effective and efficient use of
information technology to meet the performance and mission needs of the government. To assist
in fostering cloud computing adoption, the Federal Cloud Computing Program Management
Office (PMO) was created in April of 2009 at GSA. The PMO resides in the Office of Citizen
Service and Innovation Technologies and is directed by Ms. Katie Lewin who directly reports to
the Deputy Administrator for Innovative Technology, Mr. Sonny Bhagowalia. The Director of
the PMO also meets weekly with the Federal CIO to report on progress, discuss risks and
mitigations, identify promising cloud projects across the government and refine direction. The
PMO also reports on its activities and results to the CIO Council Cloud Computing Executive
Steering Committee (ESC). The ESC provides oversight for the Federal Cloud Computing
Initiative and fosters communications among agencies on cloud computing. ESC Membership
includes senior IT executives from across the entire Federal government.

The PMO provides technical and administrative leadership to cloud computing initiatives. PMO
staff is drawn from GSA technical experts with some additional contractor support. The primary
focus of the PMO is on the following activities:

• Support for the design and operation of the Apps.Gov cloud computing storefront and related
cloud procurement initiatives

• Facilitating identification of key cloud security requirements (certification, accreditation, and

authorization), particularly on a government-wide basis through a new FedRAMP initiative

• Promotion of current and planned cloud projects across the government

• Data center consolidation analysis, planning, and strategy support

• Development and open dissemination of relevant cloud computing information.

To augment their skill base, the PMO has formed working groups to address specific areas
including security, standards and specific cloud-based solutions with government or multi-
agency use, such as cloud based e-mail services. The working groups are composed of staff from
across the government who bring expertise and interest to address specific obstacles or define
paths to adoption. Each group is chaired by a government expert. The National Institute of
Standards and Technology (NIST) led both the security and the standards groups. The e-mail
group is chaired by an expert from Department of the Interior.

Cloud Computing PMO Operations

Cloud Procurement

Cloud services are usually offered and purchased as commodities. This is a new way of buying
IT services and requires careful research on both government requirements and industry
capability to meet demand. To assist agencies in buying new commercially provided cloud
services, GSA established a website -- Apps.Gov -- modeled on other GSA product and service
acquisition “storefronts.” The purpose of Apps.Gov is to provide easy, simple ways to find,
research, and procure commercial cloud products and services. Agencies can search for software
as a service (SaaS) products categorized under 33 business purpose headings and get product
descriptions, price quotes, and links to more information on specific products. Usage patterns to
date indicate that agencies use this information to either directly buy SaaS products or,
alternatively, as a source of marketplace research that is used to support cloud procurements
using other vehicles such as GSA Schedule or GSA Advantage.

Apps.Gov also has information on no-cost social media applications that have agreed to
“government-friendly” Terms of Service. When a user hits the SEND REQUEST button, they
are linked to their agency’s social media coordinator to complete the request for use of the tool in
compliance with their agency’s social media policy.

To support access to cloud-based Infrastructure as a Service (IaaS), the Cloud PMO works with
the Federal Acquisition Service (FAS) at GSA. FAS has primary responsibility for operating on-
line acquisition services that are available for government-wide use. In May 2009, the PMO
issued a Request for Information (RFI) asking the marketplace how they would address cloud
computing business models, pricing, service level agreements, operational support, data
management, security and standards. The responses to this RFI were incorporated into a Request
for Quote (RFQ) for Infrastructure as a Service capabilities and pricing. The result will be a
multiple award blanket purchase agreement that agencies can use to procure cloud based web
hosting, virtual machine, and storage services within a moderate security environment as defined
by the Federal Information Security Act (FISMA). That RFQ closed yesterday and is currently in
an evaluation stage.

Cloud Computing Security

One of the most significant obstacles to the adoption of cloud computing is security. Agencies
are concerned about the risks of housing data off-site in a cloud if FISMA security controls and
accountabilities are not in place. In other words, agencies need to have valid certification and
accreditation (C&A) process and a signed Authority to Operate (ATO) in place for each cloud-
based product they use. While vendors are willing to meet security requirements, they would
prefer not to go through the expense and effort of obtaining a C&A and ATO for each use of that
product in all the federal departments and agencies. The PMO formed a security working group,
initially chaired by NIST to address this problem. The group developed a process and
corresponding security controls that were agreed to by multiple agencies – which we have
termed as the Federal Risk and Authorization Management Program (FedRAMP).

FedRAMP is a government-wide initiative to provide joint authorizations and continuous

security monitoring services for all federal agencies with an initial focus on cloud computing. By
providing a unified government-wide risk management for enterprise level IT systems,
FedRAMP will enable agencies to either use or leverage authorizations with:

• Vetted interagency approach;

• Consistent application of Federal security requirements;

• Improved community-wide risk management posture; and

• Increased effectiveness and management cost savings.

FedRAMP allows agencies to use or leverage authorizations. Under this program, agencies will
be able to rely upon review security details, leverage the existing authorization, and secure
agency usage of system. This should greatly reduce cost, enable rapid acquisition, and reduce
effort.

FedRAMP has three components:

1. Security Requirement Authorities which create government-wide baseline security

requirements that are interagency developed and approved. This will initially be the Federal
Cloud Computing Initiative and ultimately live with the ISIMC Working Group.

2. The FedRAMP Office which will coordinate authorization packages, manage authorized
system list, and provide continuous monitoring oversight. This will be managed by GSA.

3. A Joint Authorization Board which will perform authorizations and on-going risk
determinations to be leveraged government-wide. The board will consist of representatives from
GSA, DoD, DHS and the sponsoring agency of the authorized system.
GSA is working with OMB, security groups including the Federal CIO Council’s Information
Security and Identity Management Committee, and the marketplace to vet this program and
ensure that it will meet the security requirements of the government while streamlining the
process for industry.

Cloud Computing and Open Government

In the past decade, vast increases in the ubiquity and availability of storage space, bandwidth,
and computing power have enabled a new class of Internet-based applications—broadly called
"web 2.0"—that focus less on one-way delivery of information and more on enabling large,
diverse communities to come together, share their wisdom, and take action. Increasingly,
citizens—government's customers—simply expect to find the information they want and need
through the use of the on-line social networks and platforms they are rapidly adopting and use as
part of their everyday lives.

As our Administrator, Martha Johnson, noted upon being sworn in February 2010:

Hoarding and hiding information prevents citizens and civil servants from understanding and
participating in the public process effectively…We at GSA can help change that. We can make
the information more available, as a first step. And we can do much more. We can, and will, take
advantage of emerging technologies for sorting, sharing, networking, collective intelligence, and
using that information. Our goal is nothing short of a nation that relies not on select data and
statistical boxing matches, but on accurate evidence that supports knowledge and wisdom.

Most of these new web 2.0 technologies and tools are available as cloud-based SaaS solutions
and/or are hosted in cloud computing infrastructure environments. This allows the government to
offer these tools and services in a very cost-efficient manner. Let me highlight a few examples:

The Common Open Government Dialogue Platform is a project undertaken by GSA in

response to the Open Government Directive's mandate that agencies "incorporate a mechanism
for the public to provide input on the agency’s Open Government Plan." Over the course of six
weeks, GSA provided interested agencies with a no-cost, law- and policy-compliant, public-
facing online engagement tool, as well as training and technical support to enable them to
immediately begin collecting public and employee input on their forthcoming open government
plans. Since then, GSA has worked to transfer ownership of the open government public
engagement tool, powered by a cloud SaaS platform called IdeaScale, to interested agencies, in a
manner that provided both policy and legal compliance, as well as support for sustained
engagement. The tool was launched in February 2010 across 22 federal agencies and the White
House Office of Science and Technology Policy; overall resource investment was less than
$10,000 – far less than the hundreds of thousands or millions of dollars that would have resulted
from agencies independently pursuing and procuring IT solutions. The agencies’ dialogue sites
garnered over 2,100 ideas, over 3,400 comments, and over 21,000 votes during a six-week "live"
period and the tool continues to be used by several agencies for a variety of other open
government purposes.

USASpending.gov is a source for information collected from agencies in accordance with the
Federal Funding Accountability and Transparency Act of 2006. This public facing web site is a
cornerstone of the Administration’s efforts to make government open and transparent. Using
USAspending.gov, the public can determine how their tax dollars are spent and gain insight into
the Federal spending processes across agencies. It also houses the Federal IT Dashboard, which
displays details on the nearly 800 major federal IT investments based on data reported to the
Office of Management and Budget. This data is also now housed in a cloud infrastructure
environment maintained by NASA.

Data.gov is the central portal for citizens to find, download, and assess government data. It
now hosts over 270,000 data sets covering topics ranging from healthcare to commerce to
education. Data.gov was one of the first public facing government websites to deploy cloud
computing successfully in government. It empowers citizens by allowing them to create
personalized mash-ups of information from diverse sources (e.g., local school academic scores
arrayed by education spending levels), solve problems (e.g., FAA flight time arrival
information), and build awareness of government’s role in activities affecting daily activities
(e.g., food safety, weather, and the like).

Challenge.gov is a government-wide challenge platform that will be hosted in a cloud

computing infrastructure service to facilitate government innovation through challenges and
prizes. This tool provides forums for seekers (the federal agency challenger looking for
solutions) and solvers (those with potential solutions) to suggest, collaborate on, and deliver
solutions. It will also allow the public to easily find and interact with federal government
challenges. The platform responds to requirements defined in a March 8, 2010, OMB Memo,
“Guidance on the Use of Challenges and Prizes to Promote Open Government” which included a
requirement to provide a web-based challenge platform within 120 days. GSA is also exploring
acquisition options to make it easier for agencies to procure products and services related to
challenges.
 Citizen Engagement Platform will provide a variety of blog, challenge and other engagement
tools to make it easy for government to engage with citizens, and easy for citizens to engage with
government. The platform addresses agencies’ need for easy-to-use, easy-to-deploy, secure and
policy-compliant tools. This “build once, use many” approach adds lightweight, no-cost options
for agencies to create a more open, transparent and collaborative government with tools either
hosted or directly managed by GSA.

Conclusion

Mr. Chairman, cloud computing has a promising future in transforming the federal government
because of its ability to fundamentally reshape government IT operations used for critical
government business process and citizen service delivery support. It can help shift our focus to
value added use of the information we collect and provide cost effective services in a digitally
and networked enabled world. Additionally, it has the potential to free up resources that have
gone to support data centers and capabilities that are better leveraged across the community – at
bureau, agency or cross-agency level. At GSA, we are supporting this transformation by
leveraging cloud solutions and acquisitions on a government-wide basis wherever possible to
maximize economies of scale.

Thank you for the opportunity to appear today and I look forward to answering questions from
you and members of the Subcommittee.

Source: https://www.gsa.gov/node/78287
Cloud Computing: What Are the Security Implications?”

STATEMENT OF DR. DAVID MCCLURE ASSOCIATE ADMINISTRATOR OFFICE OF

CITIZEN SERVICES AND INNOVATIVE TECHNOLOGIES GENERAL SERVICES
ADMINISTRATION BEFORE THE HOUSE COMMITTEE ON HOMELAND SECURITY
SUBCOMMITTEE ON CYBERSECURITY, INFRASTRUCTURE PROTECTION AND
SECURITY TECHNOLOGIES

October 6, 2011

“Cloud Computing: What Are the Security Implications?”

Chairman King, Ranking Member Thompson and Members of the Subcommittee:

Thank you for the opportunity to appear before you today to discuss the General Service
Administration's (GSA) leadership role in ongoing efforts to enable and accelerate adoption of
secure cloud computing across the federal government. Cloud adoption is a critical component of
the Administration’s plan to improve management of the government’s IT resources. The IT
reforms we have underway are enabling agencies to use information more efficiently and
effectively, delivering improved mission results at lower cost.

Cloud Computing Adoption in the Federal Government

Before I discuss the security of cloud computing, and the Federal Risk Authorization and
Management Program (FedRAMP) in particular, I would like to make a two important points.
First, cloud computing offers a compelling opportunity to substantially improve the efficiency of
the federal government. It moves us from buying and managing physical assets to purchasing IT
as a commoditized service. Agencies pay for only IT resources they use in response to
fluctuating program demands, avoiding the expenses of building and maintaining costly IT
infrastructure. When implemented with sound security risk management approaches, cloud
computing also ensures more consistent protection of the government’s IT infrastructure, data
and applications.
Second, practical use of cloud computing offers substantial performance benefits for the
government. Federal agencies are moving to consolidate and virtualize the more than 2,000
federal data centers. Cloud technologies provide an ideal path forward to maximize value in IT
investment dollars while substantially lowering costs – an essential focus given federal budget
constraints. Case studies we have collected from agencies point to benefits that include:

• tangible cost reductions (data storage, web hosting and analytics performed on the
government’s vast data repositories);

• enhanced productivity (shifting workforce to more high value process improvements,

problem solving, and customer service excellence);

• greater flexibility and scalability (enabling CIOs to be much more responsive to pressing
service delivery expectations); and improved self-service capabilities (on-line streamlined
commodity-like purchasing for IT resources rather than long, arduous IT acquisitions).

GSA is playing a leadership role in facilitating easy access to cloud-based solutions from
commercial providers that meet federal requirements. This will enable agencies to analyze viable
cloud computing options that meet their business and technology modernization needs, while
reducing barriers to safe and secure cloud computing. We are developing new cloud computing
procurement options with proven solutions that leverage the government’s buying power. These
cloud procurement vehicles ensure effective cloud security and standards are in place to lower
risk and foster government-wide use of cloud computing solutions such as virtualization
technologies for government data centers, cloud email, disaster recovery/backup, and
infrastructure storage. Useful information about cloud computing and available solutions is
accessible from our web page, Info.Apps.gov.

GSA’s Federal Cloud Computing Initiative was started and is managed under GSA’s e-
Government program. In FY10 and FY11 GSA’s Federal Cloud Computing Initiative (FCCI)
Program Management Office (PMO) focused on five primary tasks:
Establishing procurement vehicles that allow agencies to purchase IT resources as commodities,
culminating in the award of the Infrastructure as a Service (IaaS) Blanket Purchase Agreement
under GSA Schedule 70 to 12 diverse cloud service providers

Addressing security risks in deploying government information in a cloud environment -

resulting in the development of the Federal Risk Authorization Management Program
(FedRAMP)

Establishing a procurement vehicle that will allow agencies to purchase cloud-based e-mail
services, which created GSA’s Email as a Service (EaaS) Blanket Purchase Agreement

Supporting the government-wide collection and assessment of data center inventories, and
assisting agencies in the preparation and execution of plans to close and consolidate data centers.
Current work includes developing a comprehensive data center Total Cost Model for agencies to
use to analyze alternative consolidation scenarios, enables data-driven decision-making for
infrastructure cost and performance optimization. Operationalizing a data center marketplace that
would help optimize infrastructure utilization across government by matching agencies with
excess computing capacity with those that have immediate requirements is also being pursued.

Creating apps.gov, an on-line storefront that provides access to over 3,000 cloud-based products
and services where agencies can research solutions, compare prices and place on-line orders
using GSA’s eBuy system Initial funding provided by the e-Gov Fund has allowed GSA to be an
effective catalyst for secure cloud technology adoption government wide. However, there are
critical activities that still need to be accomplished to fully realize the significant cost savings
and productivity improvements that GSA can help agencies achieve. The continuation of these
cost-saving initiatives is dependent on FY12 eGov Fund budget levels and decisions.

FedRAMP: Ensuring Secure Cloud Systems Adoption

Cloud computing – like any technology – presents both known and new risks alongside the many
benefits outlined above. To address these risks in a more uniform and comprehensive manner,
we will soon launch a new government-wide cloud security program – the Federal Risk and
Authorization Management Program (FedRAMP). The primary goal of the Administration’s
Cloud First policy is to achieve widespread practical use of secure cloud computing to improve
operational efficiency and effectiveness of government. Today, each agency typically conducts
its own security Certification and Accreditation (C&A) process for every IT system it acquires,
leading to unnecessary expense, duplication and inconsistencies in the application of NIST
derived security controls testing, evaluation, and certification procedures. According to the 2009
FISMA report to Congress, agencies reported spending $300 million annually on C&A activities
alone.

At GSA, we have worked in close collaboration with cybersecurity and cloud experts in NIST,
DHS, DoD, NSA, OMB, and the Federal CIO Council and its Information Security and Identity
Management Subcommittee (ISIMC) to develop FedRAMP. An OMB policy memo officially
establishing the FedRAMP program is expected shortly. The intent is to strengthen existing
security practices associated with cloud computing solutions which, in turn, will build greater
trust between providers and consumers and accelerate appropriate adoption of secure cloud
solutions across government. Accordingly, FedRAMP establishes a common set of baseline
security assessment and continuous monitoring requirements for FISMA low and moderate
impact risk levels using NIST standards that must be adhered to by all cloud systems. Figure 1
illustrates how FedRAMP will address three fundamental challenges with how the federal
government approaches ensuring cloud security.

Ensuring Consistency and Quality in Cloud Security Certification and Accreditation

FedRAMP approves qualified, independent third party security assessment organizations,

ensuring consistent assessment and accreditation of cloud solutions based on NIST’s
longstanding conformity assessment approach. As noted above, security C&As are currently
performed with varying quality and consistency. This is true for situations where a third party
service provider is contracted to do a security assessment of a CSP provided system, product or
service and where government security organizations perform the work themselves. As a result,
trust levels are low for reusing this work across agencies.

To address this challenge, FedRAMP will require that cloud services providers be assessed using
these approved, independent third party assessment organizations (3PAOs). The 3PAOs will
initially apply for accreditation through the FedRAMP PMO and be assessed using established
conformity assessment criteria developed by NIST.

This will ensure higher quality assessments, done much more consistently, using agreed upon
FedRAMP security assessment controls. This can save millions of dollars in expenses borne both
by government and industry in running duplicative assessments of similar solutions by each
agency.

Building Trust and Re-Use of Existing C&A Work

All IT systems, including cloud solutions, must receive an Authority to Operate (ATO)

from the buying agency before they can be made available for purchase and implemented. The
ATO is based on a thorough review by agency security professionals of the security packages
submitted following the C&A process described above. To accelerate cloud adoption and enable
C&A re-use, FedRAMP will provide a single, provisional authorization that can be used by all
agencies as the basis for issuing an ATO. If additional security assessment evaluation and testing
is needed for specific agency cloud implementations, the C&A should only address any
additional controls needed above the existing FedRAMP approved baseline.

FedRAMP establishes a Joint Authorization Board (JAB) that reviews all cloud systems that
have been assessed by approved 3PAOs using FedRAMP controls and processes. The JAB
membership consists of CIOs and Technical Representatives from DOD, DHS, and GSA. The
JAB reviews the C&A work and decides whether to grant the “provisional authorization” – a seal
of approval on the C&A work. The security packages, assessments and documented decisions
will be accessible within government from a secure central repository. While each agency must
grant its own ATO for systems under its control, FedRAMP will facilitate greater use of an
"approve once, and use often" approach, leveraging more ATOs across government.

Moving Towards More Real-Time Security Assurance

FedRAMP shifts risk management from annual reporting under FISMA to more robust
continuous monitoring, providing real-time detection and mitigation of persistent vulnerabilities
and security incidents. Using the expertise of industry, NIST, NSA, DHS and ISIMC, nine initial
continuous monitoring controls have been identified that are among the most common persistent
threat vulnerabilities in cloud and non-cloud systems environments. Cloud Service Providers
(CSPs) must agree to near-real time reporting of continuous monitoring data feeds to DHS and/or
agency Security Operations Centers (SOCs). We are finalizing data reporting details, with the
expectation that the process will eventually use automated data feeds to maximize efficiencies
and timeliness. When done in addition to the C&A evaluations, this will result in valuable
situational cyber awareness -- a relevant and timely picture of a CSP’s security posture. In
addition, this approach provides visibility of prompt mitigation and tangible evidence of
resolution; ensuring quick steps are taken to minimize threats to government data and operations.

There is strong support and demand for stronger cloud security from agencies seeking to adopt
cloud services, as required by the Administration’s Cloud First policy. Industry cloud services
providers need to know the specific cloud security capabilities for which they are accountable.
They also desire more efficiency in how C&As and ATOs are leveraged government-wide to
avoid unnecessary, duplicative, costly security evaluations. Ensuring IT security is an ongoing
challenge. We fully expect to make improvements to the process based on collaboration with all
key stakeholders, including industry, lessons learned and the continuous evolution of security
standards and controls based upon the careful, deliberative work of NIST.

FedRAMP will be launched in phases that incrementally build toward sustainable operations and
allows for risk management by capturing ongoing lessons learned and process improvement.
Initial rollout will occur this Fall. Initial Operational Capabilities will have limited scope and
cover a relatively small number of cloud service providers. Full operations are expected to begin
next Spring with more robust operational capabilities and larger intake of cloud service providers
for FedRAMP review and approval. Late in 2012, we expect sustaining operations to scale by
demand using a privatized board for 3PAO accreditation. We will discuss the rollout in more
depth with the Congress, government executive branch agencies, industry, and the public prior to
the initial launch date.

Conclusion

Considerable progress has been made in adopting successful cloud solutions. 'Cloud computing’
is now an accepted part of the federal IT lexicon. However, there continues to be a need for more
thorough understanding of cloud deployment models, unique security implications, and data
management challenges. Agency executives should not focus on cloud technology itself; rather,
they should focus on the desired outcome driving the need for cloud adoption delivered in a
secure environment.

FedRAMP will provide a sound, cost-effective framework for secure cloud computing. CIOs
need to work with their line of business executives and program managers to develop and deploy
effective cloud roadmaps that address pressing agency mission needs, taking into account
appropriate security and risk management. Agencies should analyze business needs and identify
cloud solutions that best fit their requirements by making secure cloud adoption part of an
overall IT portfolio management and sourcing strategy. Consistent with the Federal Cloud
Computing Strategy, NIST is currently working on the first draft of a USG Cloud Computing
Technology Roadmap, to be released for public comment in November, 2011. If linked to cloud
provider products and services, it would greatly assist in this decision-making. Mr. Chair man,
thank you for the opportunity to appear today. I look forward to answering questions from you
and members of the Subcommittee.

Source: https://www.gsa.gov/node/78395
Cloud IT Acquisition Services

Staff in the Customer Engagement and Solutions Development Division (CESDD)

Help agencies with their cloud acquisitions and strategy;

Develop and manage cloud-focused acquisition vehicles;

Promote cloud adoption and innovation across the federal government; and

Work across the government to understand your business needs and with industry to track
market trends.

Cloud SIN

The Cloud SIN is a subset of GSA’s IT Schedule 70 that agencies may target for their cloud
solicitations. Agencies may just solicit only the vendors on the Cloud SIN while satisfying their
competition requirements.

Email as a Service (EaaS)

The Email as a Service Blanket Purchase Agreements (BPAs) offer email cloud solutions,
migration services, integration services and more.

Infrastructure as a Service (IaaS)

The Infrastructure as a Service Blanket Purchase Agreements (BPAs) offer cloud storage, virtual
machine and web hosting solutions.

State, local and tribal governments for cloud IT

Most governments are eligible to buy cloud solutions from the programs above with GSA's
Cooperative Purchasing Program.

IT Solutions
Government wide Acquisition Contracts (GWACs) offer cloud services as part of a total IT
solution.

Networx Telecommunications services

Networx helps federal agencies build seamless, secure operating environments with the best
available technology, including storage in the cloud.
NIST Security and Privacy in Public Cloud Computing

Cloud computing technologies can be implemented in a wide variety of architectures, under

different service and deployment models, and can coexist with other technologies and software
design approaches. The security challenges cloud computing presents are formidable, including
those faced by public clouds whose infrastructure and computational resources are owned and
operated by an outside party that delivers services to the general public via a multi-tenant
platform.

Carefully plan the security and privacy aspects of cloud computing solutions before
engaging them. Public cloud computing represents a significant paradigm shift from the
conventional norms of an organizational data center to a deperimeterized infrastructure open
to use by potential adversaries.

As with any emerging information technology area, cloud computing should be approached
carefully with due consideration to the sensitivity of data. Planning helps to ensure that the
computing environment is as secure as possible and in compliance with all relevant
organizational policies and that privacy is maintained. It also helps to ensure that the
agency derives full benefit from information technology spending.

Organizations should take a risk-based approach in analyzing available security and

privacy options and deciding about placing organizational functions into a cloud
environment.

The information technology governance practices of the organizations that pertain to the
policies, procedures, and standards used for application development and service provisioning, as
well as the design, implementation, testing, use, and monitoring of deployed or engaged services,
should be extended to cloud computing environments.

To maximize effectiveness and minimize costs, security and privacy must be considered
throughout the system lifecycle from the initial planning stage forward. Attempting to
address security and privacy issues after implementation and deployment is not only much more
difficult and expensive, but also exposes the organization to unnecessary risk.

Understand the public cloud computing environment offered by the cloud provider. The
responsibilities of both the organization and the cloud provider vary depending on the
service model. Organizations consuming cloud services must understand the delineation
of responsibilities over the computing environment and the implications for security and
privacy.
Assurances furnished by the cloud provider to support security or privacy claims, or by a
certification and compliance review entity paid by the cloud provider, should be verified
whenever possible through independent assessment by the organization.

For the complete documentation see:

nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-144.pdf
DoD Guidance on Commercial Cloud Services
Updated Guidance on the Acquisition and Use of Commercial Cloud Computing Services

DoD CIO Memo - Publish Date: 12/15/14

This memo clarifies and updates DoD guidance when acquiring commercial cloud services. In
the context of this memo, commercial cloud services also refer to cloud services provided by
non-DoD federal government organizations.

SUBJECT: Updated Guidance on the Acquisition and Use of Commercial Cloud Computing
Services

References: (a) DoD Memorandum, "Designation of the Defense Information Systems Agency
as the Department of Defense Enterprise Cloud Service Broker," June 26, 2012 (Canceled)

(b) DoD Memorandum, "Supplemental Guidance for the Department of Defense's Acquisition
and Secure Use of Commercial Cloud Services," December 16, 2013 (Canceled)

(c) DoD Memorandum, "Use of Enterprise Information Technology Standard Business Case
Analysis," October 23, 2014

(d) Federal Risk Authorization and Management Program, http: //cloud.cio.gov/fedramp

(e) DoD Instruction 8500.01 "Cybersecurity", March 14,2014

This memo clarifies and updates DoD guidance when acquiring commercial cloud services, and
hereby cancels and replaces references (a) and (b). In the context of this memo, commercial
cloud services also refer to cloud services provided by Non-DoD federal government
organizations.

1. DoD components may acquire cloud services directly. It is no longer a requirement to use
DISA for the acquisition of cloud computing services.

2. Each Component remains responsible for determining what data and missions are hosted by
external cloud service providers per the direction below.
3. Each use of cloud services must be analyzed using the Enterprise IT Business Case Analysis
(BCA) template as provided in reference (c). The BCA must be approved by the Component CIO
and a copy submitted to the DoD CIO. DISA provided cloud services must be considered as part
of the BCA.

4. The Federal Risk Authorization and Management Program (FedRAMP) will serve as the
minimum security baseline for all DoD cloud services as described in reference (d). Per current
policy, components may host Unclassified DoD information that has been publicly released on
FedRAMP approved cloud services.

5. For more sensitive DoD unclassified data or missions (called Sensitive Data below), DoD has
developed cloud security requirements and guidance that go beyond FedRAMP. A draft of this
DoD Cloud Computing Security Requirements Guide (the Guide) is currently out for DoD public
comment, with official release scheduled for January 7, 2015. The Guide is intended to give
cloud providers a stable security requirement, and to help DoD cloud customers move more
rapidly and securely into the cloud. The Guide defines several classes of Sensitive Data, with
increasing security requirements for each. Additional detail on the Guide and the Guide
development process can be found in paragraph 11.

6. Any cloud service provider that is interested in hosting Sensitive Data will submit evidence to
DISA that the provider meets specific requirements of the Guide. DISA will evaluate this
evidence and if the provider meets the requirements, DISA will issue a DoD Provisional
Authorization (PA). The PA will describe the types of information and mission that can be
hosted by a particular cloud service.

7. Per the BCA of paragraph three, using the customer guidance in the Guide and the information
in the PA, the CIO of each Component will determine which cloud service provider to use for a
particular set of information or mission. DoD Components may only host Sensitive Data in cloud
service providers that have an appropriate PA.

8. Commercial cloud services used for Sensitive Data must be connected to customers through a
Cloud Access Point (CAP) provided by DISA or through a CAP provided by another DoD
Component. All CAPs must be approved by DoD CIO. The current Navy CAP is an example of
an approved provisional cloud access point. In the future, in order to standardize cyber defenses,
our goal is that all DoD access to commercial cloud services be via a DISA provided CAP. This
CAP will protect all DoD missions from incidents that affect a particular cloud service provider,
and will provide perimeter defenses and sensing for applications hosted in the commercial cloud
service.

9. Operations in a cloud environment are diverse and will require different concepts of
operations (CONOPS), business strategies, etc. Components are responsible for cyberspace
defense of all information and missions hosted in commercial cloud services, and will share
cyberspace defense information as necessary and appropriate with cloud service providers, in
accordance with reference (e). DoD Components that acquire or use cloud services are still
responsible for ensuring that end to end security requirements are met. To operate and defend
successfully, this will require collaboration and information sharing among the Component,
DISA and the cloud service provider.

10. The DoD Cloud Computing Security Requirements Guide will be an evolving document
informed by public and private input. It is intended to be a collaborative document between the
government and private sector that recognizes the rapid technology and business changes in the
cloud services environment. To assist in the development and use of the DoD Cloud Computing
Security Requirements Guide, DoD will be holding a series of meetings, the first being a
technical interchange meeting in person and via the web with interested DoD and industry
partners on December 18, 2014. Comments on the draft DoD Cloud Computing Security
Requirements Guide are due by December 29, 2014. Details can be found at http:
//iase.disa.mil/cloud security/Pages/index.aspx. In January 2015, the Deputy CIO for
Cybersecurity will host the first regular meeting with DoD and industry, at which time the
organizations with key cloud responsibilities in DoD will describe DoD requirements, processes,
and plans, and seek feedback from our government, private and public partners in the cloud
environment. In addition, comments on the Guide are welcome at any time, via the following
email address: disa.letterkenny.FSO.mbx.stig-customer-support-mailbox@mail.mil.

Source: http://www.doncio.navy.mil/ContentView.aspx?id=5877
Acquisition and Use of Commercial Cloud Computing Services

DON CIO Memo - Publish Date: 05/15/15

This memo provides updated guidance for leveraging commercial cloud services in the
Department of the Navy, implements the December 15, 2014 cloud computing guidance from
DoD CIO, cancels the DON CIO June 4, 2013 memo, "Update to Department of the Navy
Approach to Cloud Computing," and supersedes all direction concerning cloud pilots and cloud
services in the DON CIO July 31, 2013 memo, "Enterprise Mobility and Cloud Service Pilot
Project Governance."

Subj: ACQUISITION AND USE OF COMMERCIAL CLOUD COMPUTING SERVICES

Ref: (a) Department of the Navy Chieflnformation Officer Memorandum, Update to Department
of the Navy Approach to Cloud Computing, June 4, 2013

(b) DON CIO Memorandum, Enterprise Mobility and Cloud Service Pilot Project Governance,
July 31, 2013

(c) Department ofDefense CIO Memorandum, Updated Guidance on the Acquisition and Use of
Commercial Cloud Computing Services, December 15,2014

(d) DoD CIO Memorandum, Use ofEnterprise Information Technology Standard Business Case
Analysis, October 23, 2014

(e) Federal Risk Authorization and Management Program, http://cloud.cio.gov/fedramp

(f) SECNAVINST 5720.44C, Department ofthe Navy Public Affairs Policy and Regulations,
Change Transmittal!, October 14, 2014

(g) DoD Cloud Computing Security Requirements Guide (SRG), v1 rl, http ://iase.disa.mil/
cloud_security/Pages/index.aspx

(h) DoD Instruction 8500.01, Cybersecurity, March 14, 2014

Encl: (1) Cloud Services Supplemental Guidance

(2) Revised Information Impact Levels

(3) DON Enterprise IT Abbreviated BCA

This memorandum provides updated guidance for acquiring commercial cloud services in the
Department of the Navy (DON). It also cancels reference (a) and all direction concerning cloud
pilots and services in reference (b). Reference (c) states that Department of Defense (DoD)
Components may now acquire cloud services directly, without employing the Defense
Information Systems Agency (DISA) as a cloud broker. To ensure the consistent, best value,
enterprise-wide approach directed by DoD CIO, the DON will adhere to the following
requirements.

1. Each anticipated use of commercial cloud services will first be analyzed using either the DoD
Enterprise IT Business Case Analysis (BCA) template provided in reference (d) or the DON
Enterprise IT Abbreviated Business Case Analysis template, provided in enclosure (3).
Whichever template is used, DISA- provided cloud services must be included as one of the
alternatives considered. All BCAs will be reviewed by the respective Service DON Deputy CIO.
Those recommended for approval will be submitted to DON CIO for final approval. Per
reference (c), DON CIO will forward approved BCAs to DoD CIO.

2. Federal Risk Authorization and Management Program (FedRAMP) authorization is the

minimum security baseline for all DoD commercial cloud services, as described in reference (e).

3. Non-Controlled Unclassified Information (Impact Level2) that is publicly releasable may be

hosted by a Cloud Service Provider (CSP) that is FedRAMP compliant. The decision to accept
such authorization is subject to acceptance by the application/system owner, Service DON
Deputy CIO, and the responsible Navy or Marine Corps Authorizing Official (AO). Level2
information systems and applications are prime candidates for commercial cloud services due to
the low attendant risk. Guidance concerning information release and public communication is
provided in reference (f).

4. For more sensitive Controlled Unclassified Information (CUI) (Impact Level4), a DoD
Provisional Authorization (P A) is required in addition to FedRAMP Authorization. Per
reference (g), DISA will issue a DoD PA ifthe CSP meets the requirements. The PA will
describe the types of information and associated systems that can be hosted by a particular cloud
service. The Navy or Marine Corps AO must issue an Authority to Operate accepting the risk for
the system or application being hosted in a commercial cloud environment and for the
environment itself.

5. A commercial cloud service hosting CUI (Impact Level4) must be connected to customers
through a cloud access point (CAP) provided by either DISA or another DoD Component. All
CAPs must be approved by the DoD CIO.

6. Defense Procurement and Acquisition Policy (DP AP) will develop appropriate contract
language to address the issues, guidance and requirements in DFARS Case 20 13-D024,
Contracting for Cloud Services. In the interim, DON mission owners with approved BCAs are
advised to use the language provided in the DP AP Class Deviation-SUBPART 239.99-CLOUD
COMPUTING (DEVIATION 2015-00011).

7. DON entities that acquire commercial cloud services are responsible for the cyberspace
defense of all information and associated systems hosted therein and for ensuring that end-to-end
security requirements are met in accordance with reference (h). Successful operation and defense
will require collaboration and information sharing among the DON, DISA and the CSP.

Source: http://www.doncio.navy.mil/ContentView.aspx?id=6406
Cloud Computing Studies by the GAO
Additional Opportunities and Savings Need to Be Pursued GAO-14-753: Publicly
Released: Sep 25, 2014.

Why GAO Did This Study

Cloud computing is a relatively new process for acquiring and delivering computing services via
information technology (IT) networks. Specifically, it is a means for enabling on-demand access
to shared and scalable pools of computing resources with the goal of minimizing management
effort and service provider interaction. To encourage federal agencies to pursue the potential
efficiencies associated with cloud computing, the Office of Management and Budget (OMB)
issued a “Cloud First” policy in 2011 that required agency Chief Information Officers to
implement a cloud-based service whenever there was a secure, reliable, and cost-effective
option.

GAO was asked to assess agencies' progress in implementing cloud services. GAO's objectives
included assessing selected agencies' progress in using such services and determining the extent
to which the agencies have experienced cost savings. GAO selected for review the seven
agencies that it reported on in 2012 in order to compare their progress since then in
implementing cloud services; the agencies were selected using the size of their IT budgets and
experience in using cloud services. GAO also analyzed agency cost savings and related
documentation and interviewed agency and OMB officials.

What GAO Found

Each of the seven agencies reviewed implemented additional cloud computing services since
GAO last reported on their progress in 2012. For example, since then, the total number of cloud
computing services implemented by the agencies increased by 80 services, from 21 to 101. The
agencies also added to the amount they reported spending on cloud services by $222 million,
from $307 million to $529 million. Further, the agencies increased the percentage of their
information technology (IT) budgets allocated to cloud services; however, as shown in the table,
the overall increase was just 1 percent.

The agencies' relatively small increase in cloud spending as a percent of their overall IT budgets,
is attributed in part, to the fact that these agencies collectively had not considered cloud
computing services for about 67 percent of their investments. With regard to why these
investments had not been assessed, the agencies said it was in large part due to these being
legacy investments in operations and maintenance; the agencies had only planned to consider
cloud options for these investments when they were to be modernized or replaced. This is
inconsistent with Office of Management and Budget policy that calls for cloud solutions to be
considered first whenever a secure, reliable, and cost-effective option exists regardless of where
the investment is in its life cycle. Until the agencies fully assess all their IT investments, they
will not be able to achieve the resulting benefits of operational efficiencies and cost savings.

The agencies collectively reported cost savings of about $96 million from the implementation of
22 of the 101 cloud services. These savings included both one-time and multiyear savings. For
example, the General Services Administration saved $2.6 million by migrating to a cloud
customer service solution, and Homeland Security saved $1.2 million from fiscal years 2011
through 2013 by implementing a cloud-based collaboration service. Agency officials cited two
major reasons for why the other services they had implemented did not save money. First, a
motivation for changing to some of the cloud-based services was not to reduce spending, but to
improve service. Second, in selected cases, the cloud computing service opened up a new service
or provided a higher quality of service; while this provided useful benefits to the agency, the
associated costs negated any savings.

GAO is recommending, among other things, that the seven agencies assess the IT investments
identified in this report that have yet to be evaluated for suitability for cloud computing services.
Of the seven agencies, six agreed with GAO's recommendations, and one had no comments.

Cloud Computing: Agencies Need to Incorporate Key Practices to Ensure Effective

Performance GAO-16-325: Publicly Released: Apr 7, 2016.

Why GAO Did This Study

Cloud computing is a means for delivering computing services via IT networks. When executed
effectively, cloud-based services can allow agencies to pay for only the IT services used, thus
paying less for more services. An important element of acquiring cloud services is a service level
agreement that specifies, among other things, what services a cloud provider is to perform and at
what level.

GAO was asked to examine federal agencies' use of SLAs. GAO's objectives were to (1) identify
key practices in cloud computing SLAs and (2) determine the extent to which federal agencies
have incorporated such practices into their SLAs. GAO analyzed research, studies, and guidance
developed by federal and private entities to develop a list of key practices to be included in
SLAs. GAO validated its list with the entities, including OMB, and analyzed 21 cloud service
contracts and related documentation of five agencies (with the largest fiscal year 2015 IT
budgets) against the key practices to identify any variances, their causes, and impacts.

What GAO Found

Federal and private sector guidance highlights the importance of federal agencies using a service
level agreement (SLA) in a contract when acquiring information technology (IT) services
through a cloud computing services provider. An SLA defines the level of service and
performance expected from a provider, how that performance will be measured, and what
enforcement mechanisms will be used to ensure the specified performance levels are achieved.
GAO identified ten key practices to be included in an SLA, such as identifying the roles and
responsibilities of major stakeholders, defining performance objectives, and specifying security
metrics. The key practices, if properly implemented, can help agencies ensure services are
performed effectively, efficiently, and securely. Under the direction of the Office of
Management and Budget (OMB), guidance issued to agencies in February 2012 included seven
of the ten key practices described in this report that could help agencies ensure the effectiveness
of their cloud services contracts.

GAO determined that the five agencies and the 21 cloud service contracts it reviewed had
included a majority of the ten key practices. Specifically, of the 21 cloud service contracts
reviewed from the Departments of Defense, Health and Human Services, Homeland Security,
Treasury, and Veterans Affairs, 7 had fulfilled all 10 of the key practices, as illustrated in the
figure. The remaining 13 contracts had incorporated 5 or more of the 10 key practices and 1 had
not included any practices.

GAO recommends that OMB include all ten key practices in future guidance to agencies and that
Defense, Health and Human Services, Homeland Security, Treasury, and Veterans Affairs
implement SLA guidance and incorporate applicable key practices into their SLAs. In
commenting on a draft of this report, OMB and one agency had no comment, the remaining four
agencies concurred with GAO's recommendations.

Source: https://www.gao.gov/products/GAO-16-325
DEPARTMENT OF DEFENSE (DoD) CLOUD COMPUTING SECURITY
REQUIREMENTS GUIDE (SRG) Version 1, Release 1 12 January, 2015
1 Introduction

Cloud computing technology and services provide the Department of Defense (DoD) with the opportunity to deploy
an Enterprise Cloud Environment aligned with Federal Department-wide Information Technology (IT) strategies
and efficiency initiatives, including federal data center consolidation. Cloud computing enables the Department to
consolidate infrastructure, leverage commodity IT functions, and eliminate functional redundancies while improving
continuity of operations. The overall success of these initiatives depends upon well executed security requirements,
defined and understood by both DoD Components and industry. Consistent implementation and operation of these
requirements assures mission execution, provides sensitive data protection, increases mission effectiveness, and
ultimately results in the outcomes and operational efficiencies the DoD seeks.

The 15 December 2014 DoD CIO memo regarding Updated Guidance on the Acquisition and Use of Commercial
Cloud Computing Services defines DoD Component responsibilities when acquiring commercial cloud services. The
memo allows components to responsibly acquire cloud services minimally in accordance with the security
requirements outlined in Federal Risk and Authorization Management Program (FedRAMP) FedRAMP and this
Security Requirement Guide (SRG). DISA previously published the concepts for operating in the commercial cloud
under the Cloud Security Model. Version 1 defined the overall framework and provided initial guidance for public
data. Version 2.1 added information for Controlled Unclassified Information. This document, the Cloud Computing
Security Requirements Guide (SRG), documents cloud security requirements in a construct similar to other SRGs
published by DISA for the DoD. This SRG incorporates, supersedes, and rescinds the previously published Cloud
Security Model.

The following terms will be used throughout this document:

CSP by itself refers to any or all Cloud Service Providers, DoD or non-DoD.

Non-DoD CSP will refer to a commercial or Federal Government owned and operated CSP.

Commercial CSP will refer to a Non-DoD Non-Federal Government organization offering cloud services to the
public and/or government customers as a business, typically for a fee with the intent to make a profit.

DoD CSP will refer to a DoD owned and operated CSP.

CSO refers to a CSP’s Cloud Service Offering (recognizing that a CSP may have multiple offerings).

Commercial Cloud Service is a CSO offered by a Commercial CSP.

Mission Owners are entities such as program managers within the DoD Components responsible for instantiating
information systems and applications leveraging a CSP’s Cloud Service Offering.
1.1 Purpose and Audience

FedRAMP is a Federal Government program focused on enabling secure cloud computing for the Federal
Government. DoD, by the virtue of its warfighting mission, has unique information protection requirements that
extend beyond the controls assessed via FedRAMP. This document outlines the security controls and additional
requirements necessary for using cloud-based solutions within the DoD.

The Cloud Computing SRG serves several purposes:

Provides security requirements and guidance to non-DoD owned and operated Cloud Service Providers (CSPs)
that wish to have their service offerings included in the DoD Cloud Service Catalog.

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

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

Provides guidance to DoD Mission Owners and Assessment and Authorization officials (formerly Certification
and Accreditation) in planning and authorizing the use of a CSP.

The audience for this Cloud Computing SRG includes:

Commercial and non-DoD Federal Government CSPs

DoD programs operating as a CSP

DoD Components and Mission Owners using, or considering the use of, commercial/non-DoD and DoD cloud
computing services

DoD risk management assessment officials and Authorizing Officials (AOs)

1.2 Authority

This document is provided under the authority of DoD Instruction 8500.01 and DoD Instruction 8510.01.
DoDI 8500.01, entitled Cybersecurity, directs Director DISA, under the authority, direction, and control of the DoD
CIO to develop and maintain Control Correlation Identifiers (CCIs), Security Requirements Guides (SRGs),
Security Technical Implementation Guides (STIGs), and mobile code risk categories and usage guides that
implement and are consistent with DoD cybersecurity policies, standards, architectures, security controls, and
validation procedures, with the support of the NSA/CSS, using input from stakeholders, and using automation
whenever possible.

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

DoDI 8510.01 implements NIST SP 800-37, NIST SP 800-53, Committee on National Security Systems (CNSS)
Instruction (CNSSI) 1253, and the Federal Information Security Management Act (FISMA) by establishing the DoD
Risk Management Framework (RMF) for DoD IT, establishing associated cybersecurity policy, and assigning
responsibilities for executing and maintaining the RMF.

1.3 Scope and Applicability

This Cloud Computing SRG establishes the DoD security objectives to host DoD missions up to and including
SECRET on CSOs. Missions above SECRET must follow existing applicable DoD policies and are not covered by
this SRG.

This SRG applies to all CSP offerings, regardless of who owns or operates the environments. This SRG also applies
to any supporting cloud service provider or facilities provider that a CSP might leverage to provide a complete
service. While the CSP's overall service offering may be inheriting controls and compliance from a third party, the
prime CSP is ultimately responsible for complete compliance.

The assessment of security controls and other DoD requirements for commercial and non-DoD CSPs is based the
use of FedRAMP, supplemented with DoD considerations as outlined in section 4 of this document. DoD enterprise
service programs providing cloud capabilities or service offerings (e.g. milCloud, Defense Enterprise Email) use
DoD's assessment and authorization process under the DoD RMF. Both processes utilize the NIST SP 800-53
security controls as the basis of the assessment; providing a common framework under which DoD can determine
the level of risk.

This SRG establishes the DoD baseline security requirements for DoD Mission Owners when contracting for and
using non-DoD Software as a Service (SaaS) offering, and when implementing their systems and applications on
DoD or non- DoD Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) offerings. Since IaaS and PaaS
involve CSP customers building a system or application on top of these service offerings, this SRG considers IaaS
and PaaS as being similar and treats them in the same manner, unless stated otherwise. SaaS is addressed to the
extent of the other service models, with specific application requirements being identified in other application-
related SRGs and STIGs.

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

Security Requirements Guides (SRGs) are collections of requirements applicable to a given technology family,
product category, or an organization in general. SRGs provide non-product specific requirements to mitigate sources
of security vulnerabilities consistently and commonly encountered across IT systems and applications.

While the SRGs define the high level requirements for various technology families and organizations, the Security
Technical Implementation Guides (STIGs) are the detailed guidelines for specific products. In other words, STIGs
provide product-specific information for validating, attaining, and continuously maintaining compliance with
requirements defined in the SRG for that product's technology area.

A single technology related SRG or STIG is not all inclusive for a given system. Compliance with all SRGs/STIGs
applicable to the system is required. This may result in a given system being subject to multiple SRGs and/or STIGs.

Newly published STIGs generally consist of a technology/product overview document and one or more .xml files in
Extensible Configuration Checklist Description Format (XCCDF) containing the security requirements. Security
requirements are presented in the form of Control Correlation Identifiers (CCIs) and include product specific
configuration and validation procedures. Requirements in this SRG are not being published in an XCCDF XML
format at this time.

The security requirements contained within SRGs and STIGs, in general, are applicable to all DoD-administered
systems, all systems connected to DoD networks, and all systems operated and/or administrated on behalf of the
DoD.

1.5 SRG and STIG Distribution

Interested parties can obtain the applicable SRGs and STIGs from the Information Assurance Support Environment
(IASE) website. The unclassified website is http://iase.disa.mil and the classified website is http://iase.disa.smil.mil.

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

1.6 Document Revisions and Update Cycle

DISA FSO develops, revises, updates, and publishes SRG and STIG documents in accordance with the DISA FSO
quarterly maintenance release schedule. These publications reflect new or changed policies, requirements, threats, or
mitigations; reorganize content; correct errors; and/or, provide additional clarity. The fiscal year based release
schedule can be found at http://iase.disa.mil/stigs/Pages/fso-schedule.aspx.

Major updates to a SRG or STIG result in a version change rather than an incremental release. New SRGs and
STIGs and major updates will be released as soon as they are approved and ready for publication at any time during
the year.

Comments, proposed revisions, and questions are accepted via email at disa.stig_spt@mail.mil. DISA Field Security
Operations (FSO) coordinates all change requests with relevant DoD organizations before inclusion.

1.7 Document Organization

This SRG is organized into six major sections with supporting appendices. Sections 1-4 address general information
including the processes for authorizing a particular CSP's cloud offering. Remaining sections outline specific
security requirements to be addressed in authorizing and operating cloud capabilities. In addition to specifics on
SRG roles and responsibilities, and required control parameter values, the appendices provide the references and
definitions used throughout the document.

Section 1 – Introduction: Provides general information on the purpose and use of this document.

Section 2 – Background: Contains a primer on several terms and supporting concepts used throughout the document.

Section 3 – Impact Levels and Security Objectives: Explains the concept of "Impact Levels" based on the type of
data being hosted in the cloud and outlines security objective considerations in the areas of Confidentiality,
Integrity, and Availability.

Section 4 – Risk Assessment of Cloud Service Offerings: Provides an overview of the assessment and authorization
processes used for granting a DoD provisional authorization (PA) and explains how a PA can be leveraged by a
Mission Owner and its Authorizing Official (AO) in support of an Authority to Operate (ATO) decision.

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

Section 6 – Computer Network Defense and Incident Response: Outlines the requirements for defending
information systems operating in the cloud along with the Command and Control (C2) processes necessary to
defend and operate DoD mission systems.
2 Background

This section outlines several concepts, terms, and supporting processes, providing a primer for the remainder of this
document.

2.1 Cloud Computing, Cloud Service, and Cloud Deployment Models

The National Institute of Standards and Technology (NIST) Special Publication (SP) 800-145 defines cloud
computing, five essential characteristics, three service models, and four deployment models. This SRG adheres to
these NIST definitions to characterize and standardize the discussion of Cloud Computing.

"Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of
configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly
provisioned and released with minimal management effort or service provider interaction."

Cloud service models include Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a
Service (IaaS). The components offered in IaaS form the basis for PaaS, while the components offered in PaaS form
the basis of SaaS. Cloud deployment models include Public, Private, Community, and Hybrid. Please see NIST SP
800-145 for the detailed definitions of these models.

While vendors may market and name their offerings as they wish, DISA will categorize them into one of the three
NIST cloud service models when listing them in the DoD Cloud Service Catalog. Vendors are encouraged to market
their services using the NIST cloud service models. Service offerings that provide data storage without also
providing computing services will be considered to be a subset of IaaS.As used in this SRG the terms cloud
computing and cloud services refer to service offering from a provider organization to one or more organizational
customers or tenant organizations. These terms do not refer to classic forms of IT services delivery where dedicated
hardware (whether it is virtualized or not) is employed or assembled by organizations for their own use. A service
offering from a provider organization to a customer must be part of the construct.

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

A Cloud Service Provider (CSP) is an entity that offers one or more cloud services in one or more deployment
models. A CSP might leverage or outsource services of other organizations and other CSPs (e.g., placing certain
servers or equipment in third party facilities such as data centers, carrier hotels / collocation facilities, and Internet
Network Access Points (NAPs)). CSPs offering SaaS may leverage one or more third party CSP's (i.e., for IaaS or
PaaS) to build out a capability or offering.
A Cloud Service Offering (CSO) is the actual IaaS/PaaS/SaaS solution available from a CSP. This distinction is
important since a CSP may provide several different CSOs.

2.3 DoD Risk Management Framework (DoD RMF)

DoDI 8510.01 is the implementing policy for the DoD RMF, establishing associated cybersecurity policy, and
assigning responsibilities for executing and maintaining the RMF. This DoD policy is consistent with NIST SP 800-
37, Guide for Applying the Risk Management Framework, which defines RMF for the Federal Government. CNSSI
1253 and NIST SP 800-53, Security and Privacy Controls for Federal Information Systems and Organizations are
incorporated into this DoD policy, which outline the controls and control baselines used in the assessment process.
Of critical importance to this SRG, DODI 8510.01 "provides procedural guidance for the reciprocal acceptance of
authorization decisions and artifacts within DoD, and between DoD and other federal agencies, for the authorization
and connection of information systems (ISs)."

2.4 Federal Risk and Authorization Management Program (FedRAMP)

FedRAMP is a Federal Government program focused on enabling secure cloud computing for the Federal
Government. FedRAMP is mandated for use by all Federal Agencies by the Office of Management and Budget
(OMB) as their systems and applications are migrated to the commercial cloud under the Federal Government's
Cloud-First initiatives. OMB policy requires Federal departments and agencies to utilize FedRAMP approved CSPs
and share Agency Authority to Operate (ATO)s with the FedRAMP Secure Repository.

FedRAMP provides a standardized approach to security assessment, authorization, and continuous monitoring for
cloud services by incorporating the Federal Government RMF processes. FedRAMP uses a "do once, use many
times" framework that intends to reduce cost, time, and staff required for security assessments and process
monitoring reports. The FedRAMP Joint Authorization Board (JAB) is the primary governance and decision-making
body for the FedRAMP program. JAB approved standards and processes result in the award and maintenance of a
Provisional Authorization (PA) to host Federal Government missions.

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

2.5 FedRAMP Plus (FedRAMP+)

FedRAMP+ is the concept of leveraging the work done as part of the FedRAMP assessment, and adding specific
security controls and requirements necessary to meet and assure DoD’s critical mission requirements. A CSP’s CSO
can be assessed in accordance with the criteria outlined in this SRG, with the results used as the basis for awarding a
DoD provisional authorization.

2.6 DoD Provisional Authorization

A DoD Provisional Authorization is an acceptance of risk based on an evaluation of the CSPs offering and the
potential for risk introduced to DoD networks. It provides a foundation that Authorizing Officials (AOs) responsible
for mission applications can leverage in determining the overall risk to the missions/applications that are executed as
part of a CSO.

3 Information Security Objectives / Impact Levels

Cloud security information impact levels are defined by the combination of: 1) the level of information to be stored
and processed in the CSP environment; and 2) the potential impact of an event that results in the loss of
confidentiality, integrity or availability of DoD data, systems or networks. DoD Mission Owners categorize mission
information systems in accordance with DoDI 8510.01 and CNSSI 1253 to select the impact level that most closely
aligns with defined baselines.

3.1 Security Objectives (Confidentiality, Integrity, Availability)

Information Impact Levels consider the potential impact should the confidentiality or the integrity of the information
be compromised.

According to Federal Information Processing Standards (FIPS) Publication 199, Standards for Security
Categorization of Federal Information and Information Systems, confidentiality is "preserving authorized
restrictions on information access and disclosure, including means for protecting personal privacy and proprietary
information..." [44 U.S.C., Sec. 3542]. A loss of confidentiality is the unauthorized disclosure of information.

FIPS Publication 199 defines integrity as "Guarding against improper information modification or destruction, and
includes ensuring information non-repudiation and authenticity..." [44 U.S.C., Sec. 3542]. A loss of integrity is the
unauthorized modification or destruction of information. It is important to note that the unauthorized destruction of
information will result in the loss of availability of that information.

FIPS-199 defined three levels to designate the impact of a loss of confidentiality or a loss of integrity (refer to Table
1). The security control baseline for all Impact Levels is based on moderate confidentiality and moderate integrity. If
a Mission Owner has high potential impacts, specific requirements must be included in the contract/SLA to
address/mitigate this risk or deploy to DoD facilities assessed using CNSSI 1253 high baselines through the DoD
RMF. In the future DISA will consider incorporating a FedRAMP High Baseline into this SRG after one becomes
available.

Table 1 - Potential Impact Definitions for Security Objectives

Potential Impact

Security Low Moderate High

Objective

Confidentiality The unauthorized The unauthorized The unauthorized

disclosure of disclosure of disclosure of
information could be information could be information could be
expected to have a expected to have a expected to have a
limited adverse effect serious adverse effect severe or
on organizational on organizational catastrophic adverse
operations, operations, effect on
 organizational assets, organizational assets, organizational
or individuals. or individuals. operations,
organizational assets,
or individuals.

Integrity The unauthorized The unauthorized The unauthorized

modification or modification or modification or
destruction of destruction of destruction of
information could be information could be information could be
expected to have a expected to have a expected to have a
limited adverse effect serious adverse effect severe or
on organizational on organizational catastrophic adverse
operations, operations, effect on
organizational assets, organizational assets, organizational
or individuals. or individuals. operations,
organizational assets,
or individuals.

The baseline objectives do not address the impact of availability; it is expected that the Mission Owner will assess
the CSP's stated availability rating(s) during CSP selection. Any specific or additional availability requirements
must be included in the contract or a service level agreement with the CSP. Mission Owners must ensure the
language is specific and inclusive for their required availability. For example, if the requirement is "CSP
maintenance affecting system availability must be coordinated 4 weeks in advance and only conducted between
02:00 and 04:00 EST on Sunday morning," then the contract / SLA should detail the requirement. Recommended
contract / SLA availability controls are provided under the FedRAMP+ Controls/Enhancements in Section 5.1.5,
Controls/Enhancements to be Addressed in the Contract/SLA .

CSPs will be evaluated or queried as part of the assessment process to determine the level of availability they offer
to be listed in the DoD Cloud Service Catalog. This evaluation does not prevent a CSP from receiving a PA or being
included in the DoD Cloud Service Catalog; it is only used to facilitate the matching of a DoD Mission Owner to
one or more appropriate cloud services meeting their needs.

3.2 Information Impact Levels

The previously published Cloud Security Model defined 6 information Impact Levels. In order to simplify the
selection process, the number of levels was reduced from 6 to 4. This was accomplished by integrating levels 1
(public information) and 3 (low impact Controlled Unclassified Information (CUI)) into levels 2 and 4, respectively.
The numeric designators for the Impact Levels have not changed to remain consistent with previous versions of the
Cloud Security Model, leaving Impact Levels 2, 4, 5, and 6. Note that a higher level can process data from a lower
level.

Additionally, the security control baseline for all levels has been changed to moderate confidentiality and moderate
integrity as defined by CNSSI 1253 and the FedRAMP Moderate Baseline. This modification from high
confidentiality and high integrity is intended to better align with the categorization of most DoD customer systems
that will be deployed to commercial CSP facilities. Mission owners with systems categorized at high confidentiality
or integrity impact levels must deploy to DoD facilities assessed using CNSSI 1253 high baselines through the DoD
RMF or contract for the added security. DISA will consider incorporating a FedRAMP High Baseline into this SRG
after one becomes available.
The following subsections describe the impact levels, to include those used previously, and the type of information
to be stored or hosted in CSOs.

3.2.1 Level 1: Unclassified Information approved for Public release

Level 1 is no longer used and has been merged with Level 2.

3.2.2 Level 2: Non-Controlled Unclassified Information

Level 2 includes all data cleared for public release, as well as some DoD private unclassified information not
designated as CUI or critical mission data, but the information requires some minimal level of access control.

3.2.3 Level 3: Controlled Unclassified Information

Level 3 is no longer used and has been merged with Level 4.

3.2.4 Level 4: Controlled Unclassified Information

Level 4 accommodates CUI which is the categorical designation that refers to unclassified information that under
law or policy requires protection from unauthorized disclosure as established by Executive Order 13556 (November
2010) or other mission critical data. Designating information as CUI or critical mission data to be protected at Level
4 is the responsibility of the owning organization. Determination of the appropriate impact level for a specific
mission with CUI and mission data will be the responsibility of the mission AO.

CUI contains a number of categories, including, but not limited to the following:

• Export Control--Unclassified information concerning certain items, commodities, technology, software, or

other information whose export could reasonably be expected to adversely affect the United States national
security and nonproliferation objectives. This includes dual use items; items identified in export
administration regulations, international traffic in arms regulations and the munitions list; license
applications; and sensitive nuclear technology information.
• Privacy Information--Refers to personal information or, in some cases, personally identifiable information
(PII) as defined in Office of Management and Budget (OMB) M-07-16 or means of identification as
defined in 18 USC 1028(d)(7).
• Protected Health Information (PHI) as defined in the Health Insurance Portability and Accountability Act
of 1996 (Public Law 104-191).
• Other information requiring explicit CUI designation (i.e., For Official Use Only, Official Use Only, Law
Enforcement Sensitive, Critical Infrastructure Information, and Sensitive Security Information).

3.2.5 Level 5: Controlled Unclassified Information

Level 5 accommodates CUI that requires a higher level of protection as deemed necessary by the information owner,
public law, or other government regulations. Level 5 also supports unclassified National Security Systems (NSSs)
due to the inclusion of NSS specific requirements in the FedRAMP+ controls/control enhancements (C/CEs). As
such, NSS must be implemented at Level 5.

3.2.6 Level 6: Classified Information up to SECRET

Level 6 accommodates information that has been determined: (i) pursuant to Executive Order 12958 as amended by
Executive Order 13292, or any predecessor Order, to be classified national security information; or (ii) pursuant to
the Atomic Energy Act of 1954, as amended, to be Restricted Data (RD). At this time, only information classified as
SECRET, in accordance with the applicable executive orders, is applicable to this level. Services running at higher
classification levels, to include compartmented information, are governed by other policies and are beyond the scope
of this document. Impact Level 6 requires a similar set of tailored controls as Level 5 and includes the CNSSI 1253
Appendix F, Attachment 5 Classified Information Overlay C/CEs.

4 Risk Assessment of Cloud Service Offerings

The shift to cloud computing necessitates changes in the Risk Management processes. The goal is to address the
security requirements and controls, relative to the criticality of DoD information in the external cloud, in a cost
effective and efficient manner, while still assuring the security of DoD’s core missions and networks in accordance
with the DoD RMF. To support the relationship of missions to cloud capabilities, DoD has defined information
Impact Levels (discussed in Section 3) that broadly align to the criticality, sensitivity of data, and missions that
would operate in a cloud environment. The DoD provisional authorization (PA) risk assessment process is focused
on evaluating the requirements for the impact level(s) at which a CSP’s Cloud Service Offering (CSO) is capable of
supporting. The resulting PA would then be leveraged by the Mission Owner’s Authorization Official in granting an
authorization to operate (ATO) for the mission system operating within the cloud.

4.1 Assessment of Commercial/Non-DoD Cloud Services

The 15 December 2014 DoD CIO memo regarding Updated Guidance on the Acquisition and Use of Commercial
Cloud Computing Services, states "components may host Unclassified DoD information that has been publicly
released on FedRAMP approved cloud services." The memo also states "FedRAMP will serve as the minimum
security baseline for all DoD cloud services."

Impact Level 2: Using the definitions outlined in section 3, Impact Level 2 information may be hosted in a CSP that
is government assessed as FedRAMP compliant at the moderate level. The two acceptable government assessments
include:

• JAB Provisional Authorizations – Based on a determination by the JAB that an acceptable level of risk
exists for leveraging across the Federal Government. DoD is an active participant in the technical reviews
of the JAB PA security assessment artifacts.
• Agency ATOs – Based on an assessment and ATO issued by a specific agency. These are assessed and
authorized by a DoD agency, with the artifacts made available for leveraging by others across the Federal
Government.

The decision to leverage such authorizations is subject to acceptance by the Mission Owner and the responsible
Authorizing Official (AO).

Impact Level 4/5/6: Assessments for Impact Levels 4 and above is based on a combination of the security controls
in the FedRAMP Moderate baseline and the DoD specific controls/requirements outlined in section 5.1.2 DoD
FedRAMP+ Controls/Enhancements . Where possible, DoD leverages documentation and artifacts in the FedRAMP
Secure Repository and additional CSP proprietary artifacts. FedRAMP+ requirements will be assessed by a
FedRAMP certified Third Party Assessment Organization (3PAO) or an approved DoD assessor. An overall
determination of risk is prepared by the DISA Cloud Security Control Assessors to support a DoD PA decision and
listing in the DoD Cloud Service Catalog, available to DoD personnel. The DISA Authorizing Official (AO)
(formerly the DISA DAA) approves DoD PAs.

There are three paths that can be followed in assessing a CSP for a DoD PA. These are:

• CSPs with a FedRAMP JAB PA or in the process of obtaining a JAB PA: DoD leverages the
documentation and artifacts produced as part of the FedRAMP process, supplemented with an assessment
of the DoD-specific security controls and requirements not addressed by FedRAMP for Impact Levels 4
 and above. CSPs having a FedRAMP JAB PA have been assessed by a certified 3PAO against the
FedRAMP Moderate Baseline. For those in the process of obtaining a JAB PA, DoD promotes the use of
parallel activities (FedRAMP and FedRAMP+) to minimize cost and create efficiencies in the assessment
process.
• FedRAMP Agency ATO: CSPs having a Federal agency authorization based upon security controls
assessed by a certified 3PAO can be assessed for a DoD PA provided that the authorization is accepted and
listed in the FedRAMP agency authorizations. The information from the agency ATO will be supplemented
with an assessment of the DoD-specific controls and requirements.
• DoD Self-Assessed PA: CSP is assessed by the DISA cloud assessment team, independent of FedRAMP.
The CSP is minimally assessed against the FedRAMP Moderate Baseline and FedRAMP+ requirements. A
DoD self-assessment is typically used for dedicated cloud service offerings supporting the DoD or a private
cloud service offering by a DoD or commercial CSP. In this scenario, the CSP’s assessment package will
not be in the FedRAMP secure repository, since private clouds are ineligible for inclusion in the FedRAMP
catalog. When a FedRAMP authorization does not exist for a commercial CSP, the DoD organization with
a need for the authorization will be required to support resourcing for the full assessment, in coordination
with the DISA cloud security assessment team. This assessment of both the FedRAMP, FedRAMP+
security controls, and other SRG requirements determines whether to grant a DoD PA and the appropriate
impact levels.

NOTE: Any change of ownership involving a CSP, whether the primary CSP or an underlying CSP on which a
CSO was built, will be reviewed by the DISA AO to assess the impacts and risks associated with the continuation of
the DoD PA.

4.2 Assessment of DoD Provided Cloud Services

DoD operated CSOs (e.g., milCloud) are subject to the same requirements found in this SRG and the same security
controls as commercial CSPs. However, DoD CSP programs and services must follow DoD Risk Management
procedures in accordance with DoDI 8510.01. DoD enterprise service programs considered as cloud services under
the SaaS model (e.g., Defense Enterprise Email (DEE), Defense Connect Online (DCO), DoD Enterprise Portal
Service (DEPS)), are also subject to the DoDI 8510.01 requirements. Such programs are not subject to being
assessed through the FedRAMP program and do not share DoD ATOs with the FedRAMP secure repository.

DoD is transitioning to the DoD RMF from the DoD Information Assurance Certification and Accreditation Process
(DIACAP). DIACAP is based on a set of DoD specific security controls, not the NIST 800-53 security control
catalog. Cloud services initiated and authorized under the DIACAP will be assessed and authorized using the RMF
in accordance with DoD transition guidance as defined in DODI 8510.01 or supplemental DoD guidance.

4.3 Cloud Service Offering and Mission Owner Risk Management

Risk management must consider both the CSO and the supported mission (i.e., the Mission Owner's system or
application). Each CSO must be granted a DoD PA in order to host DoD mission systems. The PA can then be used
by the Mission Owner's risk management officials as a basis of reciprocity for the controls provided by the CSP,
recognizing the controls will vary based on the service model (IaaS, PaaS, SaaS) and could also vary based on
requirements such as privacy or classification controls. Additionally, there are controls that are "shared controls"
where both the CSO and the Mission Owner need to address a requirement. The responsible AO leverages the PA
information, supplemented with an assessment of the risks within the Mission Owner's responsibility, in granting an
authorization to operate.

Understanding the distinction between what's provided and addressed with the CSO versus what's addressed by the
Mission Owner is critical to implementing the DoD cloud security requirements as defined in this SRG.
4.3.1 Cloud Service Offering (CSO) Risk

The DoD PA provides a risk acceptance determination for the CSO against the appropriate DoD security
requirements. The DoD PA assessment process assesses CSO risk based on its supported impact level. At a level 4
and above, it’s important to recognize that the DoD PA evaluation process also assesses the risk to DoD of
permitting CSPs to interconnect with DoD networks.

4.3.2 Mission Risk

Overall mission risk will continue to be assessed and authorized by the Mission Owner's AO through the issuance of
an ATO. Mission refers to the information system and functions for which a DoD entity acquires or uses a CSO.
This may be the direct use of a SaaS CSO in performing an IT-enabled mission, or the instantiation of an IT system
or application on an IaaS/PaaS CSO.

Mission Owners categorize mission systems and/or applications in accordance with (IAW) DoDI 8510.01 defined
processes. Mission owners then select CSOs from the DoD Cloud Service Catalog based on their security posture
and the risk tolerance of the Mission Owner. While CSOs will have been assessed and provisionally authorized for
use, the Mission Owner must proceed IAW the RMF to obtain an Authority To Operate (ATO) from their assigned
AO.

The Mission Owner inherits compliance from the CSO for the security controls (or portions thereof) that the CSP
meets and maintains. A Mission Owner's system or application built on an IaaS or PaaS offering will be subject to
meeting many of the same security controls within the system/application. Mission Owners contracting for SaaS
offerings inherit the bulk of compliance with the security controls from the CSO. Inheritance will be different
between CSPs operating within a service type and thus must be evaluated separately. It should also be noted that the
number of controls increases with higher impact levels and additional overlay controls (e.g. privacy). Figure 1
illustrates this concept.

Figure 1 – Notional Division of Security Inheritance and Risk

The benefit of starting with a provisionally authorized CSO is that much of the security controls assessment work is
already accomplished. Mission Owners and their AOs must still review the FedRAMP and DoD PA artifacts to
understand the risks that the mission will inherit when using the selected CSO for the mission system/application.
Mission owners may need to implement, or request that the CSP implement, compensating controls for any risk
deemed unacceptable prior to obtaining an ATO.

4.4 CSP Transition from CSM v2.1 to SRG v1r1

FedRAMP provides a transition strategy for migrating CSP assessments from the FedRAMP v1 baselines based on
NIST 800-53 rev3 to the FedRAMP v2 baselines based on NIST 800-53 rev4. This strategy went into effect on June
6, 2014. The key points are as follows:

• Any new assessment starting after June 1, 2014 will immediately transition to FedRAMP v2 baselines
based on NIST 800-53 rev4.
• CSPs in the process of being assessed against FedRAMP v1 baselines based on NIST 800-53 rev3 prior to
June 1, 2014 will continue on this track, but must transition to the FedRAMP v2 baselines within one year
of their authorization date.
• CSPs currently in continuous monitoring will have until their next annual assessment to complete the
transition to FedRAMP v2 baselines.

The requirements in this SRG become effective immediately upon final publication. However, the DoD migration
plan for CSP assessments will mirror the FedRAMP plan as follows:

• Any new assessment starting after the release of this Cloud Computing SRG will be assessed against these
requirements.
• CSPs currently in the process of being assessed against the requirements in the CSMv2.1 will continue on
this track, but must transition to compliance with the Cloud Computing SRG requirements in coordination
with their next FedRAMP annual assessment.
• CSPs currently in continuous monitoring under CSMv2.1 will have until their next FedRAMP annual
assessment to complete the transition to compliance with the Cloud Computing SRG control requirements.

A DoD PA issued for a CSP using the CSMv2.1 and based on FedRAMP v1 remains in effect for the duration of the
DoD PA, so long as compliance is achieved with the timelines described above. DoD mission systems leveraging a
CSO may experience a period of time of time where risks based on FedRAMP v2 or new FedRAMP+ security
controls have not yet been assessed. Mission owners and their AOs must review the controls to determine if the risk
is acceptable until such time the CSP is required to comply or include the required compliance in the acquisition
language.

NOTE: CSPs wishing to transition sooner than later may do so at any time.

5 Security Requirements

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

• Security requirements for CSP’s service offerings.

• Security requirements for assessing commercial and DoD CSPs for inclusion in the DoD Cloud Service
Catalog.Security requirements for Mission Owner’s systems/applications instantiated on IaaS/PaaS.
 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 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, 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, 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 and acceptance by the
Mission Owner and the responsible Authorizing Official (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.

5.1.2 DoD FedRAMP+ Security Controls/Enhancements

A tailored baseline of security C/CEs 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 DoD cloud baseline
C/CEs, which are beyond what is required by FedRAMP (otherwise referred to as 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.

The CNSSI 1253 baseline used in support of DoD PAs is based on Moderate Confidentiality and Moderate Integrity,
not including a baseline for Availability (categorization designated as M-M-x). Availability is to 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. Based on this
comparison, we find 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-35 Moderate baseline incorporated in
both. We also find that eighty eight (88) of the C/CEs are not in the FedRAMP baseline. These 88 were analyzed for
their benefit and projected cost and approximately half were selected for the DoD cloud baselines. The number of
control enhancements selected varies by impact level.

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. NSS-specific Cs/CEs have been included at these levels along with those required
for the higher impact of these levels. Thus, an unclassified NSS must be instantiated at level 5. This, however, does
not preclude an unclassified non-NSS from operating at Level 5 if the mission requires the added security. Since
Impact Level 6 is for classified NSS, it is also subject to the CNSSI 1253 Classified Overlay which imposes ninety
eight (98) additional controls/enhancements. For IaaS/PaaS service offerings, there may only be a portion of the
classified overlay applicable to the CSP with the balance of the controls/enhancements 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.

Additionally, any level that deals with PII or PHI is additionally subject to the CNSSI 1253 Privacy Overlay (when
published). This overlay adds most of the privacy specific C/CEs from NIST SP 800-53 rev4 Appendix J Privacy
Control Catalog and provides additional supplemental guidance for many of the selected C/CEs in other families. It
was developed in accordance with Privacy Act and HIPAA requirements, leveraging experts and lawyers in both
fields. Legal references are included as the basis for C/CE selection and supplemental guidance. This overlay is fully
applicable to CSP's SaaS offerings that handle PII/PHI with some C/CEs (e.g., the required System of Records
Notice in accordance with TR-2) being addressed by the Mission Owner. For IaaS/PaaS offerings, only a portion of
the overlay may be applicable to the CSP with most C/CEs being fulfilled by the Mission Owner. This in no way
alleviates any requirement incumbent upon the CSP for protecting privacy act information related to its customers
and their accounts.

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. These additional FedRAMP+ and overlay Cs/CEs must be
implemented and documented by the CSP.

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 Templates and Key Documents page.

Table 2 - DoD FedRAMP+ Security Controls/Enhancements

SP 800-53r4 Level 4 Level 5 Level 6

Cont./Enh. ID

AC-06 (07) X X X

AC-06 (08) X X X

AC-17 (06) X X X

AC-18 (03) X X X

AC-23 X X X

AT-03 (02) X X X

AT-03 (04) X X X

AU-04 (01) X X X

AU-06 (04) X X X
AU-06 (10) X X X

AU-12 (01) X X X

CA-03 (01) X n/a

CM-03 (04) X X X

CM-03 (06) X X X

CM-04 (01) X X X

CM-05 (06) X X X

IA-02 (09) X X X

IA-05 (13) X X X

IR-04 (03) X X X

IR-04 (04) X X X

IR-04 (06) X X X

IR-04 (07) X X X

IR-04 (08) X X X

IR-06 (02) X X X

MA-04 (03) X X X

MA-04 (06) X X X

PE-03 (01) X X X

PL-08 (01) X X

PS-04 (01) X X

PS-06 (03) X X

SA-04 (07) X X
 SC-07 (10) X X X

SC-07 (11) X X

SC-07 (14) X

SC-08 (02) X X

SC-23 (01) X X X

SC-23 (03) X X X

SC-23 (05) X X

SI-02 (06) X X X

SI-03 (10) X X

SI-04 (12) X X X

SI-04 (19) X X X

SI-04 (20) X X X

SI-04 (22) X X X

SI-10 (03) X X X

Total 35 44 44
PLUS Privacy PLUS Privacy PLUS 98 from
Overlay if required Overlay if required Classified Overlay

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

Many NIST SP 800-53 Security Controls and enhancements contain parameter values that are left, by NIST, to the
organization to define. For those controls required by FedRAMP and the DoD, the parameter values are defined in
Appendix D.

5.1.4 Security Controls/Enhancements to be 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.

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

SP 800-53r4 Level 4 Level 5 Level 6

Cont./Enh. ID

AC-02 (13) X X X

AC-03 (04) X X X

AC-12 (01) X X

AC-16 X X X

AC-16 (06) X X X

AU-10 X X

IA-03 (01) X X X

PS-04 (01) X

PS-06 (03) X

SA-12 X X

SA-19 X X

SC-07 (11) X

SC-07 (14) X X

SC-18 (03) X X

SC-18 (04) X X

Total 9 12 11
5.2 Legal Considerations

5.2.1 Jurisdiction/Location Requirements

Legal considerations, including legal jurisdiction, control where DoD and US government data can be located.

Impact Level 2/4: 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. Authorizing Officials (AO), after careful
consideration of the legal ramifications, may authorize other locations if necessary to support mission requirements.
Information regarding AO authorized processing locations will be provided to the supporting CND providers and
DISA's cloud services support office.

Impact Level 5/6: To protect against seizure and improper use by non-US persons and government entities, all data /
information stored and processed 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.

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. 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. A CSP
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.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 (insider threat). 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., server platforms 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 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. A community cloud service implements
dedicated infrastructure to serve a specific group or class of customer organizations. Both can serve multiple tenants
(missions) within the customer organizations the service supports.

Shared infrastructure, for the purpose of this SRG, refers to the physical cloud infrastructure being available to DoD
and Federal Government tenants as well as non-DoD and Non-Federal Government tenants. This is also referred to
as a public cloud.

It is important to note that while clouds marketed as "International Traffic in Arms (ITAR) compliant,",
"government clouds,", or "clouds for government" might restrict data location to US jurisdiction, they do not
necessarily meet the standard for "dedicated" for the Federal Government or DoD. If the cloud service, or the
underlying infrastructure it resides on, contains any non-Federal US government tenant such as state or local
governments, industry partners, or foreign governments, it is a considered shared infrastructure for purposes of this
SRG.

NOTE: The use of the term "ITAR compliant" in a CSP's marketing documentation may or may not mean that the
Department of State's Directorate of Defense Trade Controls or the Department of Commerce's Bureau of Industry
and Services certified and documented the service offering as truly ITAR compliant. The CSP must substantiate
their claim by providing access to valid documentation or the DoD Mission Owner must validate such claims before
the Mission Owner considers the service offering based on its advertised compliance.

5.2.2.1 Impact Levels 2 and 4 Location and Separation Requirements

Impact Level 2 cloud services can be offered on either shared or dedicated infrastructure. Information that may be
processed and stored at Impact Levels 2 and 4 can be processed 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."
Information that may be processed and stored at Impact Level 4 can be offered on either shared or dedicated
infrastructure. Information that can be processed and stored at Impact Level 4 can be processed 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 CSP must provide evidence of strong virtual separation controls and monitoring, and the ability to meet "search
and seizure" requests without the release of DoD information and data.

5.2.2.2 Impact Level 5 Location and Separation Requirements

Information that must be processed and stored at Impact Level 5 can only be processed in a dedicated infrastructure,
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." This excludes public service offerings.

The following applies:

Only DoD private, DoD 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 permitted.

Virtual/logical separation between tenant/mission systems is minimally required.

Physical separation (e.g. Dedicated Infrastructure) from non-DoD/non-Federal Government tenants is required.

NOTE: A CSP may offer alternate solutions that provide equivalent security to the stated requirements. Approval
will be assessed on a case by case basis during the PA assessment process.

5.2.2.3 Impact Level 6 Location and Separation Requirements

Impact Level 6 is reserved for the storage and processing of classified information. 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.
 On-premises locations are approved through DoD processes and are operated in accordance with DoD and
Director of National Intelligence (DNI) policies.

Off-premises locations that restrict the physical location of the information as described in section 5.2.1,
“Jurisdiction/Location Requirements” are approved in accordance with the National Industrial Security Program
(NISP) as defined in Executive Order 12829 and the National Industrial Security Program Operating Manual
(NISPOM), DoD 5220.22-M.

A Facility Security Clearance and cleared personnel are required.

The hosting organization must operate the facility in accordance with the NISPOM.

Only DoD private, DoD community or Federal Government community clouds which are stand-alone or
connected to SECRET networks (e.g., SIPRNet) are eligible for Impact Level 6.

Each deployment model may support multiple SECRET missions from each customer organization.

Virtual/logical separation between DoD and Federal Government tenants / SECRET missions is permitted.

Virtual/logical separation between tenant/mission systems is minimally required.

Physical separation (e.g. Dedicated Infrastructure) from non-DoD/non-Federal Government tenants is required.

5.3 Ongoing Assessment

Both FedRAMP and DoD requires an ongoing assessment and authorization capability for CSPs providing services
to the DoD. This capability is built upon the DoD RMF and the foundation of the FedRAMP continuous monitoring
strategy, as described in the FedRAMP CONOPS and Continuous Monitoring Strategy Guide. These ongoing
assessment processes which are discussed in the following sections include continuous monitoring and change
control.

5.3.1 Continuous Monitoring

CSPs, 3PAOs, and DoD assessors are responsible for providing deliverables attesting to the implementation of
security controls. Continuous monitoring data flows will differ for CSPs depending on whether they have a
FedRAMP JAB PA, a 3PAO assessed Federal Agency ATO, or DoD Self-Assessed PA (as described in Section 4).
These data flows are reflected in Figure 2, Figure 3, and Figure 4 respectively.

In some cases, CSPs 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.

This section pertains specifically to continuous monitoring of security controls, as defined by CNSSI 4009 and NIST
SP800-137. This is separate from monitoring activities performed as part of Computer Network Defense, which are
described in Section 6.

5.3.1.1 CSPs in the FedRAMP Catalog

As described in section 4.1 Assessment of Commercial/Non-DoD Cloud Services, the CSPs, acceptable to DoD in
the FedRAMP catalog include CSPs having a JAB PA (which is 3PAO assessed) or a 3PAO assessed Federal
Agency ATO. These CSPs will provide all reports required by the FedRAMP Continuous Monitoring Strategy
Guide, including self- assessments, to the FedRAMP Information System Security Officer (ISSO). These will be
reviewed by the FedRAMP TRs 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 all continuous monitoring information (FedRAMP and
FedRAMP+) with appropriate Mission Owners, AOs, and Computer Network Defense (CND) Service Providers
(CNDSPs).

The information will be used by Mission Owners, their AOs, and the DISA AO to evaluate the risk posture of the
CSP's services. 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 2 shows the normal flow of continuous monitoring information if the CSP has a FedRAMP JAB PA.

Figure 2 - DoD Continuous Monitoring for CSPs with a FedRAMP JAB PA

Figure 3 shows the flow of continuous monitoring information if the CSP has a 3PAO assessed 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 3 - DoD Continuous Monitoring for FedRAMP CSPs with a 3PAO assessed Federal Agency ATO

5.3.1.2 DoD Self-Assessed CSPs

Figure 4 shows the flow of continuous monitoring information for non-FedRAMP CSPs having a DoD PA or ATO.
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 (CNDSP)
entities as defined in section 6, "Computer Network Defense and Incident Response."
 Figure 4 - DoD Continuous Monitoring for DoD Self-Assessed CSPs

5.3.2 Change Control

The DoD will review all significant changes planned by a CSP. Like 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 AO. Figure 5, Figure 6, and Figure 7 show these change control processes.

5.3.2.1 CSPs in the FedRAMP Catalog

FedRAMP defines a 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 enumerates significant
changes. The review of significant changes will be performed at multiple layers, as reflected in Figure 5. As part of
the FedRAMP process, when the CSP holds a FedRAMP PA, the CSP will notify the FedRAMP ISSO of any
planned 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 CSP 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 CNDSP
entities as defined in section 6, "Computer Network Defense and Incident Response."

When a CSP is included in the FedRAMP catalog, but does not have a JAB PA, the CSP will notify DISA directly,
who will in turn notify the all Mission Owners utilizing that CSO, the DISA AO, and the CNDSP entities as defined
in section 6, "Computer Network Defense and Incident Response." For CSPs in the DoD Cloud Service Catalog, 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) with respect to the impact level at which it is authorized. The planned change will also be
reviewed by the Mission Owners consuming the CSP's services for any adverse impact with regard to their specific
usage of the CSO. Any updates to the FedRAMP Security Package will be forwarded to DISA.

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

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

Figure 6 shows the normal flow of significant change information if the CSP has a 3PAO assessed 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 6 - DoD Change Control Process for FedRAMP CSPs with a 3PAO assessed Federal Agency ATO

5.3.2.2 DoD Self-Assessed CSPs

Figure 7 shows the flow of significant change for non-FedRAMP CSPs having a DoD PA or ATO. 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 CNDSP entities as defined in section 6,
"Computer Network Defense and Incident Response." These entities will review the proposed change to ensure it
will not adversely affect the security posture of the CSP with respect its PA or ATO. The planned change will also
be reviewed by the Mission Owners consuming the CSP's services for any adverse impact with regard to their
specific usage of the CSO.
 Figure 7 - DoD Change Control Process for DoD Self-Assessed CSPs

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.

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 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 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 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 privileged
and 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 a CSP is responsible for authentication of DoD entities and/or identifying a hosted DoD
information system, the CSP will use NSS PKI 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 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 will need to 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 while the Federal PKI is operated by GSA.
PK enable 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.

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

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).
o Integration with DoD PKI is typically a CSP responsibility. Minimally, the CSP is responsible for
providing capabilities that enables 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.
o Integration with DoD PKI is typically a CSP responsibility. Minimally, the CSP is responsible for
providing capabilities that enables 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)
o 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.
o Implementation is a Mission Owner responsibility.

Table 4 lists the Mission Owner credential types required at each impact level and the policy under which they are
required.
 Table 4 - Mission Owner Credentials
Impact IAW DoD policy
Level
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., two-
factor token based onetime
password, DoD ECA PKI
certificate, CAC/PKI, etc.)
• Privileged user’s access to
administer Mission Owner
systems/applications
instantiated on IaaS/PaaS
requires the use of DoD
CAC/PKI or Alt
Token/PKI. DoD External
Certification Authority
(ECA) PKI certificates may
be used by DoD contractor
personnel if a physical
token cannot be provided.
Level 4 • Non-privileged user access
and 5 to CUI, non-CUI critical
mission data, and/or
unclassified NSS (L5)
requires the use of DoD
CAC/PKI. DoD ECA PKI
certificates may be used by
DoD contractor personnel
IAW FedRAMP's selection of IA-
2(12):
• Mission Owner’s
privileged user’s 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. DoD
ECA PKI certificates may
be used by DoD contractor
personnel if a physical
token cannot be provided.
• 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 ECA PKI
certificate, CAC/PKI, etc.)
• 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.
DoD ECA PKI certificates
 if a physical token cannot
be provided.
• Privileged user’s access to
administer Mission Owner
systems/applications
instantiated on IaaS/PaaS
requires the use of DoD
CAC/PKI or Alt
Token/PKI. DoD ECA PKI
certificates may be used by
DoD contractor personnel
if a physical token cannot
be provided.
may be used by DoD
contractor personnel if a
physical token cannot be
provided.
• Mission Owner’s
privileged user’s 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. DoD
ECA PKI certificates may
be used by DoD contractor
personnel if a physical
token cannot be provided.

Level 6 • Non-privileged user access • Non-privileged user access

to classified information
requires the use of NSS
SIPRNet Token/PKI.
• Privileged user’s access to
administer Mission Owner
systems/applications
instantiated on IaaS/PaaS
requires the use of NSS
SIPRNet Token/PKI.
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.

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 CSP CSP's infrastructure supporting Mission Owner's systems.

Impact Levels 2/4: IAW 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.

Impact Level 5: IAW DoD policy, the CSP must implement a dedicated strong two-factor I&A capability for CSP
privileged user access to administer and maintain dedicated CSP infrastructure supporting DoD contracted services.
Impact Level 6: IAW 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 services.

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) 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 Compliance

CSPs are subject to the FedRAMP selected security control SP 800-53 CM-6. STIGs and/or SRGs may be used to
fulfill this baseline configuration requirement.

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

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

The Mission Owner 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.

The full list of All STIGs and SRGs can be found on DISA’s IASE web site.

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 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 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. Commercial
CSP’s data processing facilities that support cloud services infrastructure and classified service offerings must
participate in and be approved through the National Industrial Security Program (NISP) to receive a facilities
clearance. The requirements for NISP are outlined in DoD 5220.22M - the National Industrial Security Program
Operating Manual (NISPOM). To receive a DoD PA for Level 6, a CSP must either have a facility clearance or be
verified that they can meet the requirements to receive it when a contract is executed.

5.6.2 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 a CSP’s
employee can have on DoD mission or data.

5.6.2.1 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 Tool is 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 can 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, 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 in consistent with the OPM Position
Designation System October 2010 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 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, an agency must stipulate, “IAW OPM and Office of Management and Budget (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.

NOTE: 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.

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 and the DoD 5200.2-R,
both entitled DoD Personnel Security Program (PSP). Commercial CSPs’ personnel clearances are granted through
the Industrial Personnel Security Clearance Process.

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

5.6.2.3 Mission Owner Responsibilities Regarding CSP

Personnel Requirements

In addition to the above requirements, the FedRAMP Control Specific Contract Clauses v2, 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 in their contracts
with the CSP.

5.7 Data Spill

Per CNSSI 4009, IA Glossary, 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 an incident that requires immediate incident 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.4 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, however, frequently requires that affected resources be 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 virtualization and/or innovative storage methods may make physical data locations
difficult to ascertain, further complicating spill cleanup.

Variability in CSP infrastructures precludes the possibility of establishing a single cleanup process. Instead, CSPs
will be responsible for providing methods and timelines for deleting specified units of data within their
infrastructure in a way that provides high assurance that such data cannot be reconstructed. An example of such a
process is:
 • Volatile hardware with subject data will be powered down within 24 hours to clear data, subject to
exceptions based on potential side effects of cleanup actions.
• Unencrypted subject data locations on nonvolatile storage hardware will be overwritten or “cleared” as
defined in NIST 800-88 within 24 hours, subject to exceptions based on potential side effects of cleanup
actions. Encrypted subject data will be deleted cryptographically by destroying the appropriate decryption
keys, then “cleared” and overwritten.
• Affected nonvolatile storage hardware will be tracked through required inventory processes and destroyed
at the end of its useful life.

NOTE: The examples above are based on currently defined data spill remediation methods for physical systems
where the location of the spilled data is likely known. DoD will assess alternative methods for data spill remediation
for cloud infrastructures and will approve those deemed acceptable.

CSP’s data spill cleanup methods will be evaluated as part of the PA assessment and then made available to all
Mission Owners utilizing that CSP. The CSP will be responsible for executing any of those methods upon report of
a data spill by a Mission Owner.

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. Timely detection, reporting, and response are
key to limiting the migration of spilled data under these circumstances.

Mission owners must take steps to protect against the detrimental effects of a data spill; to the spilled data, the
Mission Owners virtual systems and networks, and to the cloud infrastructure on which it is spilled. One method is
to encrypt ALL Mission Owner data stored in a cloud infrastructure. Such encryption must utilize FIPS 140-2
validated data-at-rest cryptography (operated in FIPS mode). If a spillage occurs, the encryption keys to the stored
information could be destroyed; requiring data backup, recovery and disaster recovery remediation procedures to
restore clean mission data from a clean backup not containing the spilled data. Alternate innovative methods for
cloud data spill protection/remediation will be assessed for equivalency to standard methods and approved if found
sufficient.

5.8 Data Recovery and Destruction

For the purpose of this section, Data Recovery and Destruction refers to a Mission Owner requiring the recovery and
removal of data stored in a CSP’s infrastructure for the purpose of transferring it to a different storage facility.
Destruction (removal) of the data in the CSP’s infrastructure is required subsequent to the successful recovery
transfer. Transfers such as these typically occur when the contract with the CSP is terminated for any of several
reasons or the CSP goes out of business. Mission owners must prepare for such eventualities and CSPs must support
the capability in a timely manner.

Upon request by a Mission Owner, the CSP will make all Mission Owner data stored in certain service offerings
available for electronic transfer out of the CSP environment, with subsequent destruction, within 60 days from the
date of request. This primarily applies to any service offerings where the Mission Owner cannot just download files
and request destruction of the files, as might be the case if the Mission Owner’s data is co-mingled in a large
database with other Mission Owner’s data. Each Mission Owner may also request different means of data transfer
(for example, as called out in the SLA), at its discretion. The subsequent destruction of transferred Mission Owner
data must include removal from all CSO backups or mirrored storage maintained by the CSP. This is to prevent the
Mission Owner data from being restored accidentally or intentionally after destruction has concluded. To support
removal/recovery/destruction of CSP customer data in this type of service offering, the CSP must be able to identify
Mission Owner data on a mission by mission basis. The CSP will provide assurance of all data destruction.
Alternate timeframes can be proposed and assessed by DoD for acceptability. Data backup entropy (i.e., letting
backups be overwritten in accordance with CSP’s backup retention and media reuse policies) is unacceptable if
longer than the defined destruction time frame. While this approach is typical for IaaS/PaaS, it may not be for SaaS
where customer data might be co-mingled in a database and identification of a specific customer’s data is most
important.

DoD Mission Owners using non-DoD service offerings must be capable of recovery of their data at any time if able
to download the data files. For primary storage and CSO-managed backups or mirrored storage (or capability therein
even if not obligated by contract) maintained by the non-DoD CSP, Mission Owners must assure that Level 4 and
higher data is protected with FIPS 140-2 validated data-at-rest cryptography (operated in FIPS mode). This
alleviates the need for data destruction, which can be simply accomplished by destroying the encryption key(s).

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 800-88. Devices that are unable to be cleared or purged must be
physically destroyed, as defined in NIST 800-88. When there is any doubt to the success of the cleared or purged
process, the storage device must be destroyed in accordance with NIST 800-88.

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

5.10 Architecture

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

• The connection between the CSP’s infrastructure and the DoD Information Network (DoDIN)
• CSP service protections and integration into required DoDIN CND and access control services
• Mission system/application protections and integration into required DoDIN CND and access control
services

5.10.1 Cloud Access Points

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)”

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 will connect to a DoD Information Network (DoDIN)
service; the Non-secure Internet Protocol Router Network (NIPRNet), or Secret Internet Protocol Router Network
(SIPRNet). In general, the CAP will provide the following protections:
 • Protects the DoDIN and its network services.
• Protects other DoD missions from incidents that affect a particular CSP’s supported missions.
• Provides provide perimeter defenses and sensing for applications hosted in the commercial cloud service.
• Provides a point at which Boundary CND sensing will occur.
• Extends the DoD demilitarized zone (DMZ) architecture to external facing mission systems and
applications.

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

The implementation of the DoDIN BCAP capability 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. Specific CAP
architectural requirements (under development) are beyond the scope of this SRG and will be published separately.

Connection of a mission system to the DoDIN via an ICAP or BCAP will be approved and recorded by the DISA
Connection Approval Office in accordance with normal connection approval procedures. 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.

CSP Infrastructure (dedicated to DoD) located inside the B/C/P/S “fence-line” (i.e., on-premises) connects via an
ICAP. The architecture of ICAPs may vary and may leverage existing capabilities such as the IA Stack protecting a
DoD Data center today or may be 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 cloud services.

CSP Infrastructure (shared w/ non-DoD or dedicated to DoD) located outside the B/C/P/S fence-line which connects
to the DoDIN/NIPRNet does so via one or more BCAPs. The BCAP terminates dedicated circuits and VPN
connections originating within the CSP’s network infrastructure and/or Mission Owner’s virtual networks. All
connections between a CSP’s network infrastructure or Mission Owner’s virtual networks that is accessed via or
from the NIPRNet/SIPRNet must connect to the DoDIN via a BCAP.

Impact Level 2: All traffic to and from off-premises CSP infrastructure serving Level 2 missions and the mission
virtual networks will connect via the Internet. The BCAP is not used. On-premises CSP infrastructure serving Level
2 missions and the mission virtual networks will connect via an ICAP. See section 5.10.3.2, “Management Plane
Connectivity” for additional details.

Impact Levels 4/5: All DoD traffic to and from CSP infrastructure serving Level 4 and level 5 missions and the
mission virtual networks must connect via one or more BCAPs. This includes the production plane for non-
privileged user access and the management plane for privileged user access and deployed IA/CND tool connectivity
to internal CND monitoring systems. See sections 5.10.2.2, “User/Data Plane Connectivity” and 5.10.3.2
Management Plane Connectivity for additional details. High availability Mission Owner systems and their
supporting CSP network infrastructure must connect to two or more BCAPs. The BCAP will support Internet facing
Mission Owner systems IAW the DMZ STIG.

Impact Level 6: All DoD traffic to and from CSP infrastructure serving Level 6 missions and the mission virtual
networks must connect via one or more BCAPs to the SIPRNet instead of the NIPRNet. This includes the
production plane for non-privileged user access and the management plane for privileged user access and deployed
IA/CND tool connectivity to internal CND monitoring systems. See section 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 to two or more BCAPs.
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 Cloud Computing 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 Off-Premises On-Premises

Level Non-DoD CSP Service Offering DoD and Non-DoD CSP Service
Infrastructure Offering Infrastructure

Level 2 • User connectivity will • User connectivity will use

leverage commercial
infrastructure (i.e.,
Internet).
• Users connecting from the
Internet will connect
directly while users
connecting from inside the
DoDIN (i.e., NIPRNet)
will connect to the Internet
via the DoDIN 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.
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 DoDIN 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 • DoD and external user

And 5 connectivity will leverage a
DoDIN 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 DoDIN 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 DoDIN extension will
traverse a BCAP.
• Users connecting from
inside the DoDIN (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 the
same as any other internal
connection using the same
requirements as any other
Internet-facing connection
(i.e., IAW the DMZ STIG).

Level 6 • User connectivity will • User connectivity will use

leverage a DoDIN existing SECRET network
extension to the infrastructure (Government
commercial facility using owned) for its user/data
government SECRET plane (i.e., SIPRNet). User
network infrastructure traffic to/from the SIPRNet
within government will traverse an ICAP.
 boundaries (i.e. SIPRNet) • User traffic to/from the
and commercial Internet (e.g., executive
infrastructure beyond travel kits users) will use
government boundaries NSA Type 1 encryption or
(i.e. commercial carrier commercial equivalent
infrastructure / connectivity (CSfC Suite B) and must
service offerings). enter/leave the SIPRNet via
• The DoDIN extension to a the approved gateways.
commercial facility can be • CSO connections will be
accomplished with a assessed and authorized the
Multiprotocol Label same as any other internal
Switching (MPLS) router connection using the same
and optical switch (referred requirements as any other
to as a Service Delivery Internet-facing connection
Node). (i.e., IAW the DMZ STIG).
• The DoDIN extension to a
commercial facility will
traverse a BCAP and will
use NSA Type 1
encryption or commercial
equivalent (CSfC 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.

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.

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

Table 6 - Management Plane Connectivity

Impact Mission Owner Management CSP Service Offering

Level Plane Management Plane

Level 2 • Management connectivity • DoD CSP on-premises

by DoD personnel or DoD service offering
contractors from outside infrastructure and
the NIPRNet requires an management: CSP
encrypted, tunneled management connectivity
 connection directly 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 be
natively encrypted or must
traverse a VPN connection.
All traffic entering/leaving
the NIPRNet must be via
the DoDIN Internet Access
Points (IAPs).
• Management connectivity
from inside the NIPRNet
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 be
natively encrypted or must
traverse a VPN connection.
All traffic must enter/leave
the NIPRNet via the
DoDIN Internet Access
Points (IAPs).
Level 4 • Management connectivity
And 5 from inside the NIPRNet
requires an encrypted,
tunneled connection
will utilize existing
infrastructure such as the
Enterprise Services
Directorate (ESD) 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 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 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
an encrypted, tunneled
connection from the CSP’s
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
service offering and
management plane
infrastructure which should
be separate.
 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 be
natively encrypted or 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 requires an
encrypted, tunneled
connection from the
Internet via an IAP and an
ICAP or BCAP to 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 be
natively encrypted or must
traverse a VPN connection
via a BCAP and NIPRNet.

Level 6 • All management and • DoD CSP on-premises

monitoring connectivity is
via the SIPRNet.
Management and
monitoring traffic will be
encrypted using FIPS 140-
2 validated cryptography to
accommodate separation
for Need-to know reasons.
• Non-DoD CSP on-
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.
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 should
be 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 hosts 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 (IDPS), and a De-Militarized Zone (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.

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. Equivalent alternative measures
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.

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 IDPS protection of the CSP’s infrastructure
supporting the SaaS application offering, as well as segmentation 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.
• Customer data-at-rest encryption protections using FIPS 140-2 validated cryptographic modules operated in
FIPS mode.
• Customer data-in transit encryption protections using FIPS 140-2 validated cryptographic modules operated
in FIPS mode.
• Hardening / patching / maintenance of OSs and applications. DoD SRGs and STIGS may be used, and must
be used if the service is private DoD or a Federal Government Community used by DoD.
• 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.

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.

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 Architecture using IaaS/PaaS.”

5.10.4 IP Addressing and DNS

DoD policy and the Domain Name Service (DNS) STIG require all DoD ISs to use the DoD authoritative DNS
servers, not public or commercial DNS servers. Additionally it requires all DoD IS to be addressed in the .mil
domain. Mission Owners are not authorized to utilize DNS services offered by the CSP or any other non-DoD DNS
provider.

This affects DoD systems instantiated on commercial cloud infrastructure as follows:

Impact Level 2: DoD IS implemented at level 2 will be instantiated in commercial CSP facilities with direct access
from the Internet. As such they will be addressed using public Internet Protocol (IP) addresses assigned and
managed by the CSP. Â In order for these systems to comply with DoD DNS policy as noted above, they must use a
CNAME in the system’s authoritative DNS record within the DoD authoritative servers that directs the URL to the
CSP assigned public IP address.

Impact Levels 4/5: DoD IS implemented at levels 4 and 5 instantiated in commercial CSP facilities will be treated
and designed as an extension of the NIPRNet, and will be addressed using DoD assigned and managed IP addresses.
These systems will use the DoD authoritative DNS servers on the NIPRNet IAW policy as would any other DoD IS.
NIPRNet addresses are assigned by the DoD NIC.

Impact Level 6: DoD IS implemented at level 6 instantiated in commercial CSP facilities will be treated and
designed as an extension of the SIPRNet and will be addressed using SIPRNet IP addresses. These systems will use
the DoD authoritative DNS servers on the SIPRNet IAW policy as would any other SIPRNet connected IS. SIPRNet
addresses are assigned by the DoD NIC.

5.10.5 Mission Owner Architecture using SaaS

While defining 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 DoDIN. This includes all traffic for Levels 4, 5, and 6 as well as management plane
traffic for Level 2.
• Register the service/application with the DoD whitelist for both inbound and outbound traffic.
• Register the CSP’s CSO in SNAPS for the connection approval which also includes designation a certified
CNDSP as the Tier 2 CND.

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 Architecture using IaaS/PaaS

Most of the areas of concern for implementing defense-in-depth security / protective measures that a Mission Owner
must address across all information impact levels when implementing systems/applications on IaaS / PaaS 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 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.
• When infrastructure has direct Internet access, implement virtual application level firewall and virtual IDPS
capabilities IAW the applicable DoD SRGs and STIGs to protect the virtual network(s) and interconnected
VMs. The Mission Owner and/or their CNDSP must be able to control firewall rules and monitor the
virtual network boundary, reporting same to the Tier 1. For dedicated infrastructure with a DoDIN
connection (Levels 4-6): implement firewall, IPS, and/or routing methods that restrict traffic flow inbound
and outbound to/from the virtual network to the DoDIN 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 between the virtual firewall, the virtual IDS capabilities
and the CNDSP responsible for the mission system/application. See section 6, “Computer Network Defense
and Incident Response” for more specific information.
• Harden (STIG) / patch / maintain each VM’s OS under IaaS and PaaS IAW DoD policy and CYBERCOM
direction. The use of DoD STIGs and SRGs is required for hardening.
• Harden (STIG) / patch / maintain each application provided by the CSP under PaaS IAW DoD policy and
United States Cyber Command (USCYBERCOM) direction. The use of DoD STIGs and SRGs is required
for hardening.
• 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 hardening 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.
• If the DoD information is sensitive government (e.g., FOUO or CUI), FIPS 140-2 validated software crypto
modules operated in FIPS mode must be used.
• Implement Host Based Security System (HBSS) IAW DoD policy.
o Implement HBSS agents on all VMs with a supported general purpose OS.
o Utilize an HBSS agent control server within NIPRNet.
o Implement a secure (encrypted) connection or path between the HBSS agents and their control
server.
o Provide visibility by the Mission Owner’s CNDSP entities as defined in section 6, “Computer
Network Defense and Incident Response.”
• Implement scanning using an Assured Compliance Assessment Solution (ACAS) server IAW
USCYBERCOM TASKORD 13-670.
o Implement a secure (encrypted) connection or path between the ACAS server and its assigned
ACAS Security Center.
o Provide visibility by the Mission Owner’s CNDSP entities as defined in section 6.
• Implement DoD PKI server certificates for establishing secure connections.
• Implement all required data-in-transit encryption protections using FIPS 140-2 validated crypto modules
operated in FIPS mode.
• Implement DoD CAC / PKI authentication as follows:
 o 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.
o 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.
o Implement a secure (encrypted) connection or path 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.
• Register the Protocols and Services along with their related IP Ports used by the Mission Owner’s
system/service/application that will traverse the DoDIN. This includes all traffic for Levels 4, 5, and 6 as
well as management plane traffic for Level 2.
• Register the Mission Owner’s system/service/application with the DoD whitelist.
• Register the CSP’s CSO in SNAP for the connection approval which also includes designating a certified
CNDSP as the Tier 2 CND (refer to section 6).

NOTE: Under PaaS (and potentially IaaS) a Mission Owner may contract the CSP to harden (STIG) / patch /
maintain VMs, OSs, applications, or maintain STIGed and patched VM images for use if the CSP provides such a
service. Such services must be validated to DoD standards IAW all applicable policies (e.g., privileged access).
Equivalencies will be assessed and approved on a case by case basis.

6 Computer Network Defense and Incident Response

Computer Network Defense (CND) addresses the defense and protection of networks and Information Systems
(ISs), detection of threats, and response to incidents. Cyber Situational Awareness (CSA) improves the quality and
timeliness of collaborative decision-making regarding the employment, protection, and defense of DoD systems and
data. The DoD CND Command and Control (C2) structure provides the means to react to threats and incidents to
defend the DoD Information Networks (DoDIN). These are among the key challenges in DoD’s adoption of Cloud
Service Offerings (CSOs). This section addresses critical CND requirements; tiers, roles and responsibilities;
incident reporting and response; and other CND processes.

6.1 Overview of CND Tiers

DoD operates a tiered CND Command and Control (C2) structure as defined in DODI O-8530.2, Support to
Computer Network Defense (CND). The structure consists of USCYBERCOM at the top tier (Tier 1) and a network
of CND Service Providers (CNDSPs) (Tier 2) that have been accredited by USCYBERCOM IAW DoD policy.
Each DoD information system is operated/managed by a Mission Owner (Tier 3) which must be aligned with an
accredited CNDSP which monitors and protects the information systems and associated assets. CNDSPs report
information to USCYBERCOM which maintains Cyber Situational Awareness over all DoD networks and ISs.
USCYBERCOM also provides threat information collected from various sources and threat mitigation orders to the
CNDSPs and Mission Owners.

DoD is adjusting its CND C2 structure to include the Joint Force Head Quarters (JFHQ) – DoD Information
Network (DoDIN). As the JFHQ moves into operation, certain responsibilities may shift from USCYBERCOM at
Tier 1.

6.2 Concept Changes for Tiers for Cloud Computing

With the move to commercial cloud computing, the DoD is adopting a risk-based approach in applying network
defense capabilities and processes. As described in section 3, DoD has defined Impact Levels commensurate to the
risk and type of data, with each higher level warranting greater protections.
With Impact Level 2 data, the overall value of the data is not mission critical or sensitive in nature, thus it doesn’t
warrant the same level of protections as higher impact level data. Recognizing that the data at Impact Level 2 has
minimal requirements for confidentiality, emphasis must be placed on integrity and availability that achieve a level
of security and risk acceptable to the responsible Authorizing Official (AO). User connectivity to the information
system flows through the CSP’s Internet connection; thus DoD is relying on the network boundary protections and
monitoring that the CSP provides for all customers versus capabilities normally provided by a DoD CNDSP.
Protection capabilities supporting the mission system at the system/host/application level will be provided by a
combination of the CNDSP and the mission system administrators (including the CSP for SaaS).

Level 4 and above data presents greater risk and thus necessitates the need for enterprise defense mechanisms and
data collection that enable robust monitoring, event correlation, and analytics. With level 4 and above data, the
DoDIN boundary is essentially extended through a connection between the DoD CAP and the CSP's network
infrastructure supporting the DoD mission. Therefore, an event may be detected through a few different entities: the
CSP through monitoring of their CSO (especially for SaaS); the mission administrators or owners; or the CNDSPs
that are supporting the monitoring of the mission and the boundary connection. All entities must work together to
quickly investigate and respond to incidents. This change requires new constructs within the CND C2 structure,
including the identification of entities with new Tier 2 CND Command and Control (C2) and Operations (Ops)
responsibilities. The use of a Cloud Access Point (CAP) drives the requirement for two distinct functions/roles:
Boundary CND and Mission CND.

6.2.1 Boundary CND

Boundary CND (BCND) monitors and defends the connections to/from CSPs via an authorized CAP. BCND guards
against the risk that each CSP interconnection poses to the DoDIN individually, along with cross-CSP analysis for
all connections flowing through an individual CAP. While this function focuses on the connections through a
particular CAP, cross-CAP analysis is warranted to determine if a threat extends beyond a single CSP or CAP.

All anomalies identified by a BCND will be forwarded to DISA for cross-CAP analysis activities. The DISA
Command Center (DCC) and DISA NetOps Center (DNC) Continental US (CONUS) are assigned global CND C2
and Ops responsibility for protecting the DoDIN. This C2 construct addresses potential impacts across the multiple
missions supported by a CSP, ensuring that Mission Owners and supporting MCNDs have access to global
situational awareness.

6.2.2 Mission CND

Mission CND (MCND) provides services to a Mission Owner’s cloud-based mission systems/applications and
virtual networks. Any given MCND may service cloud-based mission systems/applications and virtual networks
instantiated in multiple CSPs and multiple CSOs. MCND is not a new Tier 2 entity; rather it is the integration of
existing DoD CNDSPs with a focus on elements of cloud computing. The MCND will typically be the CNDSP used
by the Mission Owner’s Command, Service, or Agency (CSA) for their non-cloud-based ISs; however, Mission
Owners can choose to use any certified CNDSP for their MCND provider.

6.3 CND Roles and Responsibilities

The following is a list of the CND C2 functional elements and their responsibilities as it relates to cloud operations.

• DoDIN CND: A Tier 1 function of the DCC and DNC CONUS focused on cross-DoDIN risk in DoD’s use
of cloud computing and commercial CSPs.
o Responsible for protecting the DoDIN and DoD mission systems in commercial cloud
infrastructure through cross-CAP correlation and analysis of events/data.
o Directs C2 actions regarding DoDIN-wide incident and system health reporting involving a CAP
or CSP.
 o For DoDIN-wide incidents, establish and maintain external communications with the CSP and
ensure internal DoD communications are established between all entities which include the
MCND and BCND.
o Interfaces with US-CERT to obtain relevant CSP information; ensures cross-sharing of
information across all BCND/MCND entities.
• Boundary CND (BCND): A Tier 1 and Tier 2 function of a certified CND provider responsible for the
management and monitoring of a CAP.
o Responsible for protecting the DoDIN and DoD mission systems in commercial cloud
infrastructure connected via the CAP.
o Coordinates communications between USCYBERCOM and MCNDs.
o Responsible for monitoring CSP adherence to incident response processes and advising the CSPs
via the respective MCND on protecting their infrastructure and the DoD mission systems that they
host.
• Mission CND (MCND): Tier 2 responsibilities integrated in the existing DoD CNDSPs focused on cloud
computing. At a minimum, the MCND is responsible for:
o Monitoring, protecting, and defending the Mission Owner’s cloud-based systems, applications,
and virtual networks in the CSP’s IaaS/PaaS infrastructure.
o Ensuring internal DoD communications are established between all entities which include the
Mission Owner, MCND, and BCND.
o Providing information on CSPs and missions being supported and the supporting BCND to
DoDIN CND and the JFHQ DoDIN for situational awareness.
• Mission Administrators: Administrators of Mission Owner’s cloud-based systems, applications, and
virtual networks; at a minimum, a Tier 3 entity consuming CNDSP services is responsible for:
o Following Tier 1 and Tier 2 direction (C2).
o Maintaining and patching the cloud-based mission systems, applications, and virtual networks.
o Installing and maintaining protective measures for the cloud-based mission systems, applications,
and virtual networks.
• The CSP: CSPs provide for their own CND services to provide for a secure environment for Mission
Owner's systems, applications, and virtual networks. CSPs will effectively function as an extension of the
DoD CND Tier 3 entity (i.e., the Mission Owner) toward this end. At a minimum, CSPs are responsible for:
o Providing local operational direction and support for CND within their infrastructure and service
offerings.
o Fully maintaining, patching, monitoring, and protecting the infrastructure, operating systems, and
applications supporting all service offerings.
o Fully maintaining, patching, monitoring, and protecting SaaS service offering OSs and
applications including DoD data/information in them.
o And as contracted:
▪ Coordinating with the MCND regarding incident response and the mitigation of threats to
DoD cloud based mission systems/applications and data.
▪ Providing timely incident and system health reports.
▪ Maintaining bidirectional Cyber Situational Awareness.
• Mission Owners: Individuals/organizations responsible for the overall mission environment, ensuring that
the functional and CND requirements of the system are being met. At a minimum, Mission Owners are
responsible for:
o Engaging and funding the services of a MCND to provide for the defense of the Mission Owner’s
systems, applications, and virtual networks in any CSP’s IaaS/PaaS infrastructure (whether DoD
operated or operated by a commercial/non-DoD entity).
o Establishing the terms and requirements in the contract with the CSP for incident reporting,
incident response, and communications with the appropriate MCND and BCND providers.

Figure 8 provides a graphic representation of these entities and the flow of communications between them.
 Figure 8 - DoD Cloud Incident Response and CND C2 Structure

6.4 Incident Reporting and Response

FedRAMP, through the selection and implementation of IR-6, requires CSPs to report incidents to the Department
of Homeland Security (DHS) United States Computer Emergency Readiness Team (US-CERT) and the consuming
Federal Agencies. For CSOs that are multi-tenant or otherwise shared across Federal Agencies outside of the DoD
(Impact Levels 2 through 5), incidents will be reported to US-CERT as required by FedRAMP, in parallel with
reporting to DoD. For CSPs providing dedicated infrastructure to the DoD (Impact Levels 4 and above), incidents
regarding that infrastructure and CSOs will not be reported to US-CERT, but directly to the DoD. The DoD Tier 1
(USCYBERCOM/JFHQ DoDIN) will handle coordination with US-CERT and other entities as appropriate.

All CSPs actively supporting DoD missions will be supported by a MCND. The MCND will be the DoD point of
contact to whom the CSP's Operational entity will report and coordinate response to incidents affecting the security
posture of the CSP and the CSP's cloud service offerings. The MCND will coordinate with the higher tiered BCND
as appropriate.

6.4.1 Incident Response Plans and Addendums

CSPs will provide, either as part of their Incident Response Plan or through an Incident Response Plan Addendum,
their approach to fulfilling integration requirements. CSPs will make their plan or addendum available to DISA for
review and approval as a condition of its PA and inclusion in the DoD Cloud Service Catalog. CSPs will update and
deliver the Incident Response Plan Addendum (if used) in conjunction with updates and deliveries of their Incident
Response Plan, as required by the FedRAMP selected security control IR-1. A CSP must specifically address data
breaches, where a “breach” includes the loss of control, compromise, unauthorized acquisition, unauthorized access,
or any similar term referring to situations where any unauthorized person has access or potential access to
government data, whether in electronic or non-electronic form, for any unauthorized purpose. CSPs must ensure that
the plan or addendum addresses all breaches regardless of the time, day, or location of the breach and must provide
for notice to the Government of any breach of its data. The plan or addendum must incorporate any other policies or
procedures that the Government may require to be followed in the event of a breach, including, but not limited to:

• How and to whom within the Government, the breach will be reported;
• Specific steps to be taken in order to mitigate or remedy the breach, including time periods for taking such
steps (e.g., reporting of Personally Identifiable Information (PII) data breaches within one hour, Negligent
Disclosure of Classified Information (NDCIs) which are commonly referred to as spillages);
• How and under what circumstances any individuals or entities affected by a breach will be notified and by
whom; and
• Any other special instructions for handling computer security incidents affecting, or potentially affecting
U.S. Government data; consistent with guidance and policy directives issued by DoD, NIST, US-CERT
and CNSS for incident management, classification, and remediation; or other applicable law, regulation,
order, or policy.

6.4.2 Information Requirements, Categories, Timelines, and Formats

Defending DoD missions and systems is a shared responsibility that requires all entities (CSPs; CND entities
(MCND, BCND); Mission Owners and Mission Administrators) to work collectively as a team. An event may be
detected by any of following entities, depending upon the connection architecture (direct Internet or through a CAP):

• CSP personnel through monitoring of their CSO (especially for SaaS);

• Mission administrators or owners (includes the CSP for PaaS/SaaS);
• Supporting MCNDs through their monitoring;
• Supporting BCNDs via the CAP monitoring.

All entities must work together to quickly investigate and respond to events and incidents. In the course of a CSP
performing CND for its environments, CSPs will monitor their information systems and report relevant information
to the MCND, focused on situations where any unauthorized person has access or potential access to government
data.

CSP’s reporting requirements to DoD will align with the reporting lexicon used by US CERT for the broader
Federal Government reporting requirements. Incident notifications should include a description of the incident and
as much of the following information as possible:

• Contract information to include contract number, USG Contracting Officer(s) contact information, contract
clearance level, etc.
• Contact information for the impacted and reporting organizations as well as the MCND.
• Details describing any vulnerabilities involved (i.e., Common Vulnerabilities and Exposures (CVE)
identifiers)
 • Date/Time of occurrence, including time zone
• Date/Time of detection and identification, including time zone
• Related indicators (e.g. hostnames, domain names, network traffic characteristics, registry keys, X.509
certificates, MD5 file signatures)
• Threat vectors, if known (see Threat Vector Taxonomy and Cause Analysis flowchart within the US-CERT
Federal Incident Notification Guidelines)
• Prioritization factors (i.e. functional impact, information impact, and recoverability as defined flowchart
within the US-CERT Federal Incident Notification Guidelines) (https://www.us-
cert.gov/sites/default/files/publications/Federal_Incident_Notification_Guidelines.pdf)
• Source and Destination Internet Protocol (IP) address, port, and protocol
• Operating System(s) affected
• Mitigating factors (e.g. full disk encryption or two-factor authentication)
• Mitigation actions taken, if applicable
• System Function(s) (e.g. web server, domain controller, or workstation)
• Physical system location(s) (e.g. Washington DC, Los Angeles, CA)
• Sources, methods, or tools used to identify the incident (e.g. Intrusion Detection System or audit log
analysis)
• Any additional information relevant to the incident and not included above.

Initial incident reports should be submitted within one hour of discovery with follow-on information provided as
available. Initial reports may be incomplete to facilitate communication and teamwork between the CSP and the
supporting MCND/BCND entities. CSPs should balance the necessity of timely reporting (incomplete reports with
critical information) versus complete reports (those with all blocks completed). Timely reporting is vital, and
complete information should follow as details emerge.

NOTE: These requirements are applicable to all systems at all Information Impact Levels. The CSP must follow
these requirements when integrating with the DoD Command and Control (C2) and Network Operations (NetOps)
structure. Mission Owners must include these requirements in the contract, even at Level 2.

6.4.3 Incident Reporting Mechanism

DoD CSP's CND providers will report all incidents IAW normal DoD processes using the Joint Incident
Management System (JIMS).

Commercial CSPs will report all incidents via the on-line Defense Industrial Base (DIB) Cyber Incident Collection
Form (ICF). Use of the on-line form is preferred. Access to this form requires a DoD-approved medium assurance
External Certificate Authority (ECA) certificate. If you are unable to access this form, please call (877) 838-2174 or
email: DCISE@DC3.mil.

The CSP must include, for routing purposes, all MCND points of contact (POCs) for all DoD missions affected by
the incident. This is in addition to any other POCs required by the tool for routing to contract managers, etc. The
MCND, once the report is received, will initiate the DoD reporting process via JIMS.

Note: The Incident Collection Form (ICF) requires modification in order to be fully aligned with the above reporting
requirements. In the interim the current form will be used. CSPs should complete the fields as appropriate.

When classified incident reporting is appropriate and directed, CSPs will use SIPRNet email or secure phone/fax to
report and coordinate incidents as specified. This will always be the case for Level 6 reporting.

Existing notification mechanisms of a CSP that are already in place to communicate between the CSP and its
customers for some or all classes of CND information may be used, as long as those mechanisms demonstrate a
level of assurance, equivalent to the listed encrypted mechanisms, for the confidentiality and integrity of the
information.
6.5 Warning, Tactical Directives, and Orders

The DoD operates a tiered CND C2 structure in order to effectively defend DoD information systems that are
networked globally across a diverse set of environments. Each of these environments must defend the network and
ensure the security of computing and communication systems. It is critical that certain information be disseminated
and that actions and supporting countermeasures can be directed from higher levels of command to network
defenders (which include CSPs supporting defense of their CSOs).

The DoD cyber chain of command for CSPs is represented in Figure 8 (Section 6.3). USCYBERCOM, at Tier 1,
disseminates Warnings, Tactical Directives, and Orders to both the BCND and MCNDs (all Tier 2). The BCND
entities will analyze them for their applicability to individual CSPs, and then communicate with USCYBERCOM
and the CSPs as appropriate. CSPs (effectively acting as Tier 3) will coordinate with the BCND, MCND, and
Mission Owners as contracted to implement the provided guidance and countermeasures.

CSPs must be able to receive, act upon, and report compliance with directives and notifications sent by CND Tier 2
(MCND or BCND), as required by FedRAMP selected security control SI-5.

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

Understanding existing vulnerabilities and risks within the enterprise is a key component in performing effective
CND analysis. The vulnerability reports and POA&Ms developed by the CSPs as part of continuous monitoring
requirements supporting both FedRAMP and FedRAMP+ requirements will be made available by DISA’s cloud
services support team to the MCND and BCND providers for their collective use in providing CND.

6.7 Notice of Scheduled Outages

Planned outages affecting mission systems are to be coordinated through the Mission Owner; with the goal of
minimizing impacts to the operational community. An approved outage is referred to as an Authorized Services
Interruption (ASI). CSPs must notify all affected MCND providers of ASIs under their control when an outage starts
and upon return to service. Outages or changes that affect more than one mission environment must be reported by
the MCND to the BCND to enable broader situational awareness across all MCND providers. Mission owners and
administrators are responsible for the same notifications to the MCND when the ASI is under their control.

6.8 PKI for CND Purposes

The DoD PKI program provides assurances of an individual’s identity, which is important in sharing information
regarding C2 and CND functions. This section outlines requirements for establishing trusted identities for CSP
personnel communicating securely with DoD CND personnel.

Impact Level 2 through 5: CSPs must preferably have either a DoD PKI certificate or a DoD-approved External
Certification Authority (ECA) medium-assurance PKI Certificate for each person that needs to communicate with
DoD via encrypted email. The DoD has established the ECA program to support the issuance of DoD-approved
certificates to industry partners and other external entities and organizations; providing a mechanism to securely
communicate with the DoD and authenticate to DoD Information Systems. Additional information on the ECA
program can be found at http://iase.disa.mil/pki/eca/Pages/index.aspx. Equivalent alternative measures will be
assessed on a case by case basis.

Impact Level 6: CSPs serving Level 6 systems will already have SIPRNet tokens / NSS PKI certificates for their
system administrators by virtue of the connection to SIPRNet. Incident response and CND personnel will use
SIPRNet tokens/certificates to communicate with DoD via encrypted email.
6.9 Vulnerability and Threat Information Sharing

Vulnerability and threat information sharing is a highly effective way for DoD to help CSPs protect and defend DoD
information housed or processed in their service offerings. Government sources such as US CERT and
USCYBERCOM provide detailed vulnerability information. Several commercial sources also provide supplemental
information that can be used by CSPs in further defending their infrastructure. CSPs are encouraged to leverage such
knowledge sources. However, much of the information that the DoD can provide to CSPs is classified. An avenue to
obtain such information follows:

The Defense Industrial Base Cyber Security / Information Assurance Program (DIB CS/IA) is a program to enhance
and supplement DIB participants’ capabilities to safeguard DoD information that resides on, or transits, DIB
unclassified information systems. Membership in DIB CS/IA enables DIB participants to acquire access to DIBNet-
U and DIBNet-S, the unclassified and classified networks used for data sharing and collaboration. Access to DIBNet
provides CSPs with access to CYBERCOM notifications, classified email, and the DIB web portals.

Access to DIBNet provides CSPs with access to both classified and unclassified cyber threat information, including
mitigation strategies. DIB CS/IA program membership is voluntary, although cyber incident reporting as described
in section 6.4.3 is mandatory. Eligible CSPs are encouraged to join the voluntary DIB CS/IA program to facilitate
their protection of infrastructure that hosts higher-value DoD data and systems.

NOTE: DoD CSPs are already integrated into the CND communications architecture and receive unclassified
CYBERCOM notifications via established channels.

Appendix A References

1. Executive Order 13526: Classified National Security Information, dated 29 December 2009.
http://www.archives.gov/isoo/policy-documents/cnsi-eo.html
2. Executive Order 12829 - National Industrial Security Program, dated January 1993.
http://www.archives.gov/isoo/policy-documents/eo-12829.html
3. NIST SP 500-292: NIST Cloud Computing Reference Architecture, dated September 2011.
http://www.nist.gov/customcf/get_pdf.cfm?pub_id=909505
4. 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.

5. 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
6. 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
7. NIST SP 800-88, Revision 1: Draft: Guidelines for Media Sanitization, dated September 2012.
http://csrc.nist.gov/publications/drafts/800-88-rev1/sp800_88_r1_draft.pdf
8. 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
9. 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
10. NIST SP 800-145: The NIST Definition of Cloud Computing, dated September 2011.
http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf
11. 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
12. CNSS Instruction 4009: National Information Assurance (IA) Glossary, dated 30 April 2010.
https://www.cnss.gov CNSS Instruction 1253: Security Categorization and Control Selection for National
Security
Systems, dated 27 March 2014. https://www.cnss.gov
13. CNSS Instruction No.1253F, Attachment 5: Classified Information Overlay dated 09 May 2014.
https://www.cnss.gov
14. CNSS Instruction No.1253F, Attachment x: Privacy Overlay dated TBD.
https://www.cnss.gov (when available)
15. DoD Chief Information Officer, Updated Guidance on the Acquisition and Use of Commercial Cloud
Computing Services, 15 December 20014.
http://iase.disa.mil/Documents/commercial_cloud_computing_services.pdf
16. DoD Instruction 8500.01: Cybersecurity, dated 14 March 2014.
http://dtic.mil/whs/directives/corres/pdf/850001_2014.pdf
17. 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
18. DoD Instruction 8520.03: Identity Authentication for Information Systems, dated 13 May, 2011.
http://dtic.mil/whs/directives/corres/pdf/852003p.pdf
19. DoD Instruction O-8530.2, "Support to Computer Network Defense (CND)", March 9, 2001.
https://whsddpubs.dtic.mil/corres/pdf/O85302p.pdf (PKI requiredd)
20. DoD Instruction 5220.22: National Industrial Security Program, dated March 2011.
http://www.dtic.mil/whs/directives/corres/pdf/522022p.pdf
21. 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
22. 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
23. 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
24. 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
25. 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
26. 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
27. DoD Manual 5200.2-R: Personnel Security Program, dated February 1996.
http://www.dtic.mil/whs/directives/corres/pdf/520002r.pdf
28. CJCSM 6510.01B: Chairman of the Joint Chiefs of Staff Manual: Cyber Incident Handling Program, dated
10 July 2012. http://www.dtic.mil/cjcs_directives/cdata/unlimit/m651001.pdf
29. DSS Facility Clearance Branch http://www.dss.mil/isp/fac_clear/fac_clear.html
30. DoD ECA PKI Certificate: http://iase.disa.mil/pki/eca/Pages/index.aspx
31. OPM Position Designation System 2010: .
http://www.opm.gov/investigations/background-investigations/position-designation-tool/oct2010.pdf Â
32. Federal Risk and Authorization Management Program (FedRAMP) Home Page
http://cloud.cio.gov/fedramp
33. FedRAMP Control Specific Contract Clauses v2, June 6, 2014; http://cloud.cio.gov/document/control-
specific-contract-clauses
34. Defense Information Systems Agency, the Security Technical Implementation Guide (STIG) Home Page.
http://iase.disa.mil
35. Defense Information Systems Agency, DoD Cloud Services Support website. http://disa.mil/Services/DoD-
Cloud-Broker
 Appendix B Definitions

Authenticity: The property of being genuine and being able to be verified and trusted; confidence in the validity of
a transmission, a message, or message originator.

Availability: The property of being accessible and useable upon demand by an authorized entity.

Classified Data: Information that has been determined: (i) pursuant to Executive Order 12958 as amended by
Executive Order 13292, or any predecessor Order, to be classified national security information; or (ii) pursuant to
the Atomic Energy Act of 1954, as amended, to be Restricted Data (RD).

CNDSP: Computer Network Defense Service Provider

Federal Community Cloud: A multi-tenant cloud in which services are provided for the exclusive use of the DoD
and Federal Government organizations. Resources providing the cloud services must be dedicated to Federal
Government use and require physical separation from non-DoD/non-Federal customers.

Confidentiality: The property that information is not disclosed to system entities (users, processes, devices) unless
they have been authorized to access the information.

Infrastructure as a Service (IaaS): A cloud service model focused on providing infrastructure required to host a
workload; includes virtual machines, servers, storage, load, balancers, network, etc.

Integrity: The property whereby an entity has not been modified in an unauthorized manner.

JAB: Joint Authorization Board. The primary governance and decision-making body for the FedRAMP program.

Non-Repudiation: Assurance the sender of data is provided with proof of delivery and the recipient is provided
with proof of the sender's identity, so neither may later deny having processed the data.

Platform as a Service (PaaS): A cloud service model focused on providing a suite of environment capabilities that
enables the execution or development of applications; includes operating system, execution runtime, database, web
server, development tools, etc.

Private Cloud: Cloud in which services are provided for the exclusive use of the DoD; supporting multiple DoD
tenants or DoD sponsored tenants in the same cloud. The DoD maintains ultimate authority over the usage of the
cloud services, and any non-DoD use of services must be authorized and sponsored through the DoD. Resources
providing the cloud services must be dedicated to DoD use and have physical separation from resources not
dedicated to DoD use.

Restoration: The return of something to a former, original, normal, or unimpaired condition. Software as a Service
(SaaS): A cloud service model focused on providing the full suite of products and applications to provide a service;
includes email, virtual desktop, communication, applications, etc.
 Appendix C Roles and Responsibilities

Table 7 provides a summary of the major roles and responsibilities in implementation of the Cloud Computing SRG.

Table 7 - Roles and Responsibilities

Role Responsibility

DISA • Provide security requirements guidelines (SRGs) and

Security Technical Implementation Guidance (STIGs)
for DoD cloud computing
• Assess CSP’s Service Offerings and 3PAO results for
consideration in awarding a DOD Provisional
Authorization
• Issue DoD Provisional Authorizations
• Develop and maintain a DoD Cloud Access Point
(CAP).
• Provide DoDIN Computer Network Defense (CND)
capabilities and maintain a CND concept of operations
(CONOPS).
• Provide technical support for the DoD CIO's role on
the FedRAMP Joint Authorization Board
• Provide a catalog of DoD cloud services .
• Maintain a registry of DoD Components using
commercial cloud services.
• Support the DoDIN Waiver Process.
• Receives CSP's continuous monitoring products and
passes them to the appropriate entities within DoD
• Serve as the DoD CNDSP certifier

Cloud Service • Commercial vendor or Federal organization offering or

Provider (CSP) providing cloud services (Includes DoD CSPs)
• Provides Cloud Service Offerings for mission use
• Provides CNDSP services (all tiers) for their
infrastructure and service offerings

Cloud Access Point • Provided by DISA or other DoD Component

(CAP) • Protect DoD missions from vulnerabilities or risk that
may affect operations in a CSP environment
• Provide perimeter defenses and sensing for
applications hosted in the commercial cloud service

DoD Chief • Official approving authority for all CAPs

Information Officer
(DoD CIO)

FedRAMP Joint • Reviews CSP security assessment packages under the

Authorization Board FedRAMP program
(JAB) • Grants FedRAMP Provisional Authorizations
Third Party • Independently performs security assessments of a CSP
Assessment cloud offering and creates security assessment package
Organizations artifacts in accordance with FedRAMP requirements
(3PAO) • May perform continuous monitoring of CSP systems
• Independently assesses a CSP’s compliance to DoD
FedRAMP+ security controls and other requirements

DISA Authorizing • Official approving PA for a CSP’s Service Offerings

Official (AO) for DoD use

DISA CND • Perform cross-CAP correlation and analysis of

Functions event/data.
• Direct C2 actions regarding DoDIN-wide incident and
system health reporting involving a CAP or CSP.
• For DoDIN-wide incidents, establish and maintain
external communications with the CSP and ensure
internal DoD communications are established between
all entities which include the MCND and BCND.
• Interface with US-CERT to obtain relevant CSP
information; ensures cross-sharing of information
across all BCND/MCND entities.

DoD Component • Official approving ATOs for Mission Owner’s

Authorizing Official systems/applications
(AO) • Reviews PA documentation to understand residual risk

Mission Owner • DoD entity that acquires cloud services in support of

(CSP’s DoD Cloud its mission
Customer DoD • Performs assessment to issue ATO for their mission
Cloud Consumer) systems/applications
• Ensures Tier 2 Mission Computer Network Defense
(MCND) Service Provider is identified and funded
• Serves as CND Tier 3 for their mission
systems/applications
• Ensures CSP requirements for CND and other SRG
requirements are included in any cloud contracts

Department of • Receives incident reports from CSP as mandated by

Homeland Security FedRAMP.
(DHS) United States • Responsible for coordination across non-DoD agencies
Computer
Emergency
Readiness Team
(US-CERT)

Computer Network • Provides Computer Network Defense (CND) services

Defense Service and Command and Control (C2) direction addressing
Provider (CNDSP) the protection of the network, detection of threats, and
 response to incidents.

United States Cyber • Notify and Coordinate as appropriate with US-CERT,

Command Intelligence Community, Law Enforcement, and other
(USCYBERCOM) / Federal Agencies
JFHQ-DODIN • Provides Computer Network Defense (CND) services
and Command and Control (C2) direction for the
entire DoDIN and all DoD information systems
• DoD Tier 1
CNDSP

Boundary CND • Monitors and defends the connections to/from off-

(BCND) premises CSPs at the Cloud Access Point (CAP)
• Provides cross-CSP analysis capabilities or entities
• DoD Tier 2 • Communicates with CND Tier 1 and Tier 2 entities
CNDSP

Mission CND • Provides CND / C2 services to specific Mission

(MCND) Owner’s systems/applications and virtual networks
• Serves as the DoD CND / C2 point of contact for the
CSP
• DoD Tier 2
CNDSP • Communicates with CND Tier 2 and Tier 3 entities

Appendix D Parameter Values

Table 8 provides a listing of the FedRAMP and FedRAMP+ controls / control enhancements that require values.
Both DoD RMF and FedRAMP values are provided along with the FedRAMP Additional Requirements and
Guidance. These are provided in the format used by the originator. The purpose is to provide a comparison between
the DoD and FedRAMP values and to provide the FedRAMP Additional Requirements and Guidance for use by
DoD assessors and CSPs. All CSPs are to be assessed IAW the same set of C/CEs and values. Unless otherwise
specified, for all Commercial CSPs, the DoD RMF value takes precedence unless the FedRAMP value is more
stringent. The full control / control enhancement text is included to provide full context for the value being
addressed.

NOTE: For parameter values tagged as "Not appropriate for DoD to define for all CSP's infrastructure or service
offerings." The CSP must provide details on how this control / control enhancement is met to include its values in
the SSP for the DoD AO to approve.

Table 8 - Control / Enhancement Parameter Values

Control/Enhancement text Value

AC-1; ACCESS CONTROL; Access AC-1

Control Policy And Procedures: a. all personnel
b. Annually
The organization:
a. Develops, documents, and Source:
disseminates to DoD RMF TAG
[Assignment: organization-defined -------------------
personnel or roles]:
1. An access control policy that AC-1.b.1 [at least every 3 years]
addresses purpose, scope, roles, AC-1.b.2 [at least annually]
responsibilities, management
commitment, Source:
coordination among organizational FedRAMP v2
entities, and compliance; and -------------------
2. Procedures to facilitate the
implementation of the access control
policy and associated access controls;
and
b. Reviews and updates the current:
1. Access control policy
[Assignment: organization-defined
frequency];
and
2. Access control procedures
[Assignment: organization-defined
frequency].

References: NIST Special Publications

800-12, 800-100.
AC-2; ACCESS CONTROL; Account AC-2
Management: a. Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
The organization:
a. Identifies and selects the following e. ISSM or ISSO
types of information system accounts to
support organizational missions/business f. Not appropriate for DoD to define for all CSP's
functions: infrastructure or service offerings
[Assignment: organization-defined
information system account types]; j. at a minimum, annually
b. Assigns account managers for
information system accounts; Source:
c. Establishes conditions for group and DoD RMF TAG
role membership; -------------------
d. Specifies authorized users of the
information system, group and role AC-2j [at least annually]
membership, and access authorizations
(i.e., privileges) and other attributes (as Source:
required) for each account; FedRAMP v2
e. Requires approvals by -------------------
[Assignment: organization-defined
personnel or roles]
for requests to create information system
accounts;
f. Creates, enables, modifies, disables,
and removes information system
accounts in accordance with
[Assignment: organization-defined
procedures or conditions];
g. Monitors the use of, information
system accounts;
h. Notifies account managers:
1. When accounts are no longer
required;
2. When users are terminated or
transferred; and
3. When individual information system
usage or need-to-know changes;
i. Authorizes access to the information
system based on:
1. A valid access authorization;
2. Intended system usage; and
3. Other attributes as required by the
organization or associated
missions/business functions;
j. Reviews accounts for compliance with
account management requirements
[Assignment: organization-defined
frequency]; and
k. Establishes a process for reissuing
shared/group account credentials (if
deployed) when individuals are removed
from the group.

References: None.
AC-2 (2); ACCESS CONTROL; AC-2 (2)
Account Management - Enhancement: For temporary user accounts: 72 hours
Removal Of Temporary Emergency
Accounts For emergency admin accounts: never (see supplemental
recommendation)
The information system automatically
[Selection: Source:
- removes; DoD RMF TAG
- disables -------------------
]
temporary and emergency accounts after [No more than 30 days for temporary and emergency
[Assignment: organization-defined account types]
time period for each type of account].
Source:
References: None. FedRAMP v2
-------------------
AC-2 (3); ACCESS CONTROL; AC-2 (3)
Account Management - Enhancement: 35 days
Disable Inactive Accounts
Source:
The information system automatically DoD RMF TAG
disables inactive accounts after -------------------
[Assignment: organization-defined
time period]. [90 days for user accounts]

References: None. Source:

FedRAMP v2
-------------------

FedRAMP Additional Requirements and Guidance:


AC-2 (4); ACCESS CONTROL;
Account Management - Enhancement:
Automated Audit Actions
The information system automatically
audits account creation, modification,
enabling, disabling, and removal actions,
and notifies
[Assignment: organization-defined
personnel or roles].
Requirement: The service provider defines the time period
for non-user accounts (e.g., accounts associated with
devices). The time periods are approved and accepted by
the Authorizing Official.
AC-2 (4)
System administrator and ISSO
Source:
DoD RMF TAG
-------------------

References: None.
AC-2 (5); ACCESS CONTROL; AC-2 (5)
Account Management - Enhancement: At the end of the users standard work period unless
Inactivity Logout otherwise defined in formal organizational policy.

The organization requires that users log Source:

out when DoD RMF TAG
[Assignment: organization-defined -------------------
time-period of expected inactivity or
description of when to log out].

References: None.
AC-2 (7); ACCESS CONTROL; AC-2 (7)
Account Management - Enhancement: c. Disables (or revokes) privileged user account
Role-Based Schemes
Source:
The organization: DoD RMF TAG
(a) Establishes and administers privileged -------------------
user accounts in accordance with a role-
based access scheme that organizes
allowed information system access and
privileges into roles;
(b) Monitors privileged role assignments;
and
(c) Takes
[Assignment: organization-defined
actions]
when privileged role assignments are no
longer appropriate.

References: None.
AC-2 (9); ACCESS CONTROL; AC-2 (9)
Account Management - Enhancement: Not appropriate for DoD to define for all CSP's
Restrictions On Use Of Shared Groups / infrastructure or service offerings
Accounts
Source:
The organization only permits the use of DoD RMF TAG
shared/group accounts that meet -------------------
[Assignment: organization-defined
conditions for establishing FedRAMP Additional Requirements and Guidance:
shared/group accounts]. Required if shared/group accounts are deployed

References: None.
AC-2 (12); ACCESS CONTROL; AC-2 (12)
Account Management - Enhancement: a. Not appropriate for DoD to define for all CSP's
Account Monitoring /Atypical Usage infrastructure or service offerings

The organization: b. at a minimum, the ISSO

(a) Monitors information system
accounts for Source:
[Assignment: organization-defined DoD RMF TAG
atypical use]; -------------------
and
(b) Reports atypical usage of information FedRAMP Additional Requirements and Guidance:
system accounts to AC-2 (12)(a) and AC-2 (12)(b) Additional FedRAMP
[Assignment: organization-defined Requirements and Guidance: Required for privileged
personnel or roles]. accounts.

References: None.
AC-2 (13); ACCESS CONTROL; AC-2 (13)
Account Management - Enhancement: 30 minutes unless otherwise defined in formal
Disable Accounts For High-Risk organizational policy
Individuals
Source:
The organization disables accounts of DoD RMF TAG
users posing a significant risk within -------------------
[Assignment: organization-defined
time period]
of discovery of the risk.

References: None.
AC-3 (4); ACCESS CONTROL; Access AC-3 (4)
Enforcement - Enhancement: Not appropriate for DoD to define for all CSP's
Discretionary Access Control infrastructure or service offerings

The information system enforces Source:

[Assignment: organization-defined DoD RMF TAG
discretionary access control policies] -------------------
over defined subjects and objects where
the policy specifies that a subject that has
been granted access to information can
do one or more of the following:
(a) Pass the information to any other
subjects or objects;
(b) Grant its privileges to other subjects;
(c) Change security attributes on
subjects, objects, the information system,
or the information system's components;
(d) Choose the security attributes to be
associated with newly created or revised
objects; or
(e) Change the rules governing access
control.
References: None.
AC-4; ACCESS CONTROL; AC-4
Information Flow Enforcement: Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
The information system enforces
approved authorizations for controlling Source:
the flow of information within the system DoD RMF TAG
and between interconnected systems -------------------
based on
[Assignment: organization-defined
information flow control policies].

References: Web: ucdmo.gov

AC-4 (21); ACCESS CONTROL; AC-4 (21)
Information Flow Enforcement - Not appropriate for DoD to define for all CSP's
Enhancement: infrastructure or service offerings
Physical / Logical Separation Of
Information Flows Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
The information system separates
information flows logically or physically Source:
using DoD RMF TAG
[Assignment: organization-defined -------------------
mechanisms and/or techniques]
to accomplish
[Assignment: organization-defined
required separations by types of
information].

References: None.
AC-5; ACCESS CONTROL; Separation AC-5
Of Duties: a. Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
The organization:
a. Separates Source:
[Assignment: organization-defined DoD RMF TAG
duties of individuals]; -------------------
b. Documents separation of duties of
individuals; and
c. Defines information system access
authorizations to support separation of
duties.

References: None.
AC-6 (1); ACCESS CONTROL; Least AC-6 (1)
Privilege - Enhancement: all functions not publicly accessible and all security-
Authorize Access To Security Functions relevant information not publicly available

The organization explicitly authorizes Source:

access to DoD RMF TAG
[Assignment: organization-defined -------------------
security functions (deployed in
hardware, software, and firmware)
and security-relevant information].

References: None.
AC-6 (2); ACCESS CONTROL; Least AC-6 (2)
Privilege - Enhancement: any privileged security functions or security-relevant
Non-Privileged Access For Nonsecurity information
Functions
Source:
The organization requires that users of DoD RMF TAG
information system accounts, or roles, -------------------
with access to
[Assignment: organization-defined [all security functions]
security functions or security-relevant
information], Source:
use non-privileged accounts, or roles, FedRAMP v2
when accessing nonsecurity functions. -------------------

References: None. FedRAMP Additional Requirements and Guidance:

AC-6 (5); ACCESS CONTROL; Least
Privilege - Enhancement:
Privileged Accounts
AC-6 (2). Guidance: Examples of security functions
include but are not limited to: establishing system
accounts, configuring access authorizations (i.e.,
permissions, privileges), setting events to be audited, and
setting intrusion detection parameters, system
programming, system and security administration, other
privileged functions.
AC-6 (5)
Not appropriate for DoD to define for all CSP's
infrastructure or service offerings

The organization restricts privileged Source:

accounts on the information system to DoD RMF TAG
[Assignment: organization-defined -------------------
personnel or roles].

References: None.
AC-6 (7); ACCESS CONTROL; Least AC-6 (7)
Privilege - Enhancement: a. at a minimum, annually
Review Of User Privileges
a. all users
The organization:
(a) Reviews Source:
[Assignment: organization-defined DoD RMF TAG
frequency] -------------------
the privileges assigned to
[Assignment: organization-defined
roles or classes of users]
to validate the need for such privileges;
and
(b) Reassigns or removes privileges, if
necessary, to correctly reflect
organizational mission/business needs.

References: None.
AC-6 (8); ACCESS CONTROL; Least AC-6 (8)
Privilege - Enhancement: any software except software explicitly documented
Privilege Levels For Code Execution
Source:
The information system prevents DoD RMF TAG
[Assignment: organization-defined -------------------
software]
from executing at higher privilege levels
than users executing the software.

References: None.
AC-7; ACCESS CONTROL; AC-7
Unsuccessful Login Attempts: a(1). Three
a(2). 15 minutes
The information system: b(1). locks the account/node
a. Enforces a limit of b(2). Until released by an administrator
[Assignment: organization-defined b(3). Minimum of 5 seconds
number]
consecutive invalid login attempts by a Source:
user during a DoD RMF TAG
[Assignment: organization-defined -------------------
time period];
and AC-7a [not more than three]
b. Automatically [fifteen minutes]
[Selection:
- locks the account/node for an AC-7b [locks the account/node for thirty minutes]
[Assignment: organization-defined
time period]; Source:
- locks the account/node until FedRAMP v2
released by an administrator; -------------------
- delays next login prompt
according to
[Assignment: organization-defined
delay algorithm]
]
when the maximum number of
unsuccessful attempts is exceeded.

References: None.
AC-8; ACCESS CONTROL; System
Use Notification:
The information system:
a. Displays to users
[Assignment: organization-defined
system use notification message or
banner]
before granting access to the system that
provides privacy and security notices
consistent with applicable federal laws,
Executive Orders, directives, policies,
regulations, standards, and guidance and
states that:
1. Users are accessing a U.S.
Government information system;
AC-8
a. The content of DTM 08-060, "Policy on Use of
Department of Defense (DoD) Information Systems
– Standard Consent Banner and User
Agreement," March 2013
c. The content of DTM 08-060, "Policy on Use of
Department of Defense (DoD) Information Systems
– Standard Consent Banner and User
Agreement," March 2013
Source:
DoD RMF TAG
-------------------
Parameter: See Additional Requirements and Guidance.
 2. Information system usage may be
monitored, recorded, and subject to audit;
3. Unauthorized use of the information
system is prohibited and subject to
criminal and civil penalties; and
4. Use of the information system
indicates consent to monitoring and
recording;
b. Retains the notification message or
banner on the screen until users
acknowledge the usage conditions and
take explicit actions to log on to or
further access the information system;
and
c. For publicly accessible systems:
1. Displays system use information
[Assignment: organization-defined
conditions],
before granting further access;
2. Displays references, if any, to
monitoring, recording, or auditing that
are consistent with privacy
accommodations for such systems that
generally prohibit those activities; and
3. Includes a description of the
authorized uses of the system.
References: None.
AC-10; ACCESS CONTROL;
Concurrent Session Control:
The information system limits the
number of concurrent sessions for each
[Assignment: organization-defined
account and/or account type]
to
[Assignment: organization-defined
number].
References: None.
AC-11; ACCESS CONTROL; Session
Lock:
The information system:
a. Prevents further access to the system
by initiating a session lock after
[Assignment: organization-defined
time period]
of inactivity or upon receiving a request
from a user; and
Source:
FedRAMP v2
-------------------
FedRAMP Additional Requirements and Guidance:
Requirement: The service provider shall determine
elements of the cloud environment that require the System
Use Notification control. The elements of the cloud
environment that require System Use Notification are
approved and accepted by the Authorizing Official (AO).
Requirement: The service provider shall determine how
System Use Notification is going to be verified and
provide appropriate periodicity of the check. The System
Use Notification verification and periodicity are approved
and accepted by the AO.
Guidance: If performed as part of a Configuration
Baseline check, then the % of items requiring setting that
are checked and that pass (or fail) check can be provided.
Requirement: If not performed as part of a Configuration
Baseline check, then there must be documented agreement
on how to provide results of verification and the necessary
periodicity of the verification by the service provider. The
documented agreement on how to provide verification of
the results are approved and accepted by the AO.
AC-10
all account types and/or accounts
Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
Source:
DoD RMF TAG
-------------------
[three (3) sessions for privileged access and two (2)
sessions for non-privileged access]
Source:
FedRAMP v2
-------------------
AC-11
a. 15 minutes
Source:
DoD RMF TAG
-------------------
AC-11a. [fifteen minutes]
Source:
b. Retains the session lock until the user FedRAMP v2
reestablishes access using established -------------------
identification and authentication
procedures.

References: OMB Memorandum 06-16.

AC-12; ACCESS CONTROL; Session AC-12
Termination: Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
The information system automatically
terminates a user session after Source:
[Assignment: organization-defined DoD RMF TAG
conditions or trigger events requiring -------------------
session disconnect].

References: None.
AC-12 (1); ACCESS CONTROL; AC-12 (1)
Session Termination - Enhancement: a. all
User-Initiated Logouts / Message
Displays Source:
DoD RMF TAG
The information system: -------------------
(a) Provides a logout capability for user-
initiated communications sessions
whenever authentication is used to gain
access to
[Assignment: organization-defined
information resources];
and
(b) Displays an explicit logout message
to users indicating the reliable
termination of authenticated
communications sessions.

References: None.
AC-14; ACCESS CONTROL; Permitted AC-14
Actions Without Identification Or a. Not appropriate for DoD to define for all CSP's
Authentication: infrastructure or service offerings

The organization: Source:

a. Identifies DoD RMF TAG
[Assignment: organization-defined -------------------
user actions]
that can be performed on the information
system without identification or
authentication consistent with
organizational missions/business
functions; and
b. Documents and provides supporting
rationale in the security plan for the
information system, user actions not
requiring identification or authentication.

References: None.
AC-16; ACCESS CONTROL; Security AC-16
Attributes: a. Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
The organization:
a. Provides the means to associate a. Not appropriate for DoD to define for all CSP's
[Assignment: organization-defined infrastructure or service offerings
types of security attributes]
having c. security attributes defined in AC-16, CCIs 2256-2258
[Assignment: organization-defined
security attribute values] c. all information systems
with information in storage, in process,
and/or in transmission; d. the values defined in AC-16, CCIs 2259-2261
b. Ensures that the security attribute
associations are made and retained with Source:
the information; DoD RMF TAG
c. Establishes the permitted -------------------
[Assignment: organization-defined
security attributes]
for
[Assignment: organization-defined
information systems];
and
d. Determines the permitted
[Assignment: organization-defined
values or ranges]
for each of the established security
attributes.

References: None.
AC-16 (6); ACCESS CONTROL; AC-16 (6)
Security Attributes - Enhancement: Not appropriate for DoD to define for all CSP's
Maintenance Of Attribute Association By infrastructure or service offerings
Organization
Not appropriate for DoD to define for all CSP's
The organization allows personnel to infrastructure or service offerings
associate, and maintain the association of
[Assignment: organization-defined Not appropriate for DoD to define for all CSP's
security attributes] infrastructure or service offerings
with
[Assignment: organization-defined Source:
subjects and objects] DoD RMF TAG
in accordance with -------------------
[Assignment: organization-defined
security policies].

References: None.
AC-17 (3); ACCESS CONTROL; AC-17 (3)
Remote Access - Enhancement: Not appropriate for DoD to define for all CSP's
Managed Access Control Points infrastructure or service offerings

The information system routes all remote Source:

accesses through [Assignment: DoD RMF TAG
organization-defined number] -------------------
managed network access control points.
References: None.
AC-17 (4); ACCESS CONTROL; AC-17 (4)
Remote Access - Enhancement: a. Not appropriate for DoD to define for all CSP's
Privileged Commands / Access infrastructure or service offerings

The organization: Source:

(a) Authorizes the execution of DoD RMF TAG
privileged commands and access to -------------------
security-relevant information via remote
access only for
[Assignment: organization-defined
needs];
and
(b) Documents the rationale for such
access in the security plan for the
information system.

References: None.
AC-17 (9); ACCESS CONTROL; AC-17 (9)
Remote Access - Enhancement: immediately
Disconnect / Disable Access
Source:
The organization provides the capability DoD RMF TAG
to expeditiously disconnect or disable -------------------
remote access to the information system
within [no greater than 15 minutes]
[Assignment: organization-defined
time period]. Source:
FedRAMP v2
References: None. -------------------
AC-19 (5); ACCESS CONTROL; AC-19 (5)
Access Control For Mobile Devices - Not appropriate for DoD to define for all CSP's
Enhancement: infrastructure or service offerings
Full Device / Container- Based
Encryption Source:
DoD RMF TAG
The organization employs -------------------
[Selection:
- full-device encryption;
- container encryption
]
to protect the confidentiality and integrity
of information on
[Assignment: organization-defined
mobile devices].

References: None.
AC-21; ACCESS CONTROL; User- AC-21
Based Collaboration And Information a. Not appropriate for DoD to define for all CSP's
Sharing RENAMED: Information infrastructure or service offerings
Sharing:
b. Not appropriate for DoD to define for all CSP's
The organization: infrastructure or service offerings
a. Facilitates information sharing by
enabling authorized users to determine Source:
whether access authorizations assigned to DoD RMF TAG
the sharing partner match the access -------------------
restrictions on the information for
[Assignment: organization-defined
information sharing circumstances
where user discretion is required];
and
b. Employs
[Assignment: organization-defined
automated mechanisms or manual
processes]
to assist users in making information
sharing/collaboration decisions.

References: None.
AC-22; ACCESS CONTROL; Publicly AC-22
Accessible Content: d. Every 90 days or as new information is posted

The organization: Source:

a. Designates individuals authorized to DoD RMF TAG
post information onto a publicly -------------------
accessible information system;
b. Trains authorized individuals to ensure AC-22d. [at least quarterly]
that publicly accessible information does
not contain nonpublic information; Source:
c. Reviews the proposed content of FedRAMP v2
information prior to posting onto the -------------------
publicly accessible information system to
ensure that nonpublic information is not
included; and
d. Reviews the content on the publicly
accessible information system for
nonpublic information
[Assignment: organization-defined
frequency]
and removes such information, if
discovered.

References: None.
AC-23; ACCESS CONTROL; Data
Mining Protection:
The organization employs
[Assignment: organization-defined
data mining prevention and detection
techniques]
for
[Assignment: organization-defined
data storage objects]
to adequately detect and protect against
data mining.
AC-23
Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
Source:
DoD RMF TAG
-------------------
References: None.
AT-1; AWARENESS AND TRAINING AT-1
; Security Awareness And Training a. all personnel
Policy And Procedures:
b. (1) every 5 years
The organization: b. (2) annually
a. Develops, documents, and
disseminates to Source:
[Assignment: organization-defined DoD RMF TAG
personnel or roles]: -------------------
1. A security awareness and training
policy that addresses purpose, scope, AT-1.b.1 [at least every 3 years]
roles, responsibilities, management AT-1.b.2 [at least annually]
commitment, coordination among
organizational entities, and compliance; Source:
and FedRAMP v2
2. Procedures to facilitate the -------------------
implementation of the security awareness
and training policy and associated
security awareness and training controls;
and
b. Reviews and updates the current:
1. Security awareness and training
policy
[Assignment: organization-defined
frequency];
and
2. Security awareness and training
procedures
[Assignment: organization-defined
frequency].

References: NIST Special Publications

800-12, 800-16, 800-50, 800-100.
AT-2; AWARENESS AND TRAINING AT-2
; Security Awareness c. annually
RENAMED: Security Awareness
Training: Source:
DoD RMF TAG
The organization provides basic security -------------------
awareness training to information system
users (including managers, senior AT-2. [Assignment: organization-defined frequency]
executives, and contractors):
a. As part of initial training for new Parameter: [at least annually]
users;
b. When required by information system Source:
changes; and FedRAMP v2
c. [Assignment: organization-defined -------------------
frequency]
thereafter.

References: C.F.R. Part 5 Subpart C (5

C.F.R 930.301); NIST Special
Publication 800-50.
AT-3; AWARENESS AND TRAINING AT-3
; Security Training RENAMED: Role- c. annually
based Security Training:
Source:
The organization provides role-based DoD RMF TAG
security training to personnel with -------------------
assigned security roles and
responsibilities: AT-3c. [Assignment: organization-defined frequency]
a. Before authorizing access to the
information system or performing Parameter: [at least annually]
assigned duties;
b. When required by information system Source:
changes; and FedRAMP v2
c. [Assignment: organization-defined -------------------
frequency]
thereafter.

References: C.F.R. Part 5 Subpart C (5

C.F.R 930.301); NIST Special
Publications 800-16, 800-50.
AT-3 (2); AWARENESS AND AT-3 (2)
TRAINING ; Security Training Not appropriate for DoD to define for all CSP's
RENAMED: Role-based Security infrastructure or service offerings
Training - Enhancement:
Physical Security Controls Annual

The organization provides Source:

[Assignment: organization-defined DoD RMF TAG
personnel or roles] -------------------
with initial and
[Assignment: organization-defined
frequency]
training in the employment and operation
of physical security controls.

References: None.
AT-3 (4); AWARENESS AND AT-3 (4)
TRAINING; Role-based Security Not appropriate for DoD to define for all CSP's
Training - Enhancement: infrastructure or service offerings
Suspicious Communications And
Anomalous System Behavior Source:
DoD RMF TAG
The organization provides training to its -------------------
personnel on
[Assignment: organization-defined
indicators of malicious code]
to recognize suspicious communications
and anomalous behavior in
organizational information systems.

References: None.
AT-4; AWARENESS AND TRAINING AT-4
; Security Training Records: b. at least 5 years or 5 years after completion of a specific
training program
The organization:
a. Documents and monitors individual Source:
information system security training DoD RMF TAG
activities including basic security -------------------
awareness training and specific
information system security training; and AT-4b. [Assignment: organization-defined frequency]
b. Retains individual training records for
[Assignment: organization-defined Parameter: [At least one years]
time period].
Source:
References: None. FedRAMP v2
-------------------
AU-1; AUDIT AND AU-1
ACCOUNTABILITY; Audit And a. the ISSO and ISSM and others as the local organization
Accountability Policy And Procedures: deems appropriate
b. 1. Annually
The organization: b. 2. Annually
a. Develops, documents, and
disseminates to Source:
[Assignment: organization-defined DoD RMF TAG
personnel or roles]: -------------------
1. An audit and accountability policy
that addresses purpose, scope, roles, AU-1.b.1 [at least every 3 years]
responsibilities, management AU-1.b.2 [at least annually]
commitment, coordination among
organizational entities, and compliance; Source:
and FedRAMP v2
2. Procedures to facilitate the -------------------
implementation of the audit and
accountability policy and associated audit
and accountability controls;
and
b. Reviews and updates the current:
1. Audit and accountability policy
[Assignment: organization-defined
frequency];
and
2. Audit and accountability procedures
[Assignment: organization-defined
frequency].

References: NIST Special Publications

800-12, 800-100.
AU-2; AUDIT AND AU-2
ACCOUNTABILITY; Auditable Events: a. Successful and unsuccessful attempts to access, modify,
or delete privileges, security objects, security levels, or
The organization: categories of information (e.g. classification levels).
a. Determines that the information Successful and unsuccessful logon attempts, Privileged
system is capable of auditing the activities or other system level access, Starting and ending
following events: time for user access to the system, Concurrent logons from
[Assignment: organization-defined different workstations, Successful and unsuccessful
auditable events]; accesses to objects, All program initiations, All direct
b. Coordinates the security audit function access to the information system. All account creations,
with other organizational entities modifications, disabling, and terminations. All kernel
requiring audit-related information to
enhance mutual support and to help guide
the selection of auditable events;
c. Provides a rationale for why the
auditable events are deemed to be
adequate to support after-the-fact
investigations of security incidents; and
d. Determines that the following events
are to be audited within the information
system:
[Assignment: organization-defined
audited events (the subset of the
auditable events defined in AU-2 a.)
along with the frequency of (or
situation requiring) auditing for each
identified event].
References: NIST Special Publication
800-92; Web:
CSRC.NIST.GOV/PCIG/CIG.HTML,
IDMANAGEMENT.GOV
AU-2 (3); AUDIT AND
ACCOUNTABILITY; Auditable Events Annually and based on situational awareness of threats,
- Enhancement:
Reviews And Updates
The organization reviews and updates the DoD RMF TAG
audited events
[Assignment: organization-defined
frequency].
References: None.
AU-3 (1); AUDIT AND
ACCOUNTABILITY; Content Of Audit
Records - Enhancement:
Additional Audit Information
The information system generates audit
records containing the following
[Assignment: organization-defined
module load, unload, and restart.
d. Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
d. all auditable events defined in AU-2 (a) per occurrence.
Source:
DoD RMF TAG
-------------------
AU-2a. [Successful and unsuccessful account logon
events, account management events, object access, policy
change, privilege functions, process tracking, and system
events. For Web applications: all administrator activity,
authentication checks, authorization checks, data
deletions, data access, data changes, and permission
changes];
AU-2d. [organization-defined subset of the auditable
events defined in AU-2 a. to be audited continually for
each identified event].
Source:
FedRAMP v2
-------------------
AU-2 (3)
vulnerabilities
Source:
-------------------
AU-2 (3). [Assignment: organization-defined frequency]
Parameter: [annually or whenever there is a change in the
threat environment]
Source:
FedRAMP v2
-------------------
FedRAMP Additional Requirements and Guidance:
Guidance: Annually or whenever changes in the threat
environment are communicated to the service provider by
the Authorizing Official.
AU-3 (1)
At a minimum, full-text recording of privileged
commands or the individual identities of group account
users.
Source:
DoD RMF TAG
-------------------
additional, more detailed information].
References: None.
AU-4; AUDIT AND
ACCOUNTABILITY; Audit Storage
Capacity:
The organization allocates audit record
storage capacity in accordance with
[Assignment: organization-defined
audit record storage requirements].
References: None.
AU-4 (1); AUDIT AND
ACCOUNTABILITY; Audit Storage
Capacity - Enhancement:
Transfer To Alternate Storage
The information system off-loads audit
records
[Assignment: organization-defined
frequency]
onto a different system or media than the
system being audited.
References: None.
AU-5; AUDIT AND
ACCOUNTABILITY; Response To
Audit Processing Failures:
The information system:
a. Alerts
[Assignment: organization-defined
personnel or roles]
in the event of an audit processing
failure; and
AU-3 (1). [Assignment: organization-defined additional,
more detailed information] Parameter: [session,
connection, transaction, or activity duration; for client-
server transactions, the number of bytes received and
bytes sent; additional informational messages to diagnose
or identify the event; characteristics that describe or
identify the object or resource being acted upon]
Source:
FedRAMP v2
-------------------
FedRAMP Additional Requirements and Guidance:
AU-3 (1). Requirement: The service provider defines audit
record types. The audit record types are approved and
accepted by the Authorizing Official.
Guidance: For client-server transactions, the number of
bytes sent and received gives bidirectional transfer
information that can be helpful during an investigation or
inquiry.
AU-4
Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
Source:
DoD RMF TAG
-------------------
AU-4 (1)
At a minimum, real-time for interconnected systems and
weekly for stand-alone systems
Source:
DoD RMF TAG
-------------------
AU-5
a. At a minimum, the SCA and ISSO
b. Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
Source:
DoD RMF TAG
-------------------
AU-5b. [Assignment: Organization-defined actions to be
b. Takes the following additional actions: taken]
[Assignment: organization-defined
actions to be taken (e.g., shut down Parameter: [low-impact: overwrite oldest audit records;
information system, overwrite oldest moderate-impact: shut down]
audit records, stop generating audit
records)]. Source:
FedRAMP v2
References: None. -------------------
AU-6; AUDIT AND AU-6
ACCOUNTABILITY; Audit Review, a. every seven days or more frequently if required by an
Analysis, And Reporting: alarm event or anomaly;
a. Not appropriate for DoD to define for all CSP's
The organization: infrastructure or service offerings;
a. Reviews and analyzes information b. at a minimum, the ISSO and ISSM
system audit records
[Assignment: organization-defined Source:
frequency] DoD RMF TAG
for indications of -------------------
[Assignment: organization-defined
inappropriate or unusual activity]; AU-6a. [Assignment: organization-defined frequency]
and
b. Reports findings to Parameter: [at least weekly]
[Assignment: organization-defined
personnel or roles]. Source:
FedRAMP v2
References: None. -------------------
AU-7 (1); AUDIT AND AU-7 (1)
ACCOUNTABILITY; Audit Reduction Not appropriate for DoD to define for all CSP's
And Report Generation - Enhancement: infrastructure or service offerings
Automatic Processing
Source:
The information system provides the DoD RMF TAG
capability to process audit records for -------------------
events of interest based on
[Assignment: organization-defined
audit fields within audit records].

References: None.
AU-8; AUDIT AND AU-8
ACCOUNTABILITY; Time Stamps: b. one second

The information system: Source:

a. Uses internal system clocks to generate DoD RMF TAG
time stamps for audit records; and -------------------
b. Records time stamps for audit records
that can be mapped to Coordinated
Universal Time (UTC) or Greenwich
Mean Time (GMT) and meets
[Assignment: organization-defined
granularity of time measurement].

References: None.
AU-8 (1); AUDIT AND AU-8 (1)
ACCOUNTABILITY; Protection Of a. Every 24 hours for networked systems;
Audit Information - Enhancement: a. an authoritative time server which is synchronized with
Synchronization With Authoritative redundant United States Naval Observatory (USNO) time
Time Source servers as designated for the appropriate DoD network
(NIPRNet / SIPRNet) and/or the Global Positioning
The information system: System (GPS);
a. Compares the internal information b. Greater than the organizationally defined granularity in
system clocks AU-8
[Assignment: organization-defined
frequency] Source:
with DoD RMF TAG
[Assignment: organization-defined -------------------
authoritative time source]
and; AU-8 (1). [http://tf.nist.gov/tf-cgi/servers.cgi] <At least
b. Synchronizes the internal system hourly>
clocks to the authoritative time source
when the time difference is greater than Source:
[Assignment: organization-defined FedRAMP v2
time period]. -------------------

References: None. FedRAMP Additional Requirements and Guidance:

AU-9 (2); AUDIT AND
ACCOUNTABILITY; Protection Of
Audit Information - Enhancement:
Audit Backup On Separate Physical
Systems / Components
The information system backs up audit
records
[Assignment: organization-defined
frequency]
onto a physically different system or
system component than the system or
component being audited.
AU-8 (1). Requirement: The service provider selects
primary and secondary time servers used by the NIST
Internet time service. The secondary server is selected
from a different geographic region than the primary
server.
Requirement: The service provider synchronizes the
system clocks of network computers that run operating
systems other than Windows to the Windows Server
Domain Controller emulator or to the same time source
for that server.
Guidance: Synchronization of system clocks improves the
accuracy of log analysis.
AU-9 (2)
every seven days
Source:
DoD RMF TAG
-------------------
AU-9 (2). [at least weekly]
Source:
FedRAMP v2
-------------------

References: None.
AU-9 (4); AUDIT AND AU-9 (4)
ACCOUNTABILITY; Protection Of Not appropriate for DoD to define for all CSP's
Audit Information - Enhancement: infrastructure or service offerings
Access By Subset Of Privileged Users
Source:
The organization authorizes access to DoD RMF TAG
management of audit functionality to -------------------
only
[Assignment: organization-defined
subset of privileged users].

References: None.
AU-10; AUDIT AND AU-10
ACCOUNTABILITY; Non-Repudiation: actions defined by DoDI 8520.02 and DoDI 8520.03

The information system protects against Source:

an individual (or process acting on behalf DoD RMF TAG
of an individual) falsely denying having -------------------
performed
[Assignment: organization-defined
actions to be covered by non-
repudiation].

References: None.
AU-11; AUDIT AND AU-11
ACCOUNTABILITY; Audit Record 5 years for SAMI; otherwise for at least 1 year
Retention:
Source:
The organization retains audit records for DoD RMF TAG
[Assignment: organization-defined -------------------
time period consistent with records
retention policy] AU-11. [at least ninety days]
to provide support for after-the-fact
investigations of security incidents and to Source:
meet regulatory and organizational FedRAMP v2
information retention requirements. -------------------

References: None. FedRAMP Additional Requirements and Guidance:

AU-11. Requirement: The service provider retains audit
records on-line for at least ninety days and further
preserves audit records off-line for a period that is in
accordance with NARA requirements.
AU-12; AUDIT AND AU-12
ACCOUNTABILITY; Audit Generation: a. all information system and network components;
b. ISSM or individuals appointed by the ISSM
The information system:
a. Provides audit record generation Source:
capability for the auditable events DoD RMF TAG
defined in AU-2 a. at -------------------
[Assignment: organization-defined
information system components]; AU-12a. [all information system and network components
b. Allows where audit capability is deployed/available]
[Assignment: organization-defined
personnel or roles] Source:
to select which auditable events are to be FedRAMP v2
audited by specific components of the -------------------
information system; and
c. Generates audit records for the events
defined in AU-2 d. with the content
defined in AU-3.
References: None.
AU-12 (1); AUDIT AND AU-12 (1)
ACCOUNTABILITY; Audit Generation Not appropriate for DoD to define for all CSP's
- Enhancement: infrastructure or service offerings;
System-Wide / Time-Correlated Audit
Trail The time tracking tolerance defined in AU-8

The information system compiles audit Source:

records from DoD RMF TAG
[Assignment: organization-defined -------------------
information system components]
into a system-wide (logical or physical)
audit trail that is time-correlated to within
[Assignment: organization-defined
level of tolerance for relationship
between time stamps of individual
records in the audit trail].

References: None.
AU-12 (3); AUDIT AND AU-12 (3)
ACCOUNTABILITY; Audit Generation Not appropriate for DoD to define for all CSP's
- Enhancement: infrastructure or service offerings;
Changes By Authorized Individuals
Not appropriate for DoD to define for all CSP's
The information system provides the infrastructure or service offerings;
capability for
[Assignment: organization-defined Not appropriate for DoD to define for all CSP's
individuals or roles] infrastructure or service offerings;
to change the auditing to be performed
on Not appropriate for DoD to define for all CSP's
[Assignment: organization-defined infrastructure or service offerings
information system components]
based on Source:
[Assignment: organization-defined DoD RMF TAG
selectable event criteria] -------------------
within
[Assignment: organization-defined
time thresholds].

References: None.
CA-1; SECURITY ASSESSMENT AND CA-1
AUTHORIZATION; Security a. all personnel
Assessment And Authorization Policies
And Procedures: b. (1) every 5 years
b. (2) annually
The organization:
a. Develops, documents, and Source:
disseminates to DoD RMF TAG
[Assignment: organization-defined -------------------
personnel or roles]:
1. A security assessment and CA-1.b.1 [at least every 3 years]
authorization policy that addresses CA-1.b.2 [at least annually]
purpose, scope, roles, responsibilities,
management commitment, coordination Source:
among organizational entities, and FedRAMP v2
compliance; and -------------------
2. Procedures to facilitate the
implementation of the security
assessment and authorization policy and
associated security assessment and
authorization controls;
and
b. Reviews and updates the current:
1. Security assessment and
authorization policy
[Assignment: organization-defined
frequency];
and
2. Security assessment and
authorization procedures
[Assignment: organization-defined
frequency].

References: NIST Special Publications

800-12, 800-37, 800-53A, 800-100.
CA-2; SECURITY ASSESSMENT AND CA-2
AUTHORIZATION; Security b. Annually for technical controls
Assessments: Annually for a portion of management and operational
controls such that all are reviewed in a 3 year period
The organization: except for those requiring more frequent review as defined
a. Develops a security assessment plan in other site or overarching policy. NOTE: Technical,
that describes the scope of the assessment Management and Operational is IAW NIST SP 800-53
including: Table 1-1.
1. Security controls and control
enhancements under assessment; d. at a minimum, the ISSO and ISSM
2. Assessment procedures to be used to
determine security control effectiveness; Source:
and DoD RMF TAG
3. Assessment environment, -------------------
assessment team, and assessment roles
and responsibilities; CA-2b. [at least annually]
b. Assesses the security controls in the CA-2d[individuals or roles to include FedRAMP PMO]
information system and its environment
of operation Source:
[Assignment: organization-defined FedRAMP v2
frequency] -------------------
to determine the extent to which the
controls are implemented correctly,
operating as intended, and producing the
desired outcome with respect to meeting
established security requirements;
c. Produces a security assessment report
that documents the results of the
assessment; and
d. Provides the results of the security
control assessment to
[Assignment: organization-defined
individuals or roles].
References: Executive Order 12587;
FIPS Publication 199; NIST Special
Publications 800-37, 800-39, 800-53A,
800-115, 800-137
CA-2 (1); SECURITY ASSESSMENT CA-2 (1)
AND AUTHORIZATION; Security Not appropriate for DoD to define for all CSP's
Assessments - Enhancement: infrastructure or service offerings
Independent Assessors
Source:
The organization employs assessors or DoD RMF TAG
assessment teams with -------------------
[Assignment: organization-defined
level of independence] Added to NIST Baseline for "Low" FedRAMP baseline.
to conduct security control assessments.
Source:
References: None. FedRAMP v2
-------------------

FedRAMP Additional Requirements and Guidance:

CA-2 (2); SECURITY ASSESSMENT
AND AUTHORIZATION; Security
Assessments - Enhancement:
Specialized Assessments
The organization includes as part of
security control assessments,
[Assignment: organization-defined
frequency],
[Selection:
- announced;
- unannounced
],
[Selection (one or more):
- in-depth monitoring;
- vulnerability scanning;
- malicious user testing;
- insider threat assessment;
- performance/load testing;
- [Assignment: organization-defined
other forms of security assessment]
].
References: None.
CA-2 (3); SECURITY ASSESSMENT
AND AUTHORIZATION; Security
Assessments - Enhancement:
External Organizations
The organization accepts the results of an infrastructure or service offerings
assessment of
[Assignment: organization-defined Not appropriate for DoD to define for all CSP's
information system]
For JAB Authorization, must be an accredited 3PAO
CA-2 (2)
annually
Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
Source:
DoD RMF TAG
-------------------
[at least annually]
Source:
FedRAMP v2
-------------------
FedRAMP Additional Requirements and Guidance:
Requirement: To include 'announced', 'vulnerability
scanning'
CA-2 (3)
Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
performed by
[Assignment: organization-defined Source:
external organization] DoD RMF TAG
when the assessment meets -------------------
[Assignment: organization-defined
requirements]. [Any FedRAMP Accredited 3PAO] [the conditions of a
PA in the FedRAMP Repository]
References: None.
Source:
FedRAMP v2
-------------------
CA-3; SECURITY ASSESSMENT AND CA-3
AUTHORIZATION; Information System c. at least annually
Connections RENAMED: System
Interconnections: Source:
DoD RMF TAG
The organization: -------------------
a. Authorizes connections from the
information system to other information CA-3c. 3 Years / Annually and on input from FedRAMP
systems through the use of
Interconnection Security Agreements; Source:
b. Documents, for each interconnection, FedRAMP v2
the interface characteristics, security -------------------
requirements, and the nature of the
information communicated; and
c. Reviews and updates Interconnection
Security Agreements
[Assignment: organization-defined
frequency].

References: FIPS Publication 199; NIST

Special Publication 800-47.
CA-3 (1); SECURITY ASSESSMENT CA-3 (1)
AND AUTHORIZATION; Information all unclassified NSS
System Connections RENAMED:
System Interconnections - Enhancement: Not appropriate for DoD to define for all CSP's
Unclassified National Security System infrastructure or service offerings
Connections
Source:
The organization prohibits the direct DoD RMF TAG
connection of an -------------------
[Assignment: organization-defined
unclassified, national security system]
to an external network without the use of
[Assignment: organization-defined
boundary protection device].

References: None.
CA-3 (3); SECURITY ASSESSMENT
AND AUTHORIZATION; System
Interconnections - Enhancement:
Unclassified Non-National Security
System Connections
CA-3 (3)
Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
The organization prohibits the direct
connection of an Source:
[Assignment: organization-defined DoD RMF TAG
unclassified, non-national security -------------------
system]
to an external network without the use of Boundary Protections which meet the Trusted Internet
[Assignment; organization-defined Connection (TIC) requirements
boundary protection device].
Source:
References: None. FedRAMP v2
-------------------

FedRAMP Additional Requirements and Guidance:

CA-3 (5); SECURITY ASSESSMENT
AND AUTHORIZATION; System
Interconnections - Enhancement:
Restrictions On External System
Connections
The organization employs
[Selection:
- allow-all,
- deny-by-exception;
- deny-all,
- permit-by-exception
]
policy for allowing
[Assignment: organization-defined
information systems] to connect to
external information systems.
CA-3(3) Guidance: Refer to Appendix H – Cloud
Considerations of the TIC 2.0 Reference Architecture
document.
CA-3 (5)
deny-all, permit by exception
any systems requiring external connectivity
Source:
DoD RMF TAG
-------------------
FedRAMP Additional Requirements and Guidance:
For JAB Authorization, CSPs shall include details of this
control in their Architecture Briefing

References: None.
CA-5; SECURITY ASSESSMENT AND CA-5
AUTHORIZATION; Plan Of Action b. At least every 90 days
And Milestones:
Source:
The organization: DoD RMF TAG
a. Develops a plan of action and -------------------
milestones for the information system to
document the organization’s planned CA-5b. [at least monthly]
remedial actions to correct weaknesses or
deficiencies noted during the assessment Source:
of the security controls and to reduce or FedRAMP v2
eliminate known vulnerabilities in the -------------------
system; and
b. Updates existing plan of action and FedRAMP Additional Requirements and Guidance:
milestones CA-5 Guidance: Requirement: POA&Ms must be
[Assignment: organization-defined provided at least monthly.
frequency]
based on the findings from security
controls assessments, security impact
analyses, and continuous monitoring
activities.

References: OMB Memorandum 02-01;

NIST Special Publication 800-37.
CA-6; SECURITY ASSESSMENT AND CA-6
AUTHORIZATION; Security c. at least every three years, whenever there is a significant
Authorization: change to the system, or if there is a change to the
environment in which the system operates.
The organization:
a. Assigns a senior-level executive or Source:
manager as the authorizing official for DoD RMF TAG
the information system; -------------------
b. Ensures that the authorizing official
authorizes the information system for CA-6c. [at least every three years or when a significant
processing before commencing change occurs]
operations; and
c. Updates the security authorization Source:
[Assignment: organization-defined FedRAMP v2
frequency]. -------------------

References: OMB Circular A-130; OMB FedRAMP Additional Requirements and Guidance:
Memorandum 11-33; NIST Special CA-6c. Guidance: Significant change is defined in NIST
Publication 800-37, 800-137. Special Publication 800-37 Revision 1, Appendix F. The
service provider describes the types of changes to the
information system or the environment of operations that
would impact the risk posture. The types of changes are
approved and accepted by the Authorizing Official.
CA-7; SECURITY ASSESSMENT AND CA-7
AUTHORIZATION; Continuous Future DoD-wide CM guidance to be published.
Monitoring:
Source:
The organization develops a continuous DoD RMF TAG
monitoring strategy and implements a -------------------
continuous monitoring program that
includes: CA-7d. [To meet Federal and FedRAMP requirements]
a. Establishment of
[Assignment: organization-defined Source:
metrics] FedRAMP v2
to be monitored; -------------------
b. Establishment of
[Assignment: organization-defined FedRAMP Additional Requirements and Guidance:
frequencies] Operating System Scans: at least monthly
for monitoring and Database and Web Application Scans: at least monthly
[Assignment: organization-defined All scans performed by Independent Assessor: at least
frequencies] annually
for assessments supporting such
monitoring; CA-7 Guidance: CSPs must provide evidence of closure
c. Ongoing security control assessments and remediation of high vulnerabilities within the
in accordance with the organizational timeframe for standard POA&M updates.
continuous monitoring strategy;
d. Ongoing security status monitoring of
organization-defined metrics in
accordance with the organizational
continuous monitoring strategy;
e. Correlation and analysis of security-
related information generated by
assessments and monitoring;
f. Response actions to address results of
the analysis of security-related
information; and
g. Reporting the security status of
organization and the information system
to
[Assignment: organization-defined
personnel or roles]
[Assignment: organization-defined
frequency].

References: OMG Memorandum 11-33;

NIST Special Publications 800-37 800-
39, 800-53A, 800-115, 800-137; US-
CERT Technical Cyber Security Alerts;
DoD Information Assurance
Vulnerability Alerts.
CA-7 (1); SECURITY ASSESSMENT CA-7 (1)
AND AUTHORIZATION; Continuous Future DoD-wide CM guidance to be published.
Monitoring - Enhancement:
Independent Assessment Source:
DoD RMF TAG
The organization employs assessors or -------------------
assessment teams with
[Assignment: organization-defined
level of independence]
to monitor the security controls in the
information system on an ongoing basis.

References: None.
CA-8; SECURITY ASSESSMENT AND CA-8
AUTHORIZATION; Penetration Not appropriate for DoD to define for all CSP's
Testing: infrastructure or service offerings

The organization conducts penetration Not appropriate for DoD to define for all CSP's
testing infrastructure or service offerings
[Assignment: organization-defined
frequency] Source:
on DoD RMF TAG
[Assignment: organization-defined -------------------
information systems or system
components]. [at least annually]

References: None. Source:

FedRAMP v2
-------------------
CA-9; SECURITY ASSESSMENT AND CA-9
AUTHORIZATION; Internal System a. Not appropriate for DoD to define for all CSP's
Connections: infrastructure or service offerings
The organization: Source:
a. Authorizes internal connections of DoD RMF TAG
[Assignment: organization-defined -------------------
information system components or
classes of components]
to the information system; and
b. Documents, for each internal
connection, the interface characteristics,
security requirements, and the nature of
the information communicated.

References: None.
CM-1; BASELINE CONFIGURATION; CM-1
Configuration Management Policy And a. all stakeholders in the configuration management
Procedures: process
b. 1. annually
The organization: b. 2. annually
a. Develops, documents, and
disseminates to Source:
[Assignment: organization-defined DoD RMF TAG
personnel or roles]: -------------------
1. A configuration management policy
that addresses purpose, scope, roles, CM-1.b.1 [at least every 3 years]
responsibilities, management CM-1.b.2 [at least annually]
commitment, coordination among
organizational entities, and compliance; Source:
and FedRAMP v2
2. Procedures to facilitate the -------------------
implementation of the configuration
management policy and associated
configuration management controls;
and
b. Reviews and updates the current:
1. Configuration management policy
[Assignment: organization-defined
frequency];
and
2. Configuration management
procedures
[Assignment: organization-defined
frequency].

References: NIST Special Publications

800-12, 800-100.
CM-2 (1); BASELINE CM-2 (1)
CONFIGURATION; Baseline a. annually;
Configuration - Enhancement: b. baseline configuration changes or as events dictate such
Reviews And Updates as changes due to USCYBERCOM tactical orders/
directives or cyber attacks.
The organization reviews and updates the
baseline configuration of the information Source:
system: DoD RMF TAG
(a) [Assignment: organization-defined -------------------
frequency];
(b) When required due to CM-2 (1) (a). [at least annually]
[Assignment organization-defined CM-2 (1) (b). [to include when directed by Authorizing
circumstances]; Official]
and
(c) As an integral part of information Source:
system component installations and FedRAMP v2
upgrades. -------------------

References: None.
CM-2 (3); BASELINE CM-2 (3)
CONFIGURATION; Baseline the previous approved baseline configuration of IS
Configuration - Enhancement: components for a minimum of 3 month
Retention Of Previous Configurations
Source:
The organization retains DoD RMF TAG
[Assignment: organization-defined -------------------
previous versions of baseline
configurations of the information
system]
to support rollback.

References: None.
CM-2 (7); CONFIGURATION CM-2 (7)
MANAGEMENT; Baseline a. Not appropriate for DoD to define for all CSP's
Configuration - Enhancement: infrastructure or service offerings;
Configure Systems, Components, Or a. Not appropriate for DoD to define for all CSP's
Devices For High-Risk Areas infrastructure or service offerings;
b. Not appropriate for DoD to define for all CSP's
The organization: infrastructure or service offerings
a. Issues
[Assignment: organization-defined Source:
information systems, system DoD RMF TAG
components, or devices] -------------------
with
[Assignment: organization-defined
configurations]
to individuals traveling to locations that
the organization deems to be of
significant risk; and
b. Applies
[Assignment: organization-defined
security safeguards]
to the devices when the individuals
return.

References: None.
CM-3; BASELINE CONFIGURATION; CM-3
Configuration Change Control: e. The time period should be defined at the organization's
CCB.
The organization: g. a configuration control board;
a. Determines the type of changes to the g. at a frequency determined by the CCB;
information system that are configuration g. configuration change conditions determined by the
controlled; CCB.
b. Reviews proposed configuration-
controlled changes to the information Source:
system and approves or disapproves such DoD RMF TAG
changes with explicit consideration for -------------------
security impact analyses;
c. Documents configuration change FedRAMP Additional Requirements and Guidance:
decisions associated with the information Requirement: The service provider establishes a central
system; means of communicating major changes to or
d. Implements approved configuration- developments in the information system or environment of
controlled changes to the information operations that may affect its services to the federal
system; government and associated service consumers (e.g.,
e. Retains records of configuration- electronic bulletin board, web status page). The means of
controlled changes to the information communication are approved and accepted by the
system for [Assignment: organization- Authorizing Official.
defined time period];
f. Audits and reviews activities CM-3e Guidance: In accordance with record retention
associated with configuration-controlled policies and procedures.
changes to the information system; and
g. Coordinates and provides oversight for
configuration change control activities
through
[Assignment: organization-defined
configuration change control element
(e.g., committee, board)]
that convenes
[Selection (one or more):
- [Assignment: organization-defined
frequency];
- [Assignment: organization-defined
configuration change conditions]
].

References: NIST Special Publication

800-128.
CM-3 (4); BASELINE CM-3 (4)
CONFIGURATION; Configuration configuration control board (CCB) (as defined in CM-3,
Change Control - Enhancement: CCI 1586)
Security Representative
Source:
The organization requires an information DoD RMF TAG
security representative to be a member of -------------------
the
[Assignment: organization-defined
configuration change control element].

References: None.
CM-3 (6); CONFIGURATION CM-3 (6)
MANAGEMENT; Configuration Change All security safeguards that rely on cryptography
Control - Enhancement:
Cryptography Management Source:
DoD RMF TAG
The organization ensures that CNSSI 1253
cryptographic mechanisms used to
provide
[Assignment: organization-defined
security safeguards]
are under configuration management.

References: None.
CM-5 (2); BASELINE CM-5 (2)
CONFIGURATION; Access Restrictions Every 90 days or more frequently as the organization
For Change - Enhancement: defines for high systems AND at least annually or more
Review System Changes frequently as the organization defines for low and
moderate systems;
The organization reviews information
system changes When there is an incident or when planned changes have
[Assignment: organization-defined been performed
frequency]
and Source:
[Assignment: organization-defined DoD RMF TAG
circumstances] -------------------
to determine whether unauthorized
changes have occurred.

References: None.
CM-5 (3); BASELINE CM-5 (3)
CONFIGURATION; Access Restrictions Any software or firmware components when the vendor
For Change - Enhancement: provides digitally signed products
Signed Components
Source:
The information system prevents the DoD RMF TAG
installation of -------------------
[Assignment: organization-defined
critical software and firmware FedRAMP Additional Requirements and Guidance:
components] Guidance: If digital signatures/certificates are unavailable,
without verification that the component alternative cryptographic integrity checks (hashes, self-
has been digitally signed using a signed certs, etc.) can be utilized.
certificate that is recognized and
approved by the organization.

References: None.
CM-5 (5); BASELINE CM-5 (5)
CONFIGURATION; Access Restrictions b. every 90 days
For Change - Enhancement:
Limit Production / Operational Privileges Source:
DoD RMF TAG
The organization: -------------------
(a) Limits privileges to change
information system components and CM-5 (5) (b). [at least quarterly]
system-related information within a
production or operational environment; Source:
and FedRAMP v2
(b) Reviews and reevaluates privileges -------------------
[Assignment: organization-defined
frequency].

References: None.
CM-6; BASELINE CONFIGURATION; CM-6
Configuration Settings: a. DoD security configuration or implementation guidance
 (e.g. STIGs, SRGs, NSA configuration guides, CTOs,
The organization: DTMs etc.).;
a. Establishes and documents c. All configurable information system components;
configuration settings for information c. Not appropriate for DoD to define for all CSP's
technology products employed within the infrastructure or service offerings;
information system using
[Assignment: organization-defined Source:
security configuration checklists] DoD RMF TAG
that reflect the most restrictive mode NOTE: DISA will evaluate Commercial CSP
consistent with operational requirements; equivalencies on a case by case basis.
b. Implements the configuration settings; -------------------
c. Identifies, documents, and approves
any deviations from established CM-6a. [See CM-6(a) Additional FedRAMP
configuration settings for Requirements and Guidance]
[Assignment: organization-defined
information system components] Source:
based on FedRAMP v2
[Assignment: organization-defined -------------------
operational requirements];
and FedRAMP Additional Requirements and Guidance:
d. Monitors and controls changes to the CM-6a. Requirement: The service provider shall use the
configuration settings in accordance with
Center for Internet Security guidelines (Level 1) to
organizational policies and procedures. establish configuration settings or establishes its own
configuration settings if USGCB is not available.
References: OMB Memoranda 07-11, CM-6a. Requirement: The service provider shall ensure
07-18, 08-22; NIST Special Publications that checklists for configuration settings are Security
800-70, 800-128; Web: nvd.nist.gov; Content Automation Protocol (SCAP) validated or SCAP
checklists.nist.gov; www.nsa.gov. compatible (if validated checklists are not available).
CM-6a. Guidance: Information on the USGCB checklists
can be found at:
http://usgcb.nist.gov/usgcb_faq.html#usgcbfaq_usgcbfdcc
.
CM-6 (1); BASELINE CM-6 (1)
CONFIGURATION; Configuration Not appropriate for DoD to define for all CSP's
Settings - Enhancement: infrastructure or service offerings
Automated Central Management /
Application / Verification Source:
DoD RMF TAG
The organization employs automated -------------------
mechanisms to centrally manage, apply,
and verify configuration settings for
[Assignment: organization-defined
information system components].

References: None.
CM-7; BASELINE CONFIGURATION; CM-7
Least Functionality: IAW DoDI 8551.01

The organization: Source:

a. Configures the information system to DoD RMF TAG
provide only essential capabilities; and -------------------
b. Prohibits or restricts the use of the
following functions, ports, protocols, CM-7. [United States Government Configuration Baseline
and/or services: (USGCB)]
 [Assignment: organization-defined
prohibited or restricted functions,
ports, protocols, and/or services].
References: DoD Instruction 8551.01
CM-7 (1); BASELINE
CONFIGURATION; Least Functionality
- Enhancement:
Periodic Review
The organization:
a. Reviews the information system
[Assignment: organization-defined
frequency]
to identify unnecessary and/or nonsecure
functions, ports, protocols, and services;
and
b. Disables
[Assignment: organization-defined
functions, ports, protocols, and
services within the information system
deemed to be unnecessary and/or
nonsecure].
References: None.
CM-7 (2); BASELINE
CONFIGURATION; Least Functionality Not appropriate for DoD to define for all CSP's
- Enhancement:
Prevent Program Execution
The information system prevents
program execution in accordance with
[Selection (one or more):
- [Assignment: organization-defined FedRAMP Additional Requirements and Guidance:
policies regarding software program
usage
and restrictions];
- rules authorizing the terms and
conditions of software program usage]. written policy on what is allowed or not allowed to run.
References: None.
CM-7 (5); CONFIGURATION
MANAGEMENT; Least Functionality -
Source:
FedRAMP v2
-------------------
FedRAMP Additional Requirements and Guidance:
Requirement: The service provider shall use the Center for
Internet Security guidelines (Level 1) to establish list of
prohibited or restricted functions, ports, protocols, and/or
services or establishes its own list of prohibited or
restricted functions, ports, protocols, and/or services if
USGCB is not available.
CM-7. Guidance: Information on the USGCB checklists
can be found at:
http://usgcb.nist.gov/usgcb_faq.html#usgcbfaq_usgcbfdcc.
(Partially derived from AC-17(8).)
CM-7 (1)
a. every 30 days;
b. Not appropriate to define unnecessary functions, ports,
protocols and service at the Enterprise level. Nonsecure
functions, ports, protocols and services are defined in
DoDI 8551.01.
Source:
DoD RMF TAG
-------------------
CM-7(1) [ At least Monthly]
Source:
FedRAMP v2
-------------------
CM-7 (2)
infrastructure or service offerings
Source:
DoD RMF TAG
-------------------
CM-7(2) Guidance:Â This control shall be implemented
in a technical manner on the information system to only
allow programs to run that adhere to the policy (i.e. white
listing). This control is not to be based off of strictly
CM-7 (5)
a. Not appropriate for DoD to define for all CSP's
Enhancement: infrastructure or service offerings;
Authorized Software / Whitelisting c. Monthly

The organization: Source:

a. Identifies DoD RMF TAG
[Assignment: organization-defined -------------------
software programs authorized to
execute on CM-7(5)[ at least Annually or when there is a change.]
the information system];
b. Employs a deny-all, permit-by- Source:
exception policy to allow the execution FedRAMP v2
of authorized software programs on the -------------------
information system; and
c. Reviews and updates the list of
authorized software programs
[Assignment: organization-defined
frequency].

References: None.
CM-8; BASELINE CONFIGURATION; CM-8
Information System Component a. hardware inventory specifications (manufacturer, type,
Inventory: model, serial number, physical location), software license
information, information system/component owner, and
The organization: for a networked component/device, the machine name.;
a. Develops and documents an inventory b. at a minimum, annually
of information system components that:
1. Accurately reflects the current Source:
information system; DoD RMF TAG
2. Includes all components within the -------------------
authorization boundary of the
information system; CM-8b. [at least monthly]
3. Is at the level of granularity deemed
necessary for tracking and reporting;Â Source:
and FedRAMP v2
4. Includes -------------------
[Assignment: organization-defined
information deemed necessary to FedRAMP Additional Requirements and Guidance:
achieve effective information system CM-8 Requirement: must be provided at least monthly or
component accountability]; and when there is a change.
b. Reviews and updates the information
system component inventory
[Assignment: organization-defined
frequency].

References: NIST Special Publication

800-128.
CM-8 (3); BASELINE CM-8 (3)
CONFIGURATION; Information a. continuously;
System Component Inventory - b. the ISSO and ISSM and others as the local organization
Enhancement: deems appropriate
Automated Unauthorized Component
Detection Source:
DoD RMF TAG
The organization: -------------------
(a) Employs automated mechanisms
[Assignment: organization-defined CM-8 (3) (a). [Continuously, using automated
frequency] to detect the presence of mechanisms with a maximum five-minute delay in
unauthorized hardware, software, and detection.]
firmware components within the
information system; and Source:
(b) Takes the following actions when FedRAMP v2
unauthorized components are detected: -------------------
[Selection (one or more):
- disables network access by such
components;
- isolates the components;
- notifies [Assignment:
organization-defined personnel or
roles]
].

References: None.
CM-10 (1); CONFIGURATION CM-10 (1)
MANAGEMENT; Software Usage IAW DoD Memorandum "Clarifying Guidance Regarding
Restrictions - Enhancement: Open Source Software (OSS)" 16 Oct 2009
Open Source Software (http://dodcio.defense.gov/Home/Issuances/
DoDCIOMemorandums.aspx).
The organization establishes the
following restrictions on the use of open Source:
source software: DoD RMF TAG
[Assignment: organization-defined -------------------
restrictions].

References: None.
CM-11; CONFIGURATION CM-11
MANAGEMENT; User-Installed a. Not appropriate for DoD to define for all CSP's
Software: infrastructure or service offerings;
b. Not appropriate for DoD to define for all CSP's
The organization: infrastructure or service offerings;
a. Establishes c. at least monthly
[Assignment: organization-defined
policies] Source:
governing the installation of software by DoD RMF TAG
users; -------------------
b. Enforces software installation policies
through CM-11.c. [Continuously (via CM-7 (5))]
[Assignment: organization-defined
methods]; Source:
and FedRAMP v2
c. Monitors policy compliance at -------------------
[Assignment: organization-defined
frequency].

References: None.
CP-1; CONTINGENCY PLANNING; CP-1
Contingency Planning Policy And a. all stakeholders identified in the contingency plan
Procedures:
b. (1) every 5 years
The organization: b. (2) annually
a. Develops, documents, and
disseminates to Source:
[Assignment: organization-defined DoD RMF TAG
personnel or roles]: -------------------
1. A contingency planning policy that
addresses purpose, scope, roles, CP-1.b.1 [at least every 3 years]
responsibilities, management CP-1.b.2 [at least annually]
commitment, coordination among
organizational entities, and compliance; Source:
and FedRAMP v2
2. Procedures to facilitate the -------------------
implementation of the contingency
planning policy and associated
contingency planning controls;
and
b. Reviews and updates the current:
1. Contingency planning policy
[Assignment: organization-defined
frequency];
and
2. Contingency planning procedures
[Assignment: organization-defined
frequency].

References: Federal Continuity Directive

1; NIST Special Publications 800-12,
800-34, 800-100.
CP-2; CONTINGENCY PLANNING; CP-2
Contingency Plan: a. at a minimum, the ISSM and ISSO
b. all stakeholders identified in the contingency plan
The organization: d. annually
a. Develops a contingency plan for the f: all stakeholders identified in the contingency plan
information system that:
1. Identifies essential missions and Source:
business functions and associated DoD RMF TAG
contingency requirements; -------------------
2. Provides recovery objectives,
restoration priorities, and metrics; CP-2d. [at least annually]
3. Addresses contingency roles,
responsibilities, assigned individuals Source:
with contact information; FedRAMP v2
4. Addresses maintaining essential -------------------
missions and business functions despite
an information system FedRAMP Additional Requirements and Guidance:
disruption, compromise, or failure; Requirement: For JAB authorizations the contingency lists
5. Addresses eventual, full information include designated FedRAMP personnel.
system restoration without deterioration
of the security safeguards
originally planned and implemented; and
6. Is reviewed and approved by
[Assignment: organization-defined
personnel or roles];
b. Distributes copies of the contingency
plan to
 [Assignment: organization-defined
key contingency personnel (identified
by name
and/or by role) and organizational
elements];
c. Coordinates contingency planning
activities with incident handling
activities;
d. Reviews the contingency plan for the
information system
[Assignment: organization-defined
frequency];
e. Updates the contingency plan to
address changes to the organization,
information system, or environment of
operation and problems encountered
during contingency plan implementation,
execution, or testing;
f. Communicates contingency plan
changes to
[Assignment: organization-defined
key contingency personnel (identified
by name
and/or by role) and organizational
elements];
and
g. Protects the contingency plan from
unauthorized disclosure and
modification.

References: Federal Continuity Directive

1; NIST Special Publication 800-34.
CP-2 (3); CONTINGENCY CP-2 (3)
PLANNING; Contingency Plan - 1 hour (Availability High )
Enhancement: 12 hours (Availability Moderate)
Resume Essential Missions / Business as defined in the contingency plan
Functions
Source:
The organization plans for the DoD RMF TAG
resumption of essential missions and -------------------
business functions within
[Assignment: organization-defined
time period]
of contingency plan activation.

References: None.
CP-3; CONTINGENCY PLANNING; CP-3
Contingency Training: a. at a maximum, 10 working days

The organization provides contingency c. at least annually

training to information system users
consistent with assigned roles and Source:
responsibilities: DoD RMF TAG
a. Within -------------------
 [Assignment: organization-defined
time period] CP-3.a. [ 10 days]
of assuming a contingency role or CP-3.c. [at least annually]
responsibility;
b. When required by information system Source:
changes; and FedRAMP v2
c. [Assignment: organization-defined -------------------
frequency]
thereafter.

References: Federal Continuity Directive

1; NIST Special Publications 800-16,
800-50.
CP-4; CONTINGENCY PLANNING; CP-4
Contingency Plan Testing And Exercises a. at least annually
RENAMED: Contingency Plan Testing:
a. Not appropriate for DoD to define for all CSP's
The organization: infrastructure or service offerings
a. Tests the contingency plan for the
information system Source:
[Assignment: organization-defined DoD RMF TAG
frequency] -------------------
using
[Assignment: organization-defined CP-4a. [at least annually for moderate impact systems; at
tests] least every three years for low impact systems] [functional
to determine the effectiveness of the plan exercises for moderate impact systems; classroom
and the organizational readiness to exercises/table top written tests for low impact systems]
execute the plan;
b. Reviews the contingency plan test Source:
results; and FedRAMP v2
c. Initiates corrective actions, if needed. -------------------

References: Federal Continuity Directive FedRAMP Additional Requirements and Guidance:

1; FIPS Publication 199; NIST Special
Publications 800-34, 800-84.
CP-7; CONTINGENCY PLANNING;
Alternate Processing Site:
The organization:
a. Establishes an alternate processing site
including necessary agreements to permit
the transfer and resumption of
[Assignment: organization-defined
information system operations]
for essential missions/business functions
within
[Assignment: organization-defined
time period consistent with recovery
time and recovery point objectives]
when the primary processing capabilities
are unavailable;
b. Ensures that equipment and supplies
CP-4a. Requirement: The service provider develops test
plans in accordance with NIST Special Publication 800-34
(as amended); plans are approved by the Authorizing
Official prior to initiating testing.
CP-7
a. Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
a. 1 hour (Availability High ) 12 hours (Availability
Moderate) as defined in the contingency plan
Source:
DoD RMF TAG
-------------------
FedRAMP Additional Requirements and Guidance:
CP-7a. Requirement: The service provider defines a time
period consistent with the recovery time objectives and
business impact analysis.
required to transfer and resume
operations are available at the alternate
processing site or contracts are in place
to support delivery to the site within the
organization-defined time period for
transfer/resumption; and
c. Ensures that the alternate processing
site provides information security
safeguards equivalent to that of the
primary site.

References: NIST Special Publication

800-34.
CP-8; CONTINGENCY PLANNING;
Telecommunications Services:
The organization establishes alternate
telecommunications services including
necessary agreements to permit the
resumption of
[Assignment: organization-defined
information system operations]
for essential missions and business
functions within
[Assignment: organization-defined
time period]
when the primary telecommunications
capabilities are unavailable at either the
primary or alternate processing or storage
sites.
CP-8
Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
1 hour (Availability High )
12 hours (Availability Moderate) as defined in the
contingency plan
Source:
DoD RMF TAG
-------------------
FedRAMP Additional Requirements and Guidance:
CP-8. Requirement: The service provider defines a time
period consistent with the business impact analysis.

References: NIST Special Publication

800-34; National Communications
Directive 3-10; Web: TSP.NCS.GOV.
CP-9; CONTINGENCY PLANNING; CP-9
Information System Backup: a. at least weekly as defined in the contingency plan
b. at least weekly and as required by system baseline
The organization: configuration changes in accordance with the contingency
a. Conducts backups of user-level plan
information contained in the information c. when created or received, when updated, and as
system required by system baseline configuration changes in
[Assignment: organization-defined accordance with the contingency plan
frequency consistent with recovery
time and recovery point objectives]; Source:
b. Conducts backups of system-level DoD RMF TAG
information contained in the information -------------------
system
[Assignment: organization-defined CP-9a. [daily incremental; weekly full]
frequency consistent with recovery CP-9b. [daily incremental; weekly full]
time and recovery point objectives]; CP-9c. [daily incremental; weekly full]
c. Conducts backups of information
system documentation including Source:
security-related documentation FedRAMP v2
[Assignment: organization-defined -------------------
frequency consistent with recovery
time and recovery point objectives];
and
d. Protects the confidentiality, integrity,
and availability of backup information at
the storage locations.
References: NIST Special Publication
800-34.
CP-9 (1); CONTINGENCY
PLANNING; Information System
Backup - Enhancement:
Testing For Reliability / Integrity
The organization tests backup
information
[Assignment: organization-defined
frequency]
to verify media reliability and
information integrity.
References: None.
CP-9 (3); CONTINGENCY
PLANNING; Information System
Backup - Enhancement:
Separate Storage For Critical Information
The organization stores backup copies of DoD RMF TAG
[Assignment: organization-defined -------------------
critical information system software
and other
security-related information]
in a separate facility or in a fire-rated
container that is not collocated with the
operational system.
FedRAMP Additional Requirements and Guidance:
CP-9. Requirement: The service provider shall determine
what elements of the cloud environment require the
Information System Backup control.
Requirement: The service provider shall determine how
Information System Backup is going to be verified and
appropriate periodicity of the check.
CP-9a. Requirement: The service provider maintains at
least three backup copies of user-level information (at
least one of which is available online) or provides an
equivalent alternative.
CP-9b. Requirement: The service provider maintains at
least three backup copies of system-level information (at
least one of which is available online) or provides an
equivalent alternative.
CP-9c. Requirement: The service provider maintains at
least three backup copies of information system
documentation including security information (at least one
of which is available online) or provides an equivalent
alternative.
CP-9 (1)
at least monthly in accordance with contingency plan
Source:
DoD RMF TAG
-------------------
CP-9 (1). [at least annually]
Source:
FedRAMP v2
-------------------
CP-9 (3)
Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
Source:

References: None.
IA-1; IDENTIFICATION AND IA-1
AUTHENTICATION; Identification And the ISSO and ISSM and others as the local organization
Authentication Policy And Procedures: deems appropriate;
b. 1. annually
The organization: a. Develops, b. 2. annually
documents, and disseminates to
[Assignment: organization-defined Source:
personnel or roles]: DoD RMF TAG
1. An identification and authentication -------------------
policy that addresses purpose, scope,
roles, responsibilities, management IA-1.b.1 [at least every 3 years]
commitment, coordination among IA-1.b.2 [at least annually]
organizational entities, and compliance;
and Source:
2. Procedures to facilitate the FedRAMP v2
implementation of the identification and -------------------
authentication policy and associated
identification and authentication controls;
and b. Reviews and updates the current:
1. Identification and authentication
policy
[Assignment: organization-defined
frequency];
2. Identification and authentication
procedures
[Assignment: organization-defined
frequency].

References: FIPS Publication 201; NIST

Special Publications 800-12, 800-63,
800-73, 800-76, 800-78, 800-100.
IA-2 (11); IDENTIFICATION AND
AUTHENTICATION; Identification And
Authentication (Organizational Users) -
Enhancement:
Remote Access - Separate Device
The information system implements
multifactor authentication for remote
access to privileged and non-privileged
accounts such that one of the factors is
provided by a device separate from the
system gaining access and the device
meets
[Assignment: organization-defined
strength of mechanism requirements].
IA-2 (11)
DoD PKI or a technology approved by their Authorizing
Official, FIPS 140-2, NIAP Certification, or NSA
approval
Source:
DoD RMF TAG
-------------------
The information system implements multifactor
authentication for remote access to privileged and non-
privileged accounts such that one of the factors is
provided by a device separate from the system gaining
access and the device meets [Assignment: organization-
defined strength of mechanism requirements].

References: None. Source:

FedRAMP v2
-------------------
IA-3; IDENTIFICATION AND IA-3
AUTHENTICATION; Device all mobile devices and network connected endpoint
Identification And Authentication: devices (including but not limited to: workstations,
printers, servers (outside a datacenter), VoIP Phones, VTC
The information system uniquely CODECs).
identifies and authenticates
[Assignment: organization-defined Source:
list of specific and/or types of devices] DoD RMF TAG
before establishing a -------------------
 [Selection (one or more):
- local;
- remote;
- network
]
connection.

References: None.
IA-3 (1); IDENTIFICATION AND IA-3 (1)
AUTHENTICATION; Device Not appropriate for DoD to define for all CSP's services.
Identification And Authentication -
Enhancement: Source:
Cryptographic Bidirectional DISA Cloud Security Team
Authentication Note the DoD RMF value is not valid for Cloud
Computing.
The information system authenticates -------------------
[Assignment: organization-defined
specific devices and/or types of
devices]
before establishing
[Selection (one or more):
- local;
- remote;
- network
]
connection using bidirectional
authentication that is cryptographically
based.

References: None.
IA-4; IDENTIFICATION AND IA-4
AUTHENTICATION; Identifier a. ISSM or ISSO
Management: d. 1 year for user identifiers (DoD is not going to specify
value for device identifier).
The organization manages information e. 35 days
system identifiers by:
a. Receiving authorization from Source:
[Assignment: organization-defined DoD RMF TAG
personnel or roles] -------------------
to assign an individual, group, role, or
device identifier; IA-4d. [at least two years]
b. Selecting an identifier that identifies IA-4e. [ninety days for user identifiers] (See additional
an individual, group, role, or device; requirements and guidance.)
c. Assigning the identifier to the intended
individual, group, role, or device; Source:
d. Preventing reuse of identifiers for FedRAMP v2
[Assignment: organization-defined time -------------------
period]; and
e. Disabling the identifier after FedRAMP Additional Requirements and Guidance:
[Assignment: organization-defined IA-4e. Requirement: The service provider defines time
time period of inactivity]. period of inactivity for device identifiers.

References: FIPS Publication 201; NIST

Special Publications 800-73, 800-76,
800-78.
IA-4 (4); IDENTIFICATION AND
AUTHENTICATION; Identifier
Management - Enhancement:
Identify User Status
The organization manages individual
identifiers by uniquely identifying each
individual as
[Assignment: organization-defined
characteristic identifying individual
status].
References: None.
IA-4 (4)
contractor or government employee and by nationality.
User identifiers will follow the same format as DoD user
e-mail addresses (john.smith.ctr@army.mil or
john.smith.uk@army.mil);
- DoD user e-mail display names (e.g., John Smith,
Contractor <john.smith.ctr@army.mil> or John Smith,
United Kingdom <john.smith.uk@army.mil>); and
- automated signature blocks (e.g., John Smith,
Contractor, J-6K, Joint Staff or John Doe, Australia, LNO,
Combatant Command).
Contractors who are also foreign nationals are identified
as both, e.g., john.smith.ctr.uk@army.mil

Source:
DoD RMF TAG
-------------------

IA-4 (4). [contractors; foreign nationals]

Source:
FedRAMP v2
-------------------
IA-5; IDENTIFICATION AND IA-5
AUTHENTICATION; Authenticator g. CAC - every 3 years, or 1 year from term of contract
Management: Password: 60 days
Biometrics: every 3 years.
The organization manages information
system authenticators by: Source:
a. Verifying, as part of the initial DoD RMF TAG
authenticator distribution, the identity of -------------------
the individual, group, role, or device
receiving the authenticator; IA-5g. [to include sixty days for passwords]
b. Establishing initial authenticator
content for authenticators defined by the Source:
organization; FedRAMP v2
c. Ensuring that authenticators have -------------------
sufficient strength of mechanism for their
intended use;
d. Establishing and implementing
administrative procedures for initial
authenticator distribution, for
lost/compromised or damaged
authenticators, and for revoking
authenticators;
e. Changing default content of
authenticators prior to information
system installation;
f. Establishing minimum and maximum
lifetime restrictions and reuse conditions
for authenticators;
g. Changing/refreshing authenticators
[Assignment: organization-defined
time period by authenticator type];
h. Protecting authenticator content from
unauthorized disclosure and
modification; and
i. Requiring individuals to take, and
having devices implement, specific
security safeguards to protect
authenticators; and
j. Changing authenticators for group/role
accounts when membership to those
accounts changes.

References: OMB Memorandum 04-04,

11-11; FIPS Publication 201; NIST
Special Publications 800-73, 800-63,
800-76, 800-78; FICAM Roadmap and
Implementation Guidance; Web:
idmanagement.gov
IA-5 (1); IDENTIFICATION AND IA-5 (1)
AUTHENTICATION; Authenticator As supported by the device:
Management - Enhancement: a. minimum of 15 Characters, 1 of each of the following
Password-Based Authentication character sets:
- Upper-case
The information system, for password- - Lower-case
based authentication: - Numerics
(a) Enforces minimum password - Special characters (e.g. ~ ! @ # $ % ^ & * ( ) _ + = - ‘
complexity of [ ] / ? > <)];
[Assignment: organization-defined b. 50% of the minimum password lenth,
requirements for case sensitivity, d. Minimum 24 hours, Maximum 60 days
number of characters, mix of upper- e. Minimum of 5
case letters, lower-case letters,
numbers, and special characters, Source:
including minimum requirements for DoD RMF TAG
each type]; -------------------
(b) Enforces at least the following
number of changed characters when new IA-5 (1) (a). [case sensitive, minimum of twelve
passwords are created: characters, and at least one each of upper-case letters,
[Assignment: organization-defined lower-case letters, numbers, and special characters]
number]; IA-5 (1) (b). [at least one]
(c ) Stores and transmits only encrypted IA-5 (1) (d). [one day minimum, sixty day maximum]
representations of passwords; IA-5 (1) (e). [twenty four]
(d) Enforces password minimum and
maximum lifetime restrictions of Source:
[Assignment: organization-defined FedRAMP v2
numbers for lifetime minimum, -------------------
lifetime maximum];
(e) Prohibits password reuse for
[Assignment: organization-defined
number]
generations; and
(f) Allows the use of a temporary
password for system logons with an
immediate change to a permanent
password.
References: None.
IA-5 (3); IDENTIFICATION AND
AUTHENTICATION; Authenticator
Management - Enhancement:
In-Person Or Trusted Third-Party
Registration
The organization requires that the
registration process to receive
[Assignment: organization-defined
types of and/or specific authenticators]
be conducted
[Selection:
- in person;
- by a trusted third party
] issuance of credentials to subscribers.
before
[Assignment: organization-defined
registration authority]
with authorization by
[Assignment: organization-defined
personnel or roles].
References: None.
IA-5 (4); IDENTIFICATION AND
AUTHENTICATION; Authenticator
Management - Enhancement:
Automated Support For Password
Strength Determination
The organization employs automated
tools to determine if password
authenticators are sufficiently strong to
satisfy
[Assignment: organization-defined
requirements].
References: None.
IA-5 (11); IDENTIFICATION AND
AUTHENTICATION; Authenticator
Management - Enhancement:
Hardware Token-Based Authentication
The information system, for hardware
token-based authentication, employs
mechanisms that satisfy
[Assignment: organization-defined
token quality requirements].
References: None.
IA-5 (13); IDENTIFICATION AND
IA-5 (3)
The DoD PKI CP defines the role and responsibilities of a
DoD PKI Registration Authority (RA). The NSS PKI CP
defines the role and responsibilities of an NSS PKI RA.
The DoD PKI RA–LRA CPS defines the nomination
process for DoD PKI RAs. The NSS PKI DoD RPS
defines the nomination process for NSS PKI RAs for
DoD.
The DoD PKI CP defines DoD PKI subscribers and the
authentication requirements for issuance of credentials to
subscribers. The NSS PKI CP defines NSS PKI
subscribers and the authentication requirements for
Source:
DoD RMF TAG
-------------------
IA-5 (3). [All hardware/biometric (multifactor
authenticators] [in person]
Source:
FedRAMP v2
-------------------
IA-5 (4)
complexity as identified in IA-5 (1) Part A
Source:
DoD RMF TAG
-------------------
FedRAMP Additional Requirements and Guidance:
IA-4e Additional FedRAMP Requirements and Guidance:
Guidance: If automated mechanisms which enforce
password authenticator strength at creation are not used,
automated mechanisms must be used to audit strength of
created password authenticators
IA-5 (11)
DoDI 8520.03
Source:
DoD RMF TAG
-------------------
IA-5 (13)
AUTHENTICATION; Authenticator Not appropriate for DoD to define for all CSP's
Management - Enhancement: infrastructure or service offerings
Expiration Of Cached Authenticators
Source:
The information system prohibits the use DoD RMF TAG
of cached authenticators after -------------------
[Assignment: organization-defined
time period].

References: None.
IA-8 (3); IDENTIFICATION AND IA-8 (3)
AUTHENTICATION; Identification And Not appropriate for DoD to define for all CSP's
Authentication (Non-Organization Users) infrastructure or service offerings
- Enhancement:
Use Of FICAM-Approved Products Source:
DoD RMF TAG
The organization employs only FICAM- -------------------
approved information system
components in
[Assignment: organization-defined
information systems]
to accept third-party credentials.

References: None.
IR-1; INCIDENT RESPONSE; Incident IR-1
Response Policy And Procedures: a. all personnel identified as stakeholders in the incident
response process, as well as the ISSM and ISSO
The organization:
a. Develops, documents, and b. (1) every 5 years
disseminates to b. (2) annually
[Assignment: organization-defined
personnel or roles]:
1. An incident response policy that Source:
addresses purpose, scope, roles, DoD RMF TAG
responsibilities, management -------------------
commitment, coordination among
organizational entities, and compliance; IR-1.b.1 [at least every 3 years]
and IR-1.b.2 [at least annually]
2. Procedures to facilitate the
implementation of the incident response Source:
policy and associated incident response FedRAMP v2
controls; -------------------
and
b. Reviews and updates the current:
1. Incident response policy
[Assignment: organization-defined
frequency];
and
2. Incident response procedures
[Assignment: organization-defined
frequency].

References: NIST Special Publications

800-12, 800-61, 800-83, 800-100.
IR-2; INCIDENT RESPONSE; Incident IR-2
Response Training: a. 30 working days

The organization provides incident c. Annually

response training to information system
users consistent with assigned roles and Source:
responsibilities: DoD RMF TAG
a. Within -------------------
[Assignment: organization-defined
time period] IR-2b. [at least annually]
of assuming an incident response role or
responsibility; Source:
b. When required by information system FedRAMP v2
changes; and -------------------
c. [Assignment: organization-defined
frequency]
thereafter.

References: NIST Special Publications

800-16, 800-50.
IR-3; INCIDENT RESPONSE; Incident IR-3
Response Testing And Exercises At least every six months for high availability and at least
RENAMED: Incident Response Testing: annually for low/med availability

The organization tests the incident
response capability for the information
system
[Assignment: organization-defined
frequency]
using
[Assignment: organization-defined
tests]
to determine the incident response
effectiveness and documents the results.
References: NIST Special Publications
800-84, 800-115.
Tests as defined in the incident response plan
Source:
DoD RMF TAG
-------------------
IR-3. [at least annually]
Source:
FedRAMP v2
-------------------
FedRAMP Additional Requirements and Guidance:
IR-3. Requirement: The service provider defines tests
and/or exercises in accordance with NIST Special
Publication 800-61 (as amended).
Requirement: For JAB Authorization, the service provider
provides test plans to the Authorizing Official (AO)
annually.

Requirement: Test plans are approved and accepted by the

Authorizing Official prior to test commencing.
IR-4 (3); INCIDENT RESPONSE; IR-4 (3)
Incident Handling - Enhancement: Classes of incidents defined in CJCSM 6510.01B
Continuity Of Operations Appendix A- Enclosure B

The organization identifies Actions defined in CJCSM 6510.01B

[Assignment: organization-defined
classes of incidents] Source:
and DoD RMF TAG
 [Assignment: organization-defined -------------------
actions to take in response to classes of
incidents]
to ensure continuation of organizational
missions and business functions.

References: None.
IR-4 (7); INCIDENT RESPONSE; IR-4 (7)
Incident Handling - Enhancement: Not appropriate for DoD to define for all CSP's
Insider Threats - Intra-Organization infrastructure or service offerings
Coordination
Source:
The organization coordinates incident DoD RMF TAG
handling capability for insider threats -------------------
across
[Assignment: organization-defined
components or elements of the
organization].

References: None.
IR-4 (8); INCIDENT RESPONSE; IR-4 (8)
Incident Handling - Enhancement: The appropriate CIRT/CERT (such as US-CERT, DoD
Correlation With External Organizations CERT, IC CERT)

The organization coordinates with Not appropriate for DoD to define for all CSP's
[Assignment: organization-defined infrastructure or service offerings
external organizations]
to correlate and share Source:
[Assignment: organization-defined DoD RMF TAG
incident information] -------------------
to achieve a cross-organization
perspective on incident awareness and
more effective incident responses.

References: None.
IR-6; INCIDENT RESPONSE; Incident IR-6
Reporting: a. the timeframes specified by CJCSM 6510.01B (Table
C-A-1) unless the data owner provides more restrictive
The organization: guidance
a. Requires personnel to report suspected
security incidents to the organizational b. The appropriate CIRT/CERT (such as US-CERT, DoD
incident response capability within CERT, IC CERT)
[Assignment: organization-defined
time period]; Source:
and DoD RMF TAG
b. Reports security incident information -------------------
to
[Assignment: organization-defined IR-6a. [US-CERT incident reporting timelines as specified
authorities]. in NIST Special Publication 800-61 (as amended)]

References: NIST Special Publication Source:

800-61: Web: WWW.US-CERT.GOV. FedRAMP v2
-------------------

IR-6 (2); INCIDENT RESPONSE;
Incident Reporting - Enhancement:
Vulnerabilities Related To Incidents
The organization reports information
system vulnerabilities associated with
reported security incidents to
[Assignment: organization-defined
personnel or roles].
References: None.
IR-8; INCIDENT RESPONSE; Incident
Response Plan:
The organization:
a. Develops an incident response plan
that:
1. Provides the organization with a
roadmap for implementing its incident
response capability;
2. Describes the structure and
organization of the incident response
capability;
3. Provides a high-level approach for
how the incident response capability fits
into the overall organization;
4. Meets the unique requirements of
the organization, which relate to mission,
size, structure, and functions;
5. Defines reportable incidents;
6. Provides metrics for measuring the
incident response capability within the
organization;
7. Defines the resources and
management support needed to
effectively maintain and mature an
incident
response capability; and
8. Is reviewed and approved by
[Assignment: organization-defined
personnel or roles];
b. Distributes copies of the incident
response plan to
[Assignment: organization-defined
incident response personnel (identified
by name
and/or by role) and organizational
elements];
c. Reviews the incident response plan
[Assignment: organization-defined
FedRAMP Additional Requirements and Guidance:
Requirement: Reports security incident information
according to FedRAMP Incident Communications
Procedure.
IR-6 (2)
Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
Source:
DoD RMF TAG
-------------------
IR-8
a. at a minimum, the ISSM and ISSO
b.all stakeholders identified in the incident response plan
c. at least annually (incorporating lessons learned from
past incidents)
e. all stakeholders identified in the incident response plan,
not later than 30 days after the change is made
Source:
DoD RMF TAG
-------------------
IR-8c. [at least annually]
Source:
FedRAMP v2
-------------------
FedRAMP Additional Requirements and Guidance:
IR-8(b) Additional FedRAMP Requirements and
Guidance: The service provider defines a list of incident
response personnel (identified by name and/or by role)
and organizational elements. The incident response list
includes designated FedRAMP personnel.
IR-8(e) Additional FedRAMP Requirements and
Guidance: The service provider defines a list of incident
response personnel (identified by name and/or by role)
and organizational elements. The incident response list
includes designated FedRAMP personnel.
frequency];
d. Updates the incident response plan to
address system/organizational changes or
problems encountered during plan
implementation, execution, or testing;
e. Communicates incident response plan
changes to
[Assignment: organization-defined
incident response personnel (identified
by name
and/or by role) and organizational
elements];
and
f. Protects the incident response plan
from unauthorized disclosure and
modification.

References: NIST Special Publication

800-61
IR-9; INCIDENT RESPONSE; IR-9
Information Spillage Response: b. at a minimum, the OCA, the information
owner/originator, the ISSM, the activity security manager,
The organization responds to information and the responsible computer incident response center
spills by:
a. Identifying the specific information f. Not appropriate for DoD to define for all CSP's
involved in the information system infrastructure or service offerings
contamination;
b. Alerting Source:
[Assignment: organization-defined DoD RMF TAG
personnel or roles] -------------------
of the information spill using a method of
communication not associated with the
spill;
c. Isolating the contaminated information
system or system component;
d. Eradicating the information from the
contaminated information system or
component;
e. Identifying other information systems
or system components that may have
been subsequently contaminated; and
f. Performing other
[Assignment: organization-defined
actions].

References: None.
IR-9 (1); INCIDENT RESPONSE; IR-9 (1)
Information Spillage Response - Not appropriate for DoD to define for all CSP's
Enhancement: infrastructure or service offerings
Responsible Personnel
Source:
The organization assigns DoD RMF TAG
[Assignment: organization-defined -------------------
personnel or roles]
with responsibility for responding to
information spills.

References: None.
IR-9 (2); INCIDENT RESPONSE; IR-9 (2)
Information Spillage Response - Annually
Enhancement:
Training Source:
DoD RMF TAG
The organization provides information -------------------
spillage response training
[Assignment: organization-defined
frequency].

References: None.
IR-9 (3); INCIDENT RESPONSE; IR-9 (3)
Information Spillage Response - Not appropriate for DoD to define for all CSP's
Enhancement: infrastructure or service offerings
Post-Spill Operations
Source:
The organization implements DoD RMF TAG
[Assignment: organization-defined -------------------
procedures]
to ensure that organizational personnel
impacted by information spills can
continue to carry out assigned tasks while
contaminated systems are undergoing
corrective actions.

References: None.
IR-9 (4); INCIDENT RESPONSE; IR-9 (4)
Information Spillage Response - Not appropriate for DoD to define for all CSP's
Enhancement: infrastructure or service offerings
Exposure To Unauthorized Personnel
Source:
The organization employs DoD RMF TAG
[Assignment: organization-defined -------------------
security safeguards]
for personnel exposed to information not
within assigned access authorizations.

References: None.
MA-1; MAINTENANCE; System MA-1
Maintenance Policy And Procedures: a. all stakeholders identified in the maintenance policy

The organization: b. (1) every 5 years

a. Develops, documents, and b. (2) annually
disseminates to
[Assignment: organization-defined Source:
personnel or roles]: DoD RMF TAG
1. A system maintenance policy that -------------------
addresses purpose, scope, roles,
responsibilities, management MA-1.b.1 [at least every 3 years]
commitment, coordination among MA-1.b.2 [at least annually]
organizational entities, and compliance;
and Source:
2. Procedures to facilitate the FedRAMP v2
implementation of the system -------------------
maintenance policy and associated
system maintenance controls;
and
b. Reviews and updates the current:
1. System maintenance policy
[Assignment: organization-defined
frequency];
and
2. System maintenance procedures
[Assignment: organization-defined
frequency].

References: NIST Special Publications

800-12, 800-100.
MA-2; MAINTENANCE; Controlled MA-2
Maintenance: c. Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
The organization:
a. Schedules, performs, documents, and f. Not appropriate for DoD to define for all CSP's
reviews records of maintenance and infrastructure or service offerings
repairs on information system
components in accordance with Source:
manufacturer or vendor specifications DoD RMF TAG
and/or organizational requirements; -------------------
b. Approves and monitors all
maintenance activities, whether
performed on site or remotely and
whether the equipment is serviced on site
or removed to another location;
c. Requires that
[Assignment: organization-defined
personnel or roles]
explicitly approve the removal of the
information system or system
components from organizational facilities
for off-site maintenance or repairs;
d. Sanitizes equipment to remove all
information from associated media prior
to removal from organizational facilities
for off-site maintenance or repairs;
e. Checks all potentially impacted
security controls to verify that the
controls are still functioning properly
following maintenance or repair actions;
and
f. Includes
[Assignment: organization-defined
maintenance-related information]
in organizational maintenance records.

References: None.
MA-3 (3); MAINTENANCE; MA-3 (3)
Maintenance Tools - Enhancement: d. Not appropriate for DoD to define for all CSP's
Prevent Unauthorized Removal infrastructure or service offerings

The organization prevents the Source:

unauthorized removal of maintenance DoD RMF TAG
equipment containing organizational -------------------
information by:
(a) Verifying that there is no MA-3 (3) (d). [the information owner explicitly
organizational information contained on authorizing removal of the equipment from the facility]
the equipment;
(b) Sanitizing or destroying the Source:
equipment; FedRAMP v2
(c) Retaining the equipment within the -------------------
facility; or
(d) Obtaining an exemption from
[Assignment: organization-defined
personnel or roles]
explicitly authorizing removal of the
equipment from the facility.

References: None.
MA-6; MAINTENANCE; Timely
Maintenance:
The organization obtains maintenance
support and/or spare parts for
[Assignment: organization-defined
information system components]
within
[Assignment: organization-defined
time period]
of failure.
MA-6
Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
Within 24 hours (Low and Moderate Availability) or
immediately upon failure for (High Availability)
Source:
DoD RMF TAG
-------------------

References: None.
MP-1; MEDIA PROTECTION; Media MP-1
Protection Policy And Procedures: a. all users

The organization: b. (1) every 5 years

a. Develops, documents, and b. (2) annually
disseminates to
[Assignment: organization-defined Source:
personnel or roles]: DoD RMF TAG
1. A media protection policy that -------------------
addresses purpose, scope, roles,
responsibilities, management MP-1.b.1 [at least every 3 years]
commitment, MP-1.b.2 [at least annually]
coordination among organizational
entities, and compliance; and Source:
2. Procedures to facilitate the FedRAMP v2
implementation of the media protection -------------------
policy and associated media protection
controls;
and
b. Reviews and updates the current:
1. Media protection policy
[Assignment: organization-defined
frequency]; and
2. Media protection procedures
[Assignment: organization-defined
frequency].

References: NIST Special Publications

800-12, 800-100.
MP-2; MEDIA PROTECTION; Media
Access:
The organization restricts access to
[Assignment: organization-defined
types of digital and non-digital media]
to [Assignment: organization-defined
personnel or roles].
MP-2
All types of digital and/or non-digital media containing
information not cleared for public release
Not appropriate for DoD to define for all CSP's
infrastructure or service offerings, but types of media must
be identified IAW DoD 5200.01-M, CTO 10-133, and
CTO 08-001

References: FIPS Publication 199; NIST Source:

Special Publication 800-111 DoD RMF TAG
-------------------
MP-3; MEDIA PROTECTION; Media
Marking:
The organization:
a. Marks information system media
indicating the distribution limitations,
handling caveats, and applicable security
markings (if any) of the information; and
b. Exempts
[Assignment: organization-defined
types of information system media]
from marking as long as the media
remain within
[Assignment: organization-defined
controlled areas].
References: FIPS Publication 199.
MP-4; MEDIA PROTECTION; Media
Storage:
The organization:
a. Physically controls and securely stores
[Assignment: organization-defined
types of digital and/or non-digital
media]
within
[Assignment: organization-defined
controlled areas];
and
b. Protects information system media
MP-3
b. nothing unless otherwise exempted by DoDI 5200.01
and DoDM 5200.01 Vol 1-4
b. all areas unless otherwise exempted by DoDI 5200.01
and DoDM 5200.01 Vol 1-4
Source:
DoD RMF TAG
-------------------
MP-3b. [no removable media types]
Source:
FedRAMP v2
-------------------
FedRAMP Additional Requirements and Guidance:
MP-3b. Guidance: Second parameter not-applicable
MP-4
a (1). all digital and non-digital media containing
sensitive, controlled, and/or classified information.
a (2). areas approved for processing or storing data IAW
the sensitivity and/or classification level of the
information contained on/within the media.
Source:
DoD RMF TAG
-------------------
MP-4a. [all types of digital and non-digital media with
until the media are destroyed or sanitized sensitive information] within [FedRAMP Assignment: see
using approved equipment, techniques,
and procedures.
References: FIPS Publication 199; NIST FedRAMP v2
Special Publications 800-56, 800-57,
800-11
MP-5; MEDIA PROTECTION; Media
Transport:
The organization:
a. Protects and controls
[Assignment: organization-defined
types of information system media]
during transport outside of controlled
areas using
[Assignment: organization-defined
security safeguards];
b. Maintains accountability for
information system media during
transport outside of controlled areas;
c. Documents activities associated with
the transport of information system
media; and
d. Restricts the activities associated with
transport of information system media to
authorized personnel.
References: FIPS Publication 199; NIST
Special Publication 800-60.
MP-6; MEDIA PROTECTION; Media
Sanitization:
The organization:
a. Sanitizes
[Assignment: organization-defined
information system media]
prior to disposal, release out of
organizational control, or release for
reuse using
[Assignment: organization-defined
sanitization techniques and
procedures]
in accordance with applicable federal and
organizational standards and policies;
and
b. Employs sanitization mechanisms with
the strength and integrity commensurate
with the security category or
additional FedRAMP requirements and guidance];
Source:
-------------------
FedRAMP Additional Requirements and Guidance:
MP-4a Additional FedRAMP Requirements and
Guidance: Requirement: The service provider defines
controlled areas within facilities where the information
and information system reside.
MP-5
a. all digital and non-digital media containing sensitive,
controlled, and/or classified information.
a. DoDI 5200.1R and other organizationally defined
security safeguards.
Source:
DoD RMF TAG
-------------------
MP-5a. [all media with sensitive information] [prior to
leaving secure/controlled environment: for digital media,
encryption using a FIPS 140-2 validated encryption
module; for non-digital media, secured in locked
container]
Source:
FedRAMP v2
-------------------
MP-6
a. all media
a. techniques and procedures IAW NIST SP 800-88
Source:
DoD RMF TAG
-------------------
The organization: a. Sanitizes [Assignment: organization-
defined information system media] prior to disposal,
release out of organizational control, or release for reuse
using [Assignment: organization-defined sanitization
techniques and procedures] in accordance with applicable
federal and organizational standards and policies; and b.
Employs sanitization mechanisms with the strength and
integrity commensurate with the security category or
classification of the information.
classification of the information. Source:
FedRAMP v2
References: FIPS Publication 199; NIST -------------------
Special Publications 800-60, 800-88;
Web:
www.nsa.gov/ia/mitigation_guidance/
media_destruction_guidance/index.shtml.
MP-6 (2); MEDIA PROTECTION; MP-6 (2)
Media Sanitization - Enhancement: every 180 days.
Equipment Testing
Source:
The organization tests sanitization DoD RMF TAG
equipment and procedures -------------------
[Assignment: organization-defined
frequency] [At least annually]
to verify that the intended sanitization is
being achieved. Source:
FedRAMP v2
References: None. -------------------

FedRAMP Additional Requirements and Guidance:

MP-7; MEDIA PROTECTION; Media
Use:
The organization [Selection: restricts;
prohibits] the use of
[Assignment: organization-defined
types of information system media]
on
[Assignment: organization-defined
information systems or system
components]
using
[Assignment: organization-defined
security safeguards].
Guidance: Equipment and procedures may be tested or
validated for effectiveness
MP-7
Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
Source:
DoD RMF TAG
-------------------

References: FIPS Publication 199; NIST

Special Publication 800-111.
PE-1; PHYSICAL AND PE-1
ENVIRONMENTAL PROTECTION; a. all personnel
Physical And Environmental Protection
Policy And Procedures: b. (1) annually
b. (2) annually
The organization:
a. Develops, documents, and Source:
disseminates to DoD RMF TAG
[Assignment: organization-defined -------------------
personnel or roles]:
1. A physical and environmental PE-1.b.1 [at least every 3 years]
protection policy that addresses purpose, PE-1.b.2 [at least annually]
scope, roles, responsibilities,
management commitment, coordination Source:
among organizational entities, and FedRAMP v2
compliance; and -------------------
2. Procedures to facilitate the
implementation of the physical and
environmental protection policy and
associated physical and environmental
protection controls;
and
b. Reviews and updates the current:
1. Physical and environmental
protection policy
[Assignment: organization-defined
frequency];
and
2. Physical and environmental
protection procedures
[Assignment: organization-defined
frequency].

References: NIST Special Publications

800-12, 800-100.
PE-2; PHYSICAL AND PE-2
ENVIRONMENTAL PROTECTION; c. every 90 days
Physical Access Authorizations:
Source:
The organization: DoD RMF TAG
a. Develops, approves, and maintains a -------------------
list of individuals with authorized access
to the facility where the information PE-2c. [at least annually]
system resides;
b. Issues authorization credentials for Source:
facility access; FedRAMP v2
c. Reviews the access list detailing -------------------
authorized facility access by individuals
[Assignment: organization-defined
frequency];
and
d. Removes individuals from the facility
access list when access is no longer
required.

References: None.
PE-3; PHYSICAL AND
ENVIRONMENTAL PROTECTION;
Physical Access Control:
The organization:
a. Enforces physical access
authorizations at
[Assignment: organization-defined
entry/exit points to the facility where
the information system resides]
by;
1. Verifying individual access
PE-3
a. Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
a. (2) Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
b. Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
c. Not appropriate for DoD to define for all CSP's
authorizations before granting access to infrastructure or service offerings
the facility; and
2. Controlling ingress/egress to the d. Not appropriate for DoD to define for all CSP's
facility using infrastructure or service offerings
[Selection (one or more):
- [Assignment: organization-defined f. minimally keys or any other physical token used to gain
physical access control access
systems/devices];
- guards f. annually
];
b. Maintains physical access audit logs g. as required by security relevant events
for
[Assignment: organization-defined Source:
entry/exit points]; DoD RMF TAG
c. Provides -------------------
[Assignment: organization-defined
security safeguards] PE-3a.2 [CSP defined physical access control
to control access to areas within the systems/devices AND guards]
facility officially designated as publicly PE-3d. [in all circumstances within restricted access area
accessible; where the information system resides]
d. Escorts visitors and monitors visitor PE-3f. [at least annually]
activity
[Assignment: organization-defined PE-3g. [at least annually]
circumstances requiring visitor escorts
and monitoring]; Source:
e. Secures keys, combinations, and other FedRAMP v2
physical access devices; -------------------
f. Inventories
[Assignment: organization-defined
physical access devices]
every
[Assignment: organization-defined
frequency]; and
g. Changes combinations and keys
[Assignment: organization-defined
frequency]
and/or when keys are lost, combinations
are compromised, or individuals are
transferred or terminated.

References: FIPS Publication 201; NIST

Special Publications 800-73, 800-76,
800-78, 800-116; ICD 704, 705; DoDI
5200.39; Personal Identity Verification
(PIV) in Enterprise Physical Access
Control System (E-PACS); Web:
idmanagement.gov, fips201ep.cio.gov
PE-3 (1); PHYSICAL AND PE-3 (1)
ENVIRONMENTAL PROTECTION; Not appropriate for DoD to define for all CSP's
Physical Access Control - Enhancement: infrastructure or service offerings
Information System Access
Source:
The organization enforces physical DoD RMF TAG
access authorizations to the information -------------------
system in addition to the physical access
controls for the facility at
[Assignment: organization-defined
physical spaces containing one or more
components of the information
system].

References: None.
PE-4; PHYSICAL AND PE-4
ENVIRONMENTAL PROTECTION; Not appropriate for DoD to define for all CSP's
Access Control For Transmission infrastructure or service offerings
Medium:
Not appropriate for DoD to define for all CSP's
The organization controls physical access infrastructure or service offerings
to
[Assignment: organization-defined Source:
information system distribution and DoD RMF TAG
transmission lines] -------------------
within organizational facilities using
[Assignment: organization-defined
security safeguards].

References: NSTISSI No. 7003.

PE-6; PHYSICAL AND PE-6
ENVIRONMENTAL PROTECTION; b. every 30 days
Monitoring Physical Access:
b. Not appropriate for DoD to define for all CSP's
The organization: infrastructure or service offerings
a. Monitors physical access to the facility
where the information system resides to Source:
detect and respond to physical security DoD RMF TAG
incidents; -------------------
b. Reviews physical access logs
[Assignment: organization-defined PE-6b.[at least monthly]
frequency]
and upon occurrence of Source:
[Assignment: organization-defined FedRAMP v2
events or potential indications of -------------------
events];
and
c. Coordinates results of reviews and
investigations with the organizational
incident response capability.

References: None.
PE-8; PHYSICAL AND PE-8
ENVIRONMENTAL PROTECTION; a. at least one year
Access Records b. every 30 days
RENAMED: Visitor Access Records:
Source:
The organization: DoD RMF TAG
a. Maintains visitor access records to the -------------------
facility where the information system
resides for PE-8a [for a minimum of one year]
[Assignment: organization-defined PE-8b. [at least monthly]
time period]; and
b. Reviews visitor access records
[Assignment: organization-defined
frequency].
References: None.
PE-10; PHYSICAL AND
ENVIRONMENTAL PROTECTION;
Emergency Shutoff:
The organization:
a. Provides the capability of shutting off
power to the information system or
individual system components in
emergency situations;
b. Places emergency shutoff switches or
devices in
[Assignment: organization-defined
location by information system or
system component]
to facilitate safe and easy access for
personnel; and
c. Protects emergency power shutoff
capability from unauthorized activation.
References: None.
PE-13 (2); PHYSICAL AND
ENVIRONMENTAL PROTECTION;
Fire Protection - Enhancement:
Suppression Devices / Systems
The organization employs fire
suppression devices/systems for the
information system that provide
automatic notification of any activation
to
[Assignment: organization-defined
personnel or roles]
and
[Assignment: organization-defined
emergency responders].
References: None.
PE-14; PHYSICAL AND
ENVIRONMENTAL PROTECTION;
Temperature And Humidity Controls:
The organization:
a. Maintains temperature and humidity
levels within the facility where the
information system resides at
[Assignment: organization-defined
acceptable levels];
and
Source:
FedRAMP v2
-------------------
PE-10
While the DoD value shown below is common industry
practice it is not appropriate for DoD to define for all
CSP's infrastructure or service offerings
b. or near more than one egress point of the IT area and it
is labeled and protected by a cover to prevent accidental
shut-off
Source:
DoD RMF TAG
-------------------
PE-13 (2)
Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
Source:
DoD RMF TAG
-------------------
PE-14
NOTE: the DoD value shown for PE-14 is equivalent to
the FedRAMP value and represents industry standards. It
provides an evaluation benchmark. While this value is not
appropriate for DoD to define for all CSP's infrastructure
or service offerings, DoD CSPs must follow the DoD
value while Commercial CSPs may use the FedRAMP
value as follows:
PE-14a. [consistent with American Society of Heating,
Refrigerating and Air-conditioning Engineers (ASHRAE)
b. Monitors temperature and humidity document entitled Thermal Guidelines for Data Processing
levels Environments]
[Assignment: organization-defined
frequency]. PE-14b. [continuously]

References: None. Source:

FedRAMP v2
-------------------

FedRAMP Additional Requirements and Guidance:

PE-14a. Requirements: The service provider measures
temperature at server inlets and humidity levels by dew
point.
DoD CSP requirement:
a. For commercial grade information systems: 64.4 - 80.6
degrees F; 45% - 60% Relative Humidity; Dew Point
41.9° - 59°F; measured at the air intake inlet of the IT
equipment casing; For other systems, levels within
manufacturer specifications
b. Continuously unless manufacturer specifications allow
for a wide enough tolerance that control is not required

Source:
DoD RMF TAG
-------------------
PE-16; PHYSICAL AND PE-16
ENVIRONMENTAL PROTECTION; All system components
Delivery And Removal:
Source:
The organization authorizes, monitors, DoD RMF TAG
and controls -------------------
[Assignment: organization-defined
types of information system PE-16. [all information system components]
components]
entering and exiting the facility and Source:
maintains records of those items. FedRAMP v2
-------------------
References: None.
PE-17; PHYSICAL AND PE-17
ENVIRONMENTAL PROTECTION; a. Not appropriate for DoD to define for all CSP's
Alternate Work Site: infrastructure or service offerings but must include all
applicable building and safety codes for the information
The organization: system's environment
a. Employs
[Assignment: organization-defined Source:
security controls] DoD RMF TAG
at alternate work sites; -------------------
b. Assesses as feasible, the effectiveness
of security controls at alternate work
sites; and
c. Provides a means for employees to
communicate with information security
personnel in case of security incidents or
problems.
References: NIST Special Publication
800-46.
PL-1; PLANNING; Security Planning PL-1
Policy And Procedures: a. all personnel

The organization: b. (1) every 5 years

a. Develops, documents, and b. (2) annually
disseminates to
[Assignment: organization-defined Source:
personnel or roles]: DoD RMF TAG
1. A security planning policy that -------------------
addresses purpose, scope, roles,
responsibilities, management PL-1.b.1 [at least every 3 years]
commitment, PL-1.b.2 [at least annually]
coordination among organizational
entities, and compliance; and Source:
2. Procedures to facilitate the FedRAMP v2
implementation of the security planning -------------------
policy and associated security planning
controls;
and
b. Reviews and updates the current:
1. Security planning policy
[Assignment: organization-defined
frequency];
and
2. Security planning procedures
[Assignment: organization-defined
frequency].

References: NIST Special Publications

800-12, 800-18, 800-100
PL-2; PLANNING; System Security PL-2
Plan: b. at a minimum, the ISSO, ISSM and SCA

The organization: c. annually

a. Develops a security plan for the
information system that: Source:
1. Is consistent with the DoD RMF TAG
organization’s enterprise -------------------
architecture;
2. Explicitly defines the authorization PL-2c. [at least annually]
boundary for the system;
3. Describes the operational context of Source:
the information system in terms of FedRAMP v2
missions and business processes; -------------------
4. Provides the security categorization
of the information system including
supporting rationale;
5. Describes the operational
environment for the information system
and relationships with or connections to
other information systems;
 6. Provides an overview of the security
requirements for the system;
7. Identifies any relevant overlays, if
applicable;
8. Describes the security controls in
place or planned for meeting those
requirements including a rationale
for the tailoring and supplmentation
decisions; and
9. Is reviewed and approved by the
authorizing official or designated
representative prior to plan
implementation;
b. Distributes copies of the security plan
and communicates subsequent changes to
the plan to
[Assignment: organization-defined
personnel or roles];
c. Reviews the security plan for the
information system
[Assignment: organization-defined
frequency];
d. Updates the plan to address changes to
the information system/environment of
operation or problems identified during
plan implementation or security control
assessments; and
e. Protects the security plan from
unauthorized disclosure and
modification.

References: NIST Special Publication

800-18.
PL-2 (3); PLANNING; System Security PL-2 (3)
Plan - Enhancement: Not appropriate for DoD to define for all CSP's
Plan / Coordinate With Other infrastructure or service offerings
Organizational Entities
Source:
The organization plans and coordinates DoD RMF TAG
security-related activities affecting the -------------------
information system with
[Assignment: organization-defined
individuals or groups]
before conducting such activities in order
to reduce the impact on other
organizational entities.

References: None.
PL-4; PLANNING; Rules Of Behavior: PL-4
c. annually
The organization:
a. Establishes and makes readily Source:
available to individuals requiring access DoD RMF TAG
to the information system, the rules that -------------------
describe their responsibilities and
expected behavior with regard to PL-4c. [At least every 3 years]
information and information system
usage; Source:
b. Receives a signed acknowledgment FedRAMP v2
from such individuals, indicating that -------------------
they have read, understand, and agree to
abide by the rules of behavior, before
authorizing access to information and the
information system;
c. Reviews and updates the rules of
behavior
[Assignment: organization-defined
frequency];
and
d. Requires individuals who have signed
a previous version of the rules of
behavior to read and resign when the
rules of behavior are revised/updated.

References: NIST Publication 800-18.

PL-8; PLANNING; Information Security PL-8
Architecture: b. annually

The organization: Source:

a. Develops an information security DoD RMF TAG
architecture for the information system -------------------
that:
1. Describes the overall philosophy, PL-8b. [At least annually]
requirements, and approach to be taken
with regard to protecting the Source:
confidentiality, integrity, and availability FedRAMP v2
of organizational information; -------------------
2. Describes how the information
security architecture is integrated into
and supports the enterprise architecture;
and
3. Describes any information security
assumptions about, and dependencies on,
external services;
b. Reviews and updates the information
security architecture
[Assignment: organization-defined
frequency]
to reflect updates in the enterprise
architecture; and
c. Ensures that planned information
security architecture changes are
reflected in the security plan, the security
Concept of Operations (CONOPS), and
organizational procurements/acquisitions.

References: None.
PL-8 (1); PLANNING; Information PL-8 (1)
Security Architecture - Enhancement: a. Not appropriate for DoD to define for all CSP's
Defense-In-Depth infrastructure or service offerings

The organization designs its security a. Not appropriate for DoD to define for all CSP's
architecture using a defense-in-depth infrastructure or service offerings
approach that:
(a) Allocates Source:
[Assignment: organization-defined DoD RMF TAG
security safeguards] -------------------
to
[Assignment: organization-defined
locations and architectural layers];
and
(b) Ensures that the allocated security
safeguards operate in a coordinated and
mutually reinforcing manner.

References: None.
PS-1; PERSONNEL SECURITY; PS-1
Personnel Security Policy And a. all personnel
Procedures:
b. (1) every 5 years
The organization: b (2) annually
a. Develops, documents, and
disseminates to Source:
[Assignment: organization-defined DoD RMF TAG
personnel or roles]: -------------------
1. A personnel security policy that
addresses purpose, scope, roles, PS-1.b.1 [at least every 3 years]
responsibilities, management PS-1.b.2 [at least annually]
commitment, coordination among
organizational entities, and compliance; Source:
and FedRAMP v2
2. Procedures to facilitate the -------------------
implementation of the personnel security
policy and associated personnel
security controls; and
b. Reviews and updates the current:
1. Personnel security policy
[Assignment: organization-defined
frequency];
and
2. Personnel security procedures
[Assignment: organization-defined
frequency].

References: None.
PS-2; PERSONNEL SECURITY; PS-2
Position Categorization c. Annually
RENAMED: Position Risk Designation:
Source:
The organization: DoD RMF TAG
a. Assigns a risk designation to all -------------------
organizational positions;
b. Establishes screening criteria for PS-2c. [at least every three years]
individuals filling those positions; and
c. Reviews and updates position risk Source:
designations [Assignment: FedRAMP v2
organization-defined frequency]. -------------------

References: None.
PS-3; PERSONNEL SECURITY;
Personnel Screening:
The organization:
a. Screens individuals prior to
authorizing access to the information
system; and
b. Rescreens individuals according to
[Assignment: organization-defined
conditions requiring rescreening and,
where rescreening is so indicated, the
frequency of such rescreening].
PS-3
b. Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
Source:
DoD RMF TAG
-------------------
PS-3b. [for national security clearances; a reinvestigation
is required during the 5th year for top secret security
clearance, the 10th year for secret security clearance, and
15th year for confidential security clearance.

References: None. For moderate risk law enforcement and high impact public
trust level, a reinvestigation is required during the 5th
year. There is no reinvestigation for other moderate risk
positions or any low risk positions]

Source:
FedRAMP v2
-------------------
PS-3 (3); PERSONNEL SECURITY; PS-3 (3)
Personnel Screening - Enhancement: b. Not appropriate for DoD to define for all CSP's
Information With Special Protection infrastructure or service offerings
Measures
Source:
The organization ensures that individuals DoD RMF TAG
accessing an information system -------------------
processing, storing, or transmitting
information requiring special protection: PS-3 (3)(b). [personnel screening criteria – as required
(a) Have valid access authorizations that by specific information]
are demonstrated by assigned official
government duties; and Source:
(b) Satisfy FedRAMP v2
[Assignment: organization-defined -------------------
additional personnel screening
criteria].

References: None.
PS-4; PERSONNEL SECURITY; PS-4
Personnel Termination: a. immediately

The organization, upon termination of
individual employment:
a. Disables information system access
within
[Assignment: organization-defined
c. Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
f. at a minimum, the ISSO and personnel responsible for
revoking credentials
time period];
b. Terminates/revokes any f. immediately or within 24 hours
authenticators/credentials associated with
the individual; Source:
c. Conducts exit interviews that include a DoD RMF TAG
discussion of -------------------
[Assignment: organization-defined
information security topics]; PS-4.a. [same day]
d. Retrieves all security-related
organizational information system- Source:
related property; FedRAMP v2
e. Retains access to organizational -------------------
information and information systems
formerly controlled by terminated
individual; and
f. Notifies
[Assignment: organization-defined
personnel or roles]
within
[Assignment: organization-defined
time period].

References: NIST Special Publication

800-35.
PS-5; PERSONNEL SECURITY; PS-5
Personnel Transfer: b. actions to ensure all system accesses no longer required
are removed
The organization:
a. Reviews and confirms ongoing b. immediately
operational need for current logical and
physical access authorizations to d. at a minimum, the ISSO and personnel responsible for
information systems/facilities when transferring credentials
individuals are reassigned or transferred
to other positions within the d. 24 hours
organization;
b. Initiates Source:
[Assignment: organization-defined DoD RMF TAG
transfer or reassignment actions] -------------------
within
[Assignment: organization-defined PS-5. [within five days of the formal transfer action (DoD
time period following the formal 24 hours)]
transfer action];
c. Modifies access authorization as Source:
needed to correspond with any changes FedRAMP v2
in operational need due to reassignment -------------------
or transfer; and
d. Notifies
[Assignment: organization-defined
personnel or roles]
within
[Assignment: organization-defined
time period].

References: FIPS Publication 199; NIST

Special Publications 800-30, 800-39,
800-60.
PS-6; PERSONNEL SECURITY; PS-6
Access Agreements: b. annually

The organization: c (2) when there is a change to the user's level of access
a. Develops and documents access
agreements for organizational Source:
information systems; DoD RMF TAG
b. Reviews and updates the access -------------------
agreements
[Assignment: organization-defined PS-6b. [at least annually]
frequency]; PS-6c.2. [at least annually]
and
c. Ensures that individuals requiring Source:
access to organizational information and FedRAMP v2
information systems: -------------------
1. Sign appropriate access agreements
prior to being granted access; and
2. Re-sign access agreements to
maintain access to organizational
information systems when access
agreements have been updated or
[Assignment: organization-defined
frequency].

References: OMB Memorandum 04-04;

NIST Special Publication 800-30, 800-
39; Web: idmanagement.gov.
PS-7; PERSONNEL SECURITY; Third- PS-7
Party Personnel Security: d. at a minimum, the ISSO and personnel responsible for
transferring credentials
The organization:
a. Establishes personnel security d. immediately
requirements including security roles and
responsibilities for third-party providers; Source:
b. Requires third-party providers to DoD RMF TAG
comply with personnel security policies -------------------
and procedures established by the
organization; PS-7d. organization-defined time period – same day
c. Documents personnel security
requirements; Source:
d. Requires third-party providers to FedRAMP v2
notify -------------------
[Assignment: organization-defined
personnel or roles]
of any personnel transfers or terminations
of third-party personnel who possess
organizational credentials and/or badges,
or who have information system
privileges within
[Assignment: organization-defined
time period];
and
e. Monitors provider compliance.
References: None.
PS-8; PERSONNEL SECURITY; PS-8
Personnel Sanctions: b. at a minimum, the ISSO

The organization: b. immediately

a. Employs a formal sanctions process
for individuals failing to comply with Source:
established information security policies DoD RMF TAG
and procedures; and -------------------
b. Notifies
[Assignment: organization-defined
personnel or roles]
within
[Assignment: organization-defined
time period]
when a formal employee sanctions
process is initiated, identifying the
individual sanctioned and the reason for
the sanction.

References: None.
RA-1; RISK ASSESSMENT; Risk RA-1
Assessment Policy And Procedures: a. at a minimum, the ISSM and ISSO

The organization: b. (1) every five years

a. Develops, documents, and b. (2) annually
disseminates to
[Assignment: organization-defined Source:
personnel or roles]: DoD RMF TAG
1. A risk assessment policy that -------------------
addresses purpose, scope, roles,
responsibilities, management RA-1.b.1 [at least every 3 years]
commitment, coordination among RA-1.b.2 [at least annually]
organizational entities, and compliance;
and Source:
2. Procedures to facilitate the FedRAMP v2
implementation of the risk assessment -------------------
policy and associated risk assessment
controls;
and
b. Reviews and updates the current:
1. Risk assessment policy
[Assignment: organization-defined
frequency];
and
2. Risk assessment procedures
[Assignment: organization-defined
frequency].

References: None.
RA-3; RISK ASSESSMENT; Risk RA-3
Assessment: b. a risk assessment report
c. upon re-accreditation
The organization:
a. Conducts an assessment of risk,
including the likelihood and magnitude
of harm, from the unauthorized access,
use, disclosure, disruption, modification,
or destruction of the information system
and the information it processes, stores,
or transmits;
b. Documents risk assessment results in
[Selection:
- security plan;
- risk assessment report;
- [Assignment: organization-defined
document]
];
c. Reviews risk assessment results
[Assignment: organization-defined
frequency];
d. Disseminates risk assessment results to
[Assignment: organization-defined
personnel or roles]; and
e. Updates the risk assessment
[Assignment: organization-defined
frequency]
or whenever there are significant changes
to the information system or environment
of operation (including the identification
of new threats and vulnerabilities), or
other conditions that may impact the
security state of the system.
References: None.
RA-5; RISK ASSESSMENT;
Vulnerability Scanning:
The organization:
a. Scans for vulnerabilities in the
information system and hosted
applications
[Assignment: organization-defined
frequency and/or randomly in
accordance with organization-defined
process]
and when new vulnerabilities potentially
affecting the system/applications are
identified and reported;
b. Employs vulnerability scanning tools
and techniques that facilitate
interoperability among tools and
automate parts of the vulnerability
management process by using standards
for:
1. Enumerating platforms, software
flaws, and improper configurations;
2. Formatting checklists and test
d. ISSM, ISSO, AO, and PM
e. upon re-accreditation
Source:
DoD RMF TAG
-------------------
RA-3b. [security assessment report]
RA-3c. [at least every three years or when a significant
change occurs]
RA-3e. [at least every three years or when a significant
change occurs]
Source:
FedRAMP v2
-------------------
FedRAMP Additional Requirements and Guidance:
Guidance: Significant change is defined in NIST Special
Publication 800-37 Revision 1, Appendix F.
RA-3d. Requirement: to include the Authorizing Official;
for JAB authorizations to include FedRAMP
RA-5
a. every 30 days or as directed by an authorative source
(e.g. IAVM, CTOs, DTMs, STIGs)
d. IAW an authoritative source (e.g. IAVM, CTOs,
DTMs)
e. at a minimum, the ISSM and ISSO
Source:
DoD RMF TAG
-------------------
RA-5a. [monthly operating system/infrastructure; monthly
web applications and databases]
RA-5d. [high-risk vulnerabilities mitigated within thirty
days from date of discovery; moderate-risk vulnerabilities
mitigated within ninety days from date of discovery]
Source:
FedRAMP v2
-------------------
procedures; and
3. Measuring vulnerability impact; FedRAMP Additional Requirements and Guidance:
c. Analyzes vulnerability scan reports RA-5a. Requirement: an accredited independent assessor
and results from security control scans operating systems/infrastructure, web applications,
assessments; and databases once annually.
d. Remediates legitimate vulnerabilities RA-5e. Requirement: to include the Risk Executive; for
[Assignment: organization-defined JAB authorizations to include FedRAMP
response times]
in accordance with an organizational
assessment of risk; and
e. Shares information obtained from the
vulnerability scanning process and
security control assessments with
[Assignment: organization-defined
personnel or roles]
to help eliminate similar vulnerabilities
in other information systems (i.e.,
systemic weaknesses or deficiencies).

References: None.
RA-5 (2); RISK ASSESSMENT; RA-5 (2)
Vulnerability Scanning - Enhancement: prior to running scans
Update By Frequency / Prior To New
Scan / When Identified Source:
DoD RMF TAG
The organization updates the information -------------------
system vulnerabilities scanned
[Selection (one or more): RA-5 (2). [prior to a new scan]
- [Assignment: organization-defined
frequency]; Source:
- prior to a new scan; FedRAMP v2
- when new vulnerabilities are -------------------
identified and reported
].

References: None.
RA-5 (5); RISK ASSESSMENT; RA-5 (5)
Vulnerability Scanning - Enhancement: all information systems and infrastructure components
Privileged Access
Not appropriate for DoD to define for all CSP's
The information system implements infrastructure or service offerings
privileged access authorization to
[Assignment: organization-identified Source:
information system components] DoD RMF TAG
for selected -------------------
[Assignment: organization-defined
vulnerability scanning activities]. RA-5 (5). [operating systems / web applications /
databases] [all scans]
References: NIST Special Publication
800-65. Source:
FedRAMP v2
-------------------
SA-1; SYSTEM AND SERVICES SA-1
ACQUISITION; System And Services a. all personnel
Acquisition Policy And Procedures:
b. (1) every 5 years
The organization: b. (2) annually
a. Develops, documents, and
disseminates to Source:
[Assignment: organization-defined DoD RMF TAG
personnel or roles]: -------------------
1. A system and services acquisition
policy that addresses purpose, scope, SA-1.b.1 [at least every 3 years]
roles, responsibilities, management SA-1.b.2 [at least annually]
commitment, coordination among
organizational entities, and compliance; Source:
and FedRAMP v2
2. Procedures to facilitate the -------------------
implementation of the system and
services acquisition policy and associated
system and services acquisition controls;
and
b. Reviews and updates the current:
1. System and services acquisition
policy
[Assignment: organization-defined
frequency];
and
2. System and services acquisition
procedures
[Assignment: organization-defined
frequency].

References: None.
SA-3; SYSTEM AND SERVICES SA-3
ACQUISITION; Life Cycle Support a. Not appropriate for DoD to define for all CSP's
RENAMED: System Development Life infrastructure or service offerings
Cycle:
Source:
The organization: DoD RMF TAG
a. Manages the information system using -------------------
[Assignment: organization-defined
system development life cycle]
that incorporates information security
considerations;
b. Defines and documents information
security roles and responsibilities
throughout the system development life
cycle;
c. Identifies individuals having
information security roles and
responsibilities; and
d. Integrates the organizational
information security risk management
process into system development life
cycle activities.

References: None.
SA-4 (2); SYSTEM AND SERVICES
ACQUISITION; Acquisitions
RENAMED: Acquisition Process -
Enhancement:
Design / Implementation Information For
Security Controls
SA-4 (2)
Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
Not appropriate for DoD to define for all CSP's
infrastructure or service offerings

The organization requires the developer Source:

of the information system, system DoD RMF TAG
component, or information system -------------------
service to provide design and
implementation information for the [to include security-relevant external system interfaces
security controls to be employed that and high-level design]
includes:
[Selection (one or more): Source:
- security-relevant external system FedRAMP v2
interfaces; -------------------
- high-level design;
- low-level design;
- source code or hardware
schematics;
- [Assignment: organization-defined
design/implementation information]
]
at
[Assignment: organization-defined
level of detail].

References: None.
SA-4 (8); SYSTEM AND SERVICES
ACQUISITION; Acquisition Process -
Enhancement:
Continuous Monitoring Plan
The organization requires the developer
of the information system, system
component, or information system
service to produce a plan for the
continuous monitoring of security control
effectiveness that contains
[Assignment: organization-defined
level of detail].
References: None.
SA-5; SYSTEM AND SERVICES
ACQUISITION; Information System
Documentation:
SA-4 (8)
Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
Source:
DoD RMF TAG
-------------------
SA-4 (8). [at least the minimum requirement as defined in
control CA-7]
Source:
FedRAMP v2
-------------------
FedRAMP Additional Requirements and Guidance:
SA-4 (8) Guidance: CSP must use the same security
standards regardless of where the system component or
information system service is aquired.
SA-5
c. Not appropriate for DoD to define for all CSP's
infrastructure or service offerings

The organization: e. at a minimum, the ISSO, ISSM, and SCA

a. Obtains administrator documentation
for the information system, system Source:
component, or information system DoD RMF TAG
service that describes: -------------------
1. Secure configuration, installation,
and operation of the system, component,
or service;
2. Effective use and maintenance of
security functions/mechanisms; and
3. Known vulnerabilities regarding
configuration and use of administrative
(i.e., privileged) functions;
b. Obtains user documentation for the
information system, system component,
or information system service that
describes:
1. User-accessible security
functions/mechanisms and how to
effectively use those security
functions/mechanisms;
2. Methods for user interaction, which
enables individuals to use the system,
component, or service in a
more secure manner; and
3. User responsibilities in maintaining
the security of the system, component, or
service;
c. Documents attempts to obtain
information system, system component,
or information system service
documentation when such documentation
is either unavailable or nonexistent and
[Assignment: organization-defined
actions]
in response;
d. Protects documentation as required, in
accordance with the risk management
strategy; and
e. Distributes documentation to
[Assignment: organization-defined
personnel or roles].

References: None.
SA-9; SYSTEM AND SERVICES
ACQUISITION; External Information
System Services:
The organization:
a. Requires that providers of external
information system services comply with
organizational information security
requirements and employ
[Assignment: organization-defined
security controls]
in accordance with applicable federal
laws, Executive Orders, directives,
SA-9
a. security controls defined by CNSSI 1253
c. Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
Source:
DoD RMF TAG
-------------------
SA-9a. [FedRAMP Security Controls Baseline(s) if
Federal information is processed or stored within the
external system]
policies, regulations, standards, and SA-9c. [Federal/FedRAMP Continuous Monitoring
guidance; requirements must be met for external systems where
b. Defines and documents government Federal information is processed or stored]
oversight and user roles and
responsibilities with regard to external Source:
information system services; and FedRAMP v2
c. Employs -------------------
[Assignment: organization-defined
processes, methods, and techniques]
to monitor security control compliance
by external service providers on an
ongoing basis.

References: None.
SA-9 (1); SYSTEM AND SERVICES SA-9 (1)
ACQUISITION; External Information b. the DoD Component CIO or their delegate(s)
System Services - Enhancement:
Risk Assessments / Organizational Source:
Approvals DoD RMF TAG
-------------------
The organization:
(a) Conducts an organizational SA-9 (1) see Additional Requirement and Guidance
assessment of risk prior to the acquisition
or outsourcing of dedicated information Source:
security services; and FedRAMP v2
(b) Ensures that the acquisition or -------------------
outsourcing of dedicated information
security services is approved by FedRAMP Additional Requirements and Guidance:
[Assignment: organization-defined SA-9 (1). Requirement: The service provider documents
personnel or roles]. all existing outsourced security services and conducts a
risk assessment of future outsourced security services. For
References: None. JAB authorizations, future planned outsourced services
are approved and accepted by the JAB.
SA-9 (2); SYSTEM AND SERVICES SA-9 (2)
ACQUISITION; External Information All external information system services
Systems - Enhancement:
Identification Of Functions / Ports / Source:
Protocols / Services DoD RMF TAG
-------------------
The organization requires providers of
[Assignment: organization-defined SA-9 (2). [All external systems where Federal information
external information system services] is processed, transmitted or stored]
to identify the functions, ports, protocols,
and other services required for the use of Source:
such services. FedRAMP v2
-------------------
References: None.
SA-9 (4); SYSTEM AND SERVICES SA-9 (4)
ACQUISITION; External Information Not appropriate for DoD to define for all CSP's
Systems - Enhancement: infrastructure or service offerings
Consistent Interests Of Consumers And
Providers All external service providers from whom services are
solicited.
The organization employs
 [Assignment: organization-defined Source:
security safeguards] DoD RMF TAG
to ensure that the interests of -------------------
[Assignment: organization-defined
external service providers] SA-9 (4). [All external systems where Federal information
are consistent with and reflect is processed, transmitted or stored]
organizational interests.
Source:
References: None. FedRAMP v2
-------------------
SA-9 (5); SYSTEM AND SERVICES SA-9 (5)
ACQUISITION; External Information Not appropriate for DoD to define for all CSP's
Systems - Enhancement: infrastructure or service offerings
Processing Storage And Service Location
Not appropriate for DoD to define for all CSP's
The organization restricts the location of infrastructure or service offerings
[Selection (one or more):
- information processing; Source:
- information/data; DoD RMF TAG
- information system services -------------------
]
to SA-9 (5). [information processing, transmission,
[Assignment: organization-defined information data, AND information services]
locations]
based on Source:
[Assignment: organization-defined FedRAMP v2
requirements or conditions]. -------------------

References: ISO/IEC 15408; NIST

Special Publication 800-53A; Web:
nvd.nist.gov, cwe.mitre.org,
cve.mitre.org, capec.mitre.org.
SA-10; SYSTEM AND SERVICES SA-10
ACQUISITION; Developer b. Not appropriate for DoD to define for all CSP's
Configuration Management: infrastructure or service offerings

The organization requires the developer
of the information system, system
component, or information system
service to:
a. Perform configuration management
during system, component, or service
[Selection (one or more):
- design;
- development;
- implementation;
- operation
];
b. Document, manage, and control the
integrity of changes to
[Assignment: organization-defined
configuration items under
configuration management];
c. Implement only organization-approved
e. at a minimum, the ISSO and ISSM
Source:
DoD RMF TAG
-------------------
SA-10a. [development, implementation, AND operation]
Source:
FedRAMP v2
-------------------
FedRAMP Additional Requirements and Guidance:
SA-10e. Requirement: for JAB authorizations, track
security flaws and flaw resolution within the system,
component, or service and report findings to organization-
defined personnel, to include FedRAMP.
changes to the system, component, or
service;
d. Document approved changes to the
system, component, or service and the
potential security impacts of such
changes; and
e. Track security flaws and flaw
resolution within the system, component,
or service and report findings to
[Assignment: organization-defined
personnel].

References: None.
SA-11; SYSTEM AND SERVICES SA-11
ACQUISITION; Developer Security b. Not appropriate for DoD to define for all CSP's
Testing infrastructure or service offerings
RENAMED: Developer Security Testing
And Evaluation: Source:
DoD RMF TAG
The organization requires the developer -------------------
of the information system, system
component, or information system
service to:
a. Create and implement a security
assessment plan;
b. Perform
[Selection (one or more):
- unit;
- integration;
- system;
- regression
]
testing/evaluation at
[Assignment: organization-defined
depth and coverage];
c. Produce evidence of the execution of
the security assessment plan and the
results of the security testing/evaluation;
d. Implement a verifiable flaw
remediation process; and
e. Correct flaws identified during security
testing/evaluation.

References: None.
SA-12; SYSTEM AND SERVICES SA-12
ACQUISITION; Supply Chain measures of protection IAW DoDI 5200.44, "Protection of
Protection: Mission Critical Functions to Achieve Trusted Systems
and Networks (TSN)"
The organization protects against supply
chain threats to the information system, Source:
system component, or information DoD RMF TAG
system service by employing -------------------
[Assignment: organization-defined
security safeguards]
as part of a comprehensive, defense-in-
breadth information security strategy.

References: None.
SA-19; SYSTEM AND SERVICES SA-19
ACQUISITION; Component b. at a minimum, USCYBERCOM
Authenticity:
b. at a minimum, the ISSO, ISSM, and PM
The organization:
a. Develops and implements anti- Source:
counterfeit policy and procedures that DoD RMF TAG
include the means to detect and prevent -------------------
counterfeit components from entering the
information system; and
b. Reports counterfeit information system
components to
[Selection (one or more):
- source of counterfeit component;
- [Assignment: organization-defined
external reporting organizations];
- [Assignment: organization-defined
personnel or roles]
].

References: None.
SC-1; SYSTEM AND SC-1
COMMUNICATIONS PROTECTION; a. at a minimum, the ISSM/ISSO
System And Communications Protection
Policy And Procedures: b. (1) every 5 years
b. (2) annually
The organization:
a. Develops, documents, and Source:
disseminates to DoD RMF TAG
[Assignment: organization-defined -------------------
personnel or roles]:
1. A system and communications SC-1.b.1 [at least every 3 years]
protection policy that addresses purpose, SC-1.b.2 [at least annually]
scope, roles, responsibilities,
management commitment, coordination Source:
among organizational entities, and FedRAMP v2
compliance; and -------------------
2. Procedures to facilitate the
implementation of the system and
communications protection policy and
associated system and communications
protection controls;
and
b. Reviews and updates the current:
1. System and communications
protection policy
[Assignment: organization-defined
frequency]; and
2. System and communications
protection procedures
 [Assignment: organization-defined
frequency].

References: None.
SC-5; SYSTEM AND SC-5
COMMUNICATIONS PROTECTION; Not appropriate for DoD to define for all CSP's
Denial Of Service Protection: infrastructure or service offerings

The information system protects against Not appropriate for DoD to define for all CSP's
or limits the effects of the following infrastructure or service offerings
types of denial of service attacks:
[Assignment: organization-defined Source:
types of denial of service attacks or DoD RMF TAG
reference to -------------------
source for such information]
by employing
[Assignment: organization-defined
security safeguards].

References: None.
SC-6; SYSTEM AND SC-6
COMMUNICATIONS PROTECTION; Not appropriate for DoD to define for all CSP's
Resource Priority infrastructure or service offerings
RENAMED: Resource Availability:
Not appropriate for DoD to define for all CSP's
The information system protects the infrastructure or service offerings
availability of resources by allocating
[Assignment: organization-defined Source:
resources] DoD RMF TAG
by -------------------
[Selection (one or more);
- priority;
- quota;
- [Assignment: organization-defined
security safeguards]
].

References: None.
SC-7 (4); SYSTEM AND SC-7 (4)
COMMUNICATIONS PROTECTION; e. every 180 days
Boundary Protection - Enhancement:
External Telecommunications Services Source:
DoD RMF TAG
The organization: -------------------
(a) Implements a managed interface for
each external telecommunication service; SC-7 (4). [at least annually]
(b) Establishes a traffic flow policy for
each managed interface; Source:
(c) Protects the confidentiality and FedRAMP v2
integrity of the information being -------------------
transmitted across each interface;
(d) Documents each exception to the
traffic flow policy with a supporting
mission/business need and duration of
that need; and
(e) Reviews exceptions to the traffic flow
policy
[Assignment: organization-defined
frequency]
and removes exceptions that are no
longer supported by an explicit
mission/business need.

References: None.
SC-7 (8); SYSTEM AND
COMMUNICATIONS PROTECTION;
Boundary Protection - Enhancement:
Route Traffic To Authenticated Proxy
Servers
SC-7 (8)
protocols as designated by PPSM guidance (e.g. HTTPS,
HTTP, FTP, SNMP)
any network external to the authorization boundary

The information system routes Source:

[Assignment: organization-defined DoD RMF TAG
internal communications traffic] -------------------
to
[Assignment: organization-defined
external networks]
through authenticated proxy servers at
managed interfaces.

References: None.
SC-7 (11); SYSTEM AND SC-7 (11)
COMMUNICATIONS PROTECTION; Not appropriate for DoD to define for all CSP's
Boundary Protection - Enhancement: infrastructure or service offerings
Restrict Incoming Communications
Traffic Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
The information system only allows
incoming communications from Source:
[Assignment: organization-defined DoD RMF TAG
authorized sources] -------------------
routed to
[Assignment: organization-defined
authorized destinations].

References: None.
SC-7 (12); SYSTEM AND SC-7 (12)
COMMUNICATIONS PROTECTION; McAfee Host Intrusion Prevention (HIPS)
Boundary Protection - Enhancement:
Host-Based Protection All information system components.

The organization implements Source:

[Assignment: organization-defined
host-based boundary protection
mechanisms]
at
[Assignment: organization-defined
information system components].
DoD RMF TAG
NOTE: DISA will evaluate Commercial CSP
equivalencies on a case by case basis.
-------------------
References: None.
SC-7 (13); SYSTEM AND
COMMUNICATIONS PROTECTION;
Boundary Protection - Enhancement:
Isolation Of Security Tools /
Mechanisms / Support Components
The organization isolates
[Assignment: organization-defined
information security tools,
mechanisms, and support components]
from other internal information system
components by implementing physically
separate subnetworks with managed
interfaces to other components of the
system.
References: None.
SC-7 (14); SYSTEM AND
COMMUNICATIONS PROTECTION;
Boundary Protection - Enhancement:
Protects Against Unauthorized Physical
Connections
The organization protects against
unauthorized physical connections at
[Assignment: organization-defined
managed interfaces].
References: None.
SC-8 (1); SYSTEM AND
COMMUNICATIONS PROTECTION;
Transmission Integrity
RENAMED: Transmission
Confidentiality And Integrity -
Enhancement:
Cryptographic Or Alternate Physical
Protection
The information system implements
cryptographic mechanisms to
[Selection (one or more):
- prevent unauthorized disclosure of FedRAMP v2
information;
- detect changes to information
]
during transmission unless otherwise
protected by
[Assignment: organization-defined
SC-7 (13)
key information security tools, mechanisms, and support
components such as, but not limited to PKI, Patching
infrastructure, HBSS, CND Tools, Special Purpose
Gateway, vulnerability tracking systems, honeypots,
internet access points (IAPs); network element and data
center administrative/management traffic; Demilitarized
Zones (DMZs), Server farms/computing centers,
centralized audit log servers etc.
Source:
DoD RMF TAG
-------------------
FedRAMP Additional Requirements and Guidance:
SC-7 (13). Requirement: The service provider defines key
information security tools, mechanisms, and support
components associated with system and security
administration and isolates those tools, mechanisms, and
support components from other internal information
system components via physically or logically separate
subnets.
SC-7 (14)
internet access points, enclave LAN to WAN, cross
domain solutions, and any DoD Approved Alternate
Gateways.
Source:
DoD RMF TAG
-------------------
SC-8 (1)
Protected Distribution System (PDS)
Source:
DoD RMF TAG
-------------------
SC-8 (1). [prevent unauthorized disclosure of information
AND detect changes to information] [a hardened or
alarmed carrier Protective Distribution System (PDS)]
Source:
-------------------
alternative physical safeguards].

References: None.
SC-8 (2); SYSTEM AND missing????
COMMUNICATIONS PROTECTION;
Transmission Integrity Source:
RENAMED: Transmission DoD RMF TAG
Confidentiality And Integrity - -------------------
Enhancement:
Pre / Post Transmission Handling

The information system maintains the

[Selection (one or more):
- confidentiality;
- integrity
]
of information during preparation for
transmission and during reception.

References: None.
SC-10; SYSTEM AND SC-10
COMMUNICATIONS PROTECTION; 10 minutes in band management and 15 minutes for user
Network Disconnect: sessions

The information system terminates the Source:

network connection associated with a DoD RMF TAG
communications session at the end of the -------------------
session or after
[Assignment: organization-defined SC-10. [no longer than 30 minutes for RAS-based
time period] of inactivity. sessions or no longer than 60 minutes for non-interactive
user sessions]
References: None.
Source:
FedRAMP v2
-------------------
SC-12; SYSTEM AND SC-12
COMMUNICATIONS PROTECTION; DoDI 8520.02 "Public Key Infrastructure and Public Key
Cryptographic Key Establishment And Enabling" and DoDI 8520.03 "Identity Authentication for
Management: Information Systems"

The organization establishes and Source:

manages cryptographic keys for required DoD RMF TAG
cryptography employed within the -------------------
information system in accordance with
[Assignment: organization-defined FedRAMP Additional Requirements and Guidance:
requirements for key generation, SC-12 Guidance: Federally approved cryptography
distribution, storage, access, and
destruction].

References: None.
SC-12 (2); SYSTEM AND
COMMUNICATIONS PROTECTION;
Cryptographic Key Establishment And
Management - Enhancement:
SC-12 (2)
NIST Approved for Unclassified systems
NSA Approved for Classified systems
Symmetric Keys Source:
DoD RMF TAG
The organization produces, controls, and -------------------
distributes symmetric cryptographic keys
using SC-12 (2). [NIST FIPS-compliant]
[Selection:
- NIST FIPS-compliant; Source:
- NSA-approved FedRAMP v2
] -------------------
key management technology and
processes.

References: None.
SC-13; SYSTEM AND SC-13
COMMUNICATIONS PROTECTION; Protection of classified information: NSA-approved
Use Of Cryptography cryptography; provision of digital signatures and hashing:
RENAMED: Cryptographic Protection: FIPS-validated cryptography

The information system implements Source:

[Assignment: organization-defined DoD RMF TAG
cryptographic uses and type of -------------------
cryptography required for each use]
in accordance with applicable federal [FIPS-validated or NSA-approved cryptography]
laws, Executive Orders, directives,
policies, regulations, and standards. Source:
FedRAMP v2
References: None. -------------------
SC-15; SYSTEM AND SC-15
COMMUNICATIONS PROTECTION; Dedicated VTC suites located in approved VTC locations
Collaborative Computing Devices: that are centrally managed

The information system: Source:

a. Prohibits remote activation of DoD RMF TAG
collaborative computing devices with the -------------------
following exceptions:
[Assignment: organization-defined SC-15a. [no exceptions]
exceptions where remote activation is
to be allowed]; Source:
and FedRAMP v2
b. Provides an explicit indication of use -------------------
to users physically present at the devices.

References: NIST Special Publication

800-28; DoD Instruction 8552.01
SC-17; SYSTEM AND SC-17
COMMUNICATIONS PROTECTION; DoDI 8520.02, "Public Key Infrastructure (PKI) and
Public Key Infrastructure Certificates: Public Key (PK) Enabling.

The organization issues public key Source:

certificates under an DoD RMF TAG
[Assignment: organization-defined -------------------
certificate policy]
or obtains public key certificates from an
approved service provider.
References: OMB Memorandum 08-23;
NIST Special Publication 800-81
SC-18 (4); SYSTEM AND SC-18 (4)
COMMUNICATIONS PROTECTION; DoDI 8552.01 "Use of Mobile Code Technologies in DoD
Mobile Code - Enhancement: Information Systems"
Prevent Automatic Execution
the user be prompted
The information system prevents the
automatic execution of mobile code in Source:
[Assignment: organization-defined DoD RMF TAG
software applications] -------------------
and enforces
[Assignment: organization-defined
actions] prior to executing the code.

References: NIST Special Publication

800-81
SC-23 (3); SYSTEM AND SC-23 (3)
COMMUNICATIONS PROTECTION; Not appropriate for DoD to define for all CSP's
Session Authenticity - Enhancement: infrastructure or service offerings
Unique Session Identifiers With
Randomization Source:
DoD RMF TAG
The information system generates a -------------------
unique session identifier for each session
with
[Assignment: organization-defined
randomness requirements]
and recognizes only session identifiers
that are system-generated.

References: NIST Special Publications

800-56, 800-57, 800-111
SC-23 (5); SYSTEM AND SC-23 (5)
COMMUNICATIONS PROTECTION; DoD PKI established certificate authorities.
Session Authenticity - Enhancement:
Allowed Certificate Authorities Source:
DoD RMF TAG
The information system only allows the -------------------
use of
[Assignment: organization-defined
certificate authorities]
for verification of the establishment of
protected sessions.

References: None.
SC-28; SYSTEM AND
COMMUNICATIONS PROTECTION;
Protection Of Information At Rest:
The information system protects the
[Selection (one or more):
- confidentiality;
SC-28
Not appropriate for DoD to define for all CSP's
infrastructure or service offerings. At a minimum, must
include PII and classified information.
Source:
DoD RMF TAG
 - integrity -------------------
]
of SC-28. [confidentiality AND integrity]
[Assignment: organization-defined
information at rest]. Source:
FedRAMP v2
References: None. -------------------

FedRAMP Additional Requirements and Guidance:

SC-28. Guidance: The organization supports the capability
to use cryptographic mechanisms to protect information at
rest.
SC-28 (1); SYSTEM AND SC-28 (1)
COMMUNICATIONS PROTECTION; Not appropriate for DoD to define for all CSP's
Protection Of Information At Rest - infrastructure or service offerings. At a minimum, PII and
Enhancement: classified information.
Cryptographic Protection
any information system components storing data defined
The information system implements in SC-28 (1), 2473
cryptographic mechanisms to prevent
unauthorized disclosure and modification Source:
of DoD RMF TAG
[Assignment: organization-defined -------------------
information]
on
[Assignment: organization-defined
information system components].

References: None.
SI-1; SYSTEM AND INFORMATION SI-1
INTEGRITY; System And Information a. all appointed information assurance personnel
Integrity Policy And Procedures:
b. (1) every 5 years
The organization: b. (2) annually
a. Develops, documents, and
disseminates to Source:
[Assignment: organization-defined DoD RMF TAG
personnel or roles]: -------------------
1. A system and information integrity
policy that addresses purpose, scope, SI-1.b.1 [at least every 3 years]
roles, responsibilities, management SI-1.b.2 [at least annually]
commitment, coordination among
organizational entities, and compliance; Source:
and FedRAMP v2
2. Procedures to facilitate the -------------------
implementation of the system and
information integrity policy and
associated
system and information integrity
controls; and
b. Reviews and updates the current:
1. System and information integrity
policy
[Assignment: organization-defined
frequency]; and
2. System and information integrity
procedures
[Assignment: organization-defined
frequency].

References: NIST Special Publication

800-83.
SI-2; SYSTEM AND INFORMATION SI-2
INTEGRITY; Flaw Remediation: c. within the time period directed by an authorative source
(e.g. IAVM, CTOs, DTMs, STIGs)
The organization:
a. Identifies, reports, and corrects Source:
information system flaws; DoD RMF TAG
b. Tests software and firmware updates -------------------
related to flaw remediation for
effectiveness and potential side effects SI-2c. [Within 30 days of release of updates]
before installation;
c. Installs security-relevant software and Source:
firmware updates within FedRAMP v2
[Assignment: organization-defined -------------------
time period]
of the release of the updates; and
d. Incorporates flaw remediation into the
organizational configuration management
process.

References: None.
SI-2 (2); SYSTEM AND SI-2 (2)
INFORMATION INTEGRITY; Flaw Continuously with HBSS 30 days for any additional
Remediation - Enhancement: internal network scans not covered by HBSS Annually for
Automated Flaw Remediation Status external scans by (Computer Network Defense Service
Provider) CNDSP
The organization employs automated
mechanisms Source:
[Assignment: organization-defined DoD RMF TAG
frequency] -------------------
to determine the state of information
system components with regard to flaw SI-2 (2). [at least monthly]
remediation.
Source:
References: None. FedRAMP v2
-------------------
SI-2 (3); SYSTEM AND SI-2 (3)
INFORMATION INTEGRITY; Flaw b. within the period directed by an authorative source (e.g.
Remediation - Enhancement: IAVM, CTOs, DTMs, STIGs)
Time To Remediate Flaws / Benchmarks
For Corrective Actions Source:
DoD RMF TAG
The organization: -------------------
(a) Measures the time between flaw
identification and flaw remediation; and
(b) Establishes
[Assignment: organization-defined
benchmarks]
for taking corrective actions.

References: None.
SI-2 (6); SYSTEM AND SI-2 (6)
INFORMATION INTEGRITY; Flaw All upgraded/replaced software and firmware components
Remediation - Enhancement: that are no longer required for operation
Removal Of Previous Versions Of
Software / Firmware Source:
DoD RMF TAG
The organization removes -------------------
[Assignment: organization-defined
software and firmware components]
after updated versions have been
installed.

References: None.
SI-3; SYSTEM AND INFORMATION SI-3
INTEGRITY; Malicious Code c (1). every 7 days
Protection: c (2). Block and quarantine malicious code and then send
an alert to the administrator immediately in near real-time
The organization:
a. Employs malicious code protection Source:
mechanisms at information system entry DoD RMF TAG
and exit points to detect and eradicate -------------------
malicious code;
b. Updates malicious code protection SI-3.c.1 [at least weekly] [to include endpoints]
mechanisms whenever new releases are SI-3.c.2 [to include alerting administrator or defined
available in accordance with security personnel]
organizational configuration management
policy and procedures; Source:
c. Configures malicious code protection FedRAMP v2
mechanisms to: -------------------
1. Perform periodic scans of the
information system
[Assignment: organization-defined
frequency]
and real-time scans of files from external
sources at
[Selection (one or more);
- endpoint;
- network entry/exit points
]
as the files are downloaded, opened, or
executed in accordance with
organizational security policy; and
2. [Selection (one or more):
- block malicious code;
- quarantine malicious code;
- send alert to administrator;
- [Assignment: organization-
defined action]
]
in response to malicious code detection;
and
d. Addresses the receipt of false positives
during malicious code detection and
eradication and the resulting potential
impact on the availability of the
information system.

References: None.
SI-3 (10); SYSTEM AND SI-3 (10)
INFORMATION INTEGRITY; a. Not appropriate for DoD to define for all CSP's
Malicious Code Protection - infrastructure or service offerings
Enhancement:
Malicious Code Analysis Source:
DoD RMF TAG
The organization: -------------------
(a) Employs
[Assignment: organization-defined
tools and techniques]
to analyze the characteristics and
behavior of malicious code; and
(b) Incorporates the results from
malicious code analysis into
organizational incident response and flaw
remediation processes.

References: None.
SI-4; SYSTEM AND INFORMATION SI-4
INTEGRITY; Information System a. (1) sensor placement and monitoring requirements
Monitoring: within CJCSI 6510.01F

The organization: a. (2) Not appropriate for DoD to define for all CSP's
a. Monitors the information system to infrastructure or service offerings
detect:
1. Attacks and indicators of potential g. (1) Not appropriate for DoD to define for all CSP's
attacks in accordance with infrastructure or service offerings
[Assignment: organization-defined
monitoring objectives]; and g. (2) Not appropriate for DoD to define for all CSP's
2. Unauthorized local, network, and infrastructure or service offerings
remote connections;
b. Identifies unauthorized use of the g. (3) Not appropriate for DoD to define for all CSP's
information system through infrastructure or service offerings
[Assignment: organization-defined
techniques and methods]; Source:
c. Deploys monitoring devices: DoD RMF TAG
(i) strategically within the information -------------------
system to collect organization-
determined essential information; and
(ii) at ad hoc locations within the system
to track specific types of transactions of
interest to the organization;
d. Protects information obtained from
intrusion-monitoring tools from
unauthorized access, modification, and
deletion;
e. Heightens the level of information
system monitoring activity whenever
there is an indication of increased risk to
organizational operations and assets,
individuals, other organizations, or the
Nation based on law enforcement
information, intelligence information, or
other credible sources of information;
f. Obtains legal opinion with regard to
information system monitoring activities
in accordance with applicable federal
laws, Executive Orders, directives,
policies, or regulations; and
g. Provides
[Assignment: organization-defined
information system monitoring
information] to
[Assignment: organization-defined
personnel or roles]
[Selection (one or more):
- as needed;
- [Assignment: organization-defined
frequency]].

References: None.
SI-4 (4); SYSTEM AND SI-4 (4)
INFORMATION INTEGRITY; Continuously
Information System Monitoring -
Enhancement: Source:
Inbound And Outbound Communications DoD RMF TAG
Traffic -------------------

The information system monitors SI-4 (4). [continually]

inbound and outbound communications
traffic Source:
[Assignment: organization-defined FedRAMP v2
frequency] -------------------
for unusual or unauthorized activities or
conditions.

References: None.
SI-4 (5); SYSTEM AND
INFORMATION INTEGRITY;
Information System Monitoring -
Enhancement:
System Generated Alerts
The information system alerts
[Assignment: organization-defined
personnel or roles]
when the following indications of
compromise or potential compromise
occur:
[Assignment: organization-defined
SI-4 (5)
at a minimum, the ISSM and ISSO
Real time intrusion detection and when there are threats
identified by authoritative sources (e.g. CTOs) and IAW
incident categories I, II, IV, & VII within CJCSM
6510.01B
Source:
DoD RMF TAG
-------------------
FedRAMP Additional Requirements and Guidance:
compromise indicators]. SI-4(5) Guidance: In accordance with the incident
response plan.
References: None.
SI-4 (12); SYSTEM AND SI-4 (12)
INFORMATION INTEGRITY; When there are threats identified by authoritative sources
Information System Monitoring - (e.g. CTOs) and IAW with CJCSM 6510.01B
Enhancement:
Automated Alerts Source:
DoD RMF TAG
The organization employs automated -------------------
mechanisms to alert security personnel of
the following inappropriate or unusual
activities with security implications:
[Assignment: organization-defined
activities that trigger alerts].

References: None.
SI-4 (19); SYSTEM AND SI-4 (19)
INFORMATION INTEGRITY; Not appropriate for DoD to define for all CSP's
Information System Monitoring - infrastructure or service offerings
Enhancement:
Individuals Posing Greater Risk Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
The organization implements
[Assignment: organization-defined Source:
additional monitoring] DoD RMF TAG
of individuals who have been identified -------------------
by
[Assignment: organization-defined
sources]
as posing an increased level of risk.

References: None.
SI-4 (20); SYSTEM AND SI-4 (20)
INFORMATION INTEGRITY; Not appropriate for DoD to define for all CSP's
Information System Monitoring - infrastructure or service offerings
Enhancement:
Privileged User Source:
DoD RMF TAG
The organization implements -------------------
[Assignment: organization-defined
additional monitoring]
of privileged users.

References: None.
SI-4 (22); SYSTEM AND SI-4 (22)
INFORMATION INTEGRITY; at a minimum, the ISSM or ISSO
Information System Monitoring -
Enhancement: at a minimum, the ISSM or ISSO
Unauthorized Network Services
Source:
The information system detects network DoD RMF TAG
services that have not been authorized or -------------------
approved by
 [Assignment: organization-defined
authorization or approval processes]
and
[Selection (one or more):
- audits;
- alerts [Assignment: organization-
defined personnel or roles]
].

References: None.
SI-4 (23); SYSTEM AND SI-4 (23)
INFORMATION INTEGRITY; HBSS
Information System Monitoring -
Enhancement: all components
Host-Based Devices
Source:
The organization implements DoD RMF TAG
[Assignment: organization-defined NOTE: DISA will evaluate Commercial CSP
host-based monitoring mechanisms] equivalencies on a case by case basis.
at -------------------
[Assignment: organization-defined
information system components].

References: NIST Special Publications

800-147, 80-155.
SI-5; SYSTEM AND INFORMATION
INTEGRITY; Security Alerts,
Advisories, And Directives:
The organization:
a. Receives information system security
alerts, advisories, and directives from
[Assignment: organization-defined
external organizations] on an ongoing
basis;
b. Generates internal security alerts,
advisories, and directives as deemed
necessary;
c. Disseminates security alerts,
advisories, and directives to:
[Selection (one or more):
- [Assignment: organization-defined
personnel or roles];
- [Assignment: organization-defined
elements within the organization];
- [Assignment: organization-defined
external organizations]
];
and
d. Implements security directives in
accordance with established time frames,
or notifies the issuing organization of the
degree of noncompliance.
SI-5
a. At a minimum, USCYBERCOM.
c. the ISSO and ISSM
c. not applicable as elements are not selected as recipients
of security alerts, advisories and directives
c. CNDSP Tier 1 for vetting. The CNDSP Tier 1 will pass
the information to the accredited Tier 2 CNDSPs. Tier 2
CNDSPs are responsible for ensuring all Tier 3 entities
receive the information. Tier 3 organizations will ensure
all local Op Centers/LAN shops receive information
(i.e. Component IT System and Security Personnel)
(e.g. ISSM, ISSOs, and system administrators)
Source:
DoD RMF TAG
-------------------
SI-5a. [to include US-CERT]
SI-5c. [to include system security personnel and
administrators with configuration/patch-management
responsibilities]
Source:
FedRAMP v2
-------------------
References: None.
SI-6; SYSTEM AND INFORMATION SI-6
INTEGRITY; Security Functionality a. Not appropriate for DoD to define for all CSP's
Verification: infrastructure or service offerings

The information system: b. upon system startup, and/or restart, upon command by
a. Verifies the correct operation of user with appropriate privileges
[Assignment: organization-defined
security functions]; b. 30 days
b. Performs this verification
[Selection (one or more): c. the ISSO and ISSM
- [Assignment: organization-defined
system transitional states]; d. notifies system administrator
- upon command by user with
appropriate privilege; Source:
- [Assignment: organization-defined DoD RMF TAG
frequency] -------------------
];
c. Notifies SI-6b [to include upon system startup and/or restart at
[Assignment: organization-defined least monthly]
personnel or roles] SI-6c [to include system administrators and security
of failed security verification tests; and personnel]
d. [Selection (one or more): SI-6d [to include notification of system administrators and
- shuts the information system security personnel]
down;
- restarts the information system; Source:
- [Assignment: organization-defined FedRAMP v2
alternative action(s)] -------------------
]
when anomalies are discovered.

References: None.
SI-7; SYSTEM AND INFORMATION SI-7
INTEGRITY; Information System Not appropriate for DoD to define for all CSP's
Monitoring infrastructure or service offerings.
RENAMED: Software, Firmware, And
Information Integrity: Source:
DoD RMF TAG
The organization employs integrity -------------------
verification tools to detect unauthorized
changes to
[Assignment: organization-defined
software, firmware, and information].

References: None.
SI-7 (1); SYSTEM AND SI-7 (1)
INFORMATION INTEGRITY; Not appropriate for DoD to define for all CSP's
Information System Monitoring infrastructure or service offerings
RENAMED: Software, Firmware, And
Information Integrity - Enhancement: Not appropriate for DoD to define for all CSP's
Integrity Checks infrastructure or service offerings

The information system performs an Annually

integrity check of
 [Assignment: organization-defined Source:
software, firmware, and information] DoD RMF TAG
[Selection (one or more): -------------------
- at startup;
- at [Assignment: organization- SI-7 (1). [Selection to include security relevant events and
defined transitional states or security- at least monthly]
relevant events];
- [Assignment: organization-defined Source:
frequency] FedRAMP v2
]. -------------------

References: None.
SI-7 (7); SYSTEM AND SI-7 (7)
INFORMATION INTEGRITY; Not appropriate for DoD to define for all CSP's
Software, Firmware, And Information infrastructure or service offerings
Integrity - Enhancement:
Integration Of Detection And Response Source:
DoD RMF TAG
The organization incorporates the -------------------
detection of unauthorized
[Assignment: organization-defined
security-relevant changes to the
information system]
into the organizational incident response
capability.

References: None.
SI-10; SYSTEM AND INFORMATION SI-10
INTEGRITY; Information Input All inputs except those identified specifically by the
Validation: organization

The information system checks the Source:

validity of DoD RMF TAG
[Assignment: organization-defined -------------------
information inputs].

References: None.
SI-11; SYSTEM AND INFORMATION SI-11
INTEGRITY; Error Handling: b. the ISSO, ISSM, and SCA

The information system: Source:

a. Generates error messages that provide DoD RMF TAG
information necessary for corrective -------------------
actions without revealing information
that could be exploited by adversaries;
and
b. Reveals error messages only to
[Assignment: organization-defined
personnel or roles].

References: None.
SI-16; SYSTEM AND INFORMATION SI-16
INTEGRITY; Memory Protection: Not appropriate for DoD to define for all CSP's
infrastructure or service offerings
The information system implements
[Assignment: organization-defined Source:
security safeguards] DoD RMF TAG
to protect its memory from unauthorized -------------------
code execution.

References: None.

Source: https://iase.disa.mil/cloud_security/cloudsrg/Pages/home.aspx
 This book was distributed courtesy of:

For your own Unlimited Reading and FREE eBooks today, visit:
http://www.Free-eBooks.net

Share this eBook with anyone and everyone automatically by selecting any of the
options below:

To show your appreciation to the author and help others have

wonderful reading experiences and find helpful information too,
we'd be very grateful if you'd kindly
post your comments for this book here.

COPYRIGHT INFORMATION

Free-eBooks.net respects the intellectual property of others. When a book's copyright owner submits their work to Free-eBooks.net, they are granting us permission to distribute such material. Unless
otherwise stated in this book, this permission is not passed onto others. As such, redistributing this book without the copyright owner's permission can constitute copyright infringement. If you
believe that your work has been used in a manner that constitutes copyright infringement, please follow our Notice and Procedure for Making Claims of Copyright Infringement as seen in our Terms
of Service here:

http://www.free-ebooks.net/tos.html