10 posts tagged with "Security"

A dynamic firewall rule, called a VM access rule in tiCrypt, lets a VM reach one outside server, such as a license server, on chosen ports. It is a narrow exception to tiCrypt's default of blocking all outbound traffic from secure VMs. A super-admin writes the rule once. From then on, tiCrypt opens and closes the path by itself as VMs start and stop and as users open and close access, so nobody has to edit the firewall by hand. Any server and port that no rule names stays unreachable.

• The problem: secure VMs have no outbound network access, yet research software often needs a license server, an activation service or a package repository.
• The global list: the Licensing Servers list opens each server to every VM, all the time.
• What dynamic rules change: a server opens only to the VMs that need it, and only while they need it. Everything else stays blocked.
• Scope: one rule covers chosen VMs, one server, and the ports and protocol you set.
• Implicit rules: always on while the VM runs. Example: a license server the software checks at start-up.
• Explicit rules: off until a user opens access, then closed again after the time limit the rule sets. Example: a vendor's activation server used once a year.
• Mechanism: nftables on the firewall host. The backend sends the full list of allowed VM-to-server connections to the ticrypt-nft service every 5 minutes and right away after any change. Entries expire after 10 minutes unless renewed, so access fails closed.
• Who does what: super-admins create rules. Users who can see a VM open and close access on its explicit rules. Only rule setup is logged.

A Data Use Agreement is a contract your institution signs on behalf of every researcher who will ever touch the dataset. Most research computing environments cannot make the guarantees a DUA requires. They can only promise to try.

CMMC Level 2 requires organizations to satisfy 110 security practices defined in NIST SP 800-171 Revision 2 across 14 control families. tiCrypt's compliance model splits these practices into three responsibility categories.

Organizations operating research clusters, HPC environments, and open compute infrastructure already maintain filesystems measured in petabytes. When CMMC Level 2 compliance enters the picture, organizations often assume CUI requires physically dedicated storage: a separate appliance, separate drives, a hard boundary between the regulated enclave and everything else. That assumption is expensive and, under tiCrypt's architecture, unnecessary.

tiCrypt's client-side encryption reduces the storage layer to a ciphertext-only medium. The filesystem never holds keys or plaintext. Because the storage layer cannot read what it stores, CUI can share physical media with non-CUI workloads without compromising confidentiality. You can carve out a partition, directory, or namespace on your existing shared filesystem, point tiCrypt at it, and maintain full CMMC L2 compliance without purchasing dedicated hardware. This article explains how to do it, what the storage layer actually holds, and which CMMC controls make this acceptable.

For the theoretical foundation behind cryptographic isolation on shared media, see Cryptographic Isolation for CUI on Shared Storage. For details on how tiCrypt interacts with the underlying filesystem, see Interplay between the filesystem and tiCrypt.

If you are preparing for a CMMC Level 2 assessment, the Audit and Accountability (AU) control family is one of the first areas an assessor will examine. The nine AU practices in NIST SP 800-171r2 (practices 3.3.1 through 3.3.9) require your organization to demonstrate that every action involving Controlled Unclassified Information (CUI) is logged, attributable to a specific user, protected from tampering, and available for review. tiCrypt's audit system addresses these requirements.

This article is written for compliance officers and audit program managers building a System Security Plan (SSP) and preparing evidence packages for CMMC Level 2 assessment. It covers what tiCrypt's audit system captures and flags, how the architecture works and connects to your SIEM, where the platform's responsibility ends and your organizational controls must begin, and how each AU practice maps to specific capabilities and evidence. For a deeper look at the audit schema and forensic investigation capabilities, see Usage Reporting and Forensics in tiCrypt Audit.

We are often asked about the quantum computing threat to RSA. Adversaries may already be harvesting encrypted traffic for future decryption, NIST has finalized post-quantum standards, and NSA's CNSA 2.0 timeline calls for transition by 2030. What is tiCrypt doing about it?

Rather than keep this answer in inboxes, we are putting it on the record.

How tiCrypt's client-side encryption, key isolation, and PKI enable a shared file system to host a CUI enclave.

Universities evaluating cloud platforms for regulated research typically start with a reasonable assumption: the cloud provider handles security, and the institution handles research. The shared responsibility model promises exactly this. The provider secures the infrastructure. The customer secures everything running on it.

In practice, "everything running on it" includes most of the controls that NIST SP 800-171 actually requires. Access management, audit logging, session isolation, media protection, incident response, and configuration management all remain the customer's responsibility. The provider secures the rack. The institution must still secure the research.

This is not a criticism of cloud platforms. It is a description of the model. The problem is that many institutions adopt cloud-based research environments believing they have purchased compliance, when what they have purchased is infrastructure.

Secure virtual machines in tiCrypt run in near-complete isolation from each other and from the surrounding environment. This isolation is the foundation of tiCrypt's security model. Every network pathway into or out of a VM is tightly controlled, authenticated, and encrypted, with no exceptions.

This post explains the mechanisms that make this possible: proxy-mediated communication, application port tunneling, VM-level network isolation, and controlled access to external licensing servers.

Security isn't just about having the right tools. It's about how you use them.

Multi-Factor Authentication has become a cornerstone of modern cybersecurity. Whether you're chasing CMMC compliance, meeting NIST standards, or simply trying to keep bad actors out, MFA is table stakes. Duo, Shibboleth, NetID — these tools are everywhere, and for good reason: they work.

So why does tiCrypt refuse to trust them?