LC Security Assessment and Authorization Guidance_08242020_v5.1.pdf

SECURITY ASSESSMENT AND AUTHORIZATION

(A&A) GUIDANCE

OFFICE OF THE CHIEF INFORMATION OFFICER

INFORMATION TECHNOLOGY SECURITY DIVISION

Version 5.1

August 24, 2020

LOC Security Assessment and Authorization Guidance

August 24, 2020 i

Document History

Version Version Date Summary of Changes Team/Author v1.0 January 11, 2007 Initial Document Steve Elky v2.0 February18, 2014 Updated document with most current advisement practices

Darren Death v3.0 October 6, 2014 Updated guidance based on the NIST SP

800-37 Risk Management Framework and

Supplemental Guidance

Karen Beirne v3.0 December 29, 2014 QA Dawn Thompson v3.1 May 22, 2015 Final updates made based on Archer configuration and workflow.

Karen Beirne v3.2 September 25, 2015 Reorganized the sections in the procedure. Grace Kim v3.3 October 9, 2015 Updated language throughout from ITS to

OCIO

Karen Beirne v3.4 October 31, 2015 Section 2 – added Figure 1, IT Security

Program A&A Roles; updated roles and responsibilities descriptions, added

Information Security Architect, added the latest version of the separation of duties table

Karen Beirne v3.5 December 9, 2015 Section 3 – updated figure 2-RMF; added definitions for minor application and subsystem; Updated Figure 3 to include disposal phase; updated sections to address

Archer implementation; added table listing the RMF Step 1 tasks; added SP implementation detail guidance

Grace Kim v3.6 April 18, 2016 Section 5 – Added new section: Security

Assessment and Authorization for Cloud

Systems. Cloud Deployment Models, FedRAMP Security Package Categories;

FedRAMP Category details; how to request a cloud security package.

Karen Beirne v3.7 July 17, 2017 Section 7 – Added subsystem section. Jim Kurucz v3.8 September 6, 2017 Appendix A – updated list of acronyms Terry Grogan v4.0 September 26, 2018 Appendix B – updated various terms LaShawn Herndon v5.0 July 13, 2020 Major updates throughout Guidance Gary McCoy

August 24, 2020 ii

Version Version Date Summary of Changes Team/Author v5.1 August, 24, 2020 Section 11 (Reciprocity and Authorization to Use) – Added specific Library-specific controls that should be tailored and specific clarified documents needed (ITCP, ISCM

Plan, and SAM)

Gary McCoy

August 24, 2020 iii

Table of Contents

1 Introduction

1.1 Purpose

1.2 References

2 Roles and Responsibilities

2.1 Chief Information Officer (CIO)

2.2 Deputy Chief Information Officer (DCIO)

2.3 Authorizing Official (AO)

2.4 Chief Information Security Officer (CISO)

2.5 Chief Privacy Officer

2.6 Information System Security Officer (ISSO)

2.7 Privacy Officer

2.8 Information System Business Owner (ISBO)

2.9 Information Owner (IO)/Steward

2.10 Common Control Provider

2.11 System Administrator (SA) / Application Administrator (AA)

2.12 Security Architect

2.13 Library Partners

2.14 Ensuring Proper Separation of Duties

3 Risk Management Framework

3.1 Preparation

3.2 Categorize Information System

3.3 Select Security Controls

3.4 Implement Security Controls

3.5 Assess Security Controls

3.6 Authorize Information System

3.7 Monitor Information System

4 Security Assessment and Authorization for non-Library Information Systems 5 Security Assessment and Authorization for Cloud Systems

5.1 Cloud Deployment and Service Models

5.2 FedRAMP Security Package Categories

5.3.1 FedRAMP Category: Agency

5.3.2 FedRAMP Category: Joint Authorization Board (JAB)

5.3.3 FedRAMP Category: Cloud Service Provider (CSP)

5.3 Leveraging FedRAMP Compliant Package

5.3.4 FedRAMP – RMF Step 1: Categorize

5.3.5 FedRAMP – RMF Step 2: Select

5.3.6 FedRAMP – RMF Step 3: Implement

5.3.7 FedRAMP – RMF Step 4: Assess

5.3.8 FedRAMP – RMF Step 5: Authorize

5.3.9 FedRAMP – RMF Step 6: Monitor

5.4 FedRAMP Package Request

6 Library of Congress IT Security Architectural Principles

7 Information System Types

7.1 General Support Systems (GSS)

August 24, 2020 iv

7.2 Major Applications (MA)

7.3 Low Impact Externally Hosted (LIEH) Systems

7.4 Subsystems

7.5 Workstation Applications

8 Hosted Applications 9 Determining the Hosting Option 10 Determining System Security Boundaries

10.1 Threat Zones

11 System Reciprocity and Authorization to Use

11.1 Applicability

11.2 Process

Appendix A: Acronyms Appendix B: Glossary Appendix C: Sample Implementation Details Appendix D: Security A&A Work Breakdown Structure (WBS)

Table of Figures and Tables

Figure 3-1 - Risk Management Framework Figure 3-2: LOC SDLC to NIST RMF

Figure 5-1: FedRAMP Key Stakeholders

Figure 5-2: Service Model Examples

Table 2-1: Allowable IT Security Role Combinations

Table 3-1: Prepare Tasks Table 3-2: Categorize Tasks

Table 3-3: Selection Tasks Table 3-4: Implement Tasks Table 3-5: Assess Tasks

Table 3-6: Authorize Tasks Table 3-7: Monitor Tasks

Table 4-1: IT Security Related Roles for non-Library Information Systems Table 5-1: Cloud Service Deployment Models Table 5-2: Cloud Service Models

Table 5-5-3: FedRAMP Security Package Categories Table 5-4: FedRAMP - RMF Step 1: Categorize Table 5-5: FedRAMP - RMF Step 2: Select Table 5-6: FedRAMP - RMF Step 3: Implement Security Controls Table 5-7: FedRAMP - RMF Step 4: Assess Security Controls

Table 5-8: FedRAMP - RMF Step 5: Authorize Cloud System Table 5-9: FedRAMP - RMF Step 6: Monitor Security Controls

Table 7-1: LIEH A&A Tasks for New Information Systems Table 7-2: LIEH A&A Tasks for Annual Assessment Table 7-3: LIEH Security Controls Table 7-4: Subsystem Security Review Controls

August 24, 2020 v

Table 9-1: Hosting Options Table 10-1: Library of Congress Threat Zones Table 11-1: System Reciprocity/Authorization to Use Process

August 24, 2020 6

1 Introduction

The Library of Congress (LOC) is the Nation's oldest Federal cultural institution and serves as the research arm of Congress. It is also the largest library in the world, with millions of books, recordings, photographs, maps and manuscripts in its collections. In order to support the confidentiality, integrity, and availability of the Library’s collections, the Office of the Chief

Information Officer (OCIO), Information Technology Security Division (ITSEC) has developed this Security Assessment & Authorization (A&A) Guidance.

1.1 Purpose

The purpose of this guidance is to provide the Library with a standard approach for conducting an A&A for the information systems supporting the Library’s mission and business functions.

The guidance will ensure the appropriate security and privacy controls are selected, implemented, assessed, and monitored on an ongoing basis in order to manage risks to the information systems.

The guidance is based on National Institute of Standards and Technology (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. Guidance contained herein covers all Library Information Technology (IT) systems, including Information systems that process data on behalf of the Library.

1.2 References

The Library has formally adopted NIST guidance, codifying it into Information Technology

Security Directive 5-410.1, General Information Technology Security. The following NIST special publications are relevant to the Security Assessment and Authorization process:

NIST Special Publication 800-18, Revision 1, Guide for Developing Security Plans for

Information Technology Systems

NIST Special Publication 800-30, Revision 1, Guide for Conducting Risk Assessments

NIST Special Publication 800-34, Revision 1, Contingency Planning Guide for

Information Technology Systems

NIST Special Publication 800-37, Revision 2, Risk Management Framework for

Information Systems and Organizations: A System Life Cycle Approach for Security and

Privacy

NIST Special Publication 800-39, Managing Information Security Risk

NIST Special Publication 800-47, Security Guide for Interconnecting Information

Technology Systems

NIST Special Publication 800-53, Revision 4, Security and Privacy Controls for Federal

Information Systems and Organizations

NIST Special Publication 800-53A, Guide for Assessing the Security Controls in Federal

Information Systems

NIST Special Publication 800-60, Revision 1, Volume 1, Guide for Mapping Types of

Information and Information Systems to Security Categories

August 24, 2020 7

NIST Special Publication 800-60, Revision 1, Volume 2, Appendices to Guide for

Mapping Types of Information and Information Systems to Security Categories

NIST Special Publication 800-137, Information Security Continuous Monitoring for

Federal Information Systems and Organizations

NIST Special Publication 800-144, Guidelines on Security and Privacy in Public Cloud

Computing

NIST Special Publication 800-160, Volume 1, Systems Security Engineering:

Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy

Secure Systems

Federal Information Processing Standard 199, Standards for Security Categorization of

Federal Information and Information Systems

Federal Information Processing Standard 200, Minimum Security Requirements for

Federal Information and Information Systems

Federal Risk and Authorization Management Program (FedRAMP) Program

Management Office, FedRAMP.gov

Additionally, the Library generally follows the Federal Information Security Modernization Act

(FISMA). The primary exception is that the Library does not report security status of its

Information systems to the Office of Management and Budget (OMB) for quarterly and annual

FISMA reporting requirements.

August 24, 2020 8

2 Roles and Responsibilities

The Library regards certain IT security roles as inherently governmental. These roles include the

Chief Information Officer (CIO), Chief Information Security Officer (CISO), Authorizing

Official (AO), Information Owners (IO), and Information System Business Owners (ISBO).

Contractors who are working on behalf of the Library may assist in the performance of security functions. However, with the exception of the Information System Security Officer (ISSO), which may be a Library contractor, the responsible agent for all security requirements and functions must be a Library employee.

The Office of Chief Information Officer (OCIO) is responsible for operating the IT Security

Program for the Library.

The following sections describe the roles and responsibilities of key participants involved in the

Library’s A&A process.

2.1 Chief Information Officer (CIO)

The CIO is a Library official who is responsible for ensuring that the LOC IT Security Program is established and managed in accordance with all of the Library policies and directives. The CIO determines the appropriate allocation of resources that can be dedicated to the protection of the

Library information systems that support the LOC mission and business functions. The allocation of resources for each information system is determined based on organizational priorities.

2.2 Deputy Chief Information Officer (DCIO)

The DCIO serves as the Senior Accountable Official for Risk Management and is responsible for leading and managing the risk executive (function) at the Library. In addition, the DCIO is responsible for aligning information security and privacy risk management processes with strategic, operational, and budgetary planning processes.

The DCIO ensures that residual risk is consistent with the LOC-defined risk tolerance, and that a risk assessment is performed as part of an LOC-wide collaborative risk management initiative.

2.3 Authorizing Official (AO)

The AO is appointed by the Chief Information Officer. The AO is a senior official with the authority to formally assume responsibility and accountability for operating an information system at an acceptable risk; providing common controls inherited by organizational systems; or using an information system, service, or application from an external provider.

The Deputy CIO (DCIO) serves as the Authorizing Official for all LOC systems. In the event that a conflict of interest is perceived or apparent, the CIO will assign an alternate AO for the information system or systems.

August 24, 2020 9

The AO reviews the security assessment results and the recommendation from the Security

Control Assessor (SCA), or, CISO. Only the AO has the authority to grant an authorization to operate (ATO), Authorization to Use, or an ongoing authorization to operate (OATO).

The AO is the only Library official who can accept the security and privacy risk to Library operations, assets, and individuals. The AO is responsible and accountable for ensuring that authorization activities and functions that are delegated to authorizing official designated representatives are carried out as specified. The only activity that cannot be delegated by the authorizing official to the designated representative is the authorization decision and signing of the associated authorization decision document (i.e., the acceptance of risk).

2.4 Chief Information Security Officer (CISO)

The CISO is the LOC Senior Agency Information Security Officer who implements and manages the LOC IT Security Program. Proper implementation ensures compliance with all applicable Federal laws, directives, policies, and regulations. The CISO reviews and approves the tools, techniques, and methodologies that will be used for assessing and authorizing LOC information systems.

The CISO, or designate, serves as the Security Control Assessor (SCA). The role of Security

Control Assessor (SCA) has been included within the Chief Information Security Officer (CISO) responsibilities. NIST guidelines indicate the need for assessor independence to be determined by the organization. Within LOC, the CISO decides the required level of assessor independence based on the criticality and sensitivity of the information system and the ultimate risk to organizational operations, organizational assets, and individuals. The LOC CISO determines if the level of assessor independence is sufficient to provide confidence that the assessment results produced are sound and can be used to make credible, risk-based decisions.

The SCA is responsible for conducting a security control assessment for Library information systems. The security assessment team carries out the security control assessments on behalf of the CISO.

Under the direction of the SCA, the ITSEC Security Assessment Team (SAT) is responsible for developing the security assessment plan, executing the test procedures, and documenting the test results in Archer. The SAT provides an assessment of weaknesses or deficiencies in the information systems. The SAT then prepares the final security assessment report, which contains the results and findings from the assessment. In addition, the SAT conducts the vulnerability and compliance scanning.

2.5 Chief Privacy Officer

The chief privacy officer is the senior official or executive with agency-wide responsibility and accountability for ensuring compliance with applicable privacy requirements and managing privacy risk. Library of Congress Regulation (LCR) 5-920 designates the General Counsel as the

Chief Privacy Officer (i.e., Senior Agency Official for Privacy). The Library’s chief privacy officer has overall responsibility for all of the Library’s privacy information activities, including the formulation of PII policy, design and implementation of PII security, assurance of PII policy

August 24, 2020 10 compliance, and provision of PII training. As related to the RMF, the chief privacy officer is responsible for the following:

• Coordinating with the CISO to ensure coordination of privacy and information security activities;

• Reviewing and approving the categorization of information systems that create, collect, use, process, store, maintain, disseminate, disclose, or dispose of personally identifiable information;

• Designating which privacy controls will be treated as program management, common, system-specific, and hybrid privacy controls;

• Identifying assessment methodologies and metrics to determine whether privacy controls are implemented correctly, operating as intended, and sufficient to ensure compliance with applicable privacy requirements and manage privacy risks;

• Reviewing and approving privacy plans for information systems prior to authorization, reauthorization, or ongoing authorization;

• Reviewing authorization packages for information systems that create, collect, use, process, store, maintain, disseminate, disclose, or dispose of personally identifiable information to ensure compliance with privacy requirements and manage privacy risks;

• Conducting and documenting the results of privacy control assessments to verify the continued effectiveness of all privacy controls selected and implemented at the agency;

and

• Establishing and maintaining a privacy continuous monitoring program to maintain ongoing awareness of privacy risks and assess privacy controls at a frequency sufficient to ensure compliance with privacy requirements and manage privacy risks.

The role of chief privacy officer is assigned to government personnel only.

Note: LCR 5-290 does not apply to PII collected, maintained or used by the Copyright Office in the performance of its duties under the copyright law.

2.6 Information System Security Officer (ISSO)

The Information System Security Officer (ISSO) supports the ISBO in day-to-day IT security activities. The ISSO assists the ISBO with reviews of the security posture of the system and report any findings to the ISBO, CISO, and the Authorizing Official (AO). It is the expectation that the ISSO assist the ISBO by completing security documentation. It is also the expectation that the ISBO and the ISSO have frequent discussion on the security posture of the system to ensure that IT security requirements are met.

All systems must have an assigned ISSO and the ISSO may be responsible for multiple systems.

The ISSO responds to IT security-related requests and may not serve as the AO, CISO, ISBO, IO, or SA for any information system.

2.7 Privacy Officer

The privacy officer is responsible for ensuring that the privacy posture is maintained for a

Library information system and works in close collaboration with the ISBO and ISSO. The

August 24, 2020 11

Office of the General Council (OGC) serves as the Library’s privacy office. As such, the privacy officer is responsible for aspects of the information system that ensure compliance with privacy requirements and manage the privacy risks to individuals associated with the processing of PII.

The privacy officer may assist in the development of the system-level privacy policies and procedures and ensure compliance. In close coordination with the ISBO and ISSO, the privacy officer plays an active role in the development and review of an information system’s Privacy

Threshold Analysis (PTA) and Privacy Impact Assessment (PIA). The privacy officer may also assist in assessing the privacy impact of information system changes.

Note: The responsibilities of ISSO and privacy officers may overlap regarding aspects of the system that protect the security of PII.

2.8 Information System Business Owner (ISBO)

The ISBO is assigned by the AO and is typically a manager with budgetary authority. The ISBO is ultimately accountable for the security of the system and their responsibilities include, but are not limited to, the following areas:

Ensure that the information system is deployed and operated in accordance with IT

Security Directive 5-410.1.

Plan for and provide IT Security protection by budgeting adequate resources to fulfill all

LOC security requirements throughout the entire lifetime of the information system.

Formally approve all changes to the information system; ensuring that all changes

(software, hardware, and configuration) follow a formal change management process.

Ensure that an analysis is performed, to determine all necessary training for both technical and user communities, whenever there is a change in the information system.

Ensure that IT and security positions, including contract positions and an ISSO, are appropriately designated in writing in accordance with position sensitivity criteria.

Document the Security Categorization for the information system.

Prioritize security weaknesses for mitigation; ensuring that information security requirements and Plan of Action & Milestones (POA&M) are adequately funded, resourced, and documented.

Ensure that the necessary agreements are in place to permit the resumption of information system operations at the alternate processing site for critical mission/business functions within the allowable outage time determined in the Business Impact Analysis (BIA) when primary processing capabilities are unavailable.

Formally approve the IT Contingency Plan.

Formally approve the PTA and the PIA, as required.

Ensure that information system security controls are maintained, training is performed, and the user base is governed per the requirements in IT Security 5-410.1.

2.9 Information Owner (IO)/Steward

The IO/steward is an organizational official with statutory, management, or operational authority for specified information and the responsibility for establishing the policies and procedures

August 24, 2020 12 governing its generation, collection, processing, dissemination, and disposal. The owner/steward of the information processed, stored, or transmitted by an information system may or may not be the same as the ISBO.

The IO/steward is assigned by the ISBO to determine the value of the information that is processed, stored, or transmitted, in relation to the LOC mission. The IO is typically a manager with extensive knowledge of the business processes of the information system. The IO must be a

LOC employee with sufficient knowledge to determine the impact on the LOC mission due to a compromise of the information system.

The IO is responsible for performing security categorization for all information types that will be processed on the system. Information types are taken from the categories and types defined in

NIST SP 800-60, Rev. 1, Volume 1 and Volume 2. The designated ISBO or ISSO may be assigned to assist with any security categorization activities.

2.10 Common Control Provider

The Common Control Provider is an organizational official responsible for planning, development, implementation, assessment, authorization, and maintenance of organization common controls. The ITSEC compliance team assumes the responsibilities of the Common

Control Provider.

The Common Control Provider (CCP) documents the LOC-wide security controls that can be inherited by Information systems within LOC. The CCP maintains the LOC Enterprise Common

Control (ECC) catalog. The CCP is responsible for mitigating the vulnerabilities at the organizational level that pose risk to all Information systems under the common control authority.

2.11 System Administrator (SA) / Application Administrator (AA)

Systems Administrators include anyone with administrator, root, or other super user operating system privileges on any LOC system other than an LOC workstation. For the purposes of determining separation of duties, any individual who performs account management functions or configuration of any server, system, application, or subsystem is considered a System

Administrator.

Application Administrators are considered a subset of System Administrators; however, Application Administrators differ from System Administrators in that they do not have root or super user privileges on the underlying system. Application Administrators include personnel who have elevated privileges, beyond that of a normal end user, that do not rise to privilege level of a System Administrator. Application Administrators may also include application-level account management personnel.

2.12 Security Architect

The security architect is responsible for ensuring that stakeholder protection needs and the corresponding information system requirements necessary to protect Library missions and

August 24, 2020 13 business functions are adequately addressed in the enterprise architecture including reference models, segment architectures, and solution architectures (systems supporting mission and business processes). The security architect serves as the primary liaison between the enterprise architect and the systems security engineer and coordinates with ISBOs, common control providers, and ITSEC on the allocation of controls.

2.13 Library Partners

The LOC establishes and maintains partner relationships with various entities and organizations to support the LOC missions and functions. LOC partners may be any organization that is not part of the LOC and that stores LOC data. The primary IT security concern of the LOC is to protect its information and its associated business processes using safeguards and countermeasures that are commensurate with their value to the LOC. Therefore, the LOC requires all business partners and contractors to provide information assurance according to the established LOC information security standards. An external service provider (to include cloud service providers (CSP)) is also considered a Library partner type.

2.14 Ensuring Proper Separation of Duties

IT Security Directive 5-410.1, General Information Technology Security, contains specific requirements to separate certain duties concerning IT Security. These requirements are taken from industry best practices and are based upon conflict of interest and fraud prevention. Table

2-1: Allowable IT Security Role Combinations is from IT Security IT Security Directive 5-410.1.

Table 2-1: Allowable IT Security Role Combinations

AO CISO ISSO ISBO IO SA/AA

AO N/A No No No Yes No CISO No N/A No No No No ISSO No No N/A No No No ISBO No No No N/A Yes No

IO Yes No No Yes N/A No SA/AA No No No No No N/A

August 24, 2020 14

3 Risk Management Framework

The Risk Management Framework (RMF) provides a structured approach that enhances the system development life cycle (SDLC) by providing information security and risk management activities. The LOC uses this framework to manage the security posture of information systems against system vulnerabilities and attack surfaces.

The RMF consists of seven (7) steps, including a preparatory step to ensure that the Library is ready to execute the framework and six (6) main steps. All seven steps are essential for the successful execution of the RMF. The steps are as follow:

1. Prepare to execute the RMF from an organization- and a system-level perspective by establishing a context and priorities for managing security and privacy risk.

2. Categorize the information system and the information processed, stored, and transmitted by the system based on an analysis of the impact of loss.

3. Select an initial set of controls for the system and tailor the controls as needed to reduce risk to an acceptable level based on an assessment of risk.

4. Implement the controls and describe how the controls are employed within the information system and its environment of operation.

5. Assess the controls to determine if the controls are implemented correctly, operating as intended, and producing the desired outcomes with respect to satisfying the security and privacy requirements.

6. Authorize the information system or common controls based on a determination that

7. Monitor the information system and the associated controls on an ongoing basis to include assessing control effectiveness, documenting changes to the system and environment of operation, conducting risk assessments and impact analyses, and reporting the security and privacy posture of the information system.

Figure 3-1 - Risk Management Framework

August 24, 2020 15

Each RMF step include various tasks that support the secure implementation of applicable security controls and ongoing management of risk within an information system boundary.

The RMF emphasizes risk management by promoting the development of security and privacy capabilities into information systems throughout the SDLC. The Library mapped the SDLC framework to the RMF to ensure IT Security requirements are built into the development, operations, and maintenance of Information systems.

All of the tasks of the RMF are mandatory for all Information systems, with the exception of subsystems (defined later in the document). The ISBO is responsible for ensuring that there are sufficient resources and/or funding to accomplish all of the IT security-related tasks. The SDLC cannot be tailored to remove the IT security-related tasks for any project that involves:

Implementing a new information system

Implementing a major revision to a current information system

Although any information system undergoing a major revision must also include all of the IT security-related tasks, in the case of a system update, the level of effort for many of the tasks is much lower than for an initial implementation. For purposes of IT security, a major revision is defined as:

Adding new software modules to the information system

Adding new servers to the information system

Adding significant new functionality to the information system

A full version upgrade (e.g., version 2.0 to version 3.0) of the information system

The A&A process must occur for all new information systems. Information systems undergoing major revisions could be bound by the OA process, pending acceptance into the program. By undergoing a major revision, it is possible that an information system will no longer be considered a legacy system (depending on the scope of the revision).

Risk Management Framework:

i. Provides a repeatable process designed to promote the protection of information and information systems commensurate with risk;

ii. Promotes the use of automation for near real-time risk management and ongoing system and control authorization through the implementation of continuous monitoring processes

iii. Provides essential information to senior leaders to facilitate decisions regarding the acceptance of risk to organizational operations and assets, individuals, other organizations, and the Nation arising from the operation and use of information system.

August 24, 2020 16

At the discretion of ITSEC and after a review of the changes, an information system that has a signed and valid ATO that undergoes a major revision may require reauthorization. The CISO, ISSO, and the AO for the information system should be briefed on the planned changes. The AO will then advise the ISBO and the ISSO whether to reauthorize the system or to manage the changes through configuration management. This process is described in more detail within the

Library’s OA strategy.

Note that even if the information system does not require reauthorization, the information system must continue to meet the IT security requirements as defined within its system security plan

(SSP) and any new security controls must be documented and tested. The information system’s configuration management plan or process, in conjunction with the OCIO change management process, will be utilized to track and managed all changes.

OCIO Directive 2017-02 (SDLC directive) describes the mandatory requirements of the

SDLC for the Library, which consists of seven (7) main activities: 1) Requirements and

Analysis, 2) Design, 3) Development, 4) Testing, 5) Implementation, 6) Operations and

Maintenance, 7) Disposition. When applying the OCIO SDLC, OCIO must follow the

Waterfall SDLC or the Agile SDLC. These methodologies have been established as two alternative approaches to fulfilling the mandatory requirements of the SDLC. For more information on the OCIO SDLC, please see the directive.

August 24, 2020 17

The table below provides an overview of how the OCIO SDLC aligns with the steps and tasks of the RMF.

NIST RMF Tasks (system-level) SDLC Phases

P-8 – Mission or Business Focus

Requirements and Analysis

P-9 – System Stakeholders

P-10 – Asset Identification

P-11 – Authorization Boundary

P-12 – Information Types

P-13 Information Life Cycle

P-14 – Risk Assessment - System

P-15 – Requirements Definition

P-16 – Enterprise Architecture

P-17 – Requirements Allocation

P-18 – System Registration

C-1 – System Description

C-2 – Security Categorization

C-3 – Security Categorization Review and Approval

S-1 – Control Selection

Design

S-2 – Control Tailoring

S-3 – Control Allocation

S-4 – Documentation of Planned Control Implementations

S-5 – Continuous Monitoring Strategy – System

S-6 – Plan Review and Approval

I-1 – Control Implementation Development

I-2 – Update Control Implementation Information

A-1 – Assessor Selection

Testing

A-2 – Assessment Plan

A-3 – Control Assessments

A-4 – Assessment Reports

A-5 – Remediation Actions

A-6 – Plan of Action and Milestones

R-1 – Authorization Package

Implementation

R-2 – Risk Analysis and Determination

R-3 – Risk Response

R-4 – Authorization Decision

R-5 – Authorization Reporting

M-1 – System and Environment Changes

Operations and Maintenance

M-2 – Ongoing Assessments

M-3 – Ongoing Risk Response

M-4 – Authorization Package Updates

M-5 – Security and Privacy Reporting

M-6 – Ongoing Authorization

M-7 – System Disposal Disposition

Figure 3-2: LOC SDLC to NIST RMF

The RMF tasks are detailed in the following subsections. The Library utilizes the RSA Archer

Governance, Risk, and Compliance (Archer) tool to track and monitor security assessment and authorization packages.

August 24, 2020 18

3.1 Preparation

In order to execute the RMF from an organization- and a system-level perspective, the Library has established a context and priorities for managing security and privacy risk. The context and priorities for managing security and privacy risks were established by using the following tasks in the RMF Prepare step.

Table 3-1: Prepare Tasks

RMF Task Responsibility Input Outcome

Organizational Level

Task P-1

Risk Management Roles

Identify and assign individuals to specific roles associated with security and privacy risk management.

CIO

Chief Privacy

Officer

Organizational security and privacy policies and procedures;

organizational charts

Individuals are identified and assigned key roles for executing the Risk Management

Framework

Task P-2

Risk Management Strategy

Establish a risk management strategy for the organization that includes a determination of risk tolerance.

CIO

Organizational mission statement;

organizational policies;

organizational risk assumptions, constraints, priorities and trade-offs

A risk management strategy for the

Library that includes a determination and expression of organizational risk tolerance is established

Task P-3

Risk Assessment—

Organization

Assess organization-wide security and privacy risk and update the risk assessment results on an ongoing basis.

DCIO

CISO

Chief Privacy

Officer

Risk management strategy; mission or business objectives;

current threat information; system-level security and privacy risk assessment results;

security and privacy information from continuous monitoring

A Library-wide risk assessment is completed or an existing risk assessment is updated

Task P-4

Organizationally-Tailored

Control Baselines and

Cybersecurity Framework

Profiles

Establish, document, and publish

Library-tailored control baselines and/or Cybersecurity Framework

ISBO

DCIO

Documented security and privacy requirements directing the use of organizationally-tailored control baselines; mission or business objectives;

enterprise

Library-tailored control baselines and/or Cybersecurity

Framework Profiles are established and made available

August 24, 2020 19

RMF Task Responsibility Input Outcome

Profiles. architecture; security architecture; privacy architecture;

organization- and system-level risk assessment results;

list of common control providers and common controls available for inheritance; NIST

Special Publication

800-53B control baselines

Task P-5

Common Control Identification

Identify, document, and publish organization-wide common controls that are available for inheritance by organizational systems.

CISO

Chief Privacy

Officer

Documented security and privacy requirements; existing common control providers and associated security and privacy plans;

LOC IT Security

Program SSP;

organization- and system-level security and privacy risk assessment results

Published ITSEC

Enterprise Common

Control (ECC)

Catalog that identifies common controls that are available for inheritance by Library systems

Task P-6

Impact-Level Prioritization

(Optional)

Prioritize organizational systems with the same impact level.

DCIO Security categorization information for organizational systems; system descriptions;

organization- and system-level risk assessment results;

mission or business objectives

A prioritization of organizational systems with the same impact level is conducted

Task P-7

Continuous Monitoring

Strategy—Organization

Develop and implement an organization-wide strategy for continuously monitoring control effectiveness.

DCIO Risk management strategy;

organization- and system-level risk assessment results;

organizational security and privacy policies.

An organization-wide strategy for monitoring control effectiveness is developed and implemented

System Level

August 24, 2020 20

RMF Task Responsibility Input Outcome

Task P-8

Mission or Business Focus

Identify the missions, business functions, and mission/business processes that the system is intended to support

ISBO Organizational mission statement;

organizational policies;

mission/business process information;

system stakeholder information; requests for proposal or other acquisition documents; concept of operations

Missions, business functions, and mission/business processes that the system will support

Task P-9

System Stakeholders

Identify stakeholders who have an interest in the design, development, implementation, assessment, operation, maintenance, or disposal of the system.

ISBO Organizational mission statement;

mission or business objectives; missions, business functions, and mission/business processes that the system will support;

other mission/business process information;

organizational security and privacy policies and procedures;

organizational charts;

information about individuals or groups

(internal and external) that have an interest in and decision-making responsibility for the system

List of system stakeholders

Task P-10

Asset Identification

Identify assets that require protection.

ISBO

Missions, business functions, and mission/business processes the information system will support; business impact analyses;

internal stakeholders;

system stakeholder information; system information;

information about

Set of assets to be protected

August 24, 2020 21

RMF Task Responsibility Input Outcome other systems that interact with the system

Task P-11

Authorization Boundary

Determine the authorization boundary of the system.

Authorizing

Official

System design documentation;

network diagrams;

system stakeholder information; asset information; network and/or enterprise architecture diagrams

Documented authorization boundary

Task P-12

Information Types

Identify the types of information to be processed, stored, and transmitted by the system.

ISBO

IO/Steward

System design documentation; assets to be protected;

mission/business process information;

system design documentation

A list of information types for the system

Task P-13

Information Life Cycle

Identify and understand all stages of the information life cycle for each information type processed, stored, or transmitted by the system.

Chief Privacy

Officer

ISBO

IO/Steward

Business functions and mission/business processes;

authorization boundary information;

information about interaction with other systems (e.g., information exchange/connection agreements); system design documentation;

system information types

Documentation of the stages through which information passes in the system: data map, data flow diagrams, entity relationship diagrams, database schemas, and data dictionaries

Task P-14

Risk Assessment—System

Conduct a system-level risk assessment and update the risk assessment results on an ongoing basis.

ISBO

ISSO

Chief Privacy

Officer or designate

Assets to be protected; business functions and mission/business processes; business impact analyses;

information about interaction with other systems; provider information; threat information; data map; system design

Security and privacy risk assessment reports

August 24, 2020 22

RMF Task Responsibility Input Outcome documentation; risk management strategy

Task P-15

Requirements Definition

Define the security and privacy requirements for the system and the environment of operation.

ISBO

Information

Owner or

Steward

System design documentation;

known set of stakeholder assets to be protected; business functions and mission/business processes; business impact analyses; data map of the information life cycle for PII; information about interaction with other systems; supply chain information;

threat information;

laws, directives, regulations, or policies that apply to the system; risk management strategy

Documented security and privacy requirements

Task P-16

Enterprise Architecture

Determine the placement of the system within the enterprise architecture.

ISBO

Enterprise

Architect

Security

Architect

Privacy Office

Security and privacy requirements;

organization- and system-level risk assessment results;

enterprise architecture information; security architecture information; privacy architecture information; asset information

Updated enterprise architecture; updated security architecture;

updated privacy architecture; plans to use cloud-based systems and shared systems, services, or applications

Task P-17

Requirements Allocation

Allocate security and privacy requirements to the system and to the environment of operation.

Security

Architect

Privacy Office

ISSO

Organization- and system-level risk assessment results;

documented security and privacy requirements;

organization- and system-level risk assessment results;

ECC Catalog; system description; system element information;

List of security and privacy requirements allocated to the system, system elements, and the environment of operation

August 24, 2020 23

RMF Task Responsibility Input Outcome system component inventory; relevant laws, directives, regulations, and policies

Task P-18

System Registration

Register the system with organizational program or management offices.

ISBO

ISSO

Organizational policy on system registration; system information

Registered system in accordance with organizational policy

3.2 Categorize Information System

The security categorization is prepared by the ISSO, in cooperation with the IO and ISBO. The

ISBO must review and approve the security categorization on an annual basis to ensure that all data types selected are accurate.

The formal LOC FIPS 199 security categorization is contained in the Security Category tab in

Archer. The LOC FIPS 199 security categorization provide the basis for all IT security related activities associated with the system. The ISSOs will work with the ISBO to complete the deliverable and update the required fields in Archer.

The LOC FIPS 199 security categorization must be approved by the ISBO in Archer. If the LOC

FIPS 199 security categorization cannot be approved in Archer, then a signed copy of the LOC

FIPS 199 security categorization must be uploaded in the Security Category tab in Archer.

Failure to complete this step may delay the project.

If deviation from the baseline security categorization is required, ISBOs must obtain approval from the CISO, or designate.

The results of the security categorization process influence the selection of appropriate security controls for the information system and where applicable, the minimum assurance requirements for that system. The tasks listed in Table -1 are required to complete Step 1 of the RMF.

Table 3-2: Categorize Tasks

RMF Task Responsibility Input Outcome

Task C-1

System Description

Describe the information system including mission/purpose, system environment, and system boundary information in the

General and Boundary tab in

ISSO

ISBO

System design and requirements documentation;

system component inventory;

information;

information on system use, users, and

Documented system description in Archer

August 24, 2020 24

RMF Task Responsibility Input Outcome

Archer. roles;

Interconnections, information on system boundary

Task C-2

Security Categorization

Categorize the system and document the security categorization results.

ISBO

Information

Owner or

Steward

Authorization boundary (i.e., system) information;

list of security and privacy requirements allocated to the system, system elements, and environment of operation; business impact analyses;

information about missions, business functions, and mission/business processes supported by the system

Impact levels determined and documented in

Archer for each information type and for each security objective

(confidentiality, integrity, availability)

Security categorization based on high-water mark of information type impact levels

Task C-3

Security Categorization Review and Approval

Review and approve the security categorization results and decision.

Authorizing

Official

Senior Agency

Official for

Privacy

Impact levels determined for each information type and for each security objective

(confidentiality, integrity, availability); security categorization based on high-water mark of information type impact levels; list of high value assets for the organization

ISBO approval in

Archer

3.3 Select Security Controls

Step 3 of the RMF is selecting the security control baseline that applies to the information system. Not all security controls apply to every information system and not every security control should be tested as part of the information system’s security assessment plan. This provides for a cost-effective and risk-based method for designing and implementing security controls within an information system’s boundary. The ISBO should consider appropriately tailoring the baseline security controls to align with the policies of the Library and the environments, both physical and logical, where the information system resides. Tailoring guidance includes:

August 24, 2020 25

Identifying and designating common controls in initial security baselines – Common controls are applied LOC-wide and may be inherited by multiple Information systems.

Common controls have their own resources assigned to implement and monitor to take the onus off the information systems for monitoring these controls as part of their systems boundary. The Library’s approved common controls and common control providers are maintained in the Enterprise Common Controls (ECC) Catalog. The catalog comprises the following:

o NIST SP 800-53 security control baselines o FedRAMP security control baselines o LOC High Value Asset (HVA) baselines o Security Control Responsibility (Fully inheritable by a Common Control, a hybrid, or system-level responsibility) o LOC Enterprise Common Control Providers (e.g., LOC IT Security Program, LOC Hosting Environment, LOC Data Network, etc…) o OCIO Amazon Services Control Responsibility o Continuous Monitoring Categories, Methods, and Default Frequencies

Applying scoping consideration to the remaining baseline security controls – NIST SP

800-53, Rev. 4 defines scoping considerations that can be applied to information system boundary. This further narrows the applicable security controls needed to protect an information system. Examples of scoping considerations include operational/environmental-related considerations, security objective-related considerations, technology-related considerations, and mission-related considerations.

More detail on the scoping considerations can be found in the NIST SP 800-53, Rev. 4.

Selecting compensating security controls, if needed – Compensating controls are alternative security controls to be implemented in lieu of baseline controls that provide equal or comparable protection for the information system. Compensating controls are used when baseline controls are either too demanding on resources to make it cost effective or due to limitations of the technology already employed.

Assigning specific values to organization-defined security control parameters via explicit assignment and selection statements – A selection of the security controls in NIST SP

800-53 Rev. 4 contain parameters to define, which give the ISBOs flexibility to assign security requirements. After the scoping guidance and compensating controls have been applied, the parameter values should be defined per Federal laws, policies, regulations, IT

Security Directive 5-410.1, and any other Service Unit guidance that provide security controls.

Supplementing baselines with additional security controls and control enhancements, if needed – ISBOs may choose to add additional security controls to the information system as certain conditions (e.g., Advanced Persistent Threats) exist. These controls additions are at the discretion of the ISBOs.

Providing additional specification information for control implementation – ISBOs, with the guidance of the ISSO, can employ a requirements definition approach or a gap analysis approach in selecting security controls and control enhancements to supplement initial baseline. This is done by aligning the baseline security controls for the information and tailoring the security controls to a specific risk. In the requirements definition approach, ISBOs obtain specific and credible threat information about the activities of adversaries with certain capabilities or attack potential and define the

Information systems security baseline from that requirements analysis.

August 24, 2020 26

Once the security controls are selected for the information system, the ISSO is responsible for documenting the implementation details for each control in Archer. Implementation details for the security controls should describe the following.

The solution in place

How the solution is implemented

The party responsible for implementing and maintaining the solution

Continuous monitoring frequency

If a hybrid, the implementation details should clearly identify which requirements are addressed at the information system level and which requirements the common control provider (or external hosting partner) addresses.

Ongoing monitoring of information system security controls is a critical aspect of risk management. An information system-specific information security continuous monitoring

(ISCM) plan should be established in the initiation phase of the SDLC and Step 3 of the RMF.

The ISCM plan requires the ISBO, ISSO, and/or Common Control Provider to determine the security controls to be monitored and frequency in which to assess the selected…