Manage exceptions in IAM

At O’Hare last month, I witnessed the genius ahead of me in the security line get rejected by the scanner twice. Apparently the TSA guy had already told him, “Take everything out of your pockets.”

“But it’s just my keys.”

“EVERYTHING.”

Then it was his hanky. "Everything," he was told again. "But it's just my hanky."

Amazing. Some goober could not understand the definition of “everything.”

This is not to say that every situation wants you to stick to “everything.” Sometimes exceptions are allowed. And sometimes they’re NOT.

I’ve been discussing this subject a lot lately because of a compliance roadshow I’ve been doing. Specifically, I’ve been talking to audiences about best practices for passing security audits. My general statement is (based on what several auditors have told me) that most exceptions are acceptable, the first time through, if they’re documented.

Here’s an example. “John is allowed to request payments to vendors, but normally is not allowed to approve those same payments, for obvious reasons. However, the approval guy is out with a broken leg, and John knows the systems well, so we’re having him do double duty temporarily.”

Even if a secondary approver signs off on this, the auditors may very well say, “Nice. You’ve brought this exception to our attention before WE found it. You’re good to go, THIS time. But you not only need to clean this up, you need to show us your plan for preventing it in the future.”

The real world runs on exceptions. Yes, you’d like all access rights to be members of roles. But in reality, a user has a certain number of roles, along with a smattering of individual privileges. Collection of privileges, another collection of privileges, and three or four cats and dogs. It’s how we DEAL with these exceptions, and how we DOCUMENT them, that matters.

If an auditor finds something about your environment that you were unaware of, or that you knew about but didn’t have written down, your life gets poopy. Documentation gets you through the first pass of exceptions. After that, you get told what’s allowable and what’s not.

If the security auditor tells you “take everything out of your pockets,” then you’d better do that. Some exceptions are never allowed, even if you had them captured on a report. A bank in Minneapolis was fined $10M this winter for disallowed transactions (no, not security breaches, per se). The transactions had been duly recorded, but they were considered, well, poopy.

The migration of exceptions to exemptions doesn’t have to be sloppy. We use Oracle Identity Analytics to help customers clean up their exceptions. Create a new policy, let’s say one for Segregation of Duties. “If you have A, we will no longer allow you to have B.” This means running that policy and looking for users who get tripped up on them. NOW … you have options as to dealing with these trip-ups.

1)      Mark it as unacceptable, and take away the extraneous privilege

2)      Set it to expire in a week

3)      Set it to come back up for another review in a week

4)      Mark it as acceptable. It becomes the new policy, and won’t raise any more red flags.

Of course, you can’t just do this on a whim. You do this based on careful review, maybe by committee, and perhaps according to what the security and/or audit staff say is okay.

Years ago, I was leaving Vegas with a Fighting Nun, which is a puppet of a nun that can throw punches. The TSA guys had no idea what to make of it, but decided, after a short discussion, that it was acceptable. This is how it works. But the guy behind me, with the Bowie knife (no freaking kidding)? No, he didn’t get on with that.