Registers

Many risks can be compared quantitatively so long as they share a measurement.

Let’s compare a bunch of vulnerabilities we are treating as risks. We assume we have VULN-0 to VULN-9. If we have a common group of forecasts for all of them, we can sort and manage them as you’d expect.

Register approaches are extremely cumbersome if direct elicitation is required for every entry.

The layout may convince you that a fixing-from-the-top-down approach is the obvious one, and that we should discover all the risks, elicit forecasts for all the risks and register all the risks. Of course, this is not the right way to go.

Actual decisions involving these risks will always include non-registered factors. Engineers might not have a clear mitigation in mind. There may be costs we haven’t enumerated. Maybe delays are involved with some of the risks we’d prefer mitigating.

A risk register will not lay plans in front of us, so care should be applied in efforts to tie everything into a register.

However, there are ways to make registers more efficient.

Lens Models #

A lens model is a technique that could help populate a risk register more effiently. It allows the creation of a statistical model that captures expert opinion (or plural from a panel) on a few select predictors and outputs a register of probabilities to prioritize from. An example of this is here: AWS Risk Model

Statistical models #

Third party vulnerabilities are well covered with a method like EPSS which is promising for register based approaches. These are useful when a corpus of data is available and closely relevant to the target scenario you are forecasting. These approaches lose value in first party vulnerability risk areas or more obscure software without openly available vulnerability data.