Skip to main content

Principles governing a Compliant system

The current compliance environment relies heavily on different policies and standards, resulting in policy execution requiring a large number of FTEs, paperwork, and manual risk control. Because of a strong public-key infrastructure, tiCrypt's security foundation achieves compliance through automatic isolation and automatic enforcement. tiCrypt allows universities and research institutions to take implicit control of the practical aspect of security.

  • Benefits of the tiCrypt approach to all aspects of your organization
  • University & Research Institutions: tiCrypt is battle-tested daily by R1 Universities, Medical Centers, and National Labs. Deploying tiCrypt has allowed universities to increase research expenditure and climb national research rankings, unlocking research ranking and expenditure growth opportunities through compliance.
  • CIO/CISO/CSO: Strong security is at the core of tiCrypt vision, which follows high-end compliance, organization reputation, ethical technology, and perpetual risk diffusion.
  • Research Computing: tiCrypt is easy to deploy and manage on existing or new hardware without requiring teams of FTE support.
  • Office of Research & Compliance: tiCrypt has built-in audit reporting, simplifying workflows through automated auditing reports and system monitoring. Simply put, tiCrypt reduces paperwork for NIST 800-171, CMMC 2.0, and ITAR reporting. A deployment comprehensive System Security Plan (SSP) allows for umbrella compliance and expansion of the security envelope easily.
  • Researcher: tiCrypt allows researchers to bring existing workflows into tiCrypt's secure Linux and Windows VMs. Researchers are in control of access and data workflows, meaning no waiting for system admins to move data or grant permissions on the VM.

Why is compliance hard?​

There are competing and evolving standards issued by various funding agencies built around the idea of ensuring data security. No 100% resilient process/tactic is prescribed to meet the requirements, which can sometimes be quite non-uniform. The creation of a compliant system requires quite a niche expertise. It brings with itself tons of associated risk- related to how the hardware and software are at play, and relying on vendors for different bits and pieces while ensuring their compatibility with others is relatively easy.

How compliance affects the research?​

Here is a short outline of a couple of scenarios where compliance dictates the course of action:

  1. A data use agreement (DUA) enforced by an external organization against Institutional Review Board (IRB) agreement dictates that data needs to be stored in a secure environment to meet the updated NIST 800-171 compliance regulations. This would mean encryption is required at rest and transit.
  2. Ad-hoc and group-sharing capabilities required for a research project would again need a secure environment.
  3. Access and Identity management controls are often required to be in place for restricted project file access.
  4. All of this must work in tandem with a true-to-source audit capability that speaks to the real action taken in the past and is immutable.
  5. Secure complex processing and sharing on the VM level while having the ability to use the software preferred by the researcher.

3 Pillars of a Compliant Solution​

Strong Security​

Security should be the significant point of concern here and not an afterthought. The architecture design should be around security, not just a component of it. Security components aiming at the perimeter are insufficient: Firewalls, VPN, and Intrusion detection mechanisms still pose an insider risk and leave the resources exposed internally. Building "Security Bubbles" would ensure proper isolation, establishing a no-trust environment. The solution should be comprehensive and not a "patch" per se. e.g., iDMZ and eDMZ solve part of the problem but leave security holes at many levels.

Mechanism vs. Policy​

The policy does not govern - it instructs people what to do. This would result in manual enforcement at every level, requiring tons of non-automated effort. Policing bad behavior becomes a cakewalk once mechanisms enforce the conduct.

Auditing and Reporting​

Audit everything. Auditing should be aimed directly at compliance. Auditing should be the slate from which all the actions can be verified while ensuring no data leakage- e.g., setting a detailed audit trail for future reference. Audit logs should never be discarded.

tiCrypt's capability at a glance​

tiCrypt is designed to enable research for many secure, isolated projects while keeping the confidentiality, integrity, and availability of information protected at the appropriate level iterated in the compliance documents. Configuration security also segregates project information to prevent unauthorized disclosure or sharing of information. tiCrypt provides a secure and NIST 800-171 and 800-53 Moderate compliant computing environment; it is self-contained and rigorously controlled. Data is encrypted at rest and in transit and is processed inside isolated Secure Virtual Machines (SVM). Data stored within tiCrypt is separated from the end-user computing devices using the tiCrypt client, which provides remote desktop access to interact with Secure Virtual Machines. This facilitates security protections when storing, transmitting, processing, and using controlled unclassified information in non-federal information systems.


The detailed account: