Requirements > TAPAS Security

Release Information

Project:	TAPAS
Internal Release Number:	$Revision: 1.4 $ $State: Exp $
Related Documents:	Software Requirements Specification

Overview

This document specifies the security requirements for TAPAS|ems. Since this is a requirements specification, the emphasis is put on specifying what characteristics the system must have rather than how to build mechanisms. The latter is covered in the security design document. Security requirements are driven by the goals and consents of various stakeholders.  In our application domain those goals mainly relate to privacy issues and the consents mainly relate to the necessity of accessing particular information for an enabling the delivery of health care services.  The next section will analyze these stakeholder goals and consents in detail.

Stakeholders

Stakeholders include but are not limited to the actors appearing in the use case diagram.  This is because only direct users of the software system are shown in use case models.  However, from a security point of view additional stakeholders exist, such as patients, health authorities, and governments.  We distinguish between two main categories of stakeholders, namely direct stakeholders and indirect stakeholders.  Direct stakeholders of those stakeholders  who have some information  about them being exchanged with the system.  For these stakeholders we have to  spcify an Information Model that characterizes this information.  This is not necessary for indirect stake holders, since no information about them is exchanged with the system.  Nevertheless, indirect stakeholders such as governments have important security goals.

Patient

Patients are among the primary stakeholders of the TAPAS system.  While they do not use the system directly the overall goal of the TAPAS system is to serve patients better.

Information model

 The following table specifies the information about patients, which is managed by the system in some form or another.

Kind	Details
Structured medical summary documents (e-MS documents)	Such documents contain details about the patients medical history, current problems, medications, allergies etc. A detailed specification of the e-MS document information content was created by the VIHA e-MS group and can be found here.
Unstructured messages between physicians that contain data about patients	Similar to electronic mail. These messages may include patient information

Clinican

Information model

Kind	Details
Audit information about data access	Clinicians can create, edit, validate, and view patient summaries and demographics.   They can also edit on-call schedules. For the purpose of non repudiation, all these information access operations are audited along with the identity of the clinician who perform ed them.
User information	Information stored in the system to uniquely identify the user as well as assist in the delievery of care. For example a College ID number would be important as that will be needed both for prescriptions and for referrals.

Nurse and Medical Office Assistant (are clinicians)

They have the same information model as the clinician.

Physician (is a clinician)

Information model

Kind	Details
Meta-data in structured medical summary documents (e-MS documents)	e-MS  Documents contained meta-data  about the identities of physicians, their decisions, and their observations. A detailed specification of the e-MS document information content was created by the VIHA e-MS group and can be found here.
Unstructured messages between physicians	Similar to electronic mail
On-call schedules	On-call schedules are  Calendar information, which identifies which physician is on call at what times.
Local Content	Compressed web pages of content (such as local pharmacy phone numbers) that would be available to the physicains from their PDA.

 

Counter-stakeholder

We use the term "counter-stakeholder"  to model sources of potential security threats.  Counters stakeholders may be motivated by various intents.  for example, they may be curiosity driven, have malicious intent,  they may be self motivated hackers, they may be motivated by the expectation to make profits, or they may just use the system and an erroneous fashion.  The following figure shows a taxonomy of counter stakeholders.  We distinguish between inside and outside stakeholders.  Their particular potential goals are described  in the table following this figure.

 

Counter-stakeholder goals

The following table contains the various motivations of counter stakeholders, their primary information target (compared to stakeholder Information Model), the typical actions performed, and the rough estimate of the resources available to each counter stakeholder type.

Counter-stakeholder	motivation	information target	action	resource level (low-medium-high)
Outsider	malicious	Patient/clinician information	read (and disseminate), modify, delete	low
	for profit	Patient/clinician	read	medium
	personal curiosity	Patient/clinician	read	medium
Clincian	malicious (e.g., to hide an erroneous diagnosis)	Patient/clinician information	modify, delete	low
	for profit	Patient/clinician information	read	low
	personal curiosity	Patient/clinician information	read	low
	unintentional error	Patient/clinician information	read, modify, delete	low
Tech. Admin	malicious, for profit, personal curiosity, unintensional error	Patient/clinician information	read, modify, delete	high

Stakeholder requirements

There are two principal alternatives on how stakeholder requirements can be described with respect to information security.  The first alternative is to specify stakeholder goals, which constrain the use of information.  In other words, goals are negative statements, for example "of electronic medical summaries may not be disclosed to outside hackers".  If only goals are used to describe security requirements, then it is typically assumed that what ever has not been constrained is allowed.  However, this assumption is dangerous in practice, since requirements specifications are rarely complete and important security goals may have been ommitted.  An alternative way of specifying security requirements is to use positive statements, also called consents.  An example consent would be "patient's medical summary can be viewed by their family doctor ".  If only positive statements are used for describing the security requirements, then we typically make the assumption that everything else is forbidden.  However, again, this assumption may be too restrictive in practice, since specifications are  rarely complete.  Therefore, we're using a hybrid approach to specified Security requirements by capturing goals as well as consents.

Obviously, security  goals and consents may be in conflict.  Such conflicts have to be detected and resolved in this specification.  The resulting conflict-free specification implies that an implementing system  should allow information use according to the consents given  and restrict information use according to the goals defined.  We also make the conservative assumption that the system should impede any information use not explicitly defined in consents or goals.

Stakeholder	Kind (G/C)	(information) object	quantifier	Counter-stakeholder	Purpose/Episode	Consented/restricted Actions
Patient p	C	structured (e-MS) and unstructured medical information	some	physician c	c treats p	read, modify, delete
			some	clinician c	c supports physician x x treats p	read, modify, delete
	G	medical data containing patients identity	all	outside Tech Admin		read, modify, delete
Physician c	C	e-MS documents created by c for patient p	some	physician x	x treats p c treats p	read
	C	messages sent from c  to physician x	some	physician x		read
Provincial Government	G	Identities of patients and clinicians	all	outside		read