Attachment 23(c) - Guide to Implementing the Judiciary Information Security Framework JISF.pdf

US COURTS SENSITIVE INFORMATION // FOR OFFICIAL USE ONLY

Guide to Implementing the Judiciary Information Security Framework (JISF Guide) Version 2.5 Published: August 2011

Last Updated: November 2021

JISF Guide v2.5 Last Updated: November 2021

Page ii

Version History

Version Approver Approved Description of Changes

1.0 DTS-ITSO August 2011 Initial version.

2.0 DTS-ITSO March 2014 • Made significant adjustments to Judiciary

Recommended Security Safeguards (Appendix B) due to NIST SP 800-53, Rev. 4.

• Added references to relevant IT security resource packets, and updated hyperlinks.

2.1 DTS-ITSO June 2014 Revised to identify the Continuous Monitoring Resource Package as the primary source of detailed guidance for Step 6.

2.2 DTS-ITSO September 2016 Identified 13 missing optional safeguards, and 8 withdrawn safeguards.

2.3 DTS-ITSO June 2017 • Initial Version 2.3, adjusted for NIST terminology and processes, especially Step 1.

• Replaced safeguard with control, and Risk Mitigation Plan with POA&M.

• Moved Appendix B content to a separate document but kept the appendix for reference and link.

2.3.2 DTS-ITSO April 2018 Added ITSO recommendation for POA&M remediation, and updated links.

2.3.3 DTS-ITSO May 2018 Added Section 2.1 verbiage supporting added fields to the Security Categorization workbook.

2.3.4 DTS-ITSO July 2018 Added Security Categorization Workbook ELM to Section 2.1 as a footnote.

2.3.5 DTS-ITSO September 2018 Updated Step 1 with clarification items.

2.3.6 DTS-ITSO November 2018 Changed Hybrid example in 2.3.6, inserted Section

2.3.7, and added Appendix D.

2.3.7 Ryan MacDonald June 2020 Removed Security Categorization Workbook ELM.

2.4 Derek Armstrong October 2021 • Adjusted to use CSAM for SP, POA&Ms, etc.

• Added Prepare as Step 1 (bumping Steps 1-6 to 2-7).

• Cleaned up and added links.

• Changed Framework to JISF and JISF Guide.

• Added Self-Assessments (Scorecards) into Step 7.

• Removed Appendix C and D.

• Moved some details to Resource Packets/Best

Practices and referenced them.

2.5 Derek Armstrong November 2021 • Changed to use the JDAO “Data Security

Categorization Workbook.”

• Adjusted Step 2 to use this new Workbook.

Page iii

Table of Contents

1. Introduction

Background

Approach and Implementation

Relationship between the JISF and JISF Guide

Roles and Responsibilities

1.4.1 Judiciary IT Security Program Roles and Responsibilities

1.4.2 System-Specific Roles and Responsibilities

2. How to Implement the JISF

Step 1: How to Prepare the Judiciary and System

2.1.1 Step 1.1: Judiciary-Level Preparation Tasks

2.1.2 Step 1.2: System-Level Preparation Tasks

2.1.3 At the Completion of Step 1:

Step 2: How to Categorize the System and Information

2.2.1 Judiciary Information-Type Categorization

2.2.2 Determine the System Security Category

2.2.3 At the Completion of Step 2:

Step 3: How To Select Controls

2.3.1 Identify Recommended Controls Based on the System Security Category

2.3.2 Tailor the Initial Set of Recommended Controls

2.3.3 Document and Approve Control Tailoring

2.3.4 Develop a Continuous Monitoring Strategy

2.3.5 At the Completion of Step 3:

Step 4: How to Implement Controls

2.4.1 Applicability

2.4.2 Implementation Status

2.4.3 Implementation Statements

2.4.4 Plan of Action and Milestones (POA&M)

2.4.5 At the Completion of Step 4:

Page iv

Step 5: How to Assess Controls

2.5.1 Control Assessment Plan

2.5.2 Responsibilities of the Assessment Team

2.5.3 IT Security Assessment Report (SAR)

2.5.4 Update POA&M and SP/CSAM

2.5.5 At the Completion of Step 5:

Step 6: How to Authorize the System or Common Controls

2.6.1 What is a Judiciary Authorization?

2.6.2 What Information Should be Provided for this Decision?

2.6.3 Authorization Decisions

2.6.4 At the Completion of Step 6:

Step 7: How to Monitor System and Controls

2.7.1 System Monitoring Processes

2.7.2 System/Component Disposal

2.7.3 After the Initiation of Step 7:

INFORMATION

Security Plan (SP) Overview ......................................................................................... A1

Judiciary Recommended Security Controls ................................................................. B1

List of Figures and Tables Figure 1 – Security Risk Management Framework (RMF)

Table 1 – General Excerpts from Workbook

1. Introduction The Guide to Implementing the Judiciary Information Security Framework (JISF Guide) is a companion document to the Judiciary Information Security Framework (JISF). The JISF effectively employs best security practices to create a security controls baseline (controls) and to provide a methodology to manage information security risks for judiciary systems. The JISF Guide provides the detailed guidance necessary to effectively conduct the activities integral to the JISF.

Background Judicial independence is a core value that impacts the way the judiciary operates at multiple levels – from guaranteeing freedom from reprisal for legal decisions to exercising autonomy in governance and management. As a result, court units have historically exercised significant independence, including in the administration and management of information systems (systems). The Judicial Conference recognizes that the connectivity of court-unit systems in trusted relationships across national systems requires a common baseline for securing the judiciary’s systems, whether nationally or locally owned or managed.1 The JISF and its companion document the JISF Guide establish that baseline.

Approach and Implementation The JISF Guide addresses the activities of each of the seven steps of the Security Risk Management Framework described in the JISF. At its core, the JISF Guide provides the risk-based compendium of recommended controls and points to guidance for implementing those controls.

The JISF Guide Appendix B Judiciary Recommended Security Controls are the approved controls for use in the judiciary. The Cyber Security Assessment and Management tool (CSAM) is used by the judiciary to help manage and implement the JISF Guide.

Relationship between the JISF and JISF Guide The JISF effectively leverages best security practices to create a recommended controls baseline and supporting methodology to assist court units, national systems, and others within the judiciary with the management of information security risks to judiciary systems.

Supplementing the information contained in the JISF, the JISF Guide provides IT security practitioners with detailed information to assist in its implementation. This includes guidance for security roles and responsibilities; categorizing system IT security risk; and selecting, implementing, and regularly testing controls. To help establish a common security profile for

1 See Section V, Recommendations 1 and 2 of the Report of the Committee on Information Technology Judiciary

Network Security and Privacy.

https://jnet.ao.dcn/information-technology/security/framework-shp/judiciary-info-sec-framework http://jnet.ao.dcn/information-technology/security/csam https://jnet.ao.dcn/information-technology/judiciary-network-security-and-privacy https://jnet.ao.dcn/information-technology/judiciary-network-security-and-privacy systems in similar risk categories, the JISF Guide references a compendium of controls that have been tailored to the judiciary and are recommended for implementation to effectively manage risk.

Roles and Responsibilities JISF-related responsibilities exist at both the national and local level.

1.4.1 Judiciary IT Security Program Roles and Responsibilities

At the Administrative Office, the IT Security Office within the Department of Technology Services (DTS-ITSO) maintains the JISF and this JISF Guide. ITSO also manages the resources providing guidance on implementation of recommended controls, including the Framework Self-Help Portal, the IT Security page, and the Best Practices, Resource Packets and Guidelines.

1.4.2 System-Specific Roles and Responsibilities

Whether the system is a national system or a local court-unit system, these roles and responsibilities are recommended to manage IT security risk in the context of the JISF.

1.4.2.1 Separation of Duties

To the greatest extent possible, the System Owner (SO), IT Security Officer (ISO), and Authorizing Official should be different people. For national systems, at the discretion of the Associate Director, the individual who serves as the Authorizing Official may also serve as the SO as circumstances dictate.

1.4.2.2 System Owner (SO)

The SO is responsible for the successful operation of a system within their program area and is ultimately accountable for the security of that system. The SO should ensure that the system is deployed and operated according to good security practices. The SO should assess the criticality and sensitivity of information stored, transmitted, or processed on the system.

The SO:

• Is responsible for the successful operation of a system.

• Is accountable for the security of the system.

• Ensures that the system is deployed and operated according to good security practices.

• Validates the final selection of controls that should be applied to the system (Section 2.3.3).

• Develops a security assessment strategy and plan (Section 2.5.1).

• Reviews findings identified in the IT Security Assessment Report (Section 2.5.3).

http://jnet.ao.dcn/information-technology/security/framework-shp http://jnet.ao.dcn/information-technology/security/framework-shp http://jnet.ao.dcn/information-technology/security http://jnet.ao.dcn/information-technology/security/best-practices

• Works with other SOs to address any deficiencies identified in controls inherited by this system (Section 2.5.4).

• Generates the Security Authorization Request Letter and provides it to the Authorizing Official (Section 2.6.2).

• Provides the Authorizing Official information needed to make a risk-based decision (Section 2.6.2).

• Periodically, or when a significant change occurs to the system, obtains system reauthorization (Section 2.7.1.7).

• Ensures a continuous monitoring strategy is developed and implemented (e.g., identifies control subset, identifies continuous monitoring activities, ensures resources are allocated to correct system vulnerabilities) (Sections 2.3.4 and 2.7.1).

1.4.2.3 Information Technology Security Officer (ISO)

The Guide to Judiciary Policy encourages each court unit and national system to assign one individual as its ISO and designate that individual (and any alternates) as such in the judiciary’s InfoWeb. The ISO is responsible for implementing information security policies and procedures within the system.2 Also, the ISO supports the security objectives defined by the SO by overseeing the implementation of security on a system and the generation of security documentation for system authorization and operation.

The ISO:

• Develops and revises the Security Plan (SP) throughout the risk management process.

• Determines the system boundary and documents it in CSAM (Step 1.2).

• Determines the system’s overall Security Category and records it in CSAM (Step 2).

• Validates that the most current version of the Judiciary Recommended Controls compendium is being used (Section 2.3.1).

• Tailors a set of recommended controls to meet the security requirements of the system (Section 2.3.2).

• Documents selected controls (including tailoring) in CSAM (Section 2.3.3).

• Implements selected controls (Step 4).

• Documents control status in the SP/CSAM (Steps 4 and 7).

• Creates and updates Plan of Action and Milestones (POA&Ms), also known as Risk Mitigation Plans3 (Steps 4-7).

• Determines security impact of proposed or actual changes to the system and its operating environment (Section 2.7.1.1).

2 Guide to Judiciary Policy, § Volume 15, 310.20.05 Court Unit, FPDO, and AO IT Security Officer Responsibilities 3 Plan of Action and Milestones (POA&M) Management Resource Packet http://jnet.ao.dcn/policy-guidance/guide-judiciary-policy/volume-15-information-technology/ch-3-security#310_20

• Conducts and documents remediation actions to correct system vulnerabilities (Section 2.7.1.4).

1.4.2.4 Authorizing Official

The Authorizing Official is the senior management official or executive with the authority to approve the operation of the systems at an acceptable level of risk to judiciary operations (including mission, functions, reputation), judiciary assets, or individuals. This decision includes a review of control assessment results and any identified operational risk.4

An operational risk level is determined based on the quantity and severity of known vulnerabilities. Residual risk is that portion of risk that remains after the selected set of controls is implemented as designed, and all known POA&Ms have been remediated. Approving a system for production readiness indicates the Authorizing Official’s acceptance of that operational risk.

For national systems, the Director of the Administrative Office is the Authorizing Official. The AO Director has delegated each program office to identify appropriate judiciary employees to be designated Authorizing Officials for systems within their program office. For court-unit systems, typically a court-unit executive is the Authorizing Official. Any Authorizing Official may delegate this responsibility in writing.

The Authorizing Official:

• Evaluates a system’s security readiness to operate.

• Reviews the system information to determine if the system’s operational risk is acceptable.

• Authorizes or denies authorization for the system to transition to, or remain in, the production mode.

• Identifies the period for the system’s authorization. Court-unit authorizations should not exceed five years. National system authorizations should not exceed three years for high priority systems, five years for moderate priority systems, or seven years for low priority systems5. For more on system authorization, see Step 6.

4 Operational risk is that portion of overall information security risk that remains after the selected controls are successfully implemented. For example, vulnerabilities that are not remediated prior to deployment, contribute to operational risk.

5 National system priority processes can be found in the National System Assessment Prioritization Criteria.

https://jnet.ao.dcn/information-technology/security/framework-shp/nat-sys-assess-pri-criteria

2. How to Implement the JISF This JISF Guide provides information on how to implement the Security Risk Management Framework (RMF, see Figure 1), which provides decision-makers a repeatable process for managing security consistently throughout the entire system life cycle. This process consists of the following seven steps:

Step 1 Prepare to execute the RMF from a judiciary-level (Step 1.1) and a system-level (Step 1.2) perspective by establishing a context and priorities for managing security risk.

Step 2 Categorize the 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 3 Select baseline controls for the system and tailor6 the controls as needed to mitigate risk based on an organizational assessment of risk and local conditions.

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

Step 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 requirements.

Step 6 Authorize the system or common controls based on a determination that the risk to judiciary operations and assets, individuals, other organizations, and the Nation is acceptable.

Step 7 Monitor the system and 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 posture of the system.

6 Tailoring controls is the process by which a control baseline is modified based on: (i) the application of scoping guidance; (ii) the specification of compensating controls, if needed; and (iii) the specification of organization-defined parameters in the controls via explicit assignment and selection statements.

Figure 1 – Security Risk Management Framework (RMF)

Step 1: How to Prepare the Judiciary and System There are essential tasks at the judiciary (organization) level and the system (judiciary-unit) level to help them execute the JISF appropriate risk management processes. Executing these tasks links essential risk management processes at the system level to risk management processes at the judiciary level. In addition, it establishes responsibility and accountability for the controls implemented within the judiciary’s systems and inherited by those systems.

Without adequate risk management preparation at the judiciary level, security activities can become too costly, demand too many skilled security professionals, and produce ineffective solutions. For example, organizations that fail to implement an effective enterprise architecture will have difficulty in consolidating, optimizing, and standardizing their information technology infrastructures. Additionally, the effect of architectural and design decisions can adversely affect the ability of the judiciary to implement effective security solutions. A lack of adequate preparation by the judiciary could result in unnecessary redundancy as well as inefficient, costly and vulnerable systems, services, and applications.

2.1.1 Step 1.1: Judiciary-Level Preparation Tasks

Judiciary-level task are performed and updated as needed to provide ongoing strategy, guidance, and support for judiciary units. These preparation tasks are utilized by the system-oriented tasks and other steps (but not specifically included in Steps 2-7), and updated as needed by the Security Policy and Assessment (SPA) Division of DTS-ITSO.

A. Individuals are identified and assigned key roles for executing the JISF.

B. A risk management strategy that includes a determination and expression of judiciary risk tolerance is established.

C. A judiciary-wide risk assessment is completed, or an existing risk assessment is updated annually.

D. IT Services, enterprise architecture, and security/cybersecurity tools and related services are developed to provide uniform security processes to the judiciary and reduce costs.

E. Judiciary-tailored control baselines are established and made available (see Appendix B).

F. Common controls that are available for inheritance by judiciary systems are identified, documented, and published. Use the Judiciary Common Controls List and the Common Controls in CSAM Resource Packet as guidance. Questions should be referred to CSAM Support.

G. A prioritization of judiciary systems with the same security category is conducted.

H. Processes and forms for IT Security Self-Assessments (Scorecards)7 are reviewed and updated annually with stakeholder input.

I. A judiciary-wide continuous monitoring strategy for monitoring control effectiveness is developed and implemented.8

2.1.2 Step 1.2: System-Level Preparation Tasks

System-level preparation tasks are performed at the judiciary-unit level to address risk from a system perspective and are guided and informed by the risk decisions at the judiciary level (Step 1.1). These risk decisions at the judiciary-level can impact the selection and implementation of controls at the system level. The system uses controls that are designated by the judiciary as system-specific, hybrid, or common (inherited) controls in accordance with the enterprise architecture, security architecture, and tailored control baselines that have been developed by the judiciary-level preparation tasks.

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

B. Identify the stakeholders having an interest in the system.

C. System assets (hardware, software, and information types) for the system are identified.

7 Formalized in the Guide to Judiciary Policy, § Volume 15, 310.20.20 IT Security Self-Assessments (Scorecards).

Also, see Section 2.7.1.3 for details and links on the Scorecards.

8 See the Continuous Monitoring of Control Effectiveness Resource Packet.

https://jnet.ao.dcn/information-technology/it-services-catalog https://jnet.ao.dcn/information-technology/it-planning-development/enterprise-architecture https://jnet.ao.dcn/information-technology/security https://jnet.ao.dcn/information-technology/security http://jnet.ao.dcn/information-technology/security/judiciary-common-controls https://jnet.ao.dcn/information-technology/security/best-practices mailto:CSAM_Support@ao.uscourts.gov?subject=CSAM%20Common%20Controls%20-%20questions https://jnet.ao.dcn/policy-guidance/guide-judiciary-policy/volume-15-information-technology/ch-3-security#310_20_20

D. Plan what IT Services can be leveraged to reduce cost and enhance system security.

E. Identify potential system inheritance from the Judiciary Common Control Lists.

F. Review secure architecture diagrams, IT Services and common controls utilized, and data flow charts with David Smith Chief of ITSO Security Engineering Division (SED) to help determine the placement of the system within the enterprise architecture and ensure all relevant IT Services will be utilized.

G. Security requirements are defined.

H. Determine the IT system boundary, using the Defining the System Boundary Resource Packet. Contact David Smith for technical review and SPA’s Judiciary ISO Support for any process discussions.

I. The SO or ISO should obtain stakeholder approval on the system boundary and information types.

J. A system-level risk assessment9 is completed, or an existing risk assessment report is updated.

K. Plan for and learn how to code securely during development.

L. Enter the results of this system prepare step in the CSAM tool.10

2.1.3 At the Completion of Step 1:

Judiciary-level tasks (Step 1.1) span the entire judiciary, so they continue to be reviewed/updated as needed, are available for utilization in all system-level steps, and are not subject to individual systems or steps.

At the conclusion of the system-level preparation tasks (Step 1.2), the SO/ISO should document the results:

• Obtain stakeholders concurrence (in writing) on the system boundary definition (including information types).

• The system boundary definition with stakeholder concurrence documentation and system-level risk assessment should be entered into CSAM.

Step 2: How to Categorize the System and Information This section introduces the Data Security Categorization Workbook to facilitate judiciary information type (data) categorization which is used to determine the system security category.

System security categorization is based on the potential impact to the judiciary should events occur that jeopardize the data, or the systems needed to accomplish its mission, protect its assets, fulfill its regulatory responsibilities, maintain its day‐to‐day functions, and protect

9 See the RA Procedures Template for Risk Assessment guidance.

10 See the Security Plan Resource Packet for guidance, then if needed contact the CSAM support team for guidance on entering the IT system or judiciary unit system into CSAM, and for other CSAM support activities.

http://jnet.ao.dcn/information-technology/it-services-catalog http://jnet.ao.dcn/information-technology/security/judiciary-common-controls mailto:David_Smith@ao.uscourts.gov https://jnet.ao.dcn/information-technology/security/best-practices https://jnet.ao.dcn/information-technology/security/best-practices mailto:David_Smith@ao.uscourts.gov mailto:Judiciary_ISO@ao.uscourts.gov?subject=JISF%20Guide%20-%20Process%20Support%20Request mailto:Judiciary_ISO@ao.uscourts.gov?subject=JISF%20Guide%20-%20Process%20Support%20Request http://jnet.ao.dcn/information-technology/security/developing-secure-software-and-web-applications https://fedcourts.sharepoint.com/sites/XDPS-JDAO-DataSecurityInfoCenter/SitePages/Data-Security-Categorization-Workbooks.aspx https://jnet.ao.dcn/information-technology/security/framework-shp/proc-templates https://jnet.ao.dcn/information-technology/security/framework-shp/ mailto:CSAM_Support@ao.uscourts.gov individuals. Security controls applied to each system should be commensurate with the potential impact of a loss of confidentiality, integrity, or availability.

2.2.1 Judiciary Information-Type Categorization

The security categorization for a system is determined by the security categorization of every information type stored or processed by the system. Using the Data Security Categorization Workbook (Workbook), each judiciary information type, identified as part of defining the system boundary (Step 1.2), is then individually categorized by confidentiality, integrity, and availability. Use the Workbook and it’s guidance resources to complete the selection and categorization of each judiciary information type.

If, after judiciary stakeholder review, a higher categorization is deemed appropriate, then Exceptions to C-I-A Impact Ratings (High or Moderate) must be selected in the Workbook.

Also, these exceptions (if any) should be used in the final determination of System Security Categorization.

2.2.2 Determine the System Security Category

The next task is to determine the single, system security category based on the information-type categorization conducted in Section 2.2.1.

The system security category is determined by identifying the high-water mark for all of the Categorizations based on the aggregate of all identified data security categorizations for the system, and any Exceptions to C-I-A Impact Ratings.

Based on the data categorization from Section 2.2.1, the system security category would be determined as follows (see Workbook excerpt table below):

Table 1 – General Excerpts from Workbook

CATEGORIZATION Confidentiality Integrity Availability

High High Moderate Moderate

Moderate Moderate Moderate Low

Low Low Low Low

The highest CATEGORIZATION is High and therefore the system security category is High.

The SO/ISO should obtain stakeholder concurrence on this system security category. Then the categorization and concurrence documentation should be entered into CSAM.11

11 See CSAM data entry instructions in the Security Plan Resource Packet.

https://fedcourts.sharepoint.com/sites/XDPS-JDAO-DataSecurityInfoCenter/SitePages/Data-Security-Categorization-Workbooks.aspx https://fedcourts.sharepoint.com/sites/XDPS-JDAO-DataSecurityInfoCenter/SitePages/Data-Security-Categorization-Workbooks.aspx

2.2.3 At the Completion of Step 2:

The following activities should have been completed at the end of Step 2:

• The relevant Data Security Categorization Workbook should have been completed.

• The system should have one single categorization for the highest data categorization (from the Workbook).

• The SO/ISO should have sought and received local stakeholder concurrence on the Data Security Categorization Workbook and the system security category.

• The Data Security Categorization Workbook, system security category, and concurrence documentation should have been added into CSAM.

Step 3: How To Select Controls The next step is to select and tailor the appropriate controls based on the system security category, operating environment, individual circumstances, threat environments, and risk tolerance. There are four tasks involved in arriving at a set of controls and monitoring strategy, which adequately protect a system:

• Identify the recommended controls based on the system security category.

• Tailor the initial set of recommended controls.

• Document and approve control tailoring.

• Develop a continuous monitoring strategy.

2.3.1 Identify Recommended Controls Based on the System Security Category

Select the controls to be implemented to protect the system based on the system security category identified in Step 2. This is automatically done by CSAM when the security categorization is selected in CSAM. Refer to Appendix B for the full compendium of recommended controls for each system security category.

2.3.2 Tailor the Initial Set of Recommended Controls

The compendium of recommended controls has been customized to reflect the needs of the judiciary, however further tailoring (i.e., adding optional controls, upgrading some controls to a higher system security category, or deciding to not implement it at all)12 may be required to more closely align with the operating environment and circumstances of the specific system.

For example, a standalone system would not need to implement control CA-03 System Interconnections, because standalone systems are not connected to other systems. If tailoring a control results in all or part of a control not being selected, adequate justification for non-selection should be documented in the SP/CSAM under that specific control’s implementation

12 Control number, name, and description baselines in Appendix B have been established by the judiciary and are not subject to tailoring by system personnel.

description. Also, control tailoring may occur to ensure specific policies, financial rules, etc.

relevant to the system can be implemented securely.

2.3.3 Document and Approve Control Tailoring

The ISO should create documentation on the tailoring of the initial set of recommended controls. This tailoring documentation should state why each control was tailored with sufficient details to support control implementation and assessment.

The SO and relevant stakeholders should approve the control tailoring (using the tailoring documentation). Then documentation of this approval should be added to the SP/CSAM.

2.3.4 Develop a Continuous Monitoring Strategy

The Continuous Monitoring of Control Effectiveness Resource Packet13 establishes a judiciary-wide continuous monitoring strategy for the SO/ISO to follow. Adjustments are made to this strategy to include the tailored control changes initiated during this Step 3, and minimum frequency with which each tailored control (being implemented) is to be monitored.

This results in a system-specific continuous monitoring strategy which will be approved in Step 6 and followed in Step 7.

Develop a system specific control monitoring strategy:

To ensure that the controls being implemented or inherited provide adequate protection for the system, the continuous monitoring strategy should be developed early in the system’s life cycle process. To be effective, this strategy should include:

• Configuration management processes, including how system hardening standards will be enforced.

• Security impact analyses for any proposed changes to the system.

• Continuous monitoring of selected and tailored controls, which should:

o Reflect the priorities and importance of the system to the judiciary.

o Include some inherited controls.

o Include controls identified as deficient and included in the POA&M.

o Identify the frequency of monitoring.

o Continue throughout the system’s life cycle.

• Consistent security status reporting to the SO or other designated managers.

Monitoring controls on an ongoing basis identifies any changes to the system that may affect controls or control effectiveness. This not only improves the security of the system, but also provides current information on the overall security robustness of the system.

13 Created in Section 2.1.1 Judiciary-Level Preparation Tasks.

In general, the following two monitoring techniques are recommended for the judiciary:

• Automated – using software tools to automatically evaluate the effectiveness of a system’s internal controls (e.g., conducting periodic vulnerability scans or continuously using a host-based intrusion detection system).

• Manual – regularly performing manual processes to validate that the system is continuing to perform as desired (e.g., reviewing the user account provisioning and de-provisioning process and observing that it is being followed).

The Authorizing Official reviews the system specific Continuous Monitoring Strategy, requests adjustments if necessary, and approves it for use in Step 6 (when the system is authorized).

2.3.5 At the Completion of Step 3:

The following activities should have been completed at the end of Step 3:

• The set of controls determined to be appropriate to the system should have been determined.

• Control tailoring details are documented, approved, and added to the SP/CSAM.

• A system-specific continuous monitoring strategy has been established, and then reviewed by the Authorizing Official.

• The set of controls should be documented in the SP/CSAM. Although the judiciary control list is recommended (not mandated), any deviations (especially the decision to tailor or not implement a recommended control) should be documented in the SP/CSAM under those relevant controls for historical purposes, and to expedite periodic control implementation assessments and system reauthorization.

Step 4: How to Implement Controls Once the control selection process has been completed, the controls should be implemented on the system. Resources (e.g., best practices, templates, examples) to assist with implementation are available in the Security Plan Resource Packet. Not all controls will have to be implemented by the ISO. Some controls are inherited from outside the system (see Section 2.4.1.2), which will save time and resources. Details and status of the implementation of selected controls should be documented in the SP/CSAM. Although the implementation details will vary by control, the information should be sufficient to allow all users of the SP/CSAM to understand all pertinent information regarding the control and how the control was implemented on the system. This detail allows thorough control testing (Step 5) and monitoring (Step 7).

Control implementation consists of four tasks: Applicability; Implementation Status;

Implementation Statements; and POA&Ms.

2.4.1 Applicability

First the control applicability will need to be determined. There are five applicability options (described below): Applicable; Inherited; Hybrid; Not Applicable (RTM Logic determined); and Not Applicable (User determined). When part of a control is satisfied through inheritance,14 a control’s status should be documented as a Hybrid (see Section 2.4.1.3).

2.4.1.1 Applicable Control

For the judiciary, the default control applicability for each control within the system security category (High, Moderate, or Low) is Applicable. It is up to the ISO to adjust the Applicability for each control based on the system and provide relevant Implementation Statements.

2.4.1.2 Inherited Control

Some of the controls protecting a system come from outside the system boundary (e.g., a server benefits from the fire suppression system of the data center in which it resides). These controls are referred to as inherited controls (or “common” controls)15 and will vary between systems.

To help you identify inherited controls, below are several popular inheritance sources, which should be reviewed for applicability.

• Local court-unit policy and guidance documents.

• Shared Services - Programs (or other sub-sets of court units/national systems) provide controls (such as secure hard drive disposal) to groups of systems based on program-wide contracts or programs. There might be several different groups of these controls in a court unit/national system (e.g., several contracts in one court unit/national system to provide media protection; each contract providing protection to multiple systems).

• Facilities - Buildings and “secure” sections within them, such as a data center or other non-public area, provide control protection primarily in the Physical and Environmental Protection family (e.g., badge readers, UPS, and fire extinguishers). There are different layers of facility security (e.g., building access, controlled court-unit/national system space, and computer room).

• National Infrastructure - Networks [the wide-area network (e.g., the Data Communications Network (DCN) or PACER-Net)] provide judiciary-wide control protection (e.g., Intrusion Detection and Denial of Service Protection). Descriptive lists of controls which are likely to be inherited in whole or in part from the DCN, the Security Operations Center (SOC), or other judiciary entities are available.

• Servers may provide inherited controls to systems operating on them (e.g., controls provided by the operating system and server configuration).

14 See the Common Controls in CSAM Resource Packet for additional inheritance guidance.

15 JNet has a list of Judiciary Common Controls that may be inherited by the system.

http://jnet.ao.dcn/information-technology/security/judiciary-common-controls

• IT services through joint ventures, business partnerships, outsourcing arrangements such as contracts, inter-agency agreements, and licensing agreement. An IT services contract should contain requirements for IT controls.

When a control is inherited by a system, the SP/CSAM control implementation description should identify where the control is inherited from and if all or only part of the control’s elements still need to be addressed by the system. See the next section for information about partially inherited or hybrid controls.

Inherited controls should be identified in a formal document of responsibilities (e.g., a memorandum of understanding/agreement or a service level agreement) between the SO (or the SO’s organization) and the organization providing the inherited controls.

2.4.1.3 Hybrid Control

The label of Hybrid indicates that the control is partially inherited and should be added to the control status to clarify the actual implementation of the control as described in the SP/CSAM.

Control IR-08 Incident Response Plan is an example of partial inheritance of a control. IR-08 deals with the creation of a system incident response plan covering what actions are necessary to prepare for an incident, and how to detect and analyze possible incidents. Once an incident has been discovered the plan covers how the incident will be contained, eradicated, and in certain situations, system recovered and reconstituted with after-action review of the incident.

Such an array of actions is likely to be conducted by various entities and processes in the judiciary, such as the judiciary’s Security Operations Center (SOC). The Judiciary SOC Incident Response Plan (JSOCIRP) is recommended for courts to use as a foundation for their local incident response plans. If the JSOCIRP is leveraged for the creation of the system-level incident response plan, this control will be a hybrid control.

2.4.1.4 Not Applicable (RTM16 logic determined)

While tailoring controls in Section 2.3.2, all controls outside the system security category (High, Moderate, or Low) were identified as Not Applicable (RTM logic determined). This is handled automatically by CSAM when the system security category is entered into CSAM.

2.4.1.5 Not Applicable (User determined)

The ISO may decide to exclude one or more JISF-recommended controls (Appendix B) from the set of controls selected to be implemented on the system. When this occurs, the ISO selects Not Applicable (User determined) for the Applicability and enters a statement in the Justification Control-Level to explain why it is not applicable. An example would be AC-18 Wireless Access, where the ISO would select Not Applicable (User determined), and for the Justification Control-

16 RTM stands for Requirements Traceability Matrix for SP/CSAM security requirements.

http://jnet.ao.dcn/information-technology/security/judiciary-security-operations-center-incident-response-plan http://jnet.ao.dcn/information-technology/security/judiciary-security-operations-center-incident-response-plan

Level statement enter “System does not contain any wireless access within its system boundary;

therefore, this control is not applicable.”

2.4.2 Implementation Status

There are two types of implementation status: Stated Status and Derived Status. The Stated Status of a control is the expected status entered by the ISO and can be Implemented or Not Implemented. If the control is fully implemented on the system, the ISO entered status should be Implemented. When the status is not implemented, partially in place or planned, then the control implementation status is recorded as Not Implemented.

It is possible that resource constraints or other factors may lead to a selected control not being implemented. If the control implementation has been planned but not yet accomplished, the Stated Status would be Not Implemented and an explanation should be provided in the Implementation Statements with details of the planned implementation (including items such as dependencies, target dates, and points of contact). For example, if a facility’s offsite backups are being consolidated, but the contract award is not expected for several months, the MP-04 Media Storage and MP-05 Media Transport controls should not be identified as being Implemented. To ensure the selected control meets system requirements, any incompletely implemented control should be documented in the SP/CSAM and tracked to completion in the POA&M (see Section 2.4.4).

Until the control is implemented and tested, the operational risk to the system is the same as if the control had not been selected. In other words, the intention to implement it does not reduce risk.

The Derived Status is the actual tested/verified status results from assessments in Steps 5 and 7, and can be Implemented or Not Implemented.

2.4.3 Implementation Statements

The descriptions of control implementation in the SP/CSAM need to answer how the control objective is met and must communicate the following information to properly document the control implementation.

• Who is responsible for implementing the control?

• What is implemented?

• Where is the control implemented?

• When was/will the control be implemented?

• How does the implementation satisfy the control or requirement?

• What artifacts support the control implementation statement?

For details on control implementation statements with examples, see the Security Plan Resource Packet.

Planned actions to fully implement the control should be documented in the control implementation statement and in the CSAM POA&M (see Section 2.4.4). Also, any risk acceptance should be documented in relevant control implementation statements and tracked in a POA&M. Include the POA&M ID number in the control implementation statement, until successful remediation or for tracking risk acceptance (where relevant).

2.4.4 Plan of Action and Milestones (POA&M)

POA&Ms were historically referred to as “Risk Mitigation Plans.” While documenting the implementation of the controls, the ISO will identify Partially in Place and Planned implementations which will not be completed before authorizing the system in Step 6. These incomplete control implementations should be reported by the ISO in the system’s POA&M to ensure that they are properly addressed in a timely manner. Because an incomplete control implementation is a risk, it is also a vulnerability to the system until fully implemented. The POA&M describes the measures that are planned to complete control implementation.

The purpose of the POA&M is to identify, assess, prioritize, and monitor the progress of corrective efforts for security vulnerabilities. The POA&M should identify the information that the ISO will use to track the risk from incomplete control implementations and vulnerabilities (which are identified in Steps 4, 5, and 7), the tasks required to accomplish the plan, any milestones (or subtasks) in meeting the tasks, and target completion dates for the milestones.

On a regular basis, the ISO should update the POA&M identifying progress made on the outstanding items listed in the plan, and adding any new incomplete control implementations and newly identified vulnerabilities.17 All POA&MS are required to be entered and managed in CSAM. Follow the Plan of Action and Milestones (POA&M) Management RP for guidance.

It is recommended that the judiciary organization ensure that POA&Ms are adequately protected because they contain insights into security gap areas as well as incomplete control implementation details.

2.4.5 At the Completion of Step 4:

The following activities should have been completed at the end of Step 4:

• The SP/CSAM should contain the Applicability and Stated status of each of the system’s selected controls with Implementation Statements for each control.

• Artifacts showing evidence of control implementation should be identified in control Implementation Statements and uploaded into CSAM.

• The SO/ISO should have gained assurance that inherited controls are, in fact, implemented outside the system and are providing the expected security to the system.

17 A Vulnerability Management Resource Packet is available on JNet at Best Practices, Resource Packets, and Guidelines.

• The SO/ISO should have POA&Ms in place to track planned or partially implemented controls, other security vulnerabilities, and risk acceptance.

Step 5: How to Assess Controls Most people lock their doors during the day and verify that the doors are locked before going to bed. Believing a door is locked is the expected status of the door; checking the door before going to bed is the assessed status of the door.

Upon completion of the control implementation step, the SP/CSAM will contain the expected implementation of controls. It is necessary to test (or assess) the controls to ensure that they are:

• Implemented correctly

• Operating as intended

• Providing the desired security

Security best practices recommend a security assessment occur:

• Before initial entry into production mode

• When there are significant changes to the system or its operating environment

• For Court units, at least every five years

• For national systems, at least every three years for high priority systems, five years for moderate priority systems, and seven years for low priority systems

In addition to validating that the system is adequately protected by the controls, the results of the security assessment should be used as the basis of the authorization decision (Step 6).

Controls that are not implemented or not operating as intended are a potential risk to the system and should be evaluated to determine whether this risk should be addressed or accepted.

2.5.1 Control Assessment Plan

The SO/ISO should develop a security assessment plan (SAP) to assemble an assessment team, state objectives, and provide a detailed roadmap for an assessment of the controls. If an independent assessment is being conducted (by the Court-Unit IT Security Assessment Service (CUSA) or the National Systems Security Assessment Service (NSSA)), the assessment team creates the SAP. There are a series of distinct actions that the assessment team should follow in developing a plan to assess the controls. These actions include:

• Determine the set of controls to be included in the assessment.

• Determine the assessment methods (e.g., interview, documentation review, direct observation, technical test) to be used for each control.

• Tailor the selected assessment procedures as appropriate to eliminate assessment of inherited controls (if they have been adequately assessed by another process and http://jnet.ao.dcn/information-technology/security/court-unit-it-security-assessment https://aoweb.ao.dcn/technology/technology-management/national-systems-security-assessment-service documented in a memorandum of agreement), incorporate previous assessment results (if sufficiently current and dependable), and obtain assessment evidence from external providers, (e.g., if you are using a third party for credit card processing, obtain verification from them that they are compliant with the Payment Card Industry Data Security Standard).

• Finalize the assessment plan and obtain the necessary approvals to execute the plan.

• Upload the assessment plan to CSAM.

Most systems are comprised of a variety of components (hardware, software, firmware), with each component implementing some of the controls in the system. The assessment team develops a strategy to evaluate the components and their related controls, ensuring that all controls are thoroughly assessed in the existing operating environment.18

If there are multiples of the same component (e.g., desktop or laptop computers, firewalls, mail servers) with similar configurations, the assessment team coordinates with the SO to determine whether sampling can be effectively used to assess the controls. Sampling decisions and strategy should be documented in the SAP.

2.5.2 Responsibilities of the Assessment Team

The Assessment Team has the following responsibilities:

• Document the applicable controls of the system from the SP/CSAM. If there is no SP or CSAM entry for the system, determine the applicable controls with the ISO.

• Develop a strategy to evaluate all applicable components and their related controls (i.e., identify each component and the controls assigned to the component).

• Tailor the security assessment procedures to address the environment.

• If possible, optimize assessment procedures.

• If there are multiples of the same component, coordinate with the SO to determine whether sampling can be effectively used to assess the controls.

• Coordinate plan with SO and stakeholders prior to assessment.

• Obtain necessary approvals.

• Conduct the assessment.

• Generate the IT Security Assessment Report (SAR) documenting assessment results.

• If an independent assessment is being conducted on a national system, the NSSA Team inputs (in CSAM) the Derived Status and Implementation Statements based on their assessment results.

• Assist the ISO in the generation of the system’s POA&M identifying any vulnerabilities.

18 The assessment strategy should realistically consider available resources and timelines.

2.5.3 IT Security Assessment Report (SAR)

A risk analysis is conducted, and security assessment results are documented in a SAR. This report is used to determine the effectiveness of the implemented controls, identify any areas that need to be strengthened prior to deployment, and articulate…