Attachment_2__-_Security_Framework_Guide.pdf

Guide to Implementing the Judiciary Information

Security Framework Version 2.3

Updated: June 15, 2017 Published: August 29, 2011

Guide to Implementing the Judiciary Information Security Framework v2.3

Page i

Document Change History

Version Date Author Description

2.3 June 15, 2017 AO-DTS-ITSO • 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.

• Replaced Appendices C, D, and E with links directly to stand-alone documents.

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

• Minor cleanup on safeguard formatting.

2.1.2 April 5, 2015 AO-DTS-ITSO • Updated links to Safeguards Optional for All Risk Impact Levels.

• Minor cleanup on references to Framework Self-Help Portal and supporting documents.

2.1.1 November 6, 2014 AO-DTS-ITSO • Updated cover page, table of contents, format, and column descriptions for the Risk Mitigation Plan Template (Section 2.3.7).

• Cleaned-up Table B-2.

2.1 June 10, 2014 AO-DTS-ITSO • Revised to identify the Continuous Monitoring Resource Package as the primary source of detailed guidance for Step 6 of the Security Risk Management Model.

• Updated hyperlinks to new JNet web pages.

2.0 March 10, 2014 AO-DTS-ITSO • Made significant adjustments to Judiciary Recommended Security Safeguards (Appendix B) due to revision 4 of NIST SP 800-53.

• Added references to relevant IT security resource packets.

• Updated hyperlinks.

• Adjusted formatting and edited for errors.

• Deleted references to SSP templates (replaced by annotated examples).

• Deleted “Recommended Safeguard Listings by

Risk Category Pairs” as not a useful tool.

1.0 August 29, 2011 AO-DTS-ITSO • Final version 1.0

Page ii

Table of Contents

1. Introduction

1.1 Background

1.2 Approach and Implementation

1.3 Relationship between the Framework and Framework Guide

1.4 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 Framework

2.1 How to Categorize Information System (Step 1)

2.1.1 Define the System Boundary – Step 1.1

2.1.2 Categorize Information-Type Security Impact – Step 1.2

2.1.3 Categorize System Security Impact – Step 1.3

2.1.4 At the Completion of Step 1:

2.2 How To Select Security Controls (Step 2)

2.2.1 Identify the Recommended Controls Based on Impact Level – Step 2.1

2.2.2 Tailor the Initial Set of Recommended Controls – Step 2.2

2.2.3 Supplement the Tailored Controls – Step 2.3

2.2.4 At the Completion of Step 2:

2.3 How to Implement Security Controls (Step 3)

2.3.1 In Place Control

2.3.2 Partially In Place Control

2.3.3 Inherited Control

2.3.4 Planned Control

2.3.5 Not Selected Control

2.3.6 Hybrid Control Qualifier

2.3.7 Plan of Action and Milestones (POA&M)

2.3.8 At the Completion of Step 3:

2.4 How to Assess Security Controls (Step 4)

2.4.1 Control Assessment Plan

2.4.2 Responsibilities of the Assessment Team

2.4.3 IT Security Assessment Report

Page iii

2.4.4 Update POA&M

2.4.5 At the Completion of Step 4:

2.5 How to Authorize the Information System (Step 5)

2.5.1 What is a Judiciary Authorization?

2.5.2 What Information Should be Provided for this Decision?

2.5.3 Authorization Decisions

2.5.4 At the Completion of Step 5:

2.6 Monitoring Security Controls (Step 6)

2.6.1 At the Completion of Step 6:

3. Information

System Security Plan (SSP) Overview ........................................................................A-1

Judiciary Recommended Security Controls ............................................................... B-1

List of Figures Figure 1: Security Risk Management Framework

List of Tables Table 1 – Potential Impact Definitions for Security Objectives

Table 2 – General Information Types

Table 3 – Example Descriptions of Specific Information Types

Table 4 – Sample POA&M Template

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

1.1 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. 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 information systems, whether nationally or locally owned or managed.1 The Framework and its companion document the Framework Guide establish that baseline.

1.2 Approach and Implementation

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

1.3 Relationship between the Framework and Framework Guide

The Framework effectively leverages best security practices to create a recommended security 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 Framework, the Framework 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 security controls. To help establish a common security profile for systems in similar risk categories, the Framework Guide references a compendium of controls that have been tailored to the Judiciary and are recommended for implementation to effectively manage risk.

1.4 Roles and Responsibilities

Framework-related responsibilities exist at both the national and local level.

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

Security and Privacy.

http://jnet.ao.dcn/information-technology-judiciary-network-security-and-privacy http://jnet.ao.dcn/information-technology-judiciary-network-security-and-privacy

1.4.1 Judiciary IT Security Program Roles and Responsibilities At the Administrative Office, the IT Security Office within the Department of Technology Services (AO-DTS-ITSO) maintains the Framework and this Framework 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 Framework.

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 System Owner as circumstances dictate.

1.4.2.2 System Owner (SO)

The SO is responsible for the successful operation of an information system within his or her 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 an information system;

• Is accountable for the security of the system;

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

• Tailors a set of recommended controls to meet the security requirements of the system (Step 2.2);

• Supplements the set of recommended controls, if needed (Step 2.3);

• Validates the final selection of controls that should be applied to the system (Step 2.3);

• Implements selected controls (Step 3);

• Develops a security assessment strategy and plan (Step 4);

• Reviews findings identified in the IT Security Assessment Report (Step 4);

• Works with other SOs to address any deficiencies identified in controls inherited by this system (Step 4);

• Generates the Security Authorization Request Letter and provides it to the Authorizing Official (Step 5);

• Provides the Authorizing Official information needed to make a risk-based decision (Step 5);

• Periodically, or when a significant change occurs to the system, obtains system reauthorization (Step 5);

• Determines security impact of proposed or actual changes to the system and its operating environment (Step 6);

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

• 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) (Step 6); and

• Conducts and documents remediation actions to correct system vulnerabilities (Step 6).

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 an information system and the generation of security documentation for system authorization and operation.

The ISO:

• Develops and revises the System Security Plan (SSP) throughout the risk management process;

• Determines the system boundary and documents it in the SSP (Step 1.1);

• Determines the system’s overall Security Category, and records it in the SSP (Steps 1.2 and 1.3);

• Validates that the most current version of the Judiciary Recommended Controls compendium is being used (Step 2.1);

• Documents selected controls in the SSP (Step 2.3);

• Documents control status in the SSP (Steps 3-6); and

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

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 information systems at an acceptable level of risk to judiciary operations (including mission, functions, image or reputation), judiciary assets, or individuals. This decision includes a review of security 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 security 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.

2 Guide to Judiciary Policy, § Volume 15, 310.20.05 Court Unit, FPDO, and AO IT Security Officer Responsibilities 3 Security Risk Management Resource Packet 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.

http://jnet.ao.dcn/policy-guidance/guide-judiciary-policy/volume-15-information-technology/ch-3-security#310_20

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; and

• Identifies the time period for the system’s authorization. Court-unit authorizations should not exceed 5 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 Section 2.5.

2. How to Implement the Framework This Framework Guide provides information on how to implement the Security Risk Management Framework (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 six steps:

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 tailor6 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.

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

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

http://dtsppwa-ftp01.adu.dcn/security/downloads/nat_sys_asses_pri_criteria.pdf

Figure 1: Security Risk Management Framework

2.1 How to Categorize Information System (Step 1)

This section describes the categorization process and introduces the Judiciary IT System Security Categorization Workbook to facilitate both information-type and system categorization.7

Information system security categorization is based on the potential 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 controls applied to each system should be commensurate with the potential impact of a loss of confidentiality, integrity, or availability.

2.1.1 Define the System Boundary – Step 1.1

In order to categorize a system, it is essential to know what is being protected; how information flows into, out of, and through the system; and the components that comprise the system (as well as those that are “out of scope”). Together, this information establishes the system boundary. Accurately

7 This process is based on Federal Information Processing Standards Publication 199, Standards for Security Classification of Federal Information and Information Systems (FIPS PUB 199), and National Institute of Standards and Technology Special Publication 800-60, Vol.2, Rev.1, Appendices to Guide for Mapping Types of Information and Information Systems to Security Categories (NIST SP 880-60, Vol.2, Rev.1).

http://dtsppwa-ftp01.adu.dcn/security/downloads/sys_sec_categ_wbk.xlsx http://dtsppwa-ftp01.adu.dcn/security/downloads/sys_sec_categ_wbk.xlsx http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.199.pdf http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.199.pdf http://dx.doi.org/10.6028/NIST.SP.800-60v2r1 http://dx.doi.org/10.6028/NIST.SP.800-60v2r1 defining the system boundary is necessary for the successful identification of the types of information that are on the system as well as how critical the system’s function is to judiciary business operations.

The system boundary should be determined based on functionality, business-impact area, ownership of assets, physical location, similar system needs (such as similar types of information or similar system availability needs), and other relevant criteria. Information system key stakeholders should be consulted during the determination of the system boundary. The system boundary should take into consideration the organization’s structure and IT architecture. A Defining the System Boundary Resource Packet is available on JNet at Best Practices, Resource Packets, and Guidelines.

Once the system boundary is defined, it should be documented in the SSP. The SSP provides the security requirements for an information system or program and describes the security controls in place (including how they are implemented) or planned to meet those requirements. Appendix A provides an SSP overview and links to SSP examples.

2.1.2 Categorize Information-Type Security Impact – Step 1.2

The security categorization for an information system is determined by the security categorization of each and every information type stored or processed by the system. Each information type is first identified then individually categorized by the impact to its security objectives (confidentiality, integrity and availability) should there be a breach of security (see Table 1).

Table 1 – Potential Impact Definitions for Security Objectives

Security Objective

POTENTIAL IMPACT

LOW MODERATE HIGH

Confidentiality Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information.

The unauthorized disclosure of information could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals.

The unauthorized disclosure of information could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals.

The unauthorized disclosure of information could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals.

Integrity Guarding against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity.

The unauthorized modification or destruction of information could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals.

The unauthorized modification or destruction of information could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals.

The unauthorized modification or destruction of information could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals.

Availability Ensuring timely and reliable access to and use of information.

The disruption of access to or use of information or an information system could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals.

The disruption of access to or use of information or an information system could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals.

The disruption of access to or use of information or an information system could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals.

Establishing the appropriate security category of an information type requires determining the potential impact for all three security objectives. The acceptable values for potential impact are Low, Moderate, High, or (for confidentiality only) Not Applicable.

NIST SP 800-60 Vol.2, Rev.1, Appendices to Guide for Mapping Types of Information and Information Systems to Security Categories, provides a high-level list of information types (see Table 2). For convenience the Security Categorization Workbook focuses on the information types most likely pertinent to judiciary activities (bolded in Table 2).

Table 2 – General Information Types

Services Delivery Support Functions Mission-Based Information Types

C.2.1 Controls and Oversight C.2.2 Regulatory Development C.2.3 Planning & Budgeting C.2.4 Internal Risk Management & Mitigation C.2.5 Revenue Collection C.2.6 Public Affairs C.2.7 Legislative Relations C.2.8 General Government

D.1 Defense & National Security D.2 Homeland Security D.3 Intelligence Operations D.4 Disaster Management D.5 International Affairs & Commerce D.6 Natural Resources D.7 Energy D.8 Environmental Management D.9 Economic Development D.10 Community & Social Services D.11 Transportation D.12 Education D.13 Workforce Management D.14 Health D.15 Income Security D.16 Law Enforcement D.17 Litigation & Judicial Activities D.18 Federal Correctional Activities D.19 General Sciences & Innovation D.20 Knowledge Creation & Management D.21 Regulatory Compliance & Enforcement D.22 Public Goods Creation and Management D.23 Federal Financial Assistance D.24 Credit and Insurance D.25 Transfers to State/ Local Governments D.26 Direct Services for Citizens

Government Resource Management Functions

C.3.1 Administrative Management C.3.2 Financial Management C.3.3 Human Resource Management C.3.4 Supply Chain Management C.3.5 Information & Technology Management

Within each general information type are a number of more specific information types that are fully described and included for selection in the Security Categorization Workbook. For example, general information type D.17, Litigation & Judicial Activities, has five specific information types:

D.17.1 Judicial Hearings Information Type D.17.2 Legal Defense Information Type D.17.3 Legal Investigation Information Type D.17.4 Legal Prosecution and Litigation Information Type D.17.5 Resolution Facilitation Information Type

The detailed description of each information type includes a recommended baseline security impact level and guidance for raising that impact level as conditions warrant. See Table 3 for examples of the detail provided by NIST SP 800-60 Vol.2, Rev.1 for each specific information type.

Table 3 – Example Descriptions of Specific Information Types

Function Confidentiality Description Integrity Description Availability Description

C.2.2.1 Policy and Guidance Development

NIST 800-60:

Special Factors Affecting Confidentiality Impact Determination: The effects of loss of confidentiality of guidelines during the formative stage can result in attempts by affected entities and other interested parties to influence and/or impede the policy and guideline development process. Premature public release of formative policies and guidelines before internal coordination and review can result in unnecessary damage to public confidence in the agency. This is particularly likely where the release includes unedited internal commentary and discussion. Delays can impair an agency’s mission, but loss of public confidence can do serious and persistent harm to an agency’s ability to effectively perform its mission. In such cases, the initial confidentiality impact level recommended for policy and guidance development information is moderate. When the policy and guidance information is in the public domain, the confidentiality impact level becomes Not Applicable (NA).

Recommended Confidentiality Impact Level: Although there are cases in which unauthorized and premature disclosure of policy and guidance information can result in serious consequences for an agency, most of this information is intended to be available to the general public. Consequently, the Initial confidentiality impact level recommended for policy and guidance development information is low.

NIST 800-60:

Special Factors Affecting Integrity Impact Determination:

Some policy and guidance information is time-critical.

Unauthorized modification or destruction of information affecting external communications that contain policy and guidance development information (e.g., web pages, electronic mail) may adversely affect operations or public confidence in the agency, but the damage to the mission would usually be limited. Public confidence consequences can be expected to be much more serious in cases of agencies that have national defense, intelligence, or information security missions. In such cases, the impact may be at least moderate.

Recommended Integrity Impact Level: The Initial integrity level recommended for policy and guidance development information is low.

NIST 800-60:

The availability impact level is based on the specific mission and the data supporting that mission, not on the time required to re-establish access to the policy and guidance development information.

Though some policy and guidance information is time-critical, the policy and guidance development process is usually tolerant of delays.

Recommended Availability Impact Level: The Initial availability impact level recommended for policy and guidance development information is low.

D.17.4 Legal Prosecution and Litigation

NIST 800-60:

While most information associated with legal proceedings is public, some information is sealed or is otherwise protected from disclosure. Generally, unauthorized disclosure of legal prosecution/litigation information will have only a limited adverse effect on agency operations, assets, or individuals

Special Factors Affecting Confidentiality Impact Determination: If suspicion is raised concerning government complicity or negligence, serious loss of public confidence in government agencies or the legal process may result. In this case, the confidentiality impact of unauthorized disclosure will be moderate.

Where the life of a complainant, victim, witness, or informant may be endangered by disclosure, the confidentiality impact will be high. Also, where the consequences of a miscarriage of justice are likely to endanger public safety (e.g., release of a terrorist or other murderer), the confidentiality impact will be high.

Given the nature of many of the crimes that are the responsibility of Federal law enforcement agencies, the consequences associated with unauthorized disclosure of legal prosecution information must be assumed to pose a threat to human life or result in a loss of major assets.

Additionally, when a legal proceeding concerns matters of trans-national interest, such as trade enforcement, tariff agreements, etc., or where foreign nationals might be involved, the confidentiality impact will be high.

Information that reveals the identity and/or location of informants may be of particular concern. Information that reveals the identity and/or location of informants may be of particular concern.

Recommended Confidentiality Impact Level: Given the public nature of and disclosure rules associated with most prosecution/litigation information, the initial confidentiality impact level recommended is low.

NIST 800-60:

Where the life of a victim, witness, or informant may be endangered, the integrity impact will be high.

Also, where the consequences of a miscarriage of justice are likely to endanger public safety (e.g., release of a terrorist or other murderer), the integrity impact will be high.

Recommended Integrity Impact Level: Given the legal consequences of the unauthorized modification or destruction of legal prosecution/litigation information, the Initial integrity impact level recommended for legal prosecution/litigation information is moderate.

NIST 800-60:

In exceptional cases (e.g., information affecting a ruling regarding an impending execution), loss of availability of information can have a severe adverse effect. The availability impact level recommended for this legal prosecution/litigation information is high.

Recommended Availability Impact Level: The Initial availability impact level recommended for legal prosecution/litigation information is low.

FIPS PUB 199, Standards for Security Classification of Federal Information and Information Systems, provides a standard format for documenting risk:

Security Category information type = {(confidentiality, impact), (integrity, impact), (availability, impact)}

Example 1 shows how the security categorization for the two information types in Table 3 could be documented using the NIST SP 800-60 Vol.2, Rev.1 format and the baseline impact levels.

Example 1:

Security Category Policy and Guidance Development = {(confidentiality, Low), (integrity, Low), (availability, Low)}

Security Category Legal Prosecution and Litigation = {(confidentiality, Low), (integrity, Moderate), (availability, Low)}

If, after judiciary stakeholder review, a higher security impact level is deemed appropriate for confidentiality, integrity, or availability, then that new impact level should be used in the final information-type security category determination, as shown in Example 2.

Example 2:

Security Category Policy and Guidance Development = {(confidentiality, Moderate), (integrity, Moderate), (availability, Low)}

Security Category Legal Prosecution and Litigation = {(confidentiality, High), (integrity, High), (availability, Moderate)}

2.1.3 Categorize System Security Impact – Step 1.3

The next step is to determine the single, system security category based on the information-type impact analysis conducted in Step 1.2.

The system security category is determined by identifying the high water mark for each of the security objectives (confidentiality, integrity, availability) based on the aggregate of all identified information types for the system.

Based on the information type categorization in Example 2, the system security category would be determined as follows:

Information Type Categorization(s)

Security Category Policy and Guidance Development = {(confidentiality, Moderate), (integrity, Moderate), (availability, Low)}

Security Category Legal Prosecution and Litigation = {(confidentiality, High), (integrity, High), (availability, Moderate)}

System Security Categorization

Security Category information system = {(confidentiality, High), (integrity, High), (availability, Moderate)} http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.199.pdf http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.199.pdf

The highest potential-impact level is High and therefore the system security category is High.

2.1.4 At the Completion of Step 1:

• The system characteristics, including the system boundary, should be defined and documented in the SSP;

• The information system should have one single categorization for the highest of Confidentiality, Integrity, and Availability, which should also be documented in the SSP;

• The System Owner should have sought and received local stakeholder concurrence on the system boundary and the security category; and

• Section 1 of the SSP should be completed with enough detail to clearly document the information system design and support Framework Steps 2 through 6.

2.2 How To Select Security Controls (Step 2)

The next step is to select, tailor, and supplement the appropriate security controls based on impact level, operating environment, individual circumstances, threat environments, and risk tolerance.

There are three sub-steps involved in arriving at a set of security controls, which adequately protect a system.

2.2.1 Identify the Recommended Controls Based on Impact Level – Step 2.1 Select the controls to be implemented to protect the information system based on the security category identified in Step 1. Refer to Appendix B for the full compendium of recommended controls for each impact level.

2.2.2 Tailor the Initial Set of Recommended Controls – Step 2.2 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 impact level or deciding to not implement it at all) 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-3 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 SSP under that specific control’s implementation description.

2.2.3 Supplement the Tailored Controls – Step 2.3

Once the controls have been selected and tailored, the SO may choose to supplement them with additional controls to provide greater security or address any specific requirements of the system or the system’s environment.8

8 While it is believed that most systems will not require any supplemental controls, there are several judiciary data types and/or systems (e.g., Witness Security information/systems), which may require supplemental controls to achieve an acceptable protection profile.

For example, control CA-2 Security Assessments (recommended for High, Moderate, and Low impact levels), requires that an assessment of the system’s security controls be conducted at least annually and provides some characteristics of an appropriate assessment. If the organization wants to ensure penetration testing is conducted as part of the assessment, the SO can supplement CA-2 with CA-2 (2) Specialized Assessments (which, is optional for moderate, and low impact levels), which would require that announced penetration testing be conducted at least quarterly as part of the control assessment. Optional controls are available for use in Appendix B.

2.2.4 At the Completion of Step 2:

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

• The set of controls should be documented in the SSP. 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 SSP under those relevant controls for historical purposes, and to expedite periodic control implementation assessments and system reauthorization.

2.3 How to Implement Security Controls (Step 3)

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 Framework Implementation Resources: SSP Development Focus. Not all of the controls will have to be implemented by the System Owner; some controls are inherited from outside the system (see Section 2.3.3), which will save time and resources. Details and status of the implementation of selected controls should be documented in the SSP. Although the implementation details will vary by control, the information should be sufficient to allow all users of the SSP to understand all pertinent information regarding the control and how the control was implemented on the system. This detail allows thorough control testing (Step 4) and monitoring (Step 6). In general, the control status will be one of five options (In Place, Partially In Place, Inherited, Planned, and Not Selected), which are described below. When part of a control is satisfied through inheritance, a control’s status should be documented as a Hybrid (see Section 2.3.6). When the control status is Partially In Place or Planned, then the planned actions to fully implement the control should be documented in the POA&M (see Section 2.3.7). If a POA&M exist in an enterprise risk management tool, include that ID number in the SSP until successful remediation.

2.3.1 In Place Control

If the control is fully implemented on the system, details of the implementation should be documented. The control implementation status is recorded as “In Place.”

2.3.2 Partially In Place Control

If the control is only partially implemented on the system, details of which components have been implemented and which have not been implemented should be documented. The control implementation status is listed as “Partially In Place.” The implementation details should also provide adequate documentation regarding the control components that have been selected, but which have not yet been implemented.

http://jnet.ao.dcn/information-technology/security/framework-shp/ssp-development-focus

2.3.3 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) 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.

• Local Infrastructure. Local networks (e.g., the court unit’s local area network) are a source of locally-implemented network controls (e.g., password requirements for LAN access, and network partitioning).

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

• 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 security controls.

When a control is inherited by a system, the SSP 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. If the control is entirely inherited, its status should be documented as “Inherited/In Place,” “Inherited/Partially In Place,” or “Inherited/Planned.” See Section 2.3.6 for information about partially inherited controls.

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

2.3.4 Planned Control

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, an explanation should be provided 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-4 Media Storage and MP-5 Media Transport controls should not be identified as being complete. To ensure the selected control meets system requirements, any incompletely implemented control should be documented in the SSP and tracked to completion in the POA&M (see Section 2.3.7).

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.

2.3.5 Not Selected Control

A SO may decide to exclude one or more Framework-recommended controls from the set of controls selected to be implemented on the system. The SSP control implementation description should document why the control is not selected (e.g., there is a compensating control or set of controls, or the cost of full implementation cannot be justified based upon the expected level of risk reduction).

2.3.6 Hybrid Control Qualifier

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 SSP. Recommended control PS-4 Personnel Termination is an example of partial inheritance of a control. Control PS-4 deals with actions to be taken upon termination of individual employment (terminate system access, conduct exit interviews, retrieve system-related property, etc.). Such an array of actions is likely to be conducted by various entities and processes in the organization, such as human resources and the IT department. However, the new system may need to be added to an automated access termination/notification process, which is the SO’s responsibility.

The implementation status of partially inherited controls should be document in one of three ways:

• In Place/Hybrid describes a condition where a control is fully implemented, but parts of the control are inherited and other parts are implemented directly by the system.

• Partially In Place/Hybrid status describes a condition where part of the control is implemented and part is not yet implemented, and the control is satisfied through both inheritance and direct implementation on the system.

• Planned/Hybrid describes a condition where no part of either the inherited or the system component of a planned control has been implemented.

2.3.7 Plan of Action and Milestones (POA&M)

POA&Ms are also known as Risk Mitigation Plans. While documenting the implementation of the security controls, the ISO will identify Partially in Place and Planned implementations which will not be completed before authorizing the information system in Step 5. 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. Since 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. Table 4 suggests a suitable format for the POA&M9.

Table 4 – Sample POA&M Template

Tracking Number

Control Number

Vulnerability Description

Date Identified

Risk Rating

Vul.

Status

Target Completion Milestones POC Comments

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 SO will use to track the risk from incomplete control implementations and vulnerabilities (which are identified in Step 4), 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.10

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

The following information is captured in the POA&M for each vulnerability:

• Tracking number for each vulnerability;

• Control number (e.g., AC-2) to assist in tracking incomplete control implementation risk and vulnerability progress;

• Vulnerability description should provide an understanding of the vulnerability as well as information on the users/parts of the system that are impacted by the vulnerability. Since an incomplete control implementation is a risk, it is also a vulnerability to the system until fully implemented;

• Date the vulnerability was identified;

• The risk rating of the vulnerability;

9 Also, see the POA&M Template (Excel).

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

http://dtsppwa-ftp01.adu.dcn/security/downloads/poam_template.xlsx

• Vulnerability (Vul.) status. Recommended options for this field are:

Completed. These vulnerabilities have been corrected on the system; a high level explanation regarding the actions taken could be added to the Comments field;

Ongoing. These vulnerabilities are currently being worked; ongoing vulnerabilities should have a date in the “Target Completion” field. Recognize that high risk rated vulnerabilities will normally be addressed before moderate risk rated vulnerabilities; therefore, it is recommended that realistic target completion dates be used;

Delayed. These vulnerabilities have not yet been started. It is recommended that a target start date be identified in the Comment field; and

Accepted. Some vulnerabilities and their risk rating will be accepted without being remediated. It is recommended that these vulnerabilities have an explanation added to the Comments field, and to the SSP under the relevant control.

• Target completion date;

• Identify any milestones (intermediate actions) to guide and track mitigation progress (include target dates);

• Identify the point-of-contact (POC) for each POA&M entry; and

• Add comments as needed.

2.3.8 At the Completion of Step 3:

• The SSP should contain the status of each of the system’s selected controls;

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

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

2.4 How to Assess Security Controls (Step 4)

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 SSP 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; and

• 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; and

• 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.

A Security Risk Management Resource Packet (which includes tools for self-assessment) is available on JNet at Best Practices, Resource Packets, and Guidelines.

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 5). 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.4.1 Control Assessment Plan

The SO should develop a security assessment plan (SAP) to assemble an assessment team, state objectives, and provide a detailed roadmap for an assessment of the security controls. If an independent assessment is being conducted, 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 security 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 documented in a memorandum of agreement), incorporate previous assessment results (if sufficiently current and dependable), and…