5 Reasons RBAC Projects Go Wrong

We were discussing the main causes of RBAC projects failing this week at Oxford. The discussion is sure to go on, as there are probably as many reasons for failure as there are roles in most organizations (which is many), but I offer here five of my personal favourites. Before I elaborate though, we should first perhaps clarify what I’m talking about when I mean “an RBAC project” (as others may have different definitions or mental models)

I’m assuming here we are talking about enabling or facilitating enterprise RBAC and that our architecture comprises some or all of the following:

• Some applications that have an internal security model that uses roles for managing access to resources (like SAP or other ERP applications)
• One or more enterprise directory (Active Directory or LDAP, or both) that stores users in groups that are then used for authorization purposes by applications that don’t have internal roles
• The applications that use the above directories (and there are plenty of them now) for authorization data
• An authoritative source of identity data: perhaps (but not exclusively) HR for employees, an enterprise directory, or an IAM application or portal

Into this we are looking to deploy a roles management system that will:

• Define, keep and maintain representations of roles
• Automatically decide who gets what roles (and their associated permissions) in some cases, and allow manual administration in others
• Have some kind of workflow for approvals and notifications
• Provide feedback in the form of audit logs, reports, and (possibly) some kind of dashboard

Our aim, in our project, is to deploy this system and almost certainly hook it up to some form of provisioning or identity synchronization service to automatically deploy and manage user accounts and permissions in our enterprise applications and directories. By doing so we aim to reduce the administrative effort associated with managing our application roles and to provide an enterprise-wide view of permissions, thus enhancing security and helping us to comply with regulations such as SOX. We might perhaps also create enterprise roles that comprise many application roles, groups or other permission sets (listen and watch my webinar on pragmatic roles for more about this).

In my experience, the main reasons that roles projects fail are as follows:

1. For the same reasons other IAM projects fail: lack of executive buy-in, trying to do too much in one go without a clear set of prioritised requirements, and poor project management. See my trainwreck article for more details on these.
2. Not allowing enough time and resources for role mining. You need to allow lots of time to extract all your various application roles from their applications, and you will need support in the form of a business analyst and some technology (either a role-mining app like Eurekify, or do it yourself with ILM and SQL). Armed with these, you then need to probe your key applications and winkle out the roles and permissions buried within.
3. Not grouping application roles into enterprise roles. If you don’t group application roles into the logical wrapper of an enterprise role, you probably will end up in the apocryphal state of having more roles than people. It’s inevitable that you have lots of application roles, but the aim is to make these manageable by normalizing them into one enterprise role per organizational role (if such a thing exists).
4. Worrying too much about NIST-compliant RBAC. Whilst NIST-compliant RBAC remains a worthy goal, I believe that it can sometimes act as an inhibitor for people who should really just crack on and make a start with a few enterprise roles, or just enabling some simple role-based provisioning. If your roles management tool doesn’t support inheritance or segregation of duty, so be it. Just get on with it anyway.
5. Getting bogged down trying to define organizational roles. Again, these are nice to have. If our HR system contained a list of the 300 company-approved roles and every user entry in the system had one (and only one) of these roles, it would be easy to deploy a data-driven provisioning system that could read and act on them. But life is rarely that simple and if you work in a dynamic (dare I say chaotic) organization that changes often and re-engineers itself on a regular basis, you may never get to this stage. As with NIST-compliance, waiting for HR (or those very expensive BPR consultants they have hired) to define every possible role every employee might ever have before starting with some role-based provisioning is a bit like waiting for Godot. And he never comes.

Bear in mind here that I’m a pragmatist rather than a visionary. I don’t believe in waiting until things are perfect before I act. I like to roll up my sleeves and crack on to try and make things better, even if it’s just small incremental improvements, it’s better than nothing. Sometimes this means I discover halfway through that I need to stop, take stock and then reappraise, or even do some rework. But in my opinion that’s still better than waiting for perfect conditions to appear before starting: they seldom do.

The DIM Report Lives Again

Not my temporary Blogspot blog, the original DIM Report is back in all its tawdry glory (real or imagined)!

I’ve recently registered my own name as a domain (www.davenesbitt.com) and whilst I’m still fiddling about with themes and trying to decide whether to use WordPress or Drupal as my CMS, I thought it might be fun to put the old DIM Report html up there. All the links seem to still work, and the content is quite an eye-opener. It’s amazing how much has changed in just 3 years, and how much is still the same. Some companies have fallen by the wayside (Critical Path) some have been acquired (Abridean, Waveset, Business Layers, OpenNetwork, RadiantLogic, Netegrity, Oblix, Maxware etc), and some are still going strong on their own, but the basic message has remained the same.

The best way to view it is to click on the “Report” link from the top menu, then select a report at random from the left hand menu.

Final Words (for now) on the Child Benefit Lapse

I read a couple of things over the weekend that seemed to vindicate my main thoughts from last week (well, I would hardly read or report on stuff that contradicted me, would I?). Whilst it’s never nice to blow your own trumpet, if I don’t give myself a couple of toots it’s unlikely anyone else will, so what the heck.

Toot! I said that I found it hard to believe that the breach was caused by a junior official deciding on his own initiative to copy the entire database. I thought it was much more likely that the whole thing was down to systematic incompetence. According to The Sunday Times yesterday, “the Revenue routinely sent secret data with no security“. That doesn’t quite square up with what the good Chancellor of the Exchequer (the government minister in charge of this department, international readers) said in Parliament, but it doesn’t surprise me at all. In fact, it confirms what I suspected. The main cause of this loss of data was an endemic laissez-faire attitude within Customs and Excise with regard to citizens’ personal data. They didn’t care enough about it to treat it as valuable. Hopefully they (and other agencies and companies who hoard this stuff) might just have been frightened enough by the reaction to “datagate” to change this attitude before it happens again. Which it will.

Toot! Toot! I also said that this affair should convince us all to oppose the National ID Card and database, simply on the grounds that it will not be secure and its contents will inevitably be exposed to ne’er-do-wells and ID thieves either through negligence or a crooked employee (who now knows the real value of the data). The Government’s answer to these concerns is “Biometrics”. They claim that as the database will contain our encrypted biometric signature, there is no way ID thieves could ever steal our records, as they wouldn’t be able to use it. Yah, shuah. Ben Goldacre at Badscience.net does a far better job than I could on systematically dismantling this claim. Sorry, but if you make something valuable enough, someone, somewhere is going to work out how to steal it and how much more valuable is someone’s biometrically-authenticated identity than a plain old NI number?

Anyway, enough on this for now, more riveting real-world enterprise IAM and not-very-funny lolcats to follow shortly, I promise.

Sober Reflections on the Child Benefit Agency Debacle

A couple of days have now passed since the Government announced that two CDs containing the entire Child Benefit database went missing in the post, but the furore shows no signs of dying down, quite rightly too. Now I’ve had a chance to listen to the rhetoric on both sides, and the many opinions offered by all sorts of “experts” from every media outlet, I offer the following.

Don’t Panic, But Do Be Angry
There is no need to panic. To paraphrase Michael Winner, “calm down dear, it’s only your personal data”. The chances of this data actually ending up in the wrong hands are fairly small, and there was no data in the breach that would allow hackers to suddenly log onto our Internet Banking accounts and withdraw huge sums. There is every reason to be angry though as this was a very serious breach. Whilst there was no data that hackers could use directly, there was a mass of data that ID thieves would just love to get their hands on. In particular, details such as our children’s birthdays are often used as secondary verification; I can think of at least one time I used my eldest son’s birthday as a six-figure PIN, along with my wedding day. The sheer weight of this personal data, combined with our National Insurance numbers, could well be sufficient to convince a poorly-trained or naïve customer service rep that the person on the end of the phone claiming to be me actually is me (when it isn’t – it’s a dirty ID thief).

The Truth Will Set You Free
Hopefully this breach will make us all think a little harder about how we manage our personal identity data. The Government, other organizations, and especially company websites, have trained us to enter our most precious dates and details into online forms in order to receive rewards. We now need to break free from this Pavlovian conditioning and take back control. We need to stop trusting those who ask for our data and ask them some hard questions: why do you need this? How do I know you will look after it properly? Personally, I rarely enter my genuine contact information unless I am utterly convinced there is a need for it. I don’t enter my real date of birth, nor do I enter my mobile or home phone number, even if the little web form has an asterisk next to it telling me it’s mandatory. As an aside, hello to all the web marketers out there – how did you get on with Mickey Mouse, the Ugandan Company Directory who wants to spend $10,000,000 dollars on your software in the next week? What, he turned out to be false? And you handed him over your valuable white paper too? You mean people give you false details when you demand their mobile phone number in return for marketing data? For shame! What is the world coming to? Here’s an idea, how about you all get a grip and stop expecting us to cede our private data to you? I know all you want it for is to sign me up for your newsletter and to give to your telesales monkeys to bombard me with phone calls about your crappy software. I know your game, I don’t trust you and I ain’t gonna give it to you.

Sugar-Coated Iceberg
We need also to understand that this breach is just the tip of the iceberg. Right now, all across the world, managers and minions who have been mismanaging databases full of identity data are wiping their brows and thinking “thank God it was them, not us”. These people are almost certainly also storing our data insecurely and transporting it inappropriately, they just haven’t been caught out yet. Just look at the recent breach at retailer T J Maxx. TJX admitted to losing 45.7m credit and debit card numbers and personal information relating to almost 500,000 people in a recent security breach. How many more will there be? All organizations that capture any personal data need to take a long hard look at their current processes for capturing, storing and providing access to this data. If they don’t need it, they need to get rid of it. If they must keep it, then they must keep it securely. They should encrypt the base data and then put rigorous access control procedures in place, including authentication, authorization, and audit processes. In other words make sure no-one can get access to the data unless they prove who they are (using strong authentication, not just username and passwords), that they have the right to do what they are trying to do and that thorough audit logs are kept

Plain Old Incompetence or More Systemic Failure?
Getting back to the Child Benefit Agency breach, I find it very hard to believe that this was just simply a junior official deciding on his own initiative, without the knowledge of management, to copy the entire database to CD and pop it in the internal mail. There are some odd things going on here. For a start, why did he copy the entire database? If the what the Conservative head of the Public Accounts Committee, Edward Leigh, says is true, and the National Audit Office wanted only limited child benefit records, then surely the most obvious thing to do would be to run a simple query against the database and generate just the data required? You could then take the results file, encrypt it using a file encryption tool, and email it to the recipient with a read receipt attached: simple, cheap and quick. In fact, far simpler and cheaper than copying the whole thing to disk and posting it. Did this just not occur to him? Or, more likely, did someone else in authority suggest it? Apparently this wasn’t the first time the NAO had requested the data – surely he mentioned the fact to his line manager. I can understand the Conservatives and other opposition politicians trying to make political capital out of the mess, but I just don’t buy the argument that this was simply a result of penny-pinching. How can burning a CD be cheaper and easier than my alternative suggestion? The whole thing smacks more of systemic incompetence, lack of training, lack of professionalism and poor supervision. How could the departmental manager not have known what was going on? Surely the request for this extremely sensitive data didn’t go directly to a junior official? If it did, then this says something quite serious about a lack of understanding of the sensitivity of the data and something even more serious about the lines of communication between government departments. If the manager did know what was going on, then he or she needs his or her backside kicked every bit as hard as the clerk who did the awful deed. Had everyone in the department been under no illusions that the database was sacrosanct and that access to it should be protected at all costs, this almost certainly would never have happened.

Morals, Morals, Morals
The morals of this sorry tale are threefold. For everyone, use this as a reminder to take more care of your personal data. Yes, I know that you have no choice but to hand it over to the Government, and that you should be able to trust them, but learn not to hand it over to anyone else unless you really have to. Question those who would take your identity data from you for no good reason. Question hotel clerks as to why they need your home phone number and don’t give lazy and greedy eCommerce sites your real mobile number unless you think there is a genuine reason for them to have it. For organizations that grab and hoard personal data from customers, stop it. Stop training us to hand over our identity data to people who have no business with it. Retain only that which you really need and then protect it properly. Control access to this data rigorously and keep audit logs. Learn to treat other people’s identity data with respect. We are not commodities. Finally, for the UK Government, realize that what you have done is (once again) reinforce people’s belief that that they cannot trust you and that Government IT departments are fundamentally incompetent. Pay your permanent staff a decent wage and train them properly. Get managers to manage and understand that the buck stops with them. Use external contractors sparingly, but don’t be afraid to call in the experts when you need to. Stop using policies and procedures as crutches, teach individuals instead to be accountable for what they do. Most importantly, drop the ridiculous ID card scheme. It will run vastly over budget and over time. It will cost billions, have little real impact in preventing crime or terrorism, and, most critically, some poorly paid, poorly motivated and poorly managed dweeb will inadvertently (or, if the price is right, deliberately) release the entire contents of the database to the Russian Business Network.

Sun to Acquire Vaau

I’m a little slow on the news front these days, what with having a proper job and all, but I was doing some research on Identity Compliance and headed off the the Vaau website. What did I find? Vaau will shortly be swallowed up by Sun. Sun have made some smart acquisitions in the past, especially Waveset, and this looks like another. I spoke to the Vaau guys at Catalyst and was impressed with their breadth of vision. They didn’t seem to have a strong MIIS/ILM integration story, and I noticed the Sun logo on several of their demos, so I suppose it should have been pretty obvious what was coming. It’s slightly sad to see another small, innovative vendor disappear, but look on the bright side, at least I won’t have to struggle trying to pronounce their bizarre name anymore (vah-ow? vee-oo? vay-ow? vow?)

It will be interesting to see how this influences Microsoft. At the moment RBAC within the Microsoft IAM environment is either provided through AD and associated AD-centric vendors such as Quest and Netpro, or enterprise-wide RBAC is enabled via Omada integrated with MIIS/ILM. As far as I’m aware there will be no additional RBAC support in ILM2, so this situation is likely to continue for a while yet.

IAM Trainwrecks

I was looking through some of my old project documents on the long train journey North from Peterborough to Edinburgh this morning when I came across this – How to Avoid an IAM Trainwreck (.pdf 850kB). It’s an article that I wrote nearly two years ago with the intention of submitting for publication in some magazine or other, but I don’t think we ever actually got around to doing so (probably too busy with real projects). It’s always a difficult thing, looking back at something you used to think was great. Time has a way of making naive stylistic errors and bad grammar stand out, after the blinding effect of initial pride in your work has worn off. But even allowing for a couple of wince-making lines (that any decent sub-editor would probably have caught anyway) it still makes some decent points. It’s quite scary how many of these problems I still seem to run into.

I’d be interested in any feedback from you, and thoughts on your own IAM trainwreck avoidance strategies (always supposing there is actually anyone out there, apart from people googling “lolcat” and ending up here by mistake).

WS-Federation

I’ve been brushing up on WS-Federation again recently and the more I read the more convinced I become that it is the answer. The answer to what, I hear you ask? Everything, that’s what. I’ll have more to say about this soon, but I’m very excited. In the meantime, I suggest you read the white paper at the bottom of this page if you haven’t done so already.

Everything You Know About Identity Management Is Wrong

Jackson Shaw has an interesting post called “Everything You Know About Identity Management Is Wrong”. He didn’t say it, Gartner’s Neil MacDonald said it at a presentation Jackson attended, I think. Anyway, it’s very interesting. I felt compelled to agree on a couple of the points made:

Security-service oriented applications will require security-as-a-service, including identity services.

This was a hot topic at Burton Catalyst Europe and I think it’s inevitable. Application developers shouldn’t have to code identity into their apps, they should just consume it from a central ID service. It already happens when Kerberos-enabled apps consume tokens from AD, why not extend this model across the whole enterprise? What we need is an identity black box that spits out tokens in return for credentials. The tokens get passed to the apps, the apps can read the tokens and everyone is happy.

Overlooking the synergy between middleware and IAM

For sure. Right now I’m looking at a situation where I want to plug MIIS into IBM Websphere MQ. MQ is being used to tie together many legacy applications so getting MIIS to create MQ messages seems a logical next step.