Eeeyew, your LDAP is stepping on mine: mixing internal, external users

At a bank in Chicago recently, an IT manager asked me if I was seeing customers using Oracle Identity Manager as the HR for external users. It's kind of a loaded question, since OIM doesn't really handle payroll, taxes, that sort of thing.

I do actually have a couple of customers who use IdM as their HR, and I definitely do NOT recommend it. It's not built for that. HR is your authoritative source for who belongs in the company, who can have a badge, who gets paid, the usual. IdM is the authoritative source for who has (or had or WILL have) access to what. Every app plays its part.

IdM should be the keeper of access rights for ALL users. Where those users live in terms of the org is a different story. IdM should be able to reconcile users and profiles from wherever they're at, and it's common to have multiple authoritative sources, although a best practice is to keep these to a minimum.

And I have commonly seen external users kept physically separate from internal ones. For example, managers seem to hate putting contractors in their Active Directory. AD is some sort of sacred cow.

I can see not putting customers in there, because it can get out of hand, and AD already has a tendency to do that. I've had plenty of clients get in audit trouble because of AD, usually because they have too many groups.

But it's so easy to segment users in standard business apps, such as Peoplesoft. You've got groups, attributes, organizations, and other constructs to isolate one group from another, all of which can be supported by OIM, which makes use of this kind of data to provision, route notifications, request approvals, and satisfy any other requirements in which membership is a factor for provisioning.

You could still physically separate the users if somebody requires it, or if that's just the way you've been doing it, for legacy reasons. But you can still aggregate them when necessary through a tool like Oracle Virtual Directory.

There are so many virtual ways, in fact, to separate groups of users, and not just internal and external, that it seems downright silly to say, “I don’t even want them in the same database. They have to be on separate machines, across the room from each other.”

It’s called technology. Get used to it.

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.

Turn it off !!! Identifying rogue objects with IAM

Not to pick on Microsoft, but I tend to point out, in my talks on regulatory compliance, that two of the most common targets of security auditors are Sharepoint and Active Directory. Both are commonplace, both are easy to use, and therefore both are heavily abused. Sharepoint sites tend to crop up like cockroaches, and too, too often they’re governed by Active Directory groups, which also crop up like cockroaches. Sharepoint’s a great way to leak out documents that should only be shared with a discrete group. If I’m the boss and I say to you, “too many people have access to your department’s docs through your Sharepoint site and the AD group attached to it,” you may say, “besides being tall and handsome, you are also quite correct. I will remedy this problem by creating a second Sharepoint site, and publish a lesser set of docs there, and create an AD group to govern access.” And now you have yet another AD group.

You might also be using internal Sharepoint security, but therein lies a different problem: security that is Sharepoint-specific. In other words, a silo’d solution that doesn’t participate in the larger, enterprise environment.

It can also be quite difficult to track WHO is using a particular group, and for what purpose: single sign-on, authentication, authorization, email list, etc.

I once worked with a company that broke my personally recorded record for Active Directory groups. They had 120,000. Yeah, say it again. They had 120,000 AD groups. That was my all-time high, until I ran into another company, also in the Midwest, with 180,000.

The first customer told me they failed three different audits each year just based on those groups. I told them how we could use Oracle Identity Analytics to help them identify redundant or useless groups, but that cleaning those up would be predictably painful. Otherwise, they would go on doing what they’ve done for years: pay the regulatory fines.

The second company had a completely different approach. They wanted to get rid of their extraneous AD groups. So they started identifying their target groups, and turning them off, a few at a time, and waiting to hear who screamed. If nobody complained about a particular AD group disappearing on them after a month or so, they would nuke that group permanently.

It’s a brute force solution, AND assumes you’ve got a few years to clean up your AD. When you’ve got 180,000 groups, you can’t turn them off fast enough.

Far easier to identify and nuke are rogue accounts or users. If a user account in a target app is not associated with a live user in the enterprise directory, then you’ve got an orphaned (or zombie) account. It has life of its own, even if it has no corporate soul. A simple reconciliation, such as you might run in Oracle Identity Manager, would find that. You can also specify the remedy, either automatic destruction OR a notification to an admin who would have the task of deciding how to handle it.

If you have a whole bunch of users and/or target accounts that may be out of whack for legacy reasons, i.e. you’ve inherited an up-to-now ungoverned mess, you might also consider running an attestation cycle. All the designated managers would automatically be assigned a list of their users, or perhaps a list of the users provisioned to the resources governed by those managers, and the managers would then review their lists, and check off the users or accounts that needed to go away. If the attestation is hooked to the provisioning system, these accounts would then be deprovisioned.

Auditors don’t glumly trudge home after they find piles of AD groups, or hordes of rogue accounts in your system. They go the bar and celebrate all the extra hours they will bill you for ensuring that you fix all the crap they’ve found in your system. Don’t give them reason to celebrate. Identify and exterminate those groups, those accounts. And then YOU can go to the bar. I give you my permission.

Take control of IAM

I do a lot of security assessments. I go into a customer, sometimes with a colleague, and we ask a lot of questions. We inquire as to their current security capabilities, their security concerns and desires, the deltas, the resources they have available to implement solutions to those deltas, the ways in which they would like to improve their processes, their compliance / audit requirements.

One thing that never fails to amaze me is the number of customers with processes that befuddle them. They’ve inherited certain assets, requirements, and processes that mystify them, frustrate them, expose them.

They often speak of these things as if they are out of administrative control. They have way too many Active Directory groups they’re stuck with. They have service accounts whose creators are long gone from the organization, and they’ve never been tracked or reviewed.

So what’s the answer? Take freaking control of your system. You own it, not the other way around.

The first part is political. Somebody in the security group needs to make the bold statement that you don’t care what department created something. That something must be tracked, must be MANAGED. Target accounts must tie to actual users. Service accounts must be periodically certified. The activities of those service accounts must be audited.

These things get out of control in the first place usually because of 1) volume or 2) legacy reasons. “It was here when I got hired.” Okay, understood. But if you’re in charge of security and/or compliance, then it behooves you to be in charge of these things.

One cool thing about a proper compliance-support tool (like Oracle Identity Analytics) is the ability to quickly acquire and manage info about accounts, groups, entitlements. And I you THINK you have some rogue accounts, orphans, zombies, redundant groups, improper assignments, then run a certification. Define a process and assign the certifications to the appropriate managers. The first time through, it’s messy, but after that it’s completely manageable. Get a handle on those objects, those people,

Then once you’ve completed this cleanup, enforce the rules going forward. You may NOT create an AD group off the top of your head. You may NOT create a service account and launch a non-manual process without governance. You may NOT randomly assign target system entitlements without approvals. And if you DO any of this stuff, it will be caught by reconciliation or certification ad you will get spanked.

Be the man. Or the woman. Or just plain person. But BE it. Take charge. And then tell somebody to fix you a sandwich. It’s good to be the king.

IAM: It’s not just for security anymore

One reason IT staff often has difficulty budgeting for security is the impression that it’s overhead.  They make do with Active Directory for a user store, helpdesk for workflow, tokens for access, Crystal for reporting, and optimism for compliance.

Every single vendor will say of their product, “We’ll save you money. We’re faster and more efficient and blah blah blah.” And that’s probably true of all those products, if you deploy them to the best of their ability and yours. But let’s discuss that in a little more detail.

I work mainly with the Oracle security suite. And the Number One thing I’m getting traction on with customers is COMPLIANCE. Twice in the last month I’ve been told by customer contacts (and of course I’m paraphrasing), “I called you in because of our last audit. It’s more important than security.”

One guy even told me, “I won’t get fired if we get hacked. Everybody gets hacked. But I will get fired if we fail another audit.”

And it’s true from my side: I can secure your infrastructure and greatly limit the ability for bad guys to gain access to sensitive apps, resources, or data. But there is absolutely no guarantee in life. However, I can provide pretty good assurance that if we have a good inventory of your compliance requirements, I can vastly improve your ability to successfully get through an audit. Again, no guarantees, but if I can see the targets, I can meet them. As opposed to security, where you don’t know if you’ve missed the mark UNTIL you get hacked.

You absolutely can save money on compliance if you’ve built your compliance processes into the platform. Create and maintain that list of resources, users, and entitlements. Ensure least-privilege. Terminate users in a timely fashion. Provide audit and visibility and reporting.

Okay, so that’s the money-saving stuff. But how about revenue-generating stuff?

You may not be in a position to make money through your operations. But there are several situations  where I’ve been able to enhance revenue generation for customers by business-enabling their services, or make their existing services far easier to engage.

If you make margin by attracting and keeping customers, then here’s a chance for your IAM structure to shine. Make it easy for customers to register, create accounts, establish their access, request new access, and manage passwords, locked-out accounts, and requests.  This is what Oracle Access Manager does best.

Now, your intellectual property only has value if you can control access to it. So you need policies to lock down access to only authorized users. You need to make it easy for those users to authenticate to your stuff, and impossible for anybody else to do the same.

You might also want to throttle that access. Not just who can get the stuff, but how many transactions in a given period, how much bandwidth do they get, how many concurrent sessions they can run, what times of day or days of the week they can get that access. And of course measure all the activity.

If a customer is gold, platinum, silver, if they’re a deadbeat,  if they’re a trial customer, if you’re running a special, if they’re receiving a credit for recommending another customer, ALL of these things can affect access. And you can pull all that off with IAM.

Improve the customer experience, secure that experience, measure that experience, and do it all compliantly.

One more thing: offer your security services as just that, services. Make them available to your customers through whatever means they desire. In the new social/mobile world, that’s how a lot of people want it. Don’t write me an app, offer me a service.

Make IAM work for you. It’s not just an expense, it’s a valuable tool. And it comes in all colors. Ours is red.