Fabrizio Baiardi, Claudio Telmon, CISA, CISSP, and Daniele Sgandurra, Ph.D.
It is a common mantra that a quantitative risk assessment should be preferred to a qualitative one, because its outputs can be easily turned into investments and, as the saying goes, “you cannot manage what you do not measure.” However, while in the past years a lot of effort has been put in defining risk and risk management methodologies, much less attention has been paid to well-founded metrics to measure the risk. Commonly, risk is indirectly measured through related metrics (e.g., security metrics) without a clear relationship to the actual risk.
Furthermore, most quantitative methodologies are defined by mapping qualitative results into numbers. This is due to the lack of information for the assessment and to the complexity of the problem. While there is a lot of pressure to increase the information sharing on incidents, it seems that the resulting data would mostly be used as a better indicator for qualitative analysis; the complexity of the problem still seems to be a critical issue.
However, this attitude does not take into account that computing power is becoming cheaper and cheaper and that proper programming tools exist to support the building of a detailed model of the system and of the threats of interest. The simulation can return a large amount of data on the interactions between the system and the threats. This data can then be mined to achieve a better understanding of strengths, weaknesses, opportunities and threats of the system. Also, outlier threat behaviors can be easily identified and studied in some detail. These results provide evidence that support the conclusions of the risk assessment. The know-how and experiences of the assessors are still fundamental in defining the input parameters of the simulation, but the results of the assessment can be more objective.
The critical issue here is the initial investment required to build a detailed model of the system. The time required may also delay the assessment that can be implemented only after building the model. However, the investment can be minimized if the model is built along with the system, so that the evaluation of the risk posed by a system is a fundamental step of the system design; this is required to understand and manage the risk posed by a system before deploying it.