Cybersecurity’s Need for Speed & Where To Find It

As we talked about in the last post, a world going through a massive AI-driven transition means speed becomes vital. This is the speed of adapting to change and the speed of dealing with a world of threats, who are themselves moving ever faster. 

It’s easy to say go faster but this has to be more than just wishful thinking or a line in a strategy document. You actually have to go do some things. You also have to push back against some of the defeatism that permeates a lot of the security community that many organizations are incapable of change. Even the most bureaucratic and stultified can decide to change and then pull off that change to increase their agility. The question is not about ability, it’s about will. Let’s not confuse those. 

In thinking about some practical examples of increasing speed I revisited Stewart Brand’s Pace Layers framework explained simply in this blog post. 

Most durable and dynamic systems reflect this pattern of multiple layers. Fast building on slow. The fast layers bring novelty and experimentation and the slow layers provide stability and memory. Robustness comes from how the layers reinforce each other. To quote directly from Stewart Brand’s original framework: 

• Fast learns, slow remembers.

• Fast proposes, slow disposes.

• Fast and small instructs slow and big by accrued innovation and occasional revolution.

• Fast gets all our attention, slow has all the power.

The fast layers innovate, the slow layers stabilize. 

To pick an example, let’s look at how this framework might be applied to software development methodologies:

• Fashion: new tools, new interfaces, new patterns, and new trends mostly come and go. Some stick but most fade.

• Commerce: vendors, start ups, products, VC funding, all of which is slower than “fashion” but still has lots of rapid experimentation.

• Infrastructure: surrounding tools, cloud run times, languages, binary formats, APIs and libraries, software supply chains, open source eco-systems. Whatever happens at the fashion and commerce layers has to work on this substrate. 

• Governance: the organizational and industry specific policies, rules, regulations like your ISOs, SOC2s, NISTs, and all the industry specific things that (rightly or wrongly) drive how to build and evidence the control of software.

• Culture: the prevailaing attitudes, from education, lore, and overall community experience of how to build software.

• Nature: the environmental realities of how to build and run IT. This could be scaling, hardware, and even the speed of light affecting cross data center synchronised data replication which drives how to architect systems for certain goals. 

Pace layers are a time hierarchy where the slower elements constrain the faster ones. Despite such constraints there is still the possibility of occasional massive shocks that can move all the layers at once. We are obviously in the midst of one now where the capability of recent AI models is transforming how we produce and maintain software at each pace layer all at once. 

So, going back to the beginning, if our goal is to speed up how we manage our cybersecurity posture in response to faster change and accelerating threats, what are some things we can do.

1.Software Delivery Pipeline 

If you speed up how software changes can be deployed and backed-out then you are liberated to push fixes faster. If you can understand your code base and all its dependencies then you can analyze the risks of change, resolve issues that might block security updates, to free you to push security and other fixes exponentially faster. As more organization’s software pipelines become agentically driven then this possibility for speed is increased. Even for those not aggressively adopting such approaches the use of coding models can still help with the change analysis and dependency management to eke out more lifecycle performance. 

Developing and delivering “skills packs” to support all elements of the threat modeling, software security analysis, invariant maintenance and dependency management can liberate your teams to work faster in the face of decreasing windows of opportunity to fix issues before industrialized attackers exploit them. 

2.Change Boards / Change Approvals 

My prior post made the point that defenders ultimately have a structural advantage over attackers in the use of AI. This was met with a few comments that were essentially, “ok, but attackers don’t have bureaucracy, change boards and change approvals and so will always be more agile than defenders.” 

Ok, I sympathize with this view. I’ve spent most of my career in massive and highly regulated critical infrastructure organizations in defense, energy, finance and big tech. They have stringent change controls to shield themselves from ill-advised changes going bad with immense blast radius. But, especially in the past decade, many of those organizations have streamlined their processes, their phased deployments, and wider controls that intrinsically mitigate many change risks. This has led to faster changes, more default approved changes and radical reduction in the time and toil of the necessary bureaucracy that is typically only evident for the most wide-ranging changes. These organizations don’t move fast and break things. They move fast and fix things. All organizations can do this. Yes, some have decidedly unagile leadership so it will be an uphill battle for CIOs/CTOs/CISOs to get there. But to not relentlessly try is just defeatism. 

3.High Tempo Board Oversight 

How Boards oversee cybersecurity is a crucial but difficult topic. Boards have formal responsibility to represent shareholders to ensure businesses are well run. This includes how risks, like cybersecurity, are managed. The way Boards approach this can help increase the speed of the executive decision making that modern security programs need. The most successful security teams help their Boards with this, and in doing so build substantial and deep engagement. This equips the Board with the skills and expertise to provide an effective independent challenge and at the same time help the CISO enhance the security posture of the organization. Risk limits and thresholds (high speed exception handling), event driven scenario analysis (high speed contingency planning), incident learning / close-call analysis (high speed course correction), and business line ownership of risk - pull not push (high speed utilization of the security team), are techniques to get your Board engagement to help you move faster. 

4.Fast Executive Decision Making 

As with managing any part of your business there are four basic “loops” in security decision making and execution. The speed of these loops make the difference between poor, good, or elite security programs.

• Executive decision making. The cycle for how leadership such as the CEO, CFO, COO, CIO/CTO, or others prioritize funding and implementation of large-scale or otherwise impactful security improvements. When this isn’t working there are critical known risks left unresolved because no-one is making the decision to proceed to mitigate, or everyone thinks it’s someone else's problem to address. When it is working there are executives reaching for accountability or effective governance processes that ensure timely decisions are made.

• Implementation. The speed at which controls are implemented and progress reported to ensure accountability over those responsible for that. When this isn’t working you might see an all systems go decision has been made but teams are slow-rolling implementation. When this is working the organization’s established implementation machine like standard project management or OKR tracking kicks in to gear to track completion. 

• Fast feedback. Ensuring that implementation measurement, continuous control monitoring, incident learning, and other essential processes are in feedback loops that operate quickly and reliably. When this isn’t working you find leadership were told a control was fully implemented but it has gradually eroded and that only becomes visible too late either because of an incident or a failed audit. When this is working there are processes to continuously monitor controls using established channels, like incident management, so that these are treated as high priority breaks to fix. 

• Bottoms up self-correction. Ensuring there is a technically led culture where engineering teams are proactive about self-directing and resolving the remediation of security issues without executive direction. When this isn’t working there are many teams who know something can be fixed without major problems, but stall because they believe they need to be directed or approved to do it. When this is working, technical leads and multiple levels of management take responsibility to treat security improvements as essential parts of service delivery. 

Great things happen if executives make decisions promptly, see those implemented quickly, get immediate feedback if things aren’t going well, and trust that all teams will do what they can under their local control to keep security well maintained. 

5.Risk Convergence

There are many operational risks in enterprises, of which cybersecurity is just one. These risks include reliability, resilience, business controls, safety, privacy, change, quality, and more. These share many common control objectives and implementations. While you may not be in a position to fully converge the management of all these risks, it is important to develop practices to understand the overall landscape. This helps speed with the reuse or refactoring of controls. Let’s say you have uncovered cybersecurity risks related to excessive privilege in some teams and roles such that particular compromises would have too large of a blast radius. Rather than instituting a whole new approach of locking down access for this purpose you could, instead, look at existing privilege management controls designed to support business policy objectives and fine tune those to achieve the same goal. The former is a whole new effort that could take weeks or months, the latter is a “feature” adjustment of an existing work effort that should take days or weeks, ideally even quicker than that. 

There are similar opportunities in using privacy controls, reliability objectives and others to meet cybersecurity risk mitigation goals. 

6.Autonomic Security Operations

Every security team’s success is dependent on how quickly they adjust defenses to stay ahead of risks. These might be risks induced by threats from adversaries or more situational risks like errors or disasters. But fundamentally if your OODA (Observe, Orient, Decide, Act) loop is faster than that of your attackers then you are mostly going to win. One of the core elements of this is your detection and response capability, not just how automated that is but how autonomic this becomes. This might seem a small distinction but it’s actually more fundamentally the difference between self-defending environments and environments set up for human driven reaction that now just happens to be automated. Google has the best capabilities and content in my view on this that is covered in this post.

7.Systematized Threat Intelligence 

Getting inside and outperforming an attacker's OODA loop requires intelligence, in some cases exquisite intelligence, on their strategic goals, objectives, tactics, techniques and procedures (TTPs). When you strip away the detail, there are essentially 2 types of threat intelligence:

• Macro threat intelligence. Information on attackers’ strategic objectives, goals, structure, market, capabilities and evolving TTPs. Use this to adjust defenses to make life harder for the opponent. Aim to eliminate whole classes of attacks. For macro you need to feed it into your risk decision making process as fast as possible and increase the speed of adjusting defenses. Macro can, naturally, be derived by synthesizing more detailed intelligence (the micro), for example by looking at clusters of, say, MITRE ATT&CK hits on specific methods and observing a macro need to address an emerging theme.

• Micro threat intelligence. Information about specific attacks, signatures, indicators of compromise, and other selectors/data. Aim to eliminate or detect/respond to specific attacks. Information about threats, itself, is necessary but not sufficient. In both cases you need to be capable of doing something with it.  For micro threat intelligence you need to feed this into your defensive operations as fast as possible, in as fully an automated way as you can. Work to improve the ingest speed and coverage of this into your preventive controls and your detective sensor grid. 

8.Prioritized Vulnerability Management

In a world of more vulnerabilities and more attacker capability to exploit those it is vital to deal with those vulnerabilities at increasing speed. There is nuance here, it’s not just “throw all things at fixing all the things”. But, there are many situations where it is in fact actually easier and cheaper to engineer an environment to fix all the things constantly by default, for example on end points or using the latest pristine images in production. However, for practical purposes in many organizations other techniques need to be used to achieve vulnerability mitigation without patching everything all the time. This includes reasoning about and managing attack paths so some vulnerabilities can be reliably tolerated, applying compensating controls (in line or in run time) to reduce the extent to which a vulnerability can be exploited, or to use better intelligence to know which vulnerabilities are being exploited in what ways and then prioritize the resolution of those. 

 9.Control Reliability Engineering

One of the worst lags, where lack of speed really gets you, is when controls silently fail and that is only discovered months later in an actual breach. For example, in environments that are very much not on the immutable infrastructure pattern, ports might be opened for deployments, changes or testing that are not reliably re-locked down. These openings sit there undetected until boom happens. The right answer to this is not just constant vulnerability scanning, posture management, and continuous control monitoring but also (obviously) the need to actually fix the issues very quickly. 

Like most things of the form “just go faster” this is easier said than done and so there needs to be a deliberate practice of control reliability engineering (SRE for controls) that looks at root causes, learns from that and progressively eliminates the root causes of the root causes of the silent failures 

10.Platform Shift Down (not just shift left)

Having more positive security changes become more permanent requires going deeper down the pace layers into the lower and slower levels. It requires you to take the experimentation you do at the top, faster, layers and then commoditize those so they can be locked into those lower layers. 

In our world this is what drives the need to shift down, not just shift left. That is to put more and more controls into underlying platforms so that security by design and by default is inherent as the easy path no matter what is built at the higher layers. The ultimate speed is to ensure that in the absence of decisions to the contrary we will default to security as part of the tools and processes people routinely use. 

11.Buying Time

Finally, in our model of having our OODA loop work quicker than the attackers, we can work both sides of that equation. It’s not just about defenders getting quicker. We can work to slow down attackers - even in the face of their speed up from using AI and other techniques. This is where a revisit of deception technologies and moving target defenses will bring more opportunity than earlier attempts to use them did. 

Bottom line: The best security teams understand speed is everything. Speed of moving to a modernized IT architecture where security, resilience, compliance and privacy controls are pre-integrated. Speed of consuming and applying updates to take advantage of new or enhanced controls from your vendors’ hard fought lessons across their wider customer base. Speed of equipping employees and customers with improved capabilities. Speed of eliminating stagnant systems and wrapping remaining legacy environments in modern controls. Speed - in the right direction - is all.