Australia's new Privacy Principles - things to consider

Effective today (12th March 2014), Australia's Information Privacy Principles and National Privacy Principles will be replaced by 13 Australian Privacy Principles (APPs). Here are the important points to note:

• Applies to all organisations that turn over more than $3 million per year and collect personal data.
• Fines up to $1.7 million for breaches.
• Organisations must be transparent about how they collect, use and store personal data.
• Organisations cannot collect data “just in case they need it”.
• If personal data is disclosed to a 3rd party, the organisation disclosing the data is responsible for ensuring the 3rd party understands their obligation and that the consumer knows about the disclosure.

This effectively gives the Office of the Australian Information Commissioner (OAIC) teeth as the fines are now significant when compared to previous legislation. For example, Australian Telecommunications giant Telstra has only been fined a measly $10,200 AUD for their recent violation.

Mindful collection and sharing

The days of "we'll ask for the information in case we need it" are gone. Organisations need to think about what they really need to achieve the task at hand and collect only what they need. As consumers, we should be able to sign up for online services in a shorter amount of time instead of frustratingly getting stuck on a submission form which constantly complains we haven't filled in certain fields.

Marketing programs and processes need to be reviewed to ensure personal data is not being inappropriately shared with 3rd parties. Many companies disregard the flow of information and the lack of visibility & understanding around how this is done, sometimes through no fault of their own. The number of technology integration points involved is challenging, but as privacy is now tied to financial penalties, this is a huge risk to businesses and should be addressed urgently through the involvement of IT departments and potentially external assistance.

If information is justifiably shared outside of the organisation, they will need to have the ability to determine if an overseas 3rd party they are disclosing personal information to also complies with the privacy act. This is a function many organisations will not have and will need to be included as part of their risk management program.

Personal information

In all things privacy-related, things tend to be up for debate, none more so than the term "personal information". The safest way for organisations to tackle this ambiguity is to assume data can be tied together from various sources, even when not immediately obvious as to how, to form context that can be tied to an individual. For example, an IP address is a potential identifier of an individual when combined with information from the relevant Internet service provider.

Personal data can also be stored in unexpected locations that organisations may be unaware of, the most obvious being application logs. IT departments need to perform an internal audit of the information applications use and ensure they are not subject to inadvertent personal data leakage through logs as a result of log file settings.

There is also additional administrative overhead in dealing with personal information and its access. The right technologies and a properly implemented reliance on external information providers can help. For example, power can be given to individuals to have complete control over the information stored about them through self-service portals. In addition, there may not be a need to store certain pieces of information. Standards exist (e.g. pick your favourite federated identity standard) that allow a relying party requiring information about an individual to ask for it from an identity (or attribute) provider and use it in flight without having to store the information on disk.

Beyond the more mature federated identity standards, there are emerging ones such as User Managed Access (UMA) that place more power in the hands of consumers (i.e. the rightful owners of the data). While not yet supported in many technology stacks, the concepts are sound and organisations would do well to adopt the thinking behind what UMA is attempting to achieve in the longer run.

Summary

Australian organisations need to treat personal data like they would financial information. For example, there are a raft of measures dictated by the PCI-DSS standard regarding the storage and usage of credit card numbers. While the number of credit card data breaches have proven PCI-DSS alone does not prevent breaches, existing data protection standards are a good start for organisation struggling to deal with the implications of the new privacy principles. Organisations would do well to adopt many of the same measures dictated by security standards in protecting personal data as a start. As they understand the requirements and data flows over time, more sophisticated security and access management measures can be implemented to round out an evolving security program.

Identity foundation

You wouldn't believe how often I still have to explain Identity & Access Management (IAM) basics to people. Or maybe you do because you feel like a broken record each time you do it. So I created this to help explain it to someone who knows nothing about what comes second nature to those of us in the security game.

Note: This is a GIF so if you're viewing this through something that doesn't render GIF files properly, it's going to look like an absolute mess. Also, unless you have a magnifying glass handy, I suggest clicking on the image for a slightly larger version.

Identity in an agile world

This year, the public presentation I gave more than any other was titled: "Identity in an agile world". I put this together specifically for events in Sydney, Melbourne, Singapore, Kuala Lumpur, Wellington, Auckland, Bangalore, Mumbai, Taiwan and Hong Kong.

The most common question after each event was whether we could provide a recording of the session. The best I could do at the time was to send the slide deck to attendees. The next best thing is what I'm about to do: a blog post in the style of a presentation.

As this is a presentation masquerading as a blog post, it will be different to my usual posts. There are a bunch of images littered throughout, which are all slides from my presentation deck (I've actually omitted a few, but this shouldn't affect the overall content). As a result, you'll see some text as images because they were slides. I've kept it this way instead of typing everything out to give you a better feel for the actual presentation.

Note: This was not intended as a technical presentation. There's some IAM101 in here too, so feel free to skim when required.

---

As enterprise trends go in 2012, Cloud and mobility have dominated the headlines. Almost every survey, study, whitepaper and article you read will talk about the pressure organisations are feeling in trying to deal with the seemingly unmanageable. Of course, the increased sophistication and frequency of attacks adds to the pressure. Top it off with further reduced budgets (which seems to be an issue regardless of the year) and IT departments having to do more with less and you very quickly have everyone in the room collectively shrugging.

If you ask anyone who has had to deal with these pressures, they will tell you that scalability is paramount. If you cannot scale, forget about it. To scale, you need to be agile, not just from a security standpoint, but from an organisational standpoint. IT departments need to be able to integrate and secure new systems quickly and also react to issues, risks and requirements much faster than they are used to. If they don’t, business users will go around them and do things themselves.

The biggest concern facing organisations however, is security. How do you secure something which you do not have full control over? The enterprise perimeter’s been disappearing for some time now, but I think we can all agree that the traditional enterprise perimeter is well and truly gone when Cloud and mobility come into play.

There’s a popular school of thought that says identity is the new perimeter.

That’s one way to look at it, but it's the wrong perspective even though I don't disagree with it from a fundamental standpoint. It's wrong because it means we’re still thinking about perimeters. We must think of identity as a foundation on top of which enterprise security is built. This way, we no longer need to worry about whether there is a perimeter that you can control.

Identity management as a discipline can be very complex. Like most things, I find it easier to simplify. All we’re trying to do is to provide auditable access to protected resources that we can track, regardless of where we’re coming from and what we’re using to access the resources. That’s it.

Before I move on, let’s run through a quick history lesson of the Identity and Access Management (IAM) industry. This is an extremely simplified version so please forgive any omissions.

The last major paradigm shift in computing before this one we are currently experiencing came about as a result of the move towards distributed systems from primarily mainframe environments. With that came a problem with identities being stored in multiple places and having no way to manage them in a practical way.

So we decided to attempt using centralised directories for everything. We said: “hey, let’s just have a single identity store and make everything point there”.

It made sense at the time, but this was not always practical or even feasible. What this did do was reduce the number of identity stores. But we still had the siloed identity issue. To address this, we then decided to use synchronisation tools.

This worked just fine until those troublesome business folks got involved and wanted to wrap process around it. That’s essentially how we got to user provisioning solutions.

Once we had a process-oriented way to move our identities around, we then had to figure out how to control access to resources while hiding the nastiness from our users but maintaining an acceptable level of security. This gave us username/password authentication augmented with second and third factors, single sign-on and access control solutions to all these systems that we needed to use for our jobs.

Here’s a consolidated view of what I’ve just explained; the technical IAM big picture.

This is a very enterprise-centric view of the world. So what happens when you throw in a few new challenges?

Other than Cloud and mobility, we have to deal with audit, governance and compliance requirements and locking down those pesky privileged users that can do anything they want. Ideally, we’d like to re-use what we’ve already implemented. But as I alluded to earlier, we can only use what we already have if the current infrastructure will scale. In addition, we need to think about this a little differently; we need a scalable, agile identity.

We need to wrap our minds around this new-fangled way to think about IAM, but where do we find a scalable identity management system? What is a scalable, agile identity?

Like many other things, we can actually borrow from the real world because that’s where things generally work. We’ve actually had one for many years.

A passport is the primary form of identification for most of us; it is typically the strongest physical identification method we have. It asserts that I’m a citizen of this country.

Whenever I get on a plane...

To get to a different country...

The officers at the airport let me in because they recognise the passport as being genuine (by performing relevant checks)...

And that it has been issued by a Government they trust, in my case Australia.

This is another form of identification.

For most of us, this is our secondary form of identification. It also happens to be the one we use more often. This one says something else about me; that I live in this city.

Both forms of identification state when I was born, but...

They only care that I’m...

and

and

and

Why? Let’s look at an example. This is the Bellagio in Las Vegas.

When I go to a casino in the US, they care that I’m over 21. That’s the condition of entry. But they won’t accept this as proof.

They need this.

Here’s another example. Whenever I want to go to one of these places...

To have one of these...

They don’t care how old I am. In the US, they just care that I’m over 21.

In Australia, they care that I’m over 18.

So...

It's that...

...

...

Identity in the real world is about reputation, context and trust.

Reputation can be made up of multiple things which an entity might store about me, but it also has a lot to do with where I’m from and the demographic I fit into. We've all been unfairly stereotyped before. Unfortunately, this is part of the reputation angle. Decisions can be made based on things that are implied about us no matter how unfair or untrue. Context is all about what I’m trying to do or get access to. Trust is about whether the form of identification I’m using (i.e. my credential) is genuine and issued by a reputable, trusted party in the context of what I’m doing and where I’m doing it.

Once I get past the controls however, I can misuse my legitimate access or in some cases, much worse. Alternatively, someone or something may have stolen my credentials to be able to pose as me. Access control systems have no real way of knowing. That's how many real life crimes and frauds are committed. "Who I am" doesn’t matter. It's not even about the "what I am" anymore. Both of these aspects are irrelevant or useless given the circumstances. With the right access...

To account for this, we need a new dimension on top of identity. We need to track behaviour.

We hear about breaches almost weekly now. There are many others that never get reported. The fact is that they happen all the time.

The key to minimising the fallout if something does happen is the ability to react quickly. You need identity and behavioural analysis to help determine the appropriate steps to take.

If not, you’re sitting there with the knowledge that something bad is happening but powerless to stop it.

In the real world, privacy laws prevent measures from going beyond what we deem to be acceptable, but we’re more or less a surveillance society nowadays. Add our online personas and social networking profiles into the mix and never has it been easier to intrude on someone's privacy.

Take a look at this for a minute (click on the image for the larger version)...

Something like what you see here isn’t completely outside of the realm of possibility. We just need a few technologies to get better (facial recognition being the obvious candidate for improvement) and we’re pretty much here (especially with Google Glasses). Cutting-edge technology aside, let's think about how is this even remotely possible. Give up? It's because...

With an enterprise identity foundation that is scalable, you can absolutely do this from an organisational risk management and threat mitigation standpoint. But how does an enterprise do it? As I've said before, Standards and APIs are key. This needs to work hand-in-hand with portable, embeddable, sharable enterprise credentials (identities).

In the real world, we can't exactly do a lot with regards to the items in red (at least not legally). But all the data within enterprise-owned systems is accessible to allow for this. More on that after this next part.

I've tried to keep technology to a minimum, but I felt the need to at least summarise the most commonly used standards today and their purposes.

I won't explain what each of these are. You're all capable of looking them up. Some of these will evolve to take on other use cases. Some will cease to be relevant. If I had to bet, my money would be on the standards being used in the consumer space making their way into the enterprise, not the other way around.

Now, back to the items in red from the previous slide. Let's talk about the behavioural analysis side of things. I’m going to borrow again from the real world; well, almost real.

This is a screen shot from the World of Warcraft. Apart from the graphics and virtual world, massively multiplayer online role-playing games (MMORPGs) are built on the foundation of identities. Without identities, we don’t have characters. More accurately, we don't have avatars in the game. When we walk through one of these virtual gaming worlds, we have displays that tell us who an avatar is and their relevant attributes. We make decisions very quickly based on the contextual information available whether the avatar is friend or foe; we decide whether to have them join our guild or zap them with weapons we have at our disposal as per this screen shot. Is this so different to what we should be doing when analysing the things going on in our enterprise environments?

If you don't remember a thing I've said (written), please remember this...

The fact that I've managed to spell out "SAVE" is completely coincidental, but hopefully it helps us SAVE it to memory.

Consumerisation of IT - CSO Australia interview

The following is an excerpt from an interview I did with CSO Australia.

The role of the CSO and IT security will need to evolve. Their mindset and the way they work will change. The most fundamental change to be made is to become creative “yes” people instead of instinctive “no” people. That is, instead of constantly saying “no” to business requests because of the perceived risks, the default answer should be “yes” if the request will benefit the company’s bottom line.

Check out the whole interview here.

IBM Dropping Tivoli Brand from IAM Suite

I just read this story on Network World about IBM's plans to make Q1 Labs' Security Information and Event Management (SIEM) product, QRadar SIEM, one of the centrepieces of the newly formed IBM Security Systems division. IBM announced the acquisition of Q1 Labs and the formation of the new Security Systems division in the same press release earlier this month.

The news was a bit pedestrian until I read the following:

"IBM is dropping the 'Tivoli' name from the Identity and Access Management suite"

Of course, I did a double-take. As an ex-Tivoli-ean who went around spruiking the virtues of TIM and TAM, I was taken aback. To quote the great John McEnroe:

"YOU. CANNOT. BE SERIOUS!"

Years of goodwill (alright, and some bad when stuff didn't work the way we promised they would - but we always fixed it) and brand awareness thrown away. It also means people will no longer be able to deliver one of these Tim Tams to the customer as a joke instead of actual Identity & Access Management software.

IBM Identity Manager and IBM Access Manager just don't have the same ring. The resulting acronyms are harder to pronounce, and downright confusing, respectively. IIM and IAM. Go around talking about "IIM" and people will think you missed a word and uttered something random in place of said missing word. Either that or they'll ask if you have something stuck in your throat and whether you'd like some water. Talk about "IAM" and people in security will assume you are talking about "Identity & Access Management", not "IBM Access Manager", which only partially fulfils the "AM" part of the real IAM.

This "IIM" and "IAM" talk presents a decent enough segue to the fact that the acronym for IBM's new Security Systems division is "ISS", as opposed to Internet Security Systems (ISS), whom IBM acquired over 5 years ago and then re-branded IBM Internet Security Systems (IBM ISS). The old ISS (Internet Security Systems) technology is no doubt going to be rolled into the new ISS (IBM Security Systems) along with the IAM (Identity & Access Management, not IBM Access Manager) suite that is no longer Tivoli and the Q1 Labs technology.

At this point, you may want to take a break. Your brain must be hurting from that last paragraph...

And, we're back.

While we're on confusing branding, which IBM is no doubt very good at, I'll take this time to note something else IBM is also very good at: bad product names. IBM recently released an add-on to Tivoli, oops, I mean IBM Identity Manager, called Role and Policy Modeler (RaPM). Gees, IBM. Why didn't you just call it "Role and Policy Enforcement Modeler"? I'll leave it to the reader to work that acronym out.

So, IBM, seriously...WTF?

Alas, it is with some sadness that I must now bid adieu to "TIM TAM" and welcome, rather begrudgingly, "IIM IAM". I just said that out loud. Must. Wash. Mouth. Out.

My first identity and access management project

In a previous post (which I subsequently followed up with another), I mentioned the first Identity and Access Management (IAM) project I worked on. I also said I'd follow that post up with more details about the project I mentioned. It's been some time since I said that, but I've finally gotten around to it.

My very first IAM project was an extremely large one. It was for one of the larger Australian federal government agencies and I can't give specifics (or they'll hunt me down) so forgive me if I'm vague in certain parts.

They needed to re-engineer a core, critical business process from end-to-end. This meant a brand new system needed to be built and it ended up taking years. I personally spent almost 2 years early in my IBM career working on this monster as a consultant in the Security and Privacy practice and when I finished serving my time there (reference to prison completely intentional), they were still rolling out other functionality.

My job was done however, because we had finished laying down the whole security framework and it was working in production. The security system was actually very well architected thanks to the fact that it was designed by a very senior, very experienced, absolutely world class enterprise security architect (hi BP, I'm referring to you if you're reading this - probably not though so one of you other IBMers will have to tell him I said hi). This was actually the key. We could have slotted any equivalent product into the architecture and it would have served its purpose. Of course, being strategically aligned with IBM Tivoli meant this was what we used.

The project used a bunch of IBM software: WebSphere Application Server, MQ Series, DB2, some other IBM software to support EDI transactions (can't remember the names anymore) and of course IBM Tivoli Security software (specifically Tivoli Access Manager for e-business and Tivoli Directory Server). We even had full blown PKI software (from another vendor) to support signing of messages (for authentication purposes) and encryption. At the core of this mish-mash of software wrapped with services (provided by a consortium that was not limited to IBM alone) was Tivoli Access Manager for e-business (TAMeb). And what was its primary use? Fine-grained access management or as some of the market likes to call it today; entitlement management.

That's right, I was responsible for implementing fine-grained access/entitlement management in very first IAM project but I didn't know it at the time. Absolutely everything had to ask TAMeb before it could do anything. Want to show a button on a page? Ask TAMeb. Want to show a field on a page? Ask TAMeb. Want to allow someone to process a particular transaction? Ask TAMeb. Can this application send this message to this other application where the message is marked as secret and does it need to be encrypted as well? Ask TAMeb. No application security decisions were made without first making an authorisation call to TAMeb. None of this stuff involved web access management! Sure, we had to implement the web access management aspects too, but this was not the focus. We put in the web access management bits because it was mandated by the security architecture. But this was by no means a web access management project.

From an ease of development, time, manageability and subsequently cost standpoint, having all access control decisions managed centrally made perfect sense. I'm pretty sure everyone on that project would agree with me on this point. Here are a few reasons why they liked having a central access management point:

• All teams could adhere to the same interface contracts when it came to authentication and authorisation. This also meant that if a development team couldn't get a security component working and everyone else could, it was their fault and usually could get it fixed fairly quickly because others knew how to do it properly.
• No one had to write their own security sub-system because it was already sitting there waiting to be used and it worked extremely well. This meant they could spend time worrying about the more interesting things like business logic. I have yet to find a developer who likes writing security code (unless they are building a security product and even then it's debatable whether they actually like what they are doing) because it's simply a hurdle to getting the "real work" done.
• Teams could re-use existing policies if required because they were mostly modelled on a business requirement.
• No need to worry about policy modelling or management of security policies.
• If a policy changed, it would be reflected across all systems. Without a central store, they would each need to worry about how to synchronise their policies so that there weren't any back doors to exploit. This alone is a whole sub-project on its own.
• Security within each system was distilled down to a single statement: "Ask TAMeb". Compare this with having to worry about designing and building a security sub-system, designing and building a way to model identities, roles, policies, resources within the sub-system, designing and building a management layer on top of the sub-system and then worrying about how to ask the sub-system to make decisions from the main application. I'm talking best case scenario here of course because quite often, development teams simply use configuration files which are completely unmanageable (if you've ever written a Java Enterprise application and played with crappy deployment descriptors, you know what I mean). And if you understand the implications of using config files, you'll know that each time a security change is made you have to restart the application (which is going to screw with your SLAs) unless your vendor has some fancy way of dynamically updating in-memory application configuration settings. Oh, I haven't yet thought about how to synchronise security policies with the other systems floating around. Manually you say? Or use a provisioning product? Yeah it's possible. But it also means a heck of a lot more design and analysis work (in the case of the provisioning product). If you want to do it all manually, you can expect to have very frequent security incidents and lots of follow-up meetings with management to explain why it happened.
  

One of the biggest challenges was the huge number of transactions (and as a result, access control decisions) passing through the system due to the sheer size of the project. And to the credit of TAMeb, it scaled well and did the job. Of course, we had to do proper capacity planning and implemented multiple enforcement and decision points (PEPs and PDPs in the XACML world). And the Policy Administration Point (PAP)? This was a combination of the TAM administration console and an application we had to build to perform "identity management". Why did we have to build this? Because IBM hadn't acquired Access360 yet (which became Tivoli Identity Manager) and the existing IBM provisioning product was a piece of crap called Tivoli Identity Director which still relied on the Tivoli Framework (those with experience playing with the old framework know it's EXTREMELY painful).

I should explain why we had to build an "identity management" component on top of TAM. One major criticism of TAM when it comes to fine-grained access management is that it's not very good when you need to add a bit of context that relies on user attributes because:

1. The admin console doesn't give you access to them (last time I checked). To play around with user attributes, you either need to access the LDAP directly or use a provisioning product like Tivoli Identity Manager.
2. Contextual access control decisions based on user attributes are also not the easiest to model without a provisioning product to help. In short, you need to do it based on dynamic role memberships and have policies on resources (or entitlements) tied to these roles. Provisioning products can do this (cater for dynamic roles based on user attributes) out of the box and provision the required changes to the access management product in near real time.

In other words, we had to build the "identity management" piece to allow for contextual access control decisions based on user attributes. Nowadays of course, you can just use your favourite provisioning product.

The glaring omission from the picture is of course XACML. It wasn't even part of the IAM vocabulary at the time and the lack of XACML support in the project makes it very difficult for the government agency to swap TAMeb out of the picture (which IBM definitely isn't complaining about). But I'm guessing it's not a big deal for them because they spent a few million shed-loads worth of tax-payer's dollars to build this system and it works as designed. They're not about to replace the critical security component that makes all the decisions!

The motivation behind my occasional rants about the term "entitlement management" and how it's all too often used as a marketing gimmick to sell more products stems from my time on this project.

Broken record time: call your vendor out if they're blatantly repackaging fine-grained access management as "shiny-new-entitlement-management". If it's more along the lines of what the Burton Group thinks it should mean, we might start to get somewhere. It's still a moving target however, so I'm sure the definition will expand and evolve, especially with all this Cloud crap floating around.

Spinning entitlements

A few of us (e.g. me, Nishant Kaushik, Matt Flynn, Paul Madsen, Ian Glazer) have been lamenting the negative effect Twitter has had on our blogging frequency. As a result, we've also had a lack of discussion via our blogs. But Twitter discussions can only go so far.

As such, my previous post about entitlement management was intended to stir the pot a little bit (which is why I posted the "equation" as a hypothesis) and also bring to the surface one of my pet peeves with how some vendors position entitlement management.

I wanted to achieve 2 things:

1. Point out what you're actually getting if you buy an entitlement management product from an access management vendor.
2. If we MUST use the term "entitlement management", we should at least have a good reason for doing so instead of using it to sell more products by re-branding an old concept.
   

I purposely focused only on the authorisation/access management side of things to serve the first part of the agenda. That is, if we look at the entitlement management products from access management vendors today, the hypothesis that entitlement management = fine-grained access management + XACML holds. In other words, that's all you are buying.

The second point required discussion so I conveniently ignored everything else that I've heard people refer to as "entitlement management". The most common example is in relation to IT Governance, Risk and Compliance (GRC), specifically identity compliance and attestation-type activities. I don't typically refer to this as "entitlement management", but others do.

These are the 2 obvious sides to the entitlement management coin, but there are others that could conceivably pop-up. For example, Eve Maler brings up the possibility that Vendor Relationship Management her ProtectServe/"relationship management" proposal could potentially be thought of as "Enterprise 2.0 entitlement management" (update: Eve clarified that she meant ProtectServe rather than VRM via the comments to this post).

It's clear that the term "entitlement management" means different things to different people. It's a bit like the spinning lady illusion (where depending on how you focus, you see it spinning in one direction while others see it spinning the opposite way). In our case, some might not think we're even looking at a lady's silhouette. I don't like things to be complex (which makes people wonder why I chose this line of work). But it's also for this reason that I don't like the term "entitlement management". It confuses the heck out of everyone!

I received a few email responses. There were also a couple of opinions on Twitter, a few more in the comments to my post (which I responded to there) and a handful of blog responses (Nishant, Ian Glazer and Dave Kearns). Some agreed, others partially and some not at all.

Before I move on, I should clear something up. Paul Toal (from Oracle) comments:

"I think you are making a huge assumption that entitlements management is only related to the web access layer".

I'm not. And that is part of the problem with calling all these access management products "web access management" products. It makes everyone assume that's all these products do. And that was part of my point; that they can do so much more. Simply calling them "web access management" products does their capabilities an injustice (although some have less fine-grained access management capabilities than others). I should be able to add a little more context when I write about my first Identity and Access Management project (as promised in my previous post) but I won't talk about this "web access management" generalisation today because we'll lose focus.

In reading through the opinions of others, I noticed one thing in general; most toed the company line, which was not unexpected:

• People from Sun more or less agreed (probably because I said I liked how they are approaching it with OpenSSO).
• People from Oracle tended to use fine-grained access management as a baseline and expanded on it to include centralisation across all platforms with a common enterprise services view on everything.
• Consultants didn't like having a new term to define something they've been doing for a long time and find it difficult to explain it to customers without confusing them.
• Those who have been around and know security but don't have as much of a vested interest in "entitlement management" like to take a more pragmatic approach in trying to segment the definitions into manageable portions that make sense while not discounting the term altogether.
  
• Some of the more sales-oriented folk who don't have to sell a so-called "entitlement management" product didn't like having to explain the term because it distracts customers. Either that or they worry about the need to "shoe-horn" their product/s into the "entitlement management" hype if that's all they hear about when doing sales calls.
  

I more or less agree with what Nishant says in his blog post, but not Oracle's strategy in having 2 separate products. Then again, Oracle Entitlements Server was brought on board via their acquisition of BEA so I can understand why they chose to keep it separate. It probably didn't make much financial sense to try to roll one product into the other. In their case, cash won out over idealism.

Ian Glazer has 4 problems with my hypothesis/definition. I'll address each here:

1. "Definitions that include a protocol are worrisome as they can overly restrict the definition" - He has a point. I should probably have said "an authorisation/access management policy standard". But in reality, my view is that it'll be XACML or some evolution of it. So if we wanted to make an academic definition, then we should probably not say "XACML". I'm not a fan of academic definitions though, otherwise I would have accepted the PhD offer from my university professor instead of joining IBM.
2. "I fear this definition is a reflection of products in the market today and not a statement on what “entitlement management” is meant to do" - Bingo! Ian Glazer's just summed up a lot of what I'm getting at. I DID define it as per what the access management vendors think it should mean. Whether this is what it should mean is up for debate.
   
3. "There is something missing from the definition – the policy enforcement point" - True, if you think the definition should include the terms: policy administration point (PAP), policy decision point (PDP) and policy enforcement point (PEP). Then again, I didn't have PAP or PDP in the hypothesis either. It comes down to whether one thinks that access management products as they exists today have PAPs, PDPs and PEPs. Even so, I personally think they should be in the finer details and not the definition. As an aside, access management products with fine-grained authorisation capabilities do have some PEPs. But PEPs are a little bit like connectors in provisioning products; one size does not fit all. There's usually some work that needs to be done to build a PEP that works for whatever system you are hooking into the access management product. The obvious exception here is the web reverse proxy component in access management products because they can assume a standard protocol is in place for web-based interactions. Of course, the web reverse proxy does coarse-grained access management (aka "web access management") by many common definitions. But now I'm just confusing the matter so I'll stop :-)
   
4. "I have a problem with the phrase “entitlement management”...enterprises do not use the phrase “entitlement management” the same way we do" - It's because the vendors have managed to confuse customers. On one hand, we have the "entitlement management" that vendors use to describe run-time authorisation (which I've been referring to as access management). On the other hand, we have vendors that talk about certain aspects of IT GRC as being "entitlement management". Based on what Ian Glazer is saying, the companies he's talked to see it more from an IT GRC (or operational) perspective.
   

Ian Glazer goes on to say:

"Using a single term (“entitlement management”) to span both the run-time authorization decisions as well as the necessary legwork of gathering, interpreting, and cleansing entitlements can lead to confusion."

Yeah, tell me about it. Unfortunately, this is what we have today. It's an overloaded term which has already lead to confusion. At this point however, I'm unsure what Ian Glazer's position on the whole matter is. On one hand, he's helping round out the entitlement management definition from an access management (or run-time authorisation as he puts it) standpoint but on the other hand alluding to the fact that including this aspect in the overall definition can lead to confusion.

Dave Kearns doesn't agree with the hypothesis either. He also says he doesn't quite agree with Ian Glazer but I think he's actually disagreeing with Burton Group's perception of how enterprises define entitlement management. As I said, I'm not quite sure how Burton Group wants to define it. No matter. At least it prompted an opinion from Dave. But he goes on to say that he thinks entitlements should be tied to roles, not individuals:

"Differentiate entitlement management from access management, also (else, why use both terms?). Individuals get access, roles/groups get entitlements. Access is granted to resources (hardware, applications, services, etc.) while entitlements specify what a particular role/group can do with or within that resource."

If I were to simplify this, I would interpret it as saying access and entitlements are more or less the same thing but with intricate, important differences in terms of how you look at it. You use one term for individuals and the other term for roles. I do agree with Dave from a conceptual point of view, but I don't see the need to differentiate individuals and roles here because we're getting very close to implementation specifics if we do and are in danger of adding to the confusion.

Neil Readshaw, an ex-colleague of mine from IBM and a worldwide authority on Tivoli Security products says (via a comment in response to my previous post):

"I try to talk about authorization when taking a resource centric view (e.g. who can do something), and entitlements for a user centric view (e.g. what can this user do). In the end, it may be the same data making both of those determinations."

Neil and Dave are talking about pretty much the same thing but I prefer Neil's version because it takes a higher-level approach and avoids specifics like mappings between individuals, roles and resources. Neil's statement about "the same data making both of those determinations" however, begs the question: why do we need a separate product to do entitlement management?

I did find this statement by Ian Glazer interesting though:

"A bit of history – three or so years ago Burton Group, at a Catalyst, introduced the phrase “entitlement management” to include the run-time authorization decision process that most of the industry referred to as “fine-grained authorization.” At the time, this seemed about right. Flash forward to this year and our latest research and we have learned that our definition was too narrow."

The automatic assumption would be to blame Burton Group for this mess. But if you think about it, it's not really their fault. It's the fault of all the vendors for jumping on the bandwagon and hyping it to the point it's now out of control and we find ourselves having to come to terms with some sort of definition so we can see through the entitlement fog.

Burton Group's views seem to have evolved and the vendors are stuck with a definition a couple of years old. My objection all along has been to vendors jumping on the bandwagon and trying to convince everyone that it's such a "must have", new concept to the point where customers need to buy their new "entitlement management" product before understanding what it really means. Worse still, a few went out and built brand new products and slapped the name "entitlement manager" (or a variant) on it. Would it not have made more sense to allow their access management products to evolve naturally with business needs and keep calling them "access management solutions"? Why did they have to go and confuse the matter and in the process force customers to support separate data and policy stores for products with a lot of overlapping capabilities?

If we must have the term "entitlement management" hanging around in the lingo, we need to re-adjust our understanding of what it means. Once this is done, perhaps the vendors will rename/re-think their "entitlement management" products or roll them into their access management offerings like they should have done in the first place. Analysts like Ian Glazer should be able to help the market define this because they talk to companies about what they are actually doing. My objection isn't with the industry as a whole for talking about entitlement management. It's out in the wild now and nothing any of us can do will put the entitlement genie back in the bottle. But we shouldn't be re-branding an old concept just to sell more products.

If this discussion doesn't get us closer to a good definition, I'd like at least one thing to happen. If you are looking at an entitlement management product, please take a step back to understand what it is you actually want. You might already have the tools to do it. If not, make sure you're buying the right tool for the right reason. Not just because the vendor tells you it's their "entitlement management" product and you MUST have it because you are looking at user entitlements in your environment.

The entitlement and access management equation

Hopefully I'm not having a "mad-scientist moment"...

Hypothesis:
Web access management = Coarse-grained access management
Entitlement management = Fine-grained access management + XACML

Argument:
I've always poo poo-ed the whole notion of entitlement management and even blogged about it some time ago (Daniel Raskin from Sun had similar thoughts). It's not because I don't think it's necessary; quite the contrary.

Good access management is crucial within any enterprise security architecture. It doesn't need to be the first thing you implement, but it should be pretty darned high on the list. It saves time and money in the long run and makes things so much easier to design, build and manage. Not to mention when the audit and compliance people come knocking, a lot of the information is available from a central location (I didn't say "all the information" because it's wishful thinking that any organisation can get every system's access controls centrally managed).

Notice something? I said access management, because that's all entitlement management really is; fine-grained access management. The main reason I've never particularly been taken by the whole notion of entitlement management was because I didn't agree with the industry's need to tag it as such. As far as I was concerned, it was just access management (or authorisation as some prefer to say). There was no need for a new name because we've all been doing access control for a long time right? Apparently not. The marketing machines started spinning not so long ago and all of a sudden, it's "New School Identity Management" (note: you may have to register to read the article).

The marketing people would have us believe that before entitlement management products came along, all the industry was capable of doing was web access management. That is, URL-level access controls. And if we needed to have finer-grained access controls, we would just throw our hands up and say "nup, product doesn't do that and we'll have to write our own or just ignore it". As Guy Kawasaki would say, this is BULL-SHIITAKE! Or perhaps I joined the Identity and Access Management (IAM) world with rose-coloured glasses.

Early on in my stint at IBM, I worked for the Security and Privacy Services team. My very first Identity and Access Management (IAM) project was actually entitlement management focused with some aspects around web access management. At the time, the term "entitlement management" didn't exist the way it does today. As far as we were concerned, we were implementing access management; both coarse and fine-grained. And it was on this project that I first got my hands VERY dirty with Tivoli Access Manager for e-business (TAM) and Tivoli Directory Server (TDS). I'll talk more about this in a follow-up blog post or this will get too long and you'll all fall asleep.

I've had a few more opportunities to work with TAM (and all the other IBM Tivoli Security products) and it is because of my various experiences with the products that I haven't stopped wondering why companies like IBM bothered to build a completely brand new product to handle entitlement management (in IBM's case they now have Tivoli Security Policy Manager). TAM does have a few potential issues when it comes to entitlement management as we know it today. For example:

1. If you need to model contextual policies that rely on user attributes and getting your hands dirty scares you, then you'll find it a little bit challenging.
2. It doesn't have standard support for eXtensible Access Control Markup Language (XACML) out of the box.
3. It doesn't have a nice, standardised web services layer for other applications to integrate with (it does however, have APIs but these aren't typically what we would call "services").
   

That said, TAM did have a XACML toolkit which (update: Neil Readshaw, one of my ex-colleagues at IBM and a worldwide authority on TAM assures me there was never any XACML support in TAM whatsoever. I must have been drinking too much of the kool-aid when I worked for IBM Tivoli) I'm sure product management and development could have rolled XACML support into the core product. They could also have very easily opened up the console (or even built a whole new one that was easier to use) to allow for easier administration of contextual access policies and even expanded on the policy model to do more fancy things (alternatively you can use a provisioning product to fill in the gaps). As for web services, that isn't too difficult to build into TAM. They built a whole federated identity management product on top of it. Why not an entitlement management one?

I've seen Tivoli Security Policy Manager (TSPM) in action and it doesn't add very much on top of what TAM already does (and has been doing for years). And now, customers have to manage 2 separate policy stores for 2 products that do very similar things! You heard me right; TAM and TSPM have different policy stores and management interfaces. I realise I'm picking on IBM yet again, but this is true of many vendors that have separate web access management and entitlement management products.

So why the sudden emergence of entitlement management when I insist it's been there all along? If you followed the link back to my earlier rants about entitlement management, you may have noticed I had a rather involved public conversation with Securent's (now owned by Cisco) CEO Rajiv Gupta. Upon reading the discussion again, we seemed to be debating entitlement management vs fine-grained authorisation based on different definitions, assumptions and agendas.

This suggests that what fine-grained authorisation lacked was a standard way to define everything; enter XACML. If we could talk about everything using common terms, an understanding of where everything fit and what a policy looks like, then we might get somewhere. The same goes for systems: there needed to be a way for them to leverage authorisation services in a standarised way. So I put forward that entitlement management is simply fine-grained authorisation + XACML. Standardisation and interoperability were the missing ingredients in taking fine-grained authorisation mainstream. Perhaps another ingredient was that many companies weren't ready to worry about fine-grained authorisation yet as they were still busy with provisioning and coarse-grained authorisation (i.e. web access management).

I'll finish with the following points:

1. If you can't tell, I like TAM (but I'm biased because I cut my IAM teeth using it).
   
2. If you have a web access management product, make an effort to sit down and evaluate whether you REALLY need an entitlement management product. If you also have a provisioning product on top of your web access management product, then you REALLY need to think about whether you REALLY need an entitlement management product. Is XACML support a good enough reason to buy a whole new product? Do you really need XACML at this stage of your project? Can you talk the vendor into building XACML support into their web access management product?
   
3. I like Sun's approach of rolling fine-grained access control/entitlement management capabilities into their core web access management product (note: unfortunately, I have a feeling Oracle will throw OpenSSO aside in favour of their existing products - which I should point out are 2 separate products).

Is Centrify DirectAuthorize one of a kind?

I'm sure many of you read Dave Kearn's NetworkWorld Identity Management Newsletter. I certainly do and noticed something buried near the end of his most recent edition regarding Centrify's DirectAuthorize product:

"The new product centrally manages and enforces role-based entitlements for fine grained control of user access and privileges on Unix and Linux systems. If your organization has a mix of operating systems you need a product like this. And the “jungle drums” (Tom – Tom, get it? OK, you can groan now) assure me that this is the only product “like this”."

The "only product like this" comment jumped out at me because I'm wondering what Centrify actually means. If they are implying that it is the only product on the market that does fine-grained access management for Unix and Linux systems and is hooked into some sort of centralised Identity Management infrastructure, they need to do a bit more research because I can point to at least 2 products that can do the same thing:

• IBM Tivoli Access Manager for Operating Systems
• CA Access Control
  

If on the other hand, they simply mean that they have a nicer interface that is easier to use and tighter coupling with Active Directory then they have a very good point.

A blog post where I mention IBM and don't take some sort of "pot shot" at them would be incomplete. So I'll say this: If IBM ever decides to design user interfaces where the user doesn't scream "owwww my eyes" when they look at it, they might actually sell more software.

Update: Dave's left a comment in response to this post that clarifies things slightly. I'm still not 100% sure what "like this" means. However, I'm sure someone from Centrify could explain it in detail and sing about the benefits around how DirectAuthorize does whatever "like this" means.

Part 2 of my conversation with Amit Jasuja from Oracle

I mentioned yesterday that I spoke with Amit Jasuja, Oracle's Vice President of Development for their Identity Management Product Suite. This is the follow up post to part 1, which focused on Oracle Adaptive Access Manager (OAAM). In this post, I'll cover some of the other things we discussed.

It's probably a good idea to point out that we discussed some roadmap items and even though Amit didn't remind me that items on a roadmap are not guarantees that functionality will make it into the planned release, I'll do Oracle the favour of mentioning it on their behalf. I used to have to do this all the time so I'm aware of the drill :-)

Apart from discussing OAAM, I revisited some of the questions I asked Oracle President Charles Phillips when I met him earlier this year (because Charles didn't really answer them completely) and Amit obliged.

Essentially, part of the strategy for Oracle's overall software stack (particularly Fusion Middleware) is to have everything be "hot pluggable" with their Identity Management suite. But let me take a step back for a moment. Like many other large vendors out there, Oracle's been pushing an open strategy around Service-Oriented Architectures (SOA) and the fact that all their products will eventually support the ability to leverage (and underpin) an enterprise service bus (or whatever buzzword you feel like using). One of the main benefits in doing so is to allow for a vendor agnostic architecture where organisations aren't "locked in" to specific products (note that the industry is a long way from this being a reality despite all the hype). There are other benefits but that's a topic for another day.

The organisations arguably making the most noise around SOA are IBM and Oracle. But Oracle is making more noise (and it seems progress) around the notion of Enterprise Identity Services (Nishant Kaushik in particular seems to be spending lots of time on this) and Amit was quick to point out that the Identity Management group will be keeping with the strategy of openness while being mindful of having to show the value Oracle's products can provide over their competitors. In short, most of Oracle's software will eventually be built to support the use of SOA-like interfaces thus allowing for interoperability with competitive solutions (assuming the likes of IBM, CA, Sun and Novell build products that support the relevant standards for the relevant use cases). It will then be up to Oracle to convince organisations that even though they could use a competitor's product, Oracle's Identity and Access Management suite is the best option because of additional benefits. Amit mentioned some examples like certified support for the Identity Governance Framework (which I should point out was originally an Oracle initiative but has since been submitted to the Liberty Alliance to carry forward) and perhaps things like "quick start" initiatives with pre-built policies for use with Oracle software.

It's great to see Oracle's strategy is to make all their software "play nice together" while being open at the same time. In reality however, the sales teams will sell whatever combination of products that will fit into a customer's budget. If they have to drop products out of the solution proposal to bring it under budget, they will. It's just how the sales teams work, especially if their numbers aren't 100% tied in to Oracle Identity and Access Management software sales :-)

We also briefly touched on various pieces of the Identity and Access Management suite being "pre-baked" into other Oracle software products (e.g. there's a lot of work being done to embed Oracle Virtual Directory within other products) before moving on to exploring Oracle's relatively new Entitlements Server (OES), itself a prime candidate for being embedded within other products. I didn't want to focus on functionality because I already knew about it at a high level. I was more interested in where Oracle's headed with the product from a strategic standpoint.

The obvious direction is to have OES be the fine-grained authorisation engine for just about everything, but Oracle's software stack is HUGE. In other words, it's not an easy task (even if they go with the SOA approach) and I don't think it's going to happen very quickly. Knowing this, I shifted the focus purely to the Identity and Access Management products and their use of OES to externalise authorisation. The answer: yes, but not yet. I used Oracle Identity Manager (OIM) as an example and Amit told me that the plan is to allow for the externalisation of OIM authorisation policies to OES in the next release (e.g. delegated administration settings). He did note that OIM can already provision to OES out of the box (I would have been VERY surprised if that wasn't the case).

Finally, we moved on to speaking briefly about Governance, Risk and Compliance (GRC) that controversial "catch all" three letter acronym. I wanted to know Oracle's plans around identity-centric GRC. If you aren't familiar with the whole GRC thing, I've written about it in the past so have a quick read and then come back.

As it stands today, Oracle's GRC product is much more focused on the financial and enterprise governance (and compliance) aspects and is hooked into their Finance, ERP and CRM applications. In terms of Identity Management and compliance however, we tend to hear a lot more about identity and user account focused access controls, attestation and segregation of duties (SoD). The products in this area receiving the most press of late are SailPoint's IdentityIQ and Aveksa's Compliance Manager.

Oracle's GRC product doesn't actually compete in the identity-centric GRC area (at least not directly). But in light of Sun's very recent launch of its Identity Compliance Manager and Novell's entry into this space through their Access Governance Suite (which is actually Aveksa re-branded via an OEM agreement), I wanted to know if Oracle had any plans to expand their GRC offering to address identity-centric compliance.

Amit's answer was that Oracle does in fact have plans to do this and they are looking at expanding the capabilities of the existing GRC product instead of building a brand new one. This essentially means that the GRC product will get additional features and hooks into the Identity and Access Management suite and vice versa. This includes things like building on the existing attestation capabilities of OIM and supporting the ability to deal with SoD policies through mining existing user entitlements and also using preventative measures (like CA will have once they finish integrating the features of the recently acquired IDFocus product).

Despite Amit almost calling me a journalist on the call, I'm far from one. What I'm trying to say is that I didn't really take any notes. I just spoke to him about a topic I find very interesting and now I'm writing about it. Hence if any of you in the Oracle community (Nishant? Clayton? Mark? Anyone else?) want to confirm, deny, correct or add to any of this (or part 1) feel free to do so via the comments. If not, we'll all just take everything I've said as fact and hold product management to my claims :-)

Ultimately, talking about plans which make a lot of sense means very little other than to communicate intentions. They key will be how Oracle executes and how quickly they do it. Otherwise, they might as well be telling us they want to put a guy on Jupiter.