ACWP State of the Art

From IHE Wiki
Jump to navigation Jump to search

IHE White Paper on Access Control

State of the Art

In this section the state-of-the-art with respect to access control is sketched. All of the concepts provided in this section have evolved over the last 20 years and are well established. Their consideration in access control design therefore heavily contributes to the security and implementability of the overall system.

Principles of Secure Design

Security cannot be added to an existing system; it must explicitly be built into a system from scratch. The following list sums up some of the most important design principles for access control solutions that have been evolved over the last 20 years. The numbers in square brakets that follow the list items point to sections in this white paper where architectural issues considering the respective principle are discussed [tbd, when ToC is stable].

  • Economy of Mechanism: The used mechanism must be kept as simple as possible. It should also target a well-confined issue instead of trying to cover each and every eventuality. With respect to access control in healthcare one should always consider whether technically driven access control, organizational rules, or reactive measures - e. g. logging - are most appropriate for the implementation of different access restrictions.
  • Complete Mediation: Every access attempt must be explicitly safe-guarded through the access control mechanisms at all times. This also implies that there must be no possibility to bypass access control (even for special roles/functions such as administrators) while accessing any resource.
  • Open Design: All algorithms and security mechanisms have to be openly available and fully verifiable.
  • Least-Common Mechanism: Mechanisms, system states and objects, which are capable of explicitly or implicitly granting access rights, should not be shared between different users and/or applications. For each individual user or application, a different mechanism or an instantiation of the same mechanism should be used.
  • Fail-Safe Defaults: Anything which is not explicitly allowed is denied by default. That means in practice, that any access attempt, which cannot be explicitly and entirely verified as allowed, is automatically denied. Privileges are admitted exclusively to an initially empty set of rights (opt-in in favour of opt-out rules).
  • Separation of Privilege: Whenever possible, security and safe-guarding mechanisms should verify multiple, independent conditions.before granting access to a protected resource (e. g. a user must match a certain role and issue the request from a trusted system). Well known concepts based on this principle are »separation of duty« and »two-man rule«.
  • Least Privilege: Any identity should be granted with the least set of access rights possible in order to complete its assigned function or task. If any right needs to be added to perform extraordinary duties, the right may be granted when actually required and discarded after the completion of the non-standard task.
  • Psychological Acceptability: Mechanisms securing and safe-guarding access to a resource should follow comprehensible mental concepts and must not add unnecessary complexity to the user. Missing psychological acceptance usually leads to situations where users find creative ways to bypass many of the other design principles (e. g. everyone in a hospital department uses the most priviledged account).
  • Reluctance to Trust: Every system, human actor, and runtime environment should be always considered as insecure. Trust should never be loosely given. Furthermore, it is imperative to limit and minimise the amount of mechanisms, systems, and objects, which are required to be fully trusted required for the access control subsystem.
  • Privacy Consideration: Any identity should only have access to exactly that fraction or portion of the data, which is immediately required in order to fulfil its current task in its current role/function.
  • Isolation: All access control/management mechanisms should be isolated from other systems, operated independently, and must be specially secured.

References:

  • Saltzer, J. H.; Schroeder, M. D.: The Protection of Information in Computer Systems. Proceedings of the ACM. Vol. 63, Nr. 9. pp. 1278-1308. 1975.
  • Wallach, Dan; Balfanz, Dirk; Dean, Drew; Felten, Edward: Extensible Security Architectures for Java. In: Proc. 16th Symposium on Operating Systems Principles, October 1997, Saint-Malo, France. [[1]]
  • Benantar, Messaoud (Ed.): Access Control Systems. Springer. 2006.
  • Bishop, Matt. Computer Security: Art and Science. Boston, MA: Addison-Wesley, 2003
  • Ferraiolo, David; Kuhn, Richard; Chandramouli, Ramaswamy: Role-Based Access Control. Artech House. 2. Auflage, 2007.
  • Build Security In. Website of the US Department of Homeland Security.[[2]]

Common Access Control Models

The three fundamental access control paradigms, which may be found and distinguished in practice today, are:

  • Discretionary Access Control (DAC): the validation and grant of access permissions is solely performed on the basis of the concrete identity of a subjects and its group membership. Subjects who possess access rights for a certain resource may pass those on to other subjects. In a quite common implementation of DAC (such as used in UNIX), to each resource a special property called the "owner" is assigned, who may exclusively grant or deny any access rights to users or other groups for this resource.
  • Mandatory Access Control (MAC): – Mandatory Access Control (MAC): The validation and grant of access rights is performed by utilizing sensitivity levels/labels, rules, and/or policies. In the simplest case each protected resource and each user posses a set of security attributes: the user is usually assigned a clearance level, whereas the resource is assigned to a sensitivity level. Rules determine how those levels may concretely correlate and whether and how users of one clearance level may grant access rights to other users of different clearance levels. Depending on these rules different security objectives can be supported; e. g. if confidentiality is the major objective the Bell-LaPadula Model is more appropriate while integrity protection is better supported by the Biba model. In many running systems further dimensions – e. g. a specialty – are added for dealing with equivalency classes of sensitivity and/or clearance levels (lattice-model).
  • Role-Based Access Control (RBAC): The RBAC-model is not assigning access rights to any resource directly to a subject's identity. Instead, each subject's identity is assigned with a set of roles, in which any access rights are defined. The concrete executing of access rights is therefore not directly bound to the user but acquired through its current role. The roles and its concrete permissions may be defined hierarchical (hierarchical RBAC) and rules may be constructed, which defines limitations (constraints) for the role assignment and permissions-granting (constrained RBAC).

Many countries' laws constitute the patient as the souvereign of his medical data (my body - my data - my control). Therefore the patient implicitetly is the owner of his data and the only one to grant access permissions. This leads to a DAC influence on every access control solution in healthcare. This influence is rather implicit in an intra-enterprise scenario where a treatment contract is usually signed by the patient which transfers part of the patient's rights to the hospital (which is as well part of the DAC paradigm). In an inter-enterprise or cross-domain scenario this DAC-portion of the access policy is much more visible and usually expressed by a patient privacy consent. We will come back to this issue as part of the discussion patient privacy consents in chapter 3 of this white paper.

MAC requires subject-classes and object-classes to be partially ordered. Assuming that functional roles are used for permission assignment, this partial order must be either coarse-grained or artificially constructed. IHE BPPC is well suited to implement rather compact MAC style access control features using HL7 confidentiality codes which are e. g. supported by IHE XDS, DICOM, and HL7. An example of how an access control solution using the MAC paradigm and IHE BPPC could look like is provided in chapter 5.

RBAC is best suited to align access permissions with the organization of labor within a medical organization. Especially for intra-enterprise access control RBAC is evolving to be the paradigm of choice. For the last years VA and HL7 have provided respective guidance on the process of permission definition and on adaptable catalogs of roles and permissions. These efforts and the underlying "needs-to-know" principle will be discussed in more detail in chapter 3.

Policy Based Access Control

All commercial implementations of the above named and described access control models are based upon the strict separation - as illustrated in the figure below - of the Policy Enforcement and Policy Decision [RFC 2753, RFC 3198, ISO-10181-3]:

  • A policy is considered to be a set of rules, which are controlling the security- and privacy-behavior of a given system. The security policies addressed in this paper are defining, what subjects are legitimated to access what objects for which purpose.
  • A Policy Enforcement Point (PEP) intercepts all access attempts for any resources safe-guarded by the access control/management and forwards those requests to the PDP. Afterwards it receives the policy decision of the PDP and enforces its result against the requester.
  • A Policy Decision Point (PDP) may decide on the concrete outcome of an incoming authorization request. In order to do that, the PDP is applying the best-fitting policy and may determine additional security attributes when necessary. Then the PDP is executing the policy onto the incoming authorization request. The result - coded in form of a policy decision - defines whether the requested access operation is granted or denied.
WPAC PEP PDP v01.png

XACML defines two further actors:

  • The Policy Adiminstration Point (PAP) who is basically administering and keeping the policies.
  • The Policy Information Point (PIP) which facilitates the PDP to acquire any additional security attributes of resources and subjects in order to determine whether an access request is to be granted or denied.



Open Issues

The figure on PEP/PDP must be repainted without the MFC language constructs. For reasons of synchronicity with the text PIP and PAP should be integrated. Joerg.caumanns 17:48, 27 January 2009 (UTC)
Section 2.1.3: We should be describing these parts of access control in abstract. I am ok with this level of break-down, but I am concerned that we are using XACML terms too soon. I would rather we simply spell out PDP, PEP, PIP, PAP, etc… [John Moehrke]
Section 2.1.2: "Ease of Use" should be used instead of "Psychological Acceptability" [John Moehrke]
Most of the principle's "names" in use today are taken from a 1975 paper (Salzer's "Principles of Secure Design") and used consistently in AC literature. Therefore I would not touch this terminology... Joerg.caumanns 20:29, 19 February 2009 (UTC)

Closed Issues

This section is very long. Any ideas about what could be left out? Joerg.caumanns 17:49, 27 January 2009 (UTC)