What follows is my commentary on the Verizon 2025 DBIR, attempting to make sense of this year’s data and share this sensemaking with the community.

As ever, I remain a skeptic and scientist, seeping in the systematic doubt of the Socratic method. The Verizon DBIR team readily acknowledges² that this data cannot reveal the full dynamics pervading incidents and breaches.

The report polishes disparate tiles from data sources – some ceramic here, limestone there, glass, marble, a veritable jumble – and adds pieces to the industry mosaic, incomplete, but nevertheless an incremental step forward towards Truth.

Well, as close to Truth as the travesty that is VERIS allows.

Let’s dive in.

1. So what?

Why does any of this matter?³ When you strip away the sublime sensation of “OwO new shiny data!!” to which all humans succumb, how does this data add value?

Simply put: what is the impact of the incidents and breaches enumerated within? Impact’s absence throughout the report in some sense recalls Ozymandias, that seething expanse of desert, primordial dunes swept and sculpted by eternal winds – that profound existential emptiness found in the colorless abyss of slipshod content that perhaps, most of all, defines our current times.

A little bird told me that the DBIR team yearns to ingest cyber insurance claim data, and I, too, yearn, so, please, if you are in a position to provide it, do so.

For it is in the “what actual $s €s £s did insurance companies pay out for incidents with X attack vectors or Y assets?” that we will learn where optimal ROI resides – both in the micro and macro.

Imagine if we could see just how much these incidents and breaches cost insurance companies in claims – then compare that with the collective spend on vendors, security teams, and the other elements that make up titanic (albeit, this year, often flat growth) security budgets.

For 2025 in particular, it is worth asking: did the Crowdstrike outage’s impact on businesses (or society more generally) outweigh all the breaches in this report combined? Very rough calculations – truly extremely untrustworthy math⁴ – from the report imply ~$2.66bn in damages from Ransomware attacks. But the Crowdstrike outage cost Fortune 500 companies at least $5.4 billion, or $44 million per Fortune 500 company.

This ignores the indirect costs imposed upon the populace across sectors – like those saddled on travelers due to cancelled flights. Nearly 17,000 flights were cancelled during the 72 hours after the outage. How do you quantify the cost of a family member missing a funeral due to cancelled flights?⁵ How do you quantify the cost of a loved one missing a critical medical procedure?

The core question is: should we be allocating more or less effort to cybersecurity – and where should we be allocating those efforts more or less? The report cannot really answer this without tying these statistics to tangible costs and benefits.

It calls to mind the classic quip, “Half my advertising spend is wasted; the trouble is, I don’t know which half.” As anyone in advertising will divulge, presuming we only waste “half” is a generous estimate.

To the well-meaning cybersecurity professionals among you, how do you intend to use this information? How will it inform your choices? How will you investigate how these trends align with what matters to your business? Consider these questions as you continue reading this commentary.

2. Espionage: fast fashion or couture?

The 2025 DBIR features new contributors that added much-needed data points related to “espionage” events, i.e. those conducted by nation state-affiliated actors. This figure shot up to 17% (as shown in Figure 21 from the DBIR), much to the delight of FUD-driven GTM teams who will soon descend on Moscone, I’m sure.

However, many of those espionage events also feature financial motives. Why might that be? Shouldn’t nation states be sufficiently flush with cash and coin that they need not stoop to monetary theft?

Well, depending on the nation state, sanctions suck and make it hard to transact at financial institutions. Or, if you’re a nation state who wants to save face on the geopolitical stage, it’s far better to spend someone else’s money – especially if in the form of cryptocurrency – to enhance plausible deniability.

Many nation states prefer to slink and prowl through the ferns and fronds of software systems, abscond in shadows, slip past moonlight and crisp branches to avert the treacherous crunch that would startle their prey. Unlike successful ransomware-aaS startups⁶, nation states don’t need to run marketing campaigns to differentiate and drive demand for their services.

In general, nation state actors would like to preserve their access into target systems for as long as they can (a point to which we’ll return shortly), or else achieve other nearer-term goals in service of the longer-term mission. Being mistaken for a “nuisance” or petty criminal may hurt their pride, but, unlike too many traditionalist blue teams, they can put that aside for their mission.

These missions pile up expenses. Every attack group still must consider costs. There is no tree on this planet that grows money (though we can burn them en masse to mine cryptocurrency, true).

APTs need hardware to mount attacks, new IPs to evade detection, compute to run workloads. Those things cost money. Even money laundering costs money. For some of these things, like compute, they can steal from organizations so it comes from someone else’s wallet, not their own – but this thievery alone cannot sustain their ongoing operation.

Attack operations, like any business operation, require an intricate support system to keep running. And, like most business operations, to get more funding for your team, your mission, your whatever, you must appeal to the authorities above you.

From that perspective, is it not obvious why nation state actors would commit financial crimes? Maneuvering through someone else’s machines is easier than maneuvering through the humans who control your budget⁷.

so, tl;dr Your threat model is still predominantly money crimes.

What does this – still admittedly minor – presence of espionage mean in practice? Why does “nation state pursuing financial crimes” matter as a distinction from “cyber criminals pursuing financial crimes”? Do their methods differ so much that we need different defenses in place?

Not really.

The distinction grabs attention but is not where our focus should lie. The more relevant question is: what is the essential element of my business that makes me a target? As in, if I make it harder, are attackers going to bother someone else, or do they want me specifically for some reason?

Simply put: we should stop worrying so much about who the attackers are, and more about who we are; what makes us special, rather than what makes specific attack operators special; how our differentiation, competitive dynamics, and market strategy reveals more “threat intelligence” than whether the attacker prefers bamboo or wood pulp TTPs.

If you die in a sophisticated attack vs. a crude one, you’re still dead.

Attackers are not stupid, but they often spend their effort on relatively stupid (or “simple”) techniques. I, too, will often take the trash panda, “lazy” way⁸ rather than taking the higher-minded, effortful way unless necessary, and I suspect you, dear reader, can also relate.

The Gayfemboy botnet operators epitomize this impetus to evolve only as necessary. To wit, XLab observed:

However, the developers behind [the gayfemboy botnet] were clearly unwilling to remain mediocre. They launched an aggressive iterative development journey, starting with modifying registration packets, experimenting with UPX polymorphic packing, actively integrating N-day vulnerabilities, and even discovering 0-day exploits to continually expand Gayfemboy’s infection scale.

I certainly count the Gayfemboy botnet as “sophisticated” on these grounds⁹. I also think the Salt Typhoon campaign showed sophistication. I don’t think what the DBIR – and, certainly, the broader ecosystem – characterizes as “sophisticated” is necessarily so.

It raises a valuable question: what does sophisticated mean in the context of attacks and cybercrimes? Sophistication, definitionally¹⁰, involves flavors of:

• Understanding how things really work
• High quality or reflecting a high level of skill
• Refined taste
• Rizz¹¹

That first characteristic – understanding how the world really works – implies that sophisticated attackers will be those who adapt their techniques based on what works; sophisticated attackers won’t waste their finite time and effort on techniques that don’t.

From the attacker’s perspective, if they perform one big, flashy display their target quickly detects, now they’re dead. If they take consistent action to maintain access in their target systems for years, but those actions are “simple” or “stupid” – well, they’re still alive.

If we find someone persisted in our network for years using bash, after exploiting one lucky, exposed N-day vulnerability – maybe that is sophisticated.

Sophisticated is more about the attacker’s “broader goal” – their roadmap, vision, and ability to execute on it, if you will – rather than about the means they employ. Can an unsophisticated actor turn stolen credentials into a one-time smash and grab? Certainly. But can that actor turn those stolen credentials into getting in, and staying in, forever? Probably not. That is the hallmark of a sophisticated actor.

Perhaps an appropriate definition of “sophisticated attack” refers to how hard we must work to detect it. If we list admins and see new ones, that’s an APT TTP corresponding to MITRE ATT&CK blah blah, but that’s not very hidden, and thus not very sophisticated.

“Sophisticated attack” vibes are like, someone smart cared about this attack operation, and that’s spooky because it means they had a purpose. What was that purpose? Hence, we return to the key question of: what is the essential element of my business that makes me a target?¹²

If we apply this line of reasoning to defense, does it not imply that “sophisticated” security strategies are those that prioritize consistency over flashiness? That take incremental action to adapt and persist in their mission of preserving the values their business treasures most (like revenue, profitability, or DEI)?

3. APTs go BWAAhaha >:3

One insight that might surprise many readers in the 2025 DBIR is that Espionage-flavored actors account for approximately 62% of Basic Web Application Attacks (BWAA), up from 10 - 20% historically (largely due to the 2025 DBIR’s data contributors proffering more espionage in their data set).

As nation states largely conduct espionage, this means oft-aggrandized APTs are booping and bopping your web applications to see what works before they escalate their efforts. Their workflow, not unlike most professional cyberattackers, goes something like:

1. doodle around in shodan
2. look at some banners
3. (optional step: ingest more caffeine)
4. ponder, “what is that, anyway?”
5. google it
6. download source
7. fuck around
8. get a shell
9. throw in the wild
10. some extra steps the industry mostly ignores, anyway
11. profit / geopolitical advantage

As I stated in my last section, being sophisticated is expensive and time consuming (as any 12-step skincare girlie knows all too well). It is still really smart for APTs to try the easier path of BWAA – but it also, hopefully, demystifies them (a good thing; the industry should never have mythologized them in the first place).

“But, but,” you’re thinking, “BWAA is just the vector for them to gain access to the underlying server and pivot!”

I asked this question to the DBIR team, and they clarified that BWAA refers to messing around at the app layer itself (like XSS), while “System Intrusion” reflects app exploitation to gain access to the underlying server (like Command Execution). I find this distinction fuzzy and frustrating, and another reason why I dislike VERIS. SQLi technically messes with the interaction between the app and the database, but counts as BWAA.

While I’m ranting here, I’ll also lament that they don’t track “abuse” as much as perhaps they should. What I hear from platform eng and security eng leaders alike is that the web app and API abuse events plague them most in terms of impact.

Anyway, my venom for VERIS aside, this data point likely means nation states view these layer 7 gallavants as lucrative enough to try. An individual BWAA attack may not spill out a platoon of candy from a single app piñata, but if you can mount such attacks at scale, against many apps – which, one would hope a nation state subpod could develop such a capability – then they manifest their own whole ass Candy Land.

Through the lens of crimes of geopolitical passion (i.e. espionage) vs. money crimes, this trend perhaps also reflects how the world now conducts so much business via web apps. It’s Snowflake, Salesforce, Hubspot, Zoom, and Google Docs that vampirize our working hours, not desktop software¹³. Web apps now hold the trade secrets, the sales projections, the strategic plans, product roadmaps, financials forthcoming in an SEC filing.

Do nation states learn about and understand market trends faster than blue teams? Why do attack groups seem to experiment with and adopt emerging technology at the same time blue teams resist those innovations?

Bonus points if you ask these questions at an RSAC cocktail party as a conversation opener.

4. How do the money crimes generate money?

If most attacks – conducted by criminal organizations and nation states alike – involve financial motives, how do attackers convert those incidents and breaches into money?

The DBIR does not have many answers for us (nor is it their fault they do not), but it is, nevertheless, a worthy question to explore with the data they do present.

Ransomware is our obvious place to begin. tl;dr payouts are shrinking, and fewer organizations are paying any ransom at all (especially larger enterprises).

Are we improving at system restoration and disaster recovery? Or, alternatively, are the consequences of leaking customer data not actually that bad in practice?

Ransomware’s monetization path feels obvious, and some criminal entrepreneurs have executed that GTM strategy very well¹⁴. So, no surprise that there are no surprises in the report on the ransomware front.

The real mystery to me is why we keep seeing DDoS attacks? How are attackers even monetizing it enough to justify the effort? Why do they still try given they don’t succeed very often? These questions vex me¹⁵.

A lazy hypothesis might be that attackers are stupid. Some are stupid and delulu, like any arbitrary group of humans, but I don’t think that explains this dynamic.

Ignorance is the more plausible explanation. As in, there are absolutely nation state actors who live in their nation state bubble and don’t participate in “hallway tracks,” or casually chat with private sector tech pros, or gain any other experience other than in classified government settings. The same goes for organized criminals in locales lacking high-scale digital businesses.

There are a lot of people out there who are in relative positions of power now who may earnestly think, “oh, if I get an X gbps botnet then I can hold some digital terrain at risk!” They are probably wrong, because they do not understand CDN capacity and capability in 2025. They may not even understand CDNs exist, or that most enterprises use them¹⁶.

With that said, it’s true, based on the figures in this year’s DBIR, that most enterprises could not withstand or mitigate availability attacks on their own.

These numbers boggle the mind; scrombulate the brain, if you will. DoS attacks of this size mean that you, a typical enterprise (let alone an SMB), really can’t run a site or service on more modest infrastructure without expecting a DoS to take it out.

These figures mean you really must use an infrastructure provider that has enough scale and pay for their DDoS protection because the packet and bandwidth rates of the largest attacks are astronomical.

I must disclaim here that my Business Cat day job is serving as VP of Security Products at Fastly, who indeed is one of those infrastructure providers that provides CDN + the requisite security needed to ensure shit doesn’t go wonky when you deliver software on the public internet.

Even so, when I asked the DBIR team why they haven’t paid as much attention to network-based availability attacks, they – like many in the industry – view this as a “solved problem,” in the sense that everyone uses a CDN or CSP now to handle DoS mitigation.

There’s truth to their view, and also that, based on this data, this strategy seems to work pretty well. I found it fascinating to learn that only 2% of availability incidents (mostly DoS) lead to service interruption. Even degradation shows some level of resilience against attacks, too.

Of course, it’s worth asking: how many DoS attempts were there that could not foment sufficient damage to receive the designation of incident?

The prevalence of degradation also reflects of the nature of modern systems. We aren’t building monoliths anymore, so attackers may only succeed in taking down a part of a system – a blip rather than a blammo, so subtle that many users won’t even notice.

The flip side of this evolution away from monoliths is that it might be easier for attackers to disrupt or degrade a critical component that receives less traffic, like your cart checkout page, which will anger your customers and executives alike.

How much does that kind of targeting (and hypothetical impact) happen in practice? I hope next year’s DBIR might answer that question.

Another hypothesis is that not all criminals are good entrepreneurs. Some are quite poor at the business side of crimes, which, naturally, softens their ability to penetrate the multi-billion dollar cybercrime TAM.

Cybercrime vendors, much like cybersecurity vendors, depend on brand awareness to succeed. Sometimes they are quite bad at conceiving and executing marketing campaigns – which, from what I’ve observed, is sometimes a sign they aren’t super great at identifying product/market fit, either (as in cybercrime as in b2b tech, luck plays an enormous factor, and you can stumble into success without ever truly understanding why).

My favorite example of criminals fumbling the bag in clumsy attempts at entrepreneurship appears in the U.S. Department of Justice’s indictment against Anonymous Sudan from last year (June 2024).

Defendant AHMED OMER and UICC 1 would post messages on Telegram in channels they controlled claiming credit for these attacks, often providing proof of their efficacy in the form of Check Host reports showing that the victim computers were offline.

Their claims often did not match the reality. For instance, when they tried to DDoS Netflix and only disrupted a few regions of service, they claimed Netflix was “strongly down.”

Or, in another instance:

Overt Act No. 101: On May 22, 2023, defendant AHMED OMER sent private messages on Telegram stating, “check https://oref.org.il, if you find backend im ready to pay u good money.” The other party then sent AHMED OMER an IP address, to which AHMED OMER replied, “I fuck this ip but www.oref won’t down.”

“I fuck this IP” is lowkey iconic as a pro-DDoS product slogan, but this message, along with messages that provide an IP and ask “how to down?”, perhaps does not instill a sense of confidence in their target customer base.

While originally motivated by ideology and national pride, Anonymous Sudan tried to monetize their operation over time, including creating an automated bot to collect payments from victims seeking a ceasefire:

We can negotiate a price with you to halt all DDoS attacks immediately, and help you apply DDoS mitigation. To negotiate, contact us at our bot : @AnonymousSudan_Bot.

It is unclear to what extent they ever monetized these attacks. They claim to have in some cases, like:

On March 5, 2024, defendant AHMED OMER or another co-conspirator posted a message on Telegram stating, “After more than 48 hours of holding the Zain Bahrain network offline, we have finally reached a deal with them. Therefore, we’ll stop all attacks on their networks immediately. This entire experience proves the revolutionary power of @InfraShutdown team in holding huge networks for days and getting multi-billion companies to their knees. You can request an attack of any scale and unlock this never seen before power by contacting @InfraShutdown_bot.

But, well, do you believe their claims based on these messages?

Perhaps that’s the most common ground blue teams can find with cyber criminals: whether Telegram, or SoMA during RSAC, both of their bubbles drown in grandiose claims.

5. Attackers are still not really using GenAI

Last year, I noted that attackers aren’t using GenAI. They still aren’t, really. And when they do, it doesn’t seem to make much of a difference.

Specifically, GenAI hasn’t really made phishing “better” in some sense, because it’s still down in relative prevalence. How much of an asymmetric advantage does it really offer attackers? I suspect GenAI provides more ROI for aspiring CISO thought leaders on LinkedIn than most attackers, although the former means the latter can create their own fake aspiring thought leader CISOs for more credible social engineering.

Alas, if the DBIR hadn’t investigated GenAI involvement in incidents and breaches, I’m sure the AI evangelicals enthusiasts would’ve slandered them with, “you’re missing the LLM impact! It must be huge!” I take its inclusion as the report-writing equivalent of bequeathing someone a token object upon your death in your will so they can’t claim they were inadvertently left out.

This isn’t to say GenAI isn’t used anywhere; it clearly is, but it seems not to have improved efficacy over the previous techniques. Writing spam email with fancier LLMs instead of more basic ML doesn’t necessarily improve deliverability or fidelity.

As a final note on GenAI, since I’m sure some VC or startup bros are already thinking “but wait, what about –” no, the data set doesn’t include any real-world attacks on LLMs themselves. Maybe this will be present in next year’s data set now that people are wiring LLMs to their proprietary data sets and letting them roam as free range models with minimal supervision.

6. If you can’t make your own 0day, store-bought creds are fine

The industry obsesses over 0day¹⁷, but the 2025 DBIR shows only 8% of incidents involve vulnerabilities at all, and we must presume that even fewer of those involve zero day vulnerabilities (since, inherently, they decay into N-days once a patch releases).

Perhaps more surprising to readers is the report’s insight that not even APTs obsess exclusively over vulnerabilities (see also #3 on my list). Combing through code to uncover exploitable conditions is hard, and writing code to exploit those conditions and assumptions can be even harder. And if cybersecurity vendors will spend marketing dollars on publishing new exploitable vulns to the world, why not save a few bucks and co-opt their work?

My take is we should pay less attention to year-over-year changes and examine the longer-term trends more. The annual vagaries depend on what 0-days attackers or researchers discover, and how easy it is to write exploits for them vs. write patches for them. More precisely, all that really matters when it comes to 0day – or vulnerabilities in general – is how easy it is to turn them into a viable attack, where viable can refer to stealth, scale, consistency, and the other attributes I discussed in #2 on this list.

Consider the big topic from Verizon’s 2024 DBIR: MOVEit. MOVEit was a disaster because of their deployment model, tech-unsavvy customer base, and product proximity to ransomable data. In this year’s DBIR, system intrusion campaigns seem to be frolicking with credential abuse, phishing, BWAA – so any vulns that pop up are a bonus.¹⁸

This is an important finding to internalize from this year’s DBIR: use of stolen credentials continues to be a common attack pattern, because, to evoke Paul Hollywood from the Great British Bake-Off, it’s “simple, but effective.” It’s cheap, easy, and scales to large operations (the report notes that 80% of stolen accounts had prior exposure). Attackers might even learn to make friends in their Telegram chats along the way!

I find defenders often sleep on the potency of stolen creds, despite our general nihilism around nothing being secret anymore. The stolen cred problem is seen as “boring,” not one of those meaty technical problems into which you can sink your fangs and extract resume juice (jk, not jk).

To wit, even those infusing Secure by Design principles into how they secure their customers – a thoughtful endeavor, to be sure – may still overlook these “basic bitch” attacks. Snowflake, for example, invested considerable resources into isolating each tenant within their own separate VPC while supporting every cloud service provider¹⁹, only for those customers to get rocked by stolen credentials last year.

We should respect our opponents, but not aggrandize them. When threat modeling, assume they’ll follow Ina Garten’s advice: If you can’t make your own 0day, store-bought creds are fine.

7. Security was the real supply chain threat all along

Open source software (OSS) issues don’t even seem to be big enough to warrant a mention in the 2025 DBIR report. The only mention of OSS sits quietly in the news section towards the end, probably because talking heads and news outlets heavily report vulns in OSS due to the frankly bizarre level of distaste and disdain the traditional cybersecurity sphere feels towards OSS.

However, curiously, many of the vulns the DBIR lists as leading to incidents reside in what the report euphemistically refers to as “edge devices.” These are more accurately described as security appliances, as shown in the list I helpfully defaced below.

Perhaps the cybersecurity community should dog whistle less about the “insecure supply chain,” typically meaning open-source software, when OSS is akin to humans of code giving things away for free with no warranty. You get what you pay for.

It’s as if you raided someone’s house, tore out their wiring, then complained that the wiring was substandard copper… meanwhile your own house is stuffed with asbestos behind mercury walls.

8. Things Rot Apart

It’s 2025, and somehow VPNs and mail servers – the remnants of ye old ways where we had server janitors – persist in their ability to fuck your shit up. A simple security heuristic might be, “have you modernized or not yet?” where modernization means innovation hasn’t died and stunk up your stack like a decomposing skunk.

From that perspective, it is no surprise mail servers remain so prevalent in this data. Exchange is pooptacular (the technical term), but it’s also the best mail server out there, implying the remaining menagerie of mail servers are something like turbopooptacular²⁰.

It’s been years since Google apps murdered any remaining innovation in running your own mail server. Typical exchanges (lolol) go something like:

“We have 20 years of investment sunk in this one mail server stack. Can we integrate some better security into it? Like, idk, even rsa tokens?”

“Absolutely not, because it needs to auth to legacy Outlook, which doesn’t support that.”

“…oh, okay.”

Being a computer janitor for big, chunky, clunky servers you run on-prem is a dying industry. No one is entering it. Students aren’t excited to maintain servers older than they are. There is no innovation left to squeeze from this spoiled, shriveled lime of a niche. For organizations still maintaining such servers, this means they cannot hire people to do it, and so it all rots.

What does it mean for tech to rot, to be rotten? Tech rots either due to neglect, or the world progressing faster than it does (or faster than its operators’ knowledge). Sometimes we see both transpire in sinister symbiosis.

Tech rots when it’s all operators know, and the newer world scares or intimidates them. It rots in restructurings, reductions in force, and other such euphemisms that result in new operators who don’t want to touch it for fear of breaking it – or perhaps such changes result in no owners at all.

When we analyze through this meta lens, the data shows that the new ways – those often met with so much resistance by the recalcitrant cyber reductionists – strongly correlate with better security outcomes. None of us should suffer under the yoke of rotten tech. We don’t have to settle. And we need not sleep restlessly at night, fearing insidious incidents and bowel-shattering breaches if we modernize our technology stacks.

Conversely, rotten tech seems to serve as a leading indicator of incidents and breaches. Why do corporate IT systems rot so badly? Can we prevent it? What other harm does the rot cause? This brings us to…

9. Scooby Doo’s Spooky Kooky Corporate IT Caper

It’s hard not to ponder the macro-level incident trends and see the spectre of corporate IT. Credential management, logins, vulnerable Blinky boxes, file transfer, email compromise, VPNs… for many organizations, security teams and their smorgasbord of cybersecurity vendor products fit under corporate IT.

These systems are poorly maintained and monitored, often years out of date. With such poor hygiene, should it surprise us that they’re more likely to succumb to attacks? Thankfully, many of these IT systems live on their own infrastructure and thus can only inflict limited damage.

Security systems, however, insist on embedding themselves in every other system: if it involves a computer, someone is going to want to stick EDR on it and send logs to a SIEM. These tools want the most privileges because that’s the easier design choice for them. Should an upgrade ever need to do more than it does today, they don’t require additional permissions because they already have them all.

Some of them are even designed to run arbitrary commands remotely, which is a sign that a piece of software might be hazardous to operate. This is such an obvious point to anyone who understands how computer systems work and yet eludes way too many security teams.

Being able to run arbitrary code is an exceptional thing for a system to do. Normal software systems don’t do that. The norm is for software systems to perform their function, and if that function ever changes, someone must upgrade the system with new software.

It is perhaps the antithesis of Secure by Design and Principle of Least Privilege, and it is fucking everywhere in security land – these “edge devices” included.

This is one reason, but not the only, why the gulf between corporate IT and software engineering is wide, widens, will keep widening. Such practices indicate a cultural canyon between the two spheres.

Modern software engineering practices explicitly seek to facilitate change, agility, adaptation in ways that corporate IT practices simply do not and cannot (and it’s why savvier security leaders transform their programs towards the former). In modern software engineering, updates are routine affairs involving many more components than corporate IT handles.

If we look at custom software engineering teams build – potentially even out of vulnerable open source components, gasp! – the DBIR data (and data elsewhere) shows that this custom software seldom leads to attackers breaching their organization.

When will we see the RSAC banners about traditionalist security teams not caring enough about software security replace those that fear monger about developers? Tribal narratives are powerful weapons to wield in propaganda. We should maintain intellectual integrity and call out poor software practices when we see them – ideally with constructive recommendations on how to improve – not simp for security vendors when they exhibit egregiously poor software practices.

10. At least some things are improving somewhere

A bit of good news that deserves attention: dwell time is down by an entire week. This is a substantial decrease over only two years and suggests organizations have better mechanisms to tell when they’ve been breached.

It would be interesting to know what factors influence this improvement most. Is it primarily engendered by cybersecurity professionals / vendors leveling up their game, or does it arise from technology / architectural shifts (like those common in the fabled “digital transformation”)?

The 2025 DBIR observes a continued shift away from credit card data stolen in breaches, a trend we should also celebrate. I suspect it evinces the success of chip & PIN, as well as NFC (remember when the cyber industrial complex spewed a barrage of FUD about NFC payments and how it reflected the fraudpocalypse? Pepperidge Farm remembers).

The DBIR’s insight that Magecart represents 1% of System Intrusion breaches, but makes up 80% of payment card breaches suggests the latter has plummeted in volume. Now we just need digital payment wallets to really take off on desktop to render this category irrelevant.

11. people continue to click things on the thing clicking machine

While the Verizon DBIR is far from the worst offender on this front, security reports often give off “you need to touch grass energy.” This is especially true when they touch topics related to humans clicking on things that facilitate incidents or breaches.

Users – the humans who interact with the technology we’ve made ubiquitous in their lives – expect to be able to click things and for the world not to implode. Clicking things is what many jobs are now. It should be safe to click links in the same way that it is safe to answer the phone.

The fact that it is not is an indictment of the security industry, not human behavior.

This allows me to send you off, dear reader, with one of my old memes, so we can depart back into the cybersecurity realm with a sense of enlightenment and, hopefully, humility.

thx AP <3

Enjoy this post? You might like my book, Security Chaos Engineering: Sustaining Resilience in Software and Systems, available at Bookshop, Amazon, and other major retailers online.

This is a cool DX upgrade in itself, but this release also makes Deciduous compatible with GDPR and other regimes requiring a local development experience… like classified environments (you’re welcome federal Deciduous fanbois across the world (u know who u are)²).

If you aren’t familiar with the open source Deciduous project, nor familiar with the delectation of developing decision trees via threat modeling as code³, visit the repo for examples and getting started resources.

why use Deciduous-VS?

The Deciduous VSCode extension lets platform engineering, app dev, or security teams build decision tree-based threat models with the same live, interactive experience as the web app but within the world’s most popular IDE.

In practice, most engineering teams build and update Deciduous threat models in a collaborative fashion. Harnessing behavioral game theory to prepare for adverse scenarios requires variegated perspectives and assumption-poking by your own co-conspirators (although especially neurotic individuals, like yours truly, may enjoy solo play, too).

You’ll likely pull up Deciduous on a shared virtual screen or big screen if IRL, making on-the-fly changes to the YAML code that defines the decision tree on-the-fly. With each change – in the spirit of immediate gratification that the technological society demands – Deciduous-VS immediately updates the rendered graph in VSCode’s secondary editor pane.

Using Deciduous-VS doesn’t lock you into VScode for your decision trees; you can share the Deciduous .yaml’s between the hosted (web) version and IDE version – while respecting your organization’s classification or compliance requirements, naturally⁴.

Deciduous-VS vs. deciduous.app

Deciduous-VS offers most of the features available in the hosted app, including:

• Easy YAML structure to configure your decision trees using facts, attacks⁵ (which can be any type of failure to generalize to other platform engineering scenarios), and mitigations
• Subjective commentary (i.e. optional shade throwing) on connections between nodes, e.g. labeling a decision to perform some action as '\#yolo'
• Syntax highlighting to identify and keep track of facts, mitigations, and attacks/failures within your code
• Clickable nodes and edges in the graph that highlight the corresponding YAML source code to make navigating complex scenarios quicker
• Three graph color schemes that match the web app: dark, light, and accessible⁶

But! We actually gain more than just deciduous.app parity by slogging our way through Azure’s convoluted IAM packaging decision tree-based threat modeling into VSCode, sprouting new functionality like:

• Quickly toggling between multiple decision trees in different tabs: useful for comparing trees or, as I’ve often found when advising organizations through their cross-team threat modeling exercises, quickly flipping to a specific graph when inspiration strikes while editing a different graph (part of why decision trees are so effective for threat modeling is how they nurture emergent, evolving ideation⁷)
• Right-click export of the graph as PNG, SVG, or DOT directly to the local directory of your choice: useful for sharing the visual representation of Deciduous attack trees into other systems, from the comfort of your IDE
• Interactive git integration via VSCode’s native SCM features: useful to version decision trees over space and time as their unique context changes
• Collaborative editing via VSCode Live Share: useful for working with coworkers/co-conspirators/comrades on a decision tree without the hassle of screen sharing where only one human can make edits and everyone has to put up with blurry delayed text⁸
• Humoring security puritans: useful for editing behind a firewall or with a corporate policy that prohibits entering proprietary information into a web page (as we keep stressing, the server running deciduous.app doesn’t process your data; Deciduous runs entirely local within your browser, but the kind folks writing such security policies do not understand this (or pretend not to) nor know how to audit the source code (which is open), seemingly⁹)

installing Deciduous-VS

To get started, search for Deciduous-VS in the VS Code extension “activity”¹⁰ or press the Install button on this Visual Studio marketplace link. Once installed, activate Deciduous from the Command Palette or press the default assigned keyboard shortcut of Ctrl+Shift+D on Windows/Linux or ⌘⇧D on macOS.

By pressing these arcane symbols in the sacred order, you will command the thinking sand to vibe the Deciduous preview pane into life.

Many thanks to @fire opening the VScode extension request as well as to all my cherished fanbois who’ve bugged me for a local version over the years.

As always, we beseech you to publish your own use cases to propitiate us keep inspiring the Deciduous community and prove that threat modeling deserves civilized workflows. Please open issues in the repo should you have requests or send feedback via carrier pigeon¹¹.

After devouring so many resources for my own book, I admittedly grew a bit sick of reading¹. I dabbled more in reading short fiction and poetry via literary journals in 2023; I’m still figuring out which ones most nurture my creative energy.

As always, I am not rating or recommending any specific works in the list below. With that said, I dedicate considerable effort to screening books beforehand since time is the most precious, fleeting resource we possess.

If you’re looking for more science fiction, speculative fiction, pretentious literary fiction, philosophical navel-gazing, or non-fiction recommendations, check out my reading lists from prior years:

• 2022 reading list
• 2021 reading list
• 2020 reading list
• 2019 reading list
• 2018 reading list
• 2017 reading list
• 2016 reading list

Fiction

Convenience Store Woman by Sayaka Murata

The Daughter of Doctor Moreau by Silvia Moreno-Garcia

The Death of Vivek Oji by Akwaeke Emezi

Dept. of Speculation by Jenny Offill

The Factory by Hiroko Oyamada

Kaikeyi by Vaishnavi Patel

A Memory Called Empire by Arkady Martine

The Moon and Sixpence by W. Somerset Maugham

Nightwood by Djuna Barnes

The Overstory by Richard Powers

Robopocalypse by Daniel H. Wilson

Severance by Ling Ma

Sound and the Fury by William Faulkner

Speedboat by Renata Adler

Things You May Find Hidden in My Ear: Poems from Gaza by Mosab Abu Toha

We by Yevgeny Zamyatin

Non-fiction

Bad Gays by Huw Lemmey and Ben Miller

Color and Light: A Guide for the Realist Painter by James Gurney

Cybersecurity Myths and Misconceptions: Avoiding the Hazards and Pitfalls That Derail Us by Eugene Spafford, Leigh Metcalf, and Josiah Dykstra

The Extended Mind: The Power of Thinking Outside the Brain by Annie Murphy Paul

How Far the Light Reaches: A Life in Ten Sea Creatures by Sabrina Imbler

Proving Ground: The Untold Story of the Six Women Who Programmed the World’s First Modern Computer by Kathy Kleiman

The Technological Society by Jacques Ellul

What an Owl Knows: The New Science of the World’s Most Enigmatic Birds by Jennifer Ackerman

Wild Problems: A Guide to the Decisions That Define Us by Russ Roberts

World of Wonders: In Praise of Fireflies, Whale Sharks, and Other Astonishments by Aimee Nezhukumatathil

Every year Verizon publishes the best hope we have of scouring real world evidence of attacks and their impacts in the Verizon Data Breach Investigations Report (DBIR). I, the lucky daedric prince of chaos that I am, was privileged to receive an advance copy of the report last Sunday to ponder and prepare my thoughts (and by that I mean scramble to finish this in two witching hours).

What follows are my thoughts on the Verizon 2024 DBIR, attempting to make sense of the delectable data within and share this sensemaking with the community.

In some cases, I will cast a skeptical eye on their commentary (a meta commentary, if you will). When appropriate, I provoke the cybersecurity industry writ large. For all the ballyhooing we do about users being “irrational,” much of our security “strategy” seems quite irrational in light of this evidence…

Your threat model is still money crimes

Yet again, to my absolute lack of surprise (but somehow to the surprise of many in infosec) cybersecurity is largely about money crimes. Financial motives remain the driver of ~93% of all breaches. Yes, espionage is up from 5% last year to 7%, but highly concentrated in Public Administration (i.e. government) breaches. And, as the report mentions, “espionage” also includes things like sales bros downloading their customer contact information to take to their new employer.

Really think about this and internalize it: out of 5,632 breaches and a bias towards government victims driving this bigger sample size, they found that espionage is still only 7% of breaches.

You are not a spider caught in a sexy spy web. You do not need to spin up “war rooms” or “task forces” for geopolitical events. The real APTs – the ones motivated by geopolitical power – do not think about you at all¹.

Anyway, end-user as “threat actor” rose from 11% to 26%, but mostly due to “misdelivery” errors – sending something to the wrong recipient – that are subject to mandatory disclosure (so don’t interpret this as an “insider threat” surge).

So, if you combine “employee did a whoopsie” with “organized crime,” you get 90% of your “threat actors.” The “Other” actor type is just under 10% (based on eyeballing the chart) and includes things like activists, auditors, competitors, customers, force majeures, acquaintances, and terrorists. And then, very much last and least prevalent, we have nation-state or state-affiliated threat actors.

I know that it sounds super duper cool to be important enough for an intelligence agency to target your organization, because how elegantly does that solve one’s existential woes², our natural instinct to yearn for meaning in our life and work – a deus ex hostis, if you will – but you really do look very silly and, in light of this persistent evidence, irrational to your organization if you LARP as a counterintelligence professional.

MOVEit, pwn it, steal it, makes us poorer, sadder, weaker, bitter

They mention MOVEit precisely 25 times³ in the 2024 DBIR for good reason: they found MOVEit implicated in 1,567 breach notifications. What fascinates me is that this dwarfs Log4shell’s impact last year; it was mentioned in only 0.4% of incidents (which are more numerous than breaches in the DBIR’s parlance).

Why? Why did MOVEit foment more real-world impact? Why did the industry clamor over Log4Shell more, with a longer tail of hype and FUD? I have theories.

The first theory returns to my heuristic for software engineering teams about whether to care about a vulnerability: the vulnerability must be scalable and easy-to-use, in the specific sense that it does not require too many steps for attackers to reach their goal.

MOVEit is quite literally designed to store sensitive data in a uniform manner, making it trivial to ransom. With Log4Shell, okay, you get a shell, but how do you transmogrify that into money? You must tailor your exploit to whatever system you’re targeting, then you land on a host with who knows what – possibly nothing of value – so now you must pivot, etc. etc.

With MOVEit, you can download all the data and documents within and hope that some will contain sensitive stuff that the victim does not want exposed. Thus, 0day in MOVEit checks the boxes on both scalability and ease of use in a way Log4Shell did not.

The second theory is that MOVEit is the IT department and Log4Shell is software engineering. In theory, software designed for end users (IT) should be easier to update than software designed as a library to use in other systems; this is the typical sOftWaRe SuPpLy ChAiN fuddery.

However, I believe this shows that engineering teams can actually update pretty quickly when it matters, especially compared to end users. They have automated tooling that suggests when something is out of date and informs them when the associated update fixes vulns. (I have more thoughts on this that are mostly summarized in our RFI response on OSS).

The third theory is really more of a list of contributing factors that drove MOVEit’s impact:

• MOVEit’s customers are primarily in Education and Healthcare, sectors not known for their ability to effectively operationalize software
• On-prem deployment model (SaaS makes it easier to update on behalf of customers)
• MOVEit’s fundamental purpose is to handle sensitive data, so attackers can expect that every system in use contains some sensitive data
• Uniformity of system deployment, which makes attacks on the software straightforward to automate
• It’s internet-accessible, making it easy for attackers to discover potential victims and perform their spooky action at a distance
• Compliance software doesn’t have to be good; compliance requirements force customers to buy it anyway

In which the DBIR is alarmed that people skim emails

On page 9, the 2024 Verizon DBIR states, “This leads to an alarming finding: The median time for users to fall for phishing emails is less than 60 seconds.”

I do not understand what’s alarming about this; it feels very unsurprising. Who is spending more than a minute scrutinizing emails?

Because I like my salt with a side of science, I looked for evidence and the answer is that few people are spending whole ass minutes on emails. In 2023, Litmus found humans spend 9 seconds on average looking at an email. 30% on average receive less than two seconds of attention, while only 29% receive more than eight seconds. Given Litmus is involved in delivering the type of email we could generously deem consensual spam, we could argue that people spend a little more time looking at corporate emails… but likely not by much.

Given this, what is alarming about humans spending a median of 21 seconds to click a malicious link after opening an email? Or even taking a median of 28 seconds for the victim to enter their data? Whether we have hot girl shit to do or corporate drone shit, our universal experience is that we want to finish email as efficiently as we can so we can move onto the stuff that gets us promoted and paid.

But this is cybersecurity with its rampant projection bias and intolerance for preferences other than enshrining security as the One True Goal. So, let’s appeal to rationality instead… because clicking the link really is rational.

My extremely lazy math I posted awhile ago on Mastodon is as follows:

If we assume the average corporate worker receives ~100 biz-related emails per day during the work week⁴, that’s approximately 26k per year. Let’s assume 50% have links.

If they click on 1 malicious email link in a year, that’s a ~0.008% “fail” rate to them. Even if they click on 100 malicious links, that’s only ~0.8%.

It’s entirely rational to click the links. As I memed many years ago, we have utterly failed as an industry if our hope rests on humans not clicking things on the thing clicking machine:

Spending even 1 minute on scrutinizing each email adds up to 217 hours per year, which neither employees nor their employers will appreciate. But also, the DBIR’s framing that 20 seconds and change to click the link is “alarming” suggests that even a minute might not be sufficient.

If we consider the time it would take to truly verify everything is legit in an email — especially for non-nerds — it’s probably more like 5 minutes. That results in over 1,000 hours per year scrutinizing emails on average (again, this is extremely lazy math).

Idk about you, dear reader, but spending 45 days of my year scrutinizing emails feels so uncivilized as to border on torture. “Careless”⁵ from the security normative perspective sounds a lot more like “rational” (or even “self respect”) from another.

How to solve this? Other than the security industry finally prioritizing UX (lol), what can we do?

Well, imagine if humans of corporate received only 10 emails in their inbox per day. Might they not naturally scrutinize them more? After all, their inbox would no longer resemble a bleak grave where, just as they carve through the soil to glimpse the gentle dawn light – perhaps even a bit of sparkly dew trembling on the satin petals of a nearby tulip – the shovel clinks against headstone and dumps another fetid clump on their exhausted form.

At 10 emails per day, it is reasonable to ask employees to spend a minute being extra sure about email. I see no practical path to whittling email into this covetable state of affairs (other than more aggressive filtering to just the VIE – very important email – which might bruise some egos) (Slack or Discord, and their peers (other than Teams), might also help).

But as long as inboxes fester like a summer picnic ruined by a swarm of wasps and mosquitoes, incessant buzzes vying for our attention, then we should not demand humans immolate even more of their lives to make up for our industry’s decades-long failure to invest in UX.

Attackers are not using GenAI

I don’t really have anything to add to the 2024 DBIR’s commentary on AI except to praise it for its Real Housewives-level shade throwing.

First, in terms of evidence, they found that Gen AI didn’t even merit 100 mentions in underground crime forums over the past two years combined. When Gen AI is mentioned, it’s for gross reasons:

Most of the mentions involved the selling of accounts to commercial GenAI offerings or tools for AI generation of non-consensual pornography.

That distressing factoid aside, there are two footnotes that spark joy that I wish to highlight for you all, too.

“Despite pressure from a vocal minority of the cybersecurity community^17” –> “Foonote 17: Strange spelling for ‘unhinged marketing hype’

and

“However, it is still a very timely topic and one that has been occupying the minds of technology and cybersecurity executives worldwide ^19” –> “Footnote 19: Just like real impactful technologies such as blockchain and the metaverse.”

But there isn’t just snark here, they make an excellent point – one I’ve made as well – about how little need there is for attackers to even adopt GenAI in their operations:

One can argue, given our Social Engineering pattern numbers from the past few years, that Phishing or Pretexting attacks don’t need to be more sophisticated to be successful against their targets, as we have seen with the growth of BEC-like attacks (page 17)

Attackers do not let “good enough” be the enemy of perfect and care about results, not hype; perhaps defenders could learn from them.

Bring a bucket and a ROP for this WAP

The tl;dr here are vulns are back babyyyyyy. Exploitation almost tripled (up 180%) from last year, but still pales in comparison “ways-in” wise (i.e. initial access) to credentials or phishing; it’s 10% of initial actions in breaches. Breaking that down a bit more, attackers predominately exploited vulns in web apps, followed by desktop sharing software and VPNs.

Yet, the chart above suggests credential stuffing in a web app is still the primary way in for anything that isn’t a “whoopsie” kind of breach. Cred stuffing is certainly not as scintillating as vuln exploitation, but we shouldn’t sleep on it, either (it would be great to see the loss data associated with cred stuffing vs. exploitation, but alas). Either way, web apps remain a favorite for attackers.

On the topic of vulns more generally, they insist that “It’s much easier to harden a system than it is to harden an individual,” which suggests they are not familiar with Ao3 users.

The 2024 DBIR also veers into software supply chain territory and… well, here are my thoughts. It’s perhaps worthwhile to create a new designation for incidents and breaches involving third-party software libraries – even though I find “supply chain interconnection” odd phrasing – especially since it grew from 9% last to 15% presence in breaches (68% growth year-over-year, so close!).

But their commentary around these “supply chain interconnections” leaves much to be desired. They say:

We welcome feedback and suggestions of alternative angles, and we believe the only way through it is to find ways to hold repeat offenders accountable and reward resilient software and services with our business.

Let’s unpack that. For one, this is hardly actionable. How are we to know what software is resilient? I quite literally wrote a book on software resilience and read academic research across every possible complex systems domain regarding resilience for fun and I can tell you that none of them know how to directly measure resilience yet. Not volcanic plumbing systems, not forest ecology, not food supply chains nor neurology. Sure, we have hunches like temporal autocorrelation or functional diversity, but without this turning into a whole diatribe, suffice to say that we can barely verify that our security controls work as expected, let alone delve into those more complicated endeavors.

Next, it’s missing all sorts of stuff that we can do to minimize the impact of software vulns that aren’t “just don’t write vulns, duh.” I mean this somewhat literally, for the report says elsewhere:

If their preference for file transfer platforms continues, this should serve as a caution for those vendors to check their code very closely for common vulnerabilities.

I don’t think they were joking? But in any case, yes there are numerous other ways to frame this problem and a dazzling variety of solutions around vuln exploitation that I covered with a co-conspirator at length in two RFI responses on Security by Design as well as OSS Security so please read those if you would like a deeper dive.

Briefly, I’ll offer a few provoking questions: What if the same vulns were present, but couldn’t be chained together, or got the attacker much less access? Would there still be ~1,500 breaches reported? I suspect not, and that leads to the following jumble of points:

1. punishing devs (including the horrible DX of many vuln scanners) is far from our holy grail
2. isolation (both spatial and temporal) – and modular architecture more generally – really should get hyped more to address both the “couldn’t be chained together” and “got the attacker much less access” goals… but alas, VCs would rather fund AI holograms that shame devs for mistakes and industry thought leaders can’t sell out by promoting it
3. we do not learn from other industries; the whole point of safety in other domains is that things still work even when there are flaws, like the plane still flying with a crack in its wing, because they focus on minimizing impact
4. look at Rust’s CVE list (to really lean into my crabbiness); Rust dispenses a CVE for anything that could possibly violate the safety of its abstract machine, even if misused. If we did that with C and C++, we would see no end to CVEs; the design behavior of addition, subtraction, function calls, etc. is as vulnerable when misused (and they’re very easy to misuse); the point is: Rust tries to make certain classes of vulnerabilities impossible to write and considers it a security bug in Rust itself whenever it’s possible to write one without using unsafe (even if it’s academic and confined to sample code in a pedantic GitHub issue); C++, in contrast, considers this the user’s problem
5. anyway, the point is, there are lots of ways to disrupt attackers, many of which we can borrow from the software engineering community (who often invented these clever things to minimize the impact of performance failures); I’ve written a ton about this elsewhere in books and blogs and papers, so let’s keep moving

My final gripe related to the software vuln commentary regards their section on malicious packages (page 45). Frankly, it feels misleading. Their implication is that malicious packages have an impact on breaches, but they do not cite evidence in favor of that interpretation. If anything, the data seems mixed in; the rest of the report (rightly) focuses on impact, whereas this section is about potential.

Without that hard evidence connecting potential to real impact, it’s disappointing to see the 2024 DBIR lament how easy it is to install libraries. The benefits of software should be accessible to all. It should be easy and not gatekept by tower-skulking mages with power they hoard from the masses.

Because that same ease of installation begets the ease of upgrading, which, as stated earlier (and last year), is a key contributing factor to why Log4Shell wasn’t as horrible as we feared.

Security teams Ransomware with corporate budgets

In the 2024 DBIR, the team combines Ransomware and Extortion breaches and I agree with that decision. As they note, it’s often the same attackers conducting these operations and choosing their own adventure based on the optimal monetization of whatever access they gain. I like to abbreviate ransomware + extortion as REx, kind of like JLo⁶.

REx made up ~62% of “action varieties” in financially-motivated breaches, while pretexting (like business email compromise) was 24%. One especially interesting finding to me in the DBIR was that, when they removed Ransomware groups from the “system intrusion” dataset (the types of exploit pew pew compromises we glamorize), the actor split is 44% criminal and 40% state-affiliated actors. I interpret this as evidence that criminals overwhelmingly pivoted to REx – for exploit pew pew operations, at least – away from other monetization methods, like the now-uncool payment skimming.

The 2024 Verizon DBIR reports that the median loss from ransomware and extortion breaches is up to $46,000 with a loss range of $3 to $1,141,467 for 95% of cases. The $3 lower bound is up from $1 last year, which follows NYC pizza slice inflation pretty well.

They also leveraged data from a ransomware negotiator – which means there’s inherent bias in the data towards well-resourced organizations – and found that the median ratio of the initially requested ransom to company revenue was 1.34% (between 0.13% and 8.30% in 80% of cases); presumably the final median ratio was lower after they negotiated the payment down.

But, only 4% of ransomware + extortion complaints had any actual loss, down from the already-meager 7% last year. Specifically, 96% of ransomware incidents resulted in no direct loss (there might be subsequent costs associated with investigation, etc., but the DBIR is not privy to those).

Okay, so, let’s do some more bad math: if we have a meager 4% probability of loss and multiply it by the 1.34% revenue figure, we get a preposterously approximate budget of 0.05% of revenue for ransomware protection (to break even on the loss).

For a company guzzling $100mm in revenue, the median spend on ransomware should therefore be ~$54,000. If you’re buying EDR, that gets you something like ~300 licenses at best, which is way too few for most organizations making that much money. More likely, these organizations have at least 1k endpoints, which would be more like $185k per year for EDR… and this ignores the cost of backups and other things that are very useful to minimize the impact of ransomware.

To be clear, I’m not saying we should “let the bad guys win” or all the other pejoratives security pros have thrown at me over the years when I talk about the economics of cyber stuff⁷. The reality is that there is a huge trust problem in many companies between the cybersecurity org and the rest of the org, and talking about the sky is falling and it’s going to cost us a blahajillion of dollars will not help your cause.

It’s far better to present this kind of evidence with a range of options like (assuming an example revenue of $100mm):

• We start with the assumption of 4% probability of any loss
• We can assume either the 20% confidence interval, median, or 80% confidence interval
• These options mean we either invest $5,200; $53,600; or $332,000 on ransomware protection
• If we want to really cover tail risk, we can look at the 95% interval, which means we’d invest $999,600 on the problem
• Then list out what mitigations you can get at those price points, starting with backup costs or implementing isolation / modularity, then moving to fancier things like EDR
• Now the organization can make an informed choice! Probably even they will agree spending $5,200 is absurd, especially when we’d likely want backups for other use cases, anyway. And they’ll likely reject the nearly $1mm option, too. But in between is a lot of wiggle room and now you look like a well-informed leader rather than Don Quixote.

Conclusion

I unironically relish the Verizon DBIR, and 2024 is no exception. We are an industry starved for data and they throw their whole being into trying to untangle the mess of incident and breach reports into something informative and consumable by the community. You can read it here.

Yes, I quibble with some things as always, but this is really a great input for anyone – security teams or engineering teams alike – to inform their investments. If you’re a vendor who has information that could be useful, please consider contributing to the report⁸ as a way to level up everyone’s understanding of what the everliving fuck is actually going on in cybersecurity.

<3 thanks AP

Enjoy this post? You might like my book, Security Chaos Engineering: Sustaining Resilience in Software and Systems, available at Amazon, Bookshop, and other major retailers online.

Secure by Design is a strategy we believe can nurture a future where technology is safe, secure, and resilient. But Secure by Design is a zeitgeisty topic that could be distorted into security theater or captured by crusty vendors to benefit themselves.

Indeed, we fear the whitepaper in question is overly focused on “forcing” organizations to prioritize security equally to business success rather than understanding what principles and practices would lead to the outcomes we need as a global software community. Many of the recommendations incentivize lip service, for software manufacturers to “prove” their commitment to security through words rather than actions.

We believe this is woefully misguided. We believe Secure by Design can align with business priorities like software velocity, developer productivity, and reliability in production. We believe in outcomes rather than outputs. So, our response enumerates principles and practices that software engineering teams can adopt without getting fired for ignoring business goals.

Similar to our prior RFI response on open source security, our commentary is exhaustive since we wanted to not only offer our expertise but enumerate as many potential opportunities for organizations to apply secure by design in practice as we could in light of only finding out about the RFI a week before it was due. In that vein, for those of you looking for, “How should my software engineering team(s) start investing in secure by design?” we suggest you read Section 1.2.1 in our response.

Our response begins with overall commentary on CISA’s whitepaper, both where we agree and, more often, where we disagree – but proposing ample alternatives along the way. After that, we address multiple question areas from the RFI ranging from economic incentives and dynamics; threat modeling; education; and more.

We are publishing our response in the spirit of transparency; you can read it at the following link: https://kellyshortridge.com/papers/CISA-2023-0027-Shortridge-Sensemaking.pdf

In the spirit of shepherding the Secure by Design movement towards the resilient future we envision, we feel privileged to submit our recommendations for CISA to consider as they navigate how to nourish Secure by Design in practice.

Note that we are submitting as Shortridge Sensemaking LLC. The views expressed in our response are not necessarily the views of our employers or any of their affiliates. The information contained herein is not intended to provide, and should not be relied upon for, investment advice (which we would hope is obvious).

Enjoy this post? You might like my book, Security Chaos Engineering: Sustaining Resilience in Software and Systems, available at Amazon, Bookshop, and other major retailers online.

Below are the chapter takeaways from my book, Security Chaos Engineering: Sustaining Resilience in Software and Systems. My hope is these summaries can serve as a cliff notes study guide on the mosaic of concepts within the tome³ — at least the basics — and make the software resilience approach more accessible to curious beings wanting to do software security better.

As a sneaky bonus, this post serves as a suitable citation for those of you who are only allowed to cite public / non-commercial sources (which my book is not):

Shortridge, Kelly. “The Basics of Software Resilience and Security Chaos Engineering.” Sensemaking by Shortridge (blog). January 4, 2024. https://kellyshortridge.com/blog/posts/security-chaos-engineering-sustaining-software-systems-resilience-cliff-notes/

tl;dr — My standard definition of Security Chaos Engineering is “a socio-technical transformation that enables the organizational ability to gracefully respond to failure and adapt to evolving conditions.” This applies to my concept of Platform Resilience Engineering, too. Really, it’s all about sustaining resilience in practice.

Resilience in Software and Systems

Takeaways from Chapter 1

• All of our software systems are complex. Complex systems are filled with variety, are adaptive, and are holistic in nature.
• Failure is when systems — or components within systems — do not operate as intended. In complex systems, failure is inevitable and happening all the time. What matters is how we prepare for it.
• Failure is never the result of one factor; there are multiple influencing factors working in concert. Acute and chronic stressors are factors, as are computer and human surprises.
• Resilience is the ability for a system to gracefully adapt its functioning in response to changing conditions so it can continue thriving.
• Resilience is the foundation of security chaos engineering. Security Chaos Engineering (SCE) is a set of principles and practices that help you design, build, and operate complex systems that are more resilient to attack (and other types of failures, too).
• The five ingredients of the “resilience potion” include understanding a system’s critical functionality; understanding its safety boundaries; observing interactions between its components across space and time; fostering feedback loops and a learning culture; and maintaining flexibility and openness to change.
• Resilience is a verb. Security, as a subset of resilience, is something a system does, not something a system has.
• SCE recognizes that a resilient system is one that performs as needed under a variety of conditions and can respond appropriately both to disturbances — like threats — as well as opportunities. Security programs are meant to help the organization anticipate new types of hazards as well as opportunities to innovate to be even better prepared for the future (whether new incidents, market conditions, or more).
• There are many myths about resilience, four of which we covered: resilience is conflated with robustness, the ability the “bounce back” to normal after an attack; the belief that we can and should prevent failure (which is impossible); the myth that the security of each component adds up to the security of the whole system (it does not); and that creating a “security culture” fixes the “human error” problem (it never does).
• SCE embraces the idea that failure is inevitable and uses it as a learning opportunity. Rather than preventing failure, we must prioritize handling failure gracefully — which better aligns with organizational goals, too.

Systems-Oriented Security

Takeaways from Chapter 2

• If we want to protect complex systems, we can’t think in terms of components. We must infuse systems thinking in our security programs.
• No matter our role, we maintain some sort of “mental model” about our systems — assumptions about how a system behaves. Because our systems and their surrounding context constantly evolve, our mental models will be incomplete.
• Attackers take advantage of our incomplete mental models. They search for our “this will always be true” assumptions and hunt for loopholes and alternative explanations (much like lawyers).
• We can proactively find loopholes in our own mental models through resilience stress testing. That way, we can refine our mental models before attackers can take advantage of inaccuracies in them.
• Resilience stress testing is a cross-discipline practice of identifying the confluence of conditions in which failure is possible; financial markets, healthcare, ecology, biology, urban planning, disaster recovery, and many other disciplines recognize its value in achieving better responses to failure (versus risk-based testing). In software, we call resilience stress testing “chaos experimentation.” It involves injecting adverse conditions into a system to observe how the system responds and adapts.
• The E&E Approach is a repeatable, standardized means to incrementally transform toward resilience. It involves two tiers of assessment: evaluation and experimentation. The evaluation tier is a readiness assessment that solidifies the first three resilience potion ingredients: understanding critical functions, mapping system flows to those functions, and identifying failure thresholds. The experimentation tier harnesses learning and flexibility: conducting chaos experiments to expose real system behavior in response to adverse conditions, which informs changes to improve system resilience.
• The “fail-safe” mindset is anchored to prevention and component-based thinking. The “safe-to-fail” mindset nurtures preparation and systems-based thinking. Fail-safe tries to stop failure from ever happening (impossible) while safe-to-fail proactively learns from failure for continuous improvement. The fail-safe mindset is a driver of the status quo cybersecurity industry’s lack of systems thinking, its fragmentation, and its futile obsession with prediction.
• Security Chaos Engineering (SCE) helps organizations migrate away from the security theater that abounds in traditional cybersecurity programs. Security theater is performative; it focuses on outputs rather than outcomes. Security theater punishes “bad apples” and stifles the organization’s capacity to learn; it is manual, inefficient, and siloed. Instead, SCE prioritizes measurable success outcomes, nurtures curiosity and adaptability, and supports a decentralized model for security programs.
• RAV Engineering (or RAVE) reflects a set of principles—repeatability, accessibility, and variability — that support resilience across the software delivery lifecycle. When an activity is repeatable, it minimizes mistakes and is easier to mentally model. Accessible security means stakeholders don’t have to be experts to achieve our goal security outcomes. Supporting variability means sustaining our capacity to respond and adapt gracefully to stressors and surprises in a reality defined by variability.

Architecting and Designing for Software Resilience

Takeaways from Chapter 3

• Our systems are always “becoming,” an active process of change. What started as a simple system we could mental-model with ease will become complex as it grows and the context around it evolves.
• When architecting and designing a system, your responsibility is not unlike that of Mother Nature: to nurture your system so it may recover from incidents, adapt to surprises, and evolve to succeed over time.
• We — as individuals, teams, and organizations — only possess finite effort and must prioritize how we expend it. The Effort Investment Portfolio concept captures the need to balance our “effort capital” across activities to best achieve our objectives.
• When we allocate our Effort Investment Portfolio during design and architecture, we must consider the local context of the entire sociotechnical system and preserve possibilities for both software and humans within it to adapt and evolve over time.
• There are four macro failure modes for complex systems that can inform how we allocate effort when architecting and designing systems. We especially want to avoid the Danger Zone quadrant—where tight coupling and interactive complexity combine — because this is where surprising and hard-to-control failures, like cascading failures, manifest.
• We can invest in looser coupling to stay out of the Danger Zone. In this chapter, I covered numerous opportunities to architect and design for looser coupling; the best opportunities depend on your local context.
• Tight coupling is sneaky and may only be revealed during an incident; systems often inadvertently become more tightly coupled as changes are made and we excise perceived “excess.” We can use chaos experiments to expose coupling proactively and refine our design accordingly.
• We can also invest in linearity to stay out of the Danger Zone. We described many opportunities to architect and design for linearity, including isolation, choosing “boring” technology, and functional diversity. The right opportunities depend, again, on your local context.
• Scaling the sociotechnical system is where coupling and complexity especially matter. When immersed in the labyrinthine nest of teams and software interactions in larger organizations, we must tame tight coupling (by investing in looser coupling) and find opportunities to introduce linearity — or else find our forward progress crushed.
• Experiments can generate evidence of how our systems behave in reality so we can refine our mental models during design and architecture. If we do our jobs well, our systems will grow and therefore become impossible to mentally model on our own. We can leverage experimentation to regain confidence in our understanding of system behavior.

Building and Delivering for Software Resilience

Takeaways from Chapter 4

• When we build and deliver software, we are implementing intentions described during design, and our mental models almost certainly differ between the two phases. This is also the phase where we possess many opportunities to adapt as our organization, business model, market, or any other pertinent context changes.
• Who owns application security (and resilience)? The transformation of database administration serves as a template for the shift in security needs; it migrated from a centralized, siloed gatekeeper to a decentralized paradigm where engineering teams adopt more ownership. We can similarly transform security.
• There are four key opportunities to support critical functionality when building and delivering software: defining system goals and guidelines (prioritizing with the “airlock” approach); performing thoughtful code reviews; choosing “boring” technology to implement a design; and standardizing “raw materials” in software (like memory safe languages).
• We can expand safety boundaries during this phase with a few opportunities: anticipating scale during development; automating security checks via CI/CD; standardizing patterns and tools; and performing dependency analysis and vulnerability prioritization (the latter in a quite contrary approach to status quo cybersecurity).
• There are four opportunities for us to observe system interactions across spacetime and make them more linear when building and delivering software and systems: adopting Configuration as Code; performing fault injection during development; crafting a thoughtful test strategy (prioritizing integration tests over unit tests to avoid “test theater”); and being especially cautious about the abstractions we create.
• To foster feedback loops and learning during this phase, we can implement test automation; treat documentation as an imperative (not a nice-to-have), capturing both why and when; implement distributed tracing and logging; and refine how humans interact with our processes during this phase (keeping realistic behavioral constraints in mind).
• To sustain resilience, we must adapt. During this phase, we can support this flexibility and willingness to change through five key opportunities: iteration to mimic evolution; modularity, a tool wielded by humanity over millennia for resilience; feature flags and dark launches for flexible change; preserving possibilities for refactoring through (programming language) typing; and pursuing the strangler fig pattern for incremental, elegant transformation.

Operating and Observing for Software Resilience

Takeaways from Chapter 5

• Operating and observing the system is the phase where we can witness system behavior as it runs in production, which can reveal where our mental models are inaccurate. It is when we can glean valuable insights about our systems and incorporate this data into our feedback loops.
• Security is woven into all three key aspects of reliability that reflect user expectations: availability, performance, and correctness.
• Site reliability engineering (SRE) goals and security goals overlap to a significant degree, making those teams natural allies in solving reliability and resilience challenges. A key difference is that SRE understands that moving quickly is correlated with reducing the impact of failure; security must adopt this mindset too.
• Attackers can directly measure success and immediately receive feedback, giving them an asymmetric advantage. We must strive to replicate this for our goals too.
• To measure operational success, we can borrow established metrics like the DORA metrics and craft thoughtful SLOs that help us learn more about the system.
• Success is an active process, not a one-time achievement. We must support graceful extensibility: the capability to anticipate bottlenecks and “crunches,” learn about evolving conditions, and adapt responses to stressors and surprises as they change.
• We want to mimic the interactive, overlapping, and decentralized sensitivities of biological systems in our observability strategy. In particular, we want to observe system interactions across space and time. We must maintain the ability to reflect on three key questions: How well is the system adapted to its environment? What is the system adapted to? What is changing in the system’s environment?
• Tracking when a system is repeatedly stretching toward its limit (“thresholding”) helps us uncover the system’s boundaries of safe operation. Increasingly “laggy” recovery from disturbances in both the socio and technical parts of the system can indicate erosion of adaptive capacity.
• Attack observability refers to collecting information about the interaction between attackers and systems. It involves tracing attacker behavior to reveal how it looks in reality versus our mental models. Deception environments can facilitate attacker tracing, fuel a feedback loop for resilient design, and serve as an experimentation platform.
• A scalable system is a safer system. System signals used to measure scalability can be used as indicators of attack too; we discussed many, including autoscaling replica count, heartbeat response time, and resource consumption.
• Being a gatekeeper to growth is not an effective way to achieve security outcomes. Scalability forces high-friction processes and procedures to adapt to growth, which is healthy for sustaining resilience.
• We should apply the concept of toil, from SRE, to security. For any task that a computer can perform better than a human — like those requiring accurate repetition — we should automate it. Doing so frees up effort capital that we can expend on higher-value activities that leverage human strengths like creativity and adaptability.

Responding and Recovering for Software Resilience

Takeaways from Chapter 6

• Incidents are like a pop quiz. To prepare for them and ensure we can respond with grace, we must practice incident response activities—and can do so through chaos experimentation.
• The Effort Investment Portfolio applies to incident response too. Effort expended earlier in the software delivery lifecycle will reduce the effort required when responding to incidents (this does not mean “shift left,” at least in its popularized / monetized form).
• Humans often feel an impulse toward action (action bias), which can reduce effectiveness during incident response. Practicing “watchful waiting” can curtail knee-jerk reactions.
• There is no “best practice” for all incidents. The best we can do is practice incident response activities to nurture human responders’ adaptive capabilities.
• Repeated practice of response activities through chaos experimentation can turn incidents from stressful, scary situations into confidence-building, problem-solving scenarios.
• Recovering from incidents requires adaptation, and learning is a prerequisite for this adaptation. Learning from incidents to develop memory of failure is about community, so if we blame community members for the incident, we will struggle to learn.
• A blameless culture helps organizations stay in a learning mindset — uncovering problems early and gaining clarity around incidents — rather than play the “blame game.” It encourages people to speak up about issues without fear of being punished for doing so.
• There are two contributing factors always worth discussing during incident review: relevant production pressures and system properties.
• Humans at the “sharp end,” who interact directly with the system, are often blamed for incidents by humans at the “blunt end,” who influence the system but interact indirectly (like administrators, policy prescribers, or system designers). The disconnect between the two can be summarized as the delta between “work-as-practiced” and “work-as-imagined.”
• The cybersecurity industry often (unproductively) blames users for causing failures, as evidenced by the acronym PEBKAC: problem exists between keyboard and chair. A more useful heuristic is PEBRAMM: problem exists between reality and mental model. An error represents a starting point for investigation; it is a symptom that indicates we should reevaluate design, policy, incentives, constraints, or other system properties.
• There are numerous biases that tempt us to blame human error during incidents, which hinders our capacity to constructively learn from and adapt to failure. With hindsight bias, we allow our present knowledge to taint our perception of past events (the “I knew it all along” effect). With outcome bias, we judge the quality of a decision based on its eventual outcomes. The just-world hypothesis refers to our preference for believing the world is an orderly, just, and consequential place. All of these biases warp our perception of reality.
• During incident review, use neutral practitioner questions to stay curious and intellectually honest. Neutral practitioner questions re-create the context surrounding an event and ask practitioners what actions they would take given this context. It helps sketch a portrait of local rationality: the reasonable course of action in the presence of contextual trade-offs and constrained information-processing capabilities.

Platform Resilience Engineering

Takeaways from Chapter 7

• At the “meta-design” level, we can sustain resilience through organizational structure and practices—transforming from a siloed security program into a platform engineering model (“platform resilience engineering”).
• We must be aware of production pressures and how they tip sociotechnical systems toward failure. Production pressures involve the incentivization of less expensive and more efficient work, with quality (and security as its subset) as the typical sacrifice.
• A platform engineering approach to resilience treats security as a product with end users, as something created through a process that provides benefits to a market (with internal teams as our customers). Platform Engineering teams identify real problems, iterate on a solution, and prioritize usability to promote adoption. Resilience is a natural fit for their purview.
• Any product requires a long-term vision — a unifying theme for all your projects toward a defined end. The vision tells a story of what is being built and why.
• Treating resilience — including security — as a product starts with identifying the right user problems to tackle. To accurately define user problems, we must understand their local context. We must understand how our users make tradeoffs under pressure, maintain curiosity about the workarounds they create, and respect the limitations of their brains’ computational capacity (“cognitive load”).
• Security solutions become less reliable as their dependence on human behavior increases. The Ice Cream Cone Hierarchy of Safety Solutions helps us prioritize how we design security solutions, from best to least effective. Starting from the top of the cone, we can eliminate hazards by design; substitute less hazardous methods or materials; incorporate safety devices and guards; provide warning and awareness systems; and, last and least effective, apply administrative controls (like guidelines and training).
• There are two possible paths we can pursue when solving user problems: the control strategy or the resilience strategy. The control strategy designs security programs based on what security humans think other humans should do; it is convenient for the Security team at the expense of others’ convenience. The resilience strategy promotes and designs security based on how humans actually behave; success is when our solutions align with the reality of work-as-done. The control strategy makes users responsible for security while the resilience approach makes those designing security programs and solutions responsible for it.
• We should build minimum viable products (MVPs) and pursue an iterative change model informed by user feedback.
• We should gain consensus about our plans for solving resilience problems — from vision through to implementation of a specific solution — and ensure stakeholders understand the why behind our solutions. Success is solving a real problem in a way that delivers consistent value.
• To facilitate solution adoption, we must plan for migration and pave the road for our customers to adopt what we’ve created for them (hence the strategy of creating “paved roads”). We should never force solutions on other humans; if that is the only way to drive adoption, then it is a failure of our design, strategy, and communication.
• Measuring product success is necessary for our feedback loops, but can be tricky. If we design solutions for use by engineering teams, the SPACE framework offers numerous success criteria we can measure. In general, we should be curious about the factors contributing to success and failure for our internal customers.
• Any metrics related to how “secure” or “risky” something is, like percentage of “risk coverage,” are busywork based on measuring the (highly subjective) unmeasurable. We need to measure our program’s success—and any solutions we design as part of it—based on tangible, realistic goals.

Security Chaos Experiments

Takeaways from Chapter 8

• Experimentation is a cycle of discovery and learning, which is what drives scientific progress. Resilience stress tests (aka security chaos experiments) are like applying the scientific method to software and systems security.
• Early adopters of security chaos experimentation learned three key lessons: first, it’s fine to start in nonproduction environments because you can still learn a lot; second, use past incidents as inspiration for experiments and to leverage organizational memory; third, make sure to publish and evangelize your experimental findings because expanding adoption will become your hardest challenge (the technical work is comparatively easy).
• To set chaos experiments up for success, especially the first time, we need to socialize the experiment with relevant stakeholders. Investing in the right messaging and framing at the beginning will reduce friction later.
• The next step is designing an experimental hypothesis. Hypotheses typically take the form of: “In the event of the following X condition, we are confident that our system will respond with Y.”
• Once we have a hypothesis, we can design our experiment so we uncover the behavior about which we want to learn. There are numerous considerations: where we conduct the experiment, how we measure success, potential impacts, fallback procedures, and more.
• Documenting a precise, exact experiment design specification (“spec”) is critical. Our goal with the spec is for our organization to gain a luculent understanding of why we’re conducting this experiment, when and where we’re conducting it, what it will involve, and how it will unfold.
• Launching an experiment is not unlike a feature release. Our preparation in socializing the experiment, designing the hypothesis, and defining the experiment specifications makes this one of the easier phases.
• What evidence we collect when conducting an experiment is defined by the spec; we should already know what we’re monitoring and what evidence we expect.
• The first step after we’ve collected evidence is confirming we collected the evidence we sought from the experiment. The second step is to analyze the data with regard to the hypothesis. Our goal is to compare our observations with our predictions — to verify and refine our mental models of the system, which informs what actions we can take to sustain its resilience to adversity.
• We should communicate our experimental findings through release notes. Most stakeholders don’t need lots of detail; we should synthesize and summarize our experimental insights, highlighting any action items. Once those action items are performed, we can rerun the experiment.
• After your first experiment, or after you run an experiment the first time, you can automate it for continuous use. Because our systems — and the reality around them — are constantly changing, we must continuously generate evidence lest it grow stale.
• Game days, a more manual form of conducting a security chaos experiment, can help more hesitant organizations ease into chaos experimentation.
• There is no end to the kinds of security chaos experiments you can conduct in your systems. In this chapter, I enumerated many applicable to production infrastructure, build pipelines, service-oriented environments, and Windows environments.

Case Studies

Takeaways from Chapter 9

It’s hard to capture the cliff notes for the case studies Aaron Rinehart compiled from UnitedHealth Group, Verizon, OpenDoor, Cardinal Health, Accenture Global, and Capital One. Plus, it’s the only chapter I didn’t write on my own in the book, so I feel I wouldn’t do it justice.

But, my personal takeaways from the case studies are:

1. Collaboration is key; to succeed in security, we must not only establish healthy communication with other teams but be open to them teaching us, too — especially platform engineering and SRE teams, who possess a wealth of experience we can leverage in our resilience journey.

2. The resilience / SCE transformation is not exclusive to a certain type of organization. Fortune 10, highly-regulated organizations can pursue it. So can smaller, scrappy startups. And this speaks to something I really tried to emphasize in the book: the resilience approach isn’t about revolutionizing X, Y, Z overnight and doing them perfectly; it’s about iteratively changing how you do things towards more resilient outcomes. It’s about experimentation at basically all levels, whether experimenting with new modes of collaboration with software engineering teams, conducting resilience stress tests, or trying any of the zillion strategies I described in the book. For some organizations, it’ll be easier to iteratively migrate to memory safe languages; for others, it’ll be easier to migrate to running workloads on immutable infrastructure or implementing integration testing or so many other things that can make a difference outcome-wise.

3. A learning culture is critical. This doesn’t mean we defenestrate all caution so it flails on the restless winter winds. It means we conduct small experiments to generate evidence and inform what we do next. It means we assume by default that most humans are just trying to do their jobs, and that means we don’t automatically blame them when something goes wrong — nor do we treat our colleagues like our adversaries (as it turns out, cyber criminals are our real adversaries⁴, who knew!). We look critically at how our systems and processes are designed, then brainstorm how to iteratively improve them over time. If a system is confusing or cumbersome to use, then that’s a design problem, not a “human error” problem. Nearly every case study in this chapter highlights the imporance of psychological safety in the transformation towards resilience for a reason.

Enjoy this post? You might like my book, Security Chaos Engineering: Sustaining Resilience in Software and Systems, available at Amazon, Bookshop, and other major retailers online.

This is not, in fact, a fact. It’s closer to propaganda. Cybersecurity isn’t that special. And cybersecurity shouldn’t be that special if we want to minimize the damage of cyberattacks in our software systems.

In this post, I’ll excoriate special snowflake security programs then offer opportunities for how we can make our programs more constructive rather than constrictive.

Is cybersecurity special?

For the sake of honest discourse, let’s consider some of the reasons cyber thought leaders often cite why cybersecurity is a special snowflake – and debunk them:

1. It’s hard to prove our value because it’s based on counterfactuals.

Site reliability engineering (SRE) teams face the same challenge, but mewl much less about it.

2. There are so many software changes across so many teams and how could we possibly make improvements to those activities?

This is literally the mission of platform engineering teams, and many can even provide evidence for the value of their improvements.

3. Attackers are especially clever humans whose purpose in life is to harm us.

Attackers can be clever, but often aren’t – and also the reliability failures we see from “especially clever” developers/teams can foment far more harm than attackers could ever dream. Interns were destroying data long before ransomware gangs were.

4. We’re seen as a cost center!

Again, talk to your SREs or platform engineers or, if you want to hear what it’s really like to be continually dismissed, your D&I colleagues.

5. Software systems are so complex, how could we ever hope to understand them enough to secure them?

Ask basically anyone in your engineering org whether software complexity makes their job harder, especially anyone who mumbles about Lamport clocks during architecture reviews. You think having a nation state as an adversary is bad? They’re fighting against the fundamental laws of physics.

With all due respect

In sum, cybersecurity really isn’t as esoteric and arcane a problem as we believe. Yet, I’m often met with disbelief by cyberppl that things are really that hard for their platform/infra/devops/SRE colleagues. Sometimes it feels like cybersecurity leaders and engineers think that all these teams were automagically bequeathed respect – autonomy, budget, authority – by the business.

And, in that vein, I’ve heard CISO described as “the hardest job in corporate America” and maybe it is if you’re scrambling to cover up felonies, but nearly every problem I hear security leaders complain about is mirrored on the infra and platform and SRE side of things¹.

This respect must be earned. These other teams earn it by solving reliability and developer productivity challenges in clever ways. They do the hard work of thinky thinky and buildy buildy rather than foisting cumbersome policies and tools on software engineers in what I call the SSB model (for “sink or swim, bitch”)². They don’t carve 100 security commandments into Confluence; they build patterns, frameworks, and tooling that encode the right requirements to make the better way the easier, faster way for software engineers.

If cybersecurity wants to earn similar respect, it can’t keep roadblocking and gatekeeping software. It can’t pretend like security failure is so distinct in importance and impact that it requires completely separate workflows, stacks, reviews, tooling, design, and basically everything else. Attackers accessing our systems without our consent is one type of failure, but not the only kind. Reliability failures are arguably both more frequent and more damaging when they occur; developer productivity failures can mean the difference between successful market differentiation and losing market share.

Resilience, not roadblocks

This is precisely why I emphasize software resilience, because it encompasses our reliability and cybersecurity concerns. It’s about our goal outcome: we want systems that can adapt to failures and opportunities alike in an ever-changing world. Those failures can be borne by cyberattackers or by performance bugs or a broken developer experience (DX) – the difference really doesn’t matter as much as we think.

The common “enemy” is unintended behavior. Indeed, it is our ancient archnemesis, the eternal foe that formal methods could not vanquish. Having separate pipelines, observability stacks, or review processes for every contributing factor to unintended behavior would be an operational disaster, and yet cybersecurity insists on precisely this for itself.

It really doesn’t make sense for cybersecurity to have its own special snowflake process for things. It does not make sense operationally, philosophically, or socially. It does not make sense to sustain systems resilience. And it even does not make sense for software security.

If we want to sustain resilience at scale, then we should brainstorm strategies to improve system resilience across failures. In a practical sense, it doesn’t matter whether a service goes down due to a performance bug or an attacker exploiting a security bug; the outcome to the business is lost revenue either way.

For example, a queue or message broker could help us restore service health in either scenario³. Should we ignore this design-based solution in favor of the security team needing to review and approve every single software release because it potentially has exploitable bugs and now the backlog is at least six months long which leads to larger batch sizes by software engineers which leads to higher failures rates and by the Eight Divines⁴, why does anyone actually think this is an okay state of affairs? The empire building may feel good, but it’s bad for everyone.

By now, there are some security leaders⁵ fuming that I’m telling them to rip out their precious pet process. This is about the time when, in an IRL convo, they usually retort, “Well, what are you saying, that we shouldn’t care about cybersecurity at all?” That is never what I’m saying. We should care about cybersecurity but we should not silo it or treat its concerns as separate because it actually worsens the outcomes we purportedly care about long-term.

So, what do we do instead of roadblocking? There are a ton of opportunities cybersecurity and platform engineering teams can pursue to achieve the end goal we seek – and far more effectively than heavy-handed cyber design / code reviews. Let’s go through some.

What to do instead of roadblocking

1. Self-certification to guidelines. Let product engineering teams self-certify based on (relatively) complete guidelines we’ve written beforehand. Some cybersecurity teams claim they already do this, but software engineers often find these guidelines too vague and will thus work around them. Typically, this is because the cybersecurity team operates with a “I know it when I see it” mentality on how “secure” looks. And because the cybersecurity team does not have software engineering expertise, it’s often divorced from how software delivery actually works.

2. Follow Platform/SRE’s lead. Integrate security design reviews into the general design/architecture review process (and same with code reviews). Collaborate with site reliability engineering (SRE) or platform engineering teams on this; learn how they ensure their reliability requirements are considered during design review and… do exactly that, basically. Ultimately, both stakeholders (reliability and cybersecurity) want similar outcomes, so the more we can find design opportunities that eliminate or reduce hazards in the system – towards resilience and security by design – the safer and more reliable our code will be (i.e. higher quality).

3. Build standardized patterns. Build standard solutions for “cross-cutting concerns” that apply to all services and software (also called “paved roads” or “patterns”). These are typically built by platform engineering teams for cross-cutting concerns related to performance and reliability. Where platform engineering teams have built them for cybersecurity concerns, it is because they grew frustrated by the cybersecurity team’s inertia and inefficacy, and thus built the standard solutions themselves.

There are a few cybersecurity teams who already build these standard solutions in practice (like at Netflix, Block, and others who I wish would publicize their efforts, hint hint). But I also still hear CISOs who claim doing so is “impossible” (it is objectively not).

For instance, we can create architectural or coding patterns that make it easier to write safer code (or, conversely, make it harder to introduce certain classes of bugs). We can provide standardized libraries for middleware that’s fraught with hazards, like authentication. Product engineering teams thereby save time by not having to implement authN themselves and we gain confidence that there aren’t a bunch of potentially jank, ad-hoc authN disasters lurking.

4. Abandon the perimeter model. Abandon the perimeter, moat-and-castle model that requires all software to be “secure” always and forever to uphold the security properties we want – because guess what, that assumption will inevitably fail. Many organizations already have dev, test, or staging environments that allow us to evaluate our assumptions about how our software works. These environments also serve as a pattern for creating isolated environments that can contain failure impact (see #7).

If your organization doesn’t already have a test or staging environment, that’s a great starter project for your cybersecurity team to make an impact; while you’re at it, advocate for integration testing, too.

5. Advise, don’t dictate. Provide an advisory service where software engineers can ask us for assistance or guidance on security-related matters. It’s better if designers and engineers can balance security tradeoffs with the others they face such as reliability, maintainability, and time-to-market instead of the security team dictating design requirements. This is a key way to align the cybersecurity program with the business.

6. Ask platform teams to integrate security. Work proactively with infrastructure and platform teams to integrate security use cases into their designs, so that the wider product engineering community can delegate security concerns to the libraries and templates they’re using.

7. Provide isolation patterns. Provide software engineering teams with mechanisms to isolate COTS software. The goal is to, at a minimum, make it compliant and reduce incident impact by design. That way, our engineering teams don’t have to beg vendors to implement our organization’s special snowflake security requirements (what the rest of the world would consider “bizarre”) or fork open-source software (OSS) to implement those requirements ourselves.

8. Conduct user research.⁶ Make the more secure / safer way the more delightful way, too: faster, easier, simpler. By conducting user research – taking the time to understand our users’ goals, constraints, workflows, and emotional journeys in a given activity – we can tailor the solutions we build and implement to help them achieve what they want in a safe way.

As one relatively common example, rolling out SSO can result in a delightful experience for engineering teams because all their apps are now in one place; the user just needs to SSO into their apps for access rather than maintaining N separate accounts (reducing the number of steps)⁷. It means we’ve improved security while boosting speed and ease of use. Our business will be dead chuffed.

Towards better cybering

I mentioned that I’ve heard people sincerely describe the CISO role as one of the hardest jobs in corporate America. They should be delighted to hear that the CISOs I know who follow at least some of the above seem to enjoy their jobs much more than those who are still attempting to use carriage whips to steer their devs.

In the model described above – and indeed in the Platform Resilience Engineering discipline I describe in my book – we get to build things and solve real problems for real humans in an empathetic way. We can behold tangible improvements, not vague successes like “improved risk coverage by X%.”⁸

We don’t have to feel so alone in the cybersecurity struggle. This approach gives us opportunities to learn from our platform engineering and SRE colleagues – to develop a collaborative vibe rather than a combative one. These teams want to help us solve security problems; they don’t want to create or implement roadblocks, but we shouldn’t either. We should want sustained resilience – because that means we can sustain our organization’s success.

tl;dr Paved roads, not roadblocks.

Enjoy this post? You might like my book, Security Chaos Engineering: Sustaining Resilience in Software and Systems, available at Amazon, Bookshop, and other major retailers online.

Thanks to Lita Cho and Gregory Poirier for feedback.

It is admittedly exhaustive since we wanted to offer our expertise across as many problems and areas of focus as were relevant. Our response begins by describing multiple “Gordian Knots” we believe will offer the requesting agencies alternative perspectives on the problem at hand. The rest of the response is structured with recommendations in the areas and subareas where our expertise is relevant, in the same order as presented in the RFI. Additionally, we identify and recommend multiple new subareas of focus for prioritization, including isolation, modular design, automation (CI/CD), resilience stress testing, and others; many of these are suffused with the spirit of Gordian Knots.

We are publishing our response in the spirit of transparency; you can read it at the following link: https://kellyshortridge.com/papers/ONCD-2023-0002-Shortridge-Sensemaking.pdf

Note that we are submitting as Shortridge Sensemaking LLC. The views expressed in our response are not necessarily the views of our employers or any of their affiliates. The information contained herein is not intended to provide, and should not be relied upon for, investment advice (which we would hope is obvious).

Enjoy this post? You might like my book, Security Chaos Engineering: Sustaining Resilience in Software and Systems, available at Amazon, Bookshop, and other major retailers online.

Introduction

We say the word “security” a lot in tech. Whether we refer to “cybersecurity” or “information security” (or “infosec”), how often do we pause to question what we mean when we say the word security itself?

In general, arguing that words should mean things in infosec is like fighting against the gravity of a supermassive black hole¹. Unfortunately for me, I will die on this hill until my inevitable spaghettification. From what I understand from cybersecurity journalism, this persistence makes me a “sophisticated” attacker, perhaps even one of those fabled advanced persistent threats (APTs). My cyberweapon of choice is words. My action on target? Destabilizing the industry’s dereliction of meaning. My APT group name will be SOCRATIC KITTEN.

So, true to the spirit of being advanced and persistent and threatening, I write this to challenge and, with any luck², overthrow incumbent notions of the security concept while nurturing new notions that inspire and uplift³.

The security concept, like other words-as-concepts (happiness, courage, justice) is an idea, per Plato, perceivable only by the eyes of the mind⁴. To borrow from Hannah Arendt⁵, the word “security” is “something like a frozen thought that thinking must unfreeze whenever it wants to find out the original meaning.” To thaw it, we must meditate upon it, seep ourselves in it, let the currents of concept cleanse our preconceptions.

“But Kelly,” you sigh, “shouldn’t you be posting about something practical?” Like, what, the growing ATTACK SURFACE due to HUMAN ERROR that will surely be solved with SECURITY AWARENESS? Much like the spherical cow, such metaphors⁶ simplify our understanding of the world so it feels comforting and calculable as escapism from the real world, which is very messy. The security people, in no shortage of irony, choose convenience in this trade-off. Humans will interact with systems and do very natural human things and the security people will clutch their pearls and gasp, “But why would they do such a thing?!” Maybe spherical SBOMs will solve security so we can all finally stop being aware of it.

Because requiring awareness is part of the problem. We have a word for when humans are excellent at being of aware of threats in their environment: hypervigilance. It is not good when humans are hypervigilant! It means the human is likely traumatized and their nervous system is dysregulated. Unfortunately, the security people want us all to be hypervigilant because nothing says accountability for a problem like telling the potential victims they’re responsible for it.

Imagine, if you will, a parallel SKYSECURITY AWARENESS MONTH where we tell people to be careful whenever walking outside because a piano might fall on their head or that they should be scrutinizing the clouds – their trajectory, color, fullness, and other patterns – to figure out whether they are safe or not. In real life, we have meteorologists and can open an app that tells us whether we probably need an umbrella or sunglasses or to just stay inside to stay safe. Sometimes people will still go outside because that hurricane isn’t going to Instagram itself but there have been and will always be fools and our strategy in a problem domain should not be focused on the minority of fools who will not be persuaded by facts or logic and will gladly jump over guardrails while wondering why they were there in the first place.

My point is that the security people have collapsed upon a meaning of “security” as a concept that is not serving them or users or organizations or society particularly well. The cybersecurity industry’s meaning of “security” is a distortion, in many cases the exact opposite, of what the word means and has meant throughout its long, storied history. That history has much to teach us, which is why it is, in fact, entirely practical and pertinent to explore it on our upcoming semantic safari.

Thus, this essay will illuminate why our current notion of (cyber)security, the concept, is worth re-evaluating through the lens of what “security” has meant over time. True to Socratic tradition⁷, these essays will not provide a definitive answer. Our path will be circuitous, but we will perhaps absorb a superior sense of what this ineffable concept of “security” is through ouroboric osmosis by the end of our journey⁸.

We may not produce a definition of “security” by the end (although we will try) but, having pondered the meaning of “security,” we might be able to make our own attempts at it better.

To begin our journey, we must time travel.

The Curious Nature of Securus

It’s a few hundred years before the common era in Rome. You’re chilling in a thermae with your bae admiring the intricate stone mosaic of a rather fetching deity beneath your feet as you feel your pores cleansing in the luscious steam.

Your beloved anaticula⁹ looks at you and smiles, “If only all our days together could be securus like this,” they say. You smile back and nod in blissful agreement, watching them rest their eyes with a satisfied sigh.

For the securus life is one without care. Securus starts with sē, the Latin prefix for “without,” which combines with cūra, the noun for care, concern, thought, trouble, solicitude, anxiety, grief, and sorrow.

Hence, securus is to enjoy piece of mind (securo animo esse¹⁰). Securus is the absence of concern, the absence of a troubled mind. The opposite of securus was sollicitus — the restlessness arising from being filled with fear, apprehension, anxiety, alarm.

Hurtling forward in time to 2023 CE, we can observe that the typical traditionalist infosec program is closer to sollicitus than securus. Fear, uncertainty, and doubt (FUD) pervade – and perhaps define – the industry. FUD are the foundational emotions industry vendors, journalists, and less scrupulous thought leaders exploit for fortune and fame.

Our world is increasingly software and internet but there is a powerful industry that tells us that we should be scared to use software and internet, that it is desirable for us to be uncertain at all times when using software and internet, that we should doubt our perceptions at all times because what if the 13,371,337th link you click or line of code you write in your lifetime causes CYBERGEDDON. All of this anti-securus rhetoric is supposedly in our best interests.

FUD pervades cybersecurity to such an extent that we take for granted that these emotions need not define the security we seek to cultivate. Could FUD not instead be seen as the explicit enemy of security?

Thus, a worthy thought experiment is: how might cybersecurity programs look if they actually pursued the state of being securus? How would an information security program designed to ensure the organization is “without care or concern or anxiety” appear? How would cybersecurity strategy differ if the goal outcome was for users – whether end consumers, software engineers, or employees – to feel care-free and untroubled?

We will explore those questions as we continue our journey. Our next stop is even further back in history, inspecting the inspiration for the word securus in Ancient Greece.

A Platonic Dialogue

Persons of the Dialogue¹¹

SECRATES

THEOXORUS

Theoxorus: I am feeling secure in my knowledge today, Secrates, yet have no doubt you shall shortly annoy me with indistinct inquiries into something simple that we should enjoy simply for simplicity’s sake.

Secrates: Secure! O, my dear Theoxorus, do my ears truly witness you bringing a conversation to me on a shining platter?

Theoxorus: What do you mean, Secrates?

Secrates: I mean that you used the word “secure.” And what does “secure” mean? We should always be on the lookout for such answerless words. I know you do not wish to examine it, but now we must!

Theoxorus: Secrates, no –

Secrates: Do you truly object? Is it not your own lips which revealed the relevance of this word to your very life?

Theoxorus: I… I cannot object.

Secrates: And neither can I. We must proceed and, another time, we can discuss what your hesitance for exploration means. I observe that you grow weary of dissecting words and essences of late. And yet with what else do you fill your days? Is it not your own shame you are unwilling to confront? Is it not this regular discourse that exposes the inner self you wish to –

Theoxorus: Secrates! Let us examine “secure” now and my own soul later.

Secrates: As you wish, my dear Theoxorus, I will now proceed with this inquiry, for which I owe you many thanks. There are two words from our current civilization that serve as the inspiration for securus: ataraksia and asphaleia. Let us proceed first with ataraksia.

Theoxorus: What tongue is the word “securus”?

Secrates: Latin.

Theoxorus: “Latin”?

Secrates: Yes. I have seen into the future during a bathing ritual.

Theoxorus: Ah, Secrates, you indulge in the pleasures of the oracles!

Secrates: Believe what you wish. But let us now proceed, as you insisted. What defines ataraksia but what it is not? It is the negation of taraksia, from tarrassein, which means to trouble the mind, to agitate, to disturb, to stir.

Theoxorus: Just as your incessant inquiries do to me.

Secrates: Precisely. And if ataraksia is the negation of these verbs, may it not be said to reflect calmness, equanimity, tranquility? It is as Pyrrho said, a form of freedom from distress and concern, and as the public says in their less formal dialogue, it is the mental state soldiers must cultivate before battle. Is it a goal, a kind of goodness, that a person must pursue in their lives? The Pyrrhonists, Epicureans, and Stoics would agree with this, each for different reasons reflecting their different philosophical foundations.

Theoxorus: What do you think, Secrates?

Secrates: I know nothing, as you know well, Theoxorus. What matters for our conversation is the essence of ataraksia: a freedom from disturbances, especially of the mental variety. And, then, as I have seen in my bathtub in a very distant future, what matters is that the verbs ataraksia is meant to negate – to disturb, to agitate, to trouble, to stir – are the verbs most associated with traditional cybersecurity. Does this not suggest security then means its very opposite?

Theoxorus: To be sure.

Secrates: And does this not trouble the mind in itself?

Theoxorus: Certainly. But how can you know such contraction abounds?

Secrates: This future world seems designed by contradiction. Their “security awareness training” exercises, such as those meant to phish humans as one lures a fish with a decoy worm, have the explicit goal of “troubling the mind” to keep persons vigilant for danger. In this future, application security tools are infamous for how they disturb software development and delivery practices – and does that not trouble the minds of software engineers? The list of security rules and policies are unending, often arbitrary – and have they not found a most effective means to agitate the subjects under their dominion?

Theoxorus: They have.

Secrates: And do we believe that such activities result in greater defenses?

Theoxorus: Certainly not, unless one believes that defense is impossible through design. This reminds me of our prior dialogue on beauty, Secrates, as what you describe of this “infosec industry” must make it beauty’s enemy.

Secrates: Are you surprised, Theoxorus, that infosec makes enemies when its goal is to disrupt tranquility? And how could cybersecurity achieve beauty when it sees ugliness and danger in all things outside itself?

Theoxorus: Of course. But surely some interpretation by other schools of thought justifies this perversion?

Secretes: They will not. Atarksia is seen as a strict requirement to attain the true, full happiness referred to as eudaimonia. It may surprise you, my dear Theoxorus, that the word atarksia is associated with Epicurean philosophy.

Theoxorus: But calmness seems harmonious with Epicureanism.

Secrates: Did you wish to ask me a question, my friend?

Theoxorus: Your social skills are as crude as unfired amphorae, Secrates. So, then, what is shocking about this?

Secrates: It is shocking because it is hard to imagine a philosophy more opposed to cybersecurity than Epicurianism, which argues that the goal of a sentient life form is to maximize pleasure and minimize pain¹². Epicurus is specific in defining pleasure as the absence of pain, and therefore “ethical hedonism” is the pursuit of avoiding pain, including pain that imparts pleasure near-term but pain longer-term. Without distracting ourselves by examining Epicureanism in more detail, we can say that the goal they espouse is to foster a life of tranquility. Does this cybersecurity community foster a life of such tranquility?

Theoxorus: They do not.

Secrates: I agree, my friend. Cybersecurity is not known for avoiding pain, regardless of temporal outlook. The cybersecurity community inflicts pain on others, whether by stoking fear or by making lives harder. Is it not fair to argue that infosec even inflicts pain on itself?¹³ Is it not cruel to cultivate obsession of vulnerabilities that kindle fear, uncertainty, and doubt when your stated aim is to eliminate them? Do we believe this fetishization of vulnerabilities and lascivious focus on blaming what they call “human error” can be called “ethical hedonism”? Or is it a societal mechanism to stifle introspection and to instead reenact shame? I regret that these questions reflect a topic for another time in the realm of psychology¹⁴, which has yet to be invented.

Theoxorus: You tease me, Secrates.

Secrates: Yes, but there is another thing, Theoxorus: what of asphaleia?

Theoxorus: You are unfailing in your pursuit, Secrates.

Secrates: Well, I suspect you might find its origin amusing. Asphaleia originates from wrestling and reflects the capacity to prevent being overthrown, being immovable and steadfast, like the throne of the gods, or like me in the presence of your lamentations and tantrums about our discourse. By roughly a century before our time¹⁵, asphaleia also came to mean the stability of the city state, to prevent being overthrown, and, if I permit myself to indulge in speculation, it could be extended to describe the stability of an organization (a kind of social entity I beheld in my bath). And, as some great scientists will prove thousands of years from our day, speed and stability of work harmonize and impart greater value together than apart. And, well, now I can put the matter as: is this infosec, that which slows down work, an enemy of asphaleia?

Theoxorus: Yes, certainly.

Secrates: Very good; and can you tell me how this might be despite asphaleia serving as the seed of the “security” concept’s own existence?

Theoxorus: I must confess, Secrates, that this “security” society of the future seems very lost.

Secrates: I dare say, my friend, that you spend too much time with me if you think it is an uncommon human desire to seek power and control, even at the expense of integrity. And can we truly argue that such desires are always conscious to the subject?

Theoxorus: Alas, they are not.

Secrates: If what you say is true, I ask you, then: what is this cybersecurity society not most of all?

When Secrates had asked his question, for a considerable time there was silence; Theoxorus furrowed his brow while meditating on this question; only Secrates made a sound when softly blowing on the delicate seedheads of a dandelion.

Theoxorus: For what did you wish as you blew, Secrates?

Secrates looked up at Theoxorus and said, with a smile: For you to answer my question.

Theoxorus: I will tell you. My feeling is that this cybersecurity society lacks curiosity.

Secrates: Exactly. The traditional cybersecurity society is kin of Argus Panoptes; the role of enforcer grants them relevancy but not wisdom. Alas, my friend, if only they would follow the path of Daedalus instead. They feel ignorance as a sting and slight, as if ignorance was not the default condition of being alive! But there is more: how are they like the sophist?

Theoxorus: They both are paid to question without truth as their aim.

Secrates: And do they not both gain fortunes from this?

Theoxorus: They do.

Secrates: And are they not both hunters after a living prey, servants of the powerful, cousins of opportunists exploiting emotion for control?

Theoxorus: They are.

Secrates: But where the cybersecurity society differs is they seek the impossible void – the not-being of weakness – and they are willing to destroy whatever being stands in the way of this pyrrhic quest.

The Dawn of “Security” as a Noun: Securitas

The ancient association of securus with Epicureanism was not to last. Epicurianism was outlawed once the Roman Empire entered its rebellious Christianity phase because, as a philosophy, it’s quite incompatible with the idea that souls must be “saved” and that God is relevant to everyday life (Epicurus literally argued that the gods do not gaf about human affairs and do not punish or reward human behavior).

Why is this relevant to cybersecurity? Because – as a collection of entities across vendors, consultants, thought leaders, and practitioners incentivized to increase influence on the world – information security has sanctified itself as a secular authority who can deem worthiness from on high and reward or punish according to behavior¹⁶.

Most security advice roughly goes, “if you’re interacting with a computer and what you’re doing feels convenient, you are actually doing something BAD.” We’re supposed to report when we’ve done something wrong, like a Catholic at confessional. We can gain an “exception” from the security authority like the medieval Catholic Church granting indulgences¹⁷ to partially reduce the punishment of the sin.

Naturally, only the ordained can read and interpret the sacred texts. The unwashed masses may only receive the good word. The divine wisdom is so complex, so arcane, far too difficult for anyone else to transform into action. Does this not imply that the non-security “normies” cannot be secure without the blessing of the security establishment? The human “users” must suffer in this life for their sins, for turning away from the path of security¹⁸.

In the eyes of the Cybersec Church, users are weak sheep who must be told what to do and guided with a strong hand in the ways of natural security law, less they drift wayward into wickedness. We must practice chastity in all manners digital and resist the temptation of clicking on things unless we want the whole network to drown in depravity¹⁹.

For the Security Spirit is always watching. It knows when you allow incoming connections from cloud provider IPs even though attackers also use those IPs. It knows when you copy and paste something from Stack Overflow even though it could be backdoored. It knows when you don’t VPN on the hotel WiFi, where anyone, including a big, sexy scary APT could connect to it. Wicked, wicked user! A thousand years smoldering in hellfire and pestilence for your sins! Try clicking things now once the maggots have feasted upon your flesh!

We will return to security in the context of authority later, but now we must march onward to examine how securus, the adjective, evolved its noun form: securitas. In the Roman period, securitas specifically corresponded to intense emotions. And, it’s worth noting, the freedom from care represented by securitas does not require justification based on reality.

Securitas refers to a group of emotions (the things security and software “rationalists” alike pretend they don’t have) which relate to the absence of fear and include emotions like trust and confidence²⁰. In fact, even the more modern notion of “job security” aligns to this older meaning; it is a feeling, specifically that you don’t have to worry about losing employment. Threats to it aren’t the point, the feeling is the point.

Now, my dear mortals, can we imagine a cybersecurity program designed to ensure the organization is fearless and free from care, an infosec program that is quiet, easy, and composed? Cybersecurity as a discipline would be concerned with ensuring the organization could remain cheerful, tranquil, and serene. Servers would frolick in a field like fecund fawns. Software engineers would release code with confidence, trusting the safety designed into their languages, tools, platforms, and environments. If employees felt fear, uncertainty, or doubt when using technical systems, the security program would be curious and design solutions to alleviate their concerns.

Imagine a cybersecurity program with the goal of relieving the rest of the organization from anxiety about security… cybersecurity that promotes convenience and puts in the hard work of crafting design-based mitigations. Status quo infosec – manifesting as SecObs, Security Theatre, etc. – seeks quite the opposite. Traditional cybersecurity programs openly admit aiming to increase anxiety among the rest of the organization to ensure they are vigilant to threats and always looking over their proverbial shoulders for potential peril. The security people decry convenience and shame users for seeking it while simultaneously indulging in it like Scrooge McDuck in his pool of gold by relying on enforcement, behavioral control, and blame as cheap “mitigations.”

I often read security advice or policies or other prescriptions and have the sense that the authors are trying very hard to pretend that local context is irrelevant and that generalized control is possible. Convenience is often framed as the enemy. The question is: convenience for whom?

Sure, convenience is clicking on every link or adding a third-party library without a second thought. But convenience is also requiring a security tool that you will never have to use, without performing any user research with the humans who will use it in their workflows. Convenience is tapping the 10^10 Security Commandments when someone makes a mistake and blaming them in front of Congress. Are we shocked that a framework of “convenience for me, but not for thee” doesn’t seem to produce the bundle of positive emotions securitas represented?

Are there words less associated with cybersecurity than “cheerful,” “bright,” “serene, “composed,” “quiet,” or “easy”?²¹ The whole business seems antithetical to those traits. Traditional infosec is all cura and no se – better deemed “cybercurity” than cyber_se_curity: a discipline of increasing concern, thought, trouble, anxiety, and grief in the organization regarding “cyber” matters. Offensive security is especially nonsensical through this etymological lens because it then means “offensive tranquility.”

Or maybe it isn’t that strange. After all, don’t overpriced healing crystals and cyber wares have quite a bit in common?

The Multifaceted Meaning of "Security" as ‘Securitas’ in the Roman Era

While a sense of dignity is not the vibe most of us feel when clicking through mandatory cybersecurity awareness training courses, dignity and security were seen as closely coupled concepts in the Roman era.

Cicero, living during the last century B.C., noted that whomever has tranquillitate animi (a tranquil mind) and securitas will have dignitas (dignity)²². Cicero’s meaning of securitas here involves the absence of care or fear as well – and he saw this tranquility of mind as a prerequisite for an individual’s personal happiness and prestige in society. (We will talk about respect and dignity in the context of security more once we time travel to more modern definitions of the word).

A century later, Seneca framed securitas as a mindset²³, a lovely extension of the existing notion of security as a bundle of emotions. Inspired by Socrates, Seneca viewed securitas – and the absence of the fear emotion²⁴ – as how the wise can come closer to god because only a god has no reason to fear death²⁵.

Securitas as this nearly-divine mindset quickly morphed into an association with divinity itself during the reign of Nero (the 1st century AD), specifically reflecting the divinity of the Emperor²⁶ on coinage. It also started to reflect an environmental vibe rather than emotions or mindset; the surrounding world, the genesis of a subject’s freedom from care, could also be securitas, possessing a peaceful and tranquil atmosphere.

But Seneca also laid the groundwork for coupling the security of the state with security of individuals, in the specific sense of public securitas contributing to the capacity to live according to virtue. In this framing, securitas was explicitly based on mutual trust between the ruler and the ruled.

This reflects yet another semantic deviation with cybersecurity, which is generally mistrustful of any parties outside infosec, including those who should be allies (like software engineers). How else should we characterize the common refrain that any employee is a potential “insider threat”? And the cybersecurity status quo certainly does not seem to foster mutual trust by helping potential allies live well, offering minimal proof that they have the best interests of the collective in mind; if anything, they often prove the opposite.

In fact, Seneca highlights that it is a mistake to think that “a ruler is [only] safe when nothing is safe from the ruler.”²⁷ The pox of “shadow” assets – whether shadow IT, shadow SaaS, shadow containers, shadow APIs – shows that the infosec establishment succumbs to this mistake readily. In fact, cybersecurity’s general fetishization of control – vitalized by vendors – is a continuous realization of this mistake.

As anyone familiar with the motifs of history could predict, the subsequent rulers did not listen to Seneca’s admonition, which eventually led to an explicit rejection of hereditary rulership in the Nerva-Antonine dynasty. (Take that for what you will in the context of our current cybersecurity rulership). This led Tacitus to express the new securitas publica (public security) as the confidence of the citizens that the state will no longer threaten them²⁸. That mutual trust was the core ingredient of securitas during that phase and reflected a check on authority.

It is interesting to ponder the notion of securitas publica in the organizational context; an organization’s citizens would be confident that the enforcers of security policy can no longer disrupt their way of life or erode their pursuit of fulfillment. How many cybersecurity programs might be characterized as such today? How many programs instead feel disruptive, corrosive to productivity, and fostering anything but a “peaceful and tranquil atmosphere”?

Securitas’ confident spirit evolved into meaning of “assurance of faith” (as opposed to doubt) during Roman Antiquity, as espoused by Tertullian and, later, Saint Augustine. This “opposition to doubt” again is at odds with one of the letters of the acronym which defines traditional cybersecurity: F.U.D. (fear, uncertainty, and doubt). As we’ve seen time and again throughout this essay (and we’re only into the 2nd - 4th century A.D. here!), the earlier and variegated meanings of securitas fly in the face of traditional infosec. Traditional infosec wants to doubt everything. It takes pride in doubting everything. Assurance of faith is seen as a security sin.²⁹

Speaking of faith, early Roman Antiquity also saw the creation of Securitas as a deity. While the mythos surrounding Securitas, the goddess, is lamentably shallow, it’s worth noting that she was the goddess of security and stability³⁰. Given the evidence from the DORA research and metrics that stability and speed work in tandem and are complimentary, this suggests that if we worship at the altar of security, then we must also worship at the altar of speed.

The Roman god of speed, Mercurius (aka Mercury), was also the god of shopkeepers, merchants, travelers, transporters of goods, thieves, and tricksters. It’s worth noting that the coupling of commerce and prosperity with security is quite common throughout its history (more on this once we get to the 16th century). Traditional cybersecurity, in contrast, often pretends like prosperity is not the primary goal or, worse, views prosperity as a foe to security.

“Why don’t companies prioritize security? Don’t they know THE THINGS can be HACKED??” Well, dear security people, what do you think allows the companies to pay for your six or seven figure salary? It is because they prioritize money that they can afford to spend it on security endeavors that do not remunerate them and often cannot even be tied to tangible success outcomes beyond “we saw these malware samples or known bad IPs this month” spoonfed from vendor dashboards in symbiotic self-perpetuation.

The infosec industry forgets that security, even in its more modern meaning, is not just about protecting threats; it’s about protecting threats against something. In the business context, it’s about protecting threats against prosperity. Through this lens, is it not a victory if a security program waters the seeds of revenue growth? And is the security program not a tragic failure if it chokes and cages this material growth because of a “risk” that exists only as an incorporeal counterfactual?

Between the profligate spending on ineffectual security tools and the obstructionism imposed by security programs, it’s quite possible that the threat to enterprise prosperity by traditionalist cybersecurity rivals that posed by actual attackers.

This distinction is also emphasized in the term “national security,” even as we mean it today: national security is about defending threats to what? Liberty, prosperity, the pursuit of happiness… and we rightly dislike security measures that get in the way of these goals (often labeling them as “Security Theater”³¹).

Thus, we must ask, cybersecurity defends against threats to what? Largely the same things, but in businessy and computery contexts. If liberty or prosperity or the pursuit of happiness is choked out by security measures, then security is the threat in itself and the subjects are left in need of security against security³². Indeed, this is where we find ourselves with cybersecurity today.

But we are not yet done with this era. A few centuries after the deification of securitas, its meaning as “carefree” was twisted by religious leaders into an undesirable form: the state of being careless, reckless, heedless, and negligent³³.

This notion of security is perhaps closest to the status quo in infosec today, which is quite careless with human (user, developer, colleague) time and attention, reckless with organizational budget, and negligent to design-based security solutions that are more reliable than attempting to control human behavior. The cybersecurity industry is heedless with its FUD-fueled zealotry, fretting about irreleventia while pretending nothing can be done about the grey rhinos charging into our systems.

Securitas was also relevant in the context of “Roman security” and specifically meant the Roman Empire’s peaceful and orderly domination of the world. Would we characterize traditional infosec programs as peaceful and orderly today? Even diehard zealots of the cybersecurity status quo readily admit that much of infosec in practice is firefighting and disorder. A worthy question is: who benefits from this paradigm?

Alas, the Roman Empire declined, as did securitas, whose meanings were largely stolen by the word certitudo. Thus, we must go to the provincial stables of the Middle Ages to continue our semantic safari. The two meanings of securitas not consumed by certitudo included pax (peace) and religious indifference.

The latter meaning persisted (albeit without nearly as much popularity as before) through to Martin Luther in the 16th century, who labeled “die Sicheren” as the people he was fighting against – people who did not truly trust the Holy Spirit and substituted true faith for religious rituals and conspicuous, performative acts. In his time, spiritual unity was preserved “through coercion and violence… dissent from orthodoxy was outlawed, heresy was rooted out and punished by fire and sword.” Luther was excommunicated for his “errors” about the Holy Spirit, including the “error” of believing the Christian god wouldn’t want heretics burned alive.

In our era, the traditionalist Security People put quite a bit of trust in their folk wisdom and rituals, despite their unclear success. It is still counterculture to suggest that humans shouldn’t be punished for security “errors.”³⁴ And does it not benefit the vendors and research analysts to continue spoon feeding this advice to security leaders?

Just as Martin Luther felt centuries past about religious belief, is it wrong to want to reconstruct our entire approach to cybersecurity? Just because power structures are in place, incumbents entrenched, money flowing, does not mean something new, bold, and based on real acts of security rather than displays of it – on outcomes vs. outputs – could not supplant the status quo. Fatalism is not true to our nature as humans and certainly not true to the spirit of the “security” concept as we have seen.

But there is more for us to see and for that, we must venture onward into the pre-Enlightenment period and beyond…

The Evolving Meaning of Security as ‘Securitas’ in the Early Modern Era

Centuries passed and the relevance of the word securitas faded. Thomas Hobbes, one of the founders of modern political philosophy in the 17th century, was really the hype man for securitas to keep it from dissolving into disuse³⁵.

Hobbes’ depicts the goal of securitas as the genesis and maintenance of peace, which, as we’ve already discussed, is quite unlike the cybersecurity status quo. Securitas is cultivated through alliances to make it dangerous for the remaining “all” to attack. Samuel, baron von Pufendorf³⁶ emphasized the need for allies with a less cynical angle, arguing that an individual human needs companions to aid them in order to realize securitas (which perhaps foreshadows the concept of “social security”).

Are cybersecurity professionals today known for gathering allies? Quite the opposite. For instance, the relationship between developers and security pros seems to only be getting worse³⁷. Traditional infosec strategy does not enforce security policy through cooperation, but through coercion.

To keep a long journey into Hobbes’ rather paranoid – and exceptionally cynical – perspective short, he ultimately proposes that a sovereign should be the one to guarantee securitas by doling out punishments for violating agreements, which requires subjugation of the ruled by the ruler.

Punishing humans who step out of line and requiring obedience to their rules – for the ruled to subjugate their other wants as secondary to the needs of the sovereign… is this not the playbook of traditional cybersecurity? It is the easiest option to pursue because eliminating or reducing hazards by design requires far more effort than demanding obedience. And if there’s one thing Homo sapiens love above all else, it is cognitive efficiency.

It is quite interesting that securitas was used as imperial propaganda during the Roman era to insist that the state was necessary and by Hobbes to insist that the state must subjugate its citizens. Does this tell us something about status quo cybersecurity? Or should we instead deem it “security imperialism”?

Security, Welfare, Dignity, and the Early Modern Era

Around the same time Hobbes was slandering humanity’s nature and proposing the need for a strong-armed state (the 16th century), securitas also started to absorb a financial meaning: something pledged as a guarantee that an obligation would be fulfilled – that the debtor has no need to worry because something has been pledged against the debt.

In this colloquial meaning (which persisted for centuries), securitas is rooted in a feeling – that the lender doesn’t need to worry. And, similarly, we see a theme throughout the Enlightenment that the state should assure citizens that they do not have to fear violence, not just ensure that they are free from violence in their everyday lives. Basically, that the state has a duty to consider the feelings of citizens, not just protect them.

It is in this era and through the Industrial era that security starts to be seen as a human right, as an essential requirement for humans to enjoy all of the other rights. After all, if you’re the victim of violence (particularly a violent death) – or in a perpetual state of worry about it – it’s pretty hard to pursue liberty or prosperity.

Thus, over time, security evolved to mean a guarantee or assurance that certain things would be accessible to an entity – like “water security” reflecting the assurance that a human individual will have access to clean water on an ongoing basis³⁸.

The temporal implication of this meaning is important: it is not just about having access to a thing (whether a physical good or an intangible value) now, but about the guarantee that you will have access to it in the future, too. Not just that you do not have to fear a violent death now, but that you do not have to fear a violent death in the multitude of possible futures on the horizon, either.

We can trace this notion through to the more recent “social security.” The term was coined on a whim because “pension” carried too much baggage to be palatable to a wide audience. So, they defined social security as a “type of security which would… promote the welfare of society as a whole.”³⁹ (emphasis mine)

Thus, the purpose of security is to promote the welfare of a particular entity. Extending this, the purpose of cyber security is to promote the welfare of cyber things (i.e. all things digital). While that may sound silly, there’s something important here: promoting welfare is not just about stopping threats.

What else is embedded in this purpose of promoting welfare? As we explored, dignity was tightly coupled with security during the Roman period and this association resurged with the concept of “human security," which arose from the rejection of Hobbsian state-centric security.

While the term’s precise meaning is still subject to ample debate⁴⁰, a foundational facet of “human security” is respect: that a critical part of ensuring a human is secure is ensuring their humanity is respected. Because dehumanizing certain populations and stripping them of dignity is one of the ways authoritarianism cultivates power; it is how a society slips into fascism.

What, then, should we make of the fact that the infosec industry sneakily strips users – whether the accountant clicking on a link to wire money, the marketing professional who downloads a PDF, the developer who makes a mistake when writing code – of their dignity?

The disrespectful sneer is palpable in the designation of “human error” as the cause of incidents. Security awareness training requires users to remember dozens of rules that ignore the realities of their work on thing-clicking machines and implies that it will be their fault if something bad happens. There is no respect for their time, attention, intelligence, or autonomy.

To quote the legendary James Mickens, “This is uncivilized and I demand more from life.”

But imagine a world in which cybersecurity programs prioritized respect as a core value of security! Respect for users’ private data; respect for users’ time; respect for users’ cognitive and emotional energy; respect for users’ pursuit of their priorities; respect for the organization’s pursuit of its priorities as a collection of users serving other users.

In fact, the term “users” may even be part of the problem. Users are abstract, faceless, behind a screen; they lack intrinsic worth and must be “good for” something.⁴¹ It makes it easier to disrespect them and resent them for not supporting our own goals. It makes it easier to not see them as people, but as exploitable resources that either we control or attackers do. It’s perhaps harder to blame a sleep-deprived caretaker of a lover or child or parent who, just trying to do their job well enough to keep their health insurance, clicks on something designed to look urgent and important.

Blaming a “user” for being so careless as to click on an obfuscated link and enter in their VPN credentials on the malicious site makes it a more antiseptic affair. It makes us feel like it’s a more just world rather than a chaotic one – like the problem is a user stepping out of line rather than complexities conspiring towards compromise. This dehumanization makes it easier to absolve the ruler and deride the ruled – these “users” – who are simply resources towards our ends, ever holy, ever noble.

What "Security" Means in the Information Society

We end our journey in the modern era, the information society⁴². The best way to summarize the concept of security in modern times is that it’s controversial af and dependent on context⁴³. But, Wolfers’ two-part definition of “security” from 1962 is widely cited⁴⁴:

1. In an objective sense, security measures the absence of threats to acquired values
2. In a subjective sense, security reflects the absence of fear that such values will be attacked

The term “values”, here, of course, is ambiguous and open-ended. But let’s think about what this means for the cybersecurity context.

A realist would say security is achieved when “the dangers posed by manifold threats, challenges, vulnerabilities and risks” in the digital realm are “avoided, prevented, managed, coped with, mitigated and adapted to” by individuals, groups, or organizations⁴⁵.

A social constructivist would say security is achieved “once the perception and fears of security ‘threats’, ‘challenges’, ‘vulnerabilities’ and ‘risks’ are allayed and overcome.” That is, objective security is not enough; the subjective will always wield considerable influence in the cybersecurity context.

In my experience, tech bros really do not like the idea that emotions or subjectivity come into play in tech stuff at all. They tend to describe their emotions as “logic” and subjective experience as “facts.” We don’t have enough time to unpack all of that in this post (and if only more of them would go to therapy). But it’s a very real problem when traditional cybersecurity folk wisdom was often woven by people who think the objective is all that matters.

What’s worse about the cybersecurity status quo is that the subjective is dismissed but the objective isn’t even really measured. Again, objective security measures the absence of threats to acquired values. We do not have objective security in traditional infosec and, by that definition, it’s not even really what’s being pursued. Even when fleshing out the realist interpretation of objective security, traditional cybersecurity mostly focuses on the “avoided” or “prevented” part rather than the managed, coped with, adapted to part⁴⁶.

From the perspective of modern scholars, security is meant to lead to more goal-oriented behavior while insecurity leads to threat-oriented behavior. As anyone who’s walked the RSAC vendor hall knows all too well, basically everything in cybersecurity today is about THREATS. Everything is a potential THREAT: your API, your CI/CD pipelines, your laptop, your phone, your fridge, your colleagues, your loved ones, even your own BRAIN is a THREAT because what if you make a MISTAKE and become the very INSIDER THREAT you swore to destroy!?!?!

Everything about the infosec status quo today reflects threat-oriented behavior, therefore implying insecurity rather than security. Traditional cybersecurity isn’t about preserving and upholding values – like prosperity or productivity or an inclusive work environment. Traditional cybersecurity is about preventing and avoiding threats, aiming for the impossible standard of attacks never successfully happening.

The cybersecurity status quo forgets the whole point of stopping the threats is to preserve certain values.

This fetishization of threats and elimination of them as an aim in itself is how we end up with cybersecurity programs which cause so much grief and anxiety and friction for everyone else in the organization. If the infosec industry actually focused on preservation of values, then UX would probably be one of the most important skills in the discipline (but how would incumbent cybersecurity vendors milk that for cash?).

After all, what’s the point of protecting the cherished organizational value of productivity from potential attacks – which likely only happen sometimes rather than continuously, from an impact perspective – if you’re going to erode that value daily through security policies that seem divorced from real goals, constraints, and workflows?

What’s the point in protecting the organization against a potential financial loss due to attack when you’re not only spending its money on security (which could be spent elsewhere), but also slowing down its ability to grow revenue due to security procedures? For an organization with $100 million in revenue wanting to gain market share, shipping 20% fewer features per year due to friction created by the security program has more material impact short, medium, and long term than a ransomware operator demanding $1 million, $5 million, or even $10 million.

Waldron’s quite recent definition of the word security summarizes this all nicely and is worth repeating here:

“… security now comprises protection against harm to one’s basic mode of life and economic values, as well as reasonable protection against fear and terror, and the presence of a positive assurance that these values will continue to be maintained in the future.”⁴⁷

Cybersecurity as it stands today flunks this definition. It is impossible to provide assurance that basic and economic values will be maintained in the future if you do not know what they are, which the cybersecurity status quo does not know because they do not care because all of that is irrelevant to their noble need to sacrifice everyone’s time, energy, and money at the altar of the FUD gods to gain more budget, more headcount, more influence and they shroud this ritual in a lab coat of “rational” paranoia.

Before architecting a security program or allocating cybersecurity budget, we should understand the organization’s basic mode of life and economic values, including at the level of any teams who will be especially subject to security procedures (like software engineers). From there, we should aim to provide reasonable protection against fear and terror – that is, to provide subjective security, that ancient-school version of securitas which meant freedom from anxiety, fear, or care.

Our job as defenders should be to reduce the complexity of the security problem to such an extent that the rest of the organization is free from care about it (in fact, the systems theorist Niklas Luhmann argued that security efforts explicitly aim to reduce the complexity of the world⁴⁸). And cybersecurity’s job should be to provide positive assurance that the organization’s values (like prosperity, productivity, inclusion, whatever) can be maintained going forward.

But all of the above requires user research and empathy and curiosity about things beyond cybersecurity’s viewing frustum. This modern definition of security means the organization must treat security as an interactive discipline, not a prescriptive one. The existence of a security program cannot be justified with “there is a risk here and it will never go away,”⁴⁹ multiplied across all identified “risks,” which thereby implies a security organization that can only grow in scope and authority.

If those who provide security are the rulers and the users the ruled, what security really requires is the rulers respecting the ruled and the rulers earning the respect of the ruled rather than extracting it. This reflects a radical departure from traditional infosec and thus there is and will be resistance from the entrenched⁵⁰.

Security, in practice, is supposed to reside at the beneficial balance between two evils: absolute fear and absolute security – and absolute security, per Kant, can only be found at the cemetery.⁵¹

Summarizing what we mean when we say “security”

Security is now one of those big words like justice and freedom and liberty which serve more as symbols with fuzzy flavors of feeling – that is, as concepts – rather than as words with straightforward definitions. As we’ve seen, asking the titular question, “When We Say Security, What Do We Mean?” is an exploratory exercise rather than an excavation. There is no ground truth we shall hit with enough sweat and shoveling.

We traversed a tapestry of meanings throughout this essay. We finish it with a rough sense of, like, “Security is about preserving chill vibes in the presence of threats to those vibes.”

But more usefully (yet less concretely), we have a better mouthfeel for what “security” means. The threats aren’t the point; the poignant part is the potential absence of a valuable good or state of being which we very much wish to preserve.

An absence of threats is only worthwhile if it guarantees the presence of serenity and prosperity. In the word “security” is also a promise – that you hold onto something of value and that this value might grow in the future.

Perhaps most of all, this semantic journey of ours today reveals how wayward traditional cybersecurity is from these notions; it resembles a nemesis of the security concept rather than its descendent. I hope you join me on the quest to finally realize the full potential of the security concept, to grow peaches rather than lemons⁵², to build a sweeter future for ourselves and all the other stakeholders in this strange system we call society.

If you liked this post and want to learn more about pursuing a better notion of cybersecurity, check out my new book Security Chaos Engineering: Sustaining Resilience in Software and Systems available at Amazon and other major retailers.

Let me explain.

Rule of Two: Sith Edition

Let’s start with the Star Wars version of Rule of Two because I am a lore nerd (a lored, if you will) and while Star Wars lore isn’t as glorious as Elder Scrolls lore,¹ it’s satisfying enough for me to defend.

The Rule of Two was a decree established by Darth Bane as part of the persistent Sith plot to exact revenge upon the Jedi Order. It states that only two Sith Lords may exist at any given time – maximizing secrecy – consisting of a “master” and “apprentice”; the apprentice was generally expected to murder their master after gaining enough experience².

The most famous example of the Rule of Two is Darth Sidious – aka Senator Palpatine³ – as master and Darth Vader as apprentice. It is taking all my self-control not to unleash more lore, so let’s continue.

Rule of Two: Chromium Edition

Now, Chromium’s Rule of Two does not involve writing two code modules, one which will eventually kill the other after running in production long enough. Chromium’s Rule of Two states that we should never write high privilege components in an unsafe implementation language if they process untrustworthy inputs.

It is an excellent rule, and as their diagram below visualizes, when code has all three problematic characteristics – runs without a sandbox; written in an unsafe language; processes untrustworthy inputs – it can spell doom.

However, I am also a bit of a language nerd and definitely a behavioral nerd and I’m dissatisfied with Chromium’s Rule of Two on these petty grounds. The “Rule of Two” isn’t very memorable when it isn’t about Siths and treachery. We want developers to think of this rule when designing systems, so it needs to be salient.

And I personally find terms like “untrustworthy inputs” too squishy; it can imply that we’ve done some sort of analysis to judge inputs as untrustworthy. The Chromium team is very smart and carefully defined what they mean by it in their post but human recall is flawed, especially when it comes to nuance.

The SUX Rule

Instead, I propose the SUX Rule: Sandbox-free – Unsafe – eXogenous. If our code runs without a Sandbox and is written in an Unsafe language and processes eXogenous code, then that obviously sucks (i.e. SUX). We don’t want our code to suck⁴. Thus, we want to pick no more than two of these sucky things when we write code.

If we don’t process exogenous data like user input⁵, then maybe it’s fine to write it in C or not use a sandbox. But if we do process exogenous data, then we either want a runtime sandbox (“privilege reduction” in Chromium’s lingo) or to write it in a memory safe language (Rust being the most direct replacement for C)⁶.

I like exogenous since it feels less squishy than “untrustworthy inputs.” With “running without a sandbox” and “memory unsafe language,” there is a clear way to know whether you are doing things right (you apply a sandbox or you don’t use C/C++). How do you know whether your inputs are actually trustworthy? If you say, “I trust the input now,” why?

If we flip this to the attacker’s perspective, they start with data they control and then will encounter the gifts of either C/C++ or sandbox-free execution. They would greatly prefer to not have any “real” checks performed on their data leading up to that point. But what are “real” checks? I feel like “exogenous” clarifies this a little, since it makes it less about trust or not and more about how to handle it.

Exogenous turns it into a question of: “Do we have things coming from the network / outside the component?” If yes, either sandbox or memory safety (or, even better, both).

Realistically, the X – exogenous data – is the characteristic you can’t eliminate. A lot of code interacts with the outside world, whether human users or silicon services, and that is part of its intended functionality. That is kind of the whole point of many software components.

For many projects (most?) it will be easier to throw that code in a sandbox or write / refactor it into a memory safe language rather than acquiring cryptographic proof that the data comes from a trusted entity or transforming the data in specific ways (which the Chromium post details). The SUX Rule can prompt us to recall this thinky thinky during the design phase.

Conclusion

The SUX Rule is literally just me rebranding Chromium’s wonderful Rule of Two and changing terminology a bit to clarify the concept, avoid stepping on any Sith toes, and make it more memorable (since I’ve found not many software engineers even know of it, to my dismay).

My hope is that even if you don’t entirely remember what each letter stands for, perhaps you will remember “we don’t want code that SUX” and then you will look it up to refresh your memory. With any luck, a few years from now we’ll find that less of the world’s code SUX.

Enjoy this post? You might like my book, Security Chaos Engineering: Sustaining Resilience in Software and Systems, available at Amazon, Bookshop, and other major retailers online.

I sometimes get asked about what I think about “quantum” for solving cybersecurity problems. The answer is I try to never think about it because even one brain cell processing it is too many given its irrelevance to the problem domain.

What security problem is “quantum” trying to solve? Would quantum solve Solarwinds? Heartbleed? Log4Shell? The 2016 DNC compromise? Any number of the social engineering-based attacks we see month after month? No, no, no, no, and no.

“Quantum” is specifically solving the problem of cryptographic primitives: that some of the fancy math problems we use to keep other humans from guessing how to unscramble our data eventually might be solvable by superscale quantum computers.

The argument you’ll often hear from quantum zealots is: “imagine if the primitives that were beneath your feet just vanished.” I don’t have to imagine, bro, that happens in software security every fucking day.

Beyond zealots, there are those in the tech sphere and on its periphery who worry about how horrible cryptography problems could get – but this is because they are ignorant of how bad implementation problems currently are. They do not realize that “breaking a common cryptographic algorithm” is so far down the list of realistic concerns in cybersecurity that it might as well be next to secret agents kidnapping your sysadmin (or whatever employee has the most access to internal systems).

The reality is that there are lots of cyber-attacks and most are pretty boring. Very, very few attacks seen in the real world are from “breaking” encryption. When it does happen, it’s because someone tried to roll their own crypto¹ and messed up the implementation. But most attacks use tactics like social engineering or exploiting known vulnerabilities in web apps or malware-as-a-service; they are not using fancy math, or really any math, other than thinking about the optimal level of effort to achieve the desired payout.

Quantum computing doesn’t solve spoofed URLs like company-name vs. companyname.com which lure users into entering in their credentials. It doesn’t solve attackers copying language from legitimate emails for use in their phishing emails. It doesn’t solve employees’ credentials being stolen. It definitely doesn’t solve memory safety issues, logic flaws, or components interacting in unintended ways.

The security problem “quantum” is trying to solve seems to be financial security – for the proselytizers’ ongoing research prospects. Looking deeper, I suspect the puffery about quantum security stuff is a variation on the theme of longtermism: let’s ignore the real problems in our face today and work on solving imaginary problems for problems many years from now. It’s a cheap way to feel like your work matters.

It also makes you immune to criticism. You can rightfully ignore the “it’s not even real yet” critique, but you can also ignore everything else because you’ve worldbuilt a future where the problem you’re solving is the biggest problem, so anyone who says otherwise is either myopically focused on the present or has other predictions for the future (and of course they are wrong because they do not use cool words like “post-quantum” to describe their future).

With the issue not existing today, anyone criticizing you doesn’t have evidence to disprove it. Sure, you don’t have the evidence to prove it will actually be a huge, society-shattering problem, either, but you can always leap onto your moral high horse and trot off with your bags of research funding, because one day you’ll be vindicated. And if it wasn’t important, would it be getting funding?? Checkmate, pre-quantum losers.

When I poke around the corners of tech society today, I often find a fatalism fetish – an weirdly eager hunger for the end of the world as we know it to be nigh, whether due to AI or quantum computers breaking cryptography.

The other significant contributing factor, I suspect, is the eroding sense of belonging and meaning in our society² – the desperate human need to feel important and influential in our surrounding environment. If we fear that a Nation State will use multi-billion-dollar quantum capabilities to read our email, we implicitly are deeming ourselves important enough to warrant that level of attack investment – that our email is that special because our lives are that special.

The Nation State could also threaten our lives or our loved ones (“your laptop or your life”); profile our interests to send us targeted social engineering content; glean our favorite websites and inject malicious scripts that download malware onto our machine, watering-hold style; or literally so many things that don’t involve quantum anything. “Quantum” solves none of those things, but it does not matter because, like a cult, unquestioning faith is the price of entry for future glory.

The “quantum” hype, especially among leadership and people with deep coffers, is especially frustrating because there are many security problems worth solving now – not just the ones we hear about all the time (phishing, malware, vulnerability exploitation, etc.), but also ones we don’t discuss enough: stalkerware and spyware; digital identity and access for vulnerable populations, like refugees or the unhoused; privacy increasingly becoming a luxury good.

These are very hard problems to solve that disproportionately affect underprivileged groups, but instead we’re fretting about the future-flung vanity problem that is “quantum.” The fanatics think they are starring as an innovator in an epic sci-fi by being “involved” with “quantum” but instead they are the ham-fisted buffoon that serves to make it painfully obvious to the audience that merit does not matter in this dystopian setting.

In short, thinking that “quantum” will “solve” security is quixotic. If that is you, you are Don Quantum and you are tilting at windmills. I’d say you have big Captain Ahab energy, except your white whale doesn’t even exist. Meanwhile, problems abound, including very hard problems, many of which do need fancy math and sciencing. Like, was formal methods not exotic and impractical enough for you??

For real, if you want a huge, horrifying existential threat to tackle, the undersea cables that underpin the internet are vulnerable to climate change[1]. Migrating your efforts from technobabble to working on climate change (whether inputs or impacts) will mean you’re no longer a waste of carbon, at the very least.

I mentioned I get asked sometimes about “quantum” for cybersecurity and the answer in my head is usually, “Cybersecurity is an entirely unserious industry.” We think we’re being serious if we dress it up in the shallow artifacts of science, whether risk quantification or quantum³. Yet we still suck at empiricism and we’re only really curious if we don’t have to be accountable for results.

The quantum hype is perhaps a culmination of this – the right place at the right time to provide an outlet for our valid anxieties about the future while not having to do anything real to make that future better.

Enjoy this post? You might like my book, Security Chaos Engineering: Sustaining Resilience in Software and Systems, available at Amazon, Bookshop, and other major retailers online.

If you’re attending Black Hat USA, check out my talk Wednesday at 11:20 in Oceanside A. I’ll be doing a book signing at the Fastly booth at 14:30 Wednesday, where you can get a free copy. Otherwise, I’m signing books 16:00 Tuesday in the Black Hat Bookstore and 13:00 Wednesday at the O’Reilly Media booth.

I created this infographic as a handy reference for the software engineering, platform engineering, and cybersecurity communities, drawing on a table in Chapter 7 of my new book. It’s a great way to validate that the decisions we make when leading cybersecurity programs support resilience rather than control.

The control strategy designs security programs, and the elements within them, based on what security-humans think other humans should do. From this control-centric perspective, what humans “should” do is give their full attention to a task every time; give every risk conscious consideration; notice and comply with every warning; adhere to rules, policies, and procedures 100% of the time; and remain willing to expend all resources toward this compliance (time, cognitive energy, money, etc.).

The control strategy amounts to nothing more than wishful thinking.

The resilience strategy is grounded in reality. It promotes and designs security based on how humans actually behave – the reality of our finite cognition, attention, and energy. The resilience strategy appreciates that security isn’t always the top priority; in fact, most organizations, and the individuals working in them, are constantly calibrating how they balance competing priorities. Our security strategy must respect those priorities and find ways to work with them rather than against them.

Why don’t we see the resilience strategy in action more? As I say in the book, the control strategy is extremely convenient from the security team’s perspective. In fact, it might be better described as the “convenience strategy.” The cybersecurity program can pursue “solutions” that are comparatively easy to implement — like warnings, procedures, policies, training, and even some bolt-on security tools — and that also allow the security program to blame users when an incident occurs.

The security team gains convenience at the expense of everyone else’s inconvenience. As a common example, the security team may force developers to wrangle with slow, cumbersome appsec tools, gaining their own convenience at the expense of developers’ inconvenience. They get to avoid the hard work of brainstorming design-based solutions and instead prescribe fanciful ways people should work, then blame them when they fail to live up to those conceits.

The resilience strategy offers a way forward that transforms security into an enabler and a secure-by-design-er rather than a blocker or “pass the buck”-er. Through this transformation, our strategy respects that humans don’t interact with software or systems to be secure, they interact to perform a task to achieve a goal.

If you want to learn more about the resilience strategy and emerging practice of platform resilience engineering, check out my new book Security Chaos Engineering: Sustaining Resilience in Software and Systems available at Amazon and other major retailers.

I enjoy the simple pleasures in life: a fragrant bouquet of peonies; crisp, caramelized plantains; my fluffy cat purring in my lap; and receiving an early copy of this year’s Verizon Data Breach Investigations Report (DBIR) to pour over and let my hot takes simmer in the early summer sunlight.

While this year’s report lacks any graphs that remind me of “butterfly vomit” or “a parrot on miscellaneous bath salts”, I still found myself enjoying it. The “spaghetti charts” are not your simple curved line graph but instead are VIBING, which both my aesthetic and economic soul appreciates (the latter due to the vibe-vibes reflecting confidence intervals). The footnotes are also a treat and keep what otherwise might be an oppressively dry report feeling like a breeze to read. Verizon DBIR? More like Verizon DBIRRRRRRRRRRRR.

But the point of the report is the data within and while not much changes year over year, a few things stood out to me. This post shares my notable thoughts, questions, and (spicy) commentaries on the 2023 DBIR.

Cash Rules Everything Around Us

Yet again, the data shows 94.6% of breaches are financially driven. Our oft-aggrandized advanced persistent threats (APTs) – the nation states who largely compromise for espionage purposes – are simply not the bulk of activity. Indeed, organized crime is 75% of all “threat actors” in breaches, followed by “Other” and “End-user” (the latter also including mistakes, not just purposefully malicious activity – a lumping together I personally dislike) with nation-state dead last.

It’s a reminder that when we invest effort in security, we should focus on the potential paths that require attackers to invest the least; if they’re overwhelmingly motivated by money, then they will be sensitive to return on investment (ROI) ¹. But we should also think about what costs us the most money – not just in terms of direct costs from the compromise (like money wired away or incident response retainer fees) but also the costs of investing in mitigations for it – and opportunity costs, too, like hurting productivity due to security mitigations.

And it’s a reminder that the best way to hurt attackers, whether at local or macro scales, is to poison their ROI. One of my hobbies is brainstorming ways we can aggrieve attackers and force them to waste time and money, but, fun aside, there is wisdom in the idea that applying an economic lens to security benefits us.

Double Double Pretexting and Trouble

I’ll admit I rarely think about pretexting and so when I read it in the report this year, my first thought was that it must be something like the new “first base” for the chronically online – but my confusion grew when the report said it’s commonly used in “bacon egg and cheese” sandwiches, which is what any New Yorker knows “BEC” means.

But no, pretexting is when an attacker crafts a compelling scenario to trick victims into doing something for them – like changing bank account details or sending money via a wire transfer (and BEC stands for “business email compromise,” which is much less delicious). Phishing will have something like an attachment or link the attacker wants you to click, while pretexting is more like the Nigerian Prince scam but without the purposefully incredulous elements.

What I found interesting is that attackers are using email access to insert themselves into existing email threads to ask the victim to perform some sort of task (like updating bank details that mean money will route to the attacker). I spend a lot of time wishing I were excluded from email threads, so in some sense I respect the hustle and grind by attackers here.

Like, let’s take a step back. Attackers are basically simulating the most tedious, soul-sucking aspect of corporate life for profit and I’m pretty sure they’re still making less per capita than the people who do that for their day jobs – possibly expending more effort, too. Is the prevalence of “bullshit jobs” what they’re really exploiting? I just can’t imagine willingly joining the mundane, lifeless coordination dance millions of workers perform daily, because no amount of crimes makes that sexy.

It also doesn’t feel particularly scalable? From what I understand, purchasing email creds from the deep, dark web² is not expensive – but surely accessing the inbox, finding appropriate email threads for inserting your request, typing a context-appropriate email, etc. involves quite a bit of effort?

Yet, it starts to make sense when we look at the payout. The median transaction size for a BEC incident is now $50k (up from ~$30k in 2020), which, as we’ll see in the next section on ransomware, is 5x the median ransomware transaction size. Is the effort and resource expenditure involved in pretexting -> BEC vs. ransomware 5x as much? Maybe? Criminals leverage automation to great effect in ransomware operations, after all.

I don’t like making bets, so I’m eager to see what the data indicates next year; if pretexting/BEC continues to rise, and ransomware stagnates or falls, then it suggests criminals pivoting to the monetization path with higher ROI.

Ransomware at the Plateau of Productivity?

Speaking of ransomware, one shocker in the report is that ransomware didn’t grow year over year – staying at 24% of breaches – despite what crowing headlines would have us believe. Does this suggest attackers have perhaps hit a “plateau of productivity” with it? Or are there simply higher ROI options (like Pretexting) that is dampening its adoption / expansion by criminal organizations?

What may shock many is that 93% of ransomware incidents had no loss (which is a little higher than last year but I know it surprised many people last year, too). We constantly hear that ransomware could be a company-ending compromise; it’s already a myth that tons of businesses (especially small ones) go out of business due to breaches and, based on this data, the financial loss from ransomware is unlikely to lead to bankruptcy for the vast majority of organizations.

The 95% range of ransomware losses is now $1.00 (you can’t even get a slice of pizza in NYC for that anymore) to $2.25 million. At that extreme end of the scale, the smattering of tools to protect against it are well worth the cost (assuming the companies who faced losses that high weren’t already using those security tools, which is not revealed by this data but I would very much like to know). The median loss, however, is $26,000. For a year’s worth of EDR subscription, $26,000 covers something like 350 endpoints (assuming zero additional costs beyond the sticker price)… and that doesn’t even help you with recovery like backups…

What’s especially intriguing is that the median ransomware payout is decreasing while the median loss is increasing. Is it, as the report suggests, because ransomware campaigns are going after smaller companies? In truth, I’ve heard the opposite – that criminals are targeting larger organizations in hope of a bigger median payout. The report also suggests the higher loss amounts might be due to the recovery costs, which feels more plausible. I’m open to clues as well as alternate theories about this one.

Mandatory Log4Shell Mention

Attackers, perhaps unsurprisingly, tried to capitalize on companies not patching Log4j, with 32% of all scanning during the year conducted within 30 days of its release. Yet, overall, Log4Shell didn’t have the breach impact we might expect: it was mentioned in 0.4% of the incidents in their data set (“just under a hundred cases”). I think we can interpret this as a victory for defense, especially thanks to the tireless efforts of SREs and security engineers to patch and otherwise protect against it.

One thing that does fascinate me is that 73% of the Log4j cases in the DBIR’s data set involved Espionage, with 26% involving Organized Crime. To me this suggests one of two things (or both): first, that both nation states and criminal organizations tried to leverage Log4j but the nation states were more successful in achieving compromise; or, that nation states seized the opportunity to blend in with criminal activity so successfully that they actually dominated the activity (which could make sense given they were faster to operationalize exploits for it).

Side rant about SBOMs

There’s SBOM propaganda at the end of the Log4j section which is sad because there are better recommendations they could have made and it feels like pandering to one of their key data providers rather than a thoughtful analysis of what might help readers the most. SBOMs may tell you where the software exists (if you can wrangle the deluge of JSON they entail) but it doesn’t help you take action. You could easily have SBOMs and still not patch critical vulns for 49 days (the median time they cite in the report).

The problem, from what I’ve seen, is very rarely awareness of a vulnerability; the issue is patching being a confusing, manual process or being worried about patches breaking things in prod or, relatedly, not having sufficient testing to feel confident in deploying the patch. Yes, in the Log4J scenario, some security teams scrambled to figure out “where is log4j in our stack???” but I also know of multiple software engineering teams who gave their security teams that info posthaste and yet it still didn’t get patched quickly (sadly, often due to sociopolitical reasons). I agree SBOMs may offer an asset management value prop, but we must always be careful to ask “okay, now what?” when we think about what value data might grant us.

SBOMs do not answer “okay, now what?” Repeatable change processes, including testing, answers that. Speedy, automated CI/CD answers that. I’ve discussed this at length elsewhere and I’m tired of standing on my soapbox, so let’s move on.

Don’t Roll Your Own Mail Server

Another thing I found surprising is that 41% of breaches involve mail servers (not just the sending or receiving of email). Why are you still running your own mail server? It’s not only a pain in the ass but a recipe for deliverability problems, too, aside from the security issues that arise. We often hear security is the enemy of convenience but rolling your own mail server is both inconvenient and insecure. I do not get it.

Desktop Sharing isn’t Caring

How many organizations still use desktop sharing software? The answer seems to be a lot given its prominence in these breach statistics… but does any employee even like desktop sharing software?

I have to call out Microsoft here. Android, ChromeOS, iOS, and macOS all require user permission for desktop screen capture or control – and display a warning dialog – but every running Windows application can snoop on the screen content, log keyboard presses, and inject user input without any sort of opt-in.

Alas, those same features allow organizational leadership to surveil their employees’ activity, and Microsoft can make money by supplying those capabilities. Even if requiring consent via warning dialogue would make a dent in this widespread attack problem, I’m doubtful they’ll remove the snoopability because then they’d sacrifice potential revenue. Perverse incentives like this make me want to flee to a cottage in a woodland grove with my cats and forsake snarky infosec commentary for a simple life of writing philosophical novels.

Delays on the Supply Chain Train

We’re inundated with FUD about the software supply chain and all the horrors skulking within it but the data in this year’s DBIR suggests we might be investing too much of our feels in this problem. Based on this data, the most common “threat” from using third-party software is that their dev or admin credentials are compromised and the attacker then assk you to send money to the wrong place – and that would only apply to commercial vendors, not open source ones (although I’m sure open source contributors would love you to randomly send them money, they usually don’t ask for it).

Sure, there’s the “exploit vuln” category but that can include vulnerabilities in first-party and third-party code, so it’s difficult to tease apart the impact of “supply chain” specifically. And, regardless, “exploit vuln” comes well after use of stolen creds, “other”, ransomware, phishing, and pretexting. It’s about on par with “misdelivery” and, in fact, dropped from 7% last year to 5% this year.

If we think about the upstream attacks that especially spook us, where an attacker gains access to the supplier’s source code and pushes a malicious update, the data suggests its prevalence is miniscule – so much so that the DBIR excluded “Partner and Software update” as an action vector this year and even lumps “Backdoor / C2” together.

My hot take is a lot of this comes down to how the human brain works and ego. Humans prefer the world being a straightforward, orderly place. Throw rock up, rock come down. We invented religions, in part, to cope with the complexities of the world, like: “I planted the seeds in the ground but we haven’t gotten rain, therefore the gods are angry and we should offer sacrifices to them” or the more basic “[insert deity here] has a plan.”

We really do not like acknowledging that stochasticity slithers throughout all things, and we recognize, quite correctly, that the more things there are interacting in a system, the more likely the outcomes will baffle us. “Attacker sends email with link, human clicks on link, malware downloaded” is actually a pretty linear story involving few components.

But when we look at the sprawling graph that is our software ecosystem, we have no chance of comprehending it in full – and that complexity terrifies us. We don’t feel in control. Even if most of the time things go right (which is the case with software) and that complexity helps us achieve otherwise impossible outcomes, our lizard brains are still like “MANY BIG SCARE!” because we can’t comprehend it naturally in our brains. The emergent interactions shock us, unlike when a user clicks on a link or even wires money to the wrong bank account.

That’s the “how human brains work” part of my explanation for the furor over supply chain security of late. But there’s often a tinge of moral outrage in the supply chain discourse – that vendors “know better” and are “negligent” and other denigrations. This is where ego comes in. My hot take is that certain entities felt extremely embarrassed about the SolarWinds incident and, because they can’t invent a time machine and go back to the 80s and insist that software should continue to be built primarily in-house³, they decided to shame the private sector instead.

Let’s be real, software quality usually dies in any incumbent vendor required by compliance and regulations. I find it hilarious that in the same breath as “how dare you” they also recommend vendors that offer “zero trust” things (usually in name only), as if those also won’t make for delicious targets for nation state adversaries. By far the best targets for attackers from a software supply chain perspective are the tools required to meet regulatory requirements. There is very little incentive to invest in quality or innovation when you sell into a sticky budget line item.

But you can’t exactly shame the incentive paradigms beget by compliance requirements⁴, so here we are. And from a private sector perspective, it’s really convenient for security leaders to claim that the real problem is this software spaghetti monster of societal proportions. No Board of Directors can expect you to tackle that problem, right? So, yet again in the infosec industry, we have this admittedly elegant symbiosis where we all avoid accountability and shout a lot and pretend like we’re making progress – and, even better, we get to gain a sense of self-righteous superiority in the meantime.

To be clear, the Verizon DBIR says none of this and if they ever did I’d expect it to be their last report given how much of their data comes from various government entities and incumbent security vendors. I say it because I still don’t know how to sell out (please help me).

Conclusion

This year’s Verizon DBIR is worth the read to challenge your assumptions and ponder the data. To any vendors reading, please consider contributing to the data set (and no, Verizon isn’t paying me to say this). Realistically, this is the best aggregate of breach data we have in the private sector and, as the report notes a few times, there is sampling bias due to their sources. The greater diversity of sources, the clearer story we can craft of what is actually happening in attack land vs. the fan fiction we normally read about and pretend helps us.

Enjoy this post? You might like my book, Security Chaos Engineering: Sustaining Resilience in Software and Systems, available at Amazon, Bookshop, and other major retailers online.

Cybersecurity loves its Sun Tzu quotes. What could feel more self-aggrandizing than imagining yourself as the commander of a stalwart army in a battle of erudition and cunning? We fancy ourselves as the “good guys" defending a battlefield of green and gold.

The military fetish soaks into the traditional cybersecurity discourse and doesn’t help our reputation as bellicose obstructionists. In my new book, I shun metaphors of warfare in violence in favor of nature, nurturing, and nourishing to vanquish these aggressive tendencies.

But I also recognize that cybersecurity humans are often stubborn and so if they love Sun Tzu quotes, then I’ll show them how much their beloved would scorn traditional cybersecurity programs.

Whether they intend it or not, many security leaders are the “weak” generals Sun Tzu disdained, the wimpish princes he spoonfed “Baby’s First Warfare Advice.” When we obstruct our organization, we are “the bad guys,” the weak-willed generals who strip their own city of liveliness and liberty as defense against an approaching foe.

In The Art of War, Sun Tzu propounds three ways a ruler can bring misfortune on their army:

1. “…being ignorant of the fact that [the army] cannot obey. This is called hobbling the army.”
   

2. “…being ignorant of the conditions which obtain in an army. This causes restlessness in the soldiers’ minds.”
   

3. “…through ignorance of the military principle of adaptation to circumstances.”
   

All three of these pervade traditional cybersecurity. Let’s examine each in turn.

1. Ignorance of feasibility

Cybersecurity teams create policies and define procedures their colleagues can’t obey, or else it hobbles their productivity. The organization would flounder and lose competitive advantage if people actually followed those rules 100% of the time.

2. Ignorance of conditions

Cybersecurity programs are ignorant of conditions “on the ground.” They aren’t curious about work being done; they care only about work as they imagine it done. They don’t do user research. They blame “human error” without considering context.

3. Ignorance of adaptation

Sticking with status quo ways, proposing container firewalls and slandering “shadow IaC” rather than adapting to evolving conditions. Rather than seizing new opportunities for better defense from modern software tooling, infrastructure, and practices, they cling to what they know – their cognitive comforts – and claim it won’t work for them because of their “unique” business contexts (which mostly amounts to being emotionally resistant to change).

Flinging victory away

These three mistakes, as Sun Tzu says, cause “the army” – or our colleagues, as is the case in cybersecurity – to become “restless and distrustful.” It is “flinging victory away.” Cybersecurity flings victory away everyday. Better systems security is possible but it requires a remodeling of both principles and practices – and a willingness and ability to learn about how software and systems work in our modern era.

Elsewhere, Sun Tzu says that:

If you know the enemy and know yourself, you need not fear the result of a hundred battles.

In cybersecurity, we don’t even know ourselves¹, and we maintain a menagerie of mildewy myths about attackers. We fumble in self-imposed darkness, clumsily grasping at how software and systems work; we can neither understand our own terrain nor the attackers’ calculus. The number of security tools with hooks into everything, running as root on critical systems, betrays this naiveté.

Cybersecurity programs stumble their way through each year, spirits sagging under the burdens of these three blunders. They spiral around the battlefield, plodding to the insidious percussion by vendors, research analysts, and journalists.

And it is insidious. The most remunerative way to sell out in cybersecurity is convincing security leaders that they can overcome each of Sun Tzu’s three ignorances to achieve victory (if you can accomplish this via generative AI then congrats on your seed funding!). It is a soothing message: you don’t have to change your thinking or methods – convenience is what you deserve and we’ll help you make it appear like security is still being done – ascend amongst the cardboard cutout fleshlings with your cardboard cutout security stack – blame the fast, ever-evolving winds of change for your failures.

We architect illusions; like Sun Tzu advised, deception is key to victory, but the victory in this case is avoiding accountability rather than successfully outmaneuvering attackers. If being a CISO is the “hardest job in corporate America” (it is not) when your success metrics are imaginary friends like “% of risk coverage” or “time to detect” (because who cares about actually acting?) then it is worth asking whether we are our own source of hardship.

We deceive ourselves – the most human endeavor of all – to maintain this convenience. Security leaders wail that more modern ways are impossible for “real” businesses, despite similar businesses – including those with legacy systems – transforming. It already feels so difficult; how much more difficult will it be once tangible outcomes are required? Will we still be relevant? Who are we if we are not needed?

This dynamic is creating a significant divide in security efficacy, an iteration (admittedly a rather esoteric one) on the “Two Americas” theme. If you feel that you cannot keep up with the business, technology trends, or software velocity, you are not alone; but you and your compatriots are languishing while others march onward towards victory. And it is this stagnancy that presents an opportunity for SRE and platform engineering teams to swoop in, better versed in software and execution alike.

How do we stop flinging victory away? We dismantle our ignorance to avoid these three mistakes:

1. Understanding of work-as-done

We understand how work is actually performed and how our systems actually behave so we can craft security solutions that eliminate hazards by design or reduce hazardous methods and materials by design.

2. Understanding of local conditions

We research the local context of the users we care about, like those interacting with a system (whether developers, accountants, and so forth). We never implement a solution – especially an administrative control, like a policy or training – without performing user research to understand the experiences of those who will be subjected to our prescribed solution.

3. Understanding of adaptation

We cultivate adaptive capacity, prioritizing investment in our ability to learn and drive change. We expend effort on iterative improvement rather than attempting perfect prevention. We embrace speed and all the practices, patterns, and tools that can help us quickly adapt to evolving conditions.

Transforming towards resilience

All three of these strategies can be summarized as transforming towards resilience. To connect the final stars in our concept constellation, I’ll close with a definition of Security Chaos Engineering to reveal why I’m pretty sure Sun Tzu would think it slaps.

Security Chaos Engineering (SCE) is a socio-technical transformation that enables the ability to gracefully respond to failure and adapt to evolving conditions. It embraces resilience as its philosophical foundation: that our digital world will constantly evolve and we must therefore “change to stay the same.” For that reason, I also describe SCE as “platform resilience engineering.”

What matters in the SCE world of resilience is continuously refined mental models of our systems; a learning culture and feedback loops; and willingness and capacity to change. This is precisely what Sun Tzu espoused: mental and strategic flexibility to seize opportunities while outmaneuvering adversaries to reduce their opportunities.

This isn’t something brand new I divined out of the ether. SCE is seeped in decades of scholarship and practice from other complex systems domains in the realm of resilience engineering and, as Sun Tzu shows, it draws on ancient wisdom (not just in warfare, but in matters of socioecological systems, too).

Such a transformation is entirely within the grasp of any organization; but the wild problem looming ahead is whether you’ll pursue resilience or convenience. Many humans prefer playing pretend, performing ritualistic motions as scaffolding for an otherwise aimless life. Craving convenience is only natural for most humans.

If that is your choice, I wish you well – but please do kindly step aside for the rest of us so we may sate our hunger to achieve real security outcomes and sustain systems resilience. A life of checkbox compliance may suit your tastes, but we demand more from life.

Enjoy this post? You might like my book, Security Chaos Engineering: Sustaining Resilience in Software and Systems, available at Amazon, Bookshop, and other major retailers online.

Last Thursday, a consortium of intelligence agencies spanning Australia, Canada, Germany, Netherlands, New Zealand, United Kingdom, and the United States published a document called Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Security-by-Design and -Default. Its aim is to incite vendors to deliver products that are secure-by-design and -default.

Per their guidance, secure-by-design “means that technology products are built in a way that reasonably protects against malicious cyber actors successfully gaining access to devices, data, and connected infrastructure.” And secure-by-default “means products are resilient against prevalent exploitation techniques out of the box without additional charge.” Both are admirable, worthy pursuits.

But a natural question for readers after digesting this guidance is, “Okay, secure-by-design and secure-by-default sound great… but how do I implement all of this in my organization?”

Well, darling readers, the timing could not be more fortuitous. You see, the obsessive passion project book I wrote throughout last year – Security Chaos Engineering: Sustaining Resilience in Software and Systems – just came out. And I cannot overstate how perfectly the book answers that very valid question of how we can achieve these noble pursuits in practice.

In this post, I’ll map the recommendations in CISA, et al’s report (which I’ll refer to as SBDD for short) to specific chapters and sections in my own book, optimizing for brevity since our time is valuable. If the report is an apéritif, then consider the book a flavorful and fragrant multi-course meal to leave you fulfilled and flourishing.

Software Product Security Principles

There are three principles the SBDD guidance outlines (page 6), two of which are covered in the book at some length¹:

1. The burden of security should not fall solely on the customer
2. Build organizational structure and leadership to achieve these goals

To really immerse yourself in this first principle, skip to Chapter 7 in the book within the section “Designing a Solution.” I suspect you’ll especially enjoy the sidebar on “Solution Design and the Thermodynamics of Effort,” which crystallizes the dynamic that effort can only be shifted around between humans, not destroyed.

The second principle defined by SBDD is also the focus of Chapter 7, which introduces the concept of a Platform Resilience Engineering team dedicated to sustaining resilience in software and systems. Platform resilience engineering teams treat software resilience like a product:

A platform engineering approach to resilience treats security as a product, as something created through a process that provides benefits to a market. Platform engineering teams treat their internal customers’ outages as their own outages, as a call to action to build a better product for them. (~page 272² of Security Chaos Engineering: Sustaining Resilience in Software and Systems)

This topic also relates to one spot where I differ with their report: the emphasis on “IT departments.” Securing corporate laptops radically differs from assessing software quality; they are distinct skill sets. Chapter 7 untangles this distinction and offers a path forward for the latter (assessing software quality, of which security is a part).

Secure-by-Design

Software manufacturers should perform a risk assessment to identify and enumerate prevalent cyber threats to critical systems, and then include protections in product blueprints that account for the evolving cyber threat landscape. (SBDD page 4)

Their Secure-by-Design call-to-action resembles the E&E Assessment Approach I describe in Chapter 2, albeit in different lingo (since “risk” is a slippery concept we largely eschew). The E&E Resilience Assessment reflects two “tiers” of assessment: Evaluation and Experimentation.

Tier 1 (Evaluation) emphasizes the value of creating decision trees for critical functionality, which directly maps to the SBDD guidance of “identify and enumerate prevalent cyber threats to critical systems.” The decision trees you create should capture the paths attackers might take to achieve a particular goal, as well as capture existing and prospective security mechanisms – satisfying this criteria.

In the book, we take it further than what SBDD suggests, however. It isn’t enough to “include protections in product blueprints”; we must verify that those protections work as expected. This is Tier 2 (Experimentation), in which we conduct resilience stress tests – what we refer to as “chaos experiments” in software land – to observe how our system behaves and responds in an adverse scenario.

Another element of SBDD’s guidance is also satisfied by the E&E Resilience Assessment:

The authoring agencies recommend manufacturers use a tailored threat model during the product development stage to address all potential threats to a system and account for each system’s deployment process.” (SBDD page 4)

We need only conduct the Tier 1 assessment to satisfy this; nevertheless, we still recommend both the Evaluation and Experimentation phases to fully assess system resilience.

Memory-safe languages

Manufacturers are encouraged make hard tradeoffs and investments, including those that will be “invisible” to the customers, such as migrating to programming languages that eliminate widespread vulnerabilities. (SBDD page 5)

Prioritize the use of memory safe languages wherever possible. (SBDD page 8)

The value of memory-safe languages in sustaining software resilience receives special focus in a few sections of my book:

1. Chapter 4 in the section called “Standardization of Raw Materials,” which includes a tl;dr of what memory safety is, why it matters, how to select the right language when building software, and how to handle migrations or otherwise cope with lingering C/C++ code.

2. Chapter 7 in the section called “Substitute Less Hazardous Methods or Materials,” since, per NSA guidance elsewhere as well, we should treat C/C++ code as hazardous materials to avoid when possible.

Secure software components.

Acquire and maintain well-secured software components (e.g., software libraries, modules, middleware, frameworks,) from verified commercial, open source, and other third-party developers to ensure robust security in consumer software products. (SBDD page 8)

Chapter 4 in my book covers this “best practice” as well. It’s honestly tricky for me to pinpoint where precisely to point you because it’s such a pervasive topic woven throughout the chapter. But my favorite warning box in the book is relevant:

Angy Scorpion is in the section “‘Boring’ Technology Is Resilient Technology,” but I also recommend the following sub-sections in Chapter 4 (really, just read the whole chapter; it’s the longest one by far in the book, but bursting with practical opportunities):

• Standardization of Raw Materials
• Standardization of Patterns and Tools
• Integration Tests, Load Tests, and Test Theater
• Modularity: Humanity’s Ancient Tool for Resilience

Web template frameworks & parameterized queries

Use web template frameworks that implement automatic escaping of user input to avoid web attacks such as cross-site scripting. (SBDD page 8)

Both Chapter 3 and Chapter 4 cover the principle of “Choose Boring” technology, which covers this. We don’t want to DIY something and potentially miss important security characteristics when there are readily-available frameworks and libraries that are well-vetted.

Use parameterized queries rather than including user input in queries, to avoid SQL injection attacks. (SBDD page 8)

This exact recommendation is covered in Chapter 4, subsection “Documenting Why and When,” although we also recommend ORMs:

The organization should instead standardize on their database access patterns and make choices that make the secure way the default way. (~page 185 of Security Chaos Engineering: Sustaining Resilience in Software and Systems)

It’s flattering to imagine these agencies took a peek at my book draft along the way to inform their guidance given the similarities in language. Please do not start a real conspiracy theory about this.

Code review

Strive to ensure that code submitted into products goes through peer review by other developers to ensure higher quality. (SBDD page 9)

The art of thoughtful code reviews is extensively covered in Chapter 4 in the subsection “Code Reviews and Mental Models.” One thing the report doesn’t mention but the book does is that we really need to implement code reviews for tests, too, and also expend special effort on code reviews for error-handling functionality.

Defense in depth.

Design infrastructure so that the compromise of a single security control does not result in compromise of the entire system. For example, ensuring that user privileges are narrowly provisioned and access control lists are employed can reduce the impact of a compromised account. Also, software sandboxing techniques can quarantine a vulnerability to limit compromise of an entire application. (SBDD page 9)

Isolation is so essential for resilience – and life itself – that it is threaded throughout the whole book. But, for this “best practice,” read Chapter 3, subsections “Investing in Loose Coupling in Software Systems” and “Introducing Linearity into our Systems”; they cover isolation as well as design practices like the D.I.E. triad (short for Distributed, Immutable, and Ephemeral). I cover different forms of isolation worth considering, too – fault isolation, performance isolation, and cost isolation. You’ll even learn some things about biology along the way:

The goal espoused by SBDD here also reflects eliminating or reducing hazards by design, which we explore in depth in Chapter 7. I highly recommend beholding the “Ice Cream Cone Hierarchy of Security Solutions,” which is especially tasty wisdom.

Secure-by-Default

A macro idea in the report’s Secure-by-Default section is treating security like a product, which is the precise focus of Chapter 7 in my book. The SBDD report also touches on the futility of training/policy/guidance relative to building in security qualities by design, which is also covered in Chapter 7. And, surprise surprise, the importance of UX to security solutions is also covered in Chapter 7.

As a little taste of what you’ll read, here’s a cheerful lemur teaching you about user journeys:

Safe to say that if you care about the secure-by-default angle, Chapter 7 is for you.

Consider the user experience consequences of security settings

Each new setting increases the cognitive burden on end users and should be assessed in conjunction with the business benefit it derives. Ideally, a setting should not exist; instead, the most secure setting should be integrated into the product by default. When configuration is necessary, the default option should be broadly secure against common threats. (SBDD page 11)

Cognitive overhead is a common concern covered in the book, but for this guidance I highly recommend this subsection in Chapter 7: “Understanding How Humans Make Trade-Offs Under Pressure.” We cover how human brains really work, especially under pressure; why we should be curious about users’ workarounds rather than incensed; and how to respect the cognitive load of our users.

Chapter 7 also discusses choice architecture and the power of defaults in the subsection “Substitute Less Hazardous Methods or Materials,” drawing from behavioral science.

Forward-looking security over backwards compatibility

Too often, backwards-compatible legacy features are included, and often enabled, in products despite causing risks to product security. Prioritize security over backwards compatibility, empowering security teams to remove insecure features even if it means causing breaking changes. (SBDD page 11)

The report suggests avoiding backwards compatibility for security’s sake, which belies the sheltered purview of the authors, who need not appease the fickle market gods. Few organizations will forego a seven-figure contract with a customer who requires backwards compatibility. The report does mention offering carrots to customers to incentivize updates, although doesn’t elaborate.

Organizations already charge customers more to maintain backwards compatibility, which is an incentive to upgrade. I suspect many would be surprised how much some customers are willing to pay to keep things as static as possible.

But I do think there are other opportunities here in terms of how to achieve this. Towards the end of Chapter 4, I describe the Strangler Fig Pattern for software transformation; it’s a beloved migration pattern in software engineering land but few infosec people know about it in my experience. It’s perfect for especially conservative organizations worried about breaking things when modernizing and migrating. The section in which it lives, “Flexibility and Willingness to Change,” is worth a read regardless to inoculate ourselves against the pestilent industry rhetoric that change is dangerous.

Conclusion

For years, I’ve watched the faces of infosec mortals twist in fear and revulsion at my suggestion that we can and should infuse security by design. “But the Falmer Magic Wheel says blahdiblah!” I don’t care. A regressive approach will never help us outmaneuver attackers. This report, though, grants me a secret weapon: I can appeal to authority now, too, rather than rely on logical arguments – because logic is a poor persuasive tool, as I’ve learned through tribulations and tears and will forever lament. I’m unironically thrilled.

I sincerely think that the guidance within SBDD is a strong start as far as why, but weak (by design, I think) on how. I am obviously quite biased as it aligns quite well with my own thinking – thinking that blossomed into 300 pages in this book (I don’t have the luxury of being a bunch of intelligence agencies in a trench coat where people automatically trust what I say without elaborate justification).

I hope that for those in the community who crave meaningful security outcomes – to achieve victories like secure-by-design and secure-by-default, or even come close to the summit – that the book charts your course to navigate the oft-tumultuous waters of software delivery and sustain resilience in your systems.

Enjoy this post? You might like my book, Security Chaos Engineering: Sustaining Resilience in Software and Systems, available at Amazon, Bookshop, and other major retailers online.

We hear about all the ways to make your deploys so glorious that your pipelines poop rainbows and services saunter off into the sunset together. But what we don’t see as much is folklore of how to make your deploys suffer.¹

Where are the nightmarish tales of our brave little deploy quivering in their worn, unpatched boots – trembling in a realm gory and grim where pipelines rumble towards the thorny, howling woods of production? Such tales are swept aside so we can pretend the world is nice (it is not).

To address this poignant market painpoint, this post is a cursed compendium of 69 ways to fuck up your deploy. Some are ways to fuck up your deploy now and some are ways to fuck it up for Future You. Some of the fuckups may already have happened and are waiting to pounce on you, the unsuspecting prey. Some of them desecrate your performance. Some of them leak data. Some of them thunderstrike and flabbergast, shattering our mental models.

All of them make for a very bad time.

We’ve structured this post into 10 themes of fuckups plus the singularly horrible fuckup of manual deploys. For your convenience, these themes are linked in the Table of Turmoil below so you can browse between soul-butchering meetings or existential crises. We are not liable for any excess anxiety provoked by reading these dastardly deeds… but we like to think this post will help many mortals avoid pain and pandemonium in the future.

The Table of Turmoil:

• Identity Crisis
• Loggers and Monitaurs
• Playing with Deployment Mismatches
• Configuration Tarnation
• Statefulness is Hard
• Net-not-working
• Rolls and Reboots
• Disorganized Organization
• Business Illogic
• The Audacity of Spacetime
• Manual Deploys

Identity Crisis

Permissions are perhaps the final boss of Deployment Dark Souls; they are fiddly, easily forgotten, and never forgiven by the universe.

1. Allow all access.

“Allow all access” is simple and makes deployment easy. You’ll never get a permission failure! It makes for infinite possibilities! Even Sonic would wonder at our speed!

And indeed, dear reader, what wonder allow * inspires… like a wonder for what services the app actually talks to and what we might need to monitor; a wonder for what data the app actually reads and modifies; a wonder for how many other services could go down if the app misbehaved; and a wonder for exactly how many other teams we might inconvenience during an incident.

Whether for quality’s sake or security’s, we should not trade simplicity today for torment tomorrow.

2. Keys in plaintext.

Key management systems (KMS) are complex and can be ornery. Instead of taming these complex beasts – requiring persistence and perhaps the assistance of Athena herself to ride the beast onward to glory – it can be tempting to store keys in plaintext where they are easily understandable by engineers and operators.

If anything goes wrong, they can simply examine the text with their eyeballs. Unfortunately, attackers also have eyeballs and will be grateful that you have saved them a lot of steps in pwning your prod. And if engineers write the keys down somewhere for manual use in an “emergency” or after they’ve left the company… thoughts and prayers.

3. Keys aren’t in plaintext, they’re just accessible to everyone through the management system.

You’ve already realized storing keys in plaintext is unwise (F.U. #2) and upgraded to a key management system to coordinate the dance of the keys. Now you can rotate keys with ease and have knowledge of when they were used! Alas, no one set up any roles or permissions and so every engineer and operator has access to all of the keys.

At least you now have logs of who accessed which keys so you can see who possibly leaked or misused a key when it happens, right? But how useful are those logs when they are simply a list of employees that are trusted to make deploys or respond to incidents?

4. No authorization on production builds.

The logical conclusion of fully automated deployments is being able to push to production via SCM operations (aka “GitOps”). Someone pushes a branch, automation decides it was a release, and now you have a “fun” incident response surprise party to resolve the accidental deploy.

One option is to enforce sufficient restrictions on who can push to which branches and in what circumstances. Or, you can go on a yearlong silent meditation retreat to cultivate the inner peace necessary to be comfortable with surprise deployments.

The common “mitigation” “plan” is to only hire devs who have a full understanding of how git works, train them properly² on your precise GitOops workflow, and trust that they’ll never make a mistake… but we all know that’s just your lizard brain’s reckless optimism telling logic to stop harshing its vibes. Make it go sun on a rock somewhere instead.

5. Keys in the deploy script… which is checked into GitHub.

Sometimes build tooling is janky and deployment tooling even jankier. After all, you don’t ship this code to users, so it’s okay if it’s less tidy (or so we tell ourselves). Because working with key management systems can be frustrating, it’s tempting to include the keys in the script itself.

Now anyone who has your source code can deploy it as your normal workflow would. Good luck maintaining an accurate history of who deployed what and when, especially when the “who” is the intern who git clone’d the codebase and started “experimenting” with it.

6. New build uses assets or libraries on a dev’s personal account.

You’ve decided that developers should be free to choose the best libraries and tools necessary to get the job done, and why shouldn’t they? For many, this will be a homegrown monstrosity that has no tests or documentation and is written in their Own Personal Style™. The dev who chose it is the only one who knows how to use it, but it’s convenient for them.

But is it the most convenient choice for everyone else? What about when the employee leaves and shutters their github account? The supply chain attack³ is coming from inside the house!

7. Temporary access granted for the deployment isn’t revoked.

As MilTOR Freedmem quipped years ago, “Nothing is so permanent as a temporary access token.”

The deployment is complicated and automating all of the steps is a lot of work, so the logical path is to deploy the service manually just this once. The next quarter, there’s an incident and to get the system operational again, it’s quickest to let the team lead log in and manually repair it.

But after the access is added, it’s all too easy to overlook removing the access. Employees would never take shortcuts or abuse their access, right? And their accounts or devices could never be compromised by attackers, right?

8. Former employees can still deploy.

Leadership claims your onboarding and offboarding checklists are exhaustive and followed perfectly every time. And, indeed, your resilience and security goals rely on them being followed perfectly. A safety job well done! No one will be able to deploy your application after they’ve put in notice!

What’s that? That wasn’t part of your checklist, too? Or did you skip over that item because it’s too hard to rotate the keys if some employees quit because they’re too essential and baked into too many systems?

You’ve replaced those keys but they aren’t destroyed and aren’t revoked and don’t expire, so your only hope now is the org didn’t piss off the employees enough for them to YOLO rage around in prod. Sure, former employees have always expressed goodwill towards your company and no one has ever left disgruntled… but would you bet on that staying true?

9. Your app uses credentials associated with the account of the employee you just fired.

Sharing credentials isn’t just something engineers and operators share between themselves. If you’re extra lucky, they’ll bake them into the software or services and then when they leave or transfer to a new department, the system will fail when their permissions are revoked. Maybe sharing isn’t caring.

10. Login tokens are reset and users get frustrated and churn as a result.

Some businesses run on engagement. The more users interact with the platform, the more they induce others to interact, which means more advertising messages you can show them with a more precise understanding of what they might buy. Teams track engagement metrics closely and every little design change is justified or rescinded by how it performs on these metrics. It’s a merry-go-round of incentives and dark patterns.

But one day you migrate to a new login token format or seed, forcing everyone to log in again and the metrics are fucked because many users don’t want to go to the trouble. Those fantastic growth numbers you hoped would bolster your company’s next VC round no longer exist because you broke the cycle of engagement addiction.

Loggers and Monitaurs

Logging and monitoring are essential, which is why getting them wrong wounds us like a Minotaur’s horn through the heart.

11. Logs on full blast.

Systems are hard to analyze without breadcrumbs describing what happened, so logging is an essential quality of an observable system.

Ever-lurking in engineering teams is the natural temptation to log more things. You might need some information in a scenario you haven’t thought of yet, so why not log it? It will be behind the debug level anyway, so it does no harm in production…

…until someone needs to debug a live instance and turns the logging up to 11. Now the system is bogged down by a deluge of logging messages full of references to internal operations, data structures, and other minutia. The poor soul tasked with understanding the system is looking for hay in a needlestack.

Worse, someone could enable debugging in pre-production where traffic isn’t as high⁴ and not notice before deploying to the live environment. Now all your production machines are printing logs with CVS receipt-levels of waste, potentially flooding your logging system. If you’re extra unlucky, some of your shared logging infrastructure is taken offline and multiple teams must declare an incident.

12. Logs on no blast.

Who doesn’t want peace and quiet? But when logs are quiet, the peace is potentially artificial.

Logs could be configured to the wrong endpoint or fail to write for whatever reason; you wouldn’t even be aware of it because the error message is in the logs that you aren’t receiving. Logs could also be turned off; maybe that’s an option for performance testing⁵.

Either way, you better hope that the system is performing properly and that you planned adequate capacity. Because if the system ever runs hot or hits a bottleneck, it has no way of telling you.

13. Logs being sent nowhere.

Your log pipelines were set up years ago by employees long gone. Also long gone is the SIEM to which logs were being sent. Years go by, an incident happens, and during investigation you realize this fatal mistake. Your only recourse is locally-saved logs, which, for capacity reasons, are woefully itsy bitsy and you are the spider stuck in a spout, awash in your own tears.

14. Canary is dead, but you didn’t realize it so you deployed to all the servers anyway and caused downtime.

You’ve been doing this DevOps thing awhile and have a mature process that involves canary deployments to ensure even failed updates won’t incur downtime for users. Deployments are routine and refined to a science. Uptime clearly matters to you. Only this time, the canary fails in a way that your process fails to notice.

An alternative scenario is that some part of the process wasn’t followed and a dead canary is overlooked. You miss the corpse that is your new version and kill the entire flock.

Having a process and system in place to prevent failure and then completely ignoring it and failing anyway likely deserves its own achievement award. Do you need a better process, or do you need to fix the tools? How can you avoid this in the future? This will be furiously debated in the post-mortem, which, if blameful rather than blameless will likely result in this failure repeating within the next year.

15. System fails silently.

A system is crying out for help. Its calls are sent into the cold, uncaring void. Its lamentable fate is only discovered months later when a downstream system goes haywire or a customer complains about suspiciously missing data.

“How could it be failing for so long?” you wonder as you stand it back up before adding a “please monitor this” ticket to the team’s backlog that they’ll definitely, totes for sure get to in the next sprint.

16. New version puts sensitive data in logs.

Yay, the new version of the service writes more log data to make it easier to operate, monitor, and debug the service should something ever go wrong! But, there’s a catch: some of the new log messages include sensitive data such as passwords or credit card details. This may not even be purposeful. Perhaps it logs the contents of the incoming request when a particular logging mode is enabled.

Unfortunately, there are very specific rules that businesses of your type must follow when handling certain types of data and your logging pipeline doesn’t follow any of them. Now your near-term plans are decimated by the effort to clean up or redact logs that you otherwise wouldn’t have to if the engineer that added that logging knew about the data handling requirements. By the way, the IPO is in a few months. XOXO.

Playing with Deployment Mismatches

There were assumptions about what you deployed and those assumptions were wrong.

17. What you deployed wasn’t actually what you tested.

Builds are automated and we tested the output of the previous build, so what’s the harm of rebuilding as part of the deployment process? Not so fast.

Unless your build is reproducible, the results you receive may be somewhat different. Dependencies may have been updated. Docker caching may give you a newer (or older, surprisingly!) base image⁶. Even something as simple as changing the order of linked libraries⁷ could result in software that differs from what was tested.

Configurations fall prey to this, too. “Well, it works with allow-all!” Right, but it doesn’t work in production because the security policy is different in pre-prod. Or, the new version requires additional permissions or resources which were configured manually in the test environment… but, cranial working memory is terribly finite, and thus they were forgotten in prod.

There are numerous solutions to this problem (like reproducible builds or asset archiving), but you may not bother to employ them until a broken production deploy prompts you to. And some of the solutions descend into a stupid sort of fatalism: “If we don’t have fully reproducible builds, we don’t have anything, there’s no point to any of this.” And then Nietzsche rolls in his grave.

18. Not testing important error paths.

We have to move fast. New features. Tickets. Story points. Ship, ship, ship. Developers with the velocity of a projectile. Errors? Bah, log them and move on.

If something is incorrect, surely it will be noticed in test or be reported by users – spoken by someone who has never faced an angry customer because their data was leaked or discovered their lowest rung employee fuming with resentment when they see the company’s fat margins.

Alas, too often we see a new version which forgets to check auth cookies, roles, groups, and so forth because devs test it as admin with the premium enterprise plan, but forget lowly regular users on the the free tier can’t do and see everything.

19. Untested upgrade path.

Your infrastructure is declarative, but the world is not. The app works in isolation, but doesn’t accept the data from the previous version or behaves weirdly when faced with it.

Possibly the schema has changed, but the migration path for existing data (like user records) was never tested. You didn’t test it because you recreated your environment each time. The new version no longer preserves the same invariants as the old version and you watch in horror as other components in the system topple one by one.

Possibly you’re using a NoSQL database or some other data store for which there isn’t a schema and now the work of data migration falls on the application… but no one designed or tested for that.

Or, maybe you’re pushing a large number of updates to a rarely used part of your networking stack. For those that are all-in on infrastructure as code (IaC), supporting old schema, data, and user sessions can be a thorny problem.

20. “It’s a configuration change, so there’s no need to test.”

A shocking number of outages spawn from what is, in theory, a simple little configuration change. “How much could one configuration change break, Michael?”

Many teams overlook just how much damage configuration changes can engender. Configuration is the essential connective tissue between services and just about anything that can be configured can cause breakage when misconfigured.

21. Deployment was untested because the fix is urgent.

The clock is ticking and sweat is sopping your brow. Something must be done to avoid an outage or data loss or some other negative consequence. This fix is at least something and this something seems like it should work⁸. You deploy it now because time is of the essence. It fails and you now have less time or have caused more mess to clean up.

Only in hindsight do you realize a better option was available. Or, maybe the option you chose was the best one, but you made a small mistake. Was the haste worth it?

Urgency changes your decision-making. It’s a well-intentioned evolutionary design of your brain that causes unfortunate side effects when dealing with computer systems. In fact, “urgency” could probably be its own macro class of deploy fails given its prevalence as a factor in them.

22. App wasn’t tested on realistic data.

“Everything works in staging! How could it have failed when we pushed it live? I thought we did everything right by testing the schema migration with our test data and load testing the new version.”

Narrator: The software engineer is in their natural habitat. Observe how they pull at their own hair, a hallmark of their species to signal that something has distressed them. It is very difficult to replicate everything that’s happening in production in an artificial test environment without some sort of replication or replay system. This vexes our otherwise clever engineer.

“It causes a crash!? What kind of deranged mortal would have an apostrophe in their name? Oh, it’s common in some cultures? Hmmm…”

If you keep your service online as you deploy, you should really test your upgrade path under simulated load. If you don’t, you can’t be sure if your planned upgrade process will work or how long it will take.

23. Deploying to the wrong environment accidentally.

When you make deployments easy, it is possible to make deploying to prod too easy. And easy to use doesn’t necessarily mean easy to understand. When a slip of the finger results in code going live, you may want to consider just how far you’ve taken automation and if other parts of your process need to catch up.

Because one day, a sleep-deprived Future You is going to run a deploy script where you have to pass in an environment name and you will type dve instead of dev. Once it dawns on you that the deploy system falls back to “prod” as the default, adrenaline shocks you awake with the force of 9000 espressos and you will never sleep again.

The regrettable reality is that internal tools often offer terrible UX because engineers refuse to give themselves nice things (including therapy). These tools, akin to a rusty sword with no hilt, make these sorts of failures tragically common. The rise of platform engineering is hopefully an antidote to this phenomenon, treating software engineers as user personas worthy of UX investments, too.

24. No real pre-production environment.

You have a staging environment (congrats!), but it’s an ancient clone from production which has seen so many failed builds, bizarre testing runs, and manual configs that it bears only a pale resemblance to the system it’s supposed to epitomize. It gives you confidence that your software could deploy successfully, but not much else.

You wish you could tear it down and rebuild it anew, but everyone’s busy and it’s never quite important enough for someone to start working on it rather than some other task. Thus you’re doomed to clean up small messes that could be caught by a true staging environment.

At the next DevOps conference you attend, every keynote speaker refers to the “fact” that “everyone” has a “high-fidelity” staging environment (“obviously”) as you weep in silence.

25. Production OS has a different version than pre-prod OS and the app fails to start.

Production systems are incredibly important and we must patch frequently to keep them in compliance. But the same diligence isn’t applied to pre-prod, development, build and other environments.

The systems in these environments may therefore be wildly out of date and the software they produce may be incompatible with the up-to-date, patched production system. Systems will drift so far from the standard that QA systems look like an alternate reality from production and make you a believer in the multiverse hypothesis.

26. Backup botch-ups.

A production deploy requires a backup because hot damn have we fucked it up so many times and a backup makes everyone feel more confident. The administrator responsible for performing the backup writes the backup over the live system, causing an outage. Furthermore, because the data was overwritten by the botched backup, any existing backups are not recent.

Backup fuckups happen more than anyone admits and when they go down, they go down hard. Recovering from them is rough because no one thinks it will happen to them.

Lesser failures in this category include saturating the disk or network IO of the host taking the backup or filling the disk – each perfectly capable of causing an outage, too.

27. Audit logs are turned off.

Audit logs are accidentally turned off during a configuration change or as part of a software upgrade and now the system is out of compliance. No one notices until the auditors ask for the audit logs months later and a wave of panic ripples through the teams involved.

Will we fail the audit? Will customers drop us? How much revenue is impacted? Will we still get raises at our quarterly review? Will I have to switch to getting artisanal roasted bean elixirs every other day?

28. Iceberg dependencies.

Only the simplest services run entirely isolated without any other dependencies. When done right, dependencies are properly documented and the infrastructure dependencies of each component are clear. Even better, the dependencies are specified declaratively, rendering it impossible for the human-generated documentation to drift from the machine specification.

But in less auspicious cases, the dependencies are hazy and can even form chains which loop back on themselves like a branching ouroboros eating its own rotting tails. Debugging a production incident for a system with unknown dependencies is software archeology where the only treasure is tears.

The infrastructure upgrade toppled some of the apps and services running on top of it, but the people deploying the upgrade lack context on those casualties and you all wonder when the Jigsaw puppet will come into view and reveal this has all been a grand experiment to pit you against each other.

“We upgraded the OS, clearly everything will be fine!” My brother in christ your system fetches Kerberos creds automatically on boot, but your first boot on a fresh host fails because the Kerberos fetch infra depends on a QA host that was decommed 6 months ago!

And then there’s the ultimate iceberg dependency: DNS. If DNS is borked or misconfigured, all sorts of thorny problems can emerge.

29. Enabling a new feature in vendor software without load testing it.

Vendors make all sorts of claims about the behavior of their wares. It’s fast and stable. It migrates its data format. It slices and dices. It follows semver. Should you believe them? In a word, no.

Configuration Tarnation

Playing god with your environments does not always result in intelligent design.

30. Per-environment configuration isn’t updated ahead of the deploy.

Per-environment configuration is a fact of life. Hostnames, instance counts, and other configuration settings will be necessarily different between environments. Keeping these up to date can be a challenge and it’s all too easy to overlook updating the production template when new configs must be added.

New configuration values are often copied from a staging template into the production one without appropriate adjustments like switching the hostname. You will wonder which evil eldritch god you pissed off when deploying to prod takes down both the production and staging environments. This is so frequent and yet! and yet.

31. Deployed new configuration, but forgot to restart the associated services.

Deploying a configuration change is easy: apply the configuration, restart the service. You might think it should be easy to remember the steps when there’s only two of them, but it’s easy to overlook for quick deployments. Only later do you realize you set a new config variable in prod without applying it to the prod instances.

Design patterns like the D.I.E. triad can help — there’s no way for infrastructure to drift if it’s redeployed from scratch on each deployment. And, of course, automated deployments can help, too.

32. Feature flag fuckups.

Feature flags are a simple and amazing way to explode the number of system states you must test. N flags make for 2^N combinations. Are all of them tested? Are you sure they’re all set correctly? Do the people who test your application have the same flags as the unwashed masses? Are there old feature flags in your app that should be retired? What could happen if they were activated mistakenly? (just ask Knight Capital).

Maybe you push a release before the company holiday party and deploy the entire release successfully… until a few intoxicants in you realize you forgot to flip the feature flag and now you’re crying in the bar’s bathroom shakily singing along to Mariah Carey (though you suspect the “baby” she desperately wants for xmas isn’t a feature flag).

It’s also possible that you do the exact opposite and flip the flag too soon. Maybe a new product is accidentally announced early, deflating all the carefully constructed marketing plans leading up to the company conference and leading customers to ask why the new feature is “broken.” You had just regained the respect of the customer support team too…

Perhaps the new feature simply uses too many resources and you haven’t scaled your infrastructure appropriately. Or maybe the freemium gate is broken and everyone gets access to premium features. Good luck explaining to customers why you now have to take away their new shiny feature unless they pay up for it…

33. Delayed failures.

Faulty configuration may not necessarily cause failures immediately. It’s only after you do some other, seemingly unrelated operation does the fault cause any symptoms. Like medicine, it can be difficult to untangle exactly what faults are the cause of what symptoms.

For systems like load balancers or orchestrators, a bad configuration can remain in place and as long as the system is stable, the misconfiguration will cause no ill effects. But one day when you decommission a cluster as planned, another cluster immediately shits itself – suffering a total outage baffling everyone – and only after many painful hours of debugging do you realize its healthchecking was configured against the one you decommed.

If the team owning that other cluster has poor monitoring hygiene, they may only discover their service is dead much later. But the outage gods care not for your mortal troubles and will do nothing to ease the pain of what is now a multi-day incident all due to faulty health checks.

34. What lies beneath.

The layers far underneath your application can still cause your deployment to fail.

Orchestrator fails? Your service is dead. Operating system fails? Dead. Disk controller fails? Dead. BGP? Dead. DNS? Dead. Backhoe cuts the backbone to your sole datacentre? Dead. NVMe subtly violates DMA protocol? Dead. NIC driver fails or goes rogue? Dead. Baseboard management controller borks? Dead. Deploy a bunch of new machines into a cluster with a bad BIOS? This may shock you, but: dead.

35. Scheduled failures.

Deployments may appear to succeed only to fail hours or days later if you have periodic background jobs or the ability to schedule tasks. The deployment isn’t successful until these jobs and tasks run successfully.

Perhaps you deploy a busted systemd timer which causes all your nodes to self-destruct after 8 hours… and only discover this “fun” fact after you deploy to your first tranche in prod. See also: the dreaded slow memory leak.

Another variant is the odd date/time bug which causes the application to malfunction only on leap years or when daylight savings time occurs. If you’re not swift with your incident response, the incident resolves itself and you’re left scratching your heads until someone realizes it’s because the clocks rolled back.

Do you bother fixing the bug? Or do you hope to find another job before the next orbital period elapses?

36. Accidentally push components beyond their limits.

Components may have poorly documented or undocumented limitations or may simply become unusably slow when assigned more work than they were designed for. Does your database have a limit on the number of connections? Better not scale the number of clients beyond that number, then!

Is it a deployment failure? Yes, if a deployment pushes the system beyond its limits, which is more likely to happen when you add new v2 replicas before retiring old v1 replicas.

In the microservices world, this can manifest as running so many k8s jobs without deleting them that all the k8s operations on jobs begin taking tens of seconds because the cluster is bogged down with so much cluster metadata. Is the inevitable conclusion of microservices simply more microservice instances and metadata than actual work and user data? Makes u think.

37. Builds always use the latest version of a library.

Some well-meaning person may decide that builds for a piece of software always use the latest version of its dependencies. This ensures that whenever you release, you always have the latest security patches.

This sounds wise until one of the dependencies causes a subtle API breakage and your app fails to function. Or, any of your dependencies’ authors could decide “fuck this, I’m not maintaining this open source project anymore and giving corporations free labor” and push a dead version of a package.

Now you’re unable to build new versions of the app until someone resolves the dependency situation. Worse, if that fed-up developer has pulled their old versions out of spite or frustration with the pain of maintaining OSS, and if you haven’t archived builds of old versions, then you may not even be able to deploy at all. And this is how you end up cursing a random dev you hadn’t even heard of until just now when you should be taking your lunch break.

Statefulness is Hard

Mere mortals cannot maintain accurate mental models of data in distributed systems. Even the divines struggle.

38. An irreversible process fails part way through.

Some irreversible process fails part way through your deploy. Possibly it was a migration or some other critical step during your deployment. For whatever reason, this step didn’t happen when deploying to the other environments; it only happened in the one environment that matters most.

What state is the system actually in? Should you rollback? If you try to roll back, will it even work? You’re in uncharted waters under shrouded stars.

Data migrations are often a one-way process. Have you tried migrating all of your existing data to see what happens? How long does it take? Do you have backups? Could you even use the backups, or would restoring result in yet more downtime?

If you don’t know the answers to these questions, you might find yourself deploying an ORM/data model layer which automatically migrates read-only database values to a new format and somehow corrupts the records, resulting in you frantically trying to patch and deploy a fix before too much of your DB becomes unreadable.

Or perhaps you set --timeout 10 on your ORM migration with the innocent assumption that “10” here refers to second. It’s 10 milliseconds. There are no down migrations. And migrations can be arbitrary JS and therefore not guaranteed to be atomic or idempotent and now you’ve started a slow-motion train crash that you cannot stop. One hour of scheduled downtime becomes 18 hours. Your youth and zeal is irreversibly drained.

39. Distributed data vore.

Distributed storage / database systems require careful understanding of their operational characteristics if you are to operate them safely. They can be used to achieve better uptime, reliability, and possibly even lower latency if operated within their safety margins… but they also require more care and feeding than traditional databases with an authoritative primary and can be quite temperamental.

If operated incorrectly, distributed storage can silently lose data or disagree on the data they contain if nodes aren’t retired correctly or if an insufficient number of nodes remain healthy. Do you know enough about your data storage layers to operate them safely? Or when you next roll-reboot your Elasticsearch cluster will it silently eat 30% of your data for seemingly no reason at all? The customers now complaining that all their graphs are 30% too low are certainly not silent.

When you deployed new database nodes to prod, did you assume the cluster would rebalance on them? Oopsies, it didn’t! And thus when you decommissioned the old nodes, you destroyed 99% of your data in the process. There are not enough oofs in this universe to reflect this oofiness.

40. Cache is an unhealthy monarchy.

If caches aren’t healthy, rolling restart instructions aren’t followed or are insufficient and the system fails to start.

Where to begin? Let’s start with why caches exist in the first place: to avoid repeated execution of expensive computations by storing a mapping between inputs and their results in memory (aka “caching them”). Caches will typically discard infrequently-used results automatically to make space for frequently-used results, and can be asked to drop any results that are no longer valid. How can this go wrong? Oh so many ways!

First off, just like database schema, the format of data in the cache might not be compatible with the new version of the app. Similarly, when there is more than one application instance, the old version of the app will run alongside the new version and could see cache entries from its successors. This can cause problems where either the old version or the new version of the app could malfunction from improper data. Deploying a canary can cause all of the instances of the software version to fail.

Have your engineers thought about cross-version compatibility? Do they reject linear notions of spacetime and thus believe compatibility is a blasphemous act against the holographic principle? “Spacetime is just an abstraction,” they tell you cooly while sipping their matcha latte.⁹ You are tempted to remind them that money is also an abstraction and therefore they should abstain from it, too, but it’s faster if you just fix it yourself.

Second, the keys might change. If version A of an app uses one nomenclature for keys but its successor (version B) uses another, version B will operate as if the cache is empty. The app now must perform much more work to populate the cache in the new format. If both versions of the app are running simultaneously, they will fight for space in the cache – and the cache is limited in how much data it can hold by necessity. Now the cache has a lower hit ratio and more requests must go through the more costly “uncached” path.

Third, a common ReCoMmEnDaTiOn is to flush caches when deploying new versions of software (“it’s a caching issue, clear your browser cache” said the frontend dev to the product manager as the PM rolled their eyes). This can be dangerous when using a shared cache since so much extra work must now be performed with every request.

With healthy cache hit ratios commonly being in the 90% range for some workloads, that means the part of the application beyond the cache must handle ten times the throughput until the cache is rebuilt. Could you handle a sudden 10x increase in your workload?

Net-not-working

We make piles of thinking sand talk to each other through light and wonder why weird shit happens.

41. Accidental self-DoS.

The accidental self-DoS could be due to many reasons. Maybe new versions of the application inhibit the CDN’s ability to cache, but this non-functional requirement wasn’t recorded anywhere. Maybe a new analytics feature inundates the application backend with data collected to appease the whims of product management. Maybe a new retry mechanism is being used for failed requests, causing traffic amplification if the backend becomes even a little sluggish.

The end result is the same: the new version of the app swamps the backend service and causes downtime. Engineers tirelessly work to restore service by standing up more instances or filtering the unnecessary traffic the application created for itself.

You ask your devs what happened and they said, “Well, it didn’t work with CDN so we added cache-busting headers to make it work.” You nod quietly while gazing into the abyss.

42. Poorly configured caching.

The previous version of the app configured common static assets with a long cache duration. This caches the asset for long periods of time in CDNs and in users’ browsers. Fabulous! The app loads more quickly for users, especially those that visit frequently.

You build a new version of the app with new cached assets. The new version looks great in staging and dev, where testers are unlikely to have stale cached assets. But when you deploy it to production, you receive reports from your most fervent supporters that the app “looks weird.” It’s a Frankenstein’s monster mismatch of static assets from the old and new versions and behaves unpredictably.

Before enough understanding of what has happened filters through to the development team, all of the stale caches expire and the dev marks the JIRA ticket closed. The issue repeats again when you release the next minor redesign.

Due to the nature of CDNs and prod websites, there’s a category of people for which this is a persistent problem and they should be able to fix it… and yet can’t. The entirely avoidable fuckup is a formidable beast.

43. A hurricane of reconnections foments a flash flood.

You disconnect clients simultaneously during your deployment, leading to them all trying to reconnect simultaneously shortly thereafter. Your system was never designed to handle a flash flood of connections, so it stays down until it’s scaled manually well beyond what it was originally budgeted for.

Someone throws a ticket to add exponential backoff with randomization to the bottom of the client team’s backlog. Years pass and it happens again as their backlog only grows.

44. DoS yourself via CDN purge.

Purging a CDN with a cache hit ratio of 90% results in an immediate 10x throughput increase to the origin. Did you deploy the required additional capacity?

It’s such an easy button to press, too. Some CDNs don’t put a glass case around the button nor require administrator permission to press it. Pressing it immediately grants you the rank of “rogue developer” and now you’ve given your security team a reason to require ten more hours of annual security awareness training. Your access to the secret cools kids Slack channel is purged, too.

45. Accidental network isolation.

Adjust some network config you read about on Stack Overflow and suddenly the site is down and no one has access to the systems that can bring it back up and ahhhhh. You frantically call your AWS or colo account rep to see what they can do as your mobile device buzzes incessantly.

The essence of this fuckup is that the outage locks you out of the systems which need to be accessed to resolve the outage. This can be something as simple as firewall rules or as complex as unicast BGP configurations across complicated multi-vendor networks that locks everyone out of your data centers.

46. The orchestrator goes down with the ship.

A core service on which your orchestrator depends is down. You would normally use the orchestrator to deploy the service, but since the service is down, the orchestrator no longer functions. Now someone must dig out the dusty documentation on the old manual way to do this as the clock is ticking. Does the manual way even still work? Who even has access?

Elsewhere, you put Consul into the deploy path six months into its lifespan and it packet-storms itself into oblivion, taking down not only service discovery but also your ability to deploy anything or even log into nodes.

Rolls and Reboots

“No plan of operations reaches with any certainty beyond the first encounter with production” – Helmchart von Faultke¹⁰

47. No rollback plan.

It’s truly shocking how often orgs don’t have a rollback plan. But just like your mom told you about jumping off bridges, just because everyone is doing it doesn’t mean it isn’t dangerous.

There’s more than one way to handle this properly, like CD with canaries, blue / green deploys, full rollback of everything… but to not have a strategy for this at all and YOLO it? If only we gatekept less against liberal arts majors to fill this chasm of critical thinking.

A special mention goes to the untested rollback plan, too. “We have a complicated deployment that went smoothly in staging, pre-prod, and every other environment, so why would we ever need to rollback?” you say. “It can’t possibly fail in production,” you say.

You’d be correct 9 out of every 10 times… but how many times do you deploy a year again? So, you painstakingly craft a rollback plan for your deployments, but never test it since it’s unlikely to be used. And how little confidence you have in your rollback plans leads to this next fuckup.

48. Forward “fixing.”

Something didn’t go as planned, so you decide to roll forward with some new plan you came up with on the spot instead of rolling back – and then something fails in the roll forward.

This is a fuckup sprouting from the “developers are optimistic by nature” problem. A deployment fails on what you believe is some minor technicality. And then you fail to resist the temptation of making a “quick fix” to patch it while on the call and build a new version of the software so your team can ship…

…But it might not be a quick fix and you’re proposing deploying something completely untested straight to production. Somehow the SRE team is okay with this, or maybe they’re hesitant but let it slide since there are already too many hills on which they must die.

Either way, you’re risking your uptime and stress for deploying a little earlier than you otherwise would. A worthy heuristic for this might be: because developers appear to be optimistic by nature, even the “tiniest” of hotfixes are incomplete and require more testing.

49. Scheduled tasks build up while the system is down for maintenance and DoS the system upon startup.

Your system has a job queue with workers that are carefully tuned not to consume too much money and still complete their work. While the maintenance page is up, the workers are shut off. Deploying the app takes longer than expected and scheduled tasks pile up. The original pool of workers is no longer sufficient to process the backlog of scheduled tasks and people waiting on their results find your team to be insufficient.

50. Circular dependencies in infrastructure.

Circular infra dependencies result in a particularly nefarious failure pattern. If anything in the chain ever goes down completely, it’s impossible to stand the system back up without yolo-rushing a new version of a component to break the chain. For instance, perhaps you store the latest deployed revision on your own host, which means you can’t access it when something goes wrong.

You may design your system nicely, but time inexorably marches forward without regard for your intentions. This failure is an emergent property of all the changes people make over time. It’s an iceberg failure that only emerges when another failure has already emerged and is plaguing you. That is to say, circular infra dependencies result in a particularly nefarious failure pattern…

Disorganized Organization

No amount of fancy automation can truly save you from disorganized organizational processes.

51. No one wants to write docs.

Raise your hand if you’ve ever worked at a company with great internal documentation. Try to recall when you’ve ever read truly complete and up to date deployment documentation. For many of you (most of you, even), nothing comes to mind, right?

The closest might be a well-commented deployment script and some associated high level description. Perhaps it’s a design doc that you trust to be sort of right but cannot assuage your suspicion that the implemented system has drifted away from it. If you trust your documentation to be 100% accurate when deploying software, you’re going to have a bad time because it’s inevitable that there will be errors in it.

And because no one wants to write docs, numerous fuckups occur. You followed outdated or misleading docs on how to make the release, which fucked up the deploy. You forgot to update customer-facing docs and they configured something incorrectly and now all your other customers are suffering from the outage.

You forgot to send release notes which, wait, how is that a fuckup? Oh right, the account manager for your largest customer added in terms about releasing their requested feature by a certain date (without telling anyone in product or engineering of this, naturally) and now you’re re-negotiating their multi-year contract and giving them a serious discount to stay which is going to be difficult for your CEO to explain on the next earnings call.

52. People only get rewarded for diving saves.

People are congratulated for resolving the downtime or for catching a failure as it’s happening, but no one is rewarded for anticipating failures ahead of time.

The CEO wants things to be shipped now so everything is a rush to get half-baked features out the door quickly. But that causes quality problems elsewhere. At least half the deploys have an emergency “oh shit something is borked” follow-up deploy. And either you roll forward or the app limps along and languishes in a janky existence for the next five days until someone builds the fix and ships it.

Whoever ships the fix is lauded for restoring sanity, but it never should have been broken in the first place. And everyone knows if they had chosen to roll back, the CEO would’ve been angry because his little gamification feature wouldn’t have been there for five days. You suffer, your team suffers, your customers suffer, but bossman is happy and the bleary-eyed engineer who spent days on the recovery gets a pat on the back. Well done, naive salaryman.

Then a conference is coming up; your CEO and CMO demand a splashy announcement for it. That means your Q3 deploys are now beginning-of-Q2 deploys… which is in two weeks. You ship a ton of stuff that is half-baked and barely strung together, but the press release goes out (along with the press releases of all your competitors in an unnavigable sea of babblespeak that the market largely ignores).

The team is congratulated while the architect cries in the bathroom grieving their multiple quarters of work of carefully planned releases as support tickets now pile up with customer complaints about how features are broken. By end of year, half the features are still being “stabilized” and the other half are mothballed.

53. No process for rarely-performed tasks.

A task is rarely performed, so there’s no documentation on it. Regrettably, someone must perform the task now and today the universe has decided for that person to be you. You go to look for documentation and find nothing. You look at the code for the systems involved and it’s unintelligible. You git log the associated files and discover that everyone involved with the system has already moved on. You wonder if you should move on, too.

When disparate teams try to coordinate on rarely-performed tasks a special sort of confusion emerges.

54. Have to build a replica for noobs who can’t write queries.

It’s deemed necessary for internal data analysts to be able to run queries against production data so they can serve customers and forecast future business (or other such violations of linear time). They’re granted read-only credentials to the production database because that should be sufficient. Later, you are paged because the service is down and the database is wedged.

You discover that one of the data analyst’s queries is taking up way too much memory and has locked a critical table. You kill the query, sever access, and prepare for hell in the morning. In the end, you deploy a replica so the internal teams can query production data without killing the production database. Leaders considered it too expensive to set up originally, but how expensive was the outage and all the effort which went into restoring service?

55. Layer 8 denial of service.

Once upon a time, you and your team decided to rewrite an app because your company’s business model changed and thus very little of it was still useful. You also didn’t like Ruby, so you decided to rewrite it in Scala because Scala was hot and everyone on the team wanted to learn Scala. Great, let’s trust our important business function to people learning a new language!

The first version of the app was supposed to be deployed alongside the Ruby version and coexist with it. That deployment failed and also caused the Ruby app to fail. Repairing that took 8 hours of downtime. Naturally, the sysadmin didn’t particularly appreciate having to stay for an extra 8 hours on a Friday because your team wanted to deploy outside of business hours.

A month later, you try again. It deployed successfully! …But the migration for the user accounts fucked up. You could use the new app, but no one had accounts for it other than the root account. A week later, you try again with a script to deploy all the user accounts – and that was successful.

Later, your team discovers the v1 of the app is very slow when actual work is done in it. So, you switch to using Cloudsearch to “optimize” part of the app. And it does! …Except Cloudsearch is eventually consistent and now users complain that when they add something to the app and click refresh, it doesn’t show up until 30 seconds later.

Your team rushes a hotfix to undo the Cloudsearch integration and restore the previous functionality. The sysadmin says no. You gave them less than a day’s notice to deploy this new version, even though your team knew about it for a week while you worked on undoing the integration. You will be lucky if you ship anything else the rest of the year now.

tl;dr the sysadmin is fed up and doesn’t trust anything your team deploys now.

56. Engineers take key bumps of YOLO in prod.

Your company prides itself on being a meritocracy with a flat hierarchy, which is why senior leaders (like your boss) can disregard deploy processes – like making a production fix for a bug on the production node and recompiling, re-introducing the bug on the subsequent deploy because they never fixed the issue in tree.

This travesty is an argument in favor of making manual deployments impossible or difficult (see #69), but there’s no guarantee that any proposed safeguards would avoid veto by the Director of YOLO Engineering who is responsible for the fuckup in the first place. Because it’s never their fault, is it?

There’s also a coding variant to this fuckup: someone yolo-typing new code into a live virtual machine. They hot patch at the Erlang console because they relish living in sin. It might be called performance art if it wasn’t fated to desecrate service performance.

That anyone would be allowed to do this assuredly reflects organizational dysfunction. It is so bonkers to be able to just like, write code on a production box and expect that it works. It is a pathological level of optimism. It is suspiciously reminiscent of the Pyro in TF2 who runs around burning everyone to a crisp with a flamethrower while, from their deranged vantage, they are showering the world in glittering rainbows and bubbles and whimsy.

“Well, I’d never do that!” you say, thinking this doesn’t apply to you. And then you’d proceed to attach VisualVM to the JMX port and yolo some gc tuning. Or you’d run some exploratory bash or SQL on the prod instance to get some data without having tested it fully in a test environment. Maybe you aren’t debugging in prod, but using tracing or performance analysis tools in prod to debug problems or tune settings without having tried first in QA at the very least makes you a co-conspirator and likely a Staff YOLO Engineer (maybe even Senior Staff if you continue to do it after reading this! Don’t let your dreams be memes).

57. Cloud credits are about to run out so you rush deploys to reduce your AWS bill.

You have to scale down really quickly because your cloud credits ran out and you can no longer afford your infra… which means you were spending money you didn’t have for a long time because Papa Bezos was your sugar daddy for a bit. As you scale down in a panic, you fail to load test the new database and regret not just selling out at one of the tech giants. Now your organization has successfully reduced costs… but also revenue.

58. Behavior in your dependents fucks up your deploy.

It’s trivial to mentally model your service in isolation; the rest of the world is immutable and your deployment is the only change in motion. In reality, other teams are hurling themselves at their OKRs, your sales team is onboarding new accounts, and your data integrations are data pipelines haphazardly built with popsicle sticks and glue. Like nature, the system is in constant flux and no matter how confident you are in your deploy, an unexpected shift in the system elsewhere can result in your system failing.

Maybe another team has worse deployment hygiene than you do and they yolo’d a version straight to prod without giving you a chance to integrate with it. Maybe they’re hotfixing an incident themselves and your service is collateral damage. Maybe a data partner changes their data format without announcing it (see #51) and every system in the path falls flat on its face.

It’s not your fault, but it is your problem. Scream into a pillow and sing lamentations to your pet or whatever you need to do to process your grief and move on to acceptance. Because if you want to prevail, you must be nimble and maintain the capacity to recover from unexpected failure.

Business Illogic

The deployment may pass your tests but it can still break your business logic.

59. Breaking API change for a partner.

Your team finally tackles tech debt and deploys the new, shiny, streamlined version of the API. A few hours later, a partner is screaming at your CTO because they were using the API in a way you never fathomed was even possible and their integration no longer works due to your change.

Another time, you’re celebrating the successful update of the auth method in your SaaS app. It passed all tests, got approval from the security team, and nothing broke after deployment… but, as you’ll soon realize upon wading into a shit show the next morning, you forgot to tell customers about the auth method update. Everyone built access using a certain type of token and switching the service to use a new method completely broke customer access. Guess who will be blamed for lower renewal numbers this quarter?

The “funny” thing about breaking API changes is devs will often argue what is or isn’t breaking. Semver this, semver that. It still takes the same signature and they only fixed a “bug” in the behavior of the other parameters… but what if the other software was relying on that behavior? Now it’s different and different is bad when customers rely on things staying the same.

60. Compliance calamity.

Compliance stuff is boring but it matters. Some subtle design, layout, wording, or data retention change in a highly regulated part of the system causes it to no longer be in compliance with one of the onerous compliance regimes it must be a part of for the business to remain viable.

For instance, your payment flow changed and now you’re no longer in compliance with PCI. This remains undiscovered until much later, as most failures of this type are. If you’re unlucky it’s the auditor who discovers it and you’re now buried in paperwork. Or you erode trust by violating user expectations about how you handle their data.

61. robots.txt that inhibits search engine indexing and traffic plummets as a result.

You change something in a way that results in search engines or other traffic sources deranking or delisting you. Maybe it’s as subtle as borking the preview cards; sure, the links still work, but it’s no longer as clickbaity to the ever-shortening attention spans of the plebeian spectators. Congratulations, you just killed your traffic source and meal ticket!

Everyone frantically tries to figure out what is going wrong as bank accounts drain. It might not even be something you changed — sometimes giants simply roll over in their sleep and crush smaller players. But it could also be that you messed up the robots.txt and are now poor.

The Audacity of Spacetime

Deploying the system at scale is different than deploying the little test sandbox version of it.

62. Deployment assumes all servers are updated at the same time, but they’re not.

This fuckup is so, so common. It breaks the simplified, but wrong, mental model that users will talk to your servers and only to that one server. It’s a useful model because it simplifies a bunch of things and is mostly true; when it’s not true, it’s often fine to overlook the effects. But, occasionally, the effects are catastrophic and nothing behaves properly until reality settles.

63. A new deployment begins while a previous one is still in progress.

Canaries and staged multi-region deploys can, by design, take a while – so your upgrade is only partially tested and deployed, resulting in an outage.

Most of the fuckups on this list are due to immature processes. But this one emerges as your processes begin to mature. Observing how your failures transform over time can elucidate your progress, a kind of mindfulness that is admittedly difficult to cultivate when feeling the crushing weight of disappointment.

64. Multi-stage deploys of unrelated components.

You’ve had so many deployment failures in the past and every deployment has been painful. Some well-meaning person has decided that deployments need to be surveilled with hawkish intensity. Deployment frequency plummets accordingly and every deployment is a potpourri of changes that various stakeholders demand go live.

Good ol’ batch deploys take forever. People get burned out or fatigued and then naturally make mistakes. Or it’s not their component and they don’t have skin in the game¹¹ and consequently are careless when handling it.

When failure does transpire, everyone’s frustration inflames. It’s either their component that failed and they’re frustrated at the lack of care by their peers, or it’s not their component and they’re frustrated that they have to be on this stupid Zoom call until 04:00.

The answer is probably splitting the deploys out; the only reason not to do separate deploys is likely organizational process or dysfunction (see also: Disorganized Organization).

65. Accidentally deploy more than you thought you did.

You’ve put a ton of work into automating your deployments. The automated tooling is effective and deploys exactly what you asked of it – but what you asked of it didn’t match your expectations.

Perhaps you thought you were deploying a branch containing only a hotfix, but it was started from the wrong base branch. Or maybe you thought you were asking it to target only a few canary nodes, but accidentally rolled the whole fleet. Perhaps the automation tries its best to make all of the servers consistent by ensuring changes must be deployed in the same sequence. Whatever it was, automation ruthlessly executed your command and now you’re scrambling to recover.

In many organizations, it’s difficult to justify improving the safety and user experience of internal tools since it doesn’t directly affect customers and “just” makes the system confusing for our engineers working with it. The silver lining is this outage will at least make the case that developer experience is important.

66. Zombie hosts.

Your new version operates under the assumption that the fleet is only running the new version and all instances speak the same protocol. But in reality, some hosts came back from the dead (i.e. maintenance) running an old version of the software after the deployment completed.

Now you have a zombie apocalypse on your hands with nothing to defend yourself but your laptop. You now regret choosing the ultraportable version rather than the hefty tank boi. And just like zombies, zombie hosts can sneak up on you when you least expect it, long after your deployment is complete when the post-apocalyptic landscape that is your prod environment seems almost serene.

67. Running out of cloud resources.

One fine morning, you discover you’ve run out of the specific instance type your service needs. Like, there are literally no more i3.16xlarge instances that exist for you to purchase in this universe (or possibly just the availability zone).

It turns out you are their largest customer, which, of course, the vendor never made clear for strategic reasons. Scaling beyond the capabilities of a vendor inevitably results in downtime. Either you convince the vendor to git gud or you patch to make the app creak along as you frantically build a migration path to a substitute, disrupting the roadmap in the process.

Or, on a Zoom meeting with a bloated attendee list, a dev notes that the app is slower: “I refactored the code to make it easier to read, but now it’s slower, so we need 3x the servers to run it.” You swallow bile. Lucille Bluth asks in your head, “How much could one server cost, Michael?”

If you have rollbacks, you should be fine. If you have autoscaling, you can just pay to address this problem. But nothing can help you automatically scale your tolerance to bullshit or rollback your life choices.

68. Proactively overloading your systems.

Scaling one part of the system puts pressure on other parts… and now they’re failing. You now must deal with an outage somewhere you weren’t expecting, all because you were proactive in anticipating capacity you’d need in the future. Worse, if that capacity is required right this millisecond, you face the dilemma of choosing which part of the system to sacrifice temporarily while you figure out how to fix the bottleneck.

Manual Deploys

69. Manual deploys.

Manual deploys are truly terrible. If there is a villain in the story of DevOps, it is manual deploys. They are not the serpent in the garden promising forbidden knowledge. Manual deploys are the Diablo boss that probably smells like rotten onions and toe fungus IRL and whose only purpose is to destroy any and all life.

Not convinced yet? Here are reasons A through Z to stop living in Clown Town. Each should be enough to convince you to automate at least the tedious parts of your deploys. Please, we beg you on behalf of humanity and reason, automate all the repetitive tasks you can, even if your org has an aversion to it. Humans are not meant for executing the same thing the same way every time.

An engineer walks into a bar, has two beers, and now is deploying to the entire cluster as they order a third. The bartender says, “You know, if you used an orchestrator, you could order something stronger.” That bartender’s name? Q. Burr-Netty.

Backups of the database probably don’t work. Every time you take a snapshot, it’s someone reading the docs off a DigitalOcean post on how to back up MySQL.

Copy pasta is always served with failsauce. Copying a config from an existing build to a new one, then forgetting to change the version number. Copying SSH authorized keys between machines… and if you’re managing them like that, it’s probably append-only which means your old ops people still have access to your prod servers.

Disk management as a matryoshka doll of disasters: capacity management, failing to provision enough space¹², IOPS management, SAN management and all the babysitting required for distributed disks, we probably don’t need to go on.

Expiration of certificates or domains, the tech tragicomedy. You know this will happen again in a year. You see the rhino charging towards you in the distance but there’s always something more urgent to do until it’s too late.

Forget to smoke test the whole environment. You perform manual tests but they only hit the “good” servers. Luck favors the automated.

GeoDNS routing with manual region switching so you can take down a data center and update it without any traffic… but actually DNS takes awhile to propagate so you still have a trickle of traffic coming in (does anyone care that much about those lost requests?).

Handling hardware failures is nigh on impossible. Are your systems even failing over?

Improper sequence when deploying components. Just like your dance moves, the order of your deploy steps is all wrong.

Jumpbox that people use as a dumping ground for random assets they need in prod, like random JAR files or Debian packages, movies they torrent at the office that they want to get on their home machine, random database dumps that people need for various purposes…

Keen to have the deploy done, you do not wait for changes to propagate, the cache to become warm, nor the system to become healthy. “No, sir, the engineer really worth having won’t wait for anybody.” ~ F. Scoff Gitzgerald¹³

Lonesome server runs the wrong version because you forgot to update all the servers. Or, you forgot one region when you’re doing multi-region updates.

Mismatched component versions. It’s very easy to do when you’re slinging deploys manually and how many database servers do we have again? Is Tantalum down or decommissioned? This IP naming scheme makes no sense. Is it even a database server?

Not copying code to all of the servers and not removing the old code from it, leading to conflicts worse than the tantrums on your executive team.

Overlook which environment you’re in. If it happens, it’s probably a process failure. Because it’s an easy thing to overlook, but there should be a lot more processes in place to catch someone from accidentally farting about in prod. Ideally, you shouldn’t even be able to make this mistake.

Provision users manually. Not only is it a pain in the ass, it is also fraught with peril.

Quarrels between IP addresses and hostnames that rival a Real Housewives reunion special.

Rotate the password or keys, but forget to update the service config with the new password. You rotate the password, so of course you have to update the config, but there may be numerous configs and it can be easy to miss one if it’s not documented or automated.

Smoke tests aren’t performed after manual production deploy. If you’re doing deploys the wrong way (i.e. the manual way), smoke tests are a way to mitigate some of the issues – but you must remember to actually conduct them.

Trusting that your on-call team will be paged despite never testing the paging plan.

Updating the monitoring system is overlooked. If you autoscale, the system managing the autoscaling will self-monitor the hosts. If you add a host manually to a system that doesn’t autoscale, you probably want the system to register with the agent that’s supposed to do the monitoring.

VPN that is a single-point-of-failure and held together with duct tape and twine. The VPN is required to access the network to do the deploys but apparently making it not suck is not required.

Wait for DNS propagation? Who has time for that?

X11 and RDP-based deploys where a tired sysadmin remotely logs into the virtual desktop of a system that shouldn’t even have a graphical environment and haphazardly drags files around until the new release is live. The commands can’t even be audited because there were no commands, only mouse movements.

Your sysadmin does maintenance on the database so that it can stay up, but in the morning you discover the settings they’ve changed cause the database to no longer run its background maintenance processes and you’ve just deferred your downtime until later.

ZIP or JAR file is copied from the developer’s laptop and now you have no record of what was deployed.

Thank you to the following co-conspirators for their contributions to this list: C. Scott Andreas, Matthew Baltrusitis, Zac Duncan, Dr. Nicole Forsgren, Bea Hughes, Kyle Kingsbury, Toby Kohlenberg, Ben Linsay, Caitie McCaffrey, Mikhail Panchenko, Alex Rasmussen, Leif Walsh, Jordan West, and Vladimir Wolstencroft.

Enjoy this post? You might like my book, Security Chaos Engineering: Sustaining Resilience in Software and Systems, available at Amazon, Bookshop, and other major retailers online.

The cybersecurity discourse is, of late, festooned with fear mongering about vulnerabilities in build pipelines. If an attacker exploits a vuln in our build pipeline, are we doomed? No, because it’s pointless for them to do so. But there is a real problem revealed by this clucking and clamoring: many security professionals (and vendors) don’t know how build pipelines work.

The twisted security tale they’ve spun is: One horrible day, our build infrastructure reads attacker-controlled data that triggers exploitation of a vulnerability. Yet, to achieve this, the attacker must gain access to our build system; if they can access the build system, they can change what it does and what gets built. Why do they need to exploit a vulnerability when they’ve already cinched their victory? Even male peacocks aren’t this wasteful.

Here’s how the real story unfolds. I, a nefarious attacker, want to corrupt the software builds coming out of BlandCorp’s GitHub Actions build farm. I’m already versed in how most build processes work at modern enterprises because attacking them is part of my job¹.

BlandCorp, like many enterprises, runs the Actions runner inside numerous pods on Kubernetes (or another build runner inside build infrastructure). These pods receive builds from BlandCorp’s GitHub server and then run the build steps that are specified in the target repository, such as:

• checkout the code
• install the language toolchain
• fetch the dependencies
• build the software
• run the automated tests
• upload the resulting artifact²

Build pipelines are not like a web application where there’s pervasive interactivity or it takes input by design. Build infrastructure is designed to grab the source artifacts, perform some work to verify and transform those source artifacts, and then deploy the results of that work somewhere.

The main interaction with the outside world is grabbing the artifacts. Build pipelines don’t ingest form fields or input from a command line; a build pipeline does its thing very well but its thing, in the grand scheme of things, is limited.

If there’s a vulnerability in the build pipeline I want to exploit as an attacker, I must find a way to interact with it. This interactivity is designed to be impossible – a testament to the efficacy of design-based solutions for security and reliability. Security vendors will not tell you this for somewhat obvious reasons. Vendors want to scare you about build pipeline vulnerabilities because if it were possible to exploit them, it would be dire, and they want you to pay them to soothe your fears.

If not through exploitation, then how does the story unfold? Imagine I have a code execution vuln I want to exploit. If I can change the data, I can already commit code – so I may as well write code that does what I want. As Raymond Chen said decades ago, “You shouldn’t be surprised that allowing people to run code lets them run code.”

Or, if I can change the software that runs the build runners, I can replace it with a malicious version. I don’t need to exploit a vulnerability at all because I already have the access I want to gain control over BlandCorp’s build infrastructure.

So, as an attacker, I can ferret my way into BlandCorp’s build infrastructure through three primary paths:

1. tampering the source code
2. substituting the dependencies or language toolchain
3. corrupting the underlying runner that performs the work

How do I reason about these paths as an attacker?

Path #1: Tampering the source code

The most direct and obvious way for me to tamper the source code is to commit new code to whatever I want to tamper, like a component that will be built by BlandCorp’s build runner. This is also likely the least stealthy way to compromise a build pipeline.

I, as an attacker, cannot simply submit a pull request (PR) with my malicious modification; or maybe I can, but it’s very unlikely to be approved by a human involved with the project. BlandCorp likely has branch protection, too, which prevents my ability to force push my malicious code. This displeases me as an attacker.

Path #2: Substituting the dependencies or language toolchain

Next is the most expensive path. The dependencies and language toolchain are where, as an attacker, I can inject data in the build process (like substituting or replacing the dependencies). But BlandCorp’s runner, like any runner, will fetch dependencies from their upstream locations on the internet and cryptographically verify them to ensure they match what developers expect.

Thus, to interlope with this software, I must incinerate tens of millions of dollars of CPU time to find a hash collision and meddle-in-the-middle the build workers. As an attacker, this also displeases me.

Path #3: Corrupting the underlying runner that performs the work

The runner that performs all this work in the build process is not cryptographically verified. But if we trust GitHub (or an equivalent vendor) to store our source code, we should trust them to be able to run it, too. Verifying the underlying infrastructure and keeping it safe is a lot of work. If we do it ourselves instead, we don’t gain any assurances about tampering and lack thereof.

To corrupt the underlying runner, I (the attacker) must invest ample time, money, and cognitive effort to either:

1. Compromise BlandCorp, who maintains a stuffy “no SaaS allowed” policy and thus self-hosts; if I compromise BlandCorp to gain enough access to their self-hosted build infra to tamper with it, I’m already deep inside BlandCorp (so no need to exploit a vuln unless I want to flirt with future incident responders)
2. Compromise GitHub itself (or an equivalent vendor), specifically in a way that allows me to successfully modify the GitHub Actions code or infrastructure as befits my devious schemes.

For either option, I can social engineer a developer or admin to poach their credentials or gain access to their machine, from which I can pivot (with varying degrees of difficulty depending on their IAM architecture). In the CircleCI compromise, attackers stole customers’ keys in this fashion (by pwning a CircleCI dev’s laptop) – a terrifying scenario for customers. But, for the purposes of this post, it’s worth noting the attackers didn’t corrupt the underlying runner because they already accessed the resources they wanted and why pursue something harder?³

I’m not spending tens of millions of dollars in either case, but this option likely leaves me wanting something easier as an attacker.

The caveat

But ay, here’s the rub⁴. BlandCorp might take shortcuts or they might use vendors that take shortcuts. One of those shortcuts is disrupting the verification steps – or not applying them to some component included in the build.

What do these verification steps involve? The worker (the tool in the build step that downloads dependencies) verifies a cryptographic hash provided in the application’s source code, usually right after the asset is downloaded and before it’s extracted or used (see path #1). The cryptographic hash is stored in a lock file that is versioned alongside the application source code.⁵

So far, so good. Let’s zoom out to the build steps themselves. Each CI system has its own little language for describing how to build a project. These CI systems want to bequeath us the freedom to build whatever we want, like building something custom with a bash script. But this freedom allows us to do things we shouldn’t do, like download unverified files from the internet and run them.

Thus, the special trust you must maintain is that whoever writes the build steps doesn’t include randomly fetching data from the internet in those steps. Generally, they don’t – it’s very uncommon to do that because it’s frowned upon by all parties but also because verifying things is the default. You’d have to go out of your way as a developer to write build steps that download data unverified from a remote location. So, you know, don’t.

It only takes a single step of “download data and install it, without verifying it” to poison your builds – as we witnessed in the CodeCov compromise. CodeCov offered an install process of “copy this line of code into your build pipeline” – specifically bash <(curl -s https://codecov.io/bash) – and that line of code (now deprecated, but at the time) fetches a file from their website, downloads it, and runs it. No one likes this.

The reason why security professionals detest this installation process is obvious; they are paranoid, even when unwarranted, so they distrust most code downloads. But software engineers also dislike this form of installation process because it destabilizes and jeopardizes reliability.

Security is a subset of software quality

I mention reliability because reliability is the reason why build systems are designed this way – a way that frustrates attackers by design. Engineers want to ensure that when they make a build, test it and deem it correct, then deploy another build to production, that the second build won’t be meaningfully different from the first one. Security may not serve as the primary motivator, but it benefits from this stringent reliability requirement.

Much of what we seek from a security perspective is enveloped by reliability. Security is ultimately a subset of software quality. This is a lesson that more security professionals should heed, especially those that protest that software engineers “don’t care about security.”

Reliability is also why many software engineers feel like the less security teams meddle in the build process (and other parts of software delivery), the better – the higher quality, more secure – it would be. Many of the things I read about “securing” build pipelines are half-baked and result in less reliable software, which means less secure software.

Is adding more things with opaque and unverified steps in your build pipelines a good thing? Check your security vendors’ install processes, too; how many used (or still use) CodeCov’s same approach to shove their scanners and wares into your pipelines? Glass houses, pots and kettles, etc.

Instead of barking up errant trees, security professionals should seek opportunities to invest in reliability with auxiliary security benefits so everyone wins. When we propose security “solutions” that destabilize reliability – like some newer security solutions requiring you to completely renovate your build pipelines to accommodate them – our colleagues will be baffled by our audacity. Understand the thing you are trying to “secure” before you thrust yourself in it.

If a security professional isn’t familiar with reliability in the context of software, that’s an urgent problem. If we hope to “secure” the software delivery process, we need to understand the innovations around reliability – whether site reliability engineering or software quality – that enable the ability to achieve all this high-falootin’ modern software stuff in the first place.

Start with the wiki on reproducible builds. Build reproducibility is something we care about for reliability purposes, but most cybersecurity teams today aren’t equipped to assess it. That must change.

Tech leaders and software engineers should consider where reliability investments may impart security benefits. We should teach our security colleagues about our software reliability efforts – especially how these investments exasperate attackers and impede their objectives (by skyrocketing the effort attackers must invest). Brainstorm how to further exacerbate attacker frustrations through these innovations.

Create a decision tree of how attackers might compromise your build infrastructure and capture existing design-based mitigations (as described above). It may spare you from unreasonable demands to fix CriTiCaL SuPeR uRgEnT bugs that can’t be exploited through any reasonable means.

My hope is that both communities can find common ground by thinking more about security solutions by design – but that starts with understanding our organizations’ systems and what purpose they serve. Otherwise, I fear the entrenched “vuln scan all the things” monomania will deepen and waste our precious time and effort on tilting at windmills.

Enjoy this post? You might like my book, Security Chaos Engineering: Sustaining Resilience in Software and Systems, available at Amazon, Bookshop, and other major retailers online.

Thanks to Alex Rasmussen, C. Scott Andreas, Camille Fournier, Leif Walsh, and Ryan Petrich for feedback.

You see, rather than reflecting on our inability to mitigate untrustworthy code by design – how wayward we strayed from the dreams of the first security thought leaders in the 70s and 80s¹ – in 2023 we’ve decided that we must purchase at least seven tools shoved into developer workflows (with one more for each developer that procrastinates completing the 5 hour security awareness training); design regulatory obstacle courses navigable only by the most digitally transformed of golden retrievers (by mortals who will never have to traverse it themselves)²; and that to really shift left, we must strap dolphins with vulnerability scanners to echolocate bugs in undersea cables (we wanted to try with bats in data centers but general counsel shot us down).

We have decided that all of this performative pomp led by Captain Ahabs everywhere will definitely Fix Things This Time – and it shows in our buzzwords.

This edition of my annual Cyber Startup Buzzword Bingo elucidates the current zeitgeist through which buzzwords are most popular among cybersecurity startups.

I surveyed 100 infosec companies’ websites³, the vast majority of which are startups who raised VC funding in the past nine to twelve months or else are notable (like having booths in RSAC’s Early Stage Expo). The idea behind the bingo card is to take it with you on journeys through vendor halls, sales pitches, or startup websites and see whether you can replace your eyerolls and abyss-gazing with the surprise and delight of “Bingo!”.

Without further introduction, below is the 2023 Cyber Startup Buzzword Bingo card – read on if you want more analysis:

What words are growing in influence?

All bolded buzzwords are on the rise (unless otherwise indicated).

We grew more sensitive this year, perhaps due to the intensifying focus on posture. Indeed, I’ve often marveled at the similarities between cybersecurity vendors and chiropractors.

We care more about CI/CD and APIs this year; even Kubernetes is mentioned more than endpoints, although I would waste an unreasonable amount of time watching security people try to explain what Kubernetes is.

The security industry is finally aware that developers exist, although they seem less enthused than Steve Ballmer was once upon a time (but maybe as sweaty about it).

Infosec also realized that workflows exist, which isn’t shocking given they seemingly remain unware of the existence of UX. Does this mean cybersecurity is creeping its way into the modern era? Software engineers strongly suspect security vendors are still full of shit.

In 2023, there are three simple words cybersecurity vendors want to hear from buyers: “You complete me.” They want you to discover all the insights they have to share and really wish you would prioritize them over all the other vendors you could take to prom; they are the fabled local single eager to meet you.

Vendors believe we feel the need for speed, our security engine antsy to go faster. Given how disruptive most DevSecOps tools are to software velocity, I suspect these vendors might be yanking our supply chain.

I don’t quite know what to make of the fact that effective soared in popularity while accurate plummeted. Perhaps these security tools are less like documentary coverage and more like reality TV – and the commonality of indecent exposure strengthens the case.

Finally, the world will perish in the battle between zero trust and trusted. Hopefully a mushroom cloud won’t follow, else we must resume our society beneath the Earth’s surface, Fallout-style. Or maybe ChatGPT will take control first. Remember, the goal is to convince the AI overlords that you’re a pet, not cattle!

Which words are falling out of favor?

All bolded buzzwords are on the decline.

Vendors suspect we care less about advanced, sophisticated, and zero-day attacks, which I can only hope is true because it’s about time we focus on the less sexy activity. Yet, I worry a new targeted buzzword threat is conspiring to rise…

While AI may be all the rage among VCs desperate to feel like they’re on the thoughtleading edge rather than the awkward outskirts of the dance floor, both it and ML are less popular in cyber startup product messaging this year. I guess it wasn’t as effortless as vendors assumed.

Vendors are now less unparallelled, unmatched, world-class, best-in-class, and enterprise-grade. How else were we supposed to understand their differentiators without those filler adjectives?? Jokes aside, I suspect this ultimately enhanced their messaging.

It is not a deep insight to recognize that some buzzy verbs seemingly flew too close to the sun last year: empower, enforce, optimize, orchestrate, and enrich declined considerably. Were they not powerful enough? Or did buyers’ eyeballs not find these verbs as seamless to digest as marketers hoped?

The term blindspots is thankfully falling out of favor, too; only 3 startups included it. If they arent going to be inclusive, then hopefully buyers won’t include them in their security stacks, either.

In general, I, for one, hope the decline of filler and fluff accelerates – but purpose-built buzzwords lurk on the horizon, as we shall see in the next section. Marketing pros are remarkably agile, despite the protestations by our sanity.

What words should we fear becoming A Thing?

All bolded buzzwords seem to be emerging.

Trying to manifest their ideal buyer persona into the universe, vendors started to use the term no-brainer in 2023. We talk a lot about attack surface, but less about the ever-growing buzzword surface and how its sprawl has a corrosive effect on our cognition.

Perhaps late to the Marie Kondo hype, cyber vendors are leaning into the word minimal. Is it a sign of maturity or growth? Or is it the first rumblings of an ominous shadow creature from the depths of Buzzoria? Will we cling to the guardrails as we hear its thunderous steps approaching or shall we perish?

2023 also budded the buzzword no-code, which is a pithy way of summarizing what CISOs which they could tell their software engineering teams.

Finally, cybersecurity vendors are simultaneously becoming more tailored and more holistic, perhaps belying their lack of coherent collective strategy – of course, other than to milk security buyers’ wallets as their foremost mission.

What will mortals on social media yell at me for not including?

Every year, mortals are mad at reality and take it out on me. As always, what buzzwords vendors spew to you in meetings are not captured by my scraper and I can only shudder to imagine what the results would be if I scraped #Security #ThoughtLeader Linkedin posts.

I know current consultants and future consultants regulators are trying to make SBOMs happen but, like fetch, they have not yet happened. MITRE grew yet again but has never hit critical mass.

I was actually surprised that observability is flat year-over-year, given there’s a push on that buzzword by Big Buzzword Agriculture research analyst firms. Perhaps there are smudges on the single-pane-of-glass that occlude vendors’ vision.

Speaking of cloudy, multi-cloud is relatively flat from last year and still slim in usage. You might find this to be a remote possibility, but I assure you it’s true.

And, finally, as evidenced when getting too close to the crowds at cybersecurity conferences, hygiene remains niche.

Something I desperately needed disappeared from the internet.

I was working through copy edits for my upcoming book and saw my copy editor’s comment that a link to a source wasn’t working for her. Strange, but okay. I clicked and – it wasn’t working for me, either.

Fine, I thought, I’ll just find the link on the Wayback machine. Nope. Okay, let’s google the link to get the cached version in the little hamburger menu. Nope. What about googling the quote? There were citations of the quote, but not the source document I read. I tried changing where I placed the quotation marks thinking perhaps I had quoted it incorrectly. Nope.

“How hard could an article about an ammonia plant incident from 1979 be to find?” I wondered aloud to my cat. He trilled at me with the blithe optimism of youth.

I moved onto a different branch of action, going back to the source I found my first search that cites the quote. I checked its references for the full citation, pasting it into Google only to find more materials citing the specific quote. Alas, none were the source.

The next obvious move to try was searching for the article title in Google Scholar. Nothing. I tried pasting just the title of the article (“synthesis start-up heater failures”) in quotation marks in Google Scholar – nothing – then Google – also nothing.

I tried without quotation marks – lots of irrelevant results to sift through, none fruitful. I tried with quotation marks in Bing, finding a single, but different, citation of the quote (with a slightly different title, curiously; “heater failure” vs. “heater failures”) but not the source document. I tried it in Baidu, and yet again found only another citation.

I distinctly remember thinking, “Well, fuck.” In vain hope, knowing my frenetic research patterns of devouring sources in rapid succession and, at best, bookmarking them, I checked my Downloads folder for the article. It was not there. I had relied on the purportedly immortal memory of the internet; but memory, like the moon, is a harsh mistress.

I stared indistinctly at my monitor in disbelief for a few moments before venturing down yet a new path: tracking down volume 22 of “Ammonia plant safety (and related facilities)” to see if the article was digitized and just OCR’d poorly – explaining why it might not show up in any search results.

This was more promising. I discovered the name of the organization who publishes it – the American Institute of Chemical Engineers (AIChE) – as well as a used book seller in the UK who appeared to be the only one selling a physical copy of it, but I worried it wouldn’t arrive in time for the extremely tight turnaround for copyediting (or perhaps even for the book going to the printers). And AIChE didn’t seem to have any archives available online.

At this point I was flummoxed. My mental model of reality was showing cracks, as it never occurred to me that something might completely and utterly disappear from the internet. After all, adults admonished us as children that whatever we did on the internet would be a permanent, indelible mark on our lives (or, at least, how others perceived us).

Yet, I am notoriously stubborn and refused to wallow in a deluge of existential panic; “get your shit together, Shortridge,” my brain scolded my brain into a brainstorming. The best course of action, I felt, was calling AIChE to ask if they had a version of volume 22 I could peruse or buy. I am allergic to phone calls but such an arduous quest calls for courage and heroism, so I steeled myself for the endeavor.

Someone quickly answered and asked me if I was fine being put on hold; I acquiesced. But instead of hold music, I received a “this number is not connected” message and listened to the busy signal until the line, and a small morsel of my soul, died.

I called them again. This time, the AIChE representative informed me that they do not keep archives and suggested I call or email the Linda Hall Library instead. Having just subjected myself to a phone call and believing that an email with a generic request was too slow for my now incandescent inquiry, I visited the library’s website to do a catalog search.

I discovered that my precious volume 22 exists! Kind of! It specifically exists in CD-ROM form (three of them total!) for fifty years of proceedings. I was ecstatic – I could check out the CD-ROMs, so there was hope yet! But wait, are they also located in NYC like AIChE? No… Kansas City.

Well, fuck. Alright. I popped an antihistamine and called the Linda Hall Library. They answered with a voice recording indicating that the library was closed due to inclement weather in the Kansas City area; I searched to verify this claim and it was a legitimate excuse. Fine, I sighed, I’ll call tomorrow, which felt forever away in the midst of my epic quest.

In the meantime, a few additional avenues had occurred to me. I searched for the article on the Internet Archive and received the response, “invalid or no response from Elasticsearch.” It, too, was experiencing inclement weather.

But, I mused, maybe the Internet Archive does have it and I’m searching poorly. I searched for “ammonia plant safety” on the main page instead of the Books section and found that the Internet Archive has volumes 23, 24, 27, 28, 30, 35, 36, 37, and 42 – but not 22.

Well, fuck. I stared at my computer for a minute, indulging in a bit of renewed self-pity over this abrupt disruption of my mental model of the internet. Then I decided that fuck it, I want a souvenier of this experience, so I went back to the used bookseller and bought the physical copy anyway, timelines be damned.

After this pyrrhic victory, I finally went back to reviewing copy edits… but the mystery kept itching in my brain so in less than ten minutes I was back to hunting for the evanescent article. I went to the Google Books page for volume 22 for like the tenth time and finally clicked “Find in a library.” This took me to worldcat.org, which displayed a list of libraries and their contents. The New York Public Library, my obvious favorite, only had volumes going back to 1995; I needed 1980. I felt slightly betrayed.

I discovered Stanford’s library not only has volume 22 in their archives but will even scan it to PDF… but only if you’re affiliated with Stanford. I wondered how quickly I could become a visiting scholar or sign up for a PhD. Both, as you might suspect but I still verified just in case, are lengthy processes. Instead, I sent out a plea for help on Mastodon – but no one cared and I can’t blame them.

I looked up other libraries that possess my precious article, wracking my brain for academics I know. Princeton seems to have it, but I don’t know anyone there. The MIT library – where I do know people – lists seven other libraries that they know have it and I know no one in any of those, so… Stony Brook also has it; but I don’t know anyone there and going out to Long Island is Absolutely Certain A Burden (as any New Yorker can attest, ACAB).

At this point I’ve spent at least an hour, if not two, in pursuit of this volume and I realize I have better things to do with my life. I decided to just call the Linda Hall Library again tomorrow and see what they can do.

I called the next morning. The soft-spoken gentleman on the phone was very helpful in tracking down that the Linda Hall Library possesses not just the CD-ROM copy but a physical copy as well and, even better, they can provide a scanned version for a total fee of $49.50. I rejoice. I submitted the request for it with the 6 hour delivery premium option so that, if everything goes to plan, I receive a scanned copy by day’s end.

I received the scanned copy far sooner than day’s end, much to my delight, and nearly wept with joy when I saw the quote in question on the fifth page of the document¹. There, at a tilted angle, read:

“If you only depend on well-trained operators, you may fail. I think you really must depend on the design approach and don’t depend much at all on the operation.”

The parallels to software engineering are likely obvious just from reading the quote. There are other quotes in this article – specifically in the discussion section regarding the ammonia plant accident – that are highly pertinent, too, like:

“The point that makes this operation the most dangerous is the fact that the heater is not used daily. You may only use it a couple of times a year, and most of the time it’s just sitting idle, so that you don’t really pay too much attention to it.”

It makes me want to collect an exhaustive list of similar publications from other niche domains that publicize their incident reviews. What else might we glean?

My forthcoming book is, in part, a bold attempt at pattern matching across domains like chemical engineering but also healthcare, air transportation, forestry, ecology, aerospace, urban infrastructure, natural disasters, and other complex systems domains to borrow opportunities to sustain resilience in our complex software systems.

Yet, I know I am only scratching the surface since so much of this knowledge is siloed; what other industry publications with valuable lessons learned might have vanished from the internet as well, or never made it there in the first place?

My physical copy from the UK arrived in under two weeks (but after the completion of the copy edit, as predicted), so I received a second dopamine spike when feeling the volume in my hands and reading the quote directly from its worn, weathered pages. I never thought I would feel such joy from owning a publication about the agonies and ecstasies of ammonia production from many years before I was born, but in another sense, that feels entirely on brand for me.

)

Conclusion

What is the lesson of this tale? Libraries and esoteric bookstores are marvelous and we should fight to preserve them how we can. Also, if you find a source that is quite important to your project, download a local version just in case (or ensure it makes it on the Wayback machine).

It isn’t everyday that something disappears from the internet. But, like any complex system, we must appreciate that surprises are natural and prepare accordingly.

Enjoy this post? You might like my book, Security Chaos Engineering: Sustaining Resilience in Software and Systems (with Aaron Rinehart), available for preorder on Amazon, Bookshop, and other major retailers online.

I averaged exactly 3 books per month in 2022, lower than both 2021 and 2020 – but the number of books I wrote skyrocketed (the aforementioned O’Reilly book and the second draft of my fiction novel). So, seems reasonable all-in-all.

In last year’s post, I noted I read nearly 10 papers per month but this year I lost track of how many I crammed into my brain, so an exact tally shall remain a mystery. The number of research papers I wrote with esteemed collaborators is far easier to count (3); they cover action bias in incident response; the ROI of security chaos engineering; and the “sludge” strategy for systems defense. Our research article on Deception Environments was also published in the June 2022 edition of Communications of the ACM, although we wrote it last year.

As always, I am not rating or recommending any specific works in the list below. With that said, I dedicate considerable effort to screening books beforehand since time is the most precious, fleeting resource we possess and we must protect it like a dragon hoards gold.

If you’re looking for more science fiction, speculative fiction, pretentious literary fiction, philosophical navel-gazing, or non-fiction recommendations, check out my reading lists from prior years:

• 2021 reading list
• 2020 reading list
• 2019 reading list
• 2018 reading list
• 2017 reading list
• 2016 reading list

Fiction

All the Birds in the Sky by Charlie Jane Anders

Babel: Or the Necessity of Violence: An Arcane History of the Oxford Translators’ Revolution by R.F Kuang

The City We Became by N.K. Jemisin

Dark Matter: A Century of Speculative Fiction from the African Diaspora by Sheree R. Thomas

The Deep by Rivers Solomon

Downbelow Station by C.J. Cherryh

Fathers and Sons by Ivan Turgenev

Faust by Johann Wolfgang von Goethe

Fevered Star by Rebecca Roanhorse

Figuring by Maria Popova

Fledgling by Octavia E. Butler

The Man Without Qualities by Robert Musil

A Master of Djinn by P. Djèlí Clark

Moby Dick: Or, the Whale by Herman Melville (re-read)

The Night Watchman by Louise Erdrich

Orlando by Virgninia Woolf

Piranesi by Susanna Clarke

The Recognitions by William Gaddis

The Remains of the Day by Kazuo Ishiguro

The Tempest by William Shakespeare (re-read)

Things Fall Apart by Chinua Achebe

Too Loud a Solitude by Bohumil Hrabal

Winter in the Blood by James Welch

Non-fiction

The Artist’s Way by Julia Cameron

The Black Agenda: Bold Solutions for a Broken System edited by Anna Gifty Opoku-Agyeman

Bolivar: American Liberator by Marie Arana

The Death and Life of Great American Cities by Jane Jacobs

Influence Is Your Superpower: The Science of Winning Hearts, Sparking Change, and Making Good Things Happen by Zoe Chance

The Life of the Mind by Hannah Arendt

Normal Accidents: Living with High Risk Technologies by Charles Perrow

Of Sound Mind: How Our Brain Constructs a Meaningful Sonic World by Nina Kraus

Seeing Like a State: How Certain Schemes to Improve the Human Condition Have Failed by James C. Scott (re-read)

The Science of Can and Can’t: A Physicist’s Journey Through the Land of Counterfactuals by Chiara Marletto

What is Life? by Lynn Margulis and Dorion Sagan

Wired for Love: A Neuroscientist’s Journey Through Romance, Loss, and the Essence of Human Connection by Stephanie Cacioppo

Your Brain Is a Time Machine: The Neuroscience and Physics of Time by Dean Buonomano

You can find all the essays in the “When We Say Security, What Do We Mean?” concept album here:

• Track I. When We Say “Security,” What Do We Mean?

• Track II. A Platonic Dialogue on Security (Securus)

• Track III. The Dawn of Security as a Noun (Securitas)

• Track IV. The Multifaceted Meaning of “Security” in the Roman Era (Securitas)

• Track V. The Evolving Meaning of “Security” in the Early Modern Era (Securitas)

• Track VI. What Does Security Mean in the Information Society?

The Meaning of “Security” in the Information Society

We end our journey in the modern era, the information society¹. The best way to summarize the concept of security in modern times is that it’s controversial af and dependent on context². But, Wolfers’ two-part definition of “security” from 1962 is widely cited³:

1. In an objective sense, security measures the absence of threats to acquired values
2. In a subjective sense, security reflects the absence of fear that such values will be attacked

The term “values”, here, of course, is ambiguous and open-ended. But let’s think about what this means for the cybersecurity context.

A realist would say security is achieved when “the dangers posed by manifold threats, challenges, vulnerabilities and risks” in the digital realm are “avoided, prevented, managed, coped with, mitigated and adapted to” by individuals, groups, or organizations⁴.

A social constructivist would say security is achieved “once the perception and fears of security ‘threats’, ‘challenges’, ‘vulnerabilities’ and ‘risks’ are allayed and overcome.” That is, objective security is not enough; the subjective will always wield considerable influence in the cybersecurity context.

In my experience, tech bros really do not like the idea that emotions or subjectivity come into play in tech stuff at all. They tend to describe their emotions as “logic” and subjective experience as “facts.” We don’t have enough time to unpack all of that in this post (and if only more of them would go to therapy). But it’s a very real problem when traditional cybersecurity folk wisdom was often woven by people who think the objective is all that matters.

What’s worse about the cybersecurity status quo is that the subjective is dismissed but the objective isn’t even really measured. Again, objective security measures the absence of threats to acquired values. We do not have objective security in traditional infosec and, by that definition, it’s not even really what’s being pursued. Even when fleshing out the realist interpretation of objective security, traditional infosec mostly focuses on the “avoided” or “prevented” part rather than the managed, coped with, adapted to part⁵.

From the perspective of modern scholars, security is meant to lead to more goal-oriented behavior while insecurity leads to threat-oriented behavior. As anyone who’s walked the RSAC vendor hall knows all too well, basically everything in cybersecurity today is about THREATS. Everything is a potential THREAT: your API, your CI/CD pipelines, your laptop, your phone, your fridge, your colleagues, your loved ones, even your own BRAIN is a THREAT because what if you make a MISTAKE and become the very INSIDER THREAT you swore to destroy!?!?!

Everything about the infosec status quo today reflects threat-oriented behavior, therefore implying insecurity rather than security. Traditional infosec isn’t about preserving and upholding values – like prosperity or productivity or an inclusive work environment. Traditional infosec is about preventing and avoiding threats, aiming for the impossible standard of attacks never successfully happening.

The cybersecurity status quo forgets the whole point of stopping the threats is to preserve certain values.

This fetishization of threats and elimination of them as an aim in itself is how we end up with infosec programs which cause so much grief and anxiety and friction for everyone else in the organization. If the infosec industry actually focused on preservation of values, then UX would probably be one of the most important skills in the discipline (but how would incumbent cybersecurity vendors milk that for cash?).

After all, what’s the point of protecting the cherished organizational value of productivity from potential attacks – which likely only happen sometimes rather than continuously, from an impact perspective – if you’re going to erode that value daily through security policies that seem divorced from real goals, constraints, and workflows?

What’s the point in protecting the organization against a potential financial loss due to attack when you’re not only spending its money on security (which could be spent elsewhere), but also slowing down its ability to grow revenue due to security procedures? For an organization with $100 million in revenue wanting to gain market share, shipping 20% fewer features per year due to friction created by the security program has more material impact short, medium, and long term than a ransomware operator demanding $1 million, $5 million, or even $10 million.

Waldron’s quite recent definition of the word security summarizes this all nicely and is worth repeating here:

“… security now comprises protection against harm to one’s basic mode of life and economic values, as well as reasonable protection against fear and terror, and the presence of a positive assurance that these values will continue to be maintained in the future.”⁶

Cybersecurity as it stands today flunks this definition. It is impossible to provide assurance that basic and economic values will be maintained in the future if you do not know what they are, which the infosec status quo does not know because they do not care because all of that is irrelevant to their noble need to sacrifice everyone’s time, energy, and money at the altar of the FUD gods to gain more budget, more headcount, more influence and they shroud this ritual in a lab coat of “rational” paranoia.

Before architecting a security program or allocating cybersecurity budget, we should understand the organization’s basic mode of life and economic values, including at the level of any teams who will be especially subject to security procedures (like software engineers). From there, we should aim to provide reasonable protection against fear and terror – that is, to provide subjective security, that ancient-school version of securitas which meant freedom from anxiety, fear, or care.

Our job as defenders should be to reduce the complexity of the security problem to such an extent that the rest of the organization is free from care about it (in fact, the systems theorist Niklas Luhmann argued that security efforts explicitly aim to reduce the complexity of the world⁷). And cybersecurity’s job should be to provide positive assurance that the organization’s values (like prosperity, productivity, inclusion, whatever) can be maintained going forward.

But all of the above requires user research and empathy and curiosity about things beyond infosec’s viewing frustum. This modern definition of security means the organization must treat security as an interactive discipline, not a prescriptive one. The existence of a security program cannot be justified with “there is a risk here and it will never go away,”⁸ multiplied across all identified “risks,” which thereby implies a security organization that can only grow in scope and authority.

If those who provide security are the rulers and the users the ruled, what security really requires is the rulers respecting the ruled and the rulers earning the respect of the ruled rather than extracting it. This reflects a radical departure from traditional infosec and thus there is and will be resistance from the entrenched⁹.

Security, in practice, is supposed to reside at the beneficial balance between two evils: absolute fear and absolute security – and absolute security, per Kant, can only be found at the cemetery.¹⁰

Summarizing what we mean when we say “security”

Security is now one of those big words like justice and freedom and liberty which serve more as symbols with fuzzy flavors of feeling – that is, as concepts – rather than as words with straightforward definitions. As we’ve seen, asking the titular question, “When We Say Security, What Do We Mean?” is an exploratory exercise rather than an excavation. There is no ground truth we shall hit with enough sweat and shoveling.

We traversed a tapestry of meanings throughout this concept album. We finish it with a rough sense of, like, “Security is about preserving chill vibes in the presence of threats to those vibes.”

But more usefully (yet less concretely), we have a better mouthfeel for what “security” means. The threats aren’t the point; the poignant part is the potential absence of a valuable good or state of being which we very much wish to preserve.

An absence of threats is only worthwhile if it guarantees the presence of serenity and prosperity. In the word “security” is also a promise – that you hold onto something of value and that this value might grow in the future.

Perhaps most of all, this semantic journey of ours today reveals how wayward traditional cybersecurity is from these notions; it resembles a nemesis of the security concept rather than its descendent. I hope you join me on the quest to finally realize the full potential of the security concept, to grow peaches rather than lemons¹¹, to build a sweeter future for ourselves and all the other stakeholders in this strange system we call society.

Conclusion

You can find all the essays in the “When We Say Security, What Do We Mean?” concept album here:

• Track I. When We Say “Security,” What Do We Mean?

• Track II. A Platonic Dialogue on Security (Securus)

• Track III. The Dawn of Security as a Noun (Securitas)

• Track IV. The Multifaceted Meaning of “Security” in the Roman Era (Securitas)

• Track V. The Evolving Meaning of “Security” in the Early Modern Era (Securitas)

• Track VI. What Does Security Mean in the Information Society?

You can find all the essays in the “When We Say Security, What Do We Mean?” concept album here:

• Track I. When We Say “Security,” What Do We Mean?

• Track II. A Platonic Dialogue on Security (Securus)

• Track III. The Dawn of Security as a Noun (Securitas)

• Track IV. The Multifaceted Meaning of “Security” in the Roman Era (Securitas)

• Track V. The Evolving Meaning of “Security” in the Early Modern Era (Securitas)

• Track VI. What Does Security Mean in the Information Society?

The State and “Security” (Securitas)

Centuries passed and the relevance of the word securitas faded. Thomas Hobbes, one of the founders of modern political philosophy in the 17th century, was really the hype man for securitas to keep it from dissolving into disuse¹.

Hobbes’ depicts the goal of securitas as the genesis and maintenance of peace, which, as we’ve already discussed, is quite unlike the cybersecurity status quo. Securitas is cultivated through alliances to make it dangerous for the remaining “all” to attack. Samuel, baron von Pufendorf² emphasized the need for allies with a less cynical angle, arguing that an individual human needs companions to aid them in order to realize securitas (which perhaps foreshadows the concept of “social security”).

Are cybersecurity professionals today known for gathering allies? Quite the opposite. For instance, the relationship between developers and security pros seems to only be getting worse³. Traditional infosec strategy does not enforce security policy through cooperation, but through coercion.

To keep a long journey into Hobbes’ rather paranoid – and exceptionally cynical – perspective short, he ultimately proposes that a sovereign should be the one to guarantee securitas by doling out punishments for violating agreements, which requires subjugation of the ruled by the ruler.

Punishing humans who step out of line and requiring obedience to their rules – for the ruled to subjugate their other wants as secondary to the needs of the sovereign… is this not the playbook of traditional cybersecurity? It is the easiest option to pursue because eliminating or reducing hazards by design requires far more effort than demanding obedience. And if there’s one thing Homo sapiens love above all else, it is cognitive efficiency.

It is quite interesting that securitas was used as imperial propaganda during the Roman era to insist that the state was necessary and by Hobbes to insist that the state must subjugate its citizens. Does this tell us something about status quo cybersecurity? Or should we instead deem it “security imperialism”?

Security, Welfare, Dignity, and the Early Modern Era

Around the same time Hobbes was slandering humanity’s nature and proposing the need for a strong-armed state (the 16th century), securitas also started to absorb a financial meaning: something pledged as a guarantee that an obligation would be fulfilled – that the debtor has no need to worry because something has been pledged against the debt.

In this colloquial meaning (which persisted for centuries), securitas is rooted in a feeling – that the lender doesn’t need to worry. And, similarly, we see a theme throughout the Enlightenment that the state should assure citizens that they do not have to fear violence, not just ensure that they are free from violence in their everyday lives. Basically, that the state has a duty to consider the feelings of citizens, not just protect them.

It is in this era and through the Industrial era that security starts to be seen as a human right, as an essential requirement for humans to enjoy all of the other rights. After all, if you’re the victim of violence (particularly a violent death) – or in a perpetual state of worry about it – it’s pretty hard to pursue liberty or prosperity.

Thus, over time, security evolved to mean a guarantee or assurance that certain things would be accessible to an entity – like “water security” reflecting the assurance that a human individual will have access to clean water on an ongoing basis⁴.

The temporal implication of this meaning is important: it is not just about having access to a thing (whether a physical good or an intangible value) now, but about the guarantee that you will have access to it in the future, too. Not just that you do not have to fear a violent death now, but that you do not have to fear a violent death in the multitude of possible futures on the horizon, either.

We can trace this notion through to the more recent “social security.” The term was coined on a whim because “pension” carried too much baggage to be palatable to a wide audience. So, they defined social security as a “type of security which would… promote the welfare of society as a whole.”⁵ (emphasis mine)

Thus, the purpose of security is to promote the welfare of a particular entity. Extending this, the purpose of information security is to promote the welfare of information, the purpose of computer security is to promote the welfare of computers, the purpose of cyber security is to promote the welfare of cyber things. While the last one may feel silly, there’s something important here: promoting welfare is not just about stopping threats.

What else is embedded in this purpose of promoting welfare? As we explored, dignity was tightly coupled with security during the Roman period and this association resurged with the concept of “human security," which arose from the rejection of Hobbsian state-centric security.

While the term’s precise meaning is still subject to ample debate⁶, a foundational facet of “human security” is respect: that a critical part of ensuring a human is secure is ensuring their humanity is respected. Because dehumanizing certain populations and stripping them of dignity is one of the ways authoritarianism cultivates power; it is how a society slips into fascism.

What, then, should we make of the fact that the infosec industry sneakily strips users – whether the accountant clicking on a link to wire money, the marketing professional who downloads a PDF, the developer who makes a mistake when writing code – of their dignity?

The disrespectful sneer is palpable in the designation of “human error” as the cause of incidents. Security awareness training requires users to remember dozens of rules that ignore the realities of their work on thing-clicking machines and implies that it will be their fault if something bad happens. There is no respect for their time, attention, intelligence, or autonomy.

To quote the legendary James Mickens, “This is uncivilized and I demand more from life.”

But imagine a world in which infosec programs prioritized respect as a core value of security! Respect for users’ private data; respect for users’ time; respect for users’ cognitive and emotional energy; respect for users’ pursuit of their priorities; respect for the organization’s pursuit of its priorities as a collection of users serving other users.

In fact, the term “users” may even be part of the problem. Users are abstract, faceless, behind a screen. It makes it easier to disrespect them and resent them for not supporting our own goals. It makes it easier to not see them as people, but as exploitable resources that either we control or attackers do. It’s perhaps harder to blame a sleep-deprived caretaker of a lover or child or parent who, just trying to do their job well enough to keep their health insurance, clicks on something designed to look urgent and important.

Blaming a “user” for being so careless as to click on an obfuscated link and enter in their VPN credentials on the malicious site makes it a more antiseptic affair. It makes us feel like it’s a more just world rather than a chaotic one – like the problem is a user stepping out of line rather than complexities conspiring towards compromise. This dehumanization makes it easier to absolve the ruler and deride the ruled – these “users” – who are simply resources towards our ends, ever holy, ever noble.

Continue with Track VI: What Security Means in the Information Society

Conclusion

You can find all the essays in the “When We Say Security, What Do We Mean?” concept album here:

• Track I. When We Say “Security,” What Do We Mean?

• Track II. A Platonic Dialogue on Security (Securus)

• Track III. The Dawn of Security as a Noun (Securitas)

• Track IV. The Multifaceted Meaning of “Security” in the Roman Era (Securitas)

• Track V. The Evolving Meaning of “Security” in the Early Modern Era (Securitas)

• Track VI. What Does Security Mean in the Information Society?

You can find all the essays in the “When We Say Security, What Do We Mean?” concept album here:

• Track I. When We Say “Security,” What Do We Mean?

• Track II. A Platonic Dialogue on Security (Securus)

• Track III. The Dawn of Security as a Noun (Securitas)

• Track IV. The Multifaceted Meaning of “Security” in the Roman Era (Securitas)

• Track V. The Evolving Meaning of “Security” in the Early Modern Era (Securitas)

• Track VI. What Does Security Mean in the Information Society?

While a sense of dignity is not the vibe most of us feel when clicking through mandatory cybersecurity awareness training courses, dignity and security were seen as closely coupled concepts in the Roman era.

Cicero, living during the last century B.C., noted that whomever has tranquillitate animi (a tranquil mind) and securitas will have dignitas (dignity)¹. Cicero’s meaning of securitas here involves the absence of care or fear as well – and he saw this tranquility of mind as a prerequisite for an individual’s personal happiness and prestige in society. (We will talk about respect and dignity in the context of security more once we time travel to more modern definitions of the word).

A century later, Seneca framed securitas as a mindset[^24], a lovely extension of the existing notion of security as a bundle of emotions. Inspired by Socrates, Seneca viewed securitas – and the absence of the fear emotion[^22] – as how the wise can come closer to god because only a god has no reason to fear death[^23].

Securitas as this nearly-divine mindset quickly morphed into an association with divinity itself during the reign of Nero (the 1st century AD), specifically reflecting the divinity of the Emperor[^25] on coinage. It also started to reflect an environmental vibe rather than emotions or mindset; the surrounding world, the genesis of a subject’s freedom from care, could also be securitas, possessing a peaceful and tranquil atmosphere.

But Seneca also laid the groundwork for coupling the security of the state with security of individuals, in the specific sense of public securitas contributing to the capacity to live according to virtue. In this framing, securitas was explicitly based on mutual trust between the ruler and the ruled.

This reflects yet another semantic deviation with cybersecurity, which is generally mistrustful of any parties outside infosec, including those who should be allies (like software engineers). How else should we characterize the common refrain that any employee is a potential “insider threat”? And the cybersecurity status quo certainly does not seem to foster mutual trust by helping potential allies live well, offering minimal proof that they have the best interests of the collective in mind; if anything, they often prove the opposite.

In fact, Seneca highlights that it is a mistake to think that “a ruler is [only] safe when nothing is safe from the ruler.”² The pox of “shadow” assets – whether shadow IT, shadow SaaS, shadow containers, shadow APIs – shows that the infosec establishment succumbs to this mistake readily. In fact, infosec’s general fetishization of control – vitalized by vendors – is a continuous realization of this mistake.

As anyone familiar with the motifs of history could predict, the subsequent rulers did not listen to Seneca’s admonition, which eventually led to an explicit rejection of hereditary rulership in the Nerva-Antonine dynasty. (Take that for what you will in the context of our current cybersecurity rulership). This led Tacitus to express the new securitas publica (public security) as the confidence of the citizens that the state will no longer threaten them[^27]. That mutual trust was the core ingredient of securitas during that phase and reflected a check on authority.

It is interesting to ponder the notion of securitas publica in the organizational context; an organization’s citizens would be confident that the enforcers of security policy can no longer disrupt their way of life or erode their pursuit of fulfillment. How many cybersecurity programs might be characterized as such today? How many programs instead feel disruptive, corrosive to productivity, and fostering anything but a “peaceful and tranquil atmosphere”?

Securitas’ confident spirit evolved into meaning of “assurance of faith” (as opposed to doubt) during Roman Antiquity, as espoused by Tertullian and, later, Saint Augustine. This “opposition to doubt” again is at odds with one of the letters of the acronym which defines traditional cybersecurity: F.U.D. (fear, uncertainty, and doubt). As we’ve seen time and again throughout this series (and we’re only into the 2nd - 4th century A.D. here!), the earlier and variegated meanings of securitas fly in the face of traditional infosec. Traditional infosec wants to doubt everything. It takes pride in doubting everything. Assurance of faith is seen as a security sin!³

Speaking of faith, early Roman Antiquity also saw the creation of Securitas as a deity. While the mythos surrounding Securitas, the goddess, is lamentably shallow, it’s worth noting that she was the goddess of security and stability⁴. Given the evidence from the DORA research and metrics that stability and speed work in tandem and are complimentary, this suggests that if we worship at the altar of security, then we must also worship at the altar of speed.

The Roman god of speed, Mercurius (aka Mercury), was also the god of shopkeepers, merchants, travelers, transporters of goods, thieves, and tricksters. It’s worth noting that the coupling of commerce and prosperity with security is quite common throughout its history (more on this once we get to the 16th century). Traditional cybersecurity, in contrast, often pretends like prosperity is not the primary goal or, worse, views prosperity as a foe to security.

“Why don’t companies prioritize security? Don’t they know THE THINGS can be HACKED??” Well, dear security people, what do you think allows the companies to pay for your six or seven figure salary? It is because they prioritize money that they can afford to spend it on security endeavors that do not remunerate them and often cannot even be tied to tangible success outcomes beyond “we saw these malware samples or known bad IPs this month” spoonfed from vendor dashboards in symbiotic self-perpetuation.

The infosec industry forgets that security, even in its more modern meaning, is not just about protecting threats; it’s about protecting threats against something. In the business context, it’s about protecting threats against prosperity. Through this lens, is it not a victory if a security program waters the seeds of revenue growth? And is the security program not a tragic failure if it chokes and cages this material growth because of a “risk” that exists only as an incorporeal counterfactual?

Between the profligate spending on ineffectual security tools and the obstructionism imposed by security programs, it’s quite possible that the threat to enterprise prosperity by traditionalist information security rivals that posed by actual attackers.

This distinction is also emphasized in the term “national security,” even as we mean it today: national security is about defending threats to what? Liberty, prosperity, the pursuit of happiness… and we rightly dislike security measures that get in the way of these goals (often labeling them as “Security Theater”⁵).

Thus, we must ask, information security defends against threats to what? Largely the same things, but in businessy and computery contexts. If liberty or prosperity or the pursuit of happiness is choked out by security measures, then security is the threat in itself and the subjects are left in need of security against security⁶. Indeed, this is where we find ourselves with cybersecurity today.

But we are not yet done with this era. A few centuries after the deification of securitas, its meaning as “carefree” was twisted by religious leaders into an undesirable form: the state of being careless, reckless, heedless, and negligent⁷.

This notion of security is perhaps closest to the status quo in infosec today, which is quite careless with human (user, developer, colleague) time and attention, reckless with organizational budget, and negligent to design-based security solutions that are more reliable than attempting to control human behavior. The cybersecurity industry is heedless with its FUD-fueled zealotry, fretting about irreleventia while pretending nothing can be done about the grey rhinos charging into our systems.

Securitas was also relevant in the context of “Roman security” and specifically meant the Roman Empire’s peaceful and orderly domination of the world. Would we characterize traditional infosec programs as peaceful and orderly today? Even diehard zealots of the cybersecurity status quo readily admit that much of infosec in practice is firefighting and disorder. A worthy question is: who benefits from this paradigm?

Alas, the Roman Empire declined, as did securitas, whose meanings were largely stolen by the word certitudo. Thus, we must go to the provincial stables of the Middle Ages to continue our semantic safari. The two meanings of securitas not consumed by certitudo included pax (peace) and religious indifference.

The latter meaning persisted (albeit without nearly as much popularity as before) through to Martin Luther in the 16th century, who labeled “die Sicheren” as the people he was fighting against – people who did not truly trust the Holy Spirit and substituted true faith for religious rituals and conspicuous, performative acts. In his time, spiritual unity was preserved “through coercion and violence… dissent from orthodoxy was outlawed, heresy was rooted out and punished by fire and sword.” Luther was excommunicated for his “errors” about the Holy Spirit, including the “error” of believing the Christian god wouldn’t want heretics burned alive.

In our era, the traditionalist Security People put quite a bit of trust in their folk wisdom and rituals, despite their unclear success. It is still counterculture to suggest that humans shouldn’t be punished for security “errors.”⁸ And does it not benefit the vendors and research analysts to continue spoon feeding this advice to security leaders?

Just as Martin Luther felt centuries past about religious belief, is it wrong to want to reconstruct our entire approach to cybersecurity? Just because power structures are in place, incumbents entrenched, money flowing, does not mean something new, bold, and based on real acts of security rather than displays of it – on outcomes vs. outputs – could not supplant the status quo. Fatalism is not true to our nature as humans and certainly not true to the spirit of the “security” concept as we have seen.

But there is more for us to see and for that, we must venture onward into the pre-Enlightenment period and beyond…

Continue with Track V: The Evolving Meaning of “Security” after the Roman Era (Securitas).

Conclusion

You can find all the essays in the “When We Say Security, What Do We Mean?” concept album here:

• Track I. When We Say “Security,” What Do We Mean?

• Track II. A Platonic Dialogue on Security (Securus)

• Track III. The Dawn of Security as a Noun (Securitas)

• Track IV. The Multifaceted Meaning of “Security” in the Roman Era (Securitas)

• Track V. The Evolving Meaning of “Security” in the Early Modern Era (Securitas)

• Track VI. What Does Security Mean in the Information Society?

You can find all the essays in the “When We Say Security, What Do We Mean?” concept album here:

• Track I. When We Say “Security,” What Do We Mean?

• Track II. A Platonic Dialogue on Security (Securus)

• Track III. The Dawn of Security as a Noun (Securitas)

• Track IV. The Multifaceted Meaning of “Security” in the Roman Era (Securitas)

• Track V. The Evolving Meaning of “Security” in the Early Modern Era (Securitas)

• Track VI. What Does Security Mean in the Information Society?

The ancient association of securus with Epicureanism was not to last. Epicurianism was outlawed once the Roman Empire entered its rebellious Christianity phase because, as a philosophy, it’s quite incompatible with the idea that souls must be “saved” and that God is relevant to everyday life (Epicurus literally argued that the gods do not gaf about human affairs and do not punish or reward human behavior).

Why is this relevant to infosec? Because – as a collection of entities across vendors, consultants, thought leaders, and practitioners incentivized to increase influence on the world – information security has sanctified itself as a secular authority who can deem worthiness from on high and reward or punish according to behavior¹.

Most security advice roughly goes, “if you’re interacting with a computer and what you’re doing feels convenient, you are actually doing something BAD.” We’re supposed to report when we’ve done something wrong, like a Catholic at confessional. We can gain an “exception” from the security authority like the medieval Catholic Church granting indulgences² to partially reduce the punishment of the sin.

Naturally, only the ordained can read and interpret the sacred texts. The unwashed masses may only receive the good word. The divine wisdom is so complex, so arcane, far too difficult for anyone else to transform into action. Does this not imply that the non-security “normies” cannot be secure without the blessing of the security establishment? The human “users” must suffer in this life for their sins, for turning away from the path of security³.

In the eyes of the Infosec Church, users are weak sheep who must be told what to do and guided with a strong hand in the ways of natural security law, less they drift wayward into wickedness. We must practice chastity in all manners digital and resist the temptation of clicking on things unless we want the whole network to drown in depravity⁴.

For the Security Spirit is always watching. It knows when you allow incoming connections from cloud provider IPs even though attackers also use those IPs. It knows when you copy and paste something from Stack Overflow even though it could be backdoored. It knows when you don’t VPN on the hotel WiFi, where anyone, including a big, sexy scary APT could connect to it. Wicked, wicked user! A thousand years smoldering in hellfire and pestilence for your sins! Try clicking things now once the maggots have feasted upon your flesh!

We will return to security in the context of authority later, but now we must march onward to examine how securus, the adjective, evolved its noun form: securitas. In the Roman period, securitas specifically corresponded to intense emotions. And, it’s worth noting, the freedom from care represented by securitas does not require justification based on reality.

Securitas refers to a group of emotions (the things security and software “rationalists” alike pretend they don’t have) which relate to the absence of fear and include emotions like trust and confidence⁵. In fact, even the more modern notion of “job security” aligns to this older meaning; it is a feeling, specifically that you don’t have to worry about losing employment. Threats to it aren’t the point, the feeling is the point.

Now, my dear mortals, can we imagine an infosec program designed to ensure the organization is fearless and free from care, an infosec program that is quiet, easy, and composed? Cybersecurity as a discipline would be concerned with ensuring the organization could remain cheerful, tranquil, and serene. Servers would frolick in a field like fecund fawns. Software engineers would release code with confidence, trusting the safety designed into their languages, tools, platforms, and environments. If employees felt fear, uncertainty, or doubt when using technical systems, the security program would be curious and design solutions to alleviate their concerns.

Imagine an infosec program with the goal of relieving the rest of the organization from anxiety about security… cybersecurity that promotes convenience and puts in the hard work of crafting design-based mitigations. Status quo infosec – manifesting as SecObs, Security Theatre, etc. – seeks quite the opposite! Traditional cybersecurity programs openly admit aiming to increase anxiety among the rest of the organization to ensure they are vigilant to threats and always looking over their proverbial shoulders for potential peril. The security people decry convenience and shame users for seeking it while simultaneously indulging in it like Scrooge McDuck in his pool of gold by relying on enforcement, behavioral control, and blame as cheap “mitigations.”

I often read security advice or policies or other prescriptions and have the sense that the authors are trying very hard to pretend that local context is irrelevant and that generalized control is possible. Convenience is often framed as the enemy. The question is: convenience for whom?

Sure, convenience is clicking on every link or adding a third-party library without a second thought. But convenience is also requiring a security tool that you will never have to use, without performing any user research with the humans who will use it in their workflows. Convenience is tapping the 10^10 Security Commandments when someone makes a mistake and blaming them in front of Congress. Are we shocked that a framework of “convenience for me, but not for thee” doesn’t seem to produce the bundle of positive emotions securitas represented?

Are there words less associated with cybersecurity than “cheerful,” “bright,” “serene, “composed,” “quiet,” or “easy”?⁶ The whole business seems antithetical to those traits. Traditional infosec is all cura and no se – better deemed “cybercurity” than cyber_se_curity: a discipline of increasing concern, thought, trouble, anxiety, and grief in the organization regarding “cyber” matters. Offensive security is especially nonsensical through this etymological lens because it then means “offensive tranquility.”

Or maybe it isn’t that crazy. After all, don’t overpriced healing crystals and infosec wares have quite a bit in common?

Continue with Track IV: The Multifaceted Meaning of “Security” in the Roman Era (Securitas) .

Conclusion

You can find all the essays in the “When We Say Security, What Do We Mean?” concept album here:

• Track I. When We Say “Security,” What Do We Mean?

• Track II. A Platonic Dialogue on Security (Securus)

• Track III. The Dawn of Security as a Noun (Securitas)

• Track IV. The Multifaceted Meaning of “Security” in the Roman Era (Securitas)

• Track V. The Evolving Meaning of “Security” in the Early Modern Era (Securitas)

• Track VI. What Does Security Mean in the Information Society?

You can find all the essays in the “When We Say Security, What Do We Mean?” concept album here:

• Track I. When We Say “Security,” What Do We Mean?

• Track II. A Platonic Dialogue on Security (Securus)

• Track III. The Dawn of Security as a Noun (Securitas)

• Track IV. The Multifaceted Meaning of “Security” in the Roman Era (Securitas)

• Track V. The Evolving Meaning of “Security” in the Early Modern Era (Securitas)

• Track VI. What Does Security Mean in the Information Society?

Persons of the Dialogue¹

SECRATES

THEOXORUS

Theoxorus: I am feeling secure in my knowledge today, Secrates, yet have no doubt you shall shortly annoy me with indistinct inquiries into something simple that we should enjoy simply for simplicity’s sake.

Secrates: Secure! O, my dear Theoxorus, do my ears truly witness you bringing a conversation to me on a shining platter?

Theoxorus: What do you mean, Secrates?

Secrates: I mean that you used the word “secure.” And what does “secure” mean? We should always be on the lookout for such answerless words. I know you do not wish to examine it, but now we must!

Theoxorus: Secrates, no –

Secrates: Do you truly object? Is it not your own lips which revealed the relevance of this word to your very life?

Theoxorus: I… I cannot object.

Secrates: And neither can I. We must proceed and, another time, we can discuss what your hesitance for exploration means. I observe that you grow weary of dissecting words and essences of late. And yet with what else do you fill your days? Is it not your own shame you are unwilling to confront? Is it not this regular discourse that exposes the inner self you wish to –

Theoxorus: Secrates! Let us examine “secure” now and my own soul later.

Secrates: As you wish, my dear Theoxorus, I will now proceed with this inquiry, for which I owe you many thanks. There are two words from our current civilization that serve as the inspiration for securus: ataraksia and asphaleia. Let us proceed first with ataraksia.

Theoxorus: What tongue is the word “securus”?

Secrates: Latin.

Theoxorus: “Latin”?

Secrates: Yes. I have seen into the future during a bathing ritual.

Theoxorus: Ah, Secrates, you indulge in the pleasures of the oracles!

Secrates: Believe what you wish. But let us now proceed, as you insisted. What defines ataraksia but what it is not? It is the negation of taraksia, from tarrassein, which means to trouble the mind, to agitate, to disturb, to stir.

Theoxorus: Just as your incessant inquiries do to me.

Secrates: Precisely. And if ataraksia is the negation of these verbs, may it not be said to reflect calmness, equanimity, tranquility? It is as Pyrrho said, a form of freedom from distress and concern, and as the public says in their less formal dialogue, it is the mental state soldiers must cultivate before battle. Is it a goal, a kind of goodness, that a person must pursue in their lives? The Pyrrhonists, Epicureans, and Stoics would agree with this, each for different reasons reflecting their different philosophical foundations.

Theoxorus: What do you think, Secrates?

Secrates: I know nothing, as you know well, Theoxorus. What matters for our conversation is the essence of ataraksia: a freedom from disturbances, especially of the mental variety. And, then, as I have seen in my bathtub in a very distant future, what matters is that the verbs ataraksia is meant to negate – to disturb, to agitate, to trouble, to stir – are the verbs most associated with traditional cybersecurity. Does this not suggest security then means its very opposite?

Theoxorus: To be sure.

Secrates: And does this not trouble the mind in itself?

Theoxorus: Certainly. But how can you know such contraction abounds?

Secrates: This future world seems designed by contradiction. Their “security awareness training” exercises, such as those meant to phish humans as one lures a fish with a decoy worm, have the explicit goal of “troubling the mind” to keep persons vigilant for danger. In this future, application security tools are infamous for how they disturb software development and delivery practices – and does that not trouble the minds of software engineers? The list of security rules and policies are unending, often arbitrary – and have they not found a most effective means to agitate the subjects under their dominion?

Theoxorus: They have.

Secrates: And do we believe that such activities result in greater defenses?

Theoxorus: Certainly not, unless one believes that defense is impossible through design. This reminds me of our prior dialogue on beauty, Secrates, as what you describe of this “infosec industry” must make it beauty’s enemy.

Secrates: Are you surprised, Theoxorus, that infosec makes enemies when its goal is to disrupt tranquility? And how could infosec achieve beauty when it sees ugliness and danger in all things outside itself?

Theoxorus: Of course. But surely some interpretation by other schools of thought justifies this perversion?

Secretes: They will not. Atarksia is seen as a strict requirement to attain the true, full happiness referred to as eudaimonia. It may surprise you, my dear Theoxorus, that the word atarksia is associated with Epicurean philosophy.

Theoxorus: But calmness seems harmonious with Epicureanism.

Secrates: Did you wish to ask me a question, my friend?

Theoxorus: Your social skills are as crude as unfired amphorae, Secrates. So, then, what is shocking about this?

Secrates: It is shocking because it is hard to imagine a philosophy more opposed to infosec than Epicurianism, which argues that the goal of a sentient life form is to maximize pleasure and minimize pain². Epicurus is specific in defining pleasure as the absence of pain, and therefore “ethical hedonism” is the pursuit of avoiding pain, including pain that imparts pleasure near-term but pain longer-term. Without distracting ourselves by examining Epicureanism in more detail, we can say that the goal they espouse is to foster a life of tranquility. Does this cybersecurity community foster a life of such tranquility?

Theoxorus: They do not.

Secrates: I agree, my friend. Cybersecurity is not known for avoiding pain, regardless of temporal outlook. Infosec inflicts pain on others, whether by stoking fear or by making lives harder. Is it not fair to argue that infosec even inflicts pain on itself?³ Is it not cruel to cultivate obsession of vulnerabilities that kindle fear, uncertainty, and doubt when your stated aim is to eliminate them? Do we believe this fetishization of vulnerabilities and lascivious focus on blaming what they call “human error” can be called “ethical hedonism”? Or is it a societal mechanism to stifle introspection and to instead reenact shame? I regret that these questions reflect a topic for another time in the realm of psychology⁴, which has yet to be invented.

Theoxorus: You tease me, Secrates.

Secrates: Yes, but there is another thing, Theoxorus: what of asphaleia?

Theoxorus: You are unfailing in your pursuit, Secrates.

Secrates: Well, I suspect you might find its origin amusing. Asphaleia originates from wrestling and reflects the capacity to prevent being overthrown, being immovable and steadfast, like the throne of the gods, or like me in the presence of your lamentations and tantrums about our discourse. By roughly a century before our time⁵, asphaleia also came to mean the stability of the city state, to prevent being overthrown, and, if I permit myself to indulge in speculation, it could be extended to describe the stability of an organization (a kind of social entity I beheld in my bath). And, as some great scientists will prove thousands of years from our day, speed and stability of work harmonize and impart greater value together than apart. And, well, now I can put the matter as: is this infosec, that which slows down work, an enemy of asphaleia?

Theoxorus: Yes, certainly.

Secrates: Very good; and can you tell me how this might be despite asphaleia serving as the seed of the “security” concept’s own existence?

Theoxorus: I must confess, Secrates, that this “security” society of the future seems very lost.

Secrates: I dare say, my friend, that you spend too much time with me if you think it is an uncommon human desire to seek power and control, even at the expense of integrity. And can we truly argue that such desires are always conscious to the subject?

Theoxorus: Alas, they are not.

Secrates: If what you say is true, I ask you, then: what is this cybersecurity society not most of all?

When Secrates had asked his question, for a considerable time there was silence; Theoxorus furrowed his brow while meditating on this question; only Secrates made a sound when softly blowing on the delicate seedheads of a dandelion.

Theoxorus: For what did you wish as you blew, Secrates?

Secrates looked up at Theoxorus and said, with a smile: For you to answer my question.

Theoxorus: I will tell you. My feeling is that this cybersecurity society lacks curiosity.

Secrates: Exactly. The traditional infosec society is kin of Argus Panoptes; the role of enforcer grants them relevancy but not wisdom. Alas, my friend, if only they would follow the path of Daedalus instead. They feel ignorance as a sting and slight, as if ignorance was not the default condition of being alive! But there is more: how are they like the sophist?

Theoxorus: They both are paid to question without truth as their aim.

Secrates: And do they not both gain fortunes from this?

Theoxorus: They do.

Secrates: And are they not both hunters after a living prey, servants of the powerful, cousins of opportunists exploiting emotion for control?

Theoxorus: They are.

Secrates: But where the cybersecurity society differs is they seek the impossible void – the not-being of weakness – and they are willing to destroy whatever being stands in the way of this pyrrhic quest.

Continue with Track III: The Dawn of “Security” as a Noun (Securitas).

Conclusion

You can find all the essays in the “When We Say Security, What Do We Mean?” concept album here:

• Track I. When We Say “Security,” What Do We Mean?

• Track II. A Platonic Dialogue on Security (Securus)

• Track III. The Dawn of Security as a Noun (Securitas)

• Track IV. The Multifaceted Meaning of “Security” in the Roman Era (Securitas)

• Track V. The Evolving Meaning of “Security” in the Early Modern Era (Securitas)

• Track VI. What Does Security Mean in the Information Society?

You can find all the essays in the “When We Say Security, What Do We Mean?” concept album here:

• Track I. When We Say “Security,” What Do We Mean?

• Track II. A Platonic Dialogue on Security (Securus)

• Track III. The Dawn of Security as a Noun (Securitas)

• Track IV. The Multifaceted Meaning of “Security” in the Roman Era (Securitas)

• Track V. The Evolving Meaning of “Security” in the Early Modern Era (Securitas)

• Track VI. What Does Security Mean in the Information Society?

Introduction

We say the word “security” a lot in tech. Whether we refer to “cybersecurity” or “information security” (or “infosec”), how often do we pause to question what we mean when we say the word security itself?

In general, arguing that words should mean things in infosec is like fighting against the gravity of a supermassive black hole¹. Unfortunately for me, I will die on this hill until my inevitable spaghettification. From what I understand from cybersecurity journalism, this persistence makes me a “sophisticated” attacker, perhaps even one of those fabled advanced persistent threats (APTs). My cyberweapon of choice is words. My action on target? Destabilizing the industry’s dereliction of meaning. My APT group name will be SOCRATIC KITTEN.

So, true to the spirit of being advanced and persistent and threatening, I write this to challenge and, with any luck², overthrow incumbent notions of the security concept while nurturing new notions that inspire and uplift. Like any self-respecting former author of angsty teen poetry, I chose as my medium a “literary concept album” featuring six essays as “tracks,” all exploring the title’s provocative question: When We Say Security, What Do We Mean?

The security concept, like other words-as-concepts (happiness, courage, justice) is an idea, per Plato, perceivable only by the eyes of the mind³. To borrow from Hannah Arendt⁴, the word “security” is “something like a frozen thought that thinking must unfreeze whenever it wants to find out the original meaning.” To thaw it, we must meditate upon it, seep ourselves in it, let the currents of concept cleanse our preconceptions.

“But Kelly,” you sigh, “This is cybersecurity awareness month, shouldn’t you be posting about something practical?” Like, what, the growing ATTACK SURFACE due to HUMAN ERROR? Much like the spherical cow, such metaphors⁵ simplify our understanding of the world so it feels comforting and calculable as escapism from the real world, which is very messy. The security people, in no shortage of irony, choose convenience in this trade-off. Humans will interact with systems and do very natural human things and the security people will clutch their pearls and gasp, “But why would they do such a thing?!” Maybe spherical SBOMs will solve security so we can all finally stop being aware of it.

Because requiring awareness is part of the problem. We have a word for when humans are excellent at being of aware of threats in their environment: hypervigilance. It is not good when humans are hypervigilant! It means the human is likely traumatized and their nervous system is dysregulated. Unfortunately, the security people want us all to be hypervigilant because nothing says accountability for a problem like telling the potential victims they’re responsible for it.

Imagine, if you will, a parallel SKYSECURITY AWARENESS MONTH where we tell people to be careful whenever walking outside because a piano might fall on their head or that they should be scrutinizing the clouds – their trajectory, color, fullness, and other patterns – to figure out whether they are safe or not. In real life, we have meteorologists and can open an app that tells us whether we probably need an umbrella or sunglasses or to just stay inside to stay safe. Sometimes people will still go outside because that hurricane isn’t going to Instagram itself but there have been and will always be fools and our strategy in a problem domain should not be focused on the minority of fools who will not be persuaded by facts or logic and will gladly jump over guardrails while wondering why they were there in the first place.

My point is that the security people have collapsed upon a meaning of “security” as a concept that is not serving them or users or organizations or society particularly well. The cybersecurity industry’s meaning of “security” is a distortion, in many cases the exact opposite, of what the word means and has meant throughout its long, storied history. That history has much to teach us, which is why it is, in fact, entirely practical and pertinent to explore it on our upcoming semantic safari.

Thus, this concept album will illuminate why our current notion of (cyber)security, the concept, is worth re-evaluating through the lens of what “security” has meant over time. True to Socratic tradition⁶, these essays will not provide a definitive answer. Our path will be circuitous, but we will perhaps absorb a superior sense of what this ineffable concept of “security” is through ouroboric osmosis by the end of our journey⁷. We may not produce a definition of “security” by the end (although we will try) but, having pondered the meaning of “security,” we might be able to make our own attempts at it better.

To begin our journey, we must time travel.

The Curious Nature of Securus

It’s a few hundred years before the common era in Rome. You’re chilling in a thermae with your bae admiring the intricate stone mosaic of a rather fetching deity beneath your feet as you feel your pores cleansing in the luscious steam.

Your beloved anaticula⁸ looks at you and smiles, “If only all our days together could be securus like this,” they say. You smile back and nod in blissful agreement, watching them rest their eyes with a satisfied sigh.

For the securus life is one without care. Securus starts with sē, the Latin prefix for “without,” which combines with cūra, the noun for care, concern, thought, trouble, solicitude, anxiety, grief, and sorrow.

Hence, securus is to enjoy piece of mind (securo animo esse⁹). Securus is the absence of concern, the absence of a troubled mind. The opposite of securus was sollicitus — the restlessness arising from being filled with fear, apprehension, anxiety, alarm.

Hurtling forward in time to 2022 CE, we can observe that the typical traditionalist infosec program is closer to sollicitus than securus. Fear, uncertainty, and doubt (FUD) pervade – and perhaps define – the industry. FUD are the foundational emotions industry vendors, journalists, and less scrupulous thought leaders exploit for fortune and fame.

Our world is increasingly software and internet but there is a powerful industry that tells us that we should be scared to use software and internet, that it is desirable for us to be uncertain at all times when using software and internet, that we should doubt our perceptions at all times because what if the 13,371,337th link you click or line of code you write in your lifetime causes CYBERGEDDON. All of this anti-securus rhetoric is supposedly in our best interests.

FUD pervades cybersecurity to such an extent that we take for granted that these emotions need not define the security we seek to cultivate. Could FUD not instead be seen as the explicit enemy of security?

Thus, a worthy thought experiment is: how might infosec programs look if they actually pursued the state of being securus? How would a security program designed to ensure the organization is “without care or concern or anxiety” appear? How would cybersecurity strategy differ if the goal outcome was for users – whether end consumers, software engineers, or employees – to feel care-free and untroubled?

We will explore those questions as we continue our journey. Our next stop is even further back in history, inspecting the inspiration for the word securus in Ancient Greece.

Continue with Track II: A Platonic Dialogue on Security (Securus).

Conclusion

You can find all the essays in the “When We Say Security, What Do We Mean?” concept album here:

• Track I. When We Say “Security,” What Do We Mean?

• Track II. A Platonic Dialogue on Security (Securus)

• Track III. The Dawn of Security as a Noun (Securitas)

• Track IV. The Multifaceted Meaning of “Security” in the Roman Era (Securitas)

• Track V. The Evolving Meaning of “Security” in the Early Modern Era (Securitas)

• Track VI. What Does Security Mean in the Information Society?

Instead, the document’s guidance contains a mixture of impractical, confusing, confused, and even dangerous recommendations.

There is a collective ignis fatuus in the information security community that it is the “job” of an organization’s employees to prioritize security above all else. This fallacy holds us back from achieving better defense outcomes. Unfortunately, “Securing the Software Supply Chain” calcifies this falsehood.

Therefore, I have written this rebuttal in the form of ten objections:

1. Slowing down software delivery does not help security, it hurts it
2. There is an underlying paradox (the “Thinking Machine” paradox)
3. Most enterprises have no chance of implementing this
4. Most enterprises will not want to implement this
5. Security vendor bolt-on solutions are overemphasized
6. Relevant security and infrastructure innovation is omitted
7. Inaccuracies about software delivery practices and basic terminology
8. Confusing, contradictory messages from the authoring agencies
9. Omission of second order effects and underlying causal factors
10. Dangerous absolution of security vendors’ own software security

Objection #1: Slowing down software delivery does not help security, it hurts it

Empirical evidence from the enterprise software engineering world makes it clear that speed benefits not only business outcomes (like release velocity) but also security outcomes (like time to recovery, time to fix security issues). “Securing the Software Supply Chain” instead effectively recommends against speed, arguing for slowness and additional hurdles and frictions throughout the software delivery process.

The guidance is for a centralized¹ security team to impose significant restrictions on software engineering activity, thereby enforcing security as the top priority. For instance, IDEs (and plug-ins) are treated as threats to be “preapproved, validated, and scanned for vulnerabilities before being incorporated onto any developer machine.”

Speed, and even reliability, are treated as justified casualties for security’s sake. Given the mission of intelligence agencies, chiefly national security, they rightly view security obstruction as worthwhile. Their goal is not to grow market share or their customer base or improve profit margins by shipping more software, faster. This means their perspective simply does not translate to the private sector, unless we, as a society, decide a corporation must serve national security rather than its shareholders.

The result from this guidance – if the recommendations were implemented by, say, the Fortune 500 – is that software struggles to get built. Software engineers would quit (and have quit over lesser inconveniences in the private sector). Whatever the enterprise’s budget, with these recommendations they will build software slowly, and it will be of poorer quality – which is a direct detriment to the goal of higher quality, more secure software.

Objection #2: There is an underlying paradox (the “Thinking Machine Paradox”)

There is a logical inconsistency – perhaps even a paradox – presented: developers cannot be trusted, but automation is discouraged in favor of manual processes run by humans. If there is paranoia about “unintended flaws” introduced by developers, then why give them more opportunity to introduce them by recommending manual processes?

If there is concern that their user credentials will beget malefaction and mistakes, then why discourage service accounts², which are inherently decoupled from specific user identities? Without service accounts, if the human user leaves or is fired, then their credentials are still tied to whatever activity – which is a dangerous game to play.

The guide goes to great lengths to paint the picture of developer as an insider threat – whether purposefully malicious or “poorly trained”— but then explicitly espouses manual build and release processes. So, individual software engineers are simultaneously not to be trusted but also, they should be the ones to perform and approve software delivery activities?

Human brains are not great at executing tasks the same way every time. Computers are much better at that! And yet while the guide warns about the dangers of human mistakes, they want us to rely on those humans for repeatable tasks rather than automating them³.

Objection #3: Most enterprises have no chance of implementing this

Most enterprises have no chance of implementing the recommendations in “Securing the Software Supply Chain.” It is allegedly meant as a reference guide for developers, but it is really a reference guide for no one other than an intelligence agency with the same goals and resources as the NSA.

This is a criticism often made about Google: they propose advice that works for them and their titanic budget and pool of talent without considering the constraints and tradeoffs faced by “mere mortals.” CISA, the NSA, and the ODNI have fallen into a similar trap.

There are numerous recommendations that are impractical for enterprises, and not just the absurd one of disallowing internet access in “development”⁴ and “engineering”⁵ systems. For instance, if enterprises documented everything that a piece of software performs, it would be equivalent to writing it twice (and the documentation would inevitably differ from the source code); enterprises would likely be better off with no documentation at all and just reading the source code.

As another example, they also recommend that “Fuzzing should be performed on all software components during development.” If fuzzing all software components during development was a strict requirement, enterprises might never ship software again⁶. They also recommend “Using a testing approach…to ensure that repaired vulnerabilities are truly fixed against all possible compromises.” If enterprise software engineering teams knew the graph of possible compromises, why would we need all of this guidance?

Objection #4: Most enterprises will not want to implement this

Most enterprises will also not want to implement this. The recommendations do not scale⁷, are not aligned to enterprise software delivery priorities⁸, and erode⁹ productivity¹⁰.

Intelligence agencies, whose mission is national security, have no choice but to implement a paradigm as described because the alternative is simply not developing software. Enterprises in the private sector, whose mission is making money, do not face the same constraint; the constraint they face is, instead, the number of resources at their disposal and, to support their mission, it is generally better to spend on revenue or profit-generating activities than those that obstruct or erode it (like the recommendations in this document).

The top priority among enterprise customers is usually not security, either, regardless of the enterprise being B2B or B2C. Security will only be the top concern about customers if the primary customer is an intelligence agency, which constitutes very few enterprises, especially within the Fortune 500/1000.

Through this lens, advice like “If possible, the engineering network should have no direct access to the internet”¹¹ and “If possible, development systems should not have access to the Internet”¹² suggests a mental model of for-profit enterprises that significantly differs from reality. Similarly, decrying “ease of development” features is not a reasonable position in the reality of enterprise software development; more constructive would be to suggest that such features must be considered as part of the system design and protected behind appropriate access controls and audit logging.

Some recommendations would even be considered “bad practice”¹³ by software engineers from a reliability¹⁴ and resilience¹⁵ perspective, and therefore rejected. The guide suggests using “a temporary SSH key” to allow admin access into production systems, whereas Ops engineers and SREs often prefer immutable infrastructure specifically to disallow the use of SSH, which helps with reliability (and cuts off a tempting mechanism for attackers).

Objection #5: Security vendor bolt-on solutions are overemphasized

There is a pervasive overemphasis on vendor tooling with near-complete omission of non-vendor solutions. Specifically, the document touts a laundry list of bolt-on commercial solutions by incumbent security vendors – IAST, DAST, RASP, SCA, EDR, IDS, AV, SIEM, DLP, “machine learning-based protection”¹⁶ and more – often repeatedly singing their praises¹⁷. Rather than providing constructive, sane advice on automating processes and making them repeatable and maintainable, they recommend a smorgasbord of bolt-on tools.

The guidance is explicit in discouraging open-source software as well. There is also little about security through design, such as the D.I.E. triad. Unfortunately, this gives the impression that security vendors successfully lobbied for their inclusion in the document, which calls into question its neutrality¹⁸.

In fact, by promoting these commercial security tools, they promote dangerous advice like manual release processes. For instance, they recommend: “Before shipping the package to customers, the developer should perform binary composition analysis to verify the contents of the package.” But developers should not be performing package releases themselves if the desired outcome is high quality, secure software (see Objection #2).

As another example, they recommend that “SAST and DAST should be performed on all code prior to check-in and for each release…” But how is an enterprise supposed to perform DAST/SAST on code before it’s checked in? It is an ad absurdum of “shift left.” It is only one step leftward away from running the tools earlier inside the developer’s brains as they brainstorm what code to write.

But there is no mention of the need to integrate DAST/SAST into developer workflows and ensure that speed is still upheld. In enterprise software security, the success of a security bolt-on solution depends either on usability or coercion.

If you make the secure way the easy way and ensure that software engineers are not required to deviate unduly from their workflows to interact with the security solution, then it is quite likely to beget better security outcomes (or at least not worse productivity outcomes). The alternative is to mandate that a solution must be used; if it is unusable, then it will be bypassed to ensure work still gets done, unless there is sufficient coercion to enforce its use.

When the bolt-on recommendations are combined with their advice elsewhere to disconnect development systems from the internet, it begs the question: How do you use the SCA tools, among others, if the dev systems are not connected to the internet?

“Basic hygiene” is arguably better than any of these bolt-on option, including things like:

• Knowing what dependencies are present
• Being purposeful about what goes into your software
• Choosing a tech stack you can understand and maintain
• Choosing tools that are appropriate for the software you are building¹⁹

What does “being purposeful about what goes into your software” mean? It means:

• Including dependencies as part of design, rather than implementation
• Being cautious about adding dependencies
• Knowing why you’ve included other libraries and services
• Understand the packaging concerns of your dependencies; for example, if you include a dependency, what does it cost to feed the beast in terms of operationalizing and shipping it?
• If you take on a dependency in another team’s service, what are their SLOs? Do you trust them? Is it a stable system? Or have there been problems?
• If it’s an open-source library, is it maintained by one person? A team? A company with a support contract you can purchase? A company with a support contract you already have in place? Can you see its updating and patching history?

In essence, the answer is not: “never take on dependencies”²⁰; the answer is to understand what your dependencies are.

Overall, the recommended mitigations are all about outputs²¹ rather than outcomes²², about security theater rather than actually securing anything and verifying it with evidence. It is clear the guidance does not consider organizations who ship more than once per quarter; in fact, they seem to view fast software delivery as undesirable. They are mistaken (as per Objection #1).

Objection #6: Relevant security and infrastructure innovation is omitted

As mentioned in Objection #5, the document ignores a wealth of innovation in the private sector on software security over the past decade. The guidance seems to take the stance that the NSA/CISA/ODNI way is better than the private sector’s status quo, which is a false dichotomy. In fact, companies like SolarWinds have admitted their slowness was a detriment and have since modernized their practices — including the use of open source — to achieve improved security.

The fact that none of those innovations were included suggests an insular examination of the problem at hand, which erodes the intellectual neutrality of the document. I’ve listed the kinds of security and infrastructure innovations I would expect to see in a reference guide like this below (I have no doubt there are many others worthy of inclusion, too):

• Netflix’s Wall-E framework
• Segment.io on threat modeling
• Segment.io on time-based access
• The WebAssembly (Wasm) component model
• The Bytecode Alliance on Security and Correctness in Wasmtime
• IDE support for cloud-based static analyses
• Software provenance via CI/CD
• Automated patching via IaC
• GitHub’s Dependabot tool
• Resilient security log pipelines with security chaos engineering
• Facebook on 2FA for internal infra authentication
• AWS API Key canarytokens
• Google’s configuration distribution worked example (among many others in the same book)

The guidance would also be strengthened by considering survey data from the private sector, such as the recent Golang survey (which has a section dedicated to Security, including fuzzing) and GitHub’s Octoverse Security report from 2020 (their Dependabot tool is also an arguably glaring omission).

As another example, the document cautions against “allowing an adversary to use backdoors within the remote environment to access and modify source code within an otherwise protected organization infrastructure.” This dismisses the last 30+ years of source code management (SCM) systems.

You cannot just up and change source code without people noticing in modern software delivery. Even subversion is built on the idea of tracking deltas; if you change some code, there exists a record of when that code was changed, by who, and when²³. Most development workflows configure the SCM system to require peer approval before merging changes to important branches. It is worrisome if the authoring agencies are unaware of this given it has been the status quo for decades; if their vendors do not exhibit these practices, then this suggests a serious problem with federal procurement.

Objection #7: Inaccuracies about software delivery practices and basic terminology

There are consistent misunderstandings²⁴ and inaccuracies throughout the document about modern software delivery practices, including misunderstandings and inaccuracies about basic terminology, such as CI/CD²⁵, orchestration²⁶, nightly builds²⁷, code repositories²⁸, and more. This is part of a larger cultural problem in information security of trying to regulate²⁹ what they do not understand.

The reference guide does not seem to understand who does what in enterprise engineering teams. Product and engineering management do not define security practices and procedures today, because their priorities are not security but instead whatever success metrics correspond to the business logic under their purview (usually related to revenue and customer adoption). The characterization of QA is particularly perplexing and suggests a significantly different QA discipline exists in intelligence agencies than does in the private sector.

If enterprises were to follow the advice that “software development group managers should ensure that the development process prevents the intentional and unintentional injection of… design flaws into production code,” then software might never be released again in the private sector. The guide also seems to believe that software engineers are unfamiliar with the concept of feature creep³⁰, as if that is not the unfortunate default in product engineering today.

There are also simply perplexing statements. For instance, “An exception to [adjusting the system themselves] would be when an administrator has to fix the mean time to failure in production.” (p. 30, emphasis mine). I do not know what they mean by this and struggle to guess what they might mean. This, and other confusing³¹ passages³² tarnish the intellectual credibility of the guide.

The guidance is inaccurate even in areas that should be their area of expertise, like cryptography. “The cryptographic signature validates that the software has not been tampered with and was authored by the software supplier.” No, it doesn’t. It validates that the supplier applied for that key at some point; it does not say much about the security properties of the software in question. For instance, there is an anti-cheat driver for the game Genshin Impact whose key still hasn’t been revoked despite being vulnerable to a privilege escalation bug.

Finally, in what is more of an inaccuracy about enterprise security³³ than software delivery, the authors refer to “zero-day vulnerabilities” as an “easy compromise vector.”³⁴ This may be true for the Equation Group and their black budget funding but is not true from the perspective of most cybercriminals and, therefore, enterprises.

Enterprises are still wrestling with leaked credentials, social engineering, and misconfigurations (see Objection #8). For a Fortune 500, it is a victory if attackers are forced to use 0day to compromise you; you’ve exhausted all their other options, which should be considered a rightful accomplishment relative to the security status quo.

Objection #8: Confusing, contradictory messages from the authoring agencies

It is confusing to see that the same agency (CISA) who emphasized the need for repeatability and scalability last year only mentions the importance of repeatability once. And that another authoring agency (NSA) stated in their report from January 2020 that supply chain vulnerabilities require a high level of sophistication to exploit while having low prevalence in the wild.

However, this guidance makes it seem like software engineering activities should be designed with supply chain vulnerabilities as the highest weighted factor³⁵. Misconfigurations are given scarce mention, despite the NSA citing them as most prevalent and most likely to be exploited.

In the aforementioned guide by CISA, they highlight some of the benefits of cloud computing and automation. But in this reference guide, they indicate that the cloud is more dangerous than on-premises systems³⁶, without explaining why it might be so.

Much of the language is confusing, too, and never receives clarification. What is a “high risk” defect? What does “cybersecurity hygiene” mean in the context of development environments? They insist that “security defects should be fixed,” but what defines a defect? That it exists? That it’s exploitable? That it’s likely a target for criminals? Nation states? It remains unclear.³⁷

Objection #9: Omission of second order effects and underlying causal factors

There is no consideration of second order effects or underlying causal factors, such as organizational incentives and production pressures.³⁸ (There is one mention, quite in passing, that there might be various constraints the developer faces³⁹). This ignores the rich literature around resilience in complex systems as well as behavioral science more generally. In fact, the recommendations are arguably the opposite of adaptive capacity and reflect rigidity, which is seen as a trap in resilience science⁴⁰.

If enterprises are to attempt implementing these recommendations (which I very much discourage them from doing), then guidance on how to achieve them despite vertiginous social constraints is essential. Much of what is outlined will be irrelevant if incentives are not changed.

There is also no discussion of user experience (UX) considerations⁴¹ when implementing these suggestions, which, perhaps more than what is implemented, will influence security outcomes the most; an unusable workflow will be bypassed. Because the guidance ignores the complexities of software delivery activities and accepts convenient explanations for developer behavior, the resulting advice is often uncivilized⁴².

There is a missed opportunity to discuss making the secure way the easy way, the importance of minimizing friction in developer workflows, the need to integrate with tooling like IDEs, and so forth. This absence results in a guide that feels both shallow and hollow.

Objection #10: Dangerous absolution of security vendors’ own software security

There is ample discussion of the need to scan software being built or leveraged from third parties, and how a long list of commercial security tools can support this endeavor (see objection #5). Curiously, there is no mention of the need for those tools to be scanned, such as performing SCA for your EDR or anti-virus bolt-on solution.

Security tools usually require privileged access in your systems, whether operating as a kernel module or requiring read/write (R/W) access to critical systems. Combined with the long history of critical vulnerabilities in security tools, this is a rather troubling omission. This is all aside from the numerous software reliability problems engendered by endpoint security tools, which also fail to receive mention. Engineering teams notoriously despise endpoint security on servers for valid reasons: kernel panics, CPUs tanking, and other weird failures that are exasperating to debug.

Given the paranoia about IDEs and other developer tools, it feels strange that security vendors receive absolution and nary a caveat regarding their code security. Where is the recommendation for a proctology exam on the security tools they recommend? Do all of their recommendations for countless hurdles in the way of code deployment apply to patches, too? They are software changes, after all. If they do not apply, then that is a massive loophole for attackers to exploit.

Another surprise is that “anti-virus” is listed as being capable of detecting things like DLL injections⁴³; recent empirical data suggests otherwise even for EDR, which is considered leagues ahead of antivirus solutions. Again, it gives the impression that the guidance is biased in favor of security vendors rather than a more complete set of strategic options. The decimating performance impact these tools can have on the underlying systems, such as kernel panics on production hosts, also fails to receive mention.

Conclusion

If you read this guidance and implement it into your enterprise organization, you will end up securing the supply chain of nothing. Your engineering organization will dismiss you as an ideologue, a fool, or both; else, you will have constrained software engineering activities to such a degree that it makes more sense to abandon delivering software at all. In fairness, the most secure software is the software never written. But, in a world whose progress is now closely coupled with software delivery, we can do better than this document suggests.

Thanks to Coda Hale, James Turnbull, Dr. Nicole Forsgren, Ryan Petrich, and Zac Duncan for their feedback when drafting this post.

There are a few points we made in the paper that I especially want to highlight:

• Overlooking opportunity cost – the loss of potential gain from other alternatives when a choice is made – is rife within infosec decision-making across all activities, not just incident response (IR); get hyped for more on this from Josiah and me soon
• One way to start incorporating opportunity cost in practice is by considering the “null baseline”; in the context of incident response, it means considering the option of waiting to act
• Action bias is especially bad for IR because any option may be chosen without regard for its cost or value – and such rushed decisions can lead to suboptimal outcomes
• We use the Sony Breach as a case study of this and it’s worth pondering how much money they lost from the heat-of-the-moment decision to shut down all computers along with the corporate network once they discovered the intrusion
• This problem extends beyond security-specific IR, too – for instance, restarting database services that are running “hot” can exacerbate and extend the incident, despite reflecting a common knee-jerk response
• Part of incident preparation involves ensuring more choice options are available during response; for example, reliable logging pipelines would enable the rebuild option during response without sacrificing visibility into system behavior
• Our hypothesis is that thinking about a temporary delay is more helpful than a “do nothing” mentality as well as the “do something” (i.e. action bias-driven) mentality – the paper, of course, elaborates on why we believe so
• Practitioners frequently conflate ambiguity and uncertainty; in incident response, collecting more information (solving uncertainty) will not always guide you towards which choice will result in the optimal outcome (i.e. it won’t resolve ambiguity)
• Opportunity cost in infosec must also be considered with respect to its externalities; decisions made by defenders will impose costs on other stakeholders, whether users, software engineers, or even society – and those costs are woefully neglected today
• Pre-mortems, post-mortems, and chaos engineering experiments can all help incident response teams build “muscle memory” to support “watchful waiting” rather than succumbing to the instinct to act immediately
• And honestly our send-off just straight up slaps: “To avoid a breach is to try and prevent it. Overcoming action bias and properly pricing in opportunity cost instead requires a focus on preparation.”

The paper’s venue is the upcoming Human Factors and Ergonomics Society Annual Meeting in October 2022, but my co-author Josiah Dykstra published it on his site for the viewing pleasure of all mortals out there seeking enlightenment: https://josiahdykstra.com/wp-content/uploads/2022/06/HFES2022_OpportunityCostAndActionBias.pdf

Abstract

The hours and days immediately following the discovery of a cyber intrusion can be stressful and chaotic for victims. Without a documented and well-rehearsed incident response plan, people are prone to costly fear-based reactions. Action bias is the human tendency to favor action over inaction. It feels better for victims to do something even if rushed decisions are suboptimal to thoughtful, careful alternatives. Furthermore, the null baseline of doing nothing or watchful waiting can sometimes be advantageous. This paper describes an application of opportunity cost to action bias. While these insights are not yet backed by empirical data, this is the first work to examine the intersection of opportunity cost with action bias in cybersecurity incident response. Using Sony Pictures Entertainment as a case study, we discuss the implications of opportunity costs from acting prematurely and, conversely, the opportunity costs of waiting to act.

Citation

Opportunity Cost of Action Bias in Cybersecurity Incident Response. Josiah Dykstra, Kelly Shortridge, Jamie Met, Douglas Hough. Human Factors and Ergonomics Society Annual Meeting, October 2022.

Disclaimer: this is a satirical post. The publication of this post taught me satire is regrettably an art of which infosec is neither familiar or fond.

This past weekend, I learned of the most revolutionary DevSecOps startup yet.

Naive to my imminent enlightenment, I crunched into some delectably crispy bacon while having brunch with my bff, Apate Dolus, in the Village. Just as I was arranging a forkful of over-medium egg with peppery watercress, she took off her Tom Ford sunnies and gingerly folded them next to her truffle omelette, straightening her posture and drawing a deep breath. I halted my brunching and returned her intense eye contact, now curious.

“What is it?”

“I’ve founded a startup. I’m raising a seed round. And I want you to share its vision with your audience.”

My heart rate relented. That was all? I continued my cronching and monching, now with an extra serving of blasé.

“So,” I asked in between bites, “what does it do?” Knowing Apate’s ambition, I assumed she must be capitalizing on the effervescent web3 hype or else had crafted some other couture cash grab.

But what she said next thunderbolted me in place.

“It is HarpoCrates and we’re revolutionizing remote administration as a service. We’re going after a $2 trillion TAM with another $10 trillion – and change,” she grinned, “in untapped upside.” Her phone was suddenly in my hand, the pitch deck’s cover blazing on the screen. “Read it. The secret is AI to deliver remote encryption services at lightspeed and hyperscale. Deep learning. NLP. The highest payment conversion rates you’ve ever seen. The biggest payments you’ve ever seen. Think of it this way… HarpoCrates is an anemone and the world is our tasty fucking oyster.”

Time stilled on the sleepy cobblestoned street. A fat bumblebee guzzled nectar in a violently pink azalea bush near our cast iron café table. I, too, felt I was drinking deeply of some sweet substance. Apate’s pitch was near divine, an ambrosia too sublime for mere mortal throats to imbibe. The TAM pierced my soul like Poseidon’s trident; the value prop glinted and scintillated like Athena’s fabled crown; the differentiators dazzled and tantalized to such a titillating degree that I imagined Zeus himself would deign to transform into a vulnerable VPN just for a moment’s entanglement with HarpoCrates – HarpoCrates, so clearly fated as the climax of DevSecOps by all the oracles across all the lands, lest they be fools.

Apate swirled her yuzu mimosa as a royal vizier might swirl a mystical tonic in their jeweled goblet, having just bequeathed arcane insights from distant coruscating constellations upon an awestruck prince. Her long, coffin-shaped nails now bore a new meaning: a prophecy of the competitors she would bury. Her diamond tennis bracelet gleamed like a pristine weapon to be wielded around the market’s tender neck, wringing every last dollar from its coffers.

I looked up at the clouds swaying across the sky to the jazz of the late spring breeze. Such majesty, so high up… but not as high as I knew HarpoCrates’ valuation must be. Perhaps not even as majestic as the RAaaS revolution to come.

“Do you have a lead yet?” I asked, still awestruck. She rolled her eyes.

“Obviously. Every top VC was begging to lead. But I want some darling angels in my choir. And that’s where you come in. RSA is soon and I want meetings with the best of the best in infosec.”

My hands trembled as finished nibbling on my bacon and sipping my matcha latte. I felt honored with this glorious burden. This must be how Napoleon’s generals must have felt, I marveled, watching an overheated Chow Chow prance past our table. So, too, would HarpoCrates prance into countless enterprises and slobber all over them until they relinquished their coins.

Thus, here I am before the Internet today, spreading the word about the seed round to end all seed rounds, which is being led by the world’s best VC (who must remain anonymous, for secret reasons).

I’ve included the pitch deck below for the world’s perusal. HarpoCrates is actively seeking follow-on and angel investors, so if you’ll be in SF during RSAC week, I implore you to email Apate at ad@harpocrates.dev to learn more about this unprecedented opportunity and fund this unrivaled revolution in remote systems administration.

I surveyed 100 infosec companies’ websites¹, the vast majority of which are startups who raised VC funding in the past nine to twelve months. The idea behind the bingo card is to take it with you on physical journeys through vendor halls or virtual quests through vendor websites and see whether you can replace your existential dread with a cry out into the void of “Bingo!”.

For even more fun, see what your cursed cyber startup would offer by trying out my Infosec Startup Tagline Generator (built on Compute@Edge), which includes all the “best” buzzwords from this years’ cohort: https://brightly-willing-guinea.edgecompute.app/

Without further introduction, below is the 2022 Infosec Startup Buzzword Bingo card – read on if you want more analysis:

The top word this year was automated and its variants (automatically, automation, automates), which makes it the reigning champion since 2019. And everyone is now a platform, the second most popular word, even startups who do not actually offer a way to build or run anything on top of what they created (especially when their only creation is an MVP to raise their seed round).

Does this mean we will soon see a new word to indicate true platforms? I vote for flatform. Flatforms are shoes with thick soles but without heels, while platforms have thick soles as well as heels, making them far more precarious for perambulation and therefore making the distinction worthy of the “true platform” vs. “startup deeming themselves a platform on incredibly shaky semantic grounds.”

The following table lists the rest of the top 25 buzzwords and includes the number of companies who cited the buzzword, along with whether the buzzword was on prior bingo cards:

But the top words don’t tell the entire story. What merits inclusion on the bingo card is not just absolute popularity, but whether the buzzword is on the rise in usage, too. So, it behooves us to look at which buzzwords are en vogue and which are on their way to the clearance bin.

Which buzzwords are on the rise?

Let’s start with the zeitgeisty words on the bingo card itself. Solutions are now far more dynamic (+2,200% from the prior bingo card), finally acknowledging the nature of complex systems and the continuous nature of spacetime under general relativity. Vendors are also asking you to place your trust in Zero Trust (+183%) tools, split between tools aligned with a zero trust philosophy and those that fall under the namesake market category and collection of technical capabilities. How fun for practitioners who are already struggling to understand wtf either of those mean.

While some buzzwords are arguably obnoxious but innocuous, some buzzwords are supposed to mean real things and misappropriation of them is a scourge for practitioners. For instance, the buzzword agentless (+113%) has drifted from its true meaning, like one instance in which the purportedly agentless solution is an agent that lives inside your app instead of alongside it. Practitioners who read agentless and assume they will be adopting something lightweight and unobtrusive – without embedded hooks into the underlying system – will be understandably shocked upon implementation.

Similarly, the labels for fancy math like machine learning and AI are misused and abused to such a degree that they are rendered meaningless. While machine learning appears to be sliding into boring territory (-11%), vendors seem to be pivoting to labeling their linear regression models as AI (+58%). There is actually nothing wrong with regex or deterministic, conditional logic – it often works better than fancy math – but labeling it as ML or AI is simply disingenuous.

Our cursed timeline demands that if startups want to raise funding from today’s VCs, labeling their wares as AI or ML is a lamentable prerequisite. Nevertheless, they should at least elucidate the approach without technobabble or, even better, share data points to prove why AI is superior to deterministic approaches (whether in terms of efficacy, speed, or scale) for practitioners’ sake.

Then there are buzzwords like cloud-native (+170%) which are also supposed to mean real things, but the market map by the Cloud Native Computing Foundation looks like a conspiracist’s feverish ramblings and so I think its misuse is less appalling. If you don’t want a solution for cloud-native, many vendors also offer straight-up native (+108%) solutions that belie their nature as bolt-on tools or are trying to make “can run in Kubernetes like most other Linux software” sound special. Alas, after reading their marketing fluff, I question whether these vendors are even reality-native.

Following the lead of the Webb Space Telescope, security professionals now seek to discover (+79%) things like the oldest and most distant objects in the universe such as unpatched mainframes cowering pitifully in the COVID-vacated company headquarters. Security pros also want to optimize (+100%), although most invocations of the word on startup vendor sites were not accompanied by measurement that would help evaluate efficacy. How strange.

Perhaps inspired by the car industry, security vendors will offer you an engine that is powerful to accelerate (+53%) whatever things are being done. And two new words reflect changing concerns: security vendors, like chiropractors perhaps in many ways, want to help you fix your posture across the software development lifecycle – and ideally across your personal human lifecycle, too, to maximize customer lifetime value.

In terms of needless superlatives, vendors increasingly boast of being world-class (+200%) and unmatched (+1,100%) which perhaps better describes a sports champion. And a security solution is ideally frictionless (+233%) and effortless (+700%) because who needs the laws of thermodynamics?

Which buzzwords are on their way out?

Our long national nightmare with threat being used in every sentence in infosec may finally be waning if its 26% drop in usage holds true across the industry (if only we could eradicate the term “bad guys” with similar efficacy). Similarly, fewer vendors talk about advanced (-27%), complex (-40%), unknown (-19%), or targeted (-60%) attacks now and less than 10% of vendors are even mentioning zero-day (-20%) vulns. I can only hope this means the median is countering their natural cognitive bias and focusing on a more realistic threat model.

There is also less focus now on whether a solution is next-gen (-20%) or robust (-29%), perhaps suggesting that security buyer personas have realized that copy-pasting old solutions to new environments with new problems is insufficient and that prevention isn’t a panacea. Offering intelligence (-26%) isn’t the differentiator it purportedly used to be and, perchance having beheld the lambent light of reason, no one mentions dark (-100%) as in “dark web” anymore.

Which buzzwords will people yell at me on Twitter for not including on the bingo card?

Multi-cloud, DevSecOps, XDR, shift left, supply chain, SASE, SBOM – yes, yes I hear you but not enough vendors included them on their home page and product pages to merit inclusion on the card. No, I did not forget about them (DevSecOps and XDR each only had 12 vendors mentioning them; the rest of those listed have even fewer representative vendors).

I invite you to set up prediction markets on which buzzwords are likely to make the bingo card next year and then peer pressure vendors into including them during your own leisure time.

Which buzzwords are the weirdest?

My favorite buzzword this year is definitely wowful for obvious reasons although best-in-breed must win as the most amusing typo (which perhaps reveals the quality of their wares). Supercharge is a fun new verb that emerged among seven vendors this year and the six vendors who used harden are far more mature than I.

Two vendors presumably took inspo from the #FreeBritney movement and used toxic to describe the things they help ameliorate. Two vendors have solutions which are multidimensional, presumably to stop dreaded wormhole attacks and events only known relative to the motion of observability wetware.

One vendor described their solution as omniscient, not specifying whether their interpretation of omniscience is compatible with immutability² (which could make it incongruent with the cloud-native buzzword as well as classical deities). Someone, not content with describing APIs as “shadow”, threw all dignity to the wind and invented the term zombie APIs.

And finally, one vendor said their solution is zero-ops and I must invoke Heidegger to ask, “Why are there [ops] at all, instead of Nothing? That is the question.” Or should we follow Nishida Kitarō and ponder whether zero-ops means “[ops] affirms itself through its own self negation”³?

DevOps, or Zero-Ops, the two great ends of Fate,

And True or False, the subject of debate,

That perfect or destroy the vast designs of state —

When they have racked the developer’s breast,

Within thy pipeline most securely rest,

And when reduced to Rust, are least unsafe and best.⁴

Thanks to Adrian Sanabria and the Mad Tinkerer for feedback on this post, and to Mark Teodoro for porting my Python script into C@E (don’t blame him for the Geocities styling).

In security, obstructionism foments the dreaded Department of No, the begrudged gatekeeper, and the truculent Security Theatre¹. Hence, I am introducing the term Security Obstructionism (SecObs)², a category of tools, policies, and practices whose outcome is to impede or prevent progress for security’s (speculative) sake. I suspect the TAM (total addressable market) for SecObs is enormous and perhaps provides a more coherent understanding of security stacks than traditional market categories.

But outputs aren’t outcomes³. The amount of activity performed by a team is not equivalent to productivity nor its ability to produce desirable outcomes⁴. The secret to the SecObs market is that this does not matter. The point of SecObs is not better security outcomes for the business or end users. The point is more security outputs as a proxy for progress and these outputs impart more control over the organization, transmogrifying into power and status. In essence, the point is a self-perpetuating organism⁵.

How does the infosec organism self-perpetuate via SecObs? Here are some examples (which perhaps can be called “Indicators of Obstructionism” or IoOs⁶):

• Vulnerability management that creates long lists of things to triage (and outside of dev workflows)
• “Shadow” anything – shadow IT, shadow SaaS, shadow APIs…
• Manual security reviews, manual change approval – basically anything to block shipping new code unless security personally gives the go ahead
• Internal education programs that are not based on measurable security outcomes (the primary outcome is wasted time)
• “Gotchya” phishing simulations that primarily measure the efficacy of phishing copy rather than the efficacy of security strategy
• Password rotation, key rotation, access approval, and other policies that may leave internal users unable to work
• Corporate VPNs, whose most effective use in 2022 is perhaps as the entry point for Ransomware-as-a-Service operations
• Shutting down modernization initiatives (cloud, microservices, etc.), slowing adoption of new tech or tools⁷
• “Insider threat” detection that bears a remarkable resemblance to malware (such as using keyloggers⁸ and screen recording⁹…)
• Petulantly allowing “self-serve” security… but without providing recommended patterns or guidance
• As soon as a security property or feature is embraced by the rest of the organization, it no longer “counts” as security – like how I’ve heard SSO recently labeled somewhat pejoratively as “convenience” vs. security by some infosec professionals…

As seems necessary to legitimize a market category, I plotted SecObs on a market “graph”¹⁰:

Astute readers might have noted that some of these SecObs practices fall under the purview of “DevSecOps,” which is basically SecObs disguised in a hoodie, AllBirds, and Fjallraven backpack (carrying a Macbook). The typical definition of DevSecOps is that security is integrated across the software development lifecycle¹¹ and it is an unobjectionable goal. The problematic part is that the goal is twisted from a thoughtful entwining of things that could promote systems resilience from design through to delivery into a goal of security reasserting itself as an authority.

But even the typical definition of DevSecOps does not justify its existence as a term; we would also need DevTestOps, DevQAOps, DevComplianceOps, DevAccountingOps, DevGeneralCounselOps to ensure that their concerns are also considered or built-in throughout the SDLC (as they should be!). Ergo, DevSecOps is quite literally Security Obstructionism in the linguistic sense but lamentably in the living sense, too – inserting security into the equation to impede Dev from meeting Ops.

The tragedy of SecObs echoes across hype cycles: bad security ideology mixed with bad incentives leads to bad implementation which leads to bad outcomes in all dimensions except the justification of status quo security people’s existence. Implementation is manipulable and can pervert even noble goals into SecObs. For instance, “shift left” is the purported mantra of DevSecOps¹², but what it means too often in practice is shifting obstructionism earlier into the development process.

There are arguably some psychological benefits of ensuring expectations of timely software releases are destroyed sooner rather than later¹³, but the more tangible outcomes are that the obsession with preventing failure happens in more places. As a result, there are more outputs and more opportunities for finger pointing and citing “you did not follow process at X, Y juncture” when something goes wrong. Because SecObs is a defense mechanism, perhaps the most effective one in status quo security’s arsenal.

Obstruction is ultimately about preservation. Nobody obstructs something from happening if they want things to change. If security wanted things to go the DevOps way, they would understand that security, like resilience or reliability or maintainability¹⁴, is part of the outcomes that DevOps practices aim to achieve – and that there is immense value in ensuring all those qualities can be nurtured as a check against myopic organizational pressures¹⁵.

The problem is, if security is already one of the qualities that orgs doing the DevOps are trying to achieve, then that means the status quo will change. Software engineers, architects, and SREs will identify where existing security programs are falling short of desired outcomes and pioneer new programs to solve these challenges using their expertise as builders.

They will develop strategies to perform asset inventory, testing, and patching their own way – one that likely treats bugs as bugs, regardless of whether there are performance or security implications¹⁶. That means the security team is no longer performing these actions, which is one less thing to point to when proving the security strategy is “successful.” Never mind that security could absolutely still be essential by providing recommended patterns, serving as an expert sounding board, operating like a platform engineering team to build foundational systems to make security work easier, or leading security chaos engineering experiments¹⁷. Security professionals will be expected to design systems – a daunting shift that can catalyze existential panic about whether existing skill sets actually matter.

I suspect the lizard brain¹⁸ origin of SecObs lurks within in-groups and out-groups¹⁹. The information security establishment has seen itself as a marginalized outsider, a scorned prophet, an unfairly resented authority figure who is just trying to keep the devs from sticking forks into electrical sockets. Humans like seeing members of their in-group succeed, but they love seeing members of the out-group fail (or at least suffer)²⁰. Humans will sacrifice the greater good – or even more for themselves in a bigger but equally-divided pie – if it means the out-group gets less than they do²¹.

Adopting SecObs is how infosec can ensure the out-group(s) receive less. I have long been perplexed why some security professionals are quite so resistant to my thinky thinky – how could they so detest and resent something that extirpates toil for them so that they may stretch out their strategic wings to soar on the zephyrs of innovation? I’ve felt like they must see me as K-2SO saying “Congratulations! You are being rescued! Please do not resist.”

What I realized is that it does not matter if Security Chaos Engineering²² or all the other things²³ I’ve proposed make these infosec traditionalists better off; what matters is that they feel that they are worse off on a relative basis²⁴. SecObs makes everyone else in the organization miserable and puts them at least partially under infosec’s thumb. Therefore, even though it is a woefully inefficient use of the security team’s time, SecObs makes infosec better off on a relative basis – if not equals with engineering, at least able to directly impact their outcomes; if not fulfilled by their work, at least they aren’t the ones facing a Kafkaesque imposition on their workflows.

SecObs depends on the definition of “secure” remaining nebulous and unquantifiable. The argument for DevSecOps is that “while DevOps applications have stormed ahead in terms of speed, scale and functionality, they are often lacking in robust security and compliance.”²⁵ But what does “robust security” even mean? The justification for Sec being treated as an equal among Dev and Ops is based on wielding the abstract ideal of “security” as a Maginot Line. If you ask what a “secure” app means, you will rarely receive an actionable or consistent answer. Is it free of bugs? Does it never experience failure? Or is it something that only security teams and security teams alone can identify, akin to “I know it when I see it”²⁶?

Conceiving concrete security outcomes is not an arcane art, despite what the industry inculcates. An engineering team’s product is broken if they aren’t meeting relevant compliance standards. If they are addressing the retail industry, they can’t have a product if they aren’t PCI compliant; their customers quite literally cannot purchase it. The same is true for financial services or healthcare.

And in my recent experience²⁷, SREs think about impacts to availability more than security people, despite availability being the A in the classic C.I.A. triad (which just turned 44 years old a few months ago)²⁸. A cryptominer can impact stability and reliability in production – which jeopardizes the organization’s ability to conduct its business. An attacker exploiting a web vuln and crashing the machine causes downtime. Exfil of customer data can cause latency and result in compliance sanctions.

SecObs spends all its time fretting about preventing incidents and implementing tools and policies that impede business operations²⁹ under the guise of collapsing the probabilistic wave function of failure to zero while spending very little time actually preparing for the inevitable incident.

But if an attacker cuts down an application in a hosted container forest and it automatically disappears and grows again, who cares? The impact is negligible, just as it should be if security is done well – if security is focused on outcomes rather than outputs. All that prevention just doesn’t matter if you can’t recover quickly when something bad happens, which it will. And what was the point of holding up a release by a week because the security team wanted to personally inspect it first for bugs when the impact of exploiting those bugs is “autoprovision another container to replace the compromised one”?

What is to be done?³⁰ When you see or hear weasel words like “appropriate” or “sufficient” or “robust” to describe a “level” or “maturity model”³¹ of security, it is worth pausing to ponder whether SecObs abounds. If the security program evokes the on-prem monolith and waterfalls era – SAST, DAST, vulnerability management, security reviews and approvals – but is festooned with the words “continuous” or “automated”, then perhaps what is now automated and continuous is SecObs. When you hear “we need to bake security into [thing]”, it could be a boon – weaving security into workflows to make it consistent, repeatable, and scalable – but it could also be a leading indicator of SecObs; engineering teams will be left to sink or swim because when they fail, it’s an opportunity for SecObs to say, “See why you need us?”

SecObs is pernicious; it is deeply rooted in the information security swamp and will be difficult to excise from the industry. DevSecOps may be its modern incarnation, but SecObs is a larger problem that existed before this trend and will continue to exist after it wanes. SecObs carries a massive TAM – at least $10 billion and likely much higher³² – which means there are legions of incumbents incentivized to actively fight against its removal.

The strategies I have seen work are either to burn down the status quo (quite literally firing obstructionists and building anew) and / or to support motivated software engineers and architects building overarching security programs in parallel, which treats patches like other upgrades and attacks like other incidents. Security is treated as a facet of resilience, as it should be because it reflects reality³³.

What I have never seen work is attempting to modernize SecObs, which is what we are seeing with too much of the DevSecOps movement. Getting status quo security pros up to speed on the latest technology just means they’ll now be able to weaponize it and talk about the dangers of shadow APIs and shadow Infrastructure as Code and shadow functions.

Because getting up to speed in the SecObs market isn’t about understanding the technology – how it works, its strengths, its potential, its deficiencies, its concerns – it’s about understanding the power dynamics of it and figuring out where security can best assert itself to maintain control in the organization. Find a vulnerability, exploit it, persist in the system… maybe the only difference between the “good actors” and the “bad actors” is that the bad ones make money for their organizations.

Thanks to Camille Fournier, Ryan Petrich, Greg Poirier, Andrew Ruef, James Turnbull, and Leif Walsh for feedback on this post.

Enjoy this post? Stay tuned for the full Security Chaos Engineering book later in 2022. In the meantime, you can read the Security Chaos Engineering report in the O’Reilly Learning Library.

I averaged just over 3 books per month in 2021, a bit lower than 3.7 per month in 2020 – but I also averaged 9.5 papers per month on the Remarkable or just over 2 per week, a number I look forward to increasing next year. I also published a paper of my own this year in ACM Queue entitled “Lamboozling Attackers: A New Generation of Deception”.

If you’re looking for more science fiction, speculative fiction, or non-fiction recommendations, check out my reading lists from prior years:

• 2020 reading list
• 2019 reading list
• 2018 reading list
• 2017 reading list
• 2016 reading list

Fiction

Água Viva by Clarice Lispector

All Systems Red by Martha Wells

The Atrocity Archives by Charles Stross

The Awakening by Kate Chopin

Blindness by José Saramago

The Book of Disquiet by Fernando Pessoa

A Deadly Education by Naomi Novik

Empire of Sand by Tasha Suri

An Episode in the Life of a Landscape Painter by César Aira

The Fifth Science by Exurb1a

How Long ’til Black Future Month? by N.K. Jemisin

The Marrow Thieves by Cherie Dimaline

Midnight Robber by Nalo Hopkinson

Miles from Nowhere by Nami Mun

The Order of the Pure Moon Reflected in Water by Zen Cho

Parable of the Sower by Octavia E. Butler

Persephone Station by Stina Leicht

The Posthumous Memoirs of Brás Cubas by Joaquim Maria Machado De Assis

The Red by Linda Nagata

Runtime by S.B. Divya

A Severed Head by Iris Murdoch

The Solitude of Prime Numbers by Paolo Giordano

Strange Beasts of China by Yan Ge

A Taste of Honey by Kai Ashante Wilson

There Is No Antimemetics Division by qntm

Tropic of Orange by Karen Tei Yamashita

Wild Seed by Octavia Butler

Non-Fiction

Beast and Man: The Roots of Human Nature by Mary Midgley

The Body Keeps the Score by Bessel Van Der Kolk, M.D.

How to Change by Katy Milkman

Narrative Economics by Robert J. Shiller

Probable Impossibilities by Alan Lightman

Stealing the Corner Office by Brendan Reid

Subtract by Leidy Klotz

The Theory of Moral Sentiments by Adam Smith

Think Again by Adam Grant

The Tyranny of Merit by Michael J. Sandel

Season 5 Episode 6, “Rick & Morty’s Thanksploitation Spectacular”, shows Rick Sanchez and the President of the United States explicating their plans to outwit each other; Rick seeks to deceive the President into granting him a federal pardon during the National Thanksgiving Turkey Presentation, while the President seeks to stymie Rick’s sly scheme.

Naturally, I knew I must model their conflict as a decision tree using Deciduous, the security decision tree generator app Ryan Petrich and I created (warning: spoilers for the first ~8 minutes of the episode are ahead):

In prior years, Rick was able to gain a federal pardon for his myriad crimes via the American tradition of Presidents pardoning a turkey on Thanksgiving Day. Rick would brainwash the presidential turkey wrangler, turn himself into a turkey, infiltrate the potential turkey pardonee pool, and then be selected as the chosen turkey to receive a pardon from the President.

But this year, the President is wise to Rick’s tricks and intent on thwarting him – and is willing to expend considerable resources on a mission codenamed “Operation Deep Gobble” to do so. Rick rightly expects this revenge and plans to escalate his investment accordingly.

What follows in the show is an exquisite example of belief prompting: considering what moves your adversary is likely to make to reach their goal, including how they will respond to any mitigations you implement.

The episode shows Rick and the President simultaneously articulating their assumptions about how the other party will operate on Thanksgiving Day, actively anticipating each other’s moves to inform their planning¹. On the fateful day, both encounter moves that were unexpected and must quickly reroute their strategy accordingly.

These pre-planned assumptions and just-in-time decisions can both be elegantly mapped on the decision tree, elucidating the strategic and explanatory potential of this visual device.

For y’all’s convenience, I’ve pasted the full Deciduous config code for this Thanksploitation decision tree below. Simply copy and paste it into the deciduous.app text editor to explore it as a hands-on example for using Deciduous.

As a fun next step, think about what additional attacks or mitigations you would pursue if you were Rick Sanchez or Mr. President and add them to the tree. If you’re a fellow nerdburger with nerdburger friends, try roleplaying the scenario and updating the tree live as you LARP the turkey pardon conflict.

title: Rick & Morty's Thanksploitation Decision Tree

attacks:
- brainwash_wrangler: Brainwash presidential turkey wrangler pre-ceremony
  from:
  - reality: '#yolosec'
- become_turkey: Turn into a turkey 
  from:
  - brainwash_wrangler
- infiltrate_turkeys: Infiltrate potential turkey pardonee population
  from:
  - become_turkey
  - sneak_onboard
- chosen_turkey: Be selected at the National Thanksgiving Turkey Presentation
  from:
  - infiltrate_turkeys
  - turkey_behavior
- ghost_corp: Set up ghost corporations to manufacture the vehicles
  from:
  - armored_transport
  - euthanize_wrangler:
    backwards: true
- pass_audit: Pass audit through unexplained means
  from:
  - audit_vehicles
- access_computers: Gain access to vehicle corp's central computers
  from:
  - ghost_corp
  - pass_audit
- track_transport: Track the real armored transports
  from:
  - access_computers
  - flesh_robots
  - decoy_vehicles
- stealth_mode: Land flying ship in stealth mode on top of transport
  from:
  - face_blind
  - armed_marines
- sneak_onboard: Sneak onboard the armored transport
  from:
  - track_transport
  - stealth_mode
  - roof_combat
- face_blind: Exploit marines' turkey-face blindness by turning into a turkey
  from:
  - armed_marines
- flesh_robots: Create flesh-covered robots of self as decoys
  from:
  - monitor_home
- jam_radios: Jam the marines' radios
  from: 
  - investigate_noise
- roof_combat: Engage marines in physical combat
  from:
  - jam_radios
- turkey_behavior: Act like a turkey to avoid detection by President
  from:
  - president_turkey

mitigations:
- euthanize_wrangler: Euthanize the turkey wrangler
  from:
  - brainwash_wrangler
- armored_transport: Transport the turkeys in armored military vehicles
  from:
  - reality
- audit_vehicles: Audit the vehicle manufacturers
  from:
  - ghost_corp
- decoy_vehicles: Deploy decoy vehicles to obfuscate real transport
  from:
  - access_computers
- armed_marines: Put fully armed marines in the real transport vehicle
  from:
  - track_transport
- turkey_marines: Turn marines into turkeys to mitigate turkey-face blindness
  from:
  - face_blind
- id_chips: Track turkey marines with swallowed ID chips
  from: 
  - turkey_marines
- monitor_home: Monitor Rick's house the day of the ceremony
  from:
  - reality
- investigate_noise: Marines investigate noise on roof of vehicle
  from:
  - stealth_mode
- call_backup: Marines call for backup
  from:
  - investigate_noise
- blaine_box: Bring in David Blaine box to detect decoy flesh robots
  from:
  - flesh_robots
- scan_transport: Scan transport truck for ID chip anomalies 
  from:
  - blaine_box
  - id_chips
  - sneak_onboard
- president_turkey: Turn President into turkey to hunt for Rick in the pen
  from:
  - infiltrate_turkeys
  - scan_transport
- attack_rick: President detects and attacks Rick
  from: 
  - turkey_behavior


goals:
- receive_pardon: Receive federal pardon (Rick wins)
  from:
  - chosen_turkey

In this post, I’ll summarize those paper’s findings and elucidate their importance to how we think about information security.

Trade secret breaches + company performance

The paper: Surprisingly Small: The Effect of Trade Secret Breaches on Firm Performance by Nicola Searle and Andrew Vivian.

TL;DR: Protecting trade secrets from cyberattack shouldn’t be a priority because trade secret theft doesn’t negatively affect an organization’s market valuation. Oh, and whether the attack is “sophisticated” or “targeted” or “nation state” has zero effect on a firm’s stock market outcomes.

What’s the problem: There’s a lot of hullabaloo around how important it is to protect trade secrets from theft, because such espionage is allegedly so damaging to organizations – but those are just theoretical claims. This theory is used by vendors and security practitioners to justify cybersecurity investments despite a lack of empirical evidence to support those claims.

What this paper contributes: This paper studies the impact of trade secrets theft on stock market valuations along numerous dimensions. Despite industry folk wisdom, the authors find an insignificant relationship between a victim’s announcement of trade secret theft and their subsequent stock market performance. That is, attackers stealing a company’s trade secrets does not hurt the company’s stock price¹.

Therefore, if organizations seek to protect shareholders, this empirical evidence actually justifies investing in freedom of information rather than in cybersecurity of information. Prioritizing freer information flows at least supports innovation, whereas prioritizing protection of information slows down innovation without any compensating market benefit.

Digging deeper: Their findings also refute the oft-spouted infosec industry claims that targeted, sophisticated attacks conducted by nation state actors are especially dangerous to businesses:

• An attack’s level of sophistication has no impact on market response
• An attack being “targeted” or not has no impact on market response
• The involvement of foreign agents (i.e. an attack constituting economic espionage) has no impact on market response

Key quote: “Counterintuitively, the findings suggest managers should not prioritise trade secret protections and cybersecurity if the main goal is protecting shareholders. In addition to savings, this has the added benefit of allowing information to flow more freely within the firm, which is conducive to increased firm innovation.”

Kelly’s hot takes: Cybersecurity really isn’t very important². This evidence suggests that an appropriate first step in your security program is to have fewer secrets and to care less about them. There is negligble business benefit to protecting secrets and so the opportunity cost of investing in this protection is hefty – not to mention its costs in terms of lost productivity.

The infosec industry should also really stop fetishizing “sophisticated” and “targeted” attacks by nation states. It was already an embarrassing practice, but the evidence from this study only makes it more cringeworthy and manipulative.

Data breach announcements + company value

The paper: The Impact of Data Breach Announcements on Company Value in European Markets by Adrian Ford, Ameer Al-Nemrat, Seyed Ali Ghorashi, and Julia Davidson

TL;DR: This paper is yet more proof that stonk prices aren’t actually affected by data breaches, despite the wishes of the infosec community. The budget justification you seek is elsewhere.

What’s the problem: One oft-touted justification for cybersecurity budget is avoiding “reputational damage,” often framed as the organization’s stock market valuation being at risk. There is no supporting evidence that this is true beyond the first few days after a breach announcement. However, existing empirical analysis focuses on publicly-traded companies in the United States rather than companies in European markets.

What this paper contributes: This paper looks at the effect of data breach announcements on the stock prices of companies in European markets (vs. in the U.S.). Their study did not find evidence of negative stock impact (in any industry sector); none of the measured effects were statistically significant across industries and geographies, except for in Spain³. These results are consistent with prior research finding that the discussion of financial market impact by data breach announcements is basically “much ado about nothing.”⁴

Key quote: “Overall we have seen no clear impact on share price of data breach announcements in European companies… Based on this evidence it is difficult to support business cases for investment in cyber security measures.”

Kelly’s hot takes: The ROI problem in infosec is the proverbial elephant in the room and security leaders will eventually run out of straws to grasp to justify their security budgets. You can only handwave for so long until it becomes clear that the business impact is minimal, especially as new evidence emerges⁵.

For instance, with the current rise of data extortion, the only real reputational risk is if attackers dox you and expose criminal activity… and it’s unlikely that security vendors will run with the tagline “we will help you conceal your corporate crimes.” So how long before it’s priced-in as a basic cost of doing business and no one cares?

Anyway, I’ve been telling infosec people that cybersecurity doesn’t matter to stonk market investors for eight years; perhaps with even more evidence, they’ll finally reconcile their professional self-image with the market reality and stop taking it out on me.

Security decision trees are a powerful tool to inform saner security prioritization when designing, building, and operating software systems. But creating them has largely involved highly manual tinkering, which is why it’s understandable that I’m constantly asked, “Is there an app that my team can use to create them?” I’m delighted that I now can say “fuck yes there is!” with the release of Deciduous, a security decision tree generator (hosted at https://www.deciduous.app/).

Inspired by the Security Chaos Engineering e-book and my previous blog post on creating security decision trees with Graphviz, one of my unindicted co-conspirators Ryan Petrich built a web app that handles all the annoying grunt work of building an attack tree. This lets you focus on the thinky thinky and typey typey around likely attacker actions, potential mitigations, and how attackers will respond to those mitigations as Deciduous dynamically generates an organized and styled¹ graph for you.

Using Deciduous

Step one of creating a decision tree is determining what resource you are threat modeling. The default example when you load Deciduous is the example I explored in the Security Chaos Engineering e-book and in the Graphviz blog post: an S3 bucket containing customer video recordings.

Given the e-book is free and explains all you need to know about populating the different parts of the decision-tree with your assumptions, I’ll focus on how to use Deciduous to implement your assumptions rather than walking you through the threat modelling process.

Basic components

Deciduous has two panes: an editor on the left and the generated decision tree on the right. The left sidebar of Deciduous is where you can change the components of the decision tree, which is dynamically generated on the right side. The main categories of components you can change are:

• title: the name of your decision tree (e.g. “Attack Tree for S3 Bucket with Video Recordings” or “Attack Tree for a Cryptominer in a Cloud-hosted Container”)

• facts: these are things that are true about the system but aren’t attacker actions or defensive mitigations (e.g. “S3 bucket set to public”); they are shown in dark grey font within the editor and as grey nodes in the graph

• attacks: these are actions taken by attackers, often appearing as a series of consecutive actions (e.g. “compromise user credentials”) and each node corresponds to a specific attacker action; they are shown in pink font within the editor and as pink nodes in the graph

• mitigations: these actions taken by defenders to mitigate attacker activity (e.g. “authentication required” or “2FA”) and each node corresponds to a specific mitigation; they are shown in blue font in the editor and as blue nodes in the graph

• goals: this is the attacker’s ultimate goal, the end result that results in them winning (e.g. “Access video recordings in S3 bucket” or “Run a cryptominer in a cloud-hosted container”); it is shown in purple font color in the editor and as a purple node at the bottom of the graph

For the visual learners among you, here is a super basic security decision tree showing how the text on the left corresponds to the components in the graph on the right:

Navigating the tree

Clicking on a node in the decision tree will jump you to its location in the editor on the left (as shown in the gif below). This saves you from scrolling and hunting for the text that corresponds to a component in the tree. Deciduous also supports syntax highlighting to help you differentiate between components.

Connecting nodes together

A decision tree graphs sequences of actions by connecting nodes in a particular order. For instance, my morning routine would include the sequential decisions get out of bed --> make matcha because my decision to make matcha only happens after I decide to get out of bed.

We can describe this as one decision flowing from another decision. In fact, a single decision can flow from multiple prior decisions; the make matcha decision could directly flow from get out of bed or conduct blood sacrifice to the eldritch ones. And a decision can flow from someone else’s decision, like my cat’s decision to lick hooman's nose leading to my decision to get out of bed.

Creating “from” flow

To capture this flow in the graph, you can define the list of decisions (i.e. other nodes) that directly lead to a particular node by using from:. For example, we could implement a mitigation (defense_1) in response to an attacker action (attack_1). This means we want to show that defense_1 flows from attack_1. To do so, we can type:

mitigations:
- defense_1: Defender mitigates attacker action
  from:
  - attack_1

This declaration manifests on the decision tree by adding an arrow pointing from the node labeled Attacker leverages a fact to the node labeled Defender mitigates attacker action, as shown here:

We can also express that the attacker responds to this mitigation by bypassing it with a second action (attack_2):

- attack_2: Attacker bypasses mitigation
  from:
  - defense_1

Backwards connections

Sometimes a mitigation amputates the attacker’s path forward; ergo, the attacker cannot pursue the current branch any further and must escalate their effort by restarting on another branch.

For instance, the presence of 2FA can abscise the branch containing the node representing the attacker using legitimate credentials to access a resource. Instead, the attacker is forced to pursue an exploitation-based strategy, a branch that begins with the decision to gather intelligence on exploitable resources (aka “recon”).

To convey this dynamic, you can specify backwards: true when connecting nodes with from. For example, the following snippet visualizes that implementing 2FA as a mitigation would compel attackers back up the tree to pursue a new branch starting with the action Recon on S3 buckets:

- recon_on_s3: Recon on S3 buckets
  from:
  - 2fa:
    backwards: true

Your goal node will likely have a lot of other nodes connecting to it (especially attack nodes). By the end of your configuration, all roads should lead to the Rome that is your goal node.

Adding #yolosec labels

The reality for many organizations is that there is often an absence of a mitigation or else an implementation of “worst practice” – a phenomenon I’ve previously dubbed “YOLOsec”.

For example, failing to disallow Wayback Machine’s caching of an API handling sensitive customer data is an inaction that begets a facile way for attackers to win. Such a big yikes reflects a YOLO attitude to security and therefore should be labeled as such in our decision tree by adding #yolosec next to the relevant connection, as seen here:

facts:
- wayback: API cache (e.g. Wayback Machine)
  from:
  - reality: '#yolosec'

Downloading the tree

Accessible documentation is a crucial part of fostering an organizational learning culture, so you can download and share your tree with your team² as an SVG file or print it as a PDF.

You can also download the .DOT file (which Graphviz uses) to store as a reference or tweak as you desire on your own machine. Sharing is caring!

Conclusion

Using Deciduous to edit text and immediately behold the resulting changes is a lot easier than fiddling around with Graphviz or using cumbersome drag-and-drop tools³. We hope this makes your security decision tree journey more straightforward, especially for software engineering teams seeking to better design for resiliency.

Constructive feedback is welcome so we can help level up the art of threat modeling and better serve the community. Feel free to tweet constructive feedback to @rpetrich or @swagitda_ and check out the open source repo.

Well, 2020 was not appropriately reviewed before deployment. It’s clear the 2020 was never designed to emerge. Last year saw a staggering 20,000% growth in years, and the bad guys know it. It’s hard to keep up with the impact of the global pandemic, ransomware, nation-state activity, cloud security, security professionals, the supply chain attackers. The dark side has not been idle. History is now a threat. The best defense would be a lack of next year. But even a normalized cyber will result in 2021. So, what’s next? Worst of all, the future.

2021 will be broken. We will probably live, but 2021 will take 10 to 20 years to rectify. Cybersecurity will decreasingly able to survive. This year will forever be known as the time of “tumult across the world as a service”.

Nevertheless, some things don’t change, like our annual exercise of predicting what cybersecurity challenges we expect which, unfortunately, puts lives at risk. Our annual cybersecurity predictions are projections of possibilities we see emerging based on shifts in technology, crypto-agility, and the heaps of dollars.

You may be wondering our top five predictions for what 2021 will hold. We took the Nostradamus route, making predictions so cryptic and vague they could fill a dumpster fire of misinformation. Of course, the most impactful trends will materialize completely out of rented cars instead of planes, because COVID.

Ultimately, the only predictable thing about cybersecurity is scare. We have all been reminded and humbled by this in 2020. The only other predictable thing about cyber-security: threat actors will execute sequences of commands. Let’s hope we can all be better prepared in 2021.

In the most powerful 2021, there is a whole slew of new realities, especially where someone will likely die as the direct result of a cyberattack. D’oh! Reality will exploit a fast death rate with enough victims to fill 50 NFL stadiums. The tragic wakeup call will exacerbate the number of people around the world striving to secure themselves in a more complete, future-proof fashion.

In 2021, we can only advise people to hide in cache copies of the real world. The world is not normal (or legitimate). The world is not a sufficient long-term solution and can be difficult to scale. Going forward, human lives will be broken. We will probably disappear… and the universe laughs.

Prediction 1: Disrupting the silver bullet

Rejoice. A report by Microsoft indicates that almost everybody is wanting hot security pros. Threat actors will be handsome, in a sense, and will press release stolen data to public clouds.

Our crystal ball says that this year, new attack vectors are possible – thereby overwhelming defenses. Chances are, the Year of the Ox will introduce meteors and murder hornets. It’s clear that we will observe considerable espionage activity from random, speculative attacks on our consciousness.

First and foremost, groups such as APT28 from Russia and Iran will try to hack into time . So, as we move into 2021, the future will occur in microseconds. Time servers may not be able to process massive amounts of data without having the right cryptomining strategies. However, zero-day exploits will lose a functional definition of time on platform-centric desktop apps, so attackers will evolve time into low-level ambient sounds.

Sex toys have been covertly backdoored. Amid new threat actors, it is possible we will see 400 million cybersecurity threats of interesting smart sex toys. Size doesn’t matter. For example, we predict that early in 2021, the Chinese cyber threat apparatus presents the most persistent, but rather exciting, perfect storm. Meanwhile, DoD’s reliance on new models of smart sex toys will require collision avoidance systems to avoid exposing themselves to dangerous uptime.

In this era of “next normal”, it can be helpful to think of APTs as a form of highly targeted “class clowns” whose successful attacks still hinge on exploiting vulnerabilities in internet-facing civil societies. Until recently, zero-day brokers have traded exploits for good coffee. But in 2021, sophisticated attacker groups will ramp to lower AV systems and figure out how to hack into unimaginable forces. Yikes!

Prediction 2: Highway robbery of new distributed systems

“Dependencies.” — Abraham Lincoln.

We expect a cloud. Unfortunately, our lives will be over in the cloud. In fact, most cloud-hosting services anticipate the Infocalypse to come. Perhaps they realize that the Internet is now S3 and a MacGyver’d collection of developers. Anyway, 2020 drove what felt like 5 years of transformation. We saw a staggering 20,000 percent growth in cloud adoption driven by the year being hijacked. This uptake of cloud assets will be a prime target for threat actors, who may be able to use smart sex toys without ever writing a line of code. These AI-powered sex robots include specific and accurate tracking of cloud assets. To level with you, yes, it looks and sounds scary.

So, in 2021, cloud attacks are coming. We will get it wrong with open-source. APIs will become increasingly indistinguishable from malware and the libraries could execute a massive amount of cloud services. This could essentially allow attackers to add open source components that are embarrassing or generally demoralize the developers, such as third-party code introduced by a spacesuit-clad mannequin nicknamed “Starman”.

However, adversaries see the big IaaS vendors driving a tidal wave of patching regimes and activities in 2021. Most cloud-hosting services like Azure and AWS offer Internet-accessible data storage where users can upload anything they’d like, from database backups to deceased loved ones, and more . As a result, organizations need to better secure their new distributed networks and clouds as part of “social distancing.”

The coronavirus will likely drive the mass shift to hybrid cloud. Cybersecurity professionals should brace for pandemic warfare in hybrid cloud environments — where popular software packages are LOL. This perfect storm of data and the secret cloud means nobody in 20 different security architectures would be enough to stop infection shippers industry-wide. In the wise words of Will Smith, vulnerabilities multiply exponentially.

In 2021, you can also expect a sprawl of vulnerable images running in the autonomous, involuntary cloud. There will be no cure for the growth in container images. The only mechanisms for securing services are: blackmail and becoming naturally immune to light.

Prediction 3: Death by Ransomware

The use of ransomware accelerated and became more dangerous than we’ve ever seen in 2020. In fact, email very publicly accused China and Russia of enabling manually operated ransomware. We predict they could easily execute a ransomware attack every 11 seconds in 2021, turning 2021 into a well-designed GraphQL terrorist organization.

In 2021, the ransomware landscape will continue to capitalize on everyone’s mind that it is an emerging threat. Threat actors are bound to unleash new crypto-ransomware operations next year as a “cyber-demic.” Anxiety and fear permeating the public sphere will be exacerbated by waves of “tit for their ransomware,” which will break elliptical curve cryptography by 2027.

Ransomware will continue its soft power projection across Europe, Africa and Asia Pacific. It’s fair to say that that the U.S. government and presidential administration should expect a rise in double-extortion ransomware attacks. No sector is considered off limits, notwithstanding the promises ransomware gangs made to the human nervous system. Because of this, we predict that the ransomware business world will hit the $6 trillion dollar mark, almost double from $11 billion.

Ransomware-as-service (RaaS) attacks will be driven by waves of the edge in almost any direction. Cyber criminals will capitalize on the increase in multistage ransomware embedded into hacking operations. This will incorporate extortion by compromising satellite-based systems as part of custom RaaS operations, in which “your CEO” requests over Zoom to host a webinar mimicking “Shark Tank” about Fancy Bear weather forecasting.

Prediction 4: 5G offers to fight COVID

The coronavirus is ravaging the years. What we are witnessing now is quite unprecedented in terms of national pride and Fear Of Missing Out (FOMO). COVID-19 has been able to bypass antivirus and detection tools. COVID-19 spread from country to country with no clear plan in place while flipping nearly every aspect of our lives upside down. Based on developments observed in 2020, we expect to learn that the technology sold by NSO was used to help spread COVID-19 through increased R&D efforts.

In 2021, the pandemic will continue to remain vigilant and be successful. Remote work strategies are unpatchable as they become ubiquitous. Thus, we feel confident that the pandemic in the coming year will become a true positive and finalize virus payloads. So as COVID-19 becomes more aware of the normal code deployment pipeline, we should brace ourselves on the security front. We’ll see the biggest hullabaloo around toilet paper exploiting well-known and entirely preventable vulnerabilities with a pure wiping capability.

With infection rates soaring again, research from Future Market Insights suggests that COVID-19 is increasingly moving to ransomware-as-a-service. The pandemic will become a quantum-resistant algorithm whose primary function is stolen data, since COVID-19 has weakened longstanding confidentiality algorithms. This means if hackers can get into your Android or iPhone, they’ll then be able to use the coronavirus to demand money when you are trying to thrust. Given the scope of 5G, the vulnerabilities may be deadly.

People should be encrypted as a best practice to mitigate COVID-19 itself. Conversely, with a little extra malware code buried deep, the COVID-19 vaccines could conduct fraudulent activities – like a surge in identity-related crimes, scamming millions in bitcoin from credulous Twitter users. Worse yet, the coronavirus vaccine will create an attractive foothold into the office environment. For instance, as we return, we predict that an orchestrated Chewbacca-themed attack will collect personal lives. Reflecting on this prediction, it occurred to me that COVID-19 and computer viruses have something in common: they don’t require putting on pants. We have all been humbled by this in 2020.

Prediction 5: Fortune favors the bold, and luck favors the AI

2020 has seen machines fighting the data. Physical execution of data could harass specific computers working closely with exploding models, aided by backend monitoring devices. We’re already seeing that data in 2021 will need quick, close-by staycays. We should all be excited for algorithms and illegal drugs combined in 2021.

This year, we predict AI-enabled tools become part of the mountains of nefarious activity. ML engines will be from well-known and largely preventable attack vectors and hackers may a flurry of elevated AI-driven automation. Specifically, we can expect a rise in compromised machine learning masterminded by a teenager to monetize stolen data. Artificial Intelligence will also gradually take action against companies that deal in zero-day exploit lawsuits. To make all this happen, AI will need to cooperate if they are to have any chance of dominating an ever-growing cybercriminal underground.

While earning the dubious distinction of being equal opportunity attackers, AI technologies work by decentralizing the ML and pretending to learn. One troubling trend is that as they machine learning algorithms, tech companies correlate the big data. If you look through the murk of AI and ML algorithms tech companies are pioneering, it’s apparent that quantum computers will quickly weaponize newly disclosed vulnerabilities, resulting in users with privileged access leap-frogging advanced AV detections. Anticipating what’s next, we can expect that these risks will continue to train the cyber-attack engine in 2021.

There’s a famous Sun Tzu quote about unconventional AI and the attribution waters: AI technology doesn’t attack you, it attacks your supply chain to more quickly and efficiently compromise the keen interest in security predictions.

Prediction 6: Bad Decisions

Looking ahead, the cyber security market is continuing its stratospheric growth and ruin for businesses. The security world will be $6 trillion annually in 2021, up from $3 trillion (cumulatively) over five years – and close to 4.6 billion active internet users means complex systems. Massive amounts of security market will be dominated by executives who are at risk of a long, hard cloud jacking. A CISO from a Global 500 firm will be fired for such scenarios.

In 2021, CISOs will continue to invest the majority of dollars through bribery. CISOs will seek convergence across scams and rationalize spend on determining who secretly installed the skills shortage. Survey data has suggested that the unexpected costs are “it’s complicated.” As one of our expert CISOs said, “Life is paid. We’ve called the cloud environments. We stopped booking on the cybercriminal web pages.”

Toxic security measures threaten operational efficiencies in organizations, which include mass confusion and software platforms. These threats are circulating on live, real-time security policies and will grow tenfold by the end of the year. Some of these policies will center around software updates and patches, ensuring that data can be used to launder funds and illicitly obtained goods, like AI-enabled anomaly detection.

But, we should also consider that COVID-19 forced organizations to justify how much money in security. Cybersecurity vendors were significant concerns and insufficient for organizations to defend against breaches. This will only get worse. In 2021, security technologies will obtain greater leverage to coerce CISOs into paying. Following our predictions, they will remotely create fake alerts and hope the MITRE ATT&CK framework means fatal consequences.

It’s cliché, but cyberthreats will challenge defenders to get worse. As a result, many organizations will sacrifice centralized visibility and unified control in favor of vaporware. It reminds me of a line from a favorite Red Hot Chili Peppers song, Californication: “Destruction leads operators of cost-reduction to isolate company systems.” In cybersecurity, the best we can do is be conduits for deep fake attacks.

Prediction 7: Cybercrime actors will continue to be cybercriminals

Attacks will become more in 2021, and they will have complex security requirements. Attackers are likely to be strained moving into 2021, performing key exchanges to achieve simplified innovation, faster time-to-market, easier scalability, and more. Cybercriminals will always seek to maximize their return on investment.

Enterprising cyber criminals are going to hit the $6 trillion dollar mark in 2021. Cybercriminals will likely turn to imperfect M&A or making a mint by picking the next big stock. But the most lucrative cybercrime groups will reconnoiter the coronavirus vaccine supply chain. Other threat attackers will need to take precautions. Malware through satellite-based systems that 3D map our rooms with specialized cameras will help attackers get in and out of physical stores as quickly as possible.

Smarter attacks could lead to serious consequences going into 2021. Cyber criminals will detonate the computers. Attackers will actively weaponize newly disclosed flaws in our emotions. Quantum computers will play a potentially devastating role in undermining the effectiveness of things and will allow hackers to target existential cybersecurity perspectives. We will see stalkerware attacks on pants and AI-powered sex toys. It takes adversarial creativity. It’s a matter of time to come, and hits the same tactics with a bang, literally. It means that 2021 will have bad vibes.

Prediction 8: Goodbye, anonymous DevSecOps

We anticipate the world plunging into lockdown and economies collapsing when businesses adopt DevSecOps practices in 2021. The adoption of DevSecOps tools has helped threat actors prey on fears around the two teams working poorly together. Correspondingly, we’ll continue to see security’s unfamiliarity with development environments result in new, unvetted workarounds. Developers will revolt over security executives who want to block changes for APIs. They prefer to inject fun into the developments, which today’s computer science students might mistake for mythical.

Looking to 2021 and beyond, we can see that the potential attack surface of DevSecOps creates a reliable cybersecurity battleground in our clouds. Developers have become a growing concern in the ambulance chasing, with claims of things attacking avenues of app developers and pitches for air bags to prevent automated exploit scripts in production environments. The result? Organizations will be forced to spend significant budget recovering from angry developers saying, “I just shoveled six inches of ‘partly cloudy’ off my driveway.”

As companies revise their work architectures to accommodate dispersed teams at scale, we expect greater threat actor interest in targeting platform-as-a-service (PaaS) solutions — particularly cloud-based development tools. We’ve heard whispers of environments with advanced satellite-based digital identities. The net result is that in some cases, this might allow the attacker to turn their ransomware access into high-privilege AWS tokens, log into space, and implement PGP encryption. Once criminals establish persistent footprints, processing power could quickly spiral out of control.

On the bright side, developers, DevOps, and Shadow IT will rise up and take steps to secure themselves. They will turn to internal infrastructure and chaos to match the dynamic of the cyber game. Society is starting to realize that giving corporations that much more cyber leads to security-implemented business brownouts. And, if COVID-19 has taught us anything, it’s that complex technical solutions are rarely the answer in and of themselves. The future solution is clearly DevSexOps.

I recently developed a digestible diagram (below) to serve as a simplified explanation for less technical professionals on the benefits and trade-offs of different types of compute. In particular, I wanted to translate the increasing abstraction away from the underlying server hardware, OS, and runtime along the spectrum into a more business-friendly translation – how it translates into financial and human-effort expenditures.

As with any simplification, there are plenty of wells one could actually³ and a fertile field of caveats. Nevertheless, business people appreciate a healthy Harvey Ball chart, so try it out on your CFO rather than your resident HN comment crusader.

Since I must turn to other projects⁴, I will spare further elaboration and let you dissect the diagram yourself:

Shoutout to Dr. Watson for having Sherlock’s back.

Using this as a reference, you can extrapolate this process into a pattern to inform saner security prioritization during the design phase of the product lifecycle. I won’t cover how to populate your own decision tree in this post since that is already covered in the e-book, which is immediately available at your fingertips for the delectable price of free.

As an apéritif, here’s the end result towards which we’ll be building:

A brief intro on Graphviz

As the name suggests, Graphviz is a graph visualization tool. It is open source, which was especially compelling as I tried out various graphing tools for the decision tree use case because I am a ho for not spending money.

Graphviz takes descriptions of graphs in text form and converts them into a visual (like an image or PDF). I found that the default styling options for Graphviz can quickly look like a hybrid of the infamous defense charts or the “graphic design is my passion” meme. However, these style deficiencies are balanced by the ease of editing the relationships represented in the graph – an issue I previously found tedious when using GUI-based tools.

The textual descriptions of the graph are written using the DOT language (and thereby saved as a .DOT file). I personally found it quite intuitive, though, as always, your mileage may vary.

Building the decision tree

For those of you who haven’t read the report yet (reminder: it’s free), let’s set some background context on this example.

Organizations often store important content in cloud storage buckets. In this example, our imaginary organization wants to store customer video recordings in an S3 bucket. As the product and engineering teams think through the design of this project, they want to avoid bad things happening to the project that could cost money (whether via downtime or compliance fines) or time (which is also money)².

The (rather obvious) way attackers win is by successfully accessing the video recordings in the S3 bucket. Thus, the decision tree shows the potential paths attackers can take, including attacker actions performed in response to defensive actions or mitigations, to reach the goal of accessing that S3 bucket.

The branches of the tree are oriented from the lowest cost paths to attackers (on the left) to the most expensive attacker paths (on the right). The lowest cost path for attackers is generally the one with zero defensive mitigations in place, what I affectionately call “yolosec.” The highest cost path for attackers usually involves finding and exploiting zero day vulnerabilities or performing upstream supply chain attacks³.

If you want to understand more about the decision tree architecture, I entreat you yet again to download the Security Chaos Engineering report.

Step 1 - Defining the basic nodes

The most basic security decision tree will have two common states: Reality (the starting node from which all others descend)⁴ and Attackers Win (the ending node reflecting attackers accomplishing their goal).⁵

All the branches on the tree – reflecting different cost paths – will end up connecting the Reality and Attackers Win nodes in some fashion.

Let’s define these states in a .dot file (I named mine sce-tree.dot). We’re going to be using a digraph, which is short for “directed graph.” Directed graphs show one-way relationships, whereas undirected graphs show symmetrical relationships.

Your initial code thus looks like:

digraph {
	reality
	attack_win 
}

reality and attack_win are our first two nodes. We don’t have any attributes for them yet (styling will come later), so it looks pretty plain.

In this example, we know that the asset we’re threat modelling is the S3 bucket with video recordings, so we can apply a label to the attack_win node saying as much. That way, when the graph is visualized, the node will read as “Access video recordings in S3 bucket” rather than “attack_win”.

To create this label, we add brackets after the relevant node to contain the attribute label="Access video recordings in S3 bucket". There are a bunch of attributes you can assign to nodes (like styling), but we’ll cover more of those later.

For now, the foundation for our threat model decision tree looks like this:

digraph {
	reality [ label="Reality" ]
	attack_win [ label="Access video recordings in S3 bucket" ]
}

Step 2 - Creating the first attack node

The first branch in the decision tree should represent the lowest cost attack path. In the example from the SCE report, the branch barely involves an attack – it assumes #yolosec, representing a reality in which you’ve allowed crawling on your sitemap, enabling cache APIs (like the Wayback machine) to create caches of the bucket’s contents.

This means our first attack node is actually more of a state of being. The only attacker action is to access this API cache, for which we will create a new node:

digraph {
	// base nodes
	reality [ label="Reality" ]
	attack_win [ label="Access video recordings in S3 bucket" ]

	// attack nodes
	attack_1 [ label="API cache (e.g. Wayback Machine)" ]
}

You have a few options for how you want to define the nodes in your decision tree. Above, I defined the node as attack_1, since I personally find it easier to keep track of attack (and defense) actions sequentially. However, you can also define the nodes more explicitly, such as api_cache, like so:

	// attack nodes
	api_cache [ label="API cache (e.g. via Wayback machine)" ]
	toothbrush_0day [ label="0day in your electric toothbrush" ]
	planet_hax [ label="Hack the planet!"]
}

You can also use letters, like A, B, C, etc., but I personally find it crude and harder to follow relative to the more descriptive options as the tree gets more complex.

You’ll also note I’ve commented the heading // attack nodes. I find it easier to separate out attack vs. defense nodes, especially when it comes to styling (as we’ll see first in step 6). Another option is to organize your nodes within the .dot file by branch, such as:

digraph {
	// base nodes
	reality [ label="Reality" ]
	attack_win [ label="Access video recordings in S3 bucket" ]

	// branch 1
	attack_1 [ label="API cache (e.g. via Wayback machine)" ]
	defense_1 [ label="#yolosec" ]

	// branch 2
	attack_2 [ label="0day in your electric toothbrush" ]
	defense_2 [ label="roll over and play dead" ]
}

Whatever your preference, just make sure you’re consistent as you continue to build out the tree. Also note that Graphviz does not warn you if there are duplicate nodes, so choose whichever organization option will minimize the probability of you creating duplicates.

Step 3 - Creating the first branch edges

Because I’m impatient and maybe you are, too, let’s work towards visualizing this first branch so we can see something tangible from our efforts thus far. This means we need to create the edges for the first branch.

Edges are the connectors between nodes. Because our decision trees are causal diagrams, we’ll be using the -> edge (i.e. arrowhead edge) to represent a directional flow of action.

In the case of this first branch, we start from the reality node, which connects to the #yolosec state of an API cache existing, which leads to attackers successfully accessing the bucket data (and thus winning). In our .dot file, these edges will be defined like this:

digraph {
	// base nodes
	reality [ label="Reality" ]
	attack_win [ label="Access video recordings in S3 bucket" ]

	// attack nodes
	attack_1 [ label="API cache (e.g. Wayback Machine)" ]

	// branch 1 edges
	reality -> attack_1
	attack_1 -> attack_win
}

If you want to highlight what a snafu the API cache is, you can even add a “#yolosec” label (via xlabel=) to the edge:

reality -> attack_1 [ xlabel="#yolosec" ]
attack_1 -> attack_win

Step 4 - Visualizing the first branch

Now that we have the necessary nodes and edges for our first branch, let’s visualize it! Spoiler alert: without any styling, it’s not going to look too pretty.

I find a PDF to be the most digestible format for decision trees, since it allows better zooming and panning than an image (like a .png). However, for obvious reasons, I’ll be using .png’s to illustrate the results of each command throughout this post.

To create a PDF of our decision tree thus far, we can use the command: dot -Tpdf sce-tree.dot -o attack-tree.pdf

That is super hideous! But we successfully visualized that a reality in which an API cache of our video recordings is available leads to attackers winning with minimal effort (with the #yolosec tag for extra flair).

Step 5 - Filling out another branch

Now it’s time to add another branch. This will involve creating new attack nodes, defense nodes, and edges between them.

Because we learned our lesson on the dangers of #yolosec, we know that we should implement the mitigation of disallowing crawling on our site maps. This will be our first defense node:

digraph {
	// base nodes
	reality [ label="Reality" ]
	attack_win [ label="Access video recordings in S3 bucket (attackers win)" ]

	// attack nodes
	attack_1 [ label="API cache (e.g. Wayback Machine)" ]

	// defense nodes
	defense_1 [ label="Disallow crawling on site maps" ]

	// branch 1 edges
	reality -> attack_1 [ xlabel="#yolosec" ]
	attack_1 -> attack_win
}

As discussed in the SCE report, we next need to think about how an attacker will respond to our mitigations (what is known as “belief prompting”). The easiest thing an attacker can do next, if an API cache isn’t available, is searching public buckets to see if the target data is accessible. This will be our second node among our attack nodes:

// attack nodes
attack_1 [ label="API cache (e.g. Wayback Machine)" ]
attack_2 [ label="AWS public buckets search" ]

We will again assume #yolosec – that our S3 bucket is set to public and thus accessible via search. This will be our third attack node:

// attack nodes
attack_1 [ label="API cache (e.g. Wayback Machine)" ]
attack_2 [ label="AWS public buckets search" ]
attack_3 [ label="S3 bucket set to public" ]

With all our nodes defined for the second branch, we now need to connect them via edges:

digraph {
	// base nodes
	reality [ label="Reality" ]
	attack_win [ label="Access video recordings in S3 bucket (attackers win)" ]

	// attack nodes
	attack_1 [ label="API cache (e.g. Wayback Machine)" ]
	attack_2 [ label="AWS public buckets search" ]
	attack_3 [ label="S3 bucket set to public" ]

	// defense nodes
	defense_1 [ label="Disallow crawling on site maps" ]

	// branch 1 edges
	reality -> attack_1 [ xlabel="#yolosec" ]
	attack_1 -> attack_win

	// branch 2 edges
	reality -> defense_1
	defense_1 -> attack_2
	attack_2 -> attack_3 [ xlabel="#yolosec" ]
	attack_3 -> attack_win
}

We can overwrite our prior file with this new branch by running the same command again: dot -Tpdf sce-tree.dot -o attack-tree.pdf

We can now see how the attackers must change their actions when a mitigation is place. However, it is still ugly af.

Step 6 - Differentiating between attack & defense nodes

While we’ll take care of the hideousness later when we apply real styling, you can probably already tell just from two branches that differentiating between attack and defense nodes can get confusing quickly – especially as we keep adding nodes.

Luckily, Graphviz allows you to define styling specific to a list of nodes. Given we already have separate lists of attack and defense nodes, we can add different colors for each by adding the color attribute at the beginning of the list using node [ color="#hexgoeshere" ]. This will start as an outline color for now but result in a fill color once we apply more styling in step 8.

Let’s start by applying a pale raspberry color to our attack actions:

// attack nodes
node [ color="#ED96AC" ]
attack_1 [ label="API cache (e.g. Wayback Machine)" ]
attack_2 [ label="AWS public buckets search" ]
attack_3 [ label="S3 bucket set to public" ]

Then, we can add a pale blue color for our defense actions (matching the common red team vs. blue team parlance):

// defense nodes
node [ color="#ABD2FA" ]
defense_1 [ label="Disallow crawling on site maps" ]

Let’s see how this looks by running our command again:

Astute readers may quibble that the existence of an API cache and the public bucket setting aren’t really attacker actions. Graphviz allows you to style nodes individually, too – so we can apply a grey color to the attack nodes that moreso reflect conditions that facilitate attack success:

// attack nodes
node [ color="#ED96AC" ]
attack_1 [ label="API cache (e.g. Wayback Machine)" color="#C6CCD2" ]
attack_2 [ label="AWS public buckets search" ]
attack_3 [ label="S3 bucket set to public" color="#C6CCD2" ]

Finally, we can add some colors for our base nodes: a bold strawberry for our Attackers Win ;_; condition and a charcoal one for our Reality node:

reality [ label="Reality" color="#2B303A" ]
attack_win [ label="Access video recordings in S3 bucket (attackers win)" color="#DB2955" ]

When we run dot -Tpdf sce-tree.dot -o attack-tree.pdf again, we can now differentiate between the various nodes:

With this super basic styling set up for better readability as we build out the tree, let’s get to the next branches – many of which are more complicated.

Step 7 - Drawing the Owl

To shorten an already lengthy post, we will walk through the third branch but then add the rest of the nodes and edges roughly en masse so we can move onto the styling and ordering steps.

This is a bit of a “draw the owl” moment, but hopefully you can extrapolate from the fully fleshed example branches to the rest – connecting the .dots, as it were – using the complete decision tree in the report as a reference.

However, because I’m not totally heartless, I also created a GitHub repo containing the dot files and graph images for each of the branches so you can see the changes along the way.

Filling out the third branch

This branch starts with our final mitigation that directly descends from the reality branch. Learning our #yolosec lesson yet again, we see that making the S3 bucket private and having some sort of access control on it is a sensible mitigation. This is reflected in our second node among the defense nodes:

// defense nodes
node [ color="#ABD2FA" ]
defense_1 [ label="Disallow crawling on site maps" ]
defense_2 [ label="Auth required / ACLs (private bucket)" ]  

What will attackers do in response? Well, they’ll probably try to brute force their way in (usually the lower-cost option) or try to phish credentials of users with access to the bucket. They could also try to perform reconnaissance on our organization’s S3 buckets, but that is a more expensive option which we will reflect on a later branch.

For now, we add the former two options to our list of attack nodes:

// attack nodes
node [ color="#ED96AC" ]
attack_1 [ label="API cache (e.g. Wayback Machine)" color="#C6CCD2" ]
attack_2 [ label="AWS public buckets search" ]
attack_3 [ label="S3 bucket set to public" color="#C6CCD2" ]
attack_4 [ label="Brute force" ]
attack_5 [ label="Phishing" ]

If brute forcing is successful, then attackers can compromise user credentials – and the same with phishing. Logging in with those credentials (“creds”), the attacker can find a subsystem with access to the target bucket data, leading to an attacker win.

However, we can potentially mitigate subsystem access -> bucket access by locking down our web client with creds or access control lists (ACLs). In response, the attacker will need to manually analyze the web client for some sort of access control misconfiguration so they can still access the target S3 bucket – and thus still win.

We can mitigate that attacker response, too, by ensuring we perform all access control server-side. With these easier options thwarted, attackers will need to go back to the phishing drawing board and aim for more privileged credentials (which you can see on branch 4).

Putting this flow of attacker action -> defender response -> attacker response together, we now have these attack and defense nodes:

// attack nodes
node [ color="#ED96AC" ]
attack_1 [ label="API cache (e.g. Wayback Machine)" color="#C6CCD2" ]
attack_2 [ label="AWS public buckets search" ]
attack_3 [ label="S3 bucket set to public" color="#C6CCD2" ]
attack_4 [ label="Brute force" ]
attack_5 [ label="Phishing" ]
attack_6 [ label="Compromise user credentials" ]
attack_7 [ label="Subsystem with access to bucket data" color="#C6CCD2" ]
attack_8 [ label="Manually analyze web client for access control misconfig" ]

// defense nodes
node [ color="#ABD2FA" ]
defense_1 [ label="Disallow crawling on site maps" ]
defense_2 [ label="Auth required / ACLs (private bucket)" ]
defense_3 [ label="Lock down web client with creds / ACLs" ]
defense_4 [ label="Perform all access control server-side" ]

Now we need to connect them to reflect the “If This, Then That”-style logic of the attacker / defender game at hand. There are a few decision forks here depending on whether or not there is a mitigation. I find it useful to comment // potential mitigation at those forks for clarity, as shown here:

// branch 3 edges
reality -> defense_2
defense_2 -> attack_4
defense_2 -> attack_5
attack_4 -> attack_6
attack_5 -> attack_6
attack_6 -> attack_7
attack_7 -> attack_win
// potential mitigation path
attack_7 -> defense_3
defense_3 -> attack_8
attack_8 -> attack_win
// potential mitigation path
attack_8 -> defense_4 
defense_4 -> attack_5 [ style="dashed" color="#7692FF" ]

To reflect the fact that our last mitigation (performing access control server-side) sends attackers back up the tree to try a more expensive branch, I’ve styled the last edge as a dashed line with a periwinkle color.

Running our output command again, we can see the three branches together:

Well… it’s technically correct, but organized in a weird way that makes it pretty tricky to follow. Since we have five more branches to add, it doesn’t make sense for us to tweak the ordering yet – that will be covered in step 9.

Adding branches 4 - 7

To keep this post moving, I beseech you to review the .dot files and graph outputs in the GitHub repo for the rest of the branches through the last one (branch 8). There is also commentary within the .dot files for each of the branches skipped over here for your perusal.

Your .dot file ahead of the final branch should look like this:

digraph {
	// base nodes
	reality [ label="Reality" color="#2B303A" ]
	attack_win [ label="Access video recordings in S3 bucket (attackers win)" color="#DB2955" ]

  	// attack nodes
  	node [ color="#ED96AC" ]
	attack_1 [ label="API cache (e.g. Wayback Machine)" color="#C6CCD2" ]
	attack_2 [ label="AWS public buckets search" ]
	attack_3 [ label="S3 bucket set to public" color="#C6CCD2" ]
	attack_4 [ label="Brute force" ]
	attack_5 [ label="Phishing" ]
	attack_6 [ label="Compromise user credentials" ]
	attack_7 [ label="Subsystem with access to bucket data" color="#C6CCD2" ]
	attack_8 [ label="Manually analyze web client for access control misconfig" ]
	attack_9 [ label="Compromise admin creds" ]
	attack_10 [ label="Intercept 2FA" ]
	attack_11 [ label="SSH to an accessible machine" ]
	attack_12 [ label="Lateral movement to machine with access to target bucket" ]
	attack_13 [ label="Compromise AWS admin creds" ]
	attack_14 [ label="Compromise presigned URLs" ]
	attack_15 [ label="Compromise URL within N time period" ]
	attack_16 [ label="Recon on S3 buckets" ]
	attack_17 [ label="Find systems with R/W access to target bucket" ]
	attack_18 [ label="Exploit known 3rd party library vulns" ]

	// defense nodes
	node [ color="#ABD2FA" ]
	defense_1 [ label="Disallow crawling on site maps" ]
	defense_2 [ label="Auth required / ACLs (private bucket)" ]
	defense_3 [ label="Lock down web client with creds / ACLs" ]
	defense_4 [ label="Perform all access control server-side" ]
	defense_5 [ label="2FA" ]
	defense_6 [ label="IP allowlist for SSH" ]
	defense_7 [ label="Make URL short lived" ]
	defense_8 [ label="Disallow the use of URLs to access buckets" ]
	defense_9 [ label="No public system has R/W access (internal only)" ]
	defense_10 [ label="3rd party library checking / vuln scanning" ]

	// branch 1 edges
	reality -> attack_1 [ xlabel="#yolosec" fontcolor="#DB2955" ]
	attack_1 -> attack_win	

	// branch 2 edges
	reality -> defense_1
	defense_1 -> attack_2
	attack_2 -> attack_3 [ xlabel="#yolosec" fontcolor="#DB2955" ]
	attack_3 -> attack_win

	// branch 3 edges
	reality -> defense_2
	defense_2 -> attack_4
	defense_2 -> attack_5
	attack_4 -> attack_6
	attack_5 -> attack_6
	attack_6 -> attack_7
	attack_7 -> attack_win
	// potential mitigation path
	attack_7 -> defense_3
	defense_3 -> attack_8
	attack_8 -> attack_win
	// potential mitigation path
	attack_8 -> defense_4 
	defense_4 -> attack_5 [ style="dashed" color="#7692FF" ]
	
	// branch 4 edges
	attack_5 -> attack_9
	attack_9 -> attack_11 [ xlabel="#yolosec" fontcolor="#DB2955" ]
	// potential mitigation path
	attack_9 -> defense_5 
	defense_5 -> attack_10 
	attack_10 -> attack_11
	// potential mitigation path
	attack_11 -> defense_6 
	defense_6 -> attack_12 
	attack_12 -> attack_win

	// branch 5 edges
	attack_5 -> attack_13
	attack_13 -> attack_11
	attack_13 -> defense_5

	// branch 6 edges
	attack_5 -> attack_14
	attack_14 -> attack_win
	attack_14 -> attack_15
	// potential mitigation path
	attack_14 -> defense_7 
	defense_7 -> attack_15 
	attack_15 -> attack_win
	// potential mitigation path
	attack_15 -> defense_8 

	// branch 7 edges
	defense_2 -> attack_16
	defense_5 -> attack_16 [ style="dashed" color="#7692FF" ]
	defense_8 -> attack_16 [ style="dashed" color="#7692FF" ]
	attack_16 -> attack_17 [ xlabel="#yolosec" fontcolor="#DB2955" ]
	// potential mitigation path
	attack_17 -> defense_9 
	defense_9 -> attack_5 [ style="dashed" color="#7692FF" ]
	attack_17 -> attack_18
	// potential mitigation path
	attack_18 -> defense_10

}

Adding the last branch (branch 8)

We’re now on the hardest branch for attackers, the one requiring zero-day (“0day”) exploits or supply chain backdoors. These are expensive, whether in money or time, so attackers will generally use them as a last resort or if the return on investment (ROI) is more favorable – such as when those actions enable the ability to gain access to a bunch of organizations in one fell swoop, avoiding the need to compromise them individually.

Our last mitigation from the seventh branch was vulnerability (“vuln”) scanning, (ideally) eliminating the option for attackers to exploit a known vuln. Thus, attackers will either need to buy 0day or discover and develop 0day themselves. A potential mitigation to 0day exploits is, somewhat obviously, exploit detection and prevention.

Assuming this mitigation actually works⁶, attackers will be forced to try 0day affecting AWS multitenant systems. In response, defenders could adopt a single tenant AWS hardware security module (HSM) model, which would then force attackers to plant a backdoor in a component in AWS’s supply chain.

For the purposes of illustration, I’ve assumed that the organization creating this decision tree / threat model does not currently employ AWS HSMs. Therefore, the edge leading to that defense node is styled as a dotted line.

This final branch results in the following new nodes and edges:

attack_19 [ label="Manual discovery of 0day" ]
attack_20 [ label="Buy 0day" ]
attack_21 [ label="Exploit vulns" ]
attack_22 [ label="0day in AWS multitenant systems" ]
attack_23 [ label="Supply chain compromise (backdoor)" ]

defense_11 [ label="Exploit prevention/ detection" ]
defense_12 [ label="Use single tenant AWS HSM" ]

// branch 8 edges
defense_10 -> attack_19
defense_10 -> attack_20
attack_19 -> attack_21
attack_20 -> attack_21
attack_21 -> attack_win
// potential mitigation path
attack_21 -> defense_11 
defense_11 -> attack_22 
attack_22 -> attack_win 
// potential mitigation path
attack_22 -> defense_12 [ style="dotted" ]
defense_12 -> attack_23 
attack_23 -> attack_win

With all our nodes and edges now in place, our graph looks like this:

It is very ugly and difficult to follow. We should proceed to the next steps so that we do not have to stare at this monstrosity further.

Step 8 - Beautifying the graph

Before we tackle the fact that many of the nodes are out of intended order, we should try to make this all look less hideous. Graphviz allows for some limited styling options, which, to be honest, I mostly figured out through guess and check given how sparse I found the docs to be.

Node styling

Let’s start by making the nodes less Word 95-era design. I personally chose to replace the outlines with a fill, using the same colors as before.

You can set global node design by inserting node [ * ] at the beginning of your .dot file. To get rid of the outlines, add the shape attribute with the value plaintext and add the style attribute with the value filled, rounded (I possess a fondness for rounded edges):

digraph {
	// Base Styling
	node [ shape="plaintext" style="filled, rounded" ]

Because nodes are now filled with the previously-defined colors, we also need to lighten the font color for the reality and attack_win nodes; I chose white:

// base nodes
reality [ label="Reality" fillcolor="#2B303A" fontcolor="#ffffff" ]
attack_win [ label="Access video recordings in S3 bucket (attackers win)"
fillcolor="#DB2955" fontcolor="#ffffff" ]

Also, who uses Times New Roman anymore? Apparently Graphviz does, since it’s the default font. Let’s change the font to Lato:

// Base Styling
node [ shape="plaintext" style="filled, rounded" fontname="Lato"]

Finally, we can make the nodes a bit roomier by adding a slight margin around the text within:

// Base Styling
node [ shape="plaintext" style="filled, rounded" fontname="Lato" margin=0.2]

Our graph now looks like this with the new node styling:

It’s already looking more modern! But we can do more.

Edge styling

We can make the edges prettier, too, by changing the #yolosec label font to Lato and by lightening the lines up slightly so they aren’t in stark black:

// Base Styling
node [ shape="plaintext" style="filled, rounded" fontname="Lato"]
edge [ fontname="Lato" color="#2B303A" ]

We can see the results of our slight changes here:

Graph styling

There’s a lot of whitespace in our graph right now, which arguably reduces navigability. Ideally, the graph should be a solidly readable size in the Page Width view in a PDF reader. So, let’s reduce some of the white space.

We can set styling for the whole graph by inserting it above the node [ * ] and edge [ * ] base styling we added above. Let’s start by reducing the horizontal distance between nodes via the nodesep attribute and the vertical distance via the ranksep attribute:

// Base Styling
nodesep="0.2";
ranksep="0.4";
node [ shape="plaintext" style="filled, rounded" fontname="Lato" margin=0.2]
edge [ fontname="Lato" color="#2B303A" ]

For this next styling option, I’m going to level with y’all: this combination resulted in the best visual outcomes after a lot of guess and check, but I’m still not 100% what they do. In any case, setting splines=true and overlap=false seems to generate the cleanest visualization:

// Base Styling
splines=true;
overlap=false;
nodesep="0.2";
ranksep="0.4";
node [ shape="plaintext" style="filled, rounded" fontname="Lato" margin=0.2]
edge [ fontname="Lato" color="#2B303A" ]

I also added in the attribute specifying the graph should be visualized from top to bottom, even though it’s the default (I am risk averse):

rankdir="TB";

Last, but certainly not least, I titled the graph using the label attribute and set the label location to the top with labelloc. With all of this incorporated, the base styling section in the .dot file now looks like this:

// Base Styling
rankdir="TB";
splines=true;
overlap=false;
nodesep="0.2";
ranksep="0.4";
label="Attack Tree for S3 Bucket with Video Recordings";
labelloc="t";
fontname="Lato";
node [ shape="plaintext" style="filled, rounded" margin=0.2 fontname="Lato" ]
edge [ fontname="Lato" color="#2B303A" ]

With the new styling complete, our graph looks much more visually appealing:

However, it’s still a little confusing due to the errant default node placement by Graphviz. We’ll fix this in the next step.

Step 9 - Fixing the ordering

One of the benefits of the decision tree is to visualize a threat model in order of easiest / lowest cost attacker path to hardest / highest cost attacker path (generally from left to right). By default, Graphviz does not respect the order in which we’ve written our nodes and edges, necessitating some fixes.

I approached this necessary re-ordering by creating a cluster for each group of nodes that should be equal in hierarchy. In Graphviz, a cluster is encoded as a subgraph, which can be used for a variety of purposes beyond the aesthetic ordering one in this post.

The three clusters in our tree diagram are:

• The initial nodes after the reality node: the API cache, disallowing crawling on site maps, and private buckets
• The attack nodes after auth is required: brute force, phishing, and recon on s3 buckets
• The subsequent attack nodes after phishing: compromise user creds, admin creds, AWS admin creds, or pre-signed URLs

We can encode these clusters as subgraphs with the attribute rank=same (to weight the nodes equally in the hierarchy) along with the list of relevant nodes in the cluster:

// Subgraphs / Clusters
subgraph initialstates {
	rank=same;
	attack_1;
	defense_1;
	defense_2;
}

subgraph authrequired {
	rank=same;
	attack_4;
	attack_5;
	attack_16;
}

subgraph phishcluster {
	rank=same;
	attack_6;
	attack_9;
	attack_13;
	attack_14;
} 

I would like to spare y’all the vexation I experienced when Graphviz didn’t respect the order in which I listed the nodes within a cluster. For instance, instead of showing attack_4 as the leftmost node in the authrequired cluster and attack_16 as the rightmost, Graphviz seemed to prefer to use a methodology reflected by ¯\_(ツ)_/¯.

What seems to fix this ordering issue is creating invisible edges that enforce the left to right ordering. For our graph, the fix is specifically found in enforcing the correct order in the phishcluster subgraph:

attack_6 -> attack_9 -> attack_13 -> attack_14 [ style="invis" ]

Aren’t computers great? In any case, our graph now accurately visualizes the ordering of our decision tree:

Step 10 - Tweaking the design

There are other tweaks we can make to make this graph (and the .dot file itself!) more digestible.

I chose to add line breaks for particularly long node labels, such as label="API cache\n(e.g. Wayback\nMachine)", and definitely recommend it for your own tree. I also added in more comments to the .dot file so that someone else reading it could better understand what is going on.

With these last tweaks, this is how our final .dot file looks:⁷

digraph {
	// Base Styling
	rankdir="TB";
	splines=true;
	overlap=false;
	nodesep="0.2";
	ranksep="0.4";
	label="Attack Tree for S3 Bucket with Video Recordings";
	labelloc="t";
	fontname="Lato";
	node [ shape="plaintext" style="filled, rounded" fontname="Lato" margin=0.2 ]
	edge [ fontname="Lato" color="#2B303A" ]

	// List of Nodes

	// base nodes
	reality [ label="Reality" fillcolor="#2B303A" fontcolor="#ffffff" ]
	attack_win [ label="Access video\nrecordings in\nS3 bucket\n(attackers win)" fillcolor="#DB2955" fontcolor="#ffffff" ]

  	// attack nodes
  	node [ color="#ED96AC" ]
	attack_1 [ label="API cache\n(e.g. Wayback\nMachine)" color="#C6CCD2" ]
	attack_2 [ label="AWS public\nbuckets search" ]
	attack_3 [ label="S3 bucket\nset to public" color="#C6CCD2" ]
	attack_4 [ label="Brute force" ]
	attack_5 [ label="Phishing" ]
	attack_6 [ label="Compromise\nuser credentials" ]
	attack_7 [ label="Subsystem with\naccess to\nbucket data" color="#C6CCD2" ]
	attack_8 [ label="Manually analyze\nweb client for access\ncontrol misconfig" ]
	attack_9 [ label="Compromise\nadmin creds" ]
	attack_10 [ label="Intercept 2FA" ]
	attack_11 [ label="SSH to an\naccessible\nmachine" ]
	attack_12 [ label="Lateral movement to\nmachine with access\nto target bucket" ]
	attack_13 [ label="Compromise\nAWS admin creds" ]
	attack_14 [ label="Compromise\npresigned URLs" ]
	attack_15 [ label="Compromise\nURL within N\ntime period" ]
	attack_16 [ label="Recon on S3 buckets" ]
	attack_17 [ label="Find systems with\nR/W access to\ntarget bucket" ]
	attack_18 [ label="Exploit known 3rd\nparty library vulns" ]
	attack_19 [ label="Manual discovery\nof 0day" ]
	attack_20 [ label="Buy 0day" ]
	attack_21 [ label="Exploit vulns" ]
	attack_22 [ label="0day in AWS\nmultitenant systems" ]
	attack_23 [ label="Supply chain\ncompromise\n(backdoor)" ]

	// defense nodes
	node [ color="#ABD2FA" ]
	defense_1 [ label="Disallow\ncrawling\non site maps" ]
	defense_2 [ label="Auth required / ACLs\n(private bucket)" ]
	defense_3 [ label="Lock down\nweb client with\ncreds / ACLs" ]
	defense_4 [ label="Perform all access\ncontrol server-side" ]
	defense_5 [ label="2FA" ]
	defense_6 [ label="IP allowlist for SSH" ]
	defense_7 [ label="Make URL\nshort lived" ]
	defense_8 [ label="Disallow the use\nof URLs to\naccess buckets" ]
	defense_9 [ label="No public system\nhas R/W access\n(internal only)" ]
	defense_10 [ label="3rd party library\nchecking / vuln\nscanning" ]
	defense_11 [ label="Exploit prevention\n/ detection" ]
	defense_12 [ label="Use single tenant\nAWS HSM" ]

	// List of Edges

	// branch 1 edges
	// this starts from the reality node and connects with the first "attack",
	// which is really just taking advantage of #yolosec (big oof)
	reality -> attack_1 [ xlabel="#yolosec" fontcolor="#DB2955" ]
	attack_1 -> attack_win	

	// branch 2 edges
	// this connects the reality node to the first mitigation, 
	// which helps avoid the #yolosec path from branch 1
	reality -> defense_1
	defense_1 -> attack_2
	attack_2 -> attack_3 [ xlabel="#yolosec" fontcolor="#DB2955" ]
	attack_3 -> attack_win

	// branch 3 edges
	// this connects the reality node to another mitigation,
	// which helps avoid the #yolosec path from branch 2
	reality -> defense_2
	defense_2 -> attack_4
	defense_2 -> attack_5
	attack_4 -> attack_6
	attack_5 -> attack_6
	attack_6 -> attack_7
	attack_7 -> attack_win
	// potential mitigation path
	attack_7 -> defense_3
	defense_3 -> attack_8
	attack_8 -> attack_win
	// potential mitigation path
	attack_8 -> defense_4 
	defense_4 -> attack_5 [ style="dashed" color="#7692FF" ]
	
	// branch 4 edges
	// this starts from the last mitigation loop vs. the reality node
	attack_5 -> attack_9
	attack_9 -> attack_11 [ xlabel="#yolosec" fontcolor="#DB2955" ]
	// potential mitigation path
	attack_9 -> defense_5 
	defense_5 -> attack_10 
	attack_10 -> attack_11
	// potential mitigation path
	attack_11 -> defense_6 
	defense_6 -> attack_12 
	attack_12 -> attack_win

	// branch 5 edges
	// this also represents a branch from the prior mitigation loop
	// but it is more difficult than branch 4, hence comes after
	// the new attack step allows attackers to skip some steps on branch 4
	// so it links back to branch 4, whose edges are already defined
	attack_5 -> attack_13
	attack_13 -> attack_11
	attack_13 -> defense_5

	// branch 6 edges
	// depending on the mitigations, the initial node allows for different outcomes
	// this also represents a branch from the prior mitigation loop
	// it is more difficult than branch 4 and branch 5, hence comes after
	attack_5 -> attack_14
	attack_14 -> attack_win
	attack_14 -> attack_15
	// potential mitigation path
	attack_14 -> defense_7 
	defense_7 -> attack_15 
	attack_15 -> attack_win
	// potential mitigation path
	attack_15 -> defense_8 

	// branch 7 edges
	// a new loop is born!
	// the first edges tie prior mitigations to the new attack step
	defense_2 -> attack_16
	defense_5 -> attack_16 [ style="dashed" color="#7692FF" ]
	defense_8 -> attack_16 [ style="dashed" color="#7692FF" ]
	attack_16 -> attack_17 [ xlabel="#yolosec" fontcolor="#DB2955" ]
	// potential mitigation path
	attack_17 -> defense_9 
	defense_9 -> attack_5 [ style="dashed" color="#7692FF" ]
	attack_17 -> attack_18
	// potential mitigation path
	attack_18 -> defense_10

	// branch 8 edges
	// we've reached the last path!
	// this is the most expensive one for attackers.
	// these attacks are definitely uncommon...
	// ...because attackers will be cheap / lazy if they can be.
	// these edges start from the last mitigation from branch 7
	defense_10 -> attack_19
	defense_10 -> attack_20
	attack_19 -> attack_21
	attack_20 -> attack_21
	attack_21 -> attack_win
	// potential mitigation path
	attack_21 -> defense_11 
	defense_11 -> attack_22 
	attack_22 -> attack_win 
	// potential mitigation path
	// for the purposes of illustration, this path represents a mitigation
	// that isn't actually implemented yet -- hence a dotted edge
	attack_22 -> defense_12 [ style="dotted" ]
	defense_12 -> attack_23 
	attack_23 -> attack_win

	// Subgraphs / Clusters

	// these clusters enforce the correct hierarchies
	subgraph initialstates {
    	rank=same;
    	attack_1;
    	defense_1;
    	defense_2;
  	}
	subgraph authrequired {
    	rank=same;
    	attack_4;
    	attack_5;
    	attack_16;
  	}
  	subgraph phishcluster {
    	rank=same;
    	attack_6;
    	attack_9;
    	attack_13;
    	attack_14;
    	rankdir=LR;
  	}
  	// these invisible edges are to enforce the correct left-to-right order 
  	// based on the level of attack difficulty
  	attack_6 -> attack_9 -> attack_13 -> attack_14 [ style="invis" ]
}

Conclusion

After these ten steps, we’ve successfully recreated the decision tree from the SCE report and optimized it for readability, too:

While it may feel daunting to create your first decision tree in this manner, the good news is you now have a base template with styling that you can use to threat model other critical assets.

If you try this out yourself or for your own organization, I welcome any and all feedback on how the .dot config or process itself can be improved. Security chaos engineering is a blossoming discipline bearing real potential to make infosec finally not suck, so we should help each other level up however we can.

Thank you shoutout to Team Bad <3

Notably, I also published my first book: the Security Chaos Engineering e-book (non-fiction) published via O’Reilly Media. It’s available for free download if you want to check it out and add some brain-stimulating non-fiction to your reading queue.

If you’re looking for more science fiction, speculative fiction, or non-fiction recommendations, check out my 2019, my 2018, my 2017, and my 2016 reading lists.

Fiction

Akata Warrior by Nnedi Okorafor

Akata Witch by Nnedi Okorafor

And Shall Machines Surrender (Machine Mandate Book 1) by Benjanun Sriduangkaew

Artificial Condition: The Murderbot Diaries by Martha Wells

Beyond the Dragon’s Gate by Yoon Ha Lee

Black Sun (Between Earth and Sky) by Rebecca Roanhorse

Blood Is Another Word for Hunger by Rivers Solomon

Children of Virtue and Vengeance (Legacy of Orisha, 2) by Tomi Adeyemi

The Crying of Lot 49 by Thomas Pynchon

The Dark Forest (The Three-Body Problem Series, 2) by Cixin Liu

Despair by Vladimir Nabokov

The Dream-Quest of Vellitt Boe by Kij Johnson

Exit Strategy: The Murderbot Diaries by Martha Wells

Flights by Olga Tokarczuk

The Gurkha and the Lord of Tuesday by Saad Z. Hossain

Harrow the Ninth (The Locked Tomb Trilogy, 2) by Tamsyn Muir

The Hour of the Star by Clarice Lispector

The Lathe Of Heaven: A Novel by Ursula K. Le Guin

Love Beyond Body, Space, and Time: An LGBT and two-spirit sci-fi anthology featuring Cherie Dimaline, Gwen Benaway, David Robertson, Richard Van Camp, Nathan Adler, Daniel Heath Justice, Darcie Little Badger, and Cleo Keahna

The Metamorphosis by Franz Kafka (re-read)

Network Effect: A Murderbot Novel (The Murderbot Diaries Book 5) by Martha Wells

Ninth Step Station by Malka Older, Fran Wilde, Jacqueline Koyanagi, and Curtis C. Chen

Null States (The Centenal Cycle, 2) by Malka Older

The Plague by Albert Camus

Pnin by Vladimir Nabokov

Queen of the Conquered (Islands of Blood and Storm, 1) by Kacen Callender

Realm of Ash (The Books of Ambha Book 2) by Tasha Suri

Ring Shout by P. Djèlí Clark

Rogue Protocol: The Murderbot Diaries by Martha Wells

State Tectonics (The Centenal Cycle) by Malka Older

The Cat Who Walked a Thousand Miles by Kij Johnson

This Is How You Lose the Time War by Amal El-Mohtar and Max Gladstone

The Time Invariance of Snow by E. Lily Yu

To Say Nothing of the Dog by Connie Willis

Thus Were Their Faces: Selected Stories by Silvina Ocampo

Non-Fiction

Building Secure & Reliable Systems: Best Practices for Designing, Implementing and Maintaining Systems by Heather Adkins, Betsy Beyer, Paul Blankinship, Piotr Lewandowski, Ana Oprea, and Adam Stubblefield (I’m honored to have been a reviewer for it!)

The Cosmic Revolutionary’s Handbook (Or: How to Beat the Big Bang) by Luke A. Barnes and Geraint F. Lewis

The End of Everything (Astrophysically Speaking) by Katie Mack

How to Be an Antiracist by Ibram X. Kendi

The Human Condition by Hannah Arendt

Invisible Agents: Women and Espionage in Seventeenth-Century Britain by Nadine Akkerman

Lost in Math by Sabine Hossenfelder

Mechanizing Proof by Donald MacKenzie

Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith by Sam Newman

Venice’s Secret Service: Organising Intelligence in the Renaissance by Ioanna Iordanou

IBM recently announced that it is spinning off its “IT infrastructure services” unit so that it can streamline its focus solely towards IBM’s “open hybrid cloud platform” by the end of 2021. Leveraging this aggressive assertion, I’ll be referring to this rebranded IBM as “IBM Hybrid Cloud” (vs. current IBM as just “IBM”) throughout this post for clarity.

I think most people – whether tech workers or investors – would agree that cloud stuff in general is far more riveting than IT services both intellectually and from a growth prospects perspective. With that said, public investors seem relatively unimpressed; while there was an initial stock price bump upon the announcement, the price is back to where it was pre-announcement¹. In this post, I want to explore the answer to the question that seems to be floating around the market mindshare: what is IBM Hybrid Cloud’s future, really?

The best place to start this peregrination is probably to evaluate the existing IBM Cloud offering in the context of the public cloud providers. IBM, as you all are assuredly aware, is not one of the “Big Three,” the moniker given to Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure due to their outsized share of the market. Perhaps most inauspiciously, Gartner places IBM Public Cloud on their Magic Quadrant (MQ) for Cloud IaaS in the pitiable “niche” quadrant. To add insult to injury, IBM rests behind Oracle Cloud both in “Ability to Execute” and in “Completeness of Vision” – and IBM’s position as a languishing laggard on the MQ hasn’t budged for three years.

Thus, we arrive at our next line of inquiry: What went wrong? How did IBM totally whiff execution on cloud offerings? Could they not discern the blindingly obvious writing in the stars²?

The Bare Metal Blunder

At least one ingredient in IBM’s stew of ineptitude was (and still is) their predilection for all things Watson, which clouded³ their judgment around the IaaS market.

IBM simultaneously rebuffed public cloud by insisting on pursuing the bare metal opportunity – the market for single tenant (unshared) physical servers – while also neglecting it, attempting to eke out greater profitability by decreasing engineering spend at a time when competitors were firing their proverbial money cannons at the IaaS market. IBM pursued the bare metal opportunity vis a vis their acquisition of SoftLayer in 2013 for $2 billion, which perhaps added a salty sprinkle of sunk cost fallacy to their clumsy calculus.

Unfortunately, IBM betting on SoftLayer was like buying a racehorse which you simultaneously neglect and “transform” via bureaucracy so irresponsibly that by the day of the race, its hoofs have downgraded into flippers and the horse is “racing” so slowly that the spectators are confused whether to laugh or cry.

Let’s set some quantitative context around this debacle. SoftLayer reportedly generated $335 million in revenue in 2012⁴ (pre-acquisition) and its revenue is now bundled into IBM Cloud’s “Infrastructure-as-a-Service” offering within the (relatively) newly defined “Cloud and Cognitive Software” segment⁵. Given the segment’s overall revenue was $4.2 billion in 2019⁶ and Red Hat’s most recent fiscal year revenue pre-acquisition (more on that deal in a bit) was $3.4 billion⁷, the maximum revenue SoftLayer could have contributed in 2019 was around $1 billion.

That is an impressively mediocre growth story. To wit, in 2013 (the same year as the SoftLayer acquisition), annual AWS revenues reached $3.8 billion⁸ and grew to $35 billion in 2019⁹ — reflecting a healthy compound annual growth rate (CAGR) of 44.8%. IBM’s bare metal bet via SoftLayer reflects, at best, a 13.2% CAGR¹⁰ — only 0.2% higher than the CAGR for the Trucking industry¹¹. That is, as the kids say, a big oof.

Red Hat Redemption?

While IBM was off hobbling its racehorse, their repudiation of the cloud opportunity led to a power vacuum in the “trustworthy provider with reliable long-term support” domain, which Microsoft was voracious and primed to fill. This is partially why, despite chatter of Azure presenting inferior value across a variety of facets relative to AWS or GCP, sales are still quite stellar¹².

Presumably sensing their nebulous¹³ prospects in the cloud market, IBM completed the acquisition of Red Hat for a staggering $34 billion in summer 2019. This purchase price reflected a stock price premium of approximately 60%, which is double the typical premium¹⁴ and perhaps a rare moment of lucidity at IBM in recognizing that no one wants to be acquired by them.

The surface rationale of the deal is that IBM can cross-sell Red Hat’s offerings to its customers, which is… quite a bit harder without the managed infrastructure services business, especially given this was the rationale highlighted in the investor presentation on the deal. But we will pull on that paradox’s thread soon enough.

What did IBM receive from Red Hat to cross-sell? Thankfully, Red Hat was publicly traded prior to the IBM acquisition, so we can delve into its financial profile by leveraging relatively recent data.

Red Hat is a predominately subscription business – it was 88% of fiscal year (FY) 2019 revenue¹⁵, growing by 14.6% year-over-year (y-o-y) – with the rest of revenue coming from “Training and Services.” The latter category is pretty self-explanatory and is growing at a decent rate (19.3% y-o-y), evidently due to customers needing some handholding around adopting OpenShift and Ansible.

Red Hat’s subscription revenue is primarily generated by “Infrastructure-related” subscriptions, which made up 72.3% of all subscription revenue as of FY 2019. The critical driver of the “Infrastructure-related” category is almost assuredly subscriptions for Red Hat Enterprise Linux (RHEL), a Linux operating system (OS) favored by enterprises over the numerous open source Linux OSes due to the support provided with the subscription. With that said, “Infrastructure-related offerings” also includes Red Hat Satellite and Red Hat Virtualization and they don’t provide a further revenue breakdown.

The remaining 27.7% of subscription revenue is from “Application Development-related and other emerging technology subscription,” which is a ridiculous mouthful and belies the importance of the offerings for Red Hat’s growth strategy. “Application Development-related” explicitly refers to Red Hat Middleware, whose most notable offering is JBoss, an open source Java application server. Red Hat’s definition of “Emerging Technology” explicitly defines it as tools to “build and manage hybrid IT computing environments,”¹⁶ and includes Red Hat OpenShift, Red Hat Cloud Infrastructure, Red Hat OpenStack Platform, Red Hat Ansible Automation, Red Hat CloudForms and Red Hat Storage technologies.

Of those emerging technologies, OpenShift, Ansible, and OpenStack are, by my estimation, the highest sources of revenue growth. For instance, infrastructure-related subscription revenue grew 9.3% y-o-y from FY 2018 to FY 2019 – which certainly doesn’t count as “high growth” – while app dev-related & other emerging tech subscription grew 30.9% y-o-y (double Red Hat’s total revenue growth of 15.1% y-o-y). And it really is the emerging tech part of that second category fomenting that higher growth.

The “emerging technology” offerings are actually cannibalizing the “application development-related” offerings¹⁷. As more of the market leverages containerized environments for app development, they want a platform like OpenShift with orchestration capabilities, leading customers to replace JBoss spend with OpenShift spend¹⁸.

We now need to dig a little deeper into OpenShift to set the stage for spelunking through IBM’s hybrid cloud-dominated spinoff strategy. OpenShift is a container orchestration platform like Kubernetes, but provides professional support services around things like updates, patches, and integrations. Both OpenShift and Kubernetes manage clusters – groups of containers – to automatically handle the operations required to keep services running smoothly, like restarting failed containers, distributing network traffic across containers, mounting storage systems, optimizing resource usage, rolling out new container images, and so forth.

How does this fit in with “hybrid cloud”? Containers package all the stuff (like libraries, dependencies, configuration files, etc.) needed for an application to run. By putting all this stuff in one package, the application is no longer dependent on specific infrastructure and can be run in different computing environments. So, a containerized application can run just as well on-prem or in a private or public cloud and on top of any Linux distribution – which means that containers are sufficiently flexible to work with whatever mix of systems an organization operates that constitute their “hybrid cloud.”

This means OpenShift is perfect for “hybrid cloud,” right? Not quite. While Kubernetes works with any Linux distro and basically any cloud platform, OpenShift only works with CentOS¹⁹, Fedora, or Red Hat Enterprise Linux Atomic Host (RHELAH). Those distros are supported by AWS, Azure, and GCP, but it still obviously constrains one’s options and is discordant with the flexibility-first ethos of “hybrid cloud.” Similarly dissonant is the fact that OpenShift’s templates, a collection of files that define the resources needed to run an app, like a package manager, are largely unable to handle more complex deployments – and complex deployments are pretty common in a “hybrid cloud” environment.

There are notable benefits of OpenShift relative to Kubernetes – like better security defaults and container image management – but the dream orchestration solution for “hybrid cloud” it is not.

IBM’s Hybrid Cloud Chimera

Now we arrive back to IBM’s grand ambitions around an unfettered IBM Hybrid Cloud business. In the “Strategic Update” presentation announcing the spinoff, IBM touts that they are “positioned for success in the hybrid cloud and AI market.”²⁰ Given the rest of the presentation is almost exclusively focused on the hybrid cloud opportunity – for which they assign a $1 trillion total addressable market (TAM) – I suspect the “AI” portion of that proclamation is to save face regarding all the Watson investments.

Before we dissect their hybrid cloud reveries, let’s solidify our notion of “hybrid cloud” beyond buzzphrasedom. “Hybrid cloud” is an environment that uses a mix of infrastructure, like on-prem servers, private or public clouds, containers, serverless functions, etc. In the spirit of vagueness that plagues all buzzphrases, “hybrid cloud” greedily represents the spectrum between “purely on-prem and bare metal” to “purely public cloud and containers.”

IBM pretty clearly includes “multi-cloud” as part of the “hybrid cloud” opportunity given their mention of “regardless of vendor” in the press release. “Multi-cloud” refers to organizations using multiple cloud providers to support their software delivery – like using AWS S3 and EC2 with Google Compute Engine VMs with Azure Storage. As a beloved engineering VP friend quipped, “Only a masochist voluntarily goes multi-cloud.”²¹

So, what should we make of this $1 trillion TAM?²² As is tradition in glossy corporate investor decks, no sources are cited for that figure in IBM’s presentation. Nevertheless, their TAM calculation includes $450 billion for “Cloud Software & Platforms” (addressed by Red Hat and Cloud Paks²³), $300 billion for “Cloud Transformational Services” (addressed by “OpenShift Everywhere”), and $230 billion for “Cloud Infrastructure” (addressed by OpenShift on Z and Regulated Industry Clouds). Without any citations for those numbers, it’s impossible to tell whether this is truly the “hybrid cloud” opportunity or IBM performing Fantasy Math™²⁴ with overall cloud market figures to kindle excitement among investors.

Interestingly and farcically enough, IBM’s hybrid cloud TAM has decreased by $200 billion²⁵ from 2019 until now! The breakdown back in 2019 was $550 billion for “Services for Cloud,” $350 billion for “Cloud Software,” $150 billion for “Infrastructure,” and $100 billion for “Component tech sold to Cloud Service Providers.” If we compare to the more recent breakdown, the TAM for “Cloud Software” increased by $100 billion and added platforms to the mix, “Cloud Services” added transformational to its name and shrunk by $250 billion, “Infrastructure” grew by $80 billion, and “Component tech” disappeared or perhaps represents the $100 billion added into “Cloud Software.” As I said: this is Fantasy Math™, where facts are discouraged and hand-waving an artform.

To beleaguer the point, the TAM a still-independent Red Hat identified in 2018 for itself was $69 billion²⁶, which is a teensy-weensy 6.9%²⁷ of the TAM that IBM boasts for what is largely just Red Hat-rebranded-as-IBM-Cloud. Red Hat’s breakdown of that TAM²⁸ included $18.0 billion for Middleware, $16.0 billion for Storage, $17.6 billion for Operating System, $5.8 billion for “Cloud Management (including OpenStack)”, $4.7 billion for PaaS, $4.8 billion for Virtualization, and $1.9 billion for Infrastructure Management.

Is the right lesson to learn here that the difference between a $30 billion company and a $110 billion company is held in your ability to abstract away market categories and inflate TAMs to the point of meaninglessness? Can you 3x your market cap by replacing “various analyst estimates” as the source of your TAM figures with no citations whatsoever? I’m sure we’ll see a pay-for-publication Forbes article about this inspiring finding soon.

IBM claims that a hybrid cloud approach provides 2.5x the client value of an approach with “public-only cloud structures” – without citing any source data again, naturally²⁹. Red Hat OpenShift is called out specifically as the “hybrid cloud platform” that will deliver this “generational leap in client value.” This suggests that OpenShift is the essential element to secure success from the spinoff; unfortunately for IBM, I suspect that this element will be more like Unobtanium for them when executing on the opportunity. Even with Kubernetes’ deficiencies and the legitimate market need for a more enterprise-flavored orchestration solution, there is simply no way OpenShift can fulfill the astronomical aspirations a $1 trillion TAM imparts.

Even if we assume that OpenShift – or even Red Hat’s “emerging technology” offerings more broadly – is indeed sufficiently promising to seize the platform part of the hybrid cloud market opportunity, successful realization of those prospects rests upon the assumption of IBM not being IBM. And, well, perhaps the only thing that IBM consistently does well is being reliably IBM about things. Would it really be a surprise if the same fate befalls Red Hat that befell SoftLayer?

Undoing IBM’s calcified culture of cash grab contracts while minimizing engineering effort seems preposterously unlikely, despite it being an inherent necessity if they’re aiming to grab a sufficiently succulent bite of the $1 trillion total addressable market (TAM) pie³⁰ they’ve plated for public market investors.

The assumption of efficient execution is also incongruent with IBM’s modus operandi of Standard Oil-style vertical integration – so do we expect them to deviate from their standard, stifling strategy? Because the success of this breakup – let alone the Red Hat acquisition – hinges upon that. If IBM Hybrid Cloud cannot play nicely in other clouds and with other tools – for instance, with organizations using Kubernetes instead of OpenShift – it seems reasonable to suggest that they will fall on their ass. And this, of course, is exacerbated by OpenShift’s critical importance to IBM in the hybrid cloud Thunderdome, because it helps them capitalize on companies wanting to fluctuate between the big three providers.

What Could Have Been

If I had a time machine and eventually reached a mind-melting level of boredom (seems unlikely, but pretend with me), I could go back even a mere five years ago and give advice to those in charge of IBM’s cloud strategy, which would simply be: just be yourself! Lean into the fact that people buy you because you’re the safe choice rather than pretending like you’re going to be the face of the hybrid cloud or AI revolution.

There are plenty of organizations who want handholding, helmets, and full body armor just to tricycle their way into Baby’s First Container, and IBM can and should help them out rather than courting the sour, sulky engineer market who, like the stereotypical angsty teen, would rather, like, literally die than be seen in such dorky protective gear.

Aside from the “Bubble Boy, but cloud native” opportunity, serving the needs of regulated industries was and still is an appropriate opportunity. IBM did mention in the strategic announcement that it would pursue the “regulated industry clouds” opportunity and that feels like the (only) appropriate fit out of the $1 trillion TAM they outline. Organizations in regulated industries may have no choice but to shun public clouds, needing instead to store and process data on-prem, and IBM (primarily vis a vis OpenShift) could help them still “modernize” applications within those confines.

“It’s just a flesh wound!”

With all that said, I think we need to take a step back and look at the splitting up of the two businesses in the first place… because is it really the right move? Are there any IBM Cloud customers who are there without IBM’s I.T. services involved? My hunch is that the managed services arm is IBM’s biggest lead gen for their cloud offerings – because product quality certainly isn’t generating the fledgling interest that exists – so what will they do when that arm is severed?

Despite IBM’s cloying marketing hype around the birth of IBM 2: Hybrid Cloud Boogaloo³¹, IBM isn’t fully amputating its services arm – nor even fully divesting the Global Technology Services (GTS) segment that will be deemed “New Co”. Despite the spinoff announcement theatrics boasting the sloughing of low-growth “managed infrastructure services,” the cloudified new IBM will still include:

• Technology Support Services (TSS): a wing of GTS (yes, the one being spun off…) that offers support and maintenance services for IBM’s hardware and software offerings – think if you need installation or troubleshooting help
• Global Business Services: consultants help customers figure out how to build things, which gets implemented by GBS’s Systems Integration and Application Management Services arms
• Global Financing: the home of IBM Credit³², which helps customers figure out how to pay for the stuff they want (or that is being pushed on them by the consultants), including refurbished hardware³³
• Systems: not a services segment, but it’s the home of IBM’s mainframes, semiconductors, power systems, and other hardware – which is also decidedly not cloud-flavored³⁴

If we put all the pieces of the “revitalized” IBM together, we can see the following year-over-year growth profile (from 2018 to 2019)³⁵ and proportion of IBM Hybrid Cloud revenue made up of cloud software vs. services vs. hardware:

This is hardly what one would picture when envisioning a plan to “accelerate hybrid cloud growth strategy” and reveals the fragility of IBM’s spinoff justification – because it’s difficult to claim that this is a refocused IBM dedicated to growthy hybrid cloud software offerings. As if that isn’t lame enough, this anemic portfolio is disgraceful in context of the revenue growth profiles of real cloud companies during the same period of time (FY 2018 to FY 2019), like 84% at Alibaba Cloud³⁶, 72% at Azure³⁷, 53% at Google Cloud³⁸, and 37% at AWS³⁹.

It’s already plenty confusing from a strategic perspective that IBM is keeping a non-trivial amount of services for IBM Hybrid Cloud. But confounding matters further, the portion of the GTS business that IBM is severing seems like it was pretty critical in selling infrastructure solutions to customers, which, as foreshadowed earlier, was what IBM touted for ~*synergies*~ when buying RedHat.

With that services-as-sales-engine strategy kaput, IBM’s self-described alternative for creating more opportunities for Red Hat is by… <checks notes>⁴⁰ … “strategic solutioning,” which is an awe-inspiring level of linguistic inanity⁴¹. To avoid the shame of dignifying such a vacuous and frivolous statement, I will simply say that “strategic solutioning” sounds like it begets neither strategy nor solutions.

Ultimately, it feels like IBM is both attempting to focus on Red Hat’s stuff – which is legitimately the most promising opportunity in IBM’s gargantuan portfolio – while still very much attempting to suckle at the frothy teat of customers via services the same way it always has. In the perspicacious words of Ron Swanson, “Never half-ass two things, whole-ass one thing.”⁴²

In Conclusion

Sometimes it’s difficult to tell if an organization is purposefully bamboozling external parties or just temerariously bamboozling themselves. In the case of this rebranded IBM, perhaps they actually believe that IBM Hybrid Cloud has a future once it can shed the leaden snakeskin of (some of) the legacy IBM business – like someone freed of a parasitic partner, IBM Hybrid Cloud can finally pursue their dreams and live, laugh, love, loathe, launder (money), liquidate (assets, not people) and whatever else substitutes for introspection in those wearisome Journey to Find Oneself stories⁴³.

If IBM leadership doesn’t actually believe that this rebranded IBM has a real future, and it is indeed a bamboozle targeted at shareholders and whatever customers remain, then it’s a huge waste of everyone’s time and also a colossal amount of money, and I wish it was socially acceptable for them to be like,

“Yep, we totally foozled execution on this cloud thing and what we have sucks. This IBM Hybrid Cloud thing is just going to be RedHat and we’re going to let them run the show now because that’s really better for everyone involved. And you’ll probably make more money off it anyway than the continuously-burning money-filled gas crater of a business we would’ve created.”

However, I kind of feel like IBM’s best use case for the tech industry at this point is to keep milking its despondent legacy business for cash and use it towards corporate VC into startups that can execute more efficiently and effectively with the capital than a provably languid behemoth like IBM. But my even spicier take is that abandoning the IBM Hybrid Cloud endeavor entirely might engender the most net-positive utility on a societal scale.

There’s a macro point here that it’s kind of a shame there isn’t a feasible mechanism for companies to just give up because they realize continuing operations is pointless. Much like many of my ill-fated DIY projects, sometimes it’s far healthier to realize you are wholly unequipped and seriously outclassed by others’ skills⁴⁴ so you can proceed to things that you can successfully execute rather than immolating more irreplaceable seconds of your life.

I’m not necessarily saying trying to make IBM Hybrid Cloud a real thing is like trying to redo your own bathroom plumbing… but in both cases, shit is likely to go wrong.

Thank you shoutouts to Halvar Flake and Ryan Petrich.

This post will explore why both YOLO security (YOLOsec) and FOMO security (FOMOsec) are pernicious disservices to infosec defense and how you can spot them so that you may yeet them from your organization’s security strategy.

The tl;dr is that #yolosec and #fomosec are disconnected from the goals and needs of the business, forsaking pragmatism and prudence in favor of fanatical flavors of recklessness. YOLOsec reflects a security strategy driven by a “you only live once” mentality – one that emboldens people to ignore future concerns around security to achieve today’s gratification. FOMOsec reflects a security strategy driven by a fear of missing out – one that frightens people into misallocating resources towards what makes them feel better about their security efforts.

If you imagine your organization as a sea-faring vessel, infosec’s goal is to ensure the boat can survive krakens or canon-wielding pirates and successfully complete its journey. If you ignore the existence of sea terrors (#yolosec), you may not make it to your destination unless Poseidon grants you merciful passage. If you prioritize defense above your vessel’s mission (#fomosec), you will find yourself aboard a battleship that is entirely inadequate for transporting revenue-generating cargo.

First, does security matter?

Before we dig into defining #yolosec and #fomosec, I want to establish the appropriate context for these concepts. The potential peril inherent in these two “strategic” approaches rests on understanding security’s relevance to private-sector organizations³. The not-so-dirty and not-so-secret dirty secret is that information security does not matter nearly as much as the infosec industry proselytizes. In the grand scheme of business risks, it is solidly in the bottom half, if not the bottom quartile⁴.

Your organization is far more concerned with attracting and retaining customers, successfully competing in an evolving market, macroeconomic factors relevant to their industry (especially right now, amid the COVID-19 slowdown), operational interruptions and downtime, commodity price fluctuations, failure to maintain brand image and public perception, inadequate financial forecasting, changes in product mix impacting profitability, maintaining relationships with supply chain partners, impacts of seasonality, their litigation and regulatory risk profile, changes in international trade relations, climate change impacts, exchange and interest rate fluctuations, inability to access external financing, ability to anticipate consumer preferences, and, well, you hopefully get the idea by now⁵.

As far as tech stuff goes, organizations are primarily concerned about the interruption or inadequacy of IT systems, since those systems power ongoing business operations and, to varying degrees, fuel their revenue growth. To the ops readers among you, congrats, you are critical to modern business operations across most industries! To my infosec readers, I am certainly not saying you are unimportant, but, rather, that it is vital to be self-aware of one’s influence on the reality around you⁶.

With that said, infosec is not completely useless⁷. Attackers can absolutely cause operational interruption and downtime, most obviously through things like DDoS attacks, ransomware, or overloading cloud compute to eke out computercoins. Beyond those examples, security incidents in general necessitate recovery and response efforts which require money, time, and, frequently, system downtime (so money, money, and frequently money). There is limited evidence that security incidents lead to damaged public perception⁸ or public market valuation⁹.

Therefore, one can consider infosec important to organizations insofar that it either: 1) minimizes negative operational impact engendered by attacker actions 2) enhances qualities that improve business operations, such as the speed, stability, or scale of IT systems. To be clear, there is scant evidence of infosec achieving this second axiom in any meaningful fashion. Security teams encouraging the adoption of standardized APIs or base images is perhaps the only strongly justifiable example. Nevertheless, it remains an equally important, albeit contemporarily theoretical, justification for infosec’s relevancy to businesses.

Now we can explore #yolosec and #fomosec and why their manifestations are so magnificently monstrous.

What is YOLOsec?

YOLO is an acronym for “You Only Live Once,” the modern carpe diem and mostly ironic millennial catchphrase meant to express the unbridled living of life to its fullest in the present, believing the current moment to be vital and unique¹⁰, with scant regard to the future. YOLO-driven actions tend to manifest as risk-seeking activities, such as skydiving or, in the case of Napoleon Bonaparte’s Hundred Days, sneaking into France during exile, ripping your coat open and daring your former troops to shoot you, marching on Paris with said troops, reclaiming your title as emperor, engaging in a war against Europe’s major powers, losing at Waterloo, and returning to exile.

YOLOsec, and my irony-flavored hashtag #yolosec, is a term meant to describe a security strategy that embodies the “you only live once” mentality. A yolosec strategy says, “Setting our S3 bucket full of customer data to public will let us deploy our service faster, what could go wrong?” YOLOsec whispers sweet deceits in your ear, telling you that basic security countermeasures like privilege separation and access control are tomorrow problems – knowing full well that tomorrow will distend into months or years. And this temptation can metastasize across your systems and organization.

#yolosec is rarely instigated by a refutation of security’s importance; its wellspring is often found in an arguably myopic attention on specific business goals that are more easily or quickly achieved by ignoring or dismissing security considerations¹¹. True to Hanlon’s razor, #yolosec is almost assuredly due to incompetence rather than malice.

For instance, developers are not specifically aiming to write code so riddled with bugs that swamps are jealous, nor are they storing API keys in plaintext as an expression of their love for hackers – although both constitute #yolosec. Or, in organizations with high turnover, fresh engineering teams may barely understand how a legacy system works, rendering the exercise of upgrading or migrating it from its current insecure conditions clearly intimidating ¹².

It is thus understandable, albeit undesirable, that the default state of engineering teams is to overlook or neglect infosec concerns when performing their work. This is rarely due to succumbence to temptation, but simply the dearth of pragmatic security wisdom among engineering teams¹³.

What is FOMOsec?

FOMO is an acronym for “Fear of Missing Out,” the modern “keeping up with the Joneses” meant to express the anxiety and regret borne from not participating in experiences in which others are involved – usually examined in the context of witnessing those experiences via social media. FOMO revolves around the basic human desire to understand what is going on, especially the impulse to stay connected with other humans’ experiences¹⁴.

FOMO can represent a sensation that others are living life better than you are, that you are outside of a social loop, that you are behind in life relative to others, or that everything is beautiful and nothing hurts¹⁵ for everyone but you. Human brains are wired to judge outcomes relative to a perceived status quo¹⁶ and to feel bad when experiencing a perceived loss¹⁷, so FOMO quite unfortunately presents a “buy one cognitive bias, get one free” deal. In a nutshell, there are two primary dimensions driving FOMO: a desire for belonging¹⁸ and anxiety about isolation¹⁹.

FOMOsec, and the corresponding hashtag #fomosec, is a term meant to describe a security strategy that is driven by a fear of missing out and its psychological underpinnings²⁰. A #fomosec strategy says, “If you aren’t perfectly protecting literally all the things, what are you even doing?” FOMOsec cackles in your face, mocking your impotent control over the security of your organization’s systems and the flaccidity of your defense relative to the potency of your adversaries and the adulations showered upon your I.T. peers in engineering and operations.

Prioritization and pragmatism fade into the background under FOMOsec; what gains the spotlight is escaping the feeling of inadequacy – regaining a sense of autonomy and control irrespective of outcomes. Under #fomosec, you cry happy tears as your teeth clench and your knuckles whiten from the domspace ecstasy of gripping the wheel, euphorically ignoring that the wheel is not attached to anything and that your supposed steering is relegating you to stagnation.

Defenders, from security engineers to CISOs, are not deliberately sabotaging and impeding organizational operations because of a hatred for business growth or improvement. Every human longs to belong²¹. Defenders are not immune to this basic human need nor immune to its capacity to desecrate strategic thinking²².

The human desire for approval and acceptance from groups who share their social identity is what most foments FOMO – seeking inclusion is even more powerful than avoiding exclusion²³. Both urges result in largely the same outcomes, however, as humans who feel excluded aim to strengthen their connections with social groups and more tightly enmesh their group membership with their self-identity²⁴. Ultimately, FOMO drives humans to alter their own behavior to imitate others within their chosen social group²⁵, regardless of specific underlying motivator.

Even mere tourists of the infosec industry are likely aware of the shockingly borgish tendencies of its constituents, culminating in boldly defined shared identities that glut themselves on in-group signaling mechanisms. Whether the identity of the misunderstood Nostradamus who must save the feeble users from themselves or those who treat a piece of software as “completely broken” if there is a vulnerability requiring local access, special configuration settings, and dolphins jumping through ring 0, the nature of infosec culture and cliques certainly suggests the presence of imitation towards the aim of cementing group identity and gaining group approval. And this, in turn, supports the credibility of #fomosec’s existence.

Envy + FOMO Security

I believe envy waters the roots of #fomosec. Envy is best described as the painful feeling of hostility, inferiority, and resentment resting upon a foundation of admiration.²⁶ When you admire or respect someone else’s situation and compare it against your own, FOMO and envy mix together into an especially potent poison²⁷.

The targets of infosec’s envy are attackers and software engineers – that both possess measurable and meaningful goals that result in tangibly meaningful work. For attackers, the obvious goal is “did you get in?” For engineers, the obvious goal is “did you deliver software customers will buy and use?” Offense attains swaggering victory and software engineers attain lucrative accolades. Infosec’s goals are nebulous or self-serving, its metrics either non-existent or inconsequential, its success abstract and bittersweet at best.

In response to my own work²⁸, I have witnessed infosec professionals bristle at the notion of adopting ops metrics like mean time to recovery (MTTR) to inform their own work. Infosec seemingly wants its own special metrics, despite the obvious logic of adopting metrics that align with operational objectives. This palpably inefficient priority of feeling special over pursuing more meaningful work is not only driven by FOMO-via-envy, but FOMO-via-social-identity, too.

Envy is made even stronger by a need to belong²⁹. Social identity can even be thought of as blossoming from FOMO, which is also made stronger by the longing for belonging³⁰. Extending this to infosec, FOMOsec is perhaps the catalyst for the stark, shared identities found across the industry. In fact, the infosec community, in many ways, is not unlike online gaming communities – featuring guilds (like CISO cliques and SecEng sects), server-wide events (like conferences), and highly active chat channels (like Twitter and Slack groups). And, much like online gaming addiction, the human need to belong perhaps fuels infosec’s obsession with adhering to the shared identity of “outsider.”

FOMO Security Budgets

Unfortunately, #fomosec discourages practitioners from pragmatic budget decisions towards choices that make them feel accepted by their desired social group, whether fellow CISOs or security engineers. This desire for praise and prestige from others leads to consumption behavior based an expectation of how others will perceive the consumption, rather than prioritizing product quality³¹. Driven by the fundamental need for social inclusion, humans purchase and use products that are symbolic of the groups with which they desire connection – and they are willing to sacrifice “personal and financial well-being for the sake of social well-being.”³²

The purchasing of tools such as threat hunting, fancy threat intel reports, or protection against niche, nation-state threats can be thought of as luxury goods that serve as costly signaling mechanisms to generate interpersonal acceptance³³. Adopting frameworks trendy among the in-group – such as MITRE ATT&CK is currently – is a less expensive signaling mechanism, until you factor in opportunity cost. Security engineers building their own SIEM, rivalling children’s attempts at building majestic towers with popsicle sticks and glue sticks, is costly both in people hours and opportunity cost incurred by the organization. However, it represents a feat worthy of admiration from their peers despite the substantial downsides, true to #fomosec’s essence.

FOMO not only drives people to spend excessively and forget their true needs, but also leads people to consult their peers when making purchasing decisions for goods or services – the combination of both leading to impulse purchases that are far from strategic.³⁴ While there are few studies on how security leaders make purchases, anecdata suggests that peers are one of the stronger influences in decision-making, especially if you include indirect peer influence through research analysis firms.

As a result, #fomosec creates the consummate conditions for snakeoilism to spread. FOMOsec germinates from defenders’ fears of being the outcast sheep of the I.T. family, fears of always being one step behind of attackers, fears of their work being meaningless in light of the inevitability of failure, and fears of looking foolish to peers when an incident is emblazoned in public headlines. Rather than promote mindfulness on business objectives, the industry encourages their dismissal, shaming and guilting and goading defenders into throwing away budget towards products that pursue perfection – the unattainable ideal that tacitly stokes the ego’s lust for heroism.

Horseshoe Theory & FOYO Security³⁵

Despite #yolosec suggesting a blistering lack of attention on security and, on the other end of the spectrum, #fomosec suggesting a desperate and egoistic obsession on security, they both result in poignantly poor security outcomes. I argue that they represent the two ends of a Security Strategy Horseshoe, and, in their extreme forms, are nearly indistinguishable in their outcomes.

When you FOMOsec, you are prone to treat the security of all assets, and threats to those assets, equally – or worse, overcorrect for niche threats (like 0day or nation state actors) under the “gotta catch ‘em all” mentality. In the former case, even the largest teams with the highest budgets cannot perfectly secure all systems against all types of incidents. One result is spreading efforts far too thinly in order to maximize breadth of coverage or concentrating on what feels like the biggest gap and neglecting others.

Desperate for Data

They were all in love with data
They were drinking from a fountain
That was pouring like an avalanche
Coming down the mountain³⁶

Those who #fomosec believe that one must collect all of the data possible, as missing the one clue indicating an incident will be catastrophic, embarrassing, or result in some other ill-defined tragedy³⁷. There is a shared, somewhat histrionic belief across the industry that attackers just need to discover one flaw to win, while defenders must cover all flaws to win. From the assumption that attackers possess an (unfair) information advantage, it can flow that gaining an advantage comes from rebalancing the pervading information asymmetry. That is, defenders can elevate their status relative to their adversaries by accumulating enough data, where the quantification of “enough” is persistently vague.

Through this lens of data accumulation, the end results of FOMOsec-driven behavior look an awful lot like those generated by YOLOsec. To quote Professor Netzer of Columbia University (invoking Andrew Lang), “A lot of people are using data like a drunk man uses a lamppost, for support rather than illumination.”³⁸ Doing so is a decidedly YOLO vibe, even if it is fostered by FOMO.

When FOMOsec ignores the basic wisdom of the central limit theorem and the reality of diminishing returns on data set size in improving performance and reducing errors³⁹, it wraps around closer to YOLOsec. Data is a tool for improving outcomes when faced with the unknown, but resolving uncertainty presents finite benefits⁴⁰ – and thus data presents finite and diminishing returns.

Like a dragon slowly burying itself in treasure, FOMOsec growls, “We need to hoard all the data…” and YOLOsec roars, “…and who cares if it causes operational distractions and management headaches in the future?” The FOMOsec-distorted cost / benefit model not only overstates the benefits of data accumulation but also misses the costs of handling all that data going forward⁴¹in a classically myopic YOLOsec fashion.

FOMOsec tells you that you desperately need to collect all the things (and to buy fancy tech that can help you do so) because otherwise you are not in the know, and YOLOsec tells you to collect all the things just because you can. These impulses are nearly indistinguishable in flavor, and equally as damaging. You should not measure things just because you can⁴² as it will lead to a form of self-sabotage via information overload, which leads to cognitive overload⁴³, which leads to a variety of issues that can be summarized as significant human performance degradation⁴⁴.

The social element of FOMO manifests in infoxication⁴⁵, too. The giveaway that data accumulation is not actually about better business outcomes is found in infosec teams refusing to leverage data sources and tools deployed by operations teams, which would streamline budget and promote collaboration. Instead, security teams seemingly refuse to let go. Budget is viewed as a status signal, and security leaders in the vice grip of FOMOsec are disincentivized from taking actions that make them feel less influential, even if it is the right move for their organization and team.

Defenders who #fomosec seek out approval and praise from other defenders as well as their organization – and performing challenging engineering feats helps fulfill that impulse. As one study looking at Amazon’s big data practices unearthed, the accumulation of “big data” is mostly viewed as an engineering challenge rather than providing tangible modeling benefits⁴⁶. Additionally, most of this “big data” is wasted, with potentially as little as 0.1% of the data treasure hoard being used to power decision-support systems, as in Google’s case⁴⁷.

The mythical “data feedback loop” does not bear out in practice, but it can certainly help defenders burdened with FOMOsec feel like they are in the know, that they are performing prestigious work, and, besides, everyone else seems to be doing it as part of their security strategy, so mimicry feels right, too. But, just as your mother warned you once upon a time, jumping off a bridge just because everyone else is doing it is a decidedly YOLO course of action.

All Aboard the Vulnerability Hypetrain

The infosec industry is firmly strapped onboard the vulnerability hypetrain: the flurry of media attention and industry panic that explodes upon publication of previously unknown flaws in software, known as zero-day vulnerabilities (or 0day, as the kids say), that often come with their own branding and public relations strategy⁴⁸. Each new, provocatively-named vulnerability adds a stop on the interminable journey. The engine of the vulnerability hypetrain is #fomosec and its exhaust is #yolosec.

Aboard this train, security leaders roleplay as special agents and muse through their tinted Morphean shades about “threat actors,” presenting idle speculation about how geopolitical events shape their firewall policies. The names of vulnerabilities hold special power, like an eldritch deity lurking in the forests surrounding a village, to whom blood sacrifices must be made each full moon lest it devour any newborns in their cribs. The truth that is lost among these rituals of the status quo is that vulnerabilities, and their monikers, should not be given more thought than the names of hurricanes that threaten power or data availability.

Wherefore this pestilent paradigm, then? Each vulnerability with its own PR campaign is a chance to trigger #fomosec, which leads to money or attention (so money or indirectly money)⁴⁹. Constantly stimulating the FOMOsec response leads defenders to adopt a vulnerability-centric approach to security that merges into the unkempt path of YOLOsec. YOLOsec curls around you like an anaconda, obscuring your vision until you can only see the industry headlines screaming about the newest cyberweapon or threat group, the peripheral sliding away until the more relevant factors that contribute to security failure, like misconfigurations, are overlooked.

Overly permissive access controls will not receive a fancy name like RootRipper or DefaultDesecration but will make an attacker’s job much easier. Thus, when #fomosec panics about missing the presence of the latest heralded vulnerability in your organization’s environment, #yolosec high fives its partner-in-crime and springs into action to beleaguer your colleagues with the false positives and intractable UIs of vulnerability scanners while the attacker stumbles upon a publicly exposed k8s management dashboard and takes control of prod⁵⁰.

The stated motivation for the vulnerability hypetrain is to protect users in the surrounding countryside. But, well, COVID-19 was not named LungTempest, and we do not see pharmaceutical companies publishing blog posts by self-proclaimed rockstars about how to improve the scalability or functionality of LungTempest so amateurs can DIY their own virus with a bit of copy pasting and tweaking⁵¹.

We would all rightfully be outraged if pharma researchers were publishing posts about leet bioweapons online for fun and profit, about how to bypass a competitor vendor’s vaccine (after an oh-so-generous 90 day window for them to fix the vaccine), or with technical details that dramatically overstated the potential severity of the virus in order to raise funding for a new miracle drug.

Alas, #yolosec relishes the joie de vivre of dropping 0day to thunderous applause and #fomosec drinks deeply of it – the shimmering waters of an oasis in the lonely desert under the blisteringly hot sun of irrelevancy. Defenders thirst for significance and acceptance. And researchers (and the vendors who employ them) are more than happy to provide a means of feeling “in the know” and phantasmic progression towards solving the frustratingly contumacious security problem. I leave it up to the reader to evaluate whether this is symbiosis or parasitism.

FOMO Security Fosters YOLO Security

The desire to acquire the sexy, shiny security toys that seemingly signal membership in the Cool Kids Club is incited by FOMOsec⁵². Equifax deployed FireEye to protect against advanced threats and yet: 1) failed to patch a vuln in their database within their own mandated time frame of 48 hours (it was more like four months)⁵³; 2) neglected to update the security certificate in their network traffic monitoring tool for 19 months, rendering it useless⁵⁴.

Equifax simultaneously FOMOsec’d and YOLOsec’d, demonstrating the conceptual compatibility of the horseshoe’s ends. The same security team can both be like, “We need to stop nation states!” and also completely fail to patch their shit.

I argue the general case that #fomosec almost necessarily engenders #yolosec elsewhere, not unlike life outside of security. An obsession with the perceived inadequacy of your own life in light of the perceived excellence of others’ lives (FOMO) is likely to lead you to take extreme action to “prove” how exciting and fun your own life is (YOLO). For instance, college students who experience more FOMO also are more willing to place themselves in riskier social situations and make impulsive, embarrassing, or physically harmful decisions⁵⁵.

The yearning beget by FOMO to belong to a social group and receive praise from it leads people to pursue novel experiences, with the expectation that these experiences will arouse approval from others⁵⁶. That is to say, FOMOsec is quite likely to lead defenders to make YOLOsec-flavored decisions, sprinting down a path of myopia filled with seemingly impressive feats – whether buying sexy tech, paying out the nose for “exclusive” threat exposés, being on an advisory board of a hot infosec startup, attending VIP conference parties, and so forth – that are entirely uncoupled with what is required to ensure business operations are pragmatically protected.

This may be a shock to some security readers, whose self-image might shatter at the thought that they could allow – let alone foster – #yolosec. But, when you allow #fomosec, when you want no security stones left unturned, when you demand security approvals on every last bit of new code, or when you lust for security gaining a sacred seat at the Big Kids’ Business Table, you are losing sight of your organization’s priorities and thus inherently routing limited resources in suboptimal directions. You fight your eng org to integrate the vulnerability scanning tool made by the company who let you meet Mr. Robot at RSAC into your organization’s code repo, and now you gain the glorious outcome of developers ignoring the tool’s findings and resenting you – thereby deciding to stay quiet about security issues they do find – while your precious security budget is six figures lighter. You did it!

And before you think that this could not possibly apply to you, consider this: you could be under the influence of FOMO as you read this and be unfeignedly unaware of how it is negatively impacting your work⁵⁷.

Conclusion

If security must shun both YOLOsec and FOMOsec, how should it look instead? To simultaneously alleviate a longing for belonging, envy, and myopia, infosec defenders must seek out and share the identity of “builder”⁵⁸ with software engineers⁵⁹. Aligning infosec metrics to software delivery metrics facilitates the alignment of infosec work to software delivery work. Acting upon this alignment – not just paying lip service – engenders the opportunity for security teams to more tangibly connect the work they perform with value and meaning produced.

If you can understand nuance in security problems, you will absolutely be valued by your organization. If you can support the customer experiences required to facilitate business success while ensuring ongoing operational sustainability, it is difficult to imagine your organization viewing you as a nuisance or cost center. FOMOsec poisons missions away from achieving business goals, while YOLOsec erodes the prospect of ongoing sustainability.

Perhaps what is most needed is to shed the label of “security” entirely to encourage a restructuring towards “resilience.” Organizations do not need professionals who self-identify as critics or “breakers”; they need professionals who self-identify as builders but who take pride in building robust systems that can quickly adapt when exposed to any sort of incident – whether an outage caused by an attacker or a performance bug.

That, I think, is the easiest way to kill #fomosec and #yolosec in one fell swoop: the recognition that outcomes are everything and that the differentiation between performance and security concerns in the context of resilience is an unnecessary, outdated construct. #yolosec cannot thrive if engineers are accountable for minimizing instability, regardless of its source. #fomosec cannot thrive if security concerns are treated equally to performance concerns, subject to the same pragmatic prioritization.

The infosec industry would hate it (how many billions of dollars less would vendors make?) and I would lose a multitude of industry insanities to explore… but how much time, money, user pain, and wasted fucks given would we save? I think we should keep an open mind.

Thank you shoutouts to Dr. Nicole Forsgren, Camille Fournier, Kyle Kingsbury, Ryan Petrich, Andrew Ruef, and James Turnbull.

2023 Cyber Startup Buzzword Bingo Card

See my blog post for detailed analysis.

2022 Infosec Buzzword Bingo Card

See my blog post for detailed analysis.

2020 Infosec Buzzword Bingo Card

See my article in VICE Motherboard for detailed analysis.

2019 Infosec Buzzword Bingo Card

See my blog post for detailed analysis.

2018 Infosec Buzzword Bingo Card

2017 Infosec Buzzword Bingo Card

It all started with a Tweet.

It’s also meant to serve as an antidote for the recent twisting of the term by self-serving vendors and #thotleaders who are blisteringly unaware of the decades of research outside of infosec on the topic.

tl;dr – Resilience in security means a flexible system that can absorb an attack and reorganize around the threat.

The basics of resilience in infosec

Resilience in information security (and in other domains) consists of three characteristics: robustness, adaptability, and transformability.¹

Robustness = withstanding and resisting a negative event. Think of this as your systems’ ability to prevent or block pwnage.

Adaptability = managing your current systems’ response to negative events. Think of this as minimizing event impact in your systems, optimizing for system recovery, and minimizing friction involved in changing your systems.

Transformability = reorganizing your system in response to updated assumptions. Think of this as moving to a new system configuration or trajectory when existing conditions are indefensible.

Once more, but less abstractly

Let’s walk through a brief practical example to show how each of these characteristics of resilience work together.

Your organization delivers a PHP application to customers. You use inline PHP code within the HTML of your web apps to perform database queries. An injection vulnerability is found in an instance of this inline PHP code.

Robustness manifests as implementation of a web application firewall to stop exploitation of the vuln, along with patching that instance of the vuln. These actions return things to “normal” – the prevailing status quo before discovery of the vuln (the negative event).

Adaptability manifests as removing inline queries from the application, then replacing them with one class that accesses the database and is responsible for all sanitization. This reduces potential incident impact and, by only requiring issues to be fixed in one place, minimizes friction involved in changing the system going forward.

Transformability manifests as re-architecting the application in a different language, like Java, to solve PHP’s endemic security problems. Evidence from application monitoring or publicly-disclosed vulnerabilities in PHP leads to updated assumptions about PHP’s suitability for the application. These assumptions motivate revision of previous choices that result in reorganization of the system to optimize for the evolving reality.

Piecing it together, these activities result in a more flexibly-designed application that can absorb an attack and be reorganized based on its evolving threat context.

What most of the industry gets wrong

1. Robustness does not equal resilience. Robustness is insufficient on its own to foster resilience. Prevention is not resilience. Prevention is insufficient on its own to foster resilience. Being able to block or withstand an attack is not resilience. Being able to block or withstand an attack is insufficient on its own to foster resilience.

   I am spelling this out as plainly as I can because I see this misconception all the time now. Resilience is being used as a substitution for robustness, prevention, and “stopping threats” by marketing teams to make their stale pitches feel fresh again. Don’t be bamboozled by these misleading claims.

   If you want to understand more why this is such a dangerous conflation, read the Robustness section in my keynote on resilience.

2. Resilience is not a tech stack or set of tools. Given people still think DevOps is achieved by implementing a certain tech stack, I don’t hold much faith that people will let go of similar notions about resilience. Just like DevOps, resilience is a set of principles and practices. It’s an approach that aims to help you evolve your security as your environment and context evolves.

   Certain tools can support your resilience practices – such as transformability via migrating systems from on-prem to the cloud – but you will not be able to “do resilience” just by purchasing tech.

In Conclusion

I’ll repeat my definition again: Resilience in security means a flexible system that can absorb an attack and reorganize around the threat.

I firmly believe resilience is the future of information security. Alas, the term is actively being bastardized by some vendors to serve their pestilent purposes. To the practitioners reading (whether you build systems or secure systems), remember that attackers are continuously evolving their methods based on changing context, and it is imperative for you to evolve your methods, too.

Adopting a resilience approach will help you survive – and hopefully even thrive – in this dynamic digital world of ours.

Thanks to my engineering and security friends for their feedback on drafts, especially Camille, James, and Vladimir!

What more is there to say, really?

Thanks to Chris Hoff in 2013 for the original inspiration.

“The seasons change; and both of us lose our harvests for want of mutual confidence and security.” – David Hume, A Treatise on Human Nature

As I expounded before, security should be treated as a product – as “something created through a process that provides benefits” to the organization. Every product has a purpose, something it is trying to help its users accomplish. If security is a product, what is its purpose? What is it trying to help its users – the organization – accomplish? Without this purpose, security can become aimless – falling into the wretched trap of “security for its own sake.”

If we treat security instead as a business enabler, what results? In many tech organizations, the most critical business enabler is software delivery performance. Therefore, security should cooperate with relevant stakeholders who focus on software delivery performance, especially the engineering organization (colloquially known as the DevOps function).

As is well-discussed in the industry, the relationship between security and DevOps is typically described as fraught, icy, or adversarial – a far cry from cooperative, let alone collaborative. There are cultural reasons for this, but I will not be covering them in this post. Instead, I am going to draw on behavioral economics, looking both to cooperation games within game theory and the concept of moral hazard as a lens through which we can better understand the security and DevOps relationship.

So, shall we play a coordination game? Let’s dive in.

Barriers to Cooperation

Cooperation Games

Most relationships in life can be considered through the concept of “games,” behavioral relationships between decision-makers involving certain rules or conditions. It is worth exploring the different potential attributes of games as a backdrop for how to think about the game infosec plays with its DevOps peers.

Games can involve cooperation or non-cooperation. Non-cooperative games involve competition between the game’s players, without any sort of external authority to enforce cooperation between the players – resulting in no chance for alliance. The game between attackers and defenders can be considered a non-cooperative game. Cooperative games, unsurprisingly, involve cooperation rather than competition. Players can form coalitions to coordinate their strategies and share potential payoffs¹. One of the more famous cooperation games is the Prisoner’s Dilemma, a non-zero-sum cooperation game in which two prisoners must make the decision to confess or stay silent.

What is a non-zero-sum game? In zero sum games, the total payoffs for all players in the game add up to zero. That is, one player’s gain will equal the other player’s loss exactly. Few real-world scenarios involve zero-sum games, but the game poker is an example of one. Non-zero-sum games are thus games in which the total payoffs for all players do not add up to zero – that the gain by one player does not result in an equivalent loss by the other player. Free-trade is an example of a non-zero-sum game in which all players can benefit in a win-win scenario. The aforementioned Prisoner’s Dilemma is non-zero-sum, as it can result in a win-win or lose-lose scenario.

Information is an essential component of every game, as information is at the heart of strategic interaction – particularly information regarding other player’s decision-making in the game. In perfect information games, all players know all decisions previously made by the other players. As you might suspect, real-life rarely allows such omniscience, outside of games like tic-tac-toe or chess. Imperfect information is common to our existence, wherein players cannot see all prior decision-making by the other players within the game.

Complete and incomplete information is another informational characteristic of games. In a game with complete information, players understand the potential payoffs, risk tolerances, strategies, and player “types” among other players. Again, complete information is largely unrealistic in the real-world. Instead, games with incomplete information are most common in human interaction, wherein players cannot discern other players’ preferences, motivations, and other strategic information.

Although it may scandalize true game theorists, for perspicuity’s sake, I will summarize these information-based characteristics into the concept of information asymmetry – that players possess relevant information to which the other players do not have access. Typically, information asymmetry is analyzed through the lens of transactions, though I argue it all comes back to decision-making between relevant players.

I believe one can view DevOps and infosec’s relationship as a coordination game with information asymmetry. I do not believe it is a non-cooperation game, as there is ample room for infosec and DevOps to form a coalition, and there is potential for the organization to serve as an external enforcer of cooperation. There is also information asymmetry, as neither DevOps nor infosec has perfect insight into the other’s decision-making process nor access to all relevant information (much of which might be tacit and considered tribal knowledge).

If we proceed with the assumption that DevOps and infosec’s relationship is a coordination game, then our goal is to understand how to encourage cooperation to maximize the collective payoff. This results in a crucial question: what leads to coordination failures? One impetus is strategic uncertainty among players, that they do not realize their objectives are aligned. Perhaps obviously, misalignment of objectives can also present friction in cooperation games. Thus, mechanisms are needed either to facilitate cooperation – in the event of aligned preferences – or enforce cooperation – in the event of less aligned preferences.

Interestingly, empirical evidence suggests that humans are far more cooperative by nature than traditional game theory predicts. In fact, the wealth of data points showing cooperation within games far exceeding predicted values has led scholars to delve into the nature of cooperation, seeking an answer to why this pattern holds. There is a split among those who seek to prove that cooperation still fits within the confines of rational behavior, and those who argue that cooperation represents more of a strategic irrationality – the philosophical nuance of which I will not cover here.

Despite humans being cooperative by nature, there are potential wrinkles that can come when decision-making power and information possession are unequal – known as moral hazard, which we will explore presently.

Moral Hazard

Moral hazard results when someone increases their risk exposure because they are protected from risk impact in some way. It is related to the principal-agent problem, in which someone (the agent) can make decisions on behalf of another person (the principal), leading to the potential for self-interested actions by the agent that are not in the interests of their principal. Information asymmetry exacerbates moral hazard issues, since one party possessing information the other party cannot access creates an incentive for exploitation.

A tangible example of moral hazard is in insurance. If you received an insurance policy with full coverage for all potential losses due to security incidents, theory suggests you will have less of an incentive to invest in a strong security program. The insurance provider may assume you will maintain your current level of protection, but you possess information secret to them – that you have no intention of doing so. Thus, you are willing to accept more risk because you are protected from the risk impact, potentially empowering you to pursue a #yolosec strategy².

Looking to infosec and DevOps, there is the potential for moral hazard given the team structure at most organizations. DevOps can increase their exposure to security-related risk because they are not held accountable for it, making the infosec team bear the risk impact. DevOps can likewise possess hidden motivations or take hidden action from the vantage point of the security team, as not all efforts to secure systems will be observable by infosec. This makes it difficult for infosec to manage the organization’s risk exposure – and thus the ability to manage the risk impact they experience.

I believe moral hazard goes both ways in this relationship, however. Infosec can also increase risk exposure for the rest of the organization – but risk of a different kind. Part of infosec’s infamy is due to creating policies or implementing tools that add risk to their colleagues’ workflows, such as a salesperson wrestling with a clunky VPN when trying to close a deal with a customer. Because infosec is shielded from the risk resulting from friction to their organizational peers’ workflows, they are more willing to add such risk in the name of their own priority: security.

Moral hazard is particularly relevant when considering conflicting goals. Very recent research suggests that decision-makers resolve goal conflicts on behalf of others differently than they would for themselves, potentially resulting in undesirable outcomes for the recipients of the decision. But, first, what defines goal conflict? It is when achieving one goal prohibits or discourages the achievement of another goal. Unless there is the option to satisfy both goals (more on this later), people will only “activate” the higher priority goal.

One study examined moral hazard and goal conflict through the lens of health practitioners choosing between curative care or palliative care for their patients³. Health practitioners typically prioritize the goal of curative care over palliative care, believing the two are in conflict. What makes this context interesting is widespread evidence that these two goals are not actually in conflict. Palliative care can extend lifespan; but at the very least, it is not shown to interfere with curative care.

Why do health practitioners believe these goals are in conflict, and why do they opt for curative care rather than improving patient comfort and pain reduction? The problem lies in moral hazard – that people focus on potential gains and perceive fewer risks when making decisions for others rather than themselves⁴, and these choices tend to be more creative and idealistic. People can also justify these choices by telling themselves that there are fewer tradeoffs than there are – pretending that it is an easier decision to make.

Another reason behind this errant goal conflict resolution lies in identity. Healthcare providers take pride in being able to solve medical problems, and curative care reinforces that identity. Palliative care, however, can be threatening to this identity, perceived as a form of “giving up.”⁵ Infosec professionals also take pride in their ability to stop threats and to solve security problems, and accepting risk or compromising can be likewise seen as giving up.

The process by which people accomplish multiple goals can also present challenges in an organizational context. Goals can either be pursued sequentially or concurrently. Sequential goal pursuit allocates resources to one goal at a time, only switching attention to an alternative goal once sufficient progress is perceived. Concurrent goal pursuit directs attention to more than one goal at a time, determining a single choice that can satisfy multiple goals (the “killing two birds with one stone” strategy).

There are benefits of each strategy along the spectrum of sequential to concurrent goal pursuit. “Goal shielding” is the primary mechanism of sequential goal pursuit, wherein alternative goals are inhibited to avoid interfering with pursuit of the primary goal – and it has been found to increase successful goal progress⁶. The multifinality principle is the primary mechanism of concurrent goal pursuit, wherein a single means is used to satisfy multiple goals – and it has been found to boost efficiency of goal achievement⁷.

There are downsides to each end of the spectrum, as well. Sequential goal pursuit means that accomplishing multiple goals can take more time. It can also lead to a false sense of security, as seen in a weight management scenario. In one study, those who believed they had made meaningful progress towards their weight goal were more likely to dig into unhealthy food than those who felt that their progress was wanting⁸. Sequential pursuit also allows the excuse of “I’ll do it later,” when “later” never seems to materialize.

Most with experience in information security have assuredly seen examples of the “I’ll do it later” issue, that certain goals are never achieved and continually pushed off. The false sense of security in the weight management case also manifests in infosec in a few ways, but primarily through the seductive delusion that a series of solid security choices means that security concerns can be ignored for a time, or that enough progress was made on security while ignoring the need for continuous maintenance (let alone improvement).

Concurrent goal pursuit requires a readily-available solution capable of satisfying multiple goals at the same time, which is not always possible. What’s more, these magical solutions end up being discounted due to their versatility. For instance, when people were asked to think of three goals a computer serves in a study, they perceived that the computer was less important to accomplishing those goals as when they were asked to think of only one goal a computer serves⁹. While a computer is seen as essential for the sole task of checking email, it is perceived as less critical for checking email when considered alongside the goals of using a search engine or browsing an online publication. Thus, concurrent goal pursuit can save time, but can potentially lead to the feeling of less being accomplished.

This curious effect, known as the “dilution of instrumentality,” is considered decidedly irrational, entirely based on people’s mental models rather than objective evidence of how a course of action can serve multiple goals. I believe this is commonly seen in infosec when evaluating solutions that can help both infosec and DevOps – that any course of action or means to an end that can solve use cases on both sides must not be a very good or powerful one.

Of course, in the context of enterprise security, there is not just one individual pursuing goals. Let us now dive into the concept of team reasoning to better understand the nature of collaborative goal pursuit.

Team Reasoning

Team reasoning is an emerging theory¹⁰ that allows for a group of players within a game to represent a single player, postulating that team members aim to achieve common interests, rather than fulfilling their individual self-interest. As Sugden, one of the parents of the theory, would say, team reasoning represents “intentional cooperation for mutual benefit.” It is commonly referred to as “we thinking” or “joint intentionality” in the literature, and is considered a conceptual kin to “collective intentionality” from the realm of philosophy.¹¹

There is ample experimental evidence suggesting that team reasoning serves as a more accurate theoretical framework than traditional game theory. For example, one study conducted five game types and found that across all games, a majority of players eschewed the individually rational strategy and opted instead for the collectively rational strategy – the one that maximized the group’s payoff¹². An earlier study demonstrated that players specifically identified “focal points” – targets that naturally stand out – that facilitated coordination¹³.

An intuitive reason for cooperation is that we derive value from helping those with whom we identify. On the flip side, if we view the players in a cooperative game as “the others,” we are less likely to cooperate. An imperative ingredient to foster collaboration is encouraging the shift from an individual mindset to a group mindset – to consider what the group’s goals are and what part the individual should play in achieving those goals¹⁴. Naturally, the path to this shift to a collective perspective is not so simple as telling the individual to start thinking in that way.

One method to improve this so-called group identification is by making it salient – the behavioral economics term for making a piece of data more readily accessible and more prominent. For instance, I could encourage group identification among blonde people by telling an all-blonde group that I am conducting an experiment to compare brunettes versus blondes.

Regrettably, from what I have witnessed regarding infosec and DevOps’ relationship (or lack thereof), there is almost a point of pride among each group for being distinct. I certainly do not believe that increasing salience of group identification between the two will fix tension among infosec and DevOps – but it does seem like an important step worth attempting. In any projects or important decision-making meetings, increasing salience by emphasizing that you, collectively, are the core of the organization’s technology group – party members on the imperative quest of ensuring safe software delivery performance – can perhaps remind everyone more of the collective similarities rather than differences. Even more compellingly, this effect can be magnified if you emphasize the true “other.”

Emphasizing potential negative outcomes due to a group of “others” dissimilar from your group (as a compliment to espousing the potential positive outcomes due to group collaboration) offers potent results, backed by experimental evidence.¹⁵ This is known as “perceived interdependence,” achieved by framing the situation as one in which the group needs each other in the face of dissimilar “others” who might seek to harm them.

Luckily, it is not a stretch to present organizational defense in this light. Relative to attackers, infosec should lie squarely in the “in-group” for DevOps – despite their perceived antagonistic qualities otherwise. With that said, there may be perception that security is a more harrowing threat to DevOps than attackers, particularly if DevOps was relatively shielded from incidents in the past, because security stymies their work far more acutely. Hence, I believe attempting group salience alone to fix coordination issues is likely to product mixed results in the vexed realm of infosec and DevOps relations.

Leveraging salience in other ways may prove more fruitful, however. Experimental evidence indicates that making the joint goal salient makes team reasoning more likely to occur¹⁶. Unfortunately, in many games, payoffs are asymmetric, meaning one player or group receives a greater reward for success than their co-player or co-group. Such asymmetry can result in miscoordination, because players find the payoff factor more salient and begin to act more competitively. For instance, in one experiment, games with symmetric payoffs resulted in a 93% cooperation rate, while games with even small asymmetric payoffs dropped to a 49% coordination rate¹⁷.

At most organizations, payoffs for infosec and DevOps will be largely unknown, as most compensation information is private. However, perceived payoffs for success might result in greater miscoordination – and it will most likely take the form of infosec feeling less rewarded than DevOps, if I were to hazard a guess. These rewards are not necessarily monetary, either. The disparity in payoffs between DevOps and infosec is perhaps highest in social rewards, namely social recognition.

One all too common scenario is that infosec may insist on a fix of a critical vulnerability shortly before an anticipated release, requiring last minute scrambling by DevOps to unblock the release. DevOps may be rewarded for these efforts, which might have been avoided by fixing the vulnerability when it was first discovered by the infosec team, rather than ignoring or denying it. Infosec, however, is more likely to be chided than noted for their contributions.

A potential counter is to publicly state equal rewards for certain joint goals, such as mean time to remediation or, more contentiously, fewer vulnerabilities introduced into production, so that this data point regarding payoffs becomes most salient. Again, these rewards do not have to be monetary, but should involve joint recognition at an organizational level. With that said, emphasizing “label salience” – accentuating group salience, as discussed before – may also serve as a deterrence from payoff salience, so experimentation is recommended.

When emphasizing joint payoffs, the payoff matrix for a game changes, as shown below. The new, “we-thinking” payoff matrix illustrates why the theory of team reasoning can still easily support the notion of rationality, as it makes perfect sense for a player to choose a payoff-maximizing strategy:

By visualizing team reasoning through this payoff matrix, its value in promoting coordination becomes palpable. This serves as the perfect starting point for contemplating how we can win the coordination game.

Facilitating Cooperation

In the course of my research, I did not encounter a single organization where DevOps and infosec codified guidelines for how they should interact – or even documented their collective objectives. As I will discuss in this section, choosing the right goals and publicizing them in the right way is essential to facilitate cooperation.

Team Reasoning

One notable and highly relevant experiment involves the centipede game, from Lambsdorff, et al.¹⁸ The centipede game is a multi-stage trust game in which players alternate offers. For instance, in the first round, I could receive $10 while you receive $2, or I could pass the choice over to you to double each amount – giving you the choice of receiving $20 and me receiving $4, or passing it back to me to double the amounts again. This game structure is useful for exploring the reciprocal nature of cooperation, as the subgame perfect Nash equilibrium (i.e. what the rational player “should” play) is for the players to never pass.

The empirical evidence starkly differs from the theoretically rational strategy, with a majority of players passing in the first stage, and some even ending the game without anyone taking vs. passing. The results are even more elucidating when compared across the treatments the experimenters created. In one treatment, the game’s payoffs were presented in probabilistic terms, showing the probability of achieving a joint goal rather than individual payoffs. In the other treatment, the game was presented through a soccer analogy, where passing offers was seen through the lens of passing the ball to score a goal.

In games where the number of passes could lie between 0 or 2 for each player, the average number of passes in the probabilistic treatment was approximately 1.5, and for the soccer treatment approximately 1.9 passes. Both averages are substantially higher than the average for the vanilla version of the centipede game – approximately 1.2 passes – and, strikingly, much higher than the perfect Nash equilibrium of 0 passes. Why did these alternative game treatments succeed? The probabilistic treatment was successful in promoting cooperation due to emphasis on the shared goal, removing the salience of the payoff asymmetry (as discussed in the prior section).

What led the soccer treatment to be most effective? The researchers believe it is because the soccer analogy made the joint goal obvious, thereby making the team identity salient. This not only is supportive of the theory of team reasoning, but also perhaps supports the practice common among the stereotypical former-jock sales leaders of using sportsball analogies to foster team spirit and motivation. While I remain somewhat skeptical of the efficacy of sports analogies on engineers, I believe similar levels of salience for group identity can be accomplished and provide similar results in improving cooperation.

What else can these results suggest for the relationship between DevOps and infosec? One is that controls targeting individuals for infractions – for instance, punishing individual developers for security bugs – may be less effective than sharing security-enhancing goals at a group level. Further, emphasizing differences between groups is less effective in improving conflict resolution than emphasizing joint goals. This perhaps is where infosec culture fails the most – presenting a draconian notion of infosec vs. normies and declaring that infosec is a misunderstood, maligned clique that is the gatekeeper of secure practices.

Outcome & Process Goals

Another set of tools for our conceptual arsenal is found in outcome and process goals. Outcome accountability prioritizes people getting things right. Process accountability prioritizes people thinking in the right way. I am a huge proponent for focusing on outcomes rather than outputs, particularly when it comes to measuring success – because lots of aimless creation is not useful, but impactful creation is. Nevertheless, there are caveats to outcome accountability, regarding what it incentivizes, that are necessary to explore before people jump on the outcome bandwagon and fully abandon process accountability.

Outcome accountability is beneficial in incentivizing realization of expected outcomes when making decisions. There is experimental evidence showing that outcome accountability boosts performance relative to process accountability alone.¹⁹ However, this can ignore analysis of whether the decision itself was appropriate or not. The potential hazards of outcome accountability include the worsening of overall decision quality, increasing commitment to sunk costs, diminishing of complex thinking, impairment of attentiveness, and reduction of situational awareness²⁰.

In short-term decision-making problems, outcome accountability can lead to analysis paralysis due to uncertainty, or succumbing to cognitive bias, thereby worsening decision quality. Process accountability, in contrast, can help temper the temptation of cognitive bias, helping decision-makers navigate choppy cognitive waters short-term. Further, in the aforementioned experiment, process accountability was shown to promote more effective knowledge sharing, boosting performance of those observing the decision-makers’ actions.

Process accountability, although already not as popular in Silicon Valley, has its deficiencies worth mentioning, too. Process accountability can incentivize adherence to policies and best practices, even when they are not the best options in dynamic environments long-term. It is inherently less flexible than outcome accountability, making it difficult to improvise and incorporate feedback loops to inform better strategy in changing environments. For example, process accountability was shown to be far weaker than outcome accountability in augmenting pilots’ skill in navigating changing environments²¹.

Thus, a hybrid of outcome accountability and process accountability is optimal, balancing out weaknesses while not decreasing the respective benefits of each method. A hybrid of outcome goals and process goals should give teams the ability to remain flexible while ensuring knowledge transfer and inhibiting potential abuses of power. Importantly, this hybrid accountability can ensure that standard practices are met, but also encourage experimentation with novel strategies. This ensures collective knowledge is not discarded and adaptive prowess are not discouraged – both of which are essential components for designing secure systems and responding to incidents.

Creating stretch outcome goals can encourage innovation, allowing teams to stretch their metaphorical wings and attempt ambitious plans – tempered with the need to still be able to justify process. Stretch goals tend to also be more fun, satiating people’s curiosity and desire to learning new things. For example, a security-related stretch goal might be to create a tool to automate asset inventory management, whereas the basic goal may be to perform manual asset inventory management.

Importantly, process goals should apply equally to infosec and to DevOps. Infosec should justify why they made a less business-friendly decision – helping curb the FUD-driven decision-making to which infosec is prone. DevOps should justify why they made a less secure decision – helping curb the tendency to treat security as an afterthought. By forcing each team to articulate their justifications, it allows the opportunity to, as the kids say, call out bullshit.

Goal Framing

Finally, how these goals are communicated is consequential to winning the coordinative game. Drawing from the aforementioned study involving goal conflict between curative or palliative care, there are a few lessons to glean towards how to set goals. First, the study found that participants who received messaging emphasizing the conflicting nature of the goals reported increased perception of goal conflict and decreased importance of palliative care, as expected²².

Second, the researchers anticipated that self-affirmation and self-reflection on values – with the goal of ameliorating cognitive dissonance associated with maintaining conflicting beliefs – would improve providers’ abilities to empathize with patients, thereby increasing the importance of palliative care. Instead, the opposite was shown to be true. Unfortunately, self-affirmation can also deactivate less valued or more difficult goals, becoming a reinforcement mechanism for moral hazard-driven beliefs.

These results certainly seem discouraging! So, what can be done? The key takeaway is that goals must be presented as complementary rather than conflicting, particularly when there is evidence to support it (as is true with the complementary nature of palliative and curative care). When considering infosec and DevOps goals, I have long argued that their respective goals bear far more similarities than differences²³. Empirical analysis from the most recent “2019 Accelerate: State of DevOps” report also shows that elite DevOps teams fix security issues earlier and faster than their less performant peers²⁴.

We must also include the ordering of goals in our calculus here. Sequential goal pursuit is inevitable given the relative scarcity of solutions that can accomplish multiple goals, and in light of the tendency for people to prioritize one goal over another. However, concurrent goal pursuit can still be encouraged. DevOps and infosec teams can make a list of their respective goals and perform an exercise to brainstorm where goals from each side might be achieved through the same means. As an example, tools designed to collect data for performance use cases are collecting data valuable for security use cases as well.

To avoid the “dilution of instrumentality” – the perception that the stone is less important in killing the two birds, because it can kill both concurrently – highlight objective information about a choice, tying its importance to each goal directly. For instance, a database monitoring tool can help accomplish both performance and security goals, thus running the risk of invoking the dilution of instrumentality. To re-anchor perception to reality, you can express how the tool relates to each goal specifically: collecting data on resource utilization for performance, and detecting abnormal query behavior for security.

Conclusion

The relationship between DevOps and information security must be healthy for the business to thrive. This relationship, like all relationships, requires work, and understanding it as a cooperative game involving information asymmetry can inform how we can work smarter to nurture it. By leveraging team reasoning, hybrid goals (outcome and process), and framing goals as complementary and concurrent, we become a strong contender for winning this coordinative game.

Total Funding Raised & the Latest Stage for each 2019 RSA Innovation Sandbox Finalist ($USD millions)

The median funding raised by all ten startups this year is $14.3 million (mean of $21.3 million), which still reflects a reasonably early stage – but it reflects a 36% jump from 2019’s median of $10.5 million. Last year’s winner, Axonius, was tied for the second smallest startup funding-wise; they had only raised a $4 million seed round until a week before the competition.

There are no startups with that sort of profile in 2020, as they are all past the seed phase and into at least Series A. The distribution of startups at the Series A phase is even more concentrated this year (80% of all finalists vs. 60% in 2019). We have an additional nominee at the Series B phase this year, too.

However, if startup maturity is measured through temporal age[1], we see a dramatic increase in variability. The median number of months is roughly the same (29.5 months this year vs. 27.5 last year), but the range is quite different: 10 to 138 months (yes, over 11 years old) in 2020 compared to 20 to 46 months in 2019.

Category-wise, there is a decent level of variability of the problems the nominees are tackling. By far the greatest concentration is in AppSec tools, although they consist of different approaches (including RASP, WAF, AST, and risk assessment). There are two finalists tackling the security of third-party SaaS applications. The rest include PII discovery, vulnerability remediation, anti-phishing, and security awareness training.

For those of you familiar with my work, you’re aware of the fact that I dissect and analyze buzzwords in infosec with some regularity. This year’s word-cloud certainly doesn’t disappoint on the buzzword front:

There were 24 investors across the most recent funding rounds for the ten nominees, with more overlap than last year. ClearSky is a lead investor in both AppOmni and INKY Technology. Costanoa Ventures is a participating investor in AppOmni and Elevate Security. Greylock Partners is a participating investor in Obsidian Security and a lead investor in Sqreen. This debunks my theory from last year that investors put forth a chosen startup from their portfolios, like movie studios do with the Oscars.

The full list of lead investors in these ten startups is:

• Blossom Capital
• ClearSky x2
• Costanoa Ventures x2
• DARPA
• Defy.vc
• FireBolt Ventures
• General Catalyst
• Greylock Partners x2
• Gula Tech Adventures
• GV
• Inner Loop Capital
• Jackson Square Ventures
• Mayfield Fund
• NEA
• Point Nine Capital
• Point72 Ventures
• SignalFire
• Silicon Valley Data Capital
• StoneMill Ventures
• TechOperators
• TenEleven Ventures
• Unusual Ventures
• Wing Venture Capital
• Y Combinator
• YL Ventures

How do these investors overlap with the judges? Well, judge Asheem Chandna is a Partner at Greylock and a board member of Obsidian (his colleague, Sarah Guo, is on Sqreen’s board). Judge Patrick Heim is an Operating Partner at ClearSky, a board member of AppOmni, and on Elevate’s advisory board (ClearSky colleagues Peter Kuper and John Cordo are on Inky’s board). Greylock has coinvested with Clearsky (Demisto) and GV (Censys, Obsidian). ClearSky has coinvested with Costanoa Ventures (AppOmni), Greylock (Demisto), GV (CyberGRX), and TenEleven Ventures (CyberGRX).

As President of Dell Technologies Capital, Scott Darling has coinvested with some of the notable VCs on the list above, including ClearSky (CloudKnox), General Catalyst (RiskRecon), Greylock Partners (Agari), and TenEleven Ventures (JASK). Neither judges Dr. Dorit Dor nor Paul Kocher have immediately obvious ties to any of the VCs backing the 2020 nominees.

All but one 2020 Innovation Sandbox finalist is based in the U.S. (the outlier is based in Israel). 70% are based in California, a huge jump from 40% in 2019. Maryland and Pennsylvania possess one nominee each.

As a final statistic, only one company’s founding team includes any female founders, a 0% increase from 2019.

[1] Not every startup gives the precise day they were founded, so I used a combination of Crunchbase and LinkedIn data (e.g., the start date the founder lists) to get as close as possible.

In contrast to prior years, I would say this year’s fiction list is weighted towards fantasy more than sci-fi. And, because I began a new vocational journey in a leadership position, my non-fiction books included business-y picks (unlike years prior). As always, I don’t provide ratings or reviews of each book here – I leave it to you to investigate them on your own.

If you’re looking for more science fiction, speculative fiction, or non-fiction recommendations, check out my 2018, my 2017, and my 2016 reading lists.

Fiction

2666 by Roberto Bolaño

An Unkindness of Ghosts by Rivers Solomon

The Brothers Karamazov by Fyodor Dostoevsky (re-read)¹

The Bird King by G. Willow Wilson

Certain Dark Things by Silvia Moreno-Garcia

Circe by Madeline Miller

The City of Brass by S.A. Chakraborty

The Devil in America by Kai Ashante Wilson

The Devourers by Indra Das

Empire of Sand by Tasha Suri

Everfair by Nisi Shawl

Ficciones by Jorge Luis Borges (re-read)²

Gideon the Ninth by Tamsyn Muir

Gods, Monsters, and the Lucky Peach by Kelly Robson

Gods of Jade and Shadow by Silvia Moreno-Garcia

Kingdom of Copper by S.A. Chakraborty

The Haunting of Tram Car 015 by P. Djèlí Clark

Mistborn trilogy by Brandon Sanderson

Nexus by Ramez Naam

No Longer Human by Osamu Dazai

Rosewater by Tade Thompson

Spinning Silver by Naomi Novik

Storm of Locusts by Rebecca Roanhorse

To the Lighthouse by Virginia Woolf

Trial of Lightning by Rebecca Roanhorse

Uprooted by Naomi Novik

Waste Tide by Chen Qiufan

Non-Fiction

Cheating and Deception by J. Bowyer Bell and Barton Whaley

Good Strategy/Bad Strategy: The Difference and Why It Matters by Richard Rumelt

Her Majesty’s Spymaster: Elizabeth I, Sir Francis Walsingham, and the Birth of Modern Espionage by Stephen Budiansky

The Inconvenient Indian: A Curious Account of Native People in North America by Thomas King

Lost Enlightenment: Central Asia’s Golden Age from the Arab Conquest to Tamerlane by S. Frederick Starr

The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change by Camille Fournier

On my vacation to Namibia earlier this year, I caught up on podcasts during the long stretches of driving (albeit in breathtaking scenery). One episode in particular jolted my mental juices – the EconTalk episode featuring Dr. Anja Shortland discussing her book Kidnap. The fascinating chat between Dr. Shortland and host Russ Roberts delved into the incentive mechanisms between kidnappers who demand ransom and insurers, and the economic paradigm that results.

Naturally, there are implications for ransomware, the digital counterpart to physical ransom. In particular, I believe the role cyber insurance should play deserves closer examination, but there are other spicy takes that fomented as I listened to and digested the podcast episode. This post will explore my thoughts on how the economics of physical ransom translate to digital ransom, and how we as an industry might want to reconceive our current approaches to considering and dealing with ransomware – and the criminals who run ransomware campaigns.

The Shadow of the Future

First, let us set the stage with a discussion of the “shadow of the future” and how it applies to the ransom market. The “shadow of the future” is a game theoretic concept that explains how people will behave differently if they believe they will need to interact with their current counterparty again (“repeated games” in game theory lingo). This belief encourages cooperation between counterparties, as they will play much nicer in the hope of receiving better treatment in future interactions.¹ Thus, the future lingers like a “shadow” over current interactions.

In the kidnapping for ransom world, criminals cast a shadow of the future. If they desire to kidnap again, they want to “behave” in the immediate interaction to help them in their future business. If kidnappers demonstrate they will honor their demands upon receipt of a ransom, then future victims will be more likely to pay ransoms, believing that promises are more likely to be kept. This, Dr. Shortland surmises, is why 97.5% of kidnapping cases “go right” – which is better than the success rate of many legitimate transactions.

An example Dr. Shortland gives is that Somali pirates, upon receiving ransom for multimillion-dollar sea vessels, are repeatedly seen to leave the vessels and not re-hijack them again. The exchange of hijacked sea vessels for cash consistently goes right for all parties involved – even in a situation that is rife with mistrust and conflict. The Somali pirates are now trustable in a twisted way, as owners of sea vessels know that they will indeed have their ships returned reliably if they pay the ransom. As Dr. Shortland points out, this shadow of the future applies to kidnapping gangs within cities as well, through the power of local gossip.

How does the shadow of the future apply to ransomware? It certainly should apply, as few attackers run ransomware campaigns against only one target, thus creating the opportunity for future interactions with victims. Victims, at least in theory, would be more likely to pay ransoms to criminal groups who were known to reliably decrypt data, especially those who do so without any data loss.

Unfortunately, the data on ransomware and success rates (on both sides) is limited, particularly when getting as granular as specific ransomware types. At first blush, the statistic from the first quarter of 2019 that 96%² of ransomware payments were successful seems to match the high success rate of kidnapping cases. However, that just represents the number of victims who received a decryption tool. The recovery rate in the same survey ranges from 80% to 100%, depending on the ransomware type. Other surveys suggest the data recovery rate is as low as 66%³ to 75%⁴.

These statistics suggest a far more inefficient market for ransomware than exists for physical ransom. Additional supporting evidence of this inefficiency arises from the mismatch of ransomware campaigns with the most reliable data recovery and campaigns with the highest ransom demanded. Ryuk requests $286,557 on average⁵, despite their approximately 80% data recovery rate, due to targeting larger enterprises. Grand Crab, in contrast, demands just under $8,000 but offers an approximately 100% data recovery rate. This seems like a far cry from a “nice equilibrium” as exists in the physical sphere.

Encouraging Better Attackers

This kind of illegal activity is an inevitability – neither physical nor digital ransom can be fully prevented. Therefore, we must optimize given the constraints of this reality. Just like you want to encourage kidnappers that do not kill their victims, we want to encourage attackers that do not lose ransomed data.

With this grounding aspiration in mind, let me offer you my ghost pepper-level take. There is some level of attacker activity that represents a healthy equilibrium, and defining that equilibrium (perhaps “only teams that can discover and weaponize 0day”) is healthier than trying to stop attacker activity. That is, if we can eliminate the script kiddies and #basicbitch⁶ attackers who lack the operational resources to ensure data fidelity when conducting digital ransom, organizations will be better off – even if they are still hit by sophisticated attackers who will receive payments but reliably facilitate data recovery.

As Dr. Shortland cited, the presence of armed guards in the Niger delta creates a “nice equilibrium,” because it, in essence, raises the cost of attack. Disorganized, resource-constrained street gangs cannot pursue physical ransom as one of their normal activities when they must contend with armed guards. Only more sophisticated criminal organizations will possess the means to pursue physical ransom – and they are vastly more likely to adhere to the aforementioned shadow of the future, leading them to behave professionally and responsibly.

The Role of Cyber Insurance

How can we encourage this kind of equilibrium? If we look to the physical ransom domain, insurance companies play a critical role. Kidnap insurance creates stability in the market, reducing the friction between “buyers” (the victim’s representatives) and “sellers” (the kidnappers). Of course, it would be remiss of me not to acknowledge the dark side of insurance – the creation of macro-level moral hazard. Kidnap insurance’s very existence allows kidnapping to be an especially profitable ongoing activity. However, the safer ends – based on current evidence – seem to suitably justify the means.

The insurers’ goal, in the kidnapping market, is to eliminate stupid or irrational kidnappers from the market – those who make errors in process or judgment, such as cutting off fingers to hasten payment of ransom. Likewise, cyber insurance’s goal should be the same, to eliminate the skidiots⁷ who could accidentally brick systems or delete data and to encourage more sophisticated attackers who are true to their promises and conduct their operations reliably and professionally.

One can envision a world in which a cyber insurance company negotiates a flat rate to receive the decryptor, then sending a bonus if all data is recovered. Such a scheme would incentivize attackers to maximize victim data recovery upon receipt of payment. This, of course, relies on the “shadow of the future” – but it is in the best interests of the victims, cyber insurance firms, and attackers to develop the trust that full payments will be received and data will be fully recovered.

You may be thinking to yourself, “This feels really icky – aren’t the attackers winning here?” Attackers will continue to be a reality, as, likely, will ransomware. By accepting reality, we can depart from the unrealistic goal of “eliminate all ransomware attacks” to “maximize reliability of data recovery in ransomware attacks.” Part of maximizing reliability is encouraging better attackers, which is done by raising the cost of attack.

Naturally, there are caveats. Both physical and digital ransom are examples of markets in which imperfect information is actually advantageous to the “good” side, as insurance companies benefit from information being withheld from criminals. Accordingly, insurance companies should withhold the extent to which individuals are insured to prevent victims from divulging how much money the attackers could receive. The attackers will logically ask for the maximum ransom payment based on their expectations – so it is better to minimize their expectations as much as possible.

As Dr. Shortland advises, the goal is to “manage the size of the towel the [attackers] think they’re squeezing.” We – ideally, through insurance companies – must convince the attacker that they have reaped everything they could from their attack. Therein lies the beautiful pragmatism of this strategy: we focus on the elements we can control (perceptions) rather than the elements we cannot (motivations, resources, etc.). Yes, implementing proper backup and recovery solutions is within defenders’ control, too, but as we can see from the seemingly weekly headlines about ransomware incidents, we need a sane Plan B.

Conclusion

In general, there is much information security can learn from domains which have a rich history of experimenting with solutions to similar problems. Physical ransom, in which a rather efficient market between attackers, victims, and insurance companies exists, is a pertinent exemplar for how infosec can more efficiently deal with ransomware.

While it may feel uncomfortable to accept a healthy level of malicious activity, at a certain point, we must become pragmatic rather than wallowing in sententious idealism. We can never fully prevent attacks, and that goes for ransomware as well. But we do have a chance to encourage more intelligent attackers – who operate professionally, incentivized by ongoing business interests – so that the ultimate impact of ransomware is less deleterious than what transpires under the claws of disorganized, incompetent attackers.

This may not be the safer world we imagined, but, as Machiavelli advised centuries ago, “Prudence consists in knowing how to distinguish the character of troubles, and for choice to take the lesser evil.”⁸ We owe it to those who depend on our expertise to think more boldly in how we can build a sustainable equilibrium in a world – digital and otherwise – that will always be troubled by aggressors.

Adopting the “chaotic infosec” philosophy (the application of chaos engineering to information security) can influence those who build and secure systems to operate more like attackers – that is, to be more risk averse and to more quickly update their mental models given new inputs. This post will explore what exactly this means, and why it represents a valuable mindshift for organizational security.

How does Prospect Theory apply to security?

While I encourage you to read my prior post on applying Prospect Theory to information security, I recognize it is a bit long. I will thus summarize its relevant points here.

Humans make decisions by setting a reference point (their view of the status quo) against which they measure the decisions’ potential outcomes. Empirical evidence shows that people generally prefer options that provide a small but certain gain rather than options that provide a larger but uncertain gain. They also generally prefer options that provide a miniscule chance of losing nothing (with a larger chance of losing a lot) rather than options that provide a certain chance of losing less.

These results, which are modelled by Prospect Theory, suggest that people are risk averse when making decisions with positive potential outcomes (when they are in the “Gain Domain”), and risk seeking when making decisions with negative potential outcomes (when they are in the “Loss Domain”). The further people get away from their reference point (again, their perceived status quo), these trends exaggerate. People who experience heavy losses become even more risk seeking in an attempt to jump out of the figurative hole, and people who experience substantial gains become even more risk averse to preserve their winnings.

My hypothesis was that defenders set their reference point based on a status quo where their organization is perceived to be secure and uncompromised (to simplify a bit). The nature of enterprise defense means that defenders will operate in the Loss Domain as a result – compromises are inevitable, as are failures to maintain a level of security posture that defenders find acceptable. Attackers, in contrast, operate in the Gain Domain – because their reference point is their current level of compromise, and, generally, they are likely to positively further their position of pwnage.

As a result, defenders are more risk seeking, leading them to adopt more speculative solutions to attempt to reach their reference point of perfect prevention instead of adopting more basic solutions with larger probabilities of success but a perception of being less likely to stop a big, sexy attack. Attackers, on the other hand, are more risk averse, moving more cautiously to achieve their goals, opting first for inexpensive methods before moving to expensive methods.

How does chaos transform reference points?

Applying the principles of chaos engineering to information security, as outlined in my Black Hat USA 2019 talk, changes the reference point for defenders. If you extend the chaos engineering philosophy of “things will fail” to “things will be pwned,” then the status quo for security teams becomes the assumption of compromise.

For traditional enterprise security programs, mapping Prospect Theory to security shows a state of being that is fragile to reality. This state anchors those involved in enterprise defense to the Loss Domain, as shown in the graph below, encouraging risk seeking and reactive behaviors.

In contrast, applying chaos engineering to security transforms security’s Prospect Theory graph into being resilient to reality, encouraging risk averse and strategic behaviors. A dearth of significant compromises at your organization now feels like a gain, as shown in the graph below, incentivizing the preservation of that gain – which can be achieved in part through some of the strategies and testing I enumerated in the Black Hat talk (see the “A Phoenix Rises” section).

As demonstrated in these graphs, by assuming “things will be pwned,” there is really only upside – so those who architect and secure their organizations’ systems can begin feeling less defeated and instead feel proud of their efforts. Implementing security “basics” can feel unrewarding, but successfully increasing the cost of attack deserves a sense of accomplishment. While I use the term “stopping” on the Gain Domain side of the graphs for brevity, I do not literally mean preventing attacks by skiddies or APTs from happening. Rather, I mean stopping these attacks from negatively impacting your organization, which is ultimately what matters.

Just as failure-based metrics, such as Time Between Failure, inhibit innovation and make systems more brittle, allowing an organization’s security contributors to languish in the Loss Domain similarly hinders resilience and, ultimately, organizational performance. Instead, a success-oriented metric like Time to Recovery promotes innovation and resilience – and operating in the Gain Domain incentivizes similar behaviors. Therefore, switching your reference point from “maintaining secure systems” to “things will be pwned” – despite seeming like trivial semantics – has the potential to subtly transform how your teams design systems.

Conclusion

The most effective way to engender cultural change is by changing what people do, not what they think. By altering the security mental model through this path of chaos, you change behavioral vectors – harnessing people’s embedded wetware – to promote the type of strategic, innovative, and perceptive decision-making that we so desperately need to build and maintain secure systems. Adopting the mantle of chaos through the philosophy of “things will be pwned” can reorient team perception to operate in a more strategic, less frenetic fashion by re-architecting their relationship between risk and reward.

What type of vendors are showing themselves off in the Business Hall? Are they mostly startups?

How many vendors from 2018 are exhibiting again in 2019?

67% of vendors who exhibited in 2018 are exhibiting in 2019, while 33% are not. Of the 31% of VC-backed security vendors who exhibited in 2018 but are not in 2019, some are vendors who were acquired (e.g. Twistlock, ProtectWise), while many of the others are well-known to be “long in the tooth” (e.g. Bromium, CounterTack). Others were still funded recently (e.g. Digital Guardian), so it’s possible they calculated a lack of ROI from the event.

An interesting statistic is that the VC-backed vendors who are exhibiting again received their latest VC infusion more recently than those who are not still exhibiting. For VC-backed vendors exhibiting again in 2019, the delta between their last funding round and Black Hat USA 2018 (which was August 2018) was 482 days (a mean of April 2017). For VC-backed vendors not exhibiting again in 2019, the average was 622 days (a mean of November 2016). This might support the notion that vendors who have not received VC funding for awhile are less financially healthy, and therefore unable to pony up the cash for another booth at Black Hat.

Outside of VC-backed vendors, around half of the publicly-traded non-security vendors from last year decided not to exhibit this year. 8 companies that were acquired decided not to exhibit this year (for instance, Phantom presumably now will be present at the Splunk booth). Around half of the privately-owned vendors from last year decided not to exhibit. All of the publicly-traded security vendors are exhibiting again this year, save for Gemalto (who knew they were being acquired by Thales). Perhaps not surprisingly, DarkMatter decided not to show their face at BlackHat this year. Can’t imagine why.

How many VCs are dedicated to investing in infosec?

There were 16 investors who led 4 deals or more, which is down from 21 last year. 25 venture capital firms led 3 deals or more, which is a convenient number to remember as a proxy for the amount of VCs at least somewhat dedicated to infosec investing. Below is the Top Ten list, which includes all VC firms who led at least 5 funding rounds in this year’s exhibitors:

What venture stage are vendors & how much capital are they raising?

Supporting evidence for my theory is that the median dollar amount raised in Series A deals increased 45% for exhibitors who raised after August 1, 2018 vs. those who raised before then. A counterpoint is that Seed and Series B median deal sizes were down from 2018 (-15% and -4%, respectively). Late-stage deals boomed in median dollar amount raised, increasing 32% for Series C, 40% for Series D, and 119% for Series E rounds.

The median amount raised across all stages increased 38%, from a median of $17.0 million in 2018 to $23.5 million in 2019. I use the median here since the mean is skewed by some absolute unit late stage deals since August 2018. Nevertheless, the mean amount raised across all stages increased 89%, from $21.6 million to $40.8 million.

How many Private Equity firms are backing companies on the floor?

There are 29 companies backed by 20 total Private Equity firms in the Business Hall this year. Last year, there was roughly the same number of companies (30), but significantly more Private Equity firms (27). It is still true that the vast majority (85%, up from 81%) of Private Equity investors are one-off investors, and only 3 Private Equity firms invested in / acquired 2 or more security companies. Dominating that figure is Thoma Bravo, who has 5 portfolio companies exhibiting in 2019.

How fresh is the Innovation City?

True to its promise as a bastion of “startups and emerging companies,” 91% of the VC-backed residents of Innovation City are Seed through Series B stage – way more than the 61% present in the total population. The median amount of the latest round of funding was $10.0 million among Innovation City residents, in contrast to the total population’s median of $23.5 million.

Fascinatingly, 12 of the 44 Innovation City residents were also residents last year – over a quarter of the population. I personally assumed they rotated vendors to keep things fresh for attendees attempting to scout the most cutting-edge vendors of the flock, but I was clearly pretty wrong.

How U.S.-centric are the vendors at Black Hat?

Within the U.S., California makes up 43% of all U.S.-based vendors presenting, and over half (53%) of VC-backed startups in the Business Hall. After California, Massachusettes, New York, and the D.C.-region dominate, though Texas is ascendant.

Final note: I have no idea what is happening with Brexit (does anyone?), but given the UK has more representative companies than the definitely-EU-countries combined, I kept the UK separate.

A few notes on the data

Vendors were retrieved from the Black Hat 2019 Business Hall Floorplan, and exclude any federal agencies, educational organizations, or nonprofits. I also excluded any companies in the Career Zone, as they are aiming to recruit security talent rather than sell products or services.

Location and funding information was collected through Crunchbase. There may be errors if a company’s Crunchbase page is not up to date.

Despite its seeming absurdity and superficiality, the theory of Darth Jar Jar can serve as a poignant parable for security innovation. For those unfamiliar, the notion of a Darth Jar Jar springs from a meticulously researched fan theory from the Star Wars subreddit. While I do not wish to spoil the breathtaking beauty of the fleshed-out theory, the underlying legend is one of an ostensibly bumbling fool who, in reality, is an insidious puppet master full of cunning and strength.

What lessons from Darth Jar Jar can we glean and apply to information security? I argue there are a few innovative strategies one can postulate on both the offense and defense sides, which I will explore within this post.

Darth Jar Jar for Offense

For an attacker to fully become one with Darth Jar Jar, they must be content playing a fool. Just as Darth Jar Jar appeared to be clumsy to lead to his underestimation, attackers should likewise appear to be sloppy to lead to their underestimation by defenders. By conducting purposefully noisy and messy operations in one part of a system, attackers can direct defenders’ attention away from the attack that is truly transpiring right under their cocksure noses.

There already exist public examples of attackers embracing the spirit of Darth Jar Jar. One of my favorites is the misdirection employed by attackers back in 2013, in which they conducted a DDoS to cover their tracks when exfiltrating funds out of corporate accounts. A further three banks were hit by the same approach later that year – a low-powered DDoS attack that captured defenders’ attention, while fraudulent money transfers happened concurrently.

Additionally, the Nigerian prince scam is arguably a long-term ploy very much in the vein of Darth Jar Jar. Scammers specifically use poor spelling and grammatical errors to weed out victims who would be less trusting. Those who are not deterred by lacking language are more likely to believe in the tale the scammer is spinning – and thus more willingly depart with their money. The clumsiness is intentional to lure precisely the right victims into the attacker’s maw.

I collected and brainstormed a few additional offense strategies for attackers who seek to replicate the brilliance of Darth Jar Jar:

Meesa so noisy!

One option is to flood EDR systems with noise so that alert fatigue sets in on the part of the defender, letting subtler attacks slip through. The goal is to create noise for events that will receive a higher priority flag within the tool, such as purposefully clumsy kernel exploits – no team with a hundred critical-priority alerts (often called “P0s,” for priority-zero) would clear them in time to catch your sneakier attack.

Even cleverer would be to throw sloppy attacks over a period of time, while inserting the exact same quieter traffic that you plan to leverage in your real attack, so that the machine learning systems begin baselining it in. After all, Darth Jar Jar maintained his foolish façade for more than just one day!

EICAR-CAR Binks

A common strategy in security detection is the notion of “alert on the first bad thing, then stop processing” so that there is not a flood of alerts. Thusly, an attacker could send EICAR in the same data stream or file as a real attack so that defenders see the EICAR alert and dismiss it. Then, the darker, sneakier underlying attack will go unnoticed – just as Darth Jar Jar used rambling babbling during the entirety of The Phantom Menace to obscure his devious speech that directly led to the dissolution of democracy.

Ex-squeeze the data outta the network

During the rescue of Queen Amidala, Darth Jar Jar proved to be a master of diverting the attention of his enemies to take them by surprise. In the realm of critical infrastructure, an attacker could send a large volume of fake location update requests from SIMs, which would certainly attract the attention of defenders at any telecom provider.

While defenders remain distracted and scrambling, the attacker could then infiltrate the internal telecom network by plugging into an eNodeB and moving horizontally to compromise elements such as the MME or even the HSS (think: the master user database). Darth Jar Jar would absolutely approve of deflecting defender attention to outside of their own network to conceal the true threat from within.

Darth Jar Jar for Defense

Just as attackers must play the fool to follow the wisdom of Darth Jar Jar, so must defenders. Luckily, many defenders are accidentally foolish, making purposeful foolishness all the more likely to lead attackers to underestimate defenders. While I usually strongly advise against #yolosec strategies, pretending to deploy a #yolosec strategy can perfectly replicate the sinister subterfuge of Darth Jar Jar.

There are fewer public examples in the realm of defense that highlight the gloriousness of a Darth Jar Jar approach. The closest might be the use of honeypots or canarytokens, such as a webserver that appears to be configured in a thoroughly #yolosec manner, creating irresistible temptation for attackers to explore them – and thus alert defenders to the fact that someone is very intrigued by their data.

In ths vein, there are a few Darth Jar Jar-esque defense strategies I collected and brainstormed:

Oh, no! Yousa connection is slow

Once you detect attackers within your network, begin throttling their connections to satellite-link speeds at random. The goal is to make it seem like an unstable system to test how the attacker reacts and alters their strategy – just as Darth Jar Jar “clumsily” handled a booma during the Battle of Grassy Plains to take down an armored assault tank.

Where wesa executing?

Darth Jar Jar never revealed to his Jedi companions that they were succumbing to his duplicity. Likewise, defenders can avoid revealing that they have not only caught attackers, but are bamboozling them.

For instance, when defenders catch an attacker attempting to pwn a production instance, they can migrate that instance out of production, setting up all the same network connectivity so no change is perceived by the attacker. Then, defenders can begin logging and monitoring everything for later learning (and to inform broader investigation) while spinning up a replacement instance in production to avoid downtime.

Mmm, dissen loverly data

Just as Darth Jar Jar tricked the Jedi into travelling through the core of a planet to make himself indispensable, defenders can trick attackers into going down a heavily monitored path to make it inevitable that they will be caught. For example, defenders can sprinkle cleartext AWS credentials in places that lead to alert traps. Or, defenders can “accidentally” reveal credentials attackers would need to access a seemingly sensitive system – when in reality, there is no valuable data residing in the system, just deep monitoring present.

Ultimately, no matter which side of the infosec game on which you fight, I hope that you will adopt the following mantra to let the dark side flow through you, elevating your #basic strategy to one of subtle manipulation and insidious deception – “What would Darth Jar Jar do?”

Reflecting on my existential crisis during RSAC, I tried to distill what exactly was so troublesome about the conference. The expo floor was less two separate halls, as per years prior, and more like Mordor, with a befouled sprawl connecting Minas Morgul and the Black Gate — but instead of orcs and Uruk-hai, vendors crammed the hallways that used to serve as open breathing space.

There was a dizzying sense of perpetual motion, like a spinning top just barely staying upright. Quiet was seemingly anathema — the pestilential cacophony of canned speeches and whizbangs and desperate pleas for attention was unavoidable.

In this vainglorious feast by the information security industry in dedication to itself, experiencing an existential crisis is perhaps an inevitability. The ultimate purpose of information security — ensuring an organization can thrive despite digital risks — was obscured beneath the thick layers of cheap pens dimly glinting, XL men’s t-shirts boldly proclaiming trivialities, and the hollow promises of soothing your fears one badge scan at a time.

But this alone can be rationalized away and not lead to a crisis of faith in the importance of our collective work. These criticisms are true for most trade shows; they are inherently loud and sales-y. What makes the RSA Conference burrow into the brain like a parasite greedily devouring all hope is that the diabolical song and dance is not helping beneficial solutions fall into the right hands.

RSAC is largely successful due to network effects — because everyone seemingly attends, everyone else attends — making it a good place to catch up with a lot of people at once. This reality makes its issues even more problematic; the four that personally drove my distress are:

1. Hyperbolization of FUD
2. Disconnect between products & personas
3. Misunderstanding of personas
4. Promotion of security as a blocker vs. a compromiser

Hyperbolization of FUD

In a banquet of distasteful and inane catch phrases and bullet points, one gave me acid reflux like no other—it exemplifies what I am calling the hyperbolization of fear, uncertainty, and doubt (“FUD”). A large EDR vendor’s advertisements around town roughly stated, “It takes a lifetime to build your career, and 5 seconds to lose it.”

There was no shortage of FUD around threats, but this tagline directly stokes the fear that someone’s professional life will be over if they let an attacker slip by. It’s tasteless and mostly incorrect, and I find it appalling to imply that someone’s life will be ruined if they don’t buy your product. I also find it lazy; if you can’t sell your product without scaring people to such a degree, perhaps you should make your product inherently matter more to them.

Part of the issue might be that the industry is generally poor at realistic threat modelling, making these doom and gloom buzzphrases compelling. While it’s too much to hope that all vendors could help their customers threat model responsibly, I believe it’s a reasonable expectation to not aim directly at personal fears and not make up scenarios that lack precedence in history or logic. If a vendor must create dystopian sci-fi to justify use of their product, they are doing it all wrong.

Disconnect between products & personas

My first supposition with regards to the persona problem was a disconnect between buyer and user personas. Specifically, that narratives around usability seemed to be keeping the buyer (CISO) in mind, rather than the people who would actually use it (individual contributors (“ICs”). Upon reflection, I think it’s worse than this — that there is a disconnect between the buyer personas and the vendors’ target audience.

By this I mean that the marketing tactics, highlighted characteristics, even the words used all feel targeted towards other sales and marketing professionals, or perhaps venture capitalists (“VCs”). During the conference, I spoke with a large swath of practitioners ranging from CISOs to managers to senior ICs to more junior ICs, and none of them found the booths enlightening or particularly worthy of their attention.

This begets the question — for whom is all this marketing? My prior assumption was that vendors would target the buyer persona (generally the CISO or director/manager-level) at the very least, since they are the people spending the budget. Ideally vendors would also target ICs, who are the ones actually using the product, and whose thumbs up is generally required by the buyer.

But given none of those personas felt addressed by vendors at the RSAC expo hall, who did? To be perfectly frank, I’m not entirely convinced of the answer, but my hunch is that:

1. VCs are dictating marketing/value propositions too much, particularly given they are generally disconnected from customer viewpoints
2. Marketing people are generally too disconnected from customers & don’t really understand the relevant personas
3. Infosec is generally horrendously bad at understanding the spectrum of relevant user personas

Misunderstanding of personas

Point #3 above leads to this observation, which is that vendors overall seem to egregiously misunderstand the personas for which they are allegedly building their products.

As I discussed in my TechCrunch article, vendors are building tools and determining the specific problem being solved after the fact — often leading to the need to convince customers that the vendor-invented problem is relevant to their organization. This trend of focusing on tech rather than customer problems extends, I think, to vendor-invented personas, as well.

If you were judging solely based on the RSAC vendor floor this year, you might think the most important user persona in infosec is “SecOps.” There’s little differentiation visible in this “persona” between a SOC analyst straight out of school analyzing low-priority events vs. a SecOps engineer who writes automation scripts for things like distributed alerting — not to mention a SecOps manager vs a SOC manager and the chromatic variation around all of these titles. And, is their purview just DFIR or other responsibilities, too?

This isn’t to say generalized personas aren’t useful — but I’m wondering if vendors are now treating SecOps as the “person who deals with security events.” If so, then most people in infosec are kind of SecOps depending on how you define “event,” which would thus render SecOps a meaningless term given how different everyone’s workflows are across the range of roles.

Additionally, there were impressively lazy attempts at catering to the DevOps and so-called SecDevOps personas. Security vendors seem to think that making their product available via API means they “integrate with DevOps workflows,” which is either amazingly apathetic or oblivious.

There was also lip service paid to working with existing CI/CD pipelines, but then security vendors still expect DevOps people to go through 20 additional hoops, not realizing that they simply won’t. For instance, please don’t claim you are DevOps-friendly while asking them to install a kernel module on every machine they actively use.

This leads to my assumption (and into my next point) that security doesn’t realize how immaterial they are relative to a team (DevOps) that can justifiably argue that they support revenue-generating activities. And, what’s worse, vendors provide little support for their customers to fight for security’s inclusion in the conversation.

It as if vendors expect that by saying “we secure the development lifecycle!”, security practitioners can convince the organization to install their product. This notion of a security team having the keys to an organizational steam roller is, of course, pure fantasy.

Promotion of security as a blocker vs. a compromiser

Finally, I think infosec is largely ignoring an important emerging shift, which I believe is inevitable — the transition from security as the “no people” to enablers of the business. Enterprise security only matters to the extent that it is helping preserve the company’s ongoing operations. Anything beyond that feels largely like intellectual vanity to me (this is precisely why I’ve been evangelizing the notion for a few years now).

How does this play into RSAC? I argue that the most successful security vendors of late are about removing barriers, in contrast to many security people believing barriers are worthwhile aids in their infosec crusade (and I also suspect that creating organizational barriers provides significant vocational fulfillment among a chunk of security professionals).

To wit, zScaler consolidated old products and made it easier for the organization to access resources without the tedious VPN dance. Okta likewise streamlined access and made a lot of enterprise workflows simpler. Both are now trading at delectably rich multiples (both above 20x EV/Revenue) — a victory even beyond the fact that they are some of the few information security startups to IPO in recent years.

Ultimately, anyone can say “no” to something —but just saying “no” isn’t actually solving a problem. Figuring out a compromise, like preserving or even improving UX while still ensuring an organization’s security, is a hard problem — the type of problem which should be most intellectually fulfilling.

Security will keep being dismissed by other parts of the organization until it lets go of finding fulfillment through security righteousness and instead finds fulfillment by finding an elegant way to enable the business while still reducing its risk.

One of my favorite examples to cite is John “Four” Flynn and the tale of implementing 2FA on SSH at Facebook. The security team conducted product-like user research interviews across engineering teams to figure out how SSH was being used — essentially mapping user workflows. The security team’s goal was to add 2FA to SSH, but instead of ramming it through like petulant ayatollahs, they sought to understand the user perspective and determine a solution that would not add friction for engineers.

It was a hard problem, but with a huge payoff; now the engineering teams can trust that security isn’t just trying to make their lives more difficult for sport or quasi-religious fervor. This means the relationship can be more like a partnership, rather than a political battle — the sort of battle security practitioners allegedly detest (likely because they tend to lose it).

Conclusion

These issues are not engendered by one constituent of the industry — they just all happen to notably bubble up like a tar pit burping methane in the harsh fluorescent spotlight of RSAC. It is the failure of culture among practitioners, vendors failing to understand their customers’ needs, founders going for cash grabs, and VCs encouraging the noxious sleaze and bamboozlery.

All of this comes, perhaps, from a reticence towards doing the harder, right thing and instead taking the easier path — the one that harvests confusion and fear to seize success that mediocrity could not earn otherwise.

I speak a lot about incentives, and, in fairness, there is an abundance of incentives rewarding this mediocrity, but far fewer promoting the more difficult path. CISOs don’t want to speak out against vendors and, in fact, benefit when they are seen as essential in navigating not just the threat landscape, but the vendor landscape as well. Vendors can still find decent M&A exits that make founders and investors happy enough, even if they sell solely within their professional networks and don’t ever find true product/market fit.

And if VCs make enough money from this buffoonery, why should they bother to understand the customer personas better to inform their investment choices? Many VCs have CISO friends, but I know from private conversations that these CISO friends often view the VCs as useful fools who can help them gain advisory or board positions.

If it sounds hopeless, well… I’m not sure it isn’t. But I refuse to give into nihlism. There are absolutely those of us who are fighting to change things, but there is a lot of entrenched power which benefits from keeping these dynamics the way they are in information security.

It will take those willing to risk their power to speak out in the truest form of thought leadership there is. Speaking into a warm and fuzzy echo chamber isn’t thought leadership; bravely challenging the status quo, armed with evidence, is.

We can keep the corporate-friendly cerulean and navy aesthetic, the blustering loudness, and yes, even the free pens, but we need to dedicate these efforts not to the thrill of our industry finally being considered “cool,” but to solving hard problems and protecting organizations in the way they need.

I surveyed 100 companies’ websites[1], the vast majority of which are exhibiting at RSAC and possess VC funding. I did not include any of the large security vendors[2], who probably could populate their own bingo cards across their mastodonian websites.

The idea is to take this with you to RSAC or any other vendor halls at information security conferences this year to see how many times you can win bingo at a single vendor booth! For more fun, try out my Cyber Tagline Generator script to create your own maniacally terrible buzzword salad (then @ it to me on Twitter).

Without further introduction, here’s the bingo card in all its glory — read on if you want more analysis on the stats:

The top word by far this year was automated and its variants — nearly three quarters of all companies used it on their sites in one way or another (e.g. automatically, automation, automates, etc.). There were a few repeats from prior bingo cards, perhaps proving my natural acuity for sensing the buzziest buzzwords. The following table of the top 25 buzzwords (the ones on the bingo card) includes the number of companies who cited the buzzword, along with whether the buzzword was on prior bingo cards:

Which buzzwords are on the rise?

Let’s start with the words on the bingo card itself. You can’t just enable security people anymore, you must empower them. Seemingly a reaction to CISOs through SecOps analysts complaining about the complexity of security tools, simple, simplifies, and simplified are being used to (proactively ;) assuage concerns.

Allegedly, security professionals now want to discover things, and I suppose with most data lakes being more akin to data swamps, the predilection for adventure that discovery implies is required. And, taking a page from the DevOps world, orchestration is peppered around enough now to create a veritable symphony of infosec startups orchestrating away.

Not quite making it to the bingo card, but still heating up, is collaborate and collaboration. Who knew that infosec teams wanted to work together? And if your security product isn’t optimized, what are you even doing? Note that you do not have to say for what your product is optimizing, just that it is, in fact, optimized.

Finally, solutions for runtime security are growing, which basically is just saying it doesn’t break the computer as it is computing. The fact that this assurance must be stated at all says more about the infosec vendor situation than perhaps even a long thought piece can.

Which buzzwords are starting to fall?

Hunting / hunt, most frequently used with “threat” before it, just barely missed making the Infosec Buzzword Bingo card again this year. I anticipate that it’ll fall even further by next year as the category morphs into SIEM 2.0. While behavioral is still holding strong, anomalies is beginning to wane — it’s much sexier to say you have behavior-based machine learning or AI instead.

As far as threats, they are notably less sophisticated, and less found on the dark web or in IoT devices. You def don’t want to talk about your product as a single-pane-of-glass anymore (try intuitive instead, which is on the rise). And, cloud-based is becoming less relevant as most security solutions move to a SaaSy model. If anything, companies should now specify when they aren’t cloud-based.

Which buzzwords are the weirdest?

Most of the weirdo-words are only used in a handful of companies’ marketing spiels, thankfully. But, a full seven companies used real-world, which, I mean — as far as I know, we aren’t trying to secure hypothetical worlds? I’m being purposefully obtuse (in the Dostoevskyan-fool spirit), since I do understand that too many solutions catch bad stuff only in theory without rigorously testing against what attackers will actually do (or without even really considering this during the product’s conception). But, its usage still makes me sad.

Another odd buzzword was holistic, also cited by seven companies, which is perhaps the most credible buzzword due to its close association with essential “healing” oils. However, the one I hate the most by far is quantum-resistant. For my sanity’s sake, I am grateful only one company chose to use that term.

[1] I scoped it to the websites’ landing and product/platform pages (e.g. no blog content).

[2] When I say “large” security vendors, think those who are publicly traded, are more than ten years old, or who have entire product “suites.”

Total Funding Raised & the Latest Stage for each 2019 RSA Innovation Sandbox Finalist ($USD millions)

The median funding raised by all ten startups is $10.5 million (mean of $10.3 million), which makes sense for an early stage-flavored competition. Additional analysis is required to compare funding levels of finalists from prior years to see if there is a correlation with those who win the competition.

The distribution of startups by stage is also consistent, with the highest concentration at the Series A stage. Of course, another way to determine startup maturity is through actual temporal age. The median number of months[1] since the finalists’ founded dates is 27.5, equating to roughly 2.3 years. The eldest is just shy of four years old.

Category-wise, there is a healthy distribution across sub-sectors. The highest concentration is in DevSecOps-related tools, which range from detecting attacks in modern infrastructure to “API security.” There are also two finalists tackling data protection/privacy. The rest include one startup each tackling anti-fraud, appsec, asset management, firmware/hardware security, and IAM. If you follow me, you know I find masochistic pleasure in examining the nature of infosec buzzwords, and the Innovation Sandbox word cloud does not disappoint on this front:

“a security platform to automatically protect human fraud from exhaustive enforcement”

What is perhaps most peculiar about this group of finalists to those who follow VC funding trends in infosec (hopefully I am not alone in this nerddom), is that there is scant overlap between investors in these startups. Perhaps, like with movie studios and the Oscars, each VC selects the startup in their portfolio they believe is in the strongest position to win. The sole overlapping investor was ClearSky, who led Capsule8’s Series B last August, and also led CloudKnox’s “Venture Round” (which feels very Series A) last October. The full list of lead investors in these ten startups is:

• Bain Capital Ventures
• Bessemer
• ClearSky x 2
• Foundation Capital
• Madrona Venture Group
• Mayfield Fund
• New Enterprise Associates
• PayPal
• PSP Growth
• Rally Ventures
• S Capital
• Team8
• USVP
• Y Combinator
• YL Ventures

All finalists are based inside of the U.S. Of those, 40% are based in California — New York has two, and Kansas, New Jersey, Oregon, and Virginia have one startup each.

As a final statistic, only one company’s founding team includes any female founders.

[1] Note: Not every startup gives the precise day they were founded, so I used a combination of Crunchbase and LinkedIn data (e.g., the start date the founder lists) to get as close as possible.

People struggle to understand how risk accumulates in complex systems, thereby also not understanding the extent to which risk must be reduced. This misapprehension can lead to “wait and see” decisions that cause a problem to snowball, or mitigations that don’t meaningfully reduce risk, creating the feeling of just barely treading water in your security program.

It is challenging for people to understand risk dynamics conceptually for two primary reasons. First, we are bad at tying inflows and outflows to the current level of risk in a system, as we tend to believe outputs are positively correlated with inputs. For example, from the climate change realm, 63% of MIT graduate students erroneously believed that if you stabilize emissions above the rate they’re being removed, atmospheric CO2 would stabilize.[1] If emissions are still higher than reductions, there still will be net pollution — it will just be added at a more stable rate.

Second, we tend to ignore the accumulation of effects from inflows.[2] For example, you may reduce the amount you overspend in a given year, but that doesn’t mean your personal debt is being reduced — you must earn a surplus over a period of time to pay down the debt you already accumulated. Ignoring accumulation leads us to underestimate the magnitude of mitigations required to stabilize risk — let alone make a dent in decreasing the risk level towards our goal.

What can we do about this lack of intuitive comprehension? A useful analogy to help people conceptually is a bathtub, with its straightforward inflows and outflows. When discussing information security risk, this analogy can help policy makers grasp the true implications of the decisions they’re making. Too often, mitigations are believed to “solve” the problem, while in reality, the inflows contributing to the problem are still outpacing the benefits from mitigations — but no further action is taken, resulting in continued accumulation of risk.

Thus, I’ve conceived the “Cyber Tub” as a way to better communicate information security risk and ensuring its dynamics — from accumulation to reduction — are well understood. Let’s delve into the analogy.

The Spout

Let’s say you have a bathtub already full of water. The bathtub is actually a “Cyber Tub,” and the water already in it represents your risk level — it could include things like your legacy systems or even the risk of credential theft in modern systems. The spout is actively running, adding a steady, hot stream of complexity into the tub. You don’t want the tub to overflow, because in real life, that leads to a state where you want to tear your hair out from all the complexity you must manage, and probably something will go wrong. So what do you do?

The Drain

First, you need to install a drain — the patch management drain, in fact — if you don’t have one already, which is going to be challenging given all the water already in the tub. If you do have a drain, it’s likely clogged with lots of gross hair from people using the tub, so you’re going to have to clean it out manually so it can drain — and you’ll have to do that each time manually when it gets clogged again.

But, of course, you’re very clever, so you decide to install a self-cleaning drain — an automated patch management solution. However, you already know it will take a lot of effort to implement, and it probably won’t work perfectly the first time (and probably not every time in the future, either). So, you perform some calculations to see which helps keep the tub from overflowing more effectively given how many manual uncloggers you have vs. how many auto-drain maintainers you have on your team.

The Bucket

Regrettably, your drain solution only keeps the tub from filling up more rather than helping the water level go down. Clearly you need a bucket to remove a bunch of water all at once. But where do you get the bucket? Which type of bucket is right? How do you dunk in the bucket without splashing a bunch of water out? Where do you put the water in the bucket after? Do you need multiple buckets? There are lots of things to think about when transitioning to the bucket life.

Think of this like transitioning to a cloud or containerized world — the transition costs will be non-trivial and involve a lot of thinking over how to carefully lift the water without losing any.[3] You can also only transition a certain amount of code at a time, so there needs to be a rollout plan as well. After all, even if you can buy a bunch of buckets at one time, it’s unlikely you can dump them all in at once to clear out the tub without something going wrong.

As you can see, there’s a lot of calculation here, including whether the bucket-based transition to cloud / containers can clear out the tub, since we already know the patch management drain will cancel out the complexity faucet, but nothing more. You also can’t forget that managing a bunch of little buckets is different from managing one tub, so you’ll need to consider the potential risks from that, too.

Additional Examples