Who's in charge (of IdM) around here?

Several years ago I flew to Lexington, Kentucky to visit a large printer manufacturer. Very nice people, and they had this amazingly long hallway in their factory that was almost a mile long. But one of the things I remember most about that trip occurred at the airport.

I traveled there with two other guys, and we ended up walking behind two ladies and three kids. As we walked toward baggage claim, the women walked faster and faster, and the kids, the oldest of which was no more than ten, fell behind. The women were oblivious. Eventually we lost sight of them altogether. At one point, the kids stopped to look out the window, and WE, complete strangers, were the ones who told them to keep up. The two women were long gone. We actually walked a little slower so WE wouldn’t lose the kids.

Once in baggage, we had to scan for the women, who were at the far end. We then had to point them out to the kids, who would have otherwise have been lost. As a parent, I was fairly horrified at the stupidity of these women, who, once the kids ran up to them, said, “Well, THERE you are.”

I wanted to say, “Yeah, there they are, after we escorted them, AFTER you practically abandoned them.” Dumb dumb dumb. Apparently they assumed that total strangers were going to make sure their kids found them.

You should NEVER assume that other people will be doing the job. ANY job. Or that things will magically happen. My kids will leave dirty dishes next to the sink, and assume that magically they will end up in the dishwasher.

Somebody has to OWN every job, every process. Validation, verification, candle on the cake, must be the responsibility of a real person. In the last year, I visited a client where terminations triggered various notifications to a variety of departments, so they could each handle their piece of it, but no one party OWNED terminations. So if at any point, one or more target systems were not corrected (i.e. the terminated user was not removed), it might never be caught. Nobody was going over the checklist. Everybody just assumed that everybody else would do their duty.

At another client, terminations were SUPPOSED to trigger notifications to everybody, but sometimes these “fall through the cracks.” The backstop was a monthly HR report. More recently I spoke with a place where that backstop window was ANNUAL.

When somebody doesn’t do their job in a timely manner, then automatic escalations should kick in. Your manager, your peers, somebody sharing your role, should be asked to pick up the ball. Of course, if you’re in the airport, the task of watching your kids should not be delegated to total strangers who just happen to be in the area.

For critical processes, somebody has to be in charge. They must be accountable. Nothing magical happens. Don’t let important tasks “fall through the cracks.” And don’t lose your kids in the airport.

Remake Your World

One of my kids saw me struggling one day to pack all my spaghetti into my tech bag. Power cords, iPad, USB cables, you name it. She partially cured my ills by sewing for me, out of a set of old PJs, a little bag, complete with drawstring, for my wi-fi, the cord, and the battery pack. She made me a second for my iPhone peripherals.

You could say I added something else to my bag, but it’s lightweight, and simplifies my life. I can open one zipper and quickly locate, by feel or vision, the soft, purple bags with my stuff.

Well, Holy Analogies, Batman, you can do the same thing with IAM. No kidding. Sure, out of the box, the Oracle suite can do a whole bunch of good stuff, including 99% of your use cases. But when you need that extra percent, that little tweak, you can always extend.

In Oracle Identity Manager, there are tons of canned libraries for approvals, reconciliations, escalations, orchestrations. But if you need to incorporate some weird, out of band, external resource or call into your workflow, it’s easily enough done. You just can’t part with that shell script for creating unix accounts? Weave it into your workflow.

One of my higher ed clients worked in a call to an external service for background checks. For non-students, the second stop after the initial business approval is a shout-out to a security company. Everything gets put on hold until that comes back (or times out, prompting a phone call). They had previously had two situations where a candidate was pretty much ready to step into a classroom, and then it was discovered they were naughty people. This led to last-second, expensive, and expedited substitutions.

(By the way, it ain’t cheap to get such an online service, so most schools still do it manually.)
On the access side, authentication and authorization policies can also be extended. A transportation client of mine goes out and calculates, in real-time, a customer’s current balance. If a customer is delinquent, their access is either limited or blocked altogether.

Let’s be honest about all this. NO package, at least in the enterprise space, will work exactly the way you want. You will always, always tweak. I don’t count customization, by the way. In Oracle Identity Manager 11gR2, you can customize the snot out of the interface with drag and drop. That’s window dressing (although extremely useful in terms of productivity). What I’m talking about today is process. And it’s process that models HOW YOU DO BUSINESS. I’ve always said, when you buy some big honker like SAP, you don’t own it. It owns YOU. And you will do business the way IT does business. For some people that may be a good thing. But if you want it your way, then it’s not.

Oracle adds new endpoints, certifications, platforms, and standards all the time. I used to say that SPML wasn’t going anywhere because nobody was adopting it. Oracle kept pushing it, as did others, and now it’s gaining a lot of ground.

ESSO now supports proximity cards for auth. These scare the hell out of me for other reasons, but if customers demand it, Oracle and others eventually get around to it.

There’s usually no solution that will deal with every single one of your use cases every single time. But you want a solution that gets you as close as you can get, then lets you shoehorn in the rest.

We’re all on the clock

Before heading to the airport for my latest trip (I’m in Ohio at this moment), I was packing my computer bag, and my driver showed up 45 minutes too early. Whenever I call the same people I’ve used the last quarter-century, their computer always says I should get picked up two-plus hours before my flight. I always dial that back to a little over an hour. In this instance, it didn’t take.

And I tend to stick to the same hotel chain, to build up those wonderful points, but they’ve mucked up my last two reservations. On one, they reserved only one room instead of two (I was traveling with a colleague), and on the other they had me coming in on the wrong night.

These are big names, not fly by nights, so I expect better.

Things have to happen on time. There are expectations to be met. There are requirements to be fulfilled. People have to get what they need, in order to do their jobs. When people leave, they have to lose those same things. And if policies change, those policies have to be pushed out for accurate enforcement.

Timely provisioning is a huge value. For internal users, it means faster time to productivity. Obviously, this is a good thing for their managers as well. For external users, it means a better customer experience. “I paid for this, when can I access it?” Easier access means greater usage, which in some situations translates to better revenue.

If we properly align Oracle Identity Manager to the in-house HR app, for example, a new employee can be enabled on Day One at 9 am. A scheduled reconciliation task can pick up on the expected start date, and when the status changes to “hired” it can have that user up and running and ready to produce. When that user gets transferred, OIM can also pick up on the status change, provide new entitlements, and wipe out the old ones, without missing a beat.

And of course there are terminations. The nice ones, where Joe is retiring at 5 pm on Friday, means Joe’s expected termination date is picked up by OIM, and he keeps his access until the last minute, so he can properly hand off his assets and pending jobs before getting loaded at the bar with his old colleagues.

And when you have the ugly terminations, you may not wait for the HR status to be updated. You go straight to OIM and hit “disable” on Joe’s account and make those access rights go away immediately, on every single target system, so that he can’t backdoor his way in.

OIM uses BPEL to drive workflow tasks, which are gathered in a logical workflow definition to fit every situation. Request is made or HR status is updated, so OIM initiates the workflow to automatically provide a mailbox and an AD account, before notifying approvers downstream that they need to okay (or reject) additional access. Provisioners are also notified that they need to fat-finger accounts for target systems that haven’t been hooked up yet. People who haven’t done their jobs get nagged on a timely basis before requests are escalated to a backup manager.

One question I ask my prospective OIM clients is, “What’s your SLA on terminations?” Meaning, what is the expectation on timeframe for blowing away all access for a terminated user? Often I am given a concrete number. But sometimes people look at me and scratch their heads. The answer is, we get it done when we can. I tell them, they SHOULD be looking at seconds, or minutes at most. Hit the button, and watch those permissions go away, right away. Workflow drives this to completion.

Accomplishing these critical tasks on time won’t get you a cookie. It’s the very least that’s expected of you.

Get the right security lineup

I’m in the excellent and crappy position of always having to learn new things. It’s excellent in that it’s never boring, and somebody else usually pays for it. It’s crappy in that I have to put in the time. I was the world’s best client-server programmer, and then we invented HTML. Dammit.

Recently I tried recruiting some people to fill some open slots. One guy I talked to, a known quantity with a good background, is 15 years my junior. He told me it sounded good: more money, less travel, better hit rate, stock options. But he told me, “I don’t want to have to learn a new product set.”

Ouch. Better insurance too. But oh, that learning curve.

Two years ago, I visited a manufacturer where I had to explain federation to the guy in charge of the web site and authentication policies. And I also had to explain to his enablement guy what provisioning was. Incredible. Workflow? Adapters? Target systems? Roles? No kidding. Read a magazine or a blog sometime, pal.

Three years ago, in St. Louis, I explained to a medical company how their LDAP queries, written by their consultants almost a decade earlier, worked.

And more recently, while whiteboarding database security for a client, I ended up explaining to their db security consultant what SQL injection is. After that meeting, I was in the rental car with a colleague, and he remarked, “How do I get a job like that? Getting paid to not know my subject. Astounding.”

And right at this moment as I type, I’m sitting in an airport, having just left a session where I attempted to fix somebody else’s wretched misconfiguration of a set of security tools. In the end, I’d have been better off installing from scratch. Somebody who didn’t know or didn’t care about what they’re were doing did something anyway, and left it in a state of awfulness.

Anybody can call himself a Subject Matter Expert. I call myself the same thing, but not about All Things. I do what I’m good at, try to learn the stuff I want to be good at, and avoid the rest. Trust, but verify. You still you need to check references, ask the questions, and do the homework. Your security, your compliance stature, your reputation may depend on it.

Quit your whining, you compliance crab

A couple of months ago, I was asked to pop over to Germany. I had smooth flight over there, sitting next to an opera singer whom I later looked up on Youtube. Traveled through Hamburg on my way to my final destination to discuss the secure (using encryption and the use of protected realms) storage of data pertaining to German nationals. This was on behalf of a wonderful customer who sent me over with beautiful accommodations.

I got picked because of my excellent posture, blazing good looks, brilliant repartee, and a tiny bit because of my knowledge of data security and international regulatory laws. But really, it was the posture.

They bribed me into going with first class seats and a stop in Amsterdam. At Schipol airport, I saw a guy in the first class lounge who was so drunk, they had to call the EMTs.

To satisfy the requirements of the business at hand, I had to visit the local offices of a German ministry, located in a very nice strip mall. No kidding. They served some excellent oversized cookies. Anyway, the argument to be made was that the data could be utterly secured, and accessed only by authorized personnel. Even the DBA’s would not be able to look at personal data. This would be accomplished with a combination of Transparent Data Encryption (TDE) and Database Vault, both Oracle products.

WHY was a German ministry involved in the disposition of data to be processed by a private company, before the data was even collected? Because that’s what they do. They CARE about the disposition of the data. European privacy laws mandate that before you collect data, you need to specify what you’re going to collect, why you’re collecting it, who’s going to see it, how long you’re going to keep it, and then you may collect ONLY that data, and use it ONLY for the documented purpose before you dispose of it.

Outside the USA, compliance is a serious thing. And they don’t horse around. They enact a law, and it’s in effect, NOW. You violate it, you’re in trouble,NOW. In India, they once passed a compliance law that was so stringent, people immediately went to jail.

Meanwhile, in the USA, HIPAA is in year 95 or 96 of rollout. If you violate it, oooh, they’ll make you write a letter and make you stand in the corner. If you appear to step on SOX, you’ll probably go to court to argue that the law’s too vague, and you’ll likely win.

NERC CIP. Now there’s a set of regulations with teeth. If you don’t secure your power grid, and it gets hijacked, people lose electricity while it’s too hot out, and all the meat in their freezers goes bad. This is why CIP has provisions for violators to be beaten with sticks.

But even NERC CIP is open to interpretation, while PCI is fairly specific when it comes to IT security.

But is the U.S. gummint ripping on your security scheme before you’ve even envisioned it? No. They kinda wait until you screw up. Have they passed a law and tossed you in jail for it a day later? Nope. Remember, this is the country where they invented giving you a loan for your own home down payment, in a grand and successful scheme to tank the economy.

So when the auditors are hassling you, stop complaining, prep for your assessment, and sleep well.