a formal security model for collaboration in multi-agency networks salem aljareh newcastle...

A Formal Security Model for Collaboration in Multi-agency Networks

Salem Aljareh

Newcastle University, UK

Nick Rossiter & Michael Heather

Northumbria University, UK

[email protected]

13 April 2004 2nd WSIS, Porto

Outline

Motivation. Security Requirements. UK Security Regulations. Task-based Perspective The CTCP/CTRP model. Categorical Representation. Discussion. Current work. References.


Motivation

Polices Model Mechanisms

Vulnerabilities

Threats


Security Requirements

The origin of security requirements. Rhetoric. Concept.

Regulations. Security Policy.


UK Security Regulations

Personal Data in General: Data Protection Act.

Patient Record: Caldicott Principles and Recommendations


The CTCP/CTRP model

Collaboration Task Creation Protocol CTCP

Collaboration Task Runtime Protocol CTRP

Collaboration task

Requirements

PolicyMaterial


General Principles of our Model

Relationship. Ownership. Authorization. Responsibilities


Task-based Perspective as: There is no collaboration without a task. Can address the need-to-know problem. The collaboration task forms the common

object between the collaborators. Shared information ownership can be granted

to the collaboration task. Tasks are scalable, flexible and dynamic. Explicit responsibility is recognized in the

task-based approach.


Collaboration Task Creation Protocol

Introduction

Negotiation

Decision

Agreement

Create Task

Rethinking

Discard

Dismiss


Collaboration Task Runtime Protocol

Preparation

Task Process

Assessment

AbortUpdate

Init Process

End

Log

CTCP


Exceptions -- Three Main Types 1. The task can still continue to its normal end.

Exceptions of this type are handled within CTRP protocol by task update component.

2. The task must be terminated and another task is required to complete the function. The task in such cases is aborted in CTRP The task history is used by the CTCP protocol to create

another task to redo the function. 3. The task must be terminated and there is no need for

any further actions. Handled within the CTRP protocol through ABORT


Coverage of Data Protection Act. Principle 1: Personal data shall be processed fairly and lawfully. Principle 2: Personal data shall be obtained only for one or more

specified and lawful purposes. Principle 3: Personal data shall be adequate. Principle 4: Personal data shall be accurate and, where necessary,

kept up to date. Principle 5: Personal data processed for any purpose or purposes

shall not be kept for longer than is necessary for that purpose or those purposes.

Principle 6: Personal data shall be processed in accordance with the rights of data subjects under this Act.

Principle 7: Appropriate measures shall be taken against unauthorised processing of personal data.

Principle 8: Personal data shall not be transferred to a country or territory outside the European Economic Area.


Correspondence of DPA Principles and CTCP/CTRP Components Principle

CTCP CTRP

Int Neg Dec Agr Cre Pre Pro Ass Log Upd Dis End

1

2

3

4

5

6


Coverage of Caldicott Principles Principle 1: Justify the purpose(s) Principle 2: Don't use person-identifiable information unless it is

absolutely necessary Principle 3: Use the minimum necessary person-identifiable

information Principle 4: Access to person-identifiable information should be

on a strict need-to-know basis Principle 5: Everyone with access to person-identifiable

information should be aware of their responsibilities. Principle 6: Understand and comply with the law.


Correspondence of Caldicott Principles and CTCP/CTRP Components Principle

CTCP CTRP

Int Neg Dec Agr Cre Pre Pro Ass Log Upd Dis End

1

2

3

4

5

6

7

8


Categorical Model of Security System

C

c c x a

c

C XB A C/B

c x a a

A

Fig. 3. Categorical Pullback of System (A) over Environment (C) in the context of Purpose/View (C/B)


Correspondence -- categorical: CTCP/CTRP model corresponds to the protocol CTCP whereby

a limit C XB A is selected for a particular purpose C/B through negotiation.

Existential functor is a type constraint: there must exist for all policy rules in C XB A an entry in the system C/B.

Universal quantifier functor corresponds to the protocol CTRP: all the rules held in the negotiated policy are applied.


Use of Petri Net Notation

Increasingly used in security area Suitable for situations with:

concurrency, asynchronicity, distribution, parallelism non-determinism.

Model states and transitions


Types of Petri Nets

Simple ones may not be adequate More complex examples:

Timed Petri-Nets Stochastic Petri-Nets Coloured Petri Nets


Discussion

Sources of the security requirements sources.

Coverage of general security regulation and medical security regulation.

Software engineering principles are met (Maximal cohesion, low coupling and efficient execution).

Balance between Category Theory and Petri Nets


Case Studies

Case study multi-agency security requirements in the Electronic Health Record.

Testing our model against the EHR security requirements.


References Aljareh, S., J. Dobson and Rossiter N. Satisfaction of

Health Record Security Principles through Collaborative Protocols, 8th International Congress in Nursing Informatics. Brazil 20-25 June 2003.

Aljareh, S., & Rossiter N., 2001, Toward security in multi-agency clinical information services, Proceedings Workshop on Dependability in Healthcare Informatics,

Edinburgh, 22nd-23rd March 2001, 33-41. Aljareh S., Rossiter N. A Task-based Security Model to

facilitate Collaboration in Trusted Multi-agency Networks. In proceedings of ACM-SAC2002, Symposium on Applied Computing, 10–14 March 2002, Madrid pp 744-749.

a formal security model for collaboration in multi-agency networks salem aljareh newcastle...

Documents