Thanks to Anil John's tweets, I've been alerted to National Institute of Standards and Technology (NIST) workshop on Access Management. Having worked for DARPA a long time ago in a land far away, I am not afraid of terms such as Plenary Session or Hotwash,they make any proceeding seem important and rife with danger. Someone abused their access privileges or shared a password? Call the NSA to erase him. (Let's see if there are going to be any information security incidents after that..)

I know that some are not aware that NIST does good work in the information security realm. Among other things, they publish a series of documents called Special Publications (800 series) that cover many basic and not so basic security topics. While not particularly groundbreaking, they're thorough and vendor neutral and can serve as a good overview of technologies or approaches for just about any information security initiative. Unfortunately, the technology landscape evolves at a fast clip and there's a fair amount of dated material, ranging from slightly dated to ancient. Caveat emptor.

What I found interesting is a presentation by NIST's David Ferraiolo that talks about a universal Policy Machine or, to be more exact, a universal access control stack that can slice, dice and cook you breakfast. As the presentation notes, the main problem with access control today is very simple - the implementation is nothing like the policy. In other words, the policy might be a complex document with legal nuances but by the time the requirements filter down from the original policy document through the business to IT to implementation to delivered result, you might as well have asked for a submarine with nuclear warheads and instead gotten a toy hammer. The presentation refers to this transformation as "dismal state of affairs". (Something is rotten in the state of Denmark!) The reasons for the policy/implementation gap are many; the author cites lack of interoperability (i.e. a challenge in having application X and device Y and operating system Z all getting their "direction" from one central decision point) in heterogeneous environments as one key problem.

Furthermore, access control as defined in the paper is broader than just access to resources. It includes unauthorized dissemination of information, e.g. via a copy and paste into email and other out-of-band actions involving endpoints such as flash drives. From the author's perspective, access control should encompass the entire computing stack and then some - OS, devices, applications and data. To this end, the author proposes a universal Policy Machine that has "just enough" expressiveness in the "language" used to implement attribute-based rules so that this Policy Machine can become that one decision point all applications, devices and operating systems will use for access control. Reading this I had a science fiction flashback and my brain came up with this as a visual representation of a Policy Machine (hint: it zaps you)

The presentation closes with a promise of a working prototype of a Policy Machine that covers files and Open Office suite of apps, including copy and paste. In my next blog I will attempt to build the Policy Machine from stock parts, similar to what Jonathan Godwin (my personal hero) does with car engines.

...but perhaps it should be. A properly fortified island with double moats, crocodiles (or cheerleaders), molten lead showers, Spartan warriors and of course artillery straight from Guns of Navarone . (I don't know why you need artillery if you have crocodiles but I wanted to add it just in case. As the ancient Finnish proverb says, "backups never hurt").

In many an enterprise you'll find a network architecture where a lot of effort has been spent on protecting the perimeter, separating nice, shiny, internal TCP packets from mean, dirty and virus-laden external packets. (UDP packets are always lost and confused, no need to filter them out). As Gunnar Peterson writes in his "There Are No Firewalls" blog entry, imagine that there's no firewall separating inside from the outside. What would be the potential damage to the business assets previously thought safe? This is an excellent Gedankenexperiment for any enterprise architect but it's particularly interesting to examine in the identity and access context.

Firewalls are breached because the attacks evolve faster than perimeter security products. Even if the product has adequate protection against some very sophisticated threat, it's far from certain that it's configured and installed (and patched!) correctly to contain the threat. Thus, the conservative assumption is to assume that the firewall doesn't exist. Once the perimeter curtain drops, it can be quickly shown that identity and access management infrastructure can make a large difference in both keeping the bad guys at bay and at creating value by enabling collaboration between customers, partners and the company at the center.

If the application owners assume that they're all inside a fortress, the applications typically have an anemic authentication and authorization model. At best, authentication relies on a single factor, usually a username/password combo. At worst, there's no authentication and it's either derived from the fact that you're on the internal network with your credentials lifted from the desktop or the application doesn't even bother to authenticate you. The latter is common for content-based apps (hey, wer're on Intranet, whee).

Authentication is a binary state - you're either in or you're out. Authorization, on the other hand, is a much more fluid phenomena. You can be inside the fortress walls, even inside the building because the front door was poorly locked but you won't be able to do much after that if you need 50 different keys (privileges, permissions, broadly - entitlements) to open one more door leading to treasure. The role of entitlements and their place in an authorization model suddenly becomes crucial to reflecting the attack. Deploy adaptive access control on the front-end where transactions as benign as a page retrieval or a form submittal could be considered in a real-time risk score and deploy fine-grained entitlement attestation on the back-end to catch deviations and you've got a credible defense mechanism. (If you open the gates to the world and remove the firewall, what do you do about dirty packets, be they viruses or denial of service attacks? Gartner's Neil MacDonald says you virtualize and proxy everything).

Fortifying each app is expensive so why do it? Think about the parties you do business with, typically your customers and your partners. Your large customers and most valued partners will want to participate in your business processes, be they sales, order fulfillment, distrubution or garbage collection. How do you let them into your shop? Easy solution - require them to play nice with your perimeter, e.g. require them to use VPN or secure tunnel. Harder solution - deploy an app, usually a web app (e.g. a portal) that exposes relevant chunks of a business process. Hardest solution - don't do anything, your CRM, ERP, SFA and other apps already have your business processes implemented on top of them. All you need is for the process to extend beyond the perimeter, easy and secure collaboration. Why waste money on building yet another app or reinventing the wheel by changing the current process when you can take a few important apps, make them into islands and open the gates.

The popularity of entitlements, both as a noun and as a thing, is rapidly growing in the IDM world. Before entitlements became an oratorio impossible to ignore even with the best Jedi mind tricks, there was a flutter of butterfly wings. That is, 2-3 people in a hallway at a conference started whispering entitlements,entitlements,entitlements . Then came presentations, then whitepapers from analysts and vendors and finally the Market noticed that, wait, what about entitlements? The chaos theory refers to the initial whisper event as a butterfly effect, there's no other explanation for their sudden rise to fame. I mean, it's not like they didn't exist, they were just invisible to the human..err...auditors' eye. Hail Eris!

Much to the delight of those semantically inclined, the definition of the noun entitlement has proved hard to nail down in the identity and access management context. While we were feeling smug and entitled, we've written a blog post on the subject along with a whitepaper (registration required) that talked about the challenges of managing entitlements throughout their lifecycle. Let's see some popular definitions of entitlements:

From our perspective, it doesn't really matter that the entitlement is granted to an account, a user, an application (yes, applications have entitlements too!) or some combination thereof. The act of granting and the subsequent association between an entitlement and its subject (owner) is not relevant to the definition of entitlement. Webster is closest to what we feel is the best definition. Let's consider an example somewhat divorced from technology.

In a mythical company Ourbont (pronounced oooor-BON, yes it's French) there are monthly management meetings. Everyone who manages other people is invited to the management meeting. The security guard at the door personally knows the managers (it's a small company) and on the basis of, well, your persona, does or does not let you into the meeting. You could say that being a people's manager is an entitlement. It was something that was made into 'law' by the contract between the employee and the company at the time of hire. You could also say that being able to attend management meetings is an entitlement, perhaps a derived one, since it follows from one being a people's manager. The latter entitlement exists due to company policy which (loosely speaking) is a form of law/contract.

We continue to believe that enforcing access based on entitlements is a relatively understood issue. Sure, there are implementation challenges but there's an embarassment of riches when it comes to picking products that enforce access. In the Oracle IAM stack alone, you can throw a dart at the wall and hit a product that can check entitlements and allow or deny access:

Oracle Access Manager (OAM) - authorization rules in a policy domain.
Oracle Virtual Directory (OVD) - access control rules
Oracle Internet Directory (OID) - access control policy points and privilege groups
Oracle Entitlement Server (OES) - role and access policies
Oracle Identity Federation (OIF) - in federation protocols; usually deployed with OAM
Oracle Web Services Manager (OWSM) - assertion-based policies
Oracle Adaptive Access Manager (OAAM) - rules-based policies

In order to enforce the entitlement, it (entitlement) must be first provisioned to the target system and second associated with a subject (user, group, application,etc). This is where a lot of painfully expensive steps happen because much of the workflow involves people from different teams. Throw in approval requirements, throw in eventual upgrades of target systems (Oracle e-Business Suite 11.x -> 12.x = potentially thousands of entitlement changes), throw in audit and compliance (does this person still need this entitlement) and you've got an unmanageable mess on your hands. We've seen and tackled this problem of managing entitlements' lifecycle so many times that we've got it down to science. Come to our webinar to find out more about managing entitlements and using Oracle Identity Manager as a platform for keeping them under control.

It has been years, literally, since I have heard anyone talk about agent vs agentless. Both sides have spoken, and I believe the resolution has been passed: Agentless (by that I mean nothing installed remotely from the server) whereever possible, then use agents. And in today's climate of open standards and secure communications, it seemed like "whereever possible" was everywhere. Thus, the debate died and it became an afterthought.