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.
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.
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.
Swine Flu Issues – insufficient discrimination
The trouble with some people is that they make some deceptively reasonable comments that don't stand up under critical analysis
With an ailing economy and a whole lot of cancelled contracts resulting from
that poor economy. Pandemic planning is a major threat to our most important
asset people and it appears as though that vulnerability may have been
activated. Its time to dust off the BCP plan and update it with a Pandemic
Mitigation strategy.If it takes a pandemic to motivate you to create or review a BCP then
something is seriously wrong, and it has nothing to do with the pandemic.
Pandemic?
As one manager said to me a long time ago, "show me the numbers".
I read:
The number of confirmed cases rose Monday to 50 in the U.S., the result
of further testing at a New York City school. The WHO has confirmed 26
cases in Mexico, six in Canada and one in Spain. All of the Canadian
cases were mild, and the people have recovered.The Mexican government suspects the virus was behind at least 149 deaths
in Mexico, the epicentre of the outbreak, with hundreds more cases
suspected.
I'm sure just about any ocotr - or the 'Net - can supply us with figures on the cases and deaths from 'regular' flu world-wide, as well as the named versions.
Network Segmentation is Common Sense
On one of the professional forums I subscribe to there was a request for "references" to justify the separation of development and production networks and facilities. It seems some managers "don't get it" when it comes to things like change control and undocumented and unplanned changes. Many guidelines discuss this, but its seems that some key ones like NIST and ISO-27001 do not explicitly mandate it, and some managers use this as a reason to not do it.
Some of us security droids find this frightening.
My colleague Miriam Britt managed to sum up the reasons why one should have separation quite sussinctly and forcefully. With her permission I have copied her reasoning here and I hope many people will either reference this or copy it to their own blogs. This kind of straight forward statement needs a wide exposure.