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 form 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.
Confusion over Physical Assets, Information Assets in ISO-27000
I often explain that Information Security focuses on Information Assets.
Some day, on the corporate balance sheet, there will be an entry
which reads, “Information”; for in most cases the information is
more valuable than the hardware which processes it.
— Adm. Grace Murray Hopper, USN Ret.
Some people see this as a binary absolute – they think that there’s no need to asses the risks to the physical assets or that somehow this is automatically considered when assessing the risk to information.
The thing is there are differing types of information and differing types of containers for them.
Does ISO 27001 compliance need a data leakage prevention policy?
On one of the ISO-27000 lists I subscribe to I commented that one should have a policy to determine the need for and the criteria for choosing a Data Loss Prevention mechanism.
I get criticised occasionally for long and detailed posts that some readers complain treat them like beginners, but sadly if I don’t I get comments such as this in reply
Anton
Data Loss is something you prevent; you enforce controls to prevent data
leakage, DLP can be a programme, but , I find very difficult to support
with a policy.
Does one have visions of chasing escaping data over the net with a three-ring binder labelled “Policy”?
Let me try again.
Policy comes first.
Without policy giving direction, purpose and justification, supplying the basis for measurement, quality and applicability (never mind issues such as configuration) then you are working on an ad-hoc basis.
Remember: CMM plays an important part in ISO 27000
The DLP device you end up with on the ad-hoc basis is just whatever the networking people think they want; it may or may not fulfil business objectives from the POV of other stakeholders.
Oh, and did I mention priority? Priority leads to how you allocate resources such as budget. The business may place a different importance on matters than the network technicians or even the IT managers. But if there is policy that says something should be done then the IT managers can go to the executives and say “Your policy says we have to do this, please give us the means to fulfil your policy”.
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.
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.
Related articles
- Leading ISO 27001 Roadmap Refreshed – Takes Guesswork Out of Information Security Certification Process (prweb.com)
- 4 reasons why ISO 27001 is useful for techies (iso27001standard.com)
- Build resilience into your management system (deurainfosec.com)
- Free calculator: Duration of ISO 27001/ISO 22301 implementation (net-security.org)
- HR controls during employment and ISO 27001 (deurainfosec.com)
Control objectives – Why they are important
http://blog.iso27001standard.com/2012/04/10/iso-27001-control-objectives-why-are-they-important/
Let us leave aside the poor blog layout, Dejan’s picture ‘above the fold’ taking up to much screen real estate. In actuality he’s not that ego-driven.
What’s important in this article is the issue of making OBJECTIVES clear and and communicating (i.e. putting them in your Statement of Objective, what ISO27K calls the SoA) and keeping them up to date.
Dejan Kosutic uses ISO27K to make the point that there are high level objectives, what might be called strategy[1], and the low level objectives[2]. Call that the tactical or the operational level. Differentiating between the two is important. They should not be confused. The high level, the POLICY OBJECTIVES should be the driver.
Yes there may be a lot of fiddly-bits of technology and the need for the geeks to operate it at the lower level. And if you don’t get the lower level right to an adequate degree, you are not meeting the higher objectives.
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.
Surely compliance is binary?
Call me a dinosaur (that’s OK, since its the weekend and dressed down to work in the garden) but …
Surely COMPLIANCE is a binary measure, not a “level of” issue.
You are either in compliance or you are not.
As in you are either deal or alive.
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.
Which Risk Framework to Use: FAIR, FRAP, OCTAVE, SABSA …
What framework would you use to provide for quantitative or qualitative risk analysis at both the micro and macro level? I’m asking about a true risk assessment framework not merely a checklist.
Yes, this is a bit of a META-Question. But then its Sunday, a day for contemplation…
The diagram above represents a generic framework for risk management. (Photo credit: Wikipedia)
When does something like these stop being a check-list and become a framework?
COBIT is very clearly a framework, but not for risk analysis and even the section on risk analysis fits in to a business model rather than a technology model.
ISO-27K is arguably more technology (or at least InfoSec) focused that COBIT, but again risk analysis is only part of what its about. ISO-27K calls itself a standard[1] but in reality its a framework.
The message that these two frameworks send about risk analysis is
Context is Everything
(You expected me to say that, didn’t you?)
I’m not sure any RA method works at layer 8 or above. We all know that managers can read our reports and recommendations and ignore them. Or perhaps not read them, since being aware of the risk makes them liable.
Ah. Good point.
On LinkedIn there was a thread asking why banks seem to ignore risk analysis .. presumably because their doing so has brought us to the international financial crisis we’re in (though I don’t think its that simple).
The trouble is that RA is a bit of a ‘hypothetical’ exercise.
The real reasons for documentation – and how much
he documentation required and/or needed by ISO-2700x is a perenial source of dispute in the various forums I subscribe to.
Of course management has to define matters such as scope and applicability and the policies, but how much of the detail of getting there needs to be recorded? How much of the justification for the decisions?
Yes, you could have reviews and summaries of all meetings and email exchanges ..
But that is not and has nothing to do with the standard or its requirements.
The standard does NOT require a management review meeting.
Risk Models that hide important information
Some people seem to be making life difficult for themselves with risk models such as “Impact * Probability” and as such have lead themselves into all manner of imponderable … since this model hides essential details.
I discuss the CLASSICAL risk equation in my blog
http://infosecblog.antonaylward.com/2010/05/19/the-classical-risk-equation/
There is a good reason for, no make that MANY good reasons, for separating out the threat and the vulnerability and asset rather that just using “impact”.
Any asset is going to be affected by many
- threats
- vulnerabilities
- controls
Any control will almost certainly address many assets and in all likelihood deal with many threats and vulnerabilities.
Any reasonable approach will try to optimise this: make the controls more effective and efficient by having them cover as many assets, threats or vulnerabilities as possible.
As such, the CLASSICAL risk equation can then be viewed as addressing residual risk – the probability AFTER applying the controls.