Archive for the ‘IT Audit’ Category

Access Audit as a Service

December 4, 2008

NetVision announced our new Access Audit Managed Service offering today.   After years (more than a decade – in fact) of providing software tool sets to our customers we saw a distinct outcome in some customers.  This outcome is fairly common to Enterprise Software overall.  The problem outcome is under-utilization.

Frequently a compelling event such as an audit or a technology migration surfaced the need to measure something discrete.  And tools were bought.  And one of four ouctomes occurred:

1) Successful deployment, value is realized as expected or more (yeah for everyone!)

2) Never deployed.  Shame on everyone – vendors hate this probably more than the buyer hates it.

3) Deployed and well used but champion left the company.  And no subsequent champion stepped into his/her shoes so practices, methodology and value start a downhill slide

4) Deployed but for a very narrow, unsatisfying purpose.  The bloom is off the value “rose” pretty quickly.

Thus our impetus for SIMON (it simply stands for Simple Monitoring).  Our goal is to be able to deliver best practice as an outcome rather than as a capability.  Some of our customers prefer the DIY (do-it-yourself) strategy – that’s fine with us too.  But for those who cannot dedicate a methodology champion or who recognize the problem but perhaps not the breadth of the solution that is available, SIMON delivers the entire methodology and service management so that the customer can just consume the result.


IT Audit Rule #3: Compliance is not a byproduct of an Audit

April 29, 2008

IT Audit Rule #1: An Audit Is An Arms-Length Process (e.g. a system cannot audit itself)

IT Audit Rule #2: IT Audits Don’t Prevent Loss

IT Audit Rule #3: Compliance Is Not a By-Product Of An Audit

This statement should be pretty obvious from the discussion of Rule #2. But just as a refresher. And audit is a measurement and verification tool. In the compliance case, about whether an activity and a state complies with whatever standard you’ve chosen to be compliant with. But an audit doesn’t make compliance happen.

A while back there was an interesting debate between Mark Macauley and Ian Glazer about Compliance and whether it could be delivered as a service (CaaS). At the end of Mark’s final response on the topic he uses these words – rather intentionally I suspect: “Compliance is 100% cost at the end of the day, and companies who have figured out that it is in their best interest to automate every process to be compliant, and automate the measuring of that process……….”

Let me take the liberty of making a taxonomy out of that:

– “automate every process to be compliant” = automation which channels behavior in acceptable ways (e.g. user provisioning).

– “automate the measuring of that process” = automation of an audit

Audits can measure compliance, but not make it happen…..except in the limit, where audit findings prompt better mechanisms to channel behavior in compliant ways. Again, this point is probably an obvious one but I continue to be surprised every time I have a discussion with someone about how to get an audit tool so they can “be compliant”.

IT Audit Rule #2: IT Audits don’t prevent loss

March 19, 2008

Sorry to leave this topic open for so long since the last post. Financing activities take top priority for a private company….enough said.

Let’s talk about IT Audit Rule #2. Remember these are my rules, not an official set of commandments. But based on some experience in auditing.

IT Audit Rule #2: IT Audits don’t prevent loss.

Security’s intent is to stop loss. Audit’s intent is to verify the accuracy of something; typically by checking a sample of outcomes but also by making sure that critical controls are functioning. The theory of an audit is that if the right controls are consistently working then the thing being asserted (in this case your data’s accuracy or the state of your data security or privacy) is probably accurate.

Does an IT Audit help security? Absolutely. It will help to point out where weaknesses exist; where controls might be needed to prevent loss or inaccuracy.

And here’s one of the beauties of technology and automation. You literally can audit every event as it happens with automation. So instead of sampling a few transactions and seeing if the outcome was right, you can audit every transaction to see if the outcome was right. Not only that it occurred (see last post for flaws of IdA products for auditing) but that it was right.

But here is the Corollary to Rule #2: Don’t ask an IT Audit product to provide security. For the simple reason that if an IT Audit product now is reversing or stopping inappropriate events, it can no longer be trusted to audit (See Rule #1). It is tampering with the evidence of whether the processes and controls it is auditing are actually working.

Two separate processes need to exist in IT. The security process that tries to create an outcome. And the IT Audit process which verifies that the security process is working. If you have the option, don’t trust the vendor providing one solution to provide the other (Back to Rule #1).

IT Audit – What is it?

February 18, 2008

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.