Larger projects with many users require effective management at scale in tiCrypt. In a scaling scenario, both admins and super-admins must know how to:

• Manage multiple users simultaneously in a large number of projects.
• Make bulk changes in the user's status.
• Adopt global changes in the system when needed.
• Manage bulk changes in the tiCrypt backend.
• Proactively make use of bulk VM actions.

In this blog, we provide a set of tiCrypt features that allow you to streamline the process to maintain a significant number of projects at scale.

Global Management at Scale

Most of the time, the System Admins and Project Investigators take over the extensive project responsibilities. The scope of global management is to perform bulk actions with less effort and to enhance data consistency, avoiding human error.

The Management tab allows admins and project managers to be creative about their projects. Many of the tiCrypt features were designed to leverage power to the management teams allowing various bulk actions to occur.

Make Global Announcements​

Before deploying large projects to all admins or sub-admins may be required to set up a management infrastructure. The global announcement feature allows Project Managers and Admins to send secured global messages within the system.

To make a global announcement to all users or admins navigate to the Management tab in the Users section.

• Click the Make announcement button in the top left corner.
• Follow the instructions from Make Global Announcement section.

Management User Profiles​

The User Profiles in Management tab is a powerful tool for creating personas. They are a way to tag users without altering their default permissions settings.

Scenario: Suppose you manage a large project with 1000+ users.

You must organize the users in categories based on your management requirements, project compliance and level of access. It is tedious and time-consuming to organize 1000+ users manually.

As a result, tiCrypt allows you to use the User Profiles feature to create your own user/admin avatar. Each user profile includes custom roles and permissions to allow unique actions and events during the project deployment.

Once the user profiles are created, they can be applied in bulk to project or team members, whichever is the case.

To create a user profile navigate to Management tab in the User Profiles section.

• Click the Create new user role button in the top right.
• Follow the instructions from Create User Profile section.

Apply Profiles in Bulk​

Once you built your desired user profiles in management, you can apply them to users in bulk.

To apply profiles to users navigate to Management tab in the Users section.

• Select the users you would like to apply profiles to.
• Click the Apply profile button in the top right.
• Follow the instructions from Apply Profile section.

Bulk Email​

In a large project, communication is crucial. tiCrypt offers alternative ways to communicate via email, allowing admins to Copy all project member emails or Download them at a click of a button.

To bulk email users navigate to the Management tab in the Users section.

• Select the users you would like to bulk email.
• Click the Bulk-email button in the top right.
• Follow the instructions from Bulk Email section.

Bulk Refresh Users Information​

If a large number of Users is updated at different times and you want to build a report of them for audit purposes. You can use this option to bulk refresh all user data.

To bulk refresh users information navigate to Management tab in the Users section.

• Select the users you would like to refresh information for.
• Click the Refresh user(s) info button in the top right.
• Follow the instructions from Refresh User Info section.

Add Multiple Certifications​

Adding multiple certifications at once can automate management efforts. This feature allows admins and project managers to certify multiple users for a security requirement within a security level of a tagged (classified) project.

To add multiple user certifications to users navigate to Management tab in the Users section.

• Select the users you want to add the certifications to.
• Click the Add certification button in the top right.
• Follow the instructions from Add Certification section.

Bulk Mark Certifications as Expired​

Whenever a project requirement changes or is updated, admins and project managers can turn off the access for all project members to a security level by marking their certifications as expired.

To mark multiple user certifications as expired navigate to Management tab in User Certifications section.

• Select the user certifications you want to mark as expired.
• Click Mark as expired in the top right.
• Follow the instructions from Mark Certification As Expired section.

Add Multiple Users to a Project​

Significant project processes may require adding many users to a project; this can be achieved using the bulk Add to project option.

To add multiple users to a project navigate to Management tab in the Users section.

• Select the users you want to add to a project.
• Click the Add to project(s) button in the top right.
• Follow the instructions from Add to Project section.

Add Users to Multiple Projects​

Large projects with multiple subprojects may require admins and project managers to add many users with similar roles in the projects. This action can be sped up using the Add members to projects option.

To add multiple users to many projects navigate to Management tab in the Projects section.

• Select the projects you would like to add users to.
• Click the Add memeber(s) button in the top right.
• In the prompt, type the name of the members you want to add to the selected projects.
• Click the Add button on the right.
• Scroll down then optionally, type an expiration date for the users in the project.
• Next, select user roles in the projects.
  • Select user restrictions in the projects.
  • Select whether you want to skip or update their expiration in the projects.
• Click Save.

Assign Subadmins to Multiple Projects​

Successful project managers and admins are often supported by successful sub-admins. tiCrypt allows admins to assign projects in bulk to sub-admins.

To assign a projects to subadmins navigate to the Management tab in the Projects section.

• Select the projects you want to assign to the sub-admins.
• Click the Assign project to Sub-admin(s) button in the top right.
• Follow the instructions from Assign Projects to Subadmins via Projects section.

Change Roles in Bulk​

Changing roles to multiple users may be a rare scenario. However, tiCrypt allows admins and super-admins roles to change other users' roles simultaneously.

To change the users roles navigate to Management tab in the Users section.

• Select the users you would like to change the roles of.
• Click the Change role button in the top right.
• Follow the instructions from Change Role section.

Change States in Bulk​

In the case when users leave the organization indefinitely, you can change their states to inactive in bulk. This option also helps you to onboard new users by setting in bulk their states to active and escrow on the next login.

To change state of users navigate to Management tab in the Users section.

• Select the user(s) you would like to change state of.
• Click the Change state button in the top right.
• Follow the instructions from Change State section.

Disable Multiple Accounts Until​

When multiple users have gone on holiday or overseas, certain compliance factors may require you to prevent their access to the project. You can use the Disable account until option to pause their access for a limited time and automatically resume it later.

To disable users account until a specified date navigate to Management tab in the Users section.

• Select the user(s) you want to disable the account of.
• Click the Disable account until button in the top right.
• Follow the instructions from Disable Account Until section.

Bulk Delete Objects​

As a super-admin, you can bulk delete the majority of the objects in tiCrypt; however, you cannot delete anything that is cryptographically enhanced (i.e., Groups, VMs, Drives, Etc.) unless you are the owner of them.

To bulk delete any objects navigate to any of the following tabs Vault,Management,Virtual Machines in any section or sub-tab.

• Select the object you would like to delete.
• Click the Delete button usually in the top right.
• In the prompt, click Delete.
• Alternatively, click Yes to confirm the deletion.

Bulk Export in JSON or CSV​

Admins and project managers can bulk export data in JSON or CSV format in the Management and Virtual Machines tabs. The export options are globally displayed for most tiCrypt objects.

To bulk export in JSON or CSV any objects navigate to any of the following tabs Management,Virtual Machines in any section or sub-tab.

• Select the object you would like to export.
• Click either the CSV Export option or the JSON Export option.
• Finally, click one of the following export quantities:
  • All items.
  • Visible items.
  • Selected items.

Bulk Change Host States​

Changing host states in bulk is to manage how extensive VMs infrastructure would connect to them. When hosts may need maintenance or updates that require all VMs to be disconnected from them, super-admins can use this option.

To change the state of a host navigate to the Management tab in the Hosts section.

• Select the host you would like to change the state of.
• Click the Change state button in the top right.
• Follow the instructions from Change Host State section.

Bulk Check Host Utilizations​

The Check host utilization option is bulk by default. This checks all hosts of the system, allowing super-admins to verify the flow of resources in the host.

To check utilization of a host navigate to the Management tab in the Hosts section.

• Select the host where you would like to check the utilization.
• Click the Check utilization button in the top right.
• Follow the instructions from Check Host Utilization section.

Bulk Shutdown VMs by Hosts​

Similarly to admins changing host states to inactive, you can bulk shut down VMs by hosts. This action allows for a complete shutdown of all VMs of a host in urgent situations.

To shutdown all VMs of a host navigate to the Management tab in the Hosts section.

• Select the hosts where you would like to shut the VMs down.
• Click the Shutdown all VMs button in the top right.
• Follow the instructions from Shut Down All VMs in Host section.

Bulk Manage Hardware Setups Access​

To bulk manage access in VM Hardware Setups navigate to the Management tab in the Hardware Setups section.

• Select the VM Hardware Setups you would like to manage the access of.
• Click the Manage Access button in the top right.
• Follow the instructions from Manage Hardware Setups Access section.

Bulk Change Hardware Setups Images​

To bulk change the image in VM Hardware Setups navigate to the Management tab in the Hardware Setups section.

• Select the VM Hardware Setups you would like to change the image of.
• Click the Change Image button in the top right.
• Follow the instructions from Change Hardware Setups Images section.

Bulk Replace Hardware Setups Instructions​

To bulk replace instructions in VM Hardware Setups navigate to the Management tab in the Hardware Setups section.

• Select the VM Hardware Setups you would like to replace the instructions for.
• Click the Replace Instructions button in the top right.
• Follow the instructions from Replace Hardware Setups Instructions section.

Bulk Set Projects in Running VMs​

Some significant projects demand multiple VMs to be connected to them. You can bulk tag numerous VMs to a project simultaneously.

To set projects in running VMs navigate to the Management tab in the Running VMs section.

• Select the running VMs to which you would like to set the projects.
• Click the Set Project button in the top right.
• Follow the instructions from Set Projects in Running VMs section.

Bulk Shut Down Running VMs​

When a project is complete and data is saved on drives, the VMs are no longer in use hence you can bulk shut down them.

To shut down running VMs navigate to the Management tab in the Running VMs section.

• Select the connected VMs you want to shut down.
• Click the Shut down button in the top right.
• Follow the instructions from Shut Down Running VMs section.

Bulk Power Up Service VMs​

When starting a large project, VMs in place for service may be powered up simultaneously.

To bulk power up Service VMs navigate to the Management tab in the Service VMs section.

• Select the service VMs you would like to power up.
• Click the Power Up button in the top right.
• Follow the instructions from Power Up Service VMs section.

Bulk Fetch Libvirt XML description of Service VMs​

Super-admins can view the difference between each Service VMs's XML description.

To bulk fetch the Libvirt XML description navigate to Virtual Machines tab, in the Virtual Machines section.

• Select the connected VMs you want to view the Libvirt XML description of.
• Click the Three dots button in the top right.
• In the prompt, click the Libvirt XML Description option.
• Follow the instructions from View Libvirt XML Description of Running VMs section.

Bulk Restart Controllers of Service VMs​

Service VMs controllers may be restarted in bulk to fix errors or update changes in the VM controllers.

To restart controller in Service VMs navigate to the Management tab in the Service VMs section.

• Select the service VMs you would like to restart the controllers of.
• Click the Restart button in the top right.
• Follow the instructions from Restart Controller section.

Bulk Execute Snapshot (Incremental) Backups​

To perform a bulk incremental backup navigate to the Management tab in the Backup Domains section.

• Select the domains you want to perform the backups for.
• Click Snapshot (incremental backup) in the top right.
• Follow the instructions from Perform Domain Incremental Backup section.

Bulk Execute Checkpoint (Full) Backups​

To perform bulk full backup navigate to the Management tab in the Backup Domains section.

• Select the domains you want to perform the backups for.
• Click Checkpoint (full backup) in the top right.
• Follow the instructions from Perform Domain Full Backup section.

Bulk Check Backup Domains​

When using the Check backup domain option, the system automatically checks all backup domains for any errors and then notifies you via the task tray on the bottom right.

To perform a bulk check backup domain, navigate to the Management tab in the Backup Domains section.

• In the top right panel, view the options.
• Click Backup Domain Check button in the top right.
• Follow the instructions from Perform Backup Domain Check section.

Bulk Create Deletion Request of Escrow Users​

In the case when an entire group of escrow users is changed, you can bulk-create deletion requests and follow the process from Delete Escrow Users section to execute the deletion appropriately.

To delete an escrow user from the system navigate to the Management tab in the Escrow Users section.

• Select the escrow user you would like to delete.
• Click the Create deletion request button in the top right.
• Follow the instructions from Delete Escrow Users section.

Bulk Execute Signed Certificates​

A similar situation applies to bulk-executing signed certificates. Super-admins have permission to bulk upload the site-key admin-signed certificates into tiCrypt.

To bulk upload a signed certificate navigate to Management tab in the Escrow Certificates section.

• Click the Execute Signed Certificates button in the top right.
• Follow the instructions from Upload Escrow Certificates section.

Bulk Attach & Mount Drives to VM​

tiCrypt allows users to bulk attach and mount unlimited drives to a VM. This action is possible due to flexible infrastructure and functionality.

You can attach either read-only or read-write drives.

To attach a drive in read-only or read-write mode navigate to the Virtual machines tab in the Virtual Machines section.

• Select the Virtual machine you want to attach the drives to.
• Scroll down and click the Drive Management card.
• Click the Attach drive(s) button in the top center.
• Follow the read-only or read-write mode instructions from Attach more drives in a Running VM section.

Bulk Change Project Tag in Drives​

To change project in a drive navigate to the Management tab in the Drives section.

• Select the drive you would like to change the project for.
• Click the Change project button in the top right.
• Follow the instructions from Change Project in Drive section.

Bulk Add Users to a VM​

Adding multiple users to a VM is a frequent action in project management.

To bulk add users to a VM configuration navigate to Virtual Machines tab, in the Virtual Machines section.

• Select the virtual machine you want to add users to.
• Click the User Management card on the right panel.
• Click the Add User(s) button at the top panel.
• Follow the instructions from [Add Users to VM]](https://ticrypt.com/docs/frontend2/tiCrypt-frontend/user-role/virtuals/v-vm-configs#add-users-to-vm-configuration) section.

Unshare Drives from Everyone Else​

You can unshare drives from all users simultaneously. This action allows the owner of the drive to keep a drive private to themselves.

To unshare a drive with everyone navigate to the Management tab in the Drives section.

• Select the drive you would like to unshare.
• Click the Unshare from everyone else button in the top right.
• Follow the instructions from Unshare Drives with Everyone section.

Bulk Transfer via SFTP​

Research data at scale is necessary for large projects. A simple way to transfer large amounts of data into the projects is via SFTP methods. Before you make a transfer, you must create an endpoint for your data to land on.

To create an SFTP endpoint navigate to the My Vault tab in the My Files section.

• Select an existing directory you want to turn into an SFTP inbox.
• Click the Manage Inbox icon in the top right center.
• Follow the instructions from SFTP Overview section.

VM Management at Scale

The Virtual Machines can work in bulk to achieve complex tasks at scale. You can use the following features by accessing the Management tab or the Virtual Machine tab.

Virtual Machines User Profiles​

The User Profiles in Virtual Machines tab is a powerful tool to create personas within the virtual machines realm. They are a way to tag virtual machine users by changing their permissions in the VM.

Scenario: Suppose you manage an extensive VM infrastructure where you have a vast number of users. You are advised to leverage the VM profiles to organize the user's permission and level of control within the VMs and Drives.

• Despite the user roles in the system, you can flexibly create a VM user profile.
  • Eg1: super-admins of the system may be standard VM users if they belong to a VM User Profile designed for that purpose.
  • Eg2: standard users in the system may have VM manager roles if they belong to a VM User Profile designed for that purpose.
• Multiple users may have multiple VM user profiles.
• No matter the user role, each VM user can have a maximum of one VM user profile per virtual machine.

To create a VM User Profile navigate to Virtual Machines tab Virtual Machines section.

• Click the Connect button to make sure your VM is connected.
• Next, navigate to the VM User Profiles card.
• Click the Add profile button in the top center.
• In the prompt, type the VM User profile name.
  • Select the profile role.
  • Tick the appropriate profile permissions.
• Click Create Profile.

Create Access Directory for Large VM Groups​

Access directories play a significant role in the VM large group management. There are by default three groups for an access directory:

• Everybody: All VM users have access to the directory.
• Nobody: None of the VM users have access to the directory; except the owner of the VM.
• Managers: Only the users with manager roles in the VM have access to the directory.
• Custom: Users with custom permissions set by the VM owner or VM managers have access to the directory.

To create a new access directory navigate to Virtual Machines tab in the Virtual Machines section.

• Select the connected VM you want to create the access directory in.
• Click the Access Directory Management card.
• Click Create Access Directory button in the top left.
• Follow the instructions from Create Access Directory section.

Miscellaneous Management at Scale

It is worth mentioning several complementary features that may be used as a tool to perform management at scale.

Global Login Message​

In specific scenarios, you may need to conduct maintenance in the backend, which may require you to pause the system for a few days. Before starting the maintenance project, it is recommended to have at least one channel to contact all users about the maintenance work outside the system.

For good practice, you can use the global login message feature to inform everyone about a maintenance period or a significant project update that may affect all users. Optionally, you can set custom colors, symbols and display frequencies for your global message.

Global Terms of Services​

As an alternative to global login messages, you can apply the same principle immediately after the users have logged in.

The Terms & Conditions prompt may be used for any relevant information or update users should know about. *, e.g., "The system will be down for 14 days due to a large project maintenance."

The Terminal Hub​

The Terminal Hub helps you keep track of the running VMs when you deal with many terminals. It is a complimentary feature to large projects since it allows you to manage multiple VMs conveniently, at the same time.

The file transfer hub allows you to transfer data between an online cloud platform, your vault and your local machine.

Vault to Local Machine Transfer​

The local transfer opens a direct pathway from the tiCrypt Vault to your local machine. You can upload or download files from/to your local machine by simply drag-and-drop action in the file transfer hub.

Cloud Platforms​

You can use the following cloud providers to perform a transfer to your vault:

• . Dropbox
• . Google Drive
• . OneDrive

Connect to the Cloud​

Before initiating a transfer you must connect to the cloud and follow the prompts to create an API integration.

Initiate the Transfer​

For this transfer example, we will display a OneDrive transfer.

Layouts & Views​

Your drive will always be on the right side while your Vault will be on the left side by default. However, you can change the transfer layouts to have the Vault on top and the drive on the bottom.

Alternatively, you can switch the panels between the cozy or compact view.

Hidden Cloud Files​

Very often, cloud drives may have technical hidden files which are not visible to standard users.

You can unhide the files by using the Show hidden items button in the top right.

Vault to VM Transfer​

Before moving your data to your VM, you will contain it in your vault.

Even if you mistakenly transfer a malicious file/directory to your Vault, it will not be able to produce any harm due to isolation and containment of the vault. Any malicious attempts to break out from the vault are not an option.

More sophisticated data access restriction scenarios involve "hierarchical data"; these are situations where various data sets possess distinct scopes and hierarchical restrictions. While simple data protection can be achieved straightforwardly using the project tagging mechanism in tiCrypt, more complex scenarios like the one described below require more careful consideration.

Problem Statement​

Suppose you have a research group that has access to two-level sets of data: federal-level data and state-level data. Both sets contain CUI from the following states: Florida, Texas, and California.

We assume each of the states has distinct data.

The following data restrictions are in place:

• You can only combine the state-level data with the federal-level data per state.
• You cannot combine data sets between states.

To apply the zero-trust principle, you may want to enforce restrictions on specific data sets.

Knowing that all members work with federal-level data across the states, others work with state-level data, and a third group works with federal- and state-level data; we want to set up an infrastructure where:

• All group members have access to federal-level data.
• Specific members have access to Texas data.
• Specific members have access to Florida data.
• Specific members have access to California data.
• No member can combine federal or state-level data sets between states at any time.
• No member is allowed access to state-level data unless they are actively working on that state.
• Data declassification is limited to the project PIs.
• Data access and downloads are prevented and access-controlled.
• CUI is safe at all times under the project infrastructure.

How can you use groups and projects to achieve this infrastructure?

This blog aims to provide two possible solutions using the interplay between tiCrypt teams, groups, and project tags, and shedding light on how they can be maneuvered to accomplish this goal.

Background information​

Before exploring the interplays, we will examine the usability of tiCrypt teams, groups, and projects to understand how they interact.

Let's delve into the details.

Teams​

Teams are access-controlled. They must have at least one member.

• Separated from groups and projects: There is no interplay between groups and teams or projects and teams.
• Familiarity: Same team members are recommended to join the same group/project for better collaboration.
• Resource usage: Teams can help control resource allocation in a project or group.

Groups​

Groups are cryptographic. They make it easy to share encrypted information between users.

• Independent from teams: Try adding a user to a team, add them to a group, then remove them from the team. The user will still be in the group.
• Fully encrypted: Interaction between group members is cryptographically based on the user's public-private keys with no ACL-based operations.
• Activity isolation: Try creating a group using two team members, then promote one of them to the owner and leave the group. You cannot decrypt the content between your members unless you are now part of their group.
• Satisfy compliance requirements: You should use groups to enforce compliance standards between members.

Projects​

Projects are access-controlled. They must be active in your session to be accessible.

• Tags: You can tag almost anything in the system with your project.
• Separation of powers: Access to the project is granted by your project membership, not by your admin.
• Doubled security & enforced compliance via security levels: You can only access project resources when you have a membership and satisfy project security levels.
  • A project with no security levels still requires a project membership.
  • The more security requirements, the more effort is required to join the project.

The Interplay between Groups & Projects​

Groups are encrypted collaboration objects that allow encrypted file sharing. Projects are a tagging mechanism limiting access to objects such as files, directories, groups, VMs, and drives. Regarding resource distribution, groups commonly share resources in group directories where all group members can view and access them; projects require members to specifically share a resource with other project members to allow access to it.

By combining projects with groups, you achieve an encrypted, access-controlled group directory; that includes group permissions, project membership, and project security levels in one place.

The interplay takes place at a resource level. There are four classes of resources in a group tagged by a project:

1. Resources belonging to the group, not tagged by the project: accessible only to the group members, inaccessible to project members.
2. Resources belonging to the group, also tagged by the project: accessible only to group members who are also project members, have an active project membership, and satisfy project security requirements.
3. Resource not belonging to the group but tagged by the project: inaccessible to group members, accessible only to project members with active project membership and satisfied project security requirements.
4. Resource not belonging to the group nor tagged by the project: Outside files are inaccessible to the group and project members.

Tagged Groups Permissions​

Allow system managed access-control, meaning the following permissions or a combination of them is deployed for each group member:

• . Add Members: Add other users to the current group.
• . Remove Members: Remove existing members from the group.
• . Change Permissions: Change group permissions for themselves and other members.
• . Add Directory Entries: Upload files in the group directory using the upload action.
• . Remove Directory Entries: Delete files from group directory using the delete action.
• . Create Directories: Create new (sub)directories in the group directory using the create new directory action.
• . Modify Project Tag: Change the tags of files and directories in the group directory using the change project action.

A tagged group can hold resources with different restriction levels by project similar to our early example with federal- and state-level data containing CUI from the states of Florida, Texas, and California.

Two workflows show the practical side of project infrastructure using the right interplay between groups and projects.

Workflow 1: One Group to Span All Projects​

You can create an "umbrella" group for a project with subprojects for the data. You will manage subproject memberships via project tags.

One large member group is associated with a project tag with subprojects that individually protect the data. Each group member gets certified for a subproject which allows them to access only the group directories associated with their respective subproject. The PI controls access via subproject security levels and active memberships.

Note this is a single fully encrypted group, without cryptographic isolation between sub-directories yet secure and compliant. This method protects users from admin impersonation and uses access-control between sub-directories.

• Create an "umbrella" group (main group) to cover the whole spectrum.
• Add all members to the group who will be part of the project.

• Next, you need a subproject structure with security levels and security requirements. For this example, we will use:

  • Subproject 01,02,03,04 and 05.
  • Security level 1,2,3,4 and 5.
  • Security requirement 1,2,3,4 and 5.
  • Security requirement 1 will correspond to security level 1, security requirement 2 to security level 2, security requirement 3 to security level 3, etc.
  • Security level 1 will correspond to subproject 01, security level 2 to subproject 02, security level 3 to subproject 03, etc.

• Create security requirements for each security level.

• Create security levels for each subproject.

• Create a project which will be the project under the "umbrella" group.
  • Optionally, add a security level with security requirements to the project.
• Re-login to view the project.

• Create multiple sub-projects and link them to the appropriate security levels previously created.
• Re-login to view the subprojects.
  • Files per subproject will be visible only to users with active memberships for those sub-projects and satisfy the project requirements.

• Next, certify all group members with the security requirements corresponding to the appropriate subprojects.

• Add each group member to the corresponding subproject.

• Tag the "umbrella" group with the project tag corresponding to the main project you created earlier.

• Create a set of directories within the "umbrella" group directory that will serve as group sub-directories for the subprojects.

As a member with a user role in the "umbrella" group, you can only access the tagged group directory with colored tags. Other group directories will only show their names with a Question Mark instead of the tag, indicating that they are inaccessible due to a locked session. If a group directory bears a project tag that is not part of your active session (not your current project), you cannot view its contents.

• Next,tag all sub-directories within the group corresponding to the appropriate subproject with their own security level. For this example, we will use:
  • Subdirectory 1,2,3,4 and 5.
  • Subproject 01,02,03,04 and 05.
  • Subproject 01 will tag Subdirectory 1, subproject 2 will tag subdirectory 02, subproject 3 will tag subdirectory 03, etc.

To test your workflow infrastructure, open a group sub-directory you are a member of that was tagged with a corresponding subproject you belong to and upload a file into the group sub-directory. All members of the subproject tagging the sub-directory should be able to view, access, and perform all actions with the sub-directory files if they:

• Are an active group member of the "umbrella" group.
• Are members of the subproject that tags the sub-directory.
• Satisfy all subproject security requirements which tag the sub-directory.

Even if the users will not be able to view the other members of the subprojects (except their membership), they will be able to view the members of their "umbrella" group who are also the members of all subprojects. This action may be altered by an admin in the permissions panel of each user or using the apply profile option.

From now on, you can either manage all subproject tags of the "umbrella" group or delegate each subproject tagged sub-directory to a sub-admin.

To delegate your tagged subproject to a sub-admin:

• Promote subproject member to the manager role.
• Optionally, remove yourself from the subproject to allow independent collaboration between subproject members and the new project manager.

You have successfully completed a tagged group with projects infrastructure.​

Workflow 2: One Project to Span All Groups​

You can create an "umbrella" project to create a set of groups corresponding to subprojects of the "umbrella" project. You will manage project membership via tagged groups. This workflow is complex and requires more thoughtful management.

You have a single project with full encryption between layers (group directories). The PI controls access to your group directory via group permissions, security levels per subproject, and project memberships. You are cryptographically isolated and access-controlled which is both secure and compliant.

• Create an "umbrella" project (main project) to cover the whole spectrum.
• Optionally, create a security level with security requirements to the main project.

• Re-login to view the project.

• Next, you need a subproject structure with security levels and security requirements. For this example, we will use:

  • Subproject 1,2,3,4 and 5.
  • Security level 1,2,3,4 and 5.
  • Security requirement 1,2,3,4 and 5.
  • Security requirement 1 will correspond to security level 1, security requirement 2 to security level 2, security requirement 3 to security level 3, etc.
  • Security level 1 will correspond to subproject 1, security level 2 to subproject 2, security level 3 to subproject 3, etc.

• Create security requirements for each security level.

• Create security levels for each subproject.

• Create multiple subprojects under the "umbrella" project with each having a security level.
• Re-login to view the subprojects.

• Certify yourself with the corresponding security requirements for the security levels belonging to each subproject.
• Alternatively, certify each sub-admin who will run one of the subprojects.
• Re-login to get access to the subprojects.

• Create multiple small groups, and tag each group by its coresponding subproject.
• At the same time, add the appropriate members to the group who will belong to the corresponding subproject. For this example, we will use:
  • Group 1,2,3,4 and 5.
  • Subproject 1,2,3,4 and 5 which we created previously.
  • Group 1 will correspond to Subproject 1, group 2 to subproject 2, group 3 to subproject 3, etc.
  • Subproject 1 tags group 1, subproject 2 tags group 2, subproject 3 tags group 3, etc.
  • A random user will be added to each group corresponding to each subproject for demo purposes.
• Re-login to view the changes in user memberships.

As a member with the user role in the "umbrella" project, you can view all files from all group directories.

As a subproject member, you can view only your group directory tagged with your subproject tag. Suppose you do not satisfy the subproject security requirements. In that case, you can view the name of the files, their type, owner, creation date and size but cannot perform the following actions: view, download, change project, share, access file history, edit or delete files.

• Next, certify all group members with the security requirements corresponding to the subproject their group is tagged with.

• Add each group member to the corresponding subproject which tags their group. Remember every group is tagged by a subproject independently, marking their purpose in the "umbrella" project.

To test your workflow infrastructure, open a group directory you are a member of that was tagged with a corresponding subproject and upload a file into the group directory. All members of that group should be able to view, access, and perform all actions with the group files if they:

• Are active group members.
• Are members of the subproject that tags the group.
• Satisfy all subproject security requirements which tag the group.

Even if the users will not be able to view the other members of the subproject (except their membership), they will be able to view the members of their group who are also the members of their subproject. This action may be altered by an admin in the permissions panel of each user or using the apply profile option.

As shown below, you can either manage the tagged groups of subprojects or delegate each tagged group to a sub-admin.

To delegate your tagged group to a sub-admin:

• Promote group member to the owner of the group.
• Optionally, leave the group to allow independent collaboration between members and the group owner.

• Next, set up the subproject membership of the group owner of the tagged group corresponding to the subproject that tags the group.
  • User role: allows group owner to have control of the group but cannot untag files by subproject from the tagged group.
  • Manager role: allows group owner to untag files from the group, pulling them out of the subproject (this is not recommended).

In contrast, the group owner can move a file outside the group but still have it tagged with the subproject.

• The file will still be classified by the subproject tag but not visible to other group members except the group owner.

You have successfully completed a tagged project with groups infrastructure.​

Other Hybrid Workflows​

Besides the two workflows above, there are many other hybrid workflows you can create to fit your project needs and customize your infrastructure.

Hybrid Example 1:

• Create an "umbrella" group to create a project with subprojects for the data.
• Separately, create an "umbrella" project.
• Create a set of groups and tag them by the "umbrella" project.
• Create subdirectories for each group directory and tag them with the project's subprojects that tag the "umbrella" group.
• You will manage project memberships via tagged groups and subproject memberships via project tags at the same time.

Hybrid Example 2:

• Create an "umbrella" group to create an "umbrella" project.
• Create a set of subprojects under the "umbrella" project.
• Create small groups tagged by the "umbrella" project.
• Each small group may have sub-directories tagged independently by the subprojects created previously.

To conclude, by leveraging the power of project tags and groups, you can establish an efficient workflow for your research infrastructure.

1. Security First​

• Security is the top priority, and the architecture is designed with security as the central consideration.
• A comprehensive approach to security is taken, going far beyond perimeter protection with Firewall, VPN, and intrusion detection systems.
• Zero-trust is implemented using cryptography rather than solely relying on access control lists (ACLs).
• The goal is to architect a complete solution rather than "patching" security vulnerabilities.
• Features are only added if they do not compromise security.
• There is no notion of public/unsecured data; explicit sharing is the only allowed method.
• Default shut is favored over default open.
• Public-key cryptography (PKC) is the core concept, with all security mechanisms based on PKC.
• Password-based authentication is not used, and extensive use of cryptography is implemented.
• End-to-end encryption is utilized, and each resource is independently protected.
• Encryption keys are managed using PKC, and cryptographic isolation is enforced.

2. Separation of Duties​

• Admin power is decentralized uniformly throughout the system to prevent data breach entry points, even if an admin account is compromised.
• Access control and end-to-end encryption are used together, with the addition of two-factor authentication (2FA) for enhanced security.
• Extreme flexibility is provided in terms of operating system support (Windows and Linux), tooling support (AI + GPUs), and the full software stack.
• The overhead for small and large projects is kept minimal.
• Researchers are empowered to manage and control their data and workflows, decentralizing management and minimizing the role of admins.
• Admins define mechanisms and monitor usage but have no access to user data.

3. Mechanism instead of policy​

• The focus is on enforcing behavior through mechanisms rather than relying solely on policies.
• Mechanisms are designed to prevent and deter bad behavior, with system-enforced capabilities.
• Automated system-enforced mechanisms reduce the risk of human error and ensure consistent adherence to security protocols.
• Severely reduce the number of FTEs and "police" behavior responses.
• Policies should only dictate the mechanisms used for enforcement.

4. Support diverse research workflows​

• tiCrypt supports diverse research workflows with Windows and Linux OS support, AI + GPU capabilities, and compatibility with various hardware devices.
• It provides flexibility in deployment, allowing on-premises bare-metal servers, cloud deployment (AWS,Azure,Google Cloud,etc), hyper-converged solutions (Nutanix, RedHat,etc), and hybrid models (on prem+cloud).
• Accommodate non-uniformity and "borrow" VM hosts from both cloud and HPC clusters.
• Compatibility with existing security and infrastructure solutions such as Duo, Shibboleth, firewalls, and VPNs is ensured.

5. Detailed auditing​

• Auditing is fully integrated into the secure system, addressing compliance requirements directly.
• Different projects may have specific auditing requirements, and the system caters to those needs.
• tiCrypt solution includes an audit system that produces compliance reports, maintains a very detailed audit trail, and retains audit logs for the entire history of the system.
• Reports allow audit pre-dictions of data behavior.

Conclusion​

• Partial success can be achieved with significant effort, but there may be system blind spots and limited supported workflows. tiCrypt is the result of a collaboration with University of Florida over ten years, designed to address all compliance and security needs, making it a proven security unicorn.
• The three pillars of compliance include strong security, system enforcement, and comprehensive auditing and reporting.
• All features are designed to meet the rigorous compliance standards of public institutions.

Secure virtual machines in tiCrypt run in almost complete isolation from each-other and the environment. The main motivation for this isolation is providing a high degree of security.

Setup​

In this blog we will refer to a number of tiCrypt components that participate in the activities described here. They are:

• ticrypt-connect runs the application on user's device
• ticrypt-frontend runs in the browser on user's device and is served by ticrypt-connect
• ticrypt-backend is the set of tiCrypt services running on the Backend server
• ticrypt-rest is the entry point in ticrypt-backend and uses REST protocol.
• ticrypt-proxy mediates communication between components by replicating traffic between two other connections.
• ticrypt-allowedlist mediates access to external licensing servers
• ticrypt-vmc controls the secure VM and is responsible for all VM related security mechanisms

Overview​

The VM security is provided through the following mechanisms:

1. Reverse mechanism to talk to tiCrypt frontend using ticrypt-proxy component
2. The only opened ports for a VM are port 22 for traffic tunneling from tiCrypt Connect
3. Special mechanism to reach port 22 of VMs but no general mechanism to reach any other port from tiCrypt-backend
4. Strictly controlled outgoing traffic through ticrypt-allowedlist component

We take each mechanism in turn end provide details on how it works.

ticrypt-proxy mediated VM communication​

Due to the fact that all ports are blocked except 22 and that ticrypt-vmc (VM controller) control this port for port forwarding, there is no mechanism to directly contact a secure VM using direct access. Instead, a mechanism fully controlled by the ticrytp-vmc is employed. The mechanism relies on ticrypt-proxy (component of ticrytp-backend) to mediate communication with the user in the following manner:

1. The ticrypt-vmc creates a web-socket connection with ticrypt-proxy at all times.
2. When a user wants to connect to a VM, the ticrypt-frotnend creates a web-socket to match the existing VM one in ticrypt-proxy. All traffic between the two matching web-sockets is replicaed by ticrypt-proxy. Imediately ticrypt-vmc creates a new web-socket for future communication.
3. The first message sent by both the ticrypt-frontend and ticrypt-vmc are digital signature proofs of identity and Diffie-Helman secret key negotiation.
4. If the digital signature fails or if the user is not authorized (as determined by ticrypt-vmc) the connection is immediately closed. Similarly, if the VM validation fails, ticrypt-frontend will close the connection
5. All subsequent messages (in both directions) are encrypted using hte negotiated key. Except the setup messages, all traffic is hidden from ticrypt-proxy and any other part of the infrastructure.
6. All commands, terminal info, keys, etc are send through this encrypted channel.

Application port tunneling​

In order to allow reach application deployment in VMs, a generic mechanism that tunnels TCP traffic on specific ports from the VM to user's device is provided. The mechanism is highly controlled (as explained below) but, in principle, can make any network application access possible.

The communication pathway relies on an number of independent segments, all of which can prevent the mechanism from functioning. All traffic on these segments is proxied/forwarded and overall is secured with TLS encryption and authenticated with digital signature (not passwords). At no point any intermediate component can intercept the communication without breaking TLS.

Communication setup​

Initiating the forwarding tunnel setup requires the following steps:

1. The ticrytp-frontend using authenticated session, tells ticrypt-rest (entry point of ticrypt-backend) to create the pathway to a specific VM
2. The request is validated and ticrypt-proxy is informed of the operation
3. The ticrypt-proxy sets up a listening endpoint on one of the designated ports (usually 6000-6100). The endpoint is strictly set up and only allows access from the IP address used to make the request.
4. The ticrypt-frontend is informed of the allocated port.
5. ticrypt-frontend asks ticrypt-connect to generate a TLS certificate for authentication and connection encryption.
6. ticrypt-frontend tells ticrypt-vmc to accept the application forwarding and provides the authentication TLS certificate
7. ticrypt-vmc replies with a list of ports that need to be tunneled
8. ticrypt-frontend tells ticrypt-connect to start the connection and use the previous certificate.
9. ticrypt-vmc, upon connection creation, checks that the digital signature is correct and initiates the TLS mediated tunneling.
10. The traffic to/from local port on user device is tunneled and re-created within the VM to allow application access

Communication pathway​

The communication pathway for port tunneling is:

1. The ticrypt-connect accesses the allocated port controlled by ticrypt-proxy. The connection is pinned to the IP address the setup request comes from.
2. ticrypt-proxy forwards the request to the VM Host endpoint (explained below)
3. The VM Host endpoint forwards the traffic to port 22 of the correct VM
4. ticrypt-vmc listens on port 22 and runs the TLS protocol with port tunneling.

Secure VM isolation​

In order to ensure VM security, only port 22 is opened inbound. Furthermore, all outbound traffic is limited to ticrytp-rest traffic unless an exception is provided by ticrypt-allowedlist (next section)

The specific mechanisms deployed for VM isolation are:

1. All traffic to ports other than 22 is blocked internally by the VM thus isolating any other access. Note that application access is provided by the port tunneling above.
2. All traffic to the VM ip on ports other than 22 is blocked using firewall rules on the VM host.
3. External traffic to VMs is not routed by the VM host (with the exception of port 22)
4. Traffic from VMs to outside is blocked unless ticrypt-allowedlist mechanism is used

Licensing server access​

In order to use most commercial software, access to external licensing servers needs to be provided. Most of the time, the licensing servers reside within the organization, but occasionally, the servers are external. Recognizing this, tiCrypt provides a strictly controlled mechanism to allow access to licensing servers.

The ticrypt-allowlist component mediates setting up the mechanism that allows access to licensing servers. It does so by manipulating:

1. Firewall and port forwarding rules on the server running ticrypt-backend
2. DNS replies to requests that VMs make

The mechanism is strict and very specific. Unless a mapping is provided using ipsets and firewall rules, any outgoing traffic from VMs is blocked.

The ticrypt-allowlist component works in conjunction with ticrypt-frontend to provide a convenient way to enable/disable access. This mechanism requires SuperAdmin access.