NIST SP 800-171 Rev 3 Control Guide

Define the types of system accounts allowed and prohibited. Create, enable, modify, disable, and remove system accounts in accordance with policy, procedures, prerequisites, and criteria. Specify authorized users of the system, group and role membership, and access authorizations (i.e., privileges) for each account. Authorize access to the system based on a valid access authorization and intended system usage. Monitor the use of system accounts. Disable system accounts when the accounts have expired, have been inactive for [organization-defined time period], … (abridged)

Enforce approved authorizations for logical access to CUI and system resources in accordance with applicable access control policies.

Define permission profiles and assign them to users and teams.

Enforce approved authorizations for controlling the flow of CUI within the system and between connected systems.

Designate who may approve exports out of a project.

Identify the duties of individuals requiring separation. Define system access authorizations to support separation of duties.

Decide which staff hold each admin tier and document the profile assignments.

Allow only authorized system access for users (or processes acting on behalf of users) that is necessary to accomplish assigned organizational tasks. Authorize access to [organization-defined security functions] and [organization-defined security-relevant information]. Review the privileges assigned to roles or classes of users [organization-defined frequency] to validate the need for such privileges. Reassign or remove privileges, as necessary.

Restrict privileged accounts on the system to [organization-defined personnel or roles]. Require that users (or roles) with privileged accounts use non-privileged accounts when accessing non-security functions or non-security information.

Ensure admins use their non-privileged account for day-to-day research work.

Prevent non-privileged users from executing privileged functions. Log the execution of privileged functions.

Enforce a limit of [organization-defined number] consecutive invalid logon attempts by a user during a [organization-defined time period]. Automatically lock the account or node, delay the next logon prompt, notify the system administrator, or take other action when the maximum number of unsuccessful attempts is exceeded.

Accounts lock after a configurable number of failed private-key decryption attempts (default 5) and stay locked until an administrator releases them.

Set the lockout threshold (default 5).

Display a system use notification message with privacy and security notices consistent with applicable CUI rules before granting access to the system.

A configurable system-use banner with privacy and security notices is displayed before login.

Provide the banner text approved by your institution.

Prevent access to the system by initiating a device lock after [organization-defined time period] of inactivity and/or requiring the user to initiate a device lock before leaving the system unattended. Retain the device lock until the user reestablishes access using established identification and authentication procedures. Conceal, via the device lock, information previously visible on the display with a publicly viewable image.

Idle sessions lock after a configurable interval (default 15 minutes), hide the display, and purge keys client-side; the user must re-authenticate.

Set the idle-lock interval (default 15 minutes).

Terminate a user session automatically after [organization-defined conditions or trigger events requiring session disconnect].

Command sessions end automatically after inactivity, graphical sessions lock and require re-authentication, and keys are purged on logout.

Set session-termination thresholds.

Establish usage restrictions, configuration requirements, and connection requirements for each type of allowable remote system access. Authorize each type of remote system access prior to establishing such connections. Route remote access to the system through authorized and managed access control points. Authorize the remote execution of privileged commands and remote access to security-relevant information.

Document which remote privileged commands are authorized.

Establish usage restrictions, configuration requirements, and connection requirements for each type of wireless access to the system. Authorize each type of wireless access to the system prior to establishing such connections. Disable, when not intended for use, wireless networking capabilities prior to issuance and deployment. Protect wireless access to the system using authentication and encryption.

Establish usage restrictions, configuration requirements, and connection requirements for mobile devices. Authorize the connection of mobile devices to the system. Implement full-device or container-based encryption to protect the confidentiality of CUI on mobile devices.

Prohibit the use of external systems unless the systems are specifically authorized. Establish the following security requirements to be satisfied on external systems prior to allowing use of or access to those systems by authorized individuals: [organization-defined security requirements]. Permit authorized individuals to use external systems to access the organizational system or to process, store, or transmit CUI only after verifying that the security requirements on the external systems have been satisfied … Restrict the use of organization-controlled portable storage devices by authorized individuals on external systems. (abridged)

External systems cannot connect directly. VMs deny all outbound traffic by default, and any external endpoint (e.g., a license server) requires an explicit allowlist rule approved by a SuperAdmin.

Define the policy for permitted external connections and exports.

Train authorized individuals to ensure that publicly accessible information does not contain CUI. Review the content on publicly accessible systems for CUI and remove such information, if discovered.

The platform exposes no publicly accessible content.

Designate who may post information publicly and review public postings to confirm no CUI is released.

Provide security literacy training to system users as part of initial training for new users and [organization-defined frequency] thereafter, when required by system changes or following [organization-defined events], and on recognizing and reporting indicators of insider threat, social engineering, and social mining. Update security literacy training content [organization-defined frequency] and following [organization-defined events].

Provide role-based security training to organizational personnel before authorizing access to the system or CUI, before performing assigned duties, and [organization-defined frequency] thereafter, and when required by system changes or following [organization-defined events]. Update role-based training content [organization-defined frequency] and following [organization-defined events].

Specify the following event types selected for logging within the system: [organization-defined event types]. Review and update the event types selected for logging [organization-defined frequency].

Include the following content in audit records: what type of event occurred, when the event occurred, where the event occurred, source of the event, outcome of the event, and identity of the individuals, subjects, objects, or entities associated with the event. Provide additional information for audit records as needed.

Every action is tied to an authenticated user, session, and source IP, with millisecond UTC timestamps and a hash-chain position.

Generate audit records for the selected event types and audit record content specified in 03.03.01 and 03.03.02. Retain audit records for a time period consistent with the records retention policy.

Audit logging is always on and cannot be disabled or bypassed. 150+ event types are recorded (authentication, files, sharing, VMs, keys, admin actions), and records are kept for the life of the deployment by default on your own audit server.

Confirm the retention period meets your records policy (default: retained indefinitely) and back up the audit server.

Alert organizational personnel or roles within [organization-defined time period] in the event of an audit logging process failure. Take the following additional actions: [organization-defined additional actions].

The logging path is fail-closed: capacity alerts fire and key issuance halts at 90% log-storage use. Real-time alerts at five severity levels flag failures such as hash-chain breaks.

Route alerts to the right staff (email, Splunk, or another SIEM).

Review and analyze system audit records [organization-defined frequency] for indications and the potential impact of inappropriate or unusual activity. Report findings to organizational personnel or roles. Analyze and correlate audit records across different repositories to gain organization-wide situational awareness.

The separate audit system (ClickHouse) correlates events across users, resources, event types, and time ranges, and can forward alerts to Splunk, email, or other SIEMs.

Use the audit tools in your review process; set review cadence and alert routing.

Implement an audit record reduction and report generation capability that supports audit record review, analysis, reporting requirements, and after-the-fact investigations of incidents. Preserve the original content and time ordering of audit records.

A query builder, predefined compliance reports, direct SQL access, and Excel export support reduction and reporting without altering original records.

Use internal system clocks to generate time stamps for audit records. Record time stamps for audit records that meet [organization-defined granularity of time measurement] and that use Coordinated Universal Time (UTC), have a fixed local time offset from UTC, or include the local time offset as part of the time stamp.

All components record UTC timestamps with millisecond precision.

Synchronize host clocks to an authoritative NTP source.

Protect audit information and audit logging tools from unauthorized access, modification, and deletion. Authorize access to management of audit logging functionality to only a subset of privileged users or roles.

Limit audit-server access to designated administrators.

Develop and maintain under configuration control, a current baseline configuration of the system. Review and update the baseline configuration of the system [organization-defined frequency] and when system components are installed or modified.

Establish, document, and implement the following configuration settings for the system that reflect the most restrictive mode consistent with operational requirements: [organization-defined configuration settings]. Identify, document, and approve any deviations from established configuration settings.

Set organization-defined values and approve any deviations.

Define the types of changes to the system that are configuration-controlled. Review proposed configuration-controlled changes to the system, and approve or disapprove such changes with explicit consideration for security impacts. Implement and document approved configuration-controlled changes to the system. Monitor and review activities associated with configuration-controlled changes to the system.

Settings history records the previous value, new value, timestamp, and administrator. Platform releases are staged before production.

Run your change-control process (review and approve changes).

Analyze changes to the system to determine potential security impacts prior to change implementation. Verify that the security requirements for the system continue to be satisfied after the system changes have been implemented.

Changes to profiles, quotas, and project access go through audited Management Console controls, and Tera Insights evaluates platform changes before release.

Perform and record security impact analyses for changes in your environment.

Define, document, approve, and enforce physical and logical access restrictions associated with changes to the system.

Configuration changes are restricted to designated admins and audited. Software and VM images are signed, and boot images reset on every boot to prevent tampering.

Designate who may make changes and run change approval.

Configure the system to provide only mission-essential capabilities. Prohibit or restrict use of the following functions, ports, protocols, connections, and services: [organization-defined functions, ports, protocols, connections, and services]. Review the system [organization-defined frequency] to identify unnecessary or nonsecure functions, ports, protocols, connections, and services. Disable or remove functions, ports, protocols, connections, and services that are unnecessary or nonsecure.

Define any per-project software blocklists.

Identify software programs authorized to execute on the system. Implement a deny-all, allow-by-exception policy for the execution of authorized software programs on the system. Review and update the list of authorized software programs [organization-defined frequency].

Develop and document an inventory of system components. Review and update the system component inventory [organization-defined frequency]. Update the system component inventory as part of installations, removals, and system updates.

Identify and document the location of CUI and the system components on which the information is processed and stored. Document changes to the system or system component location where CUI is processed and stored.

Each project's data is segregated into its own encrypted VMs, drives, and Vault storage, and tiCrypt is deployed on-premises, so CUI stays on university-controlled infrastructure.

Document CUI storage locations (storage pools, hosts) in your SSP.

Issue systems or system components with the following configurations to individuals traveling to high-risk locations: [organization-defined system configurations]. Apply the following security requirements to the systems or components when the individuals return from travel: [organization-defined security requirements].

Uniquely identify and authenticate system users, and associate that unique identification with processes acting on behalf of those users. Re-authenticate users when [organization-defined circumstances or situations requiring re-authentication].

Uniquely identify and authenticate [organization-defined devices or types of devices] before establishing a system connection.

Users authenticate by signing a server challenge with their private key, no password is sent. Endpoints and VMs are authenticated by key material before any connection is established.

Implement multi-factor authentication for access to privileged and non-privileged accounts.

MFA through Duo or Shibboleth is layered on top of the private-key signature. The MFA assertion is signed and verified independently, and its identity must match the key holder or the session is denied.

Enable MFA and set its scope (off until enabled). Provide MFA for host-level admin access outside tiCrypt.

Implement replay-resistant authentication mechanisms for access to privileged and non-privileged accounts.

Each login challenge uses a random single-use nonce, so a captured response cannot be replayed.

Receive authorization from organizational personnel or roles to assign an individual, group, role, service, or device identifier. Select and assign an identifier that identifies an individual, group, role, service, or device. Prevent the reuse of identifiers for [organization-defined time period]. Manage individual identifiers by uniquely identifying each individual as [organization-defined characteristic identifying individual status].

User identifiers and UUIDs are unique and never reused, even after deletion.

Maintain a list of commonly-used, expected, or compromised passwords, and update the list [organization-defined frequency] and when organizational passwords are suspected to have been compromised. Verify that passwords are not found on that list when users create or update passwords. Transmit passwords only over cryptographically protected channels. Store passwords in a cryptographically protected form. Select a new password upon first use after account recovery. Enforce the following composition and complexity rules for passwords: [organization-defined rules]. (abridged)

Define password composition rules.

Obscure feedback of authentication information during the authentication process.

Password entry is obscured, and login errors are generic, they do not reveal whether a username exists or which credential failed.

Verify the identity of the individual, group, role, service, or device receiving the authenticator as part of the initial authenticator distribution. Establish initial authenticator content for any authenticators issued by the organization. Establish and implement administrative procedures for initial authenticator distribution; for lost, compromised, or damaged authenticators; and for revoking authenticators. Change default authenticators at first use. Change or refresh authenticators [organization-defined frequency] or when defined events occur. Protect authenticator content from unauthorized disclosure and modification. (abridged)

The authenticator is the user's client-encrypted private key, created at one-time registration and validated against a site-key chain of trust. Lockout limits guessing, password changes invalidate older key files, and escrow supports recovery of lost keys.

Verify each person's identity before approving registration, and define procedures for lost or compromised key files.

Implement an incident-handling capability that is consistent with the incident response plan and includes preparation, detection and analysis, containment, eradication, and recovery.

Track and document system security incidents. Report suspected incidents to the organizational incident response capability within [organization-defined time period]. Report incident information to [organization-defined authorities]. Provide an incident response support resource that offers advice and assistance to system users on handling and reporting incidents.

Audit logs and real-time, severity-tiered alerts provide detection data and forensic evidence for investigations.

Track, document, and report incidents to designated officials and authorities, including DoD's 72-hour reporting window.

Test the effectiveness of the incident response capability [organization-defined frequency].

Provide incident response training to system users consistent with assigned roles and responsibilities within [organization-defined time period] of assuming an incident response role or responsibility or acquiring system access, when required by system changes, and [organization-defined frequency] thereafter. Review and update incident response training content [organization-defined frequency] and following [organization-defined events].

Develop an incident response plan that provides a roadmap for implementing the incident response capability, describes its structure and organization, defines reportable incidents, addresses the sharing of incident information, and designates responsibilities. Distribute copies of the plan to designated incident response personnel; update the plan to address system and organizational changes or problems encountered during implementation, execution, or testing; and protect the plan from unauthorized disclosure. (abridged)

Approve, control, and monitor the use of system maintenance tools. Check media with diagnostic and test programs for malicious code before it is used in the system. Prevent the removal of system maintenance equipment containing CUI by verifying that there is no CUI on the equipment, sanitizing or destroying the equipment, or retaining the equipment within the facility.

The management interface is the only maintenance tool for the platform, and all maintenance runs over authenticated, encrypted, audited channels.

Approve and inspect any maintenance tools used on host infrastructure.

Approve and monitor nonlocal maintenance and diagnostic activities. Implement multi-factor authentication and replay resistance in the establishment of nonlocal maintenance and diagnostic sessions. Terminate session and network connections when nonlocal maintenance is completed.

Remote maintenance uses the same RSA challenge-response authentication, with MFA where required; sessions are encrypted and closed when finished.

Pre-approve and supervise vendor remote access; enable MFA.

Establish a process for maintenance personnel authorization. Maintain a list of authorized maintenance organizations or personnel. Verify that non-escorted personnel who perform maintenance on the system possess the required access authorizations. Designate organizational personnel with required access authorizations and technical competence to supervise the maintenance activities of personnel who do not possess the required access authorizations.

The management interface is the only maintenance tool for the platform, and all maintenance runs over authenticated, encrypted, audited channels.

Approve and inspect any maintenance tools used on host infrastructure.

Physically control and securely store system media that contain CUI.

All data is AES-256 encrypted before it reaches any media, and decryption keys are never stored on the infrastructure, so media holds only ciphertext.

Physically control and securely store the media (disks, backups) that hold the ciphertext.

Restrict access to CUI on system media to authorized personnel or roles.

Reading CUI requires tiCrypt authentication and the owner's key, regardless of who can touch the media.

Control physical access to the media.

Sanitize system media that contain CUI prior to disposal, release out of organizational control, or release for reuse.

Cryptographic erasure: destroying a resource's per-file or per-drive key makes the remaining ciphertext unrecoverable.

Sanitize physical media and the unencrypted metadata database per NIST SP 800-88 before disposal or reuse, and make sure escrowed and backup key copies are destroyed.

Mark system media that contain CUI to indicate distribution limitations, handling caveats, and applicable CUI markings.

tiCrypt's interfaces support configurable CUI markings and labels.

Apply physical markings, distribution limits, and handling caveats to media.

Protect and control system media that contain CUI during transport outside of controlled areas. Maintain accountability of system media that contain CUI during transport outside of controlled areas. Document activities associated with the transport of system media that contain CUI.

All transfers are logged, and data in transit is encrypted end to end.

Keep custody, accountability, and handling records for physical media transported outside controlled areas.

Restrict or prohibit the use of [organization-defined types of system media]. Prohibit the use of removable system media without an identifiable owner.

Protect the confidentiality of backup information. Implement cryptographic mechanisms to prevent the unauthorized disclosure of CUI at backup storage locations.

Backups contain only ciphertext because no decryption keys are stored on the infrastructure.

Screen individuals prior to authorizing access to the system. Rescreen individuals in accordance with [organization-defined conditions requiring rescreening].

When individual employment is terminated: disable system access within [organization-defined time period], terminate or revoke authenticators and credentials associated with the individual, and retrieve security-related system property. When individuals are reassigned or transferred: review and confirm the ongoing operational need for current logical and physical access authorizations, and modify access authorization to correspond with any changes in operational need.

Develop, approve, and maintain a list of individuals with authorized access to the facility where the system resides. Issue authorization credentials for facility access. Review the facility access list [organization-defined frequency]. Remove individuals from the facility access list when access is no longer required.

Monitor physical access to the facility where the system resides to detect and respond to physical security incidents. Review physical access logs [organization-defined frequency] and upon occurrence of [organization-defined events or potential indications of events].

Determine alternate work sites allowed for use by employees. Employ the following security requirements at alternate work sites: [organization-defined security requirements].

Enforce physical access authorizations at entry and exit points to the facility where the system resides by verifying individual physical access authorizations before granting access and controlling ingress and egress with physical access control systems, devices, or guards. Maintain physical access audit logs for entry or exit points. Escort visitors, and control visitor activity. Secure keys, combinations, and other physical access devices. Control physical access to output devices to prevent unauthorized individuals from obtaining access to CUI.

Control physical access to system distribution and transmission lines within organizational facilities.

Assess the risk (including supply chain risk) of unauthorized disclosure resulting from the processing, storage, or transmission of CUI. Update risk assessments [organization-defined frequency].

Monitor and scan the system for vulnerabilities [organization-defined frequency] and when new vulnerabilities affecting the system are identified. Remediate system vulnerabilities within [organization-defined response times]. Update system vulnerabilities to be scanned [organization-defined frequency] and when new vulnerabilities are identified and reported.

Respond to findings from security assessments, monitoring, and audits.

Tera Insights remediates platform vulnerabilities on a regular cadence, with critical fixes out of band, and the audit system supplies monitoring evidence.

Respond to findings from security assessments, monitoring, and audits across the full CUI boundary.

Assess the security requirements for the system and its environment of operation [organization-defined frequency] to determine if the requirements have been satisfied.

Tera Insights supplies SSP templates, assessment evidence packages, and direct support during C3PAO assessments.

Coordinate the C3PAO engagement, provide evidence for university controls, and make sure the assessment covers the full CUI boundary.

Develop a plan of action and milestones for the system to document the planned remediation actions to correct weaknesses or deficiencies noted during security assessments and to reduce or eliminate known system vulnerabilities. Update the existing plan of action and milestones based on the findings from security assessments, audits or reviews, and continuous monitoring activities.

Tera Insights helps draft POA&M items for platform controls, provides templated workflows, and handles platform-side remediation.

Own and track the POA&M and report milestones to the C3PAO.

Develop and implement a system-level continuous monitoring strategy that includes ongoing monitoring and security assessments.

Approve and manage the exchange of CUI between the system and other systems using interconnection security agreements, information exchange security agreements, memoranda of understanding or agreement, service-level agreements, user agreements, non-disclosure agreements, or other types of agreements. Document interface characteristics, security requirements, and responsibilities for each system as part of the exchange agreements. Review and update the exchange agreements [organization-defined frequency].

CUI enters only through logged ingress paths (Vault upload, Inboxes, SFTP), SFTP is upload-only, and data leaves only through an explicit, logged export approval, so exchange terms can be enforced technically.

Establish and manage exchange agreements (ISAs, DUAs, MOUs) and document interface responsibilities.

Monitor and control communications at external managed interfaces to the system and key internal managed interfaces within the system. Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks. Connect to external systems only through managed interfaces that consist of boundary protection devices arranged in accordance with an organizational security architecture.

Prevent unauthorized and unintended information transfer via shared system resources.

VMs reset to immutable images on every boot, and each service has its own database. SFTP into VMs is write-only, and transfers go through the audited Vault.

Deny network communications traffic by default, and allow network communications traffic by exception.

Inbound and outbound traffic is denied by default. Every outbound exception requires a firewall/allowlist rule created with SuperAdmin privilege.

Approve any outbound exceptions (e.g., license servers).

Implement cryptographic mechanisms to prevent the unauthorized disclosure of CUI during transmission and while in storage.

Protect the metadata database as part of the CUI boundary.

Terminate the network connection associated with a communications session at the end of the session or after [organization-defined time period] of inactivity.

Tunnels close at session end and idle sessions disconnect; client keys are purged on termination.

Set the idle-disconnect interval.

Establish and manage cryptographic keys in the system in accordance with the following key management requirements: [organization-defined requirements for key generation, distribution, storage, access, and destruction].

Keys are generated client-side (AES-256 per file and drive, RSA-2048 per user) and never stored unwrapped on the server. Key recovery uses escrow split across at least three independent holders.

Define escrow groups (minimum three) and their membership.

Implement the following types of cryptography when used to protect the confidentiality of CUI: [organization-defined types of cryptography].

All cryptography runs through the FIPS-validated OpenSSL 3.1.2 FIPS provider (CMVP #4985) in approved mode, no custom cryptography. FIPS mode is also enabled in secure VMs.

Prohibit the remote activation of collaborative computing devices and applications with the following exceptions: [organization-defined exceptions where remote activation is to be allowed]. Provide an explicit indication of use to users physically present at the devices.

Not applicable by design: collaborative computing devices (cameras, microphones) are not supported in the environment, so remote activation cannot occur.

Define acceptable mobile code and mobile code technologies. Authorize, monitor, and control the use of mobile code.

The frontend bundles all its dependencies and references no external code; it runs in the controlled Connect app, and software is signed. VMs have no browser-based code paths to external networks.

Protect the authenticity of communications sessions.

Sessions are authenticated by RSA challenge-response over mutually authenticated channels (TLS plus Diffie-Hellman), preventing hijacking and replay.

Identify, report, and correct system flaws. Install security-relevant software and firmware updates within [organization-defined time period] of the release of the updates.

Tera Insights maintains the software lifecycle, identifies flaws, and releases signed updates; VM images are rebuilt with current patches.

Apply updates on your schedule.

Implement malicious code protection mechanisms at system entry and exit points to detect and eradicate malicious code. Update malicious code protection mechanisms as new releases are available in accordance with configuration management policies and procedures. Configure malicious code protection mechanisms to perform scans of the system [organization-defined frequency] and real-time scans of files from external sources as the files are downloaded, opened, or executed, and to block, quarantine, or take other action on malicious code. (abridged)

Receive system security alerts, advisories, and directives from external organizations on an ongoing basis. Generate and disseminate internal system security alerts, advisories, and directives, as necessary.

Real-time alerts at five severity levels cover authentication failures, access attempts, and anomalies, and Tera Insights relays relevant security advisories.

Act on advisories and alerts.

Monitor the system to detect attacks and indicators of potential attacks and unauthorized connections. Identify unauthorized use of the system. Monitor inbound and outbound communications traffic to detect unusual or unauthorized activities or conditions.

Manage and retain CUI within the system and CUI output from the system in accordance with applicable laws, Executive Orders, directives, regulations, policies, standards, guidelines, and operational requirements.

Closing a project destroys its encryption keys, making the data permanently unrecoverable, and the event is logged as the destruction record. Audit records are retained for the life of the deployment by default.

Define retention and destruction requirements from laws, contracts, and DUAs, and trigger project closure when they are met.

Develop, document, and disseminate to organizational personnel or roles the policies and procedures needed to satisfy the security requirements for the protection of CUI. Review and update policies and procedures [organization-defined frequency].

Develop a system security plan that defines the constituent system components; identifies the information types processed, stored, and transmitted; describes specific threats of concern; describes the operational environment and any dependencies on or connections to other systems; provides an overview of the security requirements; describes the safeguards in place or planned; and identifies individuals that fulfill system roles and responsibilities. Review and update the plan [organization-defined frequency] and protect it from unauthorized disclosure. (abridged)

Establish rules that describe the responsibilities and expected behavior for system usage and protecting CUI. Provide rules to individuals who require access to the system. Receive a documented acknowledgement from individuals indicating that they have read, understand, and agree to abide by the rules of behavior before authorizing access to CUI and the system. Review and update the rules of behavior [organization-defined frequency].

Apply the following systems security engineering principles to the development or modification of the system and system components: [organization-defined systems security engineering principles].

The platform is engineered with layered security, end-to-end encryption, least privilege, and microservice isolation (zero-knowledge design).

Replace system components when support for the components is no longer available from the developer, vendor, or manufacturer. Provide options for risk mitigation or alternative sources for continued support for unsupported components that cannot be replaced.

Tera Insights maintains supported releases and patches for all tiCrypt software components.

Replace unsupported host operating systems, hypervisors, and hardware in the CUI boundary.

Require the providers of external system services used for the processing, storage, or transmission of CUI to comply with the following security requirements: [organization-defined security requirements]. Define and document user roles and responsibilities with regard to external system services, including shared responsibilities with external service providers. Implement processes, methods, and techniques to monitor security requirement compliance by external service providers on an ongoing basis.

Develop a plan for managing supply chain risks associated with the research and development, design, manufacturing, acquisition, delivery, integration, operations, maintenance, and disposal of the system, system components, or system services. Review and update the supply chain risk management plan [organization-defined frequency]. Protect the supply chain risk management plan from unauthorized disclosure.

Develop and implement acquisition strategies, contract tools, and procurement methods to identify, protect against, and mitigate supply chain risks.

Establish a process for identifying and addressing weaknesses or deficiencies in the supply chain elements and processes. Enforce the following security requirements to protect against supply chain risks to the system, system components, or system services and to limit the harm or consequences from supply chain-related events: [organization-defined security requirements].

tiCrypt software and certificates are signed and verified before deployment, development is under configuration management, and builds are security-tested in staging before release.

Establish your supply chain risk process and the security requirements you place on suppliers.