Attachment_3_-_System_Security_Plan.pdf

System Security Plan

RESOURCE PACKET

Updated: December 4, 2017

Published: June 18, 2014

RESOURCE PACKET: System Security Plan Updated: December 4, 2017

Table of Contents I. Purpose

II. Directions

III. Information

IV. Introductory Resources

V. Step-by-Step Resources

Step 1: Categorize Information System Risk

Step 2: Select Security Controls

Step 3: Implement Security Controls

Step 4: Assess Security Controls

Step 5: Authorize the Information System

Step 6: Monitor Security Controls

I. Purpose This document provides guidance for implementing the Judiciary Information Security Framework (Framework) security risk management framework, with particular focus on creating and managing a System Security Plan (SSP) for an application or a network, whether at the national or court-unit level. Guidance and relevant resources are provided in an efficient, process-oriented manner.

II. Directions

Before starting an SSP, review this document in its entirety to become familiar with the six steps of the security risk management process and the resources available to help you through each step.

This understanding will save you time and effort.

You are advised not to dive into tailoring the example SSP available from the IT Security Office until you have reviewed this document and the available resources (particularly the introductory resources identified in Section IV).

III. Information The IT Security Acronyms listing and Glossary of Judiciary Information Security Framework Terms are available for further clarification.

Questions or comments concerning this document may be directed to the IT Security Office at

(202) 502-2350.

http://jnet.ao.dcn/information-technology/security/framework-shp/judiciary_info_sec_framework http://jnet.ao.dcn/information-technology/security/framework-shp/judiciary_info_sec_framework http://jnet.ao.dcn/information-technology/security/framework-shp/it_sec_acronyms http://jnet.ao.dcn/information-technology/security/framework-shp/framework-glossary http://jnet.ao.dcn/information-technology/security/framework-shp/framework-glossary mailto:AO_ITSO@ao.uscourts.gov

IV. Introductory Resources

A. Guide to Judiciary Policy Project managers of national and local court-unit software applications are responsible for creating and maintaining an SSP that documents specific data protection requirements and processes for their applications and describes the controls fulfilling these requirements. Court units are also responsible for developing SSPs to document controls protecting their LANs1.

B. Guide to Implementing the Judiciary Information Security Framework The Guide to Implementing the Judiciary Information Security Framework (Framework Guide) addresses the activities of each of the six steps of the Judiciary’s Security Risk Management Framework2, as identified in Figure 1.

Figure 1: Security Risk Management Framework

1 Guide to Judiciary Policy, Volume 15, Chapter 3, Sections 310.20 (b) and 310.20.09 2 For additional information, see the Brochure: Judiciary Information Security Framework Demystified, the

Framework Glossary, and FAQs.

http://jnet.ao.dcn/information-technology/security/framework-shp/framework-guide http://jnet.ao.dcn/policy-guidance/guide-judiciary-policy/volume-15-information-technology/ch-3-security#310_20 http://jnet.ao.dcn/information-technology/security/security-training-and-awareness-resources/security-awareness-brochures/framework-demystified http://jnet.ao.dcn/information-technology/security/framework-shp/framework-glossary http://jnet.ao.dcn/information-technology/security/framework-shp/frequently-asked-questions

The six steps of the Security Risk Management Framework are:

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

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

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

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

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

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

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

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

C. Framework Implementation Electronic Learning Module (ELM) The Judiciary Information Security Framework: an Introduction to Implementation ELM provides an understanding and knowledge of how to implement the Judiciary Information Security Framework and, in the process, complete and update the SSP.

This ELM expands on the Framework Guide’s step-by-step discussion as it walks through Framework implementation and explains the tools available to move forward effectively.

Viewing Details: This ELM is approximately 32 minutes, and should initially be watched completely to provide a clear overview of the processes. There are sidebar tabs which can be selected to view any specific topic again. See “NAVIGATION INSTRUCTIONS” tab (on top of the ELM page) for details on how to navigate around this ELM.

Before continuing, review the ELM, with the Framework Guide open for reference.

3 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://jnet.ao.dcn/information-technology/security/framework-shp/framework-guide http://training.sdso.ao.dcn/trainingmaterials/AdtlTr/ITSO/ITSO_Framework/launcher.html http://training.sdso.ao.dcn/trainingmaterials/AdtlTr/ITSO/ITSO_Framework/launcher.html

V. Step-by-Step Resources

Step 1: Categorize Information System Risk This step consists of defining the system boundary (Step 1.1), and then categorizing the system based on the potential risk-impact to the Judiciary should events occur that jeopardize the confidentiality, integrity, or availability of the information or the information system. The System Boundary and the Security Category arrived at should be reviewed and concurred with by local stakeholders (e.g., IT Security Officer (ISO), System Owner (SO), IT Director, and/or the Authorizing Official).

Also during this step, any applicable national or local policies and guidance should be identified and documented in a SSP (an annotated, example SSP for your system type is available in item E, below); roles and responsibilities for Authorizing Official, SO, ISO, etc., should be documented and assignments identified; and, results of this step should be documented in Section 1 of the SSP, thus completing Section 1 with enough detail to clearly document the information system design and to support Steps 2-6.

Below are recommended resources for Step 1:

A. The Judiciary Information Security Framework: an Introduction to Implementation Electronic Learning Module (ELM) Review the “Step One” section of the ELM.

Viewing Details: The “Step One” section is approximately 6 minutes long. There are sidebar tabs which can be selected to view any specific topic again. See “NAVIGATION INSTRUCTIONS” tab (on top of the ELM page) for details on how to navigate around this ELM.

B. Defining the System Boundary RP (Step 1.1) System Boundary Definition (SBD) is necessary for the identification of the physical hardware, subsystems, and system interconnections, which comprise the system as well as how critical the system’s function is to judiciary business operations. 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. This Resource Packet (RP) provides guidance and examples for defining the system boundary.

C. Guide to Implementing the Judiciary Information Security Framework Specific guidance has been provided to help the Judiciary with determining the Security Category. Review the following sections:

• Section 2.1 How to Categorize Information System (Step 1).

http://training.sdso.ao.dcn/trainingmaterials/AdtlTr/ITSO/ITSO_Framework/launcher.html http://training.sdso.ao.dcn/trainingmaterials/AdtlTr/ITSO/ITSO_Framework/launcher.html http://jnet.ao.dcn/information-technology/security/best-practices/ http://jnet.ao.dcn/information-technology/security/framework-shp/framework-guide

D. National and Local IT Security Policies and Guidance System security should be compliant with national and local IT security policies and guidance. Make sure any applicable national policies and guidance are identified and documented in the SSP (and are later considered in control selection, tailoring, and implementation). Refer to:

• Guide to Judiciary Policy;

• Other Guidance Related to National IT Security Policy; and

• Local Policies and Guidance.

E. Annotated-Example SSPs Annotated-example SSPs are available as a starting point for judiciary personnel to develop an actual SSP. These examples are completed SSPs for fictitious systems with explanatory annotations to clarify content. The SO or ISO (or designee) should use the SSP example appropriate to the system type:

• Court LAN SSP Example; and

• Application SSP Example for national applications, and for court-developed applications intended for use by multiple courts.

F. Security Engineering Division (SED) (Bob Morningstar, Chief) In support of Step 1 activities, ITSO-SED consults with national applications and court units developing applications for use at multiple courts on integrating security engineering into their projects, with focus on helping the System Owner define and document the system boundary and Security Category. SED support can be requested by email at: SED_Support.

G. At the Completion of Step 1:

• The SO or ISO should have sought and received local stakeholder concurrence on the system boundary and Security Category;

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

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

http://jnet.ao.dcn/policy-guidance/guide-judiciary-policy http://jnet.ao.dcn/information-technology/security/national-it-security-policy-guidance http://jnet.ao.dcn/sites/default/files/information_technology/library/security/court_lan_ssp_example.docx http://jnet.ao.dcn/sites/default/files/information_technology/library/security/application_ssp_example.docx mailto:robert_morningstar@ao.uscourts.gov mailto:AOml_SEB_CM?subject=Request_Security_Framework_Support_for_Step_1

Step 2: Select Security Controls The annotated, example SSP used in Step 1 was provided with the recommended baseline security controls selected for that environment (Court LAN, national application, etc.), based on the Security Category identified in the SSP. If the actual Security Category or Impact Level of the system is different from the example, then the initial action in Step 2 should be to align the set of selected controls with the actual Impact Level (using the annotated, example SSP).

The System Owner may make risk-based decisions to further tailor and supplement these controls (e.g., non-select recommended controls or add additional controls). The System Owner or ISO should record those decisions in the SSP under the relevant controls.

Note: Do not change the actual control tables, as they provide the judiciary security baseline.

Below are recommended resources for Step 2:

A. The SSP begun in Step 1, with Section 1 completed;

B. The Judiciary Information Security Framework: an Introduction to Implementation Electronic Learning Module (ELM) Review the “Step Two” section of the ELM.

Viewing Details: The “Step Two” section is approximately 6 minutes long. There are sidebar tabs which can be selected to view any specific topic again. See “NAVIGATION INSTRUCTIONS” tab (on top of the ELM page) for details on how to navigate around this ELM.

Note: This ELM section demonstrates how to use Appendix B of the Framework Guide to determine which controls are recommended for a system based on the Security Category/Impact Level.

C. National and Local IT Security Policies and Guidance During the control selection process, consider the national and local IT security policies and guidance documented in the SSP during Step 1.

D. Guide to Implementing the Judiciary Information Security Framework

• Section 2.2 How to Select Security Controls (Step 2)

• Appendix B: Judiciary Recommended Security Controls This appendix provides a table of security control recommendations based on a system’s Impact Level.

E. Security Engineering Division (SED) (Bob Morningstar, Chief) In support of Step 2 activities, ITSO-SED consults with national applications and court units developing applications for use at multiple courts on integrating security engineering into their projects, with focus on helping the SO or ISO select controls.

SED support can be requested by email at: SED_Support.

http://training.sdsd.ao.dcn/trainingmaterials/AdtlTr/ITSO/ITSO_Framework/launcher.html http://training.sdsd.ao.dcn/trainingmaterials/AdtlTr/ITSO/ITSO_Framework/launcher.html http://training.sdsd.ao.dcn/trainingmaterials/AdtlTr/ITSO/ITSO_Framework/launcher.html http://jnet.ao.dcn/information-technology/security/framework-shp/framework-guide mailto:robert_morningstar@ao.uscourts.gov mailto:AOml_SEB_CM?subject=Request_Security_Framework_Support_for_Step_2

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

Step 3: Implement Security Controls Implement security controls using sound systems engineering practices. For each selected control in the SSP (from Step 2), do the following:

1. Select the “Implementation Status” from the drop down list;

2. Document the “Implementation of control” with specific details on each item of that control description to provide sufficient details for testing (in Step 4). For guidance on details needed, the relevant SSP example generally has implementation details which are sufficient for testing; and

3. Any control with a “partially in place” or “planned” implementation status should have the plan for full control implementation documented in the “Implementation of control” description, and include a summary in the Plan of Action and Milestones (POA&M).

Any risk acceptance should also be added to the POA&M.

Note: If a recommended control for the Impact Level is not selected, then the control implementation description should explain why it was not selected.

Below are recommended resources for Step 3:

A. The SSP from Step 2

B. The Judiciary Information Security Framework: an Introduction to Implementation Electronic Learning Module (ELM) Review the “Step Three” section of the ELM.

Viewing Details: The “Step Three” section is approximately 4-1/2 minutes long.

There are sidebar tabs which can be selected to view any specific topic again. See “NAVIGATION INSTRUCTIONS” tab (on top of the ELM page) for details on how to navigate around this ELM.

C. Guide to Implementing the Judiciary Information Security Framework

• Section 2.3 How to Implement Security Controls (Step 3)

D. Best Practices, Resource Packets, and Guidelines This series of information security best practices, resource packets (RP), and guidelines are provided to help judiciary organizations document and establish security processes for their IT systems.

E. Recommended Safeguard/Control Implementation Resources These 18 safeguard/control family PDFs identify resources for the understanding and implementation of each Judiciary recommended security control.

F. Potential Safeguard/Control Inheritance National program offices have identified safeguards/controls which are potentially inherited, in whole or in part, by court units, national systems, and others. ISOs are encouraged to use these applicable documents as a resource to understand and describe inherited or partially inherited controls in their system security plans (SSPs).

http://training.sdso.ao.dcn/trainingmaterials/AdtlTr/ITSO/ITSO_Framework/launcher.html http://training.sdso.ao.dcn/trainingmaterials/AdtlTr/ITSO/ITSO_Framework/launcher.html http://jnet.ao.dcn/information-technology/security/framework-shp/framework-guide http://jnet.ao.dcn/information-technology/security/best-practices/ http://jnet.ao.dcn/information-technology/security/framework-shp/sirs http://jnet.ao.dcn/information-technology/security/framework-shp/potential_safeguard_inheritance

G. POA&M Template (for national systems) Risk Mitigation Plan (RMP) Template (for court units) These templates provide structures for documenting plans for reducing risk associated with selected controls not yet fully implemented, and risk acceptance.

The System Owner may choose a different format for the POA&M/RMP.

Development and tracking of the plan begins in Step 3 and the plan is updated through Step 4 and Step 6.

H. Security Document Support Service The AO provides court units and national systems with security documentation support, and assistance in understanding and implementing the Framework.

I. Building Local IT Security Policies Service This AO service assists court units and national program offices with creating local IT security policies.

J. AO IT Security Research the AO IT Security page for announcements, security services, Framework Self-Help Portal, and IT security resources.

K. Security Policy and Assessment Division (SPA) (Sharon Jurado, Division Chief) In support of Step 3 activities, ITSO-SPA provides consultation on security risk management (i.e., activities of the Judiciary Information Security Framework) including the preparation of security documentation, particularly SSP development and review. ITSO-SPA points of contact are: Dan Patton at 202-502-2357 for court units; and Andrew Perkinson at 202-502-2557 for national systems.

L. At the Completion of Step 3:

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

• The SO or ISO 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 ISO should have a POA&M/RMP in place to track planned or partially implemented controls, other security vulnerabilities, and risk acceptance.

http://dtsppwa-ftp01.adu.dcn/security/downloads/poam_template.xlsx http://jnet.ao.dcn/sites/default/files/information_technology/xls/risk_mitigation_plan_template.xlsx http://jnet.ao.dcn/information-technology/security/security-services/documentation-support-service http://jnet.ao.dcn/information-technology/security/security-services/documentation-support-service http://jnet.ao.dcn/information-technology/security/building-local-it-security-policies-service http://jnet.ao.dcn/information-technology/security mailto:sharon_jurado@ao.uscourts.gov mailto:dan_patton@ao.uscourts.gov mailto:andrew_perkinson@ao.uscourts.gov

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

Step 4 includes:

1. Develop a Security Assessment Plan;

2. Assess the set of security controls identified;

3. Document assessment results in a IT Security Assessment Report (SAR);

4. Update the SSP with actual status of controls, and control implementations;

5. Update the POA&M/RMP (started in Step 3) to track planned and partial control implementations, vulnerability mitigations, and risk acceptance; and

6. If any high risk vulnerabilities will be accepted, create a Security Risk Acceptance Memo for review by the Authorizing Official in Step 5.

Below are recommended resources for Step 4:

A. The SSP and POA&M from Step 3

B. The Judiciary Information Security Framework: an Introduction to Implementation Electronic Learning Module (ELM) Review the “Step Four” section of the ELM.

Viewing Details: The “Step Four” section is approximately 3 minutes long. There are sidebar tabs which can be selected to view any specific topic again. See “NAVIGATION INSTRUCTIONS” tab (on top of the ELM page) for details on how to navigate around this ELM.

C. Guide to Implementing the Judiciary Information Security Framework

• Section 2.4 How to Assess Security Controls (Step 4)

D. Vulnerability Scanning Service (VSS) The VSS allows court units and national systems to gain visibility into vulnerabilities that are present within their system boundaries. The service provides the flexibility for IT staff to configure, schedule, and execute vulnerability scans using Tenable’s SecurityCenter Continuous View (SCCV). The service can help IT staff identify missing patches, misconfigurations, use of default passwords, and other vulnerabilities that can potentially compromise the security of their IT assets.

VSS support and contact details are provided on the right navigation bar of this page.

E. National System Security Assessments Team (NSSA) For national systems and courts that develop applications for multiple court use, the ITSO-SPA division NSSA branch provides assessment of the security controls implementation for the technical, management, and operational control classes based on the SSP, and the POA&M. NSSA point of contact is Andrew Perkinson at 202-502-2557.

http://training.sdso.ao.dcn/trainingmaterials/AdtlTr/ITSO/ITSO_Framework/launcher.html http://training.sdso.ao.dcn/trainingmaterials/AdtlTr/ITSO/ITSO_Framework/launcher.html http://jnet.ao.dcn/information-technology/security/framework-shp/framework-guide http://jnet.ao.dcn/information-technology/security/vulnerability-scanning-service mailto:andrew_perkinson@ao.uscourts.gov

F. Judiciary System Security Testing Services (JSST) The ITSO-SPA division provides security testing services for the technical control class to national system program offices and to courts that develop applications for multiple court use. The security testing activities are integrated into the systems development lifecycle – prior to initial deployment and coincident with its release cycle – to ensure the system remains secure in production. For these national systems and court developed systems, JSST services provide the opportunity to identify and mitigate security risks before the system (or upgrades to the system) is released. To request security testing, use the SOP guide called “Using the HEAT Ticketing System to Request Security Testing” (details on this page). JSST point of contact is Frank Krotzer at 202-502-1343.

G. Security Risk Management RP The primary objective of security risk management is to identify and reduce risks to an acceptable level. The Administrative Office has created this Security Risk Management Resource Packet (RP) to help judiciary organizations understand risk management and establish a risk assessment process for their information technology (IT) systems.

H. Application Risk Acceptance and Risk Mitigation Process For high risk vulnerabilities acceptance, national program offices and court units responsible for systems used by multiple courts should formally notify the AO Department of Technology Services (DTS), Chief of the IT Security Office (ITSO) by documenting acceptance of unmitigated risks. This resource provides guidance on the high risk acceptance process and example Security Risk Acceptance Memos.

I. At the Completion of Step 4:

• The IT Security Assessment Reports should have captured the results of the assessment(s) activities;

• The actual status and implementation of selected system controls should be documented in the SSP;

• The POA&M/RMP should reflect all changes in mitigation plans and any acceptance of risk and be tracked (preferably in the enterprise cybersecurity risk management tool); and

• If there is any high risk acceptance, a Security Risk Acceptance Memo should be drafted for review in Step 5.

http://jnet.ao.dcn/information-technology/security/judiciary-system-security-testing-services mailto:frank_krotzer@ao.uscourts.gov http://jnet.ao.dcn/information-technology/security/best-practices/ http://jnet.ao.dcn/information-technology/security/application-risk-acceptance-and-risk-mitigation-process

Step 5: Authorize the Information System A Security Authorization Request Letter is created by the SO, requesting that the Authorizing Official review the system documentation and make an authorization decision.

The Authorizing Official (or designee) reviews the SSP, the IT Security Assessment Reports, the POA&Ms/RMPs, the Security Risk Acceptance Memo (if utilized) and other system documentation to determine if the residual risks are acceptable to authorize the information system. The authorization decision is recorded in the Security Authorization Decision Letter prepared by the Authorizing Official.

Below are recommended resources for Step 5:

A. The SSP, IT Security Assessment Reports, POA&M/RMP, Security Risk Acceptance Memo (if utilized), and other system documentation from Step 4 as required by the Authorizing Official.

B. The Judiciary Information Security Framework: an Introduction to Implementation Electronic Learning Module (ELM) Review the “Step Five” section of the ELM.

Viewing Details: The “Step Five” section is approximately 2 minutes long. There are sidebar tabs which can be selected to view any specific topic again. See “NAVIGATION INSTRUCTIONS” tab (on top of the ELM page) for details on how to navigate around this ELM.

C. Guide to Implementing the Judiciary Information Security Framework

• Section 2.5 How to Authorize the Information System (Step 5)

D. Security Authorization Request Letter Template

E. Security Authorization Decision Letter Template

F. At the Completion of Step 5:

• The Authorizing Official should have:

- granted the System Owner security approval to “operate or go live” without conditions; or

- granted the System Owner conditional security approval to “operate or go live,”;

or

- denied the System Owner security approval to advance to production;

• If approval is conditional, the Security Authorization Decision Letter should identify the actions the SO should take (and expected timeframes) to mitigate identified risks; and

• The Security Risk Acceptance Memo (if utilized) reflects any changes to accepted high risk as directed by the Office Chief/Court Unit Executive, and is delivered to AO-DTS-ITSO (with the POA&M/RMP attached).

http://jnet.ao.dcn/information-technology/security/information-security-framework/security-framework-self-help-portal http://jnet.ao.dcn/information-technology/security/information-security-framework/security-framework-self-help-portal http://jnet.ao.dcn/information-technology/security/information-security-framework/security-framework-self-help-portal http://jnet.ao.dcn/information-technology/security/information-security-framework/security-framework-self-help-portal http://jnet.ao.dcn/information-technology/security/framework-shp/framework-guide http://dtsppwa-ftp01.adu.dcn/security/downloads/sec_auth_req_ltr.docx http://dtsppwa-ftp01.adu.dcn/security/downloads/sec_auth_dec_ltr.docx

Step 6: Monitor Security Controls Security assessments provide a snapshot of security at a point in time. Security controls should be monitored on an ongoing basis to ensure that they continue to operate effectively and are providing the security intended. Also during Step 6, items in the POA&M/RMP are tracked to completion, with new risk mitigation tasks added when identified. If a Security Risk Acceptance Memo is utilized, then it should be reviewed for on-going validity at least yearly. Configuration management and change control are primary processes to identify changes in the information system, and thus possible changes to the SSP. The SSP should be updated as the system, its operating environment, or the implementation of controls changes.

Below are recommended resources for Step 6:

A. The SSP, POA&M/RMP, and Security Risk Acceptance Memo (if utilized) from Step 5.

B. The Judiciary Information Security Framework: an Introduction to Implementation Electronic Learning Module (ELM) Review the “Step Six” section of the ELM.

Viewing Details: The “Step Six” section is approximately 2 minutes long. There are sidebar tabs which can be selected to view any specific topic again. See “NAVIGATION INSTRUCTIONS” tab (on top of the ELM page) for details on how to navigate around this ELM.

C. Guide to Implementing the Judiciary Information Security Framework

• Section 2.6 Monitoring Security Controls (Step 6)

D. Continuous Monitoring of Safeguard Effectiveness RP This Resource Packet (RP) is intended to help judiciary organizations develop or augment existing local policies and procedures on control monitoring.

E. Application Risk Acceptance and Risk Mitigation Process Review the Security Risk Acceptance Memo (prepared in Step 4, approved in Step 5, (or created and approved in Step 6), and delivered to AO-DTS-ITSO following approval) for validity at lease annually. Revise as appropriate and deliver to

AO-DTS-ITSO.

F. Security Operations Center (soc@ao.uscourts.gov) The SOC provides services/tools in support of judiciary security, including server assessments, Vulnerability Scanning Service Scanning Service, McAfee HIPS, and various technical assessment tools.

http://training.sdso.ao.dcn/trainingmaterials/AdtlTr/ITSO/ITSO_Framework/launcher.html http://training.sdso.ao.dcn/trainingmaterials/AdtlTr/ITSO/ITSO_Framework/launcher.html http://jnet.ao.dcn/information-technology/security/framework-shp/framework-guide http://jnet.ao.dcn/information-technology/security/best-practices/ http://jnet.ao.dcn/information-technology/security/application-risk-acceptance-and-risk-mitigation-process mailto:soc@ao.uscourts.gov http://jnet.ao.dcn/information-technology/security/vulnerability-scanning-service http://jnet.ao.dcn/information-technology/security/hips

G. Step 6 includes the following:

• A set of security controls and frequency target for their routine re-assessment are defined;

• An assessment test plan and schedule, which continues across the life of the system, is developed. Once a system is operational, control monitoring should continue until the system is removed from service;

• Regularly updating the SSP (at least annually or when a major system change is implemented) and POA&M/RMP (at least weekly);

• If a Security Risk Acceptance Memo is utilized, then it should be reviewed for on-going validity at least yearly; and

• Security Framework Steps 1 through 5 of the Judiciary’s Security Risk Management Framework (see Figure 1) should be performed on the information system. Periodic intervals should not exceed: five years for court units; three years for high priority national systems, five years for moderate priority national systems, seven years for low priority national systems; or upon significant changes. This will validate the system’s Security Category/Impact Level and the controls applied to the system, reassess the effectiveness of those controls, and ensure that reauthorization to continue to operate is appropriately considered.