How cybersecurity jargon creates barriers and wastes resources
Acronyms are not unique to cybersecurity, but they have become a hallmark of the way we communicate with each other. Do we really need to add this layer of complexity to an industry that is already complex? Or do they just make our developers more depressed? Let’s make security accessible and actionable.
The cybersecurity industry is experiencing record growth, growing at 20% year-on-year, building on the promise of increased productivity. And yet developers often struggle to focus on what’s important. Instead, they’re confronted with another new acronym, making them reach for that dictionary every time they want to get something done. We’ve developed something unique in the cybersecurity industry: a language that no one speaks naturally.
Security researcher and lawyer at Aikido.
The power of a common language
The root cause of all our communication problems is that we describe security tools by what they are and not by what they do.
Take ‘static application security testing’ as an example; that doesn’t really mean anything to people who don’t already know what it is. But what it actually does is try to secure our code. With that knowledge, we can immediately try to understand what ‘dynamic application security testing’ is. It’s semantics, not guesswork. (ps The latter is like a hacker trying to find vulnerabilities in our applications.)
My biggest frustration is that I don’t understand why we even need an acronym for those things when we can simply describe what they do. When we build security tools, we should be able to easily describe what they do in non-technical terms, rather than trying to describe what they are.
As this communication barrier moves up the chain and crosses the technical divide, these problems become even greater. At the board level, security teams are completely up against the wall when it comes to funding. We face a catch-22 situation where security teams don’t get enough funding, or at least think they don’t, and we also suffer much more from security attacks. One of the biggest problems is that decision makers at board level do not understand much of what is needed. Because they don’t understand what things actually do. You can’t walk into the boardroom and ask the CEO to part with some money for a CNAPP.
The cynic in me also sees many of these acronyms as money printing machines. When we create new acronyms to replace the old ones and say we need new tools to do that, it just seems like an upsell. And even when something is needed, it’s hard to separate the necessary things from the snake oil.
The value of clarity
There’s a sense of disbelief that I’m still banging this drum in 2024, but we need to approach cybersecurity more holistically. We tend to secure entire applications or the entire software development in separate phases. They are in silos. What if we could leverage all this innovation to create an approach to safety that feels like a natural part of development? These are the four main areas we need to focus on. In plain Dutch of course:
Securing our source code – This includes anything written in code, including infrastructure as code. It’s about writing secure code from the start.
Securing our runtime application – This is about protecting our application while it is running. Can an attacker find vulnerabilities? This includes fuzzing tools (tools that try to break your application by sending unexpected data to it), API testing, and what we commonly call “dynamic testing.”
Securing our cloud environments – This means protecting the infrastructure on which everything runs.
Securing our supply chain – This includes dependencies, open source components and third party elements.
Four areas. Clearly explained. And so much easier to understand for developers, because, instead of being hit with an acronym that does something different, or that combines two different functions, the priorities are clearly laid out.
As Jason Haddix, the former CISO at Ubisoft, told me on my old Security Repo podcast, “Being able to break down technical terms into non-technical terms really got me where I did.” It confirmed for me that this is the skill you need to succeed – and acronyms definitely don’t help. Even if we throw away the acronyms, there is still a way to go. If you’re talking about “we need a static application security testing tool” or “we need an infrastructure as a code testing tool”, then we should be saying in the boardroom: “we need these tools to protect our source code” and “we need these tools needed to protect our application”.
Here’s the reality: acronyms are designed to be understood by a small group of people. Yet we have (at last count) more than 300. We need to move from a culture of complexity and exclusivity to a culture of clarity and inclusivity. When we communicate effectively about security, we do more than just convey information: smart communication respects developers’ time and cognitive load. It also ensures that communication can take place effectively up the chain, meaning it is no longer a misunderstood and underfunded part of the organization.
We reviewed the best endpoint security software.
This article was produced as part of Ny BreakingPro’s Expert Insights channel, where we profile the best and brightest minds in today’s technology industry. The views expressed here are those of the author and are not necessarily those of Ny BreakingPro or Future plc. If you are interested in contributing, you can read more here: https://www.techradar.com/news/submit-your-story-to-techradar-pro