Enrich RBAC and ABAC with ProBAC, #infosec #security #BPM

1 The problem

For the stable functioning of an enterprise, it is mandatory to define up-front WHO (person, system, role) can DO SOMETHING (e.g. read, update, delete) with WHAT (tangible or intangible asset or resource), WHEN (at a particular moment of time), WHERE (from which tool, environment), WHY (justification) and HOW to impose this.

There are two popular techniques:

1. Role-Based Access Control (RBAC) is about what role (WHO) can execute what operation (DO SOMETHING) on a particular object (WHAT).
2. Attribute-Base Access Control (ABAC) is about granting rights to users (WHO) through the use of policies which combine attributes together. The policies can use any type of attributes: user (WHO) attributes, resource (WHAT) attributes, environment (WHERE) attribute etc.

To provide a reasonable granularity, RBAC causes an explosion of roles and ABAC causes an explosion of rules. Both techniques are static and require a lot of work to handle compound resources.

2 Process-Based Access Control (ProBAC)

To reinforce the governance, management and operations over the classic access control techniques, it is proposed to consider the access control with the context of business processes.

The enterprise functioning is considered as business activity flows spanning systems, employees, customers and partners within and beyond the enterprise boundaries. Various roles as well as tangible and intangible resources are involved in each business activity. Some resources are read-only for some of those roles; other resources can be modified by some of these roles. (Of course, we remember, that for each activity, the RACI pattern may be applied).

The illustration below shows this in dynamic:

1. by default, the roles associated with a particular activity have no access to the resources associated to this activity;
2. an actor (a concrete staff member) who claimed this activity is granted necessary permissions to do something with the associated resources;
3. as the actor finished the activity, all given permission are revoked.

This is the principle. Of course, the activity life-cycle is more complex because of delegation, escalation, cancellation and un-claiming. Each change of activity’s state should

3 Link to microservices

ProBAC, as a way to know the context, also simplifies the use of microservices - see http://improving-bpm-systems.blogspot.ch/search/label/%23microservice  .

4 Bigger picture of the information security

ProBAC is an integral part of the bigger picture which enhances the enterprise-wide information security – see http://improving-bpm-systems.blogspot.ch/search/label/%23security



Thanks,
AS