Posts Tagged ‘IT Audit’

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

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

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

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.

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.