tiCrypt

Assessment Evidence

AdministratorRequires: A tiCrypt Audit account for queries and reports; the Admin or Super-admin role in tiCrypt for Management screens and service configuration

Assessment evidence is the set of artifacts you put in front of a CMMC assessor to show that a practice is implemented: a query result, a screen, a configuration line, or a document. This page lists the artifact tiCrypt can produce for each of the 85 CMMC Level 2 practices that tiCrypt implements or shares, and names the 25 practices whose evidence comes from your organization's own program. Assessment evidence is not the System Security Plan. The plan states how a requirement is met, and the evidence shows it operating.

The assessor decides what is sufficient. This page lists the evidence tiCrypt can produce. It is not a guarantee of a finding.

Why evidence is listed by practice

An assessor works one practice at a time. The CMMC Assessment Guide for Level 2 gives each practice a set of assessment objectives, and for each objective the assessor examines an artifact, interviews a person, or tests a mechanism. A table organized by practice lets you hand over the artifact when the practice comes up.

The plan and the control guide stop short of the artifact. The System Security Plan says how tiCrypt implements a control, and the CMMC Level 2 control guide says who is responsible for each practice. Neither tells the administrator which query to run or which screen to open on the day.

Evidence gathered in advance shows operation, not only capability. Run the queries and open the screens before the assessment, over a period that includes real activity. A query that returns months of records shows a control in use. A query run for the first time in front of the assessor shows only that it exists.

Before you begin

• Audit account: You have a tiCrypt Audit account, and the audit service is receiving logs. See Monitoring & Audit.
• Management role: You hold the Admin role in tiCrypt for the Management screens. System Settings History, System Services, and Audit Logs require the Super-admin role.
• Configuration files: You can read the configuration files on the servers, or you can open them through System Services.
• Your own plan: You have adapted the System Security Plan into your own plan, so that each card you cite describes your deployment.

Run a saved query and export the result

This procedure describes how to run one of the saved queries named in the tables below and export its result.

1. In tiCrypt Audit, open the Queries tab. When no query is active, the tab shows the query selector.
2. Type the query's title in the search bar. You can also narrow the list with the category tags in the filter section, such as Compliance.
3. Click the query to select it.
4. In the Parameters tab, fill in the parameters: the date range, the Success choice (Success, Error, or Both), and any user, team, or project, which you pick from an autocomplete field.
5. Click Run.
6. Review the result. Click a column header to sort, and use the search bar to filter.
7. Click Export, and select Export all data, Export selected data, or Export visible data.

Result: tiCrypt Audit saves an Excel workbook named after the query, with formatting and column statistics.

For more information, see Queries.

Run and export a report

This procedure describes how to run a report, which combines several queries over one period.

1. In tiCrypt Audit, open the Reports tab and select a report from the dropdown.
2. Set the Start date and the End date.
3. If the report is scoped to a user, a team, or a project, select it in the autocomplete field.
4. Click Run. Each query in the report shows Done when it has completed.
5. Click Export.

Result: tiCrypt Audit saves an Excel workbook that holds the result of every query in the report, with formatting and summary statistics.

For more information, see Reports.

How to read the tables

Each family below has one table, with one row for each practice. The middle column condenses the assessment objectives of the CMMC Assessment Guide for Level 2. The last column lists the evidence, each item labeled by its kind. A practice marked Shared also needs evidence from your own program, which the row names.

The following table describes the kinds of evidence.

Label	What it is	How to show it
Query	A saved query in tiCrypt Audit, given by its title, followed by the folder of its definition file in the tiCrypt Audit query library.	Find it by title in the Queries tab, run it, and export the result.
Report	A saved report in tiCrypt Audit, from the reports folder. Three reports are named "Overview": one for the whole system, one for a user, and one for a project.	Run it in the Reports tab and export it.
Screen	A page of tiCrypt or of tiCrypt Audit, linked to its documentation.	Show it live, or keep a dated screenshot.
Configuration	A key, the file it lives in, and its default.	Show the line in the file. For a backend service, Management > Miscellaneous > System Services > View config shows the configuration the service loaded and downloads it.
Document	A card of the System Security Plan, or a documentation page.	Cite the matching section of your own plan.
Next release	A query that is coming in the next Audit release. It is not in the released product yet.	Use the other items in the row until you have upgraded.

The following table describes the configuration files the tables refer to.

File	Location	Holds	Reference
ticrypt-auth.conf	/etc/ticrypt/ on the backend	Sessions, lockout, MFA, split credentials, key escrow	Auth Service
ticrypt-maintenance.conf	/etc/ticrypt/ on the backend	Account locker and garbage collectors	Service Configuration
ticrypt-logger.conf	/etc/ticrypt/ on the backend	Log drivers	Service Configuration
ticrypt-proxy.conf	/etc/ticrypt/ on the backend	The interface and ports of the VM tunnels	Service Configuration
ticrypt-rest.conf	/etc/ticrypt/ on the backend	Vault storage path, request validation, HTTP timeouts	Service Configuration
ticrypt-file-manager.conf	/etc/ticrypt/ on the backend	Chunk size and storage path	Service Configuration
ticrypt-vmhost.conf	On each VM host	The host's networks and SSH access	Service Configuration
controller.toml	In each VM image, at /etc/ticrypt/controller.toml on Linux	FIPS mode, tunnels, terminal, SFTP, antivirus, administrator access	Controller Configuration
log-streamer.toml	/etc/tiaudit/ on the audit server	Alert drivers and geolocation of tiCrypt Audit	Configuration and Setup
ticrypt.yml	The installer's working directory	Firewall type and networks	Backend Installation Guide
Deployment file keys	The deployment file, overridden by the values saved in System Settings	Login notices, timeouts, password strength	System Settings

▲System Settings shows only the values saved there

A setting that was never saved in System Settings shows an empty field or a preselected choice, and takes its value from the deployment file or the built-in default. For such a setting, show the key in the deployment file, or save the value in System Settings so that the screen and System Settings History both record it.

Access Control (AC)

The following table describes the evidence for the 17 Access Control practices that tiCrypt implements or shares.

Practice	What the assessor looks for	Evidence
AC.L2-3.1.1 Authorized Access Control	Authorized users, processes, and devices are identified, and access is limited to them.	Query: "Users List" (queries) lists every account with its role and its creation and deletion dates. Screen: The Users table in User Management shows the Role and Status of each account. Next release: "Access Attempts by Removed Users" (queries/user). Document: SSP cards AC-2 and AC-3.
AC.L2-3.1.2 Transaction & Function Control	Permitted transactions and functions are defined, and access is limited to them.	Screen: User Profiles shows the role and permissions of each profile, and Permissions describes every permission. Query: "List user permissions" (queries/user) lists one user's permissions as of the end date. Document: SSP cards AC-2 and AC-3.
AC.L2-3.1.3 Control CUI Flow	Flow control policies, sources and destinations, and authorizations for CUI are defined and enforced.	Query: "Project Tag Compliance" (queries) lists each time a file or drive was tagged with a project or untagged. "Data Transfer Log" (queries/user) lists each file read from or written to the Vault, with the user. Screen: External SFTP Servers lists each approved export destination with its allowlist of users and teams. Next release: "File Sharing Log" (queries) and "External SFTP Access Log" (queries). Document: SSP card AC-4.
AC.L2-3.1.4 Separation of Duties	Duties that need separation are defined and held by separate individuals.	Screen: The Role column of the Users table in User Management shows who holds each administrative tier. User Roles states where the authority of each tier stops. Query: "Users List" (queries) gives the role of every account from the audit record. Next release: "Privileged Accounts" (queries). Document: SSP card AC-5.
AC.L2-3.1.5 Least Privilege	Privileged accounts and security functions are identified and authorized by least privilege.	Query: "Users List" (queries) shows the role and the number of permissions of each account. "Permission Change Audit" (queries/actions) lists each change to accounts, group membership, drive keys, and project access, with who made it. Screen: User Profiles. Next release: "Privileged Accounts" (queries). Document: SSP card AC-6.
AC.L2-3.1.6 Non-Privileged Account Use	Nonsecurity functions are identified, and users use non-privileged accounts or roles for them.	Screen: System Settings > User > Admin Session Downgrade lets administrators sign in with a reduced profile (key sessionDowngrade, disabled by default). Query: "Session Downgrade" (queries) lists each downgraded session with the user, the role, and the profile. Document: SSP card AC-6(2).
AC.L2-3.1.7 Privileged Functions	Privileged functions are defined, non-privileged users cannot run them, and their execution is logged.	Query: "Permission Change Audit" (queries/actions) and "User account actions (extra)" (queries/actions) list role, permission, and state changes with the administrator who made each. Configuration: default-permissions in the users section of ticrypt-auth.conf, default ["@group", "@file", "@directory", "@session"], sets what a new account can do. adminAccess in the [users] section of controller.toml, default false, means no user has administrator or sudo rights inside a VM. Next release: "Privileged Actions Audit" (queries/actions). Document: SSP card AC-6(9), AC-6(10).
AC.L2-3.1.8 Unsuccessful Logon Attempts	A means of limiting unsuccessful logon attempts is defined and implemented.	Configuration: max-challenge-attempts-before-lock in the sessions section of ticrypt-auth.conf, default 5. An account that requests more than that many login challenges in a row without completing one is locked. Query: "Failed Login Attempts" (queries/user) lists refused session requests and account lockouts. "User account disabled" (queries/user) lists each lockout. Screen: The Deactivation Cause column of the Users table shows FailedPassword for an account locked this way. Next release: "Failed Login Summary" (queries/user). Document: SSP card AC-7.
AC.L2-3.1.9 Privacy & Security Notices	Required privacy and security notices are identified and displayed.	Screen: System Settings > Notices > CUI Disclosure (key cuiBanner, off by default) and Terms of Service (key termsOfService), and Login > Login Message (key loginBanner, off by default). Sign-In Notices shows what users see. Screen: The TOS Accepted column of the Users table shows when each user accepted the terms. Document: SSP card AC-8.
AC.L2-3.1.10 Session Lock	An inactivity period is defined, the session locks after it, and the display is hidden.	Screen: System Settings > Timeouts > Session Timeout (key lockSessionTimeout, default 15 minutes). Session Lock describes the lock screen that covers the page. Screen: System Settings History shows the value in force and who set it. Document: SSP card AC-11.
AC.L2-3.1.11 Session Termination	Conditions that end a session are defined, and sessions end automatically when they occur.	Configuration: session-idle-ttl in the sessions section of ticrypt-auth.conf, default 15 minutes, closes an inactive server session. Screen: Session Timeout ends the server session when the screen stays locked for a second period, and logs the user out 60 minutes after the lock. Private Key Timeout (key purgeKeyTimeout, default 20 minutes) clears the key from memory. Document: SSP card AC-12.
AC.L2-3.1.12 Control Remote Access	Remote access is permitted by type, controlled, and monitored.	Query: "List user login info" (queries/user) lists each sign-in with its time, source address, and session expiry. "Users Launch Application" (queries) lists each connection to a VM with the user and the source and destination addresses. Screen: Running VMs lists the VMs in use, each with its owner and host. Document: SSP card AC-17.
AC.L2-3.1.13 Remote Access Confidentiality	Cryptographic mechanisms for remote access sessions are identified and implemented.	Configuration: FIPSModeOff at the top level of controller.toml, default false, keeps the VM Controller in FIPS mode. Screen: The FIPS enabled badge in the Virtual Machines table marks each VM whose controller runs in FIPS mode. Document: SSP card AC-17(2), and Cryptographic Modules for the validated module.
AC.L2-3.1.14 Remote Access Routing	Managed access control points are identified, and remote access is routed through them.	Configuration: interface and ports in the ticrypt.proxy section of ticrypt-proxy.conf set where the proxy listens. The shipped file has an empty ports list, so the value in your file is the range your deployment opens. Document: Network shows that the backend is the only host that forwards guest traffic. SSP card AC-17(3).
AC.L2-3.1.15 Privileged Remote Access	Privileged commands and security-relevant information reachable remotely are identified and authorized.	Screen: Permissions lists, by category, the administrative permissions that authorize each privileged action. Configuration: enableManagerSudo in the [debug] section of controller.toml, default false. SSH_ALLOWED_NETWORK in ticrypt-vmhost.conf limits SSH to each VM host. Its default is $TICRYPT_BACKEND_IP/32 in files shipped from backend 3.16.2. Query: "Permission Change Audit" (queries/actions). Next release: "Privileged Actions Audit" (queries/actions). Document: SSP card AC-17(4).
AC.L2-3.1.20 External Connections	Connections to and use of external systems are identified, verified, and limited.	Screen: Global Licensing Servers and VM Access Rules together list every server a VM can reach. External SFTP Servers lists every server users can push Vault files to. Next release: "External SFTP Access Log" (queries). Document: SSP card AC-20.
AC.L2-3.1.22 Control Public Information. Shared.	People authorized to post publicly are identified, and public content is reviewed for CUI.	Screen: System Settings > Login > Login Message and Login Logo are the content your administrators place on the login page, which anyone who opens it can see. Show that neither contains CUI. Document: SSP card AC-22. Your organization adds its procedure for posting to every other public system.

Audit and Accountability (AU)

The following table describes the evidence for the nine Audit and Accountability practices. tiCrypt Audit has no retention setting to show for AU.L2-3.3.1: it never deletes logs, so the full history of the system is available from the day it was installed.

Practice	What the assessor looks for	Evidence
AU.L2-3.3.1 System Auditing	Event types and record content are specified, records are created with that content, and retention is defined and met.	Query: "List user actions performed" (queries/user) shows the event types recorded for one user. "By Month statistics" (queries), run from the installation date, shows activity in every month since. Report: "Overview" (reports), for the whole system. Configuration: The main-file-logger driver in the drivers section of ticrypt-logger.conf, with main = true and immutable = true. Document: SSP cards AU-2, AU-3, AU-3(1), and AU-12.
AU.L2-3.3.2 User Accountability	Record content that traces each action to one user is defined and present.	Query: "User Access Audit" (queries/user) gives one user's timeline of file reads and writes, drive key retrievals, drive attachments, and VM connections. Report: "Overview" (reports), for one user. Document: SSP card AU-3.
AU.L2-3.3.3 Event Review. Shared.	A review process for logged event types is defined, followed, and leads to updates.	Screen: The Last Run column of the query list in the Queries tab shows when each query was last run. Document: SSP card AU-2(3). Your organization adds its review schedule and the record of each review.
AU.L2-3.3.4 Audit Failure Alerting	Who is alerted, and for which failures, is defined, and they are alerted.	Screen: The Alerts tab, filtered by alert type to Hash Alert, shows each break in the hash chain. Configuration: The [drivers] section of log-streamer.toml names where alerts go: the to list of an email driver, or the url of a Splunk driver. Document: SSP card AU-5 describes how the backend stops when logging stops, and the 90 percent storage threshold.
AU.L2-3.3.5 Audit Correlation	Review, analysis, and reporting processes are defined and correlated.	Report: "Overview" (reports), for the whole system, combines user, team, group, and project statistics with account and membership changes over one period. Screen: The Objects tab described in Queries opens any user, file, drive, or VM named in a result. Configuration: An alert driver in the [drivers] section of log-streamer.toml sends tiCrypt's alerts to the external system where you correlate them, typically one such as Splunk or Sumo Logic. Document: SSP card AU-6, and SIEM Integration. Your organization adds the second source: the monitoring tools it runs on the host servers and inside VMs, which report to its monitoring proxy inside the enclave, and the correlation of their events with tiCrypt's alerts in that system.
AU.L2-3.3.6 Reduction & Reporting	Audit reduction and report generation are available on demand.	Screen: In the Queries tab, filter a result with the search bar and click Export. In the Reports tab, run "Overview", "Security Levels", or "Team Resource Usage" (reports) and click Export. Document: SSP card AU-7.
AU.L2-3.3.7 Authoritative Time Source	System clocks generate the time stamps and are synchronized with a specified authoritative source.	Query: Any result with a Time column, such as "List user login info" (queries/user), shows the time stamp on each record. Document: SSP card AU-8. Your organization adds the NTP configuration of the backend, the VM hosts, and the audit server.
AU.L2-3.3.8 Audit Protection	Audit information and tools are protected from unauthorized access, modification, and deletion.	Query: "Check Hash" (queries) returns the hash stored for a sequence number of the SHA-512 hash chain. Screen: The Alerts tab, with no Hash Alert in the period. Management > Users in tiCrypt Audit lists who can sign in to it. Configuration: In ticrypt-logger.conf, immutable = true on the main-file-logger driver, and the tcp-logger driver with port = 25000, which pushes the log one way to the audit server. Document: SSP card AU-9.
AU.L2-3.3.9 Audit Management	A subset of privileged users who manage audit logging is defined and enforced.	Screen: Management > Users in tiCrypt Audit shows the role of each account, User or Admin. Only Admin accounts reach SQL and Management. Screen: Audit Logs in tiCrypt is shown to Super-admins only. Document: SSP card AU-9(4).

Configuration Management (CM)

The following table describes the evidence for the eight Configuration Management practices that tiCrypt implements.

Practice	What the assessor looks for	Evidence
CM.L2-3.4.2 Security Configuration Enforcement	Security configuration settings are established in the baseline and enforced.	Screen: System Services > View config shows the configuration each backend service loaded, and downloads it as a .conf file. System Settings lists each deployment-wide setting with its key and default. Document: SSP card CM-6, and the Interactive Configuration Reference for every backend parameter and its default.
CM.L2-3.4.3 System Change Management	Changes are tracked, reviewed, approved or disapproved, and logged.	Screen: System Settings History lists each saved change with the user, the time, the old value, and the new value, and exports to CSV. Query: "VM Config Lifecycle Report" (queries) lists each VM configuration created, updated, deleted, run, and killed, with the user. Document: SSP card CM-3, and the release notes for the changes in each version you install. Your organization adds its approval records.
CM.L2-3.4.4 Security Impact Analysis	The security impact of a change is analyzed before it is made.	Document: The release notes list what is new, changed, and fixed in each version, which is the input to your analysis before an upgrade. SSP card CM-4. Screen: System Settings History shows the current value of a setting before you change it. Your organization adds the record of each analysis.
CM.L2-3.4.5 Access Restrictions for Change	Physical and logical access restrictions for changes are defined, documented, approved, and enforced.	Screen: Permissions shows that Change system settings is a separate permission. System Settings History is shown to Super-admins only. Query: "Users List" (queries) shows who holds the Admin and Super-admin roles. Next release: "Privileged Accounts" (queries). Document: SSP card CM-5.
CM.L2-3.4.6 Least Functionality	Essential capabilities are defined, and the system provides only those.	Configuration: allowedPorts in the [tunnel] section of controller.toml, default [], so no application port of a VM is reachable until you list it. network.firewall in ticrypt.yml, set to "firewalld" in the example file, makes the installer configure a firewall on the backend that blocks all other inbound traffic. Screen: VM Images lists the images that VMs boot from. Document: SSP card CM-7, and the Pre-Installation Checklist for the ports a deployment opens.
CM.L2-3.4.7 Nonessential Functionality	Essential programs, functions, ports, protocols, and services are defined, and the rest are restricted.	Configuration: In controller.toml, sftpEnabled in [tunnel], default false, allowedPorts in [tunnel], default [], and enabled in [terminal], default true. Screen: VM Hardware Setups shows the terminal, tunnel, port, and SFTP settings of each setup. Global Licensing Servers lists the only outside servers that every VM can reach. Document: SSP card CM-7(2).
CM.L2-3.4.8 Application Execution Policy	An allow or deny policy for software is specified and implemented.	Screen: VM Images is the list of images, and so of the software installed for every user of a VM. Manage Access in VM Hardware Setups shows the teams and users allowed to use each setup. Configuration: adminAccess in the [users] section of controller.toml, default false, keeps users from installing software for the whole VM. Document: SSP cards CM-7(4) and CM-7(5). These support the policy and are not an allow list by themselves: a user can still run software in their own account, such as Python packages installed into a virtual environment. Your organization adds its execution policy and the mechanism in the image that enforces it.
CM.L2-3.4.9 User-Installed Software	A policy for user-installed software is established, enforced, and monitored.	Configuration: In controller.toml, adminAccess in [users], default false, so no user, including the owner, has administrator or sudo rights in a VM, and enableManagerSudo in [debug], default false. Document: SSP card CM-11. The Virtual Machines table page states that each VM boots from a clean image that resets on every restart.

Identification and Authentication (IA)

The following table describes the evidence for the 11 Identification and Authentication practices. MFA and split credentials are required for every production deployment. The shipped defaults of their keys are off, so the lines in your files are the evidence.

Practice	What the assessor looks for	Evidence
IA.L2-3.5.1 Identification	Users, processes, and devices are identified.	Query: "Users List" (queries) lists each account with its user ID and email. Screen: The LoginID and ID columns of the Users table in User Management. The VM ID, Owner, and Host Server columns of Running VMs. Document: SSP card IA-2.
IA.L2-3.5.2 Authentication	Each user, process, and device is authenticated before access.	Query: "List user login info" (queries/user) lists successful or failed sign-ins, selected with the Success parameter. "List user actions performed" (queries/user) shows the challenge and session events of one user. Document: SSP cards IA-2 and IA-3, and Private Keys for the key file a user signs in with.
IA.L2-3.5.3 Multifactor Authentication	Privileged accounts are identified, and multifactor authentication is used for privileged and network access.	Configuration: num-factors-required in the mfa section of ticrypt-auth.conf. The shipped default is 0, which disables MFA. A production deployment sets it to 1 or more and names the factors in enabled-factors. Query: "List user actions received" (queries/user) shows each MFA token issued to one user. Next release: "MFA Coverage by User" (queries/user). Document: SSP card IA-2(1), IA-2(2), IA-2(3), and MFA Setup.
IA.L2-3.5.4 Replay-Resistant Authentication	Authentication for network access resists replay.	Configuration: challenge-ttl in the sessions section of ticrypt-auth.conf, default 10 minutes, limits how long a login challenge is valid. Query: "List user actions performed" (queries/user) shows a separate challenge event for each sign-in of one user. Document: SSP card IA-2(8).
IA.L2-3.5.5 Identifier Reuse	A period in which identifiers cannot be reused is defined and enforced.	Query: "Users List" (queries) gives each account its own user ID, with its creation date and its deletion date. Screen: Deleted Users lists deleted accounts. Document: SSP card IA-4.
IA.L2-3.5.6 Identifier Handling	An inactivity period is defined, and identifiers are disabled after it.	Configuration: time-before-account-old in the account-locker section of ticrypt-maintenance.conf, default 90d, with enabled, default true. The account locker does not deactivate Super-admin accounts, so your organization adds its own review of those. Query: "Inactive User Report" (queries/user) gives the number of sign-ins of each active user in the period. Zero means inactive. Screen: The Last Login column of the Users table, and Timeout in the Deactivation Cause column for an account the locker deactivated. Document: SSP card IA-4.
IA.L2-3.5.7 Password Complexity	Complexity and change-of-character rules are defined and enforced for new passwords.	Screen: System Settings > User > Password Strength (key requiredPasswordStrength, default 3, shown as Passwords must be strong). Document: SSP card IA-5(1).
IA.L2-3.5.8 Password Reuse. Shared.	The number of generations before a password can be reused is specified and enforced.	Configuration: enabled in the server-assisted-auth section of ticrypt-auth.conf. The shipped default is false. A production deployment sets it to true, which turns split credentials on. Query: "User account actions (extra)" (queries/actions) lists each password change. Screen: The Password Changed column of the Users table. Document: SSP card IA-5(1). The password never reaches the server, so tiCrypt cannot compare a new password with earlier ones. Your organization adds the password policy that sets the number of generations and the record that it is enforced.
IA.L2-3.5.9 Temporary Passwords	A temporary password must be changed to a permanent one at once.	Screen: The Status column of the Users table shows New, not activated for a person who has registered with their own password and awaits activation. tiCrypt issues no temporary passwords. Configuration: allow-self-registration in the users section of ticrypt-auth.conf, default on. Accounts registered this way stay inactive until an administrator activates them. Document: SSP card IA-5(1).
IA.L2-3.5.10 Cryptographically-Protected Passwords	Passwords are cryptographically protected in storage and in transit.	Configuration: enabled in the server-assisted-auth section of ticrypt-auth.conf, as for IA.L2-3.5.8. Screen: System Settings > Caching > Private Key Caching (key storeEncryptedPrivateKey, default "no"). Document: Private Keys describes how the password encrypts the key file. SSP card IA-5(1).
IA.L2-3.5.11 Obscure Feedback	Authentication information is obscured as it is entered.	Screen: The login page and the lock screen, shown live while a password is typed. Document: SSP card IA-6.

Incident Response (IR)

The following table describes the evidence for the one Incident Response practice that is shared. For the two that are yours, and for what tiCrypt contributes to them, see Incident Response.

Practice	What the assessor looks for	Evidence
IR.L2-3.6.2 Incident Reporting. Shared.	Incidents are tracked and documented, and the right officials and authorities are identified and notified.	Screen: The Alerts tab lists each alert with its severity, its time, and the user involved. Query: "User Access Audit" (queries/user), and the other queries in Determine what was affected. Document: SSP card IR-6. Your organization adds its incident log and the reports it filed.

Maintenance (MA)

The following table describes the evidence for the two Maintenance practices that tiCrypt implements.

Practice	What the assessor looks for	Evidence
MA.L2-3.7.2 System Maintenance Control	Maintenance tools, techniques, mechanisms, and personnel are controlled.	Screen: System Services is where a Super-admin views service logs and configuration and restarts a service. Configuration: SSH_ALLOWED_NETWORK in ticrypt-vmhost.conf limits SSH to each VM host. Next release: "Privileged Actions Audit" (queries/actions), which includes service restarts. Document: SSP card MA-3.
MA.L2-3.7.5 Nonlocal Maintenance	Nonlocal maintenance sessions use multifactor authentication and end when the work is complete.	Configuration: num-factors-required in the mfa section of ticrypt-auth.conf, as for IA.L2-3.5.3. session-idle-ttl in the sessions section, default 15 minutes. Query: "List user login info" (queries/user) shows each administrator's sign-ins and when each session expires. Document: SSP card MA-4, and Tera Insights as a Service Provider for how vendor support works without access.

Media Protection (MP)

The following table describes the evidence for the nine Media Protection practices. Five are shared, because tiCrypt protects the content and your organization protects the physical media.

Practice	What the assessor looks for	Evidence
MP.L2-3.8.1 Media Protection. Shared.	Paper and digital media with CUI are physically controlled and securely stored.	Configuration: path in the ticrypt.rest.storage section of ticrypt-rest.conf names the directory that holds the encrypted file chunks. LIBVIRT_STORAGE in ticrypt-vmhost.conf, default /storage, names the Libvirt storage directory of a VM host. These identify the media to control. Document: SSP card MP-4. Your organization adds the physical controls on those media.
MP.L2-3.8.2 Media Access. Shared.	Access to CUI on media is limited to authorized users.	Query: "Drive Key Access Log" (queries) lists each drive key granted or revoked. "List file actions" (queries) lists each key added to one file. Screen: The Shares column of the Drives table shows how many more users hold a key to each drive. Document: SSP card MP-2. Your organization adds its control of physical access to the media.
MP.L2-3.8.3 Media Disposal. Shared.	Media with CUI is sanitized or destroyed before disposal or reuse.	Query: "Files Deleted" (queries) and "Drives Deleted" (queries) list each deletion with its time and the user. Configuration: deleted-grace-period in the garbage-collector section of ticrypt-maintenance.conf, default 3d, is how long a collected file waits before its keys and chunks are removed. Next release: "File Deletions by User" (queries). Document: SSP card MP-6. Your organization adds the sanitization records for physical media.
MP.L2-3.8.4 Media Markings. Shared.	Media with CUI carries CUI markings and distribution limitations.	Screen: System Settings > Notices > CUI Disclosure shows the banner "THIS SYSTEM CONTAINS CUI" across the app. Query: "Project Tag Compliance" (queries) lists each project tag applied to a file or a drive. Document: How Project Tags Work, and SSP card MP-3. Your organization adds the markings on physical media.
MP.L2-3.8.5 Media Accountability. Shared.	Access to media is controlled, and accountability is kept during transport.	Query: "Data Transfer Log" (queries/user) lists each file read from or written to the Vault, with the user and the time. "User Downloads and Previews" (queries/user) lists the files one user fetched. Document: SSP card MP-5. Your organization adds the custody records for physical media.
MP.L2-3.8.6 Portable Storage Encryption	CUI on digital media is protected in transport by cryptography or physical safeguards.	Configuration: chunk-size in the ticrypt.filemanager section of ticrypt-file-manager.conf, default 8 MiB, is the size of the encrypted chunks that any copy of the storage contains. Document: SSP card MP-5(4), and Cryptographic Modules.
MP.L2-3.8.7 Removeable Media	The use of removable media on system components is controlled.	Screen: Devices lists every PCI and USB device registered for use by VMs. VM Hardware Setups shows the devices each setup gives a VM. Document: SSP card MP-7.
MP.L2-3.8.8 Shared Media	Portable storage devices with no identifiable owner are prohibited.	Screen: The Owner column of the Drives table names the owner of every drive. Query: "List ALL Drive Actions" (queries/actions) lists each drive creation and each change of owner. Document: SSP card MP-7(1).
MP.L2-3.8.9 Protect Backups	The confidentiality of backup CUI is protected where it is stored.	Configuration: path in the ticrypt.rest.storage section of ticrypt-rest.conf names what a backup of the Vault copies, which is ciphertext. Screen: System Settings > Drives > Track Drive Backup (key allowAuxiliaryDriveBackup, default false) adds a Backup column to the Drives table that records which drives may be backed up. Document: SSP card CP-9(8). Your organization adds the list of backup targets, which stay in scope.

Risk Assessment (RA)

The following table describes the evidence for the two Risk Assessment practices that tiCrypt implements or shares.

Practice	What the assessor looks for	Evidence
RA.L2-3.11.2 Vulnerability Scan. Shared.	A scan frequency is defined, and systems and applications are scanned on it and when new vulnerabilities appear.	Screen: The login page shows the frontend, backend, and Connect versions in use, as described in Check Which Versions You Are Running. A scan finding is matched against these. Document: SSP card RA-5. Your organization adds its scan reports for hosts, network devices, and other software.
RA.L2-3.11.3 Vulnerability Remediation	Vulnerabilities are identified and remediated in line with risk assessments.	Document: The release notes list the fixes in each version. SSP card RA-7. Screen: The versions on the login page show which release you run. Your organization adds its upgrade records.

Security Assessment (CA)

The following table describes the evidence for the three Security Assessment practices that tiCrypt implements or shares.

Practice	What the assessor looks for	Evidence
CA.L2-3.12.1 Security Control Assessment. Shared.	An assessment frequency is defined, and controls are assessed on it.	Document: The System Security Plan, the CMMC Level 2 control guide, and this page. SSP card CA-2. Your organization adds its assessment schedule and results.
CA.L2-3.12.2 Operational Plan of Action. Shared.	Deficiencies are identified, and a plan of action is developed and carried out.	Document: SSP card CA-5. Your organization adds its plan of action and milestones.
CA.L2-3.12.3 Security Control Monitoring	Controls are monitored on an ongoing basis.	Screen: The Alerts tab, and the Last Run column of the query list in the Queries tab as a trace of each review. Report: "Overview" (reports), for the whole system, run for each review period. Configuration: The alert drivers in the [drivers] section of log-streamer.toml. Document: SSP card CA-7.

System and Communications Protection (SC)

The following table describes the evidence for the 16 System and Communications Protection practices.

Practice	What the assessor looks for	Evidence
SC.L2-3.13.1 Boundary Protection	External and key internal boundaries are defined, and communications are monitored, controlled, and protected at them.	Document: Network shows the three guest networks and the backend as the single host that forwards and filters guest traffic. SSP card SC-7. The Scoping Guide gives the boundary diagram. Configuration: network.firewall in ticrypt.yml, ports in ticrypt-proxy.conf, and SSH_ALLOWED_NETWORK in ticrypt-vmhost.conf. Query: "Users Launch Application" (queries) lists each connection through the tiCrypt proxy with its source and destination addresses.
SC.L2-3.13.2 Security Engineering	Secure architectural designs, development techniques, and engineering principles are identified and employed.	Document: SSP card SA-8, the Security Whitepaper, and Architecture.
SC.L2-3.13.3 Role Separation	User functionality and system management functionality are identified and separated.	Screen: Running VMs shows that Management actions work on a machine and not on the data inside it. User Roles states that no role can read user data. Document: SSP card SC-2.
SC.L2-3.13.4 Shared Resource Control	Unauthorized and unintended information transfer through shared resources is prevented.	Configuration: sftpEnabled in the [tunnel] section of controller.toml, default false. When it is on, the SFTP path into a VM accepts uploads only. Document: SSP card SC-4. The Virtual Machines table page states that each VM boots from a clean image that resets on every restart.
SC.L2-3.13.5 Public-Access System Separation	Publicly accessible components are identified and sit on subnetworks separated from internal networks.	Document: Network lists the secure, service, and data-in networks with their VLANs, and the Pre-Installation Checklist lists the VLANs you reserve. SSP card SC-7. Your organization adds the switch and firewall configuration that separates them.
SC.L2-3.13.6 Network Communication by Exception	Network traffic is denied by default and allowed by exception.	Screen: Global Licensing Servers and VM Access Rules are the complete list of outbound exceptions for VMs. The VM Access Rules table shows each rule with its VM configurations, server, ports, protocol, and the Super-admin who created it. The rule that lets VMs reach your monitoring proxy is one of these rows. Configuration: allowedPorts in the [tunnel] section of controller.toml, default [], and network.firewall in ticrypt.yml. Document: SSP card SC-7(5).
SC.L2-3.13.7 Split Tunneling. Shared.	Remote devices cannot hold a connection to the system and another to an external network at the same time.	Configuration: allowedPorts in the [tunnel] section of controller.toml lists the only VM ports a remote device can reach, each through its own tunnel. Document: SSP card SC-7(7). Your organization adds the endpoint setting that governs the other connections of the device.
SC.L2-3.13.8 Data in Transit	Cryptographic mechanisms or physical safeguards protect CUI in transmission.	Configuration: ssl_protocols TLSv1.2 TLSv1.3; in /etc/nginx/conf.d/audit.ticrypt.conf, the NGINX configuration of tiCrypt Audit shown in Configuration and Setup. FIPSModeOff in controller.toml, default false. Document: SSP cards SC-8 and SC-8(1), Nginx TLS Configuration, and Cryptographic Modules.
SC.L2-3.13.9 Connections Termination	An inactivity period is defined, and connections end with the session or after that period.	Configuration: idleTimeout in the [tunnel] section of controller.toml, default "15m", ends idle tunnels. proxy-ttl in ticrypt-proxy.conf, default 5 minutes. idle-timeout in the akka.http.server section of ticrypt-rest.conf, shipped as 25 minutes. session-idle-ttl in ticrypt-auth.conf, default 15 minutes. Document: SSP card SC-10.
SC.L2-3.13.10 Key Management	Cryptographic keys are established and managed wherever cryptography is used.	Screen: Escrow Groups and Escrow Users show who can take part in key recovery. The Last Escrow and Can Escrow columns of the Users table show the state of each account. Configuration: min-keys in the key-escrow section of ticrypt-auth.conf, default 3, is the number of escrow groups required before a key can be escrowed. Query: "Escrow Key Status" (queries) lists each key escrowed, with the number of escrow copies. "Escrow Users Listed" (queries) lists the escrow users. Document: SSP card SC-12.
SC.L2-3.13.11 CUI Encryption	FIPS-validated cryptography protects the confidentiality of CUI.	Document: Cryptographic Modules gives each module and its certificate, and how to show that FIPS mode is on. SSP card SC-13. Configuration: FIPSModeOff at the top level of controller.toml, default false. Screen: The FIPS enabled badge in the Virtual Machines table.
SC.L2-3.13.12 Collaborative Device Control	Collaborative devices are identified, show when they are in use, and cannot be activated remotely.	Screen: Devices lists every device a VM can be given. Show that it holds no camera and no microphone. Document: SSP card SC-15.
SC.L2-3.13.13 Mobile Code	The use of mobile code is controlled and monitored.	Screen: System Settings > Servers > XSS Headers (key xssHeaders, empty by default) lists the only outside links and image sources the app accepts. Configuration: validation.request-json and validation.response-json in the ticrypt.rest section of ticrypt-rest.conf, both on by default. kill-session and lock-user in the security.xss section of ticrypt-auth.conf, both true by default. Document: SSP card SC-18.
SC.L2-3.13.14 Voice over Internet Protocol	The use of VoIP is controlled and monitored.	Screen: Global Licensing Servers and VM Access Rules show that no VoIP service is among the servers VMs can reach. Document: SSP card SC-19.
SC.L2-3.13.15 Communications Authenticity	The authenticity of communications sessions is protected.	Configuration: challenge-ttl in the sessions section of ticrypt-auth.conf, default 10 minutes. The [tunnel.cert] section of controller.toml sets the certificate that the tunnel service of each VM generates. Document: SSP card SC-23.
SC.L2-3.13.16 Data at Rest	The confidentiality of CUI at rest is protected.	Configuration: storage.path in the ticrypt.filemanager section of ticrypt-file-manager.conf names where the encrypted chunks are stored, and chunk-size, default 8 MiB, gives their size. Document: SSP card SC-28, and Cryptographic Modules. Your organization keeps that storage, and the platform database, inside its assessment scope.

System and Information Integrity (SI)

The following table describes the evidence for the seven System and Information Integrity practices. Four points hold for the whole family.

• Monitoring evidence has two sources: tiCrypt Audit records all user activity as the tiCrypt backend sees it, so its alerts and queries are the evidence for activity on the platform. Events on the host servers and inside the operating system of a VM come from the monitoring tools your organization deploys there, such as SentinelOne or CrowdStrike.
• The two sources meet in your SIEM: tiCrypt Audit's alerts go to the SIEM through its alert drivers, and are typically integrated with an external logging and monitoring system such as Splunk or Sumo Logic. Your monitoring tools push their logs and events to a proxy or collector server that your organization runs inside the enclave, so no VM needs a path out of the enclave. That proxy is part of your in-scope environment, and your organization decides what it forwards onward. See SIEM Integration.
• The path from VMs to the proxy is a rule you can show: A Super-admin opens it with a VM access rule that names the proxy, its ports and protocol, and the VM configurations whose VMs run the tool. A rule selects VMs by VM configuration, not by team or by user. A team is the set of users who can see one another in tiCrypt, and its members get access to a VM when they are added to it as co-owners or users. To cover the VMs a team works in, list the VM configurations those VMs start from. Older deployments use a global licensing server entry, which opens the proxy to every VM. The rule is itself evidence for SC.L2-3.13.6. See Dynamic Firewall Rules.
• Malicious code protection is configured in the VM image: On a Linux image with ClamAV installed and clamAVEnabled = true, the VM Controller starts ClamAV and its on-access client, scans each drive when it is attached, and writes findings to the controller log, which the managers of the VM can read. On a Windows image, the product installed in the image, for example Microsoft Defender, notifies the user in the VM.

Practice	What the assessor looks for	Evidence
SI.L2-3.14.1 Flaw Remediation	Times to identify, report, and correct flaws are specified and met.	Document: The release notes list the fixes in each version, with its date. SSP card SI-2. Screen: The versions on the login page, as described in Check Which Versions You Are Running. Your organization adds its upgrade records.
SI.L2-3.14.2 Malicious Code Protection	Locations for malicious code protection are designated and protected.	Configuration: clamAVEnabled in the [antivirus] section of controller.toml, default false. Show it set to true in each Linux image, with ClamAV installed in the image. Screen: The controller log of a VM, under VM Settings and Details > Logs, holds the findings of the scans. On a Windows VM, show the anti-virus product installed in the image, for example Microsoft Defender. Document: SSP card SI-3.
SI.L2-3.14.3 Security Alerts & Advisories	Alerts and advisories are monitored, and response actions are identified and taken.	Screen: The Alerts tab, filtered by severity, shows the alerts for activity on the platform. Configuration: The alert drivers in the [drivers] section of log-streamer.toml, which name where alerts go. Document: SSP card SI-5, and the release notes. Your organization adds the second source: the alerts of its host and in-VM monitoring tools, which report to its monitoring proxy inside the enclave, and the record of the actions it took.
SI.L2-3.14.4 Update Malicious Code Protection	Malicious code protection is updated when new releases are available.	Configuration: clamAVEnabled in controller.toml, as for SI.L2-3.14.2. The protection is part of the VM image, so its version is the one installed in the image. Screen: VM Images lists the images in use. Document: SSP card SI-3. Your organization adds the record of each image rebuild and of the signature updates of its anti-virus product.
SI.L2-3.14.5 System & File Scanning	A scan frequency is defined, scans run on it, and files from external sources are scanned in real time.	Configuration: clamAVEnabled in controller.toml, as for SI.L2-3.14.2. With it on, the VM Controller scans each drive when it is attached and runs the ClamAV on-access client. Screen: The controller log of a VM, which a manager of the VM can download as a .tsv file, records the scans and their findings. On a Windows VM, show the scan history of the product in the image. Document: SSP card SI-3. Your organization adds its scan schedule and results for the host servers.
SI.L2-3.14.6 Monitor Communications for Attacks	The system and its inbound and outbound traffic are monitored for attacks.	Screen: The Alerts tab, filtered to IP Alert, shows sign-ins from unusual locations. Query: "Users Launch Application" (queries) lists each connection to a VM through the tiCrypt proxy, with its source and destination addresses. "List user IPs" (queries/user) maps where one user signed in from. Configuration: geoip in log-streamer.toml names the GeoIP database that location alerts need. Document: SSP card SI-4. Your organization adds the second source: its network monitoring, and the monitoring tools it runs on the host servers and inside VMs, which report to its monitoring proxy inside the enclave.
SI.L2-3.14.7 Identify Unauthorized Use	Authorized use is defined, and unauthorized use is identified.	Query: "Failed Login Attempts" (queries/user) and "User account disabled" (queries/user) show unauthorized use of tiCrypt accounts. Screen: The Alerts tab, filtered to User Locked. The "Since you last logged in" summary shows each user the failed sign-ins to their own account. Next release: "Access Attempts by Removed Users" (queries/user). Document: SSP card SI-4. Your organization adds the second source: the findings of its host and in-VM monitoring tools, which report to its monitoring proxy inside the enclave, for use that does not pass through a tiCrypt account.

Queries coming in the next Audit release

The following table describes the nine queries marked Next release above. They are not in the released product yet. Until you have upgraded, use the other evidence in each row.

Query	Folder	What the result shows	Practices
"Privileged Actions Audit"	queries/actions	Every administrative action in the period, with who performed it.	AC.L2-3.1.7, AC.L2-3.1.15, MA.L2-3.7.2
"Privileged Accounts"	queries	Each account whose role is above a regular user, with its state, when the role was set, and who set it.	AC.L2-3.1.4, AC.L2-3.1.5, CM.L2-3.4.5
"Failed Login Summary"	queries/user	For each user, the number of refused requests, failed challenges, and lockouts in the period.	AC.L2-3.1.8
"MFA Coverage by User"	queries/user	For each user, the sign-ins completed with a multifactor token and those completed without one.	IA.L2-3.5.3
"File Sharing Log"	queries	Each time a file was shared with a user or a group, with the project the file was created under.	AC.L2-3.1.3
"External SFTP Access Log"	queries	Every check of a user's access to an external SFTP server, and whether access was allowed.	AC.L2-3.1.3, AC.L2-3.1.20
"Access Attempts by Removed Users"	queries/user	Sign-in attempts made after an account was deleted, and whether each was granted or refused.	AC.L2-3.1.1, SI.L2-3.14.7
"File Deletions by User"	queries	For each user, the files deleted directly, emptied from the trash, or collected by the system.	MP.L2-3.8.3
"User Certification Status"	queries/user	Each user certification as valid, expired, or revoked on the end date.	Supports your evidence for AT.L2-3.2.1 and AT.L2-3.2.2

Practices your organization owns

The CMMC Level 2 control guide marks the following 25 practices "University": your organization implements them, and tiCrypt does not. Their evidence comes from your organization's own program.

Practice	Name	Where the evidence comes from
AC.L2-3.1.16	Wireless Access Authorization	Your organization's wireless access program.
AC.L2-3.1.17	Wireless Access Protection	Your organization's wireless access program.
AC.L2-3.1.18	Mobile Device Connection	Your organization's mobile device program.
AC.L2-3.1.19	Encrypt CUI on Mobile	Your organization's mobile device program.
AC.L2-3.1.21	Portable Storage Use	Your organization's portable storage policy.
AT.L2-3.2.1	Role-Based Risk Awareness	Your organization's security awareness program.
AT.L2-3.2.2	Role-Based Training	Your organization's training program.
AT.L2-3.2.3	Insider Threat Awareness	Your organization's training program.
CM.L2-3.4.1	System Baselining	Your organization's baseline configurations and inventories.
IR.L2-3.6.1	Incident Handling	Your organization's incident response plan.
IR.L2-3.6.3	Incident Response Testing	Your organization's incident response tests.
MA.L2-3.7.1	Perform Maintenance	Your organization's maintenance program.
MA.L2-3.7.3	Equipment Sanitization	Your organization's maintenance program.
MA.L2-3.7.4	Media Inspection	Your organization's maintenance program.
MA.L2-3.7.6	Maintenance Personnel	Your organization's maintenance program.
PS.L2-3.9.1	Screen Individuals	Your organization's personnel security program.
PS.L2-3.9.2	Personnel Actions	Your organization's personnel security program.
PE.L2-3.10.1	Limit Physical Access	Your organization's physical security program.
PE.L2-3.10.2	Monitor Facility	Your organization's physical security program.
PE.L2-3.10.3	Escort Visitors	Your organization's physical security program.
PE.L2-3.10.4	Physical Access Logs	Your organization's physical security program.
PE.L2-3.10.5	Manage Physical Access	Your organization's physical security program.
PE.L2-3.10.6	Alternative Work Sites	Your organization's physical security program.
RA.L2-3.11.1	Risk Assessments	Your organization's risk assessment program.
CA.L2-3.12.4	System Security Plan	Your organization's own plan, which you can adapt from the System Security Plan.

tiCrypt holds records that can support your evidence for three of these practices. They do not change who owns the practice.

• AT.L2-3.2.1 and AT.L2-3.2.2: User Certifications records that a user meets a project's security requirement, such as completed training, with its expiration.
• PS.L2-3.9.2: The Status, Deactivation Cause, and Deactivation Reason columns of the Users table in User Management, and the query "Users Deleted" (queries/user), show when access ended for a person who left.

Related

• CMMC Level 2 control guide: who implements each of the 110 practices, and what your organization still does.
• System Security Plan: the implementation statement behind each card cited on this page.
• Scoping Guide: which components are in scope, and so which servers hold the files and screens named here.
• Incident Response: the queries, containment actions, and evidence to preserve after a cyber incident.