The Falcon's View

Instead of measuring something so squishy, let's instead look at the operational metrics that we can absolutely measure. For example:
- Uptime
- Availability
- Performance (e.g., TPS, MIPS)
- Time-to-Fix
- MTBF (for a broad definition of "failure")
- SNR (representative here - i.e., how much "background noise" do we get from scans vs. detected legit attacks)
- Visibility (into code, into environment, etc.)

These strike me as useful metrics to track, at least operationally, with an ability to then roll them up into tactical, and even strategic, reports. Thinking about this all in terms of survivability, then, we want to be able to answer these questions:
- Have operations been negatively impacted?
- Were we able to continue operations despite degraded conditions?
- What measurable impact occurred during the impact period?
- How quickly can we resolve issues once detected?

These, I think, are very useful metrics to monitor. One could rightly argue that they're primarily IT operations metrics, but they go directly toward key infosec objectives, too. In terms of survivability, they help us gain a better picture about resiliency, such as benchmarking how recoverability, as well as to a degree defensibility.

Defensibility, of course, is where we start potentially getting back into squishiness. We have a similar problem with performing a FAIR risk analysis, too, when we look at the "Vulnerability" factor, since there's no simple, reliable, consistent way to measure it (i.e., this is one of the more subjective values in the overall scheme of things).

Putting this thought into a properly framed risk management context, based around survivability as the main driver, I think that metrics developed along these lines are more useful today, while also being reasonably accurate and precise. It's time to put aside fuzzy "security" metrics in favor of something that tells the business just how reliable its systems and applications are.