Principal Investigator Acknowledgement: Risk Awareness of Non-Standard TRE Configurations¶
These implementations carry additional risks which need to be understood by the PI.
However, we recognise the need to permit these features in specific cases to facilitate important research objectives that cannot reasonably be achieved by other means. You will be required to provide justification for these configuration decisions, which will be reviewed and fed back into the risk assessment process.
This guide is intended to highlight potential threats associated with these features and to help you make an informed decision about the risks and benefits they may pose to your project and the data.
Our team will work with you to determine how to incorporate these features, using compensating controls to strike an acceptable balance between security and functionality.
As the risk landscape and tools available to mitigate threats evolves at significant pace, we will keep these projects under close review.
Temporary Internet Access¶
Threats – Temporary Internet Access¶
-
Malicious or compromised websites
Accessing external URLs may expose users to websites that are malicious or compromised. These websites can host malware, ransomware, or phishing attacks. If a user clicks on a malicious link, it could infect their computer or steal their personal information, breaching the security and integrity of your Trusted Research Environment (TRE). -
Data exfiltration
External URLs can be used to leak sensitive data from a secure environment. This could be done maliciously by tricking a user into clicking on a link that downloads a malicious payload, or by using a cross-site scripting (XSS) attack to steal data from a user's browser.
It may also occur accidentally, for example when a user pushes code or data to an external application containing sensitive information while the TRE is in this unfiltered state.
Risk Mitigations – Temporary Internet Access¶
-
URL filtering
Only the required URLs will remain open and all other internet sites will be blocked. These URLs must be examined and deemed reliable, reputable, and directly related to research objectives. This may include reviewing the reputation of the website, checking for any reported security incidents or vulnerabilities associated with the site, and assessing the reliability of the content hosted on the URLs. Users must be vigilant and learn to recognise potential security threats. -
Dedicated Proxy Server
We utilise a dedicated proxy server to monitor and control data flow. This server ensures that only approved data transfers occur and blocks any unauthorised attempts to move data outside the secure environment. -
Firewall Settings on OpenStack Instances
Our OpenStack instances are configured with strict firewall settings. Access is limited to specific IP addresses and ports, significantly reducing the risk of unauthorised data access or transfer. -
Multi Factor Authentication (MFA)
Users are required to log in with MFA to access the project environment. This additional layer of security helps prevent unauthorised access, even if login credentials are compromised. This can help to protect against session hijacking attacks. -
Restricted Access to Data Movers VM
Only members of the project ingress and egress security groups are permitted to log in to the Data Movers VM. This stringent access control ensures that only authorised personnel can interact with enabled external services access. -
Implementation Scope Limitation
The implementation of external services access is only allowed on the Data Movers VM. This restriction ensures that external service interactions are concentrated and managed in a controlled environment, reducing the risk of unauthorised data exfiltration. -
Additional Conditions
- This should only be done when you do not have sensitive data inside the environment.
- Supervision by a system administrator is required for the duration of the open-to-internet time.
- Access must be strictly time-limited.
Training¶
(If applicable, training expectations or requirements may be documented here.)
Enabling User Access to External Libraries (e.g. GitHub, Python, R, STATA)¶
Threats – External Libraries¶
-
Malicious or Vulnerable Code
Public repositories and third-party libraries may contain malware, backdoors, or unpatched vulnerabilities that could compromise the TRE environment. -
Data Exfiltration or Leakage
Repositories may be misused to exfiltrate sensitive data or accidentally expose credentials, API keys, or proprietary code. -
Unauthorised Access or Tampering
Weak authentication or permissions could allow unauthorised access or modification of code. -
Supply Chain Attacks
Compromised dependencies or packages from unverified sources can introduce hidden malicious code. -
Excessive or Unnecessary Packages
Installing too many or unused packages increases the attack surface and dependency risks. -
Outdated or Vulnerable Dependencies
Using unpatched software may expose the TRE to known exploits. -
Data Leakage (Accidental)
Sensitive information (e.g. API keys, passwords, or other confidential data) may be accidentally committed to public repositories, exposing it to unauthorised users and creating a security risk.
Risk Mitigations – External Libraries¶
-
Trusted Sources Only
Install packages or code only from verified repositories (e.g. PyPI, CRAN, GitHub community-verified sources). -
Read-Only Access
Public repository access is configured as read-only to prevent uploading or code modification. Sensitive or proprietary data must never be uploaded or shared. -
Secure Authentication
Multi-factor authentication (MFA) is required for all repository accounts.
Access control should use private repositories and restrict installation privileges to trusted users. -
License Compliance
Users must ensure compliance with software licensing requirements when utilising third-party libraries or software within their code. Proper attribution and adherence to open-source licences are essential to avoid legal issues and maintain transparency. -
Code and Package Review
Check provenance, reliability, and signatures of external code or dependencies before use. -
Responsible Code Sharing
Users must be cautious when sharing code from the TRE to public repositories. Any potential exposure of proprietary or sensitive code should be carefully evaluated, and appropriate measures should be taken to protect intellectual property and confidential information. -
Minimal Installation
Only required packages should be installed. Review and remove outdated or unused dependencies regularly. -
Regular Updates
Keep packages and dependencies up to date with the latest security patches.
Sharing Project Dataset/Storage Amongst Child TRE Projects¶
Threats – Shared Dataset/Storage¶
-
Data Confidentiality and Access Control
Sharing storage between Trusted Research Environment (TRE) projects introduces the risk of unauthorised access and potential compromise of sensitive research data. Inadequate access controls or misconfigured permissions can lead to unintended data exposure or unauthorised modification. -
Data Ingress and Egress Risks
Unregulated or unauthorised data transfers between TRE projects or to external locations can lead to data breaches or exposure of sensitive information. Inadequate verification of data integrity during transfers can result in corrupted or tampered data. Transfers that do not comply with established security policies or data protection regulations can lead to legal and compliance issues.
Risk Mitigations – Shared Dataset/Storage¶
-
Read-Only Access to RDS Share
Read-only access ensures that data integrity is maintained and prevents unauthorised data modification and leakage. Users can access non-sensitive data from the TRE but are unable to copy anything to that share from the TRE, thus preventing unauthorised egress of data. -
Understand and Review Access Permissions
Users should be aware of the access permissions they have for shared storage within the TRE. Understand the limitations and scope of your access privileges to ensure you only access data relevant to your specific project.
Review access permissions granted to shared storage folders or directories at least annually. Ensure that only authorised individuals or project members have access to your data. Notify project administrators if you notice any discrepancies or unauthorised access. -
Limit Data Sharing
Only share data with other projects when necessary and with proper authorisation. Avoid sharing sensitive or confidential data unless it is required for collaborative purposes and authorised by project leads or administrators. -
Report Anything Suspicious
Promptly report any suspicious activities or potential security breaches related to the shared storage to project administrators or the designated authority. This helps in identifying and addressing potential risks before they escalate.
Internal Data Sharing¶
Threats – Internal Data Sharing¶
-
Unauthorised Data Access
There is a risk that unauthorised individuals could gain access to sensitive data shared between TRE projects. -
Data Integrity Risks
Without proper controls, there is a possibility of data being altered or corrupted during the sharing process. -
Data Leakage
Sensitive data could potentially be leaked if the sharing mechanism is not securely implemented. -
Compliance Violations
Sharing data between TRE projects might inadvertently violate institutional or regulatory data protection policies.
Risk Mitigations – Internal Data Sharing¶
-
Secure NFS Protocol
The read-only sharing is achieved by setting up a Network File System (NFS) over a WireGuard connection between the two TREs. This ensures secure and controlled data access. -
WireGuard VPN
WireGuard is used to create a secure VPN tunnel between the TREs, encrypting all data transmissions and protecting against unauthorised access.
Only the project egress authority is authorised to manage and approve SFTP data transfers between TRE projects. This ensures proper oversight and control, and that only authorised personnel can initiate data transfers. -
Approval Process
The access request must be initiated and approved by the Principal Investigator (PI) of the main TRE project. This ensures that only authorised data sharing requests are fulfilled. -
Read-Only Access
Data is shared in a read-only mode, preventing any modifications, deletions, or additions to the data by the child TRE project. -
Access Control
Strict access control mechanisms are in place to enforce read-only permissions and ensure that only authorised users can access the shared data. -
Regular Monitoring
Continuous monitoring of data access and sharing activities is conducted to ensure compliance with the read-only access policy. -
Periodic Audits
Audits are performed periodically to review access logs and confirm adherence to security protocols. -
Compliance with Policies
All data sharing activities must comply with institutional data protection policies and relevant regulations.
| Document owner | ResOps |
|---|---|
| Review signoff | TRE/IG/ResOps Lead |
| Review frequency | Annual |
| Last review date | 24/11/25 |
| Reviewed build | 4ee62f1 |