Humptulips: an IAM lesson

This past week I’ve been traveling through Washington state with da wife and kids. One side note: whether we’re home, away, at the dinner table, playing ping pong, doing yard work, whatever … I am always wrong. I’m the guy, I’m the breadwinner, I’m the novelist and the security book author and the prize-winning short story writer, I’m the guy who once caught a burglar with his bare hands and turned him over to the cops, and none of that matters. I’m always wrong.

But I digress. Here’s something that occurred to me today. We stopped, on the way back to the hotel from the ocean, at a little town called Humptulips (allegedly a native name referring to how hard it was to paddle the river) for gas and cupcakes. They had a VERY old gas pump, the type I used when I was pumping gas in high school. They had to sell gas by the half-gallon and double the number, because the pump only went to 99 cents. When they built these kinds of pumps, it was inconceivable that gas would ever get to a buck.

This is similar to the Y2K non-disaster, which came along because nobody ever thought that old mainframe code written years ago would still be going by the year 2000.

If you don’t do the housework for six months, then when you finally get around to it, it’s a ton of work. But if you keep up with it, it’s easy. It’s the same thing with ids, access rights, auditing, and anything else in your enterprise security repository.

Sometimes you inherit that kind of mess, with legacy inventory. Legacy ids, legacy apps, legacy integrations that need to be maintained in silo fashion.

Those legacy ids can also mean any individual user may have multiple ids, across multiple apps, and they’re not mapped to each other.

A very common audit target is AD groups. “How many do you have? Where are they used? How many are redundant? Do you have governance on who can create them and manage membership?”

I can use tools like Oracle Identity Analytics to provide me info on those kinds of things, and to some degree even clean them up. But when you’ve got thousands more AD groups than necessary, it’s challenging. That is NOT an abnormal situation. I have customers with TENS of thousands more AD groups than they should, and who regularly struggle with audits as a result.

When you installed AD way back when, who knew it would get so out of hand? Well, now we know. And not only do we need to clean up what is there, we need to keep it from happening again. In fact, in plenty of situations it’s almost impossible to clean up in a reasonable time period. But at least we can keep it from getting worse. We put in place a plan to start scouring the existing pile, as well as enforce policies to stem the flood.

That means identifying targets for elimination/consolidation. It means mapping disparate ids for individual users (which allows you to keep using disparate ids for authentication/authorization). It means governing the creation of future objects, so they remain reasonable.

This is why we are moving away from the term “identity management” and toward the term “identity governance.”

Don’t let a legacy mess stop you from improving things. Ever see one of those pathetic “hoarder” shows on TV? People ending up with so much crap in their house that they just give up? Don’t give up. Put a program in place to start cleaning up what you have and keep it from happening again.

Don’t be a victim of, or slave to, your system. Own it.