holiday post: protect your identity while at play & recalling Y2K

Just a quick post to keep up my frequency but not engage too many brain cells. First, as many of us (assuming mainly only other industry wonks are reading this) shift into the role of user over the holidays, I was reminded to make sure we practice what we preach. I cam across a neat little reminder of how easy it is to be tricked when you forget that technology is not magic. I also ran into this comic that reminds one that no matter how careful you are your identity is never as secure as you may think.

I also can’t help but think of ten years ago this season when the whole world was crazed about Y2K. It’s amazing to recall how much that accelerated technology at the time. There was a mad rush to replace everything. In a way, we’re still living in it’s shadow in the IT of many of the medium to large data centers. That was the last time they had a big “replace everything” rush. Now it seems the green revolution will be the way the next big refresh may happen – unless of course it all disappears into the cloud(s).

I won’t be back until next year. Hope you all have a nice rest between now and then – I know I’m planning to.

Microsoft & Sentillion – Federation vs. ESSO?

Many are talking about a surprising move by Microsoft, buying Sentillion. The press release doesn’t say it all, that’s for sure. My esteemed colleague, Mr. Shaw, asks some very interesting questions. I think some of the answers are right there in the discussions. More of the tweets I’ve seen so far (as of 2:30pm EST on 12/10/2009) use terms like Microsoft buys a “Healthcare Software” company. And, as @jacksonshaw points out, the acquisition was driven from the haelthcare division at Microsoft. It is entirely possible that the FIM team found out exactly when we did. I doubt this because I’ve always seen Microsoft as being a bit better at internal communications than most vendors their size, but things like that are very common in very large companies.

Also very common in larger firms are duplicate offerings across different business units. And so maybe having more than one provisioning offering is not going to be as painful as it may seem at first blush. After all, how many forms of HR application does Oracle sell right now? And that’s a core piece of corporate plumbing, not just an IT infrastructure component.

I’ve never seen Sentillion outside the healthcare niche, though I’m sure they are to some degree. They always posed the biggest threat when context management (in the CCOW sense) was a big part of the requirements. Most of these healthcare RFPs I’ve seen have been more about context than SSO. So it seems to make sense to me that the healthcare folks at Microsoft would want this in their bag as a way to capture more of their clients’ attention and budget.

My bet is that this is going to stay very healthcare focused – simply due to resources required for transition. Focus is a struggle during any transition. Adding another business unit (IDA) into the mix would be asking for trouble.

And, to finally arrive at the point in the title, the WIF focus has all been on federation. There is a definite tension between ESSO and federation. If you have the problems handled with ESSO, why spend the money and time on getting applications federation ready? So there is likely some tension there that will need some thinking through before making any attempt to glue these offerings together. Though I’d like to be a fly on the wall when someone asks Microsoft if they would support a WIF federation approach or an ESSO approach for a mid sized company if both reps with Sentillion and WIF in their bags are in the same room. That would be a fun few moments of silence…

long view identity thoughts – Gartner IAM Summit 2009 part 2

I’ve been traveling like mad (writing this in Berlin). So this comes far too long after the show for my taste, but I really wanted to get this out there because there is some very good stuff to highlight.

The star of the Gartner IAM Summit was Earl Perkins. He has a way of saying things that makes the very obvious seem as wise as it should. The thoughts he concentrated on that left an impression on me were:

1. There is too much focus on the C in GRC. Vendors are the most guilty here, since they tend to see compliance as the easiest route to sales success. If there is an audit finding or clear potential for one, you have a compelling event. It’s just as valid to talk about using IAM products in a way that removes risk and aids in governance, though; and the business uses those terms. Vendors are always looking for ways to address the business buyer vs. the technology buyer. Of course, that is also useful for the advocate of IAM projects within an organization. Talking to your customer internally about risk and governance makes them see you as proactive vs. reactive to compliance needs that arise from outside pressure.
2. The auditor is your friend. I got to see Earl brief clients directly on this at the “breakfast with the analysts” session. I can’t agree more with this. Making the business take your IAM project more seriously by virtue of making it the auditor’s edict is a wonderful trick.

Reduction is another theme that came out of both the analyst and customer led sessions. All forms of reduction are good. Quest had a session highlighting our Authentication Services being used at Chevron, and that focused on reducing the overall number of identities in any enterprise by consolidating to AD for all Unix, Linux and Macs as well as many applications. But reducing the number of roles, the number of entitlement definitions and directory infrastructures was touched on again and again.

Last is a favorite of mine: reading the magic quadrant correctly. Gartner always says this clearly, but it feels like no one ever hears them. I look at the magic quadrant as three dimensional. The two dimensional graph is a ceiling where vendors who have made the cut poke through and show up in their respective areas, as if you were looking at the top of a cube. Turn the cube to it’s side and you would see the shorter lines which don’t make it to the top of the cube which all represent the vendors which are not good enough to be in the “magic ceiling”. Earl also revisited why there is still and likely to never be an IAM magic quadrant – there is no one definition to make a cohesive statement about.

A very good conference all in all. Can’t wait for the next one…

Access Certification CBT/video for non-IT folks

I’m always in catch up mode with my reading. I finally got to Ian Glazer’s “Access Certification and Entitlement Management” on a plane to California. If you are in the market for access certification, trying to understand how to construct and approach to managing entitlements or just want to understand the moving parts of access in any reasonably complex organization, then this is a must read. What got me thinking most was the tone of the paper. Essentially it boils down to the good advice to make sure you define boundaries for tasks well and get the people from the business who should own the information to become the owners by the end of the process. Ian also encourages you to use whatever resources you can, even if they make strange bedfellows. It reminded me very much (and I’m going to mix analyst firms here so forgive me) of Earl Perkin’s thoughts about making the auditor your friend and making sure you “care, but not too much”, which he communicated at the Gartner IAM Summit last week (and blogged about previously as well).

All this got me thinking about the actual content of such IT to business communication regarding access certification. And, since I was trapped on a 6+ hour flight with a power outlet but no internet, I came up with this small, tongue in cheek video. I know the terms will feel like nails on a chalkboard to some since they are not exact. But I really tried to exercise that “it’s more important that they get the right ideas and not the exact right terminology” notion as best I could.

done

Identity Vendor Soup – Gartner IAM Summit 2009 part 1

Since there is so much to say about Gartner IAM Summit 2009, I wanted to break it up a bit. The first thing I wanted to do was get the vendor stuff out of the way. When I get to the topical stuff I’m sure some vendors will be involved, but there is much to say about what happened in exhibition hall.

Possibly the most talked about thing on the floor was the size comparison of the Oracle and Sun booths. Oracle had the biggest possible booth and, predictably, Sun had the very smallest. Sun was literally on the far wall alongside niche players and new entrants. Of course this just makes sense, but everyone was talking about it. I should have taken pictures. To add to this drama, the announcement about the EU’s objections to the merger was made while we were at the show and that just set people off talking about it all again after the booth comparison finally died down. The most sensible thoughts were all centered around the wisdom that it would be years before anything really happened to Sun’s IAM offerings. In fact, Gartner even said as much during the session about the magic quadrant. Yet many people were convinced, all wisdom aside, that this merger was going to be about Oracle raking Sun customers over the coals.

Aside from the Oracle and Sun drama, the show floor was not too exciting. Gartner always has a way of making sure their clients know the show is all about them – this time was no exception. All the booths were in the basement. That said, they only served lunch and drinks by the booths; so there was a captive audience at times. It seemed to me, watching the other attendees, that most folks didn’t really spend a lot of time talking to vendors. From my place in the center of the floor at the Quest booth, I could see pretty much everything. There was only 6 hours of booth time, and I’d say only half of that was really about vendor time (the other half was eating time). The people who came to our booth were either interested in something very specific, or on a mission to talk to everyone a bit and get the lay of the land.

The busiest booth seemed to be Aveksa’s. Sailpoint and Cyber-Ark got some good traffic, too. No surprises there. They are all in the sweet spots of their fields. The only booths I couldn’t see were Oracle and Novell. Of course, those were the biggest booths and they were right at the entrance of the floor. I’m assuming they got some good traffic just because of that.

It seemed to me the best user/vendor interactions were side meetings, which there were tons of, and the use cases that the vendors sponsored. That’s one of the very cool things about Gartner’s shows. The user is in the focus and everything is designed to make sure that it stays that way.

Next post in a few days (or sooner) and it will concentrate on what I took away from the sessions.

RBAC and ABAC and Roles, oh my.

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

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

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

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

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

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

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

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

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

entitlements and access – separate but equal?

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

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

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

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

AD Bridging gets respect at Burton’s Catalyst09

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

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

what’s on the mind of people seeking IAM solutions

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

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

security in the cloud – different standards?

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

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