Machine Speed & Meaningless Security Mottos

Cybersecurity has many mottos. There are fatalistic ones like, "Users are the weakest link," that shift failure onto users and absolve security teams from creating a bad UX, omitting controls, and relying on inadequate processes. There are broad ones like, "Shift left," that repackage old concepts like software quality starts at the design phase.

And now there's the emphatic modifier of "machine speed" that appears in dramatic discussions of agents and LLMs. Machine speed is trotted out as an apparently novel concern for cybersecurity in the age of AI, which is unfair to all the while loops, shell scripts, and automation that preceded this era of excitement.

Artificial Activities vs. Optimal Outcomes

Machine speed feels like misdirected attention to tactical improvements. Meaningful improvements, to be sure, as measured by speed of discovering flaws. Yet it’s unclear if they’re more economically efficient improvements. There’s little data on the rate of flaws found or events analyzed per unit of time per dollar. Then add on the cost of developing and confirming the quality of patches for those flaws.

That eternal cycle of find flaw, fix flaw, find, fix, find, fix again is boringly narrow. It's artifical activity in the sense of being a false strategy. It promises easy metrics like CVE counts and days to patch. (Or events analyzed in the world of SOCs.) Sure, those are observable. But they're really just measuring how busy security teams and developer teams are on short-term tasks. It doesn't matter if agents augment those teams; that just means teams are burning time and agents are burning tokens. Cybersecurity should have observable outcomes. I prefer ones that focus on reducing or avoiding flaws altogether.

Some of this reduction can be accomplished by addressing sensitivity, as in refining what the tool considers a flaw or suspicious event. Adjust the filters that surface findings. This is hardly an insightful recommendation. It’s an old, well-established technique. My disfavor for it is that it doesn’t improve the creation of code. It merely adjusts the baseline quality at which flaws are considered impactful.

This can also be accomplished by reducing attack surface and reinforcing security boundaries. This is the domain of proactive design choices — even though that feels like a fleeting wish as I type the words. It's another old concept. And one that seems to have far less uptake than refining filters.

A Completely Wishful Enumeration

React and related frameworks are great examples of secure by design principles. They make XSS scarce by addressing the flaw at its root cause — maintaining a strict distinction between the structure of HTML nodes and the content that lands in those nodes. The frameworks render arbitrary, untrusted data such that the semantics of a page are unaffected by the syntax of that data. The frameworks foster design patterns that minimize security mistakes and make it easier for linters and IDES to warn when those mistakes happen.

CSRF is similarly diminished. Cloud providers have changed APIs and default settings to make flaws like SSRF and accidental exposure of resources less common. Sadly, it also took several years for those defaults to take hold and become more common than their insecure predecessors. If there's a machine speed to strive for, it's in creating more secure defaults.

C and C++ code is getting better through compiler feedback, CPU design, and standards. Rust is making inroads into these areas. The Linux kernel won’t replace its millions of lines of C with Rust, but it will use Rust in notoriously insecure areas like device drivers.

I suspect that some orgs are reluctant to embrace an approach that reduces their attack surface because it requires more engineering effort and, cynically, because that effort is more difficult to measure. They don't have the familiar monthly trends and charts of CVE counts and days to patch that vulnerability management programs produce.

Saying that 100 patches were applied within their however-many day deadline sounds informative. We could further tweak it by making it less passive (which app owners applied met or missed deadlines), more precise (slicing by distribution of severity, or more comparative (percent change from previous timeframe). Those aren’t bad refinements, they just reinforce a retreat to numbers that are easier to gather and report on.

Saying you introduced a design change that eradicates a vuln class doesn’t fit into that vuln management framing of short-term trends that track how much the cycle of security patches keeps people busy. That’s a good thing.

Yes, there should be a step change like the count of N vuln classes went to zero. You wouldn’t count the lines of code that changed as an indicator of security. You’d have to estimate the engineering effort, then make the case for how that upfront expense saved time by reducing bug bounty payouts, limiting unpredictable patching, and avoiding potential incidents later on.

Sadly, the goal of getting rid of CWEs instead of CVEs still falls more into fiction than real-world fixing.

Smashing the Stack for a Fast Profit

So, what about the “attack faster” associated with this ambiguously defined, yet implicitly menacing, machine speed? The assertion that hackers are hacking faster implies that orgs need to change their strategies for defense. But those implications are couched in the pseudo-profundity of phrases like, “The game has changed,” or “AI era” or some sort of evolution.

Ask for an explanation and the conversation too often continues into metaphor or vapid abstraction. The equation is simple and superficial — a faster attacker necessitates a faster defender. Just be faster.

I don’t think LLM-generated packets traverse a firewall faster than those from my browser. I don’t think post-compromise shell scripts execute faster when they have the artisanal touch of artificial agentry.

Where are the indicators that machine speed is forcing fundamental changes to security controls? What proxy variables might we look at? What differences in behavior would we look for?

Cyberinsurance rates? CISA revelations? It’d be a wonderful topic for a CSRB to investigate.

At the top of my questions about whether “machine speed” means anything beyond a trite shorthand for automation by agents is what the phrase means, or at least implies, for defenders to take action on. There have always been examples of attacker automation, from the venerable Metasploit to commercial tools like CobaltStrike to plenty of open source tools from the bug bounty crowd.

There’s admittedly a faster pace of expanding privileges or pivoting across environments from automation. Yet those actions should still trigger security events or, even better, are blocked by decidedly non-machine speed controls like network isolation and restricted access.

Time and Relative Dimension in Security

Even if so-called machine speed highlights the need for more controls, an org can apply those controls regardless of whether an army of agents is attacking. Most controls work regardless of how fast or slow automation affects an attack. (One exception might be process-based controls.)

To reach for an awkward metaphor, it’s like mixing the dimensions of time and space, where machine speed speaks to attacks happening more quickly in time, but defenses are more effective when spread across space, as in reducing an attack surface.

The conversations around machine speed echo those from decades earlier about zero-days (here defined as a vuln known to attackers for which a patch is not available). One defense against a zero-day is to have the ability to obtain and apply a patch quickly. But, again, that's a very reactive stance. There are proactive steps like isolating resources, blocking egress traffic, monitoring traffic flows, setting granular access controls, and so on.

In other words, the defensive focus in on the larger system and how controls can make exploitation more difficult or post-exploitation activities easier to constrain and detect.