Attachment J.23. - Peace Corps IT Managing IT Risk.pdf

Information Technology Security Program

Managing Information Technology Risk

CIO-SEC-PRC-01

This document is approved for distribution. Policies, procedures and standards, herein, are effective at the date of signature until explicitly superseded or rescinded.

Digital Signature Chief Information Security Officer

CIO-SEC-PRC-01 Managing IT Risk

Peace Corps 2

VERSION HISTORY/CHANGE RECORD

Change Number

Person Posting Change

Change Reason for Change Page Number of Change

Initial Document 1 M Terry N/A N/A

Peace Corps 3

Table of Contents 1 Introduction

1.1 Purpose

1.2 Scope

1.3 Policy

1.4 Assessment and Authorization Roles and Responsibilities

1.4.1 Peace Corps Director

1.4.2 Chief Information Officer (CIO)

1.4.3 Chief Information Security Officer (CISO)

1.4.4 Senior Agency Official for Privacy (SAOP)

1.4.5 Chief Privacy Officer (CPO)

1.4.6 Associate Directors/Regional Directors (ADRDs)

1.4.7 Authorizing Official (AO)

1.4.8 Security, Policy and Governance

1.4.9 Information Systems Security Managers (ISSMs)

1.4.10 Information Systems Security Officers (ISSOs)

1.4.11 System Owners

1.4.12 Program Managers

1.4.13 Project Managers

1.4.14 Data Owners (i.e., Functional Business Line Managers)

1.4.15 Contracting Officers (COs)/Contracting Officer’s Representatives (CORs)

1.4.16 Custodians

1.4.17 Users of IT Resources

1.4.18 System/Network Administrators

2 PC Standard A&A Process

2.1 RMF Step 1 – Categorize Information System

2.2 RMF Step 2 – Select Security Controls

2.3 RMF Step 3 – Implement Security Controls

2.4 RMF Step 4 – Assess Security Controls

2.5 RMF Step 5 – Authorize Information System

2.6 RMF Step 6 – Security Control Monitoring

2.6.1 Security Control Monitoring

2.6.2 Information Security Continuous Monitoring Strategy

2.6.3 Security Authorization Process Guidance for Significant Changes

2.6.4 Security Authorization Process Guidance for Expiring Authorizations

3 Security Authorization Process

3.1 Identifying the Appropriate A&A Process/Program

3.2 A&A Process Descriptions

3.2.1 PC Standard A&A Process

3.2.2 Lightweight Security Authorization Process

3.2.3 Security Reviews for Low Impact Software as a Service Process

3.2.4 FedRAMP Process

Peace Corps 4

3.2.5 PC Subsystem Process

3.2.6 PC Information System Continuous Monitoring Program

4 PC Implementation of CA, PL, and RA Controls

4.1 Security Assessment and Authorization (CA)

4.1.1 CA-1 Security Assessment and Authorization Policy and Procedures

4.1.2 CA-2 Security Assessments

4.1.3 CA-3 System Interconnections

4.1.4 CA-5 Plan of Action and Milestones

4.1.5 CA-6 Security Authorization

4.1.6 CA-7 Continuous Monitoring

4.1.7 CA-8 Penetration Testing

4.1.8 CA-9 Internal System Connections

4.2 Planning (PL)

4.2.1 PL-1 Security Planning Policy and Procedures

4.2.2 PL-2 System Security Plan

4.2.3 PL-4 Rules of Behavior

4.2.4 PL-8 Information Security Architecture

4.3 Risk Assessment (RA)

4.3.1 RA-1 Risk Assessment Policy and Procedures

4.3.2 RA-2 Security Categorization

4.3.3 RA-3 Risk Assessment

4.3.4 RA-5 Vulnerability Scanning

5 Additional NIST Controls Required by PC 6 Summary Appendix A: CSF Function, Category, and Subcategory Definitions/NIST SP 80053 Control Mapping . 47 Appendix B: Consolidated List of Guidance, Policies, Procedures, Templates Appendix C: A&A Process Package Document Lists/Links Appendix D: PC Defined Cloud Controls Appendix F: Showstopper Controls

Table of Figures and Tables Figure 2-1. Risk Management Framework (from NIST 800-37) Table 2-2: CSF Functions Mapped to NIST SP 800-37 RMF Steps Table 3-1. A&A Process Requirements Table 4-1: NIST SP 800-53 Control to CSF Mapping Table 5-1: PC Additional NIST Control Requirements Table A-1: CSF Category/Subcategory to NIST SP 800-53 Controls Table F-1: PC Showstopper Controls

Peace Corps 5

NOTE: Hyperlinks in this guide are provided as follows:

• Appendix B - Consolidated List of Guidance, Policies, Procedures, and Forms. This appendix contains hyperlinks to Federal Regulations/Guidance and to PC webpages containing PC policies, guides, and forms/templates.

• In running text - Hyperlinks will be provided if they link to a location within this document (i.e., a different section or an appendix). Hyperlinks will be provided for external sources unless the hyperlink is to a webpage or document listed in Appendix B.

Note: It may be necessary to copy and paste hyperlinks in this document (Right-Click, Select Copy Hyperlink) directly into a web browser rather than using Ctrl-Click to access them within the document.

1 Introduction

Security Assessment and Authorization (A&A) processes within the Peace Corps (PC) are based on the National Institute of Standards and Technology (NIST) Risk Management Framework (RMF) and the security authorization process as described in NIST Special Publication (SP) 800-37, Revision 2, “Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy”. This guide describes key activities in managing enterprise-level risk through a system life cycle perspective including system security authorization and continuous monitoring. It is designed to assist agency and contractor personnel with security responsibilities in implementing A&A processes.

Every PC Information system must use one of the A&A processes identified in this guide or a pilot process as described in the next paragraph. Any deviations from the security requirements established under the authority of MS 542, “Information Security Program” must be coordinated by the Information Systems Security Officer (ISSO) through the Chief Information Security Officer (CISO) and authorized by the Authorizing Official (AO). Any deviations, exceptions, or other conditions not following PC policies and standards must be submitted using a Security Deviation Request.

PC may conduct pilots of additional A&A processes when a system or the evolving IT and IT security environments indicate a process different from any of PC’s existing processes is preferred. Piloting of new processes must be coordinated with the CISO. Final approval of the process is indicated by the CISO concurring with any Authorization to Operate (ATO) resulting from the pilot.

Throughout this guide, the term Authorization to Operate (ATO) should be understood to include the Authorization To Use (ATU). The ATU designation is functionally equivalent to the ATO. An ATU is intended to communicate that PC is limited to application end user https://docs.google.com/forms/d/e/1FAIpQLSew38lCEj9FnE7Tmpi6ajMn700NYbe4fZtjo2Ol5MA9Of8eUw/viewform

Peace Corps 6 functionality. This includes use of administrative or managerial roles provided within the application. The ATU is applicable to Software as a Service (SaaS) offerings.

Executive Order (EO), EO 13800, “Presidential Executive Order on Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure” requires all agencies to use “The Framework for Improving Critical Infrastructure Cybersecurity (the Framework) developed by the NIST or any successor document to manage the agency’s cybersecurity risk.” This NIST document is commonly referred to as the Cybersecurity Framework (CSF). The CSF complements, and does not replace, an organization’s risk management process and cybersecurity program. PC uses NIST’s RMF as its foundation for managing risk. Further information on how the CSF relates to PC’s use of the NIST RMF is explained in Section 2 and Appendix A where the CSF categories and subcategories are mapped to NIST RMF steps, tasks, and security controls.

In Appendix F, Table F-1, PC has identified a list of NIST SP 800-53 controls considered to be Showstopper Controls. Showstopper controls, if not fully compliant, will keep a system from receiving a full ATO.

1.1 Purpose

This procedural guide defines the PC risk management process, specifically the security authorization processes PC has implemented for information systems to obtain an ATO. The guide describes the key activities in managing enterprise-level risk as described in NIST SP 800- 37.

1.2 Scope

The requirements outlined within this guide apply to all PC Federal employees, contractors, and vendors who oversee/protect PC information systems and data. The guide provides PC Federal employees, contractors, and vendors and other IT personnel involved in performing A&A activities, the specific processes to follow for properly accomplishing A&A activities for the systems under their purview. The following definitions are provided for classifying systems within scope of this guide.

• Contractor System. An information system processing or containing PC or Federal data where the infrastructure and applications are wholly operated, administered, managed, and maintained by a Contractor in non-PC facilities.

• Federal System (i.e., Agency System). An information system processing or containing PC or Federal data where the infrastructure and/or applications are NOT wholly operated, administered, managed, and maintained by a Contractor.

Peace Corps 7

1.3 Policy

Authorizing Officials (AO) must ensure risk assessments are performed as part of A&A activities before a system is placed into production, when significant changes are made to the system and at least every three (3) years unless it is covered by PC’s Information Security Continuous Monitoring (ISCM) program.

1.4 Assessment and Authorization Roles and Responsibilities

There are many roles associated with the security authorization process. System Owners for each information system are responsible for ensuring their respective systems have been through the PC A&A process, have received an ATO from the AO, and received concurrence from the CISO. The following sections provide a high level description of the responsibility for the primary roles with management and operational A&A responsibilities.

1.4.1 Peace Corps Director

The Director is responsible for ensuring an information security program is developed, documented, and implemented to provide security for all systems, networks, and data that support the operations of PC.

1.4.2 Chief Information Officer (CIO)

The Chief Information Officer (CIO) has overall responsibility for the PC IT Security Program. The CIO is responsible for providing guidance, assistance, support, and management processes to PC staff and organizations to enable them to perform their responsibilities with regard to PC’s IT Security Program.

1.4.3 Chief Information Security Officer (CISO)

Public Law 113-283, “Federal Information Security Modernization Act of 2014” (FISMA), establishes the designation of a senior agency information security officer responsible for complying with Federal security requirements. PC has assigned this role to the Chief Information Security Officer (CISO). The CISO is the focal point for all PC IT security and must ensure the security requirements described in this Order are implemented agency-wide. The CISO reports directly to the CIO as required by FISMA.

1.4.4 Senior Agency Official for Privacy (SAOP)

The SAOP is responsible for ensuring PC’s compliance with privacy laws, regulations and PC policy, and the controls in Appendix J: Privacy Control Catalog of NIST SP 800-53, Revision 4, “Security and Privacy Controls for Federal Information Systems and Organizations”. Within PC, the Deputy Director of Management is the SAOP.

Peace Corps 8

1.4.5 Chief Privacy Officer (CPO)

The CPO is responsible for overseeing PC's Privacy Program whose mission it is to preserve and enhance privacy protections for all individuals whose personal information is handled by PC and to encourage transparency of PC operations involving personal information. The CPO manages PC’s Privacy Act Program and administers PC’s compliance with privacy laws and regulations. The CPO is responsible for developing, managing, and administering PC’s Privacy Program Plan and Privacy Strategy Plan.

1.4.6 Associate Directors/Regional Directors (ADRDs)

ADRDs are responsible for authorizing the operation of all systems, networks, and applications for which they have responsibility. They may delegate some of their authority (e.g., the role of Authorizing Official in writing) to appropriately qualified individuals within their organizations.

1.4.7 Authorizing Official (AO)

AOs are responsible for authorizing the operation of all systems, networks, and applications for which they have responsibility. They may delegate some of their authority to appropriately qualified individuals within the organization. At PC, there is a single AO and that role is delegated to the CIO.

1.4.8 Security, Policy and Governance

SPG is the CISO’s office and is responsible for ensuring IT security is properly implemented.

1.4.9 Information Systems Security Managers (ISSMs)

ISSMs report to the CISO. There is at least one ISSM. The ISSM is responsible for all IT system security and privacy matters for the systems under their authority. ISSMs are appointed, in writing, by the CISO. An individual appointed as an ISSM cannot also be assigned as the ISSO.

1.4.10 Information Systems Security Officers (ISSOs)

ISSOs are responsible for ensuring implementation of adequate system security, including privacy analysis/protection, in order to manage cybersecurity risk aligned with the CSF functions of identify, protect, detect, respond, and recover. An ISSO must be assigned for every information system. An ISSO may have responsibility for more than one system, provided there is no conflict. An individual assigned as the ISSO cannot also be the ISSM. ISSOs must be appointed via a designation letter. An ISSO must be knowledgeable of the information and processes supported by their assigned systems.

1.4.11 System Owners

System Owners are management officials within PC who bear the responsibility for the acquisition, development, maintenance, implementation, and operation of PC's IT systems.

System Owners represent the interests of the system throughout its lifecycle. Primary

Peace Corps 9 responsibility for managing risk rests with the System Owners. System Owners must ensure their systems and the data each system processes have the necessary security and privacy controls in place and are operating as intended and protected in accordance with PC regulations and any additional guidelines established by the CISO and relayed by the ISSO or

ISSM.

1.4.12 Program Managers

Program Managers are management officials within PC who are responsible for developing, implementing, and/or overseeing multi-year IT initiatives that must be carried out through multiple related projects. A Program Manager focuses on the strategic goals of PC. Program Managers are responsible for ensuring cyber risk is adequately managed and resources are allocated, monitored, and managed to support the required level of security for projects under their purview.

1.4.13 Project Managers

Project Managers are management officials within PC who are responsible for managing a project within a larger program. A Project Manager is responsible for ensuring cyber risk is adequately managed and the schedule, resources, and tasks within a project include delivering security.

1.4.14 Data Owners (i.e., Functional Business Line Managers)

Data Owners are responsible for determining the security categorization level of systems based upon Federal Information Processing Standards (FIPS) Publication 199, “Standards for Security Categorization of Federal Information and Information Systems”, and ensuring System Owners are aware of the sensitivity of data (e.g., Personally Identifiable Information, Controlled Unclassified Information) to be handled. They must coordinate with System Owners, ISSMs, ISSOs, and Custodians to ensure the data is properly stored, maintained, protected, and monitored in accordance with PC policies, regulations and any additional guidelines established by PC.

1.4.15 Contracting Officers (COs)/Contracting Officer’s Representatives (CORs)

COs/CORs are responsible for coordinating and collaborating with the CISO or other appropriate officials to ensure all agency contracts and procurements are compliant with the agency’s information security policy. They also must ensure the appropriate security and privacy contracting language is incorporated in each contract and task order.

1.4.16 Custodians

Custodians own the hardware platforms and equipment on which the data is processed. They are the individuals in physical or logical possession of information from Data Owners. They must coordinate with Data Owners and System Owners to ensure the data is properly stored, maintained, and protected.

Peace Corps 10

1.4.17 Users of IT Resources

Authorized users of PC IT resources, including all Federal employees and contractors, either by direct or indirect connections, are responsible for complying with PC’s IT Security Policy and procedures.

1.4.18 System/Network Administrators

System/Network Administrators are responsible for ensuring the appropriate security requirements are implemented consistent with PC IT security policies and hardening guidelines.

2 PC Standard A&A Process

All PC A&A processes are based upon NIST SP 800-37. A depiction of the RMF is provided in Figure 2-1.

Figure 2-1. Risk Management Framework (from NIST 800-37)

Note: This guide will be updated to incorporate NIST SP 800-37, Revision 2 in the near future.

The RMF Steps 1-6 associated with the PC Standard A&A Process are detailed in the following sections. Additional A&A processes PC has developed or uses are identified in Section 3 which have been adapted or modified from the standard RMF processes. Documents required as part of a PC A&A process are listed in Appendix C along with hyperlinks (where applicable) to resources containing document templates.

As required by EO 13800, PC has aligned its risk management process with the CSF. The five core CSF Functions are:

• Identify (ID): Develop an organizational understanding to manage cybersecurity risk to systems, people, assets, data, and capabilities.

Peace Corps 11

• Protect (PR): Develop and implement the appropriate safeguards to ensure delivery of critical infrastructure services.

• Detect (DE): Develop and implement appropriate activities to identify the occurrence of a cybersecurity event.

• Respond (RS): Develop and implement appropriate activities to take action regarding a detected cybersecurity incident.

• Recover (RC): Develop and implement appropriate activities to maintain plans for resilience and to restore any capabilities or services that were impaired due to a cybersecurity incident.

PC’s alignment of its implementation of the NIST RMF with these five core functions is portrayed in Table 2-2. The mapping was based on reviewing NIST’s mapping in the draft version of Revision 2 to NIST SP 800-37 and how PC manages risk across the enterprise. A more detailed mapping of the CSF Functions, Categories, and Subcategories to NIST SP 800-53 security controls is provided in Appendix A.

Table 2-2: CSF Functions Mapped to NIST SP 800-37 RMF Steps

CSF Function Mapped RMF Steps Identify RMF Step 1: Categorize Information System Task

1-1: Security Categorization Task 1-2: Information System Description Task 1-3: Information System Registration

RMF Step 2: Select Security Controls Task 2-1: Common Control Identification Task 2-2: Security Control Selection

Protect RMF Step 2: Select Security Controls Task 2-2: Security Control Selection Task 2-3: Monitoring Strategy

RMF Step 3: Implement Security Controls Task 3-1: Security Control Implementation

Detect RMF Step 3: Implement Security Controls Task 3-1: Security Control Implementation

RMF Step 4: Assess Security Controls Task 4-2: Security Control Assessment

RMF Step 6 Monitor Security Controls Task 6-2: Ongoing Security Control Assessments Task 6-5: Security Status Reporting

Peace Corps 12

CSF Function Mapped RMF Steps Respond RMF Step 3: Implement Security Controls

Task 3-1: Security Control Implementation RMF Step 4: Assess Security Controls Task

4-4: Remediation Actions RMF Step 5: Authorize Information System Task

5-1: Plan of Action and Milestones Task 5-4: Risk Acceptance

RMF Step 6 Monitor Security Controls Task 6-3: Ongoing Remediation Actions Task 6-5: Security Status Reporting

Recover RMF Step 3: Implement Security Controls Task 3-1: Security Control Implementation

RMF Step 4: Assess Security Controls Task 4-4: Remediation Actions

RMF Step 5: Authorize Information System Task 5-1: Plan of Action and Milestones

RMF Step 6: Monitor Security Controls Task 6-3: Ongoing Remediation Actions Task 6-6: Ongoing Risk Determination and Acceptance

2.1 RMF Step 1 – Categorize Information System

The first step in PC’s standard A&A process is to determine the FIPS 199 security categorization level of the information system. This level (Low-, Moderate-, or High-impact) will affect the remaining steps in the process. The following tasks detail the actions in RMF Step 1.

TASK 1-1: Security Categorization - Categorize the information system using the FIPS 199 categorization template and document the results of the security categorization in the system security plan (SSP). The System Owner carries out the security categorization process in cooperation and collaboration with appropriate organizational officials with information security/risk management responsibilities including but not limited to the Data Owner, AO, and ISSO. The process for determining the appropriate impact level is outlined in FIPS 199 and its associated guides:

• NIST SP 800-60 Volume I, Revision 1, “Volume I: Guide for Mapping Types of Information and Information Systems to Security Categories”

• NIST SP 800-60 Volume II, Revision 1, “Volume II, Appendices to Guide for Mapping Types of Information and Information Systems to Security Categories.”

Peace Corps 13

Please refer to these documents to categorize the information system. The resulting categorization determines the appropriate security control baseline (Low-, Moderate-, or High-impact) for the information system as outlined within NIST SP 800-53, Revision 4.

TASK 1-2: Information System Description - Describe the information system (including system boundary) and document the description in an SSP based on NIST SP 800-18, Revision 1, “Guide for Developing Security Plans for Federal Information Systems.” The SSP provides an overview of the security requirements for the information system, describes the security controls in place or planned for meeting those requirements, and formalizes the plans and expectations regarding the overall functionality of the information system. Descriptive information about the information system is documented in sections 1-12 of the security plan. The level of detail provided in the security plan should be commensurate with the security categorization of the information system. The following sections should be sufficiently detailed:

• Section 2 of the SSP describes the FIPS 199 security categorization of the system. The FIPS 199/NIST SP 800-60 analysis must be supported by a completed FIPS 199 Security Categorization Template.

• Section 9 of the SSP describes the function or purpose of the system and its information processes.

• Section 10 of the SSP contains tables outlining the technical system including an inventory of all assets in the authorization boundary. The tables within this section must be completed and depict a complete inventory of hardware, software and operating system components. Any subsystems included as a part of the system must be separately identified in Appendix C to the SSP, this appendix will be included as an attachment to the system’s ATO Letter.

• Section 11 of the SSP must list all interconnections including the system name, organization, system type; indicate if there is an Interconnection Security Agreement (ISA)/Memorandum of Understanding (MOU)/Memorandum of Agreement (MOA) on file, date of agreement to interconnect, FIPS 199 security category, ATO status, and the name of the AO. Per CIO-SEC-REQ-01, “All interconnections between Peace Corps and external entities including off-site contractors or Federal agency/departments must be documented in an Interconnection Security Agreement (ISA) that is approved by the Peace Corps AO and concurred by the Peace Corps CISO. (Interconnections are identified as connections via a dedicated path for the purpose of data transmission, typically via VPN, between a Peace Corps authorized information systems and information systems not authorized by Peace Corps AO.)” Per NIST 800-47, “Security Guide for Interconnecting Information Technology Systems” an interconnection is the direct connection of two or more IT systems for the purpose of sharing data and other information resources through a pipe, such as ISDN, T1, T3, DS3, VPN, etc.”

Peace Corps 14

Contact the CISO at ciso@peacecorps.gov with questions or requests for further clarification.

TASK 1-3: Information System Registration - Register the information system with the appropriate organizational program/management offices and security personnel. Inform the OCISO, the System/Application ISSM, and, if different, the ISSM of the larger system on which the system will reside and from which it will inherit security controls. In addition, each IT system is also an IT investment, which needs to be associated with a Unique Investment Identifier.

2.2 RMF Step 2 – Select Security Controls

Based on the FIPS 199 impact level (Low-, Moderate-, or High-impact) determined in Step 1, the appropriate controls will be selected based on PC’s CIO-SEC-STD-01, “Information Security Control Catalog” (ISCC) which also provides the assignment parameters for the applicable NIST SP 800-53 controls. In RMF Step 2, controls will be identified as system-specific, hybrid, or common; controls will be tailored and supplemented (as necessary) with additional controls and/or control enhancements to address unique organizational or system specific risks; a monitoring strategy will be developed; and the AO’s, or designated representative’s, approval of the SSP obtained.

The following tasks detail the actions in RMF Step 2.

TASK 2-1: Common Control Identification – Leverage PC’s CIO-SEC-PLN-04, “Information Security Program Plan” to identify the PC common controls and document them in the SSP initiated in RMF Step 1. Common controls are security controls that are inherited. Common control sources may include the IT Security Program, PC enterprise information systems, shared processes, and other sources. PC’s common control program is documented in CSAM as the Information System Program (ISP). System Owners inheriting common controls can either document the implementation of the controls in their respective security plans or reference the controls contained in the security plans of the common control providers.

NOTE: The ISP is currently being merged from a series of disparate programs offered by individual offices, so at the time of publication of this document, all controls may not have been fully migrated into that consolidated program.

Common control providers are responsible for:

• documenting common controls in a security plan (or equivalent document prescribed by the organization);

• ensuring that common controls are developed, implemented, and assessed for effectiveness by qualified assessors with a level of independence required by the organization;

Peace Corps 15

• documenting assessment findings in a security assessment report;

• producing a plan of action and milestones for all common controls deemed less than effective (i.e., having unacceptable weaknesses or deficiencies in the controls);

receiving authorization for the common controls from the AO; and monitoring common control effectiveness on an ongoing basis.

The Common Control Provider’s SSP, Security Assessment Report (SAR), and Plan of Action and Milestones (POA&M) for common controls (or a summary of such information) should be made available to System Owners (whose systems are inheriting the controls) after the information is reviewed and approved by the AO responsible and accountable for the controls.

A Control Summary Table pertaining to the FIPS 199 impact level associated with the system must be completed. The table identifies control types (common vs. hybrid controls vs. system specific controls) with implementation status (Fully Implemented, Partially Implemented, Planned, etc.) across required controls. The table should be customized to the SO’s or contractor’s environment to account for common controls and subsystems (as necessary).

The completed Control Summary table will be included in the appendices section of the SSP. It will be updated in subsequent steps of the RMF process, including after security control implementation and following security assessment to document the results of the review.

TASK 2-2: Security Control Selection - Select the security controls for the information system and document the controls in the SSP. The security controls are selected based on the FIPS 199 security categorization determined in RMF Step 1, Task 1-1, forming the minimum security control baseline for the information system. Once the security control baseline is determined, it must be tailored by applying scoping, parameterization, compensating control guidance, and any PC required controls. The tailored baselines, as necessary, can be supplemented with additional controls and/or control enhancements to address unique organizational and/or system specific needs based on a risk assessment (either formal or informal) and local conditions including environment of operation, organization-specific security requirements, specific threat information, cost-benefit analyses, or special circumstances.

The ISCC identifies the PC defined values for NIST SP 800-53 control assignments and selections.

The selected security controls including any controls or enhancements selected above the baseline for the information system will be documented in the SSP. Define the settings deferred to SO or contractor recommendation to be reviewed and accepted by the AO.

Note: Additional Federal requirements such as DHS Cybersecurity Directives must be included in a system’s set of requirements when the system contains components to which they apply.

TASK 2-3: Monitoring Strategy - Develop a strategy for the continuous monitoring of security control effectiveness and any proposed or actual changes to the information system and its environment of operation. The developed strategy may follow the RMF Step 6 - Security Control Monitoring process outlined within Section 2.6.1 of this guide, or the process in CIO-https://cyber.dhs.gov/directives/ https://cyber.dhs.gov/directives/ https://cyber.dhs.gov/directives/ https://cyber.dhs.gov/directives/ https://cyber.dhs.gov/directives/ https://cyber.dhs.gov/directives/

Peace Corps 16

SEC-PLN-01 “Continuous Monitoring (ISCM) Strategy and Ongoing Authorization Program” for systems in PC’s Continuous Monitoring Program. The Information System Continuous Monitoring Plan described in CIO-SEC-PLN-01 may be used by any System Owner to help form an initial strategy.

TASK 2-4: Security Plan Approval - Review and approve the security plan. The System Owner (via the ISSO) shall submit the SSP with the following appendices/attachments to the CISO, ISSM, and the AO. The remainder of the SSP’s appendices and attachments will be completed as the security controls are implemented in RMF Step 3.

• Appendix A - Acronyms, Terms, and Definitions

• Appendix B - References

• Appendix C - Hosted Subsystems (if applicable)

• Attachment 1: Privacy Threshold Analysis/Privacy Impact Assessment

• Attachment 2: FIPS 199 Security Categorization

• Attachment 3: Digital Identity Acceptance Statement (if applicable)

• Attachment 4: Interconnection Security Agreement (if applicable)

• Attachment 5: PC Control Summary Table

• Attachment 6: Contingency Plan

• Attachment 7: Contingency Plan Test Report

• Attachment 8: Incident Response Plan

• Attachment 9: Incident Response Plan Test Report

• Attachment 10: Configuration Management Plan (FIPS 199 Moderate and High only)

• Attachment 11: Continuous Monitoring Plan (if applicable)

• Attachment 12: Rules of Behavior (if applicable)

• Attachment 13: Code Review Report (if applicable)

Note: Approving the security plan is an agreement that the set of security controls (system-specific, hybrid, and/or common controls) proposed to meet the security requirements for the information system are sufficient. This approval allows the next step in the RMF to commence (i.e., the implementation of the security controls).

The CISO will review the SSP to determine if it is complete, consistent, and addresses the security requirements for the information system. Based on the results of the review, the SSP may require further updating, or may be approved. The CISO, by approving the security plan, agrees to the set of security controls (system-specific, hybrid, and/or common controls) proposed to meet the security requirements for the information system; allowing Step 3 of the RMF to begin.

• The Information Security Engineers (ISE) must review the proposed Security Architecture before the system’s security controls are implemented.

Peace Corps 17

• Security Plans will be submitted by the System Owner/Program Manager through the ISSO and ISSM to the CISO for review.

• The CISO must accept the SSP before security control implementation activities can begin.

2.3 RMF Step 3 – Implement Security Controls

Following the approval of the SSP received in RMF Step 2, implement the security controls specified in the SSP.

The following tasks detail the actions in RMF Step 3.

TASK 3-1: Security Control Implementation - Security control implementation should be consistent with the PC enterprise architecture and information security architecture. IT systems shall be configured and hardened using PC IT security hardening guidelines (i.e., security benchmarks), NIST guidelines, Center for Internet Security guidelines, USGCB or industry best practice guidelines, as deemed appropriate by the CISO or AO.

To the greatest extent possible, systems are encouraged to conduct initial security control assessments (also referred to as developmental testing and evaluation) during information system development and implementation. Such testing conducted in parallel with the development and implementation of the system facilitates the early identification of weaknesses and deficiencies and provides the most cost-effective method for initiating corrective actions.

Note: Federal requirements such as DHS Cybersecurity Directives include specific implementation instructions which must be adhered to in order to secure the system and comply with the requirement.

TASK 3-2: Security Control Documentation - Describe the security control implementation in the SSP, providing a functional description of how the control is satisfied. The security control implementation descriptions should include planned inputs, expected behavior, and expected outputs (where appropriate) that are typical for technical controls. The SSP should also address platform dependencies and include any additional information necessary to describe how the security capability required by the security control is achieved at the level of detail sufficient to support control assessment in RMF Step 4.

Security controls are documented in Section 13 of the SSP. This section must provide a thorough description of how the NIST SP 800-53 security controls for the system are being implemented or planned to be implemented. For each control, descriptions must include:

• the security control title;

• how the security control is being implemented or planned to be implemented;

https://cyber.dhs.gov/directives/ https://cyber.dhs.gov/directives/ https://cyber.dhs.gov/directives/ https://cyber.dhs.gov/directives/ https://cyber.dhs.gov/directives/

Peace Corps 18

• any scoping guidance that has been applied and what type of consideration;

• identify the control type (Common, Hybrid, System Specific); and

• identify the implementation status (Implemented, Partially Implemented, Planned, N/A, Alternate Implementation, etc.), and who is responsible for its implementation.

Note: Systems with multiple components or subsystems must describe control implementations across all components.

2.4 RMF Step 4 – Assess Security Controls

Upon implementation of security controls in RMF Step 3, perform a security control assessment to determine the extent to which security controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting security requirements.

Complete the tasks below to determine in place security controls, prepare a SAR, and initiate corrective actions based on the findings and recommendations within it.

The following tasks detail the actions in RMF Step 4.

TASK 4-1: Assessment Preparation - Develop, review, and obtain approval for a Security Assessment Plan (SAP) which will be leveraged to assess the security controls of the information system.

The SAP will provide system background information, the objectives for the security control assessment, the assessment approach, and the assessment test cases to be used in Task 4-2.

Review, update, and/or supplement PC’s NIST 800-53 Rev 4 Test Cases. Add additional assessment test cases for any supplemented controls and/or control enhancements added during Task 2-2, Security Control Selection, to address unique organizational and/or system specific needs.

Note: Assessment of additional Federal requirements including, but not limited to, DHS Cybersecurity Directives (i.e., Binding Operational Directives and Emergency Directives) must be included in the SAP as appropriate.

The following security assessment requirements must be defined in the SAP and implemented for all information systems per its FIPS 199 impact level:

• FIPS 199 Moderate and High impact systems must be assessed by an independent third party. The use of an independent assessment team reduces the potential for impartiality or conflicts of interest, when verifying the implementation status and effectiveness of the security controls. Independence, per NIST, is impartiality where the assessors are free from any perceived or actual conflicts of interest with respect to the development, operation, and/or management of the information system or the determination of security control effectiveness.

https://cyber.dhs.gov/directives/ https://cyber.dhs.gov/directives/ https://cyber.dhs.gov/directives/ https://cyber.dhs.gov/directives/ https://cyber.dhs.gov/directives/ https://cyber.dhs.gov/directives/

Peace Corps 19

• All FIPS 199 impact level information systems must conduct authenticated vulnerability scanning of their servers’ operating systems as part of security assessment activities.

Configuration/compliance scans shall be to PC technical guidelines, NIST guidelines, Center for Internet Security guidelines, or industry best practice guidelines, as deemed appropriate. Where a PC benchmark exists, configuration scanning must be to PC benchmarks. Any scanning tool configured to support the benchmarks or guidelines identified may be used. Contact CISO for information on the current tools in use or if there is a question about a specific tool.

• All FIPS 199 impact level information systems with web servers must conduct an authenticated vulnerability scan for the most current Open Web Application Security Project (OWASP) Top Ten Most Critical Web Applications Security Vulnerabilities. Any scanning tool configured to support the OWASP Top 10 may be used. Contact CISO for information on the current tools in use or if there is a question about a specific tool. If necessary, manual testing and/or verification using the most current OWASP Testing Guide is also acceptable.

• All FIPS 199 impact level information systems with database servers must have their databases assessed as part of their OS vulnerability scanning.

Note: This capability is being expanded within PC in late 2021 and may not be available at the time of this document’s release. Contact the CISO for more information.

• All Internet accessible systems, FIPS 199 High impact level, and High Value Asset (HVA) information systems, are required to complete an independent penetration test (or ‘pentest’) and provide a Penetration Test Report documenting the results of the exercise as part of the Assessment and Authorization (A&A) package.

The SAP must be reviewed and approved by the System Owner, ISSO, and ISSM to ensure that the plan:

• includes all appropriate security controls;

• is consistent with system/organizational security objectives;

• employs required assessment tools and techniques;

• provides assessment test cases; and

• outlines automation to support the concept of continuous monitoring and near real-time risk management.

The overall purpose of the SAP approval is two-fold: (1) to establish the appropriate expectations for the security control assessment; and (2) to bound the level of effort for the security control assessment.

TASK 4-2: Security Control Assessment - Assess the security controls following the SAP and using the NIST 800-53 Rev 4 Test Cases, including any supplemental or updated tests based on the specific system as identified in Task 4-1 (e.g., assessing BODs or other Federal requirements). The assessment determines if the controls implemented in RMF Step 3 are https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

Peace Corps 20 operating as intended and producing the desired outcome with respect to meeting the security requirements for the information system.

TASK 4-3: Security Assessment Report (SAR) - Prepare a Security Assessment Report documenting the issues, findings, and recommendations of the security control assessment (including, if applicable, a penetration test report as an attachment). Document the assessment findings with recommendation(s) and risk determinations from the NIST SP 800-30 Revision 2, “Guide for Conducting Risk Assessments.” Note that this revision of NIST 800-30 expands the risk rating matrix to five levels; Very Low, Low, Moderate, High, and Very High (equivalent to Critical). Findings in the SAR will be addressed in the following manner:

Findings from Test Cases. Each individual finding must be assessed for risk.

Note: Any additional findings based on Federal requirements, such as BODs, must be reported in the SAR.

Findings from Vulnerability Scans. Individual findings must be identified; however, findings may be grouped and assessed by level and type of scan. These findings should be assessed in the following groupings and associated with NIST SP 800-53 control SI-2.

1. Very High (Critical)/High OS (includes DB, if applicable) Findings

2. Very High (Critical)/High Web Application Findings

3. Moderate OS (includes DB, if applicable) Findings

4. Moderate Web Application Findings

Low risk findings based on scans do not have to be assessed within the SAR; however, those findings need to be included in the scan results attached to the SAR.

Findings from Configuration/Compliance Scans. Individual findings must be identified.

The findings will be discussed as one group. It will be listed at the Moderate level and associated with NIST SP 800-53 control CM-6.

Risk must be determined for findings, as described above, and an overall system or application risk determined. The risk determination will be included as part of the authorization package.

Refer to NIST SP 800-30, Revision 2 to ensure that all necessary risk assessment areas are completed.

The risk assessment should consist of the following steps:

• Identifying the list of threats and threat sources to the system. The list should include but not be limited to adversarial outsider and insider threats, accidental user threats, structural threats to its components and facilities, environmental threats to the systems facilities and supporting services;

• Aligning threat sources and events with vulnerabilities;

Peace Corps 21

• Assessing each system instance of absent controls and/or vulnerabilities identified during the security assessment. Evaluate the likelihood the threat sources and events will exploit an identified vulnerability;

• Assess the possible impact to the system and PC if the vulnerability was exploited;

• Make a determination of risk based on the likelihood the threat will exploit the vulnerability, and the resulting impact, and;

• Evaluate the risks of all identified vulnerabilities to determine an overall level of risk for the system or application.

The SAR must document all findings from the security assessment test cases that are not FULLY SATISFIED and address scan findings as described above. Assessments must include vulnerabilities, threats, an in place controls discussion, likelihood, impact, risk discussion/rating, and recommendations for correcting deficiencies in security controls. Assessment results for subsystems, if any, should be included as a subsection to Section 6 – Findings Discussion of the hosting system’s SAR. If there is more than one subsystem, a separate subsection should be created for each subsystem.

Note: Review and consider ALL risk categories in the process of preparing the final SAR. It is a common mistake to ignore some classes since they are incorrectly believed to be "low risk".

However all scanner tools can categorize findings, in much the same way that false positive findings are not real issues, false negative findings or "low/info risk" findings can be real issues, which a human reader will understand are necessarily more important than initially labeled.

Moreover low risk items often enhance the risk of other issues or can successfully be combined to generate higher risk. Once identified, they should be rated appropriately (i.e., no longer Low) in the final SAR.

FIPS 199 Low or Moderate level systems can possess Very High (Critical)/High risk findings the same as FIPS 199 High level systems.

TASK 4-4: Remedial Action - Conduct initial remediation actions on security controls based on the findings and recommendations of the SAR and reassess remediated control(s), as appropriate. Findings that are remediated should be appropriately marked in the final SAR. In the final SAR, include ‘‘Resolved” next to the NIST SP 800-53 Control Heading.

2.5 RMF Step 5 – Authorize Information System

Following assessment of the information system in RMF Step 4, the POA&M is prepared (updated if an existing system with a POA&M) based upon the results of the security assessment and any remedial action to correct findings; the Security Authorization Package is assembled and submitted to the AO for adjudication. The AO must determine if the remaining known vulnerabilities in the information system pose an acceptable level of risk to agency operations, assets, and individuals and determine if the overall risk to the agency is acceptable.

Peace Corps 22

Note: PC tracks all POA&Ms in CSAM which serve as the primary tool for the management, storage, and dissemination of PC system and program POA&Ms. The initial POA&M development, however, is performed using the PC Weakness Evaluation Report (WER) and Corrective Action Planning (CAP) worksheet. Approved CAPs are entered into CSAM as POA&Ms.

The following tasks detail the actions in RMF Step 5 – Authorize Information System.

TASK 5-1: Plan of Action and Milestones - Prepare the POA&M from the findings and recommendations in the SAR excluding any remediation actions taken.

Develop the POA&M as follows:

- Do not include vulnerabilities identified as ‘‘Resolved” in the SAR.

- Include any vulnerabilities associated with End-of-Life (EOL) software, regardless of the associated risk level.

- Do not include vulnerabilities identified as Low/Very Low risk in a POA&M, unless they are associated with EOL software or audit findings. Low/Very Low vulnerabilities still need to be included in the SAR either in relation to a NIST control test case or in the scan results appendices/attachments.

- Very High (Critical), High, and Moderate risk vulnerabilities need to be included in the POA&M using the following criteria:

o Assessment findings from test cases become individual entries in the POA&M.

o Findings based on scans are grouped based on the type of scan (i.e., OS, Web Application).

Vulnerability Scans. Findings will result in one POA&M entry (per scan type-e.