Posts Tagged ‘Identity Management’

If you search on “IT Audit” you will return pages and pages of relevant hits. I have no idea how many pages you have to go out before you hit the end of relevance but it’s more than I care to read. And here I am adding one more.

How can I sort out what I need to do about IT Auditing between what the audit firms, vendors, government (regulation), upper management, and Board compliance committee are telling me to do?

I spent just enough time as an internal auditor and an external auditor in my misspent youth to have yet another opinion to express and I’m going to use a couple posts to do it.

When it comes to IT Auditing, the value that should – in theory – be derived is that an uninterested party (not you) can attest with reasonable certainty that what you SAY you are doing is actually what you are doing. Those policies you say are protecting your mission critical information? They’re actually being implemented and followed (two separate tests there) .

There’s a month’s worth of blog fodder there. But to close for today let’s drag out Rule #1 of IT Auditing. It is not possible to audit yourself. Unless you are the only person you need to satisfy with an audit.

By way of example, in Identity Management circles there is a tendency to call something an Identity Audit (IdA) tool if it creates a record of an activity executed by an Identity Management System (IdM). This would, according to Rule #1, be a valid audit if the IdA tool were completely independent of an IdM tool (not from the same vendor for example) and whose audit strategy (implementation and configuration) was controlled by an independent party from you. But most of these tools are not independent of the tool they audit and therefore are incapable of satisfying Rule #1 of Auditing. We could call them attestation tools (they attest to what was done) but they are not audit tools.

We were talking to Eric Norlin about 2008 trendspotting. Given NetVision’s core raison d’etre we see a growing groundswell toward what we are calling “context” (see Eric’s post). Eric expanded our definition – which is good. But let me clarify what we mean for in our narrower definition for a second.

What we’re seeing is identity management monitoring (at least in a corporate context) being used as a stalking horse for achieving proof of compliance and risk management regarding the insider threat. As in: “I am required to demonstrate that I have control over admin rights so I need to monitor this group membership for all changes”, and other similar examples.

What we’re also observing is that providing such security (or evidence thereof) requires trolling through a lot of event data – often after the fact. As a result we’re seeing more and more customers asking us to link our risk assessment product with our change auditing product so that the search for risky behavior isn’t unguided. That’s what we mean by context. Instead of looking at the universe of data after the fact in order to document a conclusion you instead target your data gathering to areas of risk and obvious policy violation in the first place.

I am no expert on the subject of listening in on the phone calls of the world to find evidence of a threat to national security. But I believe what we’re talking about is metaphorically equivalent to whatever the national government does in order to decide what to listen to.

The question we hope to answer is: “Can this be done without creating a false negative” or overlooking a breach of security or policy which doesn’t rise to theoretical definition of risk. More on that later but opine if you have one.

I recently published a whitepaper entitled Policing the Power of Identity. It’s a vision (mine anyway) for the future use and success of identity in corporate computing. Use of identity gives us a “handle” to use in consistently assessing, analyzing, monitoring, etc. insiders. We developed multiple, fairly mature disciplines for dealing with “outsider” threats (firewall, IPS, anti-SPAM, anti-virus). We should have the same goal with protecting ourselves from insider threats – which are prevalent.

I could be accused by a reader of this whitepaper of giving the impression that I think identity is the problem. That’s not the case. But as corporate IT uses identity more exhaustively for all its good purposes then identity becomes a handy mechanism for identifying insider threat – both potential and realized. This process could most accurately be described as “Policing Computing Power BY (using) Identity”. But also, casually used, identity can create a false sense of security. And in such an imperfect-use scenario identity itself can be a problem (or more accurately, poor identity management can be a problem). In that case the process we prescribe is accurately described as “Policing the Power of Identity”. And such cases are exceedingly common if our IT customers and contacts are any indication.

Either way, our goal is never to attempt to cast identity itself as bad. But instead, to identify practices, tools and standards that use identity to provide better security and to improve identity management (aka security) practice. Along the way we believe that proof of compliance with regulations, policies or best practices will be a natural by-product of our efforts; at least in the area where identity is implicated.

If this sounds like an interesting line of discussion to follow, join the conversation or let me join yours. We’ve had a number of offline comments back on the premises in the whitepaper. I’ll add those to this blog in imminent posts.

Categories

About the Writer

I'm about figuring out what it takes to make cool technology get usefully used on a large scale. Today I'm the president of NetVision where we are doing everything we can to make the use of identity in organizational computing a really transparent - and thus inherently secure - process.