RBAC and ABAC and Roles, oh my.

PLEASE NOTE: I'VE MOVED THIS BLOG TO http://identitysander.wordpress.com DUE TO ISSUES WITH COMMENTING ON THIS SYSTEM. PLEASE SEE ALL NEW ACTIVITY THERE. THANKS.

So I missed the Kuppinger Cole webinar with Felix Gaehtgens on ABAC, but I read the materials and the Q&A was really good. What it got me thinking was that there may not be enough good stuff in the world explaining the basic differences between RBAC and ABAC and why one may be better than the other. So here's my take on it.

First, let's set up what RBAC is. RBAC stands for Role Based Access Control. The idea is that instead of granting individuals access to assets the access is granted to a role. Individuals are then associated with the role and thereby gain access to the assets. Like with so many things, there is a decent wikipedia article on RBAC, but it fails to capture some of the basic flaws I see. If you were to draw a picture of RBAC, it may look like this:



From left to right in the above diagram, you have the asset to which access is being granted. Then there is some form of a rule which is controlling access to that asset. If the asset were a file, then the permissions in the filesystem for that file would be the rule. Then you have the roles. The roles can have users associated in a number of ways. Attributes can determine the user being associated. Rules can also be used to determine role association. And a user can also simply be declared to have a role explicitly. Last you have the users and all their attributes. If the users were in AD, then the attributes would be all the attributes of the user object. In this RBAC model, the assumption is that controlling and maintaining access is easier since there doesn't have to be a direct relationship maintained for every user. The roles act as an abstraction layer. When assets were all files and the rules that governed access to them were very simple, that made sense. Now assets are much more than files on disk, there is almost always a middle application tier involved, and the rules are very robust.

In this newer, application ruled world, there are many issues with RBAC. First, asset owners must be aware of role details in order to make their choices about what roles get access. To grant access to the wrong roles means granting access to the wrong user. So all the logic for the granting of the role must be understood by the asset owner and that means almost no advantage in terms of spreading out load for maintenance - everybody must understand everything. Second, there are now two layers of abstraction, rules and roles. This results in some very complex interactions which make it hard to get a grasp of just how access is being granted, and that is very bad come audit time. Third, access is now dependent on role maintenance. If there is a group maintaining the roles with a complex and locked down change control procedure and a nimble application group which needs a lot of changes, you end up with process timing mismatches that can cost real money. And last but far from least, new use cases for assets means new roles. Because the rules can only result in a pass or fail for roles, if there is a need to have a different access scenario there will be a need for a new role to match it. And that means role proliferation and more maintenance.

For those reasons and more, I believe ABAC is becoming more popular. ABAC is Attribute Based Access Control. It's picture is much more simple:



Right away, it's clear ABAC is cleaner. It eliminates the man in the middle and puts the users right in touch with the assets. The abstraction layer RBAC provides has become overhead in the face of the new ways the assets can govern themselves. The rules assets can use via their applications are more than enough to give flexibility to the asset owners. And since the users are likely to have a good set of attributes to draw on for evaluating their claim to access, there is no reason to add the other layer of roles to mitigate. The rules can simply evaluate attributes and be quite abstracted from the actual users. And since it's much more likely that attribute stores are well maintained since they are linked to HR and other time and legally sensitive business drivers, there is much less likely to be issues with asset owners outpacing the maintenance of their source of access control information.

Of course, roles are simply going away. The role of roles is changing. The new picture is really more like this:



The roles are not directly involved with access control rules - except perhaps that they may show up as an attribute of the user and be used in the rules evaluations. But the roles are very useful in the administration of massive sets of users. They are also very useful in the attestation, auditing and other security and identity processes around entitlement management. Maybe it's time to think of RBEC, Role Based Entitlement Control. The idea being that entitlements, the security view of business rules for access, are governed and audited via roles. But we can keep the OLTP side of access control, the effective controls, in an ABAC form.

That's a lot of typing. Hope someone finds it useful...

entitlements and access - separate but equal?

So I’ve finally had the time to digest a lot of the materials and notes I collected at catalyst 2009. Though the identity track had a lot of content around many topics, there was one theme I kept hearing again and again. Access control is king. That’s not news, but it seems like everyone is just coming back from role management, provisioning and other IAM projects to find that the core issue is still waiting to be solved.

The other thing that seemed to emerge, at least to me, was a distinction between the definition of entitlement management and access management. Entitlement management is the practice of deciding what business functions a person should have access to. So a statement about entitlements would be: “Sally Brown the Accounting Director may sign off to close the books at the end of a quarter”. That may be recorded in a system. And I think that is the ultimate goal of systems like Aveksa, Sailpoint and CA/Eurekify. But what seems to happen in those systems in a practical sense is that people record things at a technical level. So they end up with statements like: “people belonging to a group with an ID of 3345 may execute the sys_plx_camp_fog procedure in the PROD system”. Of course, that is useful to know. But it is still something that needs to be decoded. To their credit, all the systems let you put friendly names around these things, but that doesn’t address the core issue. The core issue is that people are using an entitlements tool to solve access issues. It is a process issue.

Access management is the practice of encoding and enforcing entitlements in the IT infrastructure. It’s where the rubber meets the road. So things in your access management solution should actually be able to touch your infrastructure and make it listen to policy. This type of tool has been around forever. Quest’s own ActiveRoles Server, Privilege Manager for Unix and others perform this role in various types of infrastructure. Another prime example is Keystone from BiTKOO, which does this using all the new OASIS pizzazz of XACML, PDPs, PEPs and such. And just like the entitlements tools get abused by the IT staff to do technical duties, you also see these tools getting pulled by the business to try and to entitlements work.

Of course, all of this goes back to that ever present prime mover in identity – compliance. Not the only reason people do IAM work, but one of the major drivers to be sure. And so the use of one product to do entitlements and access work is natural because people are trying to get things done under time constraints to avoid failures in the next audit and also under budget constraint since they (IT) are spending someone else’s money to do it.

AD Bridging gets respect at Burton's Catalyst09

day two at catalyst09 was very on target for me. the identity track was all about leveraging existing resources for bigger ROI and that’s all we ever talk about in PM meetings around here. Burton’s Mark Diodati presented about the AD Bridge space, a name he may have invented, and then there was also a customer case about the practice of doing AD Bridging for Unix, Mac and Linux systems. the best part was when a person in the audience took the mic during Q&A and thanked Mark and Burton for taking the AD Bridge products seriously and the whole audience erupted in applause.

i’ve got lots of notes and thoughts about everything that went on. i’ll likely be posting reactions to catalyst09 over the next week.

what's on the mind of people seeking IAM solutions

Mark Diodati from Burton Group put together an article about what he sees his clients asking about. what surprised me were some of the categories he used. something like “Access Management” is so broad that it acts as a catch all. not surprisingly it gets second place after “Authentication” with 14.4% to authN’s 22.5%. Of course, authN is also pretty broad, but “Access Management” can cover just about every topic relevant to IAM given the chance. to be fair, i’m not sure what you can do about an issue like this. when you’re asking people to classify their comments, there’s only so specific you can get before you confuse or bore.

complaints about methodology aside, there was not much that’s surprising here. a lot of it mirrors our own 7 projects, those tactical goals that are the eggs and juice of the IAM healthy breakfast. If there was any surprise, it was “Federation” at 5.4% and “Authorization and Entitlement Management” at 4.4%. It seems like that’s all IAM folks and many clients want to talk about. But maybe a lot of that buzz got sucked into “Access Management” where it could rightfully belong.

security in the cloud - different standards?

i was recently at a nice little conference in NYC and one of the speakers was Adam Swidler of Google (Adam’s bio via the conference host’s site). Adam spoke about cloud services and covered the topic very broadly. one of the points he addressed, which was in tune with the topic of the day, was security. a comment he made about standards stuck with me. he said that we can’t hold the cloud to different standards than we would our own infrastructure. to set the standards for what we have today, he referenced well covered stats about loss of data via laptops and USB sticks, soft internal security and other well known risks in IT today. The point was then made that holding the cloud to a better standard than that was not fair.

i’m not sure i can agree. shouldn’t we expect that someone who is claiming that they can manage huge volumes of data in a multi tenant model is going to have better security than the statistically average IT shop? we should and do expect companies like banks and credit card providers to have better security for specifically these reasons. if Google and other cloud providers hope to have the business of banks and other high risk data carrying entities in aggregate, doesn’t that hold them up to a stronger standard? i found myself thinking this was a dodge. but maybe i’m wrong. what do you think?

M&A and divestitures in the light of IAM and security

i was at the Technology Managers Forum security conference today (http://www.techforum.com/sf2009_1/index.html). it was a really good event packed with a lot of engaged people. we held a panel about M&A and divestitures and had a really good conversation. the conclusion is that planning and policy, like with so many other things, is the key to doing any of this well. but everyone also acknowledged that especially in today’s fast paced divestures and M&A driven by market conditions instead of business growth, there isn’t always time for the best plan and having a decisive direction and good tools is the only substitute.

we only had 45 minutes so we didn’t get into a heck of a lot of details. but i was wishing we had triple that by the end because the audience was participating and so many good threads were started and then cut off in the end. i’m sure we’ll get another chance to dive deeper.

feel free to post thoughts here and we can talk it out…

The coolest stuff i saw at RSA

The coolest stuff I saw on the show floor at RSA:

1. Validus had an OTP card with a biometric built in all in the credit card form factor (http://validustech.com/index.cfm)

2. Aveksa, hiding out in the Novell booth, had a very slick entitlement audit and role management system with a nice demo (http://www.aveksa.com/)

3. The NSA had a booth and was giving away an awesome cipher game book. My daughter and I will be hacking away at that for a while, I’m sure.

4. Not technically on the show floor, but I got a chance to sit with someone from Bitarmor and they made me think encryption at rest could really be viable (http://www.bitarmor.com/)

5. Arcsight was giving away a smart car. And I thought our $5000 prize was big!

stuck in the middle with you

last week i was at a meeting at one of the financials, and it was no surprise that they want to talk hard cost cutting. they want to get everything they can onto their low cost, well run MSFT platforms. at the meeting are myself and the account manager who brought me in as well as another sales rep and their accompanying talking head. it must be fun for clients to schedule dueling consultants. i know i would in their shoes.

everyone was on the same page at the start. the topic was how to get their LDAP user stores into either AD or ADAM as easily as they can. they were reserving the choice between AD or ADAM for later. the conversation strayed a bit and we were talking about how they also wanted to get SSO for their external users out of this if they could. the other consultant kept dismissing my claims that they were going to have to go through a transition period due to their stated need to keep some users on LDAP longer than others. it went in circles until i asked him to lay out his plan. “First,” he said “you move everyone to ADAM”. the head architect from the client and i smiled at each other.

wasn’t the point that they could not just “move everyone to ADAM”? so many people seem to miss the part in the middle where both the old and the new have to work together for a while. and if you can’t see that, then you’re not seeing the real problem. if we could just snap our fingers and put everyone on shiny new tech all the time, shops like QSFT would be out of business. it’s all the hard parts that people get stuck on in the middle of these projects that make it interesting…

manage privileged accounts or privileges themselves?

Interesting article on privileged account management at SC magazine. whenever i read about this i can’t help thinking there’s a problem with the model. i think of it like a house. and password vaults, the primary vehicle for privileged account management, are a place you store the keys to the house. but once you’re inside, you could walk over to the priceless vase on the mantle and knock it over. the better model is to control the access at the level of individual entitlements – don’t give someone root, give them the ‘restart webserver’ right. it’s like having them in the house and allowed to look at the vase but not touch. the analogy always breaks down there unless you invoke crazy glue, though. but i bet you get the point.

of course, i can feel dimikagi getting ready to chide me that managing stuff at the individual entitlement level requires a previously sophisticated and mature approach to get right. and that’s correct. but most organizations could easily identify many use cases where they have whole communities of people getting access to privileged accounts just to run one command – the classic use case where every DBA has the oracle account just to restart the network listener for the database. so i think there could be some very easy things to knock off the list in even the most chaotic shop. otherwise we’d all have to take the nice things off the mantle or stop letting in guests all together.

8 weak doors or one strong one?

lots of talk about sso and authN at TEC 2009. what fascinates me is how many people are espousing the merits of having completely different credentials for many systems. they all claim that the reason is security (at least all of them that i have heard). one of our senior products folks has an analogy they use that i like to discuss this. he will ask, if you were building a house would you want 8 weak doors or one strong one? and i think that really gets to the heart of the security issue.

but even if you grant that perhaps many credentials could potentially be stronger than one, the question becomes what is the trade off? basically, we’ve been working de facto under the multiple credential world for the whole open systems era and no one thinks we’re in a good security state. i would submit it’s because of all the other issues that come from many credentials like more to manage and burden on the users. so i’d ask if there is really a way to get rid of the burden on the users and maintenance issues? some say synchronize, but then you have one door again (or at least one key that works on all the doors). and now you have extra infrastructure on top of what you already have.

sso and AD briding has a role. so does sync. but whatever the stuff that powers this stuff, sso seems like it will always be the one strong door when it’s done right. what do you think?

authZ everywhere

i’ve been spending a lot of time with prospects and clients. every one of these meetings is set up to talk about identity lifecycle and authN. but every single one ends up in a discussion about authZ. friday afternoon i sat in one of the nicer buildings in uptown manhattan and we were talking to a big media company. we were talking about their homegrown websso solution and how quest may be able to offer them something more robust. i mentioned that our product could also do some basic authZ work and the lead on the project said “if you want to talk about authorization we’ll need two more hours”. i scratched at the surface a little bit, but we only had 20 more minutes for that meeting. “everyone is challenged with this right now if they have even a slightly complex shop” the customer was very clear to state.

certainly, authZ is a big topic. Gartner’s last IAM conference made it clear that getting an authZ strategy in line is the next big task for a well run IT shop. MSFT is ready to take a fresh run at the issue in Geneva with a better chance of success (MSDN Blogs). there are some really cool players in the space like Bitkoo. and there are some really big companies taking the plunge through acquiring, the biggest being the Cisco + Securent take down. but there seems to be a big break in the types of companies i see actively looking into this. it’s the smallest of the big and the biggest of the small. shops that, not coincidentally, have the right kind of budget and the right level of complexity to be far enough along in a maturity cycle that this can edge it’s way out to the front as a real project. but project or not, everyone wants to talk about it. it will be interesting to watch it all play out.