Bidders Library Cybersecurity - DoDI 8510 01.pdf

Department of Defense

INSTRUCTION

NUMBER 8510.01

March 12, 2014

Incorporating Change 2, July 28, 2017

DoD CIO

SUBJECT: Risk Management Framework (RMF) for DoD Information Technology (IT)

References: See Enclosure 1

1. PURPOSE. This instruction:

a. Reissues and renames DoD Instruction (DoDI) 8510.01 (Reference (a)) in accordance with the authority in DoD Directive (DoDD) 5144.02 (Reference (b)).

b. Implements References (c) through (f) by establishing the RMF for DoD IT (referred to in this instruction as “the RMF”), establishing associated cybersecurity policy, and assigning responsibilities for executing and maintaining the RMF. The RMF replaces the DoD Information Assurance Certification and Accreditation Process (DIACAP) and manages the life-cycle cybersecurity risk to DoD IT in accordance with References (g) through (k).

c. Redesignates the DIACAP Technical Advisory Group (TAG) as the RMF TAG.

d. Directs visibility of authorization documentation and reuse of artifacts between and among DoD Components deploying and receiving DoD IT.

e. 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. APPLICABILITY

a. This instruction applies to:

(1) OSD, the Military Departments, the Office of the Chairman of the Joint Chiefs of Staff (CJCS) and the Joint Staff, the Combatant Commands, the Office of the Inspector General of the Department of Defense (OIG DoD), the Defense Agencies, the DoD Field Activities, and

DoDI 8510.01, March 12, 2014

Change 2, 07/28/2017 2 all other organizational entities within the Department of Defense (referred to collectively in this instruction as the “DoD Components”).

(2) The United States Coast Guard. The United States Coast Guard will adhere to DoD cybersecurity requirements, standards, and policies in this instruction in accordance with the direction in Paragraphs 4a, b, c, and d of the Memorandum of Agreement Between the Department of Defense and the Department of Homeland Security (Reference (q)).

(3) All DoD IT that receive, process, store, display, or transmit DoD information. These technologies are broadly grouped as DoD IS, platform IT (PIT), IT services, and IT products.

This includes IT supporting research, development, test and evaluation (T&E), and DoD-controlled IT operated by a contractor or other entity on behalf of the DoD.

b. Nothing in this instruction alters or supersedes the existing authorities and policies of the Director of National Intelligence regarding the protection of sensitive compartmented information (SCI), as directed by Executive Order 12333 (Reference (l)) and other laws and regulations. The application of the provisions and procedures of this instruction to information technologies processing SCI is encouraged where they may complement or cover areas not otherwise specifically addressed.

3. POLICY. It is DoD policy that:

a. The DoD will establish and use an integrated enterprise-wide decision structure for cybersecurity risk management (the RMF) that includes and integrates DoD mission areas (MAs) pursuant to DoDD 8115.01 (Reference (m)) and the governance process prescribed in this instruction.

b. The cybersecurity requirements for DoD information technologies will be managed through the RMF consistent with the principals established in National Institute of Standards and Technology (NIST) Special Publication (SP) 800-37 (Reference (c)). DoD IS and PIT systems will transition to the RMF in accordance with Table 2 of Enclosure 8 of this instruction.

c. The RMF must satisfy the requirements of subchapter III of chapter 35 of Title 44, United States Code (U.S.C.), also known and referred to in this instruction as the “Federal Information Security Management Act (FISMA) of 2002” (Reference (d)). DoD must meet or exceed the standards required by the Office of Management and Budget (OMB) and the Secretary of Commerce, pursuant to FISMA and section 11331 of Title 40, U.S.C. (Reference (n)).

d. All DoD IS and PIT systems must be categorized in accordance with Committee on National Security Systems Instruction (CNSSI) 1253 (Reference (e)), implement a corresponding set of security controls from NIST SP 800-53 (Reference (f)), and use assessment procedures from NIST SP 800-53A (Reference (g)) and DoD-specific assignment values, overlays, implementation guidance, and assessment procedures found on the Knowledge Service (KS) at https://rmfks.osd.mil. As supporting reference security control documents are updated, DoD’s implementation of these updates will be coordinated through the RMF TAG.

Change 2, 07/28/2017 3

e. Resources for implementing the RMF must be identified and allocated as part of the Defense planning, programming, budgeting, and execution process.

f. Each DoD IS, DoD partnered system, and PIT system must have an authorizing official (AO) responsible for authorizing the system’s operation based on achieving and maintaining an acceptable risk posture.

g. Reciprocal acceptance of DoD and other federal agency and department IS and PIT system authorizations will be implemented to the maximum extent possible. Refusals must be timely, documented, and reported to the responsible DoD Component senior information security officer (SISO) (formerly known as the senior information assurance (IA) officer).

h. All DoD IT identified in paragraph 2a(2) must be under the governance of a DoD Component cybersecurity program in accordance with DoDI 8500.01(Reference (h)).

i. A plan of action and milestones (POA&M) must be developed and maintained to address known vulnerabilities in the IS or PIT system.

j. Continuous monitoring capabilities will be implemented to the greatest extent possible.

k. The RMF process will inform acquisition processes for all DoD IT, including requirements development, procurement, and both developmental T&E (DT&E) and operational T&E (OT&E), but does not replace these processes.

4. RESPONSIBILITIES. See Enclosure 2.

5. PROCEDURES. See Enclosure 3.

6. RELEASABILITY. Cleared for public release. This instruction is available the Directives Division Website at http://www.esd.whs.mil/DD/.

Change 2, 07/28/2017 4

7. SUMMARY OF CHANGE. The changes to this issuance are administrative and update the language to include the United States Coast Guard, clarified responsibilities, organizational titles, and references for accuracy.

8. EFFECTIVE DATE. This instruction is effective March 12, 2014.

Enclosures

1. References

2. Responsibilities

3. RMF Procedures

4. RMF Governance

5. Cybersecurity Reciprocity

6. Risk Management of IS and PIT Systems

7. KS

8. RMF Transition Glossary

Change 2, 07/28/2017 CONTENTS 5

TABLE OF CONTENTS

ENCLOSURE 1: REFERENCES

ENCLOSURE 2: RESPONSIBILITIES

DoD CHIEF INFORMATION OFFICER (DoD CIO)

DIRECTOR, DEFENSE INFORMATION SYSTEMS AGENCY (DISA)

UNDER SECRETARY OF DEFENSE FOR ACQUISITION, TECHNOLOGY, AND

LOGISTICS (USD(AT&L))

DASD(DT&E)

DOT&E

DIRECTOR, NATIONAL SECURITY AGENCY/CHIEF, CENTRAL SECURITY

SERVICE (DIRNSA/CHCSS)

DoD COMPONENT HEADS

CJCS

COMMANDER, U.S. STRATEGIC COMMAND (USSTRATCOM)

ENCLOSURE 3: RMF PROCEDURES

OVERVIEW

RISK MANAGEMENT OF IS AND PIT SYSTEMS

RISK MANAGEMENT OF PRODUCTS, SERVICES, AND PIT

IT Products IT Services

PIT

ENCLOSURE 4: RMF GOVERNANCE

RMF GOVERNANCE

Tier 1 - Organization Tier 2 - Mission/Business Processes Tier 3 - IS and PIT Systems

RMF ROLE APPOINTMENT

ENCLOSURE 5: CYBERSECURITY RECIPROCITY

ENCLOSURE 6: RISK MANAGEMENT OF IS AND PIT SYSTEMS

OVERVIEW

Applicability Considerations for Special System Configurations Authorization Approaches Security Plan

RMF STEPS

Change 2, 07/28/2017 CONTENTS 6

Step 1 - Categorize System Step 2 - Select Security Controls Step 3 - Implement Security Controls Step 4 - Assess Security Controls Step 5 - Authorize System Step 6 - Monitor Security Controls

INTEGRATING THE RMF INTO THE DEFENSE ACQUISITION MANAGEMENT

SYSTEM

SECURITY AUTHORIZATION DOCUMENTATION

ENCLOSURE 7: KS

ENCLOSURE 8: RMF TRANSITION

GLOSSARY

PART I: ABBREVIATIONS AND ACRONYMS

PART II: DEFINITIONS

TABLES

1. Appointment of RMF Roles

2. RMF Initial Transition Timeline and Instructions

3. Transition Timeline and Instructions – Updates to CNSSI 1253

FIGURES

1. DoD IT

2. RMF Governance

3. RMF for IS and PIT Systems

4. RMF and the Defense Acquisition Management System

Change 2, 07/28/2017 ENCLOSURE 1 7

ENCLOSURE 1

REFERENCES

(a) DoD Instruction 8510.01, “DoD Information Assurance Certification and Accreditation

Process (DIACAP),” November 28, 2007 (hereby cancelled)

(b) DoD Directive 5144.02, “DoD Chief Information Officer (DoD CIO),” November 21, 2014

(c) National Institute of Standards and Technology Special Publication 800-37, “Guide for

Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach,” February 2010, as amended

(d) Subchapter II of chapter 35 of Title 44, United States Code (also known as the “Federal Information Security Modernization Act (FISMA) of 2014”)

(e) Committee on National Security Systems Instruction 1253, “Security Categorization and Control Selection for National Security Systems,” March 27, 2014, as amended

(f) National Institute of Standards and Technology Special Publication 800-53, “Security and Privacy Controls for Federal Information Systems and Organizations,” current edition

(g) National Institute of Standards and Technology Special Publication 800-53A, “Guide for Assessing the Security Controls in Federal Information Systems and Organizations:

Building Effective Security Assessment Plans,” June 2010, as amended

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

(i) National Institute of Standards and Technology Special Publication 800-39, “Managing

Information Security Risk: Organization, Mission, and Information System View,” March

(j) National Institute of Standards and Technology Special Publication 800-30, “Guide for Conducting Risk Assessments,” September 2012, as amended

(k) DoD Directive 8000.01, “Management of the Department of Defense Information Enterprise (DoD IE),” March 17, 2016

(l) Executive Order 12333, “United States Intelligence Activities,” December 4, 1981, as amended

(m) DoD Directive 8115.01, “Information Technology Portfolio Management,” October 10,

(n) Section 11331 of Title 40, United States Code

(o) DoD Directive 8140.01, “Cyberspace Workforce Management,” August 11, 2015

(p) DoD Instruction 8581.01, “Information Assurance (IA) Policy for Space Systems Used by the Department of Defense,” June 8, 2010

(q) DoD Instruction 8320.07, “Implementing the Sharing of Data, Information, and

Information Technology (IT) Services in the Department Of Defense,” August 3, 2015

(r) DoD Instruction 5000.02, “Operation of the Defense Acquisition System,” January 27, 2015, as amended

(s) DoD Chief Information Officer Memorandum, “DoD Enterprise Services Designation –

Collaboration, Content Discovery, and Content Delivery,” February 2, 2009

(t) DoD Chief Information Officer and Intelligence Community Chief Information Officer

Memorandum, “Use of Unified Cross Domain Management Office (UCDMO) Baseline Cross Domain Solutions (CDSs),” December 1, 2011

Change 2, 07/28/2017 ENCLOSURE 1 8

(u) Chairman of the Joint Chiefs of Staff Instruction 6211.02D, “Defense Information Systems Network (DISN) Responsibilities,” January 24, 2012

(v) DoD Instruction 8100.04, “DoD Unified Capabilities (UC),” December 9, 2010

(w) DoD Directive 5105.53, “Director of Administration and Management (DA&M),” February 26, 2008

(x) DoD Manual 5200.02, “Procedures for the DoD Personnel Security Program,”April 3, 2017

(y) Public Law 104-191, “Health Insurance Portability and Accountability Act of 1996,”

August 21, 1996

(z) DoD 8570.01-M, “Information Assurance Workforce Improvement Program,”

December 19, 2005, as amended

(aa) Appendix III to Office of Management and Budget Circular No. A-130, “Security of

Federal Automated Information Resources,” November 28, 2000

(ab) Committee on National Security Systems Instruction 4009, “Committee on National

Security Systems (CNSS) Glossary,”April 6, 2015

(ac) National Security Presidential Directive-54, “Cyber Security and Monitoring” /Homeland

Security Presidential Directive-23, “Cybersecurity Policy,” January 8, 20081

(ad) Memorandum of Agreement Between the Department of Defense and the Department of

Homeland Security Regarding Department of Defense and U.S. Coast Guard Cooperation on Cybersecurity and Cyberspace Operations, January 19, 20172

1 Document is classified TOP SECRET. To obtain a copy, fax a request to the Homeland Security Council Executive Secretary at 202-456-5158 and the National Security Council’s Senior Director for Records and Access Management at 202-456-9200.

2 Available at https://dcms.uscg.afpims.mil/Our-Organization/Assistant-Commandant-for-C4IT-CG-6-/The-Office-of-Information-Management-CG-61/Interagency-Agreements/

Change 2, 07/28/2017 ENCLOSURE 2 9

ENCLOSURE 2

RESPONSIBILITIES

1. DoD CHIEF INFORMATION OFFICER (DoD CIO). The DoD CIO:

a. Oversees implementation of this instruction, directs and oversees the cybersecurity risk management of DoD IT, distributes RMF information standards and sharing requirements, and manages the transition from the DIACAP to the RMF.

b. In coordination with the Deputy Assistant Secretary of Defense for Developmental Test and Evaluation (DASD(DT&E)) and the Director, Operational Test and Evaluation (DOT&E), ensures developmental and OT&E activities and findings are integrated into the RMF.

2. DIRECTOR, DEFENSE INFORMATION SYSTEMS AGENCY (DISA). Under the authority, direction, and control of the DoD CIO and in addition to the responsibilities in paragraph 7 of this enclosure, the Director, DISA:

a. Ensures control correlation identifiers (CCIs), security requirements guides (SRGs), and security technical implementation guides (STIGs) developed by DISA are consistent with security controls and assessment procedures used by the DoD.

b. Develops and provides RMF training and awareness products and a distributive training capability to support the DoD Components in accordance with Reference (h) and DoDD 8140.01 (Reference (o)); posts the training materials on the IA Support Environment Website (http://iase.disa.mil).

c. Identifies or develops and provides DoD Enterprise RMF management tools.

3. UNDER SECRETARY OF DEFENSE FOR ACQUISITION, TECHNOLOGY, AND

LOGISTICS (USD(AT&L)). The USD(AT&L) coordinates with the DoD CIO to ensure RMFs processes are appropriately integrated with Defense Acquisition System processes for acquisitions of DoD IT.

4. DASD(DT&E). Under the authority, direction, and control of the USD(AT&L), the DASD(DT&E), in coordination with the DoD CIO, ensures integration of DT&E activities into the RMF and provides the RMF TAG with input as appropriate or required.

5. DOT&E. The DOT&E:

Change 2, 07/28/2017 ENCLOSURE 2 10

a. Reviews plans, execution, and results of operational testing to ensure adequate evaluation of cybersecurity for all DoD IT acquisitions subject to oversight.

b. In coordination with DoD CIO, ensures integration of OT&E activities into the RMF and provides the RMF TAG with input as appropriate or required.

6. DIRECTOR, NATIONAL SECURITY AGENCY/CHIEF, CENTRAL SECURITY

SERVICE (DIRNSA/CHCSS)). Under the authority, direction, and control of the Under Secretary of Defense for Intelligence and in addition to the responsibilities in paragraph 7 of this enclosure, the DIRNSA/CHCSS:

a. Ensures IS security engineering services, when provided to the DoD Components, support the RMF.

b. Develops risk model and risk assessment tools to support authorization decisions.

7. DoD COMPONENT HEADS. The DoD Component heads:

a. Ensure DoD IS and PIT systems are categorized according to the guidelines provided in this instruction.

b. Verify that a program manager (PM) or system manager (SM) is appointed for all ISs and PIT systems.

c. Ensure a trained and qualified AO is appointed in writing for all DoD IS and PIT systems operating within or on behalf of the DoD Component in accordance with Reference (h) and that the systems are authorized in accordance with this instruction.

(1) This role must be assigned to government personnel only. This role may not be re-delegated to personnel that do not also meet these requirements.

(2) Relevant PIT expertise must be a factor in the selection and appointment of AOs responsible for authorizing PIT systems.

d. Develop and issue guidance for PIT systems that reflects DoD Component-unique operational and environmental demands as needed.

e Ensure DoD information technologies under their authority comply with the RMF.

f. Operate only authorized ISs and PIT systems (i.e., those with a current authorization to operate (ATO) or interim authorization to test (IATT)).

g. Comply with all authorization decisions, including denial of authorization to operate (DATO), and enforce authorization termination dates (ATD).

Change 2, 07/28/2017 ENCLOSURE 2 11

h. Ensure personnel engaged in or supporting the RMF are appropriately trained and possess professional certifications consistent with Reference (o) and supporting issuances.

i. Ensure IS owners (ISOs) appoint user representatives (URs) for DoD IS and PIT systems under the DoD Component’s purview.

j. Oversee the DoD Component chief information officer (CIO)’s implementation of this instruction.

k. Ensure participation in the RMF TAG.

l. Ensure that contracts and other agreements include specific requirements in accordance with this instruction.

8. CJCS. In coordination with the DoD CIO and in addition to the responsibilities in paragraph 7 of this enclosure, the CJCS ensures the Joint Capabilities Integration and Development System (JCIDS) process supports and documents IS and PIT system categorization consistent with this instruction.

9. COMMANDER, U.S. STRATEGIC COMMAND (USSTRATCOM). In addition to the responsibilities in paragraph 7 of this enclosure The Commander, USSTRATCOM:

a. Assigns AOs, issues authorization guidance consistent with this instruction, and resolves authorization issues for space systems used by the DoD in accordance with DoDI 8581.01 (Reference (p)).

b. Serves as the AO for authorizing the processing, storing, or transmitting of nuclear command, control, and communication data on ISs.

Change 2, 07/28/2017 ENCLOSURE 3 12

ENCLOSURE 3

RMF PROCEDURES

1. OVERVIEW. The forms of DoD IT, as shown in Figure 1, range in size and complexity from individual hardware and software products to stand-alone systems to massive computing environments, enclaves, and networks.

Figure 1. DoD IT

2. RISK MANAGEMENT OF IS AND PIT SYSTEMS. See Enclosure 6.

3. RISK MANAGEMENT OF IT PRODUCTS, SERVICES, AND PIT. IT products, services, and PIT are not authorized for operation through the full RMF process. These types of IT must be securely configured in accordance with applicable DoD policies and security controls and undergo special assessment of their functional and security-related capabilities and deficiencies.

The IS security manager (ISSM) (with the review and approval of the responsible AO) is responsible for ensuring all products, services and PIT have completed the appropriate evaluation and configuration processes prior to incorporation into or connection to an IS or PIT system. Paragraphs 3a through 3c summarize the categories of IT, the applicable evaluation process, and associated policy references.

a. IT Products. IT products (including applications), as defined in Reference (h), will be configured in accordance with applicable STIGs under a cognizant ISSM and security control assessor (SCA). STIGs are product-specific and document applicable DoD policies and security requirements, as well as best practices and configuration guidelines. STIGs are associated with security controls through CCIs, which are decompositions of NIST SP 800-53 security controls into single, actionable, measurable items. SRGs are developed by DISA to provide general security compliance guidelines and serve as source guidance documents for STIGs. When a STIG is not available for a product, an SRG may be used. STIGs, SRGs and CCIs are available

Change 2, 07/28/2017 ENCLOSURE 3 13 on the IA Support Environment Website (http://iase.disa.mil). STIG and SRG compliance results for products will be documented as security control assessment results within a product-level security assessment report (SAR) and reviewed by the responsible ISSM (under the direction of the AO) prior to acceptance or connection into an authorized computing environment (e.g., an IS or PIT system with an authorization). This review ensures products will not introduce vulnerabilities into the hosting IS or PIT system. DoD Component-level guidance maximizes testing and review results to minimize duplication of effort across the DoD. See the KS for additional guidance on the review of products.

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

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

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

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

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

c. PIT. PIT that does not rise to the level of a PIT System may be categorized using Reference (e) with the resultant security control baselines tailored as needed. Otherwise, the specific cybersecurity needs of PIT must be assessed on a case-by-case basis and security controls applied as appropriate.

Change 2, 07/28/2017 ENCLOSURE 4 14

ENCLOSURE 4

RMF GOVERNANCE

1. RMF GOVERNANCE. The DoD RMF governance structure implements the three-tiered approach to cybersecurity risk management described in NIST SP 800-39 (Reference (i)), synchronizes and integrates RMF activities across all phases of the IT life cycle, and spans logical and organizational entities. These elements are illustrated in Figure 2.

Figure 2. RMF Governance

TIER 1

ORGANIZATION

DOD CIO/SISO (RMF TAG & KS),

DOD ISRMC (DSAWG)

TIER 2

MISSION / BUSINESS PROCESSES

WMA, BMA, EIEMA, DIMA PAOS,

DOD COMPONENT CIO/SISO

TIER 3

IS/PIT SYSTEMS

AUTHORIZING OFFICIAL (AO), SYSTEM CYBERSECURITY PROGRAM

- Inter- Tier and Intra-Tier Communications

- Feedback Loop for Continuous Improvement

TACTICAL RISK

STRATEGIC RISK

- Traceability and Transparency of Risk- Based Decisions

- Organization-Wide Risk Awareness

WMA – Warfighting Mission Area BMA – Business Mission Area EIEMA – Enterprise Information Environment Mission Area DIMA – DoD portion of the Intelligence Mission Area

a. Tier 1 – Organization. For the purposes of the RMF, the organization described in Tier 1 is the OSD or strategic level, and it addresses risk management at the DoD enterprise level. The key governance elements in Tier 1 are:

(1) DoD CIO. Directs and oversees the cybersecurity risk management of DoD IT.

(2) Risk Executive Function

(a) DoD Information Security Risk Management Committee (ISRMC) (formerly the Defense Information Systems Network (DISN)/Global Information Grid (GIG) Flag Panel). The DoD ISRMC performs the DoD Risk Executive Function as described in Reference (i). The panel provides strategic guidance to Tiers 2 and 3; assesses Tier 1 risk; authorizes information

Change 2, 07/28/2017 ENCLOSURE 4 15 exchanges and connections for enterprise ISs, cross-MA ISs, cross security domain connections, and mission partner connections.

(b) Defense Security/Cybersecurity Authorization Working Group (DSAWG). The DSAWG, in support of the DoD ISRMC, is the community forum for reviewing and resolving authorization issues related to the sharing of community risk. The DSAWG develops and provides guidance to the AOs for IS connections to the DoD Information Enterprise.

(3) DoD SISO. The DoD SISO, in accordance with Reference (h), represents the DoD CIO and directs and coordinates the DoD Cybersecurity Program, which includes the establishment and maintenance of the RMF. In addition, the DoD SISO:

(a) Advises and informs the principal authorizing officials (PAOs) and their representatives.

(b) Oversees the RMF TAG and the online KS.

(4) DoD Cybersecurity Architecture. The DoD Cybersecurity architecture consists of strategies, standards, and plans that have been developed for achieving an assured, integrated, and survivable information enterprise.

(5) The RMF TAG. The RMF TAG (formerly known as the DIACAP TAG) provides implementation guidance for the RMF by interfacing with the DoD Component cybersecurity programs, cybersecurity communities of interest (COIs), and other entities (e.g., DSAWG) to address issues that are common across all entities, by:

(a) Providing detailed analysis and authoring support for the KS.

(b) Recommending changes to security controls in Reference (f), security control baselines and overlays in Reference (e), DoD assignment values, and associated implementation guidance and assessment procedures to the DoD CIO.

(c) Recommending changes to cybersecurity risk management processes to the DoD

CIO.

(d) Advising DoD forums established to resolve RMF priorities and cross-cutting issues.

(e) Developing and managing automation requirements for DoD services that support the RMF.

(f) Developing guidance for facilitating RMF reciprocity throughout the DoD.

(6) The KS. The KS, a dynamic online knowledge base, supports RMF implementation, planning, and execution by functioning as the authoritative source for RMF procedures and guidance. The KS supports RMF practitioners by providing access to DoD security control

Change 2, 07/28/2017 ENCLOSURE 4 16 baselines, security control descriptions, security control overlays, and implementation guidance and assessment procedures, all compliant with References (e) and (f). The KS also supports the RMF TAG by enabling TAG functions and activities, including maintenance of membership;

voting, analysis, and authoring; and configuration control of KS enterprise content and functionality. See Enclosure 7 for more information on KS capabilities.

b. Tier 2 - Mission/Business Processes

(1) PAO. A PAO is appointed for each of the DoD MAs (i.e., the warfighting MA (WMA), business MA (BMA), enterprise information environment MA (EIEMA), and DoD portion of the intelligence MA (DIMA)), and their representatives are members of the DoD ISRMC. PAOs must:

(a) Represent the interests of the MA, as defined in Reference (m), and, as required, issues authorization guidance specific to the MA, consistent with this instruction.

(b) Resolve authorization issues within their respective MAs and work with other PAOs to resolve issues among MAs, as needed.

(c) Designate AOs for MA IS and PIT systems supporting MA COIs specified in DoDI 8320.07 (Reference (q)), in coordination with appropriate DoD Component heads, if required.

(d) Designate information security architects or IS security engineers for MA segments or systems of systems, as needed.

(2) DoD Component CIO. Each DoD Component CIO, supported by the DoD Component SISO appointed in accordance with Reference (h), is responsible for administration of the RMF within the DoD Component cybersecurity program; participation in the RMF TAG;

visibility and sharing of the RMF status of assigned ISs and PIT systems; and enforcement of training requirements for persons participating in the RMF. DoD Component CIOs must:

(a) Maintain visibility of assessment and authorization status of DoD Component IS and PIT systems through automated assessment and authorization tools or designated repositories for their Component to the DoD CIO and PAOs.

(b) Verify that a PM or SM is identified for each DoD Component IS and PIT system.

(c) Establish and maintain processes and procedures to manage DoD Component POA&Ms.

(d) Appoint a DoD Component SISO to direct and coordinate the DoD Component cybersecurity program.

Change 2, 07/28/2017 ENCLOSURE 4 17

(e) Review and document concurrence on all ATOs issued for Component IS and PIT systems with a level of risk of “Very High” or “High.”

(3) DoD Component SISO. DoD Component SISOs have authority and responsibility for security controls assessment and must establish and manage a coordinated security assessment process for information technologies governed by the DoD Component cybersecurity program. DoD Component SISOs must:

(a) Implement and enforce the RMF within the DoD Component cybersecurity program.

(b) Perform as the SCA or formally delegate the security control assessment role for governed information technologies.

(c) Track the assessment and authorization status of IS and PIT systems governed by the DoD Component cybersecurity program.

(d) Establish and oversee a team of cybersecurity professionals qualified in accordance with Reference (p), responsible for conducting security assessments. DoD Component SISOs may task, organize, staff, and centralize or direct assessment activities to representatives as appropriate. Regardless of the adopted model, the SISO is responsible for assessing quality, capacity, visibility, and effectiveness.

(e) Identify and recommend changes and improvements to the security assessment process, security T&E, and risk assessment methodology, including procedures, risk factors, assessment approach, and analysis approach to the RMF TAG for inclusion in the KS.

(f) Advise AOs on the adequacy of acquisition program implementation of cybersecurity requirements.

(g) Serve as the single cybersecurity coordination point for joint or DoD-wide programs that are deploying information technologies to DoD Component enclaves.

(h) Ensure DoD Component RMF guidance is posted to the DoD Component portion of the KS, and is consistent with DoD policy and guidance.

(i) Oversee DoD Component-level participation in the RMF TAG.

c. Tier 3 – IS and PIT Systems

(1) AO. The DoD Component heads are responsible for the appointment of trained and qualified AOs for all DoD ISs and PIT systems within their Component. AOs should be appointed from senior leadership positions within business owner and mission owner organizations (as opposed to limiting appointments to CIO organizations) to promote accountability in authorization decisions that balance mission and business needs and security concerns. In addition to the responsibilities established in Reference (h), AOs must:

Change 2, 07/28/2017 ENCLOSURE 4 18

(a) Comply with DoD ISRMC direction issued on behalf of the MA PAOs.

(b) Ensure all appropriate RMF tasks are initiated and completed, with appropriate documentation, for assigned ISs and PIT systems.

(c) Monitor and track overall execution of system-level POA&Ms.

(d) Promote reciprocity to the maximum extent possible.

(e) Not delegate authorization decisions. Other AO responsibilities and tasks may be delegated to formally appointed and qualified AO designated representatives (AODRs).

(2) IS or PIT System Cybersecurity Program. The system cybersecurity program consists of the policies, procedures, and activities of the ISO, PM/SM, UR, ISSM, and IS security officers (ISSOs) at the system level. The system cybersecurity program implements and executes policy and guidance from Tier 1 and Tier 2, and augments them as needed. The system cybersecurity program is responsible for establishing and maintaining the security of the system, including the monitoring and reporting of the system security status. Specific cybersecurity program responsibilities include:

(a) ISOs must:

1. In coordination with the information owner (IO), categorize systems in accordance with Reference (e) and document the categorization in the appropriate JCIDS capabilities document (e.g., capabilities development document).

2. Appoint a UR for assigned IS and PIT systems.

3. Develop, maintain, and track the security plan for assigned IS and PIT systems. (Common security controls owner performs this function for inherited controls.)

(b) PMs (or SM, if no PM is assigned) must:

1. Appoint an ISSM for each assigned IS or PIT system with the support, authority, and resources to satisfy the responsibilities established in this instruction.

2. Ensure each program acquiring an IS or PIT system has an assigned IS security engineer and that they are fully integrated into the systems engineering process.

3. Implement the RMF for assigned IS and PIT systems.

4. Ensure the planning and execution of all RMF activities are aligned, integrated with, and supportive of the system acquisition process.

Change 2, 07/28/2017 ENCLOSURE 4 19

5. Enforce AO authorization decisions for hosted or interconnected IS and PIT systems.

6. Implement and assist the ISO in the maintenance and tracking of the security plan for assigned IS and PIT systems.

7. Ensure POA&M development, tracking, and resolution.

8. Ensure periodic reviews, testing and assessment of assigned IS and PIT systems are conducted at least annually.

9. Provide the IS or PIT system description.

10. Register the IS or PIT system in the DoD Component registry.

11. Ensure T&E of assigned IS and IT system is planned, resourced, and documented in the program T&E master plan in accordance with DoDI 5000.02 (Reference (r)).

(c) URs must represent the operational and functional requirements of the user community in the RMF process.

(d) ISSMs, in addition to the responsibilities established in Reference (h), must:

1. Support implementation of the RMF.

2. Maintain and report IS and PIT systems assessment and authorization status and issues in accordance with DoD Component guidance.

3. Provide direction to the ISSO in accordance with Reference (h).

4. Coordinate with the organization’s security manager to ensure issues affecting the organization's overall security are addressed appropriately.

Change 2, 07/28/2017 ENCLOSURE 4 20

2. RMF ROLE APPOINTMENT. Table 1 identifies the appropriate authority for the appointment of RMF roles.

Table 1. Appointment of RMF Roles

Role Appointed By

PAO (formerly principal accrediting authority)

DoD MA owner

DoD SISO (formerly the Senior IA Officer)

DoD CIO

DoD Component CIO DoD Component head

AO (formerly designated approving (or accrediting) authority)

DoD Component head; PAO for MA-managed ISs

AODR (formerly designated approving (or accrediting) authority representative)

AO

DoD Component SISO DoD Component CIO or, in organizations in which the position of DoD Component CIO does not exist, the DoD Component head.

SCA (formerly certifying authority) DoD Component SISO is the Component SCA, but may formally delegate the SCA role as appropriate.

PM/SM DoD Component head

ISSM (formerly IA manager) PM or SM

UR ISO

RMF TAG Representative (formerly DIACAP TAG Representative)

DoD Component SISO

Change 2, 07/28/2017 ENCLOSURE 5 21

ENCLOSURE 5

CYBERSECURITY RECIPROCITY

1. Cybersecurity reciprocity (referred to in this instruction as “reciprocity”) is an essential element in ensuring IT capabilities are developed and fielded rapidly and efficiently across the DoD Information Enterprise. Applied appropriately, reciprocity reduces redundant testing, assessing and documentation, and the associated costs in time and resources. The DoD RMF presumes acceptance of existing test and assessment results and authorization documentation. In order to facilitate reciprocity, the concepts in paragraphs 1a through 1e are fundamental to a common understanding and must be adhered to:

a. IS and PIT systems have only a single valid authorization. Multiple authorizations indicate multiple systems under separate ownership and configuration control.

b. Deploying systems with valid authorizations (from a DoD organization or other federal agency) are intended to be accepted into receiving organizations without adversely affecting the authorizations of either the deployed system or the receiving enclave or site. Deploying system ISOs and PMs must coordinate system security requirement with receiving organizations or their representatives early and throughout system development.

c. An authorization decision for IS or PIT system cannot be made without completing the required assessments and analysis, as recorded in the security authorization package. Deploying organizations must provide the complete security authorization package to receiving organizations. PMs/ ISOs deploying systems across DoD Components will post security authorization documentation to Enterprise Mission Assurance Support Service (eMASS) or other electronic means to provide visibility of authorization status and documentation to planned receiving sites.

d. The process for receiving organization to accept IS and PIT systems is:

(1) Review the complete security authorization package.

(2) Determine the security impact of connecting the deploying system within the receiving enclave or site.

(3) Determine the risk of hosting the deploying system within the enclave or site.

(4) If the risk is acceptable, execute a documented agreement between deploying and receiving organizations (e.g., memorandum of understanding (MOU), memorandum of agreement (MOA), SLA) for the maintenance and monitoring of the security posture of the system (security controls, cybersecurity service provider (CSSP), etc.).

(5) Document the acceptance by the receiving AO.

Change 2, 07/28/2017 ENCLOSURE 5 22

(6) Update the receiving enclave or site authorization documentation for inclusion of the deployed system.

e. Receiving organizations have the right to refuse deploying systems due to a security authorization package that does not meet sufficiency and completeness requirements as defined on the KS, or excessive risk to the enclave or site, as determined by the enclave or site AO.

Refusals must be documented by the refusing AO, and provided to the deploying organization’s ISO or PM, AO, and Component SISO, and to the refusing organization’s Component SISO.

Disputes should be resolved at the lowest possible level. Disputes that cannot be resolved will be raised to the next appropriate level (e.g., DoD Component, MA PAO, DSAWG, DoD

ISRMC).

2. The cases in paragraph 2a through 2e describe the proper application of DoD policy on reciprocity in the most frequently occurring scenarios:

a. A system is authorized by a DoD AO for subsequent deployment into receiving environments authorized by other DoD AOs. This case includes systems designated as enterprise systems in accordance with DoD CIO Memorandum (Reference (s)), as well as non-enterprise systems that will be developed, authorized, and deployed within a single DoD Component, or across multiple DoD Components. Systems with existing authorizations issued by DoD AOs do not require a new authorization to be issued by the receiving enclave or site.

(1) The receiving site executes the acceptance process in paragraph 1d of this enclosure.

Issues identified during the acceptance process will be negotiated between the deploying ISO or PM and the receiving enclave or site ISO or SM. Following resolution of any issues, which may result in modifications in either the deploying system or the receiving environment, the deploying system is allowed to be incorporated or connected to the hosting environment. The nature or magnitude of any modifications to the deploying system or receiving site may result in additional assessment activities, but the deploying system and receiving environment retain their own separate authorizations. It is the joint responsibility of the ISOs of deploying systems and the receiving sites to ensure the system design reflects the security, technical and threat environment of the planned receiving sites, as well as leveraging any common controls.

Unresolved issues, disputes, and refusals are addressed in accordance with paragraph 1e of this enclosure. Document the acceptance by the receiving AO.

(2) The DoD ISRMC, supported by the DSAWG, may make an enterprise level risk acceptance determination for authorized enterprise systems, which will satisfy the requirements of the first three elements of paragraph 1d of this enclosure. If the DoD ISRMC accepts the risk on behalf of the DoD Information Enterprise, the receiving organization may not refuse to deploy the system.

b. A system is authorized by another U.S. Government agency, and a DoD organization takes ownership of the system for deployment into DoD ISs or enclaves. Systems with an existing authorization issued by other federal agencies require authorization by a DoD AO in accordance with Enclosure 3 of this instruction prior to operating if the providing organization relinquishes configuration and maintenance of the system to the DoD. The receiving enclave or

Change 2, 07/28/2017 ENCLOSURE 5 23 site will maximize reuse of the external agency’s security authorization package to support the authorization by the DoD AO. Following the issuance of a DoD authorization, subsequent deployment of the system by the DoD ISO or PM to DoD receiving sites will follow the review and acceptance process described in paragraph 1d of this enclosure.

c. A system is authorized by a DoD organization for its own use, and subsequently provided to another DoD organization for it to use as a separately owned, managed and maintained system. In this case, the receiving organization becomes the ISO and must authorize the system in accordance with Enclosure 3 of this instruction. The receiving enclave or site will maximize reuse of the existing authorization documentation to support the authorization by the receiving AO. Following the issuance of the authorization, subsequent deployment of the system by the system owner to other receiving sites will follow the review and acceptance process described in paragraph 1d of this enclosure.

d. A DoD system is authorized and subsequently deployed for acceptance into receiving sites authorized by a U.S. Government agency other than DoD. In this case, the DoD system’s security authorization documentation is made available to the receiving U.S. Government agency. If the receiving agency determines there is insufficient information in the documentation or inadequate security measures in place for establishing an acceptable level of risk, the receiving agency may negotiate with the deploying DoD organization for additional security measures or security-related information. The additional security measures or security-related information may be provided by the DoD organization, the system developer, the receiving agency, some other external third party, or some combination of the above.

e. A DoD organization plans to use an IT service under contract from a commercial entity that has been authorized by a DoD or other U.S. Government agency (e.g., a commercial cloud service authorized by the Federal Risk and Authorization Management Program Joint Authorization Board). In this case, the DoD organization leverages an existing authorization, and maximizes reuse of the existing authorization documentation to support a new authorization by a DoD AO. If the DoD organization determines there are inadequate security measures in place for establishing an acceptable level of risk, the DoD organization may negotiate with IT service provider for additional security measures or security-related information. Upon assessment and approval of all newly included security measures and the documentation of all applicable security measures in the contract agreement with the IT service provider, the DoD organization AO issues an authorization.

Change 2, 07/28/2017 ENCLOSURE 6 24

ENCLOSURE 6

RISK MANAGEMENT OF IS AND PIT SYSTEMS

1. OVERVIEW. This enclosure describes the DoD process for identifying, implementing, assessing, and managing cybersecurity capabilities and services, expressed as security controls, and authorizing the operation of IS and PIT systems. This enclosure is designed to be a companion guide to Reference (c), providing specific guidance for implementation within DoD.

DoD personnel serving in RMF roles at every level should refer to Reference (c) for a full description of the process, definitions, roles and responsibilities, and activities. In cases where Reference (c) conflicts with this instruction, compliance with this instruction takes precedence and is required. The KS also provides expanded coverage of this subject, as well as tools, templates, and best practice information.

a. Applicability. This process is applicable to all IS and PIT systems, as well as DoD partnered systems where it has been agreed that DoD standards will be followed. IT below the system level (e.g., products, IT services) will not be subjected to the full process described in this enclosure. However, IT below the system level must be securely configured (in accordance with applicable DoD policies and security controls), documented in the authorization package and reviewed by the responsible ISSM (under the direction of the AO) for acceptance or connection into an authorized computing environment (i.e., an authorized IS or PIT system).

b. Considerations for Special System Configurations

(1) IS and PIT Systems Implementing a cross domain solution (CDS). CDSs are typically deployed within the IS or PIT system authorization boundary on the system with the higher classification of the cross domain connection, and are included in the IS or PIT system authorization. The AO responsible for the IS or PIT system must consider the security impact of the CDS operation in the overall authorization decision. In addition to the high-side security requirements and ATO, the security requirements for the integrity of the information transfer must be considered and implemented on the connecting low-side IS(s). Additional detail and authoritative guidance is provided in DoD CIO and Intelligence Community CIO Memorandum (Reference (t)) and CJCS Instruction 6211.02D (Reference (u)).

(2) ISs and PIT Systems Providing Unified Capabilities (UC). DoDI 8100.04 (Reference (v)) contains DoD policy for UC, and describes the process for the cybersecurity certification of UC products. UC products are implemented inside the authorization boundaries of DoD ISs, and the UC product cybersecurity certification documentation is used to support the overall system assessment and authorization.

(3) Type Authorization. The type authorization is used to deploy identical copies of an IS or PIT system in specified environments. This method allows a single security authorization package to be developed for an archetype (common) version of a system. The system can then be deployed to multiple locations with a set of installation, security control and configuration requirements, or operational security needs that will be provided by the hosting enclave.

Change 2, 07/28/2017 ENCLOSURE 6 25

(4) Stand-Alone IS and PIT System. Stand-alone IS and PIT systems are types of enclaves that are not interconnected to any other network. Stand-alone IS and PIT systems do not transmit, receive, route, or exchange information outside of the system’s authorization boundary. They may range in size from a single workstation to multiple interconnected subsystems as long as they meet the foregoing criteria. Stand-alone IS and PIT systems are authorized as any other IS and PIT systems, but assigned security control sets may be tailored as appropriate with the approval of the AO (e.g., network-related controls may be eliminated).

Stand-alone IS and PIT systems must always be clearly identified as such in the authorization documentation. Additionally, identical stand-alone IS and PIT systems that have identical security control implementation and are to be deployed to multiple locations may be type authorized.

(5) DoD-Controlled IS and PIT Systems Operated by a Contractor or Other Entity on Behalf of the DoD. Externally owned IS and PIT systems that are dedicated to DoD processing and are effectively under DoD configuration control must be authorized as DoD IS and PIT systems. A DoD AO must render an authorization decision for this type of a DoD system prior to DoD use of the capability. The following additional requirements apply:

(a) Security responsibilities of the service provider down to the control level must be made explicit in the contract or other binding agreement, along with any other performance and service-level parameters by which the DoD entity will measure the cybersecurity performance of the system for the purpose of authorization.

(b) Technical security of the outsourced environment must be the responsibility of the service provider.

(c…