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.
✔ User data is encrypted at rest and over a network
✔ 21 CFR 11 compliant, GLP support
✔ SSO, LDAP/SAML2 support, hierarchic tiered admin
✔ Protection against OWASP Top 10 web application security vulnerabilities
✔ Backup and disaster recovery strategies
✔ Independent security accreditation
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 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.
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.
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.
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.
✔ 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.
✔ 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.
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.
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:
✔ 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 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.
✔ Access to resources is controlled by a combination of Role Based Access Control and instance-based permissions (Access Control Lists).
✔ Only same-origin POST requests are permitted.
✔ 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.
✔ All user input is validated for erroneous or malicious input.
✔ Exclusive use of prepared statements guards against SQL injection attacks.
✔ We regularly update libraries and 3rd party software components to ensure the latest security fixes are in place - see Supply Chain section above.
✔ All security events are logged to a dedicated Security log whose output can be consumed by a SEM tool.
✔ 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.
✔ CREST-accredited independent penetration testers regularly evaluate RSpace, using manual and automated methods. The latest test was April 2021. We are happy to discuss findings with customers or serious potential customers.