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.

Making intelligent IAM decisions

Like much of the country, my area had local elections this past Tuesday. I haven’t missed an election since 1980, because I think everybody who CAN vote SHOULD. Leading up to it, we got hit up for our opinions, our vote, our front yard (for placement of signs). We received a robo-call from a lady running for the library board, and on this call, she read, very badly, from an index card. Not a ringing endorsement.

We were also hit on to vote for a particular individual who I personally think is full of it. I’ve heard him speak on a number of issues over the years, and discovered that he will tell you whatever you want to hear. I knew enough about him to know that I would never vote for him. There were other people running, of course, but I didn’t know enough about them to take a swag at them. There were flyers on our doorknobs, editorials, position statements in the paper, televised speeches, websites. But when you’re on two to four planes a week, it’s hard to keep up. And therefore it’s hard to make informed decisions.

But when you’re in charge of identity, access, security, and compliance, you can’t use that excuse. You MUST make informed decisions. And you need to provide justifications for your decisions. If you provide access to a user, if you provide entitlements, if you recertify somebody’s existing entitlements, you need to have all the necessary info in front of you.

It’s all about having all that info, right? So you want the info to be there, and you want that info EASILY RETRIEVED. I mean, you’ve always got the data someplace, but the trick is to have it handy. It’s a pain in the wazoo if you need to print a bunch of reports, correlate them, perform a ton of queries. Ouch.

Imagine you get a workflow-driven request to approve somebody’s access. And imagine it’s somebody you don’t know. You could make a bunch of calls, send some emails or texts, and then make the decision. Better yet, the system could instantly cough up what other entitlements this user has, his entire profile, his risk score. You could call up who else in the workflow chain has already approved it, or who else would follow you in the decision tree. This would let you make that informed decision. It would also, let’s be honest, be a little CYA.

And now it’s time to certify existing user access. Should the user in front of you keep his access? Should he lose it? Do you know enough about him to make any kind of decision?

Ideally, you would have immediate access to what else that person has access to. His roles. His entitlements. And once again, for CYA, you might want to know his certification history.

If there’s some question in your mind as to whether the user has the access legitimately, you might want to know how he got it in the first place. Did he request it? Did his manager request it for him? Was it given to him automatically by the system once he was entered into the HR system? Any of these lend to legitimacy. But if you can’t tell HOW he got it, it might be a clue that he backdoored into it. For example, he may have gotten membership in an Active Directory group via that poor man’s provisioning tool, the AD admin console. Big no-no. And maybe he SHOULD have the access, but didn’t get it the right way, meaning it’s poorly documented, so he needs to lose it, then come back in the right way.

This is one of the reasons I dig the latest version of Oracle Identity Governance. I can always access the information I need in order to make those informed decisions. It keeps me secure, it keeps me compliant, and most importantly, it keeps me out of trouble. I don’t want to elect village trustees who might set the town on fire, and I don’t want people having access they shouldn’t have because they might set the entire company on fire.

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.