Security Principles and Compliance Specifics Governing tiCrypt

Executive Summary

Judging by the continuous stream of data breaches, the security mechanisms widely deployed, such as backend network security, perimeter defenses, and security permission management, are ineffective. These traditional mechanisms fail to address what happens if you have a single point of failure, i.e., if the backend server is compromised or the risk is posed internally.

The primary assumption behind the tiCrypt design is that backend servers and network infrastructures can easily be compromised. The only mechanisms that tiCrypt trusts and what it builds the security of the system on are based on strong encryption controlled by the user. Since the decryption keys are not stored on the server, the data cannot be compromised if the server is breached. In tiCrypt, a compromised admin account does not translate into a data breach.

Security Principles

• Data Confinement through Encryption: Rather than directly hardening of the system through traditional means, tiCrypt utilizes encryption to ensure data confinement. System resources such as files, drives, and communication channels use an independent AES-256 encryption key.
• Public-Key Cryptography: Data confinement requires independent keys for each resource. The critical management nightmare is avoided in tiCrypt through public key cryptography. Upon account creation, each user creates an RSA-2048 key; this key is the primary means of secure data control.
• End-to-end encryption for security: This is defined as encrypting a file at the earliest stage and decrypting it as late as possible. tiCrypt heavily relies on end-to-end encryption to guarantee that data is maximally protected, ensuring that even system administrators do not have access to users’ data.

Advanced Security Features

• Public Key Signing and Chain of Trust: All public keys are digitally signed to ensure authenticity.
• Crowd Security: The client remembers the fingerprints of public keys to prevent user impersonation.
• Key Escrow: Advanced key recovery mechanism based on multi-party authentication.
• Secure Virtual Machines: Secure data processing using encrypted drives, connection to user data, and SSH tunnels.

Auditing and Monitoring Features

• Advanced Audits: tiCrypt provides detailed, efficient auditing and monitoring capabilities. tiCrypt's built-in audit tool can process hundreds of millions of entries per second; even large audit logs can be mined efficiently for usage patterns, compliance, and more.
• Compliance and Regulations: tiCrypt was built to meet organizations' sensitive data needs by complying with the major regulatory departments (HIPAA, FISMA, FIPS).

System Scalability

• Software Scalability: The tiCrypt software is designed to be completely scalable with its hosting hardware's capacity. The only limiting factor to the software's performance and scale is the size of the hardware on which it is deployed.

• Hardware Expansion Compatibility: Upgrading your Controlled Unclassified Information (CUI) system with tiCrypt is a straightforward process. It primarily involves expanding the hardware footprint by adding more servers to host virtual machines or enhancing the storage space on the distributed filesystem. tiCrypt is engineered to seamlessly scale and integrate with any hardware enhancements, making expansion a smooth and efficient process.

• Licensing Simplicity: To keep licensing simple and efficient, tiCrypt is offered under a single deployment license that covers the entire institution. This eliminates the need for license renegotiation or additional licensing fees as your CUI system expands. We aim to provide clarity and consistency in our licensing agreements, reducing administrative burdens.

Security Landscape, today!

tiCrypt's approach to the problem of securing a system is fundamentally different.

Across the globe, reports of hacks and data breaches have become commonplace in media headlines. No business is immune. In the last two years alone, high-profile companies with security budgets upwards of $150 million have seen their systems compromised and data breached. No amount of armed guards, sophisticated locks, firewalls, or intrusion detection systems effectively protects the system.

Traditional security systems primarily focus on three types of mechanisms: backend network security (VLANs, secure networks, etc.), perimeter defense (intrusion detection, firewalls, etc.), and security permission management (access control lists, business rules, etc.). The hope is that outside attacks are prevented by keeping the Perimeter secured.
By employing sophisticated permission management, the intent is to confine insiders to their data. The problem is that the perimeter defenses can be defeated or avoided altogether by an inside attack. Once an admin account is compromised, the perimeter defense and permission management offer no protection; there is little stopping the attackers from accessing all the information within the Perimeter. This reaffirms that traditional data security models, including perimeter defense, are fundamentally flawed. Each occurring breach, compromised server, or hijacked admin account mounts evidence against the traditional model.

Unfortunately, despite evidence mounting against the traditional model, businesses are reluctant to learn from their mistakes. The go-to response after a hack is to improve and strengthen security features to prevent the occurrence. This mentality evokes the unending cycle of poor solutions. Rethinking the fundamental approach to security is essential to correct this flaw and give companies the best chance of avoiding another incident.

The one thing the hackers (and arguably even governments) are not capable of breaching is strong encryption. If the data on the server is encrypted at all times with keys controlled by individual users, a data breach would reveal very little to an attacker. For this reason, the primary defense mechanism in tiCrypt is the reliance on user-controlled end-to-end encryption, not server security. When coupled with traditional defense mechanisms, tiCrypt offers a much more secure data storage, sharing, and processing solution. In effect, an attacker has to defeat both the encryption-based and the perimeter-based defenses to steal data–a much more challenging task for one to succeed.

Encryption on modern systems

While encryption has been long recognized as a good solution for data security, encryption is believed to be too inefficient for most situations, particularly for the client. With the implementation of hardware of the AES-256 algorithm on both Intel and AMD processors, encryption and decryption are greatly accelerated. 200-300 MB/second speeds are possible on laptops and 1GB/second on servers. tiCrypt takes advantage of these advances and incurs no significant penalty for the extensive use of encryption. Since encryption is feasible on the client, the server is unburdened by the need to perform such operations across the entire usable space. Furthermore, client encryption is highly desirable from a security standpoint since the server is the primary hacking target.

Key management using public key cryptography

One of the main problems when employing encryption is managing the encryption keys of various components. Key management becomes a severe problem if the user must remember passwords for each independent entity that needs to be encrypted. Even more importantly, secure sharing requires a secure hand-off of encryption keys to another party. Sending such keys through other means (email, phone, etc.) would significantly undermine the system's security. The elegant Solution tiCrypt uses is based on public key cryptography: each user, at account creation time, creates a public-private key pair. Secure hand-off of encryption keys to a second party is as easy as encrypting the resource key with the public key of the intended data recipient. Public-private key pairs for all participants can solve a much larger set of problems in a system like tiCrypt. In fact, all security features in tiCrypt are rooted in public key cryptography.

Secure components vs. End-to-end encryption

Regarding system security, the traditional approach is to secure each component independently, hoping that this will translate into good overall security. Typical security terms are network security (securing the network such that an attacker cannot snoop on the transmitted data), encryption-at-rest (securing the stored data through encryption so that storage devices cannot be accessed if removed from the system), and application security (securing the data while used by the application so that the information cannot be accessed by an attacker watching the application behavior). Security problems arise at the junction points and, more importantly, can be compromised by the users controlling the juncture points. tiCrypt's approach uses end-to-end encryption: data is encrypted by the user as early as possible and decrypted by the intended destination. No other participant, including admins and hackers, can decrypt the data, whether in transit, stored, or used by the application.

Strongly encrypt all data

A classic mistake is to allow multiple levels of security for the data. In tiCrypt, all data has the same security level, equivalent to top security. While this seems restrictive, powerful sharing mechanisms in tiCrypt allow easy sharing with a large number of other participants. Since differences in performance for performing strong encryption are minor (20% speed difference between AES-128 and AES-256), there is no practical reason to downgrade security, even for low-security resources.

The above ideas allow tiCrypt to provide extreme levels of data confinement. The access to each file, drive, or message is entirely under the control of the user that created the resource and independent of all other resources in the system. Without a cryptographically secure key exchange initiated by the data owner, nobody (including the system administrators) can effectively access the data. When coupled with advanced auditing facilities in tiCrypt, this property allows confinement and deep knowledge of any data leak. In the rest of this document, we discuss the properties of various mechanisms deployed in tiCrypt to ensure data security and confinement.

Security Principles

tiCrypt is based on three security principles: data confinement, public-key cryptography, and end-to-end encryption. Combining these principles is at the core of all tiCrypt security features.

Data Confinement Through Encryption

The key idea behind data confinement is to isolate resources from each other. In particular, knowledge about accessing a resource should not indicate how to access another. The traditional way to enforce data confinement is through access control lists (ACLs). The main drawback of ACLs is that administrators have complete control over them and can bypass any ACL-based mechanisms. Unfortunately, hackers impersonate admins who have the same power, thus effectively breaking data confinement.

tiCrypt primarily employs cryptographic methods to enforce data confinement. Each file, upon creation, gets encrypted with a unique, independently generated AES-256 key. These keys get encrypted with the public keys of the users (and groups) accessing the file and are then stored on the server. End-to-end encryption is performed before moving the data onto the server, while the decryption only occurs at the destination. The existence of an encrypted key on the server now serves the role of the ACL, but, more importantly, the file key can be recovered only if the private key is used.

File sharing is performed by a secure key exchange in the browser of the file owner (as opposed to a server operation):

• The encrypted key is accessed from the server.
• The encrypted key is decrypted using the owner's private key. Then the key is encrypted with the destination's public key.
• The key encrypted with the destination's public key is deposited on the server. Notice that this mechanism always keeps the private key on the owner's side; only public keys are available to all other users.

tip

With tiCrypt, each file or drive gets encrypted with a unique AES-256 key. These keys get encrypted with the public keys of the users (and groups) accessing the file. End-to-end encryption is performed before the data is moved onto the server, and the decryption occurs at the destination.

Public Key Cryptography

THE DEFINITION OF PUBLIC KEY CRYPTOGRAPHY

Public key cryptography uses two keys per user: a public key known to everyone and a private key known only to the particular user. For example, if user Tom wants to share a message with Jim, he uses Jim's public key to encrypt the message and send it securely. Decrypting the message requires knowledge of the private key, which only Jim has, making him the only user able to read the message. Until 1977, such public-private key schemes were believed to be impossible. Such cryptographic systems were introduced through the pioneering work of Rivest, Shamir, and Adleman. Mathematically, a public key cryptosystem needs a core problem that is easy to solve in one direction but hard in the other. In the case of RSA, multiplying primes is relatively easy, but factoring a product of large primes is very hard. The public key is a fixed exponent $e$ and the product of the primes $n= pq$. The private key is ${d = \dfrac{(p - 1)(q - 1)}{e}}$ and $n$.The public and private keys are opposites of each other: messages encrypted with one have to be decrypted with the other. Specifically, for $m$ a message, $m^e$ mod $n$ is the encrypted message; it can be decrypted by performing $d(m^e)$ mod $n = m$ mod $n$. Conversely, $d^m$ mod $n$ is a digital signature that can be verified by performing $e(d^m)$ mod $n = m$ mod $n$.

Beyond the mathematical details, two rules must be remembered when using any public key system. When data is first encrypted with the public key and decrypted with the private key, we call it process encryption. When data is first encrypted with the private key but decrypted with the public key, we call the process digital signature. tiCrypt uses both mechanisms to achieve secrecy and authentication.

USING PUBLIC KEY ENCRYPTION

Public key encryption is at the core of all security mechanisms used within the modern-day web. Parts or all of its principles are used, from banking to social media. Public key encryption principles allow:

• Checking the authenticity of a website through SSL certificates
• Establishing a secure communication channel with the web server
• Digitally signed and certified messages

Public key encryption removes the need for passwords or secrets to authenticate users, establish secure communication, or sign messages. The private key of the pair is now the means to achieve security. The pair's public key is made widely available and stored in plain text on servers, client computers, or even business cards. The magic of public key encryption is that everybody can encrypt using the public key, but only the private key holder can decrypt. Conversely, documents can be digitally signed using the private key, where the authenticity of the signature can be verified with the public key.

Of course, the larger the key, the more secure the data encrypted with that key is. It is estimated that it would take half a million desktop computers running for 13 billion years to derive the private key from an RSA-2048 public key. This is the type of key each user has within tiCrypt and the type recommended for government use by the NIST FIPS 140-2 publication.

tip

A digital signature scheme typically consists of 3 algorithms

1. A key generation algorithm selects a private key uniformly at random from a set of possible private keys. The algorithm outputs the private key and a corresponding public key.
2. A signing algorithm that, given a message and a private key, produces a signature.
3. A signature verifying algorithm that, given the message, public key, and signature, either accepts or rejects the message's claim to authenticity.

KEYS ALLOW FOR FEATURES

Since public key encryption is versatile, it makes sense to give each user a key. This allows users to do the following securely:

• Authenticate/Login: To authenticate, the user first enters the password to decrypt the private key stored on their computer. Next, the private key is used to sign a challenge generated by the server. Finally, the server checks the signature against the user's public key on the server. If it matches, the person has proven to hold the private key and is thus authenticated.
• Share Files: Sharing occurs without a file password/secret. Encrypting the file's symmetric key with the other user's public key ensures that only the recipient can decrypt their key to the file.
• Issue Certificates: Certificates are a list of instructions digitally signed using the private key. They entitle other users to perform operations on the owner's behalf.

End-to-end Encryption

End-to-end encryption refers to the security principle that requires the data to be encrypted as soon as possible and decrypted as late as possible. Only the intended recipient of the data should have the decryption keys and should perform the decryption just before they plan to use the data. In this form, end-to-end encryption ensures maximum data security since it reduces to a minimum the opportunity for an attacker.

• Since encryption occurs on the client side with a key controlled by the user, end-to-end encryption is possible and entirely under user control.
• Man-in-the-middle attacks, otherwise known as interception attacks, are prevented independently of SSL. Even if the SSL certificate is compromised, the communication is still secure.

End-to-end encryption is strictly more secure than encryption in transit because the files are not decrypted until the verified recipient views them. Encryption in transit allows admins and any hacker with access to the proper certificates to decrypt the files. In all cases, tiCrypt implements end-to-end encryption, even if the file is accessed or shared multiple times. Should a file be needed multiple times, it is decrypted multiple times with no copies residing in unsecured storage, each time implementing end-to-end encryption.

Advanced Security Features

tiCrypt has several advanced security features that address sophisticated attacks and allow key recovery under strict situations.

Public Key Signing and Chain of Trust

While using public key cryptography such as RSA-2048 ensures significant hardening of the system, there is still a considerable vulnerability an attacker can exploit: exchanging a user's public key with a public key controlled (i.e., for which the private key is known) by the attacker. Should a file be shared with the fake user, the attacker can decrypt the data. This attack requires a compromise of the server. It only applies to future file sharing (files shared with the correct key cannot be decrypted), but it is a vulnerability nonetheless. As a preventive measure, tiCrypt uses digital signatures in the following manner to ensure that fake keys cannot be substituted:

• The system uses a site key that is itself signed by a Tera Insights private key verifiable with a hardwired (in both the frontend and backend) public key. The site key is used to bootstrap the security of the entire software deployment. The public part of the site key is readily available to all parts of the system. Its integrity can be checked by checking the digital signature using the hardwired Tera Insights public key.

• The signed key upon creation signs the first super-admin key and its integrity can be checked using the site key.

• Any new account needs to be approved by an administrator. Upon approval, the public key associated with the account is signed by the individual approving (using their private key), thus cryptographically proving the account is valid. This effectively forms a chain of trust for each public key linking to the hardwired Tera Insights key.

• At any point in time, any user can require the digital signatures for the entire chain of trust and validate, on the client side, each key along the way. An attacker cannot inject a fake key unless it controls an administrator key.

Crowd Security

To further strengthen the public key integrity, tiCrypt employs a form of crowd security. In particular, the front end (usually the browser) will store locally, out of reach of the system administrators, fingerprints of the public keys of users previously interacted with. When a file is shared with a user, the tiCrypt frontend will request the user's public key from the server and check that the fingerprint is the same. tiCrypt uses SHA-256 as a secure fingerprinting technique, a NIST FIPS 140.2 recommended secure hashing scheme. The chain of trust combined with crowd security provides a formidable mechanism that is hard for any attacker to defeat. Any irregularity in the use of keys is likely to be discovered quickly, allowing any possibility for a leak to be removed.

Secure JavaScript Delivery

For high availability across platforms, the tiCrypt frontend is web-based and employs technologies such as HTML5, AngularJS, ASM-JS, etc. While this provides a modern, highly functional frontend, using web technologies opens a significant potential vulnerability: injecting malicious JavaScript code that steals private keys.

tiCrypt uses multiple mechanisms to mitigate the risk of compromised JavasScript:

• The tiCrypt frontend bundles up all dependencies and does not refer to outside JavaScript, CSS, or HTML resources. Compromising online JavaScript libraries would not affect packaged tiCrypt frontends.

• The tiCrypt frontend bundle is delivered as a digitally signed Zip archive. The digital signature keys are controlled by two top-level Tera Insights technology executives. This ensures the integrity and security of the JavaScript code.

• Because tiCrypt has multiple client-side configurations and content security checks, we provide users with an application, tiCrypt Connect. tiCrypt Connect serves the frontend locally and will automatically update it whenever it detects a new version. Additionally, clients control which tiCrypt versions are available to their users. Finally, tiCrypt Connect works in tandem with the front end to establish secure VM connections and ensure that all traffic is authenticated, locking down sessions if unauthenticated.

Key Escrow

Since the loss of a private key translates into a loss of data access in tiCrypt, a key recovery mechanism – key escrow – is needed to prevent data loss. In contrast, a key recovery mechanism that is too easy is a significant security risk. In tiCrypt, the key recovery using the escrow mechanism is designed to require the cooperation of multiple people to protect against individual key loss. Specifically, tiCrypt requires a minimum of three escrow keys to be used. These escrow keys need to be signed with the site key (not with any of the admin keys) and can be used exclusively for escrow activities (i.e., not for regular user activities). A user key is placed in escrow using the following mechanism:

1. When the user key needs to be (re)escrowed, the escrow keys with their digital signatures are downloaded from the server.
2. Digital signatures of all escrow keys are verified against the site key (which is itself previously verified against the hardwired key).
3. An AES-256 random key is generated for each escrow key and then encrypted with the corresponding escrow public key. These encrypted keys are stored on the server.
4. The combination of the AES-256 random keys, one for each escrow key, is used to encrypt the user's private key and then store it on the server.

tip

An essential part of this scheme is that the private keys cannot be recovered if any part is missing.

To recover the user's private key, all escrow key holders have to securely transfer their part of the key to a designated party. An essential part of this scheme is that the private keys cannot be recovered if any part is missing. Moreover, none of the escrow key holders can recover the key – only the designated party can.

Secure Virtual Machines

tiCrypt allows secure computation through the use of secure virtual machines. The specific mechanism employed is fundamentally different from existing cloud solutions. In particular:

• Securing at start-up: The VM controller will secure the VM during the start-up sequence by changing all passwords and blocking any ports except for port 22.

• Accessing VMs: For security reasons, virtual machines in tiCrypt cannot be accessed using traditional methods. In particular, direct connections to the VM console, SSH logins, or other remote server technology are not allowed since the admins can control it, and thus hackers impersonate them. The only means of communication is through a secure channel that only the owner of the VM can connect to via proxy within tiCrypt:

  • When a VM starts, it gets the owner's public key.
  • During secure channel setup, the VM and the user co-authenticate each other using the respective public and private keys.
  • A secret channel key is negotiated (Diffie-Helman protocol) and used for communication.

• Encrypted Drives: In order for the VM to perform efficient computation, it needs access to fast, secure storage. This is provided in the form of encrypted drives. When using encrypted drives, regular applications are secured since their input, output, and intermediate results are now protected by cryptography. The drive encryption keys are generated and manipulated in the same manner as the file keys. The user-VM encrypted channel transmits such keys to the VM during the start-up sequence. This way, the user fully controls the drive encryption; even admins are prevented from accessing the data.

• Access to the data store: The VMs can access the main data store through secure sub-sessions created by the client and file keys passed through the encrypted user-VM channel.

• Secure TLS-Based Tunnels: Using the user-VM secure channel, the VM controller can set up a proprietary FIPS-180 compliant TLS tunnel between the user's computer and the virtual machine. The TLS tunnel uses exclusively public-key-based login and temporary private keys. All traffic between a user's computer and the virtual machine is sent through this tunnel. Effectively, any communication between them is now possible with no possibility of snooping by any other party (including the system administrator). This method is even more restrictive than SSH, as the protocol does not allow any commands to be run on the remote machine.

• Restricted outbound Internet access: The VMs have severely restricted Internet access: only the tiCrypt backend and licensing servers can be accessed directly. The main reason is to protect against accidental or intentional information leaks. Even if a VM is hijacked, the only way to leak information is through the main vault, which is audited.

tip

Using secure virtual machines in tiCrypt, it is possible to run and securely communicate to remote versions of any Windows or Linux distributions. The virtual machines are cryptographically and physically isolated from the outside world; only the user has access through tiCrypt.

Principles of concern:

1. The most important principle is: VMs are owned by the user- a dedicated owner; and not by the admins. Compromising the admin doesn't give you implicit access to the resources in the system.
2. Authenticated network access is not dependent on measly passwords; but rather on highly controlled public key infrastructure.
3. No open ports on the VM to block everything implicitly.

Now comes the question, how is the VM usable if no ports are opened?

• By blocking all the ports, we essentially have a bunker at our hands, and we need a special mechanism to talk.
  This can be done by binding the VM with a public key, which is further bound to the user's public key. tiCrypt enables the communication between the front end and the VM by exchanging the secret using Diffie-Hellman plus Digital Signatures to facilitate co-authentication. This sets up a symmetric encryption key used for communication moving forward. Thus, as a consequence, a double encrypted channel is set up. tiCrypt uses encrypted web sockets; data is encrypted with the symmetric key. Rest encryption is achieved with the derived secret, and transport encryption is achieved with Diffie Hellman exchanged secret. The backend only comes into play during the first call, and post that, it never comes into the picture of communication between the front end and the VM. All snooping- whether from external actors or from the infrastructure is avoided.

• The mechanism mentioned above is completely password-less, but at times OS in VMs does demand the presence of passwords. In these minute use cases, passwords are always programmatically generated, quite complicated, and managed while being ephemeral in nature.

• Images used as a boot image are immutable and reset automatically on boot, providing an extra layer of security and eliminating any persistent internal risk.

Data Migration

Tera Insights has thoughtfully designed tiCrypt with a variety of secure data migration methods, giving users the flexibility to choose the most convenient option that aligns with their operational needs. Here are the three primary ways to securely transfer data into tiCrypt from external sources:

• Upload via Browser into Vault: This method allows for smaller files to be uploaded directly into the user’s Vault via the browser running the tiCrypt application.

• SFTP or Inbox Credentials: This method allows users to generate Secure File Transfer Protocol (SFTP) or Inbox credentials. With these credentials, external users can directly send files to the user's Vault in the tiCrypt system. This secure import mechanism uses the user’s public key to encrypt the files, ensuring that only the user who set up the SFTP or Inbox credentials can access and decrypt them. Notably, the tiCrypt SFTP server or Inbox can be hosted separately from the tiCrypt backend server. Once data is securely imported into the Vault, users can then move it to specific Virtual Machines (VMs) within the tiCrypt system.

• VM SFTP via tiCrypt Connect: If users have the tiCrypt Connect application running, they can generate SFTP credentials to directly transfer data into a VM. This process requires an active user account and the tiCrypt application running, as the connection to the VM and the proxy connections are managed and controlled by the application. This method provides an efficient direct path for data transfer into the desired VM.

• External Drive Builder: The tiCrypt Drive Builder tool allows users to create and populate virtual drives externally from the tiCrypt system. The user can sign and encrypt these drives using their public key. Once the virtual drive is ready, it can be copied over into the tiCrypt drive pool and made visible to the user. This option is particularly useful when dealing with large amounts of data, as it allows for bulk import.

• External Cloud Services (Dropbox, Google Cloud, OneDrive.): Users can link their external cloud service accounts to tiCrypt, facilitating a secure and direct one-way transfer of data into the user's Vault within the tiCrypt system. This method provides an easy and familiar route for users to import data, leveraging their existing cloud storage solutions. As with other methods, this process ensures the data remains secure during the transfer, maintaining the confidentiality and integrity of the data.

Each of these methods prioritizes security and user control, ensuring that data migration into tiCrypt is not only flexible and efficient but also maintains the integrity and confidentiality of the data throughout the process.

Infrastructure

The tiCrypt system consists of a back-end server and multiple servers that host virtual machines. Each of these servers acts as a service, performing independent actions, with the notable exception of services that rely on each other, like the file manager and storage. The system is designed to be resilient, ensuring that an error in one service does not affect the entire system.

tiCrypt is designed to run in isolation from other resources in your organization and to have strictly controlled entry points. The system utilizes a distributed file system to connect the main server with the VM servers.

tiCrypt can be deployed on new or existing hardware clusters as a private cloud solution for your researchers. Additionally, if a cloud option is preferred, tiCrypt can be deployed in AWS on BareMetal infrastructure.

System Requirements

1. Software Requirements:
   • RedHat Enterprise, CentOS, Rocky, or Springdale
   • Distributed file system tuned for specific system workflows
   • Java JRE version 8 or higher.
   • Libvirt and QEMU installed on all VM servers.
   • SSH installed on all VM servers (libvirt management uses SSH).

2. Network Requirements:
   • External connectivity: 1Gbit/s or better (10Gbit/s preferred).
   • Internal connectivity: 10Gbit/s or Infiniband (Infiniband preferred).
   • TLS connectivity for the REST interface and static assets.
   • A range of ports (10-100) for SSH Proxying opened on the public-facing server.
   • A firewall protecting the installation in front of the public server.

System REST Service

The system uses a central AUTH service for authentication. All requests and transactions go through AUTH to validate them. Users interact with the system through a REST service, which then delegates tasks to relevant services. For example, a request to start a VM will go through the REST service, be authenticated by AUTH, and then be sent to the VM service.

Three services - AUTH, FILE MANAGER, and VM - utilize and store data in a database. Each service has its specific configuration files that dictate the preferences related to the service. These files are stored in /etc/ticrypt and are named according to the service they correspond to.

Distributed File System & Storage

tiCrypt's storage management revolves around two primary components: the tiCrypt Vault and Encrypted Drives in Libvirt. Here is a concise overview of how these components function:

1. tiCrypt Vault

The tiCrypt Vault is an advanced file system-like facility. It maintains all metadata, such as file properties, directory entries, access information, and decryption keys, in a MongoDB database utilized by the tiCrypt-file storage service.

Files within the Vault are divided into 8MB chunks, each individually encrypted with a unique file key. These chunks are stored in a directory structure, accessible only to the tiCrypt backend. This setup ensures that without the corresponding decryption keys, the content of the chunk files remains indecipherable.

The tiCrypt Vault offers flexibility in terms of storage filesystem and integration with other systems. However, to ensure compliance, it is recommended to restrict access to only the tiCrypt backend.

2. Encrypted Drives in Libvirt

tiCrypt employs Libvirt to manage virtual machines' disk images and encrypted drives. These are stored as files in the distributed file system accessible to all Libvirt host servers. Libvirt, and by extension tiCrypt, is not particular about the choice of file system where various disk pools are defined.

Newly created tiCrypt disks are left blank, with their formatting deferred until their first attachment to a tiCrypt virtual machine. This process is a deliberate design decision to ensure that the encryption/decryption key for the encrypted drive remains confidential, even from the infrastructure, including the tiCrypt backend and Libvirt.

The formatting process is handled differently based on the underlying operating system:

• Windows: An NTFS file system is created, and BitLocker is immediately enabled, ensuring all subsequent data is encrypted. BitLocker uses full volume encryption, including metadata, limiting the information visible to external tools.
• Linux: The Linux Unified Key Setup (LUKS) full disk encryption mechanism is utilized. LUKS places an encryption block layer between the raw drive and the file system, usually EXT4, ensuring all information on the disk is encrypted.

Bootstrapping the System

The system uses a site key, signed by a Tera Insight’s private key, to bootstrap the security of the entire software deployment. The process involves the following steps:

• Generation of Site Key: The site key must be generated and handed over to Tera Insights for countersigning. This key is used to bootstrap the entire system and is a very important security component.
• Adding Escrow Groups: From the site key interface, escrow groups need to be added. These groups allow redundancy in key recovery efforts.
• Adding Escrow Users: Escrow users need to be added. These users allow key recovery in case of loss or malice.
• Creation of Super-admin Accounts: At least one, but preferably two, super-admin accounts have to be created. Super-admins coordinate the rest of the bootstrapping process, activate accounts, and change roles.

Combining tiCrypt with traditional defense mechanisms

Since tiCrypt is a software-based solution, it can be easily combined with traditional defense mechanisms like multi-factor authentication and perimeter defenses in order to provide extra layers of protection. An attacker must defeat all these mechanisms for a data breach, which is a much more challenging task.

• Multi-factor authentication:
  tiCrypt has very strong security; leaked private keys can still result in the loss of the information covered by the key. The attacker can use the stolen key to impersonate and access all user files. As an added layer of protection, extra authentication factors that are independent of tiCrypt keys and the passwords protecting them can be added to the system. Since, typically, organization-wide or token-based second-factor authentication is already in place, tiCrypt can leverage the existing mechanism as an extra authentication factor.

  The primary mechanism to accommodate extra authentication factors is to detect when the private key is used unusually. Specifically, if a key is used from a machine that was inactive for a set period by the same user or was never used, the tiCrypt authentication protocol will require the use of the extra factors to prove the authenticity of the request independently. If a private key is stolen and used from another computer, the second-factor mechanisms will catch that and still deny access.

• Perimeter and server defense:

  First, the tiCrypt deployment does not require regular user accounts on the hosting server; most server-side vulnerabilities are eliminated. Only system administrators need access to the server; thus, access can be highly restricted. Moreover, strong authentication based on SSH public keys can be deployed for management purposes, thus rendering most password-based vulnerabilities ineffective.

  Second, the server running the tiCrypt backend requires only two entry points: SSH access for management used exclusively by the administrators and HTTPS access for the tiCrypt interface. All other ports can and should be blocked to reduce the server's attack surface further.

  Third, tiCrypt is a software-based solution with encryption controlled by the client. It does not require special security appliances or unique setups on the server. All existing security mechanisms, like firewalls, intrusion detection, system auditing, etc., are compatible with tiCrypt and can be used to strengthen the server. Organizations can leverage all existing expertise in system security to add these extra layers of protection.

Threat Model and Solutions

With current events running rampant with news on cybersecurity attacks and hacks, we have researched cybersecurity breaches from 2007-2015 and analyzed why a specific breach was able to occur and how tiCrypt use would have prevented it.

Problem: Server Misconfiguration

Over a short time, one or multiple servers are misconfigured, not using two-factor authentication, or left unsecured. There are no formal systems to check for misconfigurations, and a server rebooting improperly is often enough to cause this problem.

Solution: In tiCrypt, if a server is misconfigured, it will lock the system. Breaking into the backend servers provides no benefit and is not helpful in any way to an attacker. Even if the authentication fails completely (for example, the authentication server somehow forgets to authenticate), the accessible data is useless without the private keys held only by the various users. In no scenario can tiCrypt leak present or future unencrypted data.

Problem: Insider Threats

If admins have access to all the data, any of them can steal before being noticed. Audit logs are useless since they require too many person-hours to review and keep up-to-date. Unless unforgeable audits are used for files, traditional records will not effectively serve as a deterrent. Even if everything is logged, a perfect solution for log analysis must be in place. Otherwise, it will be months before any rogue activity is noticed. Edward Snowden managed to steal tens of thousands of documents from a system with higher security than FISMA, all because he was a systems admin.

Solution: In tiCrypt , isolating the system administrators from the standard users is trivial. Based on the audit log, we can formally check that the system administrators do not have access to any user information. Since any legitimate access happens through the tiCrypt system, log mining will reveal any irregularity within minutes.

Problem: Authentication Attacks

The authentication server becomes another point of failure. If data in the system is valuable enough (medical data is valued at $50-500 per medical record), protecting the server becomes a serious problem. When using fake authentication certificates, anybody can be impersonated without any existing password cracking.

Solution: In tiCrypt, all public keys are digitally signed, and fingerprints of public keys are stored on the client for all users. An attacker cannot switch keys in an attempt to trick users into sharing information using keys controlled by the attacker. The fingerprinting is particularly hard to fool since this data is stored client-side, outside the server's reach.

Notice that a user attempting to share information with another user can validate the key of the destination even with a compromised server. The validity of the trust chain can be established independently of the server and cannot be compromised without breaking public key cryptography.

Problem: Zero Day Exploits

If zero-day exploits, which are undisclosed vulnerabilities that could be exploited, are found for any of the servers, data on that server can be stolen. If such exploits are found for the authentication server, data on all servers can be stolen. While audit logs help identify what was compromised, they do nothing to prevent the attack. If the security is based on foolproof authentication alone, this becomes very problematic. If the data on the server is valued at upwards of $10 million (as it often is when medical data is stored on the server), such high-end attacks are probable.

Solution: tiCrypt thwarts all backend attacks using end-to-end encryption, even if attackers controlled the servers for months. This is because the decryption keys are not available on the server; the server is never involved in either encryption or decryption of data. At worst, a breach of the server makes the system unavailable but not insecure.

Compliance and Monitoring

tiCrypt is built to be HIPAA, FISMA, and FIPS compliant. With the use of our high-powered data engine, tiCrypt's audit logs can be mined and reviewed for irregularities and suspicious activities. 30+ types of events are tracked at the millisecond time stamp level to ensure a complete record of all actions.

• Compliance within tiCrypt: tiCrypt was built to meet the needs of organizations with sensitive data. tiCrypt adheres to HIPAA, FISMA, NIST 800-71, and FIPS compliance requirements where appropriate. It is FIPS 140-2 certified in the Mozilla browser with FIPS mode enabled in settings. tiCrypt utilizes NIST 800-71 guidelines for access control, identification and authentication, and audit and accountability. The system has been certified by the University of Florida. For more compliance information or to request to view the System Security Plan (SSP), please contact info@terainsights.com.

• Secure Log Authentication: While protecting files against rogue employees and outside attacks is crucial, providing an audit trail of who accessed what information is essential. While most regulatory agencies mandate basic audits, tiCrypt goes beyond this minimum requirement and offers detailed, secure audits combined with forensic tools to analyze the logs.

• Securing the Log: Using secure hashing (SHA-256), log entries are chained much like Bitcoin transactions. Knowledge of the hashes ensures that admins or hackers cannot change or forge the history. Should anybody change the log entries, the hashing of the modified block will have a conflicting hash, making the change detectable upon running a log audit.

• Events Audited: More than thirty events are monitored in the Audit Logs, giving the System Admin a full profile of events:

  • Requesting, challenging, looking up, or deleting a certificate session or sub-session
  • Creating, deleting, renaming, adding, or removing a directory entry ƒƒ
  • Creating, deleting, or registering a proxy for virtual machines ƒƒ
  • Attaching, detaching, creating, or deleting a virtual drive – and adding, retrieving, or deleting a key to a virtual drive ƒƒ
  • Creating or deleting a file – and adding, retrieving, or deleting a key to a file – and reading or writing a chunk of the file
  • Creating, deleting, or modifying members and permissions of a group; Adding, deleting, or modifying permissions of a user

CMMC/CUI/NIST 800-171 Specific Information

Access Control

• Limiting System Access: tiCrypt limits system access to authorized users, processes acting on behalf of authorized users, and devices. Access to an account is deactivated by default upon registration, and it must be activated by an admin who assigns the account to a specific team and applies a permission profile to it. Direct connections to the virtual machines (VMs) are also prohibited, with the only allowed communication being through a secure channel within tiCrypt. Additional no user accounts (besides the tiCrypt user) reside on the infrastructure servers, limiting and restricting access to the physical hardware.

• Limiting Transaction Types: tiCrypt system limits access based on individual permissions. If a user does not have the permission to perform an action, the action will fail.

• Controlling CUI Flow: The tiCrypt system uses public-key cryptography and end-to-end encryption to control the flow of Controlled Unclassified Information (CUI). Each resource (like files, drives, and communication channels) uses an independent AES-256 encryption key. Additionally, each user creates an RSA-2048 key upon account creation that is used as the primary means of secure data control. Sys admins (like users) do not have access to any data in the system, unless a user explicitly shares the data or adds them to a virtual machine. This controls the CUI flow by only allowing those with explicit permission to have access to the data or virtual machine.

• Preventing Non-privileged Users from Executing Privileged Functions: tiCrypt limits the types of transactions and functions a user can execute based on their assigned permissions.

• Limiting Unsuccessful Login Attempts: tiCrypt limits the number of unsuccessful login attempts and uses exponential time between tries. After a certain number of unsuccessful attempts, the account is deactivated.

• Providing Custom Privacy and Security Notices: tiCrypt allows for configurable CUI login banners and Terms of Service acknowledgements on the login page and when a user logs into the system.

• Session Locks and Terminations: tiCrypt implements a session lock and termination based on the key timer in the system. After a specified period of inactivity, the key is purged from memory and the session is terminated.

• Remote Access Session Control: tiCrypt monitors and controls remote access sessions. Access to the VMs is restricted to a secure channel that only the owner of the VM can connect to, and the system establishes a proprietary FIPS-180 compliant TLS tunnel between the user's computer and the VM.

• Cryptographic Mechanisms for Remote Access: tiCrypt employs cryptographic mechanisms to protect the confidentiality of remote access sessions. The secure channel setup between the VM and the user employs public and private keys for co-authentication, and a secret channel key is negotiated for communication.

• Remote Access via Managed Access Control Points: tiCrypt routes remote access via managed access control points. The only allowed communication to the VMs is through a secure channel within tiCrypt.

• Authorization of Remote Execution of Privileged Commands: The tiCrypt system uses public-key cryptography to authorize remote execution of privileged commands and remote access to security-relevant information.

• Control Over Connections to External Systems: The tiCrypt system verifies and controls connections to and use of external systems. The system does not communicate with external systems except for licensing servers for VMs in a very specific and controlled way.

		Access Control (AC)
AC	AC-1	Access Control Policy and Procedures	Partially Implemented
AC	AC-2	Account Management	Implemented
AC	AC-2 (1)	Account Management / Automated System Account Management	Implemented
AC	AC-2 (2)	Account Management / Removal of Temporary / Emergency Accounts	Not Applicable
AC	AC-2 (3)	Account Management / Disable Inactive Accounts	Implemented
AC	AC-2 (4)	Account Management / Automated Audit Actions	Implemented
AC	AC-3	Access Enforcement	Implemented
AC	AC-4	Information Flow Enforcement	Implemented
AC	AC-5	Separation of Duties	Implemented
AC	AC-6	Least Privilege	Implemented
AC	AC-6 (1)	Least Privilege / Authorize Access to Security Functions	Implemented
AC	AC-6 (2)	Least Privilege / Non-Privileged Access for Nonsecurity Functions	Implemented
AC	AC-6 (5)	Least Privilege / Privileged Accounts	Implemented
AC	AC-6 (9)	Least Privilege / Auditing Use of Privileged Functions	Implemented
AC	AC-6 (10)	Least Privilege / Prohibit Non-privileged Users from Executing Privileged Functions	Implemented
AC	AC-7	Unsuccessful Logon Attempts	Implemented
AC	AC-8	System Use Notification	Implemented
AC	AC-11	Session Lock	Implemented
AC	AC-11 (1)	Session Lock / Pattern-Hiding Displays	Implemented
AC	AC-12	Session Termination	Implemented
AC	AC-14	Permitted Actions Without Identification or Authentication	Implemented
AC	AC-17	Remote Access	Implemented
AC	AC-17 (1)	Remote Access / Automated Monitoring / Control	Implemented
AC	AC-17 (2)	Remote Access / Protection of Confidentiality / Integrity Using Encryption	Implemented
AC	AC-17 (3)	Remote Access / Managed Access Control Points	Implemented
AC	AC-17 (4)	Remote Access / Privileged Commands / Access	Implemented
AC	AC-18	Wireless Access	Not Applicable
AC	AC-18 (1)	Wireless Access / Authentication and Encryption	Not Applicable
AC	AC-19	Access Control For Mobile Devices	Not Applicable
AC	AC-19 (5)	Access Control For Mobile Devices / Full Device / Container-Based Encryption	Not Applicable
AC	AC-20	Use of External Information Systems	Implemented
AC	AC-20 (1)	Use of External Information Systems / Limits on Authorized Use	Implemented
AC	AC-20 (2)	Use of External Information Systems / Portable Storage Devices	Implemented
AC	AC-21	Information Sharing	Implemented
AC	AC-22	Publicly Accessible Content	Implemented

Awareness and Training

• Training Videos: Tera Insights creates instructional videos for users and sys admins that explain how to use the system. These videos likely cover a wide range of topics, from basic system navigation and features to more advanced functionalities. These videos can be integrated into more general training modules for security and awareness.

• Deployment-Specific Training Modules: Tera Insights collaborates directly with the organization deploying the system to develop a training module tailored specifically to their needs and setup. This ensures that users understand not just the general functions of the system, but also how to use it effectively in their environment.

• Collaborative Effort and Knowledge Transfer Network: Universities collaborate with other organizations that have deployed tiCrypt to share training resources and learn from each other's experiences. This collaborative approach helps to ensure that all training materials are as thorough, up-to-date, and effective as possible.

Awareness and Training (AT)
Security Awareness and Training Policy and Procedures	Work with University
Security Awareness Training	Work with University
Security Awareness Training / Insider Threat	Work with University
Role-Based Security Training	Work with University
Security Training Records	Work with University

Auditing and Accountability

• Creation and Retention of System Audit Logs: tiCrypt creates a detailed audit trail of over thirty types of events, all tracked at the millisecond level. This allows for precise monitoring and analysis of all system activity. Log entries are secured using SHA-256 hashing, chaining entries much like Bitcoin transactions. This ensures the integrity of the records and that they cannot be changed or forged. Since tiCrypt never deletes any secure logging, it can re-create the entire history of the system in a matter of seconds. The system utilizes Clickhouse to process these logs in the Audit tool, enabling investigation and reporting of any unlawful or unauthorized activity.

• Separate Audit Platform: The audit platform is decoupled from the secure system, ensuring you can manage compliance and reporting without being a user in the secure system.

• Alerting in the Event of an Audit Logging Process Failure: The tiCrypt auditing tool has immediate alerting mechanisms that can be pushed into a central logging system (like Splunk). Alerts include, but are not limited to XSS detection, Role change, Account Deactivation, and geolocation login discrepancy.
• Correlation of Audit Records: tiCrypt's audit system includes security alerting, with alerts indicating actions within the system that may require immediate attention, such as a potential XSS attack, role change, or account deactivation. These alerts, along with the detailed audit logs, can be used for the correlation of audit records, allowing for thorough analysis and investigation of any suspicious or unusual activity. With the use of the tiCrypt Audit tool for log processing, the system can also generate immediate reports to support on-demand analysis and reporting.

• Synchronization of Internal System Clocks: tiCrypt tracks events at the millisecond time stamp level using the backends NTP server.

• Automated Report Generation: Compliance and system reports based on prebuilt or custom queries can be automated to ensure timely reporting.

• Protection of Audit Information and Tools: tiCrypt secures log entries using SHA-256 hashing, chaining entries to ensure that the history cannot be changed or forged. If any changes were made to the log entries, the hashing of the modified block would result in a conflicting hash, making the change detectable upon running a log audit. This protects the audit information from unauthorized access, modification, and deletion.

• Establishing and Maintaining Baseline Configurations and Inventories: The provided information does not explicitly state how tiCrypt establishes and maintains baseline configurations and inventories of systems throughout their life cycle. However, given the robust logging and monitoring capabilities of tiCrypt, it is reasonable to assume that it includes tools and methodologies to track and manage these aspects. This could be achieved through automated methods, such as periodically taking snapshots of the system configuration and keeping an inventory of all hardware, software, firmware, and documentation associated with the system.

		Audit and Accountability (AU)
AU	AU-1	Audit and Accountability Policy and Procedures	Partially Implemented
AU	AU-2	Audit Events	Implemented
AU	AU-2 (3)	Audit Events / Reviews and Updates	Implemented
AU	AU-3	Content of Audit Records	Implemented
AU	AU-3 (1)	Content of Audit Records / Additional Audit Information	Implemented
AU	AU-4	Audit Storage Capacity	Implemented
AU	AU-5	Response to Audit Processing Failures	Implemented
AU	AU-6	Audit Review, Analysis, and Reporting	Implemented
AU	AU-6 (1)	Audit Review, Analysis, and Reporting / Process Integration	Implemented
AU	AU-6 (3)	Audit Review, Analysis, and Reporting / Correlate Audit Repositories	Partially Implemented
AU	AU-7	Audit Reduction and Report Generation	Implemented
AU	AU-7 (1)	Audit Reduction and Report Generation / Automatic Processing	Implemented
AU	AU-8	Time Stamps	Implemented
AU	AU-8 (1)	Time Stamps / Synchronization with Authoritative Time Source	Implemented
AU	AU-9	Protection of Audit Information	Implemented
AU	AU-9 (4)	Protection of Audit Information / Access by Subset of Privileged Users	Implemented
AU	AU-11	Audit Record Retention	Implemented
AU	AU-12	Audit Generation	Implemented

Configuration Management

		Configuration Management (CM)
CM	CM-1	Configuration Management Policy and Procedures	Implemented
CM	CM-2	Baseline Configuration	Implemented
CM	CM-2 (1)	Baseline Configuration / Reviews and Updates	Implemented
CM	CM-2 (2)	Baseline Configuration / Automation Support for Accuracy / Currency	Not Applicable
CM	CM-2 (3)	Baseline Configuration / Retention of Previous Configurations	Implemented
CM	CM-2 (7)	Baseline Configuration / Configure Systems, Components, or Devices for High-Risk Areas	Implemented
CM	CM-3	Configuration Change Control	Implemented
CM	CM-3 (2)	Configuration Change Control / Test / Validate / Document Changes	Implemented
CM	CM-4	Security Impact Analysis	Implemented
CM	CM-5	Access Restrictions for Change	Implemented
CM	CM-6	Configuration Settings	Implemented
CM	CM-7	Least Functionality	Implemented
CM	CM-7 (1)	Least Functionality / Periodic Review	Implemented
CM	CM-7 (2)	Least Functionality / Prevent Program Execution	Implemented
CM	CM-7 (4)	Least Functionality / Unauthorized Software / Blacklisting	Implemented
CM	CM-7 (5)	Least Functionality / Unauthorized Software / Whitelisting	Implemented
CM	CM-8	Information System Component Inventory	Implemented
CM	CM-8 (1)	Information System Component Inventory / Updates During Installations / Removals	Implemented
CM	CM-8 (3)	Information System Component Inventory / Automated Unauthorized Component Detection	Planned
CM	CM-8 (5)	Information System Component Inventory / No Duplicate Accounting of Components	Implemented
CM	CM-9	Configuration Management Plan	Implemented
CM	CM-10	Software Usage Restrictions	Implemented
CM	CM-11	User-Installed Software	Implemented

Provide information on any built-in system real-time analysis or enforcement of security configuration settings for information technology products employed in organizational systems.

Access/Software/Network Restrictions

• Enforcing Physical and Logical Access Restrictions: tiCrypt employs a robust mechanism to enforce access restrictions. The system blocks all ports, creating a secure environment and facilitating communication through public key binding. The communication between the front-end and VM is enabled by exchanging secrets using Diffie-Hellman and Digital Signatures, which sets up a double encrypted channel. This mechanism is password-less and ensures secure communication, mitigating risks from external actors or infrastructure.

• Identifying and Authenticating System Users, Processes, and Devices: Authentication and digital signature challenges in tiCrypt are executed with the user's private key pair, which is in the user's possession.

• Implementing Multifactor Authentication: The MFA integration in tiCrypt works by obtaining the user's email and IP, generating a timestamp, and creating a digitally signed message containing this information. This message is then delivered to the tiCrypt frontend. The 2FA server is isolated from the tiCrypt server, enhancing the security of the system.

• Employing Replay-Resistant Authentication Mechanisms: tiCrypt employs the NIST 800-63 Challenge Based Authentication protocol, which uses large, randomly generated, non-reusable challenges for authentication. This mechanism prevents the replay of previous authentication events to gain access.

• Preventing Reuse of Identifiers: tiCrypt relies on the reuse prevention of the institution's authentication system. However, tiCrypt uses but does not trust the institution's authentication, requiring both MFA and digital signature authentication.

• Disabling Identifiers After a Defined Period of Inactivity: tiCrypt features a configurable inactivity period that automatically deactivates accounts after a specified amount of time.

• Enforcing Minimum Password Complexity and Change of Characters: tiCrypt enforces password complexity for the password that protects the user's private key. The backend system doesn't store any information that can be used to brute force this key.

• Allowing Temporary Password Use for System Logons: tiCrypt doesn't use passwords for authentication.

• Storing and Transmitting Only Cryptographically Protected Passwords: tiCrypt's security is based on public-key cryptography. Passwords are only transmitted when users interact with VM hosted operating systems, and in these cases, they are encrypted.

• Obscuring Feedback of Authentication Information: tiCrypt ensures that the backend and front-end are separate and distrust each other. Decryption of the key occurs on the client-side.

		Identification and Authentication (IA)
IA	IA-1	Identification and Authentication Policy and Procedures	Implemented
IA	IA-2	Identification and Authentication (Organizational Users)	Implemented
IA	IA-2 (1)	Identification and Authentication (Organizational Users) / Network Access to Privileged Accounts	Implemented
IA	IA-2 (2)	Identification and Authentication (Organizational Users) / Network Access to Non-Privileged Accounts	Implemented
IA	IA-2 (3)	Identification and Authentication (Organizational Users) / Local Access to Privileged Accounts	Implemented
IA	IA-2 (8)	Identification and Authentication (Organizational Users) / Network Access to Privileged Accounts - Replay Resistant	Implemented
IA	IA-2 (9)	Identification and Authentication (Organizational Users) / Network Access to Non-Privileged Accounts - Replay Resistant	Implemented
IA	IA-2 (11)	Identification and Authentication (Organizational Users) / Remote Access - Separate Device	Not Applicable
IA	IA-2 (12)	Identification and Authentication (Organizational Users) / Acceptance of PIV Credentials	Not Applicable
IA	IA-3	Device Identification and Authentication	Implemented
IA	IA-4	Identifier Management	Implemented
IA	IA-5	Authenticator Management	Implemented
IA	IA-5 (1)	Authenticator Management / Password-Based Authentication	Implemented
IA	IA-5 (2)	Authenticator Management / PKI-Based Authentication	Not Applicable
IA	IA-5 (3)	Authenticator Management / In-Person or Trusted Third-Party Registration	Implemented
IA	IA-5 (11)	Authenticator Management / Hardware Token-Based Authentication	Implemented
IA	IA-6	Authenticator Feedback	Implemented
IA	IA-7	Cryptographic Module Authentication	Implemented
IA	IA-8	Identification and Authentication (Non-Organizational Users)	Implemented
IA	IA-8 (1)	Identification and Authentication (Non-Organizational Users) / Acceptance of PIV Credentials from Other Agencies	Not Applicable
IA	IA-8 (2)	Identification and Authentication (Non-Organizational Users) / Acceptance of Third-Party Credentials	Not Applicable
IA	IA-8 (3)	Identification and Authentication (Non-Organizational Users) / Use of FICAM-Approved Products	Not Applicable
IA	IA-8 (4)	Identification and Authentication (Non-Organizational Users) / Use of FICAM-Issued Profiles	Not Applicable

Risk Assessment

Risk Assessment (RA)
Risk Assessment Policy and Procedures	Implemented
Security Categorization	Implemented
Risk Assessment
Vulnerability Scanning	Implemented
Vulnerability Scanning / Update Tool Capability	Implemented
Vulnerability Scanning / Update by Frequency / Prior to New Scan / When Identified	Implemented
Vulnerability Scanning / Privileged Access	Implemented

System and Communications Protection

• Protection at Boundaries: tiCrypt employs end-to-end encryption with unique AES and RSA keys for each resource, meaning that data is encrypted at the source and can only be decrypted by the intended recipient. This ensures the protection of data at external and key internal boundaries.

• Separation of User and System Management Functionality: tiCrypt has provisions to isolate system administrators from the standard users. System administrators do not have access to any user information, ensuring a clear separation between user functionality and system management.

• Prevention of Unauthorized Information Transfer: tiCrypt's end-to-end encryption ensures that even if data is accessed, it is useless without the correct decryption keys, which are only held by the intended recipient. This ensures unauthorized and unintended information transfer via shared system resources is prevented.

• Cryptographic Mechanisms: tiCrypt uses robust cryptographic mechanisms (public-private key cryptography) for data transmission. All public keys are digitally signed and the fingerprints are stored client-side, making it difficult for unauthorized parties to intercept and decipher the transmitted data.

• Network Connection Termination: Though it's not explicitly mentioned, most systems like tiCrypt have provisions for network connection termination at the end of sessions or after a defined period of inactivity to maintain security.

• Cryptographic Key Management: In tiCrypt, the public keys of users are stored client-side, and the server doesn't have access to them. This ensures that even if the server is compromised, the keys remain safe.

• Mobile Code Control and Monitoring: The tiCrypt front-end bundles up all dependencies and does not refer to outside JavaScript, CSS, or HTML resources. Compromising online JavaScript libraries would not affect packaged frontends. The tiCrypt front-end bundle is delivered as a digitally signed .zip archive. The digital signature keys are controlled by two top-level Tera Insights technology executives. This ensures the integrity and security of the JavaScript code. tiCrypt has multiple client-side configurations and content security checks, we provide users with an application, tiCrypt Connect. tiCrypt Connect serves the front-end locally and will automatically update it whenever it detects a new version. Additionally, clients control which tiCrypt versions are available to their users. Finally, tiCrypt Connect works in tandem with the front end to establish secure VM connections and to ensure that all traffic is authenticated, locking down sessions if unauthenticated.

• Authenticity of Communication Sessions: Digital signatures and client-side fingerprinting of public keys help maintain the authenticity of communication sessions.

• Protection of CUI at Rest: The end-to-end encryption mechanism ensures that the data at rest is encrypted and can only be accessed by authorized users with the correct decryption keys.

• Malicious Code Protection: While it's not explicitly mentioned, systems like tiCrypt typically have robust security measures to prevent the execution of malicious code.

• Automated Monitoring: tiCrypt has a high-powered data engine to mine and review audit logs for irregularities and suspicious activities. 110+ types of events are tracked to ensure complete security.

• Updates and Malicious Code Protection Mechanisms: The document doesn’t explicitly mention how updates are handled and how new releases of malicious code protection mechanisms are integrated into the system.

• System Monitoring Controls: tiCrypt's powerful data engine mines and reviews audit logs, tracking 30+ types of events to monitor the system effectively.

• Unauthorized Use Identification and Reporting: Any irregularity in the system access can be identified and reported within minutes using tiCrypt's alert system. Unauthorized use, therefore, becomes easier to spot and act upon.

	System and Communications Protection (SC)
SC-1	System and Communications Protection Policy and Procedures	Implemented
SC-2	Application Partitioning	Implemented
SC-4	Information in Shared Resources	Implemented
SC-5	Denial of Service Protection	Implemented
SC-7	Boundary Protection Implemented	Implemented
SC-7 (3)	Boundary Protection / Access Points	Implemented
SC-7 (4)	Boundary Protection / External Telecommunications Services	Not Applicable
SC-7 (5)	Boundary Protection / Deny by Default / Allow by Exception	Implemented
SC-7 (7)	Boundary Protection / Prevent Split Tunneling for Remote Devices	Implemented
SC-8	Transmission Confidentiality and Integrity	Implemented
SC-8 (1)	Transmission Confidentiality and Integrity / Cryptographic or Alternate Physical Protection	Implemented
SC-10	Network Disconnect	Implemented
SC-12	Cryptographic Key Establishment and Management	Implemented
SC-13	Cryptographic Protection	Implemented
SC-15	Collaborative Computing Devices	Implemented
SC-17	Public Key Infrastructure Certificates	Implemented
SC-18	Mobile Code	Implemented
SC-19	Voice Over Internet Protocol	Not Applicable
SC-20	Secure Name / Address Resolution Service (Authoritative Source)	Implemented
SC-21	Secure Name / Address Resolution Service (Recursive or Caching Resolver)	Implemented
SC-22	Architecture and Provisioning for Name / Address Resolution Service	Implemented
SC-23	Session Authenticity	Implemented
SC-28	Protection of Information at Rest	Implemented
SC-39	Process Isolation	Implemented

Maintenance

• General Maintenance on this System: Tera Insights works with each deployment ensuring that the latest patches are made available during their monthly patch window.

• Multifactor Authentication for Nonlocal Maintenance Sessions: tiCrypt supports MFA, and it is strongly recommended for all deployments. If configured to use MFA, all user accounts are protected, with no opt-out option.

• Supervision of Maintenance Activities: The tiCrypt audit system permits supervision of all activities and is separated from the main system, without access to the main system.

Maintenance (MA)
System Maintenance Policy and Procedures	Partially Implemented
Controlled Maintenance	Planned
Maintenance Tools	Implemented
Maintenance Tools/Inspect Tools	Implemented
Maintenance Tools / Inspect Media	Implemented
Nonlocal Maintenance	Implemented
Nonlocal Maintenance / Document Nonlocal Maintenance	Implemented
Maintenance Personnel	Implemented
Timely Maintenance	Implemented

Media Protection

• Protection of System Media Containing CUI: In tiCrypt, all data, is end-to-end encrypted. The keys for the encryption are never available at the infrastructure level (servers, distributed file systems, network messages, etc.). While tiCrypt doesn't directly support paper asset protection, it has a comprehensive user interface and integration with various workflows, reducing the need for paper assets.

• Limiting Access to CUI on System Media: tiCrypt not only limits access to data to authorized users but also adheres to the principle of least privilege, enforced cryptographically. Access to data always requires explicit cryptographic key sharing or digital signature-based authentication, both of which require the user's private key. Moreover, infrastructure hosting Secure VMs doesn't have direct access to data, as it always resides on encrypted virtual drives, with drive keys available only within Secure VMs controlled by the data owner.

• Sanitization or Destruction of System Media Containing CUI: All data in the tiCrypt system is end-to-end encrypted and always protected. This means there's no need for any additional measures for media destruction, as the data can only be decrypted by the data owner.

• Cryptographic Mechanisms for Protecting CUI during Transport: tiCrypt uses end-to-end encryption for all assets, with keys controlled by the data owner. Each asset (file, drive, etc.) is encrypted with a generated AES-256 key managed using the data owner's RSA-2048 public-private key pair. This ensures encryption during transport, and at rest since the data can only be decrypted by the data owner.

	Media Protection (MP)
MP-1	Media Protection Policy and Procedures	Implemented
MP-2	Media Access	Implemented
MP-3	Media Marking	Implemented
MP-4	Media Storage	Implemented
MP-5	Media Transport	Not Applicable
MP-5 (4)	Media Transport / Cryptographic Protection	Implemented
MP-6	Media Sanitization	Implemented
MP-7	Media Use	Implemented
MP-7 (1)	Media Use / Prohibit Use without Owner	Implemented