Skip to main content

Enforcing CUI Restrictions on Hierarchical Data

· 19 min read
Betuel Gag

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.
note

You may be in a situation where you share a file with another tiCrypt user. However, with time, you share files more often with the same user, and it becomes a habit. At this point, you should create a group with the respective user where you can share files unconditionally.

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.
note

Unlocked projects displaying the Unlocked tag are restriction-free. If a resource has a project tag, the project restrictions apply.

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.
tip
  • To access a tagged group, you need group keys, project membership, and satisfied security levels.
  • Tagged groups can have resources with distinctive project tags unrelated to the group's tag, enabling group owners to tag files with other projects they belong to. We do not recommend having one group with many unrelated project tags for clean data management.

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.
note
  • Once a user is added to a group, they become a group member.
  • A group member with user role becomes a group member with manager role when their Add Members permission is ticked.
  • As a group owner, you cannot change your permissions in the group.
  • Mistakenly unticking Change Permissions box as a group member you will block you from changing any permissions, including yours. To restore your permissions, you must ask the group owner to tick back the Change Permissions box for you.
  • By ticking the Modify Project Tag permission, you allow subproject members to untag (declassify) tagged group directory files from the subproject and keep them hidden within their group directory, making them visible only to their group members.
tip

For good practice, you may use the following permissions structure for your tagged groups:

  • Group User: Add directory entries, Create directories.
  • Group Manager: Add directory entries, Remove Directory Entries, Change Permissions, Add Members, Remove Members, Create directories.
  • Group Owner: All permissions by default, including Modify Project Tag.

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.

  • 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 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.
caution

When you apply a security level to the project under the "umbrella" group, you will force all group members of all subprojects to satisfy the security requirements for the main project which will tag the group.

  • 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.
note

Creating a subproject with no security levels will be considered part of the main project to all members of the newly created subproject.

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.

note

Active memberships in the project allow active sessions in the tagged group directory.

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.

caution

When you apply a security level to the "umbrella" project, you will force all members of all groups of all subprojects to satisfy the security requirements for the "umbrella" 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.

note

You can add multiple security requirements per security level, depending on your project infrastructure.

  • 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.

note

Users must be notified about the group they belong to.

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).
note
  • A declassified file from the subproject which tags the group is still secured within the group but only visible and accessible to the group members.
  • When you tag a file from the subproject tagged group directory with the "umbrella" project tag, the group members who have access to the subproject tagged group directory will also have access to the "umbrella" project tagged file since it belongs to the parent project and it is located within the appropriate group directory.

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.
tip
  • For clean data management purposes, you should never tag random files with other project tags in a tagged group. This results in many tagged files in the group directory structure that have nothing to do with the project which tags the group.
  • Do not create groups with people who do not know each other- we recommend creating groups with team members. The FE will only allow you to access other users' resources if they are on your team.
  • Set the team boundaries lined up with group boundaries.
caution
  • If a group has a project tag, you cannot get the group key unless the project is active in your session.
  • If the project tagging the group is not active, there is no way to access the group.
  • After user permission changes in the project you must re-login to update the current session.

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.