How do you mess up an identity and access project?

A "normal" customer visit for me is one in which I discuss how that customer can bolster an existing identity foundation, to provide additional protection, transparency, compliance, and administration. But there are two poles at either end of this. At one end, I've got customers who have little to no identity management. They're still doing everything manually, there is no central management of their many platforms, databases, and applications, and they couldn't tell an auditor under threat of violence or "The Best of Styx" what privileges any given user has.

At the other end are those customers who HAVE put something in place, and have done it so badly that they are looking to replace something that's broken or was never fully implemented. In some cases, they've got perfectly serviceable systems in place but which were not rolled out to completion. I remember asking one customer what was wrong with their deployment of one of my competitor's products, a producct they wanted to replace.

"We're still doing a lot of things manually," they explained.

"Why is that?" I asked.

"Because we never deployed the workflow," they answered.

This made me wonder, would they have any better success with MY stuff, if they didn't deploy MY workflow?

It's just one of a whole LOT of ways you can screw up an identity and access deployment. Wanna know what I think are the Top Ten Ways to Screw Up an IdM / IAM project? Well, I've actually created just such a list, and you can get it here:

http://www.identityaccessmanagementbook.com/download10.html

Have a look, and please let me know what you think. If you've seen other ways to achieve a broken or half-baked identity-access framework, I'd love to hear about them. This is not an excuse to wallow in other people's misery, but rather a way to suck all the mistakes out of the room, so that everybody going forward will get everything right. None of us is as smart as all of us. Except, of course, when my wife's relatives get together.

TODAY’S LESSON: IDENTITY MANAGEMENT FOR HIGHER EDUCATION

As an identity management “professional” (a term for which I qualify because people have been foolish enough to pay me for this nonsense), I’ve had to deal not only with the matter of the technology, but also the individual business requirements of my clients, i.e. the stuff they sweat. I’ve learned a lot about a lot of businesses, industries, verticals, market segments, and so on. Public or private, they all have their own issues and compliance requirements. They also have their own identity and access issues.

One of the more peculiar and aggravating set of requirements is found in HIGHER EDUCATION. Universities often have IT staffs with incredibly long tenures and low pay scales. Nothing much ever changes. When you have meetings, EVERYBODY shows up. It breaks up the monotony. But these people are very dedicated, and know every corner of every system. They’ve built lots of kludgy scripts to create accounts on their unix systems, or to kick off cron jobs for cleanup purposes. They must do a lot with very little budget. They provide space for little skunkworks projects that all have their own databases. There’s lots of sensitive information in pockets all over the place.

Most of my higher ed customers have either Peoplesoft or Banner for their HR app. That’s the easy part, getting users into the system. After that, it gets hairy. Provisioning is largely done by the help desk.

Corporations think they have it hard trying to figure out how to provision and govern access for employees, customers, partners, contractors, and vendors. But higher ed has it even stranger. They’ve got

• Applicants and registrants
• Undergrads and grad students
• Faculty and staff
• Alumni
• Adjuncts and assistants
• Regular employees
• Retirees and emeritus

These different designations are often called AFFILIATIONS. It gets even more interesting when you consider that a person can easily have multiple affiliations. For example,

• A student going back for a second degree is also an alumnus
• Grad students are often assistants
• Plenty of students are also employees (book store, cafeteria, etc.)
• And so on

In addition to these user types, they might also have high schoolers who are given guest accounts, as part of a recruitment program, or to take early college credit courses; program managers for local merchants or municipalities who get free labor from the students in exchange for signing off on community service hours; and associated schools with whom the university might have an exchange program.

At one east coast school I visited, they operate a teaching hospital, with doctors (employees) who are alumni, pursuing additional degrees as grad students, and also teaching. These users have a spider’s web of affiliations.

So what’s the problem there? CONTEXT. A very common app at universities is Blackboard, for managing curriculum, communications, classroom materials, you name it. Well, what if you’re teaching as well as taking classes, and therefore use Blackboard as with multiple contexts? This can be handled creatively through roles or group memberships, of course, or badly by handing out multiple id’s to a user. But wait! At one community college, they showed me their many, many combination roles: student-employee, student-athlete, student-assistant, etc. I showed this to my math-teacher wife, who did some funky things with factorials and figured out that these geniuses could theoretically generate about a billion roles.

On inane thing that many, many schools do is provision a user as quickly as possible, then take forever to revoke that same access. You signed up for the fall term? Here’s your email account, space on the file server, cafeteria card, and dorm access card. Oops, you never showed up for classes, not even once? Well, nobody’s looking, so you get to keep all that stuff until at least Christmas, if not summer. Remember, the turnover at these places is astounding. Students, employees, and student-employees come and go in large numbers each year. Kids sign up for classes and/or jobs, then never show up.

This is where certification is a very good thing. Have all the teachers certify, after the official cut-off (usually a few weeks into the semester), that everybody on the class list actually attends. De-certify the no-shows, so that your excellent provisioning system removes their access to class material. Never came to the dorm? The R.A. should de-certify them as well, killing their access card. They’ve been decertified from all their classes? Then kill their email account, even if it’s being used. In fact, ESPECIALLY if it’s being used. Oh, and also kill their space on the file server, which is likely filled with MP3 files and Torrents of pirated movies.

In the USA, schools must comply with FERPA, the Family Educational Rights & Privacy Act, a federal law that protects the privacy of student education records. FERPA applies to all schools receiving funds from the Department of Education. For younger kids, parents get pretty much any info they want, except in the case of a divorce, where the guardian/parent decides who can see what data. In the case of higher ed, however, the student gets to decide, even if the parent is paying for school. Universities have reported many instances where divorced parents have tried to weasel information out of a school about their kid’s grades, costs, etc. American schools also deal with CALEA, the Communications Assistance for Law Enforcement Act. If you provide internet access (like schools do), you must provide the necessary surveillance capabilities, in case you're asked. While an identity initiative may have nothing at all to do with CALEA, just mentioning it makes it sound like you've done your homework.

Schools with medical or psych programs often videotape exam sessions, and need to stringently protect that media, which is often digitized and stored on a server. If a school has no clinic or medical services, they might still be keeping medical info, and therefore HIPAA matters. If they do provide medical services, then HIPAA really, really matters.

All schools accept credit cards. Many simply accept the numbers but don't store them. Many outsource so they don't have to sweat PCI compliance. One school lost half a million credit card numbers, and paid millions for credit monitoring.

Even though they’re not necessarily corporations, schools believe that SOX compliance is a matter of time. Schools that receive corporate grants must regularly comply with requests related to the money they’ve received.

Another pesky thing that school regularly deal with is subpoenas. Authorities come to them with paper asking for information on

• Who paid a student’s tuition
• Email contents, incoming and outgoing
• File folder contents (what did the stupid kid download?)

Most schools can set their own policy on how long to keep a user’s email around for analysis before they blow it away. They try keeping this timeframe as short as possible.  

This is just a snapshot of what there is to know with higher ed and IdM. If you’re an IdM professional, you also know that schools have been accustomed since the 1970’s to getting hardware and software cheaper than anybody else. You can thank a couple of vendors in particular for that. I won’t name names, because I’ve got enough people who already want me dead.

Buying a suite vs. best of breed

One of the ego-boosting things about the software racket is when long-time customers, even ones to whom you haven’t sold anything in a while, still call and ask your opinion on something they’re considering. I have a handful of these, and I never hesitate to offer them my honest take on whatever it is they want. Trust and credibility mean everything in software, which is so much more nebulous than hardware, or automobiles, or toasters.

So I was recently asked by a long-time customer what I thought of his strategy of assembling a “best of breed” solution for their current needs, as opposed to purchasing a suite. What this means is, he needs solutions for password reset, single sign-on, access requests, workflow, endpoint connectors, auditing and reporting, compliance, and so on. Should he assemble the best stuff out there and string it all together on his own, or concentrate on only one or two vendors, looking for the best solution on average?

Quite often, disparate solutions integrate. Plenty of the vendors talk to each other’s packages, even when they compete. Oracle owns Peoplesoft and Siebel, for example, but every competitor has connectors for these common business apps. Everybody talks to Oracle database. Oracle talks to IBM and CA directories. CA has connectors for just about everything. And so on. There are also generic connectors, such as for relational databases and LDAP. Some of the bottom-feeder solutions in the identity market tell you, “You don’t need provisioning. Just take our roles or profile data and pop your requests directly into your business apps via SPML.” They do this because they’re too lazy or cheap to have connectors, but they conveniently forget the fact that the vast majority of commercial apps don’t (yet) support SPML.

If you think you’ve found the perfect combination of products, and have a sound plan for linking them, then life is good. Maybe. They might have connectors, but you’re responsible for the deployment. If there’s an issue, guess what? The vendors point at each other. And what happens when one or the other sends out a patch, an update, a dot release? How does this affect the integration? Even with a single vendor, customizations are often a problem during an upgrade. What if you need to migrate to the next version of your chosen operating system, and one vendor or the other is behind?

Hypothetically, if you need to cover identity, access, and compliance, and your strategic vendor does a great job with the first two but not the third, perhaps you plug in only that piece from another vendor who does a superior job in that arena. You might also segregate run-time from offline apps. Report writers, auditing tools, and role mining usually run in the off-hours, or at least CAN be. Those might be standalone.

However … a suite from a single vendor can also be a good thing, for obvious reasons:

• Their modules will already be integrated. If not, their building should be burned down.
• Upgrades to those various modules will invariably be correlated, if not by number then at least by functionality.
• Interfaces will (hopefully) be consistent.
• Consolidation under a limited number of vendors means consistency in quality and support. If it’s a single vendor, then you usually have what’s known in the industry as “one throat to choke.”
• There’s no finger-pointing when integration breaks. “They’re ALL your product, so fix it.”
• You can leverage the vendor’s salesguy for a better quantity discount on the consolidated price. In other words, it’s cheaper because it’s not ala carte. “I’ll buy all of it from you, sure. But what will you do for me?”
• Their report writer and auditing tool and SoD library and so on are already designed to know and take advantage of the schema and other aspects of the core tools, so you’re not having to custom-code the integration, create custom schema, or diddle with a bunch of XML files.

So you might consider following the lead of much of the market and consolidating your vendors, at least for the larger stuff. Sure, there are a lot of good, smaller vendors out there as well, with more of a limited menu, and they still have plenty to offer. But in the end, even if you’re running a charity, you’re not running it for software vendors. Do what makes the most sense, in terms of budget, implementation, and ease of support.

                                                      *****

I'm going to spoil my otherwise elegent conclusion with a quick digression on the term BoB. Sometimes vendors use “best of breed” to insinuate that their single product is simply “the best,” or that it’s been through the meat grinder of the market and emerged as a leader. But it’s terribly overused as a descriptor. I know of two startups that use the term “best of breed” to label their barely-known products, only one of which has even a single paying customer to date. In truth, BoB should be used to indicate the mind meld of multiple technologies in a way that produces the optimal business and technical value.



The ugliest compliance process there is

For the sake of transparency, accountability, privacy, security, and other virtuous pursuits, nearly every major government on Earth has enacted numerous regulatory compliance laws. These laws protect your data, determine who must sign off on documents, mandate security perimeters, and demand reporting. But if you really want to boil that down to how it affects you as a security or compliance officer at your company, it’s simple. Compliance is there for a variety of practical reasons:

To keep you secure

To keep your constituents secure

To make your life hell

Compliance mandates a lot of things you should have been doing for the sake of security and privacy way back when anyway. Some seem like plain common sense. The CEO can’t hide behind the shirt tails of the CFO. Transactions should be transparent. The numbers have to add up. Remember that old joke

CEO: So, you’d like to keep our books. Tell me, how much is two plus two?

 Prospective CFO: What would you like it to be?

But if you’re reading this, you probably don’t care much about financial statements, other than limiting access to them. You care about identity and entitlements, and the audit requirements related to those, including the entire security perimeter inventory. Where’s your sacred line, and which resources sit behind it? What are the hard and fast authentication and authorization models guarding them? And who decides which users get what access?

Automated provisioning says what you get on Day One. Request management says what you get on Day Two and beyond. Automated reconciliation (the little bot that runs nightly and takes away out of band access), if it’s available to you, keeps user rights in line. But then there’s the audit-driven version of that: attestation.

Sometimes called certification or re-certification, attestation is that periodic examination by managers of user entitlements. If you own an application or a group of employees, you get asked every few months to review user access. User manager review usually makes more sense, since the guy who maintains an app often has no clue who actually uses it. IT guys aren’t making the business decisions.

How often you certify user access to a resource depends on the sensitivity of that resource. SOX-based apps get reviewed each quarter, on average. Email? Yearly, maybe.

There are two primary reasons this process is so butt ugly. First, it’s manual. It’s that time of year again, so print out the reports on who accesses the financial reporting app. Hand out those reports to all the respective managers, who mark those reports up with different color markers. Green means the user keeps the access. Red means they lose it. Circle it and add a question mark, to indicate you have no idea why this user ended up on your list. Circle it and add a name, and this means you don’t own that user, and you have listed the name of the manager who should have gotten that user on HIS list.

Then all these reports go back to IT, who must yank access on all the red-lined users, resend all the delegated users to the right managers, and LOOK UP the managers on the users with question marks. Holy crap! It’s a lotta, lotta work.

The second reason this process reeks is the fact that all this manual work adds up to lots of mistakes. Users keep access they shouldn’t have, reviewers tend to green-line large numbers of users, changes getting fat-fingered by IT lend themselves to even more mistakes.

Automating this process solves the manual aspects of it, and the ease of use represented by automation cuts down drastically on the mistakes. This is what the Oracle IAM suite provides, for example. Put this process on a timer, per resource, so that it automatically informs you when it’s your turn to certify users for a resource. If you don’t do it within a certain time period, it nags you. When you ignore the nagging, it escalates, automatically, to your supervisor, then beats you with a stick.

When you click the link to actually perform the task, it brings up the list of users you’re responsible for. These users were (hopefully) looked up, automatically, from the org chart, because you own them. Point and click to decide who keeps access, who loses it, and who is unidentifiable, so that those users, automatically, get routed back to the process owner. If there’s somebody you don’t own but for whom you can identify the proper reviewer, you can route them to that proper owner.

No reports, no sneaker-netting the reports back and forth, no highlighter, and nobody falls through the cracks. It’s faster, more efficient, and far more accurate.

Throw in one more excellent curve: role certification, the periodic review of what entitlements are contained within a role, which is how those users got those privileges in the first place. Keep those roles current and compliant as well.

Some stuff you do because you want to, some stuff you do because you’re told to. Compliance is like that in general, and attestation is a whole lot of both as well.

Does this kind of automated process make attestation fun? Hell no. But it makes it cleaner and more useful. It’s like one of those ergonomic rakes that make cleaning up the yard easier on your back. Just remember, no matter how clean and easy attestation is this time around, you’ll be doing it again in a matter of months or weeks, so don’t get too comfortable.



What compliance is, and what it is NOT

A lot of what gets me in the door to discuss identity and access management is compliance. There are a lot of regulations out there for every country, individual regions of different countries, and of course all the verticals (banking and finance, healthcare, insurance, credit card, arms trade, telecomm, anybody who’s publicly traded, etc.). If you’re a publicly-traded US company, you have Sarbanes-Oxley. Even if you’re not in healthcare, you’ve got HIPAA (if you’re large enough). If you handle credit cards, you’ve got PCI. Most companies are subject to multiple compliance laws.

A lot of these laws share provisions, such as strong authentication, access control, attestation, protection of private data, and so on. If you know what those common elements are and institute them in your infrastructure, you can reasonably tell your auditors that you’re compliant, possibly with multiple provisions at a time. And here’s the thing that most C-level execs know: the definition of compliance is negotiable. Most of these laws are written so vaguely, they’re almost always subject to interpretation. PCI is part detail, part fog. SOX has spawned numerous lawsuits as a result. “What do you mean, I’m not compliant? In your face!”

            Compliance is an essay question. “I am compliant, and I say this because I have policy-driven user enablement, I enforce segregation of duties, I encrypt private data, I regularly review access rights and make corrections as necessary, and I log all user and administrative actions.”

            Therefore, with a proper identity and access framework in place, you might have to tweak things once in a while to make auditors happy, but in general you will pass most smell tests. Compliance equals the policies that you have in place to ensure least-privilege (everybody only gets access to what they should have, and nothing more). These policies grant privileges only to those who are eligible, and periodically checks to make sure that’s all they still have, because, y’know, stuff happens. So if you’re running an identity/access framework (eg. Oracle IAM suite), you’re enabling people at the door according to policy, governing their changes (promotion, demotion, transfer) according to policy, and using those same policies to decide how they leave at termination time. Here’s the stuff you can access, here’s the stuff you keep as you move through the organization over time, here’s the stuff you lose instantly when we catch you doing naughty stuff.

            So here’s what compliance is NOT. It is not REPORTING. I hear that term all the time, “compliance reporting.” I hear “SOX reporting” more than I hear “SOX compliance.” It implies that if you can tell who did what and who has what, after the fact, then you’re compliant. Bzzzzt. Wrong. Reporting verifies that you have been compliant all along (or that you’ve been screwing up), but by itself, it doesn’t equal compliance.

            Some laws, like Sarbanes-Oxley, are based on reporting. In fact, SOX is based on reporting two different ways. It’s largely enforced by reporting, and it governs reporting.

http://en.wikipedia.org/wiki/Sarbanes-Oxley_Act

Meanwhile, the Payment Card Industry standard naturally includes, but isn’t entirely dependent on, reporting, since what it’s really governing is data security.

http://security.arizona.edu/pci

            This is not to say that reporting is worthless. Au contraire. Without evidence, you might as well have been sitting on your can while the vultures have been circling your data. You must prove that you are compliant. Anybody who’s ever sat through a security audit knows how ugly it can be for your entire staff. But if you can provide the reports you’ve been generating on a regular basis, along with any custom reports that are requested, and those reports prove that you’ve been enforcing proper policies on access control and privacy, you have put yourself in a good place.

            And of course, reporting also tells you where those tweaks have to be made. The closer you get to full compliance and security, the less work you’ll have to do the following year, when the auditors show up again. And remember, compliance is only getting tougher, and new technology will require new efforts on your part. So doing it right now will make it easier to institute additional safeguards later. It also makes it easier to refine your policies and procedures each year after the auditors find something wrong, and they will, because that’s their job. Auditors do not get paid to tell you that you’re a genius. If there’s nothing wrong with your security and governance, guess what, there will be anway.

            By the time I was through with high school, I wanted to skip graduation. Just give me the paper, and I’m done. But my dad explained it this way: if we didn’t go to the ceremony, with the cap and gown and “Pomp and Circumstance,” it was like I’d skipped high school altogether. And then mom would have made him kill me. So even though I had the education in my head, I needed the paper in a frame.

            So both pieces are necessary, and while the paper by itself doesn’t make you any more secure, it shows the world what they need to know about you. So make yourself safe and compliant, and prepare to provide the evidence.