System Description

Host

• Google Cloud Platform

• Google Cloud Platform

Architecture

The system is running in Kubernetes and is scalable to meet potential demand. The frontend is managed via a github-backed Google Cloud Build pipeline, which makes sure all changes to the system are approved, version controlled, and pushed by the RTIC team.

The system is running in Kubernetes and is scalable to meet potential demand. The frontend is managed via a github-backed Google Cloud Build pipeline, which makes sure all changes to the system are approved, version controlled, and pushed by the ASU Research Computing team

Regulatory Compliance

Complies with the guidance set forth by the Health Insurance Portability and Accountability Act (HIPAA)

NOTE: Please contact a system administrator if your research must comply with 21 CFR Part 11 for the purposes of obtaining eConsents. Currently, this system is not set up to comply with the Code of Federal Regulations for obtaining electronic signatures. System and researcher processes must be confirmed and put in place for compliance, typically done on a project-by-project basis.

Data Approved for Collection

• Non-sensitive data

• Data that doesn’t interact with a covered entity, such as doctor’s office or insurance provider data

• Sensitive data that can be declined to provide, such as non-required questions regarding health history

• Non-sensitive data

• Data that doesn’t interact with a covered entity, such as doctor’s office or insurance provider data

• Sensitive data that can be declined to provide, such as non-required questions regarding health history

• Data that can’t be declined to provide, such as lab values

• Data interacting with a covered entity, such as a doctor’s office or insurance provider

Data Exports

• the ability to export data is available for all users and can be monitored using the User Rights module as needed

• the ability to export data should only reside with the ASU faculty sponsoring the data collection

• data that includes identifiers should be exported to a secure system, such as the KE Secure Cloud

Software Security

To help protect and secure the data stored in REDCap’s back end database, the software application employs various methods to protect against malicious users who may attempt to identify and exploit any security vulnerabilities in the system. Such methods will be described here in technical detail. In REDCap, all incoming data gets intentionally filtered, sanitized, and escaped. This includes all data submitted in an HTTP Post request and all query string data found in every URL when users access REDCap, among other modes through which user-defined data gets submitted in the application. Server environment variables that are vulnerable to forgery by end-users are also checked and sanitized. All user-submitted data is properly filtered for any possibly harmful markup tags (e.g. <script>) and is then escaped before ever being displayed on a web page within the application. SQL queries sent to the database server from REDCap are all properly escaped before being sent. If any values used in an SQL query originated from user-defined values, they would also have already been sanitized beforehand, as described above. User-defined data used within SQL queries have their data type checked to prevent any mismatching of data types (e.g. making sure a number is really a number). These processes of sanitization, filtering, data type checking, and escaping all help to protect against methods of attack, such as Cross-Site Scripting (XSS) and SQL Injection. To specifically protect against Cross-Site Request Forgery (CSRF), which is another method of attack, REDCap utilizes a “nonce” (a secret, user-specific token) on every web form used in the application. The nonce is generated as a unique value for each new HTTP request in every REDCap session. Additionally, REDCap employs “rate limiting” on its web pages, in which there is a set maximum number of web requests per minute that are allowed from a single IP address, and after that maximum is hit, the IP address of that user is permanently banned from REDCap. Rate limiting prevents denial of service attacks by bots as well as preventing other types of hacker attacks that require making many requests to the server in a short amount of time, such as with a BREACH attack. Regarding the prevention of BREACH attacks specifically, in addition to using rate limiting, REDCap always outputs an invisible string of random text of random length on every web page (to conceal the page’s true length) as an effective technique for mitigating such an attack. REDCap’s use of a unique nonce token on every web form also greatly diminishes the possibility of a BREACH attack. With regard to the security of cookies used by REDCap, all session cookies and other cookies related to authentication that are created by REDCap will automatically have the “HttpOnly” attribute set to TRUE. By default, the “Secure” cookie flag will be set to FALSE. while this is slightly more insecure, setting its value as TRUE can sometimes cause login issues with certain server configurations, such as reverse proxies. So for compatibility reasons, it is set as FALSE by default. However, any institution can enable the “Secure” flag of session cookies to improve security by setting session.cookie_secure=On in the REDCap web server’s PHP.INI configuration file.

Software Security Review

ASU’s Enterprise Technology conducted a Vendor IT Risk Assessment (VITRA), also known as a security review, on the REDCap software from Vanderbilt University Medical Center:

• Software Type: ASU Hosted and Managed Server Software

• Total Risk Score: 4 - Low. This product poses no elevated 3rd party risk as it is hosted and managed locally. To ensure REDCap users have access only to data and information that they are supposed to have within the application, user privileges are utilized within the software.

System Access

Availability

• All ASU faculty, staff, and students

• All non-ASU collaborators

• All ASU faculty, staff, and students

• All non-ASU collaborators

Prerequisites for Access

• Certified human subjects training

• Annual Information Security Training

• Certified human subjects training (ASU or external institutional equivalent)

• Annual Information Security Training

• Annual HIPAA training (ASU or external institutional equivalent)

Logging In

• Log in page: https://redcap.asu.edu/

• ASU personnel can log in using single sign-on (SSO)

• Non-ASU personnel: ASU personnel will need to request an account on behalf of the non-ASU person here and indicate the name of the ASU person that will supervise the activity

• Log in page: https://esr.asu.edu/

• ASU personnel and Non-ASU personnel must request an account here and indicate the ASU faculty that will sponsor the activity

Passwords

• ASU faculty, staff, students, and affiliated users should log in using single sign-on (SSO)

• Non-ASU personnel can utilize the ‘Forgot your password’ link on the REDCap system log in page

• Internet browser capability to save and autofill password field is enabled

• All users can establish their own password (manual account creation, i.e. not SSO)

• All users can utilize the ‘Forgot your password’ link on the REDCap system log in page

• Internet browser capability to save and autofill password field is enabled

Expirations and Suspensions

• ASU personnel’s system access is dependent on the status of their ASURite

• non-ASU personnel accounts will require approval for renewal. The initial expiration date for the account will be set to the nearest of the following dates, with renewal approvals required every timepoint thereafter.

  • April 15th

  • August 15th

  • December 15th

• To request an extension to an existing account, renewal for an existing account, or renewal for a suspended account, the ASU person supervising the account must submit a ticket here

• All accounts will require approval for renewal. The initial expiration date for the account will be set to the nearest of the following dates, with renewal approvals required every timepoint thereafter.

  • April 15th

  • August 15th

  • December 15th

• Appropriate HIPAA training must be documented prior to extensions

• To request an extension for an existing account, renewal for an existing account, or renewal for a suspended account, the ASU account holder or ASU personnel supervising the account must submit a ticket here

Revocation

A user account may be revoked if:

1. The user leaves the university

2. The user is determined to have misused the system per ACD125

Note: The content created by the user is not deleted and will be accessible after the account is extended or re-activated.

System Configuration

Automatic Log Out

• After 15 minutes of inactivity

• Users will get a two-minute warning before they are automatically logged out

• After 15 minutes of inactivity

• Users will get a two-minute warning before they are automatically logged out

Failed Log In Lockout

• Users will be locked out for 15 minutes after 3 failed log in attempts

• Users will be locked out for 15 minutes after 3 failed log in attempts

System Services

Backups

• The VM itself has 7 days worth of snapshots through the hypervisor.

• The backend block storage for the VMs also has 14 days worth of snapshots, and is replicated offsite

• Having these snapshots allows for the ability to restore the machine to previous states.

• The front end of the system is version controlled with gitlab

• The backend SQL database is backed up on a daily basis

• Backups are kept for 7 days.

Updates

• Weekly bug fixes

• Monthly minor improvements

• Semi-annual major improvements

• Weekly bug fixes

• Semi-annual minor and major improvements

Unauthorized Access

Validation

Projects

New Projects

• ASU faculty, staff, and students signing in using SSO can create new projects

• ASU faculty and staff can create new projects, take responsibility for and must supervise any student(s) they create projects for

• For any questions regarding this process, please:

  1. Submit a request here

  2. Choose ‘Request for project support’

  3. Select ‘HIPAA aligned’

  4. Enter ‘TBD’ as the project ID

  5. Include ‘Ability to request a new project be created’ in the 'Details

Project Access

• Project-level access should be administered by users with User Rights capabilities on the project.

• For ASU personnel, after the user has logged in for the first time, their username/name will show as an option to be added in the User Rights module of the project

• For non-ASU personnel, the username/name will show as an option to be added in the User Rights module of the project after the account has been added to the system by the administrator.

• Project-level access should be administered by users with User Rights capabilities on the project.

• The username/name will show as an option to be added in the User Rights module of the project after the account has been added to the system by the administrator.

Project Audits

Both REDCap services may be audited for proper service and use. This is to ensure that projects are positioned in the correct version of the product. As a result of a project review, project owners may be advised to migrate a project from one version to another.

ASU REDCap administrators perform these operational audits as resources permit. REDCap also provides audit trails for tracking data manipulation and user activity within a project. These audit trails are available to project owners and system administrators.

REDCap has a built-in audit trail that automatically logs all user activity and logs all pages viewed by every user, including contextual information (e.g. the project or record being accessed). Whether the activity be entering data, exporting data, modifying a field, running a report, or add/modifying a user, among a plethora of other activities, REDCap logs all actions. The logging record can itself be viewed within a project by users that have been given privileges to view the Logging page. The Logging page allows such users to view or export the entire audit trail for that project, and also to filter the audit trail in various ways based upon the type of activity and/or user. The built-in audit trail in REDCap allows administrators to be able to determine all the activity and all the data viewed or modified by any given user

User Privileges

To ensure that REDCap users have access only to data and information that they are supposed to have access to within the application, user privileges are utilized within the software. Each user has their own account, and their user account will only have access to REDCap projects that they themselves have created or to projects to which other users have granted them access. Some of the general user privileges in the application are dictated by the customizable settings that each institution can adjust, such as whether or not users can create their own projects or if an administrator must create it for them, among other settings. User privileges are also granular on the project level and can be modified within any given project by someone with proper privileges accessing the project’s User Rights page. The creator of a project will automatically be given full rights to everything within the project, after which they may grant other users access to the project and limit those users’ privileges as desired. Within each project, there are user controls to limit access to various functionality and modules, such as being able to export data, to enter data, to add or modify database fields or survey questions, to build or run reports, to modify user privileges, to view the logging records, and so on. Another feature called Data Access Groups can be implemented to help segregate users and the data they enter by placing users into data access groups, after which they will only be able to access records created by someone in their group. This particular feature is entirely optional but is especially helpful in certain situations, such as for multi-institutional projects where the data entered by one institution should not be accessible or viewable by other institutions with access to that same project.

User Activity

Within each project, a comprehensive list of names of authorized personnel (including terminated users) and a description of their access privileges is available in the Logging module. Access to this module and its data is dependent on the user’s privileges within the project.