I just read an essay with interesting observations made by Richard Rumelt in McKinsey Quarterly. He says “ There’s been a dramatic failure in management governance. And so our basic doctrines of how we manage things are in question and need revision.

At the heart of this failure is what I call the “smooth sailing” fallacy. Back in the 1930s, the Graf Zeppelin and the Hindenburg were the largest aircraft that had ever flown. The Hindenburg was as big as the Titanic. Together these vehicles had made 620-odd successful flights when one evening the Hindenburg suddenly burst into flames and fell to the ground in New Jersey. That was May 1937.”

Years ago, I had the chance to chat with a guy who had actually flown over Europe in the Hindenburg. And he had this wistful memory that it was a wonderful ride. He said, “It seemed so safe. It was smooth, not like the bumpy rides you get in airplanes today.” Well, the ride in the Hindenburg was smooth, until it exploded. And the risk the passengers took wasn’t related to the bumps in the ride or to its smoothness. If you had a modern econometrician on board, no matter how hard he studied those bumps and wiggles in the ride, he wouldn’t have been able to predict the disaster. The fallacy is the idea that you can predict disaster risk by looking at the bumps and wiggles in current results.

The history of bumps and wiggles—and of GDP and prices—didn’t predict economic disaster. When people talk about Six Sigma events or tail risk or Black Swan, they’re showing that they don’t really get it. What happened to the Hindenburg that night was not a surprisingly large bump. It was a design flaw.

To see the disaster coming, you had to have looked beyond the data about flight bumpiness—beyond the professionalism of the staff—and really think, “Does it make any sense to have people riding in a gondola, strapped to a giant sack of flammable hydrogen gas?” There’s just not a data series that lets you think about that. But it’s not that hard to think about.

If we apply this logic to SAP Security – I find many SAP customers suffer from the Smooth Sailing fallacy. ‘Well – we implemented SAP 10 years back, IBM is managing the support, we have no problems! Our Security incidents are insignificant.’ ‘OH we have installed SAP GRC solutions but no one uses them!’

This smooth-sailing fallacy in IS Security arises when we mistake a measure for reality. Competent management always looks deeper than the numbers, deeper than the current measures. Incompetent management just focuses on the metrics that are based on past reality. And that’s how we get into these troubles. We really have to think about the redesign ERP and SAP security & its measurements. This lesson is fundamental: you cannot manage by just looking at the results meter.  You have to have a big picture view of Security by applying constant changes in security protocols and metrics. That means your Security policy which may be 5 years old is useless and you have no security in place.

CEOs and CFOs will use the smooth sailing argument – Hey! We never had a security issue in the past 2 years? So why now?

You have to show them what Rumelt said about Hindenburg! A small design flaw can blow them out of the window.

So far – despite all efforts from SAP on the Marketing front – I have not seen this to become a reality. CUA is no longer one of SAP’s beloved children – meaning no major functionality upgrades will be provided through enhancements. But to tell you the truth, it works. So if you only care about SAP user provisioning (like me) then CUA is good enough. On the flip side CUA has nothing to do with Identity Management. Its intend was to simplify role assignments across complex system landscapes, not to automate user management. It’s still not capable of mirroring best practices for onboarding, position changes and terminations. The manual workload is tremendous and here and there in the mist of Excel spreadsheets and e-mails from HR orphan user id’s are as inevitable as candy at Halloween.

So I say it’s time to retire the good old box and get something in place that makes SU01 and SU10 go away forever. Time it is indeed.

I have posted a brief discussion on the risk in adapting new technologies, or upgrades and a general guideline for addressing the problem.  The post is available at Risk Intelligence.

My latest post can accessed be here.

It’s hard to believe that it has been more than sixty days since I have posted anything. I was busy on a small project, that was followed by research/writing for a book on IdM and recently developing a proposal and solution for a complex security problem.  I hope to get back to blogging a little more frequently.

When I worked for a large corporation I was frequently tasked with building a business case without a budget, that is, I wasn’t able to hire any consultants to assist me.  In some cases deadlines were relatively short so it was fairly difficult to get it completed.  When the Internet came around more than once I was saved by people willing share business cases they had developed.  Therefore I have uploaded a economic impact model that comprises two documents, an excel spreadsheet and word document that should cover the basic needs of a user.  I have other more sophisticated models besides this one (for example, a business process and knowledge management re-engineering model that compares the economics of the current state versus the future state) but for the majority this should suffice to help you get started.  If you find it useful just leave me a comment.

It can be downloaded here.

Update:  Fixed the link.

So it’s finally beginning.  Identity Management vendors are percieving the departure of Sun IDM from the landscape.   CA is now offering Sun Users the ability to switch over to CA’s IDM product.

I’ve not heard much lately about what the eventual plans are for Sun IDM, but something’s going to have to be announced soon before the other IdM vendors pull the rug out from under Sun/Oracle.

The answer is zero.  A unique identifier adds nothing to any logical problem we have with our data.  Let’s see why this is true.  I have two sets of data from different systems, which represent information or attributes about a real world user.  Those data elements are indistinguishable from each other.  Perhaps they are first name, last name, city and state.  They are identical as far as I can tell.  If I add a unique identifier do I know anything more about them?  I just know they are no longer identical and yet they may be in the real world the same person. By adding a unique identifier I may have made a distinction, which is false.  It’s impact will only be deleterious never beneficial.  The unique identifier becomes ornamental.  Metaphorically it is like placing a medallion around the neck of the famous twins and still not knowing if it’s Tweedledee or Tweedledum.  At least in this case I could re-name them to something like Dee and Notdee, which would be meaningful to an observer.  However, in the foregoing example, we are dealing already with a representation of an entity and it adds nothing. Now let’s add several more attributes, for example, title and department.  If I can now distinguish easily whether they are the same person or not I have accomplished my goal and I still have not added a unique identifier.  The smallest subset of elements that distinguishes one set from another is a suitable key if the data is in a database and I still haven’t added a unique identifier.  So then how are unique identifier’s useful?  They are useful within a context in which we are programmatically creating many closely similar but not identical objects whose existence is ephemeral.  When we are combining data from many different contexts, they solve nothing; they are just another attribute.

The landscape document from SAP that explains how to export from HCM to VDS to Identity Center has sections that are less than clear so I thought I would list common issues that have caused problems in the past.  First the architecture.  The way the export works is as follows:

1. A report is run in SAP HCM which extracts the necessary data formated as LDAP data.
2. SAP connects to the VDS and pushes the data.
3. VDS connects to the Identity Center information store and uploads the data.

A couple common problems I have seen.

• The field names inside SAP are misnamed or the export names to LDAP are.
• The LDAP libraries in SAP Basis are not installed.
• VDS Template:  The one you want to use is this one “HR Export to IdM Identity Center.xml” this one will not work “HCM LDAP EXTRACT for IDM.xml”
• Bad credentials or passwords (of course)
• VDS Tree for HCM is broken in some way.  If in doubt recreate your setting from the template.

Troubleshooting Tips.

• First determine where you are broken.
• Turn on verbose logging at VDS and see if HCM is even connecting.
• If you are connecting to VDS but no data is reaching the Identity Store then check the LDAP extract for misspellings.   One error in your path and the whole thing breaks.
• If VDS shows database errors then check the error logs in the identity center for problems with the task configuration

Finally, because HCM does not support event triggers — which can be tricky — I usually filter at HCM LDAP report for the data I want.  In most cases a nightly run is sufficient.  SAP recommends a full upload every time but this is not practical for large numbers of employees.

I’ve been listening / reading to information lately on “Application Centric Identity ” and how it’s supposed to be the new wave in Identity Management.  Frankly I’m a bit confused.

Basically it sounds like what’s being discussed is the creation of an authoritative store, something I’ve been working with in Identity Management for about 5 years now.

The “newness” to this offering seems to be the implementation of SOA / Web-services architectures to make it more interesting and accessible to authentication / authorization services.

I’ve always felt that by gathering the authoritative attributes from each enterprise repository and linking them together in an authoritative store (metadirectory) you create the clearest picture of what each identity “looks” like.  Furthermore, these authoritative entries can then be used as the basis for provisioning new application entries and update existing ones.

To me it seems like the backers of this school of thought are finding a new way to talk about the integration of Enterprise level ERP systems with Identity Management.  This is not a bad thing.  The one thing we need to do is break out of the idea that Identity Management is solely provisioning or Access Management. One without the other is worse than useless given the potential for malicious behavior.