Practical Security, Theoretical Exploits, and FAIR use.
Having lunch with an analyst about to take FAIR training the other day, he mentioned this to me.
"I love the whitepaper. I love FAIR, the models, consistency, all of it. The one thing I worry about is how practical it will be for me in my day to day job. I mean, if I’m not head down in some logs or scanner output, I’m talking to a vendor or my boss. I know I’ll be doing formal analysis sometimes, but I just don’t know how much."
It’s a very valid question - how practical is FAIR? I’ve spent part of my past week discussing the meaning of vulnerability with other professionals. At one point the discussion was accused of taking a "if a tree falls in the woods" direction. But when I had heard that question from my analyst friend, I had to laugh.
The same analysts, after understanding FAIR and it’s application, often accuse FAIR of being too practical!
Let me give you an example. Recently there’s been no little amount of discussion concerning Apple, SecureWorks and some wireless drivers. Inflammatory remarks by both sides have left this a somewhat acrid discussion. For those not familiar, SecureWorks researchers claimed to have found vulnerability in Apple’s wireless drivers that led to complete compromise. The Washington Post decided to headline the whole affair. Initial controversy was created because SecureWorks claimed to have given Apple notice, and Apple claimed to have not been provided with a working exploit. Long story short - for various possible reasons, the general public has yet to see an actual exploit as SecureWorks demonstrated "in the wild".
To most analysts, this is of critical interest, if not importance. This is evident by the amount of discussion surrounding it - as we techies say, there’s been a lot of cycles spent on this already. It’s got all the ingredients to scare us to death - ownership of the root account, apparent speed with which the laptop is compromised, the ubiquitousness of wireless, the fact that it’s wireless in and of itself is enough to give every self-respecting security pundit the heebeejeebies…
But to the FAIR-trained analyst, it’s time to move on. This issue shouldn’t even be on our radar. And once I’ve explained why, you’ll understand why some folks might think that FAIR is too practical.
We know that we can only have a Loss Event when we have a Threat Event to which we are Vulnerable. I In non-FAIR lingo; someone’s gotta attack us, and get by our controls in order for us to have any problem. Now given the claimed nature of this exploit, we know we will have very little Control Strength - a fault in the wireless drivers means that there are very few countermeasures we can use against this potential exploit. There’s even a high Threat Capability rating - as quickly as the security researchers seemed to take over the MacBook in question, it still takes someone within the very best of the most technical community to act on us. No doubt, our Vulnerability here is pretty high.
However, outside of a fuzzy (and to some, questionably valid) video - no real exploit of this has yet to be seen. Now of course this doesn’t mean the problem doesn’t exist! If valid, there may be a number of folks out there that, through their own research, have added this exploit to their bag of tricks. What it does mean is that it has yet to really hit mainstream, or even that exploit of this weakness is still very theoretical.
So our Threat Event Frequency (TEF) approaches zero. And despite our high vulnerability, a TEF near zero means near zero Loss Events. Ladies and Gentlemen, until we have intelligence of a working exploit, it’s time to move on to more pressing issues.
In the same way, my analyst friend will never look at his scanner output the same. A database somewhere will be telling him about the criticality of the "vulnerability" (sic) the scanner found. That criticality has nothing to do with risk. In fact, it has very little to do with actual Vulnerability until the found weakness is put in context of Control Strength and Threat Capability. And the point at which my analyst friend has a "critical" scanner finding which FAIR tells him is a non-issue is the point at which he will likely come back to me and claim that FAIR is too practical. It’s the point at which most analysts (myself included) would rather lie within the safety blanket of "everything theoretically critical" than practical risk analysis. We sometimes call it "possibility vs. probability" - and it’s one of the biggest inefficiencies of modern Information Security.
note: Just because we don’t have TEF yet doesn’t mean that this won’t ever be an issue we need to deal with. Like all things technical, this has a lifecycle - we may just be too early in that lifecycle to worry about it, or it may never have a significant enough lifecycle - but for right now I’m betting that most people not employed by Apple or SecureWorks have bigger issues to worry about.
also note: We didn’t even get to the loss side of the risk equation. If you’re organization has little to lose on their laptops - then even a working exploit in the wild might make this issue "no big deal" for immediacy.
also also note: If you want to get bent out of shape over the way Apple or Secureworks handled this, great! Vendor/Researcher relations is a different matter, and to me - more "impractical" to our jobs than a working definition of vulnerability

