Authorization Models in Medical Information Systems

Andrei Bretan

FAU

April 2, 2004

Definition of termsAuthorization and Authentication I

• Are separate concepts, sometimes misinterpreted (Example: Access Authorization).

• Authentication allows entity A to convince entity B of A’s identity with some degree of certainty.

• Entity A may be trying to perform some task (e.g., execute an application, invoke a function, or access a file).

• B needs to know not “who A is” as much as “whether A should be allowed to perform this task”

Definition of termsAuthorization and Authentication II

• Authorization allows B to make and enforce this decision.

• A’s identity may be almost irrelevant, useful for auditing purposes only. Example: “all executives are allowed to see the quarterly results before they are announced”

• Authentication answers the question “Who is this entity?”

• Authorization answers the question “Is this entity allowed to do what it is trying to do?”

Authorization Architecture

• An Authorization Architecture is the set of components and data that allows authorization decisions to be made and enforced.

• A typical Authorization Model for such Architecture includes the requesting subject/object, the protected object/operation, the request interceptor and the entity which holds access rights to objects/operations in the system.

Attributes I

• An Attribute is a piece of information that may be categorized as being associated with the subject, action, resource, or environment in an authorization architecture.

• Attributes may be static or dynamic. • Static attributes of the subject are referred to by many

names in various discussions and contexts: privileges, permissions, rights, authorizations, properties, characteristics, entitlements, and grants.

• Static attributes can also be associated with resources and with actions. Groups, roles, and document labels are all examples of static attributes.

Attributes II

• Dynamic attributes are those whose values cannot be relied upon to remain unchanged.

• Example of dynamic attributes of the subject include current account balance, amount of credit remaining.

• Dynamic attributes of the resource include the number of

times it has been accessed.

Policies I

• An access control policy with respect to a specific resource or set of resources is the set of rules governing who can do what to those resources under what conditions.

• The resources are data/information or functions/operations that the subject requests to access.

• The functions/operations will eventually (in most cases) translate to access to some data/information.

Policies II

• Policy expressions are at many levels of abstraction:

• Organizational goals, guidelines, compliance rules.

• Per-system operational policies and organization specific or business specific rules.

• Atomic i.e. per-resource controls.

Example: An Extended Authorization Architecture

PEP

PIP PDP PRP

S R

SA

RA

EA

PAP

S:subject, R:resource, PEP:policy enforcement point,

PDP:policy decision point, PIP:policy information point,

SA:subject authority, RA:resource authority,

EA:environment authority, PRP:policy retrieval point,

PAP:policy administration point.

Enforcing Policies I

• Mandatory Access Control (MAC): secures information by assigning sensitivity labels on data/operations and comparing this to the level of sensitivity a user is operating at.

• MAC is usually appropriate for extremely secure systems.

• Discretionary Access Control (DAC): is a means of restricting access to data/operations based on the identity of users and/or membership in certain groups.

• Access to information/operations is determined based on

authorizations specified by access control lists.

Enforcing Policies II

• Role Based Access Control (RBAC): access decisions are based on an individual's roles and responsibilities within the organization.

• Determines who can perform what actions, when, from where, in

what order, and in some cases under what relational circumstances.

• Defining roles: based on analyzing the structure of an organization and is usually linked to the security policy of that organization.

• Each role is designated a profile that includes all authorized commands, transactions, operations and allowable information access such as all access policies of that organization are enforced.

Research: Task Based Authorization (ARPA) I

• Multiple points of access, control, and decision making.

• Task-oriented or transaction-oriented perspective rather than the traditional subject-object view of access control.

• Involves authorizations at various points during the completion of

tasks in accordance with some application logic.

• The subject-object view typically divorces access mediation from the larger context in which a subject performs an operation on an object.

Research: Task Based Authorization (ARPA) II

• TBA actively takes part in access control management in contrast to traditional passive subject-object models that merely store primitive access control definition (tuples).

• In the subject-object view, the individual rights of subjects to various objects are stored in an internal data structure such as an access control matrix.

• The information in the access control matrix (or access control lists) represents independent and unrelated access control information (tuples).

Research: Task Based Authorization (ARPA) III

• TBA utilizes the emerging (flowing) context of activities as they

progress, when managing access control and authorizations.

• In contrast to the traditional subject-object view of access control that usually responds to the question: “Is subject ‘S’ allowed access ‘A’ (or possess the right ‘A’) to object ‘O’ ?” a task-based view seeks an answer to the following question: “Can task be authorized to proceed?”

Research: Other types of Authorization Models I

• Multiple Authorization Model (MAM): limiting factors of current access control systems is the dependence on a single subject for authorization.

• It is usually not possible to directly involve other entities, i.e., other people in a particular access control decision.

• The drawback is that any access decision occurs just on the behalf

of the single subject that makes the access.

• MAM Access control model that allows to include authorization of multiple subjects thus overcoming this drawback.

Research: Other types of Authorization Models II

• Authorization Models for Metacomputing Applications:

• Metacomputing systems cover large networks connecting mutually suspicious domains, which are independently administered.

• Public Key Infrastructure (PKI):• Shows great promise.• Use Public Key Infrastructure standards to identify users

and create digitally signed certificates.

Research: Other types of Authorization Models III

• Public Key Infrastructure (PKI) (cont.):• Access based on policy statements made by stakeholders.• Handle multiple independent stakeholders for a single resource.

• Provisional Authorization Models:• Almost all studies in access control and authorization systems have assumed the following model: “A user makes an access request of a system in some context, and the system either authorizes the access request or denies it.”

Research: Other types of Authorization Models IV

• Provisional Authorization Models (cont):• The notion of a provisional authorization which tells the user that his

request will be authorized provided he (and/or the system) takes

certain security actions such as signing his statement prior to

authorization of his request.

• Examples: You are allowed to access confidential information, but the access must be logged.

• You are allowed to read sensitive information, but you must sign a terms and conditions statement first.

Research: Other types of Authorization Models V

• Team Based Access Control (TMAC) is a role based access control in collaborative environments.

• Such an approach needs a hybrid type access control model that incorporates the advantages of broad role-based permissions across object types, yet requires fine-grained, identity-based control on individual users in certain roles and to individual object instances.

• A second requirement is the need to recognize the context associated with collaborative tasks and the ability to apply this context to decisions regarding permission activation.

Medical Information SystemsResearch I

• There are not many existing Authorization Models for Medical Information Systems.

• The existing ones are mostly adaptations of existing models to some aspects of the Medical Domain.

• There is no comprehensive model yet for security in the Medical Domain.

• There are no sets of patterns (corresponding to sets of policies) for the Medical Domain.

Medical Information SystemsResearch II

• Examples: R.A.Kemmerer, “Formal specification of a mental health delivery system”, Rept. TRCS89-31, Dept. of Computer Science, University of California Santa Barbara, November 1989.

• J. Biskup, “Protection of privacy and confidentiality in medical information systems: Problems and guidelines”, in Database Security III, Status and Prospects, Elsevier Science Publishing.

• J. Biskup and G. Bleumer, “Reflections on Security of Database and Datatransfer Systems in Health Care”, Procs. of the 13th World

Computer Congress, IFIP 1994.

Medical Information SystemsResearch III

• I. Mavridis, G. Pangalos, M. Khair, and L. Bozios, “Defining access control mechanisms for privacy protection in distributed medical databases”, Procs. IFIP Working Conf. on User Identification and Privacy Protection, June 1999.

• G. Pangalos, A. Pomportsis, L. Bozios, and M. Khair, “Development of secure medical database systems”, Procs. of DEXA’94.

• M. Wilikens, S. Feriti, M. Masera, “A Context-Related Authorization and Access Control Method Based on RBAC: A case study from the health care domain”.

Medical Information SystemsResearch IV

• Roshan K. Thomas, “Team-based Access Control (TMAC): A Primitive for Applying Role-based Access Controls in Collaborative Environments” , Odyssey Research Associates Cornell Business and Technology Park.

• Longhua Zhang, Gail-Joon Ahn,Bei-Tseng Chu,” A Role-Based Delegation Framework for Healthcare Information Systems”,

College of Information Technology, UNC Charlotte.

• E.B. Fernandez, M.M. Larrondo-Petrie, and T. Sorgente, "Security

models for medical and genetic information“.  FAU, Boca Raton FL.

Medical Information SystemsResearch and Implementations I

• Example: PCASSO (Patient Centered Access to Secure Systems Online) is a research project and technology demonstration that seeks to provide secure access to highly sensitive patient information over the Internet.

• Developed by Science Applications International Corporation (SAIC) and the University of California, San Diego, (UCSD) School of Medicine and Healthcare Network.

• Funded by the National Library of Medicine (NLM) of the National Institutes of Health (NIH) through its Health Applications for the National Information Infrastructure (NII) initiative.

Medical Information SystemsResearch and Implementations II

• All information in PCASSO is associated with a sensitivity label. Information may be patient-specific (e.g. patient-record information) or patient-independent (e.g. clinical research information).

• Individuals may access information only if they are acting in a role

authorized for the requested type of access (read, upgrade, downgrade, etc).

• First, the type of information is used to determine the default

label i.e. certain HL7 message types have an associated intrinsic sensitivity.

Medical Information SystemsResearch and Implementations III

• Second, an individual acting in an authorized role (e.g., primary care provider, PCASSO administrator) may explicitly assign a label.

• PCASSO uses label-based access control to separate five levels of increasingly sensitive patient information:

Low, Standard, Deniable, Guardian Deniable, Patient Deniable.

• PCASSO also uses label-based controls to protect its system software from malicious or misbehaving programs and its system data from unauthorized disclosure.

Medical Information SystemsResearch and Implementations IV

• Roles may be patient-specific (e.g., patient, primary care provider, secondary care provider, emergency provider) or patient independent (e.g., researcher, administrator).

• Each role is associated with a sensitivity level range, a set of rights, and an access control list (ACL).