Pure LTP and DSpace7 securityPure LTP and DSpace7 security

General consideration

When transferring restricted data across different systems, it is crucial to recognise that each system may have its own unique permission models and security protocols. This means that data protected in one system, such as Pure, may not have the same level of protection in another system, like DSpace7.

In general, we do not recommend sending restricted data to DSpace7 due to the following reasons:

Different Permission Models: DSpace7 may not offer the same granularity or robustness in its permission settings as Pure, potentially exposing sensitive data to unauthorised access.

Security Protocols: The security measures in place in DSpace7 may not align with the requirements needed to protect restricted data, increasing the risk of data breaches.

Compliance Risks: Transferring restricted data to a system that does not meet compliance standards can lead to legal and regulatory issues, especially if the data is subject to specific data protection laws.

Lack of Control: Once data is transferred to DSpace7, it may be more challenging to control access and monitor usage, which is critical for maintaining the confidentiality and integrity of restricted data.

Institutional Policies: Many institutions have specific policies regarding the handling and storage of restricted data. Transferring such data to a system that does not meet these policies could result in violations.

Given these considerations, it is advisable to explore alternative solutions for managing restricted data that ensure compliance with security and privacy standards. If there is a need to use DSpace7, consider implementing additional safeguards or consulting with IT security professionals to assess the risks and develop a mitigation strategy.

How Pure Implemented Security Measures to Protect Data in DSpace7

General Behaviours Across All Content Types

Pure has established a robust framework for managing and protecting data through various security measures. Here’s an overview of how these measures are implemented, particularly in relation to content visibility and confidentiality. The DSpace7 UI, will only display files that are placed in the "ORIGINAL" bundle, meaning that even when logged into the UI, files placed in other bundles will only be visible through editing the items.

Confidential Content

All confidential content is stored in Pure with confidentiality visibility. This ensures that sensitive information is not exposed to users where it wasn't intended. DSpace7 does not have a specific concept for confidential content, which necessitates caution when considering the transfer of such data to this system.

Content Visibility: Pure categorises content visibility into three main levels, each with specific access controls

Public: No restrictions

Implementation: Files are placed in the "ORIGINAL" bundle, unless other restrictions apply (see below).

Access Control: Policy set for "Anonymous" access. This allows anyone to view the metadata without any authentication.

Campus: Restricted to a specific IP range (e.g., university campus)

Implementation: All files are placed in a "BACKEND" bundle.

Access Control: No policies are applied. DSpace7 does not have a concept of campus access, this means that data will not be publicly available in DSpace7, setting no policy is effectively limiting access to non-authorised users.

Backend: Restricted to Pure users only

Implementation: All files are placed in a "BACKEND" bundle.

Access Control: No policies are applied. This ensures that the data is not publicly accessible in DSpace7 without authorised access, maintaining a high level of security for sensitive information.

Research Output Electronic Version File Access

Pure employs a structured approach to managing access to electronic versions of research outputs, categorising them into different access types. Each type has specific handling and security measures to ensure appropriate access control. Here’s a breakdown of how each access type is managed:

Open

Implementation: The file is placed in the "ORIGINAL" bundle. 

Access Control: The policy group is set to "Anonymous," allowing unrestricted access to the file. Anyone can view and download the file without authentication.

Embargoed

Implementation: The file is placed in the "ORIGINAL" bundle. 

Access Control: The policy group is set to "Anonymous," but with a Start Date that corresponds to Pure's embargo end date. This means that while the file is technically available, access is restricted until the embargo period expires.

Restricted

Implementation: The file is placed in a "BACKEND" bundle. 

Access Control: No policy group is set, meaning that the file is completely restricted from public access. Since DSpace7 does not have a concept of campus access, a stricter access model is applied to ensure that only authorised users can access the file.

Closed

Implementation: The file is placed in a "BACKEND" bundle. 

Access Control: No policy group is set, meaning that the file is completely restricted from public access. Only users with appropriate permissions within Pure can access the file.

Unknown

Implementation: The file is placed in a "BACKEND" bundle. 

Access Control: No policy group is set, and this access type is treated with the same restrictions as "Closed." This ensures that files with an unknown status are not accessible to unauthorised users.

Student Thesis and Datasets File Visibility

Public - no restrictions

Implementation: The file is placed in the "ORIGINAL" bundle. 

Access Control: The policy group is set to "Anonymous," allowing unrestricted access to the file. Anyone can view and download the file without authentication.

Campus - Restricted to specific IP range

Implementation: The file is placed in a "BACKEND" bundle. 

Access Control: No policy group is set, meaning that the file is completely restricted from public access. Since DSpace7 does not have a concept of campus access, a stricter access model is applied to ensure that only authorised users can access the file.

Backend - Restricted to Pure users

Implementation: The file is placed in a "BACKEND" bundle. 

Access Control: No policy group is set, meaning that the file is completely restricted from public access. Only users with appropriate permissions within Pure can access the file.

Student Thesis and Datasets File Embargo Check

Implementation: The file is placed in the "ORIGINAL" bundle. 

Access Control: The policy group is set to "Anonymous", but with a start date that corresponds to Pure's embargo end date. This means that while the file is technically available, access is restricted until the embargo period expires.