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.
And the other side of the trouble is that the non-hypothetical alternative seems to be the sort of statistical modelling that Alex Hutton and Pete Lindstrom advocate, and my own background in statistics from having worked at an insurance company gives me no confidence it the applicability of those methods in a rapidly changing field like InfoSec.

“Methodology” I like; “Model” I’m wary of. I’ve seen too many RAs that are excellent paper models and have no correspondence to what was actually faced.

Case in point for a government project I worked on. The RA was for the operation of the final deliverable with the firewall installed and configured and the switch installed and all the VLANs configured.

The reality was as the system was being built the firewall was turned off and the switch was run as a hub – flat – so exposing everything to the internet. There was no DNS or DHCP or YP/NIS or LDAP set up so all addresses were hard coded and hard coded into the software as well. The end result was that it was impossible to create the subnets that the final design required and which had been part of the model the RA assumed.

This RA was done by a supposedly experienced TLA “Big Name”.

Now I realize that a RA for the ‘build’ could have been done but this Big Name Firm didn’t. The project managers did not do a “project-in-progress” RA; and this was a government project, so you’d expect serious and experienced and wary PMs. But no.

I’ve commented many times on the gap between the Verb and the Noun in the way things work and the way people do things. This is another example. No matter the good of RA as a model of how things should be done (the ‘Noun’), the doing (the ‘Verb’) always seems to leave a lot to be desired.

It is for this reason I put a lot of emphasis on Incident Response and the necessary monitoring and logging, on DR plans and exercises and training for both.

The real world people who have to deal with matters like this, the military, firemen, airport safety crews and the like, construct scenarios and model how to respond, and then carry out exercises and run ‘post-mortems’ that examine how effective their planning and training was.

How does out profession compare with that?


Diagram illustrating the relationship between ...
Diagram illustrating the relationship between the three components of risk analysis. (Photo credit: Wikipedia)

[1] If you want to see a real standard, look how something like the
Whitworth screw thread standard is defined.
vering them up.

Enhanced by Zemanta

About the author

Security Evangelist

Leave a Reply