The ASCLEPIOS context-aware security model consists of classes and properties that can serve as background knowledge for creating access control rules for Electronic Health Records (EHR).
The ASCLEPIOS security model
The model comprises five top-level classes: Location, DateTime, Connectivity, Object and Subject. The class Location describes a physical and/or a network location where data are stored or from which a particular entity is requesting to access data. The class DateTime specifies the datetime at which an access request takes place or a data artefact is stored. The class Connectivity captures information related to the connection used by the subject for accessing sensitive data. The class Object refers to any kind of artefact that should be protected based on their sensitivity levels. These artefacts may refer to relational or other databases, files, software artefacts that manage sensitive data or even infrastructure artefacts used. Finally, an instance of the class Subject represents the agent seeking access to a particular data artefact. This can be an organisation, a person, a group or a service.
A glimpse inside the model: The Subject class
Figure 1. ASCLEPIOS Security Context Element Subject overview diagram
Figure 1 depicts the main parts of class Subject. Its subclasses comprise Person, Software, Group and Organisation.
For example, Person, which refers to anyone that is a data owner or a data requestor by an EHR system, comprises:
- Technical Staff: any entity with technical capabilities and responsibilities
- Administrative Staff: any entity in charge of administrative responsibilities in healthcare provider organisation
- Medical Force: the medical staff that conducts research; improves or develops concepts, theories and operational methods; and applies scientific knowledge related to medicine
- Researcher: a person who conducts scientific research involving background research, constructing a hypothesis, testing it, analysing data and concluding the results
- Employer: workers who, working on their own account or with one or a few partners, hold the type of job defined as a self-employed job, and in this capacity, on a continuous basis have engaged one or more persons to work for them in their business as employees
- LegalGuardian: a person who legally assists and supports minor children, mentally disabled persons or incapacitated older adults in their personal life. They can manage their property, help with daily financial administration and assist with the ward’s medical or social needs
- ContactPerson: someone who undertakes the responsibility of communication among healthcare providers or emergency call team in cases of an unconscious patient
- Patient: a person who is a recipient of healthcare, that is services received by individuals or communities to promote, maintain, monitor or restore health
Contextual attributes are used by the Asclepios authorisation policies, i.e., policies with constraints based on the use of contextual attributes which facilitate decision making on granting or denying access to protected resources or access operations. We specifically consider two types of policies and hence we provide two relevant semantic representations; one for Attribute-based Access Control (ABAC) policies and one for Attribute-based Encryption (ABE) policies.
ABAC and ABE in a nutshell
– In the case of ABAC, resources are protected by restricting attempts/requests to access or use them based on the characteristics (i.e. attributes) of the access requests as well as the resource. The characteristics of requests, resources and access operations can be dynamically-evolving contextual attributes. An ABAC rule takes the form:
| Requestor with Context Expression has Authorisation for Action on Resource |
which defines a generic structure, in terms of relevant attributes, to which all ABAC rules in the ASCLEPIOS framework adhere.
– ABE enforces the protection of resources through encryption and authorizes access to them only when certain predetermined attributes are featured. These attributes (the required values) are defined in the form of an ABE policy. In ASCLEPIOS, ABE policies are used to derive a decryption key used to decipher the encryption/decryption symmetric key of a resource.
Outro
ASCLEPIOS aims to combine ABAC and ABE policies for authorisation. We consider a two-step process where ABAC policy is first applied on access attempts to resources (either data or functionality) and subsequently, if an ABAC permit is granted, ABE policy is applied in order to recover the resource decryption key.