| Table of Contents |
|---|
Overview
OpenSpecimen is a Java Spring and REST API based application. It is designed to handle highly sensitive data such as patient identifiers, demographics, clinical information, images, test results, etc. This document explains the security considerations used in OpenSpecimen to achieve this.
Latest technology stack
OpenSpecimen is built using the latest versions of all the technology platforms used internally. This includes Tomcat, Apache, Oracle, MySQL, Java, etc.
HTTPS/SSL
OpenSpecimen supports (and highly recommends) using SSL enabled webserver to ensure encrypting data over the network.
Authentication
OpenSpecimen has an in-built user management module. For tighter security, adopters can consider integrating OpenSpecimen with their institution's LDAP (e.g., Active Directory). This will also avoid users having to remember multiple user names and passwords.
Password protection
Note: This does not apply if user accounts are integrated with the Customer's Identity Providers (IdP).
Where N is configured as per the Customer's needs.
- Password should be of length N characters (default 8)
- Password complexity defined via RegEx as per customer needs (default: one capital, one number, )
- Cannot be the same as the last N passwords
- Accounts are locked after N failed attempts
- Accounts are locked after N days of inactivity
- Password expiry every N days
- Passwords are never emailed in free text
- Passwords are stored in a one-way encrypted format
Account Protection
Where N is configured as per the Customer's needs.
- Accounts are locked after N failed attempts
- Accounts are locked after N days of inactivity
PHI Handling
Users can be restricted not to view PHI data using the roles and privileges module.
Audit
Login Audit
Every login and logout session is recorded, including failed login attempts.
Data manipulation audit
Every action that results in data being changed is audited (i.e., create, edit, delete). The audit information contains:
- Timestamp
- User id
- IP address
- Record id
- In the case of edit: old value and new value
Currently, audit reports will have to be generated either directly from the database or via REST API calls. There is no user interface for the same. Building a UI driven audit reporting module is present in our product roadmap.
Reporting audit
Every time a user runs a report, a log is maintained, which includes information like:
- User ID
- Timestamp
- Report ID
- Internal SQL generated