urn: urn:intuitem:risk:library:cjis-policy-5.9.4
locale: en
ref_id: CJIS-POLICY-5.9.4
name: Criminal Justice Information Services (CJIS) Security Policy
description: The Criminal Justice Information Services (CJIS) Security Policy is a
  set of standards and guidelines developed by the FBI to help secure criminal justice
  information (CJI), such as fingerprints, criminal histories, and other data. The
  policy aims to provide appropriate controls to protect the full lifecycle of CJI,
  ensuring that it is securely handled, stored, and transmitted.
copyright: US CJIS
version: 1
publication_date: 2024-06-14
provider: US CJIS
packager: intuitem
objects:
  framework:
    urn: urn:intuitem:risk:framework:cjis-policy-5.9.4
    ref_id: CJIS-POLICY-5.9.4
    name: Criminal Justice Information Services (CJIS) Security Policy
    description: The Criminal Justice Information Services (CJIS) Security Policy
      is a set of standards and guidelines developed by the FBI to help secure criminal
      justice information (CJI), such as fingerprints, criminal histories, and other
      data. The policy aims to provide appropriate controls to protect the full lifecycle
      of CJI, ensuring that it is securely handled, stored, and transmitted.
    requirement_nodes:
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:1
      assessable: false
      depth: 1
      ref_id: '1'
      name: INTRODUCTION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:1.1
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:1
      ref_id: '1.1'
      name: Purpose
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node4
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:1.1
      description: The CJIS Security Policy provides Criminal Justice Agencies (CJA)
        and Noncriminal Justice Agencies (NCJA) with a minimum set of security requirements
        for access to Federal Bureau of Investigation (FBI) Criminal Justice Information
        Services (CJIS) Division systems and information and to protect and safeguard
        Criminal Justice Information (CJI). This minimum standard of security requirements
        ensures continuity of information protection. The essential premise of the
        CJIS Security Policy is to provide the appropriate controls to protect CJI,
        from creation through dissemination; whether at rest or in transit.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node5
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:1.1
      description: "The CJIS Security Policy integrates presidential directives, federal\
        \ laws, FBI directives, the criminal justice community\u2019s Advisory Policy\
        \ Board (APB) decisions along with nationally recognized guidance from the\
        \ National Institute of Standards and Technology (NIST) and the National Crime\
        \ Prevention and Privacy Compact Council (Compact Council)."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:1.2
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:1
      ref_id: '1.2'
      name: Scope
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node7
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:1.2
      description: "At the consent of the advisory process, and taking into consideration\
        \ federal law and state statutes,the CJIS Security Policy applies to all entities\
        \ with access to, or who operate in support of, FBI CJIS Division\u2019s services\
        \ and information. The CJIS Security Policy provides minimum security requirements\
        \ associated with the creation, viewing, modification, transmission, dissemination,storage,\
        \ or destruction of CJI."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node8
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:1.2
      description: Entities engaged in the interstate exchange of CJI data for noncriminal
        justice purposes are also governed by the standards and rules promulgated
        by the Compact Council.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:1.3
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:1
      ref_id: '1.3'
      name: Relationship to Local Security Policy and Other Policies
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node10
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:1.3
      description: The CJIS Security Policy may be used as the sole security policy
        for the agency. The local agency may complement the CJIS Security Policy with
        a local policy, or the agency may develop their own stand-alone security policy;
        however, the CJIS Security Policy shall always be the minimum standard and
        local policy may augment, or increase the standards, but shall not detract
        from the CJIS Security Policy standards.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node11
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:1.3
      description: 'The agency shall develop, disseminate, and maintain formal, documented
        procedures to facilitate the implementation of the CJIS Security Policy and,
        where applicable, the local security policy.

        The policies and procedures shall be consistent with applicable laws, executive
        orders, directives,policies, regulations, standards, and guidance. Procedures
        developed for CJIS Security Policy areas can be developed for the security
        program in general, and for a particular information system,when required.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node12
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:1.3
      description: "This document is a compendium of applicable policies in providing\
        \ guidance on the minimum security controls and requirements needed to access\
        \ FBI CJIS information and services. These policies include presidential directives,\
        \ federal laws, FBI directives and the criminal justice community\u2019s APB\
        \ decisions. State, local, and Tribal CJA may implement more stringent policies\
        \ and requirements. Appendix I contains the references while Appendix E lists\
        \ the security forums and organizational entities referenced in this document"
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:1.4
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:1
      ref_id: '1.4'
      name: Terminology Used in This Document
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node14
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:1.4
      description: 'The following terms are used interchangeably throughout this document:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node15
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:1.4
      description: "\u2022 Agency and Organization: The two terms in this document\
        \ refer to any entity that submits or receives information, by any means,\
        \ to/from FBI CJIS systems or services."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node16
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:1.4
      description: "\u2022 Information and Data: Both terms refer to CJI."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node17
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:1.4
      description: "\u2022 System, Information System, Service, or named applications\
        \ like NCIC: all refer to connections to the FBI\u2019s criminal justice information\
        \ repositories and the equipment used to establish said connections."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node18
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:1.4
      description: "\u2022 References/Citations/Directives: Appendix I contains all\
        \ of the references used in this Policy and may contain additional sources\
        \ that could apply to any section.\nAppendix A and B provide an extensive\
        \ list of the terms and acronyms."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:1.5
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:1
      ref_id: '1.5'
      name: Distribution of the CJIS Security Policy
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node20
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:1.5
      description: The CJIS Security Policy, version 5.0 and later, is a publicly
        available document and may be posted and shared without restrictions.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:2
      assessable: false
      depth: 1
      ref_id: '2'
      name: CJIS SECURITY POLICY APPROACH
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node22
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:2
      description: The CJIS Security Policy represents the shared responsibility between
        FBI CJIS, CJIS Systems Agency (CSA), and the State Identification Bureaus
        (SIB) of the lawful use and appropriate protection of CJI. The Policy provides
        a baseline of security requirements for current and planned services and sets
        a minimum standard for new initiatives.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:2.1
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:2
      ref_id: '2.1'
      name: CJIS Security Policy Vision Statement
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node24
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:2.1
      description: The executive summary of this document describes the vision in
        terms of business needs for confidentiality, integrity, and availability of
        information. The APB collaborates with the FBI CJIS Division to ensure that
        the Policy remains updated to meet evolving business, technology and security
        needs.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:2.2
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:2
      ref_id: '2.2'
      name: Architecture Independent
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node26
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:2.2
      description: Due to advancing technology and evolving business models, the FBI
        CJIS Division is transitioning from legacy stovepipe systems and moving toward
        a flexible services approach. Systems such as National Crime Information Center
        (NCIC), National Instant Criminal Background Check System(NICS), and Next
        Generation Identification (NGI) will continue to evolve and may no longer
        retain their current system platforms, hardware, or program name. However,
        the data and services provided by these systems will remain stable
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node27
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:2.2
      description: The CJIS Security Policy looks at the data (information), services,
        and protection controls that apply regardless of the implementation architecture.
        Architectural independence is not intended to lessen the importance of systems,
        but provide for the replacement of one technology with another while ensuring
        the controls required to protect the information remain constant. This objective
        and conceptual focus on security policy areas provide the guidance and standards
        while avoiding the impact of the constantly changing landscape of technical
        innovations. The architectural independence of the Policy provides agencies
        with the flexibility for tuning their information security infrastructure
        and policies to reflect their own environments.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:2.3
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:2
      ref_id: '2.3'
      name: Risk Versus Realism
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node29
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:2.3
      description: "Every \u201Cshall\u201D statement contained within the CJIS Security\
        \ Policy has been scrutinized for risk versus the reality of resource constraints\
        \ and real-world application. The purpose of the CJIS Security Policy is to\
        \ establish the minimum security requirements; therefore, individual agencies\
        \ are encouraged to implement additional controls to address agency specific\
        \ risks. Each agency faces risk unique to that agency. It is quite possible\
        \ that several agencies could encounter the same type of risk however depending\
        \ on resources would mitigate that risk differently. In that light, a risk-based\
        \ approach can be used when implementing requirements."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3
      assessable: false
      depth: 1
      ref_id: '3'
      name: ROLES AND RESPONSIBILITIES
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.1
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3
      ref_id: '3.1'
      name: Shared Management Philosophy
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node32
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.1
      description: 'In the scope of information security, the FBI CJIS Division employs
        a shared management philosophy with federal, state, local, and tribal law
        enforcement agencies. Although an advisory policy board for the NCIC has existed
        since 1969, the Director of the FBI established the CJIS APB in March 1994
        to enable appropriate input and recommend policy with respect to CJIS services.
        Through the APB and its Subcommittees and Working Groups, consideration is
        given to the needs of the criminal justice and law enforcement community regarding
        public policy,statutory and privacy aspects, as well as national security
        relative to CJIS systems and information.

        The APB represents federal, state, local, and tribal law enforcement and criminal
        justice agencies throughout the United States, its territories, and Canada.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node33
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.1
      description: The FBI has a similar relationship with the Compact Council, which
        governs the interstate exchange of criminal history records for noncriminal
        justice purposes. The Compact Council is mandated by federal law to promulgate
        rules and procedures for the use of the Interstate Identification Index (III)
        for noncriminal justice purposes. To meet that responsibility, the Compact
        Council depends on the CJIS Security Policy as the definitive source for standards
        defining the security and privacy of records exchanged with noncriminal justice
        practitioners.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3
      ref_id: '3.2'
      name: Roles and Responsibilities for Agencies and Parties
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.1
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2
      ref_id: 3.2.1
      name: CJIS Systems Agencies (CSA)
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node36
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.1
      description: "The CSA is responsible for establishing and administering an information\
        \ technology security program throughout the CSA\u2019s user community, to\
        \ include the local levels. The head of each CSA shall appoint a CJIS Systems\
        \ Officer (CSO). The CSA may impose more stringent protection measures than\
        \ outlined in this document. Such decisions shall be documented and kept current."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.2
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2
      ref_id: 3.2.2
      name: CJIS Systems Officer (CSO)
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node38
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.2
      description: 'The CSO is an individual located within the CSA responsible for
        the administration of the CJIS network for the CSA. Pursuant to the Bylaws
        for the CJIS Advisory Policy Board and Working Groups, the role of CSO shall
        not be outsourced. The CSO may delegate responsibilities to subordinate agencies.
        The CSO shall set, maintain, and enforce the following:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.2-1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.2
      ref_id: 3.2.2-1
      description: Standards for the selection, supervision, and separation of personnel
        who have access to CJI.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.2-2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.2
      ref_id: 3.2.2-2
      description: Policy governing the operation of computers, access devices, circuits,
        hubs, routers,firewalls, and other components that comprise and support a
        telecommunications network and related CJIS systems used to process, store,
        or transmit CJI, guaranteeing the priority,confidentiality, integrity, and
        availability of service needed by the criminal justice community.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.2-2-a
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.2-2
      ref_id: 3.2.2-2-a
      description: Ensure appropriate use, enforce system discipline, and ensure CJIS
        Division operating procedures are followed by all users of the respective
        services and information.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.2-2-b
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.2-2
      ref_id: 3.2.2-2-b
      description: Ensure state/federal agency compliance with policies approved by
        the APB and adopted by the FBI.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.2-2-c
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.2-2
      ref_id: 3.2.2-2-c
      description: Ensure the appointment of the CSA ISO and determine the extent
        of authority to the CSA ISO.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.2-2-d
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.2-2
      ref_id: 3.2.2-2-d
      description: Ensure the designation of a Terminal Agency Coordinator (TAC) within
        each agency with devices accessing CJIS systems.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.2-2-e
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.2-2
      ref_id: 3.2.2-2-e
      description: Ensure each agency having access to CJI has someone designated
        as the Local Agency Security Officer (LASO).
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.2-2-f
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.2-2
      ref_id: 3.2.2-2-f
      description: Ensure each LASO receives enhanced security awareness training
        (ref. Section 5.2).
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.2-2-g
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.2-2
      ref_id: 3.2.2-2-g
      description: Approve access to FBI CJIS systems.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.2-2-h
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.2-2
      ref_id: 3.2.2-2-h
      description: Assume ultimate responsibility for managing the security of CJIS
        systems within their state and/or agency.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.2-2-i
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.2-2
      ref_id: 3.2.2-2-i
      description: Perform other related duties outlined by the user agreements with
        the FBI CJIS Division.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.2-3
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.2
      ref_id: 3.2.2-3
      description: Outsourcing of Criminal Justice Functions
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.2-3-a
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.2-3
      ref_id: 3.2.2-3-a
      description: Responsibility for the management of the approved security requirements
        shall remain with the CJA. Security control includes the authority to enforce
        the standards for the selection, supervision, and separation of personnel
        who have access to CJI; set and enforce policy governing the operation of
        computers, circuits, and telecommunications terminals used to process, store,
        or transmit CJI; and to guarantee the priority service needed by the criminal
        justice community.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.2-3-b
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.2-3
      ref_id: 3.2.2-3-b
      description: Responsibility for the management control of network security shall
        remain with the CJA. Management control of network security includes the authority
        to enforce the standards for the selection, supervision, and separation of
        personnel who have access to CJI; set and enforce policy governing the operation
        of circuits and network equipment used to transmit CJI; and to guarantee the
        priority service as determined by the criminal justice community.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.3
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2
      ref_id: 3.2.3
      name: Terminal Agency Coordinator (TAC)
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node54
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.3
      description: "The TAC serves as the point-of-contact at the local agency for\
        \ matters relating to CJIS information access. The TAC administers CJIS systems\
        \ programs within the local agency and oversees the agency\u2019s compliance\
        \ with CJIS systems policies."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.4
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2
      ref_id: 3.2.4
      name: Criminal Justice Agency (CJA)
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node56
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.4
      description: 'A CJA is defined as a court, a governmental agency, or any subunit
        of a governmental agency which performs the administration of criminal justice
        pursuant to a statute or executive order and which allocates a substantial
        part of its annual budget to the administration of criminal justice.

        State and federal Inspectors General Offices are included.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.5
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2
      ref_id: 3.2.5
      name: Noncriminal Justice Agency (NCJA)
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node58
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.5
      description: A NCJA is defined (for the purposes of access to CJI) as an entity
        or any subunit thereof that provides services primarily for purposes other
        than the administration of criminal justice.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.6
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2
      ref_id: 3.2.6
      name: Contracting Government Agency (CGA)
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node60
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.6
      description: A CGA is a government agency, whether a CJA or a NCJA, that enters
        into an agreement with a private contractor subject to the CJIS Security Addendum.
        The CGA entering into an agreement with a contractor shall appoint an agency
        coordinator.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.7
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2
      ref_id: 3.2.7
      name: Agency Coordinator (AC)
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node62
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.7
      description: 'An AC is a staff member of the CGA who manages the agreement between
        the Contractor and agency. The AC shall be responsible for the supervision
        and integrity of the system, training and continuing education of employees
        and operators, scheduling of initial training and testing, and certification
        testing and all required reports by NCIC. The AC shall:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.7-1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.7
      ref_id: 3.2.7-1
      description: Understand the communications, records capabilities, and needs
        of the Contractor which is accessing federal and state records through or
        because of its relationship with the CGA.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.7-2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.7
      ref_id: 3.2.7-2
      description: Participate in related meetings and provide input and comments
        for system improvement.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.7-3
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.7
      ref_id: 3.2.7-3
      description: Receive information from the CGA (e.g., system updates) and disseminate
        it to appropriate Contractor employees.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.7-4
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.7
      ref_id: 3.2.7-4
      description: Maintain and update manuals applicable to the effectuation of the
        agreement, and provide them to the Contractor.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.7-5
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.7
      ref_id: 3.2.7-5
      description: "Maintain up-to-date records of Contractor\u2019s employees who\
        \ access the system, including name, date of birth, social security number,\
        \ date fingerprint card(s) submitted, date security clearance issued, and\
        \ date initially trained, tested, certified or recertified (if applicable)."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.7-6
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.7
      ref_id: 3.2.7-6
      description: Train or ensure the training of Contractor personnel. If Contractor
        personnel access NCIC, schedule the operators for testing or a certification
        exam with the CSA staff, or AC staff with permission from the CSA staff. Schedule
        new operators for the certification exam within six (6) months of assignment.
        Schedule certified operators for biennial re- certification testing within
        thirty (30) days prior to the expiration of certification. Schedule operators
        for other mandated class.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.7-7
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.7
      ref_id: 3.2.7-7
      description: The AC will not permit an untrained/untested or non-certified Contractor
        employee to access CJI or systems supporting CJI where access to CJI can be
        gained.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.7-8
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.7
      ref_id: 3.2.7-8
      description: Where appropriate, ensure compliance by the Contractor with NCIC
        validation requirements.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.7-9
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.7
      ref_id: 3.2.7-9
      description: Provide completed applicant fingerprint cards on each Contractor
        employee who accesses the system to the CGA (or, where appropriate, CSA) for
        criminal background investigation prior to such employee accessing the system.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.7-10
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.7
      ref_id: 3.2.7-10
      description: Any other responsibility for the AC promulgated by the FBI.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.8
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2
      ref_id: 3.2.8
      name: CJIS Systems Agency Information Security Officer (CSA ISO)
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node74
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.8
      description: 'The CSA ISO shall:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.8-1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.8
      ref_id: 3.2.8-1
      description: Serve as the security point of contact (POC) to the FBI CJIS Division
        ISO.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.8-2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.8
      ref_id: 3.2.8-2
      description: "Document technical compliance with the CJIS Security Policy with\
        \ the goal to assure the confidentiality, integrity, and availability of criminal\
        \ justice information to the user community throughout the CSA\u2019s user\
        \ community, to include the local level."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.8-3
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.8
      ref_id: 3.2.8-3
      description: Document and provide assistance for implementing the security-related
        controls for the Interface Agency and its users.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.8-4
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.8
      ref_id: 3.2.8-4
      description: Establish a security incident response and reporting procedure
        to discover, investigate,document, and report to the CSA, the affected criminal
        justice agency, and the FBI CJIS Division ISO major incidents that significantly
        endanger the security or integrity of CJI.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.9
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2
      ref_id: 3.2.9
      name: Local Agency Security Officer (LASO)
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node80
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.9
      description: 'Each LASO shall:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.9-1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.9
      ref_id: 3.2.9-1
      description: Identify who is using the CSA approved hardware, software, and
        firmware and ensure no unauthorized individuals or processes have access to
        the same.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.9-2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.9
      ref_id: 3.2.9-2
      description: Identify and document how the equipment is connected to the state
        system.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.9-3
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.9
      ref_id: 3.2.9-3
      description: Ensure that personnel security screening procedures are being followed
        as stated in this Policy.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.9-4
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.9
      ref_id: 3.2.9-4
      description: Ensure the approved and appropriate security measures are in place
        and working as expected.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.9-5
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.9
      ref_id: 3.2.9-5
      description: Support policy compliance and ensure the CSA ISO is promptly informed
        of security incidents.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.10
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2
      ref_id: 3.2.10
      name: FBI CJIS Division Information Security Officer (FBI CJIS ISO)
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node87
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.10
      description: 'The FBI CJIS ISO shall:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.10-1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.10
      ref_id: 3.2.10-1
      description: Maintain the CJIS Security Policy.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.10-2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.10
      ref_id: 3.2.10-2
      description: Disseminate the FBI Director approved CJIS Security Policy.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.10-3
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.10
      ref_id: 3.2.10-3
      description: "Serve as a liaison with the CSA\u2019s ISO and with other personnel\
        \ across the CJIS community and in this regard provide technical guidance\
        \ as to the intent and implementation of operational and technical policy\
        \ issues."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.10-4
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.10
      ref_id: 3.2.10-4
      description: Serve as a point-of-contact (POC) for computer incident notification
        and distribution of security alerts to the CSOs and ISOs.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.10-5
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.10
      ref_id: 3.2.10-5
      description: Assist with developing audit compliance guidelines as well as identifying
        and reconciling security-related issues.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.10-6
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.10
      ref_id: 3.2.10-6
      description: Develop and participate in information security training programs
        for the CSOs and ISOs, and provide a means by which to acquire feedback to
        measure the effectiveness and success of such training.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.10-7
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.10
      ref_id: 3.2.10-7
      description: Maintain a security policy resource center (SPRC) on FBI.gov and
        keep the CSOs and ISOs updated on pertinent information.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.11
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2
      ref_id: 3.2.11
      name: Repository Manager
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node96
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.11
      description: "The State Identification Bureau (SIB) Chief, i.e., Repository\
        \ Manager or Chief Administrator, is the designated manager of the agency\
        \ having oversight responsibility for a state\u2019s fingerprint identification\
        \ services. If both state fingerprint identification services and CJIS systems\
        \ control are managed within the same state agency, the SIB Chief and CSO\
        \ may be the same person."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.12
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2
      ref_id: 3.2.12
      name: Compact Officer
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node98
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:3.2.12
      description: Pursuant to the National Crime Prevention and Privacy Compact,
        each party state shall appoint a Compact Officer who shall ensure that Compact
        provisions and rules, procedures, and standards established by the Compact
        Council are complied with in their respective state.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4
      assessable: false
      depth: 1
      ref_id: '4'
      name: CRIMINAL JUSTICE INFORMATION AND PERSONALLY IDENTIFIABLE INFORMATION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.1
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4
      ref_id: '4.1'
      name: Criminal Justice Information (CJI)
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node101
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.1
      description: "Criminal Justice Information is the term used to refer to all\
        \ of the FBI CJIS provided data necessary for law enforcement and civil agencies\
        \ to perform their missions including, but not limited to biometric, identity\
        \ history, biographic, property, and case/incident history data. The following\
        \ categories of CJI describe the various data sets housed by the FBI CJIS\
        \ architecture:\n1. Biometric Data\u2014data derived from one or more intrinsic\
        \ physical or behavioral traits of humans typically for the purpose of uniquely\
        \ identifying individuals from within a population. Used to identify individuals,\
        \ to include: fingerprints, palm prints, iris scans, and facial recognition\
        \ data.\n2. Identity History Data\u2014textual data that corresponds with\
        \ an individual\u2019s biometric data, providing a history of criminal and/or\
        \ civil events for the identified individual.\n3. Biographic Data\u2014information\
        \ about individuals associated with a unique case, and not necessarily connected\
        \ to identity data. Biographic data does not provide a history of an individual,\
        \ only information related to a unique case.\n4. Property Data\u2014information\
        \ about vehicles and property associated with crime when accompanied by any\
        \ personally identifiable information (PII).\n5. Case/Incident History\u2014\
        information about the history of criminal incidents."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node102
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.1
      description: 'The following type of data are exempt from the protection levels
        required for CJI: transaction control type numbers (e.g., ORI, NIC, UCN, etc.)
        when not accompanied by information that reveals CJI or PII.

        The intent of the CJIS Security Policy is to ensure the protection of the
        aforementioned CJI until the information is: released to the public via authorized
        dissemination (e.g., within a court system; presented in crime reports data;
        released in the interest of public safety); purged or destroyed in accordance
        with applicable record retention rules. CJI introduced into the court system
        pursuant to a judicial proceeding that can be released to the public via a
        public records request is not subject to the CJIS Security Policy'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.1.1
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.1
      ref_id: 4.1.1
      name: Criminal History Record Information (CHRI)
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node104
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.1.1
      description: "Criminal History Record Information (CHRI), sometimes informally\
        \ referred to as \u201Crestricted data\u201D, is a subset of CJI. Due to its\
        \ comparatively sensitive nature, additional controls are required for the\
        \ access, use and dissemination of CHRI. In addition to the dissemination\
        \ restrictions outlined below, Title 28, Part 20, Code of Federal Regulations\
        \ (CFR), defines CHRI and provides the regulatory guidance for dissemination\
        \ of CHRI. While the CJIS Security Policy attempts to be architecturally independent,\
        \ the III and the NCIC are specifically identified in Title 28, Part 20, CFR,\
        \ and the NCIC Operating Manual, as associated with CHRI."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4
      ref_id: '4.2'
      name: Access, Use and Dissemination of Criminal History Record Information (CHRI),
        NCIC Restricted Files Information, and NCIC Non-Restricted Files Information
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node106
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2
      description: This section describes the requirements for the access, use and
        dissemination of CHRI, NCIC restricted files information, and NCIC non-restricted
        files information.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2.1
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2
      ref_id: 4.2.1
      name: Proper Access, Use, and Dissemination of CHRI
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node108
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2.1
      description: Information obtained from the III is considered CHRI. Rules governing
        the access, use, and dissemination of CHRI are found in Title 28, Part 20,
        CFR. The III shall be accessed only for an authorized purpose. Further, CHRI
        shall only be used for an authorized purpose consistent with the purpose for
        which III was accessed. Dissemination to another agency is authorized if (a)
        the other agency is an Authorized Recipient of such information and is being
        serviced by the accessing agency, or (b) the other agency is performing personnel
        and appointment functions for criminal justice employment applicants.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2.2
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2
      ref_id: 4.2.2
      name: Proper Access, Use, and Dissemination of NCIC Restricted Files Information
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node110
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2.2
      description: 'The NCIC hosts restricted files and non-restricted files. NCIC
        restricted files are distinguished from NCIC non-restricted files by the policies
        governing their access and use. Proper access to, use, and dissemination of
        data from restricted files shall be consistent with the access, use, and dissemination
        policies concerning the III described in Title 28, Part 20, CFR, and the NCIC
        Operating Manual. The restricted files, which shall be protected as CHRI,
        are as follows:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2.2-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node110
      ref_id: 4.2.2-1
      description: Gang Files
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2.2-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node110
      ref_id: 4.2.2-2
      description: Threat Screening Center Files
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2.2-3
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node110
      ref_id: 4.2.2-3
      description: Supervised Release Files
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2.2-4
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node110
      ref_id: 4.2.2-4
      description: National Sex Offender Registry Files
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2.2-5
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node110
      ref_id: 4.2.2-5
      description: Historical Protection Order Files of the NCIC
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2.2-6
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node110
      ref_id: 4.2.2-6
      description: Identity Theft Files
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2.2-7
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node110
      ref_id: 4.2.2-7
      description: Protective Interest Files
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2.2-8
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node110
      ref_id: 4.2.2-8
      description: Person With Information (PWI) data in the Missing Person Files
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2.2-9
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node110
      ref_id: 4.2.2-9
      description: Violent Person File
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2.2-10
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node110
      ref_id: 4.2.2-10
      description: NICS Denied Transactions File
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node121
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2.2
      description: The remaining NCIC files are considered non-restricted files.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2.3
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2
      ref_id: 4.2.3
      name: Proper Access, Use, and Dissemination of NCIC Non-Restricted Files Information
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2.3.1
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2.3
      ref_id: 4.2.3.1
      name: For Official Purposes
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node124
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2.3.1
      description: "NCIC non-restricted files are those not listed as restricted files\
        \ in Section 4.2.2. NCIC non-restricted files information may be accessed\
        \ and used for any authorized purpose consistent with the inquiring agency\u2019\
        s responsibility. Information obtained may be disseminated to (a) other government\
        \ agencies or (b) private entities authorized by law to receive such information\
        \ for any purpose consistent with their responsibilities."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2.3.2
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2.3
      ref_id: 4.2.3.2
      name: For Other Authorized Purposes
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node126
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2.3.2
      description: 'NCIC non-restricted files may be accessed for other purposes consistent
        with the resources of the inquiring agency; however, requests for bulk data
        are discouraged. Information derived from NCIC non-restricted files for other
        than law enforcement purposes can be used by authorized criminal justice personnel
        only to confirm the status of a person or property (i.e., wanted or stolen).
        An inquiring agency is authorized to charge a nominal administrative fee for
        such service. Non-restricted files information shall not be disseminated commercially.

        A response to a NCIC person inquiry may include NCIC restricted files information
        as well as NCIC non-restricted files information. Agencies shall not disseminate
        restricted files information for purposes other than law enforcement.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2.3.3
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2.3
      ref_id: 4.2.3.3
      name: CSO Authority in Other Circumstances
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node128
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2.3.3
      description: If no federal, state or local law or policy prohibition exists,
        the CSO may exercise discretion to approve or deny dissemination of NCIC non-restricted
        file information.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2.4
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2
      ref_id: 4.2.4
      name: Storage
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node130
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2.4
      description: When CHRI is stored, agencies shall establish appropriate administrative,
        technical and physical safeguards to ensure the security and confidentiality
        of the information. These records shall be stored for extended periods only
        when they are key elements for the integrity and/or utility of case files
        and/or criminal record files. See Section 5.9 for physical security controls.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2.5
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2
      ref_id: 4.2.5
      name: Justification and Penalties
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2.5.1
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2.5
      ref_id: 4.2.5.1
      name: Justification
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node133
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2.5.1
      description: In addition to the use of purpose codes and logging information,
        all users shall provide a reason for all III inquiries whenever requested
        by NCIC System Managers, CSAs, local agency administrators, or their representatives.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2.5.2
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2.5
      ref_id: 4.2.5.2
      name: Penalties
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node135
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.2.5.2
      description: Improper access, use or dissemination of CHRI and NCIC Non-Restricted
        Files information is serious and may result in administrative sanctions including,
        but not limited to, termination of services and state and federal criminal
        penalties.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.3
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4
      ref_id: '4.3'
      name: Personally Identifiable Information (PII)
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node137
      assessable: true
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:4.3
      description: "For the purposes of this document, PII is information which can\
        \ be used to distinguish or trace an individual\u2019s identity, such as name,\
        \ social security number, or biometric records, alone or when combined with\
        \ other personal or identifying information which is linked or linkable to\
        \ a specific individual, such as date and place of birth, or mother\u2019\
        s maiden name. Any FBI CJIS provided data maintained by an agency, including\
        \ but not limited to, education, financial transactions, medical history,\
        \ and criminal or employment history may include PII. A criminal history record\
        \ for example inherently contains PII as would a Law Enforcement National\
        \ Data Exchange (N-DEx) case file.\nPII shall be extracted from CJI for the\
        \ purpose of official business only. Agencies shall develop policies, based\
        \ on state and local privacy rules, to ensure appropriate controls are applied\
        \ when handling PII extracted from CJI. Due to the expansive nature of PII,\
        \ this Policy does not specify auditing, logging, or personnel security requirements\
        \ associated with the life cycle of PII."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5
      assessable: false
      depth: 1
      ref_id: '5'
      name: POLICY AND IMPLEMENTATION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5
      ref_id: '5.1'
      name: 'Policy Area 1: Information Exchange Agreements'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node140
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5
      description: The information shared through communication mediums shall be protected
        with appropriate security safeguards. The agreements established by entities
        sharing information across systems and communications mediums are vital to
        ensuring all parties fully understand and agree to a set of security standards.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.1
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node140
      ref_id: 5.1.1
      name: Information Exchange
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node142
      assessable: true
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node140
      description: Before exchanging CJI, agencies shall put formal agreements in
        place that specify security controls. The exchange of information may take
        several forms including electronic mail, instant messages, web services, facsimile,
        hard copy, and information systems sending, receiving and storing CJI.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node143
      assessable: true
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node140
      description: Information exchange agreements outline the roles, responsibilities,
        and data ownership between agencies and any external parties. Information
        exchange agreements for agencies sharing CJI data that is sent to and/or received
        from the FBI CJIS shall specify the security controls and conditions described
        in this document.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node144
      assessable: true
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node140
      description: Information exchange agreements shall be supported by documentation
        committing both parties to the terms of information exchange. As described
        in subsequent sections, different agreements and policies apply, depending
        on whether the parties involved are CJAs or NCJAs. See Appendix D for examples
        of Information Exchange Agreements.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node145
      assessable: true
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node140
      description: There may be instances, on an ad-hoc basis, where CJI is authorized
        for further dissemination to Authorized Recipients not covered by an information
        exchange agreement with the releasing agency. In these instances the dissemination
        of CJI is considered to be secondary dissemination. Law Enforcement and civil
        agencies shall have a local policy to validate a requestor of CJI as an authorized
        recipient before disseminating CJI. See Section 5.1.3 for secondary dissemination
        guidance.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.1.1
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node145
      ref_id: 5.1.1.1
      name: Information Handling
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node147
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.1.1
      description: Procedures for handling and storage of information shall be established
        to protect that information from unauthorized disclosure, alteration or misuse.
        Using the requirements in this Policy as a starting point, the procedures
        shall apply to the handling, processing, storing, and communication of CJI.
        These procedures apply to the exchange of CJI no matter the form of exchange.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node148
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.1.1
      description: "The policies for information handling and protection also apply\
        \ to using CJI shared with or received from FBI CJIS for noncriminal justice\
        \ purposes. In general, a noncriminal justice purpose includes the use of\
        \ criminal history records for purposes authorized by federal or state law\
        \ other than purposes relating to the administration of criminal justice,\
        \ including \u2013 but not limited to -employment suitability, licensing determinations,\
        \ immigration and naturalization matters, and national security clearances."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.1.2
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node145
      ref_id: 5.1.1.2
      name: State and Federal Agency User Agreements
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node150
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.1.2
      description: "Each CSA head or SIB Chief shall execute a signed written user\
        \ agreement with the FBI CJIS Division stating their willingness to demonstrate\
        \ conformity with this Policy before accessing and participating in CJIS records\
        \ information programs. This agreement shall include the standards and sanctions\
        \ governing utilization of CJIS systems. As coordinated through the particular\
        \ CSA or SIB Chief, each Interface Agency shall also allow the FBI to periodically\
        \ test the ability to penetrate the FBI\u2019s network through the external\
        \ network connection or system. All user agreements with the FBI CJIS Division\
        \ shall be coordinated with the CSA head."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.1.3
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node145
      ref_id: 5.1.1.3
      name: Criminal Justice Agency User Agreements
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node152
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.1.3
      description: 'Any CJA receiving access to CJI shall enter into a signed written
        agreement with the appropriate signatory authority of the CSA providing the
        access. The written agreement shall specify the FBI CJIS systems and services
        to which the agency will have access, and the FBI CJIS Division policies to
        which the agency must adhere. These agreements shall include:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.1.3-1
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node152
      ref_id: 5.1.1.3-1
      description: Audit.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.1.3-2
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node152
      ref_id: 5.1.1.3-2
      description: Dissemination.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.1.3-3
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node152
      ref_id: 5.1.1.3-3
      description: Hit confirmation.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.1.3-4
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node152
      ref_id: 5.1.1.3-4
      description: Logging.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.1.3-5
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node152
      ref_id: 5.1.1.3-5
      description: Quality Assurance (QA).
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.1.3-6
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node152
      ref_id: 5.1.1.3-6
      description: Screening (Pre-Employment).
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.1.3-7
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node152
      ref_id: 5.1.1.3-7
      description: Security.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.1.3-8
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node152
      ref_id: 5.1.1.3-8
      description: Timeliness.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.1.3-9
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node152
      ref_id: 5.1.1.3-9
      description: Training.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.1.3-10
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node152
      ref_id: 5.1.1.3-10
      description: Use of the system.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.1.3-11
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node152
      ref_id: 5.1.1.3-11
      description: Validation.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.1.4
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node145
      ref_id: 5.1.1.4
      name: Interagency and Management Control Agreements
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node165
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.1.4
      description: A NCJA (government) designated to perform criminal justice functions
        for a CJA shall be eligible for access to the CJI. Access shall be permitted
        when such designation is authorized pursuant to executive order, statute,
        regulation, or interagency agreement. The NCJA shall sign and execute a management
        control agreement (MCA) with the CJA, which stipulates management control
        of the criminal justice function remains solely with the CJA. The MCA may
        be a separate document or included with the language of an interagency agreement.
        An example of an NCJA (government) is a city information technology (IT) department.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.1.5
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node145
      ref_id: 5.1.1.5
      name: Private Contractor User Agreements and CJIS Security Addendum
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node167
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.1.5
      description: The CJIS Security Addendum is a uniform addendum to an agreement
        between the government agency and a private contractor, approved by the Attorney
        General of the United States, which specifically authorizes access to CHRI,
        limits the use of the information to the purposes for which it is provided,
        ensures the security and confidentiality of the information is consistent
        with existing regulations and the CJIS Security Policy, provides for sanctions,
        and contains such other provisions as the Attorney General may require.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node168
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.1.5
      description: Private contractors who perform criminal justice functions shall
        meet the same training and certification criteria required by governmental
        agencies performing a similar function, and shall be subject to the same extent
        of audit review as are local user agencies. All private contractors who perform
        criminal justice functions shall acknowledge, via signing of the CJIS Security
        Addendum Certification page, and abide by all aspects of the CJIS Security
        Addendum. The CJIS Security Addendum is presented in Appendix H. Modifications
        to the CJIS Security Addendum shall be enacted only by the FBI.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.1.5-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.1.5
      ref_id: 5.1.1.5-1
      description: "Private contractors designated to perform criminal justice functions\
        \ for a CJA shall be eligible for access to CJI. Access shall be permitted\
        \ pursuant to an agreement which specifically identifies the agency\u2019\
        s purpose and scope of providing services for the administration of criminal\
        \ justice. The agreement between the CJA and the private contractor shall\
        \ incorporate the CJIS Security Addendum approved by the Director of the FBI,\
        \ acting for the U.S. Attorney General, as referenced in Title 28 CFR 20.33\
        \ (a)(7)."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.1.5-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.1.5
      ref_id: 5.1.1.5-2
      description: "Private contractors designated to perform criminal justice functions\
        \ on behalf of a NCJA (government) shall be eligible for access to CJI. Access\
        \ shall be permitted pursuant to an agreement which specifically identifies\
        \ the agency\u2019s purpose and scope of providing services for the administration\
        \ of criminal justice. The agreement between the NCJA and the private contractor\
        \ shall incorporate the CJIS Security Addendum approved by the Director of\
        \ the FBI, acting for the U.S. Attorney General, as referenced in Title 28\
        \ CFR 20.33 (a)(7)."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.1.6
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node145
      ref_id: 5.1.1.6
      name: Agency User Agreements
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node172
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.1.6
      description: A NCJA (public) designated to request civil fingerprint-based background
        checks, with the full consent of the individual to whom a background check
        is taking place, for noncriminal justice functions, shall be eligible for
        access to CJI. Access shall be permitted when such designation is authorized
        pursuant to federal law or state statute approved by the U.S. Attorney General.
        A NCJA (public) receiving access to CJI shall enter into a signed written
        agreement with the appropriate signatory authority of the CSA/SIB providing
        the access. An example of a NCJA (public) is a county school board.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node173
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.1.6
      description: A NCJA (private) designated to request civil fingerprint-based
        background checks, with the full consent of the individual to whom a background
        check is taking place, for noncriminal justice functions, shall be eligible
        for access to CJI. Access shall be permitted when such designation is authorized
        pursuant to federal law or state statute approved by the U.S. Attorney General.
        A NCJA (private) receiving access to CJI shall enter into a signed written
        agreement with the appropriate signatory authority of the CSA, SIB, or authorized
        agency providing the access. An example of a NCJA (private) is a local bank.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node174
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.1.6
      description: "All NCJAs accessing CJI shall be subject to all pertinent areas\
        \ of the CJIS Security Policy (see Appendix J for supplemental guidance).\
        \ Each NCJA that directly accesses FBI CJI shall also allow the FBI to periodically\
        \ test the ability to penetrate the FBI\u2019s network through the external\
        \ network connection or system."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.1.7
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node145
      ref_id: 5.1.1.7
      name: Outsourcing Standards for Channelers
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node176
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.1.7
      description: Channelers designated to request civil fingerprint-based background
        checks or noncriminal justice ancillary functions on behalf of a NCJA (public)
        or NCJA (private) for noncriminal justice functions shall be eligible for
        access to CJI. Access shall be permitted when such designation is authorized
        pursuant to federal law or state statute approved by the U.S. Attorney General.
        All Channelers accessing CJI shall be subject to the terms and conditions
        described in the Compact Council Security and Management Control Outsourcing
        Standard. Each Channeler that directly accesses CJI shall also allow the FBI
        to conduct periodic penetration testing.Channelers leveraging CJI to perform
        civil functions on behalf of an Authorized Recipient shall meet the same training
        and certification criteria required by governmental agencies performing a
        similar function, and shall be subject to the same extent of audit review
        as are local user agencies.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.1.8
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node145
      ref_id: 5.1.1.8
      name: Outsourcing Standards for Non-Channelers
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node178
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.1.8
      description: 'Contractors designated to perform noncriminal justice ancillary
        functions on behalf of a NCJA (public) or NCJA (private) for noncriminal justice
        functions shall be eligible for access to CJI.

        Access shall be permitted when such designation is authorized pursuant to
        federal law or state statute approved by the U.S. Attorney General. All contractors
        accessing CJI shall be subject to the terms and conditions described in the
        Compact Council Outsourcing Standard for Non- Channelers. Contractors leveraging
        CJI to perform civil functions on behalf of an Authorized Recipient shall
        meet the same training and certification criteria required by governmental
        agencies performing a similar function, and shall be subject to the same extent
        of audit review as are local user agencies.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.2
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node140
      ref_id: 5.1.2
      name: Monitoring, Review, and Delivery of Services
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node180
      assessable: true
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node140
      description: As specified in the interagency agreements, MCAs, and contractual
        agreements with private contractors, the services, reports and records provided
        by the service provider shall be regularly monitored and reviewed. The CJA,
        authorized agency, or FBI shall maintain sufficient overall control and visibility
        into all security aspects to include, but not limited to, identification of
        vulnerabilities and information security incident reporting/response. The
        incident reporting/response process used by the service provider shall conform
        to the incident reporting/response specifications provided in this Policy.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.2.1
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node180
      ref_id: 5.1.2.1
      name: Managing Changes to Service Providers
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node182
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.2.1
      description: Any changes to services provided by a service provider shall be
        managed by the CJA, authorized agency, or FBI. This includes provision of
        services, changes to existing services, and new services.Evaluation of the
        risks to the agency shall be undertaken based on the criticality of the data,
        system, and the impact of the change.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.3
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node140
      ref_id: 5.1.3
      name: Secondary Dissemination
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node184
      assessable: true
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node140
      description: "If CHRI is released to another authorized agency, and that agency\
        \ was not part of the releasing agency\u2019s primary information exchange\
        \ agreement(s), the releasing agency shall log such dissemination."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.1.4
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node140
      ref_id: 5.1.4
      name: Secondary Dissemination of Non-CHRI CJI
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node186
      assessable: true
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node140
      description: If CJI does not contain CHRI and is not part of an information
        exchange agreement then it does not need to be logged. Dissemination shall
        conform to the local policy validating the requestor of the CJI as an employee
        and/or contractor of a law enforcement agency or civil agency requiring the
        CJI to perform their mission or a member of the public receiving CJI via authorized
        dissemination.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.2
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5
      ref_id: '5.2'
      name: AWARENESS AND TRAINING (AT)
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-1
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.2
      ref_id: AT-1
      name: POLICY AND PROCEDURES
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-1-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-1
      ref_id: AT-1-a
      description: 'Develop, document, and disseminate to all personnel when their
        unescorted logical or physical access to any information system results in
        the ability, right, or privilege to view,

        modify, or make use of unencrypted CJI:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-1-a-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-1-a
      ref_id: AT-1-a-1
      description: 'Organization-level awareness and training policy that:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-1-a-1-a
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-1-a-1
      ref_id: AT-1-a-1-a
      description: 'Addresses purpose, scope, roles, responsibilities, management
        commitment,

        coordination among organizational entities, and compliance; and'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-1-a-1-b
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-1-a-1
      ref_id: AT-1-a-1-b
      description: 'Is consistent with applicable laws, executive orders, directives,
        regulations, policies,

        standards, and guidelines; and'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-1-a-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-1-a
      ref_id: AT-1-a-2
      description: Procedures to facilitate the implementation of the awareness and
        training policy and the associated awareness and training controls;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-1-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-1
      ref_id: AT-1-b
      description: Designate organizational personnel with information security awareness
        and training responsibilities to manage the development, documentation, and
        dissemination of the awareness and training policy and procedures; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-1-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-1
      ref_id: AT-1-c
      description: 'Review and update the current awareness and training:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-1-c-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-1-c
      ref_id: AT-1-c-1
      description: Policy annually and following changes in the information system
        operating environment, when security incidents occur, or when changes to the
        CJIS Security Policy are made; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-1-c-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-1-c
      ref_id: AT-1-c-2
      description: Procedures annually and following changes in the information system
        operating environment, when security incidents occur, or when changes to the
        CJIS Security Policy are made.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node198
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-1
      description: 'Discussion: Awareness and training policy and procedures address
        the controls in the AT family that are implemented within systems and organizations.
        The risk management strategy is an important factor in establishing such policies
        and procedures. Policies and procedures contribute to security and privacy
        assurance. Therefore, it is important that security and privacy programs collaborate
        on the development of awareness and training policy and procedures. Security
        and privacy program policies and procedures at the organization level are
        preferable, in general, and may obviate the need for mission- or system-specific
        policies and procedures. The policy can be included as part of the general
        security and privacy policy or be represented by multiple policies that reflect
        the complex nature of organizations. Procedures can be established for security
        and privacy programs, for mission or business processes, and for systems,
        if needed. Procedures describe how the policies or controls are implemented
        and can be directed at the individual or role that is the object of the procedure.
        Procedures can be documented in system security and privacy plans or in one
        or more separate documents. Events that may precipitate an update to awareness
        and training policy and procedures include assessment or audit findings, security
        incidents or breaches, or changes in applicable laws, executive orders, directives,
        regulations, policies, standards, and guidelines. Simply restating controls
        does not constitute an organizational policy or procedure.

        Related Controls: PS-8, SI-12.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-2
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.2
      ref_id: AT-2
      name: LITERACY TRAINING AND AWARENESS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-2-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-2
      ref_id: AT-2-a
      description: 'Provide security and privacy literacy training to system users
        (including managers, senior executives, and contractors):'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-2-a-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-2-a
      ref_id: AT-2-a-1
      description: As part of initial training for new users prior to accessing CJI
        and annually thereafter; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-2-a-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-2-a
      ref_id: AT-2-a-2
      description: When required by system changes or within 30 days of any security
        event for individuals involved in the event;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-2-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-2
      ref_id: AT-2-b
      description: 'Employ one or more of the following techniques to increase the
        security and privacy awareness of system users:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-2-b-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-2-b
      ref_id: AT-2-b-1
      description: Displaying posters
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-2-b-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-2-b
      ref_id: AT-2-b-2
      description: Offering supplies inscribed with security and privacy reminders
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-2-b-3
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-2-b
      ref_id: AT-2-b-3
      description: Displaying logon screen messages
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-2-b-4
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-2-b
      ref_id: AT-2-b-4
      description: Generating email advisories or notices from organizational officials
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-2-b-5
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-2-b
      ref_id: AT-2-b-5
      description: Conducting awareness events
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-2-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-2
      ref_id: AT-2-c
      description: Update literacy training and awareness content annually and following
        changes in the information system operating environment, when security incidents
        occur, or when changes are made in the CJIS Security Policy; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-2-d
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-2
      ref_id: AT-2-d
      description: Incorporate lessons learned from internal or external security
        incidents or breaches into literacy training and awareness techniques.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node211
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-2
      description: 'Discussion: Organizations provide basic and advanced levels of
        literacy training to system users, including measures to test the knowledge
        level of users. Organizations determine the content of literacy training and
        awareness based on specific organizational requirements, the systems to which
        personnel have authorized access, and work environments (e.g., telework).
        The content includes an understanding of the need for security and privacy
        as well as actions by users to maintain security and personal privacy and
        to respond to suspected incidents. The content addresses the need for operations
        security and the handling of personally identifiable information. Awareness
        techniques include displaying posters, offering supplies inscribed with security
        and privacy reminders, displaying logon screen messages, generating email
        advisories or notices from organizational officials, and conducting awareness
        events. Literacy training after the initial training described in AT-2a.1
        is conducted at a minimum frequency consistent with applicable laws, directives,
        regulations, and policies. Subsequent literacy training may be satisfied by
        one or more short ad hoc sessions and include topical information on recent
        attack schemes, changes to organizational security and privacy policies, revised
        security and privacy expectations, or a subset of topics from the initial
        training. Updating literacy training and awareness content on a regular basis
        helps to ensure that the content remains relevant. Events that may precipitate
        an update to literacy training and awareness content include, but are not
        limited to, assessment or audit findings, security incidents or breaches,
        or changes in applicable laws, executive orders, directives, regulations,
        policies, standards, and guidelines.

        Related Controls: AC-3, AC-17, AC-22, AT-3, AT-4, CP-3, IA-4, IR-2, IR-7,
        PL-4, PS-7, SA-8.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-2(2)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-2
      ref_id: AT-2(2)
      name: LITERACY TRAINING AND AWARENESS | INSIDER THREAT
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node213
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-2(2)
      description: Provide literacy training on recognizing and reporting potential
        indicators of insider threat.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node214
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-2(2)
      description: 'Discussion: Potential indicators and possible precursors of insider
        threat can include behaviors such as inordinate, long-term job dissatisfaction;
        attempts to gain access to information not required for job performance; unexplained
        access to financial resources; bullying or harassment of fellow employees;
        workplace violence; and other serious violations of policies, procedures,
        directives, regulations, rules, or practices. Literacy training includes how
        to communicate the concerns of employees and management regarding potential
        indicators of insider threat through channels established by the organization
        and in accordance with established policies and procedures. Organizations
        may consider tailoring insider threat awareness topics to the role. For example,
        training for managers may be focused on changes in the behavior of team members,
        while training for employees may be focused on more general observations.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-2(3)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-2
      ref_id: AT-2(3)
      name: LITERACY TRAINING AND AWARENESS | SOCIAL ENGINEERING AND MINING
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node216
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-2(3)
      description: Provide literacy training on recognizing and reporting potential
        and actual instances of social engineering and social mining.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node217
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-2(3)
      description: 'Discussion: Social engineering is an attempt to trick an individual
        into revealing information or taking an action that can be used to breach,
        compromise, or otherwise adversely impact a system. Social engineering includes
        phishing, pretexting, impersonation, baiting, quid pro quo, thread-jacking,
        social media exploitation, and tailgating. Social mining is an attempt to
        gather information about the organization that may be used to support future
        attacks. Literacy training includes information on how to communicate the
        concerns of employees and management regarding potential and actual instances
        of social engineering and data mining through organizational channels based
        on established policies and procedures.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.2
      ref_id: AT-3
      name: ROLE-BASED TRAINING
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3
      ref_id: AT-3-a
      description: 'Provide role-based security and privacy training to personnel
        with the following roles and responsibilities:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node220
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3
      description: "\u2022 All individuals with unescorted access to a physically\
        \ secure location;"
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node221
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3
      description: "\u2022 General User: A user, but not a process, who is authorized\
        \ to use an information system;"
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node222
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3
      description: "\u2022 Privileged User: A user that is authorized (and, therefore,\
        \ trusted) to perform security-\nrelevant functions that general users are\
        \ not authorized to perform;"
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node223
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3
      description: "\u2022 Organizational Personnel with Security Responsibilities:\
        \ Personnel with the responsibility to ensure the confidentiality, integrity,\
        \ and availability of CJI and the implementation of technology in a manner\
        \ compliant with the CJISSECPOL."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-a-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node223
      ref_id: AT-3-a-1
      description: Before authorizing access to the system, information, or performing
        assigned duties, and annually thereafter; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-a-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node223
      ref_id: AT-3-a-2
      description: When required by system changes.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3
      ref_id: AT-3-b
      description: Update role-based training content annually and following audits
        of the CSA and local agencies; changes in the information system operating
        environment; security incidents; or when changes are made to the CJIS Security
        Policy;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3
      ref_id: AT-3-c
      description: Incorporate lessons learned from internal or external security
        incidents or breaches into role-based training;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3
      ref_id: AT-3-d
      description: 'Incorporate the minimum following topics into the appropriate
        role-based training content:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d
      ref_id: AT-3-d-1
      description: All individuals with unescorted access to a physically secure location
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-1-a
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-1
      ref_id: AT-3-d-1-a
      description: Access, Use and Dissemination of Criminal History Record Information
        (CHRI), NCIC Restricted Files Information, and NCIC Non-Restricted Files Information
        Penalties
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-1-b
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-1
      ref_id: AT-3-d-1-b
      description: Reporting Security Events
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-1-c
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-1
      ref_id: AT-3-d-1-c
      description: Incident Response Training
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-1-d
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-1
      ref_id: AT-3-d-1-d
      description: System Use Notification
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-1-e
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-1
      ref_id: AT-3-d-1-e
      description: Physical Access Authorizations
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-1-f
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-1
      ref_id: AT-3-d-1-f
      description: Physical Access Control
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-1-g
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-1
      ref_id: AT-3-d-1-g
      description: Monitoring Physical Access
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-1-h
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-1
      ref_id: AT-3-d-1-h
      description: Visitor Control
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-1-i
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-1
      ref_id: AT-3-d-1-i
      description: Personnel Sanctions
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d
      ref_id: AT-3-d-2
      description: 'General User: A user, but not a process, who is authorized to
        use an information system.

        In addition to AT-3 (d) (1) above, include the following topics:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2-a
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2
      ref_id: AT-3-d-2-a
      description: Criminal Justice Information
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2-b
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2
      ref_id: AT-3-d-2-b
      description: Proper Access, Use, and Dissemination of NCIC Non-Restricted Files
        Information
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2-c
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2
      ref_id: AT-3-d-2-c
      description: Personally Identifiable Information
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2-d
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2
      ref_id: AT-3-d-2-d
      description: Information Handling
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2-e
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2
      ref_id: AT-3-d-2-e
      description: Media Storage
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2-f
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2
      ref_id: AT-3-d-2-f
      description: Media Access
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2-g
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2
      ref_id: AT-3-d-2-g
      description: Audit Monitoring, Analysis, and Reporting
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2-h
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2
      ref_id: AT-3-d-2-h
      description: Access Enforcement
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2-i
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2
      ref_id: AT-3-d-2-i
      description: Least Privilege
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2-j
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2
      ref_id: AT-3-d-2-j
      description: System Access Control
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2-k
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2
      ref_id: AT-3-d-2-k
      description: Access Control Criteria
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2-l
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2
      ref_id: AT-3-d-2-l
      description: System Use Notification
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2-m
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2
      ref_id: AT-3-d-2-m
      description: Session Lock
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2-n
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2
      ref_id: AT-3-d-2-n
      description: Personally Owned Information Systems
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2-o
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2
      ref_id: AT-3-d-2-o
      description: Password
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2-p
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2
      ref_id: AT-3-d-2-p
      description: Access Control for Display Medium
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2-q
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2
      ref_id: AT-3-d-2-q
      description: Encryption
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2-r
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2
      ref_id: AT-3-d-2-r
      description: Malicious Code Protection
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2-s
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2
      ref_id: AT-3-d-2-s
      description: Spam and Spyware Protection
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2-t
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2
      ref_id: AT-3-d-2-t
      description: Cellular Devices
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2-u
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2
      ref_id: AT-3-d-2-u
      description: Mobile Device Management
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2-v
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2
      ref_id: AT-3-d-2-v
      description: Wireless Device Risk Mitigations
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2-w
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2
      ref_id: AT-3-d-2-w
      description: Wireless Device Malicious Code Protection
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2-x
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2
      ref_id: AT-3-d-2-x
      description: Literacy Training and Awareness/Social Engineering and Mining
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2-y
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2
      ref_id: AT-3-d-2-y
      description: Identification and Authentication (Organizational Users)
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2-z
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-2
      ref_id: AT-3-d-2-z
      description: Media Protection
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-3
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d
      ref_id: AT-3-d-3
      description: 'Privileged User: A user that is authorized (and, therefore, trusted)
        to perform security- relevant functions that general users are not authorized
        to perform. In addition to AT-3 (d) (1) and (2) above, include the following
        topics:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-3-a
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-3
      ref_id: AT-3-d-3-a
      description: Access Control
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-3-b
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-3
      ref_id: AT-3-d-3-b
      description: System and Communications Protection and Information Integrity
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-3-c
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-3
      ref_id: AT-3-d-3-c
      description: Patch Management
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-3-d
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-3
      ref_id: AT-3-d-3-d
      description: "Data backup and storage\u2014centralized or decentralized approach"
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-3-e
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-3
      ref_id: AT-3-d-3-e
      description: Most recent changes to the CJIS Security Policy
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-4
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d
      ref_id: AT-3-d-4
      description: 'Organizational Personnel with Security Responsibilities: Personnel
        with the responsibility to ensure the confidentiality, integrity, and availability
        of CJI and the implementation of technology in a manner compliant with the
        CJISSECPOL. In addition to AT-3 (d) (1), (2), and (3) above, include the following
        topics:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-4-a
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-4
      ref_id: AT-3-d-4-a
      description: Local Agency Security Officer Role
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-4-b
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-4
      ref_id: AT-3-d-4-b
      description: Authorized Recipient Security Officer Role2
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-4-c
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-4
      ref_id: AT-3-d-4-c
      description: Additional state/local/tribal/territorial or federal agency roles
        and responsibilities
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-4-d
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-4
      ref_id: AT-3-d-4-d
      description: Summary of audit findings from previous state audits of local agencies
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-4-e
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3-d-4
      ref_id: AT-3-d-4-e
      description: Findings from the last FBI CJIS Division audit
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node278
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3
      description: "Discussion: Organizations determine the content of training based\
        \ on the assigned roles and responsibilities of individuals as well as the\
        \ security and privacy requirements of organizations and the systems to which\
        \ personnel have authorized access, including technical training specifically\
        \ tailored for assigned duties. Roles that may require role-based training\
        \ include senior leaders or management officials (e.g., head of agency/chief\
        \ executive officer, chief information officer, senior accountable official\
        \ for risk management, senior agency information security officer, senior\
        \ agency official for privacy), system owners; authorizing officials; system\
        \ security officers; privacy officers; acquisition and procurement officials;\
        \ enterprise architects; systems engineers; software developers; systems security\
        \ engineers; privacy engineers; system, network, and database administrators;\
        \ auditors; personnel conducting configuration management activities; personnel\
        \ performing verification and validation activities; personnel with access\
        \ to system-level software; control assessors; personnel with contingency\
        \ planning and incident response duties; personnel with privacy management\
        \ responsibilities; and personnel with access to personally identifiable information.\
        \ Comprehensive role-based training addresses management, operational, and\
        \ technical roles and responsibilities covering physical, personnel, and technical\
        \ controls. Role-based training also includes policies, procedures, tools,\
        \ methods, and artifacts for the security and privacy roles defined. Organizations\
        \ provide the training necessary for individuals to fulfill their responsibilities\
        \ related to operations and supply chain risk management within the context\
        \ of organizational security and privacy programs. Role-based training also\
        \ applies to contractors who provide services to federal agencies. Types of\
        \ training include web-based and computer-based training, classroom-style\
        \ training, and hands-on training (including micro-training). Updating role-based\
        \ training on a regular basis helps to ensure that the content remains relevant\
        \ and effective. Events that may precipitate an update to role-based training\
        \ content include, but are not limited to, assessment or audit findings, security\
        \ incidents or breaches, or changes in applicable laws, executive orders,\
        \ directives, regulations, policies, standards, and guidelines. \nRelated\
        \ Controls: AC-3, AC-17, AC-22, AT-2, AT-4, CP-3, IR-2, IR-4, IR-7, PL-4,\
        \ PS-7, PS-9,\nSA-3, SA-8, SA-11, SR-5, SR-6, SR-11."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3(5)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3
      ref_id: AT-3(5)
      name: ROLE-BASED TRAINING | PROCESSING PERSONALLY IDENTIFIABLE INFORMATION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node280
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3(5)
      description: Provide all personnel when their unescorted logical or physical
        access to any information system results in the ability, right, or privilege
        to view, modify, or make use of unencrypted CJI with initial and annual training
        in the employment and operation of personally identifiable information processing
        and transparency controls.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node281
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-3(5)
      description: "Discussion: Personally identifiable information processing and\
        \ transparency controls include the organization\u2019s authority to process\
        \ personally identifiable information and personally identifiable information\
        \ processing purposes. Role-based training for federal agencies addresses\
        \ the types of information that may constitute personally identifiable information\
        \ and the risks, considerations, and obligations associated with its processing.\
        \ Such training also considers the authority to process personally identifiable\
        \ information documented in privacy policies and notices, system of records\
        \ notices, computer matching agreements and notices, privacy impact assessments,[PRIVACT]\
        \ statements, contracts, information sharing agreements, memoranda of understanding,\
        \ and/or other documentation."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-4
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.2
      ref_id: AT-4
      name: TRAINING RECORDS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-4-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-4
      ref_id: AT-4-a
      description: Document and monitor information security and privacy training
        activities, including security and privacy awareness training and specific
        role-based security and privacy training;and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-4-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-4
      ref_id: AT-4-b
      description: Retain individual training records for a minimum of three years.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node285
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:at-4
      description: 'Discussion: Documentation for specialized training may be maintained
        by individual supervisors at the discretion of the organization. The National
        Archives and Records Administration provides guidance on records retention
        for federal agencies. Retention of records for three (3) years accounts for
        a triennial audit cycle.

        Related Controls: AT-2, AT-3, CP-3, IR-2, SI-12.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.3
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5
      ref_id: '5.3'
      name: INCIDENT RESPONSE (IR)
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-1
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.3
      ref_id: IR-1
      name: POLICY AND PROCEDURES
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-1-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-1
      ref_id: IR-1-a
      description: 'Develop, document, and disseminate to all personnel when their
        unescorted logical or physical access to any information system results in
        the ability, right, or privilege to view, modify, or make use of unencrypted
        CJI:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-1-a-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-1-a
      ref_id: IR-1-a-1
      description: 'Agency-level incident response policy that:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-1-a-1-a
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-1-a-1
      ref_id: IR-1-a-1-a
      description: Addresses purpose, scope, roles, responsibilities, management commitment,
        coordination among organizational entities, and compliance; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-1-a-1-b
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-1-a-1
      ref_id: IR-1-a-1-b
      description: Is consistent with applicable laws, executive orders, directives,
        regulations, policies, standards, and guidelines; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-1-a-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-1-a
      ref_id: IR-1-a-2
      description: Procedures to facilitate the implementation of the incident response
        policy and the associated incident response controls;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-1-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-1
      ref_id: IR-1-b
      description: Designate an individual with security responsibilities to manage
        the development, documentation, and dissemination of the incident response
        policy and procedures; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-1-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-1
      ref_id: IR-1-c
      description: 'Review and update the current incident response:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-1-c-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-1-c
      ref_id: IR-1-c-1
      description: Policy annually and following any security incidents involving
        unauthorized access to CJI or systems used to process, store, or transmit
        CJI; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-1-c-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-1-c
      ref_id: IR-1-c-2
      description: Procedures annually and following any security incidents involving
        unauthorized access to CJI or systems used to process, store, or transmit
        CJI.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node297
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-1
      description: 'Discussion: Incident response policy and procedures address the
        controls in the IR family that are implemented within systems and organizations.
        The risk management strategy is an important factor in establishing such policies
        and procedures. Policies and procedures contribute to security and privacy
        assurance. Therefore, it is important that security and privacy programs collaborate
        on the development of incident response policy and procedures. Security and
        privacy program policies and procedures at the organization level are preferable,
        in general, and may obviate the need for mission- or system-specific policies
        and procedures. The policy can be included as part of the general security
        and privacy policy or be represented by multiple policies that reflect the
        complex nature of organizations. Procedures can be established for security
        and privacy programs, for mission or business processes, and for systems,
        if needed. Procedures describe how the policies or controls are implemented
        and can be directed at the individual or role that is the object of the procedure.
        Procedures can be documented in system security and privacy plans or in one
        or more separate documents. Events that may precipitate an update to incident
        response policy and procedures include assessment or audit findings, security
        incidents or breaches, or changes in laws, executive orders, directives, regulations,
        policies, standards, and guidelines. Simply restating controls does not constitute
        an organizational policy or procedure.

        Related Controls: PS-8, SI-12.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-2
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.3
      ref_id: IR-2
      name: INCIDENT RESPONSE TRAINING
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-2-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-2
      ref_id: IR-2-a
      description: 'Provide incident response training to system users consistent
        with assigned roles and responsibilities:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-2-a-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-2-a
      ref_id: IR-2-a-1
      description: Prior to assuming an incident response role or responsibility or
        acquiring system access;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-2-a-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-2-a
      ref_id: IR-2-a-2
      description: When required by system changes; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-2-a-3
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-2-a
      ref_id: IR-2-a-3
      description: Annually thereafter; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-2-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-2
      ref_id: IR-2-b
      description: Review and update incident response training content annually and
        following any security incidents involving unauthorized access to CJI or systems
        used to process, store, or transmit CJI.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node304
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-2
      description: 'Discussion: Incident response training is associated with the
        assigned roles and responsibilities of organizational personnel to ensure
        that the appropriate content and level of detail are included in such training.
        For example, users may only need to know who to call or how to recognize an
        incident; system administrators may require additional training on how to
        handle incidents; and incident responders may receive more specific training
        on forensics, data collection techniques, reporting, system recovery, and
        system restoration. Incident response training includes user training in identifying
        and reporting suspicious activities from external and internal sources.

        Incident response training for users may be provided as part of AT-2 or AT-3.

        Events that may precipitate an update to incident response training content
        include, but are not limited to, incident response plan testing or response
        to an actual incident (lessons learned), assessment or audit findings, or
        changes in applicable laws, executive orders, directives, regulations, policies,
        standards, and guidelines.

        Related Controls: AT-2, AT-3, AT-4, CP-3, IR-3, IR-4, IR-8.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-2(3)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-2
      ref_id: IR-2(3)
      name: INCIDENT RESPONSE TRAINING | BREACH
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node306
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-2(3)
      description: "Provide incident response training on how to identify and respond\
        \ to a breach, including the organization\u2019s process for reporting a breach."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node307
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-2(3)
      description: 'Discussion: For federal agencies, an incident that involves personally
        identifiable information is considered a breach. A breach results in the loss
        of control, compromise, unauthorized disclosure, unauthorized acquisition,
        or a similar occurrence where a person other than an authorized user accesses
        or potentially accesses personally identifiable information or an authorized
        user accesses or potentially accesses such information for other than authorized
        purposes. The incident response training emphasizes the obligation of individuals
        to report both confirmed and suspected breaches involving information in any
        medium or form, including paper, oral, and electronic. Incident response training
        includes tabletop exercises that simulate a breach.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-3
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.3
      ref_id: IR-3
      name: INCIDENT RESPONSE TESTING
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node309
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-3
      description: 'Test the effectiveness of the incident response capability for
        the system annually using the following tests: tabletop or walk-through exercises;
        simulations; or other agency appropriate tests.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node310
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-3
      description: 'Discussion: Organizations test incident response capabilities
        to determine their effectiveness and identify potential weaknesses or deficiencies.
        Incident response testing includes the use of checklists, walk-through or
        tabletop exercises, and simulations (parallel or full interrupt). Incident
        response testing can include a determination of the effects on organizational
        operations and assets and individuals due to incident response. The use of
        qualitative and quantitative data aids in determining the effectiveness of
        incident response processes.

        Related Controls: CP-3, CP-4, IR-2, IR-4, IR-8.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-3(2)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-3
      ref_id: IR-3(2)
      name: INCIDENT RESPONSE TESTING | COORDINATION WITH RELATED PLANS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node312
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-3(2)
      description: Coordinate incident response testing with organizational elements
        responsible for related plans.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node313
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-3(2)
      description: 'Discussion: Organizational plans related to incident response
        testing include business continuity plans, disaster recovery plans, continuity
        of operations plans, contingency plans, crisis communications plans, critical
        infrastructure plans, and occupant emergency plans.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-4
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.3
      ref_id: IR-4
      name: INCIDENT HANDLING
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-4-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-4
      ref_id: IR-4-a
      description: Implement an incident handling capability for incidents that is
        consistent with the incident response plan and includes preparation, detection
        and analysis, containment, eradication, and recovery;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-4-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-4
      ref_id: IR-4-b
      description: Coordinate incident handling activities with contingency planning
        activities;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-4-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-4
      ref_id: IR-4-c
      description: Incorporate lessons learned from ongoing incident handling activities
        into incident response procedures, training, and testing, and implement the
        resulting changes accordingly; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-4-d
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-4
      ref_id: IR-4-d
      description: Ensure the rigor, intensity, scope, and results of incident handling
        activities are comparable and predictable across the organization.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node319
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-4
      description: 'Discussion: Organizations recognize that incident response capabilities
        are dependent on the capabilities of organizational systems and the mission
        and business processes being supported by those systems. Organizations consider
        incident response as part of the definition, design, and development of mission
        and business processes and systems. Incident-related information can be obtained
        from a variety of sources, including audit monitoring, physical access monitoring,
        and network monitoring; user or administrator reports; and reported supply
        chain events. An effective incident handling capability includes coordination
        among many organizational entities (e.g., mission or business owners, system
        owners, authorizing officials, human resources offices, physical security
        offices, personnel security offices, legal departments, risk executive [function],
        operations personnel, procurement offices). Suspected security incidents include
        the receipt of suspicious email communications that can contain malicious
        code. Suspected supply chain incidents include the insertion of counterfeit
        hardware or malicious code into organizational systems or system components.
        For federal agencies, an incident that involves personally identifiable information
        is considered a breach. A breach results in unauthorized disclosure, the loss
        of control, unauthorized acquisition, compromise, or a similar occurrence
        where a person other than an authorized user accesses or potentially accesses
        personally identifiable information or an authorized user accesses or potentially
        accesses such information for other than authorized purposes. Related Controls:
        AC-19, AU-6, AU-7, CM-6, CP-2, CP-3, CP-4, IR-2, IR-3, IR-5, IR-6, IR-8,

        PE-6, PL-2, SA-8, SC-5, SC-7, SI-3, SI-4, SI-7.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-4(1)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-4
      ref_id: IR-4(1)
      name: INCIDENT HANDLING | AUTOMATED INCIDENT HANDLING PROCESSES
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node321
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-4(1)
      description: Support the incident handling process using automated mechanisms
        (e.g., online incident management systems and tools that support the collection
        of live response data, full network packet capture, and forensic analysis.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node322
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-4(1)
      description: 'Discussion: Automated mechanisms that support incident handling
        processes include online incident management systems and tools that support
        the collection of live response data, full network packet capture, and forensic
        analysis. Incident handling could be inherited from an upstream agency or
        could be part of a state-level process.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-5
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.3
      ref_id: IR-5
      name: INCIDENT MONITORING
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node324
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-5
      description: Track and document incidents.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node325
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-5
      description: 'Discussion: Documenting incidents includes maintaining records
        about each incident, the status of the incident, and other pertinent information
        necessary for forensics as well as evaluating incident details, trends, and
        handling. Incident information can be obtained from a variety of sources,
        including network monitoring, incident reports, incident response teams, user
        complaints, supply chain partners, audit monitoring, physical access monitoring,
        and user and administrator reports. IR-4 provides information on the types
        of incidents that are appropriate for monitoring.

        Related Controls: AU-6, AU-7, IR-4, IR-6, IR-8, PE-6, SC-5, SC-7, SI-3, SI-4,
        SI-7.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-6
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.3
      ref_id: IR-6
      name: INCIDENT REPORTING
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-6-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-6
      ref_id: IR-6-a
      description: Require personnel to report suspected incidents to the organizational
        incident response capability within immediately but not to exceed one (1)
        hour after discovery; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-6-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-6
      ref_id: IR-6-b
      description: Report incident information to organizational personnel with incident
        handling responsibilities, and if confirmed, notify the CSO, SIB Chief, or
        Interface Agency Official.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node329
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-6
      description: "Discussion: The types of incidents reported, the content and timeliness\
        \ of the reports, and the designated reporting authorities reflect applicable\
        \ laws, executive orders, directives, regulations, policies, standards, and\
        \ guidelines. Incident information can inform risk assessments, control effectiveness\
        \ assessments, security requirements for acquisitions, and selection criteria\
        \ for technology products. \nRelated Controls: CM-6, CP-2, IR-4, IR-5, IR-8."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-6(1)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-6
      ref_id: IR-6(1)
      name: INCIDENT REPORTING | AUTOMATED REPORTING
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node331
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-6(1)
      description: Report incidents using automated mechanisms.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node332
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-6(1)
      description: 'Discussion: The recipients of incident reports are specified in
        IR-6b. Automated reporting mechanisms include email, posting on websites (with
        automatic updates), and automated incident response tools and programs.

        Related Controls: IR-7.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-6(3)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-6
      ref_id: IR-6(3)
      name: INCIDENT REPORTING | SUPPLY CHAIN COORDINATION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node334
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-6(3)
      description: Provide incident information to the provider of the product or
        service and other organizations involved in the supply chain or supply chain
        governance for systems or system components related to the incident.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node335
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-6(3)
      description: 'Discussion: Organizations involved in supply chain activities
        include product developers, system integrators, manufacturers, packagers,
        assemblers, distributors, vendors, and resellers. Entities that provide supply
        chain governance include the Federal Acquisition Security Council (FASC).
        Supply chain incidents include compromises or breaches that involve information
        technology products, system components, development processes or personnel,
        distribution processes, or warehousing facilities. Organizations determine
        the appropriate information to share and consider the value gained from informing
        external organizations about supply chain incidents, including the ability
        to improve processes or to identify the root cause of an incident.

        Related Controls: SR-8.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-7
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.3
      ref_id: IR-7
      name: INCIDENT RESPONSE ASSISTANCE
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node337
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-7
      description: Provide an incident response support resource, integral to the
        organizational incident response capability, that offers advice and assistance
        to users of the system for the handling and reporting of incidents.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node338
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-7
      description: 'Discussion: Incident response support resources provided by organizations
        include help desks, assistance groups, automated ticketing systems to open
        and track incident response tickets, and access to forensics services or consumer
        redress services, when required.

        Related Controls: AT-2, AT-3, IR-4, IR-6, IR-8, SA-9.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-7(1)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-7
      ref_id: IR-7(1)
      name: INCIDENT RESPONSE ASSISTANCE | AUTOMATION SUPPORT FOR AVAILABILITY OF
        INFORMATION AND SUPPORT
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node340
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-7(1)
      description: Increase the availability of incident response information and
        support using automated mechanisms described in the discussion.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node341
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-7(1)
      description: 'Discussion: Automated mechanisms can provide a push or pull capability
        for users to obtain incident response assistance. For example, individuals
        may have access to a website to query the assistance capability, or the assistance
        capability can proactively send incident response information to users (general
        distribution or targeted) as part of increasing understanding of current response
        capabilities and support.

        If the automated mechanisms include external assistance that will give unescorted
        physical or logical access to CJI, it is imperative to ensure that the appropriate
        controls/procedures (CJIS Security Addendum/Outsourcing Standard) are in place.
        Examples would include Cyber IncidentResponse Vendors (IT Security/Law Firms).

        Related Controls: None.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.3
      ref_id: IR-8
      name: INCIDENT RESPONSE PLAN
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8
      ref_id: IR-8-a
      description: 'Develop an incident response plan that:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8-a-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8-a
      ref_id: IR-8-a-1
      description: Provides the organization with a roadmap for implementing its incident
        response capability;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8-a-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8-a
      ref_id: IR-8-a-2
      description: Describes the structure and organization of the incident response
        capability;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8-a-3
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8-a
      ref_id: IR-8-a-3
      description: Provides a high-level approach for how the incident response capability
        fits into the overall organization;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8-a-4
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8-a
      ref_id: IR-8-a-4
      description: Meets the unique requirements of the organization, which relate
        to mission, size, structure, and functions;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8-a-5
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8-a
      ref_id: IR-8-a-5
      description: Defines reportable incidents;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8-a-6
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8-a
      ref_id: IR-8-a-6
      description: Provides metrics for measuring the incident response capability
        within the organization;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8-a-7
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8-a
      ref_id: IR-8-a-7
      description: Defines the resources and management support needed to effectively
        maintain and mature an incident response capability;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8-a-8
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8-a
      ref_id: IR-8-a-8
      description: Addresses the sharing of incident information;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8-a-9
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8-a
      ref_id: IR-8-a-9
      description: "Is reviewed and approved by the organization\u2019s/agency\u2019\
        s executive leadership annually; and"
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8-a-10
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8-a
      ref_id: IR-8-a-10
      description: Explicitly designates responsibility for incident response to organizational
        personnel with incident reporting responsibilities and CSO or CJIS WAN Official.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8
      ref_id: IR-8-b
      description: Distribute copies of the incident response plan to organizational
        personnel with incident handling responsibilities;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8
      ref_id: IR-8-c
      description: Update the incident response plan to address system and organizational
        changes or problems encountered during plan implementation, execution, or
        testing;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8-d
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8
      ref_id: IR-8-d
      description: Communicate incident response plan changes to organizational personnel
        with incident handling responsibilities; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8-e
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8
      ref_id: IR-8-e
      description: Protect the incident response plan from unauthorized disclosure
        and modification.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node358
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8
      description: 'Discussion: It is important that organizations develop and implement
        a coordinated approach to incident response. Organizational mission and business
        functions determine the structure of incident response capabilities. As part
        of the incident response capabilities, organizations consider the coordination
        and sharing of information with external organizations, including external
        service providers and other organizations involved in the supply chain. For
        incidents involving personally identifiable information (i.e., breaches),
        include a process to determine whether notice to oversight organizations or
        affected individuals is appropriate and provide that notice accordingly.

        Related Controls: AC-2, CP-2, CP-4, IR-4, IR-7, PE-6, PL-2, SA-15, SI-12,
        SR-8.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8(1)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8
      ref_id: IR-8(1)
      name: INCIDENT RESPONSE PLAN | BREACHES
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node360
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8(1)
      description: 'Include the following in the Incident Response Plan for breaches
        involving personally identifiable information:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8(1)-a
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8(1)
      ref_id: IR-8(1)-a
      description: A process to determine if notice to individuals or other organizations,
        including oversight organizations, is needed;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8(1)-b
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8(1)
      ref_id: IR-8(1)-b
      description: An assessment process to determine the extent of the harm, embarrassment,
        inconvenience, or unfairness to affected individuals and any mechanisms to
        mitigate such harms; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8(1)-c
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8(1)
      ref_id: IR-8(1)-c
      description: Identification of applicable privacy requirements.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node364
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ir-8(1)
      description: 'Discussion: Organizations may be required by law, regulation,
        or policy to follow specific procedures relating to breaches, including notice
        to individuals, affected organizations, and oversight bodies; standards of
        harm; and mitigation or other specific requirements.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.4
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5
      ref_id: '5.4'
      name: AUDIT AND ACCOUNTABILITY (AU)
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-1
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.4
      ref_id: AU-1
      name: POLICY AND PROCEDURES
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-1-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-1
      ref_id: AU-1-a
      description: 'Develop, document, and disseminate to organizational personnel
        with audit and accountability responsibilities:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-1-a-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-1-a
      ref_id: AU-1-a-1
      description: 'Agency and system-level audit and accountability policy that:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-1-a-1-a
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-1-a-1
      ref_id: AU-1-a-1-a
      description: Addresses purpose, scope, roles, responsibilities, management commitment,
        coordination among organizational entities, and compliance; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-1-a-1-b
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-1-a-1
      ref_id: AU-1-a-1-b
      description: Is consistent with applicable laws, executive orders, directives,
        regulations, policies, standards, and guidelines; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-1-a-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-1-a
      ref_id: AU-1-a-2
      description: Procedures to facilitate the implementation of the audit and accountability
        policy and the associated audit and accountability controls;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-1-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-1
      ref_id: AU-1-b
      description: Designate organizational personnel with information security responsibilities
        to manage the development, documentation, and dissemination of the audit and
        accountability policy and procedures; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-1-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-1
      ref_id: AU-1-c
      description: 'Review and update the current audit and accountability:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-1-c-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-1-c
      ref_id: AU-1-c-1
      description: Policy annually and following any security incidents involving
        unauthorized access to CJI or systems used to process, store, or transmit
        CJI; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-1-c-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-1-c
      ref_id: AU-1-c-2
      description: Procedures annually and following any security incidents involving
        unauthorized access to CJI or systems used to process, store, or transmit
        CJI.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node376
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-1
      description: 'Discussion: Audit and accountability policy and procedures address
        the controls in the AU family that are implemented within systems and organizations.
        The risk management strategy is an important factor in establishing such policies
        and procedures. Policies and procedures contribute to security and privacy
        assurance. Therefore, it is important that security and privacy programs collaborate
        on the development of audit and accountability policy and procedures. Security
        and privacy program policies and procedures at the organization level are
        preferable, in general, and may obviate the need for mission- or system-specific
        policies and procedures. The policy can be included as part of the general
        security and privacy policy or be represented by multiple policies that reflect
        the complex nature of organizations. Procedures can be established for security
        and privacy programs, for mission or business processes, and for systems,
        if needed. Procedures describe how the policies or controls are implemented
        and can be directed at the individual or role that is the object of the procedure.
        Procedures can be documented in system security and privacy plans or in one
        or more separate documents. Events that may precipitate an update to audit
        and accountability policy and procedures include assessment or audit findings,
        security incidents or breaches, or changes in applicable laws, executive orders,
        directives, regulations, policies, standards, and guidelines. Simply restating
        controls does not constitute an organizational policy or procedure.

        Related Controls: PS-8, SI-12.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.4
      ref_id: AU-2
      name: EVENT LOGGING
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2
      ref_id: AU-2-a
      description: 'Identify the types of events that the system is capable of logging
        in support of the audit function: authentication, file use, user/group management,
        events sufficient to establish what occurred, the sources of events, outcomes
        of events, and operational transactions

        (e.g., NCIC, III);'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2
      ref_id: AU-2-b
      description: Coordinate the event logging function with other organizational
        entities requiring audit- related information to guide and inform the selection
        criteria for events to be logged;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2
      ref_id: AU-2-c
      description: 'Specify the following event types for logging within the system:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node381
      assessable: false
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2-c
      description: 'All successful and unsuccessful:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2-c-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2-c
      ref_id: AU-2-c-1
      description: System log-on attempts
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2-c-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2-c
      ref_id: AU-2-c-2
      description: 'Attempts to use:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2-c-2-a
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2-c-2
      ref_id: AU-2-c-2-a
      description: Access permission on a user account, file, directory, or other
        system resource;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2-c-2-b
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2-c-2
      ref_id: AU-2-c-2-b
      description: Create permission on a user account, file, directory, or other
        system resource;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2-c-2-c
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2-c-2
      ref_id: AU-2-c-2-c
      description: Write permission on a user account, file, directory, or other system
        resource;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2-c-2-d
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2-c-2
      ref_id: AU-2-c-2-d
      description: Delete permission on a user account, file, directory, or other
        system resource;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2-c-2-e
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2-c-2
      ref_id: AU-2-c-2-e
      description: Change permission on a user account, file, directory, or other
        system resource.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2-c-3
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2-c
      ref_id: AU-2-c-3
      description: Attempts to change account passwords
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2-c-4
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2-c
      ref_id: AU-2-c-4
      description: Actions by privileged accounts (i.e., root, Oracle, DBA, admin,
        etc.)
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2-c-5
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2-c
      ref_id: AU-2-c-5
      description: 'Attempts for users to:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2-c-5-a
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2-c-5
      ref_id: AU-2-c-5-a
      description: Access the audit log file;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2-c-5-b
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2-c-5
      ref_id: AU-2-c-5-b
      description: Modify the audit log file;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2-c-5-c
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2-c-5
      ref_id: AU-2-c-5-c
      description: Destroy the audit log file.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2-d
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2
      ref_id: AU-2-d
      description: Provide a rationale for why the event types selected for logging
        are deemed to be adequate to support after-the-fact investigations of incidents;
        and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2-e
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2
      ref_id: AU-2-e
      description: Review and update the event types selected for logging annually.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node397
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2
      description: 'Discussion: An event is an observable occurrence in a system.
        The types of events that require logging are those events that are significant
        and relevant to the security of systems and the privacy of individuals. Event
        logging also supports specific monitoring and auditing needs. Event types
        include password changes, failed logons or failed accesses related to systems,
        security or privacy attribute changes, administrative privilege usage, PIV
        credential usage, data action changes, query parameters, or external credential
        usage. In determining the set of event types that require logging, organizations
        consider the monitoring and auditing appropriate for each of the controls
        to be implemented. For completeness, event logging includes all protocols
        that are operational and supported by the system.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node398
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2
      description: To balance monitoring and auditing requirements with other system
        needs, event logging requires identifying the subset of event types that are
        logged at a given point in time. For example, organizations may determine
        that systems need the capability to log every file access successful and unsuccessful,
        but not activate that capability except for specific circumstances due to
        the potential burden on system performance. The types of events that organizations
        desire to be logged may change. Reviewing and updating the set of logged events
        is necessary to help ensure that the events remain relevant and continue to
        support the needs of the organization.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node399
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2
      description: Organizations consider how the types of logging events can reveal
        information about individuals that may give rise to privacy risk and how best
        to mitigate such risks. For example, there is the potential to reveal personally
        identifiable information in the audit trail, especially if the logging event
        is based on patterns or time of usage.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node400
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-2
      description: "Event logging requirements, including the need to log specific\
        \ event types, may be referenced in other controls and control enhancements.\
        \ These include AC-2(4), AC-3(10), AC-6(9), AC-17(1), CM-3f, CM-5(1), IA-3(3.b),\
        \ MA-4(1), MP-4(2), PE-3, PM-21, PT-7, RA-8, SC-7(9), SC-7(15), SI-3(8), SI-4(22),\
        \ SI-7(8), and SI-10(1). Organizations include event types that are required\
        \ by applicable laws, executive orders, directives, policies, regulations,\
        \ standards, and guidelines. Audit records can be generated at various levels,\
        \ including at the packet level as information traverses the network. Selecting\
        \ the appropriate level of event logging is an important part of a monitoring\
        \ and auditing capability and can identify the root causes of problems. When\
        \ defining event types, organizations consider the logging necessary to cover\
        \ related event types, such as the steps in distributed, transaction-based\
        \ processes and the actions that occur in service-oriented architectures.\
        \ \nRelated Controls: AC-2, AC-3, AC-6, AC-7, AC-8, AC-17, AU-3, AU-4, AU-5,\
        \ AU-6, AU-7,\nAU-11, AU-12, CM-3, CM-5, CM-6, IA-3, MA-4, MP-4, PE-3, SA-8,\
        \ SC-7, SC-18, SI-3, SI-4,\nSI-7, SI-10, SI-11."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.4
      ref_id: AU-3
      name: CONTENT OF AUDIT RECORDS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node402
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3
      description: 'Ensure that audit records contain information that establishes
        the following:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3
      ref_id: AU-3-a
      description: What type of event occurred;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3
      ref_id: AU-3-b
      description: When the event occurred;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3
      ref_id: AU-3-c
      description: Where the event occurred;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3-d
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3
      ref_id: AU-3-d
      description: Source of the event;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3-e
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3
      ref_id: AU-3-e
      description: Outcome of the event; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3-f
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3
      ref_id: AU-3-f
      description: Identity of any individuals, subjects, or objects/entities associated
        with the event.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node409
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3
      description: "Discussion: Audit record content that may be necessary to support\
        \ the auditing function includes event descriptions (item a), time stamps\
        \ (item b), source and destination addresses (item c), user or process identifiers\
        \ (items d and f), success or fail indications (item e), and filenames involved\
        \ (items a, c, e, and f). Event outcomes include indicators of event success\
        \ or failure and event-specific results, such as the system security and privacy\
        \ posture after the event occurred. Organizations consider how audit records\
        \ can reveal information about individuals that may give rise to privacy risks\
        \ and how best to mitigate such risks. For example, there is the potential\
        \ to reveal personally identifiable information in the audit trail, especially\
        \ if the trail records inputs or is based on patterns or time of usage. \n\
        Related Controls: AU-2, AU-8, AU-12, MA-4, SA-8, SI-7, SI-11."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3(1)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3
      ref_id: AU-3(1)
      name: CONTENT OF AUDIT RECORDS | ADDITIONAL AUDIT INFORMATION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node411
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3(1)
      description: 'Generate audit records containing the following additional information:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3(1)-a
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3(1)
      ref_id: AU-3(1)-a
      description: Session, connection, transaction, and activity duration;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3(1)-b
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3(1)
      ref_id: AU-3(1)-b
      description: Source and destination addresses;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3(1)-c
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3(1)
      ref_id: AU-3(1)-c
      description: Object or filename involved; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3(1)-d
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3(1)
      ref_id: AU-3(1)-d
      description: Number of bytes received and bytes sent (for client-server transactions)
        in the audit records for audit events identified by type, location, or subject.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3(1)-e
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3(1)
      ref_id: AU-3(1)-e
      description: 'The III portion of the log shall clearly identify:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3(1)-e-1
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3(1)-e
      ref_id: AU-3(1)-e-1
      description: The operator
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3(1)-e-2
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3(1)-e
      ref_id: AU-3(1)-e-2
      description: The authorized receiving agency
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3(1)-e-3
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3(1)-e
      ref_id: AU-3(1)-e-3
      description: The requestor
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3(1)-e-4
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3(1)-e
      ref_id: AU-3(1)-e-4
      description: The secondary recipient
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node421
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3(1)
      description: 'Discussion: The ability to add information generated in audit
        records is dependent on system functionality to configure the audit record
        content. Organizations may consider additional information in audit records
        including, but not limited to, access control or flow control rules invoked
        and individual identities of group account users. Organizations may also consider
        limiting additional audit record information to only information that is explicitly
        needed for audit requirements. This facilitates the use of audit trails and
        audit logs by not including information in audit records that could potentially
        be misleading, make it more difficult to locate information of interest, or
        increase the risk to individuals'' privacy.

        Related Controls: None.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3(3)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3
      ref_id: AU-3(3)
      name: CONTENT OF AUDIT RECORDS | LIMIT PERSONALLY IDENTIFIABLE INFORMATION ELEMENTS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node423
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3(3)
      description: 'Limit personally identifiable information contained in audit records
        to the following elements identified in the privacy risk assessment: minimum
        PII necessary to achieve the purpose forwhich it is collected (see Section
        4.3).'
      annotation: ref section
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node424
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-3(3)
      description: 'Discussion: Limiting personally identifiable information in audit
        records when such information is not needed for operational purposes helps
        reduce the level of privacy risk created by a system.

        Related Controls: RA-3.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-4
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.4
      ref_id: AU-4
      name: AUDIT LOG STORAGE CAPACITY
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node426
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-4
      description: Allocate audit log storage capacity to accommodate the collection
        of audit logs to meet retention requirements (AU-11).
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node427
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-4
      description: 'Discussion: Organizations consider the types of audit logging
        to be performed and the audit log processing requirements when allocating
        audit log storage capacity. Allocating sufficient audit log storage capacity
        reduces the likelihood of such capacity being exceeded and resulting in the
        potential loss or reduction of audit logging capability.

        Related Controls: AU-2, AU-5, AU-6, AU-7, AU-9, AU-11, AU-12, SI-4.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-5
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.4
      ref_id: AU-5
      name: RESPONSE TO AUDIT LOGGING PROCESS FAILURES
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-5-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-5
      ref_id: AU-5-a
      description: Alert organizational personnel with audit and accountability responsibilities
        and system/network administrators within one (1) hour in the event of an audit
        logging process failure; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-5-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-5
      ref_id: AU-5-b
      description: 'Take the following additional actions: restart all audit logging
        processes and verify system(s) are logging properly.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node431
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-5
      description: "Discussion: Audit logging process failures include software and\
        \ hardware errors, failures in audit log capturing mechanisms, and reaching\
        \ or exceeding audit log storage capacity. Organization- defined actions include\
        \ overwriting oldest audit records, shutting down the system, and stopping\
        \ the generation of audit records. Organizations may choose to define additional\
        \ actions for audit logging process failures based on the type of failure,\
        \ the location of the failure, the severity of the failure, or a combination\
        \ of such factors. When the audit logging process failure is related to storage,\
        \ the response is carried out for the audit log storage repository (i.e.,\
        \ the distinct system component where the audit logs are stored), the system\
        \ on which the audit logs reside, the total audit log storage capacity of\
        \ the organization (i.e., all audit log storage repositories combined), or\
        \ all three. \nRelated Controls: AU-2, AU-4, AU-7, AU-9, AU-11, AU-12, SI-4,\
        \ SI-12."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-6
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.4
      ref_id: AU-6
      name: AUDIT RECORD REVIEW, ANALYSIS, AND REPORTING
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-6-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-6
      ref_id: AU-6-a
      description: Review and analyze system audit records weekly for indications
        of inappropriate or unusual activity and the potential impact of the inappropriate
        or unusual activity;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-6-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-6
      ref_id: AU-6-b
      description: Report findings to organizational personnel with audit review,
        analysis, and reporting responsibilities and organizational personnel with
        information security and privacy responsibilities; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-6-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-6
      ref_id: AU-6-c
      description: Adjust the level of audit record review, analysis, and reporting
        within the system when there is a change in risk based on law enforcement
        information, intelligence information, or other credible sources of information.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node436
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-6
      description: 'Discussion: Audit record review, analysis, and reporting covers
        information security- and privacy- related logging performed by organizations,
        including logging that results from the monitoring of account usage, remote
        access, wireless connectivity, mobile device connection, configuration settings,
        system component inventory, use of maintenance tools and non-local maintenance,
        physical access, temperature and humidity, equipment delivery and removal,
        communications at system interfaces, and use of mobile code or Voice over
        Internet Protocol (VoIP). Findings can be reported to organizational entities
        that include the incident response team, help desk, and security or privacy
        offices. If organizations are prohibited from reviewing and analyzing audit
        records or unable to conduct such activities, the review or analysis may be
        carried out by other organizations granted such authority. The frequency,
        scope, and/or depth of the audit record review, analysis, and reporting may
        be adjusted to meet organizational needs based on new information received.

        Related Controls: AC-2, AC-3, AC-5, AC-6, AC-7, AC-17, AU-7, CA-2, CA-7, CM-2,
        CM-5,

        CM-6, CM-10, CM-11, IA-2, IA-3, IA-5, IA-8, IR-5, MA-4, MP-4, PE-3, PE-6,
        RA-5, SA-8,

        SC-7, SI-3, SI-4, SI-7.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-6(1)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-6
      ref_id: AU-6(1)
      name: AUDIT RECORD REVIEW, ANALYSIS, AND REPORTING | AUTOMATED PROCESS INTEGRATION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node438
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-6(1)
      description: Integrate audit record review, analysis, and reporting processes
        using automated mechanisms.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node439
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-6(1)
      description: 'Discussion: Organizational processes that benefit from integrated
        audit record review, analysis, and reporting include incident response, continuous
        monitoring, contingency planning, investigation and response to suspicious
        activities, and Inspector General audits.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-6(3)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-6
      ref_id: AU-6(3)
      name: AUDIT RECORD REVIEW, ANALYSIS, AND REPORTING | CORRELATE AUDIT RECORD
        REPOSITORIES
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node441
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-6(3)
      description: Analyze and correlate audit records across different repositories
        to gain organization-wide situational awareness.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node442
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-6(3)
      description: 'Discussion: Organization-wide situational awareness includes awareness
        across all three levels of risk management (i.e., organizational level, mission/business
        process level, and information system level) and supports cross-organization
        awareness.

        Related Controls: AU-12, IR-4.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-7
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.4
      ref_id: AU-7
      name: AUDIT RECORD REDUCTION AND REPORT GENERATION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node444
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-7
      description: Provide and implement an audit record reduction and report generation
        capability that
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-7-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-7
      ref_id: AU-7-a
      description: Supports on-demand audit record review, analysis, and reporting
        requirements and after-the-fact investigations of incidents; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-7-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-7
      ref_id: AU-7-b
      description: Does not alter the original content or time ordering of audit records.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node447
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-7
      description: 'Discussion: Audit record reduction is a process that manipulates
        collected audit log information and organizes it into a summary format that
        is more meaningful to analysts.

        Audit record reduction and report generation capabilities do not always emanate
        from the same system or from the same organizational entities that conduct
        audit logging activities. The audit record reduction capability includes modern
        data mining techniques with advanced data filters to identify anomalous behavior
        in audit records. The report generation capability provided by the system
        can generate customizable reports. Time ordering of audit records can be an
        issue if the granularity of the timestamp in the record is insufficient.

        Related Controls: AC-2, AU-2, AU-3, AU-4, AU-5, AU-6, AU-12, CM-5, IA-5, IR-4,
        SI-4.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-7(1)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-7
      ref_id: AU-7(1)
      name: 'AUDIT RECORD REDUCTION AND REPORT GENERATION | AUTOMATIC

        PROCESSING'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node449
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-7(1)
      description: 'Provide and implement the capability to process, sort, and search
        audit records for events of interest based on the following content: information
        included in AU-3.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node450
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-7(1)
      description: 'Discussion: Events of interest can be identified by the content
        of audit records, including system resources involved, information objects
        accessed, identities of individuals, event types, event locations, event dates
        and times, Internet Protocol addresses involved, or event success or failure.
        Organizations may define event criteria to any degree of granularity required,
        such as locations selectable by a general networking location or by specific
        system component.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-8
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.4
      ref_id: AU-8
      name: TIME STAMPS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-8-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-8
      ref_id: AU-8-a
      description: Use internal system clocks to generate time stamps for audit records;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-8-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-8
      ref_id: AU-8-b
      description: Record time stamps for audit records that meet hundredths of a
        second (i.e., hh:mm:ss:00) interval and that use Coordinated Universal Time,
        have a fixed local time offset from Coordinated Universal Time, or that include
        the local time offset as part of the time stamp.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node454
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-8
      description: 'Discussion: Time stamps generated by the system include date and
        time. Time is commonly expressed in Coordinated Universal Time (UTC), a modern
        continuation of Greenwich Mean Time (GMT), or local time with an offset from
        UTC. Granularity of time measurements refers to the degree of synchronization
        between system clocks and reference clocks (e.g., clocks synchronizing within
        hundreds of milliseconds or tens of milliseconds). Organizations may define
        different time granularities for different system components. Time service
        can be critical to other security capabilities such as access control and
        identification and authentication, depending on the nature of the mechanisms
        used to support those capabilities.

        Related Controls: AU-3, AU-12.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-9
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.4
      ref_id: AU-9
      name: PROTECTION OF AUDIT INFORMATION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-9-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-9
      ref_id: AU-9-a
      description: Protect audit information and audit logging tools from unauthorized
        access, modification, and deletion; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-9-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-9
      ref_id: AU-9-b
      description: Alert organizational personnel with audit and accountability responsibilities,
        organizational personnel with information security and privacy responsibilities,
        and system/network administrators upon detection of unauthorized access, modification,
        or deletion of audit information.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node458
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-9
      description: 'Discussion: Audit information includes all information needed
        to successfully audit system activity, such as audit records, audit log settings,
        audit reports, and personally identifiable information. Audit logging tools
        are those programs and devices used to conduct system audit and logging activities.
        Protection of audit information focuses on technical protection and limits
        the ability to access and execute audit logging tools to authorized individuals.
        Physical protection of audit information is addressed by both media protection
        controls and physical and environmental protection controls.

        Related Controls: AC-3, AC-6, AU-6, AU-11, MP-2, MP-4, PE-2, PE-3, PE-6, SA-8,
        SC-8, SI-

        4.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-9(1)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-9
      ref_id: AU-9(1)
      name: PROTECTION OF AUDIT INFORMATION | ACCESS BY SUBSET OF PRIVILEGED USERS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node460
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-9(1)
      description: Authorize access to management of audit logging functionality to
        only organizational personnel with audit and accountability responsibilities,
        organizational personnel with information security and privacy responsibilities,
        and system/network administrators.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node461
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-9(1)
      description: 'Discussion: Individuals or roles with privileged access to a system
        and who are also the subject of an audit by that system may affect the reliability
        of the audit information by inhibiting audit activities or modifying audit
        records. Requiring privileged access to be further defined between audit-related
        privileges and other privileges limits the number of users or roles with audit-related
        privileges.

        Related Controls: AC-5.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-11
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.4
      ref_id: AU-11
      name: AUDIT RECORD RETENTION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node463
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-11
      description: Retain audit records for a minimum of one (1) year or until it
        is determined they are no longer needed for administrative, legal, audit,
        or other operational purposes to provide support for after-the-fact investigations
        of incidents and to meet regulatory and organizational information retention
        requirements.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node464
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-11
      description: 'Discussion: Organizations retain audit records until it is determined
        that the records are no longer needed for administrative, legal, audit, or
        other operational purposes. This includes the retention and availability of
        audit records relative to Freedom of Information Act (FOIA) requests, subpoenas,
        and law enforcement actions. Organizations develop standard categories of
        audit records relative to such types of actions and standard response processes
        for each type of action.Related Controls: AU-2, AU-4, AU-5, AU-6, AU-9, MP-6,
        RA-5, SI-12.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-12
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.4
      ref_id: AU-12
      name: AUDIT RECORD GENERATION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-12-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-12
      ref_id: AU-12-a
      description: Provide audit record generation capability for the event types
        the system is capable of auditing as defined in AU-2a on all systems generating
        required audit logs;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-12-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-12
      ref_id: AU-12-b
      description: 'Allow organizational personnel with audit record generation responsibilities,

        organizational personnel with information security and privacy responsibilities,
        and system/network administrators to select the event types that are to be
        logged by specific components of the system; and'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-12-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-12
      ref_id: AU-12-c
      description: Generate audit records for the event types defined in AU-2c that
        include the audit record content defined in AU-3.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node469
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:au-12
      description: 'Discussion: Audit records can be generated from many different
        system components. The event types specified in AU-2c are the event types
        for which audit logs are to be generated and are a subset of all event types
        for which the system can generate audit records.

        Related Controls: AC-6, AC-17, AU-2, AU-3, AU-4, AU-5, AU-6, AU-7, CM-5, MA-4,
        MP-4,

        SA-8, SC-18, SI-3, SI-4, SI-7, SI-10.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.5
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5
      ref_id: '5.5'
      name: ACCESS CONTROL (AC)
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-1
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.5
      ref_id: AC-1
      name: POLICY AND PROCEDURES
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-1-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-1
      ref_id: AC-1-a
      description: 'Develop, document, and disseminate to: organizational personnel
        with access control responsibilities'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-1-a-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-1-a
      ref_id: AC-1-a-1
      description: 'Agency-level access control policy that:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-1-a-1-a
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-1-a-1
      ref_id: AC-1-a-1-a
      description: 'Addresses purpose, scope, roles, responsibilities, management
        commitment,

        coordination among organizational entities, and compliance; and'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-1-a-1-b
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-1-a-1
      ref_id: AC-1-a-1-b
      description: 'Is consistent with applicable laws, executive orders, directives,
        regulations, policies,

        standards, and guidelines; and'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-1-a-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-1-a
      ref_id: AC-1-a-2
      description: Procedures to facilitate the implementation of the access control
        policy and the associated access controls;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-1-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-1
      ref_id: AC-1-b
      description: Designate an individual with security responsibilities to manage
        the development, documentation, and dissemination of the access control policy
        and procedures; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-1-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-1
      ref_id: AC-1-c
      description: 'Review and update the current access control:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-1-c-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-1-c
      ref_id: AC-1-c-1
      description: Policy annually and following any security incidents involving
        unauthorized access to CJI or systems used to process, store, or transmit
        CJI; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-1-c-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-1-c
      ref_id: AC-1-c-2
      description: Procedures annually and following any security incidents involving
        unauthorized access to CJI or systems used to process, store, or transmit
        CJI.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node481
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-1-c
      description: 'Discussion: Access control policy and procedures address the controls
        in the AC family that are implemented within systems and organizations. The
        risk management strategy is an important factor in establishing such policies
        and procedures. Policies and procedures contribute to security and privacy
        assurance. Therefore, it is important that security and privacy programs collaborate
        on the development of access control policy and procedures. Security and privacy
        program policies and procedures at the organization level are preferable,
        in general, and may obviate the need for mission- or system-specific policies
        and procedures. The policy can be included as part of the general security
        and privacy policy or be represented by multiple policies reflecting the complex
        nature of organizations. Procedures can be established for security and privacy
        programs, for mission or business processes, and for systems, if needed. Procedures
        describe how the policies or controls are implemented and can be directed
        at the individual or role that is the object of the procedure. Procedures
        can be documented in system security and privacy plans or in one or more separate
        documents. Events that may precipitate an update to access control policy
        and procedures include assessment or audit findings, security incidents or
        breaches, or changes in laws, executive orders, directives, regulations, policies,
        standards, and guidelines. Simply restating controls does not constitute an
        organizational policy or procedure.

        Related Controls: IA-1, PS-8, SI-12.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.5
      ref_id: AC-2
      name: ACCOUNT MANAGEMENT
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2
      ref_id: AC-2-a
      description: Define and document the types of accounts allowed and specifically
        prohibited for use within the system;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2
      ref_id: AC-2-b
      description: Assign account managers;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2
      ref_id: AC-2-c
      description: Require conditions for group and role membership;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2-d
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2
      ref_id: AC-2-d
      description: 'Specify:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2-d-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2-d
      ref_id: AC-2-d-1
      description: Authorized users of the system;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2-d-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2-d
      ref_id: AC-2-d-2
      description: Group and role membership; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2-d-3
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2-d
      ref_id: AC-2-d-3
      description: Access authorizations (i.e., privileges) and attributes listed
        for each account;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node490
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2-d
      description: 'Attribute Name:

        Email Address Text /Employer Name/ Federation Id /Given Name /Identity Provider
        Id/ Sur Name / Telephone Number /Identity Provider Id/ Unique Subject Id /Counter
        Terrorism Data Self Search Home Privilege Indicator / Criminal History Data
        Self Search Home Privilege Indicator /Criminal Intelligence Data Self Search
        Home Privilege Indicator /Criminal Investigative Data Self Search Home Privilege
        Indicator /Display Name/ Government Data Self Search Home Privilege Indicator
        / Local Id / NCIC Certification Indicator / N-DEx Privilege Indicator / PCII
        Certification Indicator / 28 CFR Certification Indicator / Employer ORI /
        Employer Organization General Category Code / Employer State Code / Public
        Safety Officer Indicator / Sworn Law Enforcement Officer Indicator / Authenticator
        Assurance Level / Federation Assurance Level / Identity Assurance Level /
        Intelligence Analyst Indicator'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2-e
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2
      ref_id: AC-2-e
      description: Require approvals by organizational personnel with account management
        responsibilities for requests to create accounts;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2-f
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2
      ref_id: AC-2-f
      description: Create, enable, modify, disable, and remove accounts in accordance
        with agency policy;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2-g
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2
      ref_id: AC-2-g
      description: Monitor the use of accounts;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2-h
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2
      ref_id: AC-2-h
      description: 'Notify account managers and system/network administrators within:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2-h-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2-h
      ref_id: AC-2-h-1
      description: One day when accounts are no longer required;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2-h-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2-h
      ref_id: AC-2-h-2
      description: One day when users are terminated or transferred; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2-h-3
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2-h
      ref_id: AC-2-h-3
      description: One day when system usage or need-to-know changes for an individual;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2-i
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2
      ref_id: AC-2-i
      description: 'Authorize access to the system based on:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2-i-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2-i
      ref_id: AC-2-i-1
      description: A valid access authorization;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2-i-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2-i
      ref_id: AC-2-i-2
      description: Intended system usage; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2-i-3
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2-i
      ref_id: AC-2-i-3
      description: Attributes as listed in AC-2(d)(3);
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2-j
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2
      ref_id: AC-2-j
      description: Review accounts for compliance with account management requirements
        at least annually;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2-k
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2
      ref_id: AC-2-k
      description: Establish and implement a process for changing shared or group
        account authenticators (if deployed) when individuals are removed from the
        group; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2-l
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2
      ref_id: AC-2-l
      description: Align account management processes with personnel termination and
        transfer processes.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node505
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2
      description: 'Discussion: Examples of system account types include individual,
        shared, group, system, guest, anonymous, emergency, developer, temporary,
        and service. Identification of authorized system users and the specification
        of access privileges reflect the requirements in other controls in the security
        plan. Users requiring administrative privileges on system accounts receive
        additional scrutiny by organizational personnel responsible for approving
        such accounts and privileged access, including system owner, mission or business
        owner, senior agency information security officer, or senior agency official
        for privacy. Types of accounts that organizations may wish to prohibit due
        to increased risk include shared, group, emergency, anonymous, temporary,
        and guest accounts. Where access involves personally identifiable information,
        security programs collaborate with the senior agency official for privacy
        to establish the specific conditions for group and role membership; specify
        authorized users, group and role membership, and access authorizations for
        each account; and create, adjust, or remove system accounts in accordance
        with organizational policies. Policies can include such information as account
        expiration dates or other factors that trigger the disabling of accounts.
        Organizations may choose to define access privileges or other attributes by
        account, type of account, or a combination of the two. Examples of other attributes
        required for authorizing access include restrictions on time of day, day of
        week, and point of origin. In defining other system account attributes, organizations
        consider system related requirements and mission/business requirements. Failure
        to consider these factors could affect system availability.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node506
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2
      description: 'Temporary and emergency accounts are intended for short-term use.
        Organizations establish temporary accounts as part of normal account activation
        procedures when there is a need for short- term accounts without the demand
        for immediacy in account activation. Organizations establish emergency accounts
        in response to crisis situations and with the need for rapid account activation.
        Therefore, emergency account activation may bypass normal account authorization
        processes. Emergency and temporary accounts are not to be confused with infrequently
        used accounts, including local logon accounts used for special tasks or when
        network resources are unavailable (may also be known as accounts of last resort).
        Such accounts remain available and are not subject to automatic disabling
        or removal dates. Conditions for disabling or deactivating accounts include
        when shared/group, emergency, or temporary accounts are no longer required
        and when individuals are transferred or terminated. Changing shared/group
        authenticators when members leave the group is intended to ensure that former
        group members do not retain access to the shared or group account. Some types
        of system accounts may require specialized training.

        Related Controls: AC-3, AC-5, AC-6, AC-17, AC-18, AC-20, AU-2, AU-12, CM-5,
        IA-2, IA-4,

        IA-5, IA-8, MA-3, MA-5, PE-2, PL-4, PS-2, PS-4, PS-5, SC-7, SC-12, SC-13.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2(1)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2
      ref_id: AC-2(1)
      name: ACCOUNT MANAGEMENT | AUTOMATED SYSTEM ACCOUNT MANAGEMENT
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node508
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2(1)
      description: Support the management of system accounts using automated mechanisms
        including email, phone, and text notifications.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node509
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2(1)
      description: 'Discussion: Automated system account management includes using
        automated mechanisms to create, enable, modify, disable, and remove accounts;
        notify account managers when an account is created, enabled, modified, disabled,
        or removed, or when users are terminated or transferred; monitor system account
        usage; and report atypical system account usage.

        Automated mechanisms can include internal system functions and email, telephonic,
        and text messaging notifications.

        Related Controls: None.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2(2)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2
      ref_id: AC-2(2)
      name: ACCOUNT MANAGEMENT | AUTOMATED TEMPORARY AND EMERGENCY ACCOUNT MANAGEMENT
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node511
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2(2)
      description: Automatically remove temporary and emergency accounts within 72
        hours.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node512
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2(2)
      description: 'Discussion: Management of temporary and emergency accounts includes
        the removal or disabling of such accounts automatically after a predefined
        time period rather than at the convenience of the system administrator. Automatic
        removal or disabling of accounts provides a more consistent implementation.

        Related Controls: None.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2(3)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2
      ref_id: AC-2(3)
      name: ACCOUNT MANAGEMENT | DISABLE ACCOUNTS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node514
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2(3)
      description: 'Disable accounts within one (1) week when the accounts:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2(3)-a
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2(3)
      ref_id: AC-2(3)-a
      description: Have expired;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2(3)-b
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2(3)
      ref_id: AC-2(3)-b
      description: Are no longer associated with a user or individual;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2(3)-c
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2(3)
      ref_id: AC-2(3)-c
      description: Are in violation of organizational policy; or
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2(3)-d
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2(3)
      ref_id: AC-2(3)-d
      description: Have been inactive for 90 calendar days.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node519
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2(3)
      description: 'Discussion: Disabling expired, inactive, or otherwise anomalous
        accounts supports the concepts of least privilege and least functionality
        which reduce the attack surface of the system.

        Related Controls: None.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2(4)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2
      ref_id: AC-2(4)
      name: ACCOUNT MANAGEMENT | AUTOMATED AUDIT ACTIONS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node521
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2(4)
      description: Automatically audit account creation, modification, enabling, disabling,
        and removal actions.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node522
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2(4)
      description: 'Discussion: Account management audit records are defined in accordance
        with AU-2 and reviewed, analyzed, and reported in accordance with AU-6.

        Related Controls: AU-2, AU-6.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2(5)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2
      ref_id: AC-2(5)
      name: ACCOUNT MANAGEMENT | INACTIVITY LOGOUT
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node524
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2(5)
      description: Require that users log out when a work period has been completed.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node525
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2(5)
      description: 'Discussion: Inactivity logout is behavior- or policy-based and
        requires users to take physical action to log out when they are expecting
        inactivity longer than the defined period. Automatic enforcement of inactivity
        logout is addressed by AC-11.

        Related Controls: AC-11.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2(13)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2
      ref_id: AC-2(13)
      name: ACCOUNT MANAGEMENT | DISABLE ACCOUNTS FOR HIGH-RISK INDIVIDUALS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node527
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2(13)
      description: Disable accounts of individuals within 30 minutes of discovery
        of direct threats to the confidentiality, integrity, or availability of CJI.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node528
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-2(13)
      description: 'Discussion: Users who pose a significant security and/or privacy
        risk include individuals for whom reliable evidence indicates either the intention
        to use authorized access to systems to cause harm or through whom adversaries
        will cause harm. Such harm includes adverse impacts to organizational operations,
        organizational assets, individuals, other organizations, or the Nation. Close
        coordination among system administrators, legal staff, human resource managers,
        and authorizing officials is essential when disabling system accounts for
        high-risk individuals.

        Related Controls: AU-6, SI-4.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-3
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.5
      ref_id: AC-3
      name: ACCESS ENFORCEMENT
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node530
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-3
      description: Enforce approved authorizations for logical access to information
        and system resources in accordance with applicable access control policies.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node531
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-3
      description: 'Discussion: Access control policies control access between active
        entities or subjects (i.e., users or processes acting on behalf of users)
        and passive entities or objects (i.e., devices, files, records, domains) in
        organizational systems. In addition to enforcing authorized access at the
        system level and recognizing that systems can host many applications and services
        in support of mission and business functions, access enforcement mechanisms
        can also be employed at the application and service level to provide increased
        information security and privacy. In contrast to logical access controls that
        are implemented within the system, physical access controls are addressed
        by the controls in the Physical and Environmental Protection (PE) family.

        Related Controls: AC-2, AC-4, AC-5, AC-6, AC-17, AC-18, AC-19, AC-20, AC-21,
        AC-22, AT-

        2, AT-3, AU-9, CA-9, CM-5, CM-11, IA-2, IA-5, IA-6, IA-7, IA-11, MA-3, MA-4,
        MA-5, MP-4,

        PS-3, SC-2, SC-4, SC-12, SC-13, SC-28, SI-4, SI-8.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-3(14)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-3
      ref_id: AC-3(14)
      name: ACCESS ENFORCEMENT | INDIVIDUAL ACCESS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node533
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-3(14)
      description: Provide automated or manual processes to enable individuals to
        have access to elements of their personally identifiable information.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node534
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-3(14)
      description: 'Discussion: Individual access affords individuals the ability
        to review personally identifiable information about them held within organizational
        records, regardless of format. Access helps individuals to develop an understanding
        about how their personally identifiable information is being processed. It
        can also help individuals ensure that their data is accurate. Access mechanisms
        can include request forms and application interfaces. For federal agencies,
        [PRIVACT] processes can be located in systems of record notices and on agency
        websites. Access to certain types of records may not be appropriate (e.g.,
        for federal agencies, law enforcement records within a system of records may
        be exempt from disclosure under the [PRIVACT]) or may require certain levels
        of authentication assurance. Organizational personnel consult with the senior
        agency official for privacy and legal counsel to determine appropriate mechanisms
        and access rights or limitations.

        Related Controls: IA-8.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-4
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.5
      ref_id: AC-4
      name: INFORMATION FLOW ENFORCEMENT
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node536
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-4
      description: Enforce approved authorizations for controlling the flow of information
        within the system and between connected systems by preventing CJI from being
        transmitted unencrypted across the public network, blocking outside traffic
        that claims to be from within the agency, and not passing any web requests
        to the public network that are not from the agency-controlled or internal
        boundary protection devices (e.g., proxies, gateways, firewalls, or routers).
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node537
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-4
      description: 'Discussion: Information flow control regulates where information
        can travel within a system and between systems (in contrast to who is allowed
        to access the information) and without regard to subsequent accesses to that
        information. Flow control restrictions include blocking external traffic that
        claims to be from within the organization, keeping export-controlled information
        from being transmitted in the clear to the Internet, restricting web requests
        that are not from the internal web proxy server, and limiting information
        transfers between organizations based on data structures and content. Transferring
        information between organizations may require an agreement specifying how
        the information flow is enforced (see CA-3). Transferring information between
        systems in different security or privacy domains with different security or
        privacy policies introduces the risk that such transfers violate one or more
        domain security or privacy policies. In such situations, information owners/stewards
        provide guidance at designated policy enforcement points between connected
        systems. Organizations consider mandating specific architectural solutions
        to enforce specific security and privacy policies. Enforcement includes prohibiting
        information transfers between connected systems (i.e., allowing access only),
        verifying write permissions before accepting information from another security
        or privacy domain or connected system, employing hardware mechanisms to enforce
        one-way information flows, and implementing trustworthy regrading mechanisms
        to reassign security or privacy attributes and labels.Organizations commonly
        employ information flow control policies and enforcement mechanisms to control
        the flow of information between designated sources and destinations within
        systems and between connected systems. Flow control is based on the characteristics
        of the information and/or the information path. Enforcement occurs, for example,
        in boundary protection devices that employ rule sets or establish configuration
        settings that restrict system services, provide a packet-filtering capability
        based on header information, or provide a message-filtering capability based
        on message content. Organizations also consider the trustworthiness of filtering
        and/or inspection mechanisms (i.e., hardware, firmware, and software components)
        that are critical to information flow enforcement. Control enhancements 3
        through 32 primarily address cross- domain solution needs that focus on more
        advanced filtering techniques, in-depth analysis, and stronger flow enforcement
        mechanisms implemented in cross-domain products, such as high- assurance guards.
        Such capabilities are generally not available in commercial off-the-shelf
        products. - Information flow enforcement also applies to control plane traffic
        (e.g., routing and DNS).

        Related Controls: AC-3, AC-6, AC-17, AC-19, AC-21, CA-3, CA-9, CM-7, SC-4,
        SC-7.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-5
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.5
      ref_id: AC-5
      name: SEPARATION OF DUTIES
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-5-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-5
      ref_id: AC-5-a
      description: Identify and document separation of duties based on specific duties,
        operations, or information systems, as necessary, to mitigate risk to CJI;
        and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-5-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-5
      ref_id: AC-5-b
      description: Define system access authorizations to support separation of duties.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node541
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-5
      description: 'Discussion: Separation of duties addresses the potential for abuse
        of authorized privileges and helps to reduce the risk of malevolent activity
        without collusion. Separation of duties includes dividing mission or business
        functions and support functions among different individuals or roles, conducting
        system support functions with different individuals, and ensuring that security
        personnel who administer access control functions do not also administer audit
        functions. Because separation of duty violations can span systems and application
        domains, organizations consider the entirety of systems and system components
        when developing policy on separation of duties. Separation of duties is enforced
        through the account management activities in AC-2, access control mechanisms
        in AC-3, and identity management activities in IA-2, IA-4, and IA-12.

        Related Controls: AC-2, AC-3, AC-6, AU-9, CM-5, CM-11, CP-9, IA-2, IA-4, IA-5,
        IA-12, MA-

        3, MA-5, PS-2, SA-8.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-6
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.5
      ref_id: AC-6
      name: LEAST PRIVILEGE
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node543
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-6
      description: Employ the principle of least privilege, allowing only authorized
        accesses for users (or processes acting on behalf of users) that are necessary
        to accomplish assigned organizational tasks.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node544
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-6
      description: 'Discussion: Organizations employ least privilege for specific
        duties and systems. The principle of least privilege is also applied to system
        processes, ensuring that the processes have access to systems and operate
        at privilege levels no higher than necessary to accomplish organizational
        missions or business functions. Organizations consider the creation of additional
        processes, roles, and accounts as necessary to achieve least privilege. Organizations
        apply least privilege to the development, implementation, and operation of
        organizational systems.

        Related Controls: AC-2, AC-3, AC-5, CM-5, CM-11, PL-2, SA-8, SA-15.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-6(1)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-6
      ref_id: AC-6(1)
      name: LEAST PRIVILEGE | AUTHORIZE ACCESS TO SECURITY FUNCTIONS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node546
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-6(1)
      description: 'Authorize access for personnel including security administrators,
        system and network administrators, and other privileged users with access
        to system control, monitoring, or administration functions (e.g., system administrators,
        information security personnel, maintainers, system programmers, etc.) to:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-6(1)-a
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-6(1)
      ref_id: AC-6(1)-a
      description: Established system accounts, configured access authorizations (i.e.,
        permissions, privileges), set events to be audited, set intrusion detection
        parameters, and other security functions; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-6(1)-b
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-6(1)
      ref_id: AC-6(1)-b
      description: Security-relevant information in hardware, software, and firmware.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node549
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-6(1)
      description: 'Discussion: Security functions include establishing system accounts,
        configuring access authorizations (i.e., permissions, privileges), configuring
        settings for events to be audited, and establishing intrusion detection parameters.
        Security-relevant information includes filtering rules for routers or firewalls,
        configuration parameters for security services, cryptographic key management
        information, and access control lists. Authorized personnel include security
        administrators, system administrators, system security officers, system programmers,
        and other privileged users.

        Related Controls: AC-17, AC-18, AC-19, AU-9, PE-2.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-6(2)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-6
      ref_id: AC-6(2)
      name: LEAST PRIVILEGE | NON-PRIVILEGED ACCESS FOR NONSECURITY FUNCTIONS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node551
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-6(2)
      description: Require that users of system accounts (or roles) with access to
        privileged security functions or security-relevant information (e.g., audit
        logs), use non-privileged accounts or roles, when accessing non-security functions.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node552
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-6(2)
      description: 'Discussion: Requiring the use of non-privileged accounts when
        accessing non-security functions limits exposure when operating from within
        privileged accounts or roles. The inclusion of roles addresses situations
        where organizations implement access control policies, such as role based
        access control, and where a change of role provides the same degree of assurance
        in the change of access authorizations for the user and the processes acting
        on behalf of the user as would be provided by a change between a privileged
        and non- privileged account.

        Related Controls: AC-17, AC-18, AC-19, PL-4.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-6(5)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-6
      ref_id: AC-6(5)
      name: LEAST PRIVILEGE | PRIVILEGED ACCOUNTS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node554
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-6(5)
      description: Restrict privileged accounts on the system to privileged users.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node555
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-6(5)
      description: 'Discussion: Privileged accounts, including super user accounts,
        are typically described as system administrator for various types of commercial
        off-the-shelf operating systems. Restricting privileged accounts to specific
        personnel or roles prevents day-to-day users from accessing privileged information
        or privileged functions. Organizations may differentiate in the application
        of restricting privileged accounts between allowed privileges for local accounts
        and for domain accounts provided that they retain the ability to control system
        configurations for key parameters and as otherwise necessary to sufficiently
        mitigate risk.

        Related Controls: IA-2, MA-3, MA-4.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-6(7)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-6
      ref_id: AC-6(7)
      name: LEAST PRIVILEGE | REVIEW OF USER PRIVILEGES
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-6(7)-a
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-6(7)
      ref_id: AC-6(7)-a
      description: Review annually the privileges assigned to non-privileged and privileged
        users to validate the need for such privileges; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-6(7)-b
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-6(7)
      ref_id: AC-6(7)-b
      description: Reassign or remove privileges, if necessary, to correctly reflect
        organizational mission and business needs.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node559
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-6(7)
      description: 'Discussion: The need for certain assigned user privileges may
        change over time to reflect changes in organizational mission and business
        functions, environments of operation, technologies, or threats. A periodic
        review of assigned user privileges is necessary to determine if the rationale
        for assigning such privileges remains valid. If the need cannot be revalidated,
        organizations take appropriate corrective actions.

        Related Controls: CA-7.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-6(9)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-6
      ref_id: AC-6(9)
      name: LEAST PRIVILEGE | LOG USE OF PRIVILEGED FUNCTIONS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node561
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-6(9)
      description: Log the execution of privileged functions.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node562
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-6(9)
      description: 'Discussion: The misuse of privileged functions, either intentionally
        or unintentionally by authorized users or by unauthorized external entities
        that have compromised system accounts, is a serious and ongoing concern and
        can have significant adverse impacts on organizations. Logging and analyzing
        the use of privileged functions is one way to detect such misuse and, in doing
        so, help mitigate the risk from insider threats and the advanced persistent
        threat.

        Related Controls: AU-2, AU-3, AU-12.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-6(10)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-6
      ref_id: AC-6(10)
      name: LEAST PRIVILEGE | PROHIBIT NON-PRIVILEGED USERS FROM EXECUTING PRIVILEGED
        FUNCTIONS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node564
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-6(10)
      description: Prevent non-privileged users from executing privileged functions.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node565
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-6(10)
      description: 'Discussion: Privileged functions include disabling, circumventing,
        or altering implemented security or privacy controls, establishing system
        accounts, performing system integrity checks, and administering cryptographic
        key management activities. Non-privileged users are individuals who do not
        possess appropriate authorizations. Privileged functions that require protection
        from non-privileged users include circumventing intrusion detection and prevention
        mechanisms or malicious code protection mechanisms. Preventing non- privileged
        users from executing privileged functions is enforced by AC-3.

        Related Controls: None.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-7
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.5
      ref_id: AC-7
      name: UNSUCCESSFUL LOGON ATTEMPTS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-7-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-7
      ref_id: AC-7-a
      description: Enforce a limit of five (5) consecutive invalid logon attempts
        by a user during a 15-minute time period; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-7-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-7
      ref_id: AC-7-b
      description: Automatically lock the account or node until released by an administrator
        when the maximum number of unsuccessful attempts is exceeded.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node569
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-7
      description: 'Discussion: The need to limit unsuccessful logon attempts and
        take subsequent action when the maximum number of attempts is exceeded applies
        regardless of whether the logon occurs via a local or network connection.
        Due to the potential for denial of service, automatic lockouts initiated by
        systems are usually temporary and automatically release after a predetermined,
        organization- defined time period. If a delay algorithm is selected, organizations
        may employ different algorithms for different components of the system based
        on the capabilities of those components.

        Responses to unsuccessful logon attempts may be implemented at the operating
        system and the application levels. Organization-defined actions that may be
        taken when the number of allowed consecutive invalid logon attempts is exceeded
        include prompting the user to answer a secret question in addition to the
        username and password, invoking a lockdown mode with limited user capabilities
        (instead of full lockout), allowing users to only logon from specified Internet
        Protocol (IP) addresses, requiring a CAPTCHA to prevent automated attacks,
        or applying user profiles such as location, time of day, IP address, device,
        or Media Access Control (MAC) address. If automatic system lockout or execution
        of a delay algorithm is not implemented in support of the availability objective,
        organizations consider a combination of other actions to help prevent brute
        force attacks.

        In addition to the above, organizations can prompt users to respond to a secret
        question before the number of allowed unsuccessful logon attempts is exceeded.
        Automatically unlocking an account after a specified period of time is generally
        not permitted. However, exceptions may be required based on operational mission
        or need.

        Related Controls: AC-2, AU-2, AU-6, IA-5.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-8
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.5
      ref_id: AC-8
      name: SYSTEM USE NOTIFICATION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-8-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-8
      ref_id: AC-8-a
      description: 'Display a system use notification message to users before granting
        access to the system that provides privacy and security notices consistent
        with applicable laws, executive orders, directives, regulations, policies,
        standards, and guidelines and state that:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-8-a-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-8-a
      ref_id: AC-8-a-1
      description: Users are accessing a restricted information system;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-8-a-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-8-a
      ref_id: AC-8-a-2
      description: System usage may be monitored, recorded, and subject to audit;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-8-a-3
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-8-a
      ref_id: AC-8-a-3
      description: Unauthorized use of the system is prohibited and subject to criminal
        and civil penalties; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-8-a-4
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-8-a
      ref_id: AC-8-a-4
      description: Use of the system indicates consent to monitoring and recording;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-8-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-8
      ref_id: AC-8-b
      description: Retain the notification message or banner on the screen until users
        acknowledge the usage conditions and take explicit actions to log on to or
        further access the system; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-8-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-8
      ref_id: AC-8-c
      description: 'For publicly accessible systems:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-8-c-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-8-c
      ref_id: AC-8-c-1
      description: Display system use information consistent with applicable laws,
        executive orders, directives, regulations, policies, standards, and guidelines,
        before granting further access to the publicly accessible system;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-8-c-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-8-c
      ref_id: AC-8-c-2
      description: Display references, if any, to monitoring, recording, or auditing
        that are consistent with privacy accommodations for such systems that generally
        prohibit those activities; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-8-c-3
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-8-c
      ref_id: AC-8-c-3
      description: Include a description of the authorized uses of the system.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node581
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-8
      description: 'Discussion: System use notifications can be implemented using
        messages or warning banners displayed before individuals log in to systems.
        System use notifications are used only for access via logon interfaces with
        human users. Notifications are not required when human interfaces do not exist.
        Based on an assessment of risk, organizations consider whether or not a secondary
        system use notification is needed to access applications or other system resources
        after the initial network logon. Organizations consider system use notification
        messages or banners displayed in multiple languages based on organizational
        needs and the demographics of system users. Organizations consult with the
        privacy office for input regarding privacy messaging and the Office of the
        General Counsel or organizational equivalent for legal review and approval
        of warning banner content.

        Related Controls: AC-14, PL-4, SI-4.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-11
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.5
      ref_id: AC-11
      name: DEVICE LOCK
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-11-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-11
      ref_id: AC-11-a
      description: 'Prevent further access to the system by initiating a device lock
        after a maximum of 30 minutes of inactivity and requiring the user to initiate
        a device lock before leaving the system unattended.

        NOTE: In the interest of safety, devices that are: (1) part of a criminal
        justice conveyance; or (2) used to perform dispatch functions and located
        within a physically secure location; or (3) terminals designated solely for
        the purpose of receiving alert notifications (i.e., receive only terminals
        or ROT) used within physically secure location facilities that remain staffed
        when in operation, are exempt from this requirement.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-11-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-11
      ref_id: AC-11-b
      description: Retain the device lock until the user reestablishes access using
        established identification and authentication procedures.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node585
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-11
      description: 'Discussion: Device locks are temporary actions taken to prevent
        logical access to organizational systems when users stop work and move away
        from the immediate vicinity of those systems but do not want to log out because
        of the temporary nature of their absences. Device locks can be implemented
        at the operating system level or at the application level. A proximity lock
        may be used to initiate the device lock (e.g., via a Bluetooth-enabled device
        or dongle). User initiated device locking is behavior or policy-based and,
        as such, requires users to take physical action to initiate the device lock.
        Device locks are not an acceptable substitute for logging out of systems,
        such as when organizations require users to log out at the end of workdays.

        Related Controls: AC-2, AC-7, IA-11, PL-4.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-11(1)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-11
      ref_id: AC-11(1)
      name: DEVICE LOCK | PATTERN-HIDING DISPLAYS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node587
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-11(1)
      description: Conceal, via the device lock, information previously visible on
        the display with a publicly viewable image.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node588
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-11(1)
      description: 'Discussion: The pattern-hiding display can include static or dynamic
        images, such as patterns used with screen savers, photographic images, solid
        colors, clock, battery life indicator, or a blank screen with the caveat that
        controlled unclassified information is not displayed.

        Related Controls: None.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-12
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.5
      ref_id: AC-12
      name: SESSION TERMINATION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node590
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-12
      description: Automatically terminate a user session after a user has been logged
        out.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node591
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-12
      description: "Discussion: Session termination addresses the termination of user-initiated\
        \ logical sessions (in contrast to SC-10, which addresses the termination\
        \ of network connections associated with communications sessions [i.e., network\
        \ disconnect]). A logical session (for local, network, and remote access)\
        \ is initiated whenever a user (or process acting on behalf of a user) accesses\
        \ an organizational system. Such user sessions can be terminated without terminating\
        \ network sessions. Session termination ends all processes associated with\
        \ a user\u2019s logical session except for those processes that are specifically\
        \ created by the user (i.e., session owner) to continue after the session\
        \ is terminated. Conditions or trigger events that require automatic termination\
        \ of the session include organization-defined periods of user inactivity,\
        \ targeted responses to certain types of incidents, or time-of-day restrictions\
        \ on system use.\nRelated Controls: MA-4, SC-10, SC-23."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-14
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.5
      ref_id: AC-14
      name: PERMITTED ACTIONS WITHOUT IDENTIFICATION OR AUTHENTICATION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-14-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-14
      ref_id: AC-14-a
      description: Identify any specific user actions that can be performed on the
        system without identification or authentication consistent with organizational
        mission and business functions; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-14-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-14
      ref_id: AC-14-b
      description: Document and provide supporting rationale in the security plan
        for the system, user actions not requiring identification or authentication.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node595
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-14
      description: "Discussion: Specific user actions may be permitted without identification\
        \ or authentication if organizations determine that identification and authentication\
        \ are not required for the specified user actions. Organizations may allow\
        \ a limited number of user actions without identification or authentication,\
        \ including when individuals access public websites or other publicly accessible\
        \ federal systems, when individuals use mobile phones to receive calls, or\
        \ when facsimiles are received. Organizations identify actions that normally\
        \ require identification or authentication but may, under certain circumstances,\
        \ allow identification or authentication mechanisms to be bypassed. Such bypasses\
        \ may occur, for example, via a software-readable physical switch that commands\
        \ bypass of the logon functionality and is protected from accidental or unmonitored\
        \ use. Permitting actions without identification or authentication does not\
        \ apply to situations where identification and authentication have already\
        \ occurred and are not repeated but rather to situations where identification\
        \ and authentication have not yet occurred. Organizations may decide that\
        \ there are no user actions that can be performed on organizational systems\
        \ without identification and authentication, and therefore, the value for\
        \ the assignment operation can be \u201Cnone.\u201D\nRelated Controls: AC-8,\
        \ IA-2, PL-2."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-17
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.5
      ref_id: AC-17
      name: REMOTE ACCESS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-17-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-17
      ref_id: AC-17-a
      description: Establish and document usage restrictions, configuration/connection
        requirements, and implementation guidance for each type of remote access allowed;
        and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-17-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-17
      ref_id: AC-17-b
      description: Authorize each type of remote access to the system prior to allowing
        such connections.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node599
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-17
      description: 'Discussion: Remote access is access to organizational systems
        (or processes acting on behalf of users) that communicate through external
        networks such as the Internet. Types of remote access include dial-up, broadband,
        and wireless. Organizations use encrypted virtual private networks (VPNs)
        to enhance confidentiality and integrity for remote connections. The use of
        encrypted VPNs provides sufficient assurance to the organization that it can
        effectively treat such connections as internal networks if the cryptographic
        mechanisms used are implemented in accordance with applicable laws, executive
        orders, directives, regulations, policies, standards, and guidelines. Still,
        VPN connections traverse external networks, and the encrypted VPN does not
        enhance the availability of remote connections. VPNs with encrypted tunnels
        can also affect the ability to adequately monitor network communications traffic
        for malicious code. Remote access controls apply to systems other than public
        web servers or systems designed for public access. Authorization of each remote
        access type addresses authorization prior to allowing remote access without
        specifying the specific formats for such authorization. While organizations
        may use information exchange and system connection security agreements to
        manage remote access connections to other systems, such agreements are addressed
        as part of CA-3. Enforcing access restrictions for remote access is addressed
        via AC-3.

        Related Controls: AC-2, AC-3, AC-4, AC-18, AC-19, AC-20, CA-3, CM-10, IA-2,
        IA-3, IA-8,

        MA-4, PE- 17, PL-2, PL-4, SC-10, SC-12, SC-13, SI-4.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-17(1)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-17
      ref_id: AC-17(1)
      name: REMOTE ACCESS | MONITORING AND CONTROL
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node601
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-17(1)
      description: Employ automated mechanisms to monitor and control remote access
        methods.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node602
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-17(1)
      description: 'Discussion: Monitoring and control of remote access methods allows
        organizations to detect attacks and help ensure compliance with remote access
        policies by auditing the connection activities of remote users on a variety
        of system components, including servers, notebook computers, workstations,
        smart phones, and tablets. Audit logging for remote access is enforced by
        AU-2. Audit events are defined in AU-2a.

        Related Controls: AU-2, AU-6, AU-12.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-17(2)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-17
      ref_id: AC-17(2)
      name: REMOTE ACCESS | PROTECTION OF CONFIDENTIALITY AND INTEGRITY USING ENCRYPTION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node604
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-17(2)
      description: Implement cryptographic mechanisms to protect the confidentiality
        and integrity of remote access sessions.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node605
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-17(2)
      description: 'Discussion: Virtual private networks can be used to protect the
        confidentiality and integrity of remote access sessions. Transport Layer Security
        (TLS) is an example of a cryptographic protocol that provides end-to-end communications
        security over networks and is used for Internet communications and online
        transactions.

        Related Controls: SC-8, SC-12, SC-13.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-17(3)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-17
      ref_id: AC-17(3)
      name: REMOTE ACCESS | MANAGED ACCESS CONTROL POINTS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node607
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-17(3)
      description: Route remote accesses through authorized and managed network access
        control points.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node608
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-17(3)
      description: "Discussion: Organizations consider the Trusted Internet Connections\
        \ (TIC) initiative requirements for external network connections since limiting\
        \ the number of access control points for remote access reduces attack surfaces.\
        \ \nRelated Controls: SC-7."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-17(4)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-17
      ref_id: AC-17(4)
      name: REMOTE ACCESS | PRIVILEGED COMMANDS AND ACCESS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-17(4)-a
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-17(4)
      ref_id: AC-17(4)-a
      description: 'Authorize the execution of privileged commands and access to security-relevant
        information via remote access only in a format that provides assessable evidence
        and for the following needs: compelling operational needs; and'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-17(4)-b
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-17(4)
      ref_id: AC-17(4)-b
      description: Document the rationale for remote access in the security plan for
        the system.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node612
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-17(4)
      description: 'Discussion: Remote access to systems represents a significant
        potential vulnerability that can be exploited by adversaries. As such, restricting
        the execution of privileged commands and access to security-relevant information
        via remote access reduces the exposure of the organization and the susceptibility
        to threats by adversaries to the remote access capability.

        Related Controls: AC-6, SC-12, SC-13.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-18
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.5
      ref_id: AC-18
      name: WIRELESS ACCESS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-18-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-18
      ref_id: AC-18-a
      description: Establish configuration requirements, connection requirements,
        and implementation guidance for each type of wireless access; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-18-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-18
      ref_id: AC-18-b
      description: Authorize each type of wireless access to the system prior to allowing
        such connections.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node616
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-18
      description: 'Discussion: Wireless technologies include microwave, packet radio
        (ultra-high frequency or very high frequency), 802.11x, and Bluetooth. Wireless
        networks use authentication protocols that provide authenticator protection
        and mutual authentication.

        Related Controls: AC-2, AC-3, AC-17, AC-19, CA-9, CM-7, IA-2, IA-3, IA-8,
        PL-4, SI-4.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-18(1)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-18
      ref_id: AC-18(1)
      name: WIRELESS ACCESS | AUTHENTICATION AND ENCRYPTION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node618
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-18(1)
      description: Protect wireless access to the system using authentication of authorized
        users and agency- controlled devices, and encryption.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node619
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-18(1)
      description: 'Discussion: Wireless networking capabilities represent a significant
        potential vulnerability that can be exploited by adversaries. To protect systems
        with wireless access points, strong authentication of users and devices along
        with strong encryption can reduce susceptibility to threats by adversaries
        involving wireless technologies.

        Related Controls: SC-8, SC-12, SC-13.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-18(3)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-18
      ref_id: AC-18(3)
      name: WIRELESS ACCESS | DISABLE WIRELESS NETWORKING
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node621
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-18(3)
      description: Disable, when not intended for use, wireless networking capabilities
        embedded within system components prior to issuance and deployment.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node622
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-18(3)
      description: 'Discussion: Wireless networking capabilities that are embedded
        within system components represent a significant potential vulnerability that
        can be exploited by adversaries. Disabling wireless capabilities when not
        needed for essential organizational missions or functions can reduce susceptibility
        to threats by adversaries involving wireless technologies.

        Related Controls: None.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-19
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.5
      ref_id: AC-19
      name: ACCESS CONTROL FOR MOBILE DEVICES
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-19-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-19
      ref_id: AC-19-a
      description: Establish configuration requirements, connection requirements,
        and implementation guidance for organization-controlled mobile devices, to
        include when such devices are outside of controlled areas; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-19-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-19
      ref_id: AC-19-b
      description: Authorize the connection of mobile devices to organizational systems.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node626
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-19
      description: 'Discussion: A mobile device is a computing device that has a small
        form factor such that it can easily be carried by a single individual; is
        designed to operate without a physical connection; possesses local, non-removable
        or removable data storage; and includes a self contained power source. Mobile
        device functionality may also include voice communication capabilities, on
        board sensors that allow the device to capture information, and/or built-in
        features for synchronizing local data with remote locations. Examples include
        smart phones and tablets. Mobile devices are typically associated with a single
        individual. The processing, storage, and transmission capability of the mobile
        device may be comparable to or merely a subset of notebook/desktop systems,
        depending on the nature and intendedpurpose of the device. Protection and
        control of mobile devices is behavior or policy-based and requires users to
        take physical action to protect and control such devices when outside of controlled
        areas. Controlled areas are spaces for which organizations provide physical
        or procedural controls to meet the requirements established for protecting
        information and systems. Due to the large variety of mobile devices with different
        characteristics and capabilities, organizational restrictions may vary for
        the different classes or types of such devices. Usage restrictions and specific
        implementation guidance for mobile devices include configuration management,
        device identification and authentication, implementation of mandatory protective
        software, scanning devices for malicious code, updating virus protection software,
        scanning for critical software updates and patches, conducting primary operating
        system (and possibly other resident software) integrity checks, and disabling
        unnecessary hardware. Usage restrictions and authorization to connect may
        vary among organizational systems. For example, the organization may authorize
        the connection of mobile devices to its network and impose a set of usage
        restrictions, while a system owner may withhold authorization for mobile device
        connection to specific applications or impose additional usage restrictions
        before allowing mobile device connections to a system. Adequate security for
        mobile devices goes beyond the requirements specified in AC-19. Many safeguards
        for mobile devices are reflected in other controls. AC-20 addresses mobile
        devices that are not organization-controlled.

        Related Controls: AC-3, AC-4, AC-7, AC-11, AC-17, AC-18, AC-20, CA-9, CM-2,
        CM-6, IA-2,

        IA-3, MP-2, MP-4, MP-5, MP-7, PL-4, SC-7, SI-3, SI-4.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-19(5)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-19
      ref_id: AC-19(5)
      name: ACCESS CONTROL FOR MOBILE DEVICES | FULL DEVICE OR CONTAINER-BASED ENCRYPTION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node628
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-19(5)
      description: Employ full-device encryption to protect the confidentiality and
        integrity of information on full-and limited-feature operating system mobile
        devices authorized to process, store, or transmit CJI.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node629
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-19(5)
      description: 'Discussion: Container-based encryption provides a more fine-grained
        approach to data and information encryption on mobile devices, including encrypting
        selected data structures such as files, records, or fields.

        Related Controls: SC-12, SC-13, SC-28.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-20
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.5
      ref_id: AC-20
      name: USE OF EXTERNAL SYSTEMS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-20-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-20
      ref_id: AC-20-a
      description: 'Establish agency-level policies governing the use of external
        systems consistent with the trust relationships established with other organizations
        owning, operating, and/or maintaining external systems, allowing authorized
        individuals to:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-20-a-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-20-a
      ref_id: AC-20-a-1
      description: Access the system from external systems; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-20-a-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-20-a
      ref_id: AC-20-a-2
      description: Process, store, or transmit organization-controlled information
        using external systems; or
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-20-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-20
      ref_id: AC-20-b
      description: Prohibit the use of personally-owned information systems including
        mobile devices (i.e., bring your own device [BYOD]) and publicly accessible
        systems for accessing, processing, storing, or transmitting CJI.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node635
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-20
      description: 'Discussion: External systems are systems that are used by but
        not part of organizational systems, and for which the organization has no
        direct control over the implementation of required controls or the assessment
        of control effectiveness. External systems include personally-owned systems,
        components, or devices; privately owned computing and communications devices
        in commercial or public facilities; systems owned or controlled by nonfederal
        organizations; systems managed by contractors; and federal information systems
        that are not owned by, operated by, or under the direct supervision or authority
        of the organization. External systems also include systems owned or operated
        by other components within the same organization and systems within the organization
        with different authorization boundaries. Organizations have the option to
        prohibit the use of any type of external system or prohibit the use of specified
        types of external systems, (e.g., prohibit the use of any external system
        that is not organizationally owned or prohibit the use of personally-owned
        systems).

        For some external systems (i.e., systems operated by other organizations),
        the trust relationships that have been established between those organizations
        and the originating organization may be such that no explicit terms and conditions
        are required. Systems within these organizations may not be considered external.
        These situations occur when, for example, there are pre existing information
        exchange agreements (either implicit or explicit) established between organizations
        or components or when such agreements are specified by applicable laws, executive
        orders,directives, regulations, policies, or standards. Authorized individuals
        include organizational personnel, contractors, or other individuals with authorized
        access to organizational systems and over which organizations have the authority
        to impose specific rules of behavior regarding system access. Restrictions
        that organizations impose on authorized individuals need not be uniform, as
        the restrictions may vary depending on trust relationships between organizations.

        Therefore, organizations may choose to impose different security restrictions
        on contractors than on state, local, or tribal governments.

        External systems used to access public interfaces to organizational systems
        are outside the scope of AC-20. Organizations establish specific terms and
        conditions for the use of external systems in accordance with organizational
        security policies and procedures. At a minimum, terms and conditions address
        the specific types of applications that can be accessed on organizational
        systems from external systems and the highest security category of information
        that can be processed, stored, or transmitted on external systems. If the
        terms and conditions with the owners of the external systems cannot be established,
        organizations may impose restrictions on organizational personnel using those
        external systems.

        Related Controls: AC-2, AC-3, AC-17, AC-19, CA-3, PL-2, PL-4, SA-9, SC-7.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-20(1)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-20
      ref_id: AC-20(1)
      name: USE OF EXTERNAL SYSTEMS | LIMITS ON AUTHORIZED USE
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node637
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-20(1)
      description: 'Permit authorized individuals to use an external system to access
        the system or to process, store, or transmit organization-controlled information
        only after:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-20(1)-a
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-20(1)
      ref_id: AC-20(1)-a
      description: "Verification of the implementation of controls on the external\
        \ system as specified in the organization\u2019s security and privacy policies\
        \ and security and privacy plans; or"
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-20(1)-b
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-20(1)
      ref_id: AC-20(1)-b
      description: Retention of approved system connection or processing agreements
        with the organizational entity hosting the external system.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node640
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-20(1)
      description: 'Discussion: Limiting authorized use recognizes circumstances where
        individuals using external systems may need to access organizational systems.
        Organizations need assurance that the external systems contain the necessary
        controls so as not to compromise, damage, or otherwise harm organizational
        systems. Verification that the required controls have been implemented can
        be achieved by external, independent assessments, attestations, or other means,
        depending on the confidence level required by organizations.

        Related Controls: CA-2.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-20(2)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-20
      ref_id: AC-20(2)
      name: "USE OF EXTERNAL SYSTEMS | PORTABLE STORAGE DEVICES \u2014 RESTRICTED\n\
        USE"
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node642
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-20(2)
      description: Restrict the use of organization-controlled portable storage devices
        by authorized individuals on external systems.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node643
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-20(2)
      description: 'Discussion: Limits on the use of organization-controlled portable
        storage devices in external systems include restrictions on how the devices
        may be used and under what conditions the devices may be used.

        Related Controls: MP-7.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-21
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.5
      ref_id: AC-21
      name: INFORMATION SHARING
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-21-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-21
      ref_id: AC-21-a
      description: "Enable authorized users to determine whether access authorizations\
        \ assigned to a sharing partner match the information\u2019s access and use\
        \ restrictions for as defined in an executed information exchange agreement;\
        \ and"
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-21-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-21
      ref_id: AC-21-b
      description: Employ attribute-based access control (see AC-2(d)(3)) or manual
        processes as defined in information exchange agreements to assist users in
        making information sharing and collaboration decisions.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node647
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-21
      description: 'Discussion: Information sharing applies to information that may
        be restricted in some manner based on some formal or administrative determination.
        Examples of such information include, contract-sensitive information, classified
        information related to special access programs or compartments, privileged
        information, proprietary information, and personally identifiable information.
        Security and privacy risk assessments as well as applicable laws, regulations,
        and policies can provide useful inputs to these determinations. Depending
        on the circumstances, sharing partners may be defined at the individual, group,
        or organizational level. Information may be defined by content, type, security
        category, or special access program or compartment. Access restrictions may
        include non-disclosure agreements (NDA). Information flow techniques and security
        attributes may be used to provide automated assistance to users making sharing
        and collaboration decisions.

        Related Controls: AC-3, AC-4, RA-3, SC-15.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-22
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.5
      ref_id: AC-22
      name: PUBLICLY ACCESSIBLE CONTENT
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-22-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-22
      ref_id: AC-22-a
      description: Designate individuals authorized to make information publicly accessible;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-22-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-22
      ref_id: AC-22-b
      description: Train authorized individuals to ensure that publicly accessible
        information does not contain nonpublic information;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-22-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-22
      ref_id: AC-22-c
      description: Review the proposed content of information prior to posting onto
        the publicly accessible system to ensure that nonpublic information is not
        included; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-22-d
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-22
      ref_id: AC-22-d
      description: Review the content on the publicly accessible system for nonpublic
        information quarterly and remove such information, if discovered
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node653
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ac-22
      description: 'Discussion: In accordance with applicable laws, executive orders,
        directives, policies, regulations, standards, and guidelines, the public is
        not authorized to have access to nonpublic information, including information
        protected under the [PRIVACT] and proprietary information. Publicly accessible
        content addresses systems that are controlled by the organization and accessible
        to the public, typically without identification or authentication. Posting
        information on non-

        organizational systems (e.g., non-organizational public websites, forums,
        and social media) is covered by organizational policy. While organizations
        may have individuals who are responsible for developing and implementing policies
        about the information that can be made publicly accessible, publicly accessible
        content addresses the management of the individuals who make such information
        publicly accessible.

        Related Controls: AC-3, AT-2, AT3.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.6
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5
      ref_id: '5.6'
      name: IDENTIFICATION AND AUTHENTICATION (IA)
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node655
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.6
      description: "Identification is a unique, auditable representation of an identity\
        \ within an information system usually in the form of a simple character string\
        \ for each individual user, machine, software component, or any other entity.\
        \ Authentication refers to mechanisms or processes to verify the identity\
        \ of a user, process, or device, as a prerequisite to allowing access to a\
        \ system\u2019s resources."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-0
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.6
      ref_id: IA-0
      name: USE OF ORIGINATING AGENCY IDENTIFIERS IN TRANSACTIONS AND INFORMATION
        EXCHANGES
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node657
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-0
      description: An FBI authorized originating agency identifier (ORI) shall be
        used in each transaction on CJIS systems in order to identify the sending
        agency and to ensure the proper level of access for each transaction. The
        original identifier between the requesting agency and the CSA/SIB/Channeler
        shall be the ORI, and other agency identifiers, such as user identification
        or personal identifier, an access device mnemonic, or the Internet Protocol
        (IP) address.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node658
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-0
      description: "Agencies may act as a servicing agency and perform transactions\
        \ on behalf of authorized agencies requesting the service. Servicing agencies\
        \ performing inquiry transactions on behalf of another agency may do so using\
        \ the requesting agency\u2019s ORI. Servicing agencies may also use their\
        \ own ORI to perform inquiry transactions on behalf of a requesting agency\
        \ if the means and procedures are in place to provide an audit trail for the\
        \ current specified retention period. Because the agency performing the transaction\
        \ may not necessarily be the same as the agency requesting the transaction,\
        \ the CSA/SIB/Channeler shall ensure that the ORI for each transaction can\
        \ be traced, via audit trail, to the specific agency which is requesting the\
        \ transaction."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node659
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-0
      description: 'Audit trails can be used to identify the requesting agency if
        there is a reason to inquire into the details surrounding why an agency ran
        an inquiry on a subject. Agencies assigned a limited access ORI shall not
        use the full access ORI of another agency to conduct an inquiry transaction.

        NOTE: This control will be included in AC-3 Access Enforcement when modernized'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-1
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.6
      ref_id: IA-1
      name: POLICY AND PROCEDURES
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-1-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-1
      ref_id: IA-1-a
      description: 'Develop, document, and disseminate to authorized personnel:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-1-a-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-1-a
      ref_id: IA-1-a-1
      description: 'Agency/Entity identification and authentication policy that:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-1-a-1-a
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-1-a-1
      ref_id: IA-1-a-1-a
      description: 'Addresses purpose, scope, roles, responsibilities, management
        commitment,

        coordination among organizational entities, and compliance; and'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-1-a-1-b
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-1-a-1
      ref_id: IA-1-a-1-b
      description: 'Is consistent with applicable laws, executive orders, directives,
        regulations, policies,

        standards, and guidelines; and'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-1-a-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-1-a
      ref_id: IA-1-a-2
      description: Procedures to facilitate the implementation of the identification
        and authentication policy and the associated identification and authentication
        controls;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-1-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-1
      ref_id: IA-1-b
      description: 'Designate an individual with security responsibilities to manage
        the development,

        documentation, and dissemination of the identification and authentication
        policy and procedures; and'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-1-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-1
      ref_id: IA-1-c
      description: 'Review and update the current identification and authentication:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-1-c-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-1-c
      ref_id: IA-1-c-1
      description: Policy annually and following any security incidents involving
        unauthorized access to CJI or systems used to process, store, or transmit
        CJI; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-1-c-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-1-c
      ref_id: IA-1-c-2
      description: Procedures annually and following any security incidents involving
        unauthorized access to CJI or systems used to process, store, or transmit
        CJI.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node670
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-1
      description: 'DISCUSSION: Identification and authentication policy and procedures
        address the controls in the IA family that are implemented within systems
        and organizations. The risk management strategy is an important factor in
        establishing such policies and procedures. Policies and procedures contribute
        to security and privacy assurance. Therefore, it is important that security
        and privacy programs collaborate on the development of identification and
        authentication policy and procedures. Security and privacy program policies
        and procedures at the organization level are preferable, in general, and may
        obviate the need for mission- or system-specific policies and procedures.
        The policy can be included as part of the general security and privacy policy
        or be represented by multiple policies that reflect the complex nature of
        organizations. Procedures can be established for security and privacy programs,
        for mission or business processes, and for systems, if needed. Procedures
        describe how the policies or controls are implemented and can be directed
        at the individual or role that is the object of the procedure. Procedures
        can be documented in system security and privacy plans or in one or more separate
        documents. Events that may precipitate an update to identification and authentication
        policy and procedures include assessment or audit findings, security incidents
        or breaches, or changes in applicable laws, executive orders, directives,
        regulations, policies, standards, and guidelines. Simply restating controls
        does not constitute an organizational policy or procedure.

        Related Controls: AC-1, PS-8, SI-12.

        Control Enhancements: None.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-2
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.6
      ref_id: IA-2
      name: IDENTIFICATION AND AUTHENTICATION (ORGANIZATIONAL USERS)
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node672
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-2
      description: Uniquely identify and authenticate organizational users and associate
        that unique identification with processes acting on behalf of those users.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node673
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-2
      description: 'DISCUSSION: Organizations can satisfy the identification and authentication
        requirements by complying with the requirements in [HSPD 12]. Organizational
        users include employees or individuals who organizations consider to have
        an equivalent status to employees (e.g., contractors and guest researchers).
        Unique identification and authentication of users applies to all accesses
        other than those that are explicitly identified in AC-14 and that occur through
        the authorized use of group authenticators without individual authentication.
        Since processes execute on behalf of groups and roles, organizations may require
        unique identification of individuals in group accounts or for detailed accountability
        of individual activity.

        Organizations employ passwords, physical authenticators, or biometrics to
        authenticate user identities or, in the case of multi-factor authentication,
        some combination thereof. Access to organizational systems is defined as either
        local access or network access. Local access is any access to organizational
        systems by users or processes acting on behalf of users, where access is obtained
        through direct connections without the use of networks. Network access is
        access to organizational systems by users (or processes acting on behalf of
        users) where access is obtainedthrough network connections (i.e., nonlocal
        accesses). Remote access is a type of network access that involves communication
        through external networks. Internal networks include local area networks and
        wide area networks.

        The use of encrypted virtual private networks for network connections between
        organizationcontrolled endpoints and non-organization-controlled endpoints
        may be treated as internal networks with respect to protecting the confidentiality
        and integrity of information traversing the network. Identification and authentication
        requirements for non-organizational users are described in IA-8.

        Related Controls: AC-2, AC-3, AC-4, AC-14, AC-17, AC-18, AU-1, AU-6, IA-4,
        IA-5, IA-8, MA-4, MA-5, PE-2, PL-4, SA-4, SA-8'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-2(1)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-2
      ref_id: IA-2(1)
      name: IDENTIFICATION AND AUTHENTICATION (ORGANIZATIONAL USERS) | MULTIFACTOR
        AUTHENTICATION TO PRIVILEGED ACCOUNTS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node675
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-2(1)
      description: Implement multi-factor authentication for access to privileged
        accounts
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node676
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-2(1)
      description: 'DISCUSSION: Multi-factor authentication requires the use of two
        or more different factors to achieve authentication. The authentication factors
        are defined as follows: something you know (e.g., a personal identification
        number [PIN]), something you have (e.g., a physical authenticator such as
        a cryptographic private key), or something you are (e.g., a biometric). Multi-factor
        authentication solutions that feature physical authenticators include hardware
        authenticators that provide time-based or challenge-response outputs and smart
        cards such as the U.S. Government Personal Identity Verification (PIV) card
        or the Department of Defense (DoD) Common Access Card (CAC). In addition to
        authenticating users at the system level (i.e., at logon), organizations may
        employ authentication mechanisms at the application level, at their discretion,
        to provide increased security. Regardless of the type of access (i.e., local,
        network, remote), privileged accounts are authenticated using multi-factor
        options appropriate for the level of risk. Organizations can add additional
        security measures, such as additional or more rigorous authentication mechanisms,
        for specific types of access.

        Related Controls: AC-5, AC-6.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-2(2)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-2
      ref_id: IA-2(2)
      name: IDENTIFICATION AND AUTHENTICATION (ORGANIZATIONAL USERS) | MULTIFACTOR
        AUTHENTICATION TO NON-PRIVILEGED ACCOUNTS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node678
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-2(2)
      description: Implement multi-factor authentication for access to non-privileged
        accounts.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node679
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-2(2)
      description: 'DISCUSSION: Multi-factor authentication requires the use of two
        or more different factors to achieve authentication. The authentication factors
        are defined as follows: something you know (e.g., a personal identification
        number [PIN]), something you have (e.g., a physical authenticator such as
        a cryptographic private key), or something you are (e.g., a biometric). Multi-factor
        authentication solutions that feature physical authenticators include hardware
        authenticators that provide time-based or challenge-response outputs and smart
        cards such as the U.S. Government Personal Identity Verification card or the
        DoD Common Access Card. In addition to authenticating users at the system
        level, organizations may also employ authentication mechanisms at the application
        level, at their discretion, to provide increased information security. Regardless
        of the type of access (i.e., local, network, remote), non-privileged accounts
        are authenticated using multifactor options appropriate for the level of risk.
        Organizations can provide additional security measures, such as additional
        or more rigorous authentication mechanisms, for specific types of access.

        Related Controls: AC-5.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-2(8)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-2
      ref_id: IA-2(8)
      name: "IDENTIFICATION AND AUTHENTICATION (ORGANIZATIONAL USERS) | ACCESS TO\
        \ ACCOUNTS \u2014 REPLAY RESISTANT"
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node681
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-2(8)
      description: Implement replay-resistant authentication mechanisms for access
        to privileged and non-privileged accounts.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node682
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-2(8)
      description: 'DISCUSSION: Authentication processes resist replay attacks if
        it is impractical to achieve successful authentications by replaying previous
        authentication messages. Replay-resistant techniques include protocols that
        use nonces or challenges such as time synchronous or cryptographic authenticators.

        Related Controls: None.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-2(12)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-2
      ref_id: IA-2(12)
      name: IDENTIFICATION AND AUTHENTICATION (ORGANIZATIONAL USERS) | ACCEPTANCE
        OF PIV CREDENTIALS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node684
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-2(12)
      description: Accept and electronically verify Personal Identity Verification-compliant
        credentials.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node685
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-2(12)
      description: 'DISCUSSION: Acceptance of Personal Identity Verification (PIV)-compliant
        credentials applies to organizations implementing logical access control and
        physical access control systems. PIVcompliant credentials are those credentials
        issued by federal agencies that conform to FIPS Publication 201 and supporting
        guidance documents. The adequacy and reliability of PIV card issuers are authorized
        using [SP 800-79-2]. Acceptance of PIV-compliant credentials includes derived
        PIV credentials, the use of which is addressed in [SP 800-166]. The DOD Common
        Access Card (CAC) is an example of a PIV credential.

        Related Controls: None.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-3
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.6
      ref_id: IA-3
      name: DEVICE IDENTIFICATION AND AUTHENTICATION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node687
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-3
      description: Uniquely identify and authenticate agency-managed devices before
        establishing network connections. In the instance of local connection, the
        device must be approved by the agency and the device must be identified and
        authenticated prior to connection to an agency asset.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node688
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-3
      description: 'DISCUSSION: Devices that require unique device-to-device identification
        and authentication are defined by type, device, or a combination of type and
        device. Organization-defined device types include devices that are not owned
        by the organization. Systems use shared known information (e.g., Media Access
        Control [MAC], Transmission Control Protocol/Internet Protocol [TCP/IP] addresses)
        for device identification or organizational authentication solutions (e.g.,
        Institute of Electrical and Electronics Engineers (IEEE) 802.1x and Extensible
        Authentication Protocol [EAP], RADIUS server with EAP-Transport Layer Security
        [TLS] authentication, Kerberos) to identify and authenticate devices on local
        and wide area networks. Organizations determine the required strength of authentication
        mechanisms based on the security categories of systems and mission or business
        requirements. Because of the challenges of implementing device authentication
        on a large scale, organizations can restrict the application of the control
        to a limited number/type of devices based on mission or business needs.

        Related Controls: AC-17, AC-18, AC-19, AU-6, CA-3, CA-9, IA-4, IA-5, IA-11,
        SI-4.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-4
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.6
      ref_id: IA-4
      name: IDENTIFIER MANAGEMENT
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node690
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-4
      description: 'Manage system identifiers by:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-4-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-4
      ref_id: IA-4-a
      description: Receiving authorization from organizational personnel with identifier
        management responsibilities to assign an individual, group, role, service,
        or device identifier;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-4-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-4
      ref_id: IA-4-b
      description: Selecting an identifier that identifies an individual, group, role,
        service, or device;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-4-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-4
      ref_id: IA-4-c
      description: Assigning the identifier to the intended individual, group, role,
        service, or device; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-4-d
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-4
      ref_id: IA-4-d
      description: Preventing reuse of identifiers for one (1) year.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node695
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-4
      description: 'DISCUSSION: Common device identifiers include Media Access Control
        (MAC) addresses, Internet Protocol (IP) addresses, or device-unique token
        identifiers. The management of individual identifiers is not applicable to
        shared system accounts. Typically, individual identifiers are the usernames
        of the system accounts assigned to those individuals. In such instances, the
        account management activities of AC-2 use account names provided by IA-4.
        Identifier management also addresses individual identifiers not necessarily
        associated with system accounts. Preventing the reuse of identifiers implies
        preventing the assignment of previously used individual, group, role, service,
        or device identifiers to different individuals, groups, roles, services, or
        devices.

        Related Controls: AC-5, IA-2, IA-3, IA-5, IA-8, IA-12, MA-4, PE-2, PE-3, PE-4,
        PL-4, PS-3, PS4, PS-5.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-4(4)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-4
      ref_id: IA-4(4)
      name: IDENTIFIER MANAGEMENT | IDENTIFY USER STATUS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node697
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-4(4)
      description: Manage individual identifiers by uniquely identifying each individual
        as agency or nonagency.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node698
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-4(4)
      description: 'DISCUSSION: Characteristics that identify the status of individuals
        include contractors, foreign nationals, and non-organizational users. Identifying
        the status of individuals by these characteristics provides additional information
        about the people with whom organizational personnel are communicating. For
        example, it might be useful for a government employee to know that one of
        the individuals on an email message is a contractor.

        Related Controls: None.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.6
      ref_id: IA-5
      name: AUTHENTICATOR MANAGEMENT
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node700
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5
      description: 'Manage system authenticators by:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-a
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node700
      ref_id: IA-5-a
      description: Verifying, as part of the initial authenticator distribution, the
        identity of the individual, group, role, service, or device receiving the
        authenticator;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-b
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node700
      ref_id: IA-5-b
      description: Establishing initial authenticator content for any authenticators
        issued by the organization;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-c
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node700
      ref_id: IA-5-c
      description: Ensuring that authenticators have sufficient strength of mechanism
        for their intended use
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-d
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node700
      ref_id: IA-5-d
      description: Establishing and implementing administrative procedures for initial
        authenticator distribution, for lost or compromised or damaged authenticators,
        and for revoking authenticators;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-e
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node700
      ref_id: IA-5-e
      description: Changing default authenticators prior to first use;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-f
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node700
      ref_id: IA-5-f
      description: Changing or refreshing authenticators annually or when there is
        evidence of authenticator compromise;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-g
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node700
      ref_id: IA-5-g
      description: Protecting authenticator content from unauthorized disclosure and
        modification;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-h
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node700
      ref_id: IA-5-h
      description: Requiring individuals to take, and having devices implement, specific
        controls to protect authenticators; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-i
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node700
      ref_id: IA-5-i
      description: Changing authenticators for group or role accounts when membership
        to those accounts changes.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-j
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node700
      ref_id: IA-5-j
      description: AAL2 Specific Requirements
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node711
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-j
      description: 'All credential service providers (CSPs) authenticating claimants
        at Authenticator Assurance Level 2 (AAL2) SHALL be assessed on the following
        criteria:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-j-1
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node711
      ref_id: IA-5-j-1
      description: Authentication SHALL occur by the use of either a multi-factor
        authenticator or a combination of two single-factor authenticators.
      annotation: 'SUPPLEMENTAL GUIDANCE: A multi-factor authenticator requires two
        factors to execute a single authentication event, such as a cryptographically-
        secure device with an integrated biometric sensor that is required to activate
        the device. Nine different authenticator types are recognized, representing
        something you know (a memorized secret), something you have (a physical authenticator),
        or combinations of physical authenticators with either memorized secrets or
        biometric modalities (something you are). Multi-factor (MF) authentication
        is required at AAL2. MF authentication at AAL2 may be performed using the
        following AAL2 permitted authenticator types: MF OTP Device, MF Crypto Software,
        or MF Crypto Device; or a memorized secret used in combination with the following
        permitted single-factor authenticators: Look-Up Secret, Out-of-Band authenticator,
        SF OTP Device, SF Crypto Software, or SF Crypto Device.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-j-2
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node711
      ref_id: IA-5-j-2
      description: If the multi-factor authentication process uses a combination of
        two single-factor authenticators, then it SHALL include a Memorized Secret
        authenticator and a possession-based authenticator.
      annotation: 'SUPPLEMENTAL GUIDANCE: Multifactor authentication requires the
        use of two different authentication factors. See IA-5 j (1) for permitted
        authenticator types at AAL2.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-j-3
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node711
      ref_id: IA-5-j-3
      description: Cryptographic authenticators used at AAL2 SHALL use approved cryptography.
      annotation: 'SUPPLEMENTAL GUIDANCE: Cryptography is considered approved if it
        is specified or adopted in a FIPS or NIST recommendation. Since verifiers
        and cryptographic authenticators must use the same algorithms to successfully
        authenticate, assessment of the verifier also assesses the authenticators
        that may be used.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-j-4
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node711
      ref_id: IA-5-j-4
      description: At least one authenticator used at AAL2 SHALL be replay resistant
      annotation: 'SUPPLEMENTAL GUIDANCE: Replay resistance is a characteristic of
        most, although not all, physical authenticators. A given output of the authenticator
        is required to be accepted for only one authentication transaction. For example,
        the output of a time-based OTP device or an out-of-band device is considered
        replay resistant if it can only be used for at most one authentication transaction
        during its validity period. If it can be used for more than one during this
        period, it is not replay resistant.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-j-5
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node711
      ref_id: IA-5-j-5
      description: Communication between the claimant and verifier SHALL be via an
        authenticated protected channel.
      annotation: 'SUPPLEMENTAL GUIDANCE: Communication between claimant or user and
        verifier or agency is required to be via an encrypted channel that authenticates
        the verifier to provide confidentiality of the authenticator output and resistance
        to Man-in-the-Middle (MitM) attacks. This is typically accomplished using
        the Transport Level Security (TLS) protocol. Mutual authentication of the
        communication channel is not required unless that is part of the process of
        authenticating the claimant. Accordingly, the verifier is only responsible
        the use of an appropriately secure communications protocol.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-j-6
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node711
      ref_id: IA-5-j-6
      description: Verifiers operated by government agencies at AAL2 SHALL be validated
        to meet the requirements of FIPS 140 Level 1.
      annotation: 'SUPPLEMENTAL GUIDANCE: Verifiers operated by or on behalf of government
        agencies are required to be validated to meet FIPS 140 requirements. The FIPS
        140 requirements generally apply to cryptographic modules (both hardware and
        software).'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-j-7
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node711
      ref_id: IA-5-j-7
      description: Authenticators procured by government agencies SHALL be validated
        to meet the requirements of FIPS 140 Level 1.
      annotation: 'SUPPLEMENTAL GUIDANCE: The FIPS 140 requirements generally apply
        to cryptographic modules (both hardware and software). While authenticators
        are not directly the responsibility of the CSP (particularly in the case of
        bring- your-own authenticators), the CSP is still responsible for ensuring
        that a sufficiently strong and FIPS 140 validated authenticator is being used.
        Binding of CSP-supplied authenticators that are known to meet validation criteria
        is sufficient.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-j-8
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node711
      ref_id: IA-5-j-8
      description: If a device such as a smartphone is used in the authentication
        process, then the unlocking of that device (typically done using a PIN or
        biometric) SHALL NOT be considered one of the authentication factors.
      annotation: 'SUPPLEMENTAL GUIDANCE: This requirement applies to multi-factor
        authenticators resident on a smartphone or similar device; single-factor authenticators
        on such devices would only provide a single (physical) authentication factor.
        Unlocking of a device such as a smartphone may be done for any number of reasons
        unrelated to authentication, and such devices are normally in an unlocked
        state for a period of time thereafter. Human action such as entry of a memorized
        secret or presentation of a biometric factor needs to be provided that is
        directly associated with the authentication event. Generally, it is not possible
        for a verifier to know that the device had been locked or if the unlock process
        met the requirements for the relevant authenticator type.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-j-9
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node711
      ref_id: IA-5-j-9
      description: If a biometric factor is used in authentication at AAL2, then the
        performance requirements stated in IA-5 m Biometric Requirements SHALL be
        met.
      annotation: 'SUPPLEMENTAL GUIDANCE: Detailed conformance criteria applicable
        to the use of biometrics are contained in section IA-5 m Biometric Requirements.
        Since verification of biometric factors is not deterministic due to measurement
        errors in collection of the biometric information, evaluation of performance,
        and, most importantly, false accept rate, is important to ensure security
        of the authentication process.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-j-10
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node711
      ref_id: IA-5-j-10
      description: Reauthentication of the subscriber SHALL be repeated at least once
        per 12 hours during an extended usage session.
      annotation: 'SUPPLEMENTAL GUIDANCE: Reauthentication is required to mitigate
        the risks associated with an authenticated endpoint that has been abandoned
        by the subscriber or has been misappropriated by an attacker while authenticated.
        At AAL2, providing a memorized secret or biometric factor is sufficient for
        reauthentication prior to the expiration time.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-j-11
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node711
      ref_id: IA-5-j-11
      description: Reauthentication of the subscriber SHALL be repeated following
        any period of inactivity lasting 30 minutes or longer.
      annotation: 'SUPPLEMENTAL GUIDANCE: Reauthentication is required to mitigate
        the risks associated with an authenticated endpoint that has been abandoned
        by the subscriber or has been misappropriated by an attacker while authenticated.
        At AAL2, providing a memorized secret or biometric factor is sufficient for
        reauthentication prior to the expiration time.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-j-12
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node711
      ref_id: IA-5-j-12
      description: The CSP SHALL employ appropriately tailored security controls from
        the moderate baseline of security controls defined in the CJISSECPOL
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node724
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node711
      description: The CSP SHALL ensure that the minimum assurance-related controls
        for moderateimpact systems are satisfied.
      annotation: "SUPPLEMENTAL GUIDANCE: NIST SP 800-53 provides a comprehensive\
        \ catalog of controls, three security control baselines (low, moderate, and\
        \ high impact), and guidance for tailoring the appropriate baseline to specific\
        \ needs and risk environments for federal information systems. These controls\
        \ are the operational, technical, and management safeguards to maintain the\
        \ integrity, confidentiality, and security of federal information systems\
        \ and are intended to be used in conjunction with the NIST risk management\
        \ framework outlined in SP 800-37 and SP 800-63-3 section 5 Digital Identity\
        \ Risk Management. NIST SP 800-53 presents security control baselines determined\
        \ by the security categorization of the information system (low, moderate\
        \ or high) from NIST FIPS 199 Standards for Security Categorization of Federal\
        \ Information and Information Systems. \nFor IAL2, the moderate baseline controls\
        \ (see https://nvd.nist.gov/80053/Rev4/impact/moderate) may be considered\
        \ the starting point for the selection, enhancement, and tailoring of the\
        \ security controls presented. Guidance on tailoring the control baselines\
        \ to best meet the organization\u2019s risk environment, systems and operations\
        \ is presented in SP 800- 53 section 3.2. Tailoring Baseline Security Controls.\
        \ \nWhile SP 800-53 and other NIST Special Publications in the SP-800-XXX\
        \ series apply to federal agencies for the implementation of the Federal information\
        \ Security Management Act (FISMA), non-federal entities providing services\
        \ for federal information services also are subject to FISMA and should similarly\
        \ use SP 800-53 and associated publications for appropriate controls. Non-federal\
        \ entities may be subject to and conformant with other applicable controls\
        \ systems and processes for information system security (e.g., FEDRAMP, ISO/IEC\
        \ 27001). SP-63A allows the application of equivalent controls from such standards\
        \ and processes to meet conformance with this criterion."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-j-13
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node711
      ref_id: IA-5-j-13
      description: The CSP SHALL comply with records retention policies i n accordance
        with applicable laws and regulations.
      annotation: 'SUPPLEMENTAL GUIDANCE: It is recommended that CSPs document any
        specific retention policies they are subject to, in accordance with applicable
        laws, regulations, or policies, including any National Archives and Records
        Administration (NARA) records retention schedules that may apply.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node726
      assessable: true
      depth: 8
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-j-13
      description: The CSP is responsible for the proper handling, protection, and
        retention or disposal of any sensitive data it collects, even after it ceases
        to provide identity proofing and enrollment services. A CSP may document its
        policies and procedures for the management of the data is collects in a data
        handling plan or other document.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-j-14
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node711
      ref_id: IA-5-j-14
      description: If the CSP opts to retain records in the absence of any mandatory
        requirements, then the CSP SHALL conduct a risk management process, including
        assessments of privacy and security risks to determine how long records should
        be retained and SHALL inform subscribers of that retention policy.
      annotation: 'SUPPLEMENTAL GUIDANCE: This is a conditional requirement and depends
        on the basis for CSP records retention. Absent clear jurisdictional requirements,
        risk management processes, including privacy and security risk assessment,
        need to be performed for records retention decisions. The records retention
        duration is required to be derived from a risk-based decision process.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-k
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node700
      ref_id: IA-5-k
      description: Privacy requirements that apply to all CSPs, verifiers, and RPs
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-k-1
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-k
      ref_id: IA-5-k-1
      description: The CSP SHALL employ appropriately tailored privacy controls from
        the CJISSECPOL.
      annotation: 'SUPPLEMENTAL GUIDANCE: This requirement establishes overall privacy
        posture of the CSP.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-k-2
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-k
      ref_id: IA-5-k-2
      description: "If the CSP processes attributes for purposes other than identity\
        \ proofing, authentication, or attribute assertions (collectively \u201Cidentity\
        \ service\u201D), related fraud mitigation, or to comply with law or legal\
        \ process, then the CSP SHALL implement measures to maintain predictability\
        \ and manageability commensurate with the associated privacy risk."
      annotation: "SUPPLEMENTAL GUIDANCE: Predictability and manageability measures\
        \ include providing clear notice, obtaining subscriber consent, and enabling\
        \ selective use or disclosure of attributes. Predictability is meant to build\
        \ trust and provide accountability and requires full understanding (and disclosure)\
        \ of how the attribute information will be used. Manageability also builds\
        \ trust by demonstrating a CSPs ability to control attribute information throughout\
        \ processing \u2013 collection, maintenance, retention."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-l
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node700
      ref_id: IA-5-l
      description: General requirements applicable to AAL2 authentication process
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-l-1
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-l
      ref_id: IA-5-l-1
      description: CSPs SHALL provide subscriber instructions on how to appropriately
        protect a physical authenticator against theft or loss.
      annotation: 'SUPPLEMENTAL GUIDANCE: Instruction should address aspects of protecting
        the specific type of authenticator being used.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-l-2
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-l
      ref_id: IA-5-l-2
      description: The CSP SHALL provide a mechanism to revoke or suspend the authenticator
        immediately upon notification from subscriber that loss or theft of the authenticator
        is suspected.
      annotation: 'SUPPLEMENTAL GUIDANCE: The CSP needs to have a documented procedure
        to allow subscribers to report lost or stolen physical authenticators, and
        to revoke or suspend such authenticators promptly when reported.Subscribers
        need to be instructed (see GEN-1) the procedure for reporting loss or theft.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-l-3
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-l
      ref_id: IA-5-l-3
      description: If required by the authenticator type descriptions in IA-5(1),
        then the verifier SHALL implement controls to protect against online guessing
        attacks.
      annotation: 'SUPPLEMENTAL GUIDANCE: Throttling or rate limiting is key to resistance
        against online guessing attacks. This is generally required for memorized
        secrets or when the authenticator output of a look-up secret, OOB, or OTP
        authenticator may have less than 64 bits of entropy.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-l-4
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-l
      ref_id: IA-5-l-4
      description: If required by the authenticator type descriptions in IA-5(1) and
        the description of a given authenticator does not specify otherwise, then
        the verifier SHALL limit consecutive failed authentication attempts on a single
        account to no more than 100.
      annotation: "SUPPLEMENTAL GUIDANCE: Throttling or rate limiting is key to resistance\
        \ against online guessing attacks. It is important that it be implemented\
        \ in a non-abrupt manner as described in the specification so that it is not\
        \ usable as a denial-of-service mechanism by an attacker. Additional techniques\
        \ MAY be used to reduce the likelihood that an attacker will lock the legitimate\
        \ claimant out as a result of rate limiting. These include: \n\u2022\tRequiring\
        \ the claimant to complete a CAPTCHA before attempting authentication.\n\u2022\
        Requiring the claimant to wait following a failed attempt for a period of\
        \ time that increases as the account approaches its maximum allowance for\
        \ consecutive failed attempts (e.g., 30 seconds up to an hour).\n\u2022Accepting\
        \ only authentication requests that come from a white list of IP addresses\
        \ from which the subscriber has been successfully authenticated before.Leveraging\
        \ other risk-based or adaptive authentication techniques to identify user\
        \ behavior that falls within, or out of, typical norms. These might, for example,\
        \ include use of IP address, geolocation, timing of request patterns, or browser\
        \ metadata."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-l-5
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-l
      ref_id: IA-5-l-5
      description: If signed attestations are used, then they SHALL be signed using
        a digital signature that provides at least the minimum security strength specified
        in the latest revision of 112 bits as of the date of this publication
      annotation: 'SUPPLEMENTAL GUIDANCE: Attestations are sometimes provided by cryptographic
        authenticators to securely indicate their capabilities, e.g., that they are
        hardware-based or that they have characteristics such as two-factor capability.
        For the attestations to be useful, these signatures need to use algorithms
        and keys that are sufficiently strong.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-l-6
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-l
      ref_id: IA-5-l-6
      description: If the verifier and CSP are separate entities (as shown by the
        dotted line in Figure 6 Digital Identity Model), then communications between
        the verifier and CSP SHALL occur through a mutually-authenticated secure channel
        (such as a client-authenticated TLS connection).
      annotation: 'SUPPLEMENTAL GUIDANCE: In cases where the verifier and CSP are
        separate, it is important that this not create additional security vulnerabilities
        as compared with an integrated verifier/CSP combination. This requirement
        ensures that there is not an opportunity to perform eavesdropping or active
        attacks on the channel between them.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-l-7
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-l
      ref_id: IA-5-l-7
      description: If the CSP provides the subscriber with a means to report loss,
        theft, or damage to an authenticator using a backup or alternate authenticator,
        then that authenticator SHALL be either a memorized secret or a physical authenticator.
      annotation: 'SUPPLEMENTAL GUIDANCE: It is important that the loss of control
        of an authenticator be quickly reported to the CSP. To balance between the
        need to easily and promptly report this and the risk of a fraudulent report,
        a backup authenticator, either a memorized secret or physical authenticator,
        should be usable by the subscriber to make this report. Only a single, single-factor
        authenticator is required.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-l-8
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-l
      ref_id: IA-5-l-8
      description: If the CSP chooses to verify an address of record (i.e., email,
        telephone, postal) and suspend authenticator(s) reported to have been compromised,
        then...The suspension SHALL be reversible if the subscriber successfully authenticates
        to the CSP using a valid (i.e., not suspended) authenticator and requests
        reactivation of an authenticator suspended in this manner.
      annotation: 'SUPPLEMENTAL GUIDANCE: Reversibility of suspension is intended
        to minimize the impact of inadvertent loss reports from the subscriber and
        in some cases from an attacker who may be attempting to deny service to the
        subscriber'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-l-9
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-l
      ref_id: IA-5-l-9
      description: If and when an authenticator expires, it SHALL NOT be usable for
        authentication.
      annotation: 'SUPPLEMENTAL GUIDANCE: Expiration is used by some CSPs to limit
        the security exposure from an authenticator that is lost but the loss has
        not been detected/reported and revoked.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-l-10
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-l
      ref_id: IA-5-l-10
      description: The CSP SHALL have a documented process to require subscribers
        to surrender or report the loss of any physical authenticator containing attribute
        certificates signed by the CSP as soon as practical after expiration or receipt
        of a renewed authenticator.
      annotation: 'SUPPLEMENTAL GUIDANCE: The requirement for surrender or destruction
        of expired authenticators minimizes the possibility that authentication with
        an expired authenticator will be attempted. PKI-based authenticators that
        are collected or known to be destroyed also do not need to be included in
        certificate revocation lists.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-l-11
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-l
      ref_id: IA-5-l-11
      description: "CSPs SHALL revoke the binding of authenticators immediately upon\
        \ notification when an online identity ceases to exist (e.g., subscriber\u2019\
        s death, discovery of a fraudulent subscriber), when requested by the subscriber,\
        \ or when the CSP determines that the subscriber no longer meets its eligibility\
        \ requirements"
      annotation: "SUPPLEMENTAL GUIDANCE: Prompt revocation ensures that unauthorized\
        \ parties are not able to use the authenticator to make unauthorized access\
        \ to the subscriber account. Revocation at subscriber request can affect only\
        \ a single authenticator; the other classes of revocation generally affect\
        \ all authenticators associated with the subscriber\u2019s account."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-l-12
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-l
      ref_id: IA-5-l-12
      description: The CSP SHALL have a documented process to require subscribers
        to surrender or report the loss of any physical authenticator containing certified
        attributes signed by the CSP within five (5) days after revocation or termination
        takes place.
      annotation: "SUPPLEMENTAL GUIDANCE: This requirement blocks the use of the authenticator\u2019\
        s certified attributes in offline situations between revocation/termination\
        \ and expiration of the certification. Prompt revocation ensures that unauthorized\
        \ parties are not able to use the authenticator to make unauthorized access\
        \ to the subscriber account. Collection or destruction also minimizes the\
        \ dependence on (and growth of) certificate revocation lists, which are not\
        \ always 100% effective in accomplishing revocation, particularly in offline\
        \ situations."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-m
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node700
      ref_id: IA-5-m
      description: Biometric Requirements
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-m-1
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-m
      ref_id: IA-5-m-1
      description: Biometrics SHALL be used only as part of multi-factor authentication
        with a physical authenticator (something you have).
      annotation: "SUPPLEMENTAL GUIDANCE: For a variety of reasons listed here, a\
        \ biometric factor is not considered to be an authenticator by itself. The\
        \ risks associated with biometric factors are largely mitigated by binding\
        \ the biometric with a specific physical authenticator. \n\u2022\tThe biometric\
        \ False Match Rate (FMR) does not provide confidence in the authentication\
        \ of the subscriber by itself. In addition, FMR does not account for spoofing\
        \ attacks.\n\u2022\tBiometric comparison is probabilistic, whereas the other\
        \ authentication factors are deterministic.\n\u2022\tBiometric template protection\
        \ schemes provide a method for revoking biometric credentials that is comparable\
        \ to other authentication factors (e.g., PKI certificates and passwords).\
        \ However, the availability of such solutions is limited, and standards for\
        \ testing these methods are under development.\n\u2022\tBiometric characteristics\
        \ do not constitute secrets. They can be obtained online or by taking a picture\
        \ of someone with a camera phone (e.g., facial images) with or without their\
        \ knowledge, lifted from objects someone touches (e.g., latent fingerprints),\
        \ or captured with high resolution images (e.g., iris patterns). While presentation\
        \ attack detection (PAD) technologies (e.g., liveness detection) can mitigate\
        \ the risk of these types of attacks, additional trust in the sensor or biometric\
        \ processing is required to ensure that PAD is operating in accordance with\
        \ the needs of the CSP and the subscriber."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-m-2
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-m
      ref_id: IA-5-m-2
      description: An authenticated protected channel between sensor (or an endpoint
        containing a sensor that resists sensor replacement) and verifier SHALL be
        established.
      annotation: "SUPPLEMENTAL GUIDANCE: This requirement ensures that biometric\
        \ data that flows across the network to the verifier is protected from disclosure\
        \ and that an attacker cannot substitute a \u201Cskimmer\u201D or other fraudulent\
        \ replacement for the biometric sensor. If the biometric factor is verified\
        \ directly on a multi-factor authenticator and the sensor is tightly integrated\
        \ with it, that local connection does not require an authenticated protected\
        \ channel."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-m-3
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-m
      ref_id: IA-5-m-3
      description: The sensor or endpoint SHALL be authenticated prior to capturing
        the biometric sample from the claimant.
      annotation: 'SUPPLEMENTAL GUIDANCE: This requirement ensures that the biometric
        data being verified is obtained from the expected sensor rather than from
        a device that may be spoofing biometric information. This is generally not
        required when the biometric factor is verified in an endpoint that is tightly
        integrated with the sensor in a manner that resists sensor replacement.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-m-4
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-m
      ref_id: IA-5-m-4
      description: The biometric system SHALL operate with an FMR [ISO/IEC 2382-37]
        of 1 in 1000 or better. This FMR SHALL be achieved under conditions of a conformant
        attack (i.e., zero-effort impostor attempt) as defined in [ISO/IEC 30107-1].
      annotation: 'SUPPLEMENTAL GUIDANCE: Since biometric comparison is an approximate
        match, an operating point threshold is chosen by the verifier that balances
        false matches and false non-matches. To operate adequately as a verifier,
        a 1 in 1000 or better false match rate is required.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-m-5
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-m
      ref_id: IA-5-m-5
      description: The biometric system SHALL allow no more than 5 consecutive failed
        authentication attempts or 10 consecutive failed attempts if PAD demonstrating
        at least 90% resistance to presentation attacks is implemented.
      annotation: 'SUPPLEMENTAL GUIDANCE: With a false accept rate of as much as 1
        in 1000 zero-effort attempts, the ability to make a large number of biometric
        authentication attempts would result in an unacceptably high probability of
        mis-authentication. This limit is comparable to that provided by several commercial
        products (mobile devices) currently on the market.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-m-6
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-m
      ref_id: IA-5-m-6
      description: 'Once the limit on authentication failures has been reached, the
        biometric authenticator SHALL either:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-m-6-i
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-m-6
      ref_id: IA-5-m-6-i
      description: Impose a delay of at least 30 seconds before the next attempt,
        increasing exponentially with each successive attempt, or
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node752
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-m-6
      description: "ii.\tdisable the biometric user authentication and offer another\
        \ factor (e.g., a different biometric modality or a PIN/Passcode if it is\
        \ not already a required factor) if such an alternative method is already\
        \ available."
      annotation: 'SUPPLEMENTAL GUIDANCE: Following a number of consecutive biometric
        match failures that exceeds the limit in IA-5 m (5), subsequent attempts need
        to be either aggressively delayed (e.g., 1 minute before the following failed
        attempt, 2 minutes before the second following attempt) or another authentication
        or biometric modality associated with the same physical authenticator needs
        to be used.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-m-7
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-m
      ref_id: IA-5-m-7
      description: The verifier SHALL make a determination of sensor and endpoint
        performance, integrity, and authenticity.
      annotation: 'SUPPLEMENTAL GUIDANCE: The verifier needs to have a basis for determining
        that biometric verification meets the necessary performance requirements.
        This may be accomplished by authenticating the sensor or endpoint, by a certification
        by an approved accreditation authority, or by runtime interrogation of a signed
        attestation.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-m-8
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-m
      ref_id: IA-5-m-8
      description: If biometric comparison is performed centrally, then use of the
        biometric as an authentication factor SHALL be limited to one or more specific
        devices that are identified using approved cryptography.
      annotation: 'SUPPLEMENTAL GUIDANCE: The ability to use a biometric factor on
        an arbitrary device greatly increases the value of breached biometric data.
        For this reason, the use of the biometric factor is limited to specific devices
        for each subscriber. A separate key is required since the main authentication
        key is only unlocked upon successful comparison of the biometric factor.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-m-9
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-m
      ref_id: IA-5-m-9
      description: If biometric comparison is performed centrally, then a separate
        key SHALL be used for identifying the device.
      annotation: 'SUPPLEMENTAL GUIDANCE: Since the main authentication key has not
        yet been unlocked, a separate key is required for identifying the specific
        device(s) that the biometric may be used with.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-m-10
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-m
      ref_id: IA-5-m-10
      description: If biometric comparison is performed centrally, then biometric
        revocation, referred to as biometric template protection in ISO/IEC 24745,
        SHALL be implemented.
      annotation: 'SUPPLEMENTAL GUIDANCE: Central databases of biometric templates
        are an attractive target for attackers. The ability to securely revoke biometric
        factors is required in response to that threat.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-m-11
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-m
      ref_id: IA-5-m-11
      description: If biometric comparison is performed centrally, all transmission
        of biometrics SHALL be over the authenticated protected channel.
      annotation: 'SUPPLEMENTAL GUIDANCE: Because of the replay potential of biometric
        data, biometric information needs to be distributed in a manner that minimizes
        the opportunity for attackers to intercept the data either by eavesdropping
        on MitM attacks.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-m-12
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-m
      ref_id: IA-5-m-12
      description: Biometric samples and any biometric data derived from the biometric
        sample such as a probe produced through signal processing SHALL be zeroized
        immediately after any training or research data has been derived.
      annotation: "SUPPLEMENTAL GUIDANCE: If the biometric factor is used for any\
        \ supplemental purpose, it is important that it not be a mechanism for breach\
        \ of subscribers\u2019 biometric data."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node700
      ref_id: IA-5-n
      description: "Authenticator binding refers to the establishment of an association\
        \ between a specific authenticator and a subscriber\u2019s account, enabling\
        \ the authenticator to be used \u2014 possibly in conjunction with other authenticators\
        \ \u2014 to authenticate for that account"
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n-1
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n
      ref_id: IA-5-n-1
      description: Authenticators SHALL be bound to subscriber accounts by either
        issuance by the CSP as part of enrollment or associating a subscriber-provided
        authenticator that is acceptable to the CSP.
      annotation: 'SUPPLEMENTAL GUIDANCE: In the past, many physical authenticators
        were provided by the CSP. More recently, there has been a trend toward BYO
        authenticators, which can be both cost-effective for CSPs and convenient for
        the subscriber. This requirement ensures that such BYO authenticators are
        subject to approval by the CSP, primarily to ensure that they meet security
        requirements'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n-2
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n
      ref_id: IA-5-n-2
      description: Throughout the digital identity lifecycle, CSPs SHALL maintain
        a record of all authenticators that are or have been associated with each
        identity.
      annotation: "SUPPLEMENTAL GUIDANCE: In order to authenticate subscribers successfully,\
        \ the CSP needs to maintain a record of authenticators bound to each subscriber\u2019\
        s account. In addition, a record of authenticators formerly bound to each\
        \ account needs to be kept for forensic purposes."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n-3
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n
      ref_id: IA-5-n-3
      description: The CSP or verifier SHALL maintain the information required for
        throttling authentication attempts.
      annotation: 'SUPPLEMENTAL GUIDANCE: In order to successfully support the throttling
        of authentication attempts (see requirement IA-5 l (3)), the CSP needs to
        maintain information on the number of consecutive failed authentication attempts.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n-4
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n
      ref_id: IA-5-n-4
      description: The CSP SHALL also verify the type of user-provided authenticator
        so verifiers can determine compliance with requirements at each AAL.
      annotation: 'SUPPLEMENTAL GUIDANCE: In order to determine compliance with AAL-specific
        requirements, the CSP needs to reliably determine some authenticator characteristics,
        such as whether the authenticator is hardware-based, whether it is a single-factor
        or multi-factor authenticator, and performance characteristics of associated
        biometric sensors. Mechanisms to do this include attestation certificates
        from the manufacturer and examination of the authenticator (particularly at
        account issuance). In the absence of this information, the CSP needs to assume
        that the authenticator is the weakest type that is consistent with the authentication
        protocol being used.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n-5
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n
      ref_id: IA-5-n-5
      description: The record created by the CSP SHALL contain the date and time the
        authenticator was bound to the account.
      annotation: "SUPPLEMENTAL GUIDANCE: For forensic purposes it is useful to have\
        \ a record of the period of time each authenticator is bound to the subscriber\u2019\
        s account."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n-6
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n
      ref_id: IA-5-n-6
      description: When any new authenticator is bound to a subscriber account, the
        CSP SHALL ensure that the binding protocol and the protocol for provisioning
        the associated key(s) are done at AAL2.
      annotation: "SUPPLEMENTAL GUIDANCE: If the process of binding an authenticator\
        \ is not strong enough, an authenticator that is fraudulently bound to the\
        \ account could be used by an attacker to gain access to a subscriber\u2019\
        s account. The authentication factor being bound to the account needs to be\
        \ included in the authentication process for the session in which the authenticator\
        \ is bound."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n-7
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n
      ref_id: IA-5-n-7
      description: Protocols for key provisioning SHALL use authenticated protected
        channels or be performed in person to protect against MitM attacks.
      annotation: "SUPPLEMENTAL GUIDANCE: For the same reasons that MitM attacks are\
        \ of concern during authentication, they could occur during provisioning,\
        \ which could result in the binding of an attacker\u2019s key to the account\
        \ rather than the subscriber\u2019s key."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n-8
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n
      ref_id: IA-5-n-8
      description: Binding of multi-factor authenticators SHALL require multi-factor
        authentication (or equivalent) at identity proofing.
      annotation: 'SUPPLEMENTAL GUIDANCE: In order to prevent a subscriber with only
        single-factor authentication from up-leveling to multi-factor, binding of
        a multi-factor authenticator requires that the subscriber be multi-factor
        authenticated at the time the new authenticator is bound'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n-9
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n
      ref_id: IA-5-n-9
      description: "At enrollment, the CSP SHALL bind at least one, and SHOULD bind\
        \ at least two, physical (something you have) authenticators to the subscriber\u2019\
        s online identity, in addition to a memorized secret or one or more biometrics."
      annotation: "SUPPLEMENTAL GUIDANCE: Executive order 13681 requires the use of\
        \ multi-factor authentication for the release of personal data. Therefore,\
        \ it is important that the CSP associate sufficient authentication factors\
        \ at enrollment to make this possible. While all identifying information is\
        \ self-asserted at IAL1, preservation of online material or an online reputation\
        \ makes it undesirable to lose control of an account due to the loss of an\
        \ authenticator. The second authenticator makes it possible to securely recover\
        \ from an authenticator loss. For this reason, a CSP SHOULD bind at least\
        \ two physical authenticators to the subscriber\u2019s credential at IAL1\
        \ as well."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n-10
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n
      ref_id: IA-5-n-10
      description: At enrollment, authenticators at AAL2 and IAL2 SHALL be bound to
        the account.
      annotation: 'SUPPLEMENTAL GUIDANCE: In order to support higher identity assurance,
        correspondingly high authenticator assurance levels are required to ensure
        the proper use of the identity.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n-11
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n
      ref_id: IA-5-n-11
      description: "If enrollment and binding are being done remotely and cannot be\
        \ completed in a single electronic transaction, then the applicant SHALL identify\
        \ themselves in each new binding transaction by presenting a temporary secret\
        \ which was either established during a prior transaction, or sent to the\
        \ applicant\u2019s phone number, email address, or postal address of record."
      annotation: 'SUPPLEMENTAL GUIDANCE: The issuance or binding of authenticators
        may occur well after the enrollment process, following adjudication and eligibility
        determinations. It is necessary to securely associate the applicant that appears
        for identity proofing with the person appearing for authenticator issuance/binding
        in order to avoid mis-issuance of authenticators. At this point it is not
        possible to fully authenticate the applicant, but the use of a temporary secret
        provides the necessary protection for this one-time transaction.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n-12
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n
      ref_id: IA-5-n-12
      description: If enrollment and binding are being done remotely and cannot be
        completed in a single electronic transaction, then long-term authenticator
        secrets are delivered to the applicant within a protected session.
      annotation: "SUPPLEMENTAL GUIDANCE: Long-term secrets need to be protected against\
        \ disclosure while they are sent to the applicant. This applies primarily\
        \ to symmetric keys, such as for OTP authenticators, that are sent to the\
        \ applicant by the CSP. \u201CProtected session\u201D in this context refers\
        \ to an authenticated protected."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n-13
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n
      ref_id: IA-5-n-13
      description: If enrollment and binding are being done in person and cannot be
        completed in a single physical encounter, the applicant SHALL identify themselves
        in person by either using a secret as described in IA-5 n (12) above, or through
        use of a biometric that was recorded during a prior encounter.
      annotation: 'SUPPLEMENTAL GUIDANCE: The issuance or binding of authenticators
        may occur well after the enrollment process, following adjudication and eligibility
        determinations. It is necessary to securely associate the applicant that appears
        for identity proofing with the person appearing for authenticator issuance/binding
        in order to avoid mis-issuance of authenticators. At this point it is not
        possible to fully authenticate the applicant, but the use of a temporary secret
        provides the necessary protection for this one-time transaction.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n-14
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n
      ref_id: IA-5-n-14
      description: If enrollment and binding are being done in person and cannot be
        completed in a single physical encounter, temporary secrets SHALL NOT be reused.
      annotation: 'SUPPLEMENTAL GUIDANCE: The issuance or binding of authenticators
        may occur well after the enrollment process, following adjudication and eligibility
        determinations. It is necessary to securely associate the applicant that appears
        for identity proofing with the person appearing for authenticator issuance/binding
        in order to avoid mis-issuance of authenticators. A new secret for this purpose
        is required for each subsequent encounter.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n-15
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n
      ref_id: IA-5-n-15
      description: If enrollment and binding are being done in person and cannot be
        completed in a single physical encounter and the CSP issues long-term authenticator
        secrets during a physical transaction, they SHALL be loaded locally onto a
        physical device that is issued in person to the applicant or delivered in
        a manner that confirms the address of record.
      annotation: 'SUPPLEMENTAL GUIDANCE: To avoid misappropriation of long-term authenticator
        secrets at enrollment, the CSP is required to load the secrets onto authenticators
        directly, or deliver them to the new subscriber in a manner that confirms
        the address of record, typically by sending a short-term secret to that address
        that the new subscriber uses to obtain the long-term secret.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n-16
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n
      ref_id: IA-5-n-16
      description: "Before adding a new authenticator to a subscriber\u2019s account,\
        \ the CSP SHALL first require the subscriber to authenticate at AAL2 (or a\
        \ higher AAL) at which the new authenticator will be used."
      annotation: 'SUPPLEMENTAL GUIDANCE: In order to maintain the significance of
        AALs and prevent attackers from leveraging lower AAL authentication to gain
        access to higher AAL resources, subscribers binding additional authenticators
        need to do so at the maximum AAL at which they will be used.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n-17
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n
      ref_id: IA-5-n-17
      description: "If the subscriber\u2019s account has only one authentication factor\
        \ bound to it, the CSP SHALL require the subscriber to authenticate at AAL1\
        \ in order to bind an additional authenticator of a different authentication\
        \ factor."
      annotation: 'SUPPLEMENTAL GUIDANCE: This is a special-case, one-time only exception
        to IA5(n)(17) to allow a single-factor account not subject to identity proofing
        (IAL1) to be upgraded to a multi-factor account. This provides a mechanism
        for such accounts to increase their authentication security.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n-18
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n
      ref_id: IA-5-n-18
      description: If a subscriber loses all authenticators of a factor necessary
        to complete multifactor authentication and has been identity proofed at IAL2,
        that subscriber SHALL repeat the identity proofing process described in IA-12.
      annotation: "SUPPLEMENTAL GUIDANCE: Repeating the identity proofing process\
        \ is an onerous requirement when a subscriber is no longer able to complete\
        \ multi-factor authentication, but it is necessary to avoid the security problems\
        \ typically present in \u201Caccount recovery\u201D situations. This is the\
        \ primary reason that the binding of multiple authenticators is recommended,\
        \ particularly in the case of physical authenticators. The entire identity\
        \ proofing process need not be repeated if the CSP has maintained enough records\
        \ of the evidence presented to repeat the verification phase of identity proofing."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n-19
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n
      ref_id: IA-5-n-19
      description: If a subscriber loses all authenticators of a factor necessary
        to complete multifactor authentication and has been identity proofed at IAL2
        or IAL3, the CSP SHALL require the claimant to authenticate using a n authenticator
        of the remaining factor, if any, to confirm binding to the existing identity.
      annotation: 'SUPPLEMENTAL GUIDANCE: While use of an authenticator at a different
        factor is only a single authentication factor (and therefore only AAL1), authentication
        in conjunction with the repeated identity proofing process provides assurance
        that the claimant is who they claim to be.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n-20
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n
      ref_id: IA-5-n-20
      description: If the CSP opts to allow binding of a new memorized secret with
        the use of two physical authenticators, then it requires entry of a confirmation
        code sent to an address of record.
      annotation: 'SUPPLEMENTAL GUIDANCE: Loss of a memorized secret is different
        from the loss of a physical authenticator because it is not mitigated by the
        binding of multiple authenticators. This alternate method of associating a
        new memorized secret may be used by CSPs to avoid the need for repeating identity
        proofing (Refer to IA-12).'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n-21
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n
      ref_id: IA-5-n-21
      description: If the CSP opts to allow binding of a new memorized secret with
        the use of two physical authenticators, then the confirmation code SHALL consist
        of at least 6 random alphanumeric characters generated by an approved random
        bit generator [SP 80090Ar1].
      annotation: 'SUPPLEMENTAL GUIDANCE: The confirmation code is required to have
        sufficient entropy and to be generated in a manner that cannot be predicted
        by an attacker.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n-22
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-n
      ref_id: IA-5-n-22
      description: If the CSP opts to allow binding of a new memorized secret with
        the use of two physical authenticators, then the confirmation code SHALL be
        valid for a maximum of 7 days but MAY be made valid up to 21 days via an exception
        process to accommodate addresses outside the direct reach of the U.S. Postal
        Service. Confirmation codes sent by means other than physical mail SHALL be
        valid for a maximum of 5 minutes.
      annotation: 'SUPPLEMENTAL GUIDANCE: The confirmation code has a limited lifetime
        to mitigate the risk of loss or misappropriation in transit.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node700
      ref_id: IA-5-o
      description: 'Session Management: The following requirements apply to applications
        where a session is maintained between the subscriber and relying party to
        allow multiple interactions without repeating the authentication event each
        time.

        Once an authentication event has taken place, it is often desirable to allow
        the subscriber to continue using the application across multiple subsequent
        interactions without requiring them to repeat the authentication event. This
        requirement is particularly true for federation scenarios where the authentication
        event necessarily involves several components and parties coordinating across
        a network.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-1
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o
      ref_id: IA-5-o-1
      description: "Session Binding Requirements: A session occurs between the software\
        \ that a subscriber is running \u2014 such as a browser, application, or operating\
        \ system (i.e., the session subject) \u2014 and the RP or CSP that the subscriber\
        \ is accessing (i.e., the session host)."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-1-a
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-1
      ref_id: IA-5-o-1-a
      description: "A session is maintained by a session secret which SHALL be shared\
        \ between the subscriber\u2019s software and the service being accessed."
      annotation: 'SUPPLEMENTAL GUIDANCE: This secret binds the two ends of the session,
        allowing the subscriber to continue using the service over time.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-1-b
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-1
      ref_id: IA-5-o-1-b
      description: "The secret SHALL be presented directly by the subscriber\u2019\
        s software or possession of the secret SHALL be proven using a cryptographic\
        \ mechanism."
      annotation: 'SUPPLEMENTAL GUIDANCE: The session secret is considered a short-term
        secret, so direct presentation of a shared secret is permitted, even at AAL2
        or AAL3.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-1-c
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-1
      ref_id: IA-5-o-1-c
      description: The secret used for session binding SHALL be generated by the session
        host in direct response to an authentication event.
      annotation: "SUPPLEMENTAL GUIDANCE: The session secret needs to be directly\
        \ associated with authentication so that it isn\u2019t inadvertently provided\
        \ to the wrong session."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-1-d
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-1
      ref_id: IA-5-o-1-d
      description: A session SHALL NOT be considered at a higher AAL than the authentication
        event.
      annotation: 'SUPPLEMENTAL GUIDANCE: Each session has an associated maximum AAL
        at which it can be used that is derived from the authentication AAL; this
        is associated with the session and its secret by the CSP/RP.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-1-e
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-1
      ref_id: IA-5-o-1-e
      description: Secrets used for session binding SHALL be generated by the session
        host during an interaction, typically immediately following authentication.
      annotation: 'SUPPLEMENTAL GUIDANCE: It is the responsibility of the host (RP/CSP/Verifier)
        to generate session secrets, not the subscriber.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-1-f
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-1
      ref_id: IA-5-o-1-f
      description: Secrets used for session binding SHALL be generated by an approved
        random bit generator [SP 800-90Ar1].
      annotation: 'SUPPLEMENTAL GUIDANCE: The use of a high-quality random bit generator
        is important to ensure that an attacker cannot guess the session secret.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-1-g
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-1
      ref_id: IA-5-o-1-g
      description: Secrets used for session binding SHALL contain at least 64 bits
        of entropy.
      annotation: 'SUPPLEMENTAL GUIDANCE: The use of a high-quality random bit generator
        is important to ensure that an attacker cannot guess the session secret.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-1-h
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-1
      ref_id: IA-5-o-1-h
      description: Secrets used for session binding SHALL be erased or invalidated
        by the session subject when the subscriber logs out.
      annotation: 'SUPPLEMENTAL GUIDANCE: At a minimum, the CSP/RP needs to ensure
        that the session secret can no longer to be used following logout. If possible,
        the secret should be erased on the subscriber endpoint as well.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-1-i
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-1
      ref_id: IA-5-o-1-i
      description: Secrets used for session binding SHALL be sent to and received
        from the device using an authenticated protected channel.
      annotation: 'SUPPLEMENTAL GUIDANCE: Session secrets, particularly when directly
        presented, need to be protected against eavesdropping and MitM attacks. This
        is typically accomplished using the Transport Level Security (TLS) protocol.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-1-j
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-1
      ref_id: IA-5-o-1-j
      description: Secrets used for session binding SHALL time out and not be accepted
        after the times specified in IA-5 j (13) as appropriate for the AAL.
      annotation: 'SUPPLEMENTAL GUIDANCE: This requirement is in support of the reauthentication
        requirements in AAL2-*, AAL3-*, and REAUTH-*. The proper way to ensure that
        a session is logged out is to invalidate the session secrets associated with
        that session. A new session secret will need to be generated and associated
        with any session that is about to be established from the same endpoint.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-1-k
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-1
      ref_id: IA-5-o-1-k
      description: "Secrets used for session binding SHALL NOT be available to insecure\
        \ communications between the host and subscriber\u2019s endpoint."
      annotation: 'SUPPLEMENTAL GUIDANCE: User endpoints such as browsers that support
        both secure and insecure communications typically have mechanisms to flag
        information (e.g., cookies) that are only available to secure sessions. These
        mechanisms are required to be used for session management secrets. See also
        IA-5 o (7).'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-1-l
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-1
      ref_id: IA-5-o-1-l
      description: Authenticated sessions SHALL NOT fall back to an insecure transport,
        such as from https to http, following authentication.
      annotation: "SUPPLEMENTAL GUIDANCE: In some cases, endpoints supporting https\
        \ provide, primary for legacy purposes, the ability to connect via http as\
        \ well. If not done properly, this can make the site vulnerable to a \u201C\
        downgrade attack\u201D where a session switches from https to http. This must\
        \ not happen for authenticated sessions. If session secrets are managed properly,\
        \ this downgrade interferes with the continuity of the session."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-1-m
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-1
      ref_id: IA-5-o-1-m
      description: URLs or POST content SHALL contain a session identifier that SHALL
        be verified by the RP to ensure that actions taken outside the session do
        not affect the protected session.
      annotation: 'SUPPLEMENTAL GUIDANCE: Unique session identifiers in the URL or
        POST content are used to ensure that sessions are not vulnerable to cross-site
        request forgery (CSRF). Note that the session identifier is separate and different
        from the session secret; under no circumstances should the session secret
        be included in a URL.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-1-n
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-1
      ref_id: IA-5-o-1-n
      description: Browser cookies SHALL be tagged to be accessible only on secure
        (HTTPS) sessions.
      annotation: "SUPPLEMENTAL GUIDANCE: Browser cookies have an optional \u201C\
        secure\u201D flag to ensure that they are not accidentally transmitted over\
        \ a non-secure channel. This flag must be set for session secrets."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-1-o
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-1
      ref_id: IA-5-o-1-o
      description: Browser cookies SHALL be accessible to the minimum practical set
        of hostnames and paths.
      annotation: 'SUPPLEMENTAL GUIDANCE: Browser cookies have a scope parameter that
        limits the sites from to which the cookie can be sent; this should be specified
        as specifically as possible to limit access to the session secret as narrowly
        as practical.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-1-p
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-1
      ref_id: IA-5-o-1-p
      description: Expiration of browser cookies SHALL NOT be depended upon to enforce
        session timeouts.
      annotation: 'SUPPLEMENTAL GUIDANCE: While browser cookies have an expiration
        time, enforcement of session timeouts must occur at the RP/CSP and not at
        the user endpoint. Cookie expiration may, however, be used to limit accumulation
        of cookies in the browser.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-1-q
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-1
      ref_id: IA-5-o-1-q
      description: The presence of an OAuth access token SHALL NOT be interpreted
        by the RP as presence of the subscriber, in the absence of other signals
      annotation: 'SUPPLEMENTAL GUIDANCE: Access tokens, used in federated identity
        systems, may be valid after the authentication session has ended and the subscriber
        has left.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-2
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o
      ref_id: IA-5-o-2
      description: Reauthentication Requirements
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-2-a
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-2
      ref_id: IA-5-o-2-a
      description: Continuity of authenticated sessions SHALL be based upon the possession
        of a session secret issued by the verifier at the time of authentication and
        optionally refreshed during the session.
      annotation: 'SUPPLEMENTAL GUIDANCE: This is a reiteration of requirement IA-5
        o (1).'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-2-b
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-2
      ref_id: IA-5-o-2-b
      description: Session secrets SHALL be non-persistent, i.e., they SHALL NOT be
        retained across a restart of the associated application or a reboot of the
        host device.
      annotation: 'SUPPLEMENTAL GUIDANCE: Session secrets are not to be maintained
        across a restart of the associated application or a reboot of the host device
        in order to minimize the likelihood that a misappropriated logged in device
        can be exploited.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-2-c
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-2
      ref_id: IA-5-o-2-c
      description: Periodic reauthentication of sessions (at least every 12 hours
        per session) SHALL be performed to confirm the continued presence of the subscriber
        at an authenticated session.
      annotation: 'SUPPLEMENTAL GUIDANCE: In order to protect against a subscriber
        leaving a logged-in endpoint, timeouts are defined for session inactivity
        and overall session length. The timer for these timeouts is reset by a reauthentication
        transaction. Higher AALs have more stringent (shorter) reauthentication timeouts.
        Following expiration of the session timer, the subscriber is required to start
        a new session by authenticating.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-2-d
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-2
      ref_id: IA-5-o-2-d
      description: "A session SHALL NOT be extended past the guidelines in IA-5 o\
        \ (2) a \u2013 j based on presentation of the session secret alone."
      annotation: "SUPPLEMENTAL GUIDANCE: The existence and possession of a session\
        \ secret does not consider whether the subscriber continued to be in control\
        \ of the session endpoint. To mitigate this risk, the session secret is only\
        \ valid for a limited period of time. While the session secret is \u201Csomething\
        \ you have\u201D, it is not an authenticator."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-2-e
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-2
      ref_id: IA-5-o-2-e
      description: 'Prior to session expiration, the reauthentication time limit SHALL
        be extended by prompting the subscriber for the authentication factor(s) of
        a memorized secret or biometric.

        Note: At AAL2, a memorized secret or biometric, and not a physical authenticator,
        is required because the session secret is something you have, and an additional
        authentication factor is required to continue the session.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-2-f
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-2
      ref_id: IA-5-o-2-f
      description: If federated authentication is being used, then since the CSP and
        RP often employ separate session management technologies, there SHALL NOT
        be any assumption of correlation between these sessions.
      annotation: 'SUPPLEMENTAL GUIDANCE: When an RP session expires and the RP requires
        reauthentication, it is entirely possible that the session at the CSP has
        not expiredand that a new assertion could be generated from this session at
        the CSP without reauthenticating the user.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-2-g
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-2
      ref_id: IA-5-o-2-g
      description: "An RP requiring reauthentication through a federation protocol\
        \ SHALL \u2014 if possible within the protocol \u2014 specify the maximum\
        \ (see IA-5 j (10)) acceptable authentication age to the CSP."
      annotation: "SUPPLEMENTAL GUIDANCE: In some applications, RPs may require a\
        \ \u201Cfresh\u201D authentication to meet its authentication risk requirements.\
        \ By specifying maximum age, the RP can proactively request the CSP to obtain\
        \ a new authentication to meet that requirement."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-2-h
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-2
      ref_id: IA-5-o-2-h
      description: If federated authentication if being used and an RP has specific
        authentication age (see IA-5 j [10]) requirements that it has communicated
        to the CSP, then the CSP SHALL reauthenticate the subscriber if they have
        not been authenticated within that time period.
      annotation: 'SUPPLEMENTAL GUIDANCE: When the RP communicates its authentication
        freshness requirements to the CSP, the CSP is expected to reauthenticate the
        subscriber to support a session that meets those requirements.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-2-i
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-2
      ref_id: IA-5-o-2-i
      description: If federated authentication is being used, the CSP SHALL communicate
        the authentication event time to the RP to allow the RP to decide if the assertion
        is sufficient for reauthentication and to determine the time for the next
        reauthentication event.
      annotation: 'SUPPLEMENTAL GUIDANCE: When federation authentication is being
        used, the authentication assertion from the CSP needs to contain the authentication
        event time to allow the RP to request reauthentication at an appropriate interval
        if it has specific authentication age requirements.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node811
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5-o-2
      description: 'DISCUSSION: Authenticators include passwords, cryptographic devices,
        biometrics, certificates, one-time password devices, and ID badges. Device
        authenticators include certificates and passwords. Initial authenticator content
        is the actual content of the authenticator (e.g., the initial password). In
        contrast, the requirements for authenticator content contain specific criteria
        or characteristics (e.g., minimum password length). Developers may deliver
        system components with factory default authentication credentials (i.e., passwords)
        to allow for initial installation and configuration. Default authentication
        credentials are often well known, easily discoverable, and present a significant
        risk. The requirement to protect individual authenticators may be implemented
        via control PL-4 or PS-6 for authenticators in the possession of individuals
        and by controls AC-3, AC-6, and SC-28 for authenticators stored in organizational
        systems, including passwords stored in hashed or encrypted formats or files
        containing encrypted or hashed passwords accessible with administrator privileges.

        Systems support authenticator management by organization-defined settings
        and restrictions for various authenticator characteristics (e.g., minimum
        password length, validation time window for time synchronous one-time tokens,
        and number of allowed rejections during the verification stage of biometric
        authentication). Actions can be taken to safeguard individual authenticators,
        including maintaining possession of authenticators, not sharing authenticators
        with others, and immediately reporting lost, stolen, or compromised authenticators.
        Authenticator management includes issuing and revoking authenticators for
        temporary access when no longer needed.

        Related Controls: AC-3, AC-6, CM-6, IA-2, IA-4, IA-7, IA-8, MA-4, PE-2, PL-4,
        SC-12, SC-13.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5
      ref_id: IA-5(1)
      name: AUTHENTICATOR MANAGEMENT | AUTHENTICATOR TYPES
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)
      assessable: false
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)
      ref_id: IA-5(1)(a)
      name: 'Memorized Secret Authenticators and Verifiers:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)-1
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)
      ref_id: IA-5(1)(a)-1
      description: Maintain a list of commonly-used, expected, or compromised passwords
        and update the list quarterly and when organizational passwords are suspected
        to have been compromised directly or indirectly;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)-2
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)
      ref_id: IA-5(1)(a)-2
      description: Require immediate selection of a new password upon account recovery
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)-3
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)
      ref_id: IA-5(1)(a)-3
      description: Allow user selection of long passwords and passphrases, including
        spaces and all printable characters;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)-4
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)
      ref_id: IA-5(1)(a)-4
      description: Employ automated tools to assist the user in selecting strong password
        authenticators;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)-5
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)
      ref_id: IA-5(1)(a)-5
      description: 'Enforce the following composition and complexity rules when agencies
        elect to follow basic password standards:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)-5-a
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)-5
      ref_id: IA-5(1)(a)-5-a
      description: Not be a proper name.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)-5-b
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)-5
      ref_id: IA-5(1)(a)-5-b
      description: Not be the same as the Userid.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)-5-c
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)-5
      ref_id: IA-5(1)(a)-5-c
      description: Expire within a maximum of 90 calendar days.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)-5-d
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)-5
      ref_id: IA-5(1)(a)-5-d
      description: Not be identical to the previous ten (10) passwords.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)-5-e
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)-5
      ref_id: IA-5(1)(a)-5-e
      description: Not be displayed when entered.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)-6
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)
      ref_id: IA-5(1)(a)-6
      description: If chosen by the subscriber, memorized secrets SHALL be at least
        8 characters in length.
      annotation: 'SUPPLEMENTAL GUIDANCE: Memorized secret length is the most reliable
        metric determining strength against online and offline guessing attacks. The
        objective is primarily to defend against online attacks (with throttling of
        guesses) and to provide some protection against offline attacks, with the
        primary defense for such attacks being secure storage of the verifier.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)-7
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)
      ref_id: IA-5(1)(a)-7
      description: If chosen by the CSP or verifier using an approved random number
        generator, memorized secrets SHALL be at least 6 characters in length.
      annotation: 'SUPPLEMENTAL GUIDANCE: Memorized secret length is the most reliable
        metric determining strength against online and offline guessing attacks. The
        objective is primarily to defend against online attacks (with throttling of
        guesses) and to provide some protection against offline attacks, with the
        primary defense for such attacks being secure storage of the verifier.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)-8
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)
      ref_id: IA-5(1)(a)-8
      description: Truncation of the secret SHALL NOT be performed.
      annotation: 'SUPPLEMENTAL GUIDANCE: Memorized secrets that are longer than expected
        by the verifier might (but must not) be simply truncated to an acceptable
        length. This gives a false impression of security to the user if the verifier
        only checks a subset of the memorized secret.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)-9
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)
      ref_id: IA-5(1)(a)-9
      description: "Memorized secret verifiers SHALL NOT permit the subscriber to\
        \ store a \u201Chint\u201D that is accessible to an unauthenticated claimant."
      annotation: 'SUPPLEMENTAL GUIDANCE: The availability of memorized secret hints
        greatly weakens the strength of memorized secret authenticators.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)-10
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)
      ref_id: IA-5(1)(a)-10
      description: "Verifiers SHALL NOT prompt subscribers to use specific types of\
        \ information (e.g., \n\u201CWhat was the name of your first pet?\u201D) when\
        \ choosing memorized secrets."
      annotation: "SUPPLEMENTAL GUIDANCE: Prompts for specific information (often\
        \ called Knowledge-based Authentication or Security Questions) encourage use\
        \ of the same memorized secrets at multiple sites, which causes a vulnerability\
        \ to \u201Cpassword stuffing\u201D attacks. This guidance applies to account\
        \ recovery situations as well as normal authentication."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)-11
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)
      ref_id: IA-5(1)(a)-11
      description: When processing requests to establish and change memorized secrets,
        verifiers SHALL compare the prospective secrets against a list that contains
        values known to be commonly used, expected, or compromised.
      annotation: "SUPPLEMENTAL GUIDANCE: The maintenance of a list of common memorized\
        \ secrets that cannot be used by users protects provides protection against\
        \ online attacks that might otherwise succeed before throttling mechanisms\
        \ take effect to defend against these attacks. This is an alternative to the\
        \ use of composition rules (requirements for particular character types, etc.)\
        \ and can provide more customized protection against common memorized secrets.\
        \ This list may include, but is not limited to:\n\u2022 Passwords obtained\
        \ from previous breach corpuses.\n\u2022 Dictionary words.\n\u2022 Repetitive\
        \ or sequential characters (e.g., \u2018aaaaaa\u2019, \u20181234abcd\u2019\
        ).\n\u2022 Context-specific words, such as the name of the service, the username,\
        \ and derivatives thereof."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)-12
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)
      ref_id: IA-5(1)(a)-12
      description: If a chosen secret is found in the list, the CSP or verifier SHALL
        advise the subscriber that they need to select a different secret.
      annotation: 'SUPPLEMENTAL GUIDANCE: The use of common memorized secrets greatly
        increases the vulnerability of the account to both online (guessing) and offline
        (cracking) attacks. This is an alternative to the use of composition rules
        (requirements for particular character types, etc.) and can provide more customized
        protection against common memorized secrets.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)-13
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)
      ref_id: IA-5(1)(a)-13
      description: If a chosen secret is found in the list, the CSP or verifier SHALL
        provide the reason for rejection.
      annotation: 'SUPPLEMENTAL GUIDANCE: When a subscriber chooses a weak memorized
        secret, it is likely that they will choose another weak memorized secret that
        may or may not be on the blocklist. In addition to explaining to the user
        the reason for the rejection of their selection, it is helpful to provide
        coaching on better choices. Tools like password-strength meters are often
        useful in this situation.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)-14
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)
      ref_id: IA-5(1)(a)-14
      description: If a chosen secret is found in the list, the CSP or verifier SHALL
        require the subscriber to choose a different value.
      annotation: 'SUPPLEMENTAL GUIDANCE: When a subscriber chooses a weak memorized
        secret, the memorized secret change process is not complete until the subscriber
        has chosen a different value.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)-15
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)
      ref_id: IA-5(1)(a)-15
      description: "Verifiers SHALL implement a rate-limiting mechanism that effectively\
        \ limits failed authentication attempts that can be made on the subscriber\u2019\
        s account to no more than five."
      annotation: 'SUPPLEMENTAL GUIDANCE: Rate limiting restricts the ability of an
        attacker to make many online guessing attacks on the memorized secret. Other
        requirements (e.g., minimum length of memorized secrets) depend on the existence
        of rate limiting, so effective rate limiting is an essential capability. Ideally,
        a rate limiting mechanism should restrict the attacker as much as possible
        without creating an opportunity for a denial-of-service attack against the
        subscriber.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)-16
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)
      ref_id: IA-5(1)(a)-16
      description: Verifiers SHALL force a change of memorized secret if there is
        evidence of compromise of the authenticator.
      annotation: 'SUPPLEMENTAL GUIDANCE: Although requiring routine periodic changes
        to memorized secrets is not recommended, it is important that verifiers have
        the capability to prompt memorized secrets on an emergency basis if there
        is evidence of a possible successful attack.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)-17
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)
      ref_id: IA-5(1)(a)-17
      description: The verifier SHALL use approved encryption when requesting memorized
        secrets in order to provide resistance to eavesdropping and MitM attacks.
      annotation: 'SUPPLEMENTAL GUIDANCE: As defined in Appendix A of the CJIS Security
        Policy, cryptography is considered approved if it is specified or adopted
        in a FIPS or NIST recommendation.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)-18
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)
      ref_id: IA-5(1)(a)-18
      description: The verifier SHALL use an authenticated protected channel when
        requesting memorized secrets in order to provide resistance to eavesdropping
        and MitM attacks.
      annotation: 'SUPPLEMENTAL GUIDANCE: Communication between claimant and verifier
        is required to be via an encrypted channel that authenticates the verifier
        to provide confidentiality of the authenticator output and resistance to MitM
        attacks. This is typically accomplished using the Transport Level Security
        (TLS) protocol.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)-19
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)
      ref_id: IA-5(1)(a)-19
      description: Verifiers SHALL store memorized secrets in a form that is resistant
        to offline attacks.
      annotation: "SUPPLEMENTAL GUIDANCE: Storage of memorized secret verifiers in\
        \ a hashed form that is not readily reversed is a key protection against offline\
        \ attacks. In no case should a verifier store memorized secrets in cleartext\
        \ form. Criteria IA-5(1)(a)(20) \u2013 (22) provide more detail on how this\
        \ is done."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)-20
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)
      ref_id: IA-5(1)(a)-20
      description: Memorized secrets SHALL be salted and hashed using a suitable one-way
        key derivation function.
      annotation: 'SUPPLEMENTAL GUIDANCE: Key derivation functions take a password,
        a salt, and a cost factor as inputs then generate a password hash. Their purpose
        is to make each password guessing trial by an attacker who has obtained a
        password hash file expensive and therefore the cost of a guessing attack high
        or prohibitive. Use of a key derivation with a salt, preferably with a time-
        and memory-hard key derivation function, provides the best protection against
        attackers that are able to obtain a copy of the verifier database.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)-21
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)
      ref_id: IA-5(1)(a)-21
      description: The salt SHALL be at least 32 bits in length and be chosen arbitrarily
        to minimize salt value collisions among stored hashes.
      annotation: 'SUPPLEMENTAL GUIDANCE: Salt values need to be large enough to make
        it impractical for an attacker to precompute hashed verifier values (so called
        rainbow tables). While rainbow tables are typically quite large, this requirement
        would increase their size by a factor of about 4.3 billion. If not chosen
        arbitrarily, the attacker might be able to anticipate the salt values that
        would be used, which would eliminate much of this advantage.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)-22
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)
      ref_id: IA-5(1)(a)-22
      description: Both the salt value and the resulting hash SHALL be stored for
        each subscriber using a memorized secret authenticator
      annotation: 'SUPPLEMENTAL GUIDANCE: In order to verify a memorized secret, it
        needs to be salted and hashed for comparison with the stored verifier (resulting
        hash). To do this, the salt value needs to be available, and since it is different
        for each user, needs to be stored with the verifier. It is impractical to
        verify a memorized secret if this is not done.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)-23
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)
      ref_id: IA-5(1)(a)-23
      description: If an additional iteration of a key derivation function using a
        salt value known only to the verifier is performed, then this secret salt
        value SHALL be generated with an approved random bit generator and of sufficient
        length.
      annotation: "SUPPLEMENTAL GUIDANCE: An additional keyed hashing iteration using\
        \ a key value that is secret and stored separately from the verifiers provides\
        \ excellent protection against even attackers (\u201Cpassword crackers\u201D\
        ) with substantial computing resources, provided the key is not also compromised.\
        \ Accordingly, it is important that this salt, which is common to multiple\
        \ users, be generated in a manner that is not vulnerable to compromise."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)-24
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)
      ref_id: IA-5(1)(a)-24
      description: If an additional iteration of a key derivation function using a
        salt value known only to the verifier is performed, then this secret salt
        value SHALL provide at least the minimumsecurity strength.
      annotation: "SUPPLEMENTAL GUIDANCE: An additional keyed hashing iteration using\
        \ a key value that is secret and stored separately from the verifiers provides\
        \ excellent protection against even attackers (\u201Cpassword crackers\u201D\
        ) with substantial computing resources, provided the key is not also compromised.\
        \ Accordingly, it is important that this salt, which is common to multiple\
        \ users, be of sufficient size to make cryptographic and brute-force attacks\
        \ impractical.\nCurrently, the requirement is that the key be at least 112\
        \ bits in length."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)-25
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)
      ref_id: IA-5(1)(a)-25
      description: If an additional iteration of a key derivation function using a
        salt value known only to the verifier is performed, then this secret salt
        value SHALL be stored separately from the memorized secrets
      annotation: "SUPPLEMENTAL GUIDANCE: An additional keyed hashing iteration using\
        \ a key value that is secret and stored separately from the verifiers provides\
        \ excellent protection against even attackers (\u201Cpassword crackers\u201D\
        ) with substantial computing resources, provided the key is not also compromised.\
        \ Accordingly, it is important that this salt, which is common to multiple\
        \ users, be stored separately so that it is unlikely to be compromised along\
        \ with the verifier database. One way to do this is to perform this last hashing\
        \ iteration on a physically separate processor, since it only requires a value\
        \ to hash as input and provides the hashed value in response."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node844
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(a)
      description: 'DISCUSSION: Password-based authentication applies to passwords
        regardless of whether they are used in single-factor or multi-factor authentication.
        Long passwords or passphrases are preferable over shorter passwords. Enforced
        composition rules provide marginal security benefits while decreasing usability.
        However, organizations may choose to establish certain rules for password
        generation (e.g., minimum character length for long passwords) under certain
        circumstances and can enforce this requirement in IA-5(1)(a)(5). Account recovery
        can occur, for example, in situations when a password is forgotten. Cryptographically
        protected passwords include salted one-way cryptographic hashes of passwords.
        The list of commonly used, compromised, or expected passwords includes passwords
        obtained from previous breach corpuses, dictionary words, and repetitive or
        sequential characters. The list includes context-specific words, such as the
        name of the service, username, and derivatives thereof.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(b)
      assessable: false
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)
      ref_id: IA-5(1)(b)
      name: Look-Up Secret Authenticators and Verifiers3
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(b)-1
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(b)
      ref_id: IA-5(1)(b)-1
      description: CSPs creating look-up secret authenticators SHALL use an approved
        random bit generator to generate the list of secrets.
      annotation: 'SUPPLEMENTAL GUIDANCE: The use of a high-quality random bit generator
        is important to ensure that an attacker cannot guess the look-up secret'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(b)-2
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(b)
      ref_id: IA-5(1)(b)-2
      description: Look-up secrets SHALL have at least 20 bits of entropy.
      annotation: 'SUPPLEMENTAL GUIDANCE: Look-up secrets need to have enough entropy
        to ensure that brute-force guessing attacks do not succeed.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(b)-3
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(b)
      ref_id: IA-5(1)(b)-3
      description: "If look-up secrets are distributed online, then they SHALL be\
        \ distributed over a secure channel in accordance with the post-enrollment\
        \ binding requirements in IA-5 \u2018n\u2019 17 through 25."
      annotation: 'SUPPLEMENTAL GUIDANCE: Look-up secrets need to be distributed in
        a manner that minimizes the opportunity for attackers to intercept the secrets
        either by eavesdropping or MitM attacks.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(b)-4
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(b)
      ref_id: IA-5(1)(b)-4
      description: Verifiers of look-up secrets SHALL prompt the claimant for the
        next secret from their authenticator or for a specific (e.g., numbered) secret.
      annotation: 'SUPPLEMENTAL GUIDANCE: In most cases claimants will be prompted
        for the next unused memorized secret in a list but may be challenged to use
        a specific secret from a list.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(b)-5
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(b)
      ref_id: IA-5(1)(b)-5
      description: A given secret from an authenticator SHALL be used successfully
        only once.
      annotation: 'SUPPLEMENTAL GUIDANCE: Many threats, such as key logging, are enabled
        if the look-up secret can be used more than once.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(b)-6
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(b)
      ref_id: IA-5(1)(b)-6
      description: If a look-up secret is derived from a grid (bingo) card, then each
        cell of the grid SHALL be used only once.
      annotation: "SUPPLEMENTAL GUIDANCE: Grid (bingo) cards are sometimes used to\
        \ provide a rudimentary challenge-response authentication involving the claimant.\
        \ However, an attacker such as a key logger that has persistent access to\
        \ the endpoint can derive the contents of the grid, and potentially authenticate\
        \ successfully, if grid entries are reused in subsequent authentication transactions.\
        \ \nAbsent the ability to reuse grid squares, grid (bingo) cards will probably\
        \ no longer be attractive as authenticators."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(b)-7
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(b)
      ref_id: IA-5(1)(b)-7
      description: Verifiers SHALL store look-up secrets in a form that is resistant
        to offline attacks.
      annotation: 'SUPPLEMENTAL GUIDANCE: Storage of look-up secret verifiers in a
        hashed form that is not readily reversed is a key protection against offline
        attacks. In no case should a verifier store look-up secrets in cleartext form.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(b)-8
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(b)
      ref_id: IA-5(1)(b)-8
      description: If look-up secrets have at least 112 bits of entropy, then they
        SHALL be hashed with an approved one-way function
      annotation: 'SUPPLEMENTAL GUIDANCE: Use of an approved one-way function effectively
        protects the look-up secrets from disclosure if the verifier is compromised.
        Salting of secrets with this amount of entropy is not required because it
        is not practical to mount brute-force or cryptographic attacks against secrets
        this large.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(b)-9
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(b)
      ref_id: IA-5(1)(b)-9
      description: If look-up secrets have less than 112 bits of entropy, then they
        SHALL be salted and hashed using a suitable one-way key derivation function.
      annotation: 'SUPPLEMENTAL GUIDANCE: Key derivation functions take a look-up
        secret, a salt, and a cost factor as inputs then generate a hash. Their purpose
        is to make each look-up secret guessing trial by an attacker who has obtained
        a look-up secret hash file expensive and therefore the cost of a guessing
        attack high or prohibitive. Use of a key derivation with a salt, preferably
        with a time- and memory-hard key derivation function, provides the best protection
        against attackers that are able to obtain a copy of the verifier database.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(b)-10
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(b)
      ref_id: IA-5(1)(b)-10
      description: If look-up secrets have less than 112 bits of entropy, then the
        salt SHALL be at least 32 bits in length and be chosen arbitrarily to minimize
        salt value collisions among stored hashes.
      annotation: 'SUPPLEMENTAL GUIDANCE: Salt values need to be large enough to make
        it impractical for an attacker to precompute hashed verifier values (so called
        rainbow tables). While rainbow tables are typically quite large, this requirement
        would increase their size by a factor of about 4.3 billion. If not chosen
        arbitrarily, the attacker might be able to anticipate the salt values that
        would be used, which would eliminate much of this advantage'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(b)-11
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(b)
      ref_id: IA-5(1)(b)-11
      description: If look-up secrets have less than 112 bits of entropy, then both
        the salt value and the resulting hash SHALL be stored for each look-up secret.
      annotation: 'SUPPLEMENTAL GUIDANCE: In order to verify a look-up secret, it
        needs to be salted and hashed for comparison with the stored verifier (resulting
        hash). To do this, the salt value needs to be available, and since it is different
        for each secret, needs to be stored with the verifier. It is impractical to
        verify a look-up secret if this is not done.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(b)-12
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(b)
      ref_id: IA-5(1)(b)-12
      description: "If look-up secrets that have less than 64 bits of entropy, then\
        \ the verifier SHALL implement a rate-limiting mechanism that effectively\
        \ limits the number of failed authentication attempts that can be made on\
        \ the subscriber\u2019s account."
      annotation: 'SUPPLEMENTAL GUIDANCE: Rate limiting restricts the ability of an
        attacker to make many online guessing attacks on the look-up secret. Other
        requirements (e.g., minimum length of look-up secrets) depend on the existence
        of rate limiting, so effective rate limiting is an essential capability. Ideally,
        a rate limiting mechanism should restrict the attacker as much as possible
        without creating an opportunity for a denial-of-service attack against the
        subscriber.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(b)-13
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(b)
      ref_id: IA-5(1)(b)-13
      description: The verifier SHALL use approved encryption when requesting look-up
        secrets in order to provide resistance to eavesdropping and MitM attacks.
      annotation: 'SUPPLEMENTAL GUIDANCE: Cryptography is considered approved if it
        is specified or adopted in a FIPS or NIST recommendation.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(b)-14
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(b)
      ref_id: IA-5(1)(b)-14
      description: The verifier SHALL use an authenticated protected channel when
        requesting look-up secrets in order to provide resistance to eavesdropping
        and MitM attacks.
      annotation: 'SUPPLEMENTAL GUIDANCE: Communication between claimant and verifier
        is required to be via an encrypted channel that authenticates the verifier
        to provide confidentiality of the authenticator output and resistance to MitM
        attacks. This is typically accomplished using the Transport Level Security
        (TLS) protocol.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)
      assessable: false
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)
      ref_id: IA-5(1)(c)
      name: Out-of-Band Authenticators and Verifiers
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)-1
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)
      ref_id: IA-5(1)(c)-1
      description: The out-of-band authenticator SHALL establish a separate channel
        with the verifier in order to retrieve the out-of-band secret or authentication
        request.
      annotation: 'SUPPLEMENTAL GUIDANCE: A channel is considered to be out-of-band
        with respect to the primary communication channel (even if it terminates on
        the same device) provided the device does not leak information from one channel
        to the other without the authorization of the claimant.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)-2
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)
      ref_id: IA-5(1)(c)-2
      description: Communication over the secondary channel SHALL be encrypted unless
        sent via the public switched telephone network (PSTN).
      annotation: 'SUPPLEMENTAL GUIDANCE: The secondary channel requires protection
        to ensure that authentication secrets are not leaked to attackers. Legacy
        use of the PSTN as an OOB authentication medium is exempt from this requirement,
        although other requirements apply.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)-3
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)
      ref_id: IA-5(1)(c)-3
      description: Methods that do not prove possession of a specific device, such
        as voice-over-IP (VoIP) or email, SHALL NOT be used for out-of-band authentication.
      annotation: "SUPPLEMENTAL GUIDANCE: Communication with VoIP phone numbers and\
        \ email do \nnot establish the possession of a specific device, so they are\
        \ not suitable for use in out-ofband authentication which is used as a physical\
        \ authenticator (something you have)."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)-4
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)
      ref_id: IA-5(1)(c)-4
      description: If PSTN is not being used for out-of-band communication, then the
        out-of-band authenticator SHALL uniquely authenticate itself by establishing
        an authenticated protected channel with the verifier.
      annotation: 'SUPPLEMENTAL GUIDANCE: Communication between out-of-band device
        and verifier is required to be via an encrypted channel to provide confidentiality
        of the authenticator output and resistance to MitM attacks. This is typically
        accomplished using the Transport Level Security (TLS) protocol.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)-5
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)
      ref_id: IA-5(1)(c)-5
      description: If PSTN is not being used for out-of-band communication, then the
        out-of-band authenticator SHALL communicate with the verifier using approved
        cryptography.
      annotation: 'SUPPLEMENTAL GUIDANCE: Cryptography is considered approved if it
        is specified or adopted in a FIPS or NIST recommendation.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)-6
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)
      ref_id: IA-5(1)(c)-6
      description: If PSTN is not being used for out-of-band communication, then the
        key used to authenticate the out-of-band device SHALL be stored in suitably
        secure storage available to the authenticator application (e.g., keychain
        storage, TPM, TEE, secure element).
      annotation: "SUPPLEMENTAL GUIDANCE: The secret key associated with an out-of-band\
        \ device or authenticator application is critical to the determination of\
        \ \u201Csomething you have\u201D and needs to be well protected."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)-7
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)
      ref_id: IA-5(1)(c)-7
      description: If the PSTN is used for out-of-band authentication and a secret
        is sent to the out-of-band device via the PSTN, then the out-of-band authenticator
        SHALL uniquely authenticate itself to a mobile telephone network using a SIM
        card or equivalent that uniquely identifies the device.
      annotation: 'SUPPLEMENTAL GUIDANCE: Since the PSTN does not support the establishment
        of authenticated protected channels, the alternative method of authenticating
        the device via the PSTN is supported. Note that there are other specific requirements
        for use of the PSTN that also apply (see IA-5 (1) c (19) through (20)).'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)-8
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)
      ref_id: IA-5(1)(c)-8
      description: If the out-of-band authenticator sends an approval message over
        the secondary communication channel, it SHALL either accept transfer of a
        secret from the primary channel to be sent to the verifier via the secondary
        communications channel, or present a secret received via the secondary channel
        from the verifier and prompt the claimant to verify the consistency of that
        secret with the primary channel, prior to accepting a yes/no response from
        the claimant which it sends to the verifier.
      annotation: "SUPPLEMENTAL GUIDANCE: Most out-of-band verifiers operate by sending\
        \ a secret over the secondary channel that the subscriber transfers to the\
        \ primary channel (e.g., the capability to copy and paste from one app to\
        \ another). Other methods are possible, however, specifically transferring\
        \ from primary to secondary and user comparison of secrets sent to both channels\
        \ (with approval being sent to the verifier over the secondary channel). It\
        \ is good practice to display descriptive information relating to the authentication\
        \ on the claimant\u2019s out-of-band device, to provide additional assurance\
        \ that the transaction being approved by the subscriber is the correct one,\
        \ and not from an attacker who exploits the subscriber\u2019s approval."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)-9
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)
      ref_id: IA-5(1)(c)-9
      description: The verifier SHALL NOT store the identifying key itself, but SHALL
        use a verification method (e.g., an approved hash function or proof of possession
        of the identifying key) to uniquely identify the authenticator.
      annotation: "SUPPLEMENTAL GUIDANCE: In order for the out-of-band authenticator\
        \ to be considered \u201Csomething you have\u201D, it must be securely authenticated\
        \ as a unique device or instance of a software-based authentication application.\
        \ This is required to be done through proof of possession of a key by the\
        \ authenticator, rather than presentation of the key itself. This provides\
        \ verifier compromise resistance with respect to the authentication key."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)-10
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)
      ref_id: IA-5(1)(c)-10
      description: 'Depending on the type of out-of-band authenticator, one of the
        following SHALL take place: transfer of a secret to the primary channel, transfer
        of a secret to the secondary channel, or verification of secrets by the claimant.'
      annotation: 'SUPPLEMENTAL GUIDANCE: Three different methods of associating the
        primary and secondary channel sessions are permitted. The intent of these
        methods is to establish approval for a specific authentication transaction,
        and to minimize the likelihood that an attacker with knowledge of when the
        subscriber authenticates can obtain approval for a rogue authentication.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)-11
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)
      ref_id: IA-5(1)(c)-11
      description: If the out-of-band authenticator operates by transferring the secret
        to the primary channel, then the verifier SHALL transmit a random secret to
        the out-of-band authenticator and then wait for the secret to be returned
        on the primary communication channel.
      annotation: 'SUPPLEMENTAL GUIDANCE: This is the most common form of out-of-band
        authentication where an authentication secret is transmitted to the out-of-band
        device and entered by the user for transmission on the primary channel.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)-12
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)
      ref_id: IA-5(1)(c)-12
      description: "If the out-of-band authenticator operates by transferring the\
        \ secret to the secondary channel, then the verifier SHALL display a random\
        \ authentication secret to the claimant via the primary channel and then wait\
        \ for the secret to be returned on the secondary channel from the claimant\u2019\
        s out-of-band authenticator."
      annotation: 'SUPPLEMENTAL GUIDANCE: This is a less typical authentication flow
        but is also acceptable in that the secret securely associates possession and
        control of the out-of-band authenticator with the session being authenticated.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)-13
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)
      ref_id: IA-5(1)(c)-13
      description: If the out-of-band authenticator operates by verification of secrets
        by the claimant, then the verifier SHALL display a random authentication secret
        to the claimant via the primary channel, send the same secret to the out-of-band
        authenticator via the secondary channel for presentation to the claimant,
        and then wait for an approval (or disapproval) message via the secondary channel.
      annotation: 'SUPPLEMENTAL GUIDANCE: This is a somewhat more user-friendly authentication
        flow because it does not require the claimant to read and manually enter the
        authentication secret, but it carries the additional risk that the claimant
        will approve the authentication without actually comparing the secrets received
        from the independent channels. Approval is required to be obtained from the
        out-of-band authenticator rather than the primary channel because that at
        least establishes control of the authenticator.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)-14
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)
      ref_id: IA-5(1)(c)-14
      description: The authentication SHALL be considered invalid if not completed
        within 10 minutes.
      annotation: 'SUPPLEMENTAL GUIDANCE: Secrets used in out-of-band authentication
        are short-term secrets and need to have a definite lifetime. This requirement
        also relieves the verifier from the responsibility of log-term storage of
        the secrets.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)-15
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)
      ref_id: IA-5(1)(c)-15
      description: Verifiers SHALL accept a given authentication secret only once
        during the validity period.
      annotation: 'SUPPLEMENTAL GUIDANCE: In order to prevent an attacker who gains
        access to an authentication secret generated by the subscriber from using
        it, it is important that the secret only be valid for a single authentication.
        This requirement only applies when a secret is being transferred between the
        primary channel and the out-of-band authenticator.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)-16
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)
      ref_id: IA-5(1)(c)-16
      description: The verifier SHALL generate random authentication secrets with
        at least 20 bits of entropy.
      annotation: 'SUPPLEMENTAL GUIDANCE: Consistent with other short-term authentication
        secrets, 20 bits of entropy are required to provide resistance against brute
        force attacks. 6-digit numeric secrets (19.93 bits of entropy) are sufficiently
        close to 20 bits to be acceptable.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)-17
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)
      ref_id: IA-5(1)(c)-17
      description: The verifier SHALL generate random authentication secrets using
        an approved random bit generator.
      annotation: 'SUPPLEMENTAL GUIDANCE: The use of a high-quality random bit generator
        is important to ensure that an attacker cannot guess the out-of-band secret.Approved
        random bit generators are generally included in a FIPS 140-2 certified encryption
        module.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)-18
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)
      ref_id: IA-5(1)(c)-18
      description: "If the authentication secret has less than 64 bits of entropy,\
        \ the verifier SHALL implement a rate-limiting mechanism that effectively\
        \ limits the number of failed authentication attempts that can be made on\
        \ the subscriber\u2019s account as described in IA-5 l (3) through (4)."
      annotation: 'SUPPLEMENTAL GUIDANCE: Rate limiting limits the opportunity for
        attackers to mount a brute-force attack on the out-of-band verifier. Since
        the out-of-band secret has a limited lifetime, it is sufficient to limit the
        number of attempts allowed during the (maximum) 10-minute lifetime of the
        secret.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)-19
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)
      ref_id: IA-5(1)(c)-19
      description: If out-of-band verification is to be made using the PSTN, then
        the verifier SHALL verify that the pre-registered telephone number being used
        is associated with a specific physical device.
      annotation: "SUPPLEMENTAL GUIDANCE: Some telephone numbers, such as those that\
        \ are associated with VoIP services, are not associated with a specific device\
        \ and can receive calls and text messages without establishing possession\
        \ and control of a specific device. Such telephone numbers are not suitable\
        \ for OOB authentication. Services exist to distinguish telephone numbers\
        \ that are associated with a device from those that aren\u2019t."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)-20
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)
      ref_id: IA-5(1)(c)-20
      description: If out-of-band verification is to be made using the PSTN, then
        changing the pre-registered telephone number is considered to be the binding
        of a new authenticator and SHALL only occur as described in IA-5 n (17) through
        (25).
      annotation: 'SUPPLEMENTAL GUIDANCE: The binding of a new authenticator requires
        that the subscriber authenticate at the same or a higher AAL (currently AAL2)
        than that at which the authenticator will be used, and that a notification
        be sent to the subscriber. This is required to prevent attackers from changing
        the phone number of a PSTN-based out-of-band authenticator to one they control.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)-21
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)
      ref_id: IA-5(1)(c)-21
      description: If PSTN is used for out-of-band authentication, then the CSP SHALL
        offer subscribers at least one alternate authenticator that is not RESTRICTED
        and can be used to authenticate at the required AAL.
      annotation: 'SUPPLEMENTAL GUIDANCE: Use of the PSTN for out-of-band authentication
        involves additional risk, resulting in its being designated as a restricted
        authenticator. CSPs are required to provide subscribers with a meaningful
        alternative.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)-22
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)
      ref_id: IA-5(1)(c)-22
      description: If PSTN is used for out-of-band authentication, then the CSP SHALL
        Provide meaningful notice to subscribers regarding the security risks of the
        RESTRICTED authenticator and availability of alternative(s) that are not RESTRICTED.
      annotation: "SUPPLEMENTAL GUIDANCE: Use of the PSTN for out-of-band authentication\
        \ involves additional risk, resulting in its being designated as a restricted\
        \ authenticator. CSPs are required to explain these risks to subscribers and\
        \ offer more secure alternatives. \nCurrently, authenticators leveraging the\
        \ public switched telephone network, including phone- and Short Message Service\
        \ (SMS)-based one-time passwords (OTPs) are restricted. Other authenticator\
        \ types may be added as additional threats emerge. Note that, among other\
        \ requirements, even when using phone- and SMS-based OTPs, the agency also\
        \ must verify that the OTP is being directed to a phone and not an IP address,\
        \ such as with VoIP, as these accounts are not typically protected with multi-factor\
        \ authentication."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)-23
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)
      ref_id: IA-5(1)(c)-23
      description: If PSTN is used for out-of-band authentication, then the CSP SHALL
        address any additional risk to subscribers in its risk assessment.
      annotation: 'SUPPLEMENTAL GUIDANCE: Use of the PSTN for out-of-band authentication
        involves additional risk, resulting in its being designated as a restricted
        authenticator. These risks need to be documented.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)-24
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(c)
      ref_id: IA-5(1)(c)-24
      description: If PSTN is used for out-of-band authentication, then the CSP SHALL
        develop a migration plan for the possibility that the RESTRICTED authenticator
        is no longer acceptable at some point in the future and include this migration
        plan in its digital identity acceptance statement.
      annotation: 'SUPPLEMENTAL GUIDANCE: Use of the PSTN for out-of-band authentication
        involves additional risk, resulting in its being designated as a restricted
        authenticator. A plan for eliminating them in the future needs to be documented.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)
      assessable: false
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)
      ref_id: IA-5(1)(d)
      name: OTP Authenticators and Verifiers
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)-1
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)
      ref_id: IA-5(1)(d)-1
      description: The secret key and its algorithm SHALL provide at least the minimum
        security strength of 112 bits as of the date of this publication.
      annotation: 'SUPPLEMENTAL GUIDANCE: The secret key used by an OTP authenticator
        needs to be sufficiently complex to resist online and offline attacks. An
        attacker may have the ability to observe the authenticator output at some
        point during its operation; it needs to be impractical for the secret key
        to be derived from a set of these observations.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)-2
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)
      ref_id: IA-5(1)(d)-2
      description: The nonce SHALL be of sufficient length to ensure that it is unique
        for each operation of the device over its lifetime.
      annotation: "SUPPLEMENTAL GUIDANCE: If the nonce isn\u2019t long enough, the\
        \ output of the authenticator will repeat, which represents an easily avoided\
        \ vulnerability."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)-3
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)
      ref_id: IA-5(1)(d)-3
      description: "OTP authenticators \u2014 particularly software-based OTP generators\
        \ \u2014SHALL NOT facilitate the cloning of the secret key onto multiple devices."
      annotation: 'SUPPLEMENTAL GUIDANCE: Like other physical authenticators, the
        use of OTP authenticators is premised upon the authenticator secret being
        present in a single authenticator so that it proves possession of a specific
        device. Mechanisms that would facilitate cloning the secret onto multiple
        devices include the ability to enroll more than one device producing the same
        OTP output and backup mechanisms, especially when software-based authenticators
        are used. Verifiers are expected to make their best effort at determining
        that bring-your-own authenticators not issued by them meet this requirement
        and to have policies not allowing the use of non-compliant authenticators'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)-4
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)
      ref_id: IA-5(1)(d)-4
      description: The authenticator output SHALL have at least 6 decimal digits (approximately
        20 bits) of entropy.
      annotation: 'SUPPLEMENTAL GUIDANCE: Consistent with other short-term authentication
        secrets, 20 bits of entropy are required to provide resistance against brute
        force attacks. 6-digit numeric secrets (19.93 bits of entropy) are sufficiently
        close to 20 bits to be acceptable.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)-5
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)
      ref_id: IA-5(1)(d)-5
      description: If the nonce used to generate the authenticator output is based
        on a real-time clock, then the nonce SHALL be changed at least once every
        2 minutes.
      annotation: 'SUPPLEMENTAL GUIDANCE: The authenticator output needs to be changed
        often enough that there is reasonable assurance that it is in the possession
        of the claimant and that it is not susceptible to OTP-guessing attacks.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)-6
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)
      ref_id: IA-5(1)(d)-6
      description: The OTP value associated with a given nonce SHALL be accepted only
        once.
      annotation: "SUPPLEMENTAL GUIDANCE: A fundamental premise of a \u201Cone-time\u201D\
        \ authenticator is that it can be used successfully only once during its validity\
        \ period."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)-7
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)
      ref_id: IA-5(1)(d)-7
      description: The symmetric keys used by authenticators are also present in the
        verifier and SHALL be strongly protected against compromise.
      annotation: 'SUPPLEMENTAL GUIDANCE: Verifiers typically contain symmetric keys
        for all subscribers using OTP authenticators. This makes them a particularly
        rich target for attackers. While the protection of these keys is implementation-
        dependent and there is therefore no specific requirement for how the keys
        are protected, measures to prevent the exfiltration of the keys are needed.
        An example of such a measure is the storage of keys and generation of authenticator
        outputs in a separate device accessible only by the verifier.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)-8
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)
      ref_id: IA-5(1)(d)-8
      description: If a single-factor OTP authenticator is being associated with a
        subscriber account, then the verifier or associated CSP SHALL use approved
        cryptography to either generate and exchange or to obtain the secrets required
        to duplicate the authenticator output.
      annotation: 'SUPPLEMENTAL GUIDANCE: It is critical that authentication secrets
        be generated and transferred or negotiated securely. This includes the use
        of secure random number generators and protocols for transferring or negotiating
        (e.g., Diffie-Hellman) secret values. Cryptography is considered approved
        if it is specified or adopted in a FIPS or NIST recommendation.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)-9
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)
      ref_id: IA-5(1)(d)-9
      description: The verifier SHALL use approved encryption when collecting the
        OTP.
      annotation: 'SUPPLEMENTAL GUIDANCE: Cryptography is considered approved if it
        is specified or adopted in a FIPS or NIST recommendation.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)-10
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)
      ref_id: IA-5(1)(d)-10
      description: The verifier SHALL use an authenticated protected channel when
        collecting the OTP.
      annotation: 'SUPPLEMENTAL GUIDANCE: Communication between claimant and verifier
        is required to be via an encrypted channel that authenticates the verifier
        to provide confidentiality of the authenticator output and resistance to MitM
        attacks. This is typically accomplished using the Transport Level Security
        (TLS) protocol.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)-11
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)
      ref_id: IA-5(1)(d)-11
      description: "If a time-based OTP is used, it SHALL have a defined lifetime\
        \ (recommended 30 seconds) that is determined by the expected clock drift\
        \ \u2014 in either direction \u2014 of the authenticator over its lifetime,\
        \ plus allowance for network delay and user entry of the OTP."
      annotation: 'SUPPLEMENTAL GUIDANCE: The clocks on time-based authenticators
        are subject to drift because of cost and environmental factors such as temperature.
        Accordingly, verifiers need to accept authenticator outputs before and particularly
        after the intended validity period to allow use by authenticators that are
        not in synchronization.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)-12
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)
      ref_id: IA-5(1)(d)-12
      description: Verifiers SHALL accept a given time-based OTP only once during
        the validity period.
      annotation: 'SUPPLEMENTAL GUIDANCE: In order to prevent an attacker who gains
        access to an OTP authenticator output from using it, it is important that
        the secret only be valid for a single authentication.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)-13
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)
      ref_id: IA-5(1)(d)-13
      description: "If the authenticator output has less than 64 bits of entropy,\
        \ the verifier SHALL implement a rate-limiting mechanism that effectively\
        \ limits the number of failed authentication attempts that can be made on\
        \ the subscriber\u2019s account as described in IA-5 l (3) through (4)."
      annotation: 'SUPPLEMENTAL GUIDANCE: OTPs whose output has less entropy are more
        vulnerable to online guessing attacks. To mitigate these attacks, rate limiting
        is required. Online guessing attacks are less of a concern for time-based
        OTP authenticators because of the limited validity window, but a limit on
        the number of guesses during a given validity period is effective in resisting
        automated attacks.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)-14
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)
      ref_id: IA-5(1)(d)-14
      description: If the authenticator is multi-factor, then each use of the authenticator
        SHALL require the input of the additional factor.
      annotation: 'SUPPLEMENTAL GUIDANCE: To ensure that a multi-factor authenticator
        cannot be stolen and used repeatedly following activation, a separate activation
        is required for each use of the authenticator. It is preferable for a multi-factor
        authenticator not to indicate that the wrong memorized secret or biometric
        were presented, but rather to produce an authenticator output that is invalid,
        although this is not required. This provides protection against guessing or
        presentation attacks on the authenticator itself.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)-15
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)
      ref_id: IA-5(1)(d)-15
      description: If the authenticator is multi-factor and a memorized secret is
        used by the authenticator for activation, then that memorized secret SHALL
        be a randomly chosen numeric secret at least 6 decimal digits in length or
        other memorized secret meeting the requirements of IA5 (1)(a).
      annotation: 'SUPPLEMENTAL GUIDANCE: The requirement for memorized secrets used
        as activation factors is the same as that for memorized secrets used as distinct
        authenticators (see IA-5 (1)(a)).'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)-16
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)
      ref_id: IA-5(1)(d)-16
      description: If the authenticator is multi-factor, then use of a memorized secret
        for activation SHALL be rate limited as specified in IA-5 l (3) through (4).
      annotation: 'SUPPLEMENTAL GUIDANCE: Rate limiting is required to provide protection
        against brute-force guessing attacks, particularly if the authenticator gives
        an indication when an incorrect secret is entered.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)-17
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)
      ref_id: IA-5(1)(d)-17
      description: If the authenticator is multi-factor and is activated by a biometric
        factor, then that factor SHALL meet the requirements of IA-5 m, including
        limits on the number of consecutive authentication failures.
      annotation: 'SUPPLEMENTAL GUIDANCE: General requirements for biometric activation
        factors include false accept rate criteria and the number of consecutive authentication
        failures that are allowed.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)-18
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)
      ref_id: IA-5(1)(d)-18
      description: "If the authenticator is multi-factor, then the unencrypted key\
        \ and activation secret or biometric sample \u2014 and any biometric data\
        \ derived from the biometric sample such as a probe produced through signal\
        \ processing \u2014 SHALL be zeroized immediately after an OTP has been generated."
      annotation: 'SUPPLEMENTAL GUIDANCE: It is important that the unencrypted key
        and associated data be zeroized to minimize the likelihood that it can be
        misappropriated by an attacker following a successful authentication. Each
        authentication requires a re-presentation of the activation factor (see IA-5(1)(d)14).
        Verifiers are expected to make their best effort at determining that bring-your-own
        authenticators not issued by them meet this requirement and to have policies
        not allowing the use of non-compliant authenticators.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)-19
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)
      ref_id: IA-5(1)(d)-19
      description: If the authenticator is multi-factor, the verifier or CSP SHALL
        establish, via the authenticator source, that the authenticator is a multi-factor
        device.
      annotation: 'SUPPLEMENTAL GUIDANCE: From the standpoint of a verifier, a multi-factor
        OTP authenticator appears the same as a single-factor OTP authenticator. In
        order to establish that the authenticator meets the multi-factor requirements,
        the verifier or CSP can issue the authenticator, examine it in some way, or
        rely on an assertion from the manufacturer.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)-20
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(d)
      ref_id: IA-5(1)(d)-20
      description: In the absence of a trusted statement that it is a multi-factor
        device, the verifier SHALL treat the authenticator as single-factor, in accordance
        with IA-5 (1) (d) (1) through (13).
      annotation: 'SUPPLEMENTAL GUIDANCE: Authenticators of unknown provenance or
        that are not known by the CSP or verifier to meet all of the requirements
        for multi-factor OTP authenticators can be used, but only as single-factor
        authenticators.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(e)
      assessable: false
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)
      ref_id: IA-5(1)(e)
      name: Cryptographic Authenticators and Verifiers (including single- and multi-factor
        cryptographic authenticators, both hardware- and software-based)
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(e)-1
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(e)
      ref_id: IA-5(1)(e)-1
      description: If the cryptographic authenticator is software based, the key SHALL
        be stored in suitably secure storage available to the authenticator application
      annotation: 'SUPPLEMENTAL GUIDANCE: Although dependent on the computing device
        on which the authenticator is operating, authenticator software needs to avail
        itself of the most secure storage available, considering issues like ability
        to extract the secret from the device and its potential to be included in
        backup data. Verifiers are expected to make their best effort at determining
        that bring-your-own authenticators not issued by them meet this requirement
        and to have policies not allowing the use of non-compliant authenticators.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(e)-2
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(e)
      ref_id: IA-5(1)(e)-2
      description: If the cryptographic authenticator is software based, the key SHALL
        be strongly protected against unauthorized disclosure by the use of access
        controls that limit access to the key to only those software components on
        the device requiring access.
      annotation: 'SUPPLEMENTAL GUIDANCE: Although dependent on the computing device
        on which the authenticator is operating, authenticator software needs to store
        secret keys in a manner that limits access to keys to the maximum extent possible
        so that they cannot be accessed by other (possibly rogue) applications and/or
        users. Verifiers are expected to make their best effort at determining that
        bring-your-own authenticators not issued by them meet this requirement and
        to have policies not allowing the use of non-compliant authenticators.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(e)-3
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(e)
      ref_id: IA-5(1)(e)-3
      description: If the cryptographic authenticator is software based, it SHALL
        NOT facilitate the cloning of the secret key onto multiple devices.
      annotation: 'SUPPLEMENTAL GUIDANCE: Like other physical authenticators, the
        use of cryptographic authenticators is premised upon the authenticator secret
        being present in a single authenticator so that it proves possession of a
        specific device. Mechanisms that would facilitate cloning the secret onto
        multiple devices include the ability to enroll more than one device with the
        same key and backup mechanisms, especially when software-based authenticators
        are used. Verifiers are expected to make their best effort at determining
        that bring-your-own authenticators not issued by them meet this requirement
        and to have policies not allowing the use of non-compliant authenticators.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(e)-4
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(e)
      ref_id: IA-5(1)(e)-4
      description: If the authenticator is single-factor and hardware-based, secret
        keys unique to the device SHALL NOT be exportable (i.e., cannot be removed
        from the device).
      annotation: 'SUPPLEMENTAL GUIDANCE: Cryptographic device authenticators are
        constructed so as not to allow the secret key to be obtained from the device.
        These devices are enrolled for authentication using the public cryptographic
        key, but the private key is never shared. This requirement addresses primarily
        functionality allowing the key to be exported; FIPS 140 requirements cover
        the resistance of the device to various forms of attack.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(e)-5
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(e)
      ref_id: IA-5(1)(e)-5
      description: If the authenticator is hardware-based, the secret key and its
        algorithm SHALL provide at least the minimum-security length of 112 bits as
        of the date of this publication.
      annotation: 'SUPPLEMENTAL GUIDANCE: The secret key used by a cryptographic authenticator
        needs to be sufficiently complex to resist online and offline attacks. An
        attacker may have the ability to observe the authenticator output at some
        point during its operation; it needs to be impractical for the secret key
        to be derived from a set of these observations. Since verifiers and cryptographic
        authenticators must use the same algorithms to successfully authenticate,
        assessment of the verifier also assesses the authenticators that may be used.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(e)-6
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(e)
      ref_id: IA-5(1)(e)-6
      description: If the authenticator is hardware-based, the challenge nonce SHALL
        be at least 64 bits in length.
      annotation: 'SUPPLEMENTAL GUIDANCE: This requirement applies to hardware-based
        cryptographic authenticators. The challenge nonce is required to be large
        enough that it will not be reused during the lifetime of the authenticator
        in order to provide replay protection. Since verifiers and cryptographic authenticators
        must use the same algorithms to successfully authenticate, assessment of the
        nonce generated by the verifier also assesses the authenticators that may
        be used.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(e)-7
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(e)
      ref_id: IA-5(1)(e)-7
      description: If the authenticator is hardware-based, approved cryptography SHALL
        be used.
      annotation: 'SUPPLEMENTAL GUIDANCE: Cryptography is considered approved if it
        is specified or adopted in a FIPS or NIST recommendation. Since verifiers
        and cryptographic authenticators must use the same algorithms to successfully
        authenticate, assessment of the verifier also assesses the authenticators
        that may be used.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(e)-8
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(e)
      ref_id: IA-5(1)(e)-8
      description: Cryptographic keys stored by the verifier SHALL be protected against
        modification.
      annotation: "SUPPLEMENTAL GUIDANCE: Protection against modification is required\
        \ for all keys to ensure that an attacker can\u2019t substitute keys they\
        \ control, which would permit them to authenticate successfully. This protection\
        \ could be provided by operating system access controls, or through integrity\
        \ checks of the stored keys with separately stored hashes."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(e)-9
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(e)
      ref_id: IA-5(1)(e)-9
      description: If symmetric keys are used, cryptographic keys stored by the verifier
        SHALL be protected against disclosure.
      annotation: 'SUPPLEMENTAL GUIDANCE: Protection against disclosure is required
        for symmetric keys because their disclosure also would permit an attacker
        to authenticate successfully. This protection could be provided through operating
        system access controls.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(e)-10
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(e)
      ref_id: IA-5(1)(e)-10
      description: The challenge nonce SHALL be at least 64 bits in length.
      annotation: 'SUPPLEMENTAL GUIDANCE: This requirement applies to verifiers of
        cryptographic authentication. The challenge nonce is generated by the verifier
        and used by a cryptographic authenticator to compute the authenticator output.
        The challenge needs to be sufficiently long that it will not need to repeat
        during the lifetime of the authenticator, so the authenticator output, if
        available to an attacker, cannot be replayed.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(e)-11
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(e)
      ref_id: IA-5(1)(e)-11
      description: "The challenge nonce SHALL either be unique over the authenticator\u2019\
        s lifetime or statistically unique (i.e., generated using an approved random\
        \ bit generator)."
      annotation: 'SUPPLEMENTAL GUIDANCE: The challenge nonce is generated by the
        verifier used by a cryptographic authenticator to compute the authenticator
        output. The nonce cannot repeat during the lifetime of the authenticator,
        so the authenticator output, if available to an attacker, cannot be replayed.
        This can be accomplished by either deterministic means (e.g., an algorithm
        choosing values guaranteed not to repeat) or statistically (random values
        chosen from a range giving a very low probability that the same nonce will
        ever be seen twice).'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(e)-12
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(e)
      ref_id: IA-5(1)(e)-12
      description: The verification operation SHALL use approved cryptography.
      annotation: 'SUPPLEMENTAL GUIDANCE: Cryptography is considered approved if it
        is specified or adopted in a FIPS or NIST recommendation. Since verifiers
        and cryptographic authenticators must use the same algorithms to successfully
        authenticate, assessment of the verifier also assesses the authenticators
        that may be used.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(e)-13
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(e)
      ref_id: IA-5(1)(e)-13
      description: If a multi-factor cryptographic software authenticator is being
        used, then each authentication requires the presentation of the activation
        factor.
      annotation: 'SUPPLEMENTAL GUIDANCE: The activation factor, either a memorized
        secret or a biometric, is required to be presented each time an authentication
        operation is requested by the authenticator to ensure that an activated authenticator
        cannot be used by an attacker.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(e)-14
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(e)
      ref_id: IA-5(1)(e)-14
      description: If the authenticator is multi-factor, then any memorized secret
        used by the authenticator for activation SHALL be a randomly chosen numeric
        secret at least 6 decimal digits in length or other memorized secret meeting
        the requirements of IA-5 (1) (a).
      annotation: 'SUPPLEMENTAL GUIDANCE: The requirement for memorized secrets used
        as activation factors is the same as that for memorized secrets used as distinct
        authenticators (see IA-5(1)a).'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(e)-15
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(e)
      ref_id: IA-5(1)(e)-15
      description: If the authenticator is multi-factor, then use of a memorized secret
        for activation SHALL be rate limited as specified in IA-5 l (3) through (4).
      annotation: 'SUPPLEMENTAL GUIDANCE: Rate limiting is required to provide protection
        against brute-force guessing attacks, particularly if the authenticator gives
        an indication when an incorrect secret is entered.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(e)-16
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(e)
      ref_id: IA-5(1)(e)-16
      description: If the authenticator is multi-factor and is activated by a biometric
        factor, then that factor SHALL meet the requirements of IA-5 m, including
        limits on the number of consecutive authentication failures.
      annotation: 'SUPPLEMENTAL GUIDANCE: General requirements for biometric activation
        factors include false accept rate criteria and the number of consecutive authentication
        failures that are allowed.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(e)-17
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)(e)
      ref_id: IA-5(1)(e)-17
      description: "If the authenticator is multi-factor, then the unencrypted key\
        \ and activation secret or biometric sample \u2014 and any biometric data\
        \ derived from the biometric sample such as a probe produced through signal\
        \ processing \u2014 SHALL be zeroized immediately after an authentication\
        \ transaction has taken place."
      annotation: 'SUPPLEMENTAL GUIDANCE: It is important that the unencrypted key
        and associated data be zeroized to minimize the likelihood that it can be
        misappropriated by an attacker following a successful authentication. Verifiers
        are expected to make their best effort at determining that bring-your-own
        authenticators not issued by them meet this requirement and to have policies
        not allowing the use of non-compliant authenticators.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node924
      assessable: false
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(1)
      description: 'Related Controls: IA-6.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(2)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5
      ref_id: IA-5(2)
      name: AUTHENTICATOR MANAGEMENT | PUBLIC KEY BASED AUTHENTICATION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(2)-a
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(2)
      ref_id: IA-5(2)-a
      description: 'For public key-based authentication:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(2)-a-1
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(2)-a
      ref_id: IA-5(2)-a-1
      description: Enforce authorized access to the corresponding private key; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(2)-a-2
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(2)-a
      ref_id: IA-5(2)-a-2
      description: Map the authenticated identity to the account of the individual
        or group; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(2)-b
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(2)
      ref_id: IA-5(2)-b
      description: 'When public key infrastructure (PKI) is used:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(2)-b-1
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(2)-b
      ref_id: IA-5(2)-b-1
      description: Validate certificates by constructing and verifying a certification
        path to an accepted trust anchor, including checking certificate status information;
        and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(2)-b-2
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(2)-b
      ref_id: IA-5(2)-b-2
      description: Implement a local cache of revocation data to support path discovery
        and validation.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node932
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(2)
      description: "DISCUSSION: Public key cryptography is a valid authentication\
        \ mechanism for individuals, machines, and devices. For PKI solutions, status\
        \ information for certification paths includes certificate revocation lists\
        \ or certificate status protocol responses. For PIV cards, certificate validation\
        \ involves the construction and verification of a certification path to the\
        \ Common Policy Root trust anchor, which includes certificate policy processing.\
        \ Implementing a local cache of revocation data to support path discovery\
        \ and validation also supports system availability in situations where organizations\
        \ are unable to access revocation information via the network.A local cache\
        \ of revocation data is also known as a certificate revocation list. This\
        \ list contains a list of revoked certificates and can be periodically downloaded\
        \ to ensure certificates can still be checked for revocation when network\
        \ access is not available or access to the Online Certificate Status Protocol\
        \ (OCSP) server is not available. Without configuring a local cache of revocation\
        \ data, there is the potential to allow access to users who are no longer\
        \ authorized (users with revoked certificates). \nRelated Controls: IA-3,\
        \ SC-17."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(6)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5
      ref_id: IA-5(6)
      name: AUTHENTICATOR MANAGEMENT | PROTECTION OF AUTHENTICATORS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node934
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(6)
      description: Protect authenticators commensurate with the security category
        of the information to which use of the authenticator permits access.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node935
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-5(6)
      description: "DISCUSSION: For systems that contain multiple security categories\
        \ of information without reliable physical or logical separation between categories,\
        \ authenticators used to grant access to the systems are protected commensurate\
        \ with the highest security category of information on the systems. Security\
        \ categories of information are determined as part of the security categorization\
        \ process. \nRelated Controls: RA-2."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-6
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.6
      ref_id: IA-6
      name: AUTHENTICATION FEEDBACK
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node937
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-6
      description: Obscure feedback of authentication information during the authentication
        process to protect the information from possible exploitation and use by unauthorized
        individuals.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node938
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-6
      description: "DISCUSSION: Authentication feedback from systems does not provide\
        \ information that would allow unauthorized individuals to compromise authentication\
        \ mechanisms. For some types of systems, such as desktops or notebooks with\
        \ relatively large monitors, the threat (referred to as shoulder surfing)\
        \ may be significant. For other types of systems, such as mobile devices with\
        \ small displays, the threat may be less significant and is balanced against\
        \ the increased likelihood of typographic input errors due to small keyboards.\
        \ Thus, the means for obscuring authentication feedback is selected accordingly.\
        \ Obscuring authentication feedback includes displaying asterisks when users\
        \ type passwords into input devices or displaying feedback for a very limited\
        \ time before obscuring it. \nRelated Controls: AC-3."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-7
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.6
      ref_id: IA-7
      name: CRYPTOGRAPHIC MODULE AUTHENTICATION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node940
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-7
      description: Implement mechanisms for authentication to a cryptographic module
        that meet the requirements of applicable laws, executive orders, directives,
        policies, regulations, standards, and guidelines for such authentication.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node941
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-7
      description: 'DISCUSSION: Authentication mechanisms may be required within a
        cryptographic module to authenticate an operator accessing the module and
        to verify that the operator is authorized to assume the requested role and
        perform services within that role.

        Related Controls: AC-3, IA-5, SA-4, SC-12, SC-13.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-8
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.6
      ref_id: IA-8
      name: IDENTIFICATION AND AUTHENTICATION (NON-ORGANIZATIONAL USERS)
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node943
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-8
      description: Uniquely identify and authenticate non-organizational users or
        processes acting on behalf of nonorganizational users.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node944
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-8
      description: "DISCUSSION: Non-organizational users include system users other\
        \ than organizational users explicitly covered by IA-2. Non-organizational\
        \ users are uniquely identified and authenticated for accesses other than\
        \ those explicitly identified and documented in AC-14. Identification and\
        \ authentication of non-organizational users accessing federal systems may\
        \ be required to protect federal, proprietary, or privacy-related information\
        \ (with exceptions noted for national security systems). Organizations consider\
        \ many factors\u2014including security, privacy, scalability, and practicality\u2014\
        when balancing the need to ensure ease of use for access to federal information\
        \ and systems with the need to protect and adequately mitigate risk.\nRelated\
        \ Controls: AC-2, AC-6, AC-14, AC-17, AC-18, AU-6, IA-2, IA-4, IA-5, IA-11,\
        \ MA-4, RA-3, SA-4, SC-8."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-8(1)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-8
      ref_id: IA-8(1)
      name: IDENTIFICATION AND AUTHENTICATION (NON-ORGANIZATIONAL USERS) | ACCEPTANCE
        OF PIV CREDENTIALS FROM OTHER AGENCIES
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node946
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-8(1)
      description: Accept and electronically verify Personal Identity Verification-compliant
        credentials from other federal, state, local, tribal, or territorial (SLTT)
        agencies.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node947
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-8(1)
      description: 'DISCUSSION: Acceptance of Personal Identity Verification (PIV)
        credentials from other federal or SLTT agencies applies to both logical and
        physical access control systems. PIV credentials are those credentials issued
        by federal or SLTT agencies that conform to FIPS Publication 201 and supporting
        guidelines.

        Related Controls: PE-3.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-8(2)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-8
      ref_id: IA-8(2)
      name: IDENTIFICATION AND AUTHENTICATION (NON-ORGANIZATIONAL USERS) | ACCEPTANCE
        OF EXTERNAL AUTHENTICATORS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-8(2)-a
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-8(2)
      ref_id: IA-8(2)-a
      description: Accept only external authenticators that are NIST-compliant; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-8(2)-b
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-8(2)
      ref_id: IA-8(2)-b
      description: Document and maintain a list of accepted external authenticators.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node951
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-8(2)
      description: 'DISCUSSION: Acceptance of only NIST-compliant external authenticators
        applies to organizational systems that are accessible to the public (e.g.,
        public-facing websites). External authenticators are issued by nonfederal
        government entities and are compliant with the CJISSECPOL. Approved external
        authenticators meet or exceed the minimum Federal Government-wide technical,
        security, privacy, and organizational maturity requirements. Meeting or exceeding
        Federal requirements allows Federal Government relying parties to trust external
        authenticators in connection with an authentication transaction at a specified
        authenticator assurance level.

        Related Controls: None.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-8(4)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-8
      ref_id: IA-8(4)
      name: IDENTIFICATION AND AUTHENTICATION (NON-ORGANIZATIONAL USERS) | USE OF
        DEFINED PROFILES
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node953
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-8(4)
      description: 'Conform to the following profiles for identity management: Security
        Assertion Markup Language (SAML) or OpenID Connect'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node954
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-8(4)
      description: 'DISCUSSION: Organizations define profiles for identity management
        based on open identity management standards. To ensure that open identity
        management standards are viable, robust, reliable, sustainable, and interoperable
        as documented, the Federal Government assesses and scopes the standards and
        technology implementations against applicable laws, executive orders, directives,
        policies, regulations, standards, and guidelines.

        Related Controls: None.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-11
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.6
      ref_id: IA-11
      name: RE-AUTHENTICATION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node956
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-11
      description: 'Require users to re-authenticate when: roles, authenticators,
        or credentials change, security categories of systems change, the execution
        of privileged functions occur, or every 12 hours.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node957
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-11
      description: 'DISCUSSION: In addition to the re-authentication requirements
        associated with device locks, organizations may require re-authentication
        of individuals in certain situations, including when roles, authenticators,
        or credentials change, when security categories of systems change, when the
        execution of privileged functions occurs, after a fixed time period, or periodically.

        Related Controls: AC-3, AC-11, IA-2, IA-3, IA-4, IA-8.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.6
      ref_id: IA-12
      name: IDENTITY PROOFING
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12
      ref_id: IA-12-a
      description: Identity proof users that require accounts for logical access to
        systems based on appropriate identity assurance level requirements as specified
        in applicable standards and guidelines;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12
      ref_id: IA-12-b
      description: Resolve user identities to a unique individual; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12
      ref_id: IA-12-c
      description: Collect, validate, and verify identity evidence.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node962
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12
      description: "DISCUSSION: Identity proofing is the process of collecting, validating,\
        \ and verifying a user\u2019s identity information for the purposes of establishing\
        \ credentials for accessing a system. Identity proofing is intended to mitigate\
        \ threats to the registration of users and the establishment of their accounts.\
        \ Organizations may be subject to laws, executive orders, directives, regulations,\
        \ or policies that address the collection of identity evidence. Organizational\
        \ personnel consult with the senior agency official for privacy and legal\
        \ counsel regarding such requirements.\nRelated Controls: AC-5, IA-1, IA-2,\
        \ IA-3, IA-4, IA-5, IA-6, IA-8."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(2)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12
      ref_id: IA-12(2)
      name: IDENTITY PROOFING | IDENTITY EVIDENCE
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node964
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(2)
      description: Require evidence of individual identification be presented to the
        registration authority.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node965
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(2)
      description: "DISCUSSION: Identity evidence, such as documentary evidence or\
        \ a combination of documents and biometrics, reduces the likelihood of individuals\
        \ using fraudulent identification to establish an identity or at least increases\
        \ the work factor of potential adversaries. The forms of acceptable evidence\
        \ are consistent with the risks to the systems, roles, and privileges associated\
        \ with the user\u2019s account.\nRelated Controls: None."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12
      ref_id: IA-12(3)
      name: IDENTITY PROOFING | IDENTITY EVIDENCE VALIDATION AND VERIFICATION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-a
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)
      ref_id: IA-12(3)-a
      description: Require that the presented identity evidence be validated and verified
        through agencydefined resolution, validation, and verification methods.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node968
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)
      description: 'DISCUSSION: Validation and verification of identity evidence increases
        the assurance that accounts and identifiers are being established for the
        correct user and authenticators are being bound to that user. Validation refers
        to the process of confirming that the evidence is genuine and authentic, and
        the data contained in the evidence is correct, current, and related to an
        individual. Verification confirms and establishes a linkage between the claimed
        identity and the actual existence of the user presenting the evidence. Acceptable
        methods for validating and verifying identity evidence are consistent with
        the risks to the systems, roles, and privileges associated with the users
        account.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-b
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)
      ref_id: IA-12(3)-b
      description: Identity proofing SHALL NOT be performed to determine suitability
        or entitlement to gain access to services or benefits.
      annotation: 'SUPPLEMENTAL GUIDANCE: The sole objective of identity proofing
        is to ensure the applicant is who they claim to be to a stated level of certitude.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-c-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)
      ref_id: IA-12(3)-c-1
      description: Collection of PII SHALL be limited to the minimum necessary to
        resolve to a unique identity in a given context.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-c-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)
      ref_id: IA-12(3)-c-2
      description: Collection of PII SHALL be limited to the minimum necessary to
        validate the existence of the claimed identity and associate the claimed identity
        with the applicant providing identity evidence for appropriate identity resolution,
        validation, and verification.
      annotation: "SUPPLEMENTAL GUIDANCE: The goal of identity resolution is to uniquely\
        \ distinguish an individual within a given population or context. Effective\
        \ identity resolution uses the smallest set of attributes necessary to resolve\
        \ to a unique individual. It provides the CSP an important starting point\
        \ in the overall identity proofing process, to include the initial detection\
        \ of potential fraud, but in no w a y represents a complete and successful\
        \ identity proofing transaction. \nCollection of PII may include attributes\
        \ are used to correlate identity evidence to authoritative sources and to\
        \ provide RPs with attributes used to make authorization decisions. There\
        \ may be many different sets that suffice as the minimum, so it is recommended\
        \ that CSPs choose this set to balance privacy and the user\u2019s usability\
        \ needs, as well as the likely attributes needed in future uses of the digital\
        \ identity.\nExamples of attributes that may be used for minimum identity\
        \ attribute sets include: \n\u25CF\tName (first, last. middle) with combinations\
        \ and variations, \n\u25CF\tAddress (#, Street, City, County, State, Zip code)\
        \ with combinations and variations, \n\u25CF\tDate of birth (DDMMYYYY) with\
        \ combinations and variations, \n\u25CF\tEmail address, \n\u25CF\tPhone number.\
        \ \nFor population sets that are more defined than the general population\
        \ (e.g., military veterans, Native Americans), these minimum attribute sets\
        \ may be tailored to that specific community. \nAdditionally, it is recommended\
        \ that CSPs document which alternative attributes it will accept in cases\
        \ where an applicant cannot provide the minimum necessary attributes (e.g.,\
        \ applicant does not have a home address or phone number)."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-d
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)
      ref_id: IA-12(3)-d
      description: The CSP SHALL provide explicit notice to the applicant at the time
        of collection regarding the purpose for collecting and maintaining a record
        of the attributes necessary for identity proofing, including whether such
        attributes are voluntary or mandatory to complete the identity proofing process,
        and the consequences for not providing the attributes.
      annotation: "SUPPLEMENTAL GUIDANCE: Notice of proofing may contain at a minimum:\
        \ \n\u25CF\tAttribute information that is mandatory \n\u25CF\tAttribute information\
        \ that is voluntary \n\u25CF\tWhat will be done with the information collected\
        \ \n\u25CF\tHow the information will be protected \n\u25CF\tConsequence of\
        \ not providing mandatory attribute information (e.g., suspension/termination\
        \ of the identity proofing process). \nThis notice may be delivered as an\
        \ online screen (for remote identity proofing), a poster or printed notice\
        \ at in-person proofing locations, or an oral notice delivered at the time\
        \ of information collection."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-e
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)
      ref_id: IA-12(3)-e
      description: "If CSPs process attributes for purposes other than identity proofing,\
        \ authentication, or attribute assertions (collectively \u201Cidentity service\u201D\
        ), related fraud mitigation, or to comply with law or legal process, then\
        \ CSPs SHALL implement measures to maintain predictability and manageability\
        \ commensurate with the privacy risk arising from the additional processing."
      annotation: "SUPPLEMENTAL GUIDANCE: Predictability and manageability measures\
        \ include providing clear notice, obtaining subscriber consent, or enabling\
        \ selective use or disclosure of attributes.\nPredictability is meant to build\
        \ trust and provide accountability and requires full understanding (and disclosure)\
        \ of how the attribute information will be used. Manageability also builds\
        \ trust by demonstrating a CSPs ability to control attribute information throughout\
        \ processing \u2013 collection, maintenance, retention."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-f
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)
      ref_id: IA-12(3)-f
      description: "If the CSP employs consent as part of its measures to maintain\
        \ predictability and manageability, \u2026then it SHALL NOT make consent for\
        \ the additional processing a condition of the identity service."
      annotation: 'SUPPLEMENTAL GUIDANCE: Consent involves collecting and recording
        an affirmative response from the applicant that they agree to the additional
        processing of their attributes. In order to make this consent meaningful,
        it is recommended that CSPs first disclose to its applicants which attributes
        are being collected and processed and why.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-g
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)
      ref_id: IA-12(3)-g
      description: The CSP SHALL provide mechanisms for redress of applicant complaints
        or problems arising from the identity proofing.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node976
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-g
      description: These [redress] mechanisms SHALL be easy for applicants to find
        and use.
      annotation: "SUPPLEMENTAL GUIDANCE: The Privacy Act requires federal CSPs that\
        \ maintain a system of records to follow procedures to enable applicants to\
        \ access and, if incorrect, amend their records. Any Privacy Act Statement\
        \ should include a reference to the applicable SORN(s), which provide the\
        \ applicant with instructions on how to make a request for access or correction.\
        \ It is recommended that non-federal CSPs have comparable procedures, including\
        \ contact information for any third parties if they are the source of the\
        \ information. \n \nIt is recommended that CSPs make the availability of any\
        \ alternative methods for completing the identity proofing and enrollment\
        \ processes clear to users (e.g., in person at a customer service center,\
        \ if available) in the event an applicant is unable to properly complete the\
        \ initial identity proofing and enrollment process requirements online.\n\
        Note: If the ID proofing process is not successful, it is recommended that\
        \ CSPs inform the applicant of the procedures to address the issue but avoid\
        \ informing the applicant of the specifics of why the registration failed.\
        \ \n \nTo be effective, the use of a CSP\u2019s redress mechanism results\
        \ in a timely correction of errors, resolution of the dispute or complaint,\
        \ and the process should not be overly burdensome or complex. \n \nIt is recommended\
        \ that the CSP document and publish, in a manner which is easy for Applicants\
        \ to find and use, its mechanisms for redress of Applicant complaints or problems\
        \ arising from the identity proofing processes."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-h
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)
      ref_id: IA-12(3)-h
      description: The CSP SHALL assess the [redress] mechanisms for their efficacy
        in achieving resolution of complaints or problems.
      annotation: "SUPPLEMENTAL GUIDANCE: \"Effective\" in this requirement means\
        \ that use of the redress mechanism will result in a timely correction of\
        \ errors, resolution of the dispute or complaint, and the process shall not\
        \ be overly burdensome or complex. \nIt is recommended that CSPs maintain\
        \ a record or log of all cases \u2013 including outcomes \u2013 where applicants\
        \ have sought redress for complaints or problems arising from the identity\
        \ proofing and provide for the periodic review of these records."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-i
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)
      ref_id: IA-12(3)-i
      description: The identity proofing and enrollment processes SHALL be performed
        according to an applicable written policy or *practice statement* that specifies
        the particular steps taken to verify identities.
      annotation: 'SUPPLEMENTAL GUIDANCE: Having documented procedures is a prerequisite
        for transparency, accountability, quality control, auditability, and ease
        of interoperability among federated communities. The documentation, dissemination,
        review and update to identity and authentication processes is a core control
        under IA-1 Identification and Authentication Policy and Procedures.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-j
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)
      ref_id: IA-12(3)-j
      description: The *practice statement* SHALL include control information detailing
        how the CSP handles proofing errors that result in an applicant not being
        successfully enrolled.
      annotation: "SUPPLEMENTAL GUIDANCE: \u201CProofing errors\u201D in this context\
        \ refer to circumstances that result in the inability or failure to complete\
        \ the identity proofing and enrollment processes. Such circumstances may include:\
        \ \n\u25CF\tApplicant abandons the identity proofing and enrollment processes;\
        \ \n\u25CF\tApplicant fails to provide mandatory attribute information; \n\
        \u25CF\tIdentity evidence of required strength is not provided; \n\u25CF\t\
        Identity evidence is rejected following inspection; \n\u25CF\tIdentity evidence\
        \ and information do not correlate; \n\u25CF\tInformation from identity evidence\
        \ is not validated by issuing or authoritative sources at the required strength;\
        \ \n\u25CF\tIdentity evidence verification of binding to the applicant fails;\
        \ and \n\u25CF\tApplicant fails to confirm enrollment code within code validity\
        \ period. \nDepending on the circumstances above, it is recommended that the\
        \ documentation include the number of retries allowed, proofing alternatives\
        \ (e.g., in-person if remote fails), or fraud countermeasures when anomalies\
        \ are detected. Additional controls for handling identity proofing errors\
        \ include: \n\u25CF\tAdvising the applicant of identity proofing failure and\
        \ recourse options; and, \n\u25CF\tRecording the errors in enrollment records/audit\
        \ logs, along with any mitigating actions."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-k
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)
      ref_id: IA-12(3)-k
      description: The CSP SHALL maintain a record, including audit logs, of all steps
        taken to verify the identity of the applicant as long as the identity exists
        in the information system.
      annotation: "SUPPLEMENTAL GUIDANCE: Ideally, the CSP\u2019s identity system\
        \ includes the capability to securely record and log key security-related\
        \ activities associated with the identity proofing process.\nExamples of key\
        \ steps that may be recorded in enrollment logs include:\n\u25CF Identity\
        \ information collected;\n\u25CF Identity evidence provided;\n\u25CF Identity\
        \ evidence validated;\n\u25CF Identity evidence validation source;\n\u25CF\
        \ Identity evidence binding verification method;\n\u25CF Identity evidence\
        \ verification result;\n\u25CF Enrollment code confirmation result;\n\u25CF\
        \ enrollment result; and\n\u25CF Authenticator enrollment binding"
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-l
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)
      ref_id: IA-12(3)-l
      description: The CSP SHALL record the types of identity evidence presented in
        the proofing process.
      annotation: "SUPPLEMENTAL GUIDANCE: Ideally, the CSP\u2019s identity system\
        \ includes the capability to securely record and log specific activities associated\
        \ with the identity proofing process. For each piece of evidence collected\
        \ or captured, the record should include: \n1.\tEvidence type; \n2.\tDetermined\
        \ strength; \n3.\tIssuing source; and \n4.\tMethod of collection/capture*.\
        \ \n* \tMethods of collection and capture may include camera, flatbed scanner,\
        \ bar code scanner."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-m
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)
      ref_id: IA-12(3)-m
      description: 'The CSP SHALL conduct a risk management process, including assessments
        of privacy and security risks to determine:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-m-1
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-m
      ref_id: IA-12(3)-m-1
      description: Any steps that it will take to verify the identity of the applicant
        beyond any mandatory requirements specified herein;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-m-2
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-m
      ref_id: IA-12(3)-m-2
      description: 'The PII, including any biometrics, images, scans, or other copies
        of the identity evidence that the CSP will maintain as a record of identity
        proofing (Note: Specific federal requirements may apply); and'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-m-3
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-m
      ref_id: IA-12(3)-m-3
      description: 'The schedule of retention for these records (Note: CSPs may be
        subject to specific retention policies in accordance with applicable laws,
        regulations, or policies, including any National Archives and Records Administration
        (NARA) records retention schedules that may apply).'
      annotation: "SUPPLEMENTAL GUIDANCE: In accordance with its risk management processes,\
        \ CSPs should conduct \u2013 and document the results of \u2013 privacy and\
        \ security risk assessments. It is recommended that the scope of this assessment\
        \ includes risks associated with: \n\u25CF\tAny steps the CSP takes to verify\
        \ applicant identities beyond what is required by the \nCJISSECPOL \n\u25CF\
        \tThe CSP\u2019s collection, processing, and protection of PII, including\
        \ any biometrics, images, scans, or other copies of the identity evidence\
        \ that the CSP will maintain as a record of identity proofing; \n\u25CF\t\
        Retention and/or disposal of any records; and \n\u25CF\tAdherence to any applicable\
        \ federal requirements, laws, regulations or policies."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-n
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)
      ref_id: IA-12(3)-n
      description: All PII collected as part of the enrollment process SHALL be protected
        to ensure confidentiality, integrity, and attribution of the information source.
      annotation: "SUPPLEMENTAL GUIDANCE: Unauthorized disclosure of PII can result\
        \ in tangible and intangible harms to both the CSP as well as the subjects\
        \ of the PII. After assessing the risks associated with collecting PII as\
        \ part of its enrollment process, it is recommended that the CSP employ functional\
        \ and technical mechanisms that adequately protect the confidentiality, integrity,\
        \ and attribution of the PII under its control. Such mechanisms may include:\
        \ \n\u25CF\tLimiting access to PII data; \n\u25CF\tPrivacy protecting policies;\
        \ \n\u25CF\tThe use of encryption for data at rest and during transmission;\
        \ and \n\u25CF\tIntegrity protection mechanisms such as hashes and record\
        \ access logging."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-o
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)
      ref_id: IA-12(3)-o
      description: '"The entire proofing transaction, including transactions that
        involve a third party, SHALL occur over authenticated protected channels.
        "'
      annotation: 'SUPPLEMENTAL GUIDANCE: An encrypted communication channel uses
        approved cryptography where the connection initiator (client) has authenticated
        the recipient (server). Authenticated protected channels provide confidentiality
        and MitM attack protection and are frequently used in the user authentication
        process. Transport Layer Security* (TLS) is an example of an authenticated
        protected channel where the certificate presented by the recipient is verified
        by the initiator. Unless otherwise specified, authenticated protected channels
        do not require the server to authenticate the client. Authentication of the
        server is often accomplished through a certificate chain leading to a trusted
        root rather than individually with each server.

        *TLS version 1.2 or greater is recommended.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-p
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)
      ref_id: IA-12(3)-p
      description: '"If the CSP uses fraud mitigation measures, then the CSP SHALL
        conduct a privacy risk assessment for these mitigation measures. "'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node989
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-p
      description: "Such assessments SHALL include any privacy risk mitigations (e.g.,\
        \ risk acceptance or transfer, limited retention, use limitations, notice)\
        \ or other technological mitigations (e.g., cryptography), and be documented\
        \ per requirement IA-12(3) k \u2013 m above."
      annotation: "SUPPLEMENTAL GUIDANCE: This is a conditional requirement. CSPs\
        \ may choose to obtain additional confidence in the identity proofing process\
        \ beyond the requirements for IAL2 through additional fraud mitigation measures.\
        \ Such measures may include: \n\u25CF\tinspecting metadata information, such\
        \ as by checking geolocation data associated with a mobile device used to\
        \ send a photo or receive an SMS; \n\u25CF\texamining the applicant\u2019\
        s device characteristics; \n\u25CF\tevaluating behavioral characteristics,\
        \ such as typing mannerisms, gait, or voice characteristics; and \n\u25CF\t\
        checking against authoritative sources, such as the Death Master File. \n\
        Employing one or more of these fraud mitigation techniques may result in the\
        \ collection of additional PII about an applicant. Additional PII increases\
        \ the potential impact of the unauthorized disclosure of this data. As part\
        \ of the privacy risk assessment on these additional fraud mitigation measures,\
        \ it is recommended that CSPs consider, at a minimum, the additional data\
        \ (PII) that is processed, the implications of retaining this additional PII,\
        \ and ways the associated risks can be minimized without negating the effects\
        \ of the additional measures. \nThese additional fraud mitigation measures\
        \ are not intended to substitute or replace the mandatory requirements. CSPs\
        \ employing these measures are still responsible for meeting all applicable\
        \ requirements."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-q
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)
      ref_id: IA-12(3)-q
      description: In the event a CSP ceases to conduct identity proofing and enrollment
        processes, then the CSP SHALL be responsible for fully disposing of or destroying
        any sensitive data including PII, or its protection from unauthorized access
        for the duration of retention.
      annotation: "SUPPLEMENTAL GUIDANCE: This is a conditional requirement for CSPs\
        \ that cease to perform identity proofing and enrollment functions. The CSP\
        \ is responsible for the proper handling, protection, and retention or disposal\
        \ of any sensitive data it collects, even after it ceases to provide identity\
        \ proofing and enrollment services. A CSP may document its policies and procedures\
        \ to the management of the data it collects in a data handling plan or other\
        \ document. Additionally, it is recommended that CSPs document any specific\
        \ retention policies they are subject to, in accordance with applicable laws,\
        \ regulations, or policies, including any National Archives and Records Administration\
        \ (NARA) records retention schedules that may apply. \nSpecifically, it is\
        \ recommended that the CSP defines and documents the practices it has in place\
        \ for fully disposing of or destroying any sensitive data including PII, or\
        \ its continued protection from unauthorized access for the duration of any\
        \ period of retention."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-r
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)
      ref_id: IA-12(3)-r
      description: 'Regardless of whether the CSP is a federal agency or non-federal
        entity, the following requirements apply to the federal agency offering or
        using the proofing service:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-r-1
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-r
      ref_id: IA-12(3)-r-1
      description: The agency SHALL consult with their Senior Agency Official for
        Privacy (SAOP) to conduct an analysis determining whether the collection of
        PII to conduct identity proofing triggers Privacy Act requirements.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-r-2
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-r
      ref_id: IA-12(3)-r-2
      description: The agency SHALL publish a System of Records Notice (SORN) to cover
        such collection, as applicable.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-r-3
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-r
      ref_id: IA-12(3)-r-3
      description: The agency SHALL consult with their SAOP to conduct an analysis
        determining whether the collection of PII to conduct identity proofing triggers
        E-Government Act of 2002 requirements.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-r-4
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-r
      ref_id: IA-12(3)-r-4
      description: The agency SHALL publish a Privacy Impact Assessment (PIA) to cover
        such collection, as applicable.
      annotation: "SUPPLEMENTAL GUIDANCE: This requirement applies to Federal agencies\
        \ whether providing authentication services directly or through a commercial\
        \ provider. This requirement directs Agencies to consult with their Senior\
        \ Agency Official for Privacy (SAOP) and conduct an analysis to determine\
        \ whether the collection of PII to issue or maintain authenticators triggers\
        \ the requirements of the Privacy Act of 1974 or the requirements of the E-Government\
        \ Act of 2002. Based on this consultation and analysis, the agency may need\
        \ to publish a System of Records Notice (SORN) and/or a Privacy Impact Assessment\
        \ (PIA) to cover such collections, as applicable. \nWhile this requirement\
        \ specifically applies only to federal agencies, CSPs that provide services\
        \ to federal agencies may be expected to provide information about their identity\
        \ services in support of an Agency\u2019s privacy analysis and PIA."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-s
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)
      ref_id: IA-12(3)-s
      description: 'An enrollment code SHALL be comprised of one of the following:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-s-1
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-s
      ref_id: IA-12(3)-s-1
      description: Minimally, a random six character alphanumeric or equivalent entropy.
        For example, a code generated using an approved random number generator or
        a serial number for a physical hardware authenticator;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node998
      assessable: false
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-s
      description: OR
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-s-2
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-s
      ref_id: IA-12(3)-s-2
      description: A machine-readable optical label, such as a QR Code, that contains
        data of similar or higher entropy as a random six character alphanumeric.
      annotation: "SUPPLEMENTAL GUIDANCE: The use of an enrollment code for address\
        \ confirmation is a requirement for IAL2 remote identity proofing and enrollment.\
        \ CSPs that perform in-person identity at IAL2 may voluntarily choose to use\
        \ enrollment codes for such binding, but this is not required. Enrollment\
        \ codes may also be used for in-person proofing and enrollment processes if\
        \ an authenticator(s) is not registered to the subscribers\u2019 account at\
        \ the time of in-person identity proofing and, therefore, the authenticator\
        \ binding would need to occur at a later time. Enrollment codes may be used\
        \ for authenticator binding to subscribers\u2019 accounts in such circumstances.\
        \ \nEnrollment code use for IAL2 remote identity proofing allows the CSP to\
        \ confirm that the applicant controls a validated address of record. Authenticator\
        \ binding may not be completed in the same session for in-person identity\
        \ proofing. Enrollment codes may be used for binding an authenticator t o\
        \ subscribers\u2019 accounts at a later time in such circumstances.The requirements\
        \ presented in this criterion apply to all enrollment codes that may be used\
        \ by the CSP for any purpose. \nEnrollment code use has the additional requirement\
        \ for code validity periods. The validity period is determined by the type\
        \ of address where the enrollment code is sent, as follows: \n\u25CF\t10 days,\
        \ when sent to a postal address of record within the contiguous United States;\
        \ \n\u25CF\t30 days, when sent to a postal address of record outside the contiguous\
        \ United States; \n\u25CF\t10 minutes, when sent to a telephone of record\
        \ (SMS or voice); \n\u25CF\t24 hours, when sent to an email address of record;\
        \ \n\u25CF\t7 days if provided directly to the applicant during an in-person\
        \ proofing session for authenticator binding at IAL2. \nThese validity periods\
        \ are presented again in requirement IA-12 (5) g which presents the mandatory\
        \ requirement for enrollment code confirmation for IAL2 remote identity proofing."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-t
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)
      ref_id: IA-12(3)-t
      description: Training requirements for personnel validating evidence SHALL be
        based on the policies, guidelines, or requirements of the CSP or RP
      annotation: "SUPPLEMENTAL GUIDANCE: The training requirement pertains to personnel\
        \ performing the validation of identity evidence but does not specify training\
        \ content. The CSP policies, guidelines, or requirements for validating identity\
        \ evidence for identity proofing would be appropriate for the type of training\
        \ intended by this requirement. Such content may include: \n\u25CF\tthe CSP\u2019\
        s policy for types of evidence it collects and validates in order to meet\
        \ the \nrequirements of designated IALs; \n\u25CF\tvalidation of security\
        \ features for the types of identity evidence collected; \n\u25CF\tdetection\
        \ of evidence alteration, falsification, or forgery for the types of identity\
        \ evidence collected. Procedures for the validation of identity evidence information\
        \ with issuing and authoritative sources. \nThis training may be accomplished\
        \ through written training material, oral instruction, on-the-job training\
        \ and mentoring, or other means. CSPs may perform some of the requirements\
        \ for identity evidence validation through automated services and equipment.\
        \ Therefore, personnel training would be based on the CSPs policies and procedures\
        \ for the manual performance of evidence validation. \n guidelines, or requirements\
        \ of the CSP or RP.\nSUPPLEMENTAL GUIDANCE: The training requirement pertains\
        \ to personnel performing the validation of identity evidence but does not\
        \ specify training content. The CSP policies, guidelines, or requirements\
        \ for validating identity evidence for identity proofing would be appropriate\
        \ for the type of training intended by this requirement. Such content may\
        \ include: \n\u25CF\tthe CSP\u2019s policy for types of evidence it collects\
        \ and validates in order to meet the \nrequirements of designated IALs; \n\
        \u25CF\tvalidation of security features for the types of identity evidence\
        \ collected; \n\u25CF\tdetection of evidence alteration, falsification, or\
        \ forgery for the types of identity evidence collected. Procedures for the\
        \ validation of identity evidence information with issuing and authoritative\
        \ sources. \nThis training may be accomplished through written training material,\
        \ oral instruction, on-the-job training and mentoring, or other means. CSPs\
        \ may perform some of the requirements for identity evidence validation through\
        \ automated services and equipment. Therefore, personnel training would be\
        \ based on the CSPs policies and procedures for the manual performance of\
        \ evidence validation. \n SUPPLEMENTAL GUIDANCE: The training requirement\
        \ pertains to personnel performing the validation of identity evidence but\
        \ does not specify training content. The CSP policies, guidelines, or requirements\
        \ for validating identity evidence for identity proofing would be appropriate\
        \ for the type of training intended by this requirement. Such content may\
        \ include: \n\u25CF\tthe CSP\u2019s policy for types of evidence it collects\
        \ and validates in order to meet the \nrequirements of designated IALs; \n\
        \u25CF\tvalidation of security features for the types of identity evidence\
        \ collected; \n\u25CF\tdetection of evidence alteration, falsification, or\
        \ forgery for the types of identity evidence collected. Procedures for the\
        \ validation of identity evidence information with issuing and authoritative\
        \ sources. \nThis training may be accomplished through written training material,\
        \ oral instruction, on-the-job training and mentoring, or other means. CSPs\
        \ may perform some of the requirements for identity evidence validation through\
        \ automated services and equipment. Therefore, personnel training would be\
        \ based on the CSPs policies and procedures for the manual performance of\
        \ evidence validation."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-u
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)
      ref_id: IA-12(3)-u
      description: 'This criterion applies to CSPs that provide identity proofing
        and enrollment services to minors (under the age of 18):'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1002
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-u
      description: "If the CSP provides identity proofing and enrollment services\
        \ to minors (under the age of 18), then\u2026the CSP SHALL give special consideration\
        \ to the legal restrictions of interacting with minors unable to meet the\
        \ evidence requirements of identity proofing [to ensure compliance with the\
        \ Children\u2019s Online Privacy Protection Act of 1998 (COPPA), and other\
        \ laws, as applicable]. \""
      annotation: "SUPPLEMENTAL GUIDANCE: In general, minors will not possess the\
        \ types of evidence required to meet the CSP\u2019s minimum requirements for\
        \ a given IAL. ICSPs that provide identity services to minors will need to\
        \ determine and document the special considerations it applies to minors.\
        \ Such special considerations may include the use of trusted referees and\
        \ an expanded list of acceptable evidence types to include evidence a minor\
        \ would likely possess, such as school IDs. \n \nRequirements \u2018v\u2019\
        \ and \u2018w\u2019 apply to the collection of biometric characteristics for\
        \ in-person (physical or supervised remote) identity proofing and are mandatory\
        \ at IAL3. These criteria also apply to CSPs that optionally choose to collect\
        \ biometric characteristics through in-person identity proofing and enrollment\
        \ at IAL2."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-v
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)
      ref_id: IA-12(3)-v
      description: The CSP SHALL have the operator view the biometric source (e.g.,
        fingers, face) for presence of non-natural materials and perform such inspections
        as part of the proofing process.
      annotation: "SUPPLEMENTAL GUIDANCE: Applicants may try to defraud the identity\
        \ proofing process by using fake fingers or by applying non-natural materials\
        \ - such as latex, silicon, or glue \u2013 to their fingers, faces, or other\
        \ sources of biometrics. It is recommended that identity proofing operators\
        \ be trained to recognize such practices and to examine all biometric sources\
        \ used in the identity proofing for the presence of foreign materials. \n\
        It is recommended that the CSP documents and applies technologies and procedures\
        \ which ensure that the proofing operator reviews the biometric source (e.g.,\
        \ fingers, face) for presence of non-natural materials and perform such inspections\
        \ as part of the proofing process."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1004
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-v
      description: "Requirements \u2018v\u2019 and \u2018w\u2019 apply to the collection\
        \ of biometric characteristics for in-person \n(physical or supervised remote)\
        \ identity proofing and are mandatory at IAL3. These criteria also apply to\
        \ CSPs that collect biometric characteristics through in-person identity-proofing\
        \ identity proofing and enrollment at IAL2."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-w
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)
      ref_id: IA-12(3)-w
      description: The CSP SHALL collect biometrics in such a way that ensures that
        the biometric is collected from the applicant, and not another subject. All
        biometric performance requirements in IA-5 m (1) through (12) apply.
      annotation: "SUPPLEMENTAL GUIDANCE: Applicants may try to defraud the identity\
        \ proofing process by having another person present themselves for biometric\
        \ collection. The risk of this happening is increased if the identity proofing\
        \ process is not completed in a single session and during supervised remote\
        \ identity proofing processes. \nDocumenting the technologies and procedures\
        \ the CSP employs to ensure that biometric samples are taken from the applicant\
        \ him/herself and not another person facilitates the assessment against this\
        \ requirement."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-x
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)
      ref_id: IA-12(3)-x
      description: The CSP SHALL support in-person or remote identity proofing, or
        both.
      annotation: "SUPPLEMENTAL GUIDANCE: IAL2 allows for remote or in-person identity\
        \ proofing. IAL2 supports a wide range of acceptable identity proofing techniques\
        \ in order to increase user adoption, decrease false negatives (legitimate\
        \ applicants that cannot successfully complete identity proofing), and detect\
        \ to the best extent possible the presentation of fraudulent identities by\
        \ a malicious applicant. \nRemote proofing presents challenges to achieving\
        \ the desired outcomes described above that can be overcome through the use\
        \ specific processes and technologies. Potential processes and controls that\
        \ CSPs may employ to mitigate risks associated with remote identity proofing\
        \ at IAL2 include: \n1.\tA remote operator is present during at least part\
        \ of the identity proofing session and can provide positive confirmation that\
        \ the requirements for IAL2 identity proofing are met. Employing real-time\
        \ remote operators provides the capability for the identity proofing process\
        \ to be completed in a single session and allows the remote operator to direct\
        \ the applicant for proper presentation and examination of identity evidence\
        \ and biometrics collection. \n2.\tThe CSP employs automated technologies\
        \ and services (e.g., liveness detection, identity evidence verification and\
        \ validation, and presentation attack detection, if applicable) which can\
        \ ensure the requirements for IAL2 identity proofing are met and protect against\
        \ spoofing attacks. This process also provides the capability for the identity\
        \ proofing process to be completed in a single session. \n3.\tThe CSP employs\
        \ an off-line operator to evaluate the evidence and images collected during\
        \ a previous identity proofing process. In this scenario, the identity proofing\
        \ process requires more than one session with the applicant and is not completed\
        \ until the operator provides a positive confirmation that all requirements\
        \ for IAL2 identity proofing are met."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-y
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)
      ref_id: IA-12(3)-y
      description: 'The CSP SHALL collect the following from the applicant:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-y-1
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-y
      ref_id: IA-12(3)-y-1
      description: "One piece of SUPERIOR or STRONG evidence if the evidence\u2019\
        s issuing source,during its identity proofing event, confirmed the claimed\
        \ identity by collecting two or more forms of SUPERIOR or STRONG evidence\
        \ and the CSP validates the evidence directly with the issuing source; OR"
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-y-2
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-y
      ref_id: IA-12(3)-y-2
      description: Two pieces of STRONG evidence; OR
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-y-3
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-y
      ref_id: IA-12(3)-y-3
      description: One piece of STRONG evidence plus two pieces of FAIR evidence
      annotation: "SUPPLEMENTAL GUIDANCE: The goal of identity validation is to collect\
        \ the most appropriate identity evidence (e.g., a passport or driver\u2019\
        s license) from the applicant and determine its authenticity, validity, and\
        \ accuracy. Identity validation is made up of three process steps: 1) collecting\
        \ the appropriate identity evidence, 2) confirming the evidence is genuine\
        \ and authentic, and 3) confirming the data contained on the identity evidence\
        \ is valid, current, and related to a real-life subject."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-z
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)
      ref_id: IA-12(3)-z
      description: "The CSP SHALL validate each piece of evidence with a process that\
        \ can achieve the same strength as the evidence presented (see \u2018y\u2019\
        \ above). For example, if two forms of STRONG identity evidence are presented,\
        \ each piece of evidence will be validated at a strength of STRONG."
      annotation: "SUPPLEMENTAL GUIDANCE: The goal of identity validation is to collect\
        \ the most appropriate identity evidence (e.g., a passport, driver\u2019s\
        \ license) from the applicant and determine its authenticity, validity, and\
        \ accuracy. Identity validation is made up of three process steps: 1) collect\
        \ the appropriate identity evidence, 2) confirm the evidence is genuine and\
        \ authentic, and 3) confirm the data contained on the identity evidence is\
        \ valid, current, and related to a real-life subject.\nEvidence validation\
        \ for authenticity involves examining the evidence for: \n\u25CF\tConfirmation\
        \ of required information completeness and format for the identity evidence\
        \ type. \n\u25CF\tDetection of evidence tampering or the creation of counterfeit\
        \ or fraudulent evidence. \n\u25CF\tConfirmation of security features. See\
        \ Figure 10 - Types of Identity Evidence Security Features to this document\
        \ for types of commonly used security features for identity evidence. \nMost\
        \ of the capabilities to confirm security features on identity evidence are\
        \ dependent upon physically viewing the evidence directly, tactile feel of\
        \ the evidence, and viewing the evidence under specialized lighting or through\
        \ the use of specialized equipment (see Figure 10 - Types of Identity Evidence\
        \ Security Features). Therefore, the validation of evidence that may be submitted\
        \ remotely for remote identity proofing methods is particularly challenging.\
        \ For this reason, CSPs opting to provide remote identity proofing may find\
        \ it most effective to use automated evidence validation products and services.\
        \ If automated evidence validation solutions are not used, CSPs may choose\
        \ to apply similar procedures for IAL2 remote proofing as are required for\
        \ IAL3 supervised remote proofing. These procedures provide that a trained\
        \ operator can remotely supervise the evidence collection process, require\
        \ the applicant to turn or tilt evidence or apply lighting to be able to confirm\
        \ security features on evidence that is presented for the identity proofing\
        \ encounter in a recorded video or webcast. Alternatively, a CSP may use an\
        \ automated interface for the capture of identity evidence images that similarly\
        \ can direct the applicant to turn, tilt or provide lighting on evidence presented\
        \ for identity proofing purposes."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-aa
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)
      ref_id: IA-12(3)-aa
      description: "The CSP SHALL verify identity evidence as follows:At a minimum,\
        \ the applicant\u2019s binding to identity evidence must be verified by a\
        \ process that is able to achieve a strength of STRONG"
      annotation: 'SUPPLEMENTAL GUIDANCE: The goal of identity verification is to
        confirm and establish a linkage between the validated evidence for the claimed
        identity and the real-life applicant presenting the evidence'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-bb
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)
      ref_id: IA-12(3)-bb
      description: For IAL2 remote proofing:The collection of biometric characteristics
        for physical or biometric comparison of the applicant to the strongest piece
        of identity evidence provided to support the claimed identity performed remotely
        SHALL adhere to all requirements as specified in IA-5 m.
      annotation: "SUPPLEMENTAL GUIDANCE: See IA-5 m (1) \u2013 (12) for conformance\
        \ criteria for the implementation and conformance assessment of requirements\
        \ for the use of biometrics."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-cc
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)
      ref_id: IA-12(3)-cc
      description: Knowledge-based verification (KBV) SHALL NOT be used for in-person
        (physical or supervised remote) identity verification.
      annotation: 'SUPPLEMENTAL GUIDANCE: identity verification is performed against
        the strongest piece of identity evidence submitted and validated. For IAL2
        the strongest piece of evidence will always be either STRONG or SUPERIOR evidence.
        KBV (sometimes referred to as knowledge-based authentication) is only permitted
        as a verification method for evidence at the FAIR strength level; therefore,
        verification of FAIR evidence binding will never be required for IAL2.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-dd
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)
      ref_id: IA-12(3)-dd
      description: The CSP SHALL employ appropriately tailored security controls,
        to include control enhancements, from the moderate or high baseline of security
        controls defined in the CJISSECPOL.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1016
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-dd
      description: The CSP SHALL ensure that the minimum assurance-related controls
        for moderate-impact systems are satisfied.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-ee
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)
      ref_id: IA-12(3)-ee
      description: "Supervised Remote Identity Proofing:Supervised remote identity\
        \ proofing is intended to provide controls for comparable levels of confidence\
        \ and security to in-person IAL3 identity proofing for identity proofing processes\
        \ that are performed remotely. Supervised remote identity proofing is optional\
        \ for CSPs; that is, if a CSP chooses to use supervised remote identity proofing,\
        \ then the following requirements, (1) through (8), would apply. It should\
        \ be noted that the term \u201Csupervised remote identity proofing\u201D has\
        \ specialized meaning and is used only to refer to the specialized equipment\
        \ and the following control requirements, (1) through (8).In addition to those\
        \ requirements presented in this document, as well as the applicable identity\
        \ validation and verification requirements, CSPs that provide supervised remote\
        \ identity proofing services must demonstrate conformance with the requirements\
        \ contained in this section.The following requirements for supervised remote\
        \ proofing apply specifically to IAL3. I f the equipment/facilities used for\
        \ supervised remote proofing are used for IAL2 identity proofing, the following\
        \ requirements, (1) through (8), for supervised remote proofing do not apply.\
        \ In this case, the requirements for conventional remote identity proofing\
        \ are applicable."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-ee-1
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-ee
      ref_id: IA-12(3)-ee-1
      description: Supervised remote identity proofing and enrollment transactions
        SHALL meet the following requirements, in addition to the IAL3 validation
        and verification requirements specified in IA-12(3)s.
      annotation: 'SUPPLEMENTAL GUIDANCE: Supervised remote identity proofing involves
        the use of a CSP-controlled station at a remote location that is connected
        to a trained operator at a central location. The goal of this arrangement
        is to permit identity proofing of individuals in remote locations where it
        is not practical for them to travel to the CSP for in-person identity proofing.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-ee-2
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-ee
      ref_id: IA-12(3)-ee-2
      description: "The CSP SHALL monitor the entire identity proofing session, from\
        \ which the applicant SHALL NOT depart \u2014 for example, by a continuous\
        \ high-resolution video transmission of the applicant."
      annotation: 'SUPPLEMENTAL GUIDANCE: The integrity of supervised remote identity
        proofing depends upon the applicant being continuously present during the
        entire session. An applicant who steps away from an in-process session may
        do so to alter their biometric source or substitute a different person to
        complete the identity proofing process.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-ee-3
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-ee
      ref_id: IA-12(3)-ee-3
      description: The CSP SHALL have a live operator participate remotely with the
        applicant for the entirety of the identity proofing session.
      annotation: 'SUPPLEMENTAL GUIDANCE: Having a trained operator supervise and
        participate in a remote identity proofing session reduces the opportunity
        for an applicant to defraud the process. As described in Appendix A Terms
        and Definitions, the operator is a person who has received specific training
        on enrollment and identity proofing procedures and the detection of potential
        fraud by an applicant.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-ee-4
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-ee
      ref_id: IA-12(3)-ee-4
      description: The CSP SHALL require all actions taken by the applicant during
        the identity proofing session to be clearly visible to the remote operator.
      annotation: 'SUPPLEMENTAL GUIDANCE: The camera(s) a CSP employs to monitor the
        actions taken by a remote applicant during the identity proofing session should
        be positioned in such a way that the upper body, hands, and face of the applicant
        are always visible. Additionally, the components of the remote identity proofing
        station (including such things as keyboard, fingerprint capture device, signature
        pad, and scanner, as applicable) should be arranged such that all interactions
        with these devices is within the field of view.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-ee-5
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-ee
      ref_id: IA-12(3)-ee-5
      description: The CSP SHALL require that all digital validation of evidence (e.g.,
        via chip or wireless technologies) be performed by integrated scanners and
        sensors.
      annotation: 'SUPPLEMENTAL GUIDANCE: Technologies exist that allow for the digital
        validation of identity evidence via electronic means (such as RFID to read
        the data off e-passports and chip readers for smartcards). The scanners and
        sensors employed to access these features should be integrated into the remote
        identity proofing stations in order to reduce the likelihood of being tampered
        with, removed, or replaced. To be integrated means the devices themselves
        are a component of the workstation (i.e., smartcard readers or fingerprint
        sensors built into a laptop) or the devices, and their connections, are secured
        in a protective case or locked box.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-ee-6
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-ee
      ref_id: IA-12(3)-ee-6
      description: The CSP SHALL require operators to have undergone a training program
        to detect potential fraud and to properly perform a supervised remote proofing
        session.
      annotation: "SUPPLEMENTAL GUIDANCE: A comprehensive training program for supervised\
        \ remote identity proofing operators may include some or all the following:\
        \ \n\u25CF\tPurpose and objectives of the identity proofing and enrollment\
        \ process, as employed by the CSP; \n\u25CF\tSupervised remote identity proofing\
        \ process workflow; \n\u25CF\tIdentity evidence validation processes; \n\u25CF\
        \tThreats associated with the identity proofing process and how to detect\
        \ potential fraud; and \n\u25CF\tSystem and process troubleshooting and problem\
        \ resolution."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-ee-7
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-ee
      ref_id: IA-12(3)-ee-7
      description: The CSP SHALL employ physical tamper detection and resistance features
        appropriate for the environment in which it is located.
      annotation: 'SUPPLEMENTAL GUIDANCE: For example, a kiosk located in a restricted
        area or one where it is monitored by a trusted individual requires less tamper
        detection than one that is located in a semi-public area such as a shopping
        mall concourse.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-ee-8
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-ee
      ref_id: IA-12(3)-ee-8
      description: The CSP SHALL ensure that all communications occur over a mutually
        authenticated protected channel.
      annotation: 'SUPPLEMENTAL GUIDANCE: Mutually authenticated protected channels
        employ approved cryptography to encrypt communications between'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-ff
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)
      ref_id: IA-12(3)-ff
      description: "Trusted Referee: The use of trusted referees is optional for CSPs;\
        \ that is, if a CSP chooses to use trusted referees for identity proofing\
        \ and enrollment, then the following requirements, (1) through (3), would\
        \ apply. The use of trusted referees is intended to assist in the identity\
        \ proofing and enrollment for populations that are unable to meet IAL2 identity\
        \ proofing requirements, or otherwise would be challenged to perform identity\
        \ proofing and enrollment process requirements. Such populations may include,\
        \ but are not limited to:\n\u2022\tdisabled individuals; \n\u2022\telderly\
        \ individuals; \n\u2022\thomeless individuals, \n\u2022\tindividuals with\
        \ little or no access to online services or computing devices; \n\u2022\t\
        unbanked and individuals with little or no credit history; \n\u2022\tvictims\
        \ of identity theft; \n\u2022\tchildren under 18; and \n\u2022\timmigrants.\n\
        In addition to those requirements presented in the General section of this\
        \ document, as well as the applicable IAL requirements, CSPs that use trusted\
        \ referees in their identity proofing services must demonstrate conformance\
        \ with the requirements contained in this section."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-ff-1
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-ff
      ref_id: IA-12(3)-ff-1
      description: "If the CSP uses trusted referees, then\u2026The CSP SHALL establish\
        \ written policy and procedures as to how a trusted referee is determined\
        \ and the lifecycle by which the trusted referee retains their status as a\
        \ valid referee, to include any restrictions, as well as any revocation and\
        \ suspension requirements."
      annotation: "SUPPLEMENTAL GUIDANCE: In instances where an individual cannot\
        \ meet the identity evidence requirements specified in IA-12 (3) y \u2013\
        \ ee and IA-12 (5) b - i, the agency may use a trusted referee to assist in\
        \ identity proofing the applicant. It is intended that CSPs using trusted\
        \ referees for identity proofing and enrollment will document the procedures\
        \ and controls in an applicable written policy or *practice statement* as\
        \ described in IA-12 (3) h."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-ff-2
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-ff
      ref_id: IA-12(3)-ff-2
      description: "If the CSP uses trusted referees, then\u2026The CSP SHALL proof\
        \ the trusted referee at the same IAL as the applicant proofing."
      annotation: 'SUPPLEMENTAL GUIDANCE: Trusted referees, who participate in the
        identity proofing process on behalf of an applicant need to be identity proofed
        themselves to the same level as that of the applicant. If CSPs allows the
        use of Trusted Referees, its documented policies should state this requirement.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-ff-3
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(3)-ff
      ref_id: IA-12(3)-ff-3
      description: "If the CSP uses trusted referees, then\u2026The CSP SHALL determine\
        \ the minimum evidence required to bind the relationship between the trusted\
        \ referee and the applicant."
      annotation: "SUPPLEMENTAL GUIDANCE: In addition to proofing a Trusted Referee\
        \ to the same (or greater) IAL as that of the applicant, CSPs will need to\
        \ determine its process for proving a legitimate relationship to the applicant.\
        \ The CSP should consider and document the types of evidence (i.e., power\
        \ of attorney) it will accept to \u201Cbind\u201D the relationship between\
        \ Trusted Referee and an applicant. This minimum evidence may vary based on\
        \ IAL."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(5)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12
      ref_id: IA-12(5)
      name: IDENTITY PROOFING | ADDRESS CONFIRMATION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(5)-a
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(5)
      ref_id: IA-12(5)-a
      description: Require that a registration code or notice of proofing be delivered
        through an out-of-band channel to verify the users address (physical or digital)
        of record.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1032
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(5)
      description: 'DISCUSSION: To make it more difficult for adversaries to pose
        as legitimate users during the identity proofing process, organizations can
        use out-of-band methods to ensure that the individual associated with an address
        of record is the same individual that participated in the registration. Confirmation
        can take the form of a temporary enrollment code or a notice of proofing.
        The delivery address for these artifacts is obtained from records and not
        self-asserted by the user. The address can include a physical or digital address.
        A home address is an example of a physical address. Email addresses and telephone
        numbers are examples of digital addresses.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(5)-b
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(5)
      ref_id: IA-12(5)-b
      description: The CSP SHALL confirm address of record.
      annotation: 'SUPPLEMENTAL GUIDANCE: Valid records to confirm address are issuing
        source(s) or authoritative source(s). Ideally, the CSP will confirm an address
        of record through validation of the address contained on any supplied, valid
        piece of identity evidence. However, the CSP may confirm address of record
        by validating information supplied by the applicant that is not contained
        on any supplied piece of identity evidence. Postal addresses are preferred,
        however these guidelines support any type of address that can be validated
        against an issuing or authoritative source, whether physical or digital. Acceptable
        addresses of record include postal addresses, email addresses, and telephone
        numbers. The types of addresses of record a CSP accepts will determine, in
        part, the method it employs to validate them. For instance, postal addresses
        can be validated by confirming it against a piece of supplied, valid identity
        evidence. Email addresses may be confirmed by sending an email to the provided
        address.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(5)-c
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(5)
      ref_id: IA-12(5)-c
      description: Valid records to confirm address SHALL be issuing source(s) or
        authoritative source(s). Self-asserted address data that has not been confirmed
        in records SHALL NOT be used for confirmation.
      annotation: "SUPPLEMENTAL GUIDANCE: An address of record is a \u201Cvalidated\
        \ and verified location (physical or digital) where an individual can receive\
        \ communications using approved mechanisms.\u201D IAL2 requires confirming\
        \ an applicant\u2019s address of record. This can be accomplished in two ways:\
        \ 1) validation of the address contained on a valid piece of identity evidence,\
        \ or 2) by employing a mechanism such as enrollment codes to validate an address\
        \ not contained on a supplied piece of identity evidence. \nAddresses that\
        \ are supplied by an applicant, either verbally or on a non-valid piece of\
        \ identity evidence, are not valid for confirming an applicant\u2019s address\
        \ of record."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(5)-d
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(5)
      ref_id: IA-12(5)-d
      description: Note that IAL2-7 applies only to in-person proofing at IAL2.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1036
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(5)
      description: "If the CSP performs in-person proofing for IAL2 and provides an\
        \ enrollment code directly to the subscriber for binding to an authenticator\
        \ at a later time, then the enrollment code\u2026SHALL be valid for a maximum\
        \ of seven (7) days."
      annotation: "SUPPLEMENTAL GUIDANCE: Upon successful completion of the identity\
        \ proofing process the CSP will typically register one or more authenticators\
        \ to t h e subscribers\u2019 account or may optionally choose to bind an authenticator(s)\
        \ at a later time. If the CSP chooses to use an enrollment code provided directly\
        \ to the applicant to authenticate for such later binding, the validity period\
        \ for the enrollment code is a maximum of seven days (see IA-12 (3) s). \n\
        Note that conformance criteria IA-12 (5) \u2018e\u2019 through \u2018i\u2019\
        \ apply to remote identity proofing processes at IAL2."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(5)-e
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(5)
      ref_id: IA-12(5)-e
      description: 'For remote identity proofing at IAL2:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1038
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(5)
      description: The CSP SHALL send an enrollment code to a confirmed address of
        record for the applicant.
      annotation: "SUPPLEMENTAL GUIDANCE: Enrollment codes used for IAL2 remote identity\
        \ proofing may be sent to any confirmed address of record \u2013 postal, mobile\
        \ phone number for SMS, or email addresses."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(5)-f
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(5)
      ref_id: IA-12(5)-f
      description: 'For remote identity proofing at IAL2: The applicant SHALL present
        a valid enrollment code to complete the identity proofing process.'
      annotation: "SUPPLEMENTAL GUIDANCE: Per IA-12 (5) e above, sending an enrollment\
        \ code to a confirmed address of record, as captured during the identity proofing\
        \ process, is required to complete the remote identity proofing process and\
        \ provides additional confidence in the binding of that address to the applicant.\n\
        Valid enrollment codes mean that the correct enrollment code is submitted\
        \ by the applicant within prescribed validity periods. Enrollment code validity\
        \ periods depend on the type of address where the code is sent as shown in\
        \ IA-12 (5) g below. \nInformation captured in the CSP\u2019s enrollment records\
        \ or system logs facilitate assessment against this requirement. Ideally,\
        \ this information would include details about the validity of the enrollment\
        \ code (date and time applicant entered code; confirmation it was the correct\
        \ code; and confirmation it was not expired)."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(5)-g
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(5)
      ref_id: IA-12(5)-g
      description: "Note that the following enrollment code validity periods apply\
        \ to enrollment codes sent to confirmed addresses of record for IAL2 remote\
        \ in-person proofing only. \nEnrollment codes shall have the following maximum\
        \ validities:\n1. 10 days, when sent to a postal address of record within\
        \ the contiguous United States;\n2. 30 days, when sent to a postal address\
        \ of record outside the contiguous United States;\n3. 10 minutes, when sent\
        \ to a telephone of record (SMS or voice);\n4. 24 hours, when sent to an email\
        \ address of record."
      annotation: 'SUPPLEMENTAL GUIDANCE: Enrollment codes sent to addresses of record
        are only valid for a limited amount of time, depending on the type of address
        of record to which they are sent. Applicants that present enrollment codes
        that are no longer valid (aka, expired) cannot use this code to complete their
        identity proofing process.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(5)-h
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(5)
      ref_id: IA-12(5)-h
      description: "If the enrollment code sent to the confirmed address of record\
        \ as part of the remote identity proofing process at IAL2 is also intended\
        \ to be an authentication factor, then\u2026it SHALL be reset upon first use."
      annotation: 'SUPPLEMENTAL GUIDANCE: Enrollment codes sent as an authentication
        factor for address confirmation may only be used once.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(5)-i
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(5)
      ref_id: IA-12(5)-i
      description: "If the CSP performs remote proofing at IAL2 and optionally sends\
        \ notification of proofing in addition to sending the required enrollment\
        \ code, then\u2026The CSP SHALL ensure the enrollment code and notification\
        \ of proofing are sent to different addresses of record."
      annotation: 'SUPPLEMENTAL GUIDANCE: For example, if the CSP sends an enrollment
        code to a phone number validated in records, a proofing notification may be
        sent to the postal address validated in records or obtained from validated
        and verified evidence, such as a driver''s license.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1043
      assessable: false
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ia-12(5)
      description: 'Related Controls: IA-12.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.7
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5
      ref_id: '5.7'
      name: 'Policy Area 7: Configuration Management'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.7.1
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.7
      ref_id: 5.7.1
      name: Access Restrictions for Changes
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.7.1.1
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.7.1
      ref_id: 5.7.1.1
      name: Least Functionality
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1047
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.7.1.1
      description: The agency shall configure the application, service, or information
        system to provide only essential capabilities and shall specifically prohibit
        and/or restrict the use of specified functions, ports, protocols, and/or services.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.7.1.2
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.7.1
      ref_id: 5.7.1.2
      name: Network Diagram
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1049
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.7.1.2
      description: The agency shall ensure that a complete topological drawing depicting
        the interconnectivity of the agency network, to criminal justice information,
        systems and services is maintained in a current status.See Appendix C for
        sample network diagrams.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1050
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.7.1.2
      description: 'The network topological drawing shall include the following: '
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.7.1.2-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.7.1.2
      ref_id: 5.7.1.2-1
      description: All communications paths, circuits, and other components used for
        the interconnection, beginning with the agency-owned system(s) and traversing
        through all interconnected systems to the agency end-point.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.7.1.2-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.7.1.2
      ref_id: 5.7.1.2-2
      description: The logical location of all components (e.g., firewalls, routers,
        switches, hubs, servers, encryption devices, and computer workstations). Individual
        workstations (clients) do not have to be shown; the number of clients is sufficient.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.7.1.2-3
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.7.1.2
      ref_id: 5.7.1.2-3
      description: "\u201CFor Official Use Only\u201D (FOUO) markings."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.7.1.2-4
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.7.1.2
      ref_id: 5.7.1.2-4
      description: The agency name and date (day, month, and year) drawing was created
        or updated.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.7.2
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.7
      ref_id: 5.7.2
      name: Security of Configuration Documentation
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1056
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.7.2
      description: The system configuration documentation often contains sensitive
        details (e.g., descriptions of applications, processes, procedures, data structures,
        authorization processes, data flow, etc.) Agencies shall protect the system
        documentation from unauthorized access consistent with the provisions described
        in Section 5.5 Access Control.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.8
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5
      ref_id: '5.8'
      name: MEDIA PROTECTION (MP)
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-1
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.8
      ref_id: MP-1
      name: POLICY AND PROCEDURES
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-1-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-1
      ref_id: MP-1-a
      description: 'Develop, document, and disseminate to authorized individuals:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-1-a-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-1-a
      ref_id: MP-1-a-1
      description: 'Agency-level media protection policy that:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-1-a-1-a
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-1-a-1
      ref_id: MP-1-a-1-a
      description: Addresses purpose, scope, roles, responsibilities, management commitment,
        coordination among agency entities, and compliance; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-1-a-1-b
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-1-a-1
      ref_id: MP-1-a-1-b
      description: Is consistent with applicable laws, executive orders, directives,
        regulations, policies, standards, and guidelines; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-1-a-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-1-a
      ref_id: MP-1-a-2
      description: Procedures to facilitate the implementation of the media protection
        policy and the associated media protection controls;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-1-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-1
      ref_id: MP-1-b
      description: Designate an individual with security responsibilities to manage
        the development, documentation, and dissemination of the media protection
        policy and procedures; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-1-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-1
      ref_id: MP-1-c
      description: 'Review and update the current media protection:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-1-c-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-1-c
      ref_id: MP-1-c-1
      description: Policy at least annually and following any security incidents involving
        digital and/or nondigital media; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-1-c-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-1-c
      ref_id: MP-1-c-2
      description: Procedures at least annually and following any security incidents
        involving digital and/or non-digital media.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1068
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-1
      description: 'Discussion: Media protection policy and procedures address the
        controls in the MP family that are implemented within systems and agencies.
        The risk management strategy is an important factor in establishing such policies
        and procedures. Policies and procedures contribute to security and privacy
        assurance. Therefore, it is important that security and privacy programs collaborate
        on the development of media protection policy and procedures. Security and
        privacy program policies and procedures at the agency level are preferable,
        in general, and may obviate the need for mission- or system-specific policies
        and procedures. The policy can be included as part of the general security
        and privacy policy or be represented by multiple policies that reflect the
        complex nature of agencies. Procedures can be established for security and
        privacy programs, for mission or business processes, and for systems, if needed.
        Procedures describe how the policies or controls are implemented and can be
        directed at the individual or role that is the object of the procedure. Procedures
        can be documented in system security and privacy plans or in one or more separate
        documents. Events that may precipitate an update to media protection policy
        and procedures include assessment or audit findings, security incidents or
        breaches, or changes in applicable laws, executive orders, directives, regulations,
        policies, standards, and guidelines. Simply restating controls does not constitute
        an agency policy or procedure.

        Related Controls: PS-8, SI-12.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-2
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.8
      ref_id: MP-2
      name: MEDIA ACCESS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1070
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-2
      description: Restrict access to digital and non-digital media to authorized
        individuals.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1071
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-2
      description: 'Discussion: System media includes digital and non-digital media.
        Digital media includes flash drives, diskettes, magnetic tapes, external or
        removable hard disk drives (e.g., solid state, magnetic), compact discs, and
        digital versatile discs. Non-digital media includes paper and microfilm. Denying
        access to hard copies of case file information stored in a locked filing cabinet
        is an example of restricting access to non-digital media. Limiting access
        to the design specifications stored on compact discs in the media library
        to individuals on the system development team is an example of restricting
        access to digital media.

        Related Controls: AC-19, AU-9, CP-2, CP-9, CP-10, MA-5, MP-4, MP-6, PE-2,
        PE-3, SC-12, SC-13, SI-12.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-3
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.8
      ref_id: MP-3
      name: MEDIA MARKING
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-3-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-3
      ref_id: MP-3-a
      description: Mark system media indicating the distribution limitations, handling
        caveats, and applicable security markings (if any) of the information; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-3-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-3
      ref_id: MP-3-b
      description: Exempt digital and non-digital media containing CJI from marking
        if the media remain within physically secure locations or controlled areas.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1075
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-3
      description: 'Discussion: Security marking refers to the application or use
        of human-readable security attributes. Digital media includes diskettes, magnetic
        tapes, external or removable hard disk drives (e.g., solid state, magnetic),
        flash drives, compact discs, and digital versatile discs. Non-digital media
        includes paper and microfilm. Controlled unclassified information (CUI) is
        defined by the National Archives and Records Administration (NARA) along with
        the appropriate safeguarding and dissemination requirements for such information
        and is codified in [32 CFR 2002]. Security markings are generally not required
        for media that contains information determined by agencies to be in the public
        domain or to be publicly releasable. Some agencies may require markings for
        public information indicating that the information is publicly releasable.
        System media marking reflects applicable laws, executive orders, directives,
        policies, regulations, standards, and guidelines. Executive Order 13556 mandates
        the marking of CUI. The following categories of CJI fall under the designated
        NARA categories which direct marking as indicated.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1076
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1075
      description: "1.Biometric Data\u2014data derived from one or more intrinsic\
        \ physical or behavioral traits of humans typically for the purpose of uniquely\
        \ identifying individuals from within a population. Used to identify individuals,\
        \ to include: fingerprints, palm prints, iris scans, and facial recognition\
        \ data. NARA CUI Category: Sensitive Personally Identifiable Information.\
        \ NARA Banner Marking: CUI"
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1077
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1075
      description: "2.Identity History Data\u2014textual data that corresponds with\
        \ an individual\u2019s biometric data, providing a history of criminal and/or\
        \ civil events for the identified individual. NARA CUI Category: Criminal\
        \ History Records Information. NARA Banner Marking: CUI//SP-CHRI"
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1078
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1075
      description: "3.Biographic Data\u2014information about individuals associated\
        \ with a unique case, and not necessarily connected to identity data. Biographic\
        \ data does not provide a history of an individual, only information related\
        \ to a unique case. NARA CUI Category: General Law Enforcement. NARA Banner\
        \ Marking: CUI"
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1079
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1075
      description: "4.Property Data\u2014information about vehicles and property associated\
        \ with crime when accompanied by any personally identifiable information (PII).\
        \ NARA CUI Category: General Law Enforcement. NARA Banner Marking: CUI"
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1080
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1075
      description: "5.Case/Incident History\u2014information about the history of\
        \ criminal incidents. NARA CUI Category: General Law Enforcement. NARA Banner\
        \ Marking: CUI"
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1081
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-3
      description: '[32 CFR 2002] states the CUI Program prohibits using markings
        or practices not included in this part or the CUI Registry. If legacy markings
        remain on information, the legacy markings are void and no longer indicate
        that the information is protected or that it is or qualifies as CUI. Related
        Controls: CP-9, MP-5, SI-12.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-4
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.8
      ref_id: MP-4
      name: MEDIA STORAGE
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-4-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-4
      ref_id: MP-4-a
      description: Physically control and securely store digital and non-digital media
        within physically secure locations or controlled areas and encrypt CJI on
        digital media when physical and personnel restrictions are not feasible; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-4-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-4
      ref_id: MP-4-b
      description: Protect system media types defined in MP-4a until the media are
        destroyed or sanitized using approved equipment, techniques, and procedures.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1085
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-4
      description: 'Discussion: System media includes digital and non-digital media.
        Digital media includes flash drives, diskettes, magnetic tapes, external or
        removable hard disk drives (e.g., solid state, magnetic), compact discs, and
        digital versatile discs. Non-digital media includes paper and microfilm. Physically
        controlling stored media includes conducting inventories, ensuring procedures
        are in place to allow individuals to check out and return media to the library,
        and maintaining accountability for stored media. Secure storage includes a
        locked drawer, desk, or cabinet or a controlled media library. The type of
        media storage is commensurate with the security category or classification
        of the information on the media. Controlled areas are spaces that provide
        physical and procedural controls to meet the requirements established for
        protecting information and systems. Fewer controls may be needed for media
        that contains information determined to be in the public domain, publicly
        releasable, or have limited adverse impacts on agencies, operations, or individuals
        if accessed by other than authorized personnel. In these situations, physical
        access controls provide adequate protection.

        Related Controls: AC-19, CP-2, CP-6, CP-9, CP-10, MP-2, MP-7, PE-3, PL-2,
        SC-12, SC-13,

        SC-28, SI-12.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-5
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.8
      ref_id: MP-5
      name: MEDIA TRANSPORT
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-5-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-5
      ref_id: MP-5-a
      description: Protect and control digital and non-digital media to help prevent
        compromise of the data during transport outside of the physically secure locations
        or controlled areas using encryption, as defined in SC-13 and SC-28 of this
        Policy.Physical media will be protected at the same level as the information
        would be protected in electronic form.Restrict the activities associated with
        transport of electronic and physical media to authorized personnel;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-5-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-5
      ref_id: MP-5-b
      description: Maintain accountability for system media during transport outside
        of the physically secure location or controlled areas;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-5-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-5
      ref_id: MP-5-c
      description: Document activities associated with the transport of system media;
        and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-5-d
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-5
      ref_id: MP-5-d
      description: Restrict the activities associated with the transport of system
        media to authorized personnel.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1091
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-5
      description: 'Discussion: System media includes digital and non-digital media.
        Digital media includes flash drives, diskettes, magnetic tapes, external or
        removable hard disk drives (e.g., solid state and magnetic), compact discs,
        and digital versatile discs. Non-digital media includes microfilm and paper.
        Controlled areas are spaces for which agencies provide physical or procedural
        controls to meet requirements established for protecting information and systems.
        Controls to protect media during transport include cryptography and locked
        containers. Cryptographic mechanisms can provide confidentiality and integrity
        protections depending on the mechanisms implemented. Activities associated
        with media transport include releasing media for transport, ensuring that
        media enters the appropriate transport processes, and the actual transport.
        Authorized transport and courier personnel may include individuals external
        to the agency. Maintaining accountability of media during transport includes
        restricting transport activities to authorized personnel and tracking and/or
        obtaining records of transport activities as the media moves through the transportation
        system to prevent and detect loss, destruction, or tampering. Agencies establish
        documentation requirements for activities associated with the transport of
        system media in accordance with agency assessments of risk. Agencies maintain
        the flexibility to define recordkeeping methods for the different types of
        media transport as part of a system of transport-related records.

        Related Controls: AC-7, AC-19, CP-2, CP-9, MP-3, MP-4, PE-16, PL-2, SC-12,
        SC-13, SC-28.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-6
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.8
      ref_id: MP-6
      name: MEDIA SANITIZATION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-6-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-6
      ref_id: MP-6-a
      description: Sanitize or destroy digital and non-digital media prior to disposal,
        release out of agency control, or release for reuse using overwrite technology
        at least three times or degauss digital media prior to disposal or release
        for reuse by unauthorized individuals.Inoperable digital media will be destroyed
        (cut up, shredded, etc.).Physical media will be securely disposed of when
        no longer needed for investigative or security purposes, whichever is later.Physical
        media will be destroyed by crosscut shredding or incineration; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-6-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-6
      ref_id: MP-6-b
      description: Employ sanitization mechanisms with the strength and integrity
        commensurate with the security category or classification of the information.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1095
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-6
      description: "Discussion: Media sanitization applies to all digital and non-digital\
        \ system media subject to disposal or reuse, whether or not the media is considered\
        \ removable. Examples include digital media in scanners, copiers, printers,\
        \ notebook computers, workstations, network components, mobile devices, and\
        \ non-digital media (e.g., paper and microfilm). The sanitization process\
        \ removes information from system media such that the information cannot be\
        \ retrieved or reconstructed. Sanitization techniques\u2014including clearing,\
        \ purging, cryptographic erase, deidentification of personally identifiable\
        \ information, and destruction\u2014prevent the disclosure of information\
        \ to unauthorized individuals when such media is reused or released for disposal.\
        \ Agencies determine the appropriate sanitization methods, recognizing that\
        \ destruction is sometimes necessary when other methods cannot be applied\
        \ to media requiring sanitization. \nAgencies use discretion on the employment\
        \ of approved sanitization techniques and procedures for media that contains\
        \ information deemed to be in the public domain or publicly releasable or\
        \ information deemed to have no adverse impact on agencies or individuals\
        \ if released for reuse or disposal. Sanitization of non-digital media includes\
        \ destruction, removing a classified appendix from an otherwise unclassified\
        \ document, or redacting selected sections or words from a document by obscuring\
        \ the redacted sections or words in a manner equivalent in effectiveness to\
        \ removing them from the document. NSA standards and policies control the\
        \ sanitization process for media that contains classified information. NARA\
        \ policies control the sanitization process for controlled unclassified information.\n\
        Related Controls: AC-3, AC-7, AU-11, MA-2, MA-3, MA-4, MA-5, SI-12, SR-11."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-7
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.8
      ref_id: MP-7
      name: MEDIA USE
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-7-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-7
      ref_id: MP-7-a
      description: Restrict the use of digital and non-digital media on agency owned
        systems that have been approved for use in the storage, processing, or transmission
        of criminal justice information by using technical, physical, or administrative
        controls (examples below); and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-7-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-7
      ref_id: MP-7-b
      description: Prohibit the use of personally owned digital media devices on all
        agency owned or controlled systems that store, process, or transmit criminal
        justice information; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-7-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-7
      ref_id: MP-7-c
      description: Prohibit the use of digital media devices on all agency owned or
        controlled systems that store, process, or transmit criminal justice information
        when such devices have no identifiable owner.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1100
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:mp-7
      description: 'Discussion: System media includes both digital and non-digital
        media. Digital media includes diskettes, magnetic tapes, flash drives, compact
        discs, digital versatile discs, and removable hard disk drives. Non-digital
        media includes paper and microfilm. Media use protections also apply to mobile
        devices with information storage capabilities. In contrast to MP-2, which
        restricts user access to media, MP-7 restricts the use of certain types of
        media on systems, for example, restricting or prohibiting the use of flash
        drives or external hard disk drives. Agencies use technical and nontechnical
        controls to restrict the use of system media. Agencies may restrict the use
        of portable storage devices, for example, by using physical cages on workstations
        to prohibit access to certain external ports or disabling or removing the
        ability to insert, read, or write to such devices. Agencies may also limit
        the use of portable storage devices to only approved devices, including devices
        provided by the agency, devices provided by other approved agencies, and devices
        that are not personally owned. Finally, agencies may restrict the use of portable
        storage devices based on the type of device, such as by prohibiting the use
        of writeable, portable storage devices and implementing this restriction by
        disabling or removing the capability to write to such devices. Requiring identifiable
        owners for storage devices reduces the risk of using such devices by allowing
        agencies to assign responsibility for addressing known vulnerabilities in
        the devices.

        Related Controls: AC-19, AC-20, PL-4.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.9
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5
      ref_id: '5.9'
      name: PHYSICAL AND ENVIRONMENTAL PROTECTION (PE)
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-1
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.9
      ref_id: PE-1
      name: POLICY AND PROCEDURES
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-1-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-1
      ref_id: PE-1-a
      description: 'Develop, document, and disseminate to organizational personnel
        with physical and environmental protection responsibilities:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-1-a-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-1-a
      ref_id: PE-1-a-1
      description: 'Agency-level physical and environmental protection policy that:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-1-a-1-a
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-1-a-1
      ref_id: PE-1-a-1-a
      description: "Addresses purpose, scope, roles, responsibilities, management\
        \ commitment, coordination among organizational entities, and compliance;\
        \ and \n"
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-1-a-1-b
      assessable: false
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-1-a-1
      ref_id: PE-1-a-1-b
      description: Is consistent with applicable laws, executive orders, directives,
        regulations, policies, standards, and guidelines; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-1-a-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-1-a
      ref_id: PE-1-a-2
      description: Procedures to facilitate the implementation of the physical and
        environmental protection policy and the associated physical and environmental
        protection controls;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-1-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-1
      ref_id: PE-1-b
      description: Designate organizational personnel with information security responsibilities
        to manage the development, documentation, and dissemination of the physical
        and environmental protection policy and procedures; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-1-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-1
      ref_id: PE-1-c
      description: 'Review and update the current physical and environmental protection:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-1-c-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-1-c
      ref_id: PE-1-c-1
      description: Policy annually and following any physical, environmental, or security
        related incidents involving CJI or systems used to process, store, or transmit
        CJI; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-1-c-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-1-c
      ref_id: PE-1-c-2
      description: Procedures annually and following any physical, environmental,
        or security related incidents involving CJI or systems used to process, store,
        or transmit CJI.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1112
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-1
      description: "Discussion: Physical and environmental protection policy and procedures\
        \ address the controls in the PE family that are implemented within systems\
        \ and organizations. The risk management strategy is an important factor in\
        \ establishing such policies and procedures. Policies and procedures contribute\
        \ to security and privacy assurance. Therefore, it is important that security\
        \ and privacy programs collaborate on the development of physical and environmental\
        \ protection policy and procedures. Security and privacy program policies\
        \ and procedures at the organization level are preferable, in general, and\
        \ may obviate the need for mission- or system-specific policies and procedures.\
        \ The policy can be included as part of the general security and privacy policy\
        \ or be represented by multiple policies that reflect the complex nature of\
        \ organizations. Procedures can be established for security and privacy programs,\
        \ for mission or business processes, and for systems, if needed. Procedures\
        \ describe how the policies or controls are implemented and can be directed\
        \ at the individual or role that is the object of the procedure. Procedures\
        \ can be documented in system security and privacy plans or in one or more\
        \ separate documents. Events that may precipitate an update to physical and\
        \ environmental protection policy and procedures include assessment or audit\
        \ findings, security incidents or breaches, or changes in applicable laws,\
        \ executive orders, directives, regulations, policies, standards, and guidelines.\
        \ Simply restating controls does not constitute an organizational policy or\
        \ procedure. \n \nRelated Controls: AT-3, PS-8, SI-12."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-2
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.9
      ref_id: PE-2
      name: PHYSICAL ACCESS AUTHORIZATIONS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-2-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-2
      ref_id: PE-2-a
      description: Develop, approve, and maintain a list of individuals with authorized
        access to the facility where the system resides;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-2-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-2
      ref_id: PE-2-b
      description: Issue authorization credentials for facility access;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-2-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-2
      ref_id: PE-2-c
      description: Review the access list detailing authorized facility access by
        individuals annually and when personnel changes occur; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-2-d
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-2
      ref_id: PE-2-d
      description: Remove individuals from the facility access list when access is
        no longer required.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1118
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-2
      description: "Discussion: Physical access authorizations apply to employees\
        \ and visitors. Individuals with permanent physical access authorization credentials\
        \ are not considered visitors. Authorization credentials include ID badges,\
        \ identification cards, and smart cards. Organizations determine the strength\
        \ of authorization credentials needed consistent with applicable laws, executive\
        \ orders, directives, regulations, policies, standards, and guidelines. Physical\
        \ access authorizations may not be necessary to access certain areas within\
        \ facilities that are designated as publicly accessible. \nRelated Controls:\
        \ AT-3, AU-9, IA-4, MA-5, MP-2, PE-3, PE-4, PE-5, PE-8, PS-3, PS-4, PS-5,\
        \ PS-6."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-3
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.9
      ref_id: PE-3
      name: PHYSICAL ACCESS CONTROL
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-3-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-3
      ref_id: PE-3-a
      description: 'Enforce physical access authorizations by:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-3-a-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-3-a
      ref_id: PE-3-a-1
      description: Verifying individual access authorizations before granting access
        to the facility; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-3-a-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-3-a
      ref_id: PE-3-a-2
      description: Controlling ingress and egress to the facility using agency-implemented
        procedures and controls;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-3-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-3
      ref_id: PE-3-b
      description: Maintain physical access audit logs for the physically secure location
        and agency-defined sensitive areas;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-3-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-3
      ref_id: PE-3-c
      description: Control access to areas within the facility designated as non-publicly
        accessible by implementing physical access devices including, but not limited
        to keys, locks, combinations, biometric readers, placards, and/or card readers;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-3-d
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-3
      ref_id: PE-3-d
      description: Escort visitors and control visitor activity in all physically
        secure locations;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-3-e
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-3
      ref_id: PE-3-e
      description: Secure keys, combinations, and other physical access devices;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-3-f
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-3
      ref_id: PE-3-f
      description: Inventory all agency-issued physical access devices annually; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-3-g
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-3
      ref_id: PE-3-g
      description: Change combinations and keys when keys are lost, combinations are
        compromised, or when individuals possessing the keys or combinations are transferred
        or terminated.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-3-h
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-3
      ref_id: PE-3-h
      description: If the above conditions cannot be met refer to the requirements
        listed in PE-17.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1130
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-3
      description: "Discussion: Physical access control applies to employees and visitors.\
        \ Individuals with permanent physical access authorizations are not considered\
        \ visitors. Physical access controls for publicly accessible areas may include\
        \ physical access control logs/records, guards, or physical access devices\
        \ and barriers to prevent movement from publicly accessible areas to non-public\
        \ areas. \nOrganizations determine the types of guards needed, including professional\
        \ security staff, system users, or administrative staff. Physical access devices\
        \ include keys, locks, combinations, biometric readers, and card readers.\
        \ Physical access control systems comply with applicable laws, executive orders,\
        \ directives, policies, regulations, standards, and guidelines. Organizations\
        \ have flexibility in the types of audit logs employed. Audit logs can be\
        \ procedural, automated, or some combination thereof. Physical access points\
        \ can include facility access points, interior access points to systems that\
        \ require supplemental access controls, or both. Components of systems may\
        \ be in areas designated as publicly accessible with organizations controlling\
        \ access to the components. \nRelated Controls: AT-3, AU-2, AU-6, AU-9, CP-10,\
        \ IA-3, IA-8, MA-5, MP-2, MP-4, PE-2, PE4, PE-5, PE-8, PS-2, PS-3, PS-6, PS-7,\
        \ RA-3, SC-28, SI-4, SR-3."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-4
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.9
      ref_id: PE-4
      name: ACCESS CONTROL FOR TRANSMISSION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1132
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-4
      description: Control physical access to information system distribution and
        transmission lines and devices within organizational facilities using agency-implemented
        procedures and controls.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1133
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-4
      description: "Discussion: Security controls applied to system distribution and\
        \ transmission lines prevent accidental damage, disruption, and physical tampering.\
        \ Such controls may also be necessary to prevent eavesdropping or modification\
        \ of unencrypted transmissions. Security controls used to control physical\
        \ access to system distribution and transmission lines include disconnected\
        \ or locked spare jacks, locked wiring closets, protection of cabling by conduit\
        \ or cable trays, and wiretapping sensors. \nRelated Controls: AT-3, IA-4,\
        \ MP-2, MP-4, PE-2, PE-3, PE-5, PE-9, SC-7, SC-8."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-5
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.9
      ref_id: PE-5
      name: ACCESS CONTROL FOR OUTPUT DEVICES
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1135
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-5
      description: Control physical access to output from monitors, printers, scanners,
        audio devices, facsimile machines, and copiers to prevent unauthorized individuals
        from obtaining the output.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1136
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-5
      description: 'Discussion: Controlling physical access to output devices includes
        placing output devices in locked rooms or other secured areas with keypad
        or card reader access controls and allowing access to authorized individuals
        only, placing output devices in locations that can be monitored by personnel,
        installing monitor or screen filters, and using headphones. Examples of output
        devices include monitors, printers, scanners, audio devices, facsimile machines,
        and copiers.

        Related Controls: PE-2, PE-3, PE-4.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-6
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.9
      ref_id: PE-6
      name: MONITORING PHYSICAL ACCESS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-6-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-6
      ref_id: PE-6-a
      description: Monitor physical access to the facility where the system resides
        to detect and respond to physical security incidents;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-6-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-6
      ref_id: PE-6-b
      description: Review physical access logs quarterly and upon occurrence of any
        physical, environmental, or security-related incidents involving CJI or systems
        used to process, store, or transmit CJI; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-6-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-6
      ref_id: PE-6-c
      description: Coordinate results of reviews and investigations with the organizational
        incident response capability.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1141
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-6
      description: "Discussion: Physical access monitoring includes publicly accessible\
        \ areas within organizational facilities. Examples of physical access monitoring\
        \ include the employment of guards, video surveillance equipment (i.e., cameras),\
        \ and sensor devices. Reviewing physical access logs can help identify suspicious\
        \ activity, anomalous events, or potential threats. The reviews can be supported\
        \ by audit logging controls, such as AU-2, if the access logs are part of\
        \ an automated system. Organizational incident response capabilities include\
        \ investigations of physical security incidents and responses to the incidents.\
        \ Incidents include security violations or suspicious physical access activities.\
        \ Suspicious physical access activities include accesses outside of normal\
        \ work hours, repeated accesses to areas not normally accessed, accesses for\
        \ unusual lengths of time, and out-of-sequence accesses. \nRelated Controls:\
        \ AU-2, AU-6, AU-9, AU-12, CA-7, CP-10, IR-4, IR-8. \n Discussion: Physical\
        \ access monitoring includes publicly accessible areas within organizational\
        \ facilities. Examples of physical access monitoring include the employment\
        \ of guards, video surveillance equipment (i.e., cameras), and sensor devices.\
        \ Reviewing physical access logs can help identify suspicious activity, anomalous\
        \ events, or potential threats. The reviews can be supported by audit logging\
        \ controls, such as AU-2, if the access logs are part of an automated system.\
        \ Organizational incident response capabilities include investigations of\
        \ physical security incidents and responses to the incidents. Incidents include\
        \ security violations or suspicious physical access activities. Suspicious\
        \ physical access activities include accesses outside of normal work hours,\
        \ repeated accesses to areas not normally accessed, accesses for unusual lengths\
        \ of time, and out-of-sequence accesses. \nRelated Controls: AU-2, AU-6, AU-9,\
        \ AU-12, CA-7, CP-10, IR-4, IR-8."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-6(1)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-6
      ref_id: PE-6(1)
      name: MONITORING PHYSICAL ACCESS | INTRUSION ALARMS AND SURVEILLANCE EQUIPMENT
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1143
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-6(1)
      description: Monitor physical access to the facility where the system resides
        using physical intrusion alarms and surveillance equipment.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1144
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-6(1)
      description: "Discussion: Physical intrusion alarms can be employed to alert\
        \ security personnel when unauthorized access to the facility is attempted.\
        \ Alarm systems work in conjunction with physical barriers, physical access\
        \ control systems, and security guards by triggering a response when these\
        \ other forms of security have been compromised or breached. Physical intrusion\
        \ alarms can include different types of sensor devices, such as motion sensors,\
        \ contact sensors, and broken glass sensors. Surveillance equipment includes\
        \ video cameras installed at strategic locations throughout the facility.\
        \ \nRelated Controls: None"
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-8
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.9
      ref_id: PE-8
      name: VISITOR ACCESS RECORDS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-8-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-8
      ref_id: PE-8-a
      description: Maintain visitor access records to the facility where the system
        resides for one (1) year;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-8-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-8
      ref_id: PE-8-b
      description: Review visitor access records quarterly; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-8-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-8
      ref_id: PE-8-c
      description: Report anomalies in visitor access records to organizational personnel
        with physical and environmental protection responsibilities and organizational
        personnel with information security responsibilities.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1149
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-8
      description: "Discussion: Visitor access records include the names and organizations\
        \ of individuals visiting, visitor signatures, forms of identification, dates\
        \ of access, entry and departure times, purpose of visits, and the names and\
        \ organizations of individuals visited. Access record reviews determine if\
        \ access authorizations are current and are still required to support organizational\
        \ mission and business functions. Access records are not required for publicly\
        \ accessible areas. \nRelated Controls: PE-2, PE-3, PE-6"
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-8(3)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-8
      ref_id: PE-8(3)
      name: VISITOR ACCESS RECORDS | LIMIT PERSONALLY IDENTIFIABLE INFORMATION ELEMENTS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1151
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-8(3)
      description: 'Limit personally identifiable information contained in visitor
        access records to the minimum PII necessary to achieve the purpose for which
        it is collected (see Section 4.3).

        Note: Access to visitor access records is restricted to authorized agency
        personnel.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1152
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-8(3)
      description: "Discussion: Organizations may have requirements that specify the\
        \ contents of visitor access records. Limiting personally identifiable information\
        \ in visitor access records when such information is not needed for operational\
        \ purposes helps reduce the level of privacy risk created by a system. \n\
        Related Controls: RA-3, SA-8."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-9
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.9
      ref_id: PE-9
      name: POWER EQUIPMENT AND CABLING
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1154
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-9
      description: 'Protect power equipment and power cabling for the system from
        damage and destruction.

        Note:This control only applies to data centers as defined in Appendix A Terms
        and Definitions.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1155
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-9
      description: "Discussion: Organizations determine the types of protection necessary\
        \ for the power equipment and cabling employed at different locations that\
        \ are both internal and external to organizational facilities and environments\
        \ of operation. Types of power equipment and cabling include internal cabling\
        \ and uninterruptable power sources in offices or data centers, generators\
        \ and power cabling outside of buildings, and power sources for self-contained\
        \ components such as satellites, vehicles, and other deployable systems. \n\
        Related Controls: PE-4."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-10
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.9
      ref_id: PE-10
      name: EMERGENCY SHUTOFF
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-10-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-10
      ref_id: PE-10-a
      description: Provide the capability of shutting off power to all information
        systems in emergency situations;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-10-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-10
      ref_id: PE-10-b
      description: Place emergency shutoff switches or devices in easily accessible
        locations to facilitate access for authorized personnel; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-10-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-10
      ref_id: PE-10-c
      description: 'Protect emergency power shutoff capability from unauthorized activation.

        Note:This control only applies to data centers as defined in Appendix A Terms
        and Definitions.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1160
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-10
      description: "Discussion: Emergency power shutoff primarily applies to organizational\
        \ facilities that contain concentrations of system resources, including data\
        \ centers, mainframe computer rooms, server rooms, and areas with computer-controlled\
        \ machinery. \nRelated Controls: PE-15."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-11
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.9
      ref_id: PE-11
      name: EMERGENCY POWER
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1162
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-11
      description: 'Provide an uninterruptible power supply to facilitate an orderly
        shutdown of the information system or transition of the information system
        to an alternate power source in the event of a primary power source loss.

        Note:This control only applies to data centers as defined in Appendix A Terms
        and Definitions.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1163
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-11
      description: "Discussion: An uninterruptible power supply (UPS) is an electrical\
        \ system or mechanism that provides emergency power when there is a failure\
        \ of the main power source. A UPS is typically used to protect computers,\
        \ data centers, telecommunication equipment, or other electrical equipment\
        \ where an unexpected power disruption could cause injuries, fatalities, serious\
        \ mission or business disruption, or loss of data or information. A UPS differs\
        \ from an emergency power system or backup generator in that the UPS provides\
        \ near-instantaneous protection from unanticipated power interruptions from\
        \ the main power source by providing energy stored in batteries, supercapacitors,\
        \ or flywheels. The battery duration of a UPS is relatively short but provides\
        \ sufficient time to start a standby power source, such as a backup generator,\
        \ or properly shut down the system. \nRelated Controls: AT-3, CP-2, CP-7."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-12
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.9
      ref_id: PE-12
      name: EMERGENCY LIGHTING
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1165
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-12
      description: 'Employ and maintain automatic emergency lighting for the system
        that activates in the event of a power outage or disruption and that covers
        emergency exits and evacuation routes within the facility.

        Note: This control only applies to data centers as defined in Appendix A Terms
        and Definitions.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1166
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-12
      description: "Discussion: The provision of emergency lighting applies primarily\
        \ to organizational facilities that contain concentrations of system resources,\
        \ including data centers, server rooms, and mainframe computer rooms. Emergency\
        \ lighting provisions for the system are described in the contingency plan\
        \ for the organization. If emergency lighting for the system fails or cannot\
        \ be provided, organizations consider alternate processing sites for power-related\
        \ contingencies. \nRelated Controls: CP-2, CP-7."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-13
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.9
      ref_id: PE-13
      name: FIRE PROTECTION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1168
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-13
      description: 'Employ and maintain fire detection and suppression systems that
        are supported by an independent energy source.

        Note: This control only applies to data centers as defined in Appendix A Terms
        and Definitions.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1169
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-13
      description: "Discussion: The provision of fire detection and suppression systems\
        \ applies primarily to organizational facilities that contain concentrations\
        \ of system resources, including data centers, server rooms, and mainframe\
        \ computer rooms. Fire detection and suppression systems that may require\
        \ an independent energy source include sprinkler systems and smoke detectors.\
        \ An independent energy source is an energy source, such as a microgrid, that\
        \ is separate, or can be separated, from the energy sources providing power\
        \ for the other parts of the facility. \nRelated Controls: AT-3."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-13(1)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-13
      ref_id: PE-13(1)
      name: "(1) FIRE PROTECTION | DETECTION SYSTEMS \u2014 AUTOMATIC ACTIVATION AND\
        \ NOTIFICATION"
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1171
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-13(1)
      description: 'Employ fire detection systems that activate automatically and
        notify organizational personnel with physical and environmental protection
        responsibilities and police, fire, or emergency medical personnel in the event
        of a fire.

        Note:This control only applies to data centers as defined in Appendix A Terms
        and Definitions.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1172
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-13(1)
      description: "Discussion: Organizations can identify personnel, roles, and emergency\
        \ responders if individuals on the notification list need to have access authorizations\
        \ or clearances (e.g., to enter to facilities where access is restricted due\
        \ to the classification or impact level of information within the facility).\
        \ Notification mechanisms may require independent energy sources to ensure\
        \ that the notification capability is not adversely affected by the fire.\
        \ \nRelated Controls: None."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-14
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.9
      ref_id: PE-14
      name: ENVIRONMENTAL CONTROLS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-14-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-14
      ref_id: PE-14-a
      description: Maintain adequate HVAC levels within the facility where the system
        resides at recommended system manufacturer levels; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-14-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-14
      ref_id: PE-14-b
      description: 'Monitor environmental control levels continuously.

        Note: This control only applies to data centers as defined in Appendix A Terms
        and Definitions.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1176
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-14
      description: "Discussion: The provision of environmental controls applies primarily\
        \ to organizational facilities that contain concentrations of system resources\
        \ (e.g., data centers, mainframe computer rooms, and server rooms). Insufficient\
        \ environmental controls, especially in very harsh environments, can have\
        \ a significant adverse impact on the availability of systems and system components\
        \ that are needed to support organizational mission and business functions.\
        \ \nRelated Controls: AT-3, CP-2."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-15
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.9
      ref_id: PE-15
      name: WATER DAMAGE PROTECTION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1178
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-15
      description: 'Protect the system from damage resulting from water leakage by
        providing master shutoff or isolation valves that are accessible, working
        properly, and known to key personnel.

        Note:This control only applies to data centers as defined in Appendix A Terms
        and Definitions.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1179
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-15
      description: "Discussion: The provision of water damage protection primarily\
        \ applies to organizational facilities that contain concentrations of system\
        \ resources, including data centers, server rooms, and mainframe computer\
        \ rooms. Isolation valves can be employed in addition to or in lieu of master\
        \ shutoff valves to shut off water supplies in specific areas of concern without\
        \ affecting entire organizations. \nRelated Controls: AT-3, PE-10."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-16
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.9
      ref_id: PE-16
      name: DELIVERY AND REMOVAL
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-16-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-16
      ref_id: PE-16-a
      description: Authorize and control information system-related components entering
        and exiting the facility; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-16-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-16
      ref_id: PE-16-b
      description: Maintain records of the system components.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1183
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-16
      description: "Discussion: Enforcing authorizations for entry and exit of system\
        \ components may require restricting access to delivery areas and isolating\
        \ the areas from the system and media libraries. \nRelated Controls: CM-3,\
        \ CM-8, MA-2, MA-3, MP-5, SR-2, SR-3, SR-6."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-17
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.9
      ref_id: PE-17
      name: ALTERNATE WORK SITE
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-17-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-17
      ref_id: PE-17-a
      description: Determine and document all alternate facilities or locations allowed
        for use by employees;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-17-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-17
      ref_id: PE-17-b
      description: 'Employ the following controls at alternate work sites:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-17-b-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-17-b
      ref_id: PE-17-b-1
      description: Limit access to the area during CJI processing times to only those
        personnel authorized by the agency to access or view CJI.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-17-b-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-17-b
      ref_id: PE-17-b-2
      description: Lock the area, room, or storage container when unattended.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-17-b-3
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-17-b
      ref_id: PE-17-b-3
      description: Position information system devices and documents containing CJI
        in such a way as to prevent unauthorized individuals from access and view.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-17-b-4
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-17-b
      ref_id: PE-17-b-4
      description: Follow the encryption requirements found in SC-13 and SC-28 for
        electronic storage (i.e., data at-rest) of CJI.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-17-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-17
      ref_id: PE-17-c
      description: Assess the effectiveness of controls at alternate work sites; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-17-d
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-17
      ref_id: PE-17-d
      description: Provide a means for employees to communicate with information security
        and privacy personnel in case of incidents.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1193
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pe-17
      description: "Discussion: Alternate work sites include government facilities\
        \ or the private residences of employees. While distinct from alternative\
        \ processing sites, alternate work sites can provide readily available alternate\
        \ locations during contingency operations. Organizations can define different\
        \ sets of controls for specific alternate work sites or types of sites depending\
        \ on the work-related activities conducted at the sites. Implementing and\
        \ assessing the effectiveness of organization-defined controls and providing\
        \ a means to communicate incidents at alternate work sites supports the contingency\
        \ planning activities of organizations. \nRelated Controls: AC-17, AC-18,\
        \ CP-7."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.10
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5
      ref_id: '5.10'
      name: SYSTEMS AND COMMUNICATIONS PROTECTION (SC)
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-1
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.10
      ref_id: SC-1
      name: POLICY AND PROCEDURES
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-1-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-1
      ref_id: SC-1-a
      description: 'Develop, document, and disseminate to organizational personnel
        with system and communications protection responsibilities:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-1-a-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-1-a
      ref_id: SC-1-a-1
      description: 'Agency-level system and communications protection policy that:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-1-a-1-a
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-1-a-1
      ref_id: SC-1-a-1-a
      description: Addresses purpose, scope, roles, responsibilities, management commitment,
        coordination among organizational entities, and compliance; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-1-a-1-b
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-1-a-1
      ref_id: SC-1-a-1-b
      description: Is consistent with applicable laws, executive orders, directives,
        regulations, policies, standards, and guidelines; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-1-a-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-1-a
      ref_id: SC-1-a-2
      description: Procedures to facilitate the implementation of the system and communications
        protection policy and the associated system and communications protection
        controls;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-1-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-1
      ref_id: SC-1-b
      description: Designate organizational personnel with information security responsibilities
        to manage the development, documentation, and dissemination of the system
        and communications protection policy and procedures; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-1-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-1
      ref_id: SC-1-c
      description: 'Review and update the current system and communications protection:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-1-c-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-1-c
      ref_id: SC-1-c-1
      description: Policy annually and following any changes and security incidents
        involving unauthorized access to CJI or systems used to process, store, or
        transmit CJI; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-1-c-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-1-c
      ref_id: SC-1-c-2
      description: Procedures annually and following any changes and security incidents
        involving unauthorized access to CJI or systems used to process, store, or
        transmit CJI.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1205
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-1
      description: "Discussion: System and communications protection policy and procedures\
        \ address the controls in the SC family that are implemented within systems\
        \ and organizations. The risk management strategy is an important factor in\
        \ establishing such policies and procedures. Policies and procedures contribute\
        \ to security and privacy assurance. Therefore, it is important that security\
        \ and privacy programs collaborate on the development of system and communications\
        \ protection policy and procedures. Security and privacy program policies\
        \ and procedures at the organization level are preferable, in general, and\
        \ may obviate the need for mission- or systemspecific policies and procedures.\
        \ The policy can be included as part of the general security and privacy policy\
        \ or be represented by multiple policies that reflect the complex nature of\
        \ organizations. Procedures can be established for security and privacy programs,\
        \ for mission or business processes, and for systems, if needed. Procedures\
        \ describe how the policies or controls are implemented and can be directed\
        \ at the individual or role that is the object of the procedure. \n \nProcedures\
        \ can be documented in system security and privacy plans or in one or more\
        \ separate documents. Events that may precipitate an update to system and\
        \ communications protection policy and procedures include assessment or audit\
        \ findings, security incidents or breaches, or changes in applicable laws,\
        \ executive orders, directives, regulations, policies, standards, and guidelines.\
        \ Simply restating controls does not constitute an organizational policy or\
        \ procedure.\nRelated Controls: PS-8, SA-8, SI-12."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-2
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.10
      ref_id: SC-2
      name: SEPARATION OF SYSTEM AND USER FUNCTIONALITY
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1207
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-2
      description: Separate user functionality, including user interface services,
        from system management functionality.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1208
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-2
      description: 'Discussion: System management functionality includes functions
        that are necessary to administer databases, network components, workstations,
        or servers. These functions typically require privileged user access. The
        separation of user functions from system management functions is physical
        or logical. Organizations may separate system management functions from user
        functions by using different computers, instances of operating systems, central
        processing units, or network addresses; by employing virtualization techniques;
        or some combination of these or other methods. Separation of system management
        functions from user functions includes web administrative interfaces that
        employ separate authentication methods for users of any other system resources.
        Separation of system and user functions may include isolating administrative
        interfaces on different domains and with additional access controls. The separation
        of system and user functionality can be achieved by applying the systems security
        engineering design principles in SA-8.

        Related Controls: AC-6, SA-4, SA-8, SC-7, SC-22, SC-39.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-4
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.10
      ref_id: SC-4
      name: INFORMATION IN SHARED SYSTEM RESOURCES
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1210
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-4
      description: Prevent unauthorized and unintended information transfer via shared
        system resources.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1211
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-4
      description: 'Discussion: Preventing unauthorized and unintended information
        transfer via shared system resources stops information produced by the actions
        of prior users or roles (or the actions of processes acting on behalf of prior
        users or roles) from being available to current users or roles (or current
        processes acting on behalf of current users or roles) that obtain access to
        shared system resources after those resources have been released back to the
        system. Information in shared system resources also applies to encrypted representations
        of information. In other contexts, control of information in shared system
        resources is referred to as object reuse and residual information protection.
        Information in shared system resources does not address information remanence,
        which refers to the residual representation of data that has been nominally
        deleted; covert channels (including storage and timing channels), where shared
        system resources are manipulated to violate information flow restrictions;
        or components within systems for which there are only single users or roles.

        Related Controls: AC-3, AC-4, SA-8'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-5
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.10
      ref_id: SC-5
      name: DENIAL-OF-SERVICE PROTECTION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-5-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-5
      ref_id: SC-5-a
      description: 'Protect against or limit the effects of the following types of
        denial-of-service events:

        distributed denial of service, DNS Denial of Service, etc.; and'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-5-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-5
      ref_id: SC-5-b
      description: 'Employ the following controls to achieve the denial-of-service
        objective: boundary protection devices and intrusion detection or prevention
        devices.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1215
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-5
      description: 'Discussion: Denial-of-service events may occur due to a variety
        of internal and external causes, such as an attack by an adversary or a lack
        of planning to support organizational needs with respect to capacity and bandwidth.
        Such attacks can occur across a wide range of network protocols (e.g., IPv4,
        IPv6). A variety of technologies are available to limit or eliminate the origination
        and effects of denial-of-service events. For example, boundary protection
        devices can filter certain types of packets to protect system components on
        internal networks from being directly affected by or the source of denial-of-service
        attacks. Employing increased network capacity and bandwidth combined with
        service redundancy also reduces the susceptibility to denial-of-service events.

        Related Controls: CP-2, IR-4, SC-7.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.10
      ref_id: SC-7
      name: BOUNDARY PROTECTION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7
      ref_id: SC-7-a
      description: Monitor and control communications at the external managed interfaces
        to the system and at key internal managed interfaces within the system;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7
      ref_id: SC-7-b
      description: Implement subnetworks for publicly accessible system components
        that are physically or logically separated from internal organizational networks;
        and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7
      ref_id: SC-7-c
      description: Connect to external networks or systems only through managed interfaces
        consisting of boundary protection devices arranged in accordance with an organizational
        security and privacy architecture.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1220
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7
      description: 'Discussion: Managed interfaces include gateways, routers, firewalls,
        guards, network-based malicious code analysis, virtualization systems, or
        encrypted tunnels implemented within a security architecture. Subnetworks
        that are physically or logically separated from internal networks are referred
        to as demilitarized zones or DMZs. Restricting or prohibiting interfaces within
        organizational systems includes restricting external web traffic to designated
        web servers within managed interfaces, prohibiting external traffic that appears
        to be spoofing internal addresses, and prohibiting internal traffic that appears
        to be spoofing external addresses. [SP 800-189] provides additional information
        on source address validation techniques to prevent ingress and egress of traffic
        with spoofed addresses. Commercial telecommunications services are provided
        by network components and consolidated management systems shared by customers.
        These services may also include third party-provided access lines and other
        service elements. Such services may represent sources of increased risk despite
        contract security provisions. Boundary protection may be implemented as a
        common control for all or part of an organizational network such that the
        boundary to be protected is greater than a system-specific boundary (i.e.,
        an authorization boundary).

        Related Controls: AC-4, AC-17, AC-18, AC-19, AC-20, CA-3, CM-2, CM-4, CM-7,
        CM-10, CP8, CP-10, IR-4, MA-4, PE-3, PL-8, SA-8, SC-5.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7(3)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7
      ref_id: SC-7(3)
      name: BOUNDARY PROTECTION | ACCESS POINTS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1222
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7(3)
      description: Limit the number of external network connections to the system.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1223
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7(3)
      description: 'Discussion: Limiting the number of external network connections
        facilitates monitoring of inbound and outbound communications traffic. A Trusted
        Internet Connection (TIC) initiative is an example of a federal guideline
        that requires limits on the number of external network connections. Limiting
        the number of external network connections to the system is important during
        transition periods from older to newer technologies (e.g., transitioning from
        IPv4 to IPv6 network protocols). Such transitions may require implementing
        the older and newer technologies simultaneously during the transition period
        and thus increase the number of access points to the system.

        Related Controls: None.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7(4)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7
      ref_id: SC-7(4)
      name: BOUNDARY PROTECTION | EXTERNAL TELECOMMUNICATIONS SERVICES
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7(4)-a
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7(4)
      ref_id: SC-7(4)-a
      description: Implement a managed interface for each external telecommunication
        service;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7(4)-b
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7(4)
      ref_id: SC-7(4)-b
      description: Establish a traffic flow policy for each managed interface;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7(4)-c
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7(4)
      ref_id: SC-7(4)-c
      description: Protect the confidentiality and integrity of the information being
        transmitted across each interface
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7(4)-d
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7(4)
      ref_id: SC-7(4)-d
      description: Document each exception to the traffic flow policy with a supporting
        mission or business need and duration of that need;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7(4)-e
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7(4)
      ref_id: SC-7(4)-e
      description: Review exceptions to the traffic flow policy annually, after any
        incident, and after any major changes impacting the information system, while
        removing exceptions that are no longer supported by an explicit mission or
        business need;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7(4)-f
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7(4)
      ref_id: SC-7(4)-f
      description: Prevent unauthorized exchange of control plane traffic with external
        networks;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7(4)-g
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7(4)
      ref_id: SC-7(4)-g
      description: Publish information to enable remote networks to detect unauthorized
        control plane traffic from internal networks; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7(4)-h
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7(4)
      ref_id: SC-7(4)-h
      description: Filter unauthorized control plane traffic from external networks.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1233
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7(4)
      description: 'Discussion: External telecommunications services can provide data
        and/or voice communications services. Examples of control plane traffic include
        Border Gateway Protocol (BGP) routing, Domain Name System (DNS), and management
        protocols. See [SP 800-189] for additional information on the use of the resource
        public key infrastructure (RPKI) to protect BGP routes and detect unauthorized
        BGP announcements.

        Related Controls: AC-3, SC-8, SC-20, SC-21, SC-22.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7(5)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7
      ref_id: SC-7(5)
      name: "BOUNDARY PROTECTION | DENY BY DEFAULT \u2014 ALLOW BY EXCEPTION"
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1235
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7(5)
      description: Deny network communications traffic by default and allow network
        communications traffic by exception at boundary devices for information systems
        used to process, store, or transmit CJI.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1236
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7(5)
      description: 'Discussion: Denying by default and allowing by exception applies
        to inbound and outbound network communications traffic. A deny-all, permit-by-exception
        network communications traffic policy ensures that only those system connections
        that are essential and approved are allowed. Deny by default, allow by exception
        also applies to a system that is connected to an external system.

        Related Controls: None'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7(7)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7
      ref_id: SC-7(7)
      name: BOUNDARY PROTECTION | SPLIT TUNNELING FOR REMOTE DEVICES
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1238
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7(7)
      description: Prevent split tunneling for remote devices connecting to organizational
        systems.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1239
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7(7)
      description: 'Discussion: Split tunneling is the process of allowing a remote
        user or device to establish a nonremote connection with a system and simultaneously
        communicate via some other connection to a resource in an external network.
        This method of network access enables a user to access remote devices and
        simultaneously, access uncontrolled networks. Split tunneling might be desirable
        by remote users to communicate with local system resources, such as printers
        or file servers. However, split tunneling can facilitate unauthorized external
        connections, making the system vulnerable to attack and to exfiltration of
        organizational information. Split tunneling can be prevented by disabling
        configuration settings that allow such capability in remote devices and by
        preventing those configuration settings from being configurable by users.
        Prevention can also be achieved by the detection of split tunneling (or of
        configuration settings that allow split tunneling) in the remote device, and
        by prohibiting the connection if the remote device is using split tunneling.
        A virtual private network (VPN) can be used to securely provision a split
        tunnel. A securely provisioned VPN includes locking connectivity to exclusive,
        managed, and named environments, or to a specific set of pre-approved addresses,
        without user control.

        Related Controls: None.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7(8)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7
      ref_id: SC-7(8)
      name: BOUNDARY PROTECTION | ROUTE TRAFFIC TO AUTHENTICATED PROXY SERVERS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1241
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7(8)
      description: Route all internal communications traffic that may be proxied,
        except traffic specifically exempted by organizational personnel with information
        security responsibilities, to all untrusted networks through authenticated
        proxy servers at managed interfaces.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1242
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7(8)
      description: "Discussion: External networks are networks outside of organizational\
        \ control. A proxy server is a server (i.e., system or application) that acts\
        \ as an intermediary for clients requesting system resources from non-organizational\
        \ or other organizational servers. System resources that may be requested\
        \ include files, connections, web pages, or services. Client requests established\
        \ through a connection to a proxy server are assessed to manage complexity\
        \ and provide additional protection by limiting direct connectivity. Web content\
        \ filtering devices are one of the most common proxy servers that provide\
        \ access to the Internet. Proxy servers can support the logging of Transmission\
        \ Control Protocol sessions and the blocking of specific Uniform Resource\
        \ Locators, Internet Protocol addresses, and domain names. Web proxies can\
        \ be configured with organization-defined lists of authorized and unauthorized\
        \ websites. Note that proxy servers may inhibit the use of virtual private\
        \ networks (VPNs) and create the potential for \u201Cman-in-the-middle\u201D\
        \ attacks (depending on the implementation).\nRelated Controls: AC-3."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7(24)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7
      ref_id: SC-7(24)
      name: BOUNDARY PROTECTION | PERSONALLY IDENTIFIABLE INFORMATION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1244
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7(24)
      description: 'For systems that process personally identifiable information:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7(24)-a
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1244
      ref_id: SC-7(24)-a
      description: 'Apply the following processing rules to data elements of personally
        identifiable information: all applicable laws, executive orders, directives,
        regulations, policies, standards, and guidelines;'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7(24)-b
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1244
      ref_id: SC-7(24)-b
      description: Monitor for permitted processing at the external interfaces to
        the system and at key internal boundaries within the system
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7(24)-c
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1244
      ref_id: SC-7(24)-c
      description: Document each processing exception; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7(24)-d
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1244
      ref_id: SC-7(24)-d
      description: Review and remove exceptions that are no longer supported.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1249
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-7(24)
      description: "Discussion: Managing the processing of personally identifiable\
        \ information is an important aspect of protecting an individual\u2019s privacy.\
        \ Applying, monitoring for, and documenting exceptions to processing rules\
        \ ensure that personally identifiable information is processed only in accordance\
        \ with established privacy requirements.\nRelated Controls: None."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-8
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.10
      ref_id: SC-8
      name: TRANSMISSION CONFIDENTIALITY AND INTEGRITY
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1251
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-8
      description: Protect the confidentiality and integrity of transmitted information.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1252
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-8
      description: Metadata derived from unencrypted CJI shall be protected in the
        same manner as CJI and shall not be used for any advertising or other commercial
        purposes by any cloud service provider or other associated entity.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1253
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-8
      description: "Discussion: Protecting the confidentiality and integrity of transmitted\
        \ information applies to internal and external networks as well as any system\
        \ components that can transmit information, including servers, notebook computers,\
        \ desktop computers, mobile devices, printers, copiers, scanners, facsimile\
        \ machines, and radios. Unprotected communication paths are exposed to the\
        \ possibility of interception and modification. Protecting the confidentiality\
        \ and integrity of information can be accomplished by physical or logical\
        \ means. Physical protection can be achieved by using protected distribution\
        \ systems. A protected distribution system is a wireline or fiber-optics telecommunications\
        \ system that includes terminals and adequate electromagnetic, acoustical,\
        \ electrical, and physical controls to permit its use for the unencrypted\
        \ transmission of classified information. Logical protection can be achieved\
        \ by employing encryption techniques. Organizations that rely on commercial\
        \ providers who offer transmission services as commodity services rather than\
        \ as fully dedicated services may find it difficult to obtain the necessary\
        \ assurances regarding the implementation of needed controls for transmission\
        \ confidentiality and integrity. In such situations, organizations determine\
        \ what types of confidentiality or integrity services are available in standard,\
        \ commercial telecommunications service packages. If it is not feasible to\
        \ obtain the necessary controls and assurances of control effectiveness through\
        \ appropriate contracting vehicles, organizations can implement appropriate\
        \ compensating controls. The agency may permit limited use of metadata derived\
        \ from unencrypted CJI when specifically approved by the agency and its \u201C\
        intended use\u201D is detailed within the service agreement. Such authorized\
        \ uses of metadata may include but are not limited to the following: spam\
        \ and spyware filtering, data loss prevention, spillage reporting, transaction\
        \ logs (events and content\u2013similar to the AU controls), data usage/indexing\
        \ metrics, and diagnostic/syslog data. \nRelated Controls: AC-17, AC-18, IA-3,\
        \ IA-8, MA-4, PE-4, SA-4, SA-8, SC-7, SC-20, SC-23, SC28."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-8(1)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-8
      ref_id: SC-8(1)
      name: TRANSMISSION CONFIDENTIALITY AND INTEGRITY | CRYPTOGRAPHIC PROTECTION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1255
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-8(1)
      description: Implement cryptographic mechanisms to prevent unauthorized disclosure
        and detect unauthorized changes or access to CJI during transmission.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1256
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-8(1)
      description: 'Discussion: Encryption protects information from unauthorized
        disclosure and modification during transmission. Cryptographic mechanisms
        that protect the confidentiality and integrity of information during transmission
        include TLS and IPSec. Cryptographic mechanisms used to protect information
        integrity include cryptographic hash functions that have applications in digital
        signatures, checksums, and message authentication codes.

        Related Controls: SC-12, SC-13.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-10
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.10
      ref_id: SC-10
      name: NETWORK DISCONNECT
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1258
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-10
      description: 'Terminate the network connection associated with a communications
        session at the end of the session or after one (1) hour of inactivity.

        NOTE: In the interest of safety, devices that are: (1) part of a criminal
        justice conveyance; or (2) used to perform dispatch functions and located
        within a physically secure location; or (3) terminals designated solely for
        the purpose of receiving alert notifications (i.e., receive only terminals
        or ROT) and used within physically secure location facilities that remain
        staffed when in operation, are exempt from this requirement.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1259
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-10
      description: 'Discussion: Network disconnect applies to internal and external
        networks. Terminating network connections associated with specific communications
        sessions includes de-allocating TCP/IP address or port pairs at the operating
        system level and de-allocating the networking assignments at the application
        level if multiple application sessions are using a single operating system-level
        network connection. Periods of inactivity may be established by organizations
        and include time periods by type of network access or for specific network
        accesses.

        Related Controls: AC-17, SC-23.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-12
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.10
      ref_id: SC-12
      name: CRYPTOGRAPHIC KEY ESTABLISHMENT AND MANAGEMENT
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1261
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-12
      description: 'Establish and manage cryptographic keys when cryptography is employed
        within the system in accordance with the following key management requirements:
        encryption key generation, distribution, storage, access, and destruction
        is controlled by the agency.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1262
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-12
      description: 'Discussion: Cryptographic key management and establishment can
        be performed using manual procedures or automated mechanisms with supporting
        manual procedures. Organizations define key management requirements in accordance
        with applicable laws, executive orders, directives, regulations, policies,
        standards, and guidelines and specify appropriate options, parameters, and
        levels. Organizations manage trust stores to ensure that only approved trust
        anchors are part of such trust stores. This includes certificates with visibility
        external to organizational systems and certificates related to the internal
        operations of systems. [NIST CMVP] and [NIST CAVP] provide additional information
        on validated cryptographic modules and algorithms that can be used in cryptographic
        key management and establishment.

        Related Controls: AC-17, AU-9, CM-3, IA-3, IA-7, SA-4, SA-8, SA-9, SC-8, SC-12,
        SC-13, SC17, SC-20, SI-3, SI-7.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-13
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.10
      ref_id: SC-13
      name: CRYPTOGRAPHIC PROTECTION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-13-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-13
      ref_id: SC-13-a
      description: Determine the use of encryption for CJI in-transit when outside
        a physically secure location; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-13-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-13
      ref_id: SC-13-b
      description: 'Implement the following types of cryptography required for each
        specified cryptographic use: cryptographic modules which are Federal Information
        Processing Standard (FIPS) 140-3 certified, or FIPS validated algorithm for
        symmetric key encryption and decryption (FIPS 197 [AES]), with a symmetric
        cipher key of at least 128-bit strength for CJI intransit.

        NOTE: Subsequent versions of approved cryptographic modules that are under
        current review for FIPS 140-3 compliancy can be used in the interim until
        certification is complete.FIPS 1402 certificates will not be acceptable after
        September 21, 2026.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1266
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-13
      description: 'Discussion: Cryptography can be employed to support a variety
        of security solutions, including the protection of classified information
        and controlled unclassified information, the provision and implementation
        of digital signatures, and the enforcement of information separation when
        authorized individuals have the necessary clearances but lack the necessary
        formal access approvals. Cryptography can also be used to support random number
        and hash generation. Generally applicable cryptographic standards include
        FIPS-validated cryptography and NSAapproved cryptography. For example, organizations
        that need to protect classified information may specify the use of NSA-approved
        cryptography. Organizations that need to provision and implement digital signatures
        may specify the use of FIPS-validated cryptography. Cryptography is implemented
        in accordance with applicable laws, executive orders, directives, regulations,
        policies, standards, and guidelines.

        Related Controls: AC-2, AC-3, AC-7, AC-17, AC-18, AC-19, AU-9, CM-11, CP-9,
        IA-3, IA-5, IA-7, MA-4, MP-2, MP-4, MP-5, SA-4, SA-8, SA-9, SC-8, SC-12, SC-20,
        SC-23, SC-28, SI-3, SI-7.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-15
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.10
      ref_id: SC-15
      name: COLLABORATIVE COMPUTING DEVICES AND APPLICATIONS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-15-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-15
      ref_id: SC-15-a
      description: Prohibit remote activation of collaborative computing devices and
        applications; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-15-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-15
      ref_id: SC-15-b
      description: Provide an explicit indication of use to users physically present
        at the devices.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1270
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-15
      description: 'Discussion: Collaborative computing devices and applications include
        remote meeting devices and applications, networked white boards, cameras,
        and microphones. The explicit indication of use includes signals to users
        when collaborative computing devices and applications are activated.

        Related Controls: AC-21.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-17
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.10
      ref_id: SC-17
      name: PUBLIC KEY INFRASTRUCTURE CERTIFICATES
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-17-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-17
      ref_id: SC-17-a
      description: Issue public key certificates under an agency-level certificate
        authority or obtain public key certificates from an approved service provider;
        and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-17-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-17
      ref_id: SC-17-b
      description: Include only approved trust anchors in trust stores or certificate
        stores managed by the organization.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1274
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-17
      description: 'Discussion: Public key infrastructure (PKI) certificates are certificates
        with visibility external to organizational systems and certificates related
        to the internal operations of systems, such as application-specific time services.
        In cryptographic systems with a hierarchical structure, a trust anchor is
        an authoritative source (i.e., a certificate authority) for which trust is
        assumed and not derived. A root certificate for a PKI system is an example
        of a trust anchor. A trust store or certificate store maintains a list of
        trusted root certificates.

        Related Controls: IA-5, SC-12.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-18
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.10
      ref_id: SC-18
      name: MOBILE CODE
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-18-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-18
      ref_id: SC-18-a
      description: Define acceptable and unacceptable mobile code and mobile code
        technologies; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-18-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-18
      ref_id: SC-18-b
      description: Authorize, monitor, and control the use of mobile code within the
        system.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1278
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-18
      description: 'Discussion: Mobile code includes any program, application, or
        content that can be transmitted across a network (e.g., embedded in an email,
        document, or website) and executed on a remote system. Decisions regarding
        the use of mobile code within organizational systems are based on the potential
        for the code to cause damage to the systems if used maliciously. Mobile code
        technologies include Java applets, JavaScript, HTML5, WebGL, and VBScript.
        Usage restrictions and implementation guidelines apply to both the selection
        and use of mobile code installed on servers and mobile code downloaded and
        executed on individual workstations and devices, including notebook computers
        and smart phones. Mobile code policy and procedures address specific actions
        taken to prevent the development, acquisition, and introduction of unacceptable
        mobile code within organizational systems, including requiring mobile code
        to be digitally signed by a trusted source.

        Related Controls: AU-2, AU-12, CM-2, CM-6, SI-3.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-20
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.10
      ref_id: SC-20
      name: SECURE NAME/ADDRESS RESOLUTION SERVICE (AUTHORITATIVE SOURCE)
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-20-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-20
      ref_id: SC-20-a
      description: Provide additional data origin authentication and integrity verification
        artifacts along with the authoritative name resolution data the system returns
        in response to external name/address resolution queries; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-20-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-20
      ref_id: SC-20-b
      description: Provide the means to indicate the security status of child zones
        and (if the child supports secure resolution services) to enable verification
        of a chain of trust among parent and child domains, when operating as part
        of a distributed, hierarchical namespace.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1282
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-20
      description: 'Discussion: Providing authoritative source information enables
        external clients, including remote Internet clients, to obtain origin authentication
        and integrity verification assurances for the host/service name to network
        address resolution information obtained through the service. Systems that
        provide name and address resolution services include domain name system (DNS)
        servers. Additional artifacts include DNS Security Extensions (DNSSEC) digital
        signatures and cryptographic keys. Authoritative data includes DNS resource
        records. The means for indicating the security status of child zones include
        the use of delegation signer resource records in the DNS. Systems that use
        technologies other than the DNS to map between host and service names and
        network addresses provide other means to assure the authenticity and integrity
        of response data.

        Related Controls: SC-8, SC-12, SC-13, SC-21, SC-22.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-21
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.10
      ref_id: SC-21
      name: SECURE NAME/ADDRESS RESOLUTION SERVICE (RECURSIVE OR CACHING RESOLVER)
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1284
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-21
      description: Request and perform data origin authentication and data integrity
        verification on the name/address resolution responses the system receives
        from authoritative sources.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1285
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-21
      description: 'Discussion: Each client of name resolution services either performs
        this validation on its own or has authenticated channels to trusted validation
        providers. Systems that provide name andaddress resolution services for local
        clients include recursive resolving or caching domain name system (DNS) servers.
        DNS client resolvers either perform validation of DNSSEC signatures, or clients
        use authenticated channels to recursive resolvers that perform such validations.
        Systems that use technologies other than the DNS to map between host and service
        names and network addresses provide some other means to enable clients to
        verify the authenticity and integrity of response data.

        Related Controls: SC-20, SC-22.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-22
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.10
      ref_id: SC-22
      name: ARCHITECTURE AND PROVISIONING FOR NAME/ADDRESS RESOLUTION SERVICE
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1287
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-22
      description: Ensure the systems that collectively provide name/address resolution
        service for an organization are fault-tolerant and implement internal and
        external role separation.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1288
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-22
      description: "Discussion: Systems that provide name and address resolution services\
        \ include domain name system (DNS) servers. To eliminate single points of\
        \ failure in systems and enhance redundancy, organizations employ at least\
        \ two authoritative domain name system servers\u2014one configured as the\
        \ primary server and the other configured as the secondary server. Additionally,\
        \ organizations typically deploy the servers in two geographically separated\
        \ network subnetworks (i.e., not located in the same physical facility). For\
        \ role separation, DNS servers with internal roles only process name and address\
        \ resolution requests from within organizations (i.e., from internal clients).\
        \ DNS servers with external roles only process name and address resolution\
        \ information requests from clients external to organizations (i.e., on external\
        \ networks, including the Internet). Organizations specify clients that can\
        \ access authoritative DNS servers in certain roles (e.g., by address ranges\
        \ and explicit lists).\nRelated Controls: SC-2, SC-20, SC-21."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-23
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.10
      ref_id: SC-23
      name: SESSION AUTHENTICITY
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1290
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-23
      description: Protect the authenticity of communications sessions.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1291
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-23
      description: "Discussion: Protecting session authenticity addresses communications\
        \ protection at the session level, not at the packet level. Such protection\
        \ establishes grounds for confidence at both ends of communications sessions\
        \ in the ongoing identities of other parties and the validity of transmitted\
        \ information. Authenticity protection includes protecting against \u201C\
        man-in-the-middle\u201D attacks, session hijacking, and the insertion of false\
        \ information into sessions.\nRelated Controls: SC-8, SC-10."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-28
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.10
      ref_id: SC-28
      name: PROTECTION OF INFORMATION AT REST
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1293
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-28
      description: "Protect the confidentiality and integrity of the following information\
        \ at rest: CJI when outside physically secure locations using cryptographic\
        \ modules which are certified FIPS 140-3 with a symmetric cipher key of at\
        \ least 128-bit strength, or FIPS 197 with a symmetric cipher key of at least\
        \ 256-bit strength.\nMetadata derived from unencrypted CJI shall be protected\
        \ in the same manner as CJI and shall not be used for any advertising or other\
        \ commercial purposes by any cloud service provider or other associated entity.\
        \ \nThe storage of CJI, regardless of encryption status, shall only be permitted\
        \ in cloud environments (e.g., government or third-party/commercial datacenters,\
        \ etc.) which reside within the physical boundaries of APB-member country\
        \ (i.e., United States, U.S. territories, Indian Tribes, and Canada) and are\
        \ under legal authority of an APB-member agency (i.e., United States\u2013\
        federal/state/territory, Indian Tribe, or the Royal Canadian Mounted Police).\
        \ \nNote: This restriction does not apply to exchanges of CJI with foreign\
        \ government agencies under international exchange agreements (e.g., the Preventing\
        \ and Combating Serious Crime agreements, fugitive extracts, and exchanges\
        \ made for humanitarian and criminal investigatory purposes in particular\
        \ circumstances)."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1294
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-28
      description: "Discussion: Information at rest refers to the state of information\
        \ when it is not in process or in transit and is located on system components.\
        \ Such components include internal or external hard disk drives, storage area\
        \ network devices, or databases. However, the focus of protecting information\
        \ at rest is not on the type of storage device or frequency of access but\
        \ rather on the state of the information. Information at rest addresses the\
        \ confidentiality and integrity of information and covers user information\
        \ and system information. System-related information that requires protection\
        \ includes configurations or rule sets for firewalls, intrusion detection\
        \ and prevention systems, filtering routers, and authentication information.\
        \ Organizations may employ different mechanisms to achieve confidentiality\
        \ and integrity protections, including the use of cryptographic mechanisms\
        \ and file share scanning. Integrity protection can be achieved, for example,\
        \ by implementing write-once-read-many (WORM) technologies. When adequate\
        \ protection of information at rest cannot otherwise be achieved, organizations\
        \ may employ other controls, including frequent scanning to identify malicious\
        \ code at rest and secure offline storage in lieu of online storage. The agency\
        \ may permit limited use of metadata derived from unencrypted CJI when specifically\
        \ approved by the agency and its \u201Cintended use\u201D is detailed within\
        \ the service agreement. Such authorized uses of metadata may include but\
        \ are not limited to the following: spam and spyware filtering, data loss\
        \ prevention, spillage reporting, transaction logs (events and content\u2013\
        similar to the AU controls), data usage/indexing metrics, and diagnostic/syslog\
        \ data. \nRelated Controls: AC-3, AC-4, AC-6, AC-19, CA-7, CM-3, CM-5, CM-6,\
        \ CP-9, MP-4, MP-5, PE-3, SC-8, SC-12, SC-13, SI-3, SI-7, SI-16."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-28(1)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-28
      ref_id: SC-28(1)
      name: PROTECTION OF INFORMATION AT REST | CRYPTOGRAPHIC PROTECTION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1296
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-28(1)
      description: Implement cryptographic mechanisms to prevent unauthorized disclosure
        and modification of the following information at rest on information systems
        and digital media outside physically secure locations:CJI.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1297
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-28(1)
      description: 'Discussion: The selection of cryptographic mechanisms is based
        on the need to protect the confidentiality and integrity of organizational
        information. The strength of mechanism is commensurate with the security category
        or classification of the information. Organizations have the flexibility to
        encrypt information on system components or media or encrypt data structures,
        including files, records, or fields.

        Related Controls: AC-19, SC-12, SC-13.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-39
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.10
      ref_id: SC-39
      name: PROCESS ISOLATION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1299
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-39
      description: Maintain a separate execution domain for each executing system
        process.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1300
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sc-39
      description: 'Discussion: Systems can maintain separate execution domains for
        each executing process by assigning each process a separate address space.
        Each system process has a distinct address space so that communication between
        processes is performed in a manner controlled through the security functions,
        and one process cannot modify the executing code of another process. Maintaining
        separate execution domains for executing processes can be achieved, for example,
        by implementing separate address spaces. Process isolation technologies, including
        sandboxing or virtualization, logically separate software and firmware from
        other software, firmware, and data. Process isolation helps limit the access
        of potentially untrusted software to other system resources. The capability
        to maintain separate execution domains is available in commercial operating
        systems that employ multi-state processor technologies.

        Related Controls: AC-3, AC-4, AC-6, SA-8, SC-2, SI-16.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.11
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5
      ref_id: '5.11'
      name: 'Policy Area 11: Formal Audits'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.11.1
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.11
      ref_id: 5.11.1
      name: Audits by the FBI CJIS Division
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.11.1.1
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.11.1
      ref_id: 5.11.1.1
      name: Triennial Compliance Audits by the FBI CJIS Division
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1304
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.11.1.1
      description: The FBI CJIS Division is authorized to conduct audits, once every
        three (3) years as a minimum, to assess agency compliance with applicable
        statutes, regulations and policies.The CJIS Audit Unit (CAU) shall conduct
        a triennial audit of each CSA in order to verify compliance with applicable
        statutes, regulations and policies.This audit shall include a sample of CJAs
        and, in coordination with the SIB, the NCJAs.Audits may be conducted on a
        more frequent basis if the audit reveals that an agency has not complied with
        applicable statutes, regulations and policies.The FBI CJIS Division shall
        also have the authority to conduct unannounced security inspections and scheduled
        audits of Contractor facilities.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.11.1.2
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.11.1
      ref_id: 5.11.1.2
      name: Triennial Security Audits by the FBI CJIS Division
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1306
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.11.1.2
      description: The FBI CJIS Division is authorized to conduct security audits
        of the CSA and SIB networks and systems, once every three (3) years as a minimum,
        to assess agency compliance with the CJIS Security Policy.This audit shall
        include a sample of CJAs and NCJAs.Audits may be conducted on a more frequent
        basis if the audit reveals that an agency has not complied with the CJIS Security
        Policy.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.11.2
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.11
      ref_id: 5.11.2
      name: Audits by the CSA
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1308
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.11.2
      description: 'Each CSA shall:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.11.2-1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.11.2
      ref_id: 5.11.2-1
      description: At a minimum, triennially audit all CJAs and NCJAs which have direct
        access to the state system in order to ensure compliance with applicable statutes,
        regulations and policies.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.11.2-2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.11.2
      ref_id: 5.11.2-2
      description: In coordination with the SIB, establish a process to periodically
        audit all NCJAs, with access to CJI, in order to ensure compliance with applicable
        statutes, regulations and policies.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.11.2-3
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.11.2
      ref_id: 5.11.2-3
      description: Have the authority to conduct unannounced security inspections
        and scheduled audits of Contractor facilities.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.11.2-4
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.11.2
      ref_id: 5.11.2-4
      description: 'Have the authority, on behalf of another CSA, to conduct a CSP
        compliance audit of contractor facilities and provide the results to the requesting
        CSA. If a subsequent CSA requests an audit of the same contractor facility,
        the CSA may provide the results of the previous audit unless otherwise notified
        by the requesting CSA that a new audit be performed.

        Note: This authority does not apply to the audit requirement outlined in the
        Security and Management Control Outsourcing Standard for Non-Channeler and
        Channelers related to outsourcing noncriminal justice administrative functions.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.11.3
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.11
      ref_id: 5.11.3
      name: Special Security Inquiries and Audits
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1314
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.11.3
      description: All agencies having access to CJI shall permit an inspection team
        to conduct an appropriate inquiry and audit of any alleged security violations.The
        inspection team shall be appointed by the APB and shall include at least one
        representative of the CJIS Division. All results of the inquiry and audit
        shall be reported to the APB with appropriate recommendations.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.11.4
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.11
      ref_id: 5.11.4
      name: Compliance Subcommittees
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1316
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.11.4
      description: The Criminal Justice Information Services (CJIS) Advisory Policy
        Board (APB) established the Compliance Evaluation (CE) Subcommittee to evaluate
        the results of audits conducted by the CJIS Audit Unit (CAU). The CE Subcommittee
        makes specific recommendations to the APB concerning compliance with applicable
        policies and regulations. The most current information regarding the CAU audits
        that are within the purview of the CE Subcommittee and detailed CE Subcommittee
        sanctions process procedures are available at CJIS.gov (Law Enforcement Enterprise
        Portal) CJIS Special Interest Groups CE Subcommittee Section and CJIS Section
        of FBI.gov.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1317
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.11.4
      description: "The National Crime Prevention and Privacy Compact (Compact) Council\
        \ at Article VI established the Compact Council (Council). The Compact Council\
        \ Sanctions Committee is responsible for ensuring the use of the Interstate\
        \ Identification Index System for noncriminal justice purposes complies with\
        \ the Compact and with rules, standards, and procedures established by the\
        \ Compact Council. As such, the Sanctions Committee reviews the results of\
        \ audits conducted by the Federal \nBureau of Investigation (FBI) of participants\
        \ in the FBI\u2019s Criminal Justice Services (CJIS) Division programs. The\
        \ Sanctions Committee reviews the audit results and the participant\u2019\
        s response to determine a course of action necessary to bring the participant\
        \ into compliance and make recommendations to the Compact Council or the FBI.\
        \ Additional information on the Compact Council Sanctions process is available\
        \ on the Compact Council\u2019s web-site."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.12
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5
      ref_id: '5.12'
      name: 'Policy Area 12: Personnel Security'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.12.1
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.12
      ref_id: 5.12.1
      name: Personnel Screening Requirements for Individuals Requiring Unescorted
        Access to Unencrypted CJI
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.12.1-1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.12.1
      ref_id: 5.12.1-1
      description: 'To verify identification, state of residency and national fingerprint-based
        record checks shall be conducted prior to granting access to CJI for all personnel
        who have unescorted access to unencrypted CJI or unescorted access to physically
        secure locations or controlled areas (during times of CJI processing).However,
        if the person resides in a different state than that of the assigned agency,
        the agency shall conduct state (of the agency) and national fingerprint-based
        record checks and execute a NLETS CHRI IQ/FQ/AQ query using purpose code C,
        E, or J depending on the circumstances.When appropriate, the screening shall
        be consistent with:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.12.1-1-a
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.12.1-1
      ref_id: 5.12.1-1-a
      description: 5 CFR 731.106; and/or
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.12.1-1-b
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.12.1-1
      ref_id: 5.12.1-1-b
      description: Office of Personnel Management policy, regulations, and guidance;
        and/or
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.12.1-1-c
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.12.1-1
      ref_id: 5.12.1-1-c
      description: agency policy, regulations, and guidance.
      annotation: "Supplemental Guidance: \na.\tFederal entities bypassing state repositories\
        \ in compliance with federal law may not be required to conduct a state fingerprint-based\
        \ record check. \nb.\tSee Appendix J for applicable guidance regarding noncriminal\
        \ justice agencies performing adjudication of civil fingerprint submissions.\
        \ \nc.\tFingerprint-based record checks may not be required for all cloud\
        \ provider personnel depending upon the type of service offering and access\
        \ to encryption keys. \nd.\tSee Appendix G.3 for guidance on personnel screening\
        \ requirements specific to cloud environments."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.12.1-2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.12.1
      ref_id: 5.12.1-2
      description: All requests for access shall be made as specified by the CSO.The
        CSO, or their designee, is authorized to approve access to CJI.All CSO designees
        shall be from an authorized criminal justice agency.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.12.1-3
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.12.1
      ref_id: 5.12.1-3
      description: If a record of any kind exists, access to CJI shall not be granted
        until the CSO or his/her designee reviews the matter to determine if access
        is appropriate.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.12.1-3-a
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.12.1-3
      ref_id: 5.12.1-3-a
      description: If a felony conviction of any kind exists, the Interface Agency
        shall deny access to CJI. However, the Interface Agency may ask for a review
        by the CSO in extenuating circumstances where the severity of the offense
        and the time that has passed would support a possible variance.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.12.1-3-b
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.12.1-3
      ref_id: 5.12.1-3-b
      description: Applicants with a record of misdemeanor offense(s) may be granted
        access if the CSO, or his or her designee, determines the nature or severity
        of the misdemeanor offense(s) do not warrant disqualification. The Interface
        Agency may request the CSO review a denial of access determination. This same
        procedure applies if the person is found to be a fugitive or has an arrest
        history without conviction.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.12.1-3-c
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.12.1-3
      ref_id: 5.12.1-3-c
      description: "If a record of any kind is found on a contractor, the CGA shall\
        \ be formally notified and system access shall be delayed pending review of\
        \ the criminal history record information.The CGA shall in turn notify the\
        \ contractor\u2019s security officer."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.12.1-4
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.12.1
      ref_id: 5.12.1-4
      description: If the person appears to be a fugitive or has an arrest history
        without conviction, the CSO or his/her designee shall review the matter to
        determine if access to CJI is appropriate.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.12.1-5
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.12.1
      ref_id: 5.12.1-5
      description: If the person already has access to CJI and is subsequently arrested
        and or convicted, continued access to CJI shall be determined by the CSO.This
        does not implicitly grant hiring/firing authority with the CSA, only the authority
        to grant access to CJI. For offenses other than felonies, the CSO has the
        latitude to delegate continued access determinations to his or her designee.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.12.1-6
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.12.1
      ref_id: 5.12.1-6
      description: If the CSO or his/her designee determines that access to CJI by
        the person would not be in the public interest, access shall be denied and
        the person's appointing authority shall be notified in writing of the access
        denial.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.12.1-7
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.12.1
      ref_id: 5.12.1-7
      description: The granting agency shall maintain a list of personnel who have
        been authorized unescorted access to unencrypted CJI and shall, upon request,
        provide a current copy of the access list to the CSO.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1333
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.12.1
      description: It is recommended individual background re-investigations be conducted
        every five years unless Rap Back is implemented.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.12.2
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.12
      ref_id: 5.12.2
      name: Personnel Termination
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1335
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.12.2
      description: Upon termination of personnel by an interface agency, the agency
        shall immediately terminate access to local agency systems with access to
        CJI. Furthermore, the interface agency shall provide notification or other
        action to ensure access to state and other agency systems is terminated. If
        the employee is an employee of a NCJA or a Contractor, the employer shall
        notify all Interface Agencies that may be affected by the personnel change.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.12.3
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.12
      ref_id: 5.12.3
      name: Personnel Transfer
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1337
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.12.3
      description: The agency shall review CJI access authorizations when personnel
        are reassigned or transferred to other positions within the agency and initiate
        appropriate actions such as closing and establishing accounts and changing
        system access authorizations.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.12.4
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.12
      ref_id: 5.12.4
      name: Personnel Sanctions
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1339
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.12.4
      description: The agency shall employ a formal sanctions process for personnel
        failing to comply with established information security policies and procedures.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5
      ref_id: '5.13'
      name: 'Policy Area 13: Mobile Devices'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1341
      assessable: true
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13
      description: "This policy area describes considerations and requirements for\
        \ mobile devices including smartphones and tablets.Mobile devices are not\
        \ limited to a single form factor or communications medium.The requirements\
        \ in this section augment those in other areas of the Policy to address the\
        \ gaps introduced by using mobile devices. \nThe agency shall: (i) establish\
        \ usage restrictions and implementation guidance for mobile devices; and (ii)\
        \ authorize, monitor, control wireless access to the information system. Wireless\
        \ technologies, in the simplest sense, enable one or more devices to communicate\
        \ without physical connections\u2014without requiring network or peripheral\
        \ cabling. \nAppendix G provides reference material and additional information\
        \ on mobile devices."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13
      ref_id: 5.13.1
      name: Wireless Communications Technologies
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.1
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1
      ref_id: 5.13.1.1
      name: 802.11 Wireless Protocols
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1344
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.1
      description: Wired Equivalent Privacy (WEP) and Wi-Fi Protected Access (WPA)
        cryptographic algorithms, used by all pre-802.11i protocols, do not meet the
        requirements for FIPS 140-2 and shall not be used.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1345
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.1
      description: "Agencies shall implement the following controls for all agency-managed\
        \ wireless access points with access to an agency\u2019s network that processes\
        \ unencrypted CJI:"
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.1-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.1
      ref_id: 5.13.1.1-1
      description: Perform validation testing to ensure rogue APs (Access Points)
        do not exist in the 802.11 Wireless Local Area Network (WLAN) and to fully
        understand the wireless network security posture.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.1-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.1
      ref_id: 5.13.1.1-2
      description: Maintain a complete inventory of all Access Points (APs) and 802.11
        wireless devices.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.1-3
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.1
      ref_id: 5.13.1.1-3
      description: Place APs in secured areas to prevent unauthorized physical access
        and user manipulation.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.1-4
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.1
      ref_id: 5.13.1.1-4
      description: Test AP range boundaries to determine the precise extent of the
        wireless coverage and design the AP wireless coverage to limit the coverage
        area to only what is needed for operational purposes.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.1-5
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.1
      ref_id: 5.13.1.1-5
      description: Enable user authentication and encryption mechanisms for the management
        interface of the AP
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.1-6
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.1
      ref_id: 5.13.1.1-6
      description: Ensure that all APs have strong administrative passwords and ensure
        that all passwords are changed in accordance with Section 5.6.2.1.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.1-7
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.1
      ref_id: 5.13.1.1-7
      description: Ensure the reset function on APs is used only when needed and is
        only invoked by authorized personnel.Restore the APs to the latest security
        settings, when the reset functions are used, to ensure the factory default
        settings are not utilized.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.1-8
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.1
      ref_id: 5.13.1.1-8
      description: Change the default service set identifier (SSID) in the APs.Disable
        the broadcast SSID feature so that the client SSID must match that of the
        AP. Validate that the SSID character string does not contain any agency identifiable
        information (division, department, street, etc.) or services.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.1-9
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.1
      ref_id: 5.13.1.1-9
      description: Enable all security features of the wireless product, including
        the cryptographic authentication, firewall, and other available privacy features.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.1-10
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.1
      ref_id: 5.13.1.1-10
      description: Ensure that encryption key sizes are at least 128-bits and the
        default shared keys are replaced by unique keys
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.1-11
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.1
      ref_id: 5.13.1.1-11
      description: Ensure that the ad hoc mode has been disabled.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.1-12
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.1
      ref_id: 5.13.1.1-12
      description: Disable all nonessential management protocols on the APs.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.1-13
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.1
      ref_id: 5.13.1.1-13
      description: Ensure all management access and authentication occurs via FIPS
        compliant secure protocols (e.g., SFTP, HTTPS, SNMP over TLS, etc.). Disable
        non-FIPS compliant secure access to the management interface.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.1-14
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.1
      ref_id: 5.13.1.1-14
      description: Enable logging (if supported) and review the logs on a recurring
        basis per local policy.At a minimum, logs shall be reviewed monthly.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.1-15
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.1
      ref_id: 5.13.1.1-15
      description: Insulate, virtually (e.g., virtual local area network (VLAN) and
        ACLs) or physically (e.g., firewalls), the wireless network from the operational
        wired infrastructure.Limit access between wireless networks and the wired
        network to only operational needs.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.1-16
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.1
      ref_id: 5.13.1.1-16
      description: When disposing of access points that will no longer be used by
        the agency, clear access point configuration to prevent disclosure of network
        configuration, keys, passwords, etc.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.2
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1
      ref_id: 5.13.1.2
      name: Cellular Devices
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.2.1
      assessable: false
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.2
      ref_id: 5.13.1.2.1
      name: Cellular Service Abroad
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1364
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.2
      description: "Certain internal functions on cellular devices may be modified\
        \ or compromised by the cellular carrier during international use as the devices\
        \ are intended to have certain parameters configured by the cellular provider\
        \ which is considered a \u201Ctrusted\u201D entity by the device.\nWhen devices\
        \ are authorized to access CJI outside the U.S., agencies shall perform an\
        \ inspection to ensure that all controls are in place and functioning properly\
        \ in accordance with the agency\u2019s policies prior to and after deployment\
        \ outside of the U.S."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.2.2
      assessable: false
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.2
      ref_id: 5.13.1.2.2
      name: Voice Transmissions Over Cellular Devices
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1366
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.2
      description: Any cellular device used to transmit CJI via voice is exempt from
        the encryption and authentication requirements.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.3
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1
      ref_id: 5.13.1.3
      name: Bluetooth
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1368
      assessable: false
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.3
      description: Bluetooth is an open standard for short-range radio frequency (RF)
        communication. Bluetooth is used primarily to establish wireless personal
        area networks (WPAN).Bluetooth technology has been integrated into many types
        of business and consumer devices, including cell phones, laptops, automobiles,
        medical devices, printers, keyboards, mice, headsets, and biometric capture
        devices.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1369
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.3
      description: "Bluetooth technology and associated devices are susceptible to\
        \ general wireless networking threats (e.g., denial of service [DoS] attacks,\
        \ eavesdropping, man-in-the-middle [MITM] attacks, message modification, and\
        \ resource misappropriation) as well as specific Bluetooth-related attacks\
        \ that target known vulnerabilities in Bluetooth implementations and specifications.Organizational\
        \ security policy shall be used to dictate the use of Bluetooth and its associated\
        \ devices based on the agency\u2019s operational and business processes."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.4
      assessable: false
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.3
      ref_id: 5.13.1.4
      name: Mobile Hotspots
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1371
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.4
      description: 'Many mobile devices include the capability to function as a Wi-Fi
        hotspot that allows other devices to connect through the device to the internet
        over the devices cellular network.

        When an agency allows mobile devices that are approved to access or store
        CJI to function as a Wi-Fi hotspot connecting to the Internet, they shall
        be configured:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.4-1
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.4
      ref_id: 5.13.1.4-1
      description: Enable encryption on the hotspot
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.4-2
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.4
      ref_id: 5.13.1.4-2
      description: "Change the hotspot\u2019s default SSID"
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.4-2-a
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.4-2
      ref_id: 5.13.1.4-2-a
      description: Ensure the hotspot SSID does not identify the device make/model
        or agency ownership
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.4-3
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.4
      ref_id: 5.13.1.4-3
      description: Create a wireless network password (pre-shared key)
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.4-4
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.4
      ref_id: 5.13.1.4-4
      description: "Enable the hotspot\u2019s port filtering/blocking features if\
        \ present"
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.4-5
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.4
      ref_id: 5.13.1.4-5
      description: "Only allow connections from agency-controlled devices \nNote:\
        \ Refer to the requirements in Section 5.10.1.2 Encryption for item #1. Refer\
        \ to the requirements in Section 5.6.2.1.1.1 Basic Password Standards for\
        \ item #3. Only password attributes #1, #2 and #3 are required."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1378
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.4
      description: OR
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1379
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.1.4
      description: "Have a MDM solution to provide the same security as identified\
        \ in items 1 \u2013 5 above."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.2
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13
      ref_id: 5.13.2
      name: Mobile Device Management (MDM)
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1381
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.2
      description: Mobile Device Management (MDM) facilitates the implementation of
        sound security controls for mobile devices and allows for centralized oversight
        of configuration control, application usage, and device protection and recovery,
        if so desired by the agency.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1382
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.2
      description: Due to the potential for inconsistent network access or monitoring
        capability on mobile devices, methods used to monitor and manage the configuration
        of full-featured operating systems may not function properly on devices with
        limited-feature operating systems.MDM systems and applications coupled with
        device specific technical policy can provide a robust method for device configuration
        management if properly implemented.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1383
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.2
      description: 'Devices that have had any unauthorized changes made to them (including
        but not limited to being rooted or jailbroken) shall not be used to process,
        store, or transmit CJI data at any time.User agencies shall implement the
        following controls when directly accessing CJI from devices running a limited-feature
        operating system:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.2-1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.2
      ref_id: 5.13.2-1
      description: Ensure that CJI is only transferred between CJI authorized applications
        and storage areas of the device.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.2-2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.2
      ref_id: 5.13.2-2
      description: 'MDM with centralized administration configured and implemented
        to perform at least the following controls:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.2-2-a
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.2-2
      ref_id: 5.13.2-2-a
      description: Remote locking of device
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.2-2-b
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.2-2
      ref_id: 5.13.2-2-b
      description: Remote wiping of device
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.2-2-c
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.2-2
      ref_id: 5.13.2-2-c
      description: Setting and locking device configuration
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.2-2-d
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.2-2
      ref_id: 5.13.2-2-d
      description: "Detection of \u201Crooted\u201D and \u201Cjailbroken\u201D devices"
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.2-2-e
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.2-2
      ref_id: 5.13.2-2-e
      description: Enforcement of folder or disk level encryption
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.2-2-f
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.2-2
      ref_id: 5.13.2-2-f
      description: Application of mandatory policy settings on the device
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.2-2-g
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.2-2
      ref_id: 5.13.2-2-g
      description: Detection of unauthorized configurations
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.2-2-h
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.2-2
      ref_id: 5.13.2-2-h
      description: Detection of unauthorized software or applications
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.2-2-i
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.2-2
      ref_id: 5.13.2-2-i
      description: Ability to determine the location of agency-controlled devices
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.2-2-j
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.2-2
      ref_id: 5.13.2-2-j
      description: Prevention of unpatched devices from accessing CJI or CJI systems
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.2-2-k
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.2-2
      ref_id: 5.13.2-2-k
      description: Automatic device wiping after a specified number of failed access
        attempts
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1397
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.2
      name: EXCEPTION
      description: An MDM is not required when receiving CJI from an indirect access
        information system (i.e., the system provides no capability to conduct transactional
        activities on state and national repositories, applications or services).
        However, it is incumbent upon the authorized agency to ensure CJI is delivered
        to the appropriate requesting agency or individual. The CSO will make the
        final determination of whether access is considered indirect.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.3
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13
      ref_id: 5.13.3
      name: Wireless Device Risk Mitigations
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1399
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.3
      description: 'Organizations shall, at a minimum, ensure that wireless devices:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.3-1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.3
      ref_id: 5.13.3-1
      description: Apply available critical patches and upgrades to the operating
        system as soon as they become available for the device and after necessary
        testing as described in Section 5.10.4.1.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.3-2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.3
      ref_id: 5.13.3-2
      description: Are configured for local device authentication (see Section 5.13.7.1).
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.3-3
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.3
      ref_id: 5.13.3-3
      description: Use advanced authentication or CSO approved compensating controls
        as per Section 5.13.7.2.1.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.3-4
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.3
      ref_id: 5.13.3-4
      description: Encrypt all CJI resident on the device.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.3-5
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.3
      ref_id: 5.13.3-5
      description: Erase cached information, to include authenticators (see Section
        5.6.2.1) in applications, when session is terminated.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.3-6
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.3
      ref_id: 5.13.3-6
      description: Employ personal firewalls on full-featured operating system devices
        or run a Mobile Device Management (MDM) system that facilitates the ability
        to provide firewall services from the agency level.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.3-7
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.3
      ref_id: 5.13.3-7
      description: Employ malicious code protection on full-featured operating system
        devices or run a MDM system that facilitates the ability to provide anti-malware
        services from the agency level.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.4
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13
      ref_id: 5.13.4
      name: System Integrity
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1408
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.4
      description: Managing system integrity on limited function mobile operating
        systems may require methods and technologies significantly different from
        traditional full-featured operating systems.In many cases, the requirements
        of Section 5.10 of the CJIS Security Policy cannot be met with a mobile device
        without the installation of a third-party MDM, application, or supporting
        service infrastructure.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.4.1
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.4
      ref_id: 5.13.4.1
      name: Patching/Updates
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1410
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.4.1
      description: Based on the varying connection methods for mobile devices, an
        always on connection cannot be guaranteed for patching and updating.Devices
        without always-on cellular connections may not be reachable for extended periods
        of time by the MDM or solution either to report status or initiate patching.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1411
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.4.1
      description: Agencies shall monitor mobile devices to ensure their patch and
        update state is current.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.4.2
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.4
      ref_id: 5.13.4.2
      name: Malicious Code Protection
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1413
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.4.2
      description: Appropriately configured MDM software is capable of checking the
        installed applications on the device and reporting the software inventory
        to a central management console in a manner analogous to traditional virus
        scan detection of unauthorized software and can provide a high degree of confidence
        that only known software or applications are installed on the device.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1414
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.4.2
      description: Agencies that allow smartphones and tablets to access CJI shall
        have a process to approve the use of specific software or applications on
        the devices. Any device natively capable of performing these functions without
        a MDM solution is acceptable under this section
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.4.3
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.4
      ref_id: 5.13.4.3
      name: Personal Firewall
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1416
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.4.3
      description: 'For the purpose of this policy, a personal firewall is an application
        that controls network traffic to and from a user device, permitting or denying
        communications based on policy.A personal firewall shall be employed on all
        mobile devices that have a full-feature operating system (i.e., laptops or
        tablets with Windows or Linux/Unix operating systems).At a minimum, the personal
        firewall shall perform the following activities:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.4.3-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.4.3
      ref_id: 5.13.4.3-1
      description: Manage program access to the Internet.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.4.3-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.4.3
      ref_id: 5.13.4.3-2
      description: Block unsolicited requests to connect to the user device.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.4.3-3
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.4.3
      ref_id: 5.13.4.3-3
      description: Filter incoming traffic by IP address or protocol.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.4.3-4
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.4.3
      ref_id: 5.13.4.3-4
      description: Filter incoming traffic by destination ports.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.4.3-5
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.4.3
      ref_id: 5.13.4.3-5
      description: Maintain an IP traffic log.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1422
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.4.3
      description: Mobile devices with limited-feature operating systems (i.e., tablets,
        smartphones) may not support a personal firewall.However, these operating
        systems have a limited number of system services installed, carefully controlled
        network access, and to a certain extent, perform functions similar to a personal
        firewall on a device with a full-feature operating system.Appropriately configured
        MDM software is capable of controlling which applications are allowed on the
        device.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.5
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13
      ref_id: 5.13.5
      name: Incident Response
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1424
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.5
      description: In addition to the requirements in Section 5.3 Incident Response,
        agencies shall develop additional or enhanced incident reporting and handling
        procedures to address mobile device operating scenarios.Rapid response to
        mobile device related incidents can significantly mitigate the risks associated
        with illicit data access either on the device itself or within online data
        resources associated with the device through an application or specialized
        interface.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1425
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.5
      description: 'Special reporting procedures for mobile devices shall apply in
        any of the following situations:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.5-1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.5
      ref_id: 5.13.5-1
      description: 'Loss of device control. For example:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.5-1-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.5
      ref_id: 5.13.5-1-a
      description: Device known to be locked, minimal duration of loss
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.5-1-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.5
      ref_id: 5.13.5-1-b
      description: Device lock state unknown, minimal duration of loss
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.5-1-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.5
      ref_id: 5.13.5-1-c
      description: Device lock state unknown, extended duration of loss
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.5-1-d
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.5
      ref_id: 5.13.5-1-d
      description: Device known to be unlocked, more than momentary duration of loss
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.5-2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.5
      ref_id: 5.13.5-2
      description: Total loss of device
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.5-3
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.5
      ref_id: 5.13.5-3
      description: Device compromise
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.5-4
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.5
      ref_id: 5.13.5-4
      description: Device loss or compromise outside the United States
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.6
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13
      ref_id: 5.13.6
      name: Access Control
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1435
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.6
      description: Multiple user accounts are not generally supported on limited-feature
        mobile operating systems. Access control (Section 5.5 Access Control) shall
        be accomplished by the application that accesses CJI.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.7
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13
      ref_id: 5.13.7
      name: Identification and Authentication
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1437
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.7
      description: Due to the technical methods used for identification and authentication
        on many limited-feature mobile operating systems, achieving compliance may
        require many different components.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.7.1
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.7
      ref_id: 5.13.7.1
      name: Local Device Authentication
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1439
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.7.1
      description: When mobile devices are authorized for use in accessing CJI, local
        device authentication shall be used to unlock the device for use.The authenticator
        used shall meet the requirements in section 5.6.2.1 Standard Authenticators.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.7.2
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.7
      ref_id: 5.13.7.2
      name: Advanced Authentication
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1441
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.7.2
      description: When accessing CJI from an authorized mobile device, advanced authentication
        shall be used by the authorized user unless the access to CJI is indirect
        as described in Section 5.6.2.2.1. If access is indirect, then AA is not required.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.7.2.1
      assessable: false
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.7.2
      ref_id: 5.13.7.2.1
      name: Compensating Controls
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1443
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.7.2.1
      description: 'CSO approved compensating controls to meet the AA requirement
        on agency-issued smartphones and tablets with limited-feature operating systems
        are permitted.Compensating controls are temporary control measures that are
        implemented in lieu of the required AA control measures when an agency cannot
        meet a requirement due to legitimate technical or business constraints.Before
        CSOs consider approval of compensating controls, Mobile Device Management
        (MDM) shall be implemented per Section 5.13.2. The compensating controls shall:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.7.2.1-1
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1443
      ref_id: 5.13.7.2.1-1
      description: Meet the intent of the CJIS Security Policy AA requirement
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.7.2.1-2
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1443
      ref_id: 5.13.7.2.1-2
      description: Provide a similar level of protection or security as the original
        AA requirement
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.7.2.1-3
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1443
      ref_id: 5.13.7.2.1-3
      description: Not rely upon the existing requirements for AA as compensating
        controls
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.7.2.1-4
      assessable: true
      depth: 7
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1443
      ref_id: 5.13.7.2.1-4
      description: Expire upon the CSO approved date or when a compliant AA solution
        is implemented.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1448
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.7.2.1
      description: Additionally, compensating controls may rely upon other, non-AA,
        existing requirements as compensating controls and/or be combined with new
        controls to create compensating controls.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1449
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.7.2.1
      description: The compensating controls for AA are a combination of controls
        providing acceptable assurance only the authorized user is authenticating
        and not an impersonator or (in the case of agency-issued device used by multiple
        users) controls that reduce the risk of exposure if information is accessed
        by an unauthorized party.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1450
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.7.2.1
      description: "The following minimum controls shall be implemented as part of\
        \ the CSO approved compensating controls: \n-\tPossession and registration\
        \ of an agency issued smartphone or tablet as an indication it is the authorized\
        \ user \n-\tUse of device certificates per Section 5.13.7.3 Device Certificates\
        \ \n-\tImplemented CJIS Security Policy compliant standard authenticator protection\
        \ on the secure location where CJI is stored"
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.7.3
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.7
      ref_id: 5.13.7.3
      name: Device Certificates
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1452
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.7.3
      description: Device certificates are often used to uniquely identify mobile
        devices using part of a public key pair on the device in the form of a public
        key certificate. While there is value to ensuring the device itself can authenticate
        to a system supplying CJI, and may provide a critical layer of device identification
        or authentication in a larger scheme, a device certificate alone placed on
        the device shall not be considered valid proof that the device is being operated
        by an authorized user.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1453
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.7.3
      description: 'When certificates or cryptographic keys used to authenticate a
        mobile device are used in lieu of compensating controls for advanced authentication,
        they shall be:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.7.3-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.7.3
      ref_id: 5.13.7.3-1
      description: Protected against being extracted from the device
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.7.3-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.7.3
      ref_id: 5.13.7.3-2
      description: Configured for remote wipe on demand or self-deletion based on
        a number of unsuccessful login or access attempts
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.7.3-3
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.13.7.3
      ref_id: 5.13.7.3-3
      description: Configured to use a secure authenticator (i.e., password, PIN)
        to unlock the key for use
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.14
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5
      ref_id: '5.14'
      name: SYSTEM AND SERVICES ACQUISITION (SA)
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sa-22
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.14
      ref_id: SA-22
      name: UNSUPPORTED SYSTEM COMPONENTS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sa-22-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sa-22
      ref_id: SA-22-a
      description: Replace system components when support for the components is no
        longer available from the developer, vendor, or manufacturer; or
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sa-22-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sa-22
      ref_id: SA-22-b
      description: 'Provide the following options for alternative sources for continued
        support for unsupported components: original manufacturer support, or original
        contracted vendor support.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1461
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:sa-22
      description: "Discussion: Support for system components includes software patches,\
        \ firmware updates, replacement parts, and maintenance contracts. An example\
        \ of unsupported components includes when vendors no longer provide critical\
        \ software patches or product updates, which can result in an opportunity\
        \ for adversaries to exploit weaknesses in the installed components. \nExceptions\
        \ to replacing unsupported system components include systems that provide\
        \ critical mission or business capabilities where newer technologies are not\
        \ available or where the systems are so isolated that installing replacement\
        \ components is not an option. \nAlternative sources for support address the\
        \ need to provide continued support for system components that are no longer\
        \ supported by the original manufacturers, developers, or vendors when such\
        \ components remain essential to organizational mission and business functions.\
        \ If necessary, organizations can establish in-house support by developing\
        \ customized patches for critical software components or, alternatively, obtain\
        \ the services of external providers who provide ongoing support for the designated\
        \ unsupported components through contractual relationships. Such contractual\
        \ relationships can include open-source software value-added vendors. The\
        \ increased risk of using unsupported system components can be mitigated,\
        \ for example, by prohibiting the connection of such components to public\
        \ or uncontrolled networks or implementing other forms of isolation. \nRelated\
        \ Controls: PL-2, SA-3."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.15
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5
      ref_id: '5.15'
      name: SYSTEM AND INFORMATION INTEGRITY (SI)
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-1
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.15
      ref_id: SI-1
      name: POLICY AND PROCEDURES
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-1-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-1
      ref_id: SI-1-a
      description: 'Develop, document, and disseminate to all organizational personnel
        with system and information integrity responsibilities and information system
        owners:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-1-a-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-1-a
      ref_id: SI-1-a-1
      description: 'Agency-level system and information integrity policy that:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-1-a-1-a
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-1-a-1
      ref_id: SI-1-a-1-a
      description: Addresses purpose, scope, roles, responsibilities, management commitment,
        coordination among organizational entities, and compliance; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-1-a-1-b
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-1-a-1
      ref_id: SI-1-a-1-b
      description: Is consistent with applicable laws, executive orders, directives,
        regulations, policies, standards, and guidelines; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-1-a-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-1-a
      ref_id: SI-1-a-2
      description: Procedures to facilitate the implementation of the system and information
        integrity policy and the associated system and information integrity controls;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-1-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-1
      ref_id: SI-1-b
      description: Designate organizational personnel with system and information
        integrity responsibilities to manage the development, documentation, and dissemination
        of the system and information integrity policy and procedures; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-1-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-1
      ref_id: SI-1-c
      description: 'Review and update the current system and information integrity:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-1-c-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-1-c
      ref_id: SI-1-c-1
      description: Policy annually and following any security incidents involving
        unauthorized access to CJI or systems used to process, store, or transmit
        CJI; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-1-c-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-1-c
      ref_id: SI-1-c-2
      description: Procedures annually and following any security incidents involving
        unauthorized access to CJI or systems used to process, store, or transmit
        CJI.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1473
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-1-c
      description: "Discussion:System and information integrity policy and procedures\
        \ address the controls in the SI family that are implemented within systems\
        \ and organizations. The risk management strategy is an important factor in\
        \ establishing such policies and procedures. Policies and procedures contribute\
        \ to security and privacy assurance. Therefore, it is important that security\
        \ and privacy programs collaborate on the development of system and information\
        \ integrity policy and procedures. Security and privacy program policies and\
        \ procedures at the organization level are preferable, in general, and may\
        \ obviate the need for mission- or system-specific policies and procedures.\
        \ The policy can be included as part of the general security and privacy policy\
        \ or be represented by multiple policies that reflect the complex nature of\
        \ organizations. Procedures can be established for security and privacy programs,\
        \ for mission or business processes, and for systems, if needed. Procedures\
        \ describe how the policies or controls are implemented and can be directed\
        \ at the individual or role that is the object of the procedure. Procedures\
        \ can be documented in system security and privacy plans or in one or more\
        \ separate documents. Events that may precipitate an update to system and\
        \ information integrity policy and procedures include assessment or audit\
        \ findings, security incidents or breaches, or changes in applicable laws,\
        \ executive orders, directives, regulations, policies, standards, and guidelines.\
        \ Simply restating controls does not constitute an organizational policy or\
        \ procedure. \n Related Controls:PS-8, SA-8, SI-12."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-2
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.15
      ref_id: SI-2
      name: FLAW REMEDIATION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-2-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-2
      ref_id: SI-2-a
      description: Identify, report, and correct system flaws;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-2-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-2
      ref_id: SI-2-b
      description: Test software and firmware updates related to flaw remediation
        for effectiveness and potential side effects before installation;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-2-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-2
      ref_id: SI-2-c
      description: Install security-relevant software and firmware updates within
        the number of days listed after the release of the updates;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1478
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-2-c
      description: "\u2022\tCritical \u2013 15 days"
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1479
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-2-c
      description: "\u2022\tHigh \u2013 30 days"
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1480
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-2-c
      description: "\u2022\tMedium \u2013 60 days"
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1481
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-2-c
      description: "\u2022\tLow \u2013 90 days; and"
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-2-d
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-2
      ref_id: SI-2-d
      description: Incorporate flaw remediation into the organizational configuration
        management process.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1483
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-2
      description: "Discussion:The need to remediate system flaws applies to all types\
        \ of software and firmware. Organizations identify systems affected by software\
        \ flaws, including potential vulnerabilities resulting from those flaws, and\
        \ report this information to designated organizational personnel with information\
        \ security and privacy responsibilities. Security-relevant updates include\
        \ patches, service packs, and malicious code signatures. Organizations also\
        \ address flaws discovered during assessments, continuous monitoring, incident\
        \ response activities, and system error handling. By incorporating flaw remediation\
        \ into configuration management processes, required remediation actions can\
        \ be tracked and verified. \nOrganization-defined time periods for updating\
        \ security-relevant software and firmware may vary based on a variety of risk\
        \ factors, including the security category of the system, the criticality\
        \ of the update (i.e., severity of the vulnerability related to the discovered\
        \ flaw), the organizational risk tolerance, the mission supported by the system,\
        \ or the threat environment. Some types of flaw remediation may require more\
        \ testing than other types. Organizations determine the type of testing needed\
        \ for the specific type of flaw remediation activity under consideration and\
        \ the types of changes that are to be configuration-managed. In some situations,\
        \ organizations may determine that the testing of software or firmware updates\
        \ is not necessary or practical, such as when implementing simple malicious\
        \ code signature updates. In testing decisions, organizations consider whether\
        \ security-relevant software or firmware updates are obtained from authorized\
        \ sources with appropriate digital signatures. \nRelated Controls:CA-5, CM-3,\
        \ CM-4, CM-5, CM-6, CM-8, MA-2, RA-5, SA-8, SA-10, SA-11, SI-3, SI- 5, SI-7,\
        \ SI-11."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-2(2)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-2
      ref_id: SI-2(2)
      name: FLAW REMEDIATION | AUTOMATED FLAW REMEDIATION STATUS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1485
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-2(2)
      description: Determine if system components have applicable security-relevant
        software and firmware updates installed using vulnerability scanning tools
        as least quarterly or following any security incidents involving CJI or systems
        used to process, store, or transmit CJI.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1486
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-2(2)
      description: "Discussion:Automated mechanisms can track and determine the status\
        \ of known flaws for system components. \nRelated Controls:CA-7, SI-4."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-3
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.15
      ref_id: SI-3
      name: MALICIOUS CODE PROTECTION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-3-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-3
      ref_id: SI-3-a
      description: Implement signature-based malicious code protection mechanisms
        at system entry and exit points to detect and eradicate malicious code;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-3-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-3
      ref_id: SI-3-b
      description: Automatically update malicious code protection mechanisms as new
        releases are available in accordance with organizational configuration management
        policy and procedures;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-3-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-3
      ref_id: SI-3-c
      description: 'Configure malicious code protection mechanisms to:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-3-c-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-3-c
      ref_id: SI-3-c-1
      description: Perform periodic scans of the system at least daily and real-time
        scans of files from external sources at network entry and exit points and
        on all servers and endpoint devices as the files are downloaded, opened, or
        executed in accordance with organizational policy; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-3-c-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-3-c
      ref_id: SI-3-c-2
      description: Block or quarantine malicious code, take mitigating action(s),
        and when necessary, implement incident response procedures; and send alert
        to system/network administrators and/or organizational personnel with information
        security responsibilities in response to malicious code detection; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-3-d
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-3
      ref_id: SI-3-d
      description: Address the receipt of false positives during malicious code detection
        and eradication and the resulting potential impact on the availability of
        the system.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1494
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-3
      description: "Discussion:System entry and exit points include firewalls, remote\
        \ access servers, workstations, electronic mail servers, web servers, proxy\
        \ servers, notebook computers, and mobile devices. Malicious code includes\
        \ viruses, worms, Trojan horses, and spyware. Malicious code can also be encoded\
        \ in various formats contained within compressed or hidden files or hidden\
        \ in files using techniques such as steganography. Malicious code can be inserted\
        \ into systems in a variety of ways, including by electronic mail, the World\
        \ Wide Web, and portable storage devices. \nMalicious code protection mechanisms\
        \ include both signature- and nonsignature-based technologies. Nonsignature-based\
        \ detection mechanisms include artificial intelligence techniques that use\
        \ heuristics to detect, analyze, and describe the characteristics or behavior\
        \ of malicious code and to provide controls against such code for which signatures\
        \ do not yet exist or for which existing signatures may not be effective.\
        \ Malicious code for which active signatures do not yet exist or may be ineffective\
        \ includes polymorphic malicious code (i.e., code that changes signatures\
        \ when it replicates). Nonsignature-based mechanisms also include reputation-based\
        \ technologies. In addition to the above technologies, pervasive configuration\
        \ management, comprehensive software integrity controls, and anti-exploitation\
        \ software may be effective in preventing the execution of unauthorized code.\
        \ Malicious code may be present in commercial off-the-shelf software as well\
        \ as custom-built software and could include logic bombs, backdoors, and other\
        \ types of attacks that could affect organizational mission and business functions.\
        \ \nIn situations where malicious code cannot be detected by detection methods\
        \ or technologies, organizations rely on other types of controls, including\
        \ secure coding practices, configuration management and control, trusted procurement\
        \ processes, and monitoring practices to ensure that software does not perform\
        \ functions other than the functions intended. Organizations may determine\
        \ that, in response to the detection of malicious code, different actions\
        \ may be warranted. For example, organizations can define actions in response\
        \ to malicious code detection during periodic scans, the detection of malicious\
        \ downloads, or the detection of maliciousness when attempting to open or\
        \ execute files. \nRelated Controls:AC-4, AC-19, CM-3, CM-8, IR-4, MA-3, MA-4,\
        \ RA-5, SC-7, SC-23, SC- 28, SI-2, SI-4, SI-7, SI-8."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.15
      ref_id: SI-4
      name: SYSTEM MONITORING
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4
      ref_id: SI-4-a
      description: 'Monitor the system to detect:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4-a-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4-a
      ref_id: SI-4-a-1
      description: 'Attacks and indicators of potential attacks in accordance with
        the following monitoring objectives:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4-a-1-a
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4-a-1
      ref_id: SI-4-a-1-a
      description: Intrusion detection and prevention
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4-a-1-b
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4-a-1
      ref_id: SI-4-a-1-b
      description: Malicious code protection
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4-a-1-c
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4-a-1
      ref_id: SI-4-a-1-c
      description: Vulnerability scanning
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4-a-1-d
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4-a-1
      ref_id: SI-4-a-1-d
      description: Audit record monitoring
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4-a-1-e
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4-a-1
      ref_id: SI-4-a-1-e
      description: Network monitoring
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4-a-1-f
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4-a-1
      ref_id: SI-4-a-1-f
      description: Firewall monitoring;and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4-a-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4-a
      ref_id: SI-4-a-2
      description: Unauthorized local, network, and remote connections;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4
      ref_id: SI-4-b
      description: 'Identify unauthorized use of the system through the following
        techniques and methods: event logging (ref. 5.4 Audit and Accountability);'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4
      ref_id: SI-4-c
      description: 'Invoke internal monitoring capabilities or deploy monitoring devices:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4-c-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4-c
      ref_id: SI-4-c-1
      description: Strategically within the system to collect organization-determined
        essential information; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4-c-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4-c
      ref_id: SI-4-c-2
      description: At ad hoc locations within the system to track specific types of
        transactions of interest to the organization;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4-d
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4
      ref_id: SI-4-d
      description: Analyze detected events and anomalies;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4-e
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4
      ref_id: SI-4-e
      description: Adjust the level of system monitoring activity when there is a
        change in risk to organizational operations and assets, individuals, other
        organizations, or the Nation;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4-f
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4
      ref_id: SI-4-f
      description: Obtain legal opinion regarding system monitoring activities; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4-g
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4
      ref_id: SI-4-g
      description: Provide intrusion detection and prevention systems, malicious code
        protection software, scanning tools, audit record monitoring software, network
        monitoring, and firewall monitoring software logs to organizational personnel
        with information security responsibilities weekly.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1513
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4
      description: "Discussion:System monitoring includes external and internal monitoring.\
        \ External monitoring includes the observation of events occurring at external\
        \ interfaces to the system. Internal monitoring includes the observation of\
        \ events occurring within the system. Organizations monitor systems by observing\
        \ audit activities in real time or by observing other system aspects such\
        \ as access patterns, characteristics of access, and other actions. The monitoring\
        \ objectives guide and inform the determination of the events. System monitoring\
        \ capabilities are achieved through a variety of tools and techniques, including\
        \ intrusion detection and prevention systems, malicious code protection software,\
        \ scanning tools, audit record monitoring software, and network monitoring\
        \ software. \nDepending on the security architecture, the distribution and\
        \ configuration of monitoring devices may impact throughput at key internal\
        \ and external boundaries as well as at other locations across a network due\
        \ to the introduction of network throughput latency. If throughput management\
        \ is needed, such devices are strategically located and deployed as part of\
        \ an established organization-wide security architecture. Strategic locations\
        \ for monitoring devices include selected perimeter locations and near key\
        \ servers and server farms that support critical applications. Monitoring\
        \ devices are typically employed at the managed interfaces associated with\
        \ controls SC-7 and AC-17. The information collected is a function of the\
        \ organizational monitoring objectives and the capability of systems to support\
        \ such objectives. Specific types of transactions of interest include Hypertext\
        \ Transfer Protocol (HTTP) traffic that bypasses HTTP proxies. System monitoring\
        \ is an integral part of organizational continuous monitoring and incident\
        \ response programs, and output from system monitoring serves as input to\
        \ those programs. System monitoring requirements, including the need for specific\
        \ types of system monitoring, may be referenced in other controls (e.g., AC-2g,\
        \ AC-17(1), CM-3f, CM-6d, MA3a, MA-4a, SC-5(3)(b), SC-7a, SC-18b). Adjustments\
        \ to levels of system monitoring are based on law enforcement information,\
        \ intelligence information, or other sources of information. The legality\
        \ of system monitoring activities is based on applicable laws, executive orders,\
        \ directives, regulations, policies, standards, and guidelines. \nRelated\
        \ Controls:AC-2, AC-3, AC-4, AC-8, AC-17, AU-2, AU-6, AU-7, AU-9, AU-12, CA-7,\
        \ CM-3, CM-6, CM-8, CM-11, IR-4, MA-3, MA-4, RA-5, SC-5, SC-7, SC-18, SI-3,\
        \ SI-7, SR-10."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4(2)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4
      ref_id: SI-4(2)
      name: SYSTEM MONITORING | AUTOMATED TOOLS AND MECHANISMS FOR REALTIME ANALYSIS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1515
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4(2)
      description: Employ automated tools and mechanisms to support near real-time
        analysis of events.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1516
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4(2)
      description: "Discussion:Automated tools and mechanisms include host-based,\
        \ network-based, transportbased, or storage-based event monitoring tools and\
        \ mechanisms or security information and event management (SIEM) technologies\
        \ that provide real-time analysis of alerts and notifications generated by\
        \ organizational systems. Automated monitoring techniques can create unintended\
        \ privacy risks because automated controls may connect to external or otherwise\
        \ unrelated systems. The matching of records between these systems may create\
        \ linkages with unintended consequences. Organizations assess and document\
        \ these risks in their privacy impact assessment and make determinations that\
        \ are in alignment with their privacy program plan. \nRelated Controls:None."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4(4)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4
      ref_id: SI-4(4)
      name: SYSTEM MONITORING | INBOUND AND OUTBOUND COMMUNICATIONS TRAFFIC
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4(4)-a
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4(4)
      ref_id: SI-4(4)-a
      description: Determine criteria for unusual or unauthorized activities or conditions
        for inbound and outbound communications traffic;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4(4)-b
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4(4)
      ref_id: SI-4(4)-b
      description: 'Monitor inbound and outbound communications traffic continuously
        for unusual or unauthorized activities or conditions such as: the presence
        of malicious code or unauthorized use of legitimate code or credentials within
        organizational systems or propagating among system components, signaling to
        external systems, and the unauthorized exporting of information.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1520
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4(4)
      description: "Discussion:Unusual or unauthorized activities or conditions related\
        \ to system inbound and outbound communications traffic includes internal\
        \ traffic that indicates the presence of malicious code or unauthorized use\
        \ of legitimate code or credentials within organizational systems or propagating\
        \ among system components, signaling to external systems, and the unauthorized\
        \ exporting of information. Evidence of malicious code or unauthorized use\
        \ of legitimate code or credentials is used to identify potentially compromised\
        \ systems or system components. \nRelated Controls:None."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4(5)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4
      ref_id: SI-4(5)
      name: SYSTEM MONITORING | SYSTEM-GENERATED ALERTS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1522
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4(5)
      description: 'Alert organizational personnel with system monitoring responsibilities
        when the following systemgenerated indications of compromise or potential
        compromise occur: inappropriate or unusual activities with security or privacy
        implications.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1523
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-4(5)
      description: "Discussion:Alerts may be generated from a variety of sources,\
        \ including audit records or inputs from malicious code protection mechanisms,\
        \ intrusion detection or prevention mechanisms, or boundary protection devices\
        \ such as firewalls, gateways, and routers. Alerts can be automated and may\
        \ be transmitted telephonically, by electronic mail messages, or by text messaging.\
        \ Organizational personnel on the alert notification list can include system\
        \ administrators, mission or business owners, system owners, information owners/stewards,\
        \ senior agency information security officers, senior agency officials for\
        \ privacy, system security officers, or privacy officers. In contrast to alerts\
        \ generated by the system, alerts generated by organizations in SI-4(12) focus\
        \ on information sources external to the system, such as suspicious activity\
        \ reports and reports on potential insider threats. \nRelated Controls:AU-4,\
        \ AU-5, PE-6."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-5
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.15
      ref_id: SI-5
      name: SECURITY ALERTS, ADVISORIES, AND DIRECTIVES
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-5-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-5
      ref_id: SI-5-a
      description: Receive system security alerts, advisories, and directives from
        external source(s) (e.g., CISA, Multi-State Information Sharing & Analysis
        Center [MS-ISAC], U.S. Computer Emergency Readiness Team [USCERT], hardware/software
        providers, federal/state advisories, etc.) on an ongoing basis;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-5-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-5
      ref_id: SI-5-b
      description: Generate internal security alerts, advisories, and directives as
        deemed necessary;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-5-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-5
      ref_id: SI-5-c
      description: 'Disseminate security alerts, advisories, and directives to: organizational
        personnel implementing, operating, maintaining, and using the system; and'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-5-d
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-5
      ref_id: SI-5-d
      description: Implement security directives in accordance with established time
        frames, or notify the issuing organization of the degree of noncompliance.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1529
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-5
      description: "Discussion:The Cybersecurity and Infrastructure Security Agency\
        \ (CISA) generates security alerts and advisories to maintain situational\
        \ awareness throughout the federal government. Security directives are issued\
        \ by OMB or other designated organizations with the responsibility and authority\
        \ to issue such directives. Compliance with security directives is essential\
        \ due to the critical nature of many of these directives and the potential\
        \ (immediate) adverse effects on organizational operations and assets, individuals,\
        \ other organizations, and the Nation should the directives not be implemented\
        \ in a timely manner. External organizations include supply chain partners,\
        \ external mission or business partners, external service providers, and other\
        \ peer or supporting organizations. \nRelated Controls:RA-5, SI-2."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-7
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.15
      ref_id: SI-7
      name: SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-7-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-7
      ref_id: SI-7-a
      description: Employ integrity verification tools to detect unauthorized changes
        to software, firmware, and information systems that contain or process CJI;
        and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-7-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-7
      ref_id: SI-7-b
      description: 'Take the following actions when unauthorized changes to the software,
        firmware, and information are detected: notify organizational personnel responsible
        for software, firmware, and/or information integrity and implement incident
        response procedures as appropriate.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1533
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-7
      description: "Discussion:Unauthorized changes to software, firmware, and information\
        \ can occur due to errors or malicious activity. Software includes operating\
        \ systems (with key internal components, such as kernels or drivers), middleware,\
        \ and applications. Firmware interfaces include Unified Extensible Firmware\
        \ Interface (UEFI) and Basic Input/Output System (BIOS). Information includes\
        \ personally identifiable information and metadata that contains security\
        \ and privacy attributes associated with information. Integrity-checking mechanisms\u2014\
        including parity checks, cyclical redundancy checks, cryptographic hashes,\
        \ and associated tools\u2014can automatically monitor the integrity of systems\
        \ and hosted applications. \nRelated Controls:AC-4, CM-3, CM-7, CM-8, MA-3,\
        \ MA-4, RA-5, SA-8, SA-9, SA-10, SC-8, SC-12, SC-13, SC-28, SI-3, SR-3, SR-5,\
        \ SR-6, SR-10, SR-11."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-7(1)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-7
      ref_id: SI-7(1)
      name: SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY | INTEGRITY CHECKS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1535
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-7(1)
      description: Perform an integrity check of software, firmware, and information
        systems that contain or process CJI at agency-defined transitional states
        or security relevant events at least weekly or in an automated fashion.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1536
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-7(1)
      description: "Discussion:Security-relevant events include the identification\
        \ of new threats to which organizational systems are susceptible and the installation\
        \ of new hardware, software, or firmware. Transitional states include system\
        \ startup, restart, shutdown, and abort. \nRelated Controls:None."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-7(7)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-7
      ref_id: SI-7(7)
      name: SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY | INTEGRATION OF DETECTION
        AND RESPONSE
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1538
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-7(7)
      description: Incorporate the detection of the following unauthorized changes
        into the organizational incident response capability:unauthorized changes
        to established configuration setting or the unauthorized elevation of system
        privileges.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1539
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-7(7)
      description: "Discussion:Integrating detection and response helps to ensure\
        \ that detected events are tracked, monitored, corrected, and available for\
        \ historical purposes. Maintaining historical records is important for being\
        \ able to identify and discern adversary actions over an extended time period\
        \ and for possible legal actions. Security-relevant changes include unauthorized\
        \ changes to established configuration settings or the unauthorized elevation\
        \ of system privileges. \nRelated Controls:AU-2, AU-6, IR-4, IR-5, SI-4."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-8
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.15
      ref_id: SI-8
      name: SPAM PROTECTION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-8-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-8
      ref_id: SI-8-a
      description: Employ spam protection mechanisms at system entry and exit points
        to detect and act on unsolicited messages; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-8-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-8
      ref_id: SI-8-b
      description: Update spam protection mechanisms when new releases are available
        in accordance with organizational configuration management policy and procedures.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1543
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-8
      description: "Discussion:System entry and exit points include firewalls, remote-access\
        \ servers, electronic mail servers, web servers, proxy servers, workstations,\
        \ notebook computers, and mobile devices.Spam can be transported by different\
        \ means, including email, email attachments, and web accesses. Spam protection\
        \ mechanisms include signature definitions. \nRelated Controls:SC-5, SC-7,\
        \ SI-3, SI-4."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-8(2)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-8
      ref_id: SI-8(2)
      name: SPAM PROTECTION | AUTOMATIC UPDATES
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1545
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-8(2)
      description: Automatically update spam protection mechanisms at least daily.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1546
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-8(2)
      description: "Discussion: Using automated mechanisms to update spam protection\
        \ mechanisms helps to ensure that updates occur on a regular basis and provide\
        \ the latest content and protection capabilities. \nRelated Controls:None."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-10
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.15
      ref_id: SI-10
      name: INFORMATION INPUT VALIDATION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1548
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-10
      description: Check the validity of the following information inputs:all inputs
        to web/application servers, database servers, and any system or application
        input that might receive or process CJI.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1549
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-10
      description: "Discussion:Checking the valid syntax and semantics of system inputs\u2014\
        including character set, length, numerical range, and acceptable values\u2014\
        verifies that inputs match specified definitions for format and content. For\
        \ example, if the organization specifies that numerical values between 1-100\
        \ are the only acceptable inputs for a field in a given application, inputs\
        \ of \u201C387,\u201D \u201Cabc,\u201D or \u201C%K%\u201D are invalid inputs\
        \ and are not accepted as input to the system. Valid inputs are likely to\
        \ vary from field to field within a software application. Applications typically\
        \ follow well-defined protocols that use structured messages (i.e., commands\
        \ or queries) to communicate between software modules or system components.\
        \ Structured messages can contain raw or unstructured data interspersed with\
        \ metadata or control information. If software applications use attackersupplied\
        \ inputs to construct structured messages without properly encoding such messages,\
        \ then the attacker could insert malicious commands or special characters\
        \ that can cause the data to be interpreted as control information or metadata.\
        \ Consequently, the module or component that receives the corrupted output\
        \ will perform the wrong operations or otherwise interpret the data incorrectly.\
        \ Prescreening inputs prior to passing them to interpreters prevents the content\
        \ from being unintentionally interpreted as commands. Input validation ensures\
        \ accurate and correct inputs and prevents attacks such as cross-site scripting\
        \ and a variety of injection attacks. \nRelated Controls:None."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-11
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.15
      ref_id: SI-11
      name: ERROR HANDLING
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-11-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-11
      ref_id: SI-11-a
      description: Generate error messages that provide information necessary for
        corrective actions without revealing information that could be exploited;
        and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-11-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-11
      ref_id: SI-11-b
      description: Reveal error messages only to organizational personnel with information
        security responsibilities.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1553
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-11
      description: "Discussion:Organizations consider the structure and content of\
        \ error messages. The extent to which systems can handle error conditions\
        \ is guided and informed by organizational policy and operational requirements.\
        \ Exploitable information includes stack traces and implementation details;\
        \ erroneous logon attempts with passwords mistakenly entered as the username;\
        \ mission or business information that can be derived from, if not stated\
        \ explicitly by, the information recorded; and personally identifiable information,\
        \ such as account numbers, social security numbers, and credit card numbers.\
        \ Error messages may also provide a covert channel for transmitting information.\
        \ \nRelated Controls:AU-2, AU-3, SI-2."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-12
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.15
      ref_id: SI-12
      name: INFORMATION MANAGEMENT AND RETENTION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1555
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-12
      description: 'Manage and retain information within the system and information
        output from the system in accordance with applicable laws, executive orders,
        directives, regulations, policies, standards, guidelines and operational requirements. '
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1556
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-12
      description: "Discussion:Information management and retention requirements cover\
        \ the full life cycle of information, in some cases extending beyond system\
        \ disposal. Information to be retained may also include policies, procedures,\
        \ plans, reports, data output from control implementation, and other types\
        \ of administrative information. The National Archives and Records Administration\
        \ (NARA) provides federal policy and guidance on records retention and schedules.\
        \ If organizations have a records management office, consider coordinating\
        \ with records management personnel. Records produced from the output of implemented\
        \ controls that may require management and retention include, but are not\
        \ limited to:All XX-1, AC-6(9), AT-4, AU-12, CA-2, CA-3, CA-5, CA-6, CA-7,\
        \ CA-9, CM-2, CM-3, CM-4, CM-6, CM-8, CM-9, CM12, CP-2, IR-6, IR-8, MA-2,\
        \ MA-4, PE-2, PE-8, PE-16, PE-17, PL-2, PL-4, PL-8, PS-2, PS-6, PS-7, RA-2,\
        \ RA-3, RA-5, SA-4, SA-5, SA-8, SA-10, SI-4, SR-2, SR-8. \nRelated Controls:AU-5,\
        \ AU-11, CA-2, CA-3, CA-5, CA-6, CA-7, CA-9, CM- 5, CM-9, CP-2, IR-8, MP-2,\
        \ MP-3, MP-4, MP-6, PL-2, PL-4, PS-2, PS-6, RA-2, RA-3, SA-5, SA-8, SR-2."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-12(1)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-12
      ref_id: SI-12(1)
      name: INFORMATION MANAGEMENT AND RETENTION | LIMIT PERSONALLY IDENTIFIABLE INFORMATION
        ELEMENTS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1558
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-12(1)
      description: Limit personally identifiable information being processed in the
        information life cycle to the minimum PII necessary to achieve the purpose
        for which it is collected (see Section 4.3).
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1559
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-12(1)
      description: "Discussion:Limiting the use of personally identifiable information\
        \ throughout the information life cycle when the information is not needed\
        \ for operational purposes helps to reduce the level of privacy risk created\
        \ by a system. The information life cycle includes information creation, collection,\
        \ use, processing, storage, maintenance, dissemination, disclosure, and disposition.\
        \ Risk assessments as well as applicable laws, regulations, and policies can\
        \ provide useful inputs to determining which elements of personally identifiable\
        \ information may create risk. \nRelated Controls:None."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-12(2)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-12
      ref_id: SI-12(2)
      name: INFORMATION MANAGEMENT AND RETENTION | MINIMIZE PERSONALLY IDENTIFIABLE
        INFORMATION IN TESTING, TRAINING, AND RESEARCH
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1561
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-12(2)
      description: Use the following techniques to minimize the use of personally
        identifiable information for research, testing, or training:data obfuscation,
        randomization, anonymization, or use of synthetic data.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1562
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-12(2)
      description: "Discussion:Organizations can minimize the risk to an individual\u2019\
        s privacy by employing techniques such as de-identification or synthetic data.\
        \ Limiting the use of personally identifiable information throughout the information\
        \ life cycle when the information is not needed for research, testing, or\
        \ training helps reduce the level of privacy risk created by a system. Risk\
        \ assessments as well as applicable laws, regulations, and policies can provide\
        \ useful inputs to determining the techniques to use and when to use them.\
        \ \nRelated Controls:None."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-12(3)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-12
      ref_id: SI-12(3)
      name: INFORMATION MANAGEMENT AND RETENTION | INFORMATION DISPOSAL
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1564
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-12(3)
      description: Use the following techniques to dispose of, destroy, or erase information
        following the retention period:as defined in MP-6.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1565
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-12(3)
      description: "Discussion:Organizations can minimize both security and privacy\
        \ risks by disposing of information when it is no longer needed. The disposal\
        \ or destruction of information applies to originals as well as copies and\
        \ archived records, including system logs that may contain personally identifiable\
        \ information. \nRelated Controls:MP-6."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-16
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.15
      ref_id: SI-16
      name: MEMORY PROTECTION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1567
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-16
      description: Implement the following controls to protect the system memory from
        unauthorized code execution:data execution prevention and address space layout
        randomization.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1568
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:si-16
      description: "Discussion:Some adversaries launch attacks with the intent of\
        \ executing code in nonexecutable regions of memory or in memory locations\
        \ that are prohibited. Controls employed to protect memory include data execution\
        \ prevention and address space layout randomization. Data execution prevention\
        \ controls can either be hardware-enforced or software-enforced with hardware\
        \ enforcement providing the greater strength of mechanism. \nRelated Controls:SI-7."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.16
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5
      ref_id: '5.16'
      name: MAINTENANCE (MA)
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-1
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.16
      ref_id: MA-1
      name: POLICY AND PROCEDURES
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-1-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-1
      ref_id: MA-1-a
      description: 'Develop, document, and disseminate to organizational personnel
        with system maintenance responsibilities:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-1-a-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-1-a
      ref_id: MA-1-a-1
      description: 'Agency-level maintenance policy that:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-1-a-1-a
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-1-a-1
      ref_id: MA-1-a-1-a
      description: Addresses purpose, scope, roles, responsibilities, management commitment,
        coordination among organizational entities, and compliance; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-1-a-1-b
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-1-a-1
      ref_id: MA-1-a-1-b
      description: Is consistent with applicable laws, executive orders, directives,
        regulations, policies, standards, and guidelines; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-1-a-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-1-a
      ref_id: MA-1-a-2
      description: Procedures to facilitate the implementation of the maintenance
        policy and the associated maintenance controls;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-1-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-1
      ref_id: MA-1-b
      description: Designate an individual with security responsibilities to manage
        the development, documentation, and dissemination of the maintenance policy
        and procedures; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-1-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-1
      ref_id: MA-1-c
      description: 'Review and update the current maintenance:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-1-c-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-1-c
      ref_id: MA-1-c-1
      description: Policy annually and following any security incidents involving
        unauthorized access to CJI or systems used to process, store, or transmit
        CJI; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-1-c-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-1-c
      ref_id: MA-1-c-2
      description: Procedures annually and following any security incidents involving
        unauthorized access to CJI or systems used to process, store, or transmit
        CJI.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1580
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-1
      description: 'Discussion: Maintenance policy and procedures address the controls
        in the MA family that are implemented within systems and organizations. The
        risk management strategy is an important factor in establishing such policies
        and procedures. Policies and procedures contribute to security and privacy
        assurance. Therefore, it is important that security and privacy programs collaborate
        on the development of maintenance policy and procedures. Security and privacy
        program policies and procedures at the organization level are preferable,
        in general, and may obviate the need for mission- or system-specific policies
        and procedures. The policy can be included as part of the general security
        and privacy policy or be represented by multiple policies that reflect the
        complex nature of organizations. Procedures can be established for security
        and privacy programs, for mission or business processes, and for systems,
        if needed. Procedures describe how the policies or controls are implemented
        and can be directed at the individual or role that is the object of the procedure.
        Procedures can be documented in system security and privacy plans or in one
        or more separate documents. Events that may precipitate an update to maintenance
        policy and procedures assessment or audit findings, security incidents or
        breaches, or changes in applicable laws, executive orders, directives, regulations,
        policies, standards, and guidelines. Simply restating controls does not constitute
        an organizational policy or procedure.

        Related Controls: PS-8, SI-12.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-2
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.16
      ref_id: MA-2
      name: CONTROLLED MAINTENANCE
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-2-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-2
      ref_id: MA-2-a
      description: Schedule, document, and review records of maintenance, repair,
        and replacement on system components in accordance with manufacturer or vendor
        specifications and/or organizational requirements;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-2-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-2
      ref_id: MA-2-b
      description: Approve and monitor all maintenance activities, whether performed
        on site or remotely and whether the system or system components are serviced
        on site or removed to another location;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-2-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-2
      ref_id: MA-2-c
      description: Require that organizational personnel with information security
        and privacy responsibilities explicitly approve the removal of the system
        or system components from organizational facilities for off-site maintenance,
        repair, or replacement;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-2-d
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-2
      ref_id: MA-2-d
      description: Sanitize equipment to remove information from associated media
        prior to removal from organizational facilities for off-site maintenance,
        repair, replacement, or destruction;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-2-e
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-2
      ref_id: MA-2-e
      description: Check all potentially impacted controls to verify that the controls
        are still functioning properly following maintenance, repair, or replacement
        actions; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-2-f
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-2
      ref_id: MA-2-f
      description: 'Include the following information in organizational maintenance
        records:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-2-f-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-2-f
      ref_id: MA-2-f-1
      description: Component name
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-2-f-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-2-f
      ref_id: MA-2-f-2
      description: Component serial number
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-2-f-3
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-2-f
      ref_id: MA-2-f-3
      description: Date/time of maintenance
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-2-f-4
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-2-f
      ref_id: MA-2-f-4
      description: Maintenance performed
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-2-f-5
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-2-f
      ref_id: MA-2-f-5
      description: Name(s) of entity performing maintenance including escort if required.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1593
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-2-f
      description: "Discussion: Controlling system maintenance addresses the information\
        \ security aspects of the system maintenance program and applies to all types\
        \ of maintenance to system components conducted by local or nonlocal entities.\
        \ Maintenance includes peripherals such as scanners, copiers, and printers.\
        \ Information necessary for creating effective maintenance records includes\
        \ the date and time of maintenance, a description of the maintenance performed,\
        \ names of the individuals or group performing the maintenance, name of the\
        \ escort, and system components or equipment that are removed or replaced.\
        \ Organizations consider supply chain-related risks associated with replacement\
        \ components for systems. \nRelated Controls: CM-2, CM-3, CM-4, CM-5, CM-8,\
        \ MA-4, MP-6, PE-16, SI-2, SR-3, SR-11."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-3
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.16
      ref_id: MA-3
      name: MAINTENANCE TOOLS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-3-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-3
      ref_id: MA-3-a
      description: Approve, control, and monitor the use of system maintenance tools;
        and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-3-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-3
      ref_id: MA-3-b
      description: Review previously approved system maintenance tools prior to each
        use.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1597
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-3
      description: "Discussion: Approving, controlling, monitoring, and reviewing\
        \ maintenance tools address security-related issues associated with maintenance\
        \ tools that are not within system authorization boundaries and are used specifically\
        \ for diagnostic and repair actions on organizational systems. Organizations\
        \ have flexibility in determining roles for the approval of maintenance tools\
        \ and how that approval is documented. A periodic review of maintenance tools\
        \ facilitates the withdrawal of approval for outdated, unsupported, irrelevant,\
        \ or no-longer- used tools. Maintenance tools can include hardware, software,\
        \ and firmware items and may be pre-installed, brought in with maintenance\
        \ personnel on media, cloud-based, or downloaded from a website. Such tools\
        \ can be vehicles for transporting malicious code, either intentionally or\
        \ unintentionally, into a facility and subsequently into systems. Maintenance\
        \ tools can include hardware and software diagnostic test equipment and packet\
        \ sniffers. The hardware and software components that support maintenance\
        \ and are a part of the system (including the software implementing utilities\
        \ such as \u201Cping,\u201D \u201Cls,\u201D \u201Cipconfig,\u201D or the hardware\
        \ and software implementing the monitoring port of an Ethernet switch) are\
        \ not addressed by maintenance tools. \nRelated Controls: MA-2, PE-16."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-3(1)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-3
      ref_id: MA-3(1)
      name: MAINTENANCE TOOLS | INSPECT TOOLS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1599
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-3(1)
      description: Inspect the maintenance tools used by maintenance personnel for
        improper or unauthorized modifications.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1600
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-3(1)
      description: "Discussion: Maintenance tools can be directly brought into a facility\
        \ by maintenance personnel or downloaded from a vendor\u2019s website. If,\
        \ upon inspection of the maintenance tools, organizations determine that the\
        \ tools have been modified in an improper manner or the tools contain malicious\
        \ code, the incident is handled consistent with organizational policies and\
        \ procedures for incident handling. \nRelated Controls: SI-7."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-3(2)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-3
      ref_id: MA-3(2)
      name: MAINTENANCE TOOLS | INSPECT MEDIA
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1602
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-3(2)
      description: Check media containing diagnostic and test programs for malicious
        code before the media are used in the system.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1603
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-3(2)
      description: "Discussion: If, upon inspection of media containing maintenance,\
        \ diagnostic, and test programs, organizations determine that the media contains\
        \ malicious code, the incident is handled consistent with organizational incident\
        \ handling policies and procedures. \nRelated Controls: SI-3."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-3(3)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-3
      ref_id: MA-3(3)
      name: MAINTENANCE TOOLS | PREVENT UNAUTHORIZED REMOVAL
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1605
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-3(3)
      description: 'Prevent the removal of maintenance equipment containing organizational
        information by:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-3(3)-a
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1605
      ref_id: MA-3(3)-a
      description: Verifying that there is no organizational information contained
        on the equipment;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-3(3)-b
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1605
      ref_id: MA-3(3)-b
      description: Sanitizing or destroying the equipment;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-3(3)-c
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1605
      ref_id: MA-3(3)-c
      description: Retaining the equipment within the facility; or
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-3(3)-d
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1605
      ref_id: MA-3(3)-d
      description: Obtaining an exemption from organizational personnel with system
        maintenance responsibilities explicitly authorizing removal of the equipment
        from the facility.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1610
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-3(3)
      description: "Discussion: Organizational information includes all information\
        \ owned by organizations and any information provided to organizations for\
        \ which the organizations serve as information stewards. \nRelated Controls:\
        \ MP-6"
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-4
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.16
      ref_id: MA-4
      name: NONLOCAL MAINTENANCE
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-4-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-4
      ref_id: MA-4-a
      description: Approve and monitor nonlocal maintenance and diagnostic activities;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-4-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-4
      ref_id: MA-4-b
      description: Allow the use of nonlocal maintenance and diagnostic tools only
        as consistent with organizational policy and documented in the security plan
        for the system;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-4-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-4
      ref_id: MA-4-c
      description: Employ strong authentication in the establishment of nonlocal maintenance
        and diagnostic sessions;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-4-d
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-4
      ref_id: MA-4-d
      description: Maintain records for nonlocal maintenance and diagnostic activities;
        and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-4-e
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-4
      ref_id: MA-4-e
      description: Terminate session and network connections when nonlocal maintenance
        is completed.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1617
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-4
      description: 'Discussion: Nonlocal maintenance and diagnostic activities are
        conducted by individuals who communicate through either an external or internal
        network. Local maintenance and diagnostic activities are carried out by individuals
        who are physically present at the system location and not communicating across
        a network connection. Authentication techniques used to establish nonlocal
        maintenance and diagnostic sessions reflect the network access requirements
        in IA-2. Strong authentication requires authenticators that are resistant
        to replay attacks and employ multi-factor authentication. Strong authenticators
        include PKI where certificates are stored on a token protected by a password,
        passphrase, or biometric. Enforcing requirements in MA-4 is accomplished,
        in part, by other controls.

        Related Controls: AC-2, AC-3, AC-6, AC-17, AU-2, AU-3, IA-2, IA-4, IA-5, IA-8,
        MA-2, MA5, PL-2, SC-7, SC-10.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-5
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.16
      ref_id: MA-5
      name: MAINTENANCE PERSONNEL
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-5-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-5
      ref_id: MA-5-a
      description: Establish a process for maintenance personnel authorization and
        maintain a list of authorized maintenance organizations or personnel;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-5-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-5
      ref_id: MA-5-b
      description: Verify that non-escorted personnel performing maintenance on the
        system possess the required access authorizations; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-5-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-5
      ref_id: MA-5-c
      description: Designate organizational personnel with required access authorizations
        and technical competence to supervise the maintenance activities of personnel
        who do not possess the required access authorizations.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1622
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-5
      description: "Discussion: Maintenance personnel refers to individuals who perform\
        \ hardware or software maintenance on organizational systems, while PE-2 addresses\
        \ physical access for individuals whose maintenance duties place them within\
        \ the physical protection perimeter of the systems. Technical competence of\
        \ supervising individuals relates to the maintenance performed on the systems,\
        \ while having required access authorizations refers to maintenance on and\
        \ near the systems. Individuals not previously identified as authorized maintenance\
        \ personnel\u2014such as information technology manufacturers, vendors, systems\
        \ integrators, and consultants\u2014may require privileged access to organizational\
        \ systems, such as when they are required to conduct maintenance activities\
        \ with little or no notice. Based on organizational assessments of risk, organizations\
        \ may issue temporary credentials to these individuals. Temporary credentials\
        \ may be for one-time use or for very limited time periods. \nRelated Controls:\
        \ AC-2, AC-3, AC-5, AC-6, IA-2, IA-8, MA-4, MP-2, PE-2, PE-3, PS-7, RA-3."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-6
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.16
      ref_id: MA-6
      name: TIMELY MAINTENANCE
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1624
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-6
      description: Obtain maintenance support and/or spare parts for critical system
        components that process, store, and transmit CJI within agency-defined recovery
        time and recovery point objectives of failure.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1625
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ma-6
      description: "Discussion: Organizations specify the system components that result\
        \ in increased risk to organizational operations and assets, individuals,\
        \ other organizations, or the Nation when the functionality provided by those\
        \ components is not operational. Organizational actions to obtain maintenance\
        \ support include having appropriate contracts in place. \nRelated Controls:\
        \ CM-8, CP-2, CP-7, RA-7, SA-15, SR-2, SR-3."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.17
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5
      ref_id: '5.17'
      name: PLANNING (PL)
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-1
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.17
      ref_id: PL-1
      name: POLICY AND PROCEDURES
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-1-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-1
      ref_id: PL-1-a
      description: 'Develop, document, and disseminate to organizational personnel
        with planning responsibilities:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-1-a-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-1-a
      ref_id: PL-1-a-1
      description: 'Agency-level planning policy that:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-1-a-1-c
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-1-a-1
      ref_id: PL-1-a-1-c
      description: Addresses purpose, scope, roles, responsibilities, management commitment,
        coordination among organizational entities, and compliance; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-1-a-1-d
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-1-a-1
      ref_id: PL-1-a-1-d
      description: Is consistent with applicable laws, executive orders, directives,
        regulations, policies, standards, and guidelines; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-1-a-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-1-a
      ref_id: PL-1-a-2
      description: Procedures to facilitate the implementation of the planning policy
        and the associated planning controls;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-1-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-1
      ref_id: PL-1-b
      description: Designate organizational personnel with information security and
        privacy responsibilities to manage the development, documentation, and dissemination
        of the planning policy and procedures; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-1-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-1
      ref_id: PL-1-c
      description: 'Review and update the current planning:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-1-c-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-1-c
      ref_id: PL-1-c-1
      description: Policy annually and following; any security incidents involving
        unauthorized access to CJI or systems used to process, store, or transmit
        CJI and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-1-c-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-1-c
      ref_id: PL-1-c-2
      description: Procedures annually and following any security incidents involving
        unauthorized access to CJI or systems used to process, store, or transmit
        CJI.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1637
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-1
      description: "Discussion: Planning policy and procedures for the controls in\
        \ the PL family implemented within systems and organizations. The risk management\
        \ strategy is an important factor in establishing such policies and procedures.\
        \ Policies and procedures contribute to security and privacy assurance. Therefore,\
        \ it is important that security and privacy programs collaborate on their\
        \ development. Security and privacy program policies and procedures at the\
        \ organization level are preferable, in general, and may obviate the need\
        \ for mission level or system-specific policies and procedures. The policy\
        \ can be included as part of the general security and privacy policy or be\
        \ represented by multiple policies that reflect the complex nature of organizations.\
        \ Procedures can be established for security and privacy programs, for mission/business\
        \ processes, and for systems, if needed. Procedures describe how the policies\
        \ or controls are implemented and can be directed at the individual or role\
        \ that is the object of the procedure. Procedures can be documented in system\
        \ security and privacy plans or in one or more separate documents. Events\
        \ that may precipitate an update to planning policy and procedures include,\
        \ but are not limited to, assessment or audit findings, security incidents\
        \ or breaches, or changes in laws, executive orders, directives, regulations,\
        \ policies, standards, and guidelines. Simply restating controls does not\
        \ constitute an organizational policy or procedure. \nRelated Controls: PS-8,\
        \ SI-12."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.17
      ref_id: PL-2
      name: SYSTEM SECURITY AND PRIVACY PLANS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2
      ref_id: PL-2-a
      description: 'Develop security and privacy plans for the system that:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2-a-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2-a
      ref_id: PL-2-a-1
      description: "Are consistent with the organization\u2019s enterprise architecture;"
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2-a-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2-a
      ref_id: PL-2-a-2
      description: Explicitly define the constituent system components;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2-a-3
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2-a
      ref_id: PL-2-a-3
      description: Describe the operational context of the system in terms of mission
        and business processes;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2-a-4
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2-a
      ref_id: PL-2-a-4
      description: Identify the individuals that fulfill system roles and responsibilities;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2-a-5
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2-a
      ref_id: PL-2-a-5
      description: Identify the information types processed, stored, and transmitted
        by the system;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2-a-6
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2-a
      ref_id: PL-2-a-6
      description: Provide the security categorization of the system, including supporting
        rationale;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2-a-7
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2-a
      ref_id: PL-2-a-7
      description: Describe any specific threats to the system that are of concern
        to the organization;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2-a-8
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2-a
      ref_id: PL-2-a-8
      description: Provide the results of a privacy risk assessment for systems processing
        personally identifiable information;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2-a-9
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2-a
      ref_id: PL-2-a-9
      description: Describe the operational environment for the system and any dependencies
        on or connections to other systems or system components;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2-a-10
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2-a
      ref_id: PL-2-a-10
      description: Provide an overview of the security and privacy requirements for
        the system;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2-a-11
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2-a
      ref_id: PL-2-a-11
      description: Identify any relevant control baselines or overlays, if applicable;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2-a-12
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2-a
      ref_id: PL-2-a-12
      description: Describe the controls in place or planned for meeting the security
        and privacy requirements, including a rationale for any tailoring decisions;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2-a-13
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2-a
      ref_id: PL-2-a-13
      description: Include risk determinations for security and privacy architecture
        and design decisions;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2-a-14
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2-a
      ref_id: PL-2-a-14
      description: Include security- and privacy-related activities affecting the
        system that require planning and coordination with organizational personnel
        with system security and privacy planning and plan implementation responsibilities;
        system developers; organizational personnel with information security and
        privacy responsibilities; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2-a-15
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2-a
      ref_id: PL-2-a-15
      description: Are reviewed and approved by the authorizing official or designated
        representative prior to plan implementation.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2
      ref_id: PL-2-b
      description: Distribute copies of the plans and communicate subsequent changes
        to the plans to organizational personnel with system security and privacy
        planning and plan implementation responsibilities; system developers; organizational
        personnel with information security and privacy responsibilities;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2
      ref_id: PL-2-c
      description: Review the system security and privacy plans at least annually
        or when required due to system changes or modifications;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2-d
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2
      ref_id: PL-2-d
      description: Update the plans to address changes to the system and environment
        of operation or problems identified during plan implementation or control
        assessments; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2-e
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2
      ref_id: PL-2-e
      description: Protect the plans from unauthorized disclosure and modification.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1659
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-2
      description: 'Discussion: System security and privacy plans are scoped to the
        system and system components within the defined authorization boundary and
        contain an overview of the security and privacy requirements for the system
        and the controls selected to satisfy the requirements. The plans describe
        the intended application of each selected control in the context of the system
        with a sufficient level of detail to correctly implement the control and to
        subsequently assess the effectiveness of the control. The control documentation
        describes how system-specific and hybrid controls are implemented and the
        plans and expectations regarding the functionality of the system. System security
        and privacy plans can also be used in the design and development of systems
        in support of life cycle-based security and privacy engineering processes.
        System security and privacy plans are living documents that are updated and
        adapted throughout the system development life cycle (e.g., during capability
        determination, analysis of alternatives, requests for proposal, and design
        reviews).The CJISSECPOL describes the different types of requirements that
        are relevant to organizations during the system development life cycle and
        the relationship between requirements and controls.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1660
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1659
      description: "Organizations may develop a single, integrated security and privacy\
        \ plan or maintain separate plans. Security and privacy plans relate security\
        \ and privacy requirements to a set of controls and control enhancements.\
        \ The plans describe how the controls and control enhancements meet the security\
        \ and privacy requirements but do not provide detailed, technical descriptions\
        \ of the design or implementation of the controls and control enhancements.\
        \ Security and privacy plans contain sufficient information (including specifications\
        \ of control parameter values for selection and assignment operations explicitly\
        \ or by reference) to enable a design and implementation that is unambiguously\
        \ compliant with the intent of the plans and subsequent determinations of\
        \ risk to organizational operations and assets, individuals, other organizations,\
        \ and the Nation if the plan is implemented. \nSecurity and privacy plans\
        \ need not be single documents. The plans can be a collection of various documents,\
        \ including documents that already exist. Effective security and privacy plans\
        \ make extensive use of references to policies, procedures, and additional\
        \ documents, including design and implementation specifications where more\
        \ detailed information can be obtained. The use of references helps reduce\
        \ the documentation associated with security and privacy programs and maintains\
        \ the security- and privacy-related information in other established management\
        \ and operational areas, including enterprise architecture, system development\
        \ life cycle, systems engineering, and acquisition. Security and privacy plans\
        \ need not contain detailed contingency plan or incident response plan information\
        \ but can instead provide\u2014explicitly or by reference\u2014 sufficient\
        \ information to define what needs to be accomplished by those plans. \nSecurity-\
        \ and privacy-related activities that may require coordination and planning\
        \ with other individuals or groups within the organization include assessments,\
        \ audits, inspections, hardware and software maintenance, acquisition and\
        \ supply chain risk management, patch management, and contingency plan testing.\
        \ Planning and coordination include emergency and nonemergency (i.e., planned\
        \ or non-urgent unplanned) situations. The process defined by organizations\
        \ to plan and coordinate security- and privacy-related activities can also\
        \ be included in other documents, as appropriate. \nRelated Controls: AC-2,\
        \ AC-6, AC-14, AC-17, AC-20, CA-2, CA-3, CA-7, CM-9, CP-2, CP-4, IR-4, IR-8,\
        \ MA-4, MA-5, MP-4, MP-5, PL-8, PL-10, PL-11, RA-3, RA-9, SA-5, SA-22, SI-12,\
        \ SR-2."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-4
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.17
      ref_id: PL-4
      name: RULES OF BEHAVIOR
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-4-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-4
      ref_id: PL-4-a
      description: Establish and provide to individuals requiring access to the system,
        the rules that describe their responsibilities and expected behavior for information
        and system usage, security, and privacy;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-4-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-4
      ref_id: PL-4-b
      description: Receive a documented acknowledgment from such individuals, indicating
        that they have read, understand, and agree to abide by the rules of behavior,
        before authorizing access to information and the system;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-4-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-4
      ref_id: PL-4-c
      description: Review and update the rules of behavior at least annually; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-4-d
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-4
      ref_id: PL-4-d
      description: Require individuals who have acknowledged a previous version of
        the rules of behavior to read and re-acknowledge annually, or when the rules
        are revised or updated.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1666
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-4
      description: "Discussion: Rules of behavior represent a type of access agreement\
        \ for organizational users. Other types of access agreements include nondisclosure\
        \ agreements, conflict-of-interest agreements, and acceptable use agreements\
        \ (see PS-6). Organizations consider rules of behavior based on individual\
        \ user roles and responsibilities and differentiate between rules that apply\
        \ to privileged users and rules that apply to general users. Establishing\
        \ rules of behavior for some types of non-organizational users, including\
        \ individuals who receive information from federal systems, is often not feasible\
        \ given the large number of such users and the limited nature of their interactions\
        \ with the systems. Rules of behavior for organizational and non-organizational\
        \ users can also be established in AC-8. The related controls section provides\
        \ a list of controls that are relevant to organizational rules of behavior.\
        \ PL-4b, the documented acknowledgment portion of the control, may be satisfied\
        \ by the literacy training and awareness and role-based training programs\
        \ conducted by organizations if such training includes rules of behavior.\
        \ Documented acknowledgements for rules of behavior include electronic or\
        \ physical signatures and electronic agreement check boxes or radio buttons.\
        \ \nRelated Controls: AC-2, AC-6, AC-8, AC-17, AC-18, AC-19, AC-20, AT-2,\
        \ AT-3, CM-11, IA-2, IA-4, IA-5, MP-7, PS-6, PS-8, SA-5, SI-12."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-4(1)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-4
      ref_id: PL-4(1)
      name: RULES OF BEHAVIOR | SOCIAL MEDIA AND EXTERNAL SITE/APPLICATION USAGE RESTRICTIONS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1668
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-4(1)
      description: 'Include in the rules of behavior, restrictions on:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-4(1)-a
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-4(1)
      ref_id: PL-4(1)-a
      description: 'Use of social media, social networking sites, and external sites/applications:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-4(1)-b
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-4(1)
      ref_id: PL-4(1)-b
      description: Posting organizational information on public websites; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-4(1)-c
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-4(1)
      ref_id: PL-4(1)-c
      description: Use of organization-provided identifiers (e.g., email addresses)
        and authentication secrets (e.g., passwords) for creating accounts on external
        sites/applications.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1672
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-4
      description: "Discussion: Social media, social networking, and external site/application\
        \ usage restrictions address rules of behavior related to the use of social\
        \ media, social networking, and external sites when organizational personnel\
        \ are using such sites for official duties or in the conduct of official business,\
        \ when organizational information is involved in social media and social networking\
        \ transactions, and when personnel access social media and networking sites\
        \ from organizational systems. Organizations also address specific rules that\
        \ prevent unauthorized entities from obtaining non-public organizational information\
        \ from social media and networking sites either directly or through inference.\
        \ Non-public information includes personally identifiable information and\
        \ system account information. \nRelated Controls: AC-22."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-8
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.17
      ref_id: PL-8
      name: SECURITY AND PRIVACY ARCHITECTURES
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-8-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-8
      ref_id: PL-8-a
      description: 'Develop security and privacy architectures for the system that:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-8-a-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-8-a
      ref_id: PL-8-a-1
      description: Describe the requirements and approach to be taken for protecting
        the confidentiality, integrity, and availability of organizational information;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-8-a-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-8-a
      ref_id: PL-8-a-2
      description: Describe the requirements and approach to be taken for processing
        personally identifiable information to minimize privacy risk to individuals;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-8-a-3
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-8-a
      ref_id: PL-8-a-3
      description: Describe how the architectures are integrated into and support
        the enterprise architecture; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-8-a-4
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-8-a
      ref_id: PL-8-a-4
      description: Describe any assumptions about, and dependencies on, external systems
        and services
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-8-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-8
      ref_id: PL-8-b
      description: Review and update the architectures at least annually or when changes
        to the system or its environment occur to reflect changes in the enterprise
        architecture; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-8-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-8
      ref_id: PL-8-c
      description: Reflect planned architecture changes in security and privacy plans,
        Concept of Operations (CONOPS), criticality analysis, organizational procedures,
        and procurements and acquisitions.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1681
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-8
      description: "Discussion: The security and privacy architectures at the system\
        \ level are consistent with the organization-wide security and privacy architectures\
        \ are integral to and developed as part of the enterprise architecture. The\
        \ architectures include an architectural description, the allocation of security\
        \ and privacy functionality (including controls), security- and privacy related\
        \ information for external interfaces, information being exchanged across\
        \ the interfaces, and the protection mechanisms associated with each interface.\
        \ The architectures can also include other information, such as user roles\
        \ and the access privileges assigned to each role; security and privacy requirements;\
        \ types of information processed, stored, and transmitted by the system; supply\
        \ chain risk management requirements; restoration priorities of information\
        \ and system services; and other protection needs. \n[SP 800-160-1] provides\
        \ guidance on the use of security architectures as part of the system development\
        \ life cycle process.Security and privacy architectures are reviewed and updated\
        \ throughout the system development life cycle, from analysis of alternatives\
        \ through review of the proposed architecture in the RFP responses to the\
        \ design reviews before and during implementation (e.g., during preliminary\
        \ design reviews and critical design reviews). \nIn today\u2019s modern computing\
        \ architectures, it is becoming less common for organizations to control all\
        \ information resources. There may be key dependencies on external information\
        \ services and service providers. Describing such dependencies in the security\
        \ and privacy architectures is necessary for developing a comprehensive mission\
        \ and business protection strategy. Establishing, developing, documenting,\
        \ and maintaining under configuration control a baseline configuration for\
        \ organizational systems is critical to implementing and maintaining effective\
        \ architectures. The development of the architectures is coordinated with\
        \ the senior agency information security officer and the senior agency official\
        \ for privacy to ensure that the controls needed to support security and privacy\
        \ requirements are identified and effectively implemented. In many circumstances,\
        \ there may be no distinction between the security and privacy architecture\
        \ for a system. In other circumstances, security objectives may be adequately\
        \ satisfied, but privacy objectives may only be partially satisfied by the\
        \ security requirements. In these cases, consideration of the privacy requirements\
        \ needed to achieve satisfaction will result in a distinct privacy architecture.\
        \ The documentation, however, may simply reflect the combined architectures.\
        \ \nRelated Controls: CM-2, CM-6, PL-2, PL-7, PL-9, PM-5, RA-9, SA-3, SA-5,\
        \ SA-8, SC-7."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-9
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.17
      ref_id: PL-9
      name: CENTRAL MANAGEMENT
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1683
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-9
      description: The CJISSECPOL is centrally managed by the FBI CJIS ISO.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1684
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-9
      description: "Discussion: Central management refers to organization-wide management\
        \ and implementation of selected controls and processes. This includes planning,\
        \ implementing, assessing, authorizing, and monitoring the organization-defined,\
        \ centrally managed controls and processes. As the central management of controls\
        \ is generally associated with the concept of common (inherited) controls,\
        \ such management promotes and facilitates standardization of control implementations\
        \ and management and the judicious use of organizational resources. Centrally\
        \ managed controls and processes may also meet independence requirements for\
        \ assessments in support of initial and ongoing authorizations to operate\
        \ and as part of organizational continuous monitoring. \nAutomated tools (e.g.,\
        \ security information and event management tools or enterprise security monitoring\
        \ and management tools) can improve the accuracy, consistency, and availability\
        \ of information associated with centrally managed controls and processes.\
        \ Automation can also provide data aggregation and data correlation capabilities;\
        \ alerting mechanisms; and dashboards to support risk-based decision-making\
        \ within the organization. \nAs part of the control selection processes, organizations\
        \ determine the controls that may be suitable for central management based\
        \ on resources and capabilities. It is not always possible to centrally manage\
        \ every aspect of a control. In such cases, the control can be treated as\
        \ a hybrid control with the control managed and implemented centrally or at\
        \ the system level. The controls and control enhancements that are candidates\
        \ for full or partial central management include but are not limited to: AC-2(1),\
        \ AC-2(2), AC-2(3), AC-2(4), AC-4(all), AC-17(1), AC17(2), AC-17(3), AC-17(9),\
        \ AC-18(1), AC-18(3), AC-18(4), AC-18(5), AC-19(4), AC-22, AC-23, \nAT-2(1),\
        \ AT-2(2), AT-3(1), AT-3(2), AT-3(3), AT-4, AU-3, AU-6(1), AU-6(3), AU-6(5),\
        \ AU-\n6(6), AU-6(9), AU-7(1), AU-7(2), AU-11, AU-13, AU-16, CA-2(1), CA-2(2),\
        \ CA-2(3), CA-3(1), CA-3(2), CA-3(3), CA-7(1), CA-9, CM-2(2), CM-3(1), CM-3(4),\
        \ CM-4, CM-6, CM-6(1), CM7(2), CM-7(4), CM-7(5), CM-8(all), CM-9(1), CM-10,\
        \ CM-11, CP-7(all), CP-8(all), SC-43, SI2, SI-3, SI-4(all), SI-7, SI-8. \n\
        Related Controls: PL-8."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-10
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.17
      ref_id: PL-10
      name: BASELINE SELECTION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1686
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-10
      description: Select a control baseline for the system.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1687
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-10
      description: "Discussion: Control baselines are predefined sets of controls\
        \ specifically assembled to address the protection needs of a group, organization,\
        \ or community of interest. Controls are chosen for baselines to either satisfy\
        \ mandates imposed by laws, executive orders, directives, regulations, policies,\
        \ standards, and guidelines or address threats common to all users of the\
        \ baseline under the assumptions specific to the baseline. Baselines represent\
        \ a starting point for the protection of individuals\u2019 privacy, information,\
        \ and information systems with subsequent tailoring actions to manage risk\
        \ in accordance with mission, business, or other constraints (see PL-11).\
        \ Federal control baselines are provided in [SP 800-53B]. The selection of\
        \ a control baseline is determined by the needs of stakeholders. Stakeholder\
        \ needs consider mission and business requirements as well as mandates imposed\
        \ by applicable laws, executive orders, directives, policies, regulations,\
        \ standards, and guidelines. For example, the control baselines in [SP 800-53B]\
        \ are based on the requirements from [FISMA] and [PRIVACT]. The requirements,\
        \ along with the NIST standards and guidelines implementing the legislation,\
        \ direct organizations to select one of the control baselines after the reviewing\
        \ the information types and the information that is processed, stored, and\
        \ transmitted on the system; analyzing the potential adverse impact of the\
        \ loss or compromise of the information or system on the organization\u2019\
        s operations and assets, individuals, other organizations, or the Nation;\
        \ and considering the results from system and organizational risk assessments.\
        \ [CNSSI 1253] provides guidance on control baselines for national security\
        \ systems.\nRelated Controls: PL-2, PL-11, RA-2, RA-3, SA-8."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-11
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.17
      ref_id: PL-11
      name: BASELINE TAILORING
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1689
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-11
      description: Tailor the selected control baseline by applying specified tailoring
        actions.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1690
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:pl-11
      description: "Discussion: The concept of tailoring allows organizations to specialize\
        \ or customize a set of baseline controls by applying a defined set of tailoring\
        \ actions. Tailoring actions facilitate such specialization and customization\
        \ by allowing organizations to develop security and privacy plans that reflect\
        \ their specific mission and business functions, the environments where their\
        \ systems operate, the threats and vulnerabilities that can affect their systems,\
        \ and any other conditions or situations that can impact their mission or\
        \ business success. Tailoring guidance is provided in [SP 800-53B]. Tailoring\
        \ a control baseline is accomplished by identifying and designating common\
        \ controls, applying scoping considerations, selecting compensating controls,\
        \ assigning values to control parameters, supplementing the control baseline\
        \ with additional controls as needed, and providing information for control\
        \ implementation. The general tailoring actions in [SP 800-53B] can be supplemented\
        \ with additional actions based on the needs of organizations. Tailoring actions\
        \ can be applied to the baselines in [SP 800-53B] in accordance with the security\
        \ and privacy requirements from [FISMA], [PRIVACT], and [OMB A-130]. Alternatively,\
        \ other communities of interest adopting different control baselines can apply\
        \ the tailoring actions in [SP 800-53B] to specialize or customize the controls\
        \ that represent the specific needs and concerns of those entities. \nRelated\
        \ Controls: PL-10, RA-2, RA-3, RA-9, SA-8."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.18
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5
      ref_id: '5.18'
      name: CONTINGENCY PLANNING (CP)
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.18-a
      assessable: true
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.18
      ref_id: 5.18-a
      description: 'Develop, document, and disseminate to organizational personnel
        with contingency planning responsibilities:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.18-a-1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.18-a
      ref_id: 5.18-a-1
      description: 'Agency-level contingency planning policy that:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.18-a-1-a
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.18-a-1
      ref_id: 5.18-a-1-a
      description: Addresses purpose, scope, roles, responsibilities, management commitment,
        coordination among organizational entities, and compliance; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.18-a-1-b
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.18-a-1
      ref_id: 5.18-a-1-b
      description: Is consistent with applicable laws, executive orders, directives,
        regulations, policies, standards, and guidelines; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.18-a-2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.18-a
      ref_id: 5.18-a-2
      description: Procedures to facilitate the implementation of the contingency
        planning policy and the associated contingency planning controls;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.18-b
      assessable: true
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.18
      ref_id: 5.18-b
      description: Designate organizational personnel with information security responsibilities
        to manage the development, documentation, and dissemination of the contingency
        planning policy and procedures; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.18-c
      assessable: true
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.18
      ref_id: 5.18-c
      description: 'Review and update the current contingency planning:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.18-c-1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.18-c
      ref_id: 5.18-c-1
      description: Policy annually and following any security incidents involving
        unauthorized access to CJI or systems used to process, store, or transmit
        CJI, or training simulations or exercises; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.18-c-2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.18-c
      ref_id: 5.18-c-2
      description: Procedures annually and following any security incidents involving
        unauthorized access to CJI or systems used to process, store, or transmit
        CJI, or training simulations or exercises.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1701
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.18-c
      description: "Discussion: Contingency planning policy and procedures address\
        \ the controls in the CP family that are implemented within systems and organizations.\
        \ The risk management strategy is an important factor in establishing such\
        \ policies and procedures. Policies and procedures contribute to security\
        \ and privacy assurance. Therefore, it is important that security and privacy\
        \ programs collaborate on the development of contingency planning policy and\
        \ procedures. Security and privacy program policies and procedures at the\
        \ organization level are preferable, in general, and may obviate the need\
        \ for mission- or system-specific policies and procedures. The policy can\
        \ be included as part of the general security and privacy policy or be represented\
        \ by multiple policies that reflect the complex nature of organizations. Procedures\
        \ can be established for security and privacy programs, for mission or business\
        \ processes, and for systems, if needed. Procedures describe how the policies\
        \ or controls are implemented and can be directed at the individual or role\
        \ that is the object of the procedure. Procedures can be documented in system\
        \ security and privacy plans or in one or more separate documents. Events\
        \ that may precipitate an update to contingency planning policy and procedures\
        \ include assessment or audit findings, security incidents or breaches, or\
        \ changes in laws, executive orders, directives, regulations, policies, standards,\
        \ and guidelines. Simply restating controls does not constitute an organizational\
        \ policy or procedure. \nRelated Controls: PS-8, SI-12."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.18
      ref_id: CP-2
      name: CONTINGENCY PLAN
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2
      ref_id: CP-2-a
      description: 'Develop a contingency plan for the system that:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2-a-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2-a
      ref_id: CP-2-a-1
      description: Identifies essential mission and business functions and associated
        contingency requirements;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2-a-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2-a
      ref_id: CP-2-a-2
      description: Provides recovery objectives, restoration priorities, and metrics;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2-a-3
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2-a
      ref_id: CP-2-a-3
      description: Addresses contingency roles, responsibilities, assigned individuals
        with contact information;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2-a-4
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2-a
      ref_id: CP-2-a-4
      description: Addresses maintaining essential mission and business functions
        despite a system disruption, compromise, or failure;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2-a-5
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2-a
      ref_id: CP-2-a-5
      description: Addresses eventual, full system restoration without deterioration
        of the controls originally planned and implemented;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2-a-6
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2-a
      ref_id: CP-2-a-6
      description: Addresses the sharing of contingency information; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2-a-7
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2-a
      ref_id: CP-2-a-7
      description: Is reviewed and approved by agency head or their designee;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2
      ref_id: CP-2-b
      description: Distribute copies of the contingency plan to organizational personnel
        with contingency planning or incident response duties;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2
      ref_id: CP-2-c
      description: Coordinate contingency planning activities with incident handling
        activities;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2-d
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2
      ref_id: CP-2-d
      description: Review the contingency plan for the system annually;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2-e
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2
      ref_id: CP-2-e
      description: Update the contingency plan to address changes to the organization,
        system, or environment of operation and problems encountered during contingency
        plan implementation, execution, or testing;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2-f
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2
      ref_id: CP-2-f
      description: Communicate contingency plan changes to organizational personnel
        with contingency planning or incident response duties;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2-g
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2
      ref_id: CP-2-g
      description: Incorporate lessons learned from contingency plan testing, training,
        or actual contingency activities into contingency testing and training; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2-h
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2
      ref_id: CP-2-h
      description: Protect the contingency plan from unauthorized disclosure and modification.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1718
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2
      description: "Discussion: Contingency planning for systems is part of an overall\
        \ program for achieving continuity of operations for organizational mission\
        \ and business functions. Contingency planning addresses system restoration\
        \ and implementation of alternative mission or business processes when systems\
        \ are compromised or breached. Contingency planning is considered throughout\
        \ the system development life cycle and is a fundamental part of the system\
        \ design. Systems can be designed for redundancy, to provide backup capabilities,\
        \ and for resilience. Contingency plans reflect the degree of restoration\
        \ required for organizational systems since not all systems need to fully\
        \ recover to achieve the level of continuity of operations desired. System\
        \ recovery objectives reflect applicable laws, executive orders, directives,\
        \ regulations, policies, standards, guidelines, organizational risk tolerance,\
        \ and system impact level. \nActions addressed in contingency plans include\
        \ orderly system degradation, system shutdown, fallback to a manual mode,\
        \ alternate information flows, and operating in modes reserved for when systems\
        \ are under attack. By coordinating contingency planning with incident handling\
        \ activities, organizations ensure that the necessary planning activities\
        \ are in place and activated in the event of an incident.Incident response\
        \ planning is part of contingency planning for organizations and is addressed\
        \ in the IR (Incident Response) family. \nRelated Controls: CP-3, CP-4, CP-6,\
        \ CP-7, CP-8, CP-9, CP-10, IR-4, IR-6, IR-8, MA-6, MP2, MP-4, MP-5, PL-2,\
        \ SA-15, SC-7, SC-23, SI-12."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2(1)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2
      ref_id: CP-2(1)
      name: CONTINGENCY PLAN | COORDINATE WITH RELATED PLANS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1720
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2(1)
      description: Coordinate contingency plan development with organizational elements
        responsible for related plans.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1721
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2(1)
      description: "Discussion: Plans that are related to contingency plans include\
        \ Business Continuity Plans, \nDisaster Recovery Plans, Critical Infrastructure\
        \ Plans, Continuity of Operations Plans, Crisis Communications Plans, Insider\
        \ Threat Implementation Plans, Data Breach Response Plans, Cyber Incident\
        \ Response Plans, Breach Response Plans, and Occupant Emergency Plans. \n\
        Related Controls: None."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2(3)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2
      ref_id: CP-2(3)
      name: CONTINGENCY PLAN | RESUME MISSION AND BUSINESS FUNCTIONS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1723
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2(3)
      description: Plan for the resumption of essential mission and business functions
        within twenty-four (24) hours of contingency plan activation.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1724
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2(3)
      description: "Discussion: Organizations may choose to conduct contingency planning\
        \ activities to resume mission and business functions as part of business\
        \ continuity planning or as part of business impact analyses. Organizations\
        \ prioritize the resumption of mission and business functions. The time period\
        \ for resuming mission and business functions may be dependent on the severity\
        \ and extent of the disruptions to the system and its supporting infrastructure.\
        \ \nRelated Controls: None."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2(8)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2
      ref_id: CP-2(8)
      name: CONTINGENCY PLAN | IDENTIFY CRITICAL ASSETS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1726
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2(8)
      description: Identify critical system assets supporting essential mission and
        business functions
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1727
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-2(8)
      description: 'Discussion: Organizations may choose to identify critical assets
        as part of criticality analysis, business continuity planning, or business
        impact analyses. Organizations identify critical system assets so that additional
        controls can be employed (beyond the controls routinely implemented) to help
        ensure that organizational mission and business functions can continue to
        be conducted during contingency operations. The identification of critical
        information assets also facilitates the prioritization of organizational resources.
        Critical system assets include technical and operational aspects. Technical
        aspects include system components, information technology services, information
        technology products, and mechanisms. Operational aspects include procedures
        (i.e., manually executed operations) and personnel (i.e., individuals operating
        technical controls and/or executing manual procedures). Organizational program
        protection plans can assist in identifying critical assets.

        Related Controls: CM-8, RA-9.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-3
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.18
      ref_id: CP-3
      name: CONTINGENCY TRAINING
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-3-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-3
      ref_id: CP-3-a
      description: 'Provide contingency training to system users consistent with assigned
        roles and responsibilities:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-3-a-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-3-a
      ref_id: CP-3-a-1
      description: Within thirty (30) days of assuming a contingency role or responsibility;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-3-a-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-3-a
      ref_id: CP-3-a-2
      description: When required by system changes; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-3-a-3
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-3-a
      ref_id: CP-3-a-3
      description: Annually thereafter; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-3-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-3
      ref_id: CP-3-b
      description: Review and update contingency training content annually and following
        any security incidents involving unauthorized access to CJI or systems used
        to process, store, or transmit CJI, or training simulations or exercises.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1734
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-3
      description: "Discussion: Contingency training provided by organizations is\
        \ linked to the assigned roles and responsibilities of organizational personnel\
        \ to ensure that the appropriate content and level of detail is included in\
        \ such training. For example, some individuals may only need to know when\
        \ and where to report for duty during contingency operations and if normal\
        \ duties are affected; system administrators may require additional training\
        \ on how to establish systems at alternate processing and storage sites; and\
        \ organizational officials may receive more specific training on how to conduct\
        \ mission-essential functions in designated off-site locations and how to\
        \ establish communications with other governmental entities for purposes of\
        \ coordination on contingency- related activities. Training for contingency\
        \ roles or responsibilities reflects the specific continuity requirements\
        \ in the contingency plan. Events that may precipitate an update to contingency\
        \ training content include, but are not limited to, contingency plan testing\
        \ or an actual contingency (lessons learned), assessment or audit findings,\
        \ security incidents or breaches, or changes in laws, executive orders, directives,\
        \ regulations, policies, standards, and guidelines. At the discretion of the\
        \ organization, participation in a contingency plan test or exercise, including\
        \ lessons learned sessions subsequent to the test or exercise, may satisfy\
        \ contingency plan training requirements. \nRelated Controls: AT-2, AT-3,\
        \ AT-4, CP-2, CP-4, CP-8, IR-2, IR-4."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-4
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.18
      ref_id: CP-4
      name: CONTINGENCY PLAN TESTING
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-4-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-4
      ref_id: CP-4-a
      description: 'Test the contingency plan for the system annually using the following
        tests to determine the effectiveness of the plan and the readiness to execute
        the plan: checklists, walkthrough and tabletop exercises, simulations (parallel
        or full interrupt), or comprehensive exercises.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-4-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-4
      ref_id: CP-4-b
      description: Review the contingency plan test results; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-4-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-4
      ref_id: CP-4-c
      description: Initiate corrective actions, if needed.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1739
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-4
      description: "Discussion: Methods for testing contingency plans to determine\
        \ the effectiveness of the plans and identify potential weaknesses include\
        \ checklists, walk-through and tabletop exercises, simulations (parallel or\
        \ full interrupt), and comprehensive exercises. Organizations conduct testing\
        \ based on the requirements in contingency plans and include a determination\
        \ of the effects on organizational operations, assets, and individuals due\
        \ to contingency operations.Organizations have flexibility and discretion\
        \ in the breadth, depth, and timelines of corrective actions. \nRelated Controls:\
        \ AT-3, CP-2, CP-3, CP-8, CP-9, IR-3, IR-4, PL-2, SR-2."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-4(1)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-4
      ref_id: CP-4(1)
      name: CONTINGENCY PLAN TESTING | COORDINATE WITH RELATED PLANS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1741
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-4(1)
      description: Coordinate contingency plan testing with organizational elements
        responsible for related plans.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1742
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-4(1)
      description: "Discussion: Plans related to contingency planning for organizational\
        \ systems include Business Continuity Plans, Disaster Recovery Plans, Continuity\
        \ of Operations Plans, Crisis \nCommunications Plans, Critical Infrastructure\
        \ Plans, Cyber Incident Response Plans, and Occupant Emergency Plans. Coordination\
        \ of contingency plan testing does not require organizations to create organizational\
        \ elements to handle related plans or to align such elements with specific\
        \ plans. However, it does require that if such organizational elements are\
        \ responsible for related plans, organizations coordinate with those elements.\
        \ \nRelated Controls: IR-8."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-6
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.18
      ref_id: CP-6
      name: ALTERNATE STORAGE SITE
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-6-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-6
      ref_id: CP-6-a
      description: Establish an alternate storage site, including necessary agreements
        to permit the storage and retrieval of system backup information; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-6-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-6
      ref_id: CP-6-b
      description: Ensure that the alternate storage site provides controls equivalent
        to that of the primary site.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1746
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-6
      description: "Discussion: Alternate storage sites are geographically distinct\
        \ from primary storage sites and maintain duplicate copies of information\
        \ and data if the primary storage site is not available. Similarly, alternate\
        \ processing sites provide processing capability if the primary processing\
        \ site is not available. Geographically distributed architectures that support\
        \ contingency requirements may be considered alternate storage sites. Items\
        \ covered by alternate storage site agreements include environmental conditions\
        \ at the alternate sites, access rules for systems and facilities, physical\
        \ and environmental protection requirements, and coordination of delivery\
        \ and retrieval of backup media. Alternate storage sites reflect the requirements\
        \ in contingency plans so that organizations can maintain essential mission\
        \ and business functions despite compromise, failure, or disruption in organizational\
        \ systems. \nRelated Controls: CP-2, CP-7, CP-8, CP-9, CP-10, MP-4, MP-5,\
        \ PE-3."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-6(1)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-6
      ref_id: CP-6(1)
      name: ALTERNATE STORAGE SITE | SEPARATION FROM PRIMARY SITE
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1748
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-6(1)
      description: Identify an alternate storage site that is sufficiently separated
        from the primary storage site to reduce susceptibility to the same threats.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1749
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-6(1)
      description: "Discussion: Threats that affect alternate storage sites are defined\
        \ in organizational risk assessments and include natural disasters, structural\
        \ failures, hostile attacks, and errors of omission or commission. Organizations\
        \ determine what is considered a sufficient degree of separation between primary\
        \ and alternate storage sites based on the types of threats that are of concern.\
        \ For threats such as hostile attacks, the degree of separation between sites\
        \ is less relevant. \nRelated Controls: RA-3."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-6(3)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-6
      ref_id: CP-6(3)
      name: ALTERNATE STORAGE SITE | ACCESSIBILITY
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1751
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-6(3)
      description: Identify potential accessibility problems to the alternate storage
        site in the event of an area-wide disruption or disaster and outline explicit
        mitigation actions.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1752
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-6(3)
      description: "Discussion: Area-wide disruptions refer to those types of disruptions\
        \ that are broad in geographic scope with such determinations made by organizations\
        \ based on organizational assessments of risk. Explicit mitigation actions\
        \ include duplicating backup information at other alternate storage sites\
        \ if access problems occur at originally designated alternate sites or planning\
        \ for physical access to retrieve backup information if electronic accessibility\
        \ to the alternate site is disrupted. \nRelated Controls: RA-3."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-7
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.18
      ref_id: CP-7
      name: ALTERNATE PROCESSING SITE
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-7-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-7
      ref_id: CP-7-a
      description: Establish an alternate processing site, including necessary agreements
        to permit the transfer and resumption of operations for essential mission
        and business functions within the time period defined in the system contingency
        plan(s) when the primary processing capabilities are unavailable;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-7-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-7
      ref_id: CP-7-b
      description: Make available at the alternate processing site, the equipment
        and supplies required to transfer and resume operations or put contracts in
        place to support delivery to the site within the organization-defined time
        period for transfer and resumption; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-7-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-7
      ref_id: CP-7-c
      description: Provide controls at the alternate processing site that are equivalent
        to those at the primary site.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1757
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-7
      description: "Discussion: Alternate processing sites are geographically distinct\
        \ from primary processing sites and provide processing capability if the primary\
        \ processing site is not available. The alternate processing capability may\
        \ be addressed using a physical processing site or other alternatives, such\
        \ as failover to a cloud-based service provider or other internally or externally\
        \ provided processing service. Geographically distributed architectures that\
        \ support contingency requirements may also be considered alternate processing\
        \ sites. Controls that are covered by alternate processing site agreements\
        \ include the environmental conditions at alternate sites, access rules, physical\
        \ and environmental protection requirements, and the coordination for the\
        \ transfer and assignment of personnel. Requirements are allocated to alternate\
        \ processing sites that reflect the requirements in contingency plans to maintain\
        \ essential mission and business functions despite disruption, compromise,\
        \ or failure in organizational systems. \nRelated Controls: CP-2, CP-6, CP-8,\
        \ CP-9, CP-10, MA-6, PE-3, PE-11, PE-12, PE-17."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-7(1)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-7
      ref_id: CP-7(1)
      name: ALTERNATE PROCESSING SITE | SEPARATION FROM PRIMARY SITE
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1759
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-7(1)
      description: Identify an alternate processing site that is sufficiently separated
        from the primary processing site to reduce susceptibility to the same threats.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1760
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-7(1)
      description: "Discussion: Threats that affect alternate processing sites are\
        \ defined in organizational assessments of risk and include natural disasters,\
        \ structural failures, hostile attacks, and errors of omission or commission.\
        \ Organizations determine what is considered a sufficient degree of separation\
        \ between primary and alternate processing sites based on the types of threats\
        \ that are of concern. For threats such as hostile attacks, the degree of\
        \ separation between sites is less relevant. \nRelated Controls: RA-3."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-7(2)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-7
      ref_id: CP-7(2)
      name: ALTERNATE PROCESSING SITE | ACCESSIBILITY
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1762
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-7(2)
      description: Identify potential accessibility problems to alternate processing
        sites in the event of an areawide disruption or disaster and outlines explicit
        mitigation actions.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1763
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-7(2)
      description: 'Discussion: Area-wide disruptions refer to those types of disruptions
        that are broad in geographic scope with such determinations made by organizations
        based on organizational assessments of risk. Related Controls: RA-3.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-7(3)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-7
      ref_id: CP-7(3)
      name: ALTERNATE PROCESSING SITE | PRIORITY OF SERVICE
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1765
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-7(3)
      description: Develop alternate processing site agreements that contain priority-of-service
        provisions in accordance with availability requirements (including recovery
        time objectives).
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1766
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-7(3)
      description: "Discussion: Priority of service agreements refer to negotiated\
        \ agreements with service providers that ensure that organizations receive\
        \ priority treatment consistent with their availability requirements and the\
        \ availability of information resources for logical alternate processing and/or\
        \ at the physical alternate processing site. Organizations establish recovery\
        \ time objectives as part of contingency planning. \nRelated Controls: None."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-8
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.18
      ref_id: CP-8
      name: TELECOMMUNICATIONS SERVICES
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1768
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-8
      description: Establish alternate telecommunications services, including necessary
        agreements to permit the resumption of system operations for essential mission
        and business functions within the time period as defined in the system contingency
        plan(s) when the primary telecommunications capabilities are unavailable at
        either the primary or alternate processing or storage sites.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1769
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-8
      description: "Discussion: Telecommunications services (for data and voice) for\
        \ primary and alternate processing and storage sites are in scope for CP-8.\
        \ Alternate telecommunications services reflect the continuity requirements\
        \ in contingency plans to maintain essential mission and business functions\
        \ despite the loss of primary telecommunications services. Organizations may\
        \ specify different time periods for primary or alternate sites. Alternate\
        \ telecommunications services include additional organizational or commercial\
        \ ground-based circuits or lines, network-based approaches to telecommunications,\
        \ or the use of satellites. Organizations consider factors such as availability,\
        \ quality of service, and access when entering into alternate telecommunications\
        \ agreements. \nRelated Controls: CP-2, CP-6, CP-7, SC-7."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-8(1)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-8
      ref_id: CP-8(1)
      name: TELECOMMUNICATIONS SERVICES | PRIORITY OF SERVICE PROVISIONS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-8(1)-a
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-8(1)
      ref_id: CP-8(1)-a
      description: Develop primary and alternate telecommunications service agreements
        that contain priority-of-service provisions in accordance with availability
        requirements (including recovery time objectives); and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-8(1)-b
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-8(1)
      ref_id: CP-8(1)-b
      description: Request Telecommunications Service Priority for all telecommunications
        services used for national security emergency preparedness if the primary
        and/or alternate telecommunications services are provided by a common carrier.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1773
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-8(1)
      description: "Discussion: Organizations consider the potential mission or business\
        \ impact in situations where telecommunications service providers are servicing\
        \ other organizations with similar priority of service provisions. Telecommunications\
        \ Service Priority (TSP) is a Federal Communications Commission (FCC) program\
        \ that directs telecommunications service providers (e.g., wireline and wireless\
        \ phone companies) to give preferential treatment to users enrolled in the\
        \ program when they need to add new lines or have their lines restored following\
        \ a disruption of service, regardless of the cause. The FCC sets the rules\
        \ and policies for the \nTSP program, and the Department of Homeland Security\
        \ manages the TSP program. The TSP program is always in effect and not contingent\
        \ on a major disaster or attack taking place. Federal sponsorship is required\
        \ to enroll in the TSP program. \nRelated Controls: None."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-8(2)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-8
      ref_id: CP-8(2)
      name: TELECOMMUNICATIONS SERVICES | SINGLE POINTS OF FAILURE
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1775
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-8(2)
      description: Obtain alternate telecommunications services to reduce the likelihood
        of sharing a single point of failure with primary telecommunications services.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1776
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-8(2)
      description: "Discussion: In certain circumstances, telecommunications service\
        \ providers or services may share the same physical lines, which increases\
        \ the vulnerability of a single failure point. It is important to have provider\
        \ transparency for the actual physical transmission capability for telecommunication\
        \ services. \nRelated Controls: None."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-9
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.18
      ref_id: CP-9
      name: SYSTEM BACKUP
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-9-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-9
      ref_id: CP-9-a
      description: Conduct backups of user-level information contained in operational
        systems for essential business functions as required by the contingency plans;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-9-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-9
      ref_id: CP-9-b
      description: Conduct backups of system-level information contained in the system
        as required by the contingency plans;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-9-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-9
      ref_id: CP-9-c
      description: Conduct backups of system documentation, including security- and
        privacy-related documentation as required by the contingency plans; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-9-d
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-9
      ref_id: CP-9-d
      description: Protect the confidentiality, integrity, and availability of backup
        information.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1782
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-9
      description: "Discussion: System-level information includes system state information,\
        \ operating system software, middleware, application software, and licenses.\
        \ User-level information includes information other than system-level information.\
        \ Mechanisms employed to protect the integrity of system backups include digital\
        \ signatures and cryptographic hashes. Protection of system backup information\
        \ while in transit is addressed by MP-5 and SC-8. System backups reflect the\
        \ requirements in contingency plans as well as other organizational requirements\
        \ for backing up information. Organizations may be subject to laws, executive\
        \ orders, directives, regulations, or policies with requirements regarding\
        \ specific categories of information (e.g., criminal justice information).\
        \ Organizational personnel consult with the senior agency official for privacy\
        \ and legal counsel regarding such requirements. \nRelated Controls: CP-2,\
        \ CP-6, CP-10, MP-4, MP-5, SC-8, SC-12, SC-13, SI-4."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-9(1)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-9
      ref_id: CP-9(1)
      name: SYSTEM BACKUP | TESTING FOR RELIABILITY AND INTEGRITY
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1784
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-9(1)
      description: Test backup information as required by the contingency plans to
        verify media reliability and information integrity.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1785
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-9(1)
      description: "Discussion: Organizations need assurance that backup information\
        \ can be reliably retrieved. Reliability pertains to the systems and system\
        \ components where the backup information is stored, the operations used to\
        \ retrieve the information, and the integrity of the information being retrieved.\
        \ Independent and specialized tests can be used for each of the aspects of\
        \ reliability. For example, decrypting and transporting (or transmitting)\
        \ a random sample of backup files from the alternate storage or backup site\
        \ and comparing the information to the same information at the primary processing\
        \ site can provide such assurance. \nRelated Controls: CP-4."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-9(8)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-9
      ref_id: CP-9(8)
      name: SYSTEM BACKUP | CRYPTOGRAPHIC PROTECTION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1787
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-9(8)
      description: Implement cryptographic mechanisms to prevent unauthorized disclosure
        and modification of CJI.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1788
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-9(8)
      description: "Discussion: The selection of cryptographic mechanisms is based\
        \ on the need to protect the confidentiality and integrity of backup information.\
        \ The strength of mechanisms selected is commensurate with the security category\
        \ or classification of the information. Cryptographic protection applies to\
        \ system backup information in storage at both primary and alternate locations.\
        \ Organizations that implement cryptographic mechanisms to protect information\
        \ at rest also consider cryptographic key management solutions. \nRelated\
        \ Controls: SC-12, SC-13, SC-28."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-10
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.18
      ref_id: CP-10
      name: SYSTEM RECOVERY AND RECONSTITUTION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1790
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-10
      description: Provide for the recovery and reconstitution of the system to a
        known state within the timeframe as required by the contingency plans after
        a disruption, compromise, or failure.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1791
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-10
      description: "Discussion: Recovery is executing contingency plan activities\
        \ to restore organizational mission and business functions. Reconstitution\
        \ takes place following recovery and includes activities for returning systems\
        \ to fully operational states. Recovery and reconstitution operations reflect\
        \ mission and business priorities; recovery point, recovery time, and reconstitution\
        \ objectives; and organizational metrics consistent with contingency plan\
        \ requirements. Reconstitution includes the deactivation of interim system\
        \ capabilities that may have been needed during recovery operations. Reconstitution\
        \ also includes assessments of fully restored system capabilities, reestablishment\
        \ of continuous monitoring activities, system reauthorization (if required),\
        \ and activities to prepare the system and organization for future disruptions,\
        \ breaches, compromises, or failures. Recovery and reconstitution capabilities\
        \ can include automated mechanisms and manual procedures. Organizations establish\
        \ recovery time and recovery point objectives as part of contingency planning.\
        \ \nRelated Controls: CP-2, CP-4, CP-6, CP-7, CP-9, IR-4, SA-8."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-10(2)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-10
      ref_id: CP-10(2)
      name: SYSTEM RECOVERY AND RECONSTITUTION | TRANSACTION RECOVERY
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1793
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-10(2)
      description: Implement transaction recovery for systems that are transaction-based.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1794
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:cp-10(2)
      description: "Discussion: Transaction-based systems include database management\
        \ systems and transaction processing systems. Mechanisms supporting transaction\
        \ recovery include transaction rollback and transaction journaling. \nRelated\
        \ Controls: None."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.19
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5
      ref_id: '5.19'
      name: RISK ASSESSMENT (RA)
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-1
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.19
      ref_id: RA-1
      name: POLICY AND PROCEDURES
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-1-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-1
      ref_id: RA-1-a
      description: 'Develop, document, and disseminate to organizational personnel
        with risk assessment responsibilities:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-1-a-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-1-a
      ref_id: RA-1-a-1
      description: 'Agency Level risk assessment policy that:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-1-a-1-a
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-1-a-1
      ref_id: RA-1-a-1-a
      description: Addresses purpose, scope, roles, responsibilities, management commitment,
        coordination among organizational entities, and compliance; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-1-a-1-b
      assessable: true
      depth: 6
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-1-a-1
      ref_id: RA-1-a-1-b
      description: Is consistent with applicable laws, executive orders, directives,
        regulations, policies, standards, and guidelines; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-1-a-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-1-a
      ref_id: RA-1-a-2
      description: Procedures to facilitate the implementation of the risk assessment
        policy and the associated risk assessment controls;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-1-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-1
      ref_id: RA-1-b
      description: Designate organizational personnel with security and privacy responsibilities
        to manage the development, documentation, and dissemination of the risk assessment
        policy and procedures; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-1-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-1
      ref_id: RA-1-c
      description: 'Review and update the current risk assessment:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-1-c-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-1-c
      ref_id: RA-1-c-1
      description: Policy annually and following any security incidents involving
        unauthorized access to CJI or systems used to process, store, or transmit
        CJI; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-1-c-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-1-c
      ref_id: RA-1-c-2
      description: Procedures annually and following any security incidents involving
        unauthorized access to CJI or systems used to process, store, or transmit
        CJI.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1806
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-1-c
      description: 'Discussion:Risk assessment policy and procedures address the controls
        in the RA family that are implemented within systems and organizations. The
        risk management strategy is an important factor in establishing such policies
        and procedures. Policies and procedures contribute to security and privacy
        assurance. Therefore, it is important that security and privacy programs collaborate
        on the development of risk assessment policy and procedures. Security and
        privacy program policies and procedures at the organization level are preferable,
        in general, and may obviate the need for mission- or system-specific policies
        and procedures. The policy can be included as part of the general security
        and privacy policy or be represented by multiple policies reflecting the complex
        nature of organizations. Procedures can be established for security and privacy
        programs, for mission or business processes, and for systems, if needed. Procedures
        describe how the policies or controls are implemented and can be directed
        at the individual or role that is the object of the procedure. Procedures
        can be documented in system security and privacy plans or in one or more separate
        documents. Events that may precipitate an update to risk assessment policy
        and procedures include assessment or audit findings, security incidents or
        breaches, or changes in laws, executive orders, directives, regulations, policies,
        standards, and guidelines.Simply restating controls does not constitute an
        organizational policy or procedure.

        Related Controls:PS-8, SI-12.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-2
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.19
      ref_id: RA-2
      name: SECURITY CATEGORIZATION
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-2-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-2
      ref_id: RA-2-a
      description: Categorize the system and information it processes, stores, and
        transmits;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-2-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-2
      ref_id: RA-2-b
      description: Document the security categorization results, including supporting
        rationale, in the security plan for the system; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-2-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-2
      ref_id: RA-2-c
      description: Verify that the authorizing official or authorizing official designated
        representative reviews and approves the security categorization decision.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1811
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-2
      description: "Discussion: Security categories describe the potential adverse\
        \ impacts or negative consequences to organizational operations, organizational\
        \ assets, and individuals if organizational information and systems are compromised\
        \ through a loss of confidentiality, integrity, or availability. Security\
        \ categorization is also a type of asset loss characterization in systems\
        \ security engineering processes that is carried out throughout the system\
        \ development life cycle. Organizations can use privacy risk assessments or\
        \ privacy impact assessments to better understand the potential adverse effects\
        \ on individuals. The FBI CJIS Advisory Policy Board (APB) has assigned a\
        \ security categorization of \u201Cmoderate\u201D for CJI and systems that\
        \ process, store, and transmit CJI.\nOrganizations conduct the security categorization\
        \ process as an organization-wide activity with the direct involvement of\
        \ chief information officers, senior agency information security officers,\
        \ senior agency officials for privacy, system owners, mission and business\
        \ owners, and information owners or stewards.\nSecurity categorization processes\
        \ facilitate the development of inventories of information assets and, along\
        \ with CM-8, mappings to specific system components where information is processed,\
        \ stored, or transmitted. The security categorization process is revisited\
        \ throughout the system development life cycle to ensure that the security\
        \ categories remain accurate and relevant. \nRelated Controls: CM-8, MP-4,\
        \ PL-2, PL-10, PL-11, RA-3, RA-5, RA-7, SA-8, SC-7, SI-12."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-3
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.19
      ref_id: RA-3
      name: RISK ASSESSMENT
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-3-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-3
      ref_id: RA-3-a
      description: 'Conduct a risk assessment, including:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-3-a-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-3-a
      ref_id: RA-3-a-1
      description: Identifying threats to and vulnerabilities in the system;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-3-a-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-3-a
      ref_id: RA-3-a-2
      description: Determining the likelihood and magnitude of harm from unauthorized
        access, use, disclosure, disruption, modification, or destruction of the system,
        the information it processes, stores, or transmits, and any related information;
        and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-3-a-3
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-3-a
      ref_id: RA-3-a-3
      description: Determining the likelihood and impact of adverse effects on individuals
        arising from the processing of personally identifiable information;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-3-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-3
      ref_id: RA-3-b
      description: Integrate risk assessment results and risk management decisions
        from the organization and mission or business process perspectives with system-level
        risk assessments;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-3-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-3
      ref_id: RA-3-c
      description: Document risk assessment results in a risk assessment report;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-3-d
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-3
      ref_id: RA-3-d
      description: Review risk assessment results at least quarterly;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-3-e
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-3
      ref_id: RA-3-e
      description: Disseminate risk assessment results to organizational personnel
        with risk assessment responsibilities and organizational personnel with security
        and privacy responsibilities; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-3-f
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-3
      ref_id: RA-3-f
      description: Update the risk assessment at least quarterly or when there are
        significant changes to the system, its environment of operation, or other
        conditions that may impact the security or privacy state of the system.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1822
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-3
      description: "Discussion: Risk assessments consider threats, vulnerabilities,\
        \ likelihood, and impact to organizational operations and assets, individuals,\
        \ other organizations, and the Nation. Risk assessments also consider risk\
        \ from external parties, including contractors who operate systems on behalf\
        \ of the organization, individuals who access organizational systems, service\
        \ providers, and outsourcing entities. \nOrganizations can conduct risk assessments\
        \ at all three levels in the risk management hierarchy (i.e., organization\
        \ level, mission/business process level, or information system level) and\
        \ at any stage in the system development life cycle. Risk assessments can\
        \ also be conducted at various steps in the Risk Management Framework, including\
        \ preparation, categorization, control selection, control implementation,\
        \ control assessment, authorization, and control monitoring. Risk assessment\
        \ is an ongoing activity carried out throughout the system development life\
        \ cycle. \nRisk assessments can also address information related to the system,\
        \ including system design, the intended use of the system, testing results,\
        \ and supply chain-related information or artifacts. Risk assessments can\
        \ play an important role in control selection processes, particularly during\
        \ the application of tailoring guidance and in the earliest phases of capability\
        \ determination. \nRelated Controls: CA-3, CA-6, CM-4, CP-6, CP-7, IA-8, MA-5,\
        \ PE-3, PE-8, PL-2, PL-10, PL11, RA-2, RA-5, RA-7, SA-8, SA-9, SI-12."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-5
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.19
      ref_id: RA-5
      name: VULNERABILITY MONITORING AND SCANNING
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-5-a
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-5
      ref_id: RA-5-a
      description: Monitor and scan for vulnerabilities in the system and hosted applications
        at least monthly and when new vulnerabilities potentially affecting the system
        are identified and reported;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-5-b
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-5
      ref_id: RA-5-b
      description: 'Employ vulnerability monitoring tools and techniques that facilitate
        interoperability among tools and automate parts of the vulnerability management
        process by using standards for:'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-5-b-1
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-5-b
      ref_id: RA-5-b-1
      description: Enumerating platforms, software flaws, and improper configurations;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-5-b-2
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-5-b
      ref_id: RA-5-b-2
      description: Formatting checklists and test procedures; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-5-b-3
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-5-b
      ref_id: RA-5-b-3
      description: Measuring vulnerability impact;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-5-c
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-5
      ref_id: RA-5-c
      description: Analyze vulnerability scan reports and results from vulnerability
        monitoring;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-5-d
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-5
      ref_id: RA-5-d
      description: Remediate legitimate vulnerabilities within the number of days
        listed;
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1831
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-5-d
      description: "\u2022\tCritical\u201315 days"
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1832
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-5-d
      description: "\u2022\tHigh\u201330 days"
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1833
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-5-d
      description: "\u2022\tMedium\u201360 days"
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1834
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-5-d
      description: "\u2022\tLow\u201390 days; and"
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-5-e
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-5
      ref_id: RA-5-e
      description: Share information obtained from the vulnerability monitoring process
        and control assessments with organizational personnel with risk assessment,
        control assessment, and vulnerability scanning responsibilities to help eliminate
        similar vulnerabilities in other systems; and
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-5-f
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-5
      ref_id: RA-5-f
      description: Employ vulnerability monitoring tools that include the capability
        to readily update the vulnerabilities to be scanned.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1837
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-5
      description: "Discussion: Security categorization of information and systems\
        \ guides the frequency and comprehensiveness of vulnerability monitoring (including\
        \ scans). Organizations determine the required vulnerability monitoring for\
        \ system components, ensuring that the potential sources of vulnerabilities\u2014\
        such as infrastructure components (e.g., switches, routers, guards, sensors),\
        \ networked printers, scanners, and copiers\u2014are not overlooked. The capability\
        \ to readily update vulnerability monitoring tools as new vulnerabilities\
        \ are discovered and announced and as new scanning methods are developed helps\
        \ to ensure that new vulnerabilities are not missed by employed vulnerability\
        \ monitoring tools. The vulnerability monitoring tool update process helps\
        \ to ensure that potential vulnerabilities in the system are identified and\
        \ addressed as quickly as possible. Vulnerability monitoring and analyses\
        \ for custom software may require additional approaches, such as static analysis,\
        \ dynamic analysis, binary analysis, or a hybrid of the three approaches.\
        \ Organizations can use these analysis approaches in source code reviews and\
        \ in a variety of tools, including web-based application scanners, static\
        \ analysis tools, and binary analyzers. \nVulnerability monitoring includes\
        \ scanning for patch levels; scanning for functions, ports, protocols, and\
        \ services that should not be accessible to users or devices; and scanning\
        \ for flow control mechanisms that are improperly configured or operating\
        \ incorrectly. Vulnerability monitoring may also include continuous vulnerability\
        \ monitoring tools that use instrumentation to continuously analyze components.\
        \ Instrumentation-based tools may improve accuracy and may be run throughout\
        \ an organization without scanning. \nVulnerability monitoring tools that\
        \ facilitate interoperability include tools that are Security Content Automated\
        \ Protocol (SCAP)-validated. Thus, organizations consider using scanning tools\
        \ that express vulnerabilities in the Common Vulnerabilities and Exposures\
        \ (CVE) naming convention and that employ the Open Vulnerability Assessment\
        \ Language (OVAL) to determine the presence of vulnerabilities. Sources for\
        \ vulnerability information include the Common Weakness Enumeration (CWE)\
        \ listing and the National Vulnerability Database (NVD). Control assessments,\
        \ such as red team exercises, provide additional sources of potential vulnerabilities\
        \ for which to scan. Organizations also consider using scanning tools that\
        \ express vulnerability impact by the Common Vulnerability Scoring System\
        \ (CVSS)."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1838
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-5
      description: "Vulnerability monitoring includes a channel and process for receiving\
        \ reports of security vulnerabilities from the public at-large. Vulnerability\
        \ disclosure programs can be as simple as publishing a monitored email address\
        \ or web form that can receive reports, including notification authorizing\
        \ good-faith research and disclosure of security vulnerabilities. Organizations\
        \ generally expect that such research is happening with or without their authorization\
        \ and can use public vulnerability disclosure channels to increase the likelihood\
        \ that discovered vulnerabilities are reported directly to the organization\
        \ for remediation. \nOrganizations may also employ the use of financial incentives\
        \ (also known as \u201Cbug bounties\u201D) to further encourage external security\
        \ researchers to report discovered vulnerabilities. Bug bounty programs can\
        \ be tailored to the organization\u2019s needs. Bounties can be operated indefinitely\
        \ or over a defined period of time and can be offered to the general public\
        \ or to a curated group.Organizations may run public and private bounties\
        \ simultaneously and could choose to offer partially credentialed access to\
        \ certain participants in order to evaluate security vulnerabilities from\
        \ privileged vantage points. \nRelated Controls: CA-2, CA-7, CM-2, CM-4, CM-6,\
        \ CM-8, RA-2, RA-3, SA-11, SA-15, SI-2, SI-3, SI-4, SI-7, SR-11."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-5(2)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-5
      ref_id: RA-5(2)
      name: VULNERABILITY MONITORING AND SCANNING | UPDATE VULNERABILITIES TO BE SCANNED
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1840
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-5(2)
      description: Update the system vulnerabilities to be scanned within 24 hours
        prior to running a new scan or when new vulnerabilities are identified and
        reported.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1841
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-5(2)
      description: "Discussion: Due to the complexity of modern software, systems,\
        \ and other factors, new vulnerabilities are discovered on a regular basis.\
        \ It is important that newly discovered vulnerabilities are added to the list\
        \ of vulnerabilities to be scanned to ensure that the organization can take\
        \ steps to mitigate those vulnerabilities in a timely manner. \nRelated Controls:\
        \ SI-5."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-5(5)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-5
      ref_id: RA-5(5)
      name: VULNERABILITY MONITORING AND SCANNING | PRIVILEGED ACCESS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1843
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-5(5)
      description: Implement privileged access authorization to information system
        components containing or processing CJI for vulnerability scanning activities
        requiring privileged access.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1844
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-5(5)
      description: 'Discussion: In certain situations, the nature of the vulnerability
        scanning may be more intrusive, or the system component that is the subject
        of the scanning may contain classified or controlled unclassified information,
        such as personally identifiable information. Privileged access authorization
        to selected system components facilitates more thorough vulnerability scanning
        and protects the sensitive nature of such scanning.

        Related Controls: None.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-5(11)
      assessable: false
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-5
      ref_id: RA-5(11)
      name: VULNERABILITY MONITORING AND SCANNING | PUBLIC DISCLOSURE PROGRAM
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1846
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-5(11)
      description: Establish a public reporting channel for receiving reports of vulnerabilities
        in organizational systems and system components.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1847
      assessable: true
      depth: 5
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-5(11)
      description: 'Discussion: The reporting channel is publicly discoverable and
        contains clear language authorizing good-faith research and the disclosure
        of vulnerabilities to the organization. The organization does not condition
        its authorization on an expectation of indefinite non- disclosure to the public
        by the reporting entity but may request a specific time period to properly
        remediate the vulnerability.

        Related Controls: None.'
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-7
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.19
      ref_id: RA-7
      name: RISK RESPONSE
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1849
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-7
      description: Respond to findings from security and privacy assessments, monitoring,
        and audits in accordance with organizational risk tolerance.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1850
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-7
      description: "Discussion: Organizations have many options for responding to\
        \ risk including mitigating risk by implementing new controls or strengthening\
        \ existing controls, accepting risk with appropriate justification or rationale,\
        \ sharing or transferring risk, or avoiding risk. The risk tolerance of the\
        \ organization influences risk response decisions and actions. Risk response\
        \ addresses the need to determine an appropriate response to risk before generating\
        \ a plan of action and milestones entry. For example, the response may be\
        \ to accept risk or reject risk, or it may be possible to mitigate the risk\
        \ immediately so that a plan of action and milestones entry is not needed.\
        \ \nHowever, if the risk response is to mitigate the risk, and the mitigation\
        \ cannot be completed immediately, a plan of action and milestones entry is\
        \ generated. \nRelated Controls: CA-5, RA-2, RA-3, SR-2."
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-9
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:5.19
      ref_id: RA-9
      name: CRITICALITY ANALYSIS
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1852
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-9
      description: Identify critical system components and functions by performing
        a criticality analysis for information system components containing or processing
        CJI at the planning, design, development, testing, implementation, and maintenance
        stages of the system development life cycle.
    - urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:node1853
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:cjis-policy-5.9.4:ra-9
      description: "Discussion: Not all system components, functions, or services\
        \ necessarily require significant protections. For example, criticality analysis\
        \ is a key tenet of supply chain risk management and informs the prioritization\
        \ of protection activities. The identification of critical system components\
        \ and functions considers applicable laws, executive orders, regulations,\
        \ directives, policies, standards, system functionality requirements, system\
        \ and component interfaces, and system and component dependencies. Systems\
        \ engineers conduct a functional decompositionof a system to identify mission-critical\
        \ functions and components. The functional decomposition includes the identification\
        \ of organizational missions supported by the system, decomposition into the\
        \ specific functions to perform those missions, and traceability to the hardware,\
        \ software, and firmware components that implement those functions, including\
        \ when the functions are shared by many components within and external to\
        \ the system. \nThe operational environment of a system or a system component\
        \ may impact the criticality, including the connections to and dependencies\
        \ on cyber-physical systems, devices, system-of- systems, and outsourced IT\
        \ services. System components that allow unmediated access to critical system\
        \ components or functions are considered critical due to the inherent vulnerabilities\
        \ that such components create. Component and function criticality are assessed\
        \ in terms of the impact of a component or function failure on the organizational\
        \ missions that are supported by the system that contains the components and\
        \ functions. \nCriticality analysis is performed when an architecture or design\
        \ is being developed, modified, or upgraded. If such analysis is performed\
        \ early in the system development life cycle, organizations may be able to\
        \ modify the system design to reduce the critical nature of these components\
        \ and functions, such as by adding redundancy or alternate paths into the\
        \ system design. Criticality analysis can also influence the protection measures\
        \ required by development contractors. In addition to criticality analysis\
        \ for systems, system components, and system services, criticality analysis\
        \ of information is an important consideration. Such analysis is conducted\
        \ as part of security categorization in RA-2. \nRelated Controls: CP-2, PL-2,\
        \ PL-8, PL-11, RA-2, SA-8, SA-15, SR-5."
