Platform Information

1. Introduction

1.1 Purpose

This standard defines platform specifications and requirements for the PrefApp platform administered by UBC Advanced Research Computing (ARC). This describes the overarching structure of the platform, its instances, and servers.

1.2 Scope

This Standard applies to all servers that collectively house the PrefApp platform. This includes the associated PrefApp production application and database instances.

2. Standard

2.1 Platform Overview

The platform consists of a production instance of PrefApp.

2.2 Server Baseline

All servers are EDUCloud virtual machines, instantiated following baseline specifications. The baseline configuration is:

- Ubuntu Linux 18.04 LTS

- SSH access is restricted to the ARC VLAN with users access managed through the UBC ELDAP service.

- root access is restricted. It is only initially provided to the arcansible setup user.

- sudo access is granted manually by the ARC Systems Team only to the roles responsible for managing the Prefapp platform.

All maintenance and updates must be done in accordance with the ARCS-13: ARC REDCap Maintenance standard.

2.3 Application Servers

All application servers include Ruby 2.6.3 and Nginx 1.14.0 in addition to the baseline. The associated PrefApp software installed also includes its own dependencies. These can be found in the open-source decideapp repositories:

● Web application: https://github.com/hicklin-james/dcida_web_pub

● API: https://github.com/hicklin-james/dcida_api_pub

2.4 Database Servers

All database servers employ PostgreSQL 12 in addition to the baseline.

3. Responsibility

3.1 Prefapp Team

Is responsible for the configuration and support of the PrefApp applications and the configuration, operation, and maintenance of the servers.

3.2 ARC Systems Team

Is responsible for the configuration, operation, and maintenance of the underlying platform.

3.3 ARC Sensitive Research Team

Is responsible for providing technical advice and documentation for the security and privacy of the underlying platform.

1. Introduction

1.1 Purpose

This document explains the terms of service for the PrefApp platform managed by the PrefApp application developers (PAD). It contains important information about the service and addresses eligibility, suitability, User responsibilities, access, support, and maintenance.

1.2 Background

PrefApp offers a free, easy-to-use, and secure method of flexible yet robust data collection. It is especially popular for use in health research projects where data including personal information may be collected. This implementation provides eligible research groups access to the software and is centrally managed by PAD.

1.3 Platform Description

PrefApp offers a suite of customizable survey templates that are tailored to the needs of preference elicitation research. PrefApp features will be maintained and security will be kept up-to-date. Only stable features will be available via PrefApp. Should new features be developed, these will be added as they become available.

The PrefApp servers are physically located in Canada at the UBC University Data Centre. See the PrefApp Security Statement and PrefApp Platform documents for detailed technical specifications and security information.

1.4 Suitability

PrefApp is an online webapp designed to facilitate data capture, primarily for preference research. It is a useful self-service web application for the collection preference data, such as that collected via discrete choice experiments and best-worst scaling tasks. It is designed to meet the specific needs of preference elicitation research and to provide the technical controls necessary to allow for sensitive data capture. Like any tool, it has limitations; It is not the best tool for all projects. It is important to understand the limitations of PrefApp to ensure it is suitable for project needs. Reviewing the Frequently Asked Questions on the PrefApp website (www.PrefApp.org) can help can help potential users understand if the platform is appropriate for their project.

1.5 Caveats

There are no representations or warranties, express or implied, as to the description, quality, completeness or fitness for any purpose of any services or information provided hereunder or described herein. Further, there is no ongoing commitment to ensure the operation of the PrefApp platform for any period of time. The PAD may terminate the operation of the PrefApp platform at any time, subject only to the requirement to use reasonable efforts to provide sufficient advanced notice to all users. It is the responsibility of the Project Owner to locate an alternate service and transfer all data.

All Users agree to use this platform in compliance with and only for purposes permitted by UBC Policy SC14 Acceptable Use and Security of UBC Electronic Information and Systems and associated information security standards. For more information, please refer to: https://cio.ubc.ca/information-security/policy-andstandards/information-security-policy-standards-and-resources

2. Access

2.1 Eligibility

Faculty and students at postsecondary institutions in Canada may request a Primary User account.

All Users must have their own valid institutional email address in order to be provisioned access to the PrefApp platform. Valid institutional email addresses include those from universities, hospitals, colleges, research institutes and centres.

2.1 User Types

There are three (3) types of Users that may access the PrefApp platform:

2.2.1 Primary Users:

Are eligible postsecondary faculty or students. Primary users may create projects and can allow other users to access and modify their projects. Primary users are considered the owner of each project they create, and are responsible for ensuring their project(s) remain in compliance with these terms.

2.2.2 Participant Users:

Study participants who have been provided access to PreApp via an identifiable link to a specific project to enter data into the system. They do not have any administrative roles in PrefApp.

2.2.3 Anonymous Users:

Individuals who access PrefApp instruments without authentication. Typically, these are anonymous study participants but depending on the project design, they may also be part of the research team.

2.4 Account Suspension

Inactive User Accounts are automatically suspended by the system after 180 days of inactivity. To maintain an active account Users must login to the system at least once during this interval. There is no requirement to interact with the system apart from logging in. Users must contact PrefApp support directly to request a reactivation (refer to PrefApp website: www.PrefApp.org. Accounts that are inactive for 365 days will be deleted alongside all associated data.

2.5 User Responsibilities

Users:

· Must not share any access credentials with any other individual.

· Must notify PrefApp support in addition to following regular institutional procedures immediately in the event of a suspected privacy breach, in the event their access credentials are compromised or believed to have been compromised, or any other security incident.

Primary Users:

· Must read, understand, and agree to these terms before using the PrefApp platform. Users are responsible for ensuring their use of the platform corresponds to all applicable regulations, research requirements, policies, and ethical requirements.

2.6 Project Suitability

The PrefApp software was designed as a secure data collection tool for preference elicitation studies. Other platforms, like REDCAP, are better suited for clinical research that requires collection of personal health information (PHI). The PrefApp API can be used to allow survey customization based on PHI without collecting PHI directly in PrefApp.

By requesting a project and through the use of the PrefApp platform, Primary Users agree to ensure that their use of the PrefApp platform is consistent and remains in compliance with all applicable institutional policies, regulations, laws, ethics requirements, and agreements. It is recommended that all Primary Users review UBC guidance on conducting online surveys:

https://universitycounsel.ubc.ca/files/2015/05/Fact-Sheet-Conducting-Surveys.pdf https://ethics.research.ubc.ca/sites/ore.ubc.ca/files/documents/Online_Survey-GN.pdf

2.7 Requesting a New Project

Primary Users can create, and thus own, up to three projects at any given time. Projects to which a user has access but does not own do not count towards the three projects limit. A user may request additional projects by emailing PrefApp Support at support@PrefApp.org. Requests will be reviewed on an individual basis.

2.8 Project Use

In all cases: projects may be used for testing while in development mode but it is the responsibility of the Project Owner to move the project into production before commencing active data collection. Regular audits of the system are in place to monitor all projects. The Project Owner will be contacted if a project, still in development mode, appears to be employed in active data collection.

Projects are limited to two (2) gigabytes (GB) in total file size (eg: attached files, PDFs, images etc). The Project Owner is responsible for ensuring the projects for which they are responsible are kept within this limit. The Project Owner will be notified if their project has exceeded this limit, and will be given 30 days to reduce their project size below this limit. Projects that exceed this limit beyond the 30 day window will revert to development mode.

2.9 Project Archive

Once data capture is complete, it is expected that data will be downloaded and the data hosted on PrefApp will be deleted.

3. Support

3.1 Support Commitment

PrefApp support is available but limited. To conserve resources, users are advised to visit the PrefApp website before contacting PrefApp support. The PrefApp website includes frequently asked questions, how-tos, and tutorials that explain how to use PrefApp features. Programming knowledge is not required to use PrefApp but basic knowledge of HTML and CSS are useful for customization. PrefApp Support is available for the use of the platform, technical questions, and guidance regarding appropriate use of the platform and instrument configuration.

3.2 Accessing Support

Request support by contacting PrefApp Support (support@PrefApp.org). Support is provided on a best effort basis and by a team of individuals with distinct skill sets. The individual(s) that respond may change based on the nature of the request.

4. Maintenance

4.1 Maintenance Windows

To facilitate required upgrades and patches the PrefApp platform does not have a pre-set maintenance window, beyond those provided by the underlying ARC infrastructure. Users will be notified in advance when the maintenance window will be required in a given month and its estimated duration. Regular upgrades and patches will only be performed during this window.

4.2 System and Software Upgrades

Regular upgrades to the PrefApp platform will be performed as needed or as new features become available.

4.3 Add-On Modules

The PrefApp architecture supports software add-ons in the form of modules to extend the functionality of the system. Some add-ons are created by collaborating development teams outside the PrefApp project. Any included add-ons are listed on the PrefApp website (www.PrefApp.org).

Projects intending to use features provided by add-ons built by other teams should consider that these are not provided by the PrefApp project and may not continue to be maintained by their respective development team. PrefApp prioritizes maintenance of the core PrefApp platform, should an add-on module no longer function following a PrefApp software upgrade, it may be disabled or removed until such time as a new version is released. Security, Stability, and Urgent patches will also be prioritized in this manner. If an add-on is found to present a security or privacy vulnerability, it may also be disabled or removed.

Support for add-on modules is provided on a best-effort basis only.

5. Backup

5.1 Backup Procedure

The PrefApp platform follows a general procedure for backup. A complete database extract is performed daily; this extract is encrypted and maintained per the database retention schedule. In addition to this extract, the entire PrefApp application server is also captured weekly via a system snapshot, which is retained following the Virtual Machine (VM) retention schedule.

5.2 Schedule & Retention

PrefApp servers are backed up through UBC’s EduCloud and follow UBC IT’s business practices for backup, retention, and security.

The PrefApp database is backed-up once per day to a GnuPG 4096-bit key encrypted database to a disk in the Production environment. Encrypted database backups on the local disk are then backed up and replicated through EduCloud backup.

5.3 Restoration Requests

Restoration from backup is only available at the project-level and in exceptional circumstances. Backup processes are designed to protect against significant data loss/corruption events. Restoration of individual records or groups of records is not possible. The existence of backups should not be considered as a mitigation for record-level errors or data entry/deletion incidents.

The Project Owner responsible for a project may request restoration of the project from backup by submitting a request to support@PrefApp.org. Restoration requests will be considered on an individual basis, handled on a best-effort basis, and are subject to the availability of data under the schedule defined in section 5.2.

6. Data Retention and Destruction

6.1 Backup Procedure

See PrefApp’s Data Retention and Destruction policies document for details.

1. Introduction

PrefApp is designed to facilitate data capture, primarily for individual preference information. It is a useful self-service web application for the collection of simple tabular data such as demographic details and preference surveys.

PrefApp is hosted servers that are physically located in Canada at the UBC University Data Centre. For more information about the platform see PrefApp Platform [link to website]. For detailed security information see PrefApp Security Statement [link to website].

2. Privacy Model

PrefApp operates under a shared responsibility model. PrefApp is responsible for the underlying platform and ensuring the operation of the software, the Project Owner is responsible for the data collected, its use, and disclosure. The PrefApp software itself is developed and supported by the PrefApp developers.

3. Data Collection

PrefApp does not collect any personal information as part of the operation of the PrefApp platform. PrefApp only collects the necessary business information required for the provision of the service (e.g., email address; user name).

4. Data Use and Disclosure

PrefApp does not use or disclose any of the information collected by projects within the PrefApp platform except where required by law or as directed by the Project Owner. The Project Owner is responsible for the data collected, its use, and disclosure. See also Disclosing Personal Information to Law Enforcement Agencies and Government Bodies

5. References

PrefApp Platform

PrefApp Security Statement

Disclosing Personal Information to Law Enforcement Agencies and Government Bodies:

https://universitycounsel.ubc.ca/files/2015/05/Fact-Sheet-Disclosure-to-Outside-Agencies.pdf

1. Introduction

This document summarizes the security architecture and controls of the PrefApp instances managed by the Prefapp team. For more information please contact support@prefapp.org.

2. PrefApp Software

The PrefApp software provided by the PrefApp developers is installed “AS-IS”. UBC ARC does not conduct any additional review of the software code provided. For additional detail concerning the PrefApp application in general please refer to: www.prefapp.org.

3. Platform Architecture

All servers for the PrefApp platform are located in British Columbia, Canada within the UBC University Data Centre: A modern secure data center with pass-card restricted and logged entry, generator-backed UPS protected power, and video surveillance.

4. Access Control

PrefApp platform users have a dedicated username & password that they use to access the platform. Passwords are bcrypt-encrypted and stored in a secure database. Privileged accounts used to administrate the platform are limited to the Prefapp development team, and must use encrypted SSH connections from the internal network to access platform servers.

5. Maintenance and Patching

To facilitate required upgrades and patches the Prefapp platform has a pre-set maintenance window the fourth (4th) Saturday of every month starting at 0800h Pacific Time.

6. Vulnerability Scanning

The Prefapp Platform is periodically scanned using a variety of automated vulnerability scanning tools. Reports are reviewed and inform the maintenance and patching priorities for the platform.

7. Backup

Instances of the Prefapp platform follow the same general procedure for backups. A complete database extract is performed nightly; this extract is encrypted and maintained for 7 days. In addition to this extract, the entire Prefapp application server is also captured weekly via a system

1. Introduction

1.1 Purpose

PrefApp must implement appropriate data retention and destruction standards to safeguard data and backups stored on systems managed by PrefApp. This standard defines how data stored on PrefApp Systems is either retained or destroyed. It defines what protocols are to be employed in each case and what timelines must be followed when considering which data should be retained or destroyed.

1.2 Scope

This standard applies to all PrefApp Systems. This standard does not alter the responsibilities set out in UBC Policy SC6 Scholarly Integrity and UBC Policy LR2: Research.

1.3 Exceptions

Exceptions to this Standard are for approved purposes only. Approval is contingent upon information provided by a formal request and an assessment by PrefApp. Any approved exceptions must be re-evaluated regularly or whenever a material change to the control environment occurs.

2. Data Retention

2.1 Data Retention

Data on PrefApp Systems is retained indefinitely, until the PrefApp platform is terminated or the Data Owner decides to delete the project. On request from the Data Owner, logs can be scrubbed of all relevant data after project deletion.

3. Data Deletion

3.1 Data Deletion

Data stored in PrefApp Systems may be deleted through the normal UI mechanism provided to users. No additional measures are required to clear data from PrefApp Systems as physical media is subject to additional sanitization (see section 4).

4. Data Destruction

4.1 Data Destruction

All physical media is owned by UBC Advanced Research Computing (ARC). PrefApp data is subject to all Data Destruction governance as described by ARCS-5: Data Retention and Destruction (https://arc.ubc.ca/sites/arc.ubc.ca/files/documents/ARCS-05-ARC-DataRetentionAndDestruction.pdf).

5. Responsibility

5.1 Data Owner

The Data Owner is responsible for the complete lifecycle of their data. The Data Owner is responsible to ensure that storage of this data on PrefApp Systems, in compliance with this standard, is consistent and remains in compliance with all applicable institutional policies, regulations, laws, ethics requirements, and agreements. The Data Owner is responsible for ensuring that no personally identifiable information is collected during the period of their project on PrefApp Systems.

5.2 PrefApp Systems Team

The PrefApp Systems team is responsible for ensuring that PrefApp Systems are managed in compliance with this standard.

5.3 ARC Systems Team

The ARC Systems Team is responsible for ensuring ARC Systems are managed in compliance with this standard.

5.4 UBC IT

UBC IT is responsible for the security of some backup storage systems where data from ARC Systems may be retained in accordance with all UBC information security standards including UBC Information Security Standard #08 Destruction of UBC Electronic Information.

1. Introduction

1.1 Purpose

This standard defines the reporting, monitoring and logging requirements for Prefapp, including both system and security logs as well as audit logs.

1.2 Scope

This Standard applies to all servers that collectively house the Prefapp platform managed by the Prefapp team and hosted on UBC Advanced Research Computing (ARC). This includes the associated Prefapp application and database instances.

2. Standard

Effective logging and monitoring procedures (i.e. continual monitoring and/or periodic reviews) provide ongoing assurance that the Prefapp platform, and the information it holds, is secure and that confidentiality and integrity are ensured. In the event of a security breach, Audit Logs are relied upon to determine whether or not information has been accessed or modified without authority. Logs are generally intended to be used for maintenance and troubleshooting, as well as detecting and investigating information security events. Access for other purposes must be approved using one of the following methods:

- Internally, within UBC, in accordance with UBC Information Security Standard #10 Accessing Electronic Accounts and Records,

- Externally to law enforcement via Campus Security; or

- Externally to other entities via authorization from the Office of the University Counsel.

All transactions must be logged at the server layer, application layer, and database layer. Regular log review is required, and where appropriate, alerts of Privileged Account significant activities must be transmitted to the relevant users.

2.1 Security Logging

Logs must record system faults to facilitate attack and unauthorized activity detection. Logs must be monitored to determine the use of system resources and to detect information security events (e.g. failed logons, simultaneous logins from different geographic locations, escalation of privilege, attacks against the system, etc).

2.2 Audit Logs

Prefapp has a built in audit trail which records all activities and data viewed or modified by a given user.

2.3 Server Logs

The platform server logs are stored on the application server and allow system administrators to better monitor the health and stability of the system.

2.4 Database Logs

All changes to application data are stored in the Audit Logs. PostgreSQL maintains its own log of all queries that is accessible to all system administrators.

2.5 Project Monitoring

2.5.1 Stale Projects

Projects that have been inactive for six (6) months will be flagged by setting the project to inactive mode and the Project Owner contacted by the Prefapp team to ascertain the status of the project. Projects will be moved to archived mode if no response is received within 30 days. Stale active projects will be monitored for on a monthly basis.

2.6 User Monitoring

The following User activities must be logged and monitored:

• Login, logout, access to resource(s),

• Actions performed by User and the time they were performed,

• Any access to or modification of records.

2.7 Securing logs

All logs must be protected from unauthorized access and modification, by storing them on the application server outside the Demilitarized Zone (DMZ). No one should be able to modify or delete log information.

2.8 Log retention

All logs must be retained for a minimum of 90 days, and retrievable in a timely manner.

3. Procedures

Log review must be completed according to the ARC log review procedures.

4. Responsibility

4.1 Prefapp Team

Is responsible for monitoring User activity logs and project logs and for taking appropriate corrective action, including notifying users.