In last
week's contribution (From ‘oversight’ to the algorithm-driven company) I
contemplated about the necessary underpinnings of a digital transformed
corporation, gave some justification why it is so hard to answer the
obviously simple question, which is at the core of any oversight: Who
has (had) access to which Resources? And I mentioned how oversight is
executed according to the state-of–the-art. In this third and final post
I will discuss current trends and - with the help of professional
analysts - try to look ahead.
Despite Mark Twains (among others) warning “It is difficult to make predictions, especially about the future.” in 2015 modern days Pythia, The Gartner Group, predicted that “By
2020, 70 percent of enterprises will use ABAC as the dominant mechanism
to protect critical assets, up from less than 5 percent today.”
Why do they come up with such a radical opinion and what are the driving forces behind? Well, unfortunately, after all these years in business I am still not capable to read the mind of a Gartner analyst. However there are some evident trends, which even I stumbled upon. And so might have done those augurs.
ABAC stands for Attribute Based Access Control as opposed to RBAC (Role Based Access Control). It is a policy-based approach, where machine executable policies (executable business rules) act on certain attributes (well, parameters, as a programmer would say). If invoked at runtime a highly dynamic and responsive authorisation infrastructure can be created this way.
And this is exactly the point. Agility is not only required on project level, but on corporate level as well. It goes without saying that just the board of directors being agile will not be sufficient. Its rulings need to take immediate effect, without trickling down the organisation throughout the following years.
Dealing with compliance for example has become more complex and costly than ever before.
Thomson Reuters once counted a mere number of ~100 minor or major regulatory changes per day to be taken into account, most of them in the financial sector. You certainly need to be fast in order not to be breathlessly chasing after their implementation, before finding them already outdated, but instead get into the driver seat again and take advantage of market opportunities.
A policy-based approach means a centralization of management with executable policies as its key element. As the total of interacting policies on all levels can be considered as the central governance processing machine, direction & oversight will be executed by running these governance programs.
Also decision making can be centralised and implemented in a redundancy-free way – decluttered.
My statement here is: Roles are just the result of rules applied on the access space – however most often without being documented. Implement those rules directly and RBAC will appear to you as a special case static ABAC. This striking similarity has been recognised by the “inventors” of ABAC too. The NIST proposes 3 different ways to take advantage of both worlds by a model extension.
First of all, roles already were capable of being parametrized. This easily overlooked little, yet powerful, feature was initially designed to cope with non-functional attributes and dynamic decisions based on attributes.
Some attributes however are independent of roles. A combined model was sought therefore. The NIST came up with a 3-fold proposal. Note: All three variants can even be combined and used within one single access model.
Dynamic attributes like time or date are used
to determine the subject's role, hereby retaining a conventional role
structure but changing role sets dynamically. For further reading I
refer to R. Fernandez, Enterprise Dynamic Access Control Version 2 Overview.
Here a role name is just one of many attributes – without any fine structure. The role is not any longer a collection of permissions like in conventional RBAC.
The main drawback is the rapid loss of RBAC's administrative simplicity as more attributes are added (IEEE Computer, vol. 43, no. 6 (June, 2010), pp. 79-81). In this approach you may have problems determining the risk exposure of an employee's position.
This 2nd scenario could serve as a good approach for a rapid start, generating early results of automatic entitlement assignment - without deep knowledge of the job function.
In the 3rd variant attributes are added to
constrain RBAC. Constraints can only reduce permissions available to the
user not expand them. Some of ABAC's flexibility may get lost because
access is still granted via a (constrained) role. On the other hand
system retains the RBAC capability to statically determine the maximum
set of user-obtainable permissions.
The RBAC model in 1992 was explicitly designed, to apply additional constraints to roles. This approach is the one envisioned as the natural RBAC approach by KuppingerCole.
First of all, don't leave rules unrelated. Provide a traceable deduction from business- or regulatory requirements, e.g.:
Second, attributes must be provided on demand during runtime during invocation of the authorisation sub-system by calling an attribute server, e.g. an operational Data Warehouse, which in turn collects them from various corporate or external sources.
Third, there is no way around the enumeration of the same rules for reporting & audit, which are used for the authorisation act as well. And maybe the auditor's questions have to be altered & more explicitly specified too.
If different tools are used for specific sub-tasks, the underlying data have to be kept in tight sync. Hereby single duty services, operating in an SOA fashion, are to be preferred over all encompassing monolithic suites.
In addition in attestation runs business line representatives reassess past business decisions. Information hence needs to be expressed and presented to them in business terms.
Finally Information security demands a holistic approach. Entitlement information and operational access information have to span all relevant layers of the IT stack (Applications, Middleware, operating systems, hardware and – of course – physical access).
For forensic investigations assessments have to be performed back in time. Past entitlement situations hence need to be stored in a normalized structure, reaching sufficiently back and easy to query in its historic context (aka ‘temporal’ functionality).
Deciding on the implementation of appropriate activities however needs a solid foundation. Data analytics applied to I&A provide the equivalent of switching on the light before cleaning up a mess. The resulting architecture hence should be layered into at least the following:
Each layer itself may be expressed in its own Business-, Technical or Data-architecture.
Based on a sufficiently rich set of data the compilation of the most basic I&A health indicators allows for directing effort in the most promising IAM and / or IAG activities. Hence IAI should be the first of the three disciplines to invest into. Identity & Access Governance needs to be built on top of a powerful data warehouse. Discovery & warehousing hence enter centre stage of I&A Governance.
A caveat should be mentioned however: In addition to I&A knowledge this approach requires sound data analytics skills – usually not found in I&A but rather in marketing- or product-Q&A departments.
The changes to be expected are …
To summarize all the sections in three (although lengthy) sentences:
What does Pythia foresee for us?
Why do they come up with such a radical opinion and what are the driving forces behind? Well, unfortunately, after all these years in business I am still not capable to read the mind of a Gartner analyst. However there are some evident trends, which even I stumbled upon. And so might have done those augurs.
ABAC stands for Attribute Based Access Control as opposed to RBAC (Role Based Access Control). It is a policy-based approach, where machine executable policies (executable business rules) act on certain attributes (well, parameters, as a programmer would say). If invoked at runtime a highly dynamic and responsive authorisation infrastructure can be created this way.
And this is exactly the point. Agility is not only required on project level, but on corporate level as well. It goes without saying that just the board of directors being agile will not be sufficient. Its rulings need to take immediate effect, without trickling down the organisation throughout the following years.
Dealing with compliance for example has become more complex and costly than ever before.
Thomson Reuters once counted a mere number of ~100 minor or major regulatory changes per day to be taken into account, most of them in the financial sector. You certainly need to be fast in order not to be breathlessly chasing after their implementation, before finding them already outdated, but instead get into the driver seat again and take advantage of market opportunities.
A policy-based approach means a centralization of management with executable policies as its key element. As the total of interacting policies on all levels can be considered as the central governance processing machine, direction & oversight will be executed by running these governance programs.
Also decision making can be centralised and implemented in a redundancy-free way – decluttered.
Combining RBAC and ABAC
I took both four-letter-acronyms RBAC and ABAC as antagonists for the (old) static and the (new) dynamic world of “real-time enterprises”. Well, static is not all bad and the world is not black and white. Static structures will remain and they will do so for the benefit of the corporations.My statement here is: Roles are just the result of rules applied on the access space – however most often without being documented. Implement those rules directly and RBAC will appear to you as a special case static ABAC. This striking similarity has been recognised by the “inventors” of ABAC too. The NIST proposes 3 different ways to take advantage of both worlds by a model extension.
First of all, roles already were capable of being parametrized. This easily overlooked little, yet powerful, feature was initially designed to cope with non-functional attributes and dynamic decisions based on attributes.
Some attributes however are independent of roles. A combined model was sought therefore. The NIST came up with a 3-fold proposal. Note: All three variants can even be combined and used within one single access model.
Dynamic roles
Attribute-centric
Here a role name is just one of many attributes – without any fine structure. The role is not any longer a collection of permissions like in conventional RBAC.
The main drawback is the rapid loss of RBAC's administrative simplicity as more attributes are added (IEEE Computer, vol. 43, no. 6 (June, 2010), pp. 79-81). In this approach you may have problems determining the risk exposure of an employee's position.
This 2nd scenario could serve as a good approach for a rapid start, generating early results of automatic entitlement assignment - without deep knowledge of the job function.
Role-centric
The RBAC model in 1992 was explicitly designed, to apply additional constraints to roles. This approach is the one envisioned as the natural RBAC approach by KuppingerCole.
Governance in a flexible RBAC & ABAC world
A question remains to be answered: How to do recertification if there are no static entitlements? We remember that re-certification is one of the traditional key elements within the detective controls of the oversight part of Identity & Access Governance.First of all, don't leave rules unrelated. Provide a traceable deduction from business- or regulatory requirements, e.g.:
- Regulations (external) → Policies (internal) → Rules (executable, atomic) → Authorisations (operational)
Second, attributes must be provided on demand during runtime during invocation of the authorisation sub-system by calling an attribute server, e.g. an operational Data Warehouse, which in turn collects them from various corporate or external sources.
- However, some limitations may remain: In the end there is no static answer the “who-has-access-to-what” question in a dynamic environment.
Third, there is no way around the enumeration of the same rules for reporting & audit, which are used for the authorisation act as well. And maybe the auditor's questions have to be altered & more explicitly specified too.
- Re-certification of dynamic entitlements will feel more like debugging JavaScript code than ticking off long entitlement list twice a year.
Requirements to I&A technology
So what will be the requirements to the supporting technology? As I mentioned IAM, IAG & IAI are by no means isolated disciplines. They operate on highly fragmented yet massively overlapping information in arbitrary formats following different retention policies.If different tools are used for specific sub-tasks, the underlying data have to be kept in tight sync. Hereby single duty services, operating in an SOA fashion, are to be preferred over all encompassing monolithic suites.
In addition in attestation runs business line representatives reassess past business decisions. Information hence needs to be expressed and presented to them in business terms.
Finally Information security demands a holistic approach. Entitlement information and operational access information have to span all relevant layers of the IT stack (Applications, Middleware, operating systems, hardware and – of course – physical access).
For forensic investigations assessments have to be performed back in time. Past entitlement situations hence need to be stored in a normalized structure, reaching sufficiently back and easy to query in its historic context (aka ‘temporal’ functionality).
Deciding on the implementation of appropriate activities however needs a solid foundation. Data analytics applied to I&A provide the equivalent of switching on the light before cleaning up a mess. The resulting architecture hence should be layered into at least the following:
- A Business Layer
- A Technical Layer and
- A Data Layer.
Based on a sufficiently rich set of data the compilation of the most basic I&A health indicators allows for directing effort in the most promising IAM and / or IAG activities. Hence IAI should be the first of the three disciplines to invest into. Identity & Access Governance needs to be built on top of a powerful data warehouse. Discovery & warehousing hence enter centre stage of I&A Governance.
A caveat should be mentioned however: In addition to I&A knowledge this approach requires sound data analytics skills – usually not found in I&A but rather in marketing- or product-Q&A departments.
Outlook - dynamics blends in to the static approach
Although a powerful technology needs to be invoked, in order to keep the complexity on a manageable level, the transformation my not need to be performed in one revolutionary big bang step. Rather an agile, evolutionary approach will lead to faster and better results and a higher degree of user (i.e. Management level) acceptance.The changes to be expected are …
|  |
|
- In essence it thus turns out that after undergoing a digital transformation not only the business operations will be automated.
- Management of these operational processes as well as the overarching governance will need to follow that automation trend too.
- This is certainly still a long way to go.
