tiCrypt
Rev 3 Readiness
AdministratorRequires: The Change system settings permission for System Settings; root on the backend host and in VM images for the configuration files
Rev 3 readiness is the state of a tiCrypt deployment measured against NIST SP 800-171 Revision 3 with the Department of Defense's organization-defined parameter (ODP) values applied. An ODP is a blank that Revision 3 leaves in a requirement, such as a number of failed logons or a period of inactivity, for a federal agency or the organization to fill in. Revision 3 states that "Once specified, the values for the organization-defined parameters become part of the requirement." Rev 3 readiness is not CMMC certification. CMMC Level 2 is assessed against Revision 2 today, and this page shows what changes when Revision 3 applies.
Why Rev 3 readiness matters now
The values are already set. Revision 3 is not yet the assessed standard, but the Department of Defense has published the value it expects for every ODP in it. A contractor that implements Revision 3 must use those values, so the target is known before the rule changes.
The values are specific, and some are stricter than tiCrypt's defaults. Revision 2 says "Limit unsuccessful logon attempts" and leaves the number to you. The Department's value for Revision 3 is "at most five (5)". tiCrypt's default is 10. A deployment that meets Revision 2 can miss a Revision 3 value until a setting changes.
Gaps have to be addressed before Revision 3 is assessed. The Department's guidance, quoted below, tells contractors to address the gaps between the two revisions. This page lists them for a tiCrypt deployment: the settings to change, the values to write into your policies, and the requirements that have no CMMC practice behind them.
Where Revision 3 stands for CMMC
The Department of Defense CIO's CMMC Frequently Asked Questions (July 2026 edition), question B-Q3, asks whether the Department will update the program to use Revision 3. The answer:
Yes, the Department will incorporate Revision 3 with future rulemaking. In the interim, the Department has issued a class deviation to Defense Federal Acquisition Regulation Supplement clause 252.204-7012 to maintain Revision 2 as the standard against which defense industrial base companies will be assessed until Revision 3 has been incorporated into the 32 Code of Federal Regulations CMMC Program rule through rulemaking.
Question B-Q4 of the same document asks whether contractors can implement Revision 3. The answer:
Yes. Companies can implement Revision 3 but must use the Department's Organization-Defined Parameters (ODPs) defined in the April 2025 memorandum, "Department of Defense Organization-Defined Parameters for National Institute of Standards and Technology Special Publication 800-171 Revision 3" found here: https://dodcio.defense.gov/Portals/0/Documents/CMMC/OrgDefinedParmsNISTSP800-171.pdf. Because CMMC assessments will be conducted against Revision 2 until the class deviation memo (see Q3 of this section) is withdrawn or otherwise superseded, defense industrial base companies must ensure any identified gaps between Revision 2 and Revision 3 are addressed.
The two answers lead to three working rules.
- Assessment: Your CMMC Level 2 assessment uses Revision 2. The CMMC Level 2 control guide is the reference for it.
- Values: If you implement Revision 3, the ODP values are the Department's, not your own. The tables on this page use them.
- Gaps: The differences between the revisions are yours to close. See Gaps between Revision 2 and Revision 3.
The Revision 3 picture for a tiCrypt deployment
Revision 3 has 97 active requirements. The NIST SP 800-171 Rev 3 control guide assigns each one to tiCrypt, to your organization, or to both. The following table describes the split.
| Requirements | Total | tiCrypt implements | Shared | Your organization |
|---|---|---|---|---|
| Active in Revision 3 | 97 | 50 | 21 | 26 |
| Carried from a CMMC practice | 80 | 47 | 16 | 17 |
| New in Revision 3, with no CMMC practice | 17 | 3 | 5 | 9 |
A shared requirement is one where tiCrypt supplies part of the implementation and your organization supplies the rest. A requirement that tiCrypt implements can still have settings and procedures that are yours, and the control guide lists them for each requirement. Revision 3 also withdraws 33 requirement numbers, which the control guide lists with the reason for each.
The Department's ODP values
The values come from the memorandum "Department of Defense Organization-Defined Parameters for National Institute of Standards and Technology Special Publication 800-171 Revision 3", signed on April 10, 2025, and published at dodcio.defense.gov. Its Attachment A assigns 80 ODPs across 50 requirements. The memorandum states that four of them are "defined as guidance versus a specified value", and that the values "will be updated as necessary". Work from the memorandum itself when you write your System Security Plan.
Several values use the word "significant". The memorandum defines it: "Significant: having or likely to have influence or effect."
This page accounts for all 80 ODPs. The 51 that belong to a requirement tiCrypt implements or shares are in the tables that follow. The 29 that belong to a requirement that is entirely your organization's are in ODPs that are entirely your organization's.
How to read the results
Each row ends with one of five results.
- Meets: tiCrypt's default, or a behavior that tiCrypt fixes, satisfies the Department's value. There is nothing to change in tiCrypt.
- Change: A tiCrypt setting has to change. The row names the key and the value.
- Partly: tiCrypt satisfies part of the value. The row says which part is left to you.
- No setting: tiCrypt's behavior does not match the value, and no setting changes it. Record the difference in your System Security Plan and your plan of action.
- Organization: The value is yours to define and to operate outside tiCrypt. Where tiCrypt has a related setting or record, the row names it.
A result covers tiCrypt only. Hosts, VM operating systems, networks, and workstations have settings
of their own, and your organization sets them to the same values. The tiCrypt defaults come from
three places: the backend configuration files in /etc/ticrypt, described in
Service Configuration and
Auth Service; System Settings
in the web application; and the VM controller's
controller.toml.
Where tiCrypt's defaults differ from the Department's values
Of the 51 ODPs in the tables, tiCrypt meets 11 as shipped, 1 needs a setting changed, 7 are met in part, 2 have no setting that reaches the value, and 30 are your organization's to define. The following table describes the setting to change.
| ODP | Setting | Shipped default | Department's value | Set it to |
|---|---|---|---|---|
03.05.12.e.01 | num-factors-required in the ticrypt.auth.mfa section of ticrypt-auth.conf | 0, which turns multi-factor authentication off | "never for passwords where MFA is employed" | 1 or more, with a configured provider |
Two values have no tiCrypt setting behind them.
- Password length (
03.05.07.f): The Department's value requires "a minimum length of 16 characters". tiCrypt's Password Strength setting is a strength score, not a length, and tiCrypt has no minimum-length setting. - Password list updates (
03.05.07.a): The Department's value is "at least quarterly". The lists that tiCrypt checks new passwords against are built into the application and change only with a tiCrypt release.
The setting can change now. CMMC practice IA.L2-3.5.3 already requires multifactor authentication, and Tera Insights requires it for every production deployment, so a production deployment has made this change.
Three backend defaults are set to the Department's values: accounts are locked after 90 days
without a sign-in (time-before-account-old), an account locks after five login challenges in a
row that are not completed (max-challenge-attempts-before-lock), and a server session that is not
used for 15 minutes ends (session-idle-ttl). A deployment that sets one of these keys in its own
configuration files keeps its own value, so check that yours are no looser.
ODP values for requirements tiCrypt implements or shares
Access Control
| ODP | Parameter | Department's value | tiCrypt setting and default | Result |
|---|---|---|---|---|
03.01.01.f.02 | Account Management: inactivity after which an account is disabled | "at most 90 days" | time-before-account-old in the ticrypt.maintenance.account-locker section of ticrypt-maintenance.conf, default 90d. The account locker is on by default and runs every 4h. It does not deactivate Super-admin accounts. | Partly. The default meets the value for every account except Super-admin accounts: 90 days against at most 90 days. Keep time-before-account-old at 90d or less, and review Super-admin accounts by hand. The locker runs every 4h, so an account can stay active for up to that long past the period. Set 89d if your assessor counts the interval. |
03.01.01.g.01 | Account Management: time to notify account managers when an account is no longer required | "24 hours" | No setting. tiCrypt records account changes in the audit log. | Organization. Write the 24 hours into your account procedure. |
03.01.01.g.02 | Account Management: time to notify account managers when a user is terminated or transferred | "24 hours" | No setting. | Organization. |
03.01.01.g.03 | Account Management: time to notify account managers when system usage or need-to-know changes | "24 hours" | No setting. | Organization. |
03.01.01.h.01 | Account Management: inactivity after which users must log out | "at most 24 hours" | session-idle-ttl in the ticrypt.auth.sessions section of ticrypt-auth.conf, default 15 minutes. tiCrypt closes a session that is idle for this long. | Meets. 15 minutes is within 24 hours. |
03.01.01.h.02 | Account Management: circumstances in which users must log out | "the work period ends, for privileged users at a minimum" | No setting. A user ends the session by logging out or with the manual lock, Ctrl+Shift+P. | Organization. State the rule in your rules of behavior. |
03.01.05.b.01 | Least Privilege: security functions that need authorization | "at a minimum and if applicable: establishing system accounts and assigning privileges, configuring access authorizations, configuring settings for events to be audited, establishing vulnerability scanning parameters, establishing intrusion detection parameters, and managing audit information" | No fixed list. Roles and permissions decide who can manage accounts, assign permissions, and change system settings. The set of logged events is fixed, and no role can change it. | Organization. Assign these functions to named roles through user profiles. |
03.01.05.b.02 | Least Privilege: security-relevant information that needs authorization | "at a minimum and if applicable: threat and vulnerability information, filtering rules for routers or firewalls, configuration parameters for security services, cryptographic key management information, security architecture, access control lists, and audit information" | No fixed list. Permissions govern system settings inside tiCrypt. Audit information is reached through tiCrypt Audit accounts, which are separate from tiCrypt accounts. | Organization. Decide who holds each permission and each audit account. |
03.01.05.c | Least Privilege: how often privileges are reviewed | "at least every 12 months" | No setting. | Organization. |
03.01.06.a | Least Privilege, privileged accounts: who may hold a privileged account | "only defined and authorized personnel or administrative roles" | No setting. tiCrypt's privileged roles are Sub-admin, Admin, and Super-admin, and your administrators assign them. | Organization. Name the people who may hold each role. |
03.01.08.a.01 | Unsuccessful Logon Attempts: consecutive invalid attempts allowed | "at most five (5)" | max-challenge-attempts-before-lock in the ticrypt.auth.sessions section of ticrypt-auth.conf, default 5. Five challenges in a row may go uncompleted, and the next request locks the account. | Meets. Five against at most five. Keep max-challenge-attempts-before-lock at 5 or less. |
03.01.08.a.02 | Unsuccessful Logon Attempts: period over which attempts are counted | "period of five (5) minutes" | No setting. tiCrypt counts login challenges requested in a row without one being completed, and the count has no time window. | Meets. The count does not expire, so failures inside any five-minute period are always counted. |
03.01.08.b | Unsuccessful Logon Attempts: action when the limit is exceeded | "[Selection (one or more): lock the account or node for an at least 15-minute time period; lock the account or node until released by an administrator and notify a system administrator]" | Fixed behavior. tiCrypt deactivates the account, with the Deactivation Cause FailedPassword, until an administrator reactivates it, and records the lockout in the audit log. | Partly. The lock until released by an administrator is met. Notifying a system administrator is an alert that you route from tiCrypt Audit. |
03.01.10.a | Device Lock: inactivity before the lock | "initiating a device lock after 'at most 15 minutes' of inactivity and requiring the user to initiate a device lock before leaving the system unattended" | Session Timeout in System Settings (key lockSessionTimeout), default 15 minutes. Users can also lock at once with Ctrl+Shift+P. | Meets. 15 minutes against at most 15 minutes. Keep the setting at 15 or less. The rule that users lock before leaving, and the workstation's own lock, are yours. |
03.01.11 | Session Termination: conditions that end a session | "a specified duration (maximum of 24 hours) of inactivity, misbehavior (end the session due to an attempted policy violation), and maintenance (terminate sessions to prevent issues with an upgrade or service outage)" | Inactivity: session-idle-ttl, default 15 minutes. In the web application the server session ends once the screen has stayed locked for one more Session Timeout. Misbehavior: kill-session in the ticrypt.auth.security.xss section, default true, ends the session when a cross-site scripting attack is detected. Maintenance: no setting. | Partly. Inactivity is met: 15 minutes is within 24 hours. One misbehavior trigger is built in. Ending sessions for maintenance is your upgrade procedure. |
03.01.20.b | Use of External Systems: security requirements for external systems | "Guidance: Organizations establish specific terms and conditions for the use of external systems in accordance with organizational security policies and procedures." The guidance continues in the memorandum. | No setting. An external system reaches tiCrypt only through tiCrypt Connect, and VMs deny outbound traffic by default. | Organization. Write the terms and conditions. |
Audit and Accountability
| ODP | Parameter | Department's value | tiCrypt setting and default | Result |
|---|---|---|---|---|
03.03.01.a | Event Logging: event types to log | "at a minimum and where applicable:" followed by 13 numbered event types. They cover logons and logoffs, security-relevant file and object events, exports to and imports from devices and digital media, user and group management, security policy and configuration changes, administrator access, privilege escalation, access to audit data, restart and shutdown, printing, and application start. | Fixed behavior. tiCrypt records more than 200 event types. Logging is always on and cannot be reduced or turned off (SSP AU-2). | Partly. tiCrypt records its own authentication, file, sharing, permission, group, drive, VM, key, and administrative events. Operating system events, such as restart, printing, application start, and removable media, come from the audit configuration of your hosts, VM images, and workstations. Map the 13 types to both sources in your System Security Plan. |
03.03.01.b | Event Logging: how often the logged event types are reviewed | "at least every 12 months and after any significant incidents or significant changes to risks" | No setting. The product defines tiCrypt's event set. | Organization. Review the event types that your operating systems log. |
03.03.04.a | Response to Audit Logging Process Failures: time to alert | "near real time or as soon as practicable upon discovery" | Fixed behavior. If the logging service stops, the backend services that depend on it stop (SSP AU-5). tiCrypt treats a service as offline after 20s without an answer (timeout in the ticrypt.auth.services section). Key issuance halts at 90% log-storage use. Alert routing has no default. | Organization. tiCrypt detects the failure. Route its alerts to named staff so they arrive in near real time. |
03.03.04.b | Response to Audit Logging Process Failures: additional actions | "document the failure and resolution, troubleshoot, repair/restart the audit logging process, and report as incident if applicable" | No setting. Because the backend stops with the logging service, work resumes only after the logging service is repaired. | Organization. Put these steps in your procedure. |
03.03.05.a | Audit Record Review, Analysis, and Reporting: review frequency | "at least weekly" | No setting. tiCrypt Audit supplies the reports, queries, and alerts (SSP AU-6). | Organization. Assign reviewers and review at least weekly. |
03.03.07.b | Time Stamps: granularity | "a granularity of one (1) second or smaller" | Fixed behavior. Every audit record carries a UTC timestamp with millisecond precision (SSP AU-8). | Meets. One millisecond is smaller than one second. Synchronize the host clocks. |
Configuration Management
| ODP | Parameter | Department's value | tiCrypt setting and default | Result |
|---|---|---|---|---|
03.04.02.a | Configuration Settings: the settings to establish | "Apply the appropriate use of common security configurations available from the National Institute of Standards and Technology's National Checklist Program (NCP) website (https://ncp.nist.gov/repository) and prevent remote devices from simultaneously establishing non-remote connections with organizational systems and communicating via some other unauthorized connection to resources in external networks. Document any deviations from the published standard or source document." | No setting. tiCrypt Connect gives a remote device application tunnels and no network-layer connection to the enclave (SSP SC-7(7)). Whether a workstation may hold other connections at the same time is a workstation setting. | Organization. Apply the checklists to hosts, VM images, and workstations, and document deviations. |
03.04.06.b | Least Functionality: functions, ports, protocols, connections, and services to prohibit or restrict | "Guidance: Where feasible, organizations should limit component functionality to a single function per component." The guidance continues in the memorandum. | allowedPorts in the [tunnel] section of controller.toml, default []: a VM forwards no application port until an administrator lists it. | Organization. Define the list. tiCrypt's defaults deny. |
03.04.06.c | Least Functionality: how often the system is reviewed | "at least every 12 months, when any system functions, ports, protocols, or services changes are made, and after any significant incidents or significant changes to risks" | No setting. | Organization. |
03.04.08.c | Authorized Software: how often the list of authorized software is reviewed | "at least quarterly" | No setting. The software in each VM image and each project's software list are yours. | Organization. Review them at least quarterly. |
Identification and Authentication
| ODP | Parameter | Department's value | tiCrypt setting and default | Result |
|---|---|---|---|---|
03.05.01.b | User Identification and Authentication: circumstances that require re-authentication | "roles, authenticators, or credentials change (including modification of user privilege); when security categories of systems change; when the execution of privileged functions occurs; and after a session termination" | Private Key Timeout in System Settings (key purgeKeyTimeout), default 20 minutes: after it, the next operation that needs the key asks for the password again. A session that has ended requires a full sign-in, including multi-factor authentication unless a cached token is still valid. | Partly. Re-authentication after a session termination is met. No tiCrypt setting covers the other circumstances. Describe in your System Security Plan how each is handled. |
03.05.02 | Device Identification and Authentication: devices to identify and authenticate | "all devices for identification, where feasible for authentication, and document when not feasible" | Fixed behavior. Each endpoint running tiCrypt Connect, and each VM, presents proof tied to its own key material before a connection is accepted (SSP IA-3). | Meets. Every device that connects to tiCrypt is authenticated. Other devices in your boundary are yours to identify. |
03.05.05.c | Identifier Management: period in which an identifier is not reused | "at least ten (10) years" | Fixed behavior. tiCrypt does not reuse user identifiers, even after an account is deleted (SSP IA-4). | Meets. An identifier that is never reused satisfies any period. |
03.05.05.d | Identifier Management: characteristic that identifies each individual's status | "privileged or non-privileged users; contractors, foreign nationals, and/or non-organizational users" | Fixed behavior. Each account shows its role in the Users table: User, Sub-admin, Admin, or Super-admin. tiCrypt has no field for contractor, foreign national, or non-organizational status. | Partly. The role identifies privileged and non-privileged users. Record the other statuses through your own convention, such as team membership. |
03.05.07.a | Password Management: how often the list of commonly used, expected, or compromised passwords is updated | "at least quarterly" | No setting. The password strength check carries its own lists of common passwords. They ship with the application and change only with a tiCrypt release. | No setting. tiCrypt cannot update the lists on a schedule. Record the difference. |
03.05.07.f | Password Management: composition and complexity rules | "1) Must have a minimum length of 16 characters. 2) Contains a string of characters that does not include the user's account name or full name." | Password Strength in System Settings (key requiredPasswordStrength), default 3 on a scale of 0 to 4. The score estimates how many guesses a password withstands. It is not a length. passwordLength is the maximum length, default 64. tiCrypt has no minimum-length setting and does not compare the password with the user's name. | No setting. Require 16 characters and the name rule by policy, and record that tiCrypt does not enforce them. |
03.05.12.e.01 | Authenticator Management: how often authenticators are changed or refreshed | "never for passwords where MFA is employed, at least every five (5) years for hard tokens and identification badges, and at least every three (3) years for all other authenticators" | tiCrypt has no setting that expires key passwords. Multi-factor authentication is set by num-factors-required in the ticrypt.auth.mfa section of ticrypt-auth.conf. The shipped default is 0, which turns it off. Tera Insights requires multi-factor authentication for every production deployment. | Change, if your deployment still has the shipped default. Set num-factors-required to 1 or more, so that "never" applies to key passwords. The intervals for tokens, badges, and other authenticators are yours. |
03.05.12.e.02 | Authenticator Management: events that require a change | "after a relevant security incident or any evidence of compromise or loss" | No setting. A user changes the key password in tiCrypt. With split credentials on, the change stops earlier key files from working (SSP IA-5(1)). | Organization. Put the trigger in your incident procedure. |
Incident Response
| ODP | Parameter | Department's value | tiCrypt setting and default | Result |
|---|---|---|---|---|
03.06.02.b | Incident Monitoring, Reporting, and Response Assistance: time to report a suspected incident internally | "near real time or as soon as practicable upon discovery" | No setting. Audit records and alerts supply the detection data. | Organization. See Incident Response. |
03.06.02.c | Incident Monitoring, Reporting, and Response Assistance: authorities to report to | "all applicable personnel and entities as specified by the contract, and in accordance with any incident response plan notification procedures" | No setting. | Organization. |
Media Protection
| ODP | Parameter | Department's value | tiCrypt setting and default | Result |
|---|---|---|---|---|
03.08.07.a | Media Use: types of system media to restrict or prohibit | "any removable media not managed by or on behalf of the organization" | Default behavior. A VM has no USB passthrough. Removable media reaches a VM only for privileged users, after an administrator configures the hardware and approves it (SSP MP-7). | Meets, inside VMs. Removable media on workstations and hosts is yours to restrict. |
Risk Assessment and Security Assessment
| ODP | Parameter | Department's value | tiCrypt setting and default | Result |
|---|---|---|---|---|
03.11.02.a | Vulnerability Monitoring and Scanning: scan frequency | "at least monthly, or when there are significant incidents or significant changes to risks" | No setting. Your organization scans with its own tools (SSP RA-5). | Organization. |
03.11.02.b | Vulnerability Monitoring and Scanning: time to remediate | "thirty (30) days from date of discovery for high-risk vulnerabilities (including both critical and high); 90 days from date of discovery for moderate-risk vulnerabilities; and 180 days from date of discovery for low-risk vulnerabilities" | No setting. Tera Insights releases fixes for tiCrypt. You install them. | Organization. Install tiCrypt releases and operating system updates inside these times. |
03.11.02.c | Vulnerability Monitoring and Scanning: how recently the list of vulnerabilities to scan for is updated | "no more than 24 hours prior to running the scans" | No setting. | Organization. |
03.12.01 | Security Assessment: assessment frequency | "at least every 12 months, or when there are significant incidents or significant changes to risks" | No setting. | Organization. |
03.12.05.a | Information Exchange: type of agreement | "requirements as described in the contract" | No setting. CUI enters and leaves tiCrypt only through logged paths, which lets you enforce an agreement's terms. | Organization. |
03.12.05.c | Information Exchange: how often agreements are reviewed | "at least every 12 months" | No setting. | Organization. |
System and Communications Protection
| ODP | Parameter | Department's value | tiCrypt setting and default | Result |
|---|---|---|---|---|
03.13.09 | Network Disconnect: inactivity before a network connection is terminated | "no longer than 15 minutes" | idleTimeout in the [tunnel] section of controller.toml, default "15m": a VM tunnel with no active forwarded connection is closed. 0 turns the timeout off, and a VM hardware setup can set its own Idle timeout. The server session is a separate timer: session-idle-ttl, default 15 minutes, closes a session that no request has renewed for that long. The web application renews its session while it is open and ends it once the screen has stayed locked for one more Session Timeout, which is 30 minutes after the last activity at the default of 15. | Partly. A VM tunnel with no open forwarded connection meets the value: 15 minutes against 15 minutes. idleTimeout does not close a tunnel while a forwarded connection is open, whether or not data is moving on it. Keep idleTimeout at "15m" or less, never 0, in every image and hardware setup. The server session default meets it too: keep session-idle-ttl at 15 minutes or less. In the web application a session ends 30 minutes after the last activity at the default Session Timeout of 15. To apply the value there as well, set Session Timeout to 7 minutes or less. |
03.13.10 | Cryptographic Key Establishment and Management: key management requirements | "Guidance: At a minimum, establish a policy and procedure in line with the latest Cryptographic key management guidance" | Key generation and wrapping are fixed, and Cryptographic Modules describes them. min-keys in the ticrypt.auth.key-escrow section, default 3, is the minimum number of escrow groups. | Organization. Write the policy and procedure, and name the escrow groups and their members. |
03.13.11 | Cryptographic Protection: types of cryptography | "FIPS Validated Cryptography (https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Validated-Modules)" | The OpenSSL 3.1.2 FIPS provider, CMVP certificate #4985, performs the cryptography that protects CUI: the key operations on the user's client and everything the VM controller does. FIPSModeOff in controller.toml, default false, keeps the VM controller in FIPS mode. | Meets. Keep FIPSModeOff at false, and build VM images on operating system releases that have their own certificates. See Cryptographic Modules. |
03.13.12.a | Collaborative Computing Devices and Applications: exceptions that allow remote activation | "only as enumerated and justified in the System Security Plan before such remote activation occurs, and only when there are no other options, and the remote activation is operationally critical" | Fixed behavior. tiCrypt does not support collaborative computing devices such as cameras and microphones (SSP SC-15). | Meets. tiCrypt has no exception to list. Workstation devices are yours. |
System and Information Integrity, Acquisition, and Supply Chain
| ODP | Parameter | Department's value | tiCrypt setting and default | Result |
|---|---|---|---|---|
03.14.01.b | Flaw Remediation: time to install security-relevant updates | "thirty (30) days for high-risk flaws (including both critical and high), 90 days for moderate-risk flaws, and 180 days for low-risk flaws" | No setting. Tera Insights publishes signed updates, and VM images are rebuilt from updated base images (SSP SI-2). | Organization. Install tiCrypt releases and rebuild images inside these times. |
03.14.02.c.01 | Malicious Code Protection: frequency of system scans | "at least weekly" | No setting. Inside a VM, tiCrypt has your anti-virus product scan files on import and on every read and write (SSP SI-3). The schedule of full scans is set in that product. | Organization. Schedule a full scan at least weekly. |
03.16.01 | Security Engineering Principles: principles to apply | "Guidance: At a minimum, documentation that provides user and administrator guidance for the implementation and operation of controls." The guidance continues in the memorandum. | Tera Insights publishes this documentation, the System Security Plan, and the Security Whitepaper for tiCrypt (SSP SA-8). | Meets, for tiCrypt. Keep the same kind of documentation for your own components. |
03.17.03.b | Supply Chain Requirements and Processes: security requirements to enforce | "at a minimum, integrate Supply Chain Risk Management (SCRM) into acquisition/procurement policies, provide adequate SCRM resources, define the SCRM control baseline, establish processes to ensure suppliers disclose significant vulnerabilities and significant incidents" | No setting. tiCrypt packages are signed and verified before deployment (SSP SR-11). | Organization. |
ODPs that are entirely your organization's
The remaining 29 ODPs belong to 18 requirements that the control guide assigns to your organization. tiCrypt has no setting for any of them. Write the Department's values into your policies and procedures.
- Literacy training (
03.02.01): Train users "at least every 12 months" (03.02.01.a.01) and after "significant, novel incidents, or significant changes to risks" (03.02.01.a.02). Update the content "at least every 12 months" (03.02.01.b.01) and after "significant, novel incidents, or significant changes to risks" (03.02.01.b.02). - Role-based training (
03.02.02): Train "at least every 12 months" (03.02.02.a.01) and after "significant, novel incidents, or significant changes to risks" (03.02.02.a.02). Update the content "at least every 12 months" (03.02.02.b.01) and after "significant, novel incidents, or significant changes to risks" (03.02.02.b.02). - Baseline configuration (
03.04.01.b): Review and update the baseline "at least every 12 months and after any significant incidents or significant changes occur". - System component inventory (
03.04.10.b): Review and update the inventory "at least quarterly". - Systems for high-risk locations (
03.04.12): Issue "a configuration that has no CUI or FCI stored on the system and prevents the processing, storing, and transmission of CUI and FCI, unless a specific exception is granted in writing by the Contracting Officer" (03.04.12.a). On return, "examine the system for signs of physical tampering and take the appropriate actions, and then either purge and reimage all storage media or destroy the system" (03.04.12.b). - Incident response testing (
03.06.03): Test the capability "at least every 12 months". - Incident response training (
03.06.04): Train within "ten (10) days for privileged users, thirty (30) days for all other roles" (03.06.04.a.01) and "at least every 12 months" after that (03.06.04.a.03). Review the content "at least every 12 months" (03.06.04.b.01) and after "significant, novel incidents, or significant changes to risks" (03.06.04.b.02). - Personnel screening (
03.09.01.b): Rescreen under "an organizational policy requiring rescreening when there is a significant incident, or change in status, related to an individual". - Personnel termination (
03.09.02.a.01): Disable system access within "four (4) hours". For tiCrypt this means deactivating the person's account inside that time. - Facility access list (
03.10.01.c): Review it "at least every 12 months, or when there are significant incidents or significant changes to risks". - Physical access logs (
03.10.02): Review them "at least every 45 days" (03.10.02.b.01) and after "significant, novel incidents, or significant changes to risks" (03.10.02.b.02). - Alternate work sites (
03.10.06.b): Require "adequate security, comparable to organizational security requirements at the primary work site where practical, documented in policy, and covered by training". - Risk assessment (
03.11.01.b): Update it "at least every 12 months, or when there are significant incidents or significant changes to risks". - Policies and procedures (
03.15.01.b): Review and update them "at least every 12 months, or when there are significant incidents or significant changes to risks". - System Security Plan (
03.15.02.b): Review and update it "at least every 12 months, or when there are significant incidents or significant changes to risks". - Rules of behavior (
03.15.03.d): Review and update them "at least every 12 months, or when there are significant incidents or significant changes to risks". - External system services (
03.16.03.a): The value has two parts. Cloud service providers must be "FedRAMP Authorized at the FedRAMP Moderate (or higher) baseline in accordance with the FedRAMP Marketplace", or meet "security requirements established by the government equivalent to the FedRAMP Moderate (or higher) baseline". The memorandum adds that "All other external service providers must meet NIST SP 800-171 R2." See External Service Provider for Tera Insights' own position. - Supply chain risk management plan (
03.17.01.b): Review and update it "at least every 12 months, or when there are significant incidents or significant changes to risks".
Gaps between Revision 2 and Revision 3
A deployment that is ready for a Revision 2 assessment has three kinds of gap to plan for.
- Settings: The setting in Where tiCrypt's defaults differ, and the two password values that no setting reaches.
- Values: The ODP values above that are yours to define. Most are frequencies and time limits that your policies may state differently today.
- New requirements: The 17 requirements that have no CMMC practice behind them. A Revision 2 assessment does not examine them, so your current assessment evidence may not cover them.
The following table describes the 17 new requirements and what to plan for each.
| Requirement | Who implements it | What to plan |
|---|---|---|
03.04.11 Information Location | tiCrypt | tiCrypt keeps each project's data in its own encrypted VMs, drives, and Vault storage on infrastructure you control. Document the storage pools and hosts that hold CUI in your System Security Plan. |
03.05.12 Authenticator Management | tiCrypt | The authenticator is the user's private key, encrypted on the client. Verify each person's identity before you approve a registration, define the procedure for a lost or compromised key file, and apply the two ODP values above. |
03.16.01 Security Engineering Principles | tiCrypt | Cite SSP SA-8 and the Security Whitepaper for tiCrypt. Apply the same principles to the components you add. |
03.11.04 Risk Response | Shared | Tera Insights remediates platform vulnerabilities, and the audit system supplies monitoring evidence. Respond to the findings of assessments, monitoring, and audits across your whole boundary. |
03.12.05 Information Exchange | Shared | CUI enters tiCrypt only through logged paths and leaves only through a logged export approval. Establish the exchange agreements, document each interface, and review the agreements "at least every 12 months". |
03.14.08 Information Management and Retention | Shared | Once an operator has turned the file garbage collector on (it ships disabled and in dry-run), it destroys the key of each deleted file with its chunks after deleted-grace-period, three days by default, and its purge records in the audit trail are the destruction record. Define retention and destruction requirements from your laws, contracts, and agreements. When they are met, delete the project's files and drives, and expire and sanitize the backups. |
03.16.02 Unsupported System Components | Shared | Tera Insights maintains supported releases of tiCrypt. Replace unsupported host operating systems, hypervisors, and hardware in your boundary. |
03.17.03 Supply Chain Requirements and Processes | Shared | tiCrypt packages are signed and verified before deployment. Establish your supply chain risk process and the requirements you place on suppliers. |
03.04.12 System and Component Configuration for High-Risk Areas | Your organization | Define the travel configuration and the return procedure with the two ODP values above. |
03.06.04 Incident Response Training | Your organization | Train incident responders on the schedule in the four ODP values above. |
03.06.05 Incident Response Plan | Your organization | Write, distribute, and protect the plan. Incident Response shows what tiCrypt supplies to it. |
03.10.08 Access Control for Transmission | Your organization | Control physical access to distribution and transmission lines in your facilities. |
03.15.01 Policy and Procedures | Your organization | Write and distribute the policies and procedures for every family, and review them on the ODP schedule. |
03.15.03 Rules of Behavior | Your organization | Write the rules and collect each user's acknowledgement before access. tiCrypt's Terms of Service dialog in System Settings can present the rules at sign-in, and tiCrypt records the date each user accepts them. |
03.16.03 External System Services | Your organization | Hold each external service provider to the ODP value above, and document the shared responsibilities. |
03.17.01 Supply Chain Risk Management Plan | Your organization | Write the plan, review it on the ODP schedule, and protect it from disclosure. |
03.17.02 Acquisition Strategies, Tools, and Methods | Your organization | Build supply chain risk into your acquisition and procurement methods. |
The requirements carried from Revision 2 are also reworded, merged, or split. The NIST SP 800-171 Rev 3 control guide shows the CMMC practices behind each requirement, and the CMMC Level 2 control guide shows where each practice went.