We will explore what administrators can do to manage tiCrypt for their teams. This practical guide should help administrators with the following:
- How to practically make the best use of the system
- How to help their team effectively
- How to innovate in tiCrypt and add their blend to it
This document is not intended to replace tiCrypt documentation and to provide exhaustive information on tiCrypt features. For technical reference, please refer to tiCrypt documentation. The sister document addressing the best practices for project management may be found in administrator roles within tiCrypt.
The Principle of Minimal Privilege (Zero-Trust)
The term 'Zero-trust' is broadly misunderstood and often interpreted as a security principle for marketing purposes.
Zero-trust should be called the Principle of Minimal Privilege.
'Minimal' means never wanting to give more permission than is needed to any user in the system, including access to the data and other users' data. Zero-trust is a minimal privilege and preferably cryptographically enforced.
Talking about the minimal privilege principle is consequential because it is a complex problem. The government is skilled at putting zero-trust documents together but needs to be more skilled at doing things in practice. What needs to be addressed is enforcing the minimal privilege into a fully functional cryptographically enforced system, a challenge solved by tiCrypt projects.
To the majority, zero-trust is a mechanism that allows users to take a specific action based on a set of rules written by the administrator in the beginning. However, the constant problem with this methodology is the following: when a hacker comes in, he won't use the admin rules but will instead find a way to circumvent the whole system, so now the admin's zero-trust is worthless.
Imagine the following scenario.
A hacker attempts a social engineering attack ( or admin impersonation) where he asks for a "password reset for his account." This hacking attempt may work with large organizations of thousands of people; however, it is a handicapped attempt for tiCrypt.
In a tiCrypt scenario, the employee at the end of the line would not be able to give any details to an admin-impersonated hacker due to the minimal privilege principle.
Since they have no access to the data themselves, employees would have to forward the hacker to the project leader of the specific team, who has access to the particular data he requested in the first place. In a small team, the project leader has the group keys and knows all the team members because they work closely together. Hence they would immediately recognize the social engineering attack and calmly expose the hacker.
Furnishing Compliance
Compliance is complex, but on the other hand, it allows the flow of research grants and increases research expenditure.
To furnish compliance, admins should use projects that include security levels & requirements allowing access to research data based on the user certifications.
Admins can leverage the user certifications to external organizations who offer relevant research materials to successfully carry out a project in exchange for complying with their requirements. The operation opens many doors to high-quality data research entities.
We recommend adding an expiry date to the user certificates based on good practice to enforce compliance.
Admins should keep security requirements as simple as possible to avoid unnecessary questions from many users. At the same time, security levels are better off when using one word or simple abbreviations (i.e., HIPAA).
When considering compliance per project, admins may view the initial constraints and restrictions. In contrast with the project requirements, they can compile a set of rules to help every member comply before project deployment.
Data Back-up Management
There are two practices for backup: never-back-up data & always-back-up data.
Never-back-up data may be used for general repetitive data representing a storage liability to the organization. This practice may be used for long-term cleaning storage purposes.
Always-back-up data may be used for collectible data assets resulting from various research projects; files that have to do with system functionality; parameters of compliance; and anything that may have a significant impact.
Oftentimes administrators are requested by the users to keep all their data backed-up. They should not do that if they want to avoid a larger storage problem.
Suppose a University has attributed 10TB drives for researchers to produce significant data stocks; it will develop normally until the admins decide to back up the data.
Back-uping the data is more expensive than creating it because it requires the drives to keep the entire history of files. The university has an add-on that eventually becomes ten times bigger than 10TB, ever-growing daily to become the most expensive part of the system. This issue leads to choosing what gets backed up and where the backup takes place.
In good practice, administrators should be highly selective with the backup operations; they should constantly decentralize it.
When backup data is decentralized, it allows control over backup sections so that admins decide what remains or goes out of the system.
The only scenario when administrators can enforce data backup is when they force users to commit large amounts of financial resources for the service. Some universities run into millions of dollars in costs because of data-back-up management.
Another important aspect of backup is data access management.
In a hypothetical example, a user has two levels of data to work with: Federal government-level & Federal state-level data.
The management rules are 'never mix the data from the two levels' and 'do not peek at other federal government data files.
A user is naturally tempted to see other federal data files unless the system enforces this operation. tiCrypt enforced compliance mechanism allows the user to see specific parts of data required for the project while keeping other data separate and inaccessible. Users cannot mix data unless expressly permitted by the group owner or administrator.
To achieve this in practice, administrators should tag the projects with two different security levels allowing the user to access only specific data sets needed for the project. Administrators can use groups to stop a member from adding files to a local project, avoiding the mix of data altogether.
Escrow Mechanism
tiCrypt understands users of any technical level, from simple research activities to complex operations.
Login passwords are bound to be in a private password manager or offline in a safe place. The users do not have to memorize any keys or extended characters except their user's email address and a memorable password.
Users should be advised to never edit any characters in their private key. A single edit can deactivate their key resulting in an unpleasant escrow situation.
To keep the private key safe and avoid escrow protocols, administrators should do the following:
- Put the private key in a location they can easily find it
- Always make at least one copy to their private key and keep it somewhere safe, either offline or in their local machine
By doing this, administrators will be able to log in if they forget their previous private key location and give access to new members to join their group.
To help administrators understand the principle behind the escrow mechanism, we showcase the following box analogy. All private keys in tiCrypt are encrypted; they exist in closed virtual boxes that require a cryptographic key pair. If hackers would like to crack a ' box' where the user has its private key, it would take all the computing resource power of humanity running at the age of the universe. The exact process appears when encrypting files and escrow keys.
Since there is no ' forgot my password' button in tiCrypt due to strong security, the system uses escrow.
Escrow is a separation of duties; it works only if multiple escrow users do it. The escrow key may be split into three parts where all escrow users will share their piece of the key with the fourth user who needs to escrow their account.
The best practice to avoid bad key management is to have three escrow users who are not regular users, system admins, or audit members.
An escrow user cannot log in to the system and has minimal functionality.
Super-admins are not escrowing users; they do not involve at all in the key recovery. The super-admin can only initiate the state of escrow login. Escrow users also have escrow groups where they can share their key with the other escrow user in case an escrow user leaves the organization temporarily or permanently.
A decent candidate for an escrow group may be:
- One of the super-admins
- A highly trusted person in the organization
- An individual from a different department
In this way, the chain of trust is vital, coming from three fundamentally different parts of the organization.
The Vault
Administrators can use the vault best by organizing the folder structure. It is best to avoid a vast number of sub-folders. Main folders may be divided into research areas by allocating resources for each research team to their specific folder.
For each created group, a folder will be automatically created in the vault with the group's name.
Administrators can tag new folders in the vault with the classified project name if they want to set up a restricted folder linked to the classified project.
We recommend adding folders in the vault after setting up the teams and groups.
User Profiles vs. Permission Management
There are numerous functionalities in tiCrypt when it comes to roles. Each role has various permissions, which will change how the world looks for each user.
For the best practice, we strongly discourage users from playing with specific permissions; unless there is a particular case where they need them to carry out a complex project. We advise administrators to follow the simple User Profiles, which helps them automatically segment the user roles with their respective permissions.
User profiles are historically better for researchers due to simplicity and fast-forward setup.
They serve a similar purpose both for users and admins.
Teams
Teams are the element of administration and visibility. Users should know about each other and have clarity about their available resource levels.
Teams visibility is based on user roles as follows:
- Sub-admin will see the users they manage in the system
- Admins will see other admins, sub-admins, and their managed users
- Super-admins will see all the users in the system
For best practice, we recommend discussing the management plan before giving admin access to local projects.
We also recommend having three super-admins as an appropriate management solution. Suppose a super-admin cannot access the machine or continue working for the organization. In that case, the system can use the other super-admin keys to transfer the person's key to a new super-admin securely.
Groups
When an admin creates a new group, a folder with the group's name is automatically created in the vault. The new folder in the vault serves the purpose of effectively sharing information and data with the right people. Groups facilitate and segment user access.
Minimum privilege principle applies to both groups and projects. Only explicit sharing works (E.g., PI shared a file with the whole group explicitly). Only an existing group member with active permissions can give access to a new group member.
There is significant differences between Teams and Groups as seen below:
- Teams serve the management purpose; Groups serve the project purpose
- Teams and the Projects are access controlled; Groups and the VMs are cryptographic
- There can be a Team of users where each of them belongs to a different Group
- There can be a Group where each member belongs to a different team
- Groups can have a tag with restrictions per project; Teams cannot have a tag attached to them
- Groups serve the success of a project; Teams serve the management of users across the organization
Administrators should keep in mind the above functionalities when creating a group. They should assign the group to a project and have the members know each other.
Projects
Projects are an organized way to enforce compliance.
In principle, users can access project files, but because of the project membership, they cannot view or download them. This operation is a vital compliance effort that may explain why a project is disabled. E.g., "the HIPAA certificate expired."
A real example is the NIH projects that have restrictions; they need a stamp on the project that states users cannot access the individual file. tiCrypt projects enforce access by mechanism. Administrators should make full use of the tiCrypt mechanism to manage project restrictions. Security levels make it easy for administrators to 'stamp' a project via user certificates.
Projects can tag Groups.
Project memberships will prevent users from tagging projects; they can receive permission to tag only from the administrators. All projects may deter users from grabbing encryption keys.
Projects may be not only access-controlled but also cryptographic in combination with Groups. If a project tags a group, users can only get the key if they convince the system that they are actively part of that group and the information is relevant to them. A user must have access to the Group key to join the group, but only a group member can give the Group key to the new user.
When an admin creates a group, it also creates a current version of the group key, but each user has a private cryptographic key as part of the group key.
Group keys are not stored on a user's local machine. The only key stored is the user's private key.
Composable Security
Projects are entirely under admin control and backend control.
You can combine groups with projects to get the highest level of security. This is known as composable security.
Projects are not cryptographic; they are a complete mechanism. They can take away permissions from users. E.g. "the ability to add the private key to the group key".
Deleting a project is not a good practice because the resources users have accumulated on that project may be an asset in the future. It is better to park the project, a new feature coming soon into tiCrypt.
As a good practice example, several organizations use tiCrypt to tag files with HIPAA in projects whenever there is a slight assumption of becoming a HIPAA type of information.
HIPAA is a political regulation with various counterintuitive and bizarre expectations. As a result, safe-keeping projects and files under the HIPAA tag enforces the compliance mechanism; hence it diminishes the chance of ever being penalized for data-handling processes.
Project Size Scenario
Supposing you are a complex organization with three kinds of project levels, all running at the same time as follows:
Project A – Large project with 100 people involved
Project B – Medium project with 30 people involved
Project C – Small project with 6 people involved
You would have to decide which project will need User Profiles the most to control the users and the management workflows.
Project C
It is not a critical case for using User Profiles since members are limited and they work closely and well-coordinated.
Project B
This kind of project should consider using User Profiles due to the project size. Members may change with new members across a short period; updates often need reviewing; coordination is necessary for the project to be successful.
Project A
Having User Profiles set up before opening the project is critical. A large number of members requires larger management teams. The audit team is actively involved, and there is high responsibility from the project's leaders to ensure every new member fits into pre-determined User Profiles and has clear instructions to carry out their tasks successfully.
Security Levels
Security levels (e.g., HIPAA) are containers for requirements (e.g., HIPAA requests). When admins have a new project coming, they should first define the constraints and restrictions.
Constraints are the easiest way to assess a project's potential and be able to get a grant investment for it. Restrictions play a similar role in achieving project compliance. tiCrypt allows admins to decide every time if any current security levels fit the new project requirements.
In this way, system admins have leverage over future projects that require similar requests.
Security Requirements
We recommend creating security requirements after setting up security levels. Each security requirement should address one security level.
User Certifications
User Certifications should be user addressed and should have expiry dates. If a user leaves the project or the organization, admins should immediately decertify the user from the individual project or make the user inactive.
In a hypothetical situation, administrators may be in a meeting trying to help organization members achieve a healthy project goal. However, the call gets rejected for some reason. Three months later, members returned to the administrators and asked how it would be possible to apply their suggestions to the project. Admins can use user__ certifications to navigate sudden changes in management decisions.
The best practice for user certifications is to consider to which user the policy and the feature address, the practical benefit of the user resulting from this policy, and finally, the problem that this policy solves for the user.
Adding A User Checklist
After successfully adding a new user, you may follow the following checklist example for good practice:
- User registers account
- Sub-admin logs onto tiCrypt and updates the user's settings
- Add the user to Teams, E.g. "DAC."
- Update Role and Permissions role to the user
- Set status to "escrow, active on next login."
- Profile to "Granite User."
- Add Security Certificate "DAC Compliance."
- Add a user to the project "DAC" (this is the "parent" project)
If it is a Researcher:
- Check "Cannot download."
- Check "Cannot view."
- Add User to "DUA project" (this is a sub-project of DAC)
- Add User to VM (Virtual Machine)
- Connect to VM
- Select the "User" role
tiAudit and Reports
In this example, we consider the scenario where an organization checks the history records of clients and students. Suppose they find unusual activity in their system; they would report it and later realize it was a hacking attack. The costliest problem comes after discovering the breach, which is determining what information was stolen from the database. This issue is usually unknown when it comes to large organizations.
For this reason, the law forces the organization to declare that all their database has been compromised leaving significant gaps for external audit companies to step in, government record fines, and high losses for the organization.
We learn that the government is hardly convinced; an internal audit report will not save the organization in such a situation.
In tiCrypt, all actions are audited at all times into tiAudit, releasing the need to hire internal auditors or pay external data audit companies.
tiCrypt can take any file that 'smells' sensitive and non-compliant and label it as sensitive and compliant using classified project tags. We recommend that admins train users to tag files if they feel the information becomes too keen to be unprotected for compliance purposes.
tiAudit has three parts:
Alerts
Designed to help compliance officers track compliance in real time.
All alerts are triggered from the system.
Reports
They are the most creative part of the auditing because they allow full customization. For good practice, we suggest having regular reports over once-a-month reports on auditing.
Users have all they need to be compliant in the reports. At a press of a button, all reports are system-generated. We recommend that the audit team use reports and queries to get deeply accustomed to tiAudit.
Queries
We strongly recommend using the queries for forensic operations. The audit team may inquire about the system database about incident responses. They can find out what happens anytime in the past since the installation of the system. Due to the depth of data, we advise this kind of investigation to be carried out by a system engineer; otherwise, it might be overwhelming to ask the proper data queries.
Universities would spend millions of dollars on consultancy companies without tiAudit forensic tools. For this reason, tiAudit records in detail everything from the primary system.
tiAudit is not a backup management system. It memorizes the user action, not the user content.
Although Personal Investigators may use tiAudit to spy on their users' work progress, they primarily use it for compliance at the organizational level.
Due to its past detailed queries, tiAudit can effectively predict what will happen with the data in the future, giving room for data management decisions in the present. Administrators should fabricate queries from various data angles to make the best future decisions.
For R1 and R2, universities running projects that require HIPAA stamps, tiAudit ensures the data to avoid legal penalties. By law, federal entities can release fines even for one HIPAA violation. However, the costliest part is not acceptable but determining what happened with the data. This cost may result in millions of dollars spent on third-party audit companies and data digging.
Although tiCrypt does not know what is in the data, it proficiently understands how the data moves at all times. By writing a query in tiAudit, admins can find precisely what moved with the data, saving to university millions of dollars that would have otherwise gone as legal penalties and payments to authorized auditing companies.