How to build an asset inventory for 27001

How do you know WHAT assets are  to be included in the ISO-27K Asset Inventory?

SOMF Asset Patterns

This question and variants of the “What are assets [for ISO27K]?” comes up often and has seen much discussion on the various InfoSec forums I subscribe to.

Perhaps some ITIL influence is need.  Or perhaps not since that might be too reductionist.

The important thing to note here is that the POV of the accountants/book-keepers is not the same as the ISO27K one. To them, an asset is something that was purchased and either depreciates in value, according to the rules of the tax authority you operate under, or appreciates in value (perhaps) according to the market, such as land and buildings.

Here in Canada, computer hardware and software depreciates PDQ under this scheme, so that the essential software on which you company depends is deemed worthless by the accountants. Their view is that depreciable assets should be replaced when they reach the end of their accounting-life. Your departmental budget may say different.

Many of the ISO27K Assets are things the accountants don’t see: data, processes, relationships, know-how, documentation.

I used to give the example of 9/11 in my presentations. Many of the SMBs and mid-size companies that had offices in the Twin Towers went bankrupt even though the insurance covered hardware loss and they had backups. What was lost was the know-how, the stuff in people’s heads and other intangibles.

Sadly, that’s a good way of looking at the “What is an Asset” question.  Treat it like a Business Continuity (as in disaster recovery) question. What do you need to get running again if you had a ‘hot site’ with all the equipment?

There are, I suppose, two there takes on this question.

The first is “how do you record it?”
It doesn’t matter, so long as you do and the information is accessible (since it too is now an asset) and satisfies the Auditor.

The other is “how do you collect the information?”
Perhaps the best way I can answer that is “go google” for the inner workings of SOX. To  meet the requirements of SOX (as well as many regulations imposed on banks) business processes have to be documented, the work-flow, the accountabilities and so forth. SOX has a more limited scope but the techniques are well documented because the Big N-1  Accounting firms ended up with processes guides & check-lists they could give to juniors to carry out :-/ Look those up, they’ll tell you who to ask questions of, what questions and how to convert the answers into something meaningful. It isn’t all that you want, but its a start.

Personally I use COBIT. Version 3 has a lot on the who to interview and what to find out; version 4 has many ways of expressing the nature of the information and reporting. version 5 is in the process of being released. Version 5 integrates Value and Risk and is pretty amazing.

What COBIT has done for me has guided the analysis and identification of what information InfoSec needs to operate effectively and what is needed to satisfy the auditors. As ever, you need to consider scope.


Enhanced by Zemanta

About the author

Security Evangelist

Leave a Reply