Phil and Eric had asked me to sit in on a panel titled “Are NIST Based Roles the Right Answer?” along with Thomas Raeuchle (Prodigen) and Chris Sullivan (Courion). Phil set the premise that he had heard through all his conversations “that in the process of compliance auditing that in the process of auditing compliance data, auditors have come to people and said in order for us to audit the process, instead of auditing the data, [you need] to go role based” and as a result people are getting the order to go role based.”

Phil went on to note that “Role based is one of those things that is easy and makes a lot of sense…”, however… “[while] it is conceptually simple but it stops right about there, and that actually the process of going to roles tends terrifies those who have done it, and terrifies those who haven’t done it even more because they’ve seen the ones who have done it.”

So this was a discussion around why are roles not rolling out like it should?

One issue was that no one wants to roll out something new, so everyone coalesced to the NIST RBAC model. So the question was “Are NIST Based Roles the Right Answer?”

Phil introduced me as one of the DIDW advisory board member, as well as a guy who knows “everything”. Still trying to figure out the impetus there, but Phil and I definitely have had some interesting and wide ranging conversations around the field.

On the panel, we started with a discussion around what the NIST RBAC model actually is and whether it is a standard. We agreed in principle that the model was primarily a good thing to start from in terms of it being a mathematical and mechanical model for roles. We also agreed that it was not an easy thing to understand. As for it being a standard, the answer is “yes”. RBAC was adopted by the ANSI group in 1994, and is the American National Standard 359-2004. (You can find it at the International Committee for Information Technology Standards - http://www.incits.org/). Because it is primarily a model that works well in a single application, and can create challenges when working across applications, without clear implementation guidelines. Asking the crowd whether they had actually seen the standard, over 90% of the audience said they had not… herein is the interesting thing – everyone wants roles and more importantly wants to understand them, but reading the standard is tough – I’ll touch on that in a minute.

the question was is the model the right thing to use.

As a result of the usability challenges with the “standard” there is a new effort underway through NIST to undertake an update. Thomas introduced this and noted that it would be based on the current standard, but, it doesn’t mean it can’t build something new that may be different from the current approach. Many vendors including HP are involved as well as organizations hoping to better utilize the standard. You can find information on this effort a www.intcits.org under the cyber security group known as CS1.

In the middle, we all agreed that roles work well in individual applications (for example, in SAP), however, Chris and I definitely disagreed on some of what is critical in a deployment. Chris suggested that everyone should read and understand the NIST RBAC standard – I disagreed. Even having read and largely understood it myself, I think people would understand as much as necessary conceptually if they read other more accessible documents detailing role usage rather than the NIST model (ANSI standard). Because no one implements RBAC completely per se, and roles are even less consistent across applications, it doesn’t help that much to have done much more than skim the standard – If at all.

The reason was that we need to understand how the tool allows you to manage the roles, and more critically the policies that define how roles are used. Furthermore, across applications, the hierarchical approach pushed by the model does not extend far enough to support the variety of needs of security, business and it. Ultimately this becomes a change management issue that the model does not solve in any way – it is up to the management tool or tools in place.

Interestingly Phil who is deeply involved in the industry admitted he had never actually read the standard, and this is closer to what most happens to most folks who try to implement roles. My position is that role modeling and management over time require better management tools that also handle delegation as well as time based or temporal concerns. In this I believe that because we are dealing with complex environments with complex change management issues, we cannot consolidate these issues to just IT and security. We need to be able to offer the capabilities to business managers. Getting to a state is one thing that we might achieve with IT and security alone but managing it to support business needs over time is the real issue. So if we agree that starting somewhere is a challenge, the point I was making is that we are getting wrapped around the wrong axel (or not seeing the forest for the trees and numerous other analogies).

In general the panel agreed that roles are tough to manage, especially at scale. It was also agreed that a better “read” as it were is the Healthcare Level 7 (HL7) model http://www.hl7.org/ regardless of whether you’re in healthcare or not, as it provides a good approach for defining roles. In addition the Software Engineering Institutes Capability Maturity model at http://www.sei.cmu.edu/cmm/ is another more mature model on how to do enterprise role implementations. Chris and I did agree that these are definitely more implementation focused and useful whatever industry an organization is in.

I noted that the “standard” does not help you move from one product to another. As such, the issue is the interpretations and implementations of roles in products – especially identity management products.

From my experience with customers and vendors alike, everyone is different and everyone is the same… is that a cop-out? Specifically, all organizations want a starting point in terms of a role definition, but all organizations deviate from that starting point with unflinching uniqueness. Implementation experience helps get to that starting point, but that very quickly deteriorates as an organization deals with all the changes it needs to. I am not just referring to identity changes, but IT and business changes as well such as systems and hardware being put into or taken out of the environment, or mergers and acquisitions taking place.

Ultimately given the answer of 42 (see HHGTTG), we came back to the issue with the topic, which is, “what is the question we are trying to answer in the first place”, or, “did we ask the right question”. As a result, the thinking was that a better title based on the discussion might have been: “What is NIST RBAC best suited for?” and given everything discussed today.

Given the space of this post, I’ll have to follow up with some more thoughts in another one…