ACWP State of the Art

From IHE Wiki
Jump to navigation Jump to search

IHE White Paper on Access Control

State of the Art

Principles of Secure Design

  • 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.
  • Complete Mediation: Every access attempt must be explicitly safe-guarded through the access management mechanisms at all times. This also implies that there must be no possibility to avoid the access management (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 check- and 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: Addresses the principle that anything which is not allowed explicitly is denied by default. That means in practice, that any access attempt, which may not be explicitly and entirely verified as allowed, is automatically denied. Privileges are admitted exclusively to an initially empty set of rights (opt-in instead of opt-out).
  • Separation of Privilege: All security and safe-guarding mechanisms must ensure that multiple conditions, which exist independently from each other, are fully checked and validated before granting any rights.
  • Least Privileges: Any identity should only 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 may not add unnecessary complexity to the user or complicate the user to execute the granted right of accessing that resource unjustifiably.
  • Reluctance to Trust: External systems, individuals, users, and objects should be always considered as insecure. A certain level of trust in external elements may only be granted, when explicitly supported by adequate security certifications, such as Common Criteria [CC 3.1]. Furthermore, it is imperative to limit and minimise the amount of mechanisms, systems, and objects, which are to be fully trusted required for the access control/management.
  • 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]]

Access Control Paradigms: DAC, MAC, RBAC, ...

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. However, in a typical DAC-style model, it may not be avoidable that a user may acquire access rights for resources - through the means mentioned above - which this user should not posses conventionally.
  • Mandatory Access Control (MAC): The validation and grant of access rights is performed by utilising sensitivity levels/labels, rules, and/or policies. In the simplest case (multi-level) sensitivity each object 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. The MAC-style access control model - with a certain degree of tweaks and modifications - is implemented and utilised in most of the operating systems.
  • 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).

Policy Based Access Control (PEP, PDP, ...)

All commercial implementations of the above named and described access control models are based upon the strict separation - as illustrated in figure 3 - 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-behaviour of a given system. The security policies addressed in this paper are defining, what subjects may - under what constraints with what operations - access what objects.
  • A Policy Decision Point (PDP) may decide on the concrete outcome of an incoming authorisation request. In order to do that, the PEP is applying the best-fitting policy and may determine additional security attributes when necessary. Then the PEP is executing the policy onto the incoming authorisation request. The result - coded in form of a policy decision - defines whether the requested access operation is granted or denied.
  • 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.
WPAC PEP PDP v01.png

XACML [XACML 1.0] defines two further actors:

  • The Policy Adiminstration Point (PAP) who is basically administering 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.

Standards (SAML, WS*, XACML, XSPA, ...)

Author's Note: Standards are discussed in greater depth in chapter 6. Therefore I would suggest to skip this issue here.

Discussion

place issues to be discussed among the editorial team here...

Change Requests

place your change requests here...

Retrieved from "http://wiki.ihe.net/index.php?title=ACWP_State_of_the_Art&oldid=28863"