Security

Updated 1 year ago by Vaida

Overview

RSpace takes the security of your personal and scientific data extremely seriously. We use a range of technologies to safeguard your data, including encryption, auditing, logging, and backups. The responsibility and privilege of protecting your identity and scientific information is our first priority and our team is committed to making this happen.

The RSpace web application follows OWASP guidelines and Oracle Cert Secure Coding standards and is continuously tested for security flaws. Our development processes consider the security impact for all new features and improvements.

ResearchSpace has SOC 2 - Type 2 unqualified certification , SOC 2 Type 2 unqualified report indicates the auditors didn’t find anything below the standards set by the American Institute of Certified Public Accountants (AICPA) Trust Service Criteria (formerly the Trust Service Principles).

SOC 2 Type 2 is an auditing procedure highly adopted by cloud-based service providers by the American Institute of Certified Public Accountants (AICPA). This ensures a standard degree of security control in areas including organization and management, communications, risk management, monitoring of controls, and more. Meeting this milestone addresses critical compliance requirements of Research Spaces diverse and global customer base. It examines a service provider’s internal controls and systems related to security, availability, processing integrity, confidentiality, and privacy of data.

This means RSpace has maintained the highest level of requirements within the industry to further protect and secure customer data and the availability of its product.

The full SOC2 report can be made available to customers on signing of a Non-disclosure Agreement.

For hosted customers, RSpace uses Scalable Storage in Cloud provided by Amazon Web Services. Amazon stores data in highly secured data centers, which utilize state-of-the-art electronic surveillance and multi-factor access control systems. Data centers are monitored 24/7 by trained security guards and their access is authorized strictly on a least privileged basis.

For on-premises customers, RSpace integrates smoothly into your environment, supporting both SAML2 and LDAP-based user authentication. RSpace can be fully installed and managed by customer IT staff, if it is required that no access be permitted to Research Space staff.

The following sections explain some of the security procedures and strategies used to keep users’ data and details secure.

We regularly commission penetration testing from an accredited specialist security testing company. These are week-long tests incorporating both manual and automated testing. We are happy to share the latest report with prospective and current customers on request.

Supply chain security

RSpace software comprises bespoke code written in-house, open-source third-party libraries and a small number of commercial third-party libraries.

In-house code is reviewed for secure coding practices during code-review stage. Source code development is conducted entirely in-house and is not sub-contracted.
RSpace source code is stored on Github, and therefore benefits from Github's automated vulnerability scanning of dependent libraries. If a vulnerability is detected with a known fix, a Pull Request with a recommended fix is auto-generated and the development team notified. In this way, vulnerabilities in our dependencies can be detected and addressed as part of the Software Development Lifecycle. New libraries can be vetted for known security defects before going into production.
For commercial libraries, we receive security advisories directly as part of our service agreement and update accordingly.

Password security

In ‘stand-alone’ mode (i.e. not using an institution’s SSO mechanism to authenticate users), RSpace maintains its own authentication mechanism and credentials database.

Passwords created by the user must be at least 8 characters long, not be identical to the username, and not belong to a common password blacklist (e.g., ‘password’).
Passwords are salted with a unique 16 byte prefix generated by a cryptographically secure random number generator and hashed, before persisting to the database. In this way the plaintext password is never stored, and, in the event of the password table becoming compromised, it is not immediately susceptible to dictionary or rainbow table attacks.
To prevent brute-force password guessing attacks, accounts are locked out for a short time after a number of consecutive unsuccessful logins. All login attempts are logged to a security event log.
Auto-completion of input fields is disabled for login and signup pages.
We also recommend that for admin role accounts, end-users follow good practice by disabling password-storing in their browsers.
After logout, sensitive pages are not cached in the browser.
Plain-text passwords are never emailed to the user as a result of password reset / forgotten password workflows.
Any credentials used by Research Space staff to access customer servers in an administrative or maintenance role are always unique, long, securely-random, and managed in a secure vault with access restricted to operational personnel.

If RSpace is deployed in an institution using SSO, then it is the institution’s Identity Provider's responsibility to safeguard passwords and login credentials.

Network security

RSpace must run over a secure HTTPS connection which encrypts the communication channel between client and server, and also verifies the identity of the endpoint by SSL certificates issued by a recognized Certification Authority.

Database security

No direct access to the database is possible by end-users or from outside an RSpace deployment's internal network.
All SQL queries use Prepared Statements to defend against malicious user input.
The database itself is not encrypted, but OS-level encryption can be used if necessary.
The RSpace database client runs using limited permissions.

Resource Authorization

Privacy of the user’s content depends on RSpace's authorization policy. All access to ELN entries or resources requires authenticated access by default, and URL paths are protected by user roles. At a fine-grained level, access to individual records is controlled by a combination of Access Control Lists (ACLs) and user-specific permissions. Every action (e.g., Read, Edit, Delete, Export, Copy) is authorized at the server level before proceeding - RSpace does not solely rely on controlling the actions available in the UI, as these may be circumvented by URL-guessing attacks.

For example, a user has authorization to edit content created by him/herself, but must be granted permission to access content created by other members of his/her group. To access content created outside a lab group, all PIs or RSpace managers of the groups concerned must accept the sharing request. Otherwise, the content is not accessible. A request to view a record, for example at '/notebook/view/123/' will check for the authenticated user's permission to access record 123 before proceeding.

For more coarse-grained permissions - for example, global admin permissions - we use Role Based Access Control (RBAC) to restrict the available functionality to the user’s role.

Defence against malicious use

We are guided by OWASP's guidelines on securing web applications and aim to be at least level 1 compliant in their Application Security Verification Standard (ASVS). Here, we briefly enumerate our policies in the following Control areas:

Authentication & session management (A2)

Failed logins give no information about reason for failure.
Sensitive information is never included in URLs.
Users are informed at each login when their last login was, so they can see if anyone has impersonated them since their last session.
A security event logs all login attempts.
To minimize brute force attacks, accounts are temporarily locked after 4 unsuccessful logins.
RSpace uses secure random number generators to generate session keys.
Sessions expire after a short time of inactivity. Users performing sensitive operations must re-authenticate at the time of the operation (e.g., password resets, signing documents, etc).
Browser caching - Our policy in this are is guided by OWASP’s guidelines at (https://wiki.owasp.org/index.php/Testing_for_Logout_and_Browser_Cache_Management_(OWASP-AT-007)). In brief, sensitive data such as login pages, signup pages, user profile pages, and any pages only accessible to a ROLE_ADMIN or ROLE_SYSADMIN are returned from the server with HTTP headers set to prevent browser caching. When a user logs out (or his session expires due to inactivity) the session is invalidated, and clicking on the browser’s ‘Back’ button will trigger a reload from the server for these pages, which will redirect to the login page.

Authorization of resources

Access to resources is controlled by a combination of Role Based Access Control and instance-based permissions (Access Control Lists).

Cross-Site Request Forgery

Only same-origin POST requests are permitted.

Cross-site scripting

All user input submitted to the server is filtered before being sent back to the client for display. Client side libraries use ‘safe’ Javascript methods to manipulate user input - e.g., jQuery’s text() method.

Injection

All user input is validated for erroneous or malicious input.

Exclusive use of prepared statements guards against SQL injection attacks.

Current libraries (A9)

We regularly update libraries and 3rd party software components to ensure the latest security fixes are in place - see Supply Chain section above.

Security event logging

All security events are logged to a dedicated Security log whose output can be consumed by a SEM tool.

Revision history and audit trail

The revision history records all changes made to research records over time. RSpace keeps a full record of this, including timestamps. The audit trail records events on the system - document edits and updates are recorded.

Testing and audits

CREST-accredited independent penetration testers regularly evaluate RSpace, using manual and automated methods. The latest test was March 2023. We are happy to discuss findings with customers or serious potential customers.

If you wish to speak to us about any security related matters, please email security@researchspace.com

Vulnerability Disclosure Program

RSpace follows industry standards, adopting the use of "security.txt (https://securitytxt.org/)". People wishing to know more information can read our security.txt file located at https://researchspace.com/security.txt