Patterns for access control

1
Patterns for access control

• E.B. Fernandez

2
Access control models

• An access control model defines who can access
  what and in what manner in a system
• Some secure design methodologies start from use
  cases and from them a conceptual model is
  developed. Security constraints are then defined
  in the conceptual model. The most important
  constraints are related to access control

3
Many access control models

• There are many models for access control, mostly
  variations of some basic models and it is
  confusing for a software developer to select an
  appropriate model for her application
• Access control models generally represent a few
  types of security policies, e.g. rights are
  assigned to roles, and provide a formalization
  of these policies using some ad hoc notation
• Four basic access control models are commonly
  used and they may be extended to include other
  aspects
• Access control models can be defined for
  different architectural levels, including
  application, database systems, operating systems,
  and firewalls
• Some of them apply to any type of systems while
  some are specialized, e.g. for distributed
  systems.

4
Model dimensions

• Access control models fall into two basic
  categories mandatory models (MAC), where users
  rights are defined by administrators and data may
  be labeled to indicate its sensitivity, and
  discretionary (DAC), where users may administer
  the data items they create and own
• In a MAC model users and data are classified by
  administrators and the system applies a setoff
  built-in rules that users cannot circumvent
• In a DAC model, there is no clear separation of
  use and administration users can be owners of
  the data they create and act as their
  administrators
• Orthogonal to this classification, there are
  several models for access control to information
  that differ on how they define and enforce their
  policies

5
Basic models for access control

• The Multilevel model organizes the data using
  security levels. This model is usually
  implemented as a mandatory model where its
  entities are labeled indicating their levels.
  This model is able to reach a high degree of
  security, although it can be too rigid for some
  applications.
• The Access Matrix describes access by subjects
  (actors, entities) to protected objects (data,
  resources) in specific ways (access types). It is
  more flexible than the multilevel model and it
  can be made even more flexible and precise using
  predicates and other extensions. It is
  intrinsically a discretionary model in which
  users own the data objects and may grant access
  to other subjects. This model is usually
  implemented using Access Control Lists (lists of
  the subjects that can access a given object) or
  Capabilities (tickets that allow a process to
  access some objects).
• Role-Based Access Control (RBAC), collects users
  into roles based on their tasks or functions and
  assigns rights to each role. RBAC has been
  extended and combined in many ways.
• Attribute-Based Access Control (ABAC). This model
  controls access based on properties of subjects
  or objects. It is used in environments where some
  subjects may not be pre-registered

6
Many variants

• While these basic models may be useful for
  specific domains or applications, they are not
  flexible enough for the full range of policies
  present in some of these applications
• A large variety of ad hoc RBAC variations that
  have been proposed most of which add specialized
  policies to a basic RBAC
• For example, some models have added content or
  context-dependent access, delegation, role
  hierarchies, task-based access, and relationships
  between role entities
• All these models effectively incorporate a set of
  built-in access control policies and cannot
  handle situations not considered by these
  policies

7
Confusion for the designer

• All these models present a bewildering set of
  options to the designer, who has problems
  deciding which model to use
• The result in practice is that only basic models
  are used and the power of more advanced models is
  thus lost
• We try to clarify this panorama here through the
  use of patterns
• We use pattern diagrams to make clear the pattern
  space and help in their selection
• A subproduct is the analysis of which patterns
  are available for use and which need to be
  written
• Pattern maps are also useful to perform
  semi-automatic model transformations

8
What is a pattern?

• A requirement for a pattern is that the solution
  it describes has been used in at least three real
  systems
• This is consistent with the idea of patterns as
  best practices
• However, a pattern can also describe solutions
  that have not been used (or have been used only
  once) but appear useful for several situations
• Because of this, we include here both types
  good practices patterns and useful solutions
  patterns
• We consider more important their genericity

9
Structure of models

• Access control models have two aspects a
  definition of a set of rules specifying the valid
  accesses (some of them may be implicit), and an
  enforcement mechanism that intercepts access
  requests from users or processes and determines
  if the request is valid
• The main difference between models is on the way
  they define their rules, so it makes sense to
  separate the enforcement mechanism
• For each type of models we provide separate
  patterns for rules and only one pattern for
  enforcement.

10
Organizing the models

• Pattern diagrams can help the designer in the
  selection of an appropriate model
• Starting from a basic Authorization (Access
  Matrix) pattern we can add elements
• The basic access matrix defines rights for
  individual subjects to access resources

11
Access matrix authorization rules

• Basic rule ( s, o, t ) , where s is a subject
  (active entity), t is an access type, and o is an
  object
• Extended rule ( s, o , t , p, f) , where p is a
  predicate (access condition or guard) and f is a
  copy flag
• This, and the other models, can be described by
  patterns

12
Authorization/Access Matrix
13
Patterns derived from the Access Matrix
14
Reference Monitor

• Each request for resources must be intercepted
  and evaluated for authorized access
• Abstract concept, implemented as memory access
  manager, file permission checks, CORBA adapters,
  etc.

15
(No Transcript)
16
Analyze elements of the access matrix

• Understand function of each element subject,
  object, access type
• Consider administrative approaches (MAC and DAC)
• Start from a general pattern that defines
  structure of authorization rules Policy-Based
  Access Control

17
(No Transcript)
18

• We can expand each branch of the big pattern to
  focus on some specific aspects and analyze better
  the pattern relationships
• The initial pattern diagram could have been
  obtained in this way

19
Policies and sessions
20
Growing models from simpler models

• Each pattern can be augmented with new features
  to produce a new variety of models
• The next figure shows the basic RBAC pattern,
  where users are assigned to roles and roles are
  given rights
• The NIST standard adds the concept of session and
  a simple role hierarchy
• The next figure shows a model of RBAC beyond the
  NIST standard where in addition we have
  object/resource hierarchies where the hierarchies
  are recursive (described by the Composite pattern)

21
(No Transcript)
22
NIST model with composite hierarchies
23
A more advanced RBAC model
24
Distributed systems

• The nature of distributed systems implies that a
  subject does not need to be known in advance by
  the system in order to request access to a
  resource
• The use of credentials including attributes may
  be sufficient to trust a subject.
• In the next diagram, traditional models, such as
  the Access Matrix and RBAC (Role-Based Access
  Control), are represented along with
  Attribute-Based Access control and Policy-Based
  Access control
• All of the models use a Reference Monitor to
  enforce access decisions
• ACL (Access Control List) and Capability are
  implementation-oriented patterns they implement
  the Access Matrix or RBAC model
• For web services, XACML (eXtensible Access
  Control Markup Language) Access Control
  Evaluation implements the Attribute-Based Access
  control pattern and the Policy-Based Access
  control pattern, and the XACML Policy Language
  implements the Policy-Based Access control
  pattern
• The SAML Authorization Assertion is a kind of
  Capability.

25
Patterns for distributed systems
26
More complex models

• With these basic units we can compose more
  complex, implementation-oriented AC systems
• Policy-based access control defines access
  evaluation based on general policies stored in
  some repository
• Depending on the objects, rights are defined by
  administrators or users, the policies may define
  a MAC or DAC model, respectively
• Policy-based access control uses a reference
  Monitor for its enforcement functions and a
  Policy pattern that defines the general structure
  of each policy
• Policy-based access control may be specialized to
  implement models such as the Access Matrix, RBAC,
  or ABAC by convenient adaptation of the policy
  structure.

27
Policy-Based access control

• The Policy-Based Access Control pattern decides
  if a subject is authorized to access an object
  according to policies defined in a central policy
  repository.
• Context We consider centralized or distributed
  systems with a large number of resources
  (objects). A large number of subjects may access
  those objects. Some rules are defined to control
  access to objects. The rules defined by the
  organization are typically designed by different
  actors (technical, organizational, legal, etc),
  and each set of rules designed by a specific
  policy designer can concern overlapping sets of
  objects and/or subjects. We assume that access
  requests come from authenticated subjects.

28
(No Transcript)
29
Models through analogies

• We can build security models through analogies
  when two standards or regulations have similar
  types of policies
• We can convert a HIPAA model into a
  Sarbanes/Oxley model

30
(No Transcript)
31
Moving to SOX

• The Patient record can become a Financial record,
  the Patient becomes an Investor, the doctor is
  now a Broker
• This approach simplifies the task of building
  pattern catalogs and makes it easier for users to
  remember what patterns to use in a given
  situation.

32
A SOX model
33
Conclusions

• We can navigate the pattern diagram because
  patterns are composable, i.e. adding a feature
  (perhaps embodied by another pattern) produces a
  new pattern with extra features
• Using this approach we could not only clarify the
  relationships of AC models but it lead us also to
  discover the need for new security patterns
  Subject, Object, Labeled security, DAC, MAC
• In order to apply this approach one needs
• A good catalog of security patterns to
  let designers find
• the required solution to each security
  restriction
• A classification of patterns according to
  their security
• concerns and architectural level