2010 The Year of Entitlements
By Sean ONeill on Jan 14, 2010
Welcome back from the holidays.
Been busy around here with getting ready to join Oracle (granted, its an acquisition, but in the end, I can choose to accept a position, if offered). Oh, and lets get the 2010 thing out of the way (its twenty-ten, just like nineteen sixty three, not twenty-ought-ten). And remember back in 1984? This was the year Arthur C. Clarke said we would make contact. Let me know how that works out for you.
So were do we stand looking forward to the new year? That's been a focus of mine recently and quite a few others out there. Central repositories - been there, upgraded that. Access Management - transitional year as it takes on more significance, but not the big mover this year. Provisioning - deployed, upgraded, and looking to reach deeper into the organization (more on this in a future blog). Role Management - good stuff, good market, and tools maturing.
My personal focus is on entitlements this year. Its their time. To date, all identity projects really have eventually dealt with entitlements - who has access to what and what can they do with it. But we never have really gotten down to where the "rubber meets the road". The actual security attributes on a resource (files, dbs, ports, devices, sockets, pipes, queues, applications, etc.) can be many and numerous.
Accounts have entitlements and roles are a way of grouping accounts and entitlements into a more manageable form. Accounts and roles have full life cycle management. They are defined, approved, deployed, certified, and retired. As such,we have been managing entitlements all along. But now, specific life cycle management of the entitlements themselves is being asked for. For example, the specific entitlement "transfer up to $100K to a vendor" will need to be identified as critical to the organization, will need an owner, will need to have a regular certification cycles, and will need to be fully life cycled. Not the account, not the role, but the entitlement specifically.
So how big is this elephant?
Take Solaris' file system. Many think there are four entitlements to the file (read, write, execute, denied). But they are combined into eight permissions (No permissions, execute only, write only, write/execute, read only, read/write, read/execute, read/write/execute). And these permissions are grouped into three permission sets based on who is trying to access the file - owner, group, and other. This leads to actually:
8 owner X 8 group X 8 other = 512 permission possibilities on file
Now add the fact the file resides somewhere inside a directory that has its own set of permissions:
512 file permissions X 512 directory permissions = 262,144 permission combinations
So every file has over a quarter of a million ways of securing access to it. Granted having full permissions to a file in a directory that has no permissions is a little self defeating (actually, it is meant to defeat unauthorized access), you get the idea of how quickly entitlements management can get out of hand.
Add to that ERP GRC, SOA web services entitlement, and the need to expand identity to virtual and federated resources and you may start to understand the gravity of the situation.
So, we are going to start this year focusing on entitlement management in the next few blogs, if for no other reason to scare the pants off of anyone who currently works in the identity field.
Be seeing you.