This weekend, I had a problem. And that problem was a hungry family, a beautiful roast and how to not screw it up.
Now you might remember that I like to cook, and I’m interested in learning how to do things properly. So, that means I like to get optimal results when I’m cooking anything—even, in this case, when I couldn’t remember the last time I’d actually made a roast.
One method of cooking it that is used quite a lot is the time per kg or pound approach. So you’ll find certain calculations in cookbooks that say if you have a 3lb roast, you cook it for X minutes, and it’ll be perfect!
…right.
It’s rarely that easy (pun intended).
And in this particular case, another problem I had was that the package for said roast was well thrown away, and, of course, the batteries on the kitchen scale were dead. Either way, it meant any kind of cooking ratio based on time was out the window.
Did I mention that I was also trying to do something else at the same time? So that also ruled out checking it incessantly to make sure it wasn’t burning, so I could jerk it out of the oven in the nick of time without ending up with a shriveled piece of leather.
Fortunately, one of the books on the shelf is Pépin’s New Complete Techniques (I actually like the old one better, but I gave it away thinking I could just easily buy it again…wrong).
And in it, he overtly poo-poo’s the time-based approach to trying to cook a roast because the cooking time varies on the:
- Size of the roast
- The cut of the roast (different tissues, you see)
- The temperature of the oven
So he gives the one key measurement technique that *always* works: you poke it with your finger.
Yep. The precision instrument of touch and experience wins the day.
But you say, how do I recognize what’s right?
It’s based on the “spring” of the roast when you touch it. If it gives a lot and feels soft and mushy, then it’s going to be pretty rare and underdone. If it’s soft with some bounce, it’s going to be rare. If it’s hard and springy, it’s going to be medium, and if it feels hard with no bounce, it’s going to be well done.
And, you know what, it works! That, and the other piece of critical advice is to let it rest for 5-10 min so it’s evenly cooked and not raw in the middle and dry around the edges.
Even I could do it, and get it right on the first go too!
What’s this have to do with cybersecurity measurement?
Quite a lot, actually.
What’s the objective we’re trying to achieve?
A desired level of “doneness” acceptable to the family.
What are we measuring?
The spring of the meat, which is directly related to the objective we care about. It’s impossible to separate the two things: the “spring” is directly proportional to the level of doneness, and we have a metric that tells us how they relate.
What didn’t we measure?
Time as a proxy for doneness.
Why?
Because from the description, and thinking about it for a minute, there’s no direct correlation between the two given the number of variables we have to work with. So trying to measure two independent variables and hoping for some magical relationship between them is clearly a recipe for disaster (you see what I did there, right?).
Now think for a minute…
Here’s the scenario. In the dining room, we have the owners of the objective, the family. And they express their preference for a level of quality and a certain set of characteristics for what we’re supposed to build.
They’re the customer, and they’ve given us a requirement.
And in the kitchen, with the specific roast in question, we have an oven, which we can directly control (to a point), we have time, which we can measure, and we have a measurement approach which is touch the meat and observe the reaction so we can compare it to the measurement scale established by the metric we’re using.
So what did I do?
Set a timer for a specified interval to trigger the measurement of the environment. Compared the measurement to the scale of my metric, and then made a decision about what to do next to achieve my objective.
Fortunately the approach worked, and the roast was perfect.
But what I really did was I had a fully-engineered set of requirements from the business customer down to the lowest levels of the operational implementation that all had to fit together in a system specifically designed to achieve the value the customer wanted.
That doesn’t happen by accident…and yet, that’s what happens too often in security programs. Requirements don’t get translated into a complete system that will allow them to be measured, reported and ultimately allow the course corrections required to have the best chance of success.
It’s all kinda random…or bad agile-ized…or islands of effort with the messages put in the bottle, tossed into the ocean and hoping that they’ll be delivered in time to influence the outcome.
Requirements engineering is a system to build systems, and as a system, it means it has a number of parts.
If you want to really know how to make sure all those messages get delivered all the way through from requirement to value in the best way possible,
…then you’d better make sure you get the upcoming October issue of the print Security Sanity™ newsletter. It’s how you make sure your customers don’t go hungry, start to riot and fill the streets with shouts of “Off with their heads!”
To subscribe before the deadline, go here: https://securitysanity.com
Stay safe,
ast
—
Andrew S. Townley
Archistry Chief Executive
