Attachment_1_-_PPS_Security_and_Privacy.pdf

Security and Privacy The PPS-CCM Solution shall be compliant with all relevant security controls outlined in the Federal Information Processing Standard (FIPS), the Federal Information Security Management Act (FISMA) and Federal Risk and Authorization Management Program (FedRAMP) to include, but not limited to, the ability of the federal government to perform a security certification and accreditation process to obtain an authorization to operate that will be signed by the federal principal without delay to system deployment. The system shall be FedRAMP High compliant (i.e., High Confidentiality, Moderate Integrity, and Moderate Availability), Judiciary Information Security Framework (JISF) High compliant, and Criminal Justice Information Services (CJIS) Security Policy compliant.

Specific JISF security and privacy requirements for the PPS-CCM Solution are specified in Exhibit A: PPS- CCM JISF Safeguard Risk Categories and Impacts to the RFP.

The Judiciary Information Security Framework (JISF) addresses the activities of each of the six steps of the Judiciary’s Security Risk Management Framework, see below in Figure 1.

Figure 1: Judiciary Security Risk Management Framework (SRMF)

The six steps of the Security Risk Management Framework are:

Step 1

CATEGORIES

Information System

Step 2

SELECT

Security Controls

Step 6

MONITOR

Security Controls

Step 5

AUTHORIZE

Information System

Step 3

IMPLEMENT

Security Controls

Step 4

ASSESS

Security Controls

Security Risk

Management Framework

Step 1: Categorize the information system and the information processed, stored, and transmitted by that system based on the potential impact to the Judiciary should the system suffer an incident. The greater the negative impact, the higher the system impact rating.

Step 2: Select baseline security controls for the system and tailor3 controls as needed based on impact levels, and the operating environment determined in Step 1.

Step 3: Implement security controls using sound information system and security engineering methodologies.

Step 4: Assess security controls to determine the extent to which they are implemented correctly and operating as intended to meet the security requirements for the system.

Step 5: Authorize operation of the information system if operational risks are acceptable.

Step 6: Monitor security controls on an ongoing basis to identify any changes to the information system or its operating environment that may affect control effectiveness.

The Framework Guide covers these six steps in detail, including what should be accomplished by the end of each step before continuing. It is recommended that you follow along in the Framework Guide as you review this document.

The results of each step are recorded in the SSP, thus completing the SSP and periodically updating it.

JISF Security controls have a well-defined organization and structure. Modeled on the controls identified in NIST SP 800-53 Rev. 4, April 2013 (updated January 22, 2015), Security and Privacy Controls for Federal Information Systems and Organizations. The security controls are organized into eighteen families distributed among the following three classes:

Management safeguards focus on the management of risk and the management of information system security.

Operational safeguards are primarily implemented and executed by people (as opposed to systems).

Technical safeguards are primarily implemented and executed by the information system through mechanisms contained in the hardware, software, or firmware components of the system.

Table 1: Security Safeguard Identifiers, Families, and Classes

Identifier Family Class AC Access Control Technical AT Awareness and Training Operational AU Audit and Accountability Technical CA Security Assessment and Authorization Management CM Configuration Management Operational CP Contingency Planning Operational IA Identification and Authentication Technical IR Incident Response Operational

MA Maintenance Operational

MP Media Protection Operational PE Physical and Environmental Protection Operational PL Planning Management PM Program Management Management PS Personnel Security Operational RA Risk Assessment Management SA System and Services Acquisition Management SC System and Communications

Protection Technical

SI System and Information Integrity Operational

Figure 2: FedRAM and JISF Security Control Alignment

Information system risk categorization is based on the potential risk-impact to the Judiciary should events occur that jeopardize the information, or the information systems needed to accomplish its mission, protect its assets, fulfill its regulatory responsibilities, maintain its day-to-day functions, and protect individuals. Security safeguards applied to each system should be commensurate with the potential impact of a loss of confidentiality, integrity, or availability. Consider the following:

Confidentiality – How important is it to ensure that information is accessible only to those authorized to have access?

Integrity –What would be the impact to the Judiciary’s mission if the information was improperly modified or destroyed?

AC: Access Control AU: Audit and Accountability

IA: Identification and Authentication

SC: System and Communications Protection

AT: Awareness and Training

CA

Security Assessment and Authorization

CM: Configuration Management

CP: Contingency Planning

IR: Incident Response MA: Maintenance

PL: PlanningPE: Physical and Environmental Protection

MP: Media Protection

PM: Program Management

PS: Personnel Security RA: Risk Assessment

SA: System and Services Acquisition

SI: System and Information Integrity

JISFFedRAMP Technical Operational Management

Security Control Identifiers, Families, and Classes

Security Classes

Availability – How much performance degradation or system downtime can be tolerated?

There are three levels of risk impact (High, Moderate, and Low) based on a system’s confidentiality, integrity, and availability categorization. For the Judiciary, confidentiality and integrity should be categorized together because of the similarities in the safeguards necessary to protect them.

Availability should be categorized separately, based on the Availability requirements of the specific system. Therefore, there are two Judiciary categories that are separately assessed: Confidentiality and Integrity (C-I), and Availability (Av).

For information to help you categorize your system’s C-I and Av risk impact, refer to Exhibit G.

Each type of information on the system is assessed to determine the C-I risk impact that applies to that information type. In Table 2 below, the types of information being handled by the system are identified.

Using Table 3, “Risk-Based Confidentiality-Integrity (C-I) Categorization,” of the Guide to Implementing the Judiciary Information Security Framework, the C-I risk impact category for each type of information is determined.

Table 2: Information Type Processed by PPS-CCM

Information Type Confidentiality-Integrity Risk Impact Level PII High

Financial Low

Table 3: PPS-CCM platform solution Risk Categorization

System Risk Categorization Impact Level Confidentiality High

Integrity Moderate Availability Moderate

Exhibit A: PPS-CCM JISF Safeguard Risk Categories and Impacts and FBI CJIS Security Policy

A B C D E F

H M L

PM‐1

Information

Security

Program Plan

Judicial organizations should:

a. Develop and disseminate an information security program plan that:

Provides a list of recommended security safeguards based on system categories and risk;

• Provides sufficient information about the framework methodology and recommended safeguards to enable a determination of the residual risk if the framework is implemented as intended and an implementation that is unambiguously compliant with the intent of the framework;

• Includes roles, responsibilities, management commitment, and coordination among

Judiciary entities; and

• Is approved by a senior official with responsibility for the risk being incurred to Judiciary operations (including mission, functions, image, and reputation), Judiciary assets, individuals, other organizations;

b. Review the information security framework periodically (at least annually); and

c. Revise the framework to address Judiciary changes and problems identified during framework implementation or security control assessments.

C‐I Yes Yes Yes

PM‐2

Information

Security Officer

Judicial organizations appointed an information security officer with the mission and resources to coordinate, develop, implement, and maintain the information security program. C‐I Yes Yes Yes

PM‐3

Information

Security

The information security officer should:

a. Ensure that all budget requests include the resources needed to implement the information security program and document all exceptions to this requirement;

b. Employ a business case to record the resources required; and

c. Ensure that information security resources are available for expenditure as planned.

C‐I Yes Yes Yes

PM‐4

Risk Mitigation

Plan Process

The information security officer should implement a process for ensuring that risk mitigation plans for the security program and the associated information systems are maintained and document the remedial information security actions to mitigate risk to

Judiciary operations and assets, individuals, and other organizations.

C‐I Yes Yes Yes

PM‐5

Information

System

Inventory

Each Judicial organization should develop and maintain an inventory of its information systems.

C‐I Yes Yes Yes

Risk ImpactSafeguard

Name &

Safeguard Description Risk

Category

Probation and Pretrial Services Case Management

System Safeguards (Risk Category and Impacts)

A B C D E F

H M L

Risk ImpactSafeguard

Name &

Safeguard Description Risk

Category

PM‐6

Information

Security

Measures of

Performance

Each Judicial organization should develop, monitor, and report on the results of information security measures of performance. Measures of performance are outcome‐based metrics used by an organization to measure the effectiveness or efficiency of the information security program and the security safeguards employed in support of the program.

Examples include number of unpatched systems and resultant risk level, number of systems with confirmed vulnerabilities and resultant risk level, number and severity of malware/virus incidents, percentage of users/employees that have acknowledged (online or through signature) system Rules of Behavior agreements, and percentage of employees that have attended security awareness training.

C‐I Yes Yes Yes

PM‐9

Risk

Management

Strategy

Judicial organizations should:

a. Develop a comprehensive strategy to manage risk to operations and assets, individuals, and other organizations associated with the operation and use of information systems; and

b. Implement that strategy consistently across the organization.

C‐I Yes Yes Yes

PM‐10

Security

Authorization

Process

Judicial organizations should:

a. Manage (i.e., document, track, and report) the security state of information systems through security authorization processes;

b. Designate individuals to fulfill specific roles and responsibilities within the risk management process; and

c. Fully integrate the security authorization processes into an enterprise‐wide risk management program.

C‐I Yes Yes Yes

PM‐11

Mission /

Business

Process

Definition

Judicial organizations should:

a. Define mission/business processes with consideration for information security and the resulting risk to Judiciary operations, Judiciary assets, individuals, and other organizations;

and

b. Determine information protection needs arising from the defined mission/business processes and revise the processes as necessary, until an achievable set of protection needs is obtained.

C‐I Yes Yes Yes

CA‐1

Security

Assessment and

Authorization

Policies and

Procedures

Judicial organizations should develop, disseminate, and review/update periodically (not to exceed annually):

a. Formal, documented security assessment and authorization policies that address purpose, scope, roles, responsibilities, management commitment, coordination among

Judiciary entities, and (where applicable) compliance for security assessments, information system connections, risk mitigation plan, system security authorization, continuous monitoring; and

b. Formal, documented procedures to facilitate the implementation of the security assessment and (where applicable) authorization policies and associated security assessment and authorization safeguards.

C‐I Yes Yes Yes

A B C D E F

H M L

Risk ImpactSafeguard

Name &

Safeguard Description Risk

Category

CA‐2

Security

Assessments

The SO should:

a. Develop a security assessment plan that describes the scope of the assessment including:

• Security safeguards under assessment;

• Assessment procedures to be used to determine security safeguard effectiveness; and

• Assessment environment, assessment team, and assessment roles and responsibilities;

b. Assess the security safeguards in the information system periodically (at least annually) to determine the extent to which the safeguards are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security guidance for the system;

c. Produce a security assessment report that documents the results of the assessment; and

d. Provide the results of the security safeguard assessment, in writing, to an appropriate official or designated representative.

C‐I Yes Yes Yes

CA‐3

Information

System

Connections

The SO should:

a. Authorize connections from the information system to other information systems outside of the authorization boundary through the use of Interconnection Security Agreements and

Memorandum of Understanding (MOU);

b. Document, for each connection, the interface characteristics, security guidance, and the nature of the information communicated; and

c. Monitor connections on an ongoing basis to verify enforcement of security guidance.

C‐I Yes Yes Yes

CA‐5

Risk Mitigation

Plan

The SO should:

a. Develop a risk mitigation plan for the information system to document the Judiciary’s planned remedial actions to correct weaknesses or deficiencies noted during the assessment of the security safeguards and to reduce or eliminate known vulnerabilities in the system; and

b. Update existing risk mitigation plan monthly based on the findings from security safeguards assessments, security impact analyses, and continuous monitoring activities.

C‐I Yes Yes Yes

CA‐6

System Security

Authorization

Judiciary organizations should:

a. Assign a senior‐level executive or manager to the role of authorizing official for the information system;

b. Ensure that the authorizing official authorizes the information system for processing before commencing operations; and

c. Update the security authorization periodically (at least every 3 years)

A B C D E F

H M L

Risk ImpactSafeguard

Name &

Safeguard Description Risk

Category

CA‐7

Continuous

Monitoring

The SO should establish a continuous monitoring strategy and implement a continuous monitoring program that includes:

a. A configuration management process for the information system and its constituent components;

b. A determination of the security impact of changes to the information system and environment of operation;

c. Ongoing security safeguard assessments in accordance with the Judiciary continuous monitoring strategy; and

d. Reporting the security state of the information system to appropriate Judiciary officials periodically (at least annually).

C‐I Yes Yes Yes

PL‐1

Security

Planning Policy and Procedures

Judicial organizations should develop, disseminate, and review/update periodically (not to exceed annually):

a. A formal, documented security planning policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among Judiciary entities, and

(where applicable) compliance for system security plan, system security plan update, security related activity planning; and

b. Formal, documented procedures to facilitate the implementation of the security planning policy and associated security planning safeguards.

C‐I Yes Yes Yes

PL‐2

System Security

Plan

The SO should:

a. Develop a security plan for the information system that:

• Is consistent with the Judiciary’s enterprise architecture;

• Explicitly defines the authorization boundary for the system;

• Describes the operational context of the information system in terms of mission and business processes;

• Provides the security category and impact level of the information system including supporting rationale;

• Describes the operational environment for the information system;

• Describes relationships with or connections to other information systems;

• Provides an overview of the security for the system;

• Describes the security safeguards in place, inherited, or planned for meeting the system’s security requirements including a rationale for the tailoring and supplementation decisions;

and

• Is reviewed and approved by the authorizing official or designated representative prior to plan implementation;

b. Review the security plan for the information system periodically (i.e., at least annually or when significant changes to the system or operating environment occur); and

c. Update the plan to address changes to the information system/environment of operation or problems identified during plan implementation or security safeguard assessments.

A B C D E F

H M L

Risk ImpactSafeguard

Name &

Safeguard Description Risk

Category

PL‐4

Rules of

Behavior

The SO should:

a. Establish and make readily available to all information system users, the rules that describe their responsibilities and expected behavior with regard to information and information system usage; and

b. Receive acknowledgment (signed or documented online) from users indicating that they have read, understand, and agree to abide by the rules of behavior, before authorizing access to information and the information system.

C‐I Yes Yes Yes

PL‐6

Security‐

Related Activity

Planning

The SO should plan and coordinate security‐related activities affecting the information system before conducting such activities in order to reduce the impact on Judiciary operations (i.e., mission, functions, image, and reputation), Judiciary assets, and individuals C‐I Yes Yes Yes

RA‐1

Risk

Assessment

Policy and

Procedures

Judicial organizations should develop, disseminate, and review/update periodically (not to exceed annually):

a. A formal, documented risk assessment policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among Judiciary entities, and

(where applicable) compliance for risk categorization, risk assessments and updates, vulnerability scanning,; and

b. Formal, documented procedures to facilitate the implementation of the risk assessment policy and associated risk assessment safeguards

C‐I Yes Yes Yes

RA‐2

Risk

Categorization

The SO should:

a. Determine the Risk Categorization of the information and the information system in accordance with applicable laws, directives, policies, regulations, standards, and guidance;

b. Document the Risk Categorization results (including supporting rationale) in the security plan for the information system; and

c. Ensure the Risk Categorization decision is reviewed and approved by the authorizing official or authorizing official designated representative.

C‐I Yes Yes Yes

RA‐3

Risk

Assessment

The SO should:

a. Conduct an assessment of risk, including the likelihood and magnitude of harm, from the unauthorized access, use, disclosure, disruption, modification, or destruction of the information system and the information it processes, stores, or transmits;

b. Document risk assessment results in the system security plan;

c. Review risk assessment results at least annually; and

d. Update the risk assessment at least every three (3) years or whenever there are significant changes to the information system or environment of operation (including the identification of new threats and vulnerabilities), or other conditions that may impact the security state of the system.

A B C D E F

H M L

Risk ImpactSafeguard

Name &

Safeguard Description Risk

Category

RA‐5

Vulnerability

Scanning

The SO should:

a. Scan for vulnerabilities in the information system and hosted applications:

• For Low/Moderate C‐I Risk systems: quarterly,

• For High C‐I Risk systems: monthly, and when new vulnerabilities potentially affecting the system/applications are identified and reported;

b. Employ vulnerability scanning tools and techniques that promote interoperability among tools and automate parts of the vulnerability management process by using standards for:

• Enumerating platforms, software flaws, and improper configurations;

• Formatting and making transparent, checklists and test procedures; and

• Measuring vulnerability impact;

c. Analyze vulnerability scan reports and results from security safeguard assessments; and

d. Remediate legitimate vulnerabilities within the SO‐defined response times in accordance with a Judiciary assessment of risk.

C‐I Yes Yes Yes

RA‐5 (1) The SO should employ vulnerability scanning tools that include the capability to readily update the list of information system vulnerabilities scanned.

C‐I Yes Yes Yes

RA‐5 (2) The SO should update the list of information system vulnerabilities scanned periodically (at least quarterly) or when new vulnerabilities are identified and reported. C‐I Yes Yes Yes

RA‐5 (3) The SO should employ vulnerability scanning procedures that can demonstrate the breadth and depth of coverage (i.e., information system components scanned and vulnerabilities checked).

C‐I Yes Yes Yes

RA‐5 (4) The SO should attempt to discern what information about the information system is discoverable by adversaries.

C‐I Yes Yes Yes

RA‐5 (7) he SO should employ automated mechanisms periodically (at least quarterly) to detect the presence of unauthorized software on Judiciary information systems and notify designated

Judiciary officials.

C‐I Yes Opt. Opt.

SA‐1

System and

Services

Acquisition

Policy and

Procedures

Judicial organizations should develop, disseminate, and review/update periodically (not to exceed annually):

a. A formal, documented system and services acquisition policy that includes information security configurations and that addresses purpose, scope, roles, responsibilities, management commitment, coordination among Judiciary entities, and (where applicable) compliance for allocation of resources, life cycle support, acquisitions, information system documentation, software usage restrictions, user installed software, security engineering principles, external information system services, developer security testing, supply chain protection; and

b. Formal, documented procedures to facilitate the implementation of the system and services acquisition policy and associated system and services acquisition safeguards.

A B C D E F

H M L

Risk ImpactSafeguard

Name &

Safeguard Description Risk

Category

SA‐2

Allocation of

Resources

The SO should:

a. Include a determination of information security requirements for the information system in mission/business process planning;

b. Determine, document, and allocate the resources required to protect the information system as part of its budget control process; and

c. Establish a discrete line item for information security in budget documentation.

C‐I Yes Yes Yes

SA‐3

Life Cycle

Support

The SO should:

a. Manage the information system using a system development life cycle methodology that includes information security configurations;

b. Define and document information system security roles and responsibilities throughout the system development life cycle; and

c. Identify individuals having information system security roles and responsibilities.

C‐I Yes Yes Yes

SA‐4

Acquisitions

The SO should include the following requirements and/or specifications, explicitly or by reference, in information system acquisition contracts based on an assessment of risk and in accordance with applicable laws, directives, policies, regulations, and standards:

a. Security functional requirements/specifications;

b. Security‐related documentation requirements; and

c. Developmental and evaluation‐related assurance requirements.

C‐I Yes Yes Yes

SA‐4 (1) The SO should require in acquisition documents that vendors/contractors provide information describing the functional properties of the security safeguards to be employed within the information system, information system components, or information system services in sufficient detail to permit analysis and testing of the safeguards.

C‐I Yes Yes Yes

SA‐4 (2) The SO should require in acquisition documents that vendors/contractors provide information describing the design and implementation details of the security safeguards to be employed within the information system, information system components, or information system services (including functional interfaces among control components) in sufficient detail to permit analysis and testing of the safeguards.

C‐I Yes Yes Opt.

SA‐4 (4) The SO should ensure that each information system component acquired is explicitly assigned to an information system, and that the person responsible for the system acknowledges this assignment.

C‐I Yes Opt. Opt.

A B C D E F

H M L

Risk ImpactSafeguard

Name &

Safeguard Description Risk

Category

SA‐5

Information

System

Documentation

The SO should:

a. Obtain, protect as recommended, and make available to authorized personnel, administrator documentation for the information system that describes:

• Secure configuration, installation, and operation of the information system;

• Effective use and maintenance of security features/functions; and

• Known vulnerabilities regarding configuration and use of administrative (i.e., privileged) functions; and

b. Obtain, protect as recommended, and make available to authorized personnel, user documentation for the information system that describes:

• User‐accessible security features/functions and how to effectively use those security features/functions;

• Methods for user interaction with the information system, which enables individuals to use the system in a more secure manner; and

• User responsibilities in maintaining the security of the information and information system; and

c. Document attempts to obtain information system documentation when such documentation is either unavailable or nonexistent.

C‐I Yes Yes Yes

SA‐5 (1) The SO should obtain, protect as recommended, and make available to authorized personnel, vendor/manufacturer documentation that describes the functional properties of the security safeguards employed within the information system with sufficient detail to permit analysis and testing.

C‐I Yes Yes Opt.

SA‐5 (2) The SO should obtain, protect as recommended, and make available to authorized personnel, vendor/manufacturer documentation that describes the security‐relevant external interfaces to the information system with sufficient detail to permit analysis and testing

C‐I Yes Opt. Opt.

SA‐5 (3) The SO should obtain, protect as recommended, and make available to authorized personnel, vendor/manufacturer documentation that describes the high‐level design of the information system in terms of subsystems and implementation details of the security safeguards employed within the system with sufficient detail to permit analysis and testing

C‐I Yes Yes Opt.

SA‐6

Software Usage

Restrictions

The SO should:

a. Use software and associated documentation in accordance with contract agreements and copyright laws;

b. Employ tracking systems for software and associated documentation protected by quantity licenses to control copying and distribution; and

c. Ensure that the use of peer‐to‐peer file sharing technology conforms to organizational policy.

C‐I Yes Yes Yes

SA‐6 (1) The SO should:

a. Prohibit the use of binary or machine executable code from sources with limited or no warranty without accompanying source code; and

b. Provide exceptions to the source code requirement only for compelling mission/operational requirements when no alternative solutions are available and with the express written consent of the authorizing official.

C‐I Yes Yes Opt.

A B C D E F

H M L

Risk ImpactSafeguard

Name &

Safeguard Description Risk

Category

SA‐7

User Installed

Software

The SO should enforce explicit rules governing the installation of software by users.

C‐I Yes Yes Yes

SA‐8

Security

Engineering

Principles

The SO should apply information system security engineering principles in the specification, design, development, implementation, and modification of the information system.

C‐I Yes Yes Opt.

SA‐9

External

Information

System Services

The SO should:

a. Require that providers of external information system services comply with Judiciary information security guidance and employ appropriate security safeguards in accordance with applicable laws, directives, policies, regulations, standards, and guidance;

b. Define and document user roles and responsibilities with regard to external information system services; and

c. Monitor security safeguard compliance by external service providers.

C‐I Yes Yes Yes

SA‐9 (1) The SO should:

a. Conduct an assessment of risk prior to the acquisition or outsourcing of dedicated information security services; and

b. Ensure that the acquisition or outsourcing of dedicated information security services is approved by the designated senior Judiciary official

C‐I Yes Yes Opt.

SA‐10

Developer

Configuration

Management

The SO should require that information system developers/integrators:

a. Perform configuration management during information system design, development, implementation, and operation;

b. Manage and control changes to the information system;

c. Implement only Judiciary‐approved changes;

d. Document approved changes to the information system; and

e. Track security flaws and flaw resolution.

C‐I Yes Yes Yes

SA‐11

Developer

Security Testing

The SO should require that information system developers/integrators, in consultation with associated security personnel (including security engineers):

a. Create and implement a security test and evaluation plan;

b. Implement a verifiable flaw remediation process to correct weaknesses and deficiencies identified during the security testing and evaluation process; and

c. Document the results of the security testing/evaluation and flaw remediation processes.

C‐I Yes Yes Opt.

SA‐12

Supply Chain

Protection

The SO should protect against supply chain threats as part of a comprehensive information security strategy. C‐I Yes Opt. Opt.

A B C D E F

H M L

Risk ImpactSafeguard

Name &

Safeguard Description Risk

Category

AT‐1

Security

Awareness and

Training Policy and Procedures

Judicial organizations should develop, disseminate, and review/update periodically (not to exceed annually):

a. A formal, documented security awareness and training policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among Judiciary entities, and (where applicable) compliance for security awareness, security training, security training records; and

b. Formal, documented procedures to facilitate the implementation of the security awareness and training policy and associated security awareness and training safeguards.

C‐I Yes Yes Yes

AT‐2

Security

Awareness

The SO should provide basic security awareness training to all information system users

(including managers, senior executives, and contractors) as part of initial training for new users, when recommended by system changes, and periodically (at least annually) thereafter

C‐I Yes Yes Yes

AT‐3

Security

Training

The SO should provide role‐based security‐related training:

• Before authorizing access to the system or performing assigned duties;

• When recommended by system changes; and

• Periodically (at least annually) thereafter.

C‐I Yes Yes Opt.

AT‐4

Security

Training

Records

The SO should:

a. Document and monitor individual information system security training activities including basic security awareness training and specific information system security training; and

b. Retain individual training records for at least 5 years.

C‐I Yes Yes Opt.

CM‐1

Configuration

Management

Policy and

Procedures

Judicial organizations should develop, disseminate, and review/update periodically (not to exceed annually):

a. A formal, documented configuration management policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among Judiciary entities, and (where applicable) compliance for baseline configurations, configuration change control, security impact analysis, access restrictions for change, configuration settings, least functionality information system component inventory, configuration management plan;

and

b. Formal, documented procedures to facilitate the implementation of the configuration management policy and associated configuration management safeguards.

C‐I Yes Yes Yes

CM‐2

Baseline

Configuration

The SO should develop, document, and maintain under configuration control, a current baseline configuration of the information system. C‐I Yes Yes Yes

CM‐2 (1) The SO should review and update the baseline configuration of the information system:

• Monthly;

• When circumstances warrant; and

• As an integral part of information system component installations and upgrades.

C‐I Yes Yes Yes

CM‐2 (2) The SO should employ automated mechanisms to maintain an up‐to‐date, complete, accurate, and readily available baseline configuration of the information system. C‐I Yes Yes Yes

A B C D E F

H M L

Risk ImpactSafeguard

Name &

Safeguard Description Risk

Category

CM‐2 (3) The SO should retain older versions of baseline configurations as deemed necessary to support rollback.

C‐I Yes Yes Opt.

CM‐2 (5) The SO should:

a. Develop and maintain a list of software programs authorized to execute on the information system; and

b. Employ a “deny‐all, permit‐by‐exception” authorization policy to identify software allowed to execute within the information system.

C‐I Yes Yes Opt.

CM‐2 (6) The SO should maintain a baseline configuration for development and test environments that is managed separately from the operational baseline configuration. C‐I Yes Yes Opt.

CM‐3

Configuration

Change Control

The SO should:

a. Determine the types of changes to the information system that are configuration controlled;

b. Approve configuration‐controlled changes to the system with explicit configuration for security impact analyses;

c. Document approved configuration‐controlled changes to the system;

d. Retain and review records of configuration‐controlled changes to the system; and

e. Audit activities associated with configuration‐controlled changes to the system.

C‐I Yes Yes Yes

CM‐3 (2) The SO should test, validate, and document changes to the information system before implementing the changes on the operational system.

C‐I Yes Yes Opt.

CM‐4

Security Impact

Analysis

The SO should analyze changes to the information system to determine potential security impacts prior to change implementation.

C‐I Yes Yes Yes

CM‐4 (1) The SO should analyze new software in a separate test environment before installation in an operational environment, looking for security impacts due to flaws, weaknesses, incompatibility, or intentional malice.

C‐I Yes Yes Opt.

CM‐4 (2) The SO, after the information system is changed, should check the security functions to verify that the functions are implemented correctly, operating as intended, and producing the desired outcome with regard to meeting the security guidance for the system.

C‐I Yes Yes Opt.

CM‐5

Access

Restrictions for

Change

The SO should define, document, approve, and enforce physical and logical access restrictions associated with changes to the information system.

C‐I Yes Yes Yes

CM‐5 (1) The SO should employ automated mechanisms to enforce access restrictions and support auditing of the enforcement actions.

C‐I Yes Yes Opt.

CM‐5 (2) The SO should conduct audits of information system changes periodically (at least annually) or when indications so warrant to determine whether unauthorized changes have occurred. C‐I Yes Opt. Opt.

A B C D E F

H M L

Risk ImpactSafeguard

Name &

Safeguard Description Risk

Category

CM‐5 (5) The SO should:

a. Limit information system developer/integrator privileges to change hardware, software, and firmware components and system information directly within a production environment; and

b. Review and reevaluate information system developer/integrator privileges periodically

(at least semi‐annually).

C‐I Yes Opt. Opt.

CM‐5 (6) The SO should limit privileges to change software resident within software libraries

(including privileged programs).

C‐I Yes Opt. Opt.

CM‐6

Configuration

Settings

The SO should:

a. Establish and document configuration settings for information technology products employed within the information system using security configuration checklists (for items such as registry settings; account, file, and directory settings (i.e., permissions); and settings for services, ports, protocols, and remote connections) that reflect the most restrictive mode consistent with operational guidance;

b. Implement the configuration settings;

c. Identify, document, and approve exceptions from the configuration settings for individual components within the information system based on explicit operational guidance; and

d. Monitor and control changes to the configuration settings in accordance with policies and procedures established in CM‐1.

C‐I Yes Yes Yes

CM‐6 (1) The SO should employ automated mechanisms to centrally manage, apply, and verify configuration settings.

C‐I Yes Opt. Opt.

CM‐6 (2) The SO should employ automated mechanisms to respond to unauthorized changes to the configuration settings.

C‐I Yes Opt. Opt.

CM‐6 (3) The SO should incorporate detection of unauthorized, security‐relevant configuration changes into the Judiciary’s incident response capability to ensure that such detected events are tracked, monitored, corrected, and available for historical purposes.

C‐I Yes Opt. Opt.

CM‐7

Least

Functionality

The SO should configure the information system to provide only essential capabilities.

C‐I Yes Yes Yes

CM‐7 (1) The SO should review the information system periodically (at least quarterly) to identify and eliminate unnecessary functions, ports, protocols, and/or services.

C‐I Yes Yes Yes

CM‐7 (2) The SO should employ automated mechanisms to prevent program execution in accordance with a system‐specific list of authorized and unauthorized programs.

C‐I Yes Yes Opt.

CM‐8

Information

System

Component

Inventory

The SO should develop, document, and maintain an inventory of information system components that:

a. Accurately reflects the current information system;

b. Is consistent with the authorization boundary of the information system;

c. Is at the level of granularity deemed necessary for tracking and reporting; and

d. Is available for review and audit by designated Judiciary officials.

C‐I Yes Yes Yes

CM‐8 (1) The SO should update the inventory of information system components as an integral part of component installations, removals, and information system updates. C‐I Yes Yes Yes

A B C D E F

H M L

Risk ImpactSafeguard

Name &

Safeguard Description Risk

Category

CM‐8 (2) The SO should employ automated mechanisms to help maintain an up‐to‐date, complete, accurate, and readily available inventory of information system components. C‐I Yes Yes Opt.

CM‐8 (3) The SO should:

a. Employ automated mechanisms at least annually to detect the addition of unauthorized components or devices into the information system; and

b. Disable network access to such components or devices and notify designated Judiciary officials

C‐I Yes Yes Opt.

CM‐9

Configuration

Management

Plan

The SO should develop, document, and implement a configuration management plan for the information system that:

a. Addresses roles, responsibilities, and configuration management processes and procedures;

b. Defines the configuration items for the information system and when in the system development life cycle the configuration items are placed under configuration management; and

c. Establish the means for identifying configuration items throughout the system development life cycle and a process for managing the configuration of the configuration items.

C‐I Yes Yes Yes

CP‐1

Contingency

Planning Policy and Procedures

Judicial organizations should develop, disseminate, and review/update periodically (not to exceed annually):

a. A formal, documented contingency planning policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among Judiciary entities, and

(where applicable) compliance for contingency plan, contingency training, contingency plan testing and exercises, contingency plan update, alternate storage site, alternate processing site, telecommunications services, information system backup, information system recovery and reconstitution; and

b. Formal, documented procedures to facilitate the implementation of the contingency planning policy and associated contingency planning safeguards

A B C D E F

H M L

Risk ImpactSafeguard

Name &

Safeguard Description Risk

Category

CP‐2

Contingency

Plan

The SO should:

a. Develop a contingency plan for the information system that:

• Identifies essential mission and business functions and associated contingency guidance;

• Provides recovery objectives, restoration priorities, and metrics;

• Addresses contingency roles, responsibilities, assigned individuals with contact information;

• Addresses maintaining essential mission and business functions despite an information system disruption, compromise, or failure;

• Addresses eventual, full information system restoration without deterioration of the security measures originally planned and implemented; and

• Is reviewed and approved by designated officials within the Judiciary;

b. Distribute copies of the contingency plan to the list of key contingency personnel

(identified by name and/or by role) and Judiciary elements;

c. Coordinate contingency planning activities with incident handling activities;

d. Review the contingency plan for the information system at least annually, or when significant changes to the system or operating environment occur;

e. Revise the contingency plan to address changes to the Judiciary, information system, or environment of operation and problems encountered during contingency plan implementation, execution, or testing; and

f. Communicate contingency plan changes to the list of key contingency personnel

(identified by name and/or by role) and Judiciary elements.

Av Yes Yes Yes

CP‐2 (1) The SO should coordinate contingency plan development with Judiciary elements responsible for related plans.

Av Yes Yes Opt.

CP‐2 (2) The SO should conduct capacity planning so that necessary capacity for information processing, telecommunications, and environmental support exists during contingency operations.

Av Yes Yes Opt.

CP‐2 (3) The SO should determine the Recovery Time Objective (RTO) and plan for the resumption of essential mission and business functions based on system categorization. Av Yes Yes Yes

CP‐2 (4) The SO should plan for the full resumption of Judicial mission and business functions:

• For Moderate AV Risk Systems: within 1 week of contingency plan activation.

• For High AV Risk Systems: within 1 day of contingency plan activation.

Av Yes Yes Opt.

CP‐3

Contingency

Training

The SO should train personnel in their contingency roles and responsibilities with respect to the information system and provide refresher training periodically (at least annually). Av Yes Yes Yes

CP-3 (1)

The SO should incorporate simulated events into contingency training to facilitate effective response by personnel in crisis situations.

Av Yes Opt. Opt.

A B C D E F

H M L

Risk ImpactSafeguard

Name &

Safeguard Description Risk

Category

CP‐4

Contingency

Plan Testing and Exercises

The SO should:

a. Test and/or exercise the contingency plan for the information system using a tabletop exercise (covering processes and participant’s roles and responsibilities) or full scale test of the Contingency Plan:

• For Low Availability Risk systems: at least every three years or when there are significant changes to the operating environment

• For High/Moderate Availability Risk systems: at least annually or when there are significant changes to the operating environment to determine the plan’s effectiveness and the Judiciary’s readiness to execute the plan; and

b. Review the test/exercise results and initiate corrective actions.

Av Yes Yes Yes

CP‐4 (1) The SO should coordinate contingency plan testing and/or exercises with Judiciary elements responsible for related plans.

Av Yes Yes Opt.

CP‐4 (2) The SO should test/exercise the contingency plan at the alternate processing site to familiarize contingency personnel with the facility and available resources and to evaluate the site’s capabilities to support contingency operations.

Av Yes Opt. Opt.

CP‐4 (4) The SO should include a full recovery and reconstitution of the information system to a known state as part of contingency plan testing Av Yes Opt. Opt.

CP‐6

Alternate

Storage Site

The SO should establish an alternate storage site including necessary agreements to permit the storage and recovery of information system backup information. Av Yes Yes Opt.

CP‐6 (1) The SO should identify an alternate storage site that is separated from the primary storage site so as not to be susceptible to the same hazards.

Av Yes Yes Opt.

CP‐6 (2) The SO should configure the alternate storage site to facilitate recovery operations in accordance with recovery time and recovery point objectives.

Av Yes Opt. Opt.

CP‐6 (3) The SO should identify potential accessibility problems to the alternate storage site in the event of an area‐wide disruption or disaster and outlines explicit mitigation actions. Av Yes Yes Opt.

CP‐7

Alternate

Processing Site

The SO should:

a. Establish an alternate processing site including necessary agreements to permit the resumption of information system operations for essential mission and business functions;

and

b. Ensure that equipment and supplies required to resume operations are available at the alternate site or contracts are in place to support delivery to the site in time to support the time period for resumption.

Av Yes Yes Opt.

CP‐7 (1) The SO should identify an alternate processing site that is separated from the primary processing site so as not to be susceptible to the same hazards.

Av Yes Yes Opt.

CP‐7 (2) The SO should identify potential accessibility problems to the alternate processing site in the event of an area‐wide disruption or disaster and outlines explicit mitigation actions. Av Yes Yes Opt.

CP‐7 (3) The SO should develop alternate processing site agreements that contain priority‐of‐service provisions in accordance with the Judiciary’s availability guidance.

Av Yes Yes Opt.

CP‐7 (5) The SO should ensure that the alternate processing site provides information security measures equivalent to that of the primary site Av Yes Yes Opt.

A B C D E F

H M L

Risk ImpactSafeguard

Name &

Safeguard Description Risk

Category

CP‐8

Telecommunica tions Services

The SO should establish alternate telecommunications services when the primary telecommunications capabilities are unavailable, including necessary agreements to permit the resumption of information system operations for essential mission and business functions

Av Yes Yes Opt.

CP‐8 (1) The SO should:

a. Develop primary and alternate telecommunications service agreements that contain priority‐of‐service provisions in accordance with the Judiciary’s availability guidance; and

b. Request Telecommunications Service Priority for all telecommunications services used for national security emergency preparedness in the event that the primary and/or alternate telecommunications services are provided by a common carrier.

Av Yes Opt. Opt.

CP‐8 (2) The SO should obtain alternate telecommunications services with configuration for reducing the likelihood of sharing a single point of failure with primary telecommunications services.

Av Yes Opt. Opt.

CP‐8 (3) The SO should obtain alternate telecommunications service providers that are separated from primary service providers so as not to be susceptible to the same hazards. Av Yes Opt. Opt.

CP‐8 (4) The SO should require primary and alternate telecommunications service providers to have contingency plans.

Av Yes Opt. Opt.

CP‐9

Information

System Backup

The SO should:

a. Conduct backups of user‐level information contained in the information system at intervals appropriate to the criticality and volatility of the information or application;

b. Conduct backups of system‐level information contained in the information system at intervals appropriate to the criticality and volatility of the information or application;

c. Conduct backups of information system documentation including security‐related documentation at intervals appropriate to the criticality and volatility of the information or application; and

d. Protect the confidentiality and integrity of backup information at the storage location.

Av Yes Yes Yes

CP‐9 (1) The SO should test backup information periodically (at least annually) to verify media reliability and information integrity.

Av Yes Yes Yes

CP‐9 (3) The SO should store backup copies of the operating system and other critical information system software, as well as copies of the information system inventory (including hardware, software, and firmware components) in a separate facility or in a fire‐rated container that is not collocated with the operational system.

Av Yes Yes Opt.

CP‐9 (5) The SO should transfer information system backup information to the alternate storage site at intervals appropriate to the criticality and volatility of the information or application. Av Yes Yes Opt.

A B C D E F

H M L

Risk ImpactSafeguard

Name &

Safeguard Description Risk

Category

CP‐10

Information

System

Recovery and

Reconstitution

The SO should provide for the recovery and reconstitution of the information system to a known state after a disruption, compromise, or failure.

Av Yes Yes Yes

CP‐10 (2) The information system should implement transaction recovery for systems that are transaction‐based.

Av Yes Opt. Opt.

CP‐10 (4) The SO should provide the capability to reimage information system components within the time restoration time‐period consistent with the system’s criticality from configuration‐ controlled and integrity‐protected disk images representing a secure, operational state for the components.

Av Yes Opt. Opt.

CP‐10 (6) The SO should protect backup and…