<cmmc>
  <author>Anthony Awtrey</author>
  <version>2024-11-01</version>
  <copyright>According to 17 U.S.C. § 105: Copyright protection under this title is not available for any work of the United States Government.</copyright>
  <license>Public Domain</license>
  <note>This file contains a combination of data gathered from documents including FAR Clause 52.204-21, 32 CFR Part 170, NIST SP 800-171 r2 / 800-172, and NIST SP 800-171A / 800-172A.</note>
  <domain>
    <name>Access Control</name>
    <description>Requirements, control, and limitations for system and data access based for internal and remote sources across both users and processes</description>
    <icon>fas fa-user-lock</icon>
    <code>AC</code>
    <practice>
      <level>L1</level>
      <nist>3.1.1</nist>
      <far>b.1.i</far>
      <name>Authorized Access Control</name>
      <description>Limit information system access to authorized users, processes acting on behalf of authorized users, or devices (including other information systems).</description>
      <discussion>Access control policies (e.g., identity- or role-based policies, control matrices, and cryptography) control access between active entities or subjects (i.e., users or processes acting on behalf of users) and passive entities or objects (e.g., devices, files, records, and domains) in systems. Access enforcement mechanisms can be employed at the application and service level to provide increased information security. Other systems include systems internal and external to the organization. This requirement focuses on account management for systems and applications. The definition of and enforcement of access authorizations, other than those determined by account type (e.g., privileged verses non-privileged) are addressed in requirement 3.1.2.</discussion>
      <source>FAR Clause 52.204-21 b.1.i, NIST SP 800-171 Rev 2 3.1.1</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Access control policy; procedures addressing account management; security plan; system design documentation; system configuration settings and associated documentation; list of active system accounts and the name of the individual associated with each account; list of conditions for group and role membership; notifications or records of recently transferred, separated, or terminated employees; list of recently disabled system accounts along with the name of the individual associated with each account; access authorization records; account management compliance reviews; system monitoring records; system audit logs and records; other relevant documents or records; list of devices and other systems authorized to connect to organizational systems].</examine>
        <interview>[SELECT FROM: Personnel with account management responsibilities; system or network administrators; personnel with information security responsibilities].</interview>
        <test>[SELECT FROM: Organizational processes for managing system accounts; mechanisms for implementing account management].</test>
        <objective>[a] authorized users are identified;</objective>
        <objective>[b] processes acting on behalf of authorized users are identified;</objective>
        <objective>[c] devices (and other systems) authorized to connect to the system are identified;</objective>
        <objective>[d] system access is limited to authorized users;</objective>
        <objective>[e] system access is limited to processes acting on behalf of authorized users; and</objective>
        <objective>[f] system access is limited to authorized devices (including other systems).</objective>
      </assessment>
    </practice>
    <practice>
      <level>L1</level>
      <nist>3.1.2</nist>
      <far>b.1.ii</far>
      <name>Transaction &amp; Function Control</name>
      <description>Limit information system access to the types of transactions and functions that authorized users are permitted to execute.</description>
      <discussion>Organizations may choose to define access privileges or other attributes by account, by type of account, or a combination of both. System account types include individual, shared, group, system, anonymous, guest, emergency, developer, manufacturer, vendor, and temporary. Other attributes required for authorizing access include restrictions on time-of-day, day-of-week, and point-of-origin. In defining other account attributes, organizations consider system-related requirements (e.g., system upgrades scheduled maintenance,) and mission or business requirements, (e.g., time zone differences, customer requirements, remote access to support travel requirements).</discussion>
      <source>FAR Clause 52.204-21 b.1.ii, NIST SP 800-171 Rev 2 3.1.2</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Access control policy; procedures addressing access enforcement; security plan; system design documentation; list of approved authorizations (user privileges) including remote access authorizations; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with access enforcement responsibilities; system or network administrators; personnel with information security responsibilities; system developers].</interview>
        <test>[SELECT FROM: Mechanisms implementing access control policy].</test>
        <objective>[a] the types of transactions and functions that authorized users are permitted to execute are defined; and;</objective>
        <objective>[b] system access is limited to the defined types of transactions and functions for authorized users.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L3</level>
      <nist>3.1.2e</nist>
      <name>Organizationally Controlled Assets</name>
      <description>Restrict access to systems and system components to only those information resources that are owned, provisioned, or issued by the organization.</description>
      <discussion>Information resources that are not owned, provisioned, or issued by the organization include systems or system components owned by other organizations and personally owned devices. Nonorganizational information resources present significant risks to the organization and complicate the ability to employ a “comply-to-connect” policy or implement component or device attestation techniques to ensure the integrity of the organizational system.</discussion>
      <source>NIST SP 800-172 3.1.2e</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Access control policy; procedures addressing the use of external systems; list of information resources owned, provisioned, or issued by the organization; security plan; system design documentation; system configuration settings and associated documentation; system connection or processing agreements; system audit records; account management documents; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Organizational personnel responsible for restricting or prohibiting the use of non-organizationally owned systems, system components, or devices; system and network administrators; organizational personnel responsible for system security].</interview>
        <test>[SELECT FROM: Mechanisms implementing restrictions on the use of nonorganizationally owned systems, components, or devices].</test>
        <objective>[a] Information resources that are owned, provisioned, or issued by the organization are identified; and</objective>
        <objective>[b] Access to systems and system components is restricted to only those information resources that are owned, provisioned, or issued by the organization.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.1.3</nist>
      <name>Control CUI Flow</name>
      <description>Control the flow of CUI in accordance with approved authorizations.</description>
      <discussion>Information flow control regulates where information can travel within a system and between systems (versus who can access the information) and without explicit regard to subsequent accesses to that information. Flow control restrictions include the following: keeping export-controlled information from being transmitted in the clear to the Internet; blocking outside traffic that claims to be from within the organization; restricting requests to the Internet that are not from the internal web proxy server; and limiting information transfers between organizations based on data structures and content.  Organizations commonly use information flow control policies and enforcement mechanisms to control the flow of information between designated sources and destinations (e.g., networks, individuals, and devices) within systems and between interconnected systems. Flow control is based on characteristics of the information or the information path. Enforcement occurs in boundary protection devices (e.g., gateways, routers, guards, encrypted tunnels, firewalls) that employ rule sets or establish configuration settings that restrict system services, provide a packet-filtering capability based on header information, or message-filtering capability based on message content (e.g., implementing key word searches or using document characteristics). Organizations also consider the trustworthiness of filtering and inspection mechanisms (i.e., hardware, firmware, and software components) that are critical to information flow enforcement.  Transferring information between systems representing different security domains with different security policies introduces risk that such transfers violate one or more domain security policies. In such situations, information owners or stewards provide guidance at designated policy enforcement points between interconnected systems. Organizations consider mandating specific architectural solutions when required to enforce specific security policies. Enforcement includes: prohibiting information transfers between interconnected systems (i.e., allowing access only); employing hardware mechanisms to enforce one-way information flows; and implementing trustworthy regrading mechanisms to reassign security attributes and security labels.</discussion>
      <source>NIST SP 800-171 Rev 2 3.1.3</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Access control policy; information flow control policies; procedures addressing information flow enforcement; security plan; system design documentation; system configuration settings and associated documentation; list of information flow authorizations; system baseline configuration; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: System or network administrators; personnel with information security responsibilities; system developers].</interview>
        <test>[SELECT FROM: Mechanisms implementing information flow enforcement policy].</test>
        <objective>[a] information flow control policies are defined;</objective>
        <objective>[b] methods and enforcement mechanisms for controlling the flow of CUI are defined;</objective>
        <objective>[c] designated sources and destinations (e.g., networks, individuals, and devices) for CUI within the system and between interconnected systems are identified;</objective>
        <objective>[d] authorizations for controlling the flow of CUI are defined; and</objective>
        <objective>[e] approved authorizations for controlling the flow of CUI are enforced.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L3</level>
      <nist>3.1.3e</nist>
      <name>Secured Information Transfer</name>
      <description>Employ organization-defined secure information transfer solutions to control information flows between security domains on connected systems.</description>
      <discussion>Organizations 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 inspection mechanisms (i.e., hardware, firmware, and software components) that are critical to information flow enforcement. Transferring information between systems in different security domains with different security policies introduces the risk that the transfers violate one or more domain security policies. In such situations, information owners or information stewards provide guidance at designated policy enforcement points between connected systems. Organizations mandate specific architectural solutions when required to enforce logical or physical separation between systems in different security domains. Enforcement includes prohibiting information transfers between connected systems, employing hardware mechanisms to enforce one-way information flows, verifying write permissions before accepting information from another security domain or connected system, and implementing trustworthy regrading mechanisms to reassign security attributes and labels. Secure information transfer solutions often include one or more of the following properties: use of cross-domain solutions when traversing security domains, mutual authentication of the sender and recipient (using hardware-based cryptography), encryption of data in transit and at rest, isolation from other domains, and logging of information transfers (e.g., title of file, file size, cryptographic hash of file, sender, recipient, transfer time and Internet Protocol [IP] address, receipt time, and IP address).</discussion>
      <source>NIST SP 800-172 3.1.3e</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Access control policy; information flow control policies; procedures addressing information flow enforcement; system design documentation; security plan; system configuration settings and associated documentation; system audit records; system baseline configuration; list of information flow authorizations; other relevant documents or records].</examine>
        <interview>[SELECT FROM: System and network administrators; organizational personnel   responsible for information security; system developers].</interview>
        <test>[SELECT FROM: Mechanisms implementing information flow enforcement policy].</test>
        <objective>[ODP1] Secure information transfer solutions are defined;</objective>
        <objective>[a] Information flows between security domains on connected systems are identified; and</objective>
        <objective>[b] Secure information transfer solutions are employed to control information flows between security domains on connected systems.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.1.4</nist>
      <name>Separation of Duties</name>
      <description>Separate the duties of individuals to reduce the risk of malevolent activity without collusion.</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 functions and system support functions among different individuals or roles; conducting system support functions with different individuals (e.g., configuration management, quality assurance and testing, system management, programming, and network security); and ensuring that security personnel administering 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 organizational systems and system components when developing policy on separation of duties.</discussion>
      <source>NIST SP 800-171 Rev 2 3.1.4</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Access control policy; procedures addressing divisions of responsibility and separation of duties; security plan; system configuration settings and associated documentation; list of divisions of responsibility and separation of duties; system access authorizations; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with responsibilities for defining divisions of responsibility and separation of duties; personnel with information security responsibilities; system or network administrators].</interview>
        <test>[SELECT FROM: Mechanisms implementing separation of duties policy].</test>
        <objective>[a] the duties of individuals requiring separation are defined;</objective>
        <objective>[b] responsibilities for duties that require separation are assigned to separate individuals; and</objective>
        <objective>[c] access privileges that enable individuals to exercise the duties that require separation are granted to separate individuals.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.1.5</nist>
      <name>Least Privilege</name>
      <description>Employ the principle of least privilege, including for specific security functions and privileged accounts.</description>
      <discussion>Organizations employ the principle of least privilege for specific duties and authorized accesses for users and processes. The principle of least privilege is applied with the goal of authorized privileges no higher than necessary to accomplish required organizational missions or business functions. Organizations consider the creation of additional processes, roles, and system accounts as necessary, to achieve least privilege. Organizations also apply least privilege to the development, implementation, and operation of organizational systems. Security functions include establishing system accounts, setting events to be logged, setting intrusion detection parameters, and configuring access authorizations (i.e., permissions, privileges).  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 having access to privileged information or functions. Organizations may differentiate in the application of this requirement between allowed privileges for local accounts and for domain accounts provided organizations retain the ability to control system configurations for key security parameters and as otherwise necessary to sufficiently mitigate risk.</discussion>
      <source>NIST SP 800-171 Rev 2 3.1.5</source>
      <score>3</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Access control policy; procedures addressing account management; security plan; system design documentation; system configuration settings and associated documentation; list of active system accounts and the name of the individual associated with each account; list of conditions for group and role membership; notifications or records of recently transferred, separated, or terminated employees; list of recently disabled system accounts along with the name of the individual associated with each account; access authorization records; account management compliance reviews; system monitoring/audit records; other relevant documents or records; procedures addressing least privilege; list of security functions (deployed in hardware, software, and firmware) and security-relevant information for which access must be explicitly authorized; list of system-generated privileged accounts; list of system administration personnel].</examine>
        <interview>[SELECT FROM: Personnel with account management responsibilities; system or network administrators; personnel with information security responsibilities; personnel with responsibilities for defining least privileges necessary to accomplish specified tasks].</interview>
        <test>[SELECT FROM: Organizational processes for managing system accounts; mechanisms for implementing account management; mechanisms implementing least privilege functions; mechanisms prohibiting privileged access to the system].</test>
        <objective>[a] privileged accounts are identified;</objective>
        <objective>[b] access to privileged accounts is authorized in accordance with the principle of least privilege;</objective>
        <objective>[c] security functions are identified; and</objective>
        <objective>[d] access to security functions is authorized in accordance with the principle of least privilege.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.1.6</nist>
      <name>Non-Privileged Account Use</name>
      <description>Use non-privileged accounts or roles when accessing nonsecurity functions.</description>
      <discussion>This requirement 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 all processes acting on behalf of the user as would be provided by a change between a privileged and non-privileged account.</discussion>
      <source>NIST SP 800-171 Rev 2 3.1.6</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Access control policy; procedures addressing least privilege; security plan; list of system-generated security functions assigned to system accounts or roles; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with responsibilities for defining least privileges necessary to accomplish specified organizational tasks; personnel with information security responsibilities; system or network administrators].</interview>
        <test>[SELECT FROM: Mechanisms implementing least privilege functions].</test>
        <objective>[a] nonsecurity functions are identified; and</objective>
        <objective>[b] users are required to use non-privileged accounts or roles when accessing nonsecurity functions.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.1.7</nist>
      <name>Privileged Functions</name>
      <description>Prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit logs.</description>
      <discussion>Privileged functions include establishing system accounts, performing system integrity checks, conducting patching operations, or administering cryptographic key management activities. Non-privileged users are individuals that do not possess appropriate authorizations. Circumventing intrusion detection and prevention mechanisms or malicious code protection mechanisms are examples of privileged functions that require protection from non-privileged users. Note that this requirement represents a condition to be achieved by the definition of authorized privileges in 3.1.2.  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 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.</discussion>
      <source>NIST SP 800-171 Rev 2 3.1.7</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Access control policy; procedures addressing least privilege; security plan; system design documentation; list of privileged functions and associated user account assignments; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with responsibilities for defining least privileges necessary to accomplish specified tasks; personnel with information security responsibilities; system developers].</interview>
        <test>[SELECT FROM: Mechanisms implementing least privilege functions for non-privileged users; mechanisms auditing the execution of privileged functions].</test>
        <objective>[a] privileged functions are defined;</objective>
        <objective>[b] non-privileged users are defined;</objective>
        <objective>[c] non-privileged users are prevented from executing privileged functions; and</objective>
        <objective>[d] the execution of privileged functions is captured in audit logs.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.1.8</nist>
      <name>Unsuccessful Logon Attempts</name>
      <description>Limit unsuccessful logon attempts.</description>
      <discussion>This requirement 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, in most cases, temporary and automatically release after a predetermined period established by the organization (i.e., a delay algorithm). If a delay algorithm is selected, organizations may employ different algorithms for different system components based on the capabilities of the respective components. Responses to unsuccessful logon attempts may be implemented at the operating system and application levels.</discussion>
      <source>NIST SP 800-171 Rev 2 3.1.8</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Access control policy; procedures addressing unsuccessful logon attempts; security plan; system design documentation; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with information security responsibilities; system developers; system or network administrators].</interview>
        <test>[SELECT FROM: Mechanisms implementing access control policy for unsuccessful logon attempts].</test>
        <objective>[a] the means of limiting unsuccessful logon attempts is defined; and</objective>
        <objective>[b] the defined means of limiting unsuccessful logon attempts is implemented.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.1.9</nist>
      <name>Privacy &amp; Security Notices</name>
      <description>Provide privacy and security notices consistent with applicable CUI rules.</description>
      <discussion>System use notifications can be implemented using messages or warning banners displayed before individuals log in to organizational systems. System use notifications are used only for access via logon interfaces with human users and are not required when such human interfaces do not exist. Based on a risk assessment, organizations consider whether a secondary system use notification is needed to access applications or other system resources after the initial network logon. Where necessary, posters or other printed materials may be used in lieu of an automated system banner. Organizations consult with the Office of General Counsel for legal review and approval of warning banner content</discussion>
      <source>NIST SP 800-171 Rev 2 3.1.9</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Access control policy; privacy and security policies, procedures addressing system use notification; documented approval of system use notification messages or banners; system audit logs and records; system design documentation; user acknowledgements of notification message or banner; security plan; system use notification messages; system configuration settings and associated documentation; other relevant documents or records].</examine>
        <interview>[SELECT FROM: System or network administrators; personnel with information security responsibilities; personnel with responsibility for providing legal advice; system developers].</interview>
        <test>[SELECT FROM: Mechanisms implementing system use notification].</test>
        <objective>[a] privacy and security notices required by CUI-specified rules are identified, consistent, and associated with the specific CUI category; and</objective>
        <objective>[b] privacy and security notices are displayed.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.1.10</nist>
      <name>Session Lock</name>
      <description>Use session lock with pattern-hiding displays to prevent access and viewing of data after a period of inactivity.</description>
      <discussion>Session locks are temporary actions taken when users stop work and move away from the immediate vicinity of the system but do not want to log out because of the temporary nature of their absences. Session locks are implemented where session activities can be determined, typically at the operating system level (but can also be at the application level). Session locks are not an acceptable substitute for logging out of the system, for example, if organizations require users to log out at the end of the workday.  Pattern-hiding displays can include static or dynamic images, for example, patterns used with screen savers, photographic images, solid colors, clock, battery life indicator, or a blank screen, with the additional caveat that none of the images convey controlled unclassified information.</discussion>
      <source>NIST SP 800-171 Rev 2 3.1.10</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Access control policy; procedures addressing session lock; procedures addressing identification and authentication; system design documentation; system configuration settings and associated documentation; security plan; other relevant documents or records].</examine>
        <interview>[SELECT FROM: System or network administrators; personnel with information security responsibilities; system developers].</interview>
        <test>[SELECT FROM: Mechanisms implementing access control policy for session lock].</test>
        <objective>[a] the period of inactivity after which the system initiates a session lock is defined;</objective>
        <objective>[b] access to the system and viewing of data is prevented by initiating a session lock after the defined period of inactivity; and</objective>
        <objective>[c] previously visible information is concealed via a pattern-hiding display after the defined period of inactivity.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.1.11</nist>
      <name>Session Termination</name>
      <description>Terminate (automatically) a user session after a defined condition.</description>
      <discussion>This requirement addresses the termination of user-initiated logical sessions in contrast to the termination of network connections that are associated with communications sessions (i.e., disconnecting from the network). 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 (and thus terminate user access) without terminating network sessions. Session termination terminates all processes associated with a user’s logical session except those processes that are specifically created by the user (i.e., session owner) to continue after the session is terminated. Conditions or trigger events requiring automatic session termination can include organization-defined periods of user inactivity, targeted responses to certain types of incidents, and time-of-day restrictions on system use</discussion>
      <source>NIST SP 800-171 Rev 2 3.1.11</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Access control policy; procedures addressing session termination; system design documentation; security plan; system configuration settings and associated documentation; list of conditions or trigger events requiring session disconnect; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: System or network administrators; personnel with information security responsibilities; system developers].</interview>
        <test>[SELECT FROM: Mechanisms implementing user session termination].</test>
        <objective>[a] conditions requiring a user session to terminate are defined; and</objective>
        <objective>[b] a user session is automatically terminated after any of the defined conditions occur.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.1.12</nist>
      <name>Control Remote Access</name>
      <description>Monitor and control remote access sessions.</description>
      <discussion>Remote access is access to organizational systems by users (or processes acting on behalf of users) communicating through external networks (e.g., the Internet). Remote access methods include dial-up, broadband, and wireless. Organizations often employ encrypted virtual private networks (VPNs) to enhance confidentiality over remote connections. The use of encrypted VPNs does not make the access non-remote; however, the use of VPNs, when adequately provisioned with appropriate control (e.g., employing encryption techniques for confidentiality protection), may provide sufficient assurance to the organization that it can effectively treat such connections as internal networks. VPNs with encrypted tunnels can affect the capability to adequately monitor network communications traffic for malicious code.  Automated monitoring and control of remote access sessions allows organizations to detect cyber-attacks and help to ensure ongoing compliance with remote access policies by auditing connection activities of remote users on a variety of system components (e.g., servers, workstations, notebook computers, smart phones, and tablets).  [SP 800-46], [SP 800-77], and [SP 800-113] provide guidance on secure remote access and virtual private networks.</discussion>
      <source>NIST SP 800-171 Rev 2 3.1.12</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Access control policy; procedures addressing remote access implementation and usage (including restrictions); configuration management plan; security plan; system configuration settings and associated documentation; remote access authorizations; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with responsibilities for managing remote access connections; system or network administrators; personnel with information security responsibilities].</interview>
        <test>[SELECT FROM: Remote access management capability for the system].</test>
        <objective>[a] remote access sessions are permitted;</objective>
        <objective>[b] the types of permitted remote access are identified;</objective>
        <objective>[c] remote access sessions are controlled; and</objective>
        <objective>[d] remote access sessions are monitored.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.1.13</nist>
      <name>Remote Access Confidentiality</name>
      <description>Employ cryptographic mechanisms to protect the confidentiality of remote access sessions.</description>
      <discussion>Cryptographic standards include FIPS-validated cryptography and NSA-approved cryptography. See [NIST CRYPTO]; [NIST CAVP]; [NIST CMVP]; National Security Agency Cryptographic Standards.</discussion>
      <source>NIST SP 800-171 Rev 2 3.1.13</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Access control policy; procedures addressing remote access to the system; security plan; system design documentation; system configuration settings and associated documentation; cryptographic mechanisms and associated configuration documentation; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: System or network administrators; personnel with information security responsibilities; system developers].</interview>
        <test>[SELECT FROM: Cryptographic mechanisms protecting remote access sessions].</test>
        <objective>[a] cryptographic mechanisms to protect the confidentiality of remote access sessions are identified; and</objective>
        <objective>[b] cryptographic mechanisms to protect the confidentiality of remote access sessions are implemented.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.1.14</nist>
      <name>Remote Access Routing</name>
      <description>Route remote access via managed access control points.</description>
      <discussion>Routing remote access through managed access control points enhances explicit, organizational control over such connections, reducing the susceptibility to unauthorized access to organizational systems resulting in the unauthorized disclosure of CUI.</discussion>
      <source>NIST SP 800-171 Rev 2 3.1.14</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Access control policy; procedures addressing remote access to the system; security plan; system design documentation; list of all managed network access control points; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: System or network administrators; personnel with information security responsibilities].</interview>
        <test>[SELECT FROM: Mechanisms routing all remote accesses through managed network access control points].</test>
        <objective>[a] managed access control points are identified and implemented; and</objective>
        <objective>[b] remote access is routed through managed network access control points.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.1.15</nist>
      <name>Privileged Remote Access</name>
      <description>Authorize remote execution of privileged commands and remote access to security-relevant information.</description>
      <discussion>A privileged command is a human-initiated (interactively or via a process operating on behalf of the human) command executed on a system involving the control, monitoring, or administration of the system including security functions and associated security-relevant information. Security-relevant information is any information within the system that can potentially impact the operation of security functions or the provision of security services in a manner that could result in failure to enforce the system security policy or maintain isolation of code and data. Privileged commands give individuals the ability to execute sensitive, security-critical, or security-relevant system functions. Controlling such access from remote locations helps to ensure that unauthorized individuals are not able to execute such commands freely with the potential to do serious or catastrophic damage to organizational systems. Note that the ability to affect the integrity of the system is considered security-relevant as that could enable the means to by-pass security functions although not directly impacting the function itself.</discussion>
      <source>NIST SP 800-171 Rev 2 3.1.15</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Access control policy; procedures addressing remote access to the system; system configuration settings and associated documentation; security plan; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: System or network administrators; personnel with information security responsibilities].</interview>
        <test>[SELECT FROM: Mechanisms implementing remote access management].</test>
        <objective>[a] privileged commands authorized for remote execution are identified;</objective>
        <objective>[b] security-relevant information authorized to be accessed remotely is identified;</objective>
        <objective>[c] the execution of the identified privileged commands via remote access is authorized; and</objective>
        <objective>[d] access to the identified security-relevant information via remote access is authorized.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.1.16</nist>
      <name>Wireless Access Authorization</name>
      <description>Authorize wireless access prior to allowing such connections.</description>
      <discussion>Establishing usage restrictions and configuration/connection requirements for wireless access to the system provides criteria for organizations to support wireless access authorization decisions. Such restrictions and requirements reduce the susceptibility to unauthorized access to the system through wireless technologies. Wireless networks use authentication protocols which provide credential protection and mutual authentication.  [SP 800-97] provides guidance on secure wireless networks.</discussion>
      <source>NIST SP 800-171 Rev 2 3.1.16</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Access control policy; configuration management plan; procedures addressing wireless access implementation and usage (including restrictions); security plan; system design documentation; system configuration settings and associated documentation; wireless access authorizations; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with responsibilities for managing wireless access connections; personnel with information security responsibilities].</interview>
        <test>[SELECT FROM: Wireless access management capability for the system].</test>
        <objective>[a] wireless access points are identified; and</objective>
        <objective>[b] wireless access is authorized prior to allowing such connections.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.1.17</nist>
      <name>Wireless Access Protection</name>
      <description>Protect wireless access using authentication and encryption.</description>
      <discussion>Organizations authenticate individuals and devices to help protect wireless access to the system. Special attention is given to the wide variety of devices that are part of the Internet of Things with potential wireless access to organizational systems. See [NIST CRYPTO].</discussion>
      <source>NIST SP 800-171 Rev 2 3.1.17</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Access control policy; system design documentation; procedures addressing wireless implementation and usage (including restrictions); security plan; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: System or network administrators; personnel with information security responsibilities; system developers].</interview>
        <test>[SELECT FROM: Mechanisms implementing wireless access protections to the system].</test>
        <objective>[a] wireless access to the system is protected using authentication; and</objective>
        <objective>[b] wireless access to the system is protected using encryption.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.1.18</nist>
      <name>Mobile Device Connection</name>
      <description>Control connection of mobile devices.</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 (e.g., wirelessly transmit or receive information); possesses local, non-removable or removable data storage; and includes a self-contained power source. Mobile devices may also include voice communication capabilities, on-board sensors that allow the device to capture information, or built-in features for synchronizing local data with remote locations. Examples of mobile devices include smart phones, e-readers, and tablets.  Due to the large variety of mobile devices with different technical characteristics and capabilities, organizational restrictions may vary for the different types of devices. Usage restrictions and implementation guidance for mobile devices include: device identification and authentication; configuration management; implementation of mandatory protective software (e.g., malicious code detection, firewall); 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 (e.g., wireless, infrared). The need to provide adequate security for mobile devices goes beyond this requirement. Many controls for mobile devices are reflected in other CUI security requirements.  [SP 800-124] provides guidance on mobile device security.</discussion>
      <source>NIST SP 800-171 Rev 2 3.1.18</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Access control policy; authorizations for mobile device connections to organizational systems; procedures addressing access control for mobile device usage (including restrictions); system design documentation; configuration management plan; security plan; system audit logs and records; system configuration settings and associated documentation; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel using mobile devices to access organizational systems; system or network administrators; personnel with information security responsibilities].</interview>
        <test>[SELECT FROM: Access control capability authorizing mobile device connections to organizational systems].</test>
        <objective>[a] mobile devices that process, store, or transmit CUI are identified;</objective>
        <objective>[b] mobile device connections are authorized; and</objective>
        <objective>[c] mobile device connections are monitored and logged.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.1.19</nist>
      <name>Encrypt CUI on Mobile</name>
      <description>Encrypt CUI on mobile devices and mobile computing platforms.</description>
      <discussion>Organizations can employ full-device encryption or container-based encryption to protect the confidentiality of CUI on mobile devices and computing platforms. Container-based encryption provides a more fine-grained approach to the encryption of data and information including encrypting selected data structures such as files, records, or fields. See [NIST CRYPTO]. [23] Mobile devices and computing platforms include, for example, smartphones and tablets.</discussion>
      <source>NIST SP 800-171 Rev 2 3.1.19</source>
      <score>3</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Access control policy; procedures addressing access control for mobile devices; system design documentation; system configuration settings and associated documentation; encryption mechanisms and associated configuration documentation; security plan; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with access control responsibilities for mobile devices; system or network administrators; personnel with information security responsibilities].</interview>
        <test>[SELECT FROM: Encryption mechanisms protecting confidentiality of information on mobile devices].</test>
        <objective>[a] mobile devices and mobile computing platforms that process, store, or transmit CUI are identified; and</objective>
        <objective>[b] encryption is employed to protect CUI on identified mobile devices and mobile computing platforms.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L1</level>
      <nist>3.1.20</nist>
      <far>b.1.iii</far>
      <name>External Connections</name>
      <description>Verify and control/limit connections to and use of external information systems.</description>
      <discussion>External systems are systems or components of systems for which organizations typically have no direct supervision and authority over the application of security requirements and controls or the determination of the effectiveness of implemented controls on those systems. External systems include personally owned systems, components, or devices and privately-owned computing and communications devices resident in commercial or public facilities. This requirement also addresses the use of external systems for the processing, storage, or transmission of CUI, including accessing cloud services (e.g., infrastructure as a service, platform as a service, or software as a service) from organizational systems.  Organizations establish terms and conditions for the use of external systems in accordance with organizational security policies and procedures. Terms and conditions address as a minimum, the types of applications that can be accessed on organizational systems from external systems. If terms and conditions with the owners of external systems cannot be established, organizations may impose restrictions on organizational personnel using those external systems.  This requirement recognizes that there are circumstances where individuals using external systems (e.g., contractors, coalition partners) need to access organizational systems. In those situations, organizations need confidence 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 effectively implemented can be achieved by third-party, independent assessments, attestations, or other means, depending on the assurance or confidence level required by organizations.  Note that while “external” typically refers to outside of the organization’s direct supervision and authority, that is not always the case. Regarding the protection of CUI across an organization, the organization may have systems that process CUI and others that do not. And among the systems that process CUI there are likely access restrictions for CUI that apply between systems. Therefore, from the perspective of a given system, other systems within the organization may be considered “external" to that system.</discussion>
      <source>FAR Clause 52.204-21 b.1.iii, NIST SP 800-171 Rev 2 3.1.20</source>
      <score>1</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Access control policy; procedures addressing the use of external systems; terms and conditions for external systems; security plan; list of types of applications accessible from external systems; system configuration settings and associated documentation; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with responsibilities for defining terms and conditions for use of external systems to access organizational systems; system or network administrators; personnel with information security responsibilities].</interview>
        <test>[SELECT FROM: Mechanisms implementing terms and conditions on use of external systems].</test>
        <objective>[a] connections to external systems are identified;</objective>
        <objective>[b] the use of external systems is identified;</objective>
        <objective>[c] connections to external systems are verified;</objective>
        <objective>[d] the use of external systems is verified;</objective>
        <objective>[e] connections to external systems are controlled/limited; and</objective>
        <objective>[f] the use of external systems is controlled/limited.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.1.21</nist>
      <name>Portable Storage Use</name>
      <description>Limit use of portable storage devices on external systems.</description>
      <discussion>Limits on the use of organization-controlled portable storage devices in external systems include complete prohibition of the use of such devices or restrictions on how the devices may be used and under what conditions the devices may be used. Note that while “external” typically refers to outside of the organization’s direct supervision and authority, that is not always the case.  Regarding the protection of CUI across an organization, the organization may have systems that process CUI and others that do not. Among the systems that process CUI there are likely access restrictions for CUI that apply between systems. Therefore, from the perspective of a given system, other systems within the organization may be considered “external" to that system.</discussion>
      <source>NIST SP 800-171 Rev 2 3.1.21</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Access control policy; procedures addressing the use of external systems; security plan; system configuration settings and associated documentation; system connection or processing agreements; account management documents; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with responsibilities for restricting or prohibiting use of organization-controlled storage devices on external systems; system or network administrators; personnel with information security responsibilities].</interview>
        <test>[SELECT FROM: Mechanisms implementing restrictions on use of portable storage devices].</test>
        <objective>[a] the use of portable storage devices containing CUI on external systems is identified and documented;</objective>
        <objective>[b] limits on the use of portable storage devices containing CUI on external systems are defined; and</objective>
        <objective>[c] the use of portable storage devices containing CUI on external systems is limited as defined.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L1</level>
      <nist>3.1.22</nist>
      <far>b.1.iv</far>
      <name>Control Public Information</name>
      <description>Control information posted or processed on publicly accessible information systems.</description>
      <discussion>In accordance with laws, Executive Orders, directives, policies, regulations, or standards, the public is not authorized access to nonpublic information (e.g., information protected under the Privacy Act, CUI, and proprietary information). This requirement addresses systems that are controlled by the organization and accessible to the public, typically without identification or authentication. Individuals authorized to post CUI onto publicly accessible systems are designated. The content of information is reviewed prior to posting onto publicly accessible systems to ensure that nonpublic information is not included.</discussion>
      <source>FAR Clause 52.204-21 b.1.iv, NIST SP 800-171 Rev 2 3.1.22</source>
      <score>1</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Access control policy; procedures addressing publicly accessible content; security plan; list of users authorized to post publicly accessible content on organizational systems; training materials and/or records; records of publicly accessible information reviews; records of response to nonpublic information on public websites; system audit logs and records; security awareness training records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with responsibilities for managing publicly accessible information posted on organizational systems; personnel with information security responsibilities].</interview>
        <test>[SELECT FROM: Mechanisms implementing management of publicly accessible content].</test>
        <objective>[a] individuals authorized to post or process information on publicly accessible systems are identified;</objective>
        <objective>[b] procedures to ensure [FCI/CUI] is not posted or processed on publicly accessible systems are identified;</objective>
        <objective>[c] a review process is in place prior to posting of any content to publicly accessible systems;</objective>
        <objective>[d] content on publicly accessible systems is reviewed to ensure that it does not include [FCI/CUI]; and</objective>
        <objective>[e] mechanisms are in place to remove and address improper posting of [FCI/CUI].</objective>
      </assessment>
    </practice>
  </domain>
  <domain>
    <name>Awareness and Training</name>
    <description>Conduct security awareness activities and training</description>
    <icon>fas fa-graduation-cap</icon>
    <code>AT</code>
    <practice>
      <level>L2</level>
      <nist>3.2.1</nist>
      <name>Role-Based Risk Awareness</name>
      <description>Ensure that managers, systems administrators, and users of organizational systems are made aware of the security risks associated with their activities and of the applicable policies, standards, and procedures related to the security of those systems.</description>
      <discussion>Organizations determine the content and frequency of security awareness training and security awareness techniques based on the specific organizational requirements and the systems to which personnel have authorized access. The content includes a basic understanding of the need for information security and user actions to maintain security and to respond to suspected security incidents. The content also addresses awareness of the need for operations security. Security awareness techniques include: formal training; offering supplies inscribed with security reminders; generating email advisories or notices from organizational officials; displaying logon screen messages; displaying security awareness posters; and conducting information security awareness events.  [SP 800-50] provides guidance on security awareness and training programs.</discussion>
      <source>NIST SP 800-171 Rev 2 3.2.1</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Security awareness and training policy; procedures addressing security awareness training implementation; relevant codes of federal regulations; security awareness training curriculum; security awareness training materials; security plan; training records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with responsibilities for security awareness training; personnel with information security responsibilities; personnel composing the general system user community].</interview>
        <test>[SELECT FROM: Mechanisms managing security awareness training; mechanisms managing role-based security training].</test>
        <objective>[a] security risks associated with organizational activities involving CUI are identified;</objective>
        <objective>[b] policies, standards, and procedures related to the security of the system are identified;</objective>
        <objective>[c] managers, systems administrators, and users of the system are made aware of the security risks associated with their activities; and</objective>
        <objective>[d] managers, systems administrators, and users of the system are made aware of the applicable policies, standards, and procedures related to the security of the system.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L3</level>
      <nist>3.2.1e</nist>
      <name>Advanced Threat Awareness</name>
      <description>Provide awareness training upon initial hire, following a significant cyber event, and at least annually, focused on recognizing and responding to threats from social engineering, advanced persistent threat actors, breaches, and suspicious behaviors; update the training at least annually or when there are significant changes to the threat.</description>
      <discussion>An effective method to detect APT activities and reduce the effectiveness of those activities is to provide specific awareness training for individuals. A well-trained and security-aware workforce provides another organizational safeguard that can be employed as part of a defense-in-depth strategy to protect organizations against malicious code injections via email or web applications. Threat awareness training includes educating individuals on the various ways that APTs can infiltrate organizations, including through websites, emails, advertisement pop-ups, articles, and social engineering. Training can include techniques for recognizing suspicious emails, the use of removable systems in non-secure settings, and the potential targeting of individuals by adversaries outside the workplace. Awareness training is assessed and updated periodically to ensure that the training is relevant and effective, particularly with respect to the threat since it is constantly, and often rapidly, evolving. [SP 800-50] provides guidance on security awareness and training programs.</discussion>
      <source>NIST SP 800-172 3.2.1e</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Awareness training policy; procedures addressing awareness training implementation; appropriate codes of federal regulations; awareness training curriculum; awareness training materials; security plan; training records; threat information on social engineering, advanced persistent threat actors, suspicious behaviors, and breaches; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Organizational personnel responsible for awareness training; organizational personnel responsible for information security; organizational personnel comprising the general system user community].</interview>
        <test>[SELECT FROM: Mechanisms managing awareness training; mechanisms managing threat information].</test>
        <objective>[a] Threats from social engineering, advanced persistent threat actors, breaches, and suspicious behaviors are identified;</objective>
        <objective>[b] Awareness training focused on recognizing and responding to threats from social engineering, advanced persistent threat actors, breaches, and suspicious behaviors is provided upon initial hire, following a significant cyber event, and at least annually;</objective>
        <objective>[c] Significant changes to the threats from social engineering, advanced persistent threat actors, breaches, and suspicious behaviors are identified; and</objective>
        <objective>[d] Awareness training is updated at least annually or when there are significant changes to the threat.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.2.2</nist>
      <name>Role-Based Training</name>
      <description>Ensure that personnel are trained to carry out their assigned information security-related duties and responsibilities.</description>
      <discussion>Organizations determine the content and frequency of security training based on the assigned duties, roles, and responsibilities of individuals and the security requirements of organizations and the systems to which personnel have authorized access. In addition, organizations provide system developers, enterprise architects, security architects, acquisition/procurement officials, software developers, system developers, systems integrators, system/network administrators, personnel conducting configuration management and auditing activities, personnel performing independent verification and validation, security assessors, and other personnel having access to system-level software, security-related technical training specifically tailored for their assigned duties.  Comprehensive role-based training addresses management, operational, and technical roles and responsibilities covering physical, personnel, and technical controls. Such training can include policies, procedures, tools, and artifacts for the security roles defined. Organizations also provide the training necessary for individuals to carry out their responsibilities related to operations and supply chain security within the context of organizational information security programs.  [SP 800-181] provides guidance on role-based information security training in the workplace. [SP 800-161] provides guidance on supply chain risk management.</discussion>
      <source>NIST SP 800-171 Rev 2 3.2.2</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Security awareness and training policy; procedures addressing security training implementation; codes of federal regulations; security training curriculum; security training materials; security plan; training records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with responsibilities for role-based security training; personnel with assigned system security roles and responsibilities].</interview>
        <test>[SELECT FROM: Mechanisms managing role-based security training].</test>
        <objective>[a] information security-related duties, roles, and responsibilities are defined;</objective>
        <objective>[b] information security-related duties, roles, and responsibilities are assigned to designated personnel; and</objective>
        <objective>[c] personnel are adequately trained to carry out their assigned information security- related duties, roles, and responsibilities.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L3</level>
      <nist>3.2.2e</nist>
      <name>Practical Training Exercises</name>
      <description>Include practical exercises in awareness training for all users, tailored by roles, to include general users, users with specialized roles, and privileged users, that are aligned with current threat scenarios and provide feedback to individuals involved in the training and their supervisors.</description>
      <discussion>Awareness training is most effective when it is complemented by practical exercises tailored to the tactics, techniques, and procedures (TTP) of the threat. Examples of practical exercises include unannounced social engineering attempts to gain unauthorized access, collect information, or simulate the adverse impact of opening malicious email attachments or invoking, via spear phishing attacks, malicious web links. Rapid feedback is essential to reinforce desired user behavior. Training results, especially failures of personnel in critical roles, can be indicative of a potentially serious problem. It is important that senior management are made aware of such situations so that they can take appropriate remediating actions. [SP 800-181] provides guidance on role-based security training, including a lexicon and taxonomy that describes cybersecurity work via work roles.</discussion>
      <source>NIST SP 800-172 3.2.2e</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Awareness training policy; procedures addressing awareness training implementation; appropriate codes of federal regulations; awareness training curriculum; awareness training materials; security plan; training records; threat information on social engineering, advanced persistent threat actors, suspicious behaviors, breaches, or other relevant adversary tactics, techniques, or procedures; feedback on practical exercises and awareness training; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Organizational personnel responsible for awareness training; organizational personnel responsible for information security; organizational personnel with roles identified for practical exercises; supervisors of personnel with roles identified for practical exercises].</interview>
        <test>[SELECT FROM: Mechanisms managing awareness training; mechanisms managing threat information].</test>
        <objective>[a] Practical exercises are identified;</objective>
        <objective>[b] Current threat scenarios are identified;</objective>
        <objective>[c] Individuals involved in training and their supervisors are identified;</objective>
        <objective>[d] Practical exercises that are aligned with current threat scenarios are included in awareness training for all users, tailored by roles, to include general users, users with specialized roles, and privileged users; and</objective>
        <objective>[e] Feedback is provided to individuals involved in the training and their supervisors.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.2.3</nist>
      <name>Insider Threat Awareness</name>
      <description>Provide security awareness training on recognizing and reporting potential indicators of insider threat.</description>
      <discussion>Potential indicators and possible precursors of insider threat include behaviors such as: inordinate, long-term job dissatisfaction; attempts to gain access to information that is not required for job performance; unexplained access to financial resources; bullying or sexual harassment of fellow employees; workplace violence; and other serious violations of the policies, procedures, directives, rules, or practices of organizations. Security awareness training includes how to communicate employee and management concerns regarding potential indicators of insider threat through appropriate organizational channels in accordance with established organizational policies and procedures. Organizations may consider tailoring insider threat awareness topics to the role (e.g., training for managers may be focused on specific changes in behavior of team members, while training for employees may be focused on more general observations).</discussion>
      <source>NIST SP 800-171 Rev 2 3.2.3</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Security awareness and training policy; procedures addressing security awareness training implementation; security awareness training curriculum; security awareness training materials; insider threat policy and procedures; security plan; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel that participate in security awareness training; personnel with responsibilities for basic security awareness training; personnel with information security responsibilities].</interview>
        <test>[SELECT FROM: Mechanisms managing insider threat training].</test>
        <objective>[a] potential indicators associated with insider threats are identified; and</objective>
        <objective>[b] security awareness training on recognizing and reporting potential indicators of insider threat is provided to managers and employees.</objective>
      </assessment>
    </practice>
  </domain>
  <domain>
    <name>Audit and Accountability</name>
    <description>Activities and requirements related to the renention, analysis, and generation of audit data.</description>
    <icon>fas fa-user-circle</icon>
    <code>AU</code>
    <practice>
      <level>L2</level>
      <nist>3.3.1</nist>
      <name>System Auditing</name>
      <description>Create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity.</description>
      <discussion>An event is any observable occurrence in a system, which includes unlawful or unauthorized system activity. Organizations identify event types for which a logging functionality is needed as those events which are significant and relevant to the security of systems and the environments in which those systems operate to meet specific and ongoing auditing needs. Event types can include password changes, failed logons or failed accesses related to systems, administrative privilege usage, or third-party credential usage. In determining event types that require logging, organizations consider the monitoring and auditing appropriate for each of the CUI security requirements. Monitoring and auditing requirements can be balanced with other system needs. For example, organizations may determine that systems must have the capability to log every file access both successful and unsuccessful, but not activate that capability except for specific circumstances due to the potential burden on system performance.  Audit records can be generated at various levels of abstraction, including at the packet level as information traverses the network. Selecting the appropriate level of abstraction is a critical aspect of an audit logging capability and can facilitate the identification of root causes to problems. Organizations consider in the definition of event types, the logging necessary to cover related events such as the steps in distributed, transaction-based processes (e.g., processes that are distributed across multiple organizations) and actions that occur in service-oriented or cloud-based architectures.  Audit record content that may be necessary to satisfy this requirement includes time stamps, source and destination addresses, user or process identifiers, event descriptions, success or fail indications, filenames involved, and access control or flow control rules invoked. Event outcomes can include indicators of event success or failure and event-specific results (e.g., the security state of the system after the event occurred).  Detailed information that organizations may consider in audit records includes full text recording of privileged commands or the individual identities of group account users. Organizations consider limiting the additional audit log information to only that information explicitly needed for specific audit requirements. This facilitates the use of audit trails and audit logs by not including information that could potentially be misleading or could make it more difficult to locate information of interest. Audit logs are reviewed and analyzed as often as needed to provide important information to organizations to facilitate risk-based decision making.  [SP 800-92] provides guidance on security log management.</discussion>
      <source>NIST SP 800-171 Rev 2 3.3.1</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Audit and accountability policy; procedures addressing auditable events; security plan; system design documentation; system configuration settings and associated documentation; system audit logs and records; system auditable events; system incident reports; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with audit and accountability responsibilities; personnel with information security responsibilities; system or network administrators].</interview>
        <test>[SELECT FROM: Mechanisms implementing system audit logging].</test>
        <objective>[a] audit logs needed (i.e., event types to be logged) to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity are specified;</objective>
        <objective>[b] the content of audit records needed to support monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity is defined;</objective>
        <objective>[c] audit records are created (generated);</objective>
        <objective>[d] audit records, once created, contain the defined content;</objective>
        <objective>[e] retention requirements for audit records are defined; and</objective>
        <objective>[f] audit records are retained as defined.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.3.2</nist>
      <name>User Accountability</name>
      <description>Ensure that the actions of individual system users can be uniquely traced to those users, so they can be held accountable for their actions.</description>
      <discussion>This requirement ensures that the contents of the audit record include the information needed to link the audit event to the actions of an individual to the extent feasible. Organizations consider logging for traceability including results from monitoring of account usage, remote access, wireless connectivity, mobile device connection, communications at system boundaries, configuration settings, physical access, nonlocal maintenance, use of maintenance tools, temperature and humidity, equipment delivery and removal, system component inventory, use of mobile code, and use of Voice over Internet Protocol (VoIP).</discussion>
      <source>NIST SP 800-171 Rev 2 3.3.2</source>
      <score>3</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Audit and accountability policy; procedures addressing audit records and event types; security plan; system design documentation; system configuration settings and associated documentation; system audit logs and records; system events; system incident reports; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with audit and accountability responsibilities; personnel with information security responsibilities; system or network administrators].</interview>
        <test>[SELECT FROM: Mechanisms implementing system audit logging].</test>
        <objective>[a] the content of the audit records needed to support the ability to uniquely trace users to their actions is defined; and</objective>
        <objective>[b] audit records, once created, contain the defined content.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.3.3</nist>
      <name>Event Review</name>
      <description>Review and update logged events.</description>
      <discussion>The intent of this requirement is to periodically re-evaluate which logged events will continue to be included in the list of events to be logged. The event types that are logged by organizations may change over time. Reviewing and updating the set of logged event types periodically is necessary to ensure that the current set remains necessary and sufficient.</discussion>
      <source>NIST SP 800-171 Rev 2 3.3.3</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Audit and accountability policy; procedures addressing audit records and event types; security plan; list of organization-defined event types to be logged; reviewed and updated records of logged event types; system audit logs and records; system incident reports; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with audit and accountability responsibilities; personnel with information security responsibilities].</interview>
        <test>[SELECT FROM: Mechanisms supporting review and update of logged event types].</test>
        <objective>[a] a process for determining when to review logged events is defined;</objective>
        <objective>[b] event types being logged are reviewed in accordance with the defined review process; and</objective>
        <objective>[c] event types being logged are updated based on the review.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.3.4</nist>
      <name>Audit Failure Alerting</name>
      <description>Alert in the event of an audit logging process failure.</description>
      <discussion>Audit logging process failures include software and hardware errors, failures in the audit record capturing mechanisms, and audit record storage capacity being reached or exceeded. This requirement applies to each audit record data storage repository (i.e., distinct system component where audit records are stored), the total audit record storage capacity of organizations (i.e., all audit record data storage repositories combined), or both.</discussion>
      <source>NIST SP 800-171 Rev 2 3.3.4</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Audit and accountability policy; procedures addressing response to audit logging processing failures; system design documentation; security plan; system configuration settings and associated documentation; list of personnel to be notified in case of an audit logging processing failure; system incident reports; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with audit and accountability responsibilities; personnel with information security responsibilities; system or network administrators; system developers].</interview>
        <test>[SELECT FROM: Mechanisms implementing system response to audit logging processing failures].</test>
        <objective>[a] personnel or roles to be alerted in the event of an audit logging process failure are identified;</objective>
        <objective>[b] types of audit logging process failures for which alert will be generated are defined; and</objective>
        <objective>[c] identified personnel or roles are alerted in the event of an audit logging process failure.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.3.5</nist>
      <name>Audit Correlation</name>
      <description>Correlate audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity.</description>
      <discussion>Correlating audit record review, analysis, and reporting processes helps to ensure that they do not operate independently, but rather collectively. Regarding the assessment of a given organizational system, the requirement is agnostic as to whether this correlation is applied at the system level or at the organization level across all systems.</discussion>
      <source>NIST SP 800-171 Rev 2 3.3.5</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Audit and accountability policy; procedures addressing audit record review, analysis, and reporting; security plan; system design documentation; system configuration settings and associated documentation; system audit logs and records across different repositories; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with audit record review, analysis, and reporting responsibilities; personnel with information security responsibilities].</interview>
        <test>[SELECT FROM: Mechanisms supporting analysis and correlation of audit records].</test>
        <objective>[a] audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity are defined; and</objective>
        <objective>[b] defined audit record review, analysis, and reporting processes are correlated.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.3.6</nist>
      <name>Reduction &amp; Reporting</name>
      <description>Provide audit record reduction and report generation to support on-demand analysis and reporting.</description>
      <discussion>Audit record reduction is a process that manipulates collected audit information and organizes such information in 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 organizational entities conducting auditing activities. Audit record reduction capability can include, for example, modern data mining techniques with advanced data filters to identify anomalous behavior in audit records. The report generation capability provided by the system can help generate customizable reports. Time ordering of audit records can be a significant issue if the granularity of the time stamp in the record is insufficient.</discussion>
      <source>NIST SP 800-171 Rev 2 3.3.6</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Audit and accountability policy; procedures addressing audit record reduction and report generation; system design documentation; security plan; system configuration settings and associated documentation; audit record reduction, review, analysis, and reporting tools; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with audit record reduction and report generation responsibilities; personnel with information security responsibilities].</interview>
        <test>[SELECT FROM: Audit record reduction and report generation capability].</test>
        <objective>[a] an audit record reduction capability that supports on-demand analysis is provided; and</objective>
        <objective>[b] a report generation capability that supports on-demand reporting is provided.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.3.7</nist>
      <name>Authoritative Time Source</name>
      <description>Provide a system capability that compares and synchronizes internal system clocks with an authoritative source to generate time stamps for audit records.</description>
      <discussion>Internal system clocks are used to generate time stamps, which include date and time. Time is expressed in Coordinated Universal Time (UTC), a modern continuation of Greenwich Mean Time (GMT), or local time with an offset from UTC. The granularity of time measurements refers to the degree of synchronization between system clocks and reference clocks, for example, clocks synchronizing within hundreds of milliseconds or within tens of milliseconds. Organizations may define different time granularities for different system components. Time service can also 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. This requirement provides uniformity of time stamps for systems with multiple system clocks and systems connected over a network. See [IETF 5905].</discussion>
      <source>NIST SP 800-171 Rev 2 3.3.7</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Audit and accountability policy; procedures addressing time stamp generation; system design documentation; security plan; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with information security responsibilities; system or network administrators; system developers].</interview>
        <test>[SELECT FROM: Mechanisms implementing time stamp generation].</test>
        <objective>[a] internal system clocks are used to generate time stamps for audit records;</objective>
        <objective>[b] an authoritative source with which to compare and synchronize internal system clocks is specified; and</objective>
        <objective>[c] internal system clocks used to generate time stamps for audit records are compared to and synchronized with the specified authoritative time source.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.3.8</nist>
      <name>Audit Protection</name>
      <description>Protect audit information and audit logging tools from unauthorized access, modification, and deletion.</description>
      <discussion>Audit information includes all information (e.g., audit records, audit log settings, and audit reports) needed to successfully audit system activity. Audit logging tools are those programs and devices used to conduct audit and logging activities. This requirement focuses on the technical protection of audit information and limits the ability to access and execute audit logging tools to authorized individuals. Physical protection of audit information is addressed by media protection and physical and environmental protection requirements.</discussion>
      <source>NIST SP 800-171 Rev 2 3.3.8</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Audit and accountability policy; access control policy and procedures; procedures addressing protection of audit information; security plan; system design documentation; system configuration settings and associated documentation, system audit logs and records; audit logging tools; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with audit and accountability responsibilities; personnel with information security responsibilities; system or network administrators; system developers].</interview>
        <test>[SELECT FROM: Mechanisms implementing audit information protection].</test>
        <objective>[a] audit information is protected from unauthorized access;</objective>
        <objective>[b] audit information is protected from unauthorized modification;</objective>
        <objective>[c] audit information is protected from unauthorized deletion;</objective>
        <objective>[d] audit logging tools are protected from unauthorized access;</objective>
        <objective>[e] audit logging tools are protected from unauthorized modification; and</objective>
        <objective>[f] audit logging tools are protected from unauthorized deletion.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.3.9</nist>
      <name>Audit Management</name>
      <description>Limit management of audit logging functionality to a subset of privileged users.</description>
      <discussion>Individuals with privileged access to a system and who are also the subject of an audit by that system, may affect the reliability of audit information by inhibiting audit logging activities or modifying audit records. This requirement specifies that privileged access be further defined between audit-related privileges and other privileges, thus limiting the users with audit-related privileges</discussion>
      <source>NIST SP 800-171 Rev 2 3.3.9</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Audit and accountability policy; access control policy and procedures; procedures addressing protection of audit information; security plan; system design documentation; system configuration settings and associated documentation; access authorizations; system-generated list of privileged users with access to management of audit logging functionality; access control list; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with audit and accountability responsibilities; personnel with information security responsibilities; system or network administrators; system developers].</interview>
        <test>[SELECT FROM: Mechanisms managing access to audit logging functionality].</test>
        <objective>[a] a subset of privileged users granted access to manage audit logging functionality is defined; and</objective>
        <objective>[b] management of audit logging functionality is limited to the defined subset of privileged users.</objective>
      </assessment>
    </practice>
  </domain>
  <domain>
    <name>Configuration Management</name>
    <description>Establish and monitor configuration by tracking established baselines and change processes</description>
    <icon>fas fa-database</icon>
    <code>CM</code>
    <practice>
      <level>L2</level>
      <nist>3.4.1</nist>
      <name>System Baselining</name>
      <description>Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles.</description>
      <discussion>Baseline configurations are documented, formally reviewed, and agreed-upon specifications for systems or configuration items within those systems. Baseline configurations serve as a basis for future builds, releases, and changes to systems. Baseline configurations include information about system components (e.g., standard software packages installed on workstations, notebook computers, servers, network components, or mobile devices; current version numbers and update and patch information on operating systems and applications; and configuration settings and parameters), network topology, and the logical placement of those components within the system architecture. Baseline configurations of systems also reflect the current enterprise architecture. Maintaining effective baseline configurations requires creating new baselines as organizational systems change over time. Baseline configuration maintenance includes reviewing and updating the baseline configuration when changes are made based on security risks and deviations from the established baseline configuration.  Organizations can implement centralized system component inventories that include components from multiple organizational systems. In such situations, organizations ensure that the resulting inventories include system-specific information required for proper component accountability (e.g., system association, system owner). Information deemed necessary for effective accountability of system components includes hardware inventory specifications, software license information, software version numbers, component owners, and for networked components or devices, machine names and network addresses. Inventory specifications include manufacturer, device type, model, serial number, and physical location.  [SP 800-128] provides guidance on security-focused configuration management.</discussion>
      <source>NIST SP 800-171 Rev 2 3.4.1</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Configuration management policy; procedures addressing the baseline configuration of the system; procedures addressing system inventory; security plan; configuration management plan; system inventory records; inventory review and update records; enterprise architecture documentation; system design documentation; system architecture and configuration documentation; system configuration settings and associated documentation; change control records; system component installation records; system component removal records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with configuration management responsibilities; personnel with responsibilities for establishing the system inventory; personnel with responsibilities for updating the system inventory; personnel with information security responsibilities; system or network administrators].</interview>
        <test>[SELECT FROM: Organizational processes for managing baseline configurations; mechanisms supporting configuration control of the baseline configuration; organizational processes for developing and documenting an inventory of system components; organizational processes for updating inventory of system components; mechanisms supporting or implementing the system inventory; mechanisms implementing updating of the system inventory].</test>
        <objective>[a] a baseline configuration is established;</objective>
        <objective>[b] the baseline configuration includes hardware, software, firmware, and documentation;</objective>
        <objective>[c] the baseline configuration is maintained (reviewed and updated) throughout the system development life cycle;</objective>
        <objective>[d] a system inventory is established;</objective>
        <objective>[e] the system inventory includes hardware, software, firmware, and documentation; and</objective>
        <objective>[f] the inventory is maintained (reviewed and updated) throughout the system development life cycle.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L3</level>
      <nist>3.4.1e</nist>
      <name>Authoritative Respository</name>
      <description>Establish and maintain an authoritative source and repository to provide a trusted source and accountability for approved and implemented system components.</description>
      <discussion>The establishment and maintenance of an authoritative source and repository includes a system component inventory of approved hardware, software, and firmware; approved system baseline configurations and configuration changes; and verified system software and firmware, as well as images and/or scripts. The authoritative source implements integrity controls to log changes or attempts to change software, configurations, or data in the repository. Additionally, changes to the repository are subject to change management procedures and require authentication of the user requesting the change. In certain situations, organizations may also require dual authorization for such changes. Software changes are routinely checked for integrity and authenticity to ensure that the changes are legitimate when updating the repository and when refreshing a system from the known, trusted source. The information in the repository is used to demonstrate adherence to or identify deviation from the established configuration baselines and to restore system components from a trusted source. From an automated assessment perspective, the system description provided by the authoritative source is referred to as the desired state. The desired state is compared to the actual state to check for compliance or deviations. [SP 80e-128] provides guidance on security configuration management, including security configuration settings and configuration change control. [IR 8011-1] provides guidance on automation support to assess system and system component configurations.</discussion>
      <source>NIST SP 800-172 3.4.1e</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Configuration management policy; procedures addressing the baseline configuration of the system; configuration management plan; enterprise architecture documentation; system design documentation; system architecture and configuration documentation; system configuration settings and associated documentation; change control records; system and system component inventory records; inventory reviews and update records; security plan; system audit records; change control audit and review reports; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with configuration management responsibilities; personnel with responsibilities for establishing the system inventory; personnel with responsibilities for updating the system inventory; personnel with information security responsibilities; system or network administrators].</interview>
        <test>[SELECT FROM: Organizational processes for managing baseline configurations; mechanisms supporting configuration control of the baseline configuration; organizational processes for developing and documenting an inventory of system components; organizational processes for updating inventory of system components; mechanisms supporting or implementing the system inventory; mechanisms implementing updating of the system inventory].</test>
        <objective>[a] Approved system components are identified;</objective>
        <objective>[b] Implemented system components are identified;</objective>
        <objective>[c] An authoritative source and repository are established to provide a trusted source and accountability for approved and implemented system components; and</objective>
        <objective>[d] An authoritative source and repository are maintained to provide a trusted source and accountability for approved and implemented system components.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.4.2</nist>
      <name>Security Configuration Enforcement</name>
      <description>Establish and enforce security configuration settings for information technology products employed in organizational systems.</description>
      <discussion>Configuration settings are the set of parameters that can be changed in hardware, software, or firmware components of the system that affect the security posture or functionality of the system. Information technology products for which security-related configuration settings can be defined include mainframe computers, servers, workstations, input and output devices (e.g., scanners, copiers, and printers), network components (e.g., firewalls, routers, gateways, voice and data switches, wireless access points, network appliances, sensors), operating systems, middleware, and applications.  Security parameters are those parameters impacting the security state of systems including the parameters required to satisfy other security requirements. Security parameters include: registry settings; account, file, directory permission settings; and settings for functions, ports, protocols, and remote connections. Organizations establish organization-wide configuration settings and subsequently derive specific configuration settings for systems. The established settings become part of the systems configuration baseline.  Common secure configurations (also referred to as security configuration checklists, lockdown and hardening guides, security reference guides, security technical implementation guides) provide recognized, standardized, and established benchmarks that stipulate secure configuration settings for specific information technology platforms/products and instructions for configuring those system components to meet operational requirements. Common secure configurations can be developed by a variety of organizations including information technology product developers, manufacturers, vendors, consortia, academia, industry, federal agencies, and other organizations in the public and private sectors.  [SP 800-70] and [SP 800-128] provide guidance on security configuration settings.</discussion>
      <source>NIST SP 800-171 Rev 2 3.4.2</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Configuration management policy; procedures addressing configuration settings for the system; configuration management plan; security plan; system design documentation; system configuration settings and associated documentation; security configuration checklists; evidence supporting approved deviations from established configuration settings; change control records; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with security configuration management responsibilities; personnel with information security responsibilities; system or network administrators].</interview>
        <test>[SELECT FROM: Organizational processes for managing configuration settings; mechanisms that implement, monitor, and/or control system configuration settings; mechanisms that identify and/or document deviations from established configuration settings].</test>
        <objective>[a] security configuration settings for information technology products employed in the system are established and included in the baseline configuration; and</objective>
        <objective>[b] security configuration settings for information technology products employed in the system are enforced.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L3</level>
      <nist>3.4.2e</nist>
      <name>Automated Detection &amp; Remediation</name>
      <description>Employ automated mechanisms to detect misconfigured or unauthorized system components; after detection, remove the components or place the components in a quarantine or remediation network to facilitate patching, re-configuration, or other mitigations.</description>
      <discussion>System components used to process, store, transmit, or protect CUI are monitored and checked against the authoritative source (i.e., hardware and software inventory and associated baseline configurations). From an automated assessment perspective, the system description provided by the authoritative source is referred to as the desired state. Using automated tools, the desired state is compared to the actual state to check for compliance or deviations. Security responses to system components that are unknown or that deviate from approved configurations can include removing the components; halting system functions or processing; placing the system components in a quarantine or remediation network that facilitates patching, re-configuration, or other mitigations; or issuing alerts and/or notifications to personnel when there is an unauthorized modification of an organization-defined configuration item. Responses can be automated, manual, or procedural. Components that are removed from the system are rebuilt from the trusted configuration baseline established by the authoritative source. [IR 8011-1] provides guidance on using automation support to assess system configurations.</discussion>
      <source>NIST SP 800-172 3.4.2e</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Configuration management policy; procedures addressing the baseline configuration of the system; configuration management plan; authoritative source or repository; enterprise architecture documentation; system design documentation; system architecture and configuration documentation; system procedures addressing system configuration change control; configuration settings and associated documentation; change control records; change control audit and review reports; agenda/minutes from configuration change control oversight meetings; alerts/notifications of unauthorized baseline configuration changes; security plan; system audit records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Organizational personnel responsible for configuration management; organizational personnel responsible for information security; organizational personnel  responsible for configuration change control; system developers; system/network administrators; members of a change control board or similar roles].</interview>
        <test>[SELECT FROM: Automated mechanisms supporting configuration control of the baseline configuration; automated mechanisms that implement security responses to changes to the baseline configurations; automated mechanisms that implement configuration change control; automated mechanisms that detect misconfigured or unauthorized system components].</test>
        <objective>[a] Automated mechanisms to detect misconfigured or unauthorized system components are identified;</objective>
        <objective>[b] Automated mechanisms are employed to detect misconfigured or unauthorized system components;</objective>
        <objective>[c] Misconfigured or unauthorized system components are detected; and</objective>
        <objective>[d] After detection, system components are removed or placed in a quarantine or remediation network to facilitate patching, re-configuration, or other mitigations.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.4.3</nist>
      <name>System Change Management</name>
      <description>Track, review, approve or disapprove, and log changes to organizational systems.</description>
      <discussion>Tracking, reviewing, approving/disapproving, and logging changes is called configuration change control. Configuration change control for organizational systems involves the systematic proposal, justification, implementation, testing, review, and disposition of changes to the systems, including system upgrades and modifications. Configuration change control includes changes to baseline configurations for components and configuration items of systems, changes to configuration settings for information technology products (e.g., operating systems, applications, firewalls, routers, and mobile devices), unscheduled and unauthorized changes, and changes to remediate vulnerabilities.  Processes for managing configuration changes to systems include Configuration Control Boards or Change Advisory Boards that review and approve proposed changes to systems. For new development systems or systems undergoing major upgrades, organizations consider including representatives from development organizations on the Configuration Control Boards or Change Advisory Boards. Audit logs of changes include activities before and after changes are made to organizational systems and the activities required to implement such changes.  [SP 800-128] provides guidance on configuration change control.</discussion>
      <source>NIST SP 800-171 Rev 2 3.4.3</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Configuration management policy; procedures addressing system configuration change control; configuration management plan; system architecture and configuration documentation; security plan; change control records; system audit logs and records; change control audit and review reports; agenda/minutes from configuration change control oversight meetings; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with configuration change control responsibilities; personnel with information security responsibilities; system or network administrators; members of change control board or similar].</interview>
        <test>[SELECT FROM: Organizational processes for configuration change control; mechanisms that implement configuration change control].</test>
        <objective>[a] changes to the system are tracked;</objective>
        <objective>[b] changes to the system are reviewed;</objective>
        <objective>[c] changes to the system are approved or disapproved; and</objective>
        <objective>[d] changes to the system are logged.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L3</level>
      <nist>3.4.3e</nist>
      <name>Automated Inventory</name>
      <description>Employ automated discovery and management tools to maintain an up-to-date, complete, accurate, and readily available inventory of system components.</description>
      <discussion>The system component inventory includes system-specific information required for component accountability and to provide support to identify, control, monitor, and verify configuration items in accordance with the authoritative source. The information necessary for effective accountability of system components includes the system name, hardware and software component owners, hardware inventory specifications, software license information, software version numbers, and—for networked components—the machine names and network addresses. Inventory specifications include the manufacturer, supplier information, component type, date of receipt, cost, model, serial number, and physical location. Organizations also use automated mechanisms to implement and maintain authoritative (i.e., up-to-date, complete, accurate, and available) baseline configurations for systems that include hardware and software inventory tools, configuration management tools, and network management tools. Tools can be used to track version numbers on operating systems, applications, types of software installed, and current patch levels.</discussion>
      <source>NIST SP 800-172 3.4.3e</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Configuration management policy; configuration management plan; procedures addressing system component inventory; procedures addressing the baseline configuration of the system; configuration management plan; system design documentation; system architecture and configuration documentation; security plan; system configuration settings and associated documentation; configuration change control records; system inventory records; change control records; system maintenance records; system audit records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Organizational personnel responsible for information security; organizational personnel responsible for configuration management; organizational personnel responsible for managing the automated mechanisms implementing the system component inventory; system developers; system/network administrators].</interview>
        <test>[SELECT FROM: Automated mechanisms implementing baseline configuration maintenance; automated mechanisms implementing the system component inventory].</test>
        <objective>[a] Automated discovery and management tools for the inventory of system components are identified;</objective>
        <objective>[b] An up-to-date, complete, accurate, and readily available inventory of system components exists; and</objective>
        <objective>[c] Automated discovery and management tools are employed to maintain an up-to-date, complete, accurate, and readily available inventory of system components.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.4.4</nist>
      <name>Security Impact Analysis</name>
      <description>Analyze the security impact of changes prior to implementation.</description>
      <discussion>Organizational personnel with information security responsibilities (e.g., system administrators, system security officers, system security managers, and systems security engineers) conduct security impact analyses. Individuals conducting security impact analyses possess the necessary skills and technical expertise to analyze the changes to systems and the associated security ramifications. Security impact analysis may include reviewing security plans to understand security requirements and reviewing system design documentation to understand the implementation of controls and how specific changes might affect the controls. Security impact analyses may also include risk assessments to better understand the impact of the changes and to determine if additional controls are required.  [SP 800-128] provides guidance on configuration change control and security impact analysis.</discussion>
      <source>NIST SP 800-171 Rev 2 3.4.4</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Configuration management policy; procedures addressing security impact analysis for changes to the system; configuration management plan; security impact analysis documentation; security plan; analysis tools and associated outputs; change control records; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with responsibility for conducting security impact analysis; personnel with information security responsibilities; system or network administrators].</interview>
        <test>[SELECT FROM: Organizational processes for security impact analysis].</test>
        <objective>[a] the security impact of changes to the system is analyzed prior to implementation.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.4.5</nist>
      <name>Access Restrictions for Change</name>
      <description>Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems.</description>
      <discussion>Any changes to the hardware, software, or firmware components of systems can potentially have significant effects on the overall security of the systems. Therefore, organizations permit only qualified and authorized individuals to access systems for purposes of initiating changes, including upgrades and modifications. Access restrictions for change also include software libraries.  Access restrictions include physical and logical access control requirements, workflow automation, media libraries, abstract layers (e.g., changes implemented into external interfaces rather than directly into systems), and change windows (e.g., changes occur only during certain specified times). In addition to security concerns, commonly-accepted due diligence for configuration management includes access restrictions as an essential part in ensuring the ability to effectively manage the configuration.  [SP 800-128] provides guidance on configuration change control.</discussion>
      <source>NIST SP 800-171 Rev 2 3.4.5</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Configuration management policy; procedures addressing access restrictions for changes to the system; security plan; configuration management plan; system design documentation; system architecture and configuration documentation; system configuration settings and associated documentation; logical access approvals; physical access approvals; access credentials; change control records; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with logical access control responsibilities; personnel with physical access control responsibilities; personnel with information security responsibilities; system or network administrators].</interview>
        <test>[SELECT FROM: Organizational processes for managing access restrictions associated with changes to the system; mechanisms supporting, implementing, and enforcing access restrictions associated with changes to the system].</test>
        <objective>[a] physical access restrictions associated with changes to the system are defined;</objective>
        <objective>[b] physical access restrictions associated with changes to the system are documented;</objective>
        <objective>[c] physical access restrictions associated with changes to the system are approved;</objective>
        <objective>[d] physical access restrictions associated with changes to the system are enforced;</objective>
        <objective>[e] logical access restrictions associated with changes to the system are defined;</objective>
        <objective>[f] logical access restrictions associated with changes to the system are documented;</objective>
        <objective>[g] logical access restrictions associated with changes to the system are approved; and</objective>
        <objective>[h] logical access restrictions associated with changes to the system are enforced.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.4.6</nist>
      <name>Least Functionality</name>
      <description>Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities.</description>
      <discussion>Systems can provide a wide variety of functions and services. Some of the functions and services routinely provided by default, may not be necessary to support essential organizational missions, functions, or operations. It is sometimes convenient to provide multiple services from single system components. However, doing so increases risk over limiting the services provided by any one component. Where feasible, organizations limit component functionality to a single function per component.  Organizations review functions and services provided by systems or components of systems, to determine which functions and services are candidates for elimination. Organizations disable unused or unnecessary physical and logical ports and protocols to prevent unauthorized connection of devices, transfer of information, and tunneling. Organizations can utilize network scanning tools, intrusion detection and prevention systems, and end-point protections such as firewalls and host-based intrusion detection systems to identify and prevent the use of prohibited functions, ports, protocols, and services.</discussion>
      <source>NIST SP 800-171 Rev 2 3.4.6</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Configuration management policy; configuration management plan; procedures addressing least functionality in the system; security plan; system design documentation; system configuration settings and associated documentation; security configuration checklists; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with security configuration management responsibilities; personnel with information security responsibilities; system or network administrators].</interview>
        <test>[SELECT FROM: Organizational processes prohibiting or restricting functions, ports, protocols, or services; mechanisms implementing restrictions or prohibition of functions, ports, protocols, or services].</test>
        <objective>[a] essential system capabilities are defined based on the principle of least functionality; and</objective>
        <objective>[b] the system is configured to provide only the defined essential capabilities.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.4.7</nist>
      <name>Nonessential Functionality</name>
      <description>Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services.</description>
      <discussion>Restricting the use of nonessential software (programs) includes restricting the roles allowed to approve program execution; prohibiting auto-execute; program blacklisting and whitelisting; or restricting the number of program instances executed at the same time. The organization makes a security-based determination which functions, ports, protocols, and/or services are restricted. Bluetooth, File Transfer Protocol (FTP), and peer-to-peer networking are examples of protocols organizations consider preventing the use of, restricting, or disabling.</discussion>
      <source>NIST SP 800-171 Rev 2 3.4.7</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Configuration management policy; procedures addressing least functionality in the system; configuration management plan; security plan; system design documentation; system configuration settings and associated documentation; specifications for preventing software program execution; security configuration checklists; documented reviews of programs, functions, ports, protocols, and/or services; change control records; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with responsibilities for reviewing programs, functions, ports, protocols, and services on the system; personnel with information security responsibilities; system or network administrators; system developers].</interview>
        <test>[SELECT FROM: Organizational processes for reviewing and disabling nonessential programs, functions, ports, protocols, or services; mechanisms implementing review and handling of nonessential programs, functions, ports, protocols, or services; organizational processes preventing program execution on the system; organizational processes for software program usage and restrictions; mechanisms supporting or implementing software program usage and restrictions; mechanisms preventing program execution on the system].</test>
        <objective>[a] essential programs are defined;</objective>
        <objective>[b] the use of nonessential programs is defined;</objective>
        <objective>[c] the use of nonessential programs is restricted, disabled, or prevented as defined;</objective>
        <objective>[d] essential functions are defined;</objective>
        <objective>[e] the use of nonessential functions is defined;</objective>
        <objective>[f] the use of nonessential functions is restricted, disabled, or prevented as defined;</objective>
        <objective>[g] essential ports are defined;</objective>
        <objective>[h] the use of nonessential ports is defined;</objective>
        <objective>[i] the use of nonessential ports is restricted, disabled, or prevented as defined;</objective>
        <objective>[j] essential protocols are defined;</objective>
        <objective>[k] the use of nonessential protocols is defined;</objective>
        <objective>[l] the use of nonessential protocols is restricted, disabled, or prevented as defined;</objective>
        <objective>[m] essential services are defined;</objective>
        <objective>[n] the use of nonessential services is defined; and</objective>
        <objective>[o] the use of nonessential services is restricted, disabled, or prevented as defined.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.4.8</nist>
      <name>Application Execution Policy</name>
      <description>Apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or deny-all, permit-by-exception (whitelisting) policy to allow the execution of authorized software.</description>
      <discussion>The process used to identify software programs that are not authorized to execute on systems is commonly referred to as blacklisting. The process used to identify software programs that are authorized to execute on systems is commonly referred to as whitelisting. Whitelisting is the stronger of the two policies for restricting software program execution. In addition to whitelisting, organizations consider verifying the integrity of whitelisted software programs using, for example, cryptographic checksums, digital signatures, or hash functions. Verification of whitelisted software can occur either prior to execution or at system startup.  [SP 800-167] provides guidance on application whitelisting.</discussion>
      <source>NIST SP 800-171 Rev 2 3.4.8</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Configuration management policy; procedures addressing least functionality in the system; security plan; configuration management plan; system design documentation; system configuration settings and associated documentation; list of software programs not authorized to execute on the system; list of software programs authorized to execute on the system; security configuration checklists; review and update records associated with list of authorized or unauthorized software programs; change control records; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with responsibilities for identifying software authorized or not authorized to execute on the system; personnel with information security responsibilities; system or network administrators].</interview>
        <test>[SELECT FROM: Organizational process for identifying, reviewing, and updating programs authorized or not authorized to execute on the system; process for implementing blacklisting or whitelisting; mechanisms supporting or implementing blacklisting or whitelisting].</test>
        <objective>[a] a policy specifying whether whitelisting or blacklisting is to be implemented is specified;</objective>
        <objective>[b] the software allowed to execute under whitelisting or denied use under blacklisting is specified; and</objective>
        <objective>[c] whitelisting to allow the execution of authorized software or blacklisting to prevent the use of unauthorized software is implemented as specified.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.4.9</nist>
      <name>User-Installed Software</name>
      <description>Control and monitor user-installed software.</description>
      <discussion>Users can install software in organizational systems if provided the necessary privileges. To maintain control over the software installed, organizations identify permitted and prohibited actions regarding software installation through policies. Permitted software installations include updates and security patches to existing software and applications from organization-approved “app stores.” Prohibited software installations may include software with unknown or suspect pedigrees or software that organizations consider potentially malicious. The policies organizations select governing user-installed software may be organization-developed or provided by some external entity. Policy enforcement methods include procedural methods, automated methods, or both.</discussion>
      <source>NIST SP 800-171 Rev 2 3.4.9</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Configuration management policy; procedures addressing user installed software; configuration management plan; security plan; system design documentation; system configuration settings and associated documentation; list of rules governing user-installed software; system monitoring records; system audit logs and records; continuous monitoring strategy; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with responsibilities for governing user-installed software; personnel operating, using, or maintaining the system; personnel monitoring compliance with user-installed software policy; personnel with information security responsibilities; system or network administrators].</interview>
        <test>[SELECT FROM: Organizational processes governing user-installed software on the system; mechanisms enforcing rules or methods for governing the installation of software by users; mechanisms monitoring policy compliance].</test>
        <objective>[a] a policy for controlling the installation of software by users is established;</objective>
        <objective>[b] installation of software by users is controlled based on the established policy; and</objective>
        <objective>[c] installation of software by users is monitored.</objective>
      </assessment>
    </practice>
  </domain>
  <domain>
    <name>Identification and Authentication</name>
    <description>Apply zero-trust security principals to user and service access</description>
    <icon>fas fa-id-badge</icon>
    <code>IA</code>
    <practice>
      <level>L1</level>
      <nist>3.5.1</nist>
      <far>b.1.v</far>
      <name>Identification</name>
      <description>Identify information system users, processes acting on behalf of users, or devices.</description>
      <discussion>Common device identifiers include Media Access Control (MAC), Internet Protocol (IP) addresses, or device-unique token identifiers. Management of individual identifiers is not applicable to shared system accounts. Typically, individual identifiers are the user names associated with the system accounts assigned to those individuals. Organizations may require unique identification of individuals in group accounts or for detailed accountability of individual activity. In addition, this requirement addresses individual identifiers that are not necessarily associated with system accounts. Organizational devices requiring identification may be defined by type, by device, or by a combination of type/device.  [SP 800-63-3] provides guidance on digital identities.</discussion>
      <source>FAR Clause 52.204-21 b.1.v, NIST SP 800-171 Rev 2 3.5.1</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Identification and authentication policy; procedures addressing user identification and authentication; security plan, system design documentation; system configuration settings and associated documentation; system audit logs and records; list of system accounts; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with system operations responsibilities; personnel with information security responsibilities; system or network administrators; personnel with account management responsibilities; system developers].</interview>
        <test>[SELECT FROM: Organizational processes for uniquely identifying and authenticating users; mechanisms supporting or implementing identification and authentication capability].</test>
        <objective>[a] system users are identified;</objective>
        <objective>[b] processes acting on behalf of users are identified; and</objective>
        <objective>[c] devices accessing the system are identified.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L3</level>
      <nist>3.5.1e</nist>
      <name>Bidirectional Authentication</name>
      <description>Identify and authenticate systems and system components, where possible, before establishing a network connection using bidirectional authentication that is cryptographically based and replay resistant.</description>
      <discussion>Cryptographically-based and replay-resistant authentication between systems, components, and devices addresses the risk of unauthorized access from spoofing (i.e., claiming a false identity). The requirement applies to client-server authentication, server-server authentication, and device authentication (including mobile devices). The cryptographic key for authentication transactions is stored in suitably secure storage available to the authenticator application (e.g., keychain storage, Trusted Platform Module [TPM], Trusted Execution Environment [TEE], or secure element). Mandating authentication requirements at every connection point may not be practical, and therefore, such requirements may only be applied periodically or at the initial point of network connection. [SP 800-63-3] provides guidance on identity and authenticator management.</discussion>
      <source>NIST SP 800-172 3.5.1e</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Identification and authentication policy; procedures addressing device identification and authentication; network connection policy; security plan; system configuration settings and associated documentation; system design documentation; list of devices requiring unique identification and authentication; device connection reports; system audit records; list of privileged system accounts; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Organizational personnel responsible for system operations; organizational personnel responsible for account management; organizational personnel  responsible for device identification and authentication; organizational personnel responsible for information security; system/network administrators; system developers].</interview>
        <test>[SELECT FROM: Cryptographically-based bidirectional authentication mechanisms; mechanisms supporting and/or implementing network connection policy; mechanisms supporting and/or implementing replay-resistant authentication mechanisms; mechanisms supporting and/or implementing an identification and authentication capability; mechanisms supporting and/or implementing a device identification and authentication capability].</test>
        <objective>[ODP1] Systems and system components to identify and authenticate are defined;</objective>
        <objective>[a] Bidirectional authentication that is cryptographically-based is implemented;</objective>
        <objective>[b] Bidirectional authentication that is replay-resistant is implemented; and</objective>
        <objective>[c] Systems and system components, where possible, are identified and authenticated before establishing a network connection using bidirectional authentication that is cryptographically-based and replay-resistant.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L1</level>
      <nist>3.5.2</nist>
      <far>b.1.vi</far>
      <name>Authentication</name>
      <description>Authenticate (or verify) the identities of those users, processes, or devices, as a prerequisite to allowing access to organizational information systems.</description>
      <discussion>Individual authenticators include the following: passwords, key cards, cryptographic devices, and one-time password devices. Initial authenticator content is the actual content of the authenticator, for example, the initial password. In contrast, the requirements about authenticator content include the minimum password length. Developers ship system components with factory default authentication credentials to allow for initial installation and configuration. Default authentication credentials are often well known, easily discoverable, and present a significant security risk.  Systems support authenticator management by organization-defined settings and restrictions for various authenticator characteristics including minimum password length, validation time window for time synchronous one-time tokens, and number of allowed rejections during the verification stage of biometric authentication. Authenticator management includes issuing and revoking, when no longer needed, authenticators for temporary access such as that required for remote maintenance. Device authenticators include certificates and passwords.  [SP 800-63-3] provides guidance on digital identities.</discussion>
      <source>FAR Clause 52.204-21 b.1.vi, NIST SP 800-171 Rev 2 3.5.2</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Identification and authentication policy; procedures addressing authenticator management; security plan; system design documentation; system configuration settings and associated documentation; list of system authenticator types; change control records associated with managing system authenticators; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with authenticator management responsibilities; personnel with information security responsibilities; system or network administrators].</interview>
        <test>[SELECT FROM: Mechanisms supporting or implementing authenticator management capability].</test>
        <objective>[a] the identity of each user is authenticated or verified as a prerequisite to system access;</objective>
        <objective>[b] the identity of each process acting on behalf of a user is authenticated or verified as a prerequisite to system access; and</objective>
        <objective>[c] the identity of each device accessing or connecting to the system is authenticated or verified as a prerequisite to system access.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.5.3</nist>
      <name>Multifactor Authentication</name>
      <description>Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.</description>
      <discussion>Multifactor authentication requires the use of two or more different factors to authenticate. The factors are defined as something you know (e.g., password, personal identification number [PIN]); something you have (e.g., cryptographic identification device, token); or something you are (e.g., biometric). Multifactor authentication solutions that feature physical authenticators include hardware authenticators providing time-based or challenge-response authenticators and smart cards. In addition to authenticating users at the system level (i.e., at logon), organizations may also employ authentication mechanisms at the application level, when necessary, to provide increased information security. Access to organizational systems is defined as local access or network access. Local access is any access to organizational systems by users (or processes acting on behalf of users) where such access is obtained by direct connections without the use of networks. Network access is access to systems by users (or processes acting on behalf of users) where such access is obtained through network connections (i.e., nonlocal accesses). Remote access is a type of network access that involves communication through external networks. The use of encrypted virtual private networks for connections between organization-controlled and non-organization controlled endpoints may be treated as internal networks with regard to protecting the confidentiality of information.  [SP 800-63-3] provides guidance on digital identities. [24] Multifactor authentication requires two or more different factors to achieve authentication. The factors include: something you know (e.g., password/PIN); something you have (e.g., cryptographic identification device, token); or something you are (e.g., biometric). The requirement for multifactor authentication should not be interpreted as requiring federal Personal Identity Verification (PIV) card or Department of Defense Common Access Card (CAC)-like solutions. A variety of multifactor solutions (including those with replay resistance) using tokens and biometrics are commercially available. Such solutions may employ hard tokens (e.g., smartcards, key fobs, or dongles) or soft tokens to store user credentials. [25] Local access is any access to a system by a user (or process acting on behalf of a user) communicating through a direct connection without the use of a network. Network access is any access to a system by a user (or a process acting on behalf of a user) communicating through a network (e.g., local area network, wide area network, Internet).</discussion>
      <source>NIST SP 800-171 Rev 2 3.5.3</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Identification and authentication policy; procedures addressing user identification and authentication; security plan; system design documentation; system configuration settings and associated documentation; system audit logs and records; list of system accounts; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with system operations responsibilities; personnel with account management responsibilities; personnel with information security responsibilities; system or network administrators; system developers].</interview>
        <test>[SELECT FROM: Mechanisms supporting or implementing multifactor authentication capability].</test>
        <objective>[a] privileged accounts are identified;</objective>
        <objective>[b] multifactor authentication is implemented for local access to privileged accounts;</objective>
        <objective>[c] multifactor authentication is implemented for network access to privileged accounts; and</objective>
        <objective>[d] multifactor authentication is implemented for network access to non-privileged accounts.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L3</level>
      <nist>3.5.3e</nist>
      <name>Block Untrusted Assets</name>
      <description>Employ automated or manual/procedural mechanisms to prohibit system components from connecting to organizational systems unless the components are known, authenticated, in a properly configured state, or in a trust profile.</description>
      <discussion>Identification and authentication of system components and component configurations can be determined, for example, via a cryptographic hash of the component. This is also known as device attestation and known operating state or trust profile. A trust profile based on factors such as the user, authentication method, device type, and physical location is used to make dynamic decisions on authorizations to data of varying types. If device attestation is the means of identification and authentication, then it is important that patches and updates to the device are handled via a configuration management process such that the patches and updates are done securely and do not disrupt the identification and authentication of other devices. [IR 8011-1] provides guidance on using automation support to assess system configurations.</discussion>
      <source>NIST SP 800-172 3.5.3e</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Configuration management policy; identification and authentication policy; system and information integrity policy; procedures addressing system component inventory; procedures addressing device identification and authentication; procedures addressing device configuration management; procedures addressing system monitoring tools and techniques; configuration management plan; security plan; system design documentation; system configuration settings and associated documentation; system inventory records; configuration management records; system monitoring records; alerts/notifications of unauthorized components within the system; change control records; system audit records; system monitoring tools and techniques documentation; documented authorization/approval of network services; notifications or alerts of unauthorized network services; system monitoring logs or records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Organizational personnel responsible for managing the mechanisms implementing unauthorized system component detection; organizational personnel responsible for device identification and authentication; organizational personnel responsible for information security; organizational personnel responsible for installing, configuring, and/or maintaining the system; system/network administrators; organizational personnel responsible for monitoring the system; system developers].</interview>
        <test>[SELECT FROM: Mechanisms implementing the detection of unauthorized system components; mechanisms supporting and/or implementing a device identification and authentication capability; mechanisms for providing alerts; mechanisms supporting and/or implementing configuration management; cryptographic mechanisms supporting device attestation; mechanisms supporting and/or implementing a system monitoring capability; mechanisms for auditing network services].</test>
        <objective>[a] System components that are known, authenticated, in a properly configured state, or in a trust profile are identified;</objective>
        <objective>[b] Automated or manual/procedural mechanisms to prohibit system components from connecting to organizational systems are identified; and</objective>
        <objective>[c] Automated or manual/procedural mechanisms are employed to prohibit system components from connecting to organizational systems unless the components are known, authenticated, in a properly configured state, or in a trust profile.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.5.4</nist>
      <name>Replay-Resistant Authentication</name>
      <description>Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts.</description>
      <discussion>Authentication processes resist replay attacks if it is impractical to successfully authenticate by recording or replaying previous authentication messages. Replay-resistant techniques include protocols that use nonces or challenges such as time synchronous or challenge-response one-time authenticators.  [SP 800-63-3] provides guidance on digital identities.</discussion>
      <source>NIST SP 800-171 Rev 2 3.5.4</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Identification and authentication policy; procedures addressing user identification and authentication; security plan; system design documentation; system configuration settings and associated documentation; system audit logs and records; list of privileged system accounts; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with system operations responsibilities; personnel with account management responsibilities; personnel with information security responsibilities; system or network administrators; system developers].</interview>
        <test>[SELECT FROM: Mechanisms supporting or implementing identification and authentication capability or replay resistant authentication mechanisms].</test>
        <objective>[a] replay-resistant authentication mechanisms are implemented for network account access to privileged and non-privileged accounts.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.5.5</nist>
      <name>Identifier Reuse</name>
      <description>Prevent reuse of identifiers for a defined period.</description>
      <discussion>Identifiers are provided for users, processes acting on behalf of users, or devices (3.5.1). Preventing reuse of identifiers implies preventing the assignment of previously used individual, group, role, or device identifiers to different individuals, groups, roles, or devices.</discussion>
      <source>NIST SP 800-171 Rev 2 3.5.5</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Identification and authentication policy; procedures addressing identifier management; procedures addressing account management; security plan; system design documentation; system configuration settings and associated documentation; list of system accounts; list of identifiers generated from physical access control devices; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with identifier management responsibilities; personnel with information security responsibilities; system or network administrators; system developers].</interview>
        <test>[SELECT FROM: Mechanisms supporting or implementing identifier management].</test>
        <objective>[a] a period within which identifiers cannot be reused is defined; and</objective>
        <objective>[b] reuse of identifiers is prevented within the defined period.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.5.6</nist>
      <name>Identifier Handling</name>
      <description>Disable identifiers after a defined period of inactivity.</description>
      <discussion>Inactive identifiers pose a risk to organizational information because attackers may exploit an inactive identifier to gain undetected access to organizational devices. The owners of the inactive accounts may not notice if unauthorized access to the account has been obtained.</discussion>
      <source>NIST SP 800-171 Rev 2 3.5.6</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Identification and authentication policy; procedures addressing identifier management; procedures addressing account management; security plan; system design documentation; system configuration settings and associated documentation; list of system accounts; list of identifiers generated from physical access control devices; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with identifier management responsibilities; personnel with information security responsibilities; system or network administrators; system developers].</interview>
        <test>[SELECT FROM: Mechanisms supporting or implementing identifier management].</test>
        <objective>[a] a period of inactivity after which an identifier is disabled is defined; and</objective>
        <objective>[b] identifiers are disabled after the defined period of inactivity.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.5.7</nist>
      <name>Password Complexity</name>
      <description>Enforce a minimum password complexity and change of characters when new passwords are created.</description>
      <discussion>This requirement applies to single-factor authentication of individuals using passwords as individual or group authenticators, and in a similar manner, when passwords are used as part of multifactor authenticators. The number of changed characters refers to the number of changes required with respect to the total number of positions in the current password. To mitigate certain brute force attacks against passwords, organizations may also consider salting passwords.</discussion>
      <source>NIST SP 800-171 Rev 2 3.5.7</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Identification and authentication policy; password policy; procedures addressing authenticator management; security plan; system design documentation; system configuration settings and associated documentation; password configurations and associated documentation; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with authenticator management responsibilities; personnel with information security responsibilities; system or network administrators; system developers].</interview>
        <test>[SELECT FROM: Mechanisms supporting or implementing password-based authenticator management capability].</test>
        <objective>[a] password complexity requirements are defined;</objective>
        <objective>[b] password change of character requirements are defined;</objective>
        <objective>[c] minimum password complexity requirements as defined are enforced when new passwords are created; and</objective>
        <objective>[d] minimum password change of character requirements as defined are enforced when new passwords are created.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.5.8</nist>
      <name>Password Reuse</name>
      <description>Prohibit password reuse for a specified number of generations.</description>
      <discussion>Password lifetime restrictions do not apply to temporary passwords</discussion>
      <source>NIST SP 800-171 Rev 2 3.5.8</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Identification and authentication policy; password policy; procedures addressing authenticator management; security plan; system design documentation; system configuration settings and associated documentation; password configurations and associated documentation; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with authenticator management responsibilities; personnel with information security responsibilities; system or network administrators; system developers].</interview>
        <test>[SELECT FROM: Mechanisms supporting or implementing password-based authenticator management capability].</test>
        <objective>[a] the number of generations during which a password cannot be reused is specified and</objective>
        <objective>[b] reuse of passwords is prohibited during the specified number of generations.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.5.9</nist>
      <name>Temporary Passwords</name>
      <description>Allow temporary password use for system logons with an immediate change to a permanent password.</description>
      <discussion>Changing temporary passwords to permanent passwords immediately after system logon ensures that the necessary strength of the authentication mechanism is implemented at the earliest opportunity, reducing the susceptibility to authenticator compromises.</discussion>
      <source>NIST SP 800-171 Rev 2 3.5.9</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Identification and authentication policy; password policy; procedures addressing authenticator management; security plan; system design documentation; system configuration settings and associated documentation; password configurations and associated documentation; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with authenticator management responsibilities; personnel with information security responsibilities; system or network administrators; system developers].</interview>
        <test>[SELECT FROM: Mechanisms supporting or implementing password-based authenticator management capability].</test>
        <objective>[a] an immediate change to a permanent password is required when a temporary password is used for system logon.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.5.10</nist>
      <name>Cryptographically-Protected Passwords</name>
      <description>Store and transmit only cryptographically-protected passwords.</description>
      <discussion>Cryptographically-protected passwords use salted one-way cryptographic hashes of passwords. See [NIST CRYPTO].</discussion>
      <source>NIST SP 800-171 Rev 2 3.5.10</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Identification and authentication policy; password policy; procedures addressing authenticator management; security plan; system design documentation; system configuration settings and associated documentation; password configurations and associated documentation; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with authenticator management responsibilities; personnel with information security responsibilities; system or network administrators; system developers].</interview>
        <test>[SELECT FROM: Mechanisms supporting or implementing password-based authenticator management capability].</test>
        <objective>[a] passwords are cryptographically protected in storage; and</objective>
        <objective>[b] passwords are cryptographically protected in transit.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.5.11</nist>
      <name>Obscure Feedback</name>
      <description>Obscure feedback of authentication information.</description>
      <discussion>The feedback from systems does not provide any information that would allow unauthorized individuals to compromise authentication mechanisms. For some types of systems or system components, for example, desktop or notebook computers with relatively large monitors, the threat (often referred to as shoulder surfing) may be significant. For other types of systems or components, for example, mobile devices with small displays, this threat may be less significant, and is balanced against the increased likelihood of typographic input errors due to the small keyboards. Therefore, the means for obscuring the authenticator feedback is selected accordingly. Obscuring authenticator feedback includes displaying asterisks when users type passwords into input devices or displaying feedback for a very limited time before fully obscuring it.</discussion>
      <source>NIST SP 800-171 Rev 2 3.5.11</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Identification and authentication policy; procedures addressing authenticator feedback; security plan; system design documentation; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with information security responsibilities; system or network administrators; system developers].</interview>
        <test>[SELECT FROM: Mechanisms supporting or implementing the obscuring of feedback of authentication information during authentication].</test>
        <objective>[a] authentication information is obscured during the authentication process.</objective>
      </assessment>
    </practice>
  </domain>
  <domain>
    <name>Incident Response</name>
    <description>Provide an incident response capability with robust planning, monitoring, reseponse capabilities</description>
    <icon>fas fa-diagnoses</icon>
    <code>IR</code>
    <practice>
      <level>L2</level>
      <nist>3.6.1</nist>
      <name>Incident Handling</name>
      <description>Establish an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities.</description>
      <discussion>Organizations recognize that incident handling capability is dependent on the capabilities of organizational systems and the mission/business processes being supported by those systems. Organizations consider incident handling as part of the definition, design, and development of mission/business processes and systems. Incident-related information can be obtained from a variety of sources including audit monitoring, network monitoring, physical access monitoring, user and administrator reports, and reported supply chain events. Effective incident handling capability includes coordination among many organizational entities including mission/business owners, system owners, authorizing officials, human resources offices, physical and personnel security offices, legal departments, operations personnel, procurement offices, and the risk executive.  As part of user response activities, incident response training is provided by organizations and is linked directly 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, regular users may only need to know who to call or how to recognize an incident on the system; system administrators may require additional training on how to handle or remediate incidents; and incident responders may receive more specific training on forensics, reporting, system recovery, and restoration. Incident response training includes user training in the identification/reporting of suspicious activities from external and internal sources. User response activities also includes incident response assistance which may consist of help desk support, assistance groups, and access to forensics services or consumer redress services, when required.  [SP 800-61] provides guidance on incident handling. [SP 800-86] and [SP 800-101] provide guidance on integrating forensic techniques into incident response. [SP 800-161] provides guidance on supply chain risk management.</discussion>
      <source>NIST SP 800-171 Rev 2 3.6.1</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Incident response policy; contingency planning policy; procedures addressing incident handling; procedures addressing incident response assistance; incident response plan; contingency plan; security plan; procedures addressing incident response training; incident response training curriculum; incident response training materials; incident response training records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with incident handling responsibilities; personnel with contingency planning responsibilities; personnel with incident response training and operational responsibilities; personnel with incident response assistance and support responsibilities; personnel with access to incident response support and assistance capability; personnel with information security responsibilities].</interview>
        <test>[SELECT FROM: Incident-handling capability for the organization; organizational processes for incident response assistance; mechanisms supporting or implementing incident response assistance].</test>
        <objective>[a] an operational incident-handling capability is established;</objective>
        <objective>[b] the operational incident-handling capability includes preparation;</objective>
        <objective>[c] the operational incident-handling capability includes detection;</objective>
        <objective>[d] the operational incident-handling capability includes analysis;</objective>
        <objective>[e] the operational incident-handling capability includes containment;</objective>
        <objective>[f] the operational incident-handling capability includes recovery; and</objective>
        <objective>[g] the operational incident-handling capability includes user response activities.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L3</level>
      <nist>3.6.1e</nist>
      <name>Security Operations Center</name>
      <description>Establish and maintain a security operations center capability that operates 24/7, with allowance for remote/on-call staff.</description>
      <discussion>A security operations center (SOC) is the focal point for security operations and computer network defense for an organization. The purpose of the SOC is to defend and monitor an organization’s systems and networks (i.e., cyber infrastructure) on an ongoing basis. The SOC is also responsible for detecting, analyzing, and responding to cybersecurity incidents in a timely manner. The SOC is staffed with skilled technical and operational personnel (e.g., security analysts, incident response personnel, systems security engineers); in some instances operates 24 hours per day, seven days per week; and implements technical, management, and operational controls (e.g., monitoring, scanning, and forensics tools) to monitor, fuse, correlate, analyze, and respond to security-relevant event data from multiple sources. Sources of event data include perimeter defenses, network devices (e.g., gateways, routers, and switches), and endpoint agent data feeds. The SOC provides a holistic situational awareness capability to help organizations determine the security posture of the system and organization. An SOC capability can be obtained in many ways. Larger organizations may implement a dedicated SOC while smaller organizations may employ third-party organizations to provide such a capability. [SP 800-61] provides guidance on incident handling. [SP 800-86] and [SP 800-101] provide guidance on integrating forensic techniques into incident response. [SP 800-150] provides guidance on cyber threat information sharing. [SP 800-184] provides guidance on cybersecurity event recovery.</discussion>
      <source>NIST SP 800-172 3.6.1e</source>
      <score>1</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Incident response policy; contingency planning policy; procedures addressing incident handling; procedures addressing the security operations center operations; mechanisms supporting dynamic response capabilities; incident response plan; contingency plan; security plan; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Organizational personnel responsible for incident handling; organizational personnel responsible for contingency planning; security operations center personnel; organizational personnel responsible for information security].</interview>
        <test>[SELECT FROM: Mechanisms that support and/or implement the security operations center capability; mechanisms that support and/or implement the incident handling process].</test>
        <objective>[a] A security operations center capability is established;</objective>
        <objective>[b] The security operations center capability operates 24/7, with allowance for remote/on- call staff; and</objective>
        <objective>[c] The security operations center capability is maintained.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.6.2</nist>
      <name>Incident Reporting</name>
      <description>Track, document, and report incidents to designated officials and/or authorities both internal and external to the organization.</description>
      <discussion>Tracking and documenting system security incidents includes maintaining records about each incident, the status of the incident, and other pertinent information necessary for forensics, evaluating incident details, trends, and handling. Incident information can be obtained from a variety of sources including incident reports, incident response teams, audit monitoring, network monitoring, physical access monitoring, and user/administrator reports.  Reporting incidents addresses specific incident reporting requirements within an organization and the formal incident reporting requirements for the organization. Suspected security incidents may also be reported and include the receipt of suspicious email communications that can potentially contain malicious code. The types of security incidents reported, the content and timeliness of the reports, and the designated reporting authorities reflect applicable laws, Executive Orders, directives, regulations, and policies.  [SP 800-61] provides guidance on incident handling.</discussion>
      <source>NIST SP 800-171 Rev 2 3.6.2</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Incident response policy; procedures addressing incident monitoring; incident response records and documentation; procedures addressing incident reporting; incident reporting records and documentation; incident response plan; security plan; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with incident monitoring responsibilities; personnel with incident reporting responsibilities; personnel who have or should have reported incidents; personnel (authorities) to whom incident information is to be reported; personnel with information security responsibilities].</interview>
        <test>[SELECT FROM: Incident monitoring capability for the organization; mechanisms supporting or implementing tracking and documenting of system security incidents; organizational processes for incident reporting; mechanisms supporting or implementing incident reporting].</test>
        <objective>[a] incidents are tracked;</objective>
        <objective>[b] incidents are documented;</objective>
        <objective>[c] authorities to whom incidents are to be reported are identified;</objective>
        <objective>[d] organizational officials to whom incidents are to be reported are identified;</objective>
        <objective>[e] identified authorities are notified of incidents; and</objective>
        <objective>[f] identified organizational officials are notified of incidents.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L3</level>
      <nist>3.6.2e</nist>
      <name>Cyber Incident Response Team</name>
      <description>Establish and maintain a cyber-incident response team that can be deployed by the organization within 24 hours.</description>
      <discussion>A cyber incident response team (CIRT) is a team of experts that assesses, documents, and responds to cyber incidents so that organizational systems can recover quickly and implement the necessary controls to avoid future incidents. CIRT personnel include, for example, forensic analysts, malicious code analysts, systems security engineers, and real-time operations personnel. The incident handling capability includes performing rapid forensic preservation of evidence and analysis of and response to intrusions. The team members may or may not be full-time but need to be available to respond in the time period required. The size and specialties of the team are based on known and anticipated threats. The team is typically pre-equipped with the software and hardware (e.g., forensic tools) necessary for rapid identification, quarantine, mitigation, and recovery and is familiar with how to preserve evidence and maintain chain of custody for law enforcement or counterintelligence uses. For some organizations, the CIRT can be implemented as a cross-organizational entity or as part of the Security Operations Center (SOC). [SP 800-61] provides guidance on incident handling. [SP 800-86] and [SP 800-101] provide guidance on integrating forensic techniques into incident response. [SP 800-150] provides guidance on cyber threat information sharing. [SP 800-184] provides guidance on cybersecurity event recovery.</discussion>
      <source>NIST SP 800-172 3.6.2e</source>
      <score>1</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Incident response policy; procedures addressing incident response; incident response plan; security plan; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Organizational personnel responsible for incident response; organizational personnel from the incident response team; organizational personnel  responsible for information security].</interview>
        <test>[SELECT FROM: Mechanisms supporting and/or implementing incident response].</test>
        <objective>[a] A cyber incident response team is established;</objective>
        <objective>[b] The cyber incident response team can be deployed by the organization within 24 hours; and</objective>
        <objective>[c] The cyber incident response team is maintained.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.6.3</nist>
      <name>Incident Response Testing</name>
      <description>Test the organizational incident response capability.</description>
      <discussion>Organizations test incident response capabilities to determine the effectiveness of the capabilities and to identify potential weaknesses or deficiencies. Incident response testing includes the use of checklists, walk-through or tabletop exercises, simulations (both parallel and full interrupt), and comprehensive exercises. Incident response testing can also include a determination of the effects on organizational operations (e.g., reduction in mission capabilities), organizational assets, and individuals due to incident response.  [SP 800-84] provides guidance on testing programs for information technology capabilities.</discussion>
      <source>NIST SP 800-171 Rev 2 3.6.3</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Incident response policy; contingency planning policy; procedures addressing incident response testing; procedures addressing contingency plan testing; incident response testing material; incident response test results; incident response test plan; incident response plan; contingency plan; security plan; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with incident response testing responsibilities; personnel with information security responsibilities].</interview>
        <test>[SELECT FROM: Mechanisms and processes for incident response].</test>
        <objective>[a] the incident response capability is tested.</objective>
      </assessment>
    </practice>
  </domain>
  <domain>
    <name>Maintentance</name>
    <description>Track and manage the maintenance of technology assets</description>
    <icon>fas fa-tools</icon>
    <code>MA</code>
    <practice>
      <level>L2</level>
      <nist>3.7.1</nist>
      <name>Perform Maintenance</name>
      <description>Perform maintenance on organizational systems.</description>
      <discussion>This requirement addresses the information security aspects of the system maintenance program and applies to all types of maintenance to any system component (including hardware, firmware, applications) conducted by any local or nonlocal entity. System maintenance also includes those components not directly associated with information processing and data or information retention such as scanners, copiers, and printers. [26] In general, system maintenance requirements tend to support the security objective of availability. However, improper system maintenance or a failure to perform maintenance can result in the unauthorized disclosure of CUI, thus compromising confidentiality of that information.</discussion>
      <source>NIST SP 800-171 Rev 2 3.7.1</source>
      <score>3</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: System maintenance policy; procedures addressing controlled system maintenance; maintenance records; manufacturer or vendor maintenance specifications; equipment sanitization records; media sanitization records; security plan; other relevant documents or records].</examine>
        <interview>[select from: Personnel with system maintenance responsibilities; personnel with information security responsibilities; personnel responsible for media sanitization; system or network administrators].</interview>
        <test>[SELECT FROM: Organizational processes for scheduling, performing, documenting, reviewing, approving, and monitoring maintenance and repairs for systems; organizational processes for sanitizing system components; mechanisms supporting or implementing controlled maintenance; mechanisms implementing sanitization of system components].</test>
        <objective>[a] system maintenance is performed.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.7.2</nist>
      <name>System Maintenance Control</name>
      <description>Provide controls on the tools, techniques, mechanisms, and personnel used to conduct system maintenance.</description>
      <discussion>This requirement addresses security-related issues with maintenance tools that are not within the organizational system boundaries that process, store, or transmit CUI, but are used specifically for diagnostic and repair actions on those systems. Organizations have flexibility in determining the controls in place for maintenance tools, but can include approving, controlling, and monitoring the use of such tools. Maintenance tools are potential vehicles for transporting malicious code, either intentionally or unintentionally, into a facility and into organizational systems. Maintenance tools can include hardware, software, and firmware items, for example, hardware and software diagnostic test equipment and hardware and software packet sniffers.</discussion>
      <source>NIST SP 800-171 Rev 2 3.7.2</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: System maintenance policy; procedures addressing system maintenance tools and media; maintenance records; system maintenance tools and associated documentation; maintenance tool inspection records; security plan; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with system maintenance responsibilities; personnel with information security responsibilities].</interview>
        <test>[SELECT FROM: Organizational processes for approving, controlling, and monitoring maintenance tools; mechanisms supporting or implementing approval, control, and monitoring of maintenance tools; organizational processes for inspecting maintenance tools; mechanisms supporting or implementing inspection of maintenance tools; organizational process for inspecting media for malicious code; mechanisms supporting or implementing inspection of media used for maintenance].</test>
        <objective>[a] tools used to conduct system maintenance are controlled;</objective>
        <objective>[b] techniques used to conduct system maintenance are controlled;</objective>
        <objective>[c] mechanisms used to conduct system maintenance are controlled; and</objective>
        <objective>[d] personnel used to conduct system maintenance are controlled.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.7.3</nist>
      <name>Equipment Sanitization</name>
      <description>Ensure equipment removed for off-site maintenance is sanitized of any CUI.</description>
      <discussion>This requirement addresses the information security aspects of system maintenance that are performed off-site and applies to all types of maintenance to any system component (including applications) conducted by a local or nonlocal entity (e.g., in-contract, warranty, in- house, software maintenance agreement).  [SP 800-88] provides guidance on media sanitization.</discussion>
      <source>NIST SP 800-171 Rev 2 3.7.3</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: System maintenance policy; procedures addressing controlled system maintenance; maintenance records; manufacturer or vendor maintenance specifications; equipment sanitization records; media sanitization records; security plan; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with system maintenance responsibilities; personnel with information security responsibilities; personnel responsible for media sanitization; system or network administrators].</interview>
        <test>[select from: Organizational processes for scheduling, performing, documenting, reviewing, approving, and monitoring maintenance and repairs for systems; organizational processes for sanitizing system components; mechanisms supporting or implementing controlled maintenance; mechanisms implementing sanitization of system components].</test>
        <objective>[a] equipment to be removed from organizational spaces for off-site maintenance is sanitized of any CUI.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.7.4</nist>
      <name>Media Inspection</name>
      <description>Check media containing diagnostic and test programs for malicious code before the media are used in organizational systems.</description>
      <discussion>If, upon inspection of media containing maintenance diagnostic and test programs, organizations determine that the media contain malicious code, the incident is handled consistent with incident handling policies and procedures.</discussion>
      <source>NIST SP 800-171 Rev 2 3.7.4</source>
      <score>3</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: System maintenance policy; procedures addressing system maintenance tools; system maintenance tools and associated documentation; maintenance records; security plan; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with system maintenance responsibilities; personnel with information security responsibilities].</interview>
        <test>[select from: Organizational process for inspecting media for malicious code; mechanisms supporting or implementing inspection of media used for maintenance].</test>
        <objective>[a] media containing diagnostic and test programs are checked for malicious code before being used in organizational systems that process, store, or transmit CUI.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.7.5</nist>
      <name>Nonlocal Maintenance</name>
      <description>Require multifactor authentication to establish nonlocal maintenance sessions via external network connections and terminate such connections when nonlocal maintenance is complete.</description>
      <discussion>Nonlocal maintenance and diagnostic activities are those activities conducted by individuals communicating through an external network. The authentication techniques employed in the establishment of these nonlocal maintenance and diagnostic sessions reflect the network access requirements in 3.5.3.</discussion>
      <source>NIST SP 800-171 Rev 2 3.7.5</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: System maintenance policy; procedures addressing nonlocal system maintenance; security plan; system design documentation; system configuration settings and associated documentation; maintenance records; diagnostic records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with system maintenance responsibilities; personnel with information security responsibilities; system or network administrators].</interview>
        <test>[select from: Organizational processes for managing nonlocal maintenance; mechanisms implementing, supporting, and managing nonlocal maintenance; mechanisms for strong authentication of nonlocal maintenance diagnostic sessions; mechanisms for terminating nonlocal maintenance sessions and network connections].</test>
        <objective>[a] multifactor authentication is used to establish nonlocal maintenance sessions via external network connections; and</objective>
        <objective>[b] nonlocal maintenance sessions established via external network connections are terminated when nonlocal maintenance is complete.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.7.6</nist>
      <name>Maintenance Personnel</name>
      <description>Supervise the maintenance activities of maintenance personnel without required access authorization.</description>
      <discussion>This requirement applies to individuals who are performing hardware or software maintenance on organizational systems, while 3.10.1 addresses physical access for individuals whose maintenance duties place them within the physical protection perimeter of the systems (e.g., custodial staff, physical plant maintenance personnel). Individuals not previously identified as authorized maintenance personnel, such as information technology manufacturers, vendors, consultants, and systems integrators, may require privileged access to organizational systems, for example, when required to conduct maintenance activities with little or no notice. Organizations may choose to issue temporary credentials to these individuals based on organizational risk assessments. Temporary credentials may be for one-time use or for very limited time periods.</discussion>
      <source>NIST SP 800-171 Rev 2 3.7.6</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: System maintenance policy; procedures addressing maintenance personnel; service provider contracts; service-level agreements; list of authorized personnel; maintenance records; access control records; security plan; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with system maintenance responsibilities; personnel with information security responsibilities].</interview>
        <test>[SELECT FROM: Organizational processes for authorizing and managing maintenance personnel; mechanisms supporting or implementing authorization of maintenance personnel].</test>
        <objective>[a] maintenance personnel without required access authorization are supervised during maintenance activities.</objective>
      </assessment>
    </practice>
  </domain>
  <domain>
    <name>Media Protection</name>
    <description>Ensure that media storing controlled unclassified information (CUI) is appropriately marked, secured and sanitized</description>
    <icon>fas fa-save</icon>
    <code>MP</code>
    <practice>
      <level>L2</level>
      <nist>3.8.1</nist>
      <name>Media Protections</name>
      <description>Protect (i.e., physically control and securely store) system media containing CUI, both paper and digital.</description>
      <discussion>System media includes digital and non-digital media. Digital media includes diskettes, magnetic tapes, external and removable hard disk drives, flash drives, compact disks, and digital video disks. Non-digital media includes paper and microfilm. Protecting digital media includes limiting access to design specifications stored on compact disks or flash drives in the media library to the project leader and any individuals on the development team. Physically controlling system media includes conducting inventories, maintaining accountability for stored media, and ensuring procedures are in place to allow individuals to check out and return media to the media library. Secure storage includes a locked drawer, desk, or cabinet, or a controlled media library.  Access to CUI on system media can be limited by physically controlling such media, which includes conducting inventories, ensuring procedures are in place to allow individuals to check out and return media to the media library, and maintaining accountability for all stored media.  [SP 800-111] provides guidance on storage encryption technologies for end user devices.</discussion>
      <source>NIST SP 800-171 Rev 2 3.8.1</source>
      <score>3</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: System media protection policy; procedures addressing media access restrictions; access control policy and procedures; physical and environmental protection policy and procedures; security plan; media storage facilities; access control records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with system media protection responsibilities; personnel with information security responsibilities; system or network administrators].</interview>
        <test>[SELECT FROM: Organizational processes for restricting information media; mechanisms supporting or implementing media access restrictions].</test>
        <objective>[a] paper media containing CUI is physically controlled;</objective>
        <objective>[b] digital media containing CUI is physically controlled;</objective>
        <objective>[c] paper media containing CUI is securely stored; and</objective>
        <objective>[d] digital media containing CUI is securely stored.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.8.2</nist>
      <name>Media Access</name>
      <description>Limit access to CUI on system media to authorized users.</description>
      <discussion>Access can be limited by physically controlling system media and secure storage areas. Physically controlling system media includes conducting inventories, ensuring procedures are in place to allow individuals to check out and return system media to the media library, and maintaining accountability for all stored media. Secure storage includes a locked drawer, desk, or cabinet, or a controlled media library</discussion>
      <source>NIST SP 800-171 Rev 2 3.8.2</source>
      <score>3</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: System media protection policy; procedures addressing media storage; physical and environmental protection policy and procedures; access control policy and procedures; security plan; system media; designated controlled areas; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with system media protection and storage responsibilities; personnel with information security responsibilities].</interview>
        <test>[SELECT FROM: Organizational processes for storing media; mechanisms supporting or implementing secure media storage and media protection].</test>
        <objective>[a] access to CUI on system media is limited to authorized users.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L1</level>
      <nist>3.8.3</nist>
      <far>b.1.vii</far>
      <name>Media Disposal</name>
      <description>Sanitize or destroy information system media containing Federal Contract Information before disposal or release for reuse.</description>
      <discussion>This requirement applies to all system media, digital and non-digital, subject to disposal or reuse. Examples include: digital media found in workstations, network components, scanners, copiers, printers, notebook computers, and mobile devices; and non-digital media such as paper and microfilm. The sanitization process removes information from the media such that the information cannot be retrieved or reconstructed. Sanitization techniques, including clearing, purging, cryptographic erase, and destruction, prevent the disclosure of information to unauthorized individuals when such media is released for reuse or disposal.  Organizations determine the appropriate sanitization methods, recognizing that destruction may be necessary when other methods cannot be applied to the media requiring sanitization. Organizations use discretion on the employment of sanitization techniques and procedures for media containing information that is in the public domain or publicly releasable or deemed to have no adverse impact on organizations or individuals if released for reuse or disposal. Sanitization of non-digital media includes destruction, removing CUI from documents, or redacting selected sections or words from a document by obscuring the redacted sections or words in a manner equivalent in effectiveness to removing the words or sections from the document. NARA policy and guidance control sanitization processes for controlled unclassified information.  [SP 800-88] provides guidance on media sanitization.</discussion>
      <source>FAR Clause 52.204-21 b.1.vii, NIST SP 800-171 Rev 2 3.8.3</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: System media protection policy; procedures addressing media sanitization and disposal; applicable standards and policies addressing media sanitization; security plan; media sanitization records; system audit logs and records; system design documentation; system configuration settings and associated documentation; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with media sanitization responsibilities; personnel with information security responsibilities; system or network administrators].</interview>
        <test>[SELECT FROM: Organizational processes for media sanitization; mechanisms supporting or implementing media sanitization].</test>
        <objective>[a] system media containing [FCI/CUI] is sanitized or destroyed before disposal; and</objective>
        <objective>[b] system media containing [FCI/CUI] is sanitized before it is released for reuse.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.8.4</nist>
      <name>Media Markings</name>
      <description>Mark media with necessary CUI markings and distribution limitations.</description>
      <discussion>The term security marking refers to the application or use of human-readable security attributes. System media includes digital and non-digital media. Marking of system media reflects applicable federal laws, Executive Orders, directives, policies, and regulations. See [NARA MARK]. [27] The implementation of this requirement is per marking guidance in [32 CFR 2002] and [NARA CUI]. Standard Form (SF) 902 (approximate size 2.125” x 1.25”) and SF 903 (approximate size 2.125” x .625”) can be used on media that contains CUI such as hard drives, or USB devices. Both forms are available from https://www.gsaadvantage.gov.</discussion>
      <source>NIST SP 800-171 Rev 2 3.8.4</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: System media protection policy; procedures addressing media marking; physical and environmental protection policy and procedures; security plan; list of system media marking security attributes; designated controlled areas; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with system media protection and marking responsibilities; personnel with information security responsibilities].</interview>
        <test>[SELECT FROM: Organizational processes for marking information media; mechanisms supporting or implementing media marking].</test>
        <objective>[a] media containing CUI is marked with applicable CUI markings; and</objective>
        <objective>[b] media containing CUI is marked with distribution limitations.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.8.5</nist>
      <name>Media Accountability</name>
      <description>Control access to media containing CUI and maintain accountability for media during transport outside of controlled areas.</description>
      <discussion>Controlled areas are areas or spaces for which organizations provide physical or procedural controls to meet the requirements established for protecting systems and information. Controls to maintain accountability for media during transport include locked containers and cryptography. Cryptographic mechanisms can provide confidentiality and integrity protections depending upon the mechanisms used. Activities associated with transport include the actual transport as well as those activities such as releasing media for transport and ensuring that media enters the appropriate transport processes. For the actual transport, authorized transport and courier personnel may include individuals external to the organization. Maintaining accountability of media during transport includes restricting transport activities to authorized personnel and tracking and obtaining explicit records of transport activities as the media moves through the transportation system to prevent and detect loss, destruction, or tampering.</discussion>
      <source>NIST SP 800-171 Rev 2 3.8.5</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: System media protection policy; procedures addressing media storage; physical and environmental protection policy and procedures; access control policy and procedures; security plan; system media; designated controlled areas; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with system media protection and storage responsibilities; personnel with information security responsibilities; system or network administrators].</interview>
        <test>[SELECT FROM: Organizational processes for storing media; mechanisms supporting or implementing media storage and media protection].</test>
        <objective>[a] access to media containing CUI is controlled; and</objective>
        <objective>[b] accountability for media containing CUI is maintained during transport outside of controlled areas.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.8.6</nist>
      <name>Portable Storage Encryption</name>
      <description>Implement cryptographic mechanisms to protect the confidentiality of CUI stored on digital media during transport unless otherwise protected by alternative physical safeguards.</description>
      <discussion>This requirement applies to portable storage devices (e.g., USB memory sticks, digital video disks, compact disks, external or removable hard disk drives). See [NIST CRYPTO].  [SP 800-111] provides guidance on storage encryption technologies for end user devices.</discussion>
      <source>NIST SP 800-171 Rev 2 3.8.6</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: System media protection policy; procedures addressing media transport; system design documentation; security plan; system configuration settings and associated documentation; system media transport records; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with system media transport responsibilities; personnel with information security responsibilities].</interview>
        <test>[SELECT FROM: Cryptographic mechanisms protecting information on digital media during transportation outside controlled areas].</test>
        <objective>[a] the confidentiality of CUI stored on digital media is protected during transport using cryptographic mechanisms or alternative physical safeguards.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.8.7</nist>
      <name>Removable Media</name>
      <description>Control the use of removable media on system components.</description>
      <discussion>In contrast to requirement 3.8.1, which restricts user access to media, this requirement 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. Organizations can employ technical and nontechnical controls (e.g., policies, procedures, and rules of behavior) to control the use of system media. Organizations may control 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.  Organizations may also limit the use of portable storage devices to only approved devices including devices provided by the organization, devices provided by other approved organizations, and devices that are not personally owned. Finally, organizations may control the use of portable storage devices based on the type of device, prohibiting the use of writeable, portable devices, and implementing this restriction by disabling or removing the capability to write to such devices.</discussion>
      <source>NIST SP 800-171 Rev 2 3.8.7</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: System media protection policy; system use policy; procedures addressing media usage restrictions; security plan; rules of behavior; system design documentation; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with system media use responsibilities; personnel with information security responsibilities; system or network administrators].</interview>
        <test>[SELECT FROM: Organizational processes for media use; mechanisms restricting or prohibiting use of system media on systems or system components].</test>
        <objective>[a] the use of removable media on system components is controlled.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.8.8</nist>
      <name>Shared Media</name>
      <description>Prohibit the use of portable storage devices when such devices have no identifiable owner.</description>
      <discussion>Requiring identifiable owners (e.g., individuals, organizations, or projects) for portable storage devices reduces the overall risk of using such technologies by allowing organizations to assign responsibility and accountability for addressing known vulnerabilities in the devices (e.g., insertion of malicious code).</discussion>
      <source>NIST SP 800-171 Rev 2 3.8.8</source>
      <score>3</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: System media protection policy; system use policy; procedures addressing media usage restrictions; security plan; rules of behavior; system design documentation; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with system media use responsibilities; personnel with information security responsibilities; system or network administrators].</interview>
        <test>[SELECT FROM: Organizational processes for media use; mechanisms prohibiting use of media on systems or system components].</test>
        <objective>[a] the use of portable storage devices is prohibited when such devices have no identifiable owner.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.8.9</nist>
      <name>Protect Backups</name>
      <description>Protect the confidentiality of backup CUI at storage locations.</description>
      <discussion>Organizations can employ cryptographic mechanisms or alternative physical controls to protect the confidentiality of backup information at designated storage locations. Backed-up information containing CUI may include system-level information and user-level information. System-level information includes system-state information, operating system software, application software, and licenses. User-level information includes information other than system-level information.</discussion>
      <source>NIST SP 800-171 Rev 2 3.8.9</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Procedures addressing system backup; security plan; backup storage location(s); system backup logs or records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with system backup responsibilities; personnel with information security responsibilities].</interview>
        <test>[SELECT FROM: Organizational processes for conducting system backups; mechanisms supporting or implementing system backups].</test>
        <objective>[a] the confidentiality of backup CUI is protected at storage locations.</objective>
      </assessment>
    </practice>
  </domain>
  <domain>
    <name>Personnel Security</name>
    <description>Screen and protect federal contract information during personnel actions</description>
    <icon>fas fa-shield-alt</icon>
    <code>PS</code>
    <practice>
      <level>L2</level>
      <nist>3.9.1</nist>
      <name>Screen Individuals</name>
      <description>Screen individuals prior to authorizing access to organizational systems containing CUI.</description>
      <discussion>Personnel security screening (vetting) activities involve the evaluation/assessment of individual’s conduct, integrity, judgment, loyalty, reliability, and stability (i.e., the trustworthiness of the individual) prior to authorizing access to organizational systems containing CUI. The screening activities reflect applicable federal laws, Executive Orders, directives, policies, regulations, and specific criteria established for the level of access required for assigned positions.</discussion>
      <source>NIST SP 800-171 Rev 2 3.9.1</source>
      <score>3</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Personnel security policy; procedures addressing personnel screening; records of screened personnel; security plan; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with personnel security responsibilities; personnel with information security responsibilities].</interview>
        <test>[SELECT FROM: Organizational processes for personnel screening].</test>
        <objective>[a] individuals are screened prior to authorizing access to organizational systems containing CUI.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.9.2</nist>
      <name>Personnel Actions</name>
      <description>Ensure that organizational systems containing CUI are protected during and after personnel actions such as terminations and transfers.</description>
      <discussion>Protecting CUI during and after personnel actions may include returning system-related property and conducting exit interviews. System-related property includes hardware authentication tokens, identification cards, system administration technical manuals, keys, and building passes. Exit interviews ensure that individuals who have been terminated understand the security constraints imposed by being former employees and that proper accountability is achieved for system-related property. Security topics of interest at exit interviews can include reminding terminated individuals of nondisclosure agreements and potential limitations on future employment. Exit interviews may not be possible for some terminated individuals, for example, in cases related to job abandonment, illnesses, and non-availability of supervisors. For termination actions, timely execution is essential for individuals terminated for cause. In certain situations, organizations consider disabling the system accounts of individuals that are being terminated prior to the individuals being notified.  This requirement applies to reassignments or transfers of individuals when the personnel action is permanent or of such extended durations as to require protection. Organizations define the CUI protections appropriate for the types of reassignments or transfers, whether permanent or extended. Protections that may be required for transfers or reassignments to other positions within organizations include returning old and issuing new keys, identification cards, and building passes; changing system access authorizations (i.e., privileges); closing system accounts and establishing new accounts; and providing for access to official records to which individuals had access at previous work locations and in previous system accounts.</discussion>
      <source>NIST SP 800-171 Rev 2 3.9.2</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Personnel security policy; procedures addressing personnel transfer and termination; records of personnel transfer and termination actions; list of system accounts; records of terminated or revoked authenticators and credentials; records of exit interviews; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with personnel security responsibilities; personnel with account management responsibilities; system or network administrators; personnel with information security responsibilities].</interview>
        <test>[SELECT FROM: Organizational processes for personnel transfer and termination; mechanisms supporting or implementing personnel transfer and termination notifications; mechanisms for disabling system access and revoking authenticators].</test>
        <objective>[a] a policy and/or process for terminating system access and any credentials coincident with personnel actions is established;</objective>
        <objective>[b] system access and credentials are terminated consistent with personnel actions such as termination or transfer; and</objective>
        <objective>[c] the system is protected during and after personnel transfer actions.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L3</level>
      <nist>3.9.2e</nist>
      <name>Adverse Information</name>
      <description>Ensure that organizational systems are protected if adverse information develops or is obtained about individuals with access to CUI.</description>
      <discussion>If adverse information develops or is obtained about an individual with access to CUI which calls into question whether the individual should have continued access to systems containing CUI, actions are taken (e.g., preclude or limit further access by the individual, audit actions taken by the individual) to protect the CUI while the adverse information is resolved.</discussion>
      <source>NIST SP 800-172 3.9.2e</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Personnel security policy; system and services acquisition policy; procedures addressing personnel screening; records of screened personnel; enterprise architecture documentation; system design documentation; system architecture and configuration documentation; security plan; list of individuals who have been identified as posing an increased level of risk; list of appropriate access authorizations required for system personnel; personnel screening criteria and associated documentation; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Organizational personnel responsible for personnel security; organizational personnel responsible for information security; organizational personnel  responsible for system and services acquisition; organizational personnel responsible for personnel screening].</interview>
        <test>[SELECT FROM: Organizational processes for personnel screening; mechanisms supporting personnel screening].</test>
        <objective>[a] Individuals with access to CUI are identified;</objective>
        <objective>[b] Adverse information about individuals with access to CUI is defined;</objective>
        <objective>[c] Organizational systems to which individuals have access are identified; and</objective>
        <objective>[d] Mechanisms are in place to protect organizational systems if adverse information develops or is obtained about individuals with access to CUI.</objective>
      </assessment>
    </practice>
  </domain>
  <domain>
    <name>Physical Protection</name>
    <description>Apply physical access constraints</description>
    <icon>fas fa-hard-hat</icon>
    <code>PE</code>
    <practice>
      <level>L1</level>
      <nist>3.10.1</nist>
      <far>b.1.viii</far>
      <name>Limit Physical Access</name>
      <description>Limit physical access to organizational information systems, equipment, and the respective operating environments to authorized individuals.</description>
      <discussion>This requirement applies to employees, individuals with permanent physical access authorization credentials, and visitors. Authorized individuals have credentials that include badges, identification cards, and smart cards. Organizations determine the strength of authorization credentials needed consistent with applicable laws, directives, policies, regulations, standards, procedures, and guidelines. This requirement applies only to areas within facilities that have not been designated as publicly accessible.  Limiting physical access to equipment may include placing equipment in locked rooms or other secured areas and allowing access to authorized individuals only; and placing equipment in locations that can be monitored by organizational personnel. Computing devices, external disk drives, networking devices, monitors, printers, copiers, scanners, facsimile machines, and audio devices are examples of equipment.</discussion>
      <source>FAR Clause 52.204-21 b.1.viii, NIST SP 800-171 Rev 2 3.10.1</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Physical and environmental protection policy; procedures addressing physical access authorizations; security plan; authorized personnel access list; authorization credentials; physical access list reviews; physical access termination records and associated documentation; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with physical access authorization responsibilities; personnel with physical access to system facility; personnel with information security responsibilities].</interview>
        <test>[SELECT FROM: Organizational processes for physical access authorizations; mechanisms supporting or implementing physical access authorizations].</test>
        <objective>[a] authorized individuals allowed physical access are identified;</objective>
        <objective>[b] physical access to organizational systems is limited to authorized individuals;</objective>
        <objective>[c] physical access to equipment is limited to authorized individuals; and</objective>
        <objective>[d] physical access to operating environments is limited to authorized individuals.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.10.2</nist>
      <name>Monitor Facility</name>
      <description>Protect and monitor the physical facility and support infrastructure for organizational systems.</description>
      <discussion>Monitoring of physical access includes publicly accessible areas within organizational facilities. This can be accomplished, for example, by the employment of guards; the use of sensor devices; or the use of video surveillance equipment such as cameras. Examples of support infrastructure include system distribution, transmission, and power lines. Security controls applied to the support infrastructure prevent accidental damage, disruption, and physical tampering. Such controls may also be necessary to prevent eavesdropping or modification of unencrypted transmissions. Physical access controls to support infrastructure include locked wiring closets; disconnected or locked spare jacks; protection of cabling by conduit or cable trays; and wiretapping sensors.</discussion>
      <source>NIST SP 800-171 Rev 2 3.10.2</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Physical and environmental protection policy; procedures addressing physical access monitoring; security plan; physical access logs or records; physical access monitoring records; physical access log reviews; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with physical access monitoring responsibilities; personnel with incident response responsibilities; personnel with information security responsibilities].</interview>
        <test>[SELECT FROM: Organizational processes for monitoring physical access; mechanisms supporting or implementing physical access monitoring; mechanisms supporting or implementing the review of physical access logs].</test>
        <objective>[a] the physical facility where organizational systems reside is protected;</objective>
        <objective>[b] the support infrastructure for organizational systems is protected;</objective>
        <objective>[c] the physical facility where organizational systems reside is monitored; and</objective>
        <objective>[d] the support infrastructure for organizational systems is monitored.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L1</level>
      <nist>3.10.3</nist>
      <far>b.1.ix</far>
      <name>Escort Visitors</name>
      <description>Escort visitors and monitor visitor activity.</description>
      <discussion>Individuals with permanent physical access authorization credentials are not considered visitors. Audit logs can be used to monitor visitor activity.</discussion>
      <source>FAR Clause 52.204-21 Partial b.1.ix, NIST SP 800-171 Rev 2 3.10.3</source>
      <score>1</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Physical and environmental protection policy; procedures addressing physical access control; security plan; physical access control logs or records; inventory records of physical access control devices; system entry and exit points; records of key and lock combination changes; storage locations for physical access control devices; physical access control devices; list of security safeguards controlling access to designated publicly accessible areas within facility; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with physical access control responsibilities; personnel with information security responsibilities].</interview>
        <test>[SELECT FROM: Organizational processes for physical access control; mechanisms supporting or implementing physical access control; physical access control devices].</test>
        <objective>[a] visitors are escorted;</objective>
        <objective>[b] visitor activity is monitored;</objective>
      </assessment>
    </practice>
    <practice>
      <level>L1</level>
      <nist>3.10.4</nist>
      <far>b.1.ix</far>
      <name>Physical Access Logs</name>
      <description>Maintain audit logs of physical access.</description>
      <discussion>Organizations have flexibility in the types of audit logs employed. Audit logs can be procedural (e.g., a written log of individuals accessing the facility), automated (e.g., capturing ID provided by a PIV card), or some combination thereof. Physical access points can include facility access points, interior access points to systems or system components requiring supplemental access controls, or both. System components (e.g., workstations, notebook computers) may be in areas designated as publicly accessible with organizations safeguarding access to such devices.</discussion>
      <source>FAR Clause 52.204-21 Partial b.1.ix, NIST SP 800-171 Rev 2 3.10.4</source>
      <score>1</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Physical and environmental protection policy; procedures addressing physical access control; security plan; physical access control logs or records; inventory records of physical access control devices; system entry and exit points; records of key and lock combination changes; storage locations for physical access control devices; physical access control devices; list of security safeguards controlling access to designated publicly accessible areas within facility; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with physical access control responsibilities; personnel with information security responsibilities].</interview>
        <test>[SELECT FROM: Organizational processes for physical access control; mechanisms supporting or implementing physical access control; physical access control devices].</test>
        <objective>[a] audit logs of physical access are maintained;</objective>
      </assessment>
    </practice>
    <practice>
      <level>L1</level>
      <nist>3.10.5</nist>
      <far>b.1.ix</far>
      <name>Manage Physical Access</name>
      <description>Control and manage physical access devices.</description>
      <discussion>Physical access devices include keys, locks, combinations, and card readers.</discussion>
      <source>FAR Clause 52.204-21 Partial b.1.ix, NIST SP 800-171 Rev 2 3.10.5</source>
      <score>1</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Physical and environmental protection policy; procedures addressing physical access control; security plan; physical access control logs or records; inventory records of physical access control devices; system entry and exit points; records of key and lock combination changes; storage locations for physical access control devices; physical access control devices; list of security safeguards controlling access to designated publicly accessible areas within facility; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with physical access control responsibilities; personnel with information security responsibilities].</interview>
        <test>[SELECT FROM: Organizational processes for physical access control; mechanisms supporting or implementing physical access control; physical access control devices].</test>
        <objective>[a] physical access devices are identified;</objective>
        <objective>[b] physical access devices are controlled; and</objective>
        <objective>[c] physical access devices are managed.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.10.6</nist>
      <name>Alternative Work Sites</name>
      <description>Enforce safeguarding measures for CUI at alternate work sites.</description>
      <discussion>Alternate work sites may include government facilities or the private residences of employees. Organizations may define different security requirements for specific alternate work sites or types of sites depending on the work-related activities conducted at those sites.  [SP 800-46] and [SP 800-114] provide guidance on enterprise and user security when teleworking.</discussion>
      <source>NIST SP 800-171 Rev 2 3.10.6</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Physical and environmental protection policy; procedures addressing alternate work sites for personnel; security plan; list of safeguards required for alternate work sites; assessments of safeguards at alternate work sites; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel approving use of alternate work sites; personnel using alternate work sites; personnel assessing controls at alternate work sites; personnel with information security responsibilities].</interview>
        <test>[SELECT FROM: Organizational processes for security at alternate work sites; mechanisms supporting alternate work sites; safeguards employed at alternate work sites; means of communications between personnel at alternate work sites and security personnel].</test>
        <objective>[a] safeguarding measures for CUI are defined for alternate work sites; and</objective>
        <objective>[b] safeguarding measures for CUI are enforced for alternate work sites.</objective>
      </assessment>
    </practice>
  </domain>
  <domain>
    <name>Risk Assessment</name>
    <description>Periodically assess and remediate risks to organizational operations</description>
    <icon>fas fa-backward</icon>
    <code>RA</code>
    <practice>
      <level>L2</level>
      <nist>3.11.1</nist>
      <name>Risk Assessments</name>
      <description>Periodically assess the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, and individuals, resulting from the operation of organizational systems and the associated processing, storage, or transmission of CUI.</description>
      <discussion>Clearly defined system boundaries are a prerequisite for effective risk assessments. Such risk assessments consider threats, vulnerabilities, likelihood, and impact to organizational operations, organizational assets, and individuals based on the operation and use of organizational systems. Risk assessments also consider risk from external parties (e.g., service providers, contractors operating systems on behalf of the organization, individuals accessing organizational systems, outsourcing entities). Risk assessments, either formal or informal, can be conducted at the organization level, the mission or business process level, or the system level, and at any phase in the system development life cycle.  [SP 800-30] provides guidance on conducting risk assessments.</discussion>
      <source>NIST SP 800-171 Rev 2 3.11.1</source>
      <score>3</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Risk assessment policy; security planning policy and procedures; procedures addressing organizational risk assessments; security plan; risk assessment; risk assessment results; risk assessment reviews; risk assessment updates; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with risk assessment responsibilities; personnel with information security responsibilities].</interview>
        <test>[SELECT FROM: Organizational processes for risk assessment; mechanisms supporting or for conducting, documenting, reviewing, disseminating, and updating the risk assessment].</test>
        <objective>[a] the frequency to assess risk to organizational operations, organizational assets, and individuals is defined; and</objective>
        <objective>[b] risk to organizational operations, organizational assets, and individuals resulting from the operation of an organizational system that processes, stores, or transmits CUI is assessed with the defined frequency.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L3</level>
      <nist>3.11.1e</nist>
      <name>Threat Hunting</name>
      <description>Employ threat intelligence, at a minimum from open or commercial sources, and any DoD-provided sources, as part of a risk assessment to guide and inform the development of organizational systems, security architectures, selection of security solutions, monitoring, threat hunting, and response and recovery activities.</description>
      <discussion>The constant evolution and increased sophistication of adversaries, especially the APT, makes it more likely that adversaries can successfully compromise or breach organizational systems. Accordingly, threat intelligence can be integrated into each step of the risk management process throughout the system development life cycle. This risk management process includes defining system security requirements, developing system and security architectures, selecting security solutions, monitoring (including threat hunting), and remediation efforts. [SP 800-30] provides guidance on risk assessments. [SP 800-39] provides guidance on the risk management process. [SP 800-160-1] provides guidance on security architectures and systems security engineering. [SP 800-150] provides guidance on cyber threat information sharing.</discussion>
      <source>NIST SP 800-172 3.11.1e</source>
      <score>1</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Information security program plan; risk assessment policy; threat awareness program documentation; procedures for the threat awareness program; security planning policy and procedures; procedures addressing organizational assessments of risk; threat hunting program documentation; procedures for the threat hunting program; risk assessment results relevant to threat awareness; threat hunting results; list or other documentation on the cross-organization, information-sharing capability; security plan; risk assessment; risk assessment results; risk assessment reviews; risk assessment updates; contingency planning policy; contingency plan; incident response policy; incident response plan; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Organizational personnel responsible for information security program planning and plan implementation; organizational personnel responsible for the threat awareness and threat hunting programs; organizational personnel responsible for risk assessments; organizational personnel responsible for the cross-organization, information-sharing capability; organizational personnel responsible for information security; organizational personnel responsible for contingency planning; organizational personnel responsible for incident response; personnel with whom threat awareness information is shared by the organization].</interview>
        <test>[SELECT FROM: Mechanisms supporting and/or implementing the threat awareness program; mechanisms supporting and/or implementing the cross-organization, information-sharing capability; mechanisms supporting and/or implementing the threat hunting program; mechanisms for conducting, documenting, reviewing, disseminating, and updating risk assessments; mechanisms supporting and/or implementing contingency plans; mechanisms supporting and/or implementing incident response plans].</test>
        <objective>[ODP1] Sources of threat intelligence are defined;</objective>
        <objective>[a] A risk assessment methodology is identified;</objective>
        <objective>[b] Threat intelligence, at a minimum from open or commercial sources, and any DoD-provided sources, are employed as part of a risk assessment to guide and inform the development of organizational systems and security architectures;</objective>
        <objective>[c] Threat intelligence, at a minimum from open or commercial sources, and any DoD-provided sources, are employed as part of a risk assessment to guide and inform the selection of security solutions;</objective>
        <objective>[d] Threat intelligence, at a minimum from open or commercial sources, and any DoD-provided sources, are employed as part of a risk assessment to guide and inform system monitoring activities;</objective>
        <objective>[e] Threat intelligence, at a minimum from open or commercial sources, and any DoD-provided sources, are employed as part of a risk assessment to guide and inform threat hunting activities; and</objective>
        <objective>[f] Threat intelligence, at a minimum from open or commercial sources, and any DoD-provided sources, are employed as part of a risk assessment to guide and inform response and recovery activities.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.11.2</nist>
      <name>Vulnerability Scan</name>
      <description>Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified.</description>
      <discussion>Organizations determine the required vulnerability scanning for all system components, ensuring that potential sources of vulnerabilities such as networked printers, scanners, and copiers are not overlooked. The vulnerabilities to be scanned are readily updated as new vulnerabilities are discovered, announced, and scanning methods developed. This process ensures that potential vulnerabilities in the system are identified and addressed as quickly as possible. Vulnerability analyses for custom software applications may require additional approaches such as static analysis, dynamic analysis, binary analysis, or a hybrid of the three approaches. Organizations can employ these analysis approaches in source code reviews and in a variety of tools (e.g., static analysis tools, web-based application scanners, binary analyzers) and in source code reviews. Vulnerability scanning includes: scanning for patch levels; scanning for functions, ports, protocols, and services that should not be accessible to users or devices; and scanning for improperly configured or incorrectly operating information flow control mechanisms.  To facilitate interoperability, organizations consider using products that are Security Content Automated Protocol (SCAP)-validated, 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 system vulnerabilities. Sources for vulnerability information include the Common Weakness Enumeration (CWE) listing and the National Vulnerability Database (NVD).  Security 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). 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 highly sensitive information. Privileged access authorization to selected system components facilitates thorough vulnerability scanning and protects the sensitive nature of such scanning. [SP 800-40] provides guidance on vulnerability management.</discussion>
      <source>NIST SP 800-171 Rev 2 3.11.2</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Risk assessment policy; procedures addressing vulnerability scanning; risk assessment; security plan; security assessment report; vulnerability scanning tools and associated configuration documentation; vulnerability scanning results; patch and vulnerability management records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with risk assessment, security assessment and vulnerability scanning responsibilities; personnel with vulnerability scan analysis and remediation responsibilities; personnel with information security responsibilities; system or network administrators].</interview>
        <test>[SELECT FROM: Organizational processes for vulnerability scanning, analysis, remediation, and information sharing; mechanisms supporting or implementing vulnerability scanning, analysis, remediation, and information sharing].</test>
        <objective>[a] the frequency to scan for vulnerabilities in organizational systems and applications is defined;</objective>
        <objective>[b] vulnerability scans are performed on organizational systems with the defined frequency;</objective>
        <objective>[c] vulnerability scans are performed on applications with the defined frequency;</objective>
        <objective>[d] vulnerability scans are performed on organizational systems when new vulnerabilities are identified; and</objective>
        <objective>[e] vulnerability scans are performed on applications when new vulnerabilities are identified.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L3</level>
      <nist>3.11.2e</nist>
      <name>Threat Hunting</name>
      <description>Conduct cyber threat hunting activities on an on-going aperiodic basis or when indications warrant, to search for indicators of compromise in organizational systems and detect, track, and disrupt threats that evade existing controls.</description>
      <discussion>Threat hunting is an active means of defense that contrasts with traditional protection measures, such as firewalls, intrusion detection and prevention systems, quarantining malicious code in sandboxes, and Security Information and Event Management (SIEM) technologies and systems. Cyber threat hunting involves proactively searching organizational systems, networks, and infrastructure for advanced threats. The objective is to track and disrupt cyber adversaries as early as possible in the attack sequence and to measurably improve the speed and accuracy of organizational responses. Indicators of compromise are forensic artifacts from intrusions that are identified on organizational systems at the host or network level and can include unusual network traffic, unusual file changes, and the presence of malicious code. Threat hunting teams use existing threat intelligence and may create new threat information, which may be shared with peer organizations, Information Sharing and Analysis Organizations (ISAO), Information Sharing and Analysis Centers (ISAC), and relevant government departments and agencies. Threat indicators, signatures, tactics, techniques, procedures, and other indicators of compromise may be available via government and non-government cooperatives, including Forum of Incident Response and Security Teams, United States Computer Emergency Response Team, Defense Industrial Base Cybersecurity Information Sharing Program, and CERT Coordination Center. [SP 800-30] provides guidance on threat and risk assessments, risk analyses, and risk modeling. [SP 800-160-2] provides guidance on systems security engineering and cyber resiliency. [SP 800-150] provides guidance on cyber threat information sharing.</discussion>
      <source>NIST SP 800-172 3.11.2e</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: System and information integrity policy; policy and procedures addressing system monitoring; threat hunting program documentation; procedures for the threat hunting program; threat hunting results; system design documentation; security plan; system monitoring tools and techniques documentation; security planning policy and procedures; system configuration settings and associated documentation; system monitoring logs or records; system audit records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Organizational personnel responsible for threat hunting program; system/network administrators; organizational personnel responsible for information security; system developers; organizational personnel installing, configuring, and/or maintaining the system; organizational personnel responsible for monitoring the system and/or network].</interview>
        <test>[SELECT FROM: Mechanisms supporting and/or implementing a threat hunting program; mechanisms supporting and/or implementing a system monitoring capability; mechanisms supporting and/or implementing the discovery, collection, distribution, and use of indicators of compromise].</test>
        <objective>[ODP4] Organizational systems to search for indicators of compromise are defined;</objective>
        <objective>[a] Indicators of compromise are identified;</objective>
        <objective>[b] Cyber threat hunting activities are conducted on an on-going aperiodic basis or when indications warrant, to search for indicators of compromise in organizational systems; and</objective>
        <objective>[c] Cyber threat hunting activities are conducted on an on-going aperiodic basis or when indications warrant, to detect, track, and disrupt threats that evade existing controls.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.11.3</nist>
      <name>Vulnerability Remediation</name>
      <description>Remediate vulnerabilities in accordance with risk assessments.</description>
      <discussion>Vulnerabilities discovered, for example, via the scanning conducted in response to 3.11.2, are remediated with consideration of the related assessment of risk. The consideration of risk influences the prioritization of remediation efforts and the level of effort to be expended in the remediation for specific vulnerabilities.</discussion>
      <source>NIST SP 800-171 Rev 2 3.11.3</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Risk assessment policy; procedures addressing vulnerability scanning; risk assessment; security plan; security assessment report; vulnerability scanning tools and associated configuration documentation; vulnerability scanning results; patch and vulnerability management records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with risk assessment, security assessment and vulnerability scanning responsibilities; personnel with vulnerability scan analysis responsibilities; personnel with vulnerability remediation responsibilities; personnel with information security responsibilities; system or network administrators].</interview>
        <test>[SELECT FROM: Organizational processes for vulnerability scanning, analysis, remediation, and information sharing; mechanisms supporting or implementing vulnerability scanning, analysis, remediation, and information sharing].</test>
        <objective>[a] vulnerabilities are identified; and</objective>
        <objective>[b] vulnerabilities are remediated in accordance with risk assessments.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L3</level>
      <nist>3.11.3e</nist>
      <name>Advanced Risk Identification</name>
      <description>Employ advanced automation and analytics capabilities in support of analysts to predict and identify risks to organizations, systems, and system components.</description>
      <discussion>A properly resourced Security Operations Center (SOC) or Computer Incident Response Team (CIRT) may be overwhelmed by the volume of information generated by the proliferation of security tools and appliances unless it employs advanced automation and analytics to analyze the data. Advanced automation and predictive analytics capabilities are typically supported by artificial intelligence concepts and machine learning. Examples include Automated Workflow Operations, Automated Threat Discovery and Response (which includes broad-based collection, context-based analysis, and adaptive response capabilities), and machine-assisted decision tools. [SP 800-30] provides guidance on risk assessments and risk analyses.</discussion>
      <source>NIST SP 800-172 3.11.3e</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: System and information integrity policy; risk assessment policy; security planning policy and procedures; procedures addressing organizational assessments of risk; procedures addressing system monitoring; enterprise architecture documentation; system design documentation; system architecture and configuration documentation; system monitoring tools and techniques documentation; system configuration settings and associated documentation; system monitoring logs or records; system audit records; security plan; risk assessment artifacts; risk assessment results; risk assessment reviews; risk assessment updates; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Organizational personnel responsible for information security; organizational personnel responsible for risk assessments; risk analysts; system developers; organizational personnel installing, configuring, and/or maintaining the system; organizational personnel responsible for monitoring; system/network administrators].</interview>
        <test>[SELECT FROM: Automated mechanisms supporting and/or implementing risk analytics capabilities; automated mechanisms supporting and/or implementing system monitoring capability; automated mechanisms supporting and/or implementing the discovery, collection, distribution, and use of indicators of compromise; automated mechanisms for conducting, documenting, reviewing, disseminating, and updating risk assessments].</test>
        <objective>[a] Advanced automation and analytics capabilities to predict and identify risks to organizations, systems, and system components are identified;</objective>
        <objective>[b] Analysts to predict and identify risks to organizations, systems, and system components are identified; and</objective>
        <objective>[c] Advanced automation and analytics capabilities are employed in support of analysts to predict and identify risks to organizations, systems, and system components.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L3</level>
      <nist>3.11.4e</nist>
      <name>Security Solution Rationale</name>
      <description>Document or reference in the system security plan the security solution selected, the rationale for the security solution, and the risk determination.</description>
      <discussion>System security plans relate security requirements to a set of security controls and solutions. The plans describe how the controls and solutions meet the security requirements. For the enhanced security requirements selected when the APT is a concern, the security plan provides traceability between threat and risk assessments and the risk-based selection of a security solution, including discussion of relevant analyses of alternatives and rationale for key security-relevant architectural and design decisions. This level of detail is important as the threat changes, requiring reassessment of the risk and the basis for previous security decisions. When incorporating external service providers into the system security plan, organizations state the type of service provided (e.g., software as a service, platform as a service), the point and type of connections (including ports and protocols), the nature and type of the information flows to and from the service provider, and the security controls implemented by the service provider. For safety critical systems, organizations document situations for which safety is the primary reason for not implementing a security solution (i.e., the solution is appropriate to address the threat but causes a safety concern). [SP 800-18] provides guidance on the development of system security plans.</discussion>
      <source>NIST SP 800-172 3.11.4e</source>
      <score>1</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: system security plan; records of security plan reviews and updates; system design documentation; security planning policy; procedures addressing security plan development; procedures addressing security plan reviews and updates; enterprise architecture documentation; enterprise security architecture documentation; system interconnection security agreements and other information exchange agreements; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Organizational personnel responsible for information security; organizational personnel responsible for developing, implementing, or approving system interconnection and information exchange agreements; personnel managing the systems to which the Interconnection Security Agreement/Information Exchange Agreement applies; system developers; organizational personnel responsible for security planning and plan implementation; organizational personnel responsible for boundary protection; system developers; system/network administrators].</interview>
        <test>[SELECT FROM: Organizational processes for security plan development, review, update, and approval].</test>
        <objective>[a] The system security plan documents or references the security solution selected;</objective>
        <objective>[b] The system security plan documents or references the rationale for the security solution; and</objective>
        <objective>[c] The system security plan documents or references the risk determination.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L3</level>
      <nist>3.11.5e</nist>
      <name>Security Solution Effectiveness</name>
      <description>Assess the effectiveness of security solutions at least annually or upon receipt of relevant cyber threat information, or in response to a relevant cyber incident, to address anticipated risk to organizational systems and the organization based on current and accumulated threat intelligence.</description>
      <discussion>Threat awareness and risk assessment of the organization are dynamic, continuous, and inform system operations, security requirements for the system, and the security solutions employed to meet those requirements. Threat intelligence (i.e., threat information that has been aggregated, transformed, analyzed, interpreted, or enriched to help provide the necessary context for decision-making) is infused into the risk assessment processes and information security operations of the organization to identify any changes required to address the dynamic threat environment. [SP 800-30] provides guidance on risk assessments, threat assessments, and risk analyses.</discussion>
      <source>NIST SP 800-172 3.11.5e</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Risk assessment policy; security planning policy and procedures; security assessment policy and procedures; security assessment plans; security assessment results; procedures addressing organizational assessments of risk; security plan; risk assessment; risk assessment results; risk assessment reviews; risk assessment updates; threat intelligence information; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Organizational personnel responsible for security assessments; organizational personnel responsible for risk assessments; organizational personnel responsible for threat analysis; organizational personnel responsible for information security].</interview>
        <test>[SELECT FROM: Mechanisms supporting, conducting, documenting, reviewing, disseminating, and updating risk assessments; mechanisms supporting and/or implementing security assessments].</test>
        <objective>[a] Security solutions are identified;</objective>
        <objective>[b] Current and accumulated threat intelligence is identified;</objective>
        <objective>[c] Anticipated risk to organizational systems and the organization based on current and accumulated threat intelligence is identified; and</objective>
        <objective>[d] The effectiveness of security solutions is assessed at least annually or upon receipt of relevant cyber threat information, or in response to a relevant cyber incident, to address anticipated risk to organizational systems and the organization based on current and accumulated threat intelligence.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L3</level>
      <nist>3.11.6e</nist>
      <name>Supply Chain Risk Response</name>
      <description>Assess, respond to, and monitor supply chain risks associated with organizational systems and system components.</description>
      <discussion>Supply chain events include disruption, use of defective components, insertion of counterfeits, theft, malicious development practices, improper delivery practices, and insertion of malicious code. These events can have a significant impact on a system and its information and, therefore, can also adversely impact organizational operations (i.e., mission, functions, image, or reputation), organizational assets, individuals, other organizations, and the Nation. The supply chain-related events may be unintentional or malicious and can occur at any point during the system life cycle. An analysis of supply chain risk can help an organization identify systems or components for which additional supply chain risk mitigations are required. [SP 800-30] provides guidance on risk assessments, threat assessments, and risk analyses. [SP 800-161] provides guidance on supply chain risk management.</discussion>
      <source>NIST SP 800-172 3.11.6e</source>
      <score>1</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Risk assessment policy; procedures addressing organizational assessments of risk; security planning policy and procedures; supply chain risk management plan; security plan; risk assessment; risk assessment results; risk assessment reviews; risk assessment updates; threat intelligence information; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Organizational personnel responsible for information security; organizational personnel responsible for risk assessments; organizational personnel responsible for supply chain risk management].</interview>
        <test>[SELECT FROM: Mechanisms supporting, conducting, documenting, reviewing, disseminating, and updating risk assessments].</test>
        <objective>[a] Supply chain risks associated with organizational systems and system components are identified;</objective>
        <objective>[b] Supply chain risks associated with organizational systems and system components are assessed;</objective>
        <objective>[c] Supply chain risks associated with organizational systems and system components are responded to; and</objective>
        <objective>[d] Supply chain risks associated with organizational systems and system components are monitored.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L3</level>
      <nist>3.11.7e</nist>
      <name>Supply Chain Risk Plan</name>
      <description>Develop a plan for managing supply chain risks associated with organizational systems and system components; update the plan at least annually, and upon receipt of relevant cyber threat information, or in response to a relevant cyber incident.</description>
      <discussion>The growing dependence on products, systems, and services from external providers, along with the nature of the relationships with those providers, present an increasing level of risk to an organization. Threat actions that may increase risk include the insertion or use of counterfeits, unauthorized production, tampering, theft, insertion of malicious software and hardware, and poor manufacturing and development practices in the supply chain. Supply chain risks can be endemic or systemic within a system element or component, a system, an organization, a sector, or the Nation. Managing supply chain risk is a multifaceted undertaking that requires a coordinated effort across an organization to build trust relationships and communicate with both internal and external stakeholders. Supply chain risk management (SCRM) activities involve identifying and assessing risks, determining appropriate mitigating actions, developing SCRM plans to document selected mitigating actions, and monitoring performance against plans. SCRM plans address requirements for developing trustworthy, secure, and resilient systems and system components, including the application of the security design principles implemented as part of life cycle-based systems security engineering processes. [SP 800-161] provides guidance on supply chain risk management.</discussion>
      <source>NIST SP 800-172 3.11.7e</source>
      <score>1</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Risk assessment policy; supply chain risk management plan; security planning policy and procedures; procedures addressing organizational assessments of risk; security plan; risk assessment; risk assessment results; risk assessment reviews; risk assessment updates; threat intelligence information; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Organizational personnel responsible for information security; organizational personnel responsible for risk assessments; organizational personnel responsible for supply chain risk management].</interview>
        <test>[SELECT FROM: Automated mechanisms supporting, conducting, documenting, reviewing, disseminating, and updating risk assessments].</test>
        <objective>[a] Supply chain risks associated with organizational systems and system components are identified;</objective>
        <objective>[b] Organizational systems and system components to include in a supply chain risk management plan are identified;</objective>
        <objective>[c] A plan for managing supply chain risks associated with organizational systems and system components is developed; and</objective>
        <objective>[d] The plan for managing supply chain risks is updated at least annually, and upon receipt of relevant cyber threat information, or in response to a relevant cyber incident.</objective>
      </assessment>
    </practice>
  </domain>
  <domain>
    <name>Security Assessment</name>
    <description>Establish, manage and maintain security plans for information technology systems</description>
    <icon>fas fa-lock</icon>
    <code>CA</code>
    <practice>
      <level>L2</level>
      <nist>3.12.1</nist>
      <name>Security Control Assessment</name>
      <description>Periodically assess the security controls in organizational systems to determine if the controls are effective in their application.</description>
      <discussion>Organizations assess security controls in organizational systems and the environments in which those systems operate as part of the system development life cycle. Security controls are the safeguards or countermeasures organizations implement to satisfy security requirements. By assessing the implemented security controls, organizations determine if the security safeguards or countermeasures are in place and operating as intended. Security control assessments ensure that information security is built into organizational systems; identify weaknesses and deficiencies early in the development process; provide essential information needed to make risk-based decisions; and ensure compliance to vulnerability mitigation procedures. Assessments are conducted on the implemented security controls as documented in system security plans.  Security assessment reports document assessment results in sufficient detail as deemed necessary by organizations, to determine the accuracy and completeness of the reports and whether the security controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting security requirements. Security assessment results are provided to the individuals or roles appropriate for the types of assessments being conducted.  Organizations ensure that security assessment results are current, relevant to the determination of security control effectiveness, and obtained with the appropriate level of assessor independence. Organizations can choose to use other types of assessment activities such as vulnerability scanning and system monitoring to maintain the security posture of systems during the system life cycle.  [SP 800-53] provides guidance on security and privacy controls for systems and organizations. [SP 800-53A] provides guidance on developing security assessment plans and conducting assessments.</discussion>
      <source>NIST SP 800-171 Rev 2 3.12.1</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Security assessment and authorization policy; procedures addressing security assessment planning; procedures addressing security assessments; security assessment plan; security plan; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with security assessment responsibilities; personnel with information security responsibilities].</interview>
        <test>[SELECT FROM: Mechanisms supporting security assessment, security assessment plan development, and security assessment reporting].</test>
        <objective>[a] the frequency of security control assessments is defined; and</objective>
        <objective>[b] security controls are assessed with the defined frequency to determine if the controls are effective in their application.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L3</level>
      <nist>3.12.1e</nist>
      <name>Penetration Testing</name>
      <description>Conduct penetration testing at least annually or when significant security changes are made to the system, leveraging automated scanning tools and ad hoc tests using subject matter experts.</description>
      <discussion>Penetration testing is a specialized type of assessment conducted on systems or individual system components to identify vulnerabilities that could be exploited by adversaries. Penetration testing goes beyond automated vulnerability scanning. It is conducted by penetration testing agents and teams with particular skills and experience that include technical expertise in network, operating system, and application-level security. Penetration testing can be used to validate vulnerabilities or determine a system’s penetration resistance to adversaries within specified constraints. Such constraints include time, resources, and skills. Organizations may also supplement penetration testing with red team exercises. Red teams attempt to duplicate the actions of adversaries in carrying out attacks against organizations and provide an in-depth analysis of security-related weaknesses or deficiencies. Organizations can use the results of vulnerability analyses to support penetration testing activities. Penetration testing can be conducted internally or externally on the hardware, software, or firmware components of a system and can exercise both physical and technical controls. A standard method for penetration testing includes pretest analysis based on full knowledge of the system, pretest identification of potential vulnerabilities based on the pretest analysis, and testing designed to determine the exploitability of vulnerabilities. All parties agree to the specified rules of engagement before the commencement of penetration testing. Organizations correlate the rules of engagement for penetration tests and red teaming exercises (if used) with the tools, techniques, and procedures that they anticipate adversaries may employ. The penetration testing or red team exercises may be organization-based or external to the organization. In either case, it is important that the team possesses the necessary skills and resources to do the job and is objective in its assessment. [SP 800-53A] provides guidance on conducting security assessments.</discussion>
      <source>NIST SP 800-172 3.12.1e</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Security assessment policy; procedures addressing penetration testing; security plan; security assessment plan; penetration test report; security assessment report; security assessment evidence; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Organizational personnel responsible for security assessments;  penetration testing team; system/network administrators; organizational personnel responsible for information security].</interview>
        <test>[SELECT FROM: Automated mechanisms supporting security assessments; automated mechanisms supporting penetration testing].</test>
        <objective>[a] Automated scanning tools are identified;</objective>
        <objective>[b] Ad hoc tests using subject matter experts are identified; and</objective>
        <objective>[c] Penetration testing is conducted at least annually or when significant security changes are made to the system, leveraging automated scanning tools and ad hoc tests using subject matter experts.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.12.2</nist>
      <name>Plan of Action</name>
      <description>Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems.</description>
      <discussion>The plan of action is a key document in the information security program. Organizations develop plans of action that describe how any unimplemented security requirements will be met and how any planned mitigations will be implemented. Organizations can document the system security plan and plan of action as separate or combined documents and in any chosen format.  Federal agencies may consider the submitted system security plans and plans of action as critical inputs to an overall risk management decision to process, store, or transmit CUI on a system hosted by a nonfederal organization and whether it is advisable to pursue an agreement or contract with the nonfederal organization. [NIST CUI] provides supplemental material for Special Publication 800-171 including templates for plans of action.</discussion>
      <source>NIST SP 800-171 Rev 2 3.12.2</source>
      <score>3</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Security assessment and authorization policy; procedures addressing plan of action; security plan; security assessment plan; security assessment report; security assessment evidence; plan of action; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with plan of action development and implementation responsibilities; personnel with information security responsibilities].</interview>
        <test>[SELECT FROM: Mechanisms for developing, implementing, and maintaining plan of action].</test>
        <objective>[a] deficiencies and vulnerabilities to be addressed by the plan of action are identified;</objective>
        <objective>[b] a plan of action is developed to correct identified deficiencies and reduce or eliminate identified vulnerabilities; and</objective>
        <objective>[c] the plan of action is implemented to correct identified deficiencies and reduce or eliminate identified vulnerabilities.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.12.3</nist>
      <name>Security Control Monitoring</name>
      <description>Monitor security controls on an ongoing basis to ensure the continued effectiveness of the controls.</description>
      <discussion>Continuous monitoring programs facilitate ongoing awareness of threats, vulnerabilities, and information security to support organizational risk management decisions. The terms continuous and ongoing imply that organizations assess and analyze security controls and information security-related risks at a frequency sufficient to support risk-based decisions. The results of continuous monitoring programs generate appropriate risk response actions by organizations. Providing access to security information on a continuing basis through reports or dashboards gives organizational officials the capability to make effective and timely risk management decisions.  Automation supports more frequent updates to hardware, software, firmware inventories, and other system information. Effectiveness is further enhanced when continuous monitoring outputs are formatted to provide information that is specific, measurable, actionable, relevant, and timely. Monitoring requirements, including the need for specific monitoring, may also be referenced in other requirements.  [SP 800-137] provides guidance on continuous monitoring.</discussion>
      <source>NIST SP 800-171 Rev 2 3.12.3</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Security planning policy; organizational procedures addressing security plan development and implementation; procedures addressing security plan reviews and updates; enterprise architecture documentation; security plan; records of security plan reviews and updates; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with security planning and plan implementation responsibilities; personnel with information security responsibilities].</interview>
        <test>[SELECT FROM: Organizational processes for security plan development, review, update, and approval; mechanisms supporting the security plan].</test>
        <objective>[a] security controls are monitored on an ongoing basis to ensure the continued effectiveness of those controls.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.12.4</nist>
      <name>System Security Plan</name>
      <description>Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems.</description>
      <discussion>System security plans relate security requirements to a set of security controls. System security plans also describe, at a high level, how the security controls meet those security requirements, but do not provide detailed, technical descriptions of the design or implementation of the controls. System security plans contain sufficient information to enable a design and implementation that is unambiguously compliant with the intent of the plans and subsequent determinations of risk if the plan is implemented as intended. Security plans need not be single documents; the plans can be a collection of various documents including documents that already exist. Effective security plans make extensive use of references to policies, procedures, and additional documents (e.g., design and implementation specifications) where more detailed information can be obtained. This reduces the documentation requirements associated with security programs and maintains security-related information in other established management/operational areas related to enterprise architecture, system development life cycle, systems engineering, and acquisition.  Federal agencies may consider the submitted system security plans and plans of action as critical inputs to an overall risk management decision to process, store, or transmit CUI on a system hosted by a nonfederal organization and whether it is advisable to pursue an agreement or contract with the nonfederal organization.  [SP 800-18] provides guidance on developing security plans. [NIST CUI] provides supplemental material for Special Publication 800-171 including templates for system security plans.</discussion>
      <source>NIST SP 800-171 Rev 2 3.12.4</source>
      <score></score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: Security planning policy; procedures addressing security plan development and implementation; procedures addressing security plan reviews and updates; enterprise architecture documentation; security plan; records of security plan reviews and updates; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with security planning and plan implementation responsibilities; personnel with information security responsibilities].</interview>
        <test>[SELECT FROM: Organizational processes for security plan development, review, update, and approval; mechanisms supporting the security plan].</test>
        <objective>[a] a system security plan is developed;</objective>
        <objective>[b] the system boundary is described and documented in the system security plan;</objective>
        <objective>[c] the system environment of operation is described and documented in the system security plan;</objective>
        <objective>[d] the security requirements identified and approved by the designated authority as non-applicable are identified;</objective>
        <objective>[e] the method of security requirement implementation is described and documented in the system security plan;</objective>
        <objective>[f] the relationship with or connection to other systems is described and documented in the system security plan;</objective>
        <objective>[g] the frequency to update the system security plan is defined; and</objective>
        <objective>[h] system security plan is updated with the defined frequency.</objective>
      </assessment>
    </practice>
  </domain>
  <domain>
    <name>System and Communications Protection</name>
    <description>Define secure system and communication boundaries and control transmission of data across boundaries</description>
    <icon>fas fa-satellite-dish</icon>
    <code>SC</code>
    <practice>
      <level>L1</level>
      <nist>3.13.1</nist>
      <far>b.1.xi</far>
      <name>Boundary Protection</name>
      <description>Monitor, control, and protect organizational communications (i.e., information transmitted or received by organizational information systems) at the external boundaries and key internal boundaries of the information systems.</description>
      <discussion>Communications can be monitored, controlled, and protected at boundary components and by restricting or prohibiting interfaces in organizational systems. Boundary components include gateways, routers, firewalls, guards, network-based malicious code analysis and virtualization systems, or encrypted tunnels implemented within a system security architecture (e.g., routers protecting firewalls or application gateways residing on protected subnetworks). Restricting or prohibiting interfaces in organizational systems includes restricting external web communications traffic to designated web servers within managed interfaces and prohibiting external traffic that appears to be spoofing internal addresses.  Organizations consider the shared nature of commercial telecommunications services in the implementation of security requirements associated with the use of such services. Commercial telecommunications services are commonly based on network components and consolidated management systems shared by all attached commercial customers and may also include third party-provided access lines and other service elements. Such transmission services may represent sources of increased risk despite contract security provisions. [SP 800-41] provides guidance on firewalls and firewall policy. [SP 800-125B] provides guidance on security for virtualization technologies. [28] There is no prescribed format or specified level of detail for system security plans. However, organizations ensure that the required information in 3.12.4 is conveyed in those plans.</discussion>
      <source>FAR Clause 52.204-21 b.1.x, NIST SP 800-171 Rev 2 3.13.1</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: System and communications protection policy; procedures addressing boundary protection; security plan; list of key internal boundaries of the system; system design documentation; boundary protection hardware and software; enterprise security architecture documentation; system audit logs and records; system configuration settings and associated documentation; other relevant documents or records].</examine>
        <interview>[SELECT FROM: System or network administrators; personnel with information security responsibilities; system developer; personnel with boundary protection responsibilities].</interview>
        <test>[SELECT FROM: Mechanisms implementing boundary protection capability].</test>
        <objective>[a] the external system boundary is defined;</objective>
        <objective>[b] key internal system boundaries are defined;</objective>
        <objective>[c] communications are monitored at the external system boundary;</objective>
        <objective>[d] communications are monitored at key internal boundaries;</objective>
        <objective>[e] communications are controlled at the external system boundary;</objective>
        <objective>[f] communications are controlled at key internal boundaries;</objective>
        <objective>[g] communications are protected at the external system boundary; and</objective>
        <objective>[h] communications are protected at key internal boundaries.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.13.2</nist>
      <name>Security Engineering</name>
      <description>Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems.</description>
      <discussion>Organizations apply systems security engineering principles to new development systems or systems undergoing major upgrades. For legacy systems, organizations apply systems security engineering principles to system upgrades and modifications to the extent feasible, given the current state of hardware, software, and firmware components within those systems. The application of systems security engineering concepts and principles helps to develop trustworthy, secure, and resilient systems and system components and reduce the susceptibility of organizations to disruptions, hazards, and threats. Examples of these concepts and principles include developing layered protections; establishing security policies, architecture, and controls as the foundation for design; incorporating security requirements into the system development life cycle; delineating physical and logical security boundaries; ensuring that developers are trained on how to build secure software; and performing threat modeling to identify use cases, threat agents, attack vectors and patterns, design patterns, and compensating controls needed to mitigate risk. Organizations that apply security engineering concepts and principles can facilitate the development of trustworthy, secure systems, system components, and system services; reduce risk to acceptable levels; and make informed risk-management decisions.  [SP 800-160-1] provides guidance on systems security engineering.</discussion>
      <source>NIST SP 800-171 Rev 2 3.13.2</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Security planning policy; procedures addressing security plan development and implementation; procedures addressing security plan reviews and updates; enterprise architecture documentation; security plan; records of security plan reviews and updates; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with security planning and plan implementation responsibilities; personnel with information security responsibilities].</interview>
        <test>[SELECT FROM: Organizational processes for security plan development, review, update, and approval; mechanisms supporting the system security plan].</test>
        <objective>[a] architectural designs that promote effective information security are identified;</objective>
        <objective>[b] software development techniques that promote effective information security are identified;</objective>
        <objective>[c] systems engineering principles that promote effective information security are identified;</objective>
        <objective>[d] identified architectural designs that promote effective information security are employed;</objective>
        <objective>[e] identified software development techniques that promote effective information security are employed; and</objective>
        <objective>[f] identified systems engineering principles that promote effective information security are employed.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.13.3</nist>
      <name>Role Separation</name>
      <description>Separate user functionality from system management functionality.</description>
      <discussion>System management functionality includes functions necessary to administer databases, network components, workstations, or servers, and typically requires privileged user access. The separation of user functionality from system management functionality is physical or logical. Organizations can implement separation of system management functionality from user functionality by using different computers, different central processing units, different instances of operating systems, or different network addresses; virtualization techniques; or combinations of these or other methods, as appropriate. This type of separation includes web administrative interfaces that use separate authentication methods for users of any other system resources. Separation of system and user functionality may include isolating administrative interfaces on different domains and with additional access controls.</discussion>
      <source>NIST SP 800-171 Rev 2 3.13.3</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: System and communications protection policy; procedures addressing application partitioning; system design documentation; system configuration settings and associated documentation; security plan; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: System or network administrators; personnel with information security responsibilities; system developer].</interview>
        <test>[SELECT FROM: Separation of user functionality from system management functionality].</test>
        <objective>[a] user functionality is identified;</objective>
        <objective>[b] system management functionality is identified; and</objective>
        <objective>[c] user functionality is separated from system management functionality.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.13.4</nist>
      <name>Shared Resource Control</name>
      <description>Prevent unauthorized and unintended information transfer via shared system resources.</description>
      <discussion>The control of information in shared system resources (e.g., registers, cache memory, main memory, hard disks) is also commonly referred to as object reuse and residual information protection. This requirement prevents 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 any 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. This requirement also applies to encrypted representations of information. This requirement does not address information remanence, which refers to residual representation of data that has been nominally deleted; covert channels (including storage or timing channels) where shared resources are manipulated to violate information flow restrictions; or components within systems for which there are only single users or roles.</discussion>
      <source>NIST SP 800-171 Rev 2 3.13.4</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: System and communications protection policy; procedures addressing application partitioning; security plan; system design documentation; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: System or network administrators; personnel with information security responsibilities; system developer].</interview>
        <test>[SELECT FROM: Separation of user functionality from system management functionality].</test>
        <objective>[a] unauthorized and unintended information transfer via shared system resources is prevented.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L3</level>
      <nist>3.13.4e</nist>
      <name>Isolation</name>
      <description>Employ physical isolation techniques or logical isolation techniques or both in organizational systems and system components.</description>
      <discussion>A mix of physical and logical isolation techniques (described below) implemented as part of the system architecture can limit the unauthorized flow of CUI, reduce the system attack surface, constrain the number of system components that must be secure, and impede the movement of an adversary. When implemented with a set of managed interfaces, physical and logical isolation techniques for organizational systems and components can isolate CUI into separate security domains where additional protections can be implemented. Any communications across the managed interfaces (i.e., across security domains), including for management or administrative purposes, constitutes remote access even if the communications remain within the organization. Separating system components with boundary protection mechanisms allows for the increased protection of individual components and more effective control of information flows between those components. This enhanced protection limits the potential harm from and susceptibility to hostile cyber-attacks and errors. The degree of isolation can vary depending on the boundary protection mechanisms selected. Boundary protection mechanisms include routers, gateways, and firewalls separating system components into physically separate networks or subnetworks; virtualization and micro-virtualization techniques; encrypting information flows among system components using distinct encryption keys; cross-domain devices separating subnetworks; and complete physical separation (i.e., air gaps). System architectures include logical isolation, partial physical and logical isolation, or complete physical isolation between subsystems and at system boundaries between resources that store, process, transmit, or protect CUI and other resources. Examples include:•	Logical isolation: Data tagging, digital rights management (DRM), and data loss prevention (DLP) that tags, monitors, and restricts the flow of CUI; virtual machines or containers that separate CUI and other information on hosts; and virtual local area networks (VLAN) that keep CUI and other information separate on networks.•	Partial physical and logical isolation: Physically or cryptographically isolated networks, dedicated hardware in data centers, and secure clients that (a) may not directly access resources outside of the domain (i.e., all applications with cross-enclave connectivity execute as remote virtual applications hosted in a demilitarized zone [DMZ] or internal and protected enclave), (b) access via remote virtualized applications or virtual desktop with no file transfer capability other than with dual authorization, or (c) employ dedicated client hardware (e.g., a zero or thin client) or hardware approved for multi-level secure (MLS) usage. Complete physical isolation: Dedicated (not shared) client and server hardware; physically isolated, stand-alone enclaves for clients and servers; and (a) logically separate network traffic (e.g., using a VLAN) with end-to-end encryption using Public Key Infrastructure (PKI)-based cryptography or (b) physical isolation from other networks. Isolation techniques are selected based on a risk management perspective that balances the threat, the information being protected, and the cost of the options for protection. Architectural and design decisions are guided and informed by the security requirements and selected solutions. Organizations consider the trustworthiness of the isolation techniques employed (e.g., the logical isolation relies on information technology that could be considered a high value target because of the function being performed), introducing its own set of vulnerabilities. [SP 800-160-1] provides guidance on developing trustworthy, secure, and cyber resilient systems using systems security engineering practices and security design concepts.</discussion>
      <source>NIST SP 800-172 3.13.4e</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: System and communications protection policy; procedures addressing boundary protection; system design documentation; procedures addressing the use of thin nodes; list of key internal boundaries of the system; security plan; boundary protection hardware and software; system configuration settings and associated documentation; enterprise architecture documentation; system architecture; security architecture documentation; system audit records; system component inventory; list of security tools and support components to be isolated from other system components; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Organizational personnel responsible for information security; system/network administrators; system developers; organizational personnel responsible for boundary protection].</interview>
        <test>[SELECT FROM: Mechanisms implementing the boundary protection capability; mechanisms implementing physical isolation techniques; mechanisms supporting and/or implementing the isolation of information security tools, mechanisms, and support components; mechanisms supporting and/or implementing the capability to separate system components supporting organizational missions and business functions; mechanisms implementing logical isolation techniques; mechanisms supporting or implementing separate network addresses/different subnets; mechanisms supporting and/or implementing thin nodes].</test>
        <objective>[ODP1] One or more of the following is/are selected: physical isolation techniques; logical isolation techniques;</objective>
        <objective>[ODP2] Physical isolation techniques are defined (if selected);</objective>
        <objective>[ODP3] Logical isolation techniques are defined (if selected);</objective>
        <objective>[a] Physical isolation techniques or logical isolation techniques or both are employed in organizational systems and system components.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L1</level>
      <nist>3.13.5</nist>
      <far>b.1.xi</far>
      <name>Public-Access System Separation</name>
      <description>Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.</description>
      <discussion>Subnetworks that are physically or logically separated from internal networks are referred to as demilitarized zones (DMZs). DMZs are typically implemented with boundary control devices and techniques that include routers, gateways, firewalls, virtualization, or cloud-based technologies.  [SP 800-41] provides guidance on firewalls and firewall policy. [SP 800-125B] provides guidance on security for virtualization technologies</discussion>
      <source>FAR Clause 52.204-21 b.1.xi, NIST SP 800-171 Rev 2 3.13.5</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: System and communications protection policy; procedures addressing boundary protection; security plan; list of key internal boundaries of the system; system design documentation; boundary protection hardware and software; system configuration settings and associated documentation; enterprise security architecture documentation; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: System or network administrators; personnel with information security responsibilities; system developer; personnel with boundary protection responsibilities].</interview>
        <test>[SELECT FROM: Mechanisms implementing boundary protection capability].</test>
        <objective>[a] publicly accessible system components are identified; and</objective>
        <objective>[b] subnetworks for publicly accessible system components are physically or logically separated from internal networks.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.13.6</nist>
      <name>Network Communication by Exception</name>
      <description>Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception).</description>
      <discussion>This requirement applies to inbound and outbound network communications traffic at the system boundary and at identified points within the system. A deny-all, permit-by-exception network communications traffic policy ensures that only those connections which are essential and approved are allowed.</discussion>
      <source>NIST SP 800-171 Rev 2 3.13.6</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: System and communications protection policy; procedures addressing boundary protection; security plan; system design documentation; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: System or network administrators; personnel with information security responsibilities; system developer; personnel with boundary protection responsibilities].</interview>
        <test>[SELECT FROM: Mechanisms implementing traffic management at managed interfaces].</test>
        <objective>[a] network communications traffic is denied by default; and</objective>
        <objective>[b] network communications traffic is allowed by exception.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.13.7</nist>
      <name>Split Tunneling</name>
      <description>Prevent remote devices from simultaneously establishing non-remote connections with organizational systems and communicating via some other connection to resources in external networks (i.e., split tunneling).</description>
      <discussion>Split tunneling might be desirable by remote users to communicate with local system resources such as printers or file servers. However, split tunneling allows unauthorized external connections, making the system more vulnerable to attack and to exfiltration of organizational information. This requirement is implemented in remote devices (e.g., notebook computers, smart phones, and tablets) through configuration settings to disable split tunneling in those devices, and by preventing configuration settings from being readily configurable by users. This requirement is implemented in the system 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.</discussion>
      <source>NIST SP 800-171 Rev 2 3.13.7</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: System and communications protection policy; procedures addressing boundary protection; security plan; system design documentation; system hardware and software; system architecture; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: System or network administrators; personnel with information security responsibilities; system developer; personnel with boundary protection responsibilities].</interview>
        <test>[SELECT FROM: Mechanisms implementing boundary protection capability; mechanisms supporting or restricting non-remote connections].</test>
        <objective>[a] remote devices are prevented from simultaneously establishing non-remote connections with the system and communicating via some other connection to resources in external networks (i.e., split tunneling).</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.13.8</nist>
      <name>Data in Transit</name>
      <description>Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards.</description>
      <discussion>This requirement applies to internal and external networks and any system components that can transmit information including servers, notebook computers, desktop computers, mobile devices, printers, copiers, scanners, and facsimile machines. Communication paths outside the physical protection of controlled boundaries are susceptible to both interception and modification. Organizations relying on commercial providers offering transmission services as commodity services rather than as fully dedicated services (i.e., services which can be highly specialized to individual customer needs), may find it difficult to obtain the necessary assurances regarding the implementation of the controls for transmission confidentiality. In such situations, organizations determine what types of confidentiality services are available in commercial telecommunication service packages. If it is infeasible or impractical to obtain the necessary safeguards and assurances of the effectiveness of the safeguards through appropriate contracting vehicles, organizations implement compensating safeguards or explicitly accept the additional risk. An example of an alternative physical safeguard is a protected distribution system (PDS) where the distribution medium is protected against electronic or physical intercept, thereby ensuring the confidentiality of the information being transmitted. See [NIST CRYPTO].</discussion>
      <source>NIST SP 800-171 Rev 2 3.13.8</source>
      <score>3</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: System and communications protection policy; procedures addressing transmission confidentiality and integrity; security plan; system design documentation; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: System or network administrators; personnel with information security responsibilities; system developer].</interview>
        <test>[SELECT FROM: Cryptographic mechanisms or mechanisms supporting or implementing transmission confidentiality; organizational processes for defining and implementing alternative physical safeguards].</test>
        <objective>[a] cryptographic mechanisms intended to prevent unauthorized disclosure of CUI are identified;</objective>
        <objective>[b] alternative physical safeguards intended to prevent unauthorized disclosure of CUI are identified; and</objective>
        <objective>[c] either cryptographic mechanisms or alternative physical safeguards are implemented to prevent unauthorized disclosure of CUI during transmission.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.13.9</nist>
      <name>Connections Termination</name>
      <description>Terminate network connections associated with communications sessions at the end of the sessions or after a defined period of inactivity.</description>
      <discussion>This requirement applies to internal and external networks. Terminating network connections associated with communications sessions include de-allocating associated TCP/IP address or port pairs at the operating system level, or de-allocating networking assignments at the application level if multiple application sessions are using a single, operating system-level network connection. Time periods of user inactivity may be established by organizations and include time periods by type of network access or for specific network accesses</discussion>
      <source>NIST SP 800-171 Rev 2 3.13.9</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: System and communications protection policy; procedures addressing network disconnect; system design documentation; security plan; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: System or network administrators; personnel with information security responsibilities; system developer].</interview>
        <test>[SELECT FROM: Mechanisms supporting or implementing network disconnect capability].</test>
        <objective>[a] a period of inactivity to terminate network connections associated with communications sessions is defined;</objective>
        <objective>[b] network connections associated with communications sessions are terminated at the end of the sessions; and</objective>
        <objective>[c] network connections associated with communications sessions are terminated after the defined period of inactivity.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.13.10</nist>
      <name>Key Management</name>
      <description>Establish and manage cryptographic keys for cryptography employed in organizational systems.</description>
      <discussion>Cryptographic key management and establishment can be performed using manual procedures or mechanisms supported by manual procedures. Organizations define key management requirements in accordance with applicable federal laws, Executive Orders, policies, directives, regulations, and standards specifying appropriate options, levels, and parameters.  [SP 800-56A] and [SP 800-57-1] provide guidance on cryptographic key management and key  establishment.</discussion>
      <source>NIST SP 800-171 Rev 2 3.13.10</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: System and communications protection policy; procedures addressing cryptographic key establishment and management; security plan; system design documentation; cryptographic mechanisms; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: System or network administrators; personnel with information security responsibilities; personnel with responsibilities for cryptographic key establishment and management].</interview>
        <test>[SELECT FROM: Mechanisms supporting or implementing cryptographic key establishment and management].</test>
        <objective>[a] cryptographic keys are established whenever cryptography is employed; and</objective>
        <objective>[b] cryptographic keys are managed whenever cryptography is employed.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.13.11</nist>
      <name>CUI Encryption</name>
      <description>Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.</description>
      <discussion>Cryptography can be employed to support many security solutions including the protection of controlled unclassified information, the provision of digital signatures, and the enforcement of information separation when authorized individuals have the necessary clearances for such information but lack the necessary formal access approvals. Cryptography can also be used to support random number generation and hash generation. Cryptographic standards include FIPS-validated cryptography and/or NSA-approved cryptography. See [NIST CRYPTO]; [NIST CAVP]; and [NIST CMVP].</discussion>
      <source>NIST SP 800-171 Rev 2 3.13.11</source>
      <score>5</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: System and communications protection policy; procedures addressing cryptographic protection; security plan; system design documentation; system configuration settings and associated documentation; cryptographic module validation certificates; list of FIPS-validated cryptographic modules; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: System or network administrators; personnel with information security responsibilities; system developer; personnel with responsibilities for cryptographic protection].</interview>
        <test>[SELECT FROM: Mechanisms supporting or implementing cryptographic protection].</test>
        <objective>[a] FIPS-validated cryptography is employed to protect the confidentiality of CUI.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.13.12</nist>
      <name>Collaborative Device Control</name>
      <description>Prohibit remote activation of collaborative computing devices and provide indication of devices in use to users present at the device.</description>
      <discussion>Collaborative computing devices include networked white boards, cameras, and microphones. Indication of use includes signals to users when collaborative computing devices are activated. Dedicated video conferencing systems, which rely on one of the participants calling or connecting to the other party to activate the video conference, are excluded. [29] Dedicated video conferencing systems, which rely on one of the participants calling or connecting to the other party to activate the video conference, are excluded.</discussion>
      <source>NIST SP 800-171 Rev 2 3.13.12</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: System and communications protection policy; procedures addressing collaborative computing; access control policy and procedures; security plan; system design documentation; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: System or network administrators; personnel with information security responsibilities; system developer; personnel with responsibilities for managing collaborative computing devices].</interview>
        <test>[SELECT FROM: Mechanisms supporting or implementing management of remote activation of collaborative computing devices; mechanisms providing an indication of use of collaborative computing devices].</test>
        <objective>[a] collaborative computing devices are identified;</objective>
        <objective>[b] collaborative computing devices provide indication to users of devices in use; and</objective>
        <objective>[c] remote activation of collaborative computing devices is prohibited.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.13.13</nist>
      <name>Mobile Code</name>
      <description>Control and monitor the use of mobile code.</description>
      <discussion>Mobile code technologies include Java, JavaScript, ActiveX, Postscript, PDF, Flash animations, and VBScript. Decisions regarding the use of mobile code in organizational systems are based on the potential for the code to cause damage to the systems if used maliciously. Usage restrictions and implementation guidance apply to the selection and use of mobile code installed on servers and mobile code downloaded and executed on individual workstations, notebook computers, and devices (e.g., smart phones). Mobile code policy and procedures address controlling or preventing the development, acquisition, or introduction of unacceptable mobile code in systems, including requiring mobile code to be digitally signed by a trusted source.  [SP 800-28] provides guidance on mobile code.</discussion>
      <source>NIST SP 800-171 Rev 2 3.13.13</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: System and communications protection policy; procedures addressing mobile code; mobile code usage restrictions, mobile code implementation policy and procedures; security plan; list of acceptable mobile code and mobile code technologies; list of unacceptable mobile code and mobile technologies; authorization records; system monitoring records; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: System or network administrators; personnel with information security responsibilities; personnel with responsibilities for managing mobile code].</interview>
        <test>[SELECT FROM: Organizational process for controlling, authorizing, monitoring, and restricting mobile code; mechanisms supporting or implementing the management of mobile code; mechanisms supporting or implementing the monitoring of mobile code].</test>
        <objective>[a] use of mobile code is controlled; and</objective>
        <objective>[b] use of mobile code is monitored.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.13.14</nist>
      <name>Voice over Internet Protocol</name>
      <description>Control and monitor the use of Voice over Internet Protocol (VoIP) technologies.</description>
      <discussion>VoIP has different requirements, features, functionality, availability, and service limitations when compared with the Plain Old Telephone Service (POTS) (i.e., the standard telephone service). In contrast, other telephone services are based on high-speed, digital communications lines, such as Integrated Services Digital Network (ISDN) and Fiber Distributed Data Interface (FDDI). The main distinctions between POTS and non-POTS services are speed and bandwidth. To address the threats associated with VoIP, usage restrictions and implementation guidelines are based on the potential for the VoIP technology to cause damage to the system if it is used maliciously. Threats to VoIP are similar to those inherent with any Internet-based application.  [SP 800-58] provides guidance on Voice Over IP Systems.</discussion>
      <source>NIST SP 800-171 Rev 2 3.13.14</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: System and communications protection policy; procedures addressing VoIP; VoIP usage restrictions; VoIP implementation guidance; security plan; system design documentation; system configuration settings and associated documentation; system monitoring records; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: System or network administrators; personnel with information security responsibilities; personnel with responsibilities for managing VoIP].</interview>
        <test>[SELECT FROM: Organizational process for authorizing, monitoring, and controlling VoIP; mechanisms supporting or implementing authorizing, monitoring, and controlling VoIP].</test>
        <objective>[a] use of Voice over Internet Protocol (VoIP) technologies is controlled; and</objective>
        <objective>[b] use of Voice over Internet Protocol (VoIP) technologies is monitored.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.13.15</nist>
      <name>Communications Authenticity</name>
      <description>Protect the authenticity of communications sessions.</description>
      <discussion>Authenticity protection includes protecting against man-in-the-middle attacks, session hijacking, and the insertion of false information into communications sessions. This requirement addresses communications protection at the session versus packet level (e.g., sessions in service-oriented architectures providing web-based services) and establishes grounds for confidence at both ends of communications sessions in ongoing identities of other parties and in the validity of information transmitted.  [SP 800-77], [SP 800-95], and [SP 800-113] provide guidance on secure communications sessions.</discussion>
      <source>NIST SP 800-171 Rev 2 3.13.15</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: System and communications protection policy; procedures addressing session authenticity; security plan; system design documentation; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: System or network administrators; personnel with information security responsibilities].</interview>
        <test>[SELECT FROM: Mechanisms supporting or implementing session authenticity].</test>
        <objective>[a] the authenticity of communications sessions is protected.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.13.16</nist>
      <name>Data at Rest</name>
      <description>Protect the confidentiality of CUI at rest.</description>
      <discussion>Information at rest refers to the state of information when it is not in process or in transit and is located on storage devices as specific components of systems. The focus of protection at rest is not on the type of storage device or the frequency of access but rather the state of the information. Organizations can use different mechanisms to achieve confidentiality protections, including the use of cryptographic mechanisms and file share scanning. Organizations may also use other controls including secure off-line storage in lieu of online storage when adequate protection of information at rest cannot otherwise be achieved or continuous monitoring to identify malicious code at rest. See [NIST CRYPTO].</discussion>
      <source>NIST SP 800-171 Rev 2 3.13.16</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: System and communications protection policy; procedures addressing protection of information at rest; security plan; system design documentation; list of information at rest requiring confidentiality protections; system configuration settings and associated documentation; cryptographic mechanisms and associated configuration documentation; other relevant documents or records].</examine>
        <interview>[SELECT FROM: System or network administrators; personnel with information security responsibilities; system developer].</interview>
        <test>[SELECT FROM: Mechanisms supporting or implementing confidentiality protections for information at rest].</test>
        <objective>[a] the confidentiality of CUI at rest is protected.</objective>
      </assessment>
    </practice>
  </domain>
  <domain>
    <name>System and Informational Integrity</name>
    <description>Identify and mitigate vulnerabilities and risks of networks and systems</description>
    <icon>fas fa-certificate</icon>
    <code>SI</code>
    <practice>
      <level>L1</level>
      <nist>3.14.1</nist>
      <far>b.1.xii</far>
      <name>Flaw Remediation</name>
      <description>Identify, report, and correct information and information system flaws in a timely manner.</description>
      <discussion>Organizations identify systems that are affected by announced software and firmware flaws including potential vulnerabilities resulting from those flaws and report this information to designated personnel with information security responsibilities. Security-relevant updates include patches, service packs, hot fixes, and anti-virus signatures. Organizations address flaws discovered during security assessments, continuous monitoring, incident response activities, and system error handling. Organizations can take advantage of available resources such as the Common Weakness Enumeration (CWE) database or Common Vulnerabilities and Exposures (CVE) database in remediating flaws discovered in organizational systems.  Organization-defined time periods for updating security-relevant software and firmware may vary based on a variety of factors including the criticality of the update (i.e., severity of the vulnerability related to the discovered flaw). Some types of flaw remediation may require more testing than other types of remediation.  [SP 800-40] provides guidance on patch management technologies.</discussion>
      <source>FAR Clause 52.204-21 b.1.xii, NIST SP 800-171 Rev 2 3.14.1</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: System and information integrity policy; procedures addressing flaw remediation; procedures addressing configuration management; security plan; list of flaws and vulnerabilities potentially affecting the system; list of recent security flaw remediation actions performed on the system (e.g., list of installed patches, service packs, hot fixes, and other software updates to correct system flaws); test results from the installation of software and firmware updates to correct system flaws; installation/change control records for security-relevant software and firmware updates; other relevant documents or records].</examine>
        <interview>[SELECT FROM: System or network administrators; personnel with information security responsibilities; personnel installing, configuring, and maintaining the system; personnel with responsibility for flaw remediation; personnel with configuration management responsibility].</interview>
        <test>[SELECT FROM: Organizational processes for identifying, reporting, and correcting system flaws; organizational process for installing software and firmware updates; mechanisms supporting or implementing reporting, and correcting system flaws; mechanisms supporting or implementing testing software and firmware updates].</test>
        <objective>[a] the time within which to identify system flaws is specified;</objective>
        <objective>[b] system flaws are identified within the specified time frame;</objective>
        <objective>[c] the time within which to report system flaws is specified;</objective>
        <objective>[d] system flaws are reported within the specified time frame;</objective>
        <objective>[e] the time within which to correct system flaws is specified; and</objective>
        <objective>[f] system flaws are corrected within the specified time frame.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L3</level>
      <nist>3.14.1e</nist>
      <name>Integrity Verification</name>
      <description>Verify the integrity of security critical and essential software using root of trust mechanisms or cryptographic signatures.</description>
      <discussion>Verifying the integrity of the organization’s security-critical or essential software is an important capability since corrupted software is the primary attack vector used by adversaries to undermine or disrupt the proper functioning of organizational systems. There are many ways to verify software integrity throughout the system development life cycle. Root of trust mechanisms (e.g., secure boot, trusted platform modules, Unified Extensible Firmware Interface [UEFI]), verify that only trusted code is executed during boot processes. This capability helps system components protect the integrity of boot firmware in organizational systems by verifying the integrity and authenticity of updates to the firmware prior to applying changes to the system component and preventing unauthorized processes from modifying the boot firmware. The employment of cryptographic signatures ensures the integrity and authenticity of critical and essential software that stores, processes, or transmits, CUI. Cryptographic signatures include digital signatures and the computation and application of signed hashes using asymmetric cryptography, protecting the confidentiality of the key used to generate the hash, and using the public key to verify the hash information. Hardware roots of trust are considered to be more secure. This requirement supports 3.4.1e and 3.4.3.e.[FIPS 140-3] provides security requirements for cryptographic modules. [FIPS 180-4] and [FIPS 202] provide secure hash standards. [FIPS 186-4] provides a digital signature standard. [SP 800-147] provides BIOS protection guidance. [NIST TRUST] provides guidance on the roots of trust project.</discussion>
      <source>NIST SP 800-172 3.14.1e</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: System and information integrity policy; procedures addressing software, firmware, and information integrity; system design documentation; security plan; system configuration settings and associated documentation; system component inventory; integrity verification tools and associated documentation; records of integrity verification scans; system audit records; cryptographic mechanisms and associated documentation; records of detected unauthorized changes to software, firmware, and information; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Organizational personnel responsible for information security; organizational personnel responsible for software, firmware, and/or information integrity; system developers; system/network administrators].</interview>
        <test>[SELECT FROM: Software, firmware, and information integrity verification tools; mechanisms supporting and/or implementing integrity verification of the boot process; mechanisms supporting and/or implementing protection of the integrity of boot firmware; cryptographic mechanisms implementing software, firmware, and information integrity; safeguards implementing protection of the integrity of boot firmware].</test>
        <objective>[ODP1] Security critical or essential software is defined;</objective>
        <objective>[a] Root of trust mechanisms or cryptographic signatures are identified; and</objective>
        <objective>[b] The integrity of security critical and essential software is verified using root of trust mechanisms or cryptographic signatures.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L1</level>
      <nist>3.14.2</nist>
      <far>b.1.xiii</far>
      <name>Malicious Code Protection</name>
      <description>Provide protection from malicious code at appropriate locations within organizational information systems.</description>
      <discussion>Designated locations include system entry and exit points which may 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 be encoded in various formats (e.g., UUENCODE, Unicode), 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 web accesses, electronic mail, electronic mail attachments, and portable storage devices. Malicious code insertions occur through the exploitation of system vulnerabilities.  Malicious code protection mechanisms include anti-virus signature definitions and reputation-based technologies. A variety of technologies and methods exist to limit or eliminate the effects of malicious code. Pervasive configuration management and comprehensive software integrity controls may be effective in preventing execution of unauthorized code. In addition to commercial off-the-shelf software, malicious code may also be present in custom-built software. This could include logic bombs, back doors, and other types of cyber-attacks that could affect organizational missions/business functions. Traditional malicious code protection mechanisms cannot always detect such code. In these situations, organizations rely instead on other safeguards including secure coding practices, configuration management and control, trusted procurement processes, and monitoring practices to help ensure that software does not perform functions other than the functions intended. [SP 800-83] provides guidance on malware incident prevention.</discussion>
      <source>FAR Clause 52.204-21 b.1.xiii, NIST SP 800-171 Rev 2 3.14.2</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: System and information integrity policy; configuration management policy and procedures; procedures addressing malicious code protection; records of malicious code protection updates; malicious code protection mechanisms; security plan; system design documentation; system configuration settings and associated documentation; record of actions initiated by malicious code protection mechanisms in response to malicious code detection; scan results from malicious code protection mechanisms; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: System or network administrators; personnel with information security responsibilities; personnel installing, configuring, and maintaining the system; personnel with responsibility for malicious code protection; personnel with configuration management responsibility].</interview>
        <test>[SELECT FROM: Organizational processes for employing, updating, and configuring malicious code protection mechanisms; organizational process for addressing false positives and resulting potential impact; mechanisms supporting or implementing employing, updating, and configuring malicious code protection mechanisms; mechanisms supporting or implementing malicious code scanning and subsequent actions].</test>
        <objective>[a] designated locations for malicious code protection are identified; and</objective>
        <objective>[b] protection from malicious code at designated locations is provided.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.14.3</nist>
      <name>Security Alerts &amp; Advisories</name>
      <description>Monitor system security alerts and advisories and take action in response.</description>
      <discussion>There are many publicly available sources of system security alerts and advisories. For example, the Department of Homeland Security’s Cybersecurity and Infrastructure Security Agency (CISA) generates security alerts and advisories to maintain situational awareness across the federal government and in nonfederal organizations. Software vendors, subscription services, and industry information sharing and analysis centers (ISACs) may also provide security alerts and advisories. Examples of response actions include notifying relevant external organizations, for example, external mission/business partners, supply chain partners, external service providers, and peer or supporting organizations.  [SP 800-161] provides guidance on supply chain risk management.</discussion>
      <source>NIST SP 800-171 Rev 2 3.14.3</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: System and information integrity policy; procedures addressing security alerts, advisories, and directives; security plan; records of security alerts and advisories; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Personnel with security alert and advisory responsibilities; personnel implementing, operating, maintaining, and using the system; personnel, organizational elements, and external organizations to whom alerts, advisories, and directives are to be disseminated; system or network administrators; personnel with information security responsibilities].</interview>
        <test>[SELECT FROM: Organizational processes for defining, receiving, generating, disseminating, and complying with security alerts, advisories, and directives; mechanisms supporting or implementing definition, receipt, generation, and dissemination of security alerts, advisories, and directives; mechanisms supporting or implementing security directives].</test>
        <objective>[a] response actions to system security alerts and advisories are identified;</objective>
        <objective>[b] system security alerts and advisories are monitored; and</objective>
        <objective>[c] actions in response to system security alerts and advisories are taken.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L3</level>
      <nist>3.14.3e</nist>
      <name>Specialized Asset Security</name>
      <description>Ensure that specialized assets including IoT, IIoT, OT, GFE, Restricted Information Systems, and test equipment are included in the scope of the specified enhanced security requirements or are segregated in purpose-specific networks.</description>
      <discussion>Organizations may have a variety of systems and system components in their inventory, including Information Technology (IT), Internet of Things (IoT), Operational Technology (OT), and Industrial Internet of Things (IIoT). The convergence of IT, OT, IoT, and IIoT significantly increases the attack surface of organizations and provides attack vectors that are challenging to address. Compromised IoT, OT, and IIoT system components can serve as launching points for attacks on organizational IT systems that handle CUI. Some IoT, OT, and IIoT system components can store, transmit, or process CUI (e.g., specifications or parameters for objects manufactured in support of critical programs). Most of the current generation of IoT, OT, and IIoT system components are not designed with security as a foundational property and may not be able to be configured to support security functionality. Connections to and from such system components are generally not encrypted, do not provide the necessary authentication, are not monitored, and are not logged. Therefore, these components pose a significant cyber threat. Gaps in IoT, OT, and IIoT security capabilities may be addressed by employing intermediary system components that can provide encryption, authentication, security scanning, and logging capabilities—thus, preventing the components from being accessible from the Internet. However, such mitigation options are not always available or practicable. The situation is further complicated because some of the IoT, OT, and IIoT devices may be needed for essential missions and business functions. In those instances, it is necessary for such devices to be isolated from the Internet to reduce the susceptibility to cyber-attacks.  [SP 800-160-1] provides guidance on security engineering practices and security design concepts.</discussion>
      <source>NIST SP 800-172 3.14.3e</source>
      <score>1</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Access control policy; information flow control policies; system and services acquisition policy; system and communications protection policy; procedures addressing security function isolation; procedures addressing application partitioning; procedures addressing security engineering principles used in the specification, design, development, implementation, and modification of the system; procedures addressing information flow enforcement; procedures addressing access enforcement; system architecture; system design documentation; security plan; system component inventory; system configuration settings and associated documentation; system baseline configuration; list of security functions to be isolated from non-security functions; system audit records; security requirements and specifications for the system; list of approved authorizations (user privileges); list of information flow authorizations; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Organizational personnel responsible for access enforcement; system/network administrators; organizational personnel responsible for information security; system developers; system integrators; organizational personnel responsible for acquisition/contracting;  organizational personnel responsible for determining system security requirements; system security architects; enterprise architects; organizational personnel responsible for system specification, design, development, implementation, and modification].</interview>
        <test>[SELECT FROM: Mechanisms implementing the access control policy; mechanisms implementing the information flow enforcement policy; mechanisms supporting the application of security engineering principles in system specification, design, development, implementation, and modification].</test>
        <objective>[a] Specialized assets including IoT, IIoT, OT, GFE, Restricted Information Systems and test equipment are included in the scope of the specified enhanced security requirements; and</objective>
        <objective>[b] Systems and system components that are not included in specialized assets including IoT, IIoT, OT, GFE, Restricted Information Systems and test equipment are segregated in purpose-specific networks.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L1</level>
      <nist>3.14.4</nist>
      <far>b.1.xiv</far>
      <name>Update Malicious Code Protection</name>
      <description>Update malicious code protection mechanisms when new releases are available.</description>
      <discussion>Malicious code protection mechanisms include anti-virus signature definitions and reputation-based technologies. A variety of technologies and methods exist to limit or eliminate the effects of malicious code. Pervasive configuration management and comprehensive software integrity controls may be effective in preventing execution of unauthorized code. In addition to commercial off-the-shelf software, malicious code may also be present in custom-built software. This could include logic bombs, back doors, and other types of cyber-attacks that could affect organizational missions/business functions. Traditional malicious code protection mechanisms cannot always detect such code. In these situations, organizations rely instead on other safeguards including secure coding practices, configuration management and control, trusted procurement processes, and monitoring practices to help ensure that software does not perform functions other than the functions intended.</discussion>
      <source>FAR Clause 52.204-21 b.1.xiv, NIST SP 800-171 Rev 2 3.14.4</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: System and information integrity policy; configuration management policy and procedures; procedures addressing malicious code protection; malicious code protection mechanisms; records of malicious code protection updates; security plan; system design documentation; system configuration settings and associated documentation; scan results from malicious code protection mechanisms; record of actions initiated by malicious code protection mechanisms in response to malicious code detection; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: System or network administrators; personnel with information security responsibilities; personnel installing, configuring, and maintaining the system; personnel with responsibility for malicious code protection; personnel with configuration management responsibility].</interview>
        <test>[SELECT FROM: Organizational processes for employing, updating, and configuring malicious code protection mechanisms; organizational process for addressing false positives and resulting potential impact; mechanisms supporting or implementing malicious code protection mechanisms (including updates and configurations); mechanisms supporting or implementing malicious code scanning and subsequent actions].</test>
        <objective>[a] malicious code protection mechanisms are updated when new releases are available.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L1</level>
      <nist>3.14.5</nist>
      <far>b.1.xv</far>
      <name>System &amp; File Scanning</name>
      <description>Perform periodic scans of the information system and real-time scans of files from external sources as files are downloaded, opened, or executed.</description>
      <discussion>Periodic scans of organizational systems and real-time scans of files from external sources can detect malicious code. Malicious code can be encoded in various formats (e.g., UUENCODE, Unicode), 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 web accesses, electronic mail, electronic mail attachments, and portable storage devices. Malicious code insertions occur through the exploitation of system vulnerabilities.</discussion>
      <source>FAR Clause 52.204-21 b.1.xv, NIST SP 800-171 Rev 2 3.14.5</source>
      <score>3</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: System and information integrity policy; configuration management policy and procedures; procedures addressing malicious code protection; malicious code protection mechanisms; records of malicious code protection updates; security plan; system design documentation; system configuration settings and associated documentation; scan results from malicious code protection mechanisms; record of actions initiated by malicious code protection mechanisms in response to malicious code detection; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: System or network administrators; personnel with information security responsibilities; personnel installing, configuring, and maintaining the system; personnel with responsibility for malicious code protection; personnel with configuration management responsibility].</interview>
        <test>[SELECT FROM: Organizational processes for employing, updating, and configuring malicious code protection mechanisms; organizational process for addressing false positives and resulting potential impact; mechanisms supporting or implementing malicious code protection mechanisms (including updates and configurations); mechanisms supporting or implementing malicious code scanning and subsequent actions].</test>
        <objective>[a] the frequency for malicious code scans is defined;</objective>
        <objective>[b] malicious code scans are performed with the defined frequency; and</objective>
        <objective>[c] real-time malicious code scans of files from external sources as files are downloaded, opened, or executed are performed.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.14.6</nist>
      <name>Monitor Communications for Attacks</name>
      <description>Monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks.</description>
      <discussion>System monitoring includes external and internal monitoring. External monitoring includes the observation of events occurring at the system boundary (i.e., part of perimeter defense and boundary protection). Internal monitoring includes the observation of events occurring within the system. Organizations can monitor systems, for example, by observing audit record activities in real time or by observing other system aspects such as access patterns, characteristics of access, and other actions. The monitoring objectives may guide determination of the events. System monitoring capability is achieved through a variety of tools and techniques (e.g., intrusion detection systems, intrusion prevention systems, malicious code protection software, scanning tools, audit record monitoring software, network monitoring software). Strategic locations for monitoring devices include selected perimeter locations and near server farms supporting critical applications, with such devices being employed at managed system interfaces. The granularity of monitoring information collected is based on organizational monitoring objectives and the capability of systems to support such objectives.  System monitoring is an integral part of continuous monitoring and incident response programs. Output from system monitoring serves as input to continuous monitoring and incident response programs. A network connection is any connection with a device that communicates through a network (e.g., local area network, Internet). A remote connection is any connection with a device communicating through an external network (e.g., the Internet). Local, network, and remote connections can be either wired or wireless.  Unusual or unauthorized activities or conditions related to inbound/outbound communications traffic include internal traffic that indicates the presence of malicious code in systems or propagating among system components, the unauthorized exporting of information, or signaling to external systems. Evidence of malicious code is used to identify potentially compromised systems or system components. System monitoring requirements, including the need for specific types of system monitoring, may be referenced in other requirements.  [SP 800-94] provides guidance on intrusion detection and prevention systems.</discussion>
      <source>NIST SP 800-171 Rev 2 3.14.6</source>
      <score>5</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: System and information integrity policy; procedures addressing system monitoring tools and techniques; continuous monitoring strategy; system and information integrity policy; procedures addressing system monitoring tools and techniques; facility diagram or layout; security plan; system design documentation; system monitoring tools and techniques documentation; locations within system where monitoring devices are deployed; system protocols; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records].</examine>
        <interview>[SELECT FROM: System or network administrators; personnel with information security responsibilities; personnel installing, configuring, and maintaining the system; personnel with responsibility monitoring the system; personnel with responsibility for the intrusion detection system].</interview>
        <test>[SELECT FROM: Organizational processes for system monitoring; mechanisms supporting or implementing intrusion detection capability and system monitoring; mechanisms supporting or implementing system monitoring capability; organizational processes for intrusion detection and system monitoring; mechanisms supporting or implementing the monitoring of inbound and outbound communications traffic].</test>
        <objective>[a] the system is monitored to detect attacks and indicators of potential attacks;</objective>
        <objective>[b] inbound communications traffic is monitored to detect attacks and indicators of potential attacks; and</objective>
        <objective>[c] outbound communications traffic is monitored to detect attacks and indicators of potential attacks.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L3</level>
      <nist>3.14.6e</nist>
      <name>Threat-Guided Intrusion Detection</name>
      <description>Use threat indicator information and effective mitigations obtained from, at a minimum, open or commercial sources, and any DoD-provided sources, to guide and inform intrusion detection and threat hunting.</description>
      <discussion>Threat information related to specific threat events (e.g., TTPs, targets) that organizations have experienced, threat mitigations that organizations have found to be effective against certain types of threats, and threat intelligence (i.e., indications and warnings about threats that can occur) are sourced from and shared with trusted organizations. This threat information can be used by organizational Security Operations Centers (SOC) and incorporated into monitoring capabilities. Threat information sharing includes threat indicators, signatures, and adversary TTPs from organizations participating in threat-sharing consortia, government-commercial cooperatives, and government-government cooperatives (e.g., CERTCC, CISA/US-CERT, FIRST, ISAO, DIB CS Program). Unclassified indicators, based on classified information but which can be readily incorporated into organizational intrusion detection systems, are available to qualified nonfederal organizations from government sources.</discussion>
      <source>NIST SP 800-172 3.14.6e</source>
      <score>1</score>
      <poam>Yes</poam>
      <assessment>
        <examine>[SELECT FROM: System and information integrity policy; information security program plan; procedures addressing security alerts, advisories, and directives; threat awareness program documentation; procedures addressing system monitoring; procedures for the threat awareness program; risk assessment results relevant to threat awareness; records of security alerts and advisories; system design documentation; security plan; system monitoring tools and techniques documentation; system configuration settings and associated documentation; system monitoring logs or records; system audit records; documentation on the cross-organization information-sharing capability; other relevant documents or records].</examine>
        <interview>[SELECT FROM: Organizational personnel responsible for information security program planning and plan implementation; system/network administrators; organizational personnel responsible for the threat awareness program; organizational personnel responsible for the cross-organization information-sharing capability; organizational personnel responsible for information security; organizational personnel responsible for installing, configuring, and/or maintaining the system; organizational personnel responsible for monitoring system hosts; organizational personnel responsible for security alerts and advisories; organizational personnel responsible for implementing, operating, maintaining, and using the system; organizational personnel, organizational elements, and/or external organizations to whom alerts, advisories, and directives are to be disseminated;  personnel with whom threat awareness information is shared by the organization; system developers].</interview>
        <test>[SELECT FROM: Mechanisms supporting and/or implementing the threat awareness program; mechanisms supporting and/or implementing the cross-organization information-sharing capability; mechanisms supporting and/or implementing the system monitoring capability; mechanisms supporting and/or implementing the definition, receipt, generation, and dissemination of security alerts, advisories, and directives; mechanisms supporting and/or implementing security directives; mechanisms supporting and/or implementing threat hunting; mechanisms supporting and/or implementing intrusion detection; mechanisms supporting and/or implementing the discovery, collection, distribution, and use of indicators of compromise].</test>
        <objective>[ODP1] External organizations from which to obtain threat indicator information and effective mitigations are defined;</objective>
        <objective>[a] Threat indicator information is identified;</objective>
        <objective>[b] Effective mitigations are identified;</objective>
        <objective>[c] Intrusion detection approaches are identified;</objective>
        <objective>[d] Threat hunting activities are identified; and</objective>
        <objective>[e] Threat indicator information and effective mitigations obtained from, at a minimum, open or commercial sources and any DoD-provided sources, are used to guide and inform intrusion detection and threat hunting.</objective>
      </assessment>
    </practice>
    <practice>
      <level>L2</level>
      <nist>3.14.7</nist>
      <name>Identify Unauthorized Use</name>
      <description>Identify unauthorized use of organizational systems.</description>
      <discussion>System monitoring includes external and internal monitoring. System monitoring can detect unauthorized use of organizational systems.  System monitoring is an integral part of continuous monitoring and incident response programs. Monitoring is achieved through a variety of tools and techniques (e.g., intrusion detection systems, intrusion prevention systems, malicious code protection software, scanning tools, audit record monitoring software, network monitoring software). Output from system monitoring serves as input to continuous monitoring and incident response programs.  Unusual/unauthorized activities or conditions related to inbound and outbound communications traffic include internal traffic that indicates the presence of malicious code in systems or propagating among system components, the unauthorized exporting of information, or signaling to external systems. Evidence of malicious code is used to identify potentially compromised systems or system components. System monitoring requirements, including the need for specific types of system monitoring, may be referenced in other requirements.  [SP 800-94] provides guidance on intrusion detection and prevention systems.</discussion>
      <source>NIST SP 800-171 Rev 2 3.14.7</source>
      <score>3</score>
      <poam>No</poam>
      <assessment>
        <examine>[SELECT FROM: Continuous monitoring strategy; system and information integrity policy; procedures addressing system monitoring tools and techniques; facility diagram/layout; security plan; system design documentation; system monitoring tools and techniques documentation; locations within system where monitoring devices are deployed; system configuration settings and associated documentation; other relevant documents or records].</examine>
        <interview>[SELECT FROM: System or network administrators; personnel with information security responsibilities; personnel installing, configuring, and maintaining the system; personnel with responsibility for monitoring the system].</interview>
        <test>[SELECT FROM: Organizational processes for system monitoring; mechanisms supporting or implementing system monitoring capability].</test>
        <objective>[a] authorized use of the system is defined; and</objective>
        <objective>[b] unauthorized use of the system is identified.</objective>
      </assessment>
    </practice>
  </domain>
</cmmc>
