Ok, before I talk about the importance of our risk models being predictive, descriptive, consistent, simple, structurally stable, and even normative, we need to agree on what we mean when we use the word MODEL. Why? Because if we don't start at the base of our pyramid of understanding then we can each be going down different paths without ever knowing it.
Sad, isn't it? We want to talk about IT Security Risk and we are still working to get past the definition stage. This shouldn't take too long, though, because we have Wikipedia to give us fast access to definitions.
I love Wikipedia! When I first began to explore the philosophy of modeling I had to spelunk through dusty aisles of old books in the bowels of various libraries. I sneezed a lot. :) Today I have summaries and definitions at my fingertips!
First, let me say that the term MODEL is very general. If you look around you'll find many, each one potentially tailored to a specific field. I'll start with the definition from www.wikipedia.org/wiki/Model:
A model (from V.L. *modellus, dim. of L. modulus "measure, standard," dim. of modus "manner, measure") is a pattern, plan, representation (especially in miniature), or description designed to show the main object or workings of an object, system, or concept.
I want to expand that with an operational definition in my own words:
A model is a representation of something complex. It is (usually) simpler (easier to manage, handle, view, operate, etc.) than the thing it represents. We use the simple model to help us understand the more complex thing. A model can be physical, mathematical, metaphorical, chemical, biological, or mental.
If you are thinking to yourself at this point, "that is not very specific", then you get a gold star. Our use of the term is diverse for good reason. Here are some examples of models that illustrate the point:
A model can be derived from first principles with the goal of describing the essence of the thing being modeled. The equation E=MC2 above as an example. Mathematicians and physicists have historically aimed for this type of model.
A model can also be constructed in an ad hoc manner based solely on observations, measurements, or analysis of behavior from the thing being modeled. If you were to put pen to paper while driving around your neighborhood and create a map for later use then you would have an example of this type of model.
The difference between these two model types is extremely important.
Why? Because a model intended to represent the essence of the thing has immensely more predictive value than a model created from an array of ad hoc measurements of the thing.
Why would I say that? Consider an equation with two parameters, like E=MC2, and consider that it was derived by observing multiple measurements of E and M from experiments. If the model/equation represents the essence of the thing, then I can use the model/equation to predict unobserved and unmeasured values of E and/or M. The equation is predictive outside of the original measurements.
What about our model/ad hoc map of your city? I think you'll agree that it's unlikely your hand-sketched map predicts street names and relationships in a different city. The map is not predictive outside of the original measurements.
So what is the take away message? When we create IT Security risk metrics we need to be conscious of the models underpinning those metrics so that we can interpret them wisely.
Finally, I think we are in a position to start talking about risk models being predictive, descriptive, consistent, simple, structurally stable, and even normative. Oh, wait! We just talked about predictive models. :)
More next time. :)