The “Model-As” Problem

In my last post, I talked about Jeff Bardin’s excellent session about the reality of successfully deploying an enterprise IAM infrastructure. During his session, he touched upon one of the more interesting problems that we see in enterprises today – the “Model-As” problem.

Jeff was referring to a practice that is very common in a lot of enterprises today. When a user is getting created and provisioned in the enterprise, system administrators and/or managers basically rely on a common short cut. Instead of trying to figure out what privileges that a new user Bob should have, they essentially say “give Bob all the privileges that Alice has, because Bob has the same job as Alice”. As Jeff so articulately pointed out, the result is the propagation of bad or unneeded privileges from one user to another. One can easily see how privileges that Alice accumulated over her lifetime of service end up in Bob’s profile, even if some of those privileges were legitimately assigned to Alice only for a short period of time, after which they should have been taken away. And as we are learning, enterprises are actually quite fluid and the privileges that a user has actually reflects how much a user’s actual responsibilities differ from the base definition of their “job”.

This is the “Model-As” problem, also known within our group as the “Copy User” problem. It becomes a problem because it assumes that the privilege environment is pristine, and that everyone has only those privileges that they should have. It also assumes a highly rigid enterprise where two people doing the same job will essentially do the same things and remain the same from a privileges perspective. In most complex enterprises, that is not true, and the result is an unnecessary explosion of compliance violations and privilege creep.

The solution, as Jeff pointed out, is actually quite simple – RBAC. The model-as problem exists because it is the poor man’s RBAC model. In the absence of true role management, and role based provisioning, the manager is forced to identify a model user that is, in essence, the description of the role(s) that the new user needs to be assigned. Bringing in RBAC and role-based provisioning can help clean this up by providing the necessary abstraction and control to the environment. Assigning an ad-hoc or short-lived privilege to Alice no longer pollutes the role definition, and therefore eliminates scope creep. In the future things like resource management software could also aid to stop or reduce scope creep and continue to allow the business to flourish. Companies like ProSymmetry (https://www.prosymmetry.com/resources/how-to-prevent-scope-creep-disaster-with-resource-management-software/) provide this software so businesses can continue to aim for success. RBAC and role-based provisioning also allow the administrator to change the role-privilege definition once and apply it everywhere, without having to go and track the model-as patterns and chains. In Jeff’s words, it brings sense and order to the “identity chaos” that exists in the enterprise.