Archive for January, 2010

Sun IDM officially dead

Friday, January 29th, 2010

I just read Jackson Shaw’s post responding to Oracle’s announcement about what they intend to do with the various Sun identity and access management products.

(Read Jackson’s post here)

Quite funny – and I concur. Having looked at both the Sun and Oracle identity manager products in the past, it was pretty evident that Oracle would have to go this way — Sun’s IDM product is really awful and I couldn’t see Oracle investing in two products, when one of them is this much trouble to support.

The real question now is what will all those customers do? Sun was very good at selling their user provisioning product to hundreds of unsuspecting customers, who each spent millions of dollars trying to get it to do something useful. Those guys are all in various stages of production deployment and certainly need support.

So: I think Sun customers will be happy that their slow, buggy user provisioning system will be replaced by something better, but distressed at the prospect of having to redo huge, expensive deployments. I’m fairly sure that not much of the work that they have invested in policy definition, workflow processes, etc. will be salvageable — we’re talking rewrite here, folks.

Which means that many IDM customers may go shopping soon. Oracle will likely give them a free-upgrade path (i.e., you get the replacement software for no cost), but the services engagements will be huge. More costly than the software license fees being saved, for sure.

While this is bad for those customers, it’s also an opportunity in the marketplace to replace first-generation, unstable, non-scalable software with something better.

Does anyone else see it this way?

Bad PR x 1.2 million customers!

Sunday, January 17th, 2010

Interesting reading:

Sounds like Lincoln National had a bunch of shared, static admin passwords and after 10 years (!!) someone was tipped off that
ex-employees still had access and may have compromised customer privacy.


Can you imagine leaving admin passwords the same for that long, presumably spanning the departure of IT admin staff?

That’s just dumb, and the consequence these days is not “oops, lucky nothing bad happened” but rather “oops, we have to notify 1.2 million customers that we did something stupid.” Great PR.

The solution, of course, is simple. Change those passwords – often. Products such as Hitachi ID Privileged Password Manager (link below) make it even easier – they will change the password for you, automatically.

PAM Product site

Hopefully this is a lesson for someone.. 🙂

— Idan

Does your SoD engine actually work?

Wednesday, January 6th, 2010

Segregation of duties (SoD) is a pretty fundamental tool used to prevent fraud and other bad behaviour.

Fundamentally SoD works because it prevents one user on your network from having all of the entitlements that are required to do something bad. In other words, having effective SoD engine means that the bad guys have to collude to do bad things. It takes more than just one bad guy to do harm.

SoD policies are generally defined as toxic combinations of entitlements. The classic example: a user who can create vendor records cannot also issue payments to vendors. The toxic combination here is two entitlements: (a) creating vendors and (b) issuing payments.

In general, an SoD rule may specify that a single user should not be assigned more than N of M entitlements, where N is less than or equal to M. For example, you might define 20 entitlements and define an SoD rule that prevents any one person from having more than one of them.

So far so good — what’s so tough about that?

First, entitlements might appear on different systems. For example, no user should be assigned both this Active Directory group and that SAP role. That means that SoD enforcement needs to be in the identity management infrastructure, rather than locked into a single application’s silo.

Second, entitlements might be grouped into roles. A role is nothing more than a set of entitlements — which themselves are security groups on systems and applications, login accounts on systems and applications, or other roles. Keep that last bit in mind — roles can be nested, which means that role definitions can be quite complicated.

An SoD rule might be expressed in terms of individual entitlements, in terms of aggregates (roles) or both. It’s natural, for example, to create a role called “Vendor management” which includes all sorts of entitlements to do with looking at, creating, modifying and deleting vendors in a financial system. You could similarly create a “payment management” role on the same financial system. The natural question is then: “how do I prevent a user from getting both the vendor and payment management roles?” Do you define an SoD policy in terms of specific entitlements, such as “create vendor” and “issue payment,” or do you write it in terms of the two roles, or perhaps you need both kinds of policies?

If you define the SoD rule in terms of individual entitlements, you’d better make sure that your SoD engine will detect and block users from getting a combination of roles that includes a toxic set of entitlements.

Conversely, if you define the SoD rule in terms of roles, you’d better make sure that your SoD engine will detect and block users from getting a set of fine-grained entitlements that are equivalent to the roles you said were not simultaneously allowed.

I know that we got it right in the Hitachi ID Identity Manager, but I’ve been told that some of the SoD engines — embedded in other user provisioning products — will miss some SoD scenarios.

If your SoD engine doesn’t reliably catch all violations, then it’s worse than having no SoD engine at all — you have a false sense of security but your controls are actually not effective at all!

If you’re not sure, here’s a little test you can run:

  • Create four entitlements — say Active Directory groups — in your environment. Call them Ea, Eb, Ec and Ed.
  • Create two roles on your user provisioning system: R1 which includes Ea and Eb and R2 which includes Ec and Ed.
  • Define an SoD rule in your user provisioning system that prevents users from having both R1 and R2.
  • Create a new user and assign Ea and Ec to that user.
  • Add Eb to that user — this should not violate your policy, so should be allowed.
  • Add Ed to that user — this should violate your policy, so should be blocked, since the user will now effectively have R1 (he already has Ea and Eb) and R2 (he already has Ec and you’re adding Ed).

I bet you’ll find that the last step — adding Ed to the user, won’t set off any alarms. If it doesn’t, you should start worryiing, because your SoD engine is broken.

Have fun! Ping me if you find that your system works (or doesn’t) — I’m quite interested to learn which SoD engines out there are effective and which ones aren’t.

— Idan