When you strip away all the fluff, security succeeds when:
You are moving quicker than attackers - mitigating specific attacks ahead of, or just in time, through fast detection, containment and recovery.
You are strategically outmatching attackers - by implementing a defensible architecture that defeats whole classes of attacks.
You have a primary goal of business / mission outcomes - by driving technology approaches that primarily deliver commercial or mission benefits but still achieve strong security and resilience goals in doing so e.g. software and infrastructure reproducibility.
There are whole books written on topics 1 and 2 such as Building Secure and Reliable Systems. I’ve been writing a number of posts about 3. Increasingly, I wonder if there are some other measurement frameworks that look at progress on moving quicker, outmatching attackers and achieving our outcomes. That is, as opposed to lagging indicators or even some of the more advanced leading indicators I talk about here.
Thinking about the time dimension of security I am intrigued by a couple of possible approaches: Isochrones and “Time to Hello World”. This is a brain-dump sort of post that I will revisit more thoroughly. Incidentally, Winn Schwartau’s Time Based Security book also has some interesting ideas here.
Isochrones
I first came across this well-established concept in the diagram below, from Sketchplanations. In this example it shows contours as the time it takes to travel a specific distance. The “fingers” are the result of mass transit (e.g. trains) or high capacity roads (e.g. freeways / motorways).
What might the security applications of this idea be? You could model time to respond, time to fix, time to “whatever”. Then look for ways of compacting the contours, creating or inverting the fingers. Imagine visualizing this as a radar chart plotted as a set of possible incident / event types which shows the degree to which you have built in prevention, detection, response and recovery and then overlaying the isochrones of how far you got in that cycle in, say, 4 hours. Some events might be fully recovered by 4 hours, others might only barely be detected.
You can equally apply the same concept beyond incidents to risks, for the find risk / fix risk flow, control failures in continuous controls monitoring, or resiliency events. The plot of all of these could reveal some insights into why certain events are handled more completely in less time than others. In other words, what are the “high speed rail” or “freeway” fingers for these?
There are other possible uses of isochrones related to risk management, for example:
Mapping knowledge diffusion: create "knowledge isochrones" to visualize how ideas or innovations spread through social networks or academic communities, identifying key influencers and potential barriers to knowledge sharing.
Measuring information accessibility: similar to physical accessibility, information accessibility can be assessed using "isochrones" to measure the time it takes to find, retrieve, and understand information from different sources.
Mapping attack propagation: conversely, from using isochrones to map response times, we could also utilize isochrones to visualize the potential spread of a cyberattack or physical threat from an initial point, considering factors like network vulnerabilities or attacker movement.
Identifying critical assets: analyzing the time it takes for attackers to reach critical infrastructure or sensitive data, isochrones can help prioritize security measures for the most vulnerable assets.
Optimizing patrol routes: in physical security, patrols for physical assets like buildings or borders can be optimized using isochrones to ensure maximum coverage within a set timeframe.
Visualizing evacuation zones: isochrones can be used to create dynamic evacuation plans, identifying areas that can be safely evacuated within a specific time frame in case of emergencies like fires or natural disasters.
Time to Hello World
“Hello World” is the typical initial computer program we first write when confronting a new programming language or environment. The time to hello world is the rough amount of time it takes to get such a program up and running and outputting “Hello World”. It’s not always so literal, there is similar thinking on other simple actions such as time develop a program to write and read a database entry, bringing up an API endpoint or launching a container. Some languages / environments are trivial while others have a big learning curve just to get the development environment even set up so you can even enter a line of code like “printf(“Hello World\n”);” let alone get it compiled and deployed to a run time so you can even see that output on the console or through an API response.
There are two angles to explore related to Time to Hello World (TTHW) for security. First, security’s contribution or not to a high or low TTHW. Second, what are security’s potential equivalents to TTHW. Let us look at each.
Securing Time to Hello World
There will be variants of this depending on what specifically TTHW is covering. If TTHW is literally spitting out Hello World on the console as opposed to, say, starting up an API endpoint, then securing it is going to be much easier. Let’s make some assumptions to give this some more realism, let’s say this TTHW is to develop a short program that spins up an API endpoint in the cloud that responds to an API method with an input of 5 characters by emitting back “Hello World” + those 5 characters. Therefore the time to secure TTHW, that is STTHW, is TTHW augmented with some degree of vulnerability scanning, static code analysis, IDE based delivery of findings, compile time findings, deploy time findings including cloud configuration weaknesses and, finally, a rudimentary run time analysis of the API behavior.
So, the Time to Hello World is based on programming language effectiveness, IDE set up, run time deployment set up and so on. STTHW is all that in addition to the tooling required to achieve the above and to fix and deploy the inevitable vulnerabilities even in such a small system. Reducing STTHW would be helped by many factors:
Nature of the programming language such as memory safety and compiler flags to reduce types of vulnerability.
Nature of the development environment and ease of which security tooling is either built in or deployable into it and the way that provides actionable feedback to the developer.
How vulnerability (software and infrastructure configuration) scanning tooling is built in or deployable into it and, likewise, how that provides actionable recommendations.
What third party packages are needed to get the Hello World program up and running and does that automatically inherit (down the supply chain) all the most up to date packages.
Security default choices so that, at least, there are no discernible environmental vulnerabilities that take developer time that could have been configured correctly in those defaults.
Extent of secure libraries to reliably take care of common security needs such as authentication, authorization, input validation, output sanitization, API security and so on.
It would be great if all combinations of languages, development environments and runtime deployment environments had a benchmarked STTHW as well as TTHW and we had a league table of the differences. It is also worth asking the corollaries of what is STTHW with an SBOM and STTHW with an SBOM and a SLSA Level 4 build.
Time to Hello World for Security
Taking this analogy further, instead of TTHW or the variant STTHW, ask what are security equivalents of this? There are well established concepts of Mean Time to Detect/Recover, Mean Time Between Failures and so on, but here I’m really more thinking Iike TTHW - that it’s a measure of tooling / environment effectiveness in support of security personnel. For example:
Time to deploy a sensor to detect one event.
Time to set up BYOID in a tightly scoped way.
Time to first vulnerability scan.
Time to turn an SBOM into reliable actions.
Bottom line: we have lots of useful security metrics but not that many of them are time and effort related. This is surprising, given how important time is as a factor to outpace attackers and how much reduction in effort is needed to scale the workforce. There is much work to be done but isochrones to watch for fast(er) paths to actions and measuring variants of Time to Hello World may lead to some interesting outcomes.