The Black Book of Identity Access Mgmt
This form does not yet contain any fields.

    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.”


    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.


    How to pass that audit

    As promised, here’s my quick and dirty guide to the inventory of digital and physical assets you need to have handy whenever compliance or security auditors come calling. I have some lovely and grotesque true stories behind some of these, but we’ll tackle those another time. This is indeed the Cliff’s Notes version.

    These are the things that auditors will ask for directly, or in some cases I’ve included items which, if you have them, you will indirectly provide something else they’ll bug you for.

    Inventory of assets: servers, app servers, APPS, databases, directories (LDAP), load balancers, firewalls, web servers (including plug-ins), identity-authentication-authorization mechanisms, and so on. In other words, the systems that run your business as well as the systemsthat PROTECT those systems.

    Authoritative sources: the things that say what you can have. For example, “If a user is in the HR system with a status of employed=Y, then they automatically get email and a phone.” HR and payroll systems are common authoritative sources. It’s common to have more than one, but bad practice to have MANY. By the way, a person cannot be an authoritative source.

    Policies, processes: how things happen. A policy is, we make users change passwords every sixty days. The process is, our IAM system is configured to enforce this policy. How do you enable and disable users. How and when are reports generated. And CHANGE MANAGEMENT. Promotions, demotions, transfers, and the really big one, terminations, whether nice or for cause.

    Legacy systems: they’re often left out because the cranky old guys who run them don’t like it when you include them in IAM architectures. “You’re not installing that %#^$ on MY box, Junior,” a guy told me in Indy once.

    Dev and test procedures: how do you launch new apps or systems, whether homegrown or store-bought? Do you test code? Penetration testing, for example. If you use production data for testing, do you MASK that data to conceal PII for dev and test teams?

    Data security: are you encrypting sensitive data? I can’t believe the goobers who end up in the news when they allow the escape of data that was in the clear. It needs to be scrambled in production, over the wire, and in backup. And how are you auditing? Do you watch who does what with the data? This includes DBAs and other privileged users. Do we not trust DBAs? No, we love them to death. But we worry about their accounts being compromised. And yeah, once in a while one of them DOES do something naughty.

    Segregation of Duties: how do you develop those policies, how do you review them, how do you enforce them.

    Privileged users: do temporary duties get an end-of-life? Do you audit what privileged users do? Do you watch service accounts to make sure they ONLY do what they’re supposed to do?

    Reporting: is anybody tasked with reading exception and other reports and looking for anything actionable? Do you review alerts, even the non-critical ones? They often point to potentially bad behavior early on.

    Exceptions: are they documented? Most of them are acceptable, if you are aware of them AND you’ve documented them. “It’s in my head” is not documentation.

    Certifications: access reviews, in other words. How often do you conduct them, and do you take action against them. And make sure you’re not just rubber-stamping people to keep existing access without an actual review.

    Disaster recovery plan: in chaos comes opportunity, often for bad guys. A customer of mine copied live data to an unsecured machine, and bad stuff nearly happened, while they were attempting to get back online after a meltdown.

    Threats: do you know yours? Are people trying to hack your grid, steal your credit card info, muck with your servers? Have you identified your most likely enemies? Because all this leads to …

    Risk assessment: How do you determine risk? Do you grade it (here’s a yellow alert, here’s a red alert, etc.)? Risk must be calculated, and re-calculated, dynamically. Also transactionally. You might assign a risk score to a privileged user, and also to a privileged app account. But don’t forget the other factors. The trusted CFO looking at financial data is a little riskier if he’s doing it at 2 am on the weekend from a mobile device. Is that really him?

    DOCUMENTATION: everything needs to be captured. Everything I just talked about needs to be in a doc, or set of docs. Don’t EVER let an auditor tell you something about your environment you didn’t already know. It’s what auditors call “proof of compliance.” All the security and compliance in the world are meaningless if you can’t prove it, at least in terms of an audit.

    There is WAY more to this subject, of course, but these are the high level must-haves. If you’re really sweating your audit and/or the aftermath, then it’s probably well worth your while to bring in help to take a pre-inventory and get you on the rails. Failing an audit is costly and embarrassing. It brings me a lot of business, but at the expense of my customers. Don’t be one of those guys.



    Are you up to code?

    I've been doing a whole lot of talks lately about HOW TO PASS A SECURITY AUDIT. All too often, I get called into customers after they've failed an audit. Recently I received an invite to speak with a customer who knew they were woefully unprepared. They think they know what they need to do. And sometimes it's surprising when people in a particular industry, who presumably are paid to know the regulatory rules for said industry, don't understand the actual nitty gritty of those regulations. They've read the docs, but haven't translated that into duties and responsibilities (which are similar yet different) that can be understood by the people whose job titles or descriptions include those duties.

    As I've written before, security is NOT compliance, and vice versa. You can be compliant, but still be unsecure. Likewise, you can be relatively secure (remembering that nobody is ever completely breach-proof) and still fail an audit.

    But people confuse these two all the time, and don't understand where security and compliance overlap and where they are irrelevant to each other.

    Too often I'm also asked to help with "compliance reporting." And I remind folks, reporting is not compliance either. It tells you after the fact that you've been compliant, and provides what auditors call "evidence of compliance." But reporting is the thing that comes afterwards. Security and compliance are the things you're providing every minute of the day.

    The attendance at these speaking events, and the questions afterward, indicate the intense interest in the subject. But still there is a lot of uncertainty out there. In a sales cycle with a utility customer a handful of years ago, I beat the competition, who showed up and said, "here's our junk," by saying "here's MY junk and how it helps you with NERC CIP." I then became that customer's education program on NERC, because they hadn't established one yet. They conceded that they had all the documents on NERC CIP, but hadn't figured out how to translate them into tactical, day to day activities.

    Everybody knows they're supposed to be compliant, just as they know they're supposed to be secure. They just aren't always sure how to get there, and how to use the same efforts in some cases to achieve both.

    Next time, I will summarize the kinds of assets, processes, and knowledge base you need to pass a security audit AND bolster your security at the same time.


    Decisions, decisions: You CAN get there from here

    It’s not enough to simply make important security decisions. You have to provide your documented reason for each decision. The only person who really gets away with deciding something without justification is your mom.

    “Mom, why can’t I have a cookie before dinner?”

                    “Because I said so.”

                    Justifications are good things. First off, they’re part of the documentation process. Auditors want to know why and how users received entitlements. They want to know why those entitlements were later revoked. If you somehow mitigated an SoD violation, if you approved an override to a policy, if you granted temporary privileged access, you need to say why.

                    These justifications also lead the way to future decisions, by way of setting precedents.

                    So here’s how information serves you. If you’re an approver looking at a request for additional access, you might say, “I don’t know the requester that well. Or he’s only been in my department for a week. Or I haven’t yet determined the level of risk the organization deems acceptable for this kind of request. And so on.”

                    So how do you make yourself comfortable, or at least cover your butt? Examine what other people in the approval chain said. Who approved their piece of the request before it came to you? What else does the requester already have in terms of entitlements? What has he had in the past?

                    Now, let’s say it’s time for you to certify users for existing privileges. “Here are all the people who can currently access this application. It’s that time of year, so let’s review who keeps it and who loses it.”

                    So you create a certification process in analytics, and reviewers receive their lists of users they are required to certify. Okay, now I’ve got a guy on my screen who may or may not need to keep that access. But again, I don’t know if I have all the info I need to make that decision. So I should be able to readily examine the risk level, the combo of the user and the privilege. And I should be able to click a link and see how long he’s had that access, or HOW HE GOT IT. Was it a request, and if so, was it was requested by him or his boss? Did he get it automatically, based on rules that acted on his profile in the HR system? Did he get it in some back-door fashion, bypassing the appropriate approval process?

                    Okay, so he got it through a request. I can click another link and see all the people who originally participated in the approval process.

                    I can even see what other people have that access.

                    In my world, I would use Oracle Identity Manager to make those requests and approvals, and Oracle Identity Analytics to perform that certification. In the broader world, I need to make sure I stay secure, and I need to stay compliant, by making the right decisions for the right reasons. Oh, and by the way, once I make those decisions, I also add to the greater documentation posture, so that the next person in my position can also make good decisions. Because, y’know, I only do smart stuff, so you should do what I do.