CEN/TR 15300:2006
(Main)Health informatics - Framework for formal modelling of healthcare security policies
Health informatics - Framework for formal modelling of healthcare security policies
This CEN report specifies the starting point for working on some formalising tools that could be used by the healthcare actors to express, compare and validate local and/or network security policies.
Defining and validating a correct security policy encompass different activities such as expressing correctly
(i.e. without any ambiguity), formulating correctly (i.e. without any misinterpretation) and proving the correctness (i.e. without known failures or major lack) of the [to be formally modelled] security policy.
This CEN report does NOT intend at all to specify a UNIQUE or UNIVERSAL formal model that need to be used by the European healthcare community: it only indicates, as a first working step, some ways that could be followed to help that healthcare community to correctly and fruitfully manipulate the security policy concept(s) and the formal modelling techniques.
This CEN report does NOT intend to indicate an EXHAUSTIVE spectrum of all the published formal security policy models: it only gives a readable and understandable flavour of the most well-known formal models and also of the [maybe] most interesting ones from the healthcare activity and needs point of view. This CEN report is, in this very first version, divided in five parts:
o Part #1 - Introduction to formal modelling: this clause summarises and justifies the following needs:
i. need for policies, in general and for any context;
ii. need for security policies, in any data processing context;
iii. need for models (or modelling facilities) of security policies, in some generic system environments;
iv. need for formal models (or formal modelling facilities) of security policies, in some sensitive areas;
v. need for healthcare-oriented formal models of security policies, specialized to healthcare specificities.
o Part #2 - Historical security policies and models: this clause explains and introduces the main objectives and concepts of the security policy modelling activity that seems to be of
Medizinische Informatik - Rahmenkonzept für Modelle von Sicherheitspolicen im Gesundheitswesen
Informatique de santé - Cadre pour modélisation formelle des politiques de sécurité dans le domaine de la santé
Zdravstvena informatika - Okvir za formalno oblikovanje varnostne politike v zdravstvenem varstvu
General Information
Standards Content (Sample)
SLOVENSKI STANDARD
01-december-2006
Zdravstvena informatika - Okvir za formalno oblikovanje varnostne politike v
zdravstvenem varstvu
Health informatics - Framework for formal modelling of healthcare security policies
Medizinische Informatik - Rahmenkonzept für Modelle von Sicherheitspolicen im
Gesundheitswesen
Informatique de santé - Cadre pour modélisation formelle des politiques de sécurité dans
le domaine de la santé
Ta slovenski standard je istoveten z: CEN/TR 15300:2006
ICS:
35.240.80 Uporabniške rešitve IT v IT applications in health care
zdravstveni tehniki technology
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
TECHNICAL REPORT
CEN/TR 15300
RAPPORT TECHNIQUE
TECHNISCHER BERICHT
October 2006
ICS 35.240.80
English Version
Health informatics - Framework for formal modelling of
healthcare security policies
Informatique de santé - Cadre pour modélisation formelle Medizinische Informatik - Rahmenkonzept für Modelle von
des politiques de sécurité dans le domaine de la santé Sicherheitspolicen im Gesundheitswesen
This Technical Report was approved by CEN on 5 December 2005. It has been drawn up by the Technical Committee CEN/TC 251.
CEN members are the national standards bodies of Austria, Belgium, Cyprus, Czech Republic, Denmark, Estonia, Finland, France,
Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania,
Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
Management Centre: rue de Stassart, 36 B-1050 Brussels
© 2006 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TR 15300:2006: E
worldwide for CEN national Members.
Contents Page
Foreword.3
Introduction .4
1 Scope .6
2 Normative References.7
3 Terms and definitions .7
4 Symbols and abbreviations .10
5 Introduction to FM_HSP.11
6 Historical security policies .18
7 A generic formal modelling approach .22
8 Healthcare current needs & future trends.23
9 Healthcare applications of FM_HSP .24
Annex A Bell LaPadula’s and Biba’s models.26
Annex B Non-deduction / Non-inference models.27
Annex C HRU / Take-Grant / TAM-ATAM models .28
Annex D Chinese Wall model .29
Annex E Modal logic-based models .30
Annex F Deontic logic-based models.31
Bibliography .32
Foreword
This document (CEN/TR 15300:2006) has been prepared by Technical Committee CEN/TC 251 “Health
informatics”, the secretariat of which is held by NEN.
This non-normative CEN Technical report is intended to help the European health sector understand the need
for serious work on formal models dedicated to provide healthcare-relevant security policies. This very first
step towards European recommendations and/or standards about healthcare security policy formal modelling
is only a small part of the twin theoretical-pragmatic approaches that are to be developed in order to help the
healthcare sector end user implement his own relevant security policies.
Introduction
In order to help the healthcare sector specificity to be taken into account in any security policy specification
and implementation it is necessary to consider the three following aspects:
• it is unavoidable to be as close as possible to the user requirements (i.e. informal but also technical
requests);
• it is necessary, in consequence, to be adaptable enough in order to be able to catch all those various
possible requirements, in the sense that it is mandatory that the approach to security policy specification
need to have high flexibility property;
• it is obliged, at the opposite, to be rigorous enough when deriving such requirements into some refined
security policies, in the sense that it is also obliged that the methodology need to have high robustness
capacity.
User requirements
Most of the time the user requirements, concerning the security aspects, if not helped by any comprehensive
standard and/or some detailed security expertise, are not formal and/or detailed enough to be directly or even
automatically derived into security policies; especially in such a specific sector as the healthcare activity.
In any case, these are the security requests and requirements which are to be progressively refined in order to
be implemented. In addition, due to the wide range of actors, profiles, roles but also of IT technologies,
communicating systems, and security technologies, the user requirements might belong to a wide spectrum of
possible requests: this is the flexibility necessity. Nevertheless, any case of such user requirements,
concerning the security aspects, need to be proved as correctly taken into account: this is the robustness
obligation.
Flexibility
Considering:
• the four possible security properties possibly required (availability, integrity, confidentiality and auditability);
• times, the different IT systems possibly considered,
• times, the various healthcare establishment types and categories,
• times, the varying healthcare organisations and procedural processes,
• times, the variable healthcare actors and their related roles,
• times, the potential security technologies useable and used,
• times, the possible distribution and sharing policies of healthcare information,
it is clear that a very high number of authorised security policies might defined, refined and formalized.
In order to capture all these case, better than an exhaustive enumeration, an implicit definition by means of
some modelling approach should be easier and more faithful: the high diversity of security policies can only be
captured by a high flexibility of the security policy expression and formalising facilities: that is an overall
necessity.
Robustness
Considering:
• the always possible accidental and/or intentional (malicious or non-malicious) failures in the security policy
definition /specification/conception/implementation process;
• the always possible accidental and/or intentional (malicious or non-malicious) misuse of any healthcare
information system;
• the always possible accidental and/or intentional (malicious or non-malicious) misunderstanding of the
security needs of any healthcare organisation expressing informal security requirements;
• the always possible accidental and/or intentional a posteriori conflict between two healthcare parties
involved in a same health activity or health information exchange;
• the always possible security failures integrating in any security component being part of a global solution
it is clear that a high level of trustworthiness is required when the security policies are defined, refined and
formalized.
In order to capture such high a level of trustworthiness, better than repetitive controls, an proved
strategy/process should be more trusted and more relevant: the high level required for the security policy
expression and formalising can only be captured by a high robustness of the security policy expression
throughout mathematical facilities: that is an major obligation.
1 Scope
This CEN Technical report specifies the starting point for working on some formalising tools that could be
used by the healthcare actors to express, compare and validate local and/or network security policies.
Defining and validating a correct security policy encompass different activities such as expressing correctly
(i.e. without any ambiguity), formulating correctly (i.e. without any misinterpretation) and proving the
correctness (i.e. without known failures or major lack) of the [to be formally modelled] security policy.
This CEN Technical report does NOT intend at all to specify a UNIQUE or UNIVERSAL formal model that
need to be used by the European healthcare community: it only indicates, as a first working step, some ways
that could be followed to help that healthcare community to correctly and fruitfully manipulate the security
policy concept(s) and the formal modelling techniques.
This CEN Technical report does NOT intend to indicate an EXHAUSTIVE spectrum of all the published formal
security policy models: it only gives a readable and understandable flavour of the most well-known formal
models and also of the [maybe] most interesting ones from the healthcare activity and needs point of view.
This CEN Technical report is, in this very first version, divided in five parts:
Part #1 - Introduction to formal modelling: this clause summarises and justifies the following needs:
i. need for policies, in general and for any context;
ii. need for security policies, in any data processing context;
iii. need for models (or modelling facilities) of security policies, in some generic system environments;
iv. need for formal models (or formal modelling facilities) of security policies, in some sensitive areas;
v. need for healthcare-oriented formal models of security policies, specialized to healthcare specificities.
Part #2 - Historical security policies and models: this clause explains and introduces the main objectives and
concepts of the security policy modelling activity that seems to be of interest for future healthcare usage:
a. formal models of confidentiality policies;
b. formal models of integrity policies;
c. formal modelling attempts of general purpose policies.
Part #3 - A generic formal modelling approach: this clause informs on the possibilities of formal models,
related to the security policy activity and especially for the healthcare organisations:
a. which types of formal models exist?
b. why using formal modelling?
c. what for choosing modal logic?
c. how implementing deontic logic?
Part #4 - Healthcare current needs and future trends: this clause intends to make the link between all the
user requirements that are handled inside the activity of CEN/TC 251 and the past/current/future needs:
1. past results with the security categorisation work;
2. current work with the distribution- or the communication- security policy modelling;
3. future trends and corresponding expected results with the new activity on real formal modelling.
Part #5 - Healthcare applications of FM_HSP: this clause gives examples of applicability of the global formal
modelling approach to healthcare security policies:
1. anonymisation policies;
2. Trusted Third Party’s policies;
3. communication security policies;
4. cryptographic policies;
5. safety versus security policies.
This CEN Technical report is intended to built a long term prospect: this means that confidentiality and
integrity, but also availability and accountability, considerations need to be taken into account in order to
propose interesting and useful results to the healthcare actors concerned with the general security policy
aspects.
2 Normative References
Not applicable.
3 Terms and definitions
For the purposes of this CEN Technical report, the following terms and definitions apply.
NOTE Please note that for those definitions where no reference is given, the definitions proposed here have not been
endorsed to be generally valid in the work of CEN/TC 251.
3.1
access control
a means of ensuring that the resources of a data processing system can be accessed only by authorized
entities in authorized ways
[ISO 2382-8:1998]
3.2
accountability
the property that ensures that the actions of an entity may be traced uniquely to the entity
[ISO 7498-2:1989]
3.3
anonymity
property that ensures that the nominative identity is not revealed
3.4
auditability
the property that ensures that any action of any security subject on any security object may be examined in
order to establish the real operational responsibilities
[ENV 13608-1:2000]
3.5
authentication
process of reliably identifying security subjects by securely associating and its authenticator. See also data
origin authentication and peer entity authentication
[ISO 7498-2:1989]
3.6
authenticity
combination of element that ensure the origin of a document or of data: the data integrity and the sender’s
authentication contribute to the document authenticity
3.7
authorization
the granting of rights, which includes the granting of access based on access rights
[ISO 7498-2:1998]
3.8
authority
entity that has the responsibility and capacity for providing some added value to the network or system
3.9
availability
property of being accessible and useable upon demand by an authorised entity
[ISO 7498-2:1989]
3.10
certification
use of digital signature to make transferable statement about beliefs of identity, or statements about
delegation of authority
[ENV 13608-1:2000]
3.11
Certification Authority
an authority trusted by one or more users to create and assign certificates. Optionally the certification authority
may create the users' keys
[ISO 9594-8:2001]
3.12
confidentiality
the property that information is not made available or disclosed to unauthorised individuals, entities, or
processes
[ISO 7498-2:1989]
3.13
cryptography
the discipline which embodies principles, means, and methods for the transformation of data in order to hide
its information content, prevent its undetected modification and/or prevent its unauthorised use
[ISO 7498-2:1989]
3.14
decryption/deciphering
the reversal of a corresponding reversible encipherment
See decipherment
[ISO 7498-2:1989]
3.15
encryption/enciphering
the cryptographic transformation of data (see cryptography) to produce ciphertext
See encipherment
[ISO 7498-2:1989]
3.16
identification
process of identifying the security subjects attributes, such as name, address, or other subject attributes
[ENV 13608-1:2000]
3.17
identifier
piece of information used to claim an identity, before a potential corroboration by a corresponding
authenticator
3.18
identity
collection of data items, such as official name, postal address etc., that are required for naming non
ambiguously a given person
3.19
Integrity
property of being unmodified by any kind of unauthorised security subject
[ENV 13608-1:2000]
3.20
private key
key that is used with an asymmetric cryptographic algorithm and whose possession is restricted (usually to
only one entity)
[ISO/IEC 10181-1:1996]
3.21
public key
key that is used with an asymmetric cryptographic algorithm and that can be made publicly available
[ISO 10181-1:1996]
3.22
secret key
key which is kept secure and only disclosed to parties intended to have access to data protected by it
3.23
security
combination of security properties (such as availability, confidentiality and integrity, and also auditability)
[ENV 13608-1:2000]
3.24
Security Object
passive entity that contains or receives information
[ITSEC:1991]
3.25
Security Policy
set of laws, rules, and practices that regulate how an organisation manages, protects, and distributes sensitive
information
[TCSEC:1985]
3.26
security service
service, provided by a layer of communicating open systems, which ensures adequate security of the systems
or of data transfers
[ISO 7498-2:1989]
3.27
Security Subject
an active entity, generally in the form of a person, process or device that causes information to flow among
objects or changes the system state. Technically, a process/domain pair
[TCSEC:1985]
3.28
third party
party other than data owner, or data recipient, required to perform a security function as part of a
communication protocol
3.29
Trusted Third Party (TTP)
third party which is considered trusted for purposes of a security protocol
NOTE TTP, a special case of the generic notion of third party, is a party to which a justifiable trustworthiness can be
placed for the need of the security services it is intended to provide to the requesting entities.
4 Symbols and abbreviations
4.1 Abbreviations
3DES Triple ‘Data Encryption Standard’
CC Common criteria
CORBA Common Object Request Brokerage
DES Data Encryption Standard
DICOM Digital Imaging and Communication in Medicine
ECMA European Computers and Manufacturer Association
EDIFACT Electronic Data Interchange For Administration Commerce and Transport
HL7 Health Level 7
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
IETF Internet Engineering Task Force
ITSEC Information Technology Security Evaluation Criteria
MIME Multimedia Internet Message Extensions
PKCS#7 Public Key Cryptographic Standard#7
PBM Policy Bridging Model
PP Protection Profile
RFC Request For Comment
RSA Rivest-Shamir-Adleman
SEMRIC Secure Medical Record Information Communication
SCO Secure Channel Object
SCT Security Concepts & Terminology
SDO Secure Data Object
SPB Security Policy Bridging
S/MIME Secure ‘Multimedia Internet Message Extensions’
SMTP Standard Mail Transfer Protocol
SSL3 Secure Socket Layer (version 3)
TLS Transport Layer Security
UML Unify Modelling Language
4.2 Symbols
[] When a given term (e.g., ISO 7498-2) is indicated in between the square-brackets symbols (e.g.,
[ISO 7498-2]), this means that it is a bibliography reference.
{…} set of…
⊄ not included in…
⊂ included in…
∈ belongs to…
∉ belongs not to…
∧ logical and
∨ logical or
⇔ equivalence relationship
5 Introduction to FM_HSP
5.1 Policy: a global need
In any organisation, especially in health/healthcare/medical institutions, procedural and technical rules shall be
applied (either explicitly imposed or implicitly enforced), for the global interest of the company, in order to
preserve that organisation’s coherence and to provide some chance of perenniality: these are some ‘standard’
rules and procedures that apply to any subsystems of that organisation and define the internal (i.e. between
internal subsystems) and external (i.e. between internal subsystems and the outside world) relationships.
A special case of such policies, that need to globally exist, is of course the security policy concept(s).
5.2 Security policy: a multiform concept
Different interpretations (i.e. concrete/formal concepts) of the same notion (i.e. abstract/informal formulation)
of security policy (SP) are presented here. This simply shows that a pertinent understanding of the relevant
need(s) is fundamental for a correct formulation, and thus a precise formalisation, of the adequate solution(s).
From a global corporate point of view, the security policy concept is generally, for example, divided into:
i. corporate security policy: which defines a global strategy of actions for the corporate;
ii. procedural security policy: which details the itemized recommendations for the different activities;
iii. technical security policy: which specifies the technical rules and procedures for each component.
In that case, ‘security policy’ could be translated as ‘information flow strategy’.
From an IT system point of view, the security policy concept is sometimes, as in [ITSEC91], a nested
concept:
a. security objectives: which correspond to the main goals of the [ITSEC91] security target;
b. security enforcing functions: which more formally satisfy the more informal security objectives;
c. security mechanisms: which globally intend to accurately implement the security enforcing functions.
In that case, ‘security policy’ could be interpreted as ‘system security policy’.
From a more technical point of view, the security policy concept is very often, for example, divided into:
i. physical security policy: which states how/when/why people can physically access to various sites;
ii. logical security policy: which states how/when/why users can logically access to information systems.
In that case, ‘security policy’ could be seen ‘access control policy’.
From a data processing point of view, the security policy concept is also, for example, divided into:
i. sensitive information management policy;
ii. access control policy.
In that case, ‘security policy’ could be called ‘logical security policy’.
From a system security point of view, the security policy concept is also, for example, splitted into:
a. identification/authentication policy;
b. authorization policy;
c. access [verification/control] policy.
In that case, ‘security policy’ could be entitled ‘logical access control policy’.
From a modelling point of view, the security policy concept is also, for example, categorized in:
i. [external] access control policy [or model];
ii. [internal] flow control policy [or model].
In that case, ‘security policy’ could be defined as ‘flow control policy [or model]’.
From an access control point of view, the security policy concept is also, for example, categorized in:
i. DAC: discretionary access control [policy or policy model];
ii. MAC: mandatory access control [policy or policy model];
iii. RBAC: role-based access control [policy or policy model].
In that case, ‘security policy’ generally means ‘access control [policy or policy/model]’.
5.3 Security policy modelling: a flexibility necessity
Like any policy which is recognised as a global need and which existence is a necessity, and as a special
case of policy (see 5.1 above), building security policy is seen as an unavoidable necessity.
As it is recognised that the security policy concept is a multiform concept (see 5.2 above), using a security
policy also impose the necessity to provide some real flexibility.
The solution that is often chosen to address, in the general case, such a flexibility necessity is the modelling
approach, for various needs:
i. time flexibility: because a SP shall be evolutionary in time due to multiple contextual evolutions;
(e.g. a user profile can be changed/modified because the work he is responsible for has changed);
thus a SP model shall be able to accept future evolutions of the original SP specification;
ii. space flexibility: because a SP shall be adaptive in space due to multiple contextual considerations,
(e.g. a user privilege might be adapted between local access and remote/network access);
thus a SP model shall be able to consider several adaptations for the same SP requirement item;
iii. form flexibility: because a SP shall be expressive in its various forms, due to its possible usage,
(e.g. a SP’s correctness may be explained by convincing words at the uppermost requirement level, whereas
it shall be rigorously demonstrated by a provable process at the lower specification level;)
thus a SP model shall be able to propose different [levels of] expressions of the inherited SP philosophy.
The modelling approach, in the case of security policy, is a natural answer to flexibility, for various reasons:
i. exhaustivity: by means of extensional mathematical-like or set-like expressions such as:
{a, b, c} are authorized for userU and only {a } is authorized for userV …,
(e.g. a given user’s access control list may be described in very details by an exhaustive enumeration of all
the files and programs he has the right to read/write/execute/…;)
thus a SP model is, in that case, a quite long list of access control lists;
In that document, the terms ‘model’, ‘modelling’ or ‘modelisation’ is understood in their mathematical sense: this
means that a relevant formulation and a generic expression (of the problem that is to be solved) are included in those
three terms.
ii. genericity: by means of intentional mathematical-like notation, such as:
{∀ user ∈ MedicalStaff ∧ ∀ data ∈ MedicalRecord, user Has_Read_Right_to data}
(e.g. a user profile may be described in very precise terms by some generic rules that should be derived from
some sort of code of practise and/or some deontology law;)
thus a SP model is, in that case, a very abstract view of all the possible access rights;
iii. deducibility: by well-formed mathematical expression proved complete/correct/consistent, such as:
If userU Has_Read_Right_to PatientRecord and dataD Is_Part_Of_Medical_Record
then userU Has_read_right_to dataD
e.g. a user profile may be obtained by a dynamic calculation of his rights, within real-time constraints;
a SP model is, in that case, a coherent set of assumptions from which new assumptions can be derived.
5.4 Formal security policy modelling: a robustness obligation
In some circumstances (e.g. from E4 to E6 ITSEC levels), a security policy is more than a necessity; there is
also an obligation to describe it, to explain it and even prove it: some security features or invariable
parameters are needed to be proved on the basis of some characteristics of the security policy.
More than an existence necessity (and even a flexibility necessity), there might also be an existence obligation
for the security policy (and even a robustness obligation) in order to provide confidence and prove the
trustworthiness in/of the system which security is based on that security policy.
The solution that is often chosen to address such robustness obligations is the formal approach, for various
reasons:
i. non-ambiguity (w.r.t. security needs): because an operational SP shall be accurate enough in order to
be able to follow a deterministic behaviour in any case, even if some contradictory assumptions are
revealed;
(e.g. a given user’s access right might be both accepted or rejected depending on which rules are applied
first)
thus, the SP formal model shall be able to strongly propose which behaviour is the best one;
ii. correctness (w.r.t. environmental features): because an operational SP shall be relevant enough to
remove all the possible failures, even if the system is placed in a vulnerable environment;
(e.g. covert channels or specific information integrity downgrading shall be impossible if they are not
permitted)
thus, the SP formal model shall be able to propose the verify of the environmental-faults removal;
iii. reliability (w.r.t. original requirements): because an operational SP shall be faithful enough to its
uppermost specification level, even if the end user’s requirement are not precise and accurate at all;
(e.g. when refining in very details the system, new vulnerabilities should not be introduced)
thus, the SP formal model shall be able to successively improve the original security requirements;
In that document, the terms ‘formal’, ‘formalising’ or ‘formalisation’ is understood in their mathematical sense: this
means that a precise formulation and non-ambiguous expression (of the problem that is to be solved) are included in
those three terms.
iv. invulnerability (w.r.t. operational activities): because an operational SP shall be non-violable enough to
provide trustworthiness to its end users, even if deliberately malicious attacks against the system
occurs;
(e.g. when an attack is attempted, it shall be possible to at least detect it and even to remove it)
thus, in case of intentional attack attempts, the SP formal model shall be able to provide the evidence
that the system specification, design and implementation has been submitted to relevant security
requirements;
v. provability (w.r.t. implemented mechanisms): because an operational SP shall be provable enough in
order to be able to provide opposable elements that needs to be lawfully recognised when in court;
(e.g. when an intrusion occurs, it shall be possible to prove that adequat_to_the_need techniques were in
place)
thus, in case of security failure due to an intentional attack, the SP formal model shall be able to provide
the evidence that the systems was in a coherent state w.r.t. to its security level of requirement.
For all these reasons, the formal properties provided to the model that is intended to describe the security
policy can ensure that the robustness of the system throughout, its security policy, will be correctly and
exhaustively required, specified, designed, implemented and used.
5.5 Formal healthcare security policy modelling: a growing demand
In the healthcare/health/medical sector(s), for various reasons depending on the security specification level,
i) the global need for some information flow regulation provided by overall policies and security policies,
ii) the flexibility necessity related to the security policy concept provided by the modelling approach, and
iii) the robustness obligation related to the security policy features provided by the formalising approach,
are also some new considerations for which more and more demands have been observed.
Such growing demands have been, or will be soon, observed in many fields related to healthcare:
responsibility: both medical, medico-administrative or technical responsibility for security considerations;
delegation: delegation of actions or decisions in relation with the operational activity an IT system;
health cards: both Health Professional Cards (HPC) and Patient Data Cards (PDC);
confidentiality: both on-line confidentiality services and indirect aspects such as Trusted Third Parties (TTP);
authenticity: both on-line confidentiality services and indirect aspects such as Trusted Third Parties (TTP);
anonymity: both for reversible or non-reversible anonymisation needs or requirement, and techniques;
cryptography: both on technical and legal aspects of the development and usage of cryptographic protocols;
For all these example (e.g. responsibility, delegation, health cards, confidentiality, authenticity, anonymity,
cryptography) that are extremely fundamental for the security of the healthcare IT systems in general, both the
flexibility necessity, that can be solved by modelling, and the robustness obligation, that can be solved by
formalisation, can be shown as a very important requirement: this duality between flexibility and robustness is
perhaps the central point for the interoperability of the future standardized healthcare IT systems.
5.6 Responsibility examples
Responsibility flexibility:
Different kinds of responsibilities may be involved in an operational health data processing system (e.g.
informatics responsibility, financial responsibility, medical responsibility) so that flexibility is sometimes highly
recommended to address all of them: they should be taken into account before defining the security policy that
contains rights and duties related to each responsibility.
Responsibility robustness:
On the other side, independently of the kinds of responsibilities involved, the security property shall be
provided: this means that some robustness shall asked for those different responsibilities in the sense that the
security policy shall also contain some forbidden and some permitted features for each of those
responsibilities.
5.7 Delegation examples
Delegation flexibility:
Different types of delegation of roles may be implemented in pragmatic health data processing systems (e.g.
mono-level or multi-level delegations, mandatory or discretionary delegations, single delegate or multiple
delegate,…) so that flexibility is sometime highly recommended to address all of them: they should be taken
into account before defining any security policy that contains rights and duties related to each delegation.
Delegation robustness:
On the other side, independently of the type of delegation required, the security property shall still be provided,
this means that some robustness shall be asked for those different delegations in the sense that the security
policy shall also contain some forbidden and some mandatory features for each of those delegations.
5.8 HealthCards examples
HealthCards flexibility:
Similarly, different types of- and various implementations over- health cards may be used in a health system
(e.g. HPC or PDC, microprocessor cards or optical cards, Java cards or ActiveX) so that flexibility could
interesting in order to combine such different technology in a same security approach: they could be taken into
account before defining any security policy that contains facilities and requirements of these different cards.
HealthCards robustness:
On the other side, independently of the type of card implemented, the security property has to be provided:
this means that some robustness shall imposed to any of them in the sense that the security policy shall also
contain what is impossible and what is possible to be done by each of those cards.
5.9 Confidentiality examples
Confidentiality flexibility:
Different views of the confidentiality property have been defined, formalised and used in the past (e.g. direct or
indirect confidentiality, non-deduction or non-interference, informative or existential confidentiality,…) so that
flexibility might be useful to be able to address all of them: they shall be taken into account before
implementing any security policy that contains secrecy authorisation or privileges related to each of these
views of confidentiality.
Confidentiality robustness:
On the other side, independently of the view of the required confidentiality, the confidentiality policy shall be
ensured: this means that some robustness about the confidentiality property shall be demonstrated, in the
sense that forbidden and mandatory aspects of the confidentiality policy shall also be forecasted.
5.10 Authenticity examples
Authenticity flexibility:
Different forms of authenticity might desired in a health system (i.e. authenticity of an electronic
document/message/…, authenticity of an action/order/event, authenticity of a device/chipcard/protocol/…) so
that here again flexibility is necessary for these different forms to be expressed: they have to be considered
before writing the security policy that contains he features related to each form of authenticity.
Authenticity robustness:
On the other side, independently of the forms of authenticity asked, the authenticity property shall be proved:
this means that some robustness is also relevant for the authenticity requirements, in the sense that the
security policy shall contain some recommendation about authenticity.
5.11 Anonymity examples
Anonymity flexibility:
Different anonymity needs may be requested in an healthcare environment (e.g. cooperative or co-ordinated
anonymity, ubiquitous or unified anonymity, unique or universal anononymity, reversible/irreversible/inversible
anonymity,…) so that flexibility might be necessary to obtain interoperable anonymisation systems: they
should be anticipated before establishing the anonymisation policy and thus the security policy.
Anonymity robustness:
On the other side, independently of the anonymity needs required, anonymity shall be provided and
respected: this means that some robustness is also possible to be demonstrated for the different anonymity
needs in the sense that the security policy shall indicate what kinds of anonymity are recommended, possible
or forbidden.
5.12 Cryptography examples
Cryptography flexibility:
Different cryptographic strategies or mechanisms are used in any sensitive system (e.g. symmetric or
asymmetric, encryption or digital signature, RSA or DSA, DES or IDEA,…) so that flexibility for defining the
cryptographic policy is unavoidable: all the desired options should be taken into account in the security policy
that contains the recommended and permitted cryptographic options.
Cryptography robustness:
On the other side, independently of the cryptographic strategy chosen, the cryptographic good/claimed
properties shall be ensured: this means that some robustness of the cryptographic features shall be proved in
the sense that the security policy has to detail what is allowed and what in not form a cryptographic point of
view.
6 Historical security policies
6.1 General
This clause provides a short overview of the rich activity held in the security policy field and/or security policy
modelling area for many years. This overview has been helped by some refined aspects described, or even
detailed, in [Bieber91]. Historically famous, as well as recently more unknown, policies and/or models are
quickly described in order to show the wide spectrum of solutions that have been attempted to be THE
solutions.
More than a very detailed description of all theses policies and models, some details of the reasons of their
non-applicability due to their major demonstrated drawbacks are presented (or recalled) in this short overview.
This intention is not to be destructive; on the contrary it is to be constructive in order to go on the path of the
multi-purpose multi-property multi-fold healthcare security policy modelling activity.
For each family of such policies/models (i.e. confidentiality, integrity, both of these two properties, others), a
sort of generic conclusion is provided for being taken into account in the near future when trying to build THE
universal standard(s).
6.2 Confidentiality-dedicated security policies
6.2.1 General
The first, in time and in terms of energy spent to it, category of security policy or security policy modelling
activity is the confidentiality-dedicated one: confidentiality-dedicated because confidentiality only has quasi-
always been addressed. The huge amount of fundamental, mathematical-oriented or research-shaped work
done comes from the military and defence research and development centres which where very interested in
formalising the security property.
6.2.2 Confidentiality policies/model
The very first and very famous work on the confidentiality is the Bell and LaPadula policy [Bell74]. As perhaps
not always known, this model has been proposed in 1974 in a MITRE research report and was very famous
because its trustworthiness was based on the fact that its proof of correctness (i.e. what is called robustness
in this report) has also been provided by what is called the “Basic Security Theorem (BST)”.
In fact it is well known that Bell&LaPadula is in fact based on three (instead of two) security properties:
• the simple security property, which (briefly) says that, according to the security object classifications or
labels(in the object security level scale) and the security subject clearances or duties (in the subject security
level scale), any write-down action is forbidden, in order to avoid unauthorised information disclosure;
• the symmetrical *-property, quickly described here, according to the security objects/subjects
labels/clearances, says that any read-up action is forbidden, in order to avoid unauthorised information
disclosure;
• the discretionary security property which shortly says that any subject of the modelised system, trying to
access to any object of the modelised system, is formalised in the access control matrix of the security sub-
system.
Ten years later, John McLean [McLean85] proved that the basic security theorem was not secure (i.e. robust
in the sense developed in this report) by showing systems that, nevertheless fulfilling the BST, were not
secure in the Bell&LaPadula sense as defined by the three above-mentioned properties (i.e. simple-, *- and
discretionary- security properties).
This simply demonstrates that even the most famous and well-known aspect of the security culture might be
refuted one day: it depends on the level of details and the amount of formal proofs.
6.2.3 Formal models of confidentiality policies
As shown by the demonstration of J.McLean, who said that the confidentiality property chosen by Bell and
LaPadula was not the good one, many other works have followed considering new aspects of THE definition
of the confidentiality property, such as for the most well-known examples:
• the non-deduction model proposed by D.Sutherland [Sutherland86] considered the confidentiality property
throughout the traces of the system that is to be modelised: one trace corresponds to one running of the
system in which he tried to explicitly formalise the notion information flows in the system;
the non-deduction model is the only serious initiative for modelling in logic the notion of information flow;
• the non-interference model proposed by J.A.Goguen and J.Meseguer [Goguen84] proposed to formalise the
confidentiality property by taking into account the access control and the inference control dual aspects:
intuitively this means that when a given confidential object is not permitted to be disclosed to a given
unauthorised subject, whatever the process used (i.e., by means of not rigid enough access control and/or
not powerful enough inference control), it shall not be disclosed;
the interest of that model is that it is uses a negative formulation (i.e. a top secret object O does not interfere
with any secret (only) object) which fulfilment is easier to prove than the non-occurrence of a positive
property;
• the generalized non-interference model, an extension of the non-interference model proposed by J.Haigh
and M.Y.Vardi [Haigh86], which had the interest (w.r.t. to the Bell and LaPadula model), as for the non-
interference model, to provide both a precise and general
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...