dr. liang xiao university of southampton united kingdom

1

130th International Conference on Software Engineering

Leipzig, Germany, 10 - 18 May 2008

Dr. Liang Xiao

University of Southampton

United Kingdom

Developing a Security Protocol for a Distributed Decision

Support System in a Healthcare Environment

2



Background and motivation• Security in Software Engineering

– Non-functional requirements– Software quality (IEEE standard, etc.)– Relationship with functional requirements

• Healthcare and security– Data sharing– Patient privacy and confidentiality

• Laws and regulations– UK Data Protection Act 1998

• Existing Software Engineering approaches to security in healthcare– Heuristic agents intercept calls to resources– Security agents authenticate user access to electronic healthcare

records– Multi-Agent System encrypts private patient records and authorises

access before information sharing– Security not considered as an integral part of software design

3



The HealthAgents project

MicroArt Universitat de València Universitat Autònoma de Barcelona

ITACA Pharma Quality Europe Katholieke Universiteit Leuven

University of Birmingham University of Edinburgh University of Southampton

• Partners: seven educational and research institutions and 2 SMEs from Belgium, Italy, Spain, and the United Kingdom• Hospitals distributed in Birmingham, Barcelona, and Valencia

4



The HealthAgents: to create a multi-agent distributed Decision Support System, and help in the early diagnosis and prognosis of brain tumours

• Medical imaging techniques such as magnetic resonance spectroscopy (MRS) and laboratory techniques such as gene expression arrays promise to deliver these advances but suffer from a complexity of interpretation which has hindered their incorporation into routine clinical practice

• The classification of brain tumours, especially rare types, will enhance with information sought from many hospitals

• The application of Pattern Recognition techniques can improve the discrimination between tumour classes and facilitate decision making

• This is supported by a distributed system for data collection and management prior to the required classifier training process

5



Retrieve a local case for classification

Local access control policies apply

Create a new classifier

Inter-centre resource access is via Yellow Pages Agent

External access control policies apply to access of cases & classifiers from other clinical centres

Key components and architecture

6



The HealthAgents network

7



The use of a link-anonymised data scheme in HealthAgents

• Data has personal information (e.g. name, address, date of birth) removed

• A unique patient identifier is added• Allow data from the same patient to be added at

a later date• Allow a specific patient’s data to be located and

removed at any time when requested• Full patient records are kept for clinical purposes

within the treating hospital

8



Data transmission among distributed sites

9



Resource access: case vs classifier

• Cases are processed and tumour classifiers produced

• Cases normally only known to the classifier producer software (agents)

• The produced classifier software (agents) as opposed to specific cases are used for decision making in the tumour diagnosis processes

• No private patient data that is involved in the production of classifiers will be revealed to the clinical users

10



• Anonymised patient cases– Validated: diagnosis confirmed– Public: accessible to all HealthAgents nodes – Private: accessible only to the local node or for

producing classifiers

• Classifiers– Global: trained upon public cases– Local: trained uniquely upon local public and private

cases – Specific: trained upon all public cases and local

private cases (being given a special weight)

Types of case and classifier & their access principle

11



The UK Data Protection Act 1998• Personal data shall be obtained for lawful purposes and

processed in accordance with the rights of data subjects– Patient consents will be obtained before cases enter into HealthAgents database.

Furthermore, patients retain the rights of withdrawing their cases and if requested they will be removed from the databases immediately (via the unique patient identifier)

• Personal data shall be processed fairly– Patient case records are only processed for

• the diagnosis of that particular patient • the training of classifiers

• Personal data processed for any purpose shall not be kept for longer than is necessary for that purpose or those purposes

– All cases used for the purpose of training classifiers will be discarded when classifiers are produced and will not be kept for longer than it is necessary

• Appropriate technical and organisational measures shall be taken against unauthorised processing of personal data

– The publicity of a case and its direct access is strictly controlled by the case home node

– The routine use of cases, for facilitating decision making, is largely replaced by classifier training software

– Each clinical centre enforces an appropriate data access control mechanism

12



The potential dangers on confidentiality, integrity, availability • Theft and disclosure of patient privacy information by a

hacker due to insecure transportation network – a confidentiality issue.

• Malicious users may create low quality classifiers – an integrity issue.

• Accidentally, inexperienced users may assign unreasonable reputation values to classifiers, such incorrect alteration of classifier reputation values will mislead diagnosis results – an integrity issue.

• Abuse of system services (Yellow Pages, Classifier Training, etc.) and so make them unavailable or even replace them with malicious alternatives and direct to wrong diagnosis – availability and integrity issues.

• Users from one hospital access data or execute classifiers from another hospital without the proper permission – confidentiality and integrity issues.

13



0. Update a private patient record: often only available to the patient’s principle physician.

1. Read a private patient record: also available to the producers of specific classifiers.

2. Read a public anonymised patient record: available to classifier producers and under agreements to other hospitals in the HealthAgents network.

3. Create a classifier: available to specific experienced clinicians with sufficient power who may allow the classifier producers to access required anonymised data and later set the publicity of the classifier.

4. Update a classifier reputation: available to experienced clinicians who have executed that classifier upon a case and the accurate diagnosis result is known to them at that moment.

5. Execute a local classifier: often available to local hospitals.6. Execute a global classifier: available to all hospitals in the HealthAgents

network.7. Invoke a system service (Yellow Pages, etc.): may open even to hospitals

outside of the HealthAgents network, this allows them to gain better knowledge of the available resources inside the network so they may want to join in later.

Data sensibility levels and access control policies

14



Three security levels Principles Protection Techniques

Secure communication

All messages passing in the network should be securely signed and encrypted.

Messages in transmission are kept secrete and unaltered, ensuring confidentiality and integrity.

SSL,

Public Key Infrastructure,

JADE-S

Authentication Users will be allowed to enter the system only if their identities are recognised.

The one who claims to be of an identity has indeed that identity. No one can pretend to be someone else.

JAAS

Authorisation When resources are being requested, security policy rules, as set globally in the network, locally in hospitals, or individually by clinicians will be applied against the particular identity.

Users can access or perform operations upon critical system resources only if they have been authorised to do so, their access permissions being bound with their identities recognised during authentication.

Access control model and policy rules

15



The security architecture (a cross-hospital resource access scenario)

16



Secure Message Transportation 1. An instance of HealthAgent register itself and upon recognition its principal (public key) is added to the trust list

2. the HealthAgent communicates with other trusted agents by using handleMessage, which in turn uses JadeMessagingService

3. JadeSecurityService uses secureSendingMessage to check if the message receiver is trusted and if so, it will sign and encrypt the message and send it on

4. JadeSecurityService uses secureReceivingMessage to check if the the message sender is trusted and if so, it will decrypt the message and reply in signed and encrypted messages

In both above situations, JadeSecurityServiceAgent uses validatePrincipal to check if the communicating agent’s principal is among the trustedPrincipals, being maintained by YellowPagesAgent at runtime

17



Authentication• Java Authentication and Authorisation Service (JAAS) provides a framework

for user-based authentication• A user’s identity is confirmed in authentication and represented by a subject • A principal is granted to the user after identity is verified during the

authentication• A LoginModule performs authentication (verifying a subject’s username

and password)• The implementation of a SimpleLoginModule is provided in JAAS• Alternative LoginModules can be loaded as configured in a Configuration

file, being consulted by a LoginContext• LoginContext invokes a login method of the loaded LoginModule for

authentication of subjects and upon success will associate principals with them

• Principals of a subject can be later retrieved by invoking its getPrincipals method

• JAAS policies can be configured for subjects and grant them authorised permissions following authentication

• These can be later enforced by invoking doAs(subject,action) method, achieving the effect of having an action run as the subject

18



Authorisation • User identification• User role and group recognition• Security policy rule application• Rule scheme: {Subject (Id, Role, Organisation), Resource (Id,

Type), Access Operation (Op), Access Context (Co)}– A resource access request message can be identified to its origin and mapped to

the roles that subject plays– To ease management, policies are defined on the basis of roles but those on the

basis of individuals and organisations are also allowed – In HealthAgents, case records, classifiers, services (Yellow Pages, etc.) are the

resources to which access must be protected– Various access operations may be performed upon resources and they have

different sensibility levels. One clinician may be able to execute a classifier but not update its reputation value

– A context offers flexibility in access control: 1) allowing in particular situations certain specially delegated access in the name of a particular role; 2) constraining the valid time period associated with the access; 3) providing justification of the special access

19



A role interaction model for a comprehensive HealthAgents case

• A new hospital joins the HealthAgents network with a new MAS setup in that site, new clinician users wish to perform classification upon cases from there, and they do so by creating new classifiers for the purpose

20



The new clinician is authenticated by JAAS via the local GUI Agent and his/her principal is bound with the interface for the entire interactive session The GUI Agent registers this new node via the YellowPagesAgent which recognises its identityThe YellowPagesAgent adds this new node to the trusted node list The GUI Agent at that node can start to communicate in the HealthAgents

network and now it wants to perform a classification upon a local case The GUI Agent searches the YellowPagesAgent for available classifiers by sending questions to solve as the first message it initialises for a new conversation

The YellowPagesAgent has its principal registered in the trusted list so this conversation is permitted and all ongoing messages signed and encrypted The YellowPagesAgent checks this GUI Agent against the permission of using its query service and will perform the query to its registered classifiers but unfortunately no such classifier is available

The GUI Agent requires the building of a new specific classifier using distributed data sets The TrainingPetitionerAgent applies a local policy repository and allows the request operation of building a new classifier Relevant public cases as well as local private cases from the request site will be sent to the building site for the production of the new classifier and data access policy rules will be applied

A new classifier is produced and registered to the YellowPagesAgent, a copy becoming available to the original request site The clinician now wants to execute the new classifier upon the case when being informed of the availability of the classifier The local policy rules on the use of the classifier and the particular case will be applied against this specific clinician and he/she will be allowed to do the operation

Decision making support is received from the results of the classification and a diagnosis will be made later on When an actual diagnosis result is known, the clinician wants to update the classifier reputation and the case he/she just diagnosed and the local policy rules on both operations will be applied

21



Introducing Lightweight Coordination Calculus (LCC)

• Developed in the OpenKnowledge project • Used for the specification of interaction behaviour• Regulate the message exchange protocols among participant peers,

each of which plays a particular role that dictates its particular message passing pattern in protocols

• a(role, id) :: def denotes that an agent of identity id plays a role of role as defined in def

• def describes the message passing behaviour constructed using the following forms: def1 then def2 (def1 satisfied before def2), def1 or def2 (either def1 or def2 satisfied), or def1 par def2 (both def1 and def2 satisfied)

• In the def, m a denotes that a message m is sent to agent a while m a denotes that a message m is received from agent a

• Also in the def, ← constraint denotes that a constraint must be satisfied before the clause prior to it

22



Resource access interaction formalism

a(resource_request, RRID) :: request(Resource, Operation, Context) a(resource_manager, RMID) a(resource_manager, RMID) :: request(Resource, Operation, Context) a(resource_request, RRID) ← grantPermission(RRID, Resource, Operation, Context, Policies) then ( response(Grant_yes) a(resource_request, RRID) or response(Resource_result) a(resource_request, RRID) ← getOperationResult(Resource, Operation, Access_result) )

agents RRID and RMID play the roles of resource_request and resource_manager DefRRID has a single and DefRMID has a composite message passing behaviour RRID plays the role of resource_request and will send a request message to RMID which plays the role of resource_managerRMID plays the role of resource_manager and will receive a request message from RRID. It will solve a constraint before a subsequent behaviour carried out

the constraint is expressed as the resource manager agent applying appropriate security policies upon the request and as a result a permission is grantedConstraint being satisfied (or not), RMID responds by sending back a message either saying the request has been granted (or rejected) or by providing the actual resources (or the results of their usage) being requested

Additional computation (for offering the required resource sets) may follow prior to a response message is sent out back to RRID

23



The LCC specification for HealthAgents (clinician roles )

/* R10: classify a local case using the new classifier just produced */a(clinician_classify, CID) :: classifierAvailable(C) a(yellowpages_register, YPID) then requestCaseRecordByID(I) a(database, DBID) then caseRecord (R) a(database, DBID) then requestClassification(R, C) a(classifier_petitioner, CPID) then classificationResults(S) a(classifier_petitioner, CPID) then a(clinician_followingdiagnosis, CID)/* R14: update case record and classifier reputation following diagnosis */a(clinician_followingdiagnosis, CID) :: ( updateCaseRecordByID(I) a(database_update, DBID) then caseRecordUpdated(Y) a (database_update, DBID) ) par ( updateClassifier(I) a(classifier_petitioner, CPID) then classifierUpdated(Y) a (classifier_petitioner, CPID) )

24



/* R11: send a case record for classification */a(database_download, DBID) :: requestCaseRecordByID(I) a(clinician_classify, CID) ← grantPermission(CID, I, Read, Normal_classify_from_local_site, Local_database_read_policy_set) then caseRecord(R) a(clinician_classify, CID) ← getCaseRecordByID(I, R) then a(database_update, DBID)/* R15: update a case record after classification */a(database_update, DBID) :: updateCaseRecordByID(I) a(clinician_followingdiagnosis, CID) ← grantPermission(CID, I, Update, Normal_update_from_local_site, Local_database_update_policy_set) then caseRecordUpdated (Y) a(clinician_followingdiagnosis, CID)

The LCC specification for HealthAgents (manager roles )

25



Security policy rule checking

• a(role, id) represents a clinician with a unique identity who wants to play a certain function role

• This identify can be extracted from the message being sent from the sender• Associated with that identity, the access rights to resources involved in the

function role playing behaviour will be checked by resource manager agents before permissions are granted and functions carried out

• This means security constraints embedded in the agent interaction protocols must be evaluated satisfactorily with a Boolean value of true returned

• A grantPermission method will be provided in the system that will be invoked for security policy application.

grantPermission(ID RRID, Resource r, Operation o, Context c, PolicySet p) { logger.setAccessAudit(RRID, r, o, c, getTimestamp()); return applyPolicies(RRID, getRoleByID(RRID), r, o, c, p); …… }

• This offers audit points where each access can be later traced back, hence the audit-ability of sensitive resource access being enabled

• The running and execution of LCC specification for agent interaction is supported by the OpenKnowledge kernel

26



Conclusions

• A sustainable security solution has been presented, being developed in accordance with Software Engineering principles and ethical regulations

• Provide in a distributed Decision Support System (d-DSS) for healthcare: secure communication, authentication, and authorisation

• The functional (interaction model specification and runtime support) and non-functional requirements (security constraint specification and policy rule application) are separated but integrated into a unified framework from the start of software development

• Maintenance of either functionalities or security constraints in systems is eased, each clinical centre can separately manage their local policy rules

• Implementation work is going on in the HealthAgents (www.healthagents.net) and OpenKnowledge (www.openk.org) projects

27



Questions?

dr. liang xiao university of southampton united kingdom

Documents