Confusion over Physical Assets, Information Assets – Part Two
So I need to compile a list of ALL assets, information or otherwise,
NO!
That leads to tables and chairs and powerbars.
OK so you can't work without those, but that's not what I meant.
Physical assets are only relevant in so far as they part of information processing. You should not start from those, you should start from the information and look at how the business processes make use of it. Don't confuse you DR/BC plan with your core ISMS statements. ISO Standard 22301 addresses that.
This is, ultimately, about the business processes.
How much Risk Assessment is needed?
In many of the InfoSec forums I subscribe to people regularly as the "How long is a piece of string" question:
How extensive a risk assessment is required?
It's a perfectly valid question we all have faced, along with the "where do I begin" class of questions.
The ISO-27001 standard lays down some necessities, such as your asset register, but it doesn't tell you the detail necessary. You can choose to say "desktop PCs" as a class without addressing each one, or even addressing the different model. You can say "data centre" without having to enumerate every single component therein.
At first.
How to build an asset inventory for 27001
How do you know WHAT assets are to be included in the ISO-27K Asset Inventory?
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.
Help on ISO-27000 SoA
This kind of question keeps coming up, many people are unclear about the Statement of Applicability on ISO-27000.
The SoA should outline the measures to be taken in order to reduce risks such as those mentioned in Annex A of the standard. These are based on 'Controls'.
But if you are using closed-source products such as those from Microsoft, are you giving up control? Things like validation checks and integrity controls are are 'internal'.
Well, its a bit of a word-play.
- SoA contains exclusions on controls that are not applicable because the organization doesn't deal with these problems (ie ecommerce)
- SoA contains exclusions on controls that pose a threat (and risks arise) but cannot be helped (ie A.12.2 Correct processing in applications) and no measures can be taken to reduce these risks.
With this, a record must be present in risk assessments, stating that the risk (even if it is above minimum accepted risk level) is accepted
The key to the SOA is SCOPE.
About ISO 27001 Risk Statement and Controls
On the ISO27000 Forum list, someone asked:
I'm looking for Risk statement for each ISO 27k control; meaning
"what is the risk of not implementing a control".
That's a very ingenious way of looking at it!
One way of formulating the risk statement is from the control
objective mentioned in the standard.
Is there any other way out ?
Ingenious aside, I'd be very careful with an approach like this.
Risks and controlsare not, should not, be 1:1.
All Threats? All Vulnerabilities? All Assets?
One list I subscribe I saw this outrageous statement:
ISO 27001 requires that you take account of all the relevant threats
(and vulnerabilities) to every asset - that means that you have to
consider whether every threat from your list is related to each of
your assets.
"All"? "Every"?
I certainly hope not!
Unless you have a rule as to where to stop those lists - vectors that you are going to multiply - are going to become indefinitely large if not infinite. Its a problem in set theory to do with enumberability.
See
http://infosecblog.antonaylward.com/2010/05/19/the-classical-risk-equation/
for a more complete discussion of this aspect of 'risk'.
See
http://www.bloginfosec.com/2010/08/23/why-the-risk-threats-x-vulnerabilities-x-impact-formula-is-mathematical-nonsense/
in which Jeff Lowder has a discussion of the "utility value" approach to controls
Because its the controls and their effectiveness that really count.
Audit Frequency
In one of the forums I subscribe to the question came up "How often should one carry out an internal audit?" There were variations on this to do with external audits as well. Lets suppose you aren't one of the relicrant types that take the attitude that audits aren't necessary or that an audit - or a risk analysis for that mater - needs to be done just the once.
How often? Yearly? Ever Six Months? Every Month?
Maybe. maybe not.
If you are one of a certain set of classes of organizations there are rules that mandate when you get audited. For example, if you process credit cards then the PCI:DSS rules apply to you.
If you are a bank, you should check for Basel II and FFIEC regulations.
And so forth.