SIST-TP CEN/TR 15300:2006

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

• Status: Published
• Publication Date: 30-Nov-2006
• ICS: 35.030 - IT Security
• ICS: 35.240.80 - IT applications in health care technology
• Technical Committee: ITC - Information technology
• Current Stage: 6060 - National Implementation/Publication (Adopted Project)
• Start Date: 01-Dec-2006
• Due Date: 01-Dec-2006
• Completion Date: 01-Dec-2006
• Ref Project: CEN/TR 15300:2006 - Health informatics - Framework for formal modelling of healthcare security policies

Standards Content (Sample)

SLOVENSKI STANDARD
SIST-TP CEN/TR 15300:2006
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
SIST-TP CEN/TR 15300:2006 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------

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.

---------------------- Page: 2 ----------------------

CEN/TR 15300:2006 (E)
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

2

---------------------- Page: 3 ----------------------

CEN/TR 15300:2006 (E)
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.
3

---------------------- Page: 4 ----------------------

CEN/TR 15300:2006 (E)
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.
4

---------------------- Page: 5 ----------------------

CEN/TR 15300:2006 (E)
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.
5

---------------------- Page: 6 ----------------------

CEN/TR 15300:2006 (E)

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;
6

---------------------- Page: 7 ----------------------

CEN/TR 15300:2006 (E)
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]

7

---------------------- Page: 8 ----------------------

CEN/TR 15300:2006 (E)
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
8

---------------------- Page: 9 ----------------------

CEN/TR 15300:2006 (E)
[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
9

---------------------- Page: 10 ----------------------

CEN/TR 15300:2006 (E)
[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
10

---------------------- Page: 11 ----------------------

CEN/TR 15300:2006 (E)
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).
11

---------------------- Page: 12 ----------------------

CEN/TR 15300:2006 (E)
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].
12

---------------------- Page: 13 ----------------------

CEN/TR 15300:2006 (E)
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.
1
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;

1
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.
13

---------------------- Page: 14 ----------------------

CEN/TR 15300:2006 (E)
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.
2
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;

2
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.
14

-------------------
...