How cybersecurity jargon creates barriers and wastes resources | usagoldmines.com

Acronyms aren’t unique to cybersecurity, but they’ve become a hallmark of how we communicate with each other. Do we really need to be adding this layer of complexity to an industry which is already complex? Or are they just making our devs more depressed? Let’s make security accessible and actionable.

The cybersecurity industry is seeing record growth, growing 20% YoY, and built on the promise of increased productivity. And yet developers often struggle to focus on what matters. Instead, they are met with another new acronym that has them reaching 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 natively speaks.

The power of a common language

The root cause of all of 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 that don’t know what it is already. But what it actually does is try to secure our code. With that knowledge we can then immediately try to understand what “dynamic application security testing” is. It’s semantics, not guess work. (p.s. The latter is like a hacker trying to find vulnerabilities in our applications.)

My main frustration is that I can’t understand why we actually even need an acronym for those things when we could simply describe what they do. When we’re building security tools, we should be able to easily describe what they do in non-technical terms, instead of trying to describe what they are.

As this communication barrier moves up the chain and crosses the technical divide, these problems become even more amplified. At the board level, security teams are completely against the wall in terms of funding. We have this catch-22 situation where security teams aren’t getting enough funding, or at least they believe they’re not, and we’re also suffering way more from security attacks. One of the biggest issues is that at the board level, the decision makers don’t understand a lot of what’s 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 cash for a CNAPP.

The cynic in me also sees a lot of these acronyms as money-printing machines. When we create new acronyms that replace the old ones and say we need new tools for them, it just looks like an upsell. And, even when something might be needed, it’s difficult to separate the necessities from the snake oil.

The value of clarity

There’s a sense of disbelief that I’m still beating this drum in 2024, but we need to approach cybersecurity more holistically. We have a tendency to secure entire applications or entire software development in separate stages. They are in silos. What if we could harness all this innovation to create a security approach that feels like a natural part of development? Here are the four key areas we need to focus on. In plain English, naturally:

Securing our source code – This covers everything 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’s running. Can an attacker find vulnerabilities? This includes fuzzing tools (tools that try to break your application by throwing unexpected data at it), API testing, and what we typically call “dynamic testing.”

Securing our cloud environments – This means protecting the infrastructure that everything runs on.

Securing our supply chain – This covers dependencies, open source components, and third-party elements.

Four areas. Clearly explained. And so much easier for developers to understand because, rather than being hit with an acronym that does something slightly 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 to where I did.” It confirmed to me that this is the skill you need to succeed – and acronyms absolutely don’t help. Even if we discard the acronyms, there’s still a way to go. If you’re talking about “we need a static application security testing tool” or “we need an infrastructure as code testing tool,” what we should be saying in the boardroom is “we need these tools to protect our source code” and “we need these tools to protect our application”.

Here’s the reality: acronyms are designed to be understood by a small subset of people. Yet, we have (at the last count) more than 300 of them. We need to move from a culture of complexity and exclusivity to one of clarity and inclusivity. When we communicate effectively about security, we do more than transfer information: smart communication respects developers’ time and cognitive load. It also allows communication to move effectively up the chain, meaning it is no longer a misunderstood and underfunded part of the organization.

We’ve rated the best endpoint protection software.

This article was produced as part of TechRadarPro’s Expert Insights channel where we feature the best and brightest minds in the technology industry today. The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/news/submit-your-story-to-techradar-pro