Security and Privacy

From TAPASWiki

Contents 1 Security Requirements 1.1 Confidentiality Requirements 1.1.1 TAPAS Confidentiality Stakeholders 1.1.2 Requirements 1.2 Authenticity Requirements 1.3 Integrity Requirements 1.4 Availability Requirements 2 Security Design 2.1 Confidentiality 2.2 Integrity 2.3 Authenticity

Security Requirements

Confidentiality Requirements

Confidentiality requirements capture the concerns of users and other interested groups about usage of data in the system. These concerns are elicited based on the various use cases, the data captured or processed as well as other stakeholders involved in the specific process(es).

Confidentiality Requirment terminology

1. Confidentiality stakeholder: A stakeholder with confidentiality requirements. The confidentiality stakeholder has an interest in ensuring that some particular data is not accessed or accessed by other stakeholders under certain conditions. Stakeholder roles identify groups of individuals who have similar confidentiality requirements. Therefore, a confidentiality stakeholder is an instance of a confidentiality stakeholer role (a type).
2. Counter Stakeholder: A stakeholder who is the target of a requirement. This is the stakeholder who the requirement
3. Episode :
4. A Requirement : A confidentiality concern of a stakeholder role. Requirements are specified with attributes, which indicate such information as the stakeholder role whose concern is addressed, the data object of concern, the stakeholder who should be granted/denied access etc.

Attributes of Confidentiality Requirments

1. Owner: the stakeholder whose concern is addressed by the requirement
2. Type : a requirement can be a consent (concession) or a goal (constraint).
3. Counter-Stakeholder :
4. Information : data object that is subject to the requirement.
5. Rationale: reason for the requirement. This helps to understand the objective of the stakeholder for the requirement.
6. Context: relates the requirement to a cluster of system functions.

TAPAS Confidentiality Stakeholders

The following confidentiality roles are identified for the TAPAS system:

• Patients
• Clinician - physicians, MOAs, nurses

Will include the taxonomy image

Requirements

Adeniyi, please use this page to model the Cree case study.

Authenticity Requirements

Pincipals interacting within the TAPAS system must be authenticated. Machine components must be authenticated using strong cryptographic means. Two-factor authentication should be used for human principals.

Integrity Requirements

The integrity of information exchanged in the system must be enforced.

Availability Requirements

The CASA service must be highly available and protected from Denial of Service attacks.

Security Design

The physical deplaoyment architecture consists of four component (categories) as shown in the following figure.

The CASA server hosts a database with the electronic medical information maintained by TAPAS. The Mozo mobile conduit allows mobile clients to synchronize with the CASA database. Both of these servers are operating in a trusted intranet and in a physical location that restricts access to trusted personnel. A tightly controlled firewall with "default deny" policy controlls the gateway between the trusted intranet and the Internet.

A number of mobile PDA clients and stationary ("always on") desktop clients can connect to CASA (respectively Mozo) through an untrusted network connection.

Confidentiality

Servers CASA Server and Mozo Conduit operate on a trusted Intranet in a phycially restricted location. Data held and exchanged by these machines is stored in unencrypted format to enable fast database access.

1. Both server machines will physically be locked to their location (server room - not an office) and there will be locks preventing against tempering with these machines.
2. The local Intranet will be locked down to allow only known MAC addresses to enter the network.
3. A minimum of known (and trusted) individuals will have a key to the server room and they will be trained to keep it locked at all times.
4. Server machines will run only those software components needed for TAPAS and their operating systems will be updated with security-related patches as soon as they become available.
5. Remote maintenance of servers can be done only by accessing a virtual private network (the same MAC address filtering rule applies).

Tapear Desktop Clients Tapear clients are "always-on" clients and do not persist confidential application data locally (apart from exported/printed documents). However, Tapear client machines host their users' X.509 security certificate including private keys. These certificates will be protected cryptographically based on keys generated from user passwords.

1. Users will be trained in keeping exported documents (printed) confidential.
2. A time-out mechanism will blank the screen after the system has been idle for x minutes. (x to be determined but fixed.)
3. Users will be trained not to share they passwords with anybody.

Tapeta Mobile Clients Tapeta clients are not "always connected" but they synchronize data regularly with the CASA server (via Mozo). Therefore, they have to persist application data locally. Most of this data is persistet in encrypted format (using a Blowfish cipher). The data that is kept unencryped on the client database is listed below. Everything else is encrypted.

1. Patient first and last names
2. The internal TAPAS patient ID
3. The patient's gender
4. The time of the last modification of each patient and alert record
5. The IDs of each alert associated with each patient (purely internal number)
6. The ID of the group associated as the owner of this alert
7. The start and end date of each alert

The Tapeta mobile client also contains two additional secrets: (1) a user's X.509 certificate including the private key (2) a private "client key" used for encrypting the persisted data. Both are cryptographically protected using user passwords as keys.

Additional Tapeta security measures:

1. Users will be trained not to share their password with anybody
2. The Tapeta screen will blank after being idle for x minutes (x to be determined but fixed).

Administrative Client Administrative clients are used for maintenance of the server infrastructure and connect using a VPN. They do not persist local application data. They contain a local private key that is used for the VPN authentication. This key must be cryptographically protected using a user password to generate a key. The VPN connection must timeout after x minutes of idle time (x to be determined but fix.)

Network confidentiality

1. Tapear Desktop Client <-> CASA: The confidentiality will be enforced using (RMI over) SSL.
2. Tapeta Mobile Client <-> Mozo: The confidentiality will be enforced by synchronizing mostly encrypted data. Some fields such as patient name, gender, internal TAPAS ide remain clear text. See Tapeta confidentiality section for details.
3. Administrative Client <-> Servers: The confidentiality will be enforced using a VPN connection.

Application-policy-specific confidentiality

1. Patient records are either marked as "shared" or "exclusive". Exclusive patient records are only exchanged with clients used by clinicians that belong to the same clinic the patient is a client of.

Integrity

Code integrity

1. Tapear Desktop Client: The Tapear rich client will be deployed based on Java Web Start technology. All code assemblies (jar files) will be cryptographically signed with the TAPAS certificate.
2. Tapeta Mobile Client: The Tapeta mobile client code will be encrypted with the joint secret of the initiated PDA client and the CASA server (the "Client Key"). A code validator and bootstrap loader that has been installed at initiation time will decrypt the code and validate its integrity.

Networking integrity

1. Tapear Desktop Client <-> CASA: The network integrity between Tapear and CASA is ensured due to the fact that all communication is performed using SSL.
2. Tapeta Mobile Client <-> Mozo: The network integrity between Tapeta and Mozo will not be 100% enforced, since we are still looking for a way to implement this using the standard network hotsync protocol. Still, the damage that can be done by an adversary is limited to changing the unencrypted data of patient records (names, gender, id numbers, group IDs). We will try to fix this vulnerability in the future.

Authenticity

1. Tapear/User <-> CASA: Two factor authentication is used to authenticate a tapear user to the server. Each user has to enter a strong password and also needs to install his/her digital certificate (x.509) on the client. A timeout is used after x minutes of idle time (and users have to re-authenticate). The CASA server is authenticated to the Tapear client by means of its digital certificate, which must be trusted by a major trust authority. Certificate revocation schemes have to be in place and passwords are automatically checked against dictionary attacks.
2. Tapeta/User <->Mozo: Authenticity of the mobile client is checked by registering and checking the hardware serial number. Authenticity (and identity) of the mobile user is checked by synchronizing a nonce encrypted with the user's digital certificate. Moreover, users are trained to enable the palm os password which will ensure that only ligitimate users will be allowed to perform a hotsync operation. Authenticity of Mozo will be checked by synchronizing not only the updated data to Tapeta but also an encrypted nonce and time stamp. The shared secret encryption key is used to validate the authenticity.