tiCrypt

Incident Response

AdministratorRequires: A tiCrypt Audit account for the queries; user administration permissions in tiCrypt for the containment actions

Incident response is the set of actions an organization takes once it discovers a cyber incident: it finds out what was affected, contains the cause, preserves the evidence, and reports to the Department of Defense. DFARS clause 252.204-7012 sets the deadlines for a contractor that holds covered defense information, and the work is shared: tiCrypt supplies the record of what happened inside the system and the actions that stop it, and your organization supplies the plan, the host and network evidence, and the report. Incident response is not audit review. Audit review reads the logs on a schedule, while incident response starts when something has gone wrong and a deadline is running.

Why incident response has its own page

The clause sets a deadline that starts at discovery. DFARS 252.204-7012 gives a contractor 72 hours from discovery to report a cyber incident, and the report rests on a review that names the compromised computers, servers, data, and user accounts. That review fits in 72 hours only when the queries, the people, and the reporting certificate are in place beforehand.

The work is split between tiCrypt and your organization. In the CMMC Level 2 control guide, two of the three incident response practices belong to your organization and the third is shared. tiCrypt records what happened inside the system and gives administrators the actions to stop it. It does not write your plan, see your hosts and network, or file your report. This page shows where each half begins.

Encryption does not remove the obligation. tiCrypt stores file and drive contents as ciphertext, and its servers hold no decryption keys. A copy of that storage in the wrong hands is still an incident, because encrypted CUI is still CUI. See Encrypted CUI is still CUI.

When to use this page

• You are writing the incident response plan: Use the timeline and the "Your organization does" lines to assign each step to a role.
• You are preparing for an assessment: Use CMMC practices this page supports to show how tiCrypt feeds practices IR.L2-3.6.1 through IR.L2-3.6.3.
• You are testing the plan: Run the queries in Determine what was affected against a test account, and time how long the answer takes.
• An incident is under way: Start at Contain an account or a session, then Determine what was affected.

What the clause requires

This section summarizes DFARS 252.204-7012, Safeguarding Covered Defense Information and Cyber Incident Reporting, in the version dated May 2024. The clause in your contract controls, so work from its text.

The following table describes the terms the clause defines in paragraph (a).

Term	Definition
Compromise	"disclosure of information to unauthorized persons, or a violation of the security policy of a system, in which unauthorized intentional or unintentional disclosure, modification, destruction, or loss of an object, or the copying of information to unauthorized media may have occurred"
Cyber incident	"actions taken through the use of computer networks that result in a compromise or an actual or potentially adverse effect on an information system and/or the information residing therein"
Rapidly report	"within 72 hours of discovery of any cyber incident"
Forensic analysis	"the practice of gathering, retaining, and analyzing computer-related data for investigative purposes in a manner that maintains the integrity of the data"
Malicious software	"computer software or firmware intended to perform an unauthorized process that will have adverse impact on the confidentiality, integrity, or availability of an information system"

The following table describes what the clause requires, in the order the deadlines arrive.

When	What the clause requires	Paragraph
Before an incident	Hold a medium assurance certificate approved by the Department of Defense. Without it you cannot file a report. The clause points to public.cyber.mil/eca for how to obtain one.	(c)(3)
At discovery	Review for evidence of compromise of covered defense information. Identify the compromised computers, servers, specific data, and user accounts, and analyze the other systems on your network that may have been accessed.	(c)(1)(i)
At discovery	Start preserving images of all known affected systems and all relevant monitoring and packet capture data.	(e)
Within 72 hours of discovery	Report the incident to the Department of Defense at dibnet.dod.mil, with at least the required elements listed there.	(c)(1)(ii), (c)(2)
When you find and isolate malicious software	Submit it to the Department of Defense Cyber Crime Center (DC3), following the instructions of DC3 or the Contracting Officer. Do not send it to the Contracting Officer.	(d)
For at least 90 days after you submit the report	Keep the images and the monitoring and packet capture data preserved and protected, so that the Department of Defense can request the media or decline interest.	(e)
On request	Give the Department of Defense access to additional information or equipment that a forensic analysis needs.	(f)
If a damage assessment is conducted	Provide the damage assessment information gathered under paragraph (e) when the Contracting Officer asks for it.	(g)

Two further paragraphs reach beyond your own organization.

• Subcontractors: Paragraph (m)(2)(ii) requires a subcontractor that reports an incident to give the incident report number to the prime contractor, or the next higher-tier subcontractor, as soon as practicable.
• External cloud service providers: Paragraph (b)(2)(ii)(D) requires a cloud service provider that stores, processes, or transmits covered defense information for you to comply with paragraphs (c) through (g).

▲The 90 days run from the report

Paragraph (e) counts the 90 days "from the submission of the cyber incident report", not from the incident or its discovery. Evidence gathered on the first day is therefore kept for longer than 90 days. Set the retention date when you file the report.

What tiCrypt records and what it does not

tiCrypt has its own audit system, which produces alerts and reports and answers ad hoc queries. tiCrypt Audit records all user activity as the tiCrypt backend sees it, in 200+ event types: sign-ins and sessions, file and directory operations, sharing, drives, virtual machines, key operations, and administrative changes. The tiCrypt backend pushes each log line one way to the audit server on TCP port 25000. tiCrypt Audit never deletes logs, so the full history of the system is available from the day it was installed.

tiCrypt is an application. It records what passes through it and nothing below it. The following table describes where each kind of evidence comes from.

Evidence	Recorded by tiCrypt	Where it comes from
Actions inside tiCrypt: sign-ins, file reads and writes, shares, drive and VM activity, administrative changes	Yes	tiCrypt Audit, on your audit server.
Host events: operating system logins, sudo, process and file activity on the backend, VM hosts, storage servers, and audit server	No	Your host logging, such as syslog and auditd, and the monitoring tools you install on the host servers.
Events inside a VM's operating system: processes, local logins, and file activity in the guest	No. tiCrypt records that the VM started, who connected, and which drives were attached.	A monitoring tool you install in the VM image.
Network events: firewall logs, intrusion detection, flow records, packet capture	No	Your network security tools.
Endpoint events: activity on the workstations that users connect from	No	Your endpoint detection and response tool.
Server health: processor, memory, and disk use	No	Your infrastructure monitoring.
Physical access: badge and camera records	No	Your facility systems.

Your organization covers the rows marked No with its own monitoring tools. Tools such as SentinelOne and CrowdStrike can be deployed on the host servers and inside VMs, where you install them in the VM image. The agents 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, for example to your SIEM. tiCrypt Audit's own alerts reach the SIEM through its alert drivers, and are typically integrated with an external logging and monitoring system such as Splunk or Sumo Logic. See SIEM Integration.

A VM reaches the monitoring proxy only where a rule opens the path. A Super-admin creates a VM access rule that names the proxy, its ports and protocol, and the VM configurations whose VMs run the tool, so only those VMs can reach it. 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 instead, which opens the proxy to every VM. See Dynamic Firewall Rules.

▲An attacker who bypasses tiCrypt leaves no trace in tiCrypt Audit

Someone who signs in to a server with an operating system account, or copies files from a storage server, never passes through tiCrypt. Only host and network logs show that activity. A clean result in tiCrypt Audit means no tiCrypt account did it. It does not mean it did not happen.

Determine what was affected

Paragraph (c)(1)(i) asks for the compromised computers, servers, specific data, and user accounts. For everything that happened through a tiCrypt account, the saved queries in tiCrypt Audit answer "which files, drives, VMs, and users did this account touch, and when". Find each query by its title in the Queries tab, set the date range and the user or file, and click Run. For the procedure, see Queries.

The following table describes the queries to run. The folder is where the query's definition file sits in the tiCrypt Audit query library.

Question	Query	Folder	What the result shows
Which files, drives, and VMs did this account reach, and when?	"User Access Audit"	queries/user	A timeline for one user: each file read, file write, drive key retrieval, drive attached to a VM, and VM connection, with its time and the resource.
What else did this account do?	"List user actions performed"	queries/user	Every action the user performed in the period, across files, directories, drives, groups, teams, sessions, and VMs.
What was done to this account?	"List user actions received"	queries/user	Session requests, group and drive key changes, and account changes made to the user.
Where did this account sign in from?	"List user IPs"	queries/user	Each source address the user signed in from, with the last use, the number of sign-ins, and a map.
When did the sessions start and expire?	"List user login info"	queries/user	Each sign-in with the user, the time, the source address, and the time the session expires.
Were there failed sign-ins or lockouts?	"Failed Login Attempts"	queries/user	Each refused session request and each account lockout, with the user, the source address, and the time.
Which files moved, for every user?	"Data Transfer Log"	queries/user	One row for each file in each session: the user, the direction (Vault Read or Vault Write), the file, and the start time.
How much data did this account read and write?	"User transfer information"	queries/user	For one user, each file with the bytes read and the bytes written.
Which files did this account download or preview?	"User Downloads and Previews"	queries/user	For one user, each file whose key was fetched, with the time.
Who touched this file?	"List file actions"	queries	For one file ID: its creation, each key added for a user or group, each read and write, and its deletion.
What happened to the drives?	"List ALL Drive Actions"	queries/actions	Drive creation, deletion, modification, attachment, detachment, key grants and removals, and ownership changes, with who performed each.
Who was given or lost a drive key?	"Drive Key Access Log"	queries	Each drive key granted or revoked, with the user and whether write access was included.
Which VMs ran, and who connected?	"List VM actions"	queries/actions	Each VM start, stop, registration, and application connection, with the source address.
Which VMs did this account connect to?	"User Launch Application"	queries/user	For one user, each connection to a VM with the source and destination addresses.
Did this account change anyone's access?	"Permission Change Audit"	queries/actions	User account changes, group membership and ownership changes, drive key grants and revocations, and project access changes, with who made each.
Was a role, state, or password changed?	"User account actions (extra)"	queries/actions	Each role change, permission change, state change, key escrow, and password change, with who performed it.
What could this account reach at the time?	"List user permissions", "List user teams", "List user groups", "List user projects"	queries/user	The user's permissions and memberships as they stood on the end date you set.
Was anything deleted?	"Files Deleted", "Drives Deleted"	queries	Each deleted file or drive with the time and the user who deleted it.
Which data belongs to the contract?	"Project Resource Pairs"	queries	Each resource with the project it is tagged with, so you can tell which affected files and drives belong to a project that holds covered defense information.

The saved queries take a user, a file, a team, or a project, and a date range. None takes a session ID. To isolate one session, read its start and expiry times from "List user login info", and run the other queries over that period. An administrator of tiCrypt Audit can go further in the SQL tab: most event tables carry a SessionID column.

Click a user, file, drive, VM, or address in any result to open it in the Objects tab. An address shows its location, city, and country when a GeoIP database is configured.

Two screens inside tiCrypt complement the queries, and neither replaces them.

• View History: A user with access to a file can list its events (created, accessed, shared, unshared, project changed) from the Vault.
• Audit Logs: The Management table shows only the most recent log lines, with no user or time filter. It is not the full history.

The following queries are coming in the next Audit release. They are not in the released product yet.

Query	Folder	What the result shows
"Access Attempts by Removed Users"	queries/user	Sign-in attempts made after an account was deleted, and whether the server granted or refused each one.
"Failed Login Summary"	queries/user	For each user, the number of refused requests, failed challenges, and lockouts in the period.
"File Sharing Log"	queries	Each time a file was shared with a user or a group, with the project the file was created under.
"Privileged Actions Audit"	queries/actions	Every administrative action in the period, with who performed it.
"External SFTP Access Log"	queries	Every check of a user's access to an external SFTP server, and whether access was allowed.
"File Deletions by User"	queries	For each user, the number of files deleted directly, emptied from the trash, or collected by the system.

• tiCrypt provides: The saved queries above, over the full history of the system.
• Your organization does: Decide which accounts and systems are in question, run the queries, compare the result with host and network logs, and identify which of the affected data is covered defense information.

Prove the logs are intact

A forensic analysis, as the clause defines it, maintains the integrity of the data. The audit log is a SHA-512 hash chain, which makes any change to it detectable.

• Append-only source: The backend's logger service writes the master copy of the log to a local file through a driver marked immutable = true, which produces append-only output.
• One-way delivery: The backend pushes the log to the audit server on TCP port 25000. The audit server has no path back to the backend.
• Hash chain: The log contains numbered hash records. Each one is the SHA-512 digest of the previous hash record and of every log line written since it. Changing, inserting, or removing a line changes every digest after it.

The following table describes the three ways to verify the chain.

Check	How	What it shows
Continuous	The tiaudit-logger service recomputes each digest as lines arrive and compares it with the hash record. A mismatch raises a Hash Alert, which appears in the Alerts tab and goes to every configured alert driver.	Every line matched its chain when it arrived, for as long as no Hash Alert was raised. Filter the Alerts tab by alert type to show this for a period. This check does not show that records already stored in the audit database are unchanged. The Independent check does that, from the backend's own log files.
On demand	Run "Check Hash" (queries) with a sequence number. It returns the time, the hash number, and the hash stored in tiCrypt Audit. Compare it with the hash record of the same number in the backend's log files under /var/log/ticrypt.	The audit server and the backend hold the same chain at that point.
Independent	Load a copy of the backend's log files into a second tiCrypt Audit installation with tiaudit-log-uploader. It recomputes the chain from the first record and raises a Hash Alert at any mismatch.	The whole chain verifies without relying on the first audit server.

For the uploader and its alert drivers, see Configuration and Setup.

• tiCrypt provides: The hash chain, the continuous check, the Hash Alert, and the "Check Hash" query.
• Your organization does: Route Hash Alerts to people who act on them, limit who can administer the audit server, and keep the result of the check with the incident record.

Contain an account or a session

Containment in tiCrypt acts on accounts, memberships, VMs, and network allowlists. An administrator performs most of these actions in Management. Since backend 3.16.1, changing an account also ends or updates the sessions already open for it.

The following table describes the containment actions.

Goal	Action	Effect
End all access for an account	Change state: set the account to Inactive and enter a Reason for deactivation.	Every session acting for the person ends at once: the web app, file transfers, the person's VMs, and uploads into their inboxes. New sign-ins are refused. Nothing is deleted.
End access from an identity system	Deactivate Users: call POST /api/users/disable with a list of user IDs.	The same as setting the accounts to Inactive. Super-admin accounts cannot be deactivated this way.
Reduce what an account can do	Change role, or edit the user's permissions.	Open sessions end. The next sign-in carries the new role and permissions.
Cut an account off from one project	Delete the project membership.	The project leaves every open session of the person at once. Resources tagged with the project are out of reach.
Stop a VM	Shut down or hard shut down the VM from Running VMs.	The VM stops. Its encrypted drives keep their contents.
Take a drive away from an account	The drive's owner removes the user's access in the Share dialog.	The user no longer holds a key to the drive. Only the drive's owner can do this. An administrator who does not own the drive deactivates the account instead.
Revoke an API key	Delete the API key.	Scripts that use the key stop working.
Close an outbound path from VMs	Delete every allowance for that server: its entry in Global Licensing Servers and each rule in VM Access Rules that names it. Traffic passes when either list allows it, so check both, then confirm from a VM that the server no longer answers.	VMs can no longer reach that server once no entry and no rule allows it. Every other destination was already blocked.
Close an export path	Delete the entry in External SFTP Servers.	Users can no longer push Vault files to that server.

tiCrypt also contains some events without an administrator.

• Repeated failed sign-ins: An account that requests more than 5 login challenges in a row without completing one is locked (max-challenge-attempts-before-lock in ticrypt-auth.conf, default 5). It stays locked until an administrator activates it.
• Suspected cross-site scripting: The backend ends the session and locks the account (kill-session and lock-user in the security.xss section of ticrypt-auth.conf, both true by default).

For what each action does to open sessions, see Offboarding in tiCrypt.

▲Shutting a VM down discards its guest state

A tiCrypt VM boots from a clean image on every start, so a shutdown discards the memory and the operating system state of the guest. If your plan calls for that state as evidence, capture an image from the VM host before you shut the VM down. Deactivating the account ends the VM's session with the server without waiting for that decision.

• tiCrypt provides: The actions above, each recorded in the audit log with who performed it.
• Your organization does: Decide who may order containment, contain hosts and network segments with your own tools, and record each action and its time in the incident record.

Preserve evidence for 90 days

Paragraph (e) covers two things: images of all known affected systems, and all relevant monitoring and packet capture data. tiCrypt holds one part of the second. Your organization holds the rest.

What tiCrypt holds. tiCrypt Audit never deletes logs, and it has no retention setting to shorten. The audit record of the incident is therefore still there 90 days after the report, and for as long as the audit server and its backups exist. The backend writes the original log files under /var/log/ticrypt, which the hash chain is verified against. Include them in the image and the backups of the backend.

What tiCrypt does not hold. The following table describes the evidence your organization must capture and keep for at least 90 days after the report.

Evidence	Why tiCrypt does not hold it
Images of the affected hosts: backend server, VM hosts, storage servers, database, audit server	tiCrypt runs on these hosts and does not image them.
Images of the affected VMs	A VM boots from a clean image on every start, and tiCrypt keeps no copy of a guest's state.
Network monitoring and packet capture data: firewall logs, intrusion detection alerts, flow records, packet captures	tiCrypt has no view of network traffic outside its own proxy.
Host logs: syslog, auditd, SSH sign-ins, and the systemd journal that holds the service logs	tiCrypt Audit records application events only. The journal rotates under your host settings.
Events collected by your host and in-VM monitoring tools	The tools report to your own monitoring proxy inside the enclave, not to tiCrypt.
Endpoint images and endpoint detection data for the workstations involved	The workstations are outside tiCrypt.
Earlier contents of files and drives	tiCrypt keeps the current ciphertext and the history of events, not earlier versions. Storage snapshots and backups hold earlier states.
Physical access records	They come from your facility systems.

▲Preserved images are still CUI

An image of a tiCrypt storage server contains ciphertext, and an image of the platform database contains file and directory names that are not encrypted. Both remain CUI. Keep preserved images on systems inside your assessment scope, and control who can reach them.

• tiCrypt provides: The complete audit history, with no action needed to retain it.
• Your organization does: Image the affected systems, keep the monitoring and packet capture data, back up the audit server, protect all of it for at least 90 days from the report, and release it only as paragraphs (e) through (g) provide.

Export evidence

tiCrypt Audit exports what a query or a report returns. An export is a copy for the incident record. The authoritative record stays in tiCrypt Audit, under the hash chain.

The following table describes the export formats.

What	Format	How
A query result	An Excel workbook (.xlsx) named after the query, with formatting and column statistics	In the Queries tab, click Export, then Export all data, Export selected data, or Export visible data. See Queries.
A report, with the results of all its queries	An Excel workbook (.xlsx)	In the Reports tab, click Export. A script can call GET /reports/{ReportID}/{StartDate}/{EndDate}. See Reports.
Query rows for a script	JSON: an array of rows	POST /queries/{QueryID}/{EndDate} with an access token.
Alerts raised in a period	JSON	GET /alerts/{StartDate}/{EndDate} with an access token.
Details of users, files, drives, VMs, and addresses	JSON	POST /objects/{Type}/{EndDate} with an access token.
Tables in tiCrypt Management, such as Users, Running VMs, and System Settings History	CSV or JSON	The Export CSV and Export JSON buttons of each table.

An administrator of tiCrypt Audit creates access tokens in Management > Access Tokens, each with a purpose and an expiration date. For the routes, see the REST API Reference.

• tiCrypt provides: Excel exports from the interface, and JSON and Excel through the REST API.
• Your organization does: Record with each export who ran it, when, and with which parameters, and store the files with the preserved evidence.

Feed a SIEM

A SIEM is where tiCrypt events meet the host, network, and endpoint events that tiCrypt does not see. Customers typically integrate tiCrypt's alerts with an external logging and monitoring system such as Splunk or Sumo Logic. Splunk has its own alert driver. Any other system takes the console driver's output through a log collector, or pulls from the REST API. The host and in-VM monitoring tools take a separate route: they report to your monitoring proxy inside the enclave, which forwards what you decide to the same SIEM. tiCrypt Audit delivers in two ways.

• Alert drivers: tiCrypt Audit pushes each alert as it is raised. Alerts can go to email, to the console, or to Splunk. The Splunk driver sends JSON to a Splunk collection point. The console (print) driver writes to standard output or standard error, which a log collector can forward to any other SIEM. Drivers are set in the [drivers] section of /etc/tiaudit/log-streamer.toml. See Configuration and Setup.
• REST API: A scheduled job pulls alerts and query results with an access token. See the REST API Reference.

The alert types include an unusual sign-in location (IP Alert), a break in the hash chain (Hash Alert), a locked account (User Locked), a new account (User Added), and changes to an account's state or role. Each alert carries one of five severities, from Info to Critical. See Alerts.

• tiCrypt provides: Alerts pushed as they happen, and the audit data on request.
• Your organization does: Run the monitoring proxy that your tools report to, decide what it forwards, decide which severities page which team, write the playbooks, and correlate tiCrypt events with the other sources in the SIEM.

Report within 72 hours

The report itself is your organization's act. tiCrypt contributes the facts that go into it.

Tera Insights staff have no access to your deployment. Tera Insights cannot read your logs, investigate on your behalf, or report for you. Support is given as guidance. If you send log excerpts to support during an incident, those excerpts are security protection data that now reside outside your boundary. See Tera Insights as a Service Provider.

• tiCrypt provides: The accounts, data, times, and source addresses involved, from the queries above.
• Your organization does: Hold the medium assurance certificate, file the report at dibnet.dod.mil within 72 hours of discovery, notify your own designated officials, and, as a subcontractor, pass the incident report number to the prime contractor.

Submit malicious software

Paragraph (d) applies when you discover and isolate malicious software in connection with a reported incident.

A tiCrypt VM boots from a clean image on every start, so malicious software in a guest operating system does not survive a restart. Files in the Vault and on encrypted drives do persist, and so does anything in them.

Malicious code protection is configured in the VM image. The following table describes how a finding reaches you on each kind of image.

Image	Protection	Where a finding appears
Linux, with ClamAV installed and clamAVEnabled = true in the [antivirus] section of controller.toml (default false)	The VM Controller starts ClamAV and its on-access client, and scans each drive when it is attached.	In the controller log, which the managers of the VM can read. See Access the Virtual Machine Controller Logs.
Windows	The product installed in the image, for example Microsoft Defender.	In the VM, where the product notifies the user.

tiCrypt Audit has no alert type for an anti-virus finding in a VM. Your incident response plan needs a route from the user or the VM's manager to your security team, or a monitoring tool in the image that reports to your monitoring proxy inside the enclave.

• tiCrypt provides: The scan of attached drives on Linux images, and the trail of the file: "List file actions" shows who created it, who received a key to it, and who read it.
• Your organization does: Build anti-virus into the images, isolate the sample, submit it to DC3 as instructed, and never send it to the Contracting Officer.

Give access for forensic analysis and damage assessment

Paragraphs (f) and (g) apply after the report, at the request of the Department of Defense or the Contracting Officer.

The following table describes the two kinds of access tiCrypt can give.

Access to	How
The audit record	Invite the investigator to tiCrypt Audit with the User role. The account runs queries and reports and has no access to the tiCrypt backend, its data, or user keys. See Management.
File and drive contents	Contents are encrypted with keys that users hold. A user with access shares the file or drive. When the user is not available and the account's key was escrowed, the escrow groups recover the key. Administrators cannot. See Recover a User's Private Key.

• tiCrypt provides: Read access to the audit record without access to data, and key recovery through escrow where it was set up.
• Your organization does: Provide the preserved images, the monitoring and packet capture data, and any equipment requested, and decide with counsel what is released.

Encrypted CUI is still CUI

The Department of Defense CIO's CMMC Frequently Asked Questions (July 2026 edition), question B-Q8, asks whether encrypted CUI is still considered to be CUI. The answer states that "encrypted CUI data retains the control designation given to the plain text counterpart".

The clause's definition of a compromise includes the case in which "the copying of information to unauthorized media may have occurred". Put the two together. If someone copies tiCrypt's ciphertext from a storage server, a replica, or a backup, CUI has been copied to unauthorized media. That is a compromise, and the incident is reportable, even though no plaintext is exposed.

What encryption changes is the damage, not the duty to report. The servers hold no decryption keys, so the copied file and drive contents cannot be read without a user's private key. State that in the report, together with what is not encrypted: the platform database holds file and directory names in the clear.

• tiCrypt provides: Contents that stay unreadable when the storage is copied.
• Your organization does: Treat a copy of the storage as a compromise, find out from host and network logs what was taken, and report it.

CMMC practices this page supports

The following table describes the practices involved, with the responsibility the CMMC Level 2 control guide assigns. The control guide labels your organization's practices "University".

Practice	Responsibility	What tiCrypt contributes	What your organization does
IR.L2-3.6.1 Incident Handling	University	Detection data and the containment actions on this page. They serve your capability and do not replace it.	Establish the capability: preparation, detection, analysis, containment, recovery, and user response.
IR.L2-3.6.2 Incident Reporting	Shared	Audit logs and real-time alerts in five severities, as detection data and forensic evidence. See the System Security Plan.	Track, document, and report incidents to your officials and to the authorities, within the 72 hours.
IR.L2-3.6.3 Incident Response Testing	University	The queries on this page, which a test can run against a test account.	Test the capability and record the result.
AU.L2-3.3.1 System Auditing	tiCrypt	200+ event types, always on, kept for the life of the deployment.	Back up the audit server.
AU.L2-3.3.2 User Accountability	tiCrypt	Every action tied to a user, a session, and a source address.	None.
AU.L2-3.3.4 Audit Failure Alerting	tiCrypt	Alerts on failures such as a break in the hash chain.	Route the alerts to the right staff.
AU.L2-3.3.5 Audit Correlation	tiCrypt	Correlation across users, resources, event types, and time, and alerts forwarded to a SIEM.	Use the tools in your review and response process.
AU.L2-3.3.6 Reduction & Reporting	tiCrypt	Saved queries, reports, and Excel export.	None.
AU.L2-3.3.8 Audit Protection	tiCrypt	The SHA-512 hash chain and the one-way push to a separate audit server.	None.
AU.L2-3.3.9 Audit Management	tiCrypt	Audit administration limited to a small group.	Limit access to the audit server to designated administrators.

For the artifact to show an assessor for each of these, see Assessment Evidence.

Related

• Assessment Evidence: the query, screen, or configuration line to show an assessor for each practice.
• Scoping Guide: which hosts and networks are in scope, and therefore which systems you may have to image.
• Usage Reporting and Forensics in tiCrypt Audit: what the audit log records and how an investigation uses it.
• Audit Telemetry and SIEM Integration: the ingestion path for each SIEM, and the boundary between tiCrypt and your monitoring.
• Monitoring & Audit: the queries, reports, and alerts of tiCrypt Audit.
• Audit Service: how the audit server is deployed and how it receives the log.