Thoughts on ISO 27005
First, many readers sent us the New York Times/Slashdot “Risk Management” link. Thank you!
The beginning of a reasoned response was written by Aleks on Andrew Gelman’s blog (http://www.stat.columbia.edu/~cook/movabletype/archives/2009/01/dont-blame-it-o.html).
Long-time readers of this blog will recall that I believe that Risk Estimation != Risk Management.
We security professionals have a really good idea of why Risk Estimation is not all there is to the management of risk based on our experience. You, smart guy or gal that you are, know that having a control in place, or even having a point-in-time positive test of that control’s effectiveness does not make you ’secure’. It’s some evidence of security, sure. But there are other variables that we must understand, like the ability of the threat to overcome/bypass the control, the skills and resources of those operating the control, our ability to properly manage those people, etc. These things all contribute to security (and therefore, ‘risk’).
Similarly, if Wall Street folks were only using VaR as a means to understand their portfolio risk, or just plain lazy while the market kept going up, that’s not necessarily a failure of risk estimation or risk analysis as it is of risk management. But some very high profile critics of Wall Street are focusing on the means of estimation that VaR produces, and not the deficiencies in the concept of risk management. The article does say one or two things about that:
You face the risk that, in the current state of the world (assuming you can estimate that perfectly), an unlikely event will occur. You also face the risk that the state of the world will change. VaR … can quantify the first risk, not the second.
And understanding the”risk” (what a poor choice of words there, mixing and matching terminology) of that change and our ability to adapt to it is the essence of risk management. So speaking of the fact that Risk Estimation != Risk Management, I finally got around to reading:
INTERNATIONAL STANDARD ISO/IEC 27005
First edition 2008-06-15
Information technology — Security techniques — Information security risk management
Technologies de l’information — Techniques de sécurité — Gestion du risque en sécurité de l’information
As you can probably guess, I’ve got opinions. And since we’re both here (me writing, you reading) why don’t I let you know what those are.
I have a few disagreements:
ISO 27005 IS NOT ABOUT THE MANAGEMENT OF RISK
First, in agreement with our discussion above, is that 27005 has very little to do with the actual management of risk. It’s really an issue management framework where we create a statement about risk for a very particular scenario, and then tie a Plan-Do-Check-Act cycle to the back of that wagon with the hopes that the issue doesn’t become “red” again. 27005 suffers from the same problems as those who on Wall Street who over-relied on VaR as the end all of Risk Management. It’s whack-a-mole with a hamster-wheel-of-pain sprinkled on top, and does very little to address the root cause of risk - deficiencies in our capability to manage risk.
ISO 27005 HAS ITS PRIORITIES BACKWARDS
Second, and probably due to this inaccurate view of risk management, is their discussion on the purpose of risk management. I believe that the purpose of risk management is to align the risk exposure of an organization to that organization’s risk tolerance. The ISO, not so much.
In section 7.1 (which seems awfully late in the document to start discussing the reason we’re all here today) 27005 states:
It is essential to determine the purpose of the information security risk management as this affects the overall process and the context establishment in particular. This purpose can be:
- Supporting an ISMS
- Legal compliance and evidence of due diligence
- Preparation of a business continuity plan
- Preparation of an incident response plan
- Description of the information security requirements for a product, a service or a mechanism
This is all kind of backwards to me. An ISMS, BCP, or IRP are not *reasons* for risk management. Rather the management of risk is a reason to have an ISMS, BCP, or IRP (or not have one, depending on the organization’s tolerance for risk). Similarly, compliance and due diligence are executed because executive management has no tolerance for adding those sorts of losses to the risk they already face.
ISO 27005′S VIEW OF THE ROLE OF ASSETS IS FLAWED
Now with those two disagreements behind us, I actually have very little critique of section 8.2 - risk analysis. I could launch into a rather wonkish discussion about controls and vulnerability and talk at length as to why FAIR provides better definitions, but I think these differences are less important because the fundamental differences in these differences are less pronounced than other significant deficiencies. Deficiencies such as the one we’ll find in 8.2.1.2 -
8.2.1.2 Identification of Assets.
An asset owner should be identified for each asset, to provide responsibility and accountability for the asset.
Great, as long as the asset owner is really in the line of business that the asset generates revenue for.
The review boundary is the perimeter of assets of the organization defined to be managed by the information security risk management process.
WHOOOOAAAAAAAAAA! - This “Review Boundary” you speak of is dynamic. Think Jericho. Think Vendor Management. Think 100,000 user networks in which 60,000 of the users are not w-2 employees. Think of “The Cloud” (won’t someone please think of The Cloud?).
Consider the following - malware infects home PC, home PC used to capture home banking creds. Those creds are then used to create fraud. Bank is effected, but the Point of Attack (home PC) is not bank owned. According to ISO 27005, this isn’t an important source of risk, as you’re not expected to measure it. I really think there are problems with completely ignoring the fact that assets we don’t directly manage contribute to the amount of risk we have.
DESPITE ALL THIS, 27005 IS FORGIVABLE UNTIL YOU REACH THE ANNEXES
Next, lets talk about the annexes. To be fair (*cough*) without the annexes the ISO isn’t a bad ’standard’. It is purposefully vague where it needs to be vague, and purposefully specific where it needs to be specific.
Unfortunately, someone thought that we needed more direction and tacked on several annexes. The first problem with these annexes is that they’ll be taken for gospel even though they are meant to be “informative”. And if they were any good, that wouldn’t be so bad. However the threat and asset valuation ones are disturbingly average for our industry, which is to say, not well thought out at all. And in some places these annexes are just wrong. To whit: Annex E page 50 asks you to perform mathematical functions on ordinal values:
The third step is to calculate the measure of risk by multiplying (b × c).
I just multiplied Peanut Butter by Airplane and that equals 723.58!
THE BIG PROBLEM
My final problem with 27005 is that it just wasn’t needed. It doesn’t really add anything remarkable or special that we don’t already have in place in any number of other documents and standards. It would seem that its only demonstrative use is for the purposes of auditing to standard compliance. And I have to think that this is really what this document is all about, something more to serve the ISMS and the cottage industry that surrounds it. And that’s a shame, because the field of risk management could really use someone like the ISO really putting forth a significant and good effort.
Eric Jan 6
27005 doesn’t really do a good job at helping build a risk management program. It seems more geared to risk analysis, than a a Risk Management process/program that builds a framework for assessing risk. If I were to implement the standard in my organization, I’d have to hire 5-7 people just to identify each and every asset in our org. That’s just the physical asset, what about grouping of assets (PCI Systems, HIPAA Systems, et al.)? It’s a nasty piece of awful. I’m beginning to think ISO is playing a little too hard in the intangibles.
dunsany Jan 6
Alright, I promised some comments and here they are:
“ISO 27005 IS NOT ABOUT THE MANAGEMENT OF RISK”
Correct, it’s only part of a well-balanced breakfast . 27005 is a risk ANALYSIS standard to be used as part of your risk management efforts. However they might have sold it or even introduced it, it’s a risk management standard meant to be plugged into an ISMS model. Those of us who were doing ISMS back in the day had to choose our own risk model , but now ISO has gone forward and published an “official” one. And yes, it’s weak and very unspectacular. Then again, so are all ISO standards, the very definition of committee consensus.
“ISO 27005 HAS ITS PRIORITIES BACKWARDS”
If you’re using it for risk management, then you are correct - someone is missing the point. ISO 27001 is about how to do risk management. 27001 describes how you match up your risks to assets and let management choose mitigation strategies. You can get some control ideas from ISO 27002. You get advice on how to implement in ISO 27003. Measure your progress and effectiveness using ISO 27004. You have to buy the whole set to get the whole picture.
“ISO 27005?S VIEW OF THE ROLE OF ASSETS IS FLAWED”
Or more accurately, it’s simplistic and myopic. Back when I was doing ISMS work, I was begging for a standard way to do asset analysis. We did come up with one, but it was proprietary to the place I was at. Now someone needs to step and publish an open one. Hopefully something that is modular enough to be used with a variety of risk analysis and risk management methods.
“My final problem with 27005 is that it just wasn’t needed. ”
Yes, this late in the game, there are plenty of other choices for risk analysis methods that can be used. Why officially sanctify a watered-down version of ALE and sell it as a ISO standard? Probably because some checklist-oriented novice demanded it and there was money to be made.
As for me, I use my own flavor of FMEA to do risk analysis (with a few major adds from other disciplines and models). I like it because it disconnects itself from the causes (which speeds things up) and it provides a bottom-up approach (which is fresh). I think FAIR is pretty nifty too and if I were consulting again and needed to hand an organization a recipe on how to do comprehensive RA, I’d probably point at FAIR.
Biggest problem I see in the world is that people pay lip service to risk analysis in general. Most of what I’ve seen that passes for RA is a short list of possible scenarios and/or vulnerabilities. So if they’re going to use a 2K5 or nothing, at least, they’re starting somewhere. Hopefully once they start using it, they realize there are more useful ways to skin that cat.
The ironic part is that most of us with experience in the field have better ways of doing all the things the ISO 27000 standards define. So for many of us, it’s a lot of “eh, that’s nice”. The secondary value is that it’s a repeatable standard that I can follow and document to, which makes the auditors happy. Luckily it’s a lot more flexible than other standards (cough, PCI, cough) so I can still actually get some meaningful security out of it too.
Poettinger Feb 13
concerning the annex
most of the stuff is directly copied from EBIOS which is available for free…
Heartburn Home Remedy Apr 15
Hey, nice tips. Perhaps I’ll buy a glass of beer to the person from that forum who told me to visit your site
Matthias Jan 13
@dunsany: “As for me, I use my own flavor of FMEA to do risk analysis (with a few major adds from other disciplines and models). ”
That sounds great, as - although I’m an risk analysis newbie - I’m planning to use FMEA as well. Would you mind giving me some more ideas about your FMEA flavour? Thanks!
Tedjok Feb 21
Great info. This will be really helpful for me since I am an ISMS Consultant.
M4x Mar 25
I just read this old post about ISO27005. I must agree on some of it but disagree a lot on many areas. I maybe not have the same perspective as you have but I think you’re totally wrong on being the ISO27005 as backwards. It could be but it’s not from an infosec person. It’s a good guide on people with some background on infosec and risk management. I’ve used the old British standard way back in late 90s until 2003 as part of my only job performing risk assessments. Today, with some help from many standards and frameworks including this so called backwards ISO27005, FMEA, NIST, OCTAVE, FIRM, SOMAP, FAIR and others, I was able to derive my own RA methodology. Some people will claim that one is better than the rest, I am sure someone will. In 15 years just doing Risk Assessment of many things (primarily IS and Operational Risks), I came to a conclusion that each one of these standards have some strengths and weaknesses. For everyone in this business, I strongly suggest looking at these above standards and make your own assessment (basically, learn and try them out). In the end, you will realize that not one framework will satisfy you.
blackjack Apr 14
I agree with m4x.
But I’ve got my own opinions too.
I would just like to add that this has always been the way of ISO, to be agnostic. You won’t find specific steps here, because I believe it takes a significant amount of understanding to fully apply this standard. Something I believe you still lack dear writer.
27005 for me is the best risk management standard out there because of its granularity compared to NIST and AS/NZS, though others may think that the granularity may not be needed (Risk Acceptance). As more detailed the standard goes, the more hard it becomes to execute.
And you’re the one who got it backwards, ISMS is a much much broader scope than ISRM. ISRM, BCM (BCP for you) is just a part of the requirement of ISMS. Any infosec guy with *credible experience* will tell you this.
Piece of advice, read more and get the experience to have a better understanding. It appears you need it.
Alex Apr 14
What an amazing ability to argue without using reason or logic you have there! You’ll forgive me for saying so, but to emulate your greatness about the only experience I’ll need is the ability to utilize cognitive biases.
m4x May 26
Just to add to that, ISO, NIST and OCTAVE (in its unified model) seem to be the most appropriate framework for the type of results we want. A year ago, we looked at FAIR (and we paid a lot of money to learn it and I think we regret that) hoping that a quantitative analysis would address our risk assessment headaches. We were not very convinced that it solved our problem. It made one risk finding with multiple threat profiles (because each threat profile has varying threat capabilities!) into a series of spreadsheet!
Today, we use a hybrid model that takes a lot of flavors from ISO, NIST, OCTAVE, TARA and OCTAVE. After a series of assessments, we are convinced that this is a better model.
Jack Freund May 26
Hello m4x
I’m very sorry that you didn’t find FAIR helpful.
One of the things that we often say is that you have to use FAIR at useful level of abstraction. If you had that many Tcom’s, and you didn’t find that useful, I would say that you should have combined them. You lose fidelity in the analysis that way, but if it was really that troubling, you could have done it.
Also, there are several very well documented problems with the qualitative methods that you’ve identified (well, TARA is good and useful for FAIR–but they have a lot of Tcom’s too. How did you deal with that?) It’s too much to go into here, but Douglas Hubbard documents them well in his Failure of Risk Management book.
Lastly, I’m not sure when you worked with FAIR, but we have made great strides in the last year or so. We now are able to do a more detailed control analysis with consolidated enterprise risk visualizations. I’m sure Jack Jones would be happy to talk with you about it. I know he always leaves the training sessions with his contact information in case things go awry.
Alex May 27
m4x,
I’d be real interested to see what “flavors” you took from each of those standards. Primarily because not one of them address probability theory properly, or in a consistent manner.