Getting into a TRE is only half the security problem

When organisations first look at Trusted Research Environments, the conversation usually starts with access controls.

• Who can log in?
• Is MFA enabled?
• Is the workstation isolated?
• Is internet access blocked?
• Can researchers copy files out?

These are all important questions. But they are only part of the problem.
The harder question is often this:

Once sensitive data is inside the environment, how does anything get out safely?

That question has had a strong influence on how we are building TrustBoxx.

We believe a modern Trusted Research Environment should control the full lifecycle of sensitive data, not just provide a secure desktop around it.

Our thinking is straightforward:

Governed in. Researched inside. Observed throughout. Approved out. Destroyed on exit.
This is the principle behind the TrustBoxx architecture.

This is the principle behind the TrustBoxx architecture.

A secure research environment does not begin at the login screen.
It begins with the way data enters the environment.

Sensitive datasets may come from health systems, registries, universities, government bodies, research partners or other controlled sources. In each case, there needs to be a clear and auditable process for moving that data into the research environment.

In TrustBoxx, researchers do not ingest data directly. Data ingress is handled through a controlled administrative process using secure transfer mechanisms. The incoming data can be hash-verified and the acceptance recorded before it becomes available for research.

The same principle applies to software.

Researchers frequently need specialist tools, libraries and licensed applications. Blocking the public internet while leaving researchers without the tools they need would make the environment secure but impractical.

So TrustBoxx is designed to support software curation as part of the managed environment. Common research tools can be pre-installed. Additional client-specific or licensed tools can be reviewed and installed when required.

The boundary is controlled before the research begins.

The researcher should work where the data is

One of the simplest ways to think about a TRE is this:

Do not send sensitive data to the researcher. Bring the researcher to the data.

TrustBoxx provides a dedicated research environment for each client project. The research workstation runs inside a private AWS network with encrypted storage and controlled access.

Researchers connect through a browser-based access route using MFA and Guacamole before reaching the Windows research workstation.

Inside the environment, they can work with the tools needed for analysis. Depending on the project, this can include R, RStudio, Python, Jupyter, Stata, LibreOffice and other approved applications.

We also support local services that make the environment practical for day-to-day research.

• Gitea: can provide version control inside the TRE without allowing researchers to push code to an external repository.
• Nexus: can provide approved packages and software without opening unrestricted public downloads.
• Private AI assistance: can be made available inside the boundary so that AI can support the research workflow without sending sensitive data to a public model.

The objective is not to create a stripped-down desktop.

The objective is to create a useful research environment where the normal routes for moving sensitive data outside are tightly controlled.

“Please do not copy the data” is not enough

Policies are necessary. Training is necessary. User agreements are necessary.
But for highly sensitive data, policy should be backed by technical controls.

If researchers are not supposed to move information through the clipboard, copy files to their local machine or upload data to an external website, those actions should not remain freely available and depend entirely on user behaviour.

TrustBoxx therefore uses several layers of restriction around the research environment.

The workstation sits in a private subnet. Inbound access is limited to the controlled gateway. Internet access is restricted rather than openly available. Session controls can disable clipboard, USB redirection and file transfer. Access to internal storage and platform services can be controlled using AWS networking and application roles.

No single control is treated as the entire security model.

The value comes from the controls working together.

Why we think egress deserves more attention

Most security architectures spend a lot of time describing how users authenticate and how systems prevent unauthorised access.

A TRE needs the same discipline around output.

Research is useful only if something can eventually come out of the environment. That might be a statistical result, a report, a trained model, an aggregate dataset, a chart or another research output.

The challenge is allowing useful output to leave without creating a convenient route for sensitive source data to leave with it.

This is why we think about TrustBoxx as an egress-first TRE.

When a researcher wants to take an output outside TrustBoxx, they submit it through the egress workflow from inside the research environment. The submission includes the result and a written justification.

The platform can attach statistical disclosure control information and run automated checks against the submitted output. The file is hash-verified so the exact submitted version can be tracked through the process.

The important point is what happens next.

The researcher does not simply download the submitted file.

The request moves to a separate review and approval process outside the TRE.

An authorised approver reviews the output and decides whether it can be released. The approver is separate from the submitter. The decision is recorded, including the reason for approval or rejection.

At the time of release, the state of the request can be checked again before the approved output is made available outside the TRE.

This separation matters because it prevents the release decision from being reduced to a button controlled by the same person who created the output.

Egress becomes a governed process with evidence around it.

Approved output should be the only normal exit

A well-designed TRE should make the safe path the normal path.

Researchers should not need to invent workarounds to retrieve legitimate results, and administrators should not need to make ad hoc exceptions every time an output has to leave.

TrustBoxx is designed so that reviewed and approved outputs leave through the egress workflow. The release is attributed to the people involved, including who submitted it, who approved it and when it was released.

The released bytes can be made available for a limited period and then purged, while the audit record and file hash remain as evidence of what was approved.

This gives data owners something more useful than a statement that “downloads are restricted”.

It gives them a process they can inspect, govern and audit.

Monitoring should tell you what happened, not just collect logs

Preventive controls are only one part of a secure research environment.

Data owners also need visibility into what is happening inside the environment.

TrustBoxx collects workstation and session activity using monitoring tools such as Beats and Sysmon and centralises that information through ELK for review. AWS-level activity can be observed through services such as CloudTrail and CloudWatch.

The purpose is not simply to retain large volumes of logs.

The useful outcome is the ability to identify suspicious behaviour, investigate events and maintain a record of activity across the project.

For example, attempted exfiltration or unusual behaviour should be surfaced for attention rather than disappearing into a log archive that nobody reviews.

This is also important when a client needs evidence of how the environment was operated, who had access and what happened during the research period.

A TRE also needs an ending

Research environments often get discussed in terms of provisioning, onboarding and access.

The end of the project deserves the same level of design.

TrustBoxx environments are dedicated per client project. Infrastructure is created using Infrastructure as Code, and the lifecycle includes decommissioning when the project is complete.

Once the research has finished, approved outputs have been released and the required evidence has been retained, the environment can be destroyed. TrustBoxx can maintain evidence of that destruction as part of the project record.

This avoids a common infrastructure problem where temporary project environments slowly become permanent systems simply because nobody wants to take responsibility for shutting them down.

For sensitive data, deletion and destruction should be deliberate actions with evidence behind them.

The architecture is only part of the answer

It is tempting to describe a TRE as a collection of technologies.

VPCs. MFA. Encryption. Remote desktops. Logging. Egress controls.

All of those are necessary building blocks, but the important part is how they are arranged around the research process.

A data owner should be able to answer a much broader set of questions:

• Who is allowed to bring data into the environment?
• How is that data verified and recorded?
• Who can access the research workspace?
• What can researchers do inside it?
• Which routes for moving data outside are technically restricted?
• What activity is monitored?
• How is a research output submitted for release?
• Who reviews it?
• Can the submitter approve their own request?
• What evidence exists after an output leaves?
• What happens to the environment when the project ends?

That is the level at which we believe a modern Trusted Research Environment should be designed.

How we are building TrustBoxx

TrustBoxx is being built as a managed Trusted Research Environment for organisations working with sensitive data.

Each client project gets a dedicated environment rather than sharing a research workspace with other clients. Access, networking, software, monitoring, ingress and egress are managed as part of the platform. Governance and evidence are treated as part of the operating model rather than something added at the end of the project.

We are also aligning the platform and operating procedures with the SATRE approach as the product develops.

The architecture attached to this article shows the current flow in more detail, from external data sources and ingress through the research environment, monitoring, egress approval and final release.

The individual technologies will continue to evolve.

The principle should not.

Sensitive data should be governed when it enters, protected while research happens, observed while it is being used, reviewed before anything leaves and deliberately removed when the work is finished.

That is how we believe a modern TRE should work, and that is how we are building TrustBoxx.

Want to see how the flow works?

If you are responsible for sensitive data, research infrastructure, information security or governance and you are evaluating Trusted Research Environments, we would be happy to walk you through TrustBoxx and the thinking behind the architecture.

Request a demo and we can take you through the complete flow, including researcher access, monitoring, controlled ingress and the egress approval process.