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.