FAIR Institute Blog

As a relatively new discipline within cybersecurity, cyber risk quantification isn’t well-understood by many within the profession. Amongst other things, there is confusion about what CRQ is (and isn’t), and why it matters.

The Wall Street Journal recently published an article, “Whistleblower Reports of Lax Cybersecurity Expected to Rise,” reacting to the conviction of Joe Sullivan for his handling of two data breaches as CSO at Uber

Imagine that you’re looking for an encryption solution.  There are many providers on the market, all of whom use one of the well-vetted public encryption standards.  But let’s imagine there’s a new player in the market — one that claims to have a vastly improved, but proprietary, solution. 

It’s not often that I’m surprised by someone’s actions on the Internet, but I’ll admit to being surprised today.

In the previous post, I provided examples of some controls-related data that can’t be used to support automated cyber risk quantification (CRQ).  But the news isn’t all bad.  There are some data that can be used to support CRQ.

I covered a lot of ground in the previous posts, and rather than summarize them here I’ll assume you’ve read those posts already.  So, let’s dive into the last analytic dimension…

In the previous two posts, I briefly discussed that:

1. The CRQ market is rapidly growing, and there’s a strong desire to automate CRQ analysis...

In Part 1 of this series, I discussed that the market for cyber risk quantification (particularly automated CRQ) is growing rapidly, but that automation, done poorly, can to more harm than good.  In this post, I’ll begin to discuss what it takes to automate CRQ responsibly.

Until recently, it’s mostly been organizations with visionary and early adopter tendencies who have embraced cyber risk quantification (CRQ).  They understood the value and were willing to deal with the challenges.