Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Acronyms are not unique cybersecuritybut they have become a sign of the way they communicate with each other. Do we really need to add this layer of complexity to an already complex industry? Or are they just making our devs more depressed? We make security accessible and actionable.
The cyber security industry is seeing record growth, a growth of 20% per year, and built on the promise of increase. productivity. However, developers often struggle to focus on what matters. Instead, they encountered another new acronym that made them reach for that dictionary every time they wanted to do something. We have developed something unique in the cybersecurity industry – a language that no one speaks natively.
Security Researcher and Aikido Advocate.
The power of a common language
The root cause of all our communication problems is that we describe security tools for what they are and not for what they do.
Take “static application security testing” as an example – that doesn’t really mean anything to people who don’t know what it is already. But what it’s really about is trying to secure our code. With this knowledge, we can immediately try to understand what “dynamic application security testing” is. It’s semantics, not guess work. (ps The last one is like a hacker trying to find vulnerabilities in our applications.)
My main frustration is that I can’t understand why we even need an acronym for these things when we can just describe what they do. When we build security tools, we should be able to easily describe what they do in non-technical terms, instead of trying to describe what they are.
When this communication barrier moves up the chain and crosses the technical division, these problems become even more amplified. At council level, security teams are completely up against the wall in terms of funding. We have this catch-22 situation where security teams are not getting enough funding, or at least they believe they are not, and we suffer even more from security attacks. One of the biggest problems is that at the council level, the decision-makers do not understand much of what is needed. Because they don’t understand what things really 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 that replace the old ones and say we need new tools for them, it just seems like an upsell. And, even when something might be needed, it’s hard to separate the needs from the snake oil.
The value of clarity
There is a sense of disbelief that they are still beating this drum in 2024, but we need to approach cybersecurity more holistically. We have a tendency to secure whole or entire applications software development in separate stages. They are in silos. What if we could leverage all of this innovation to create an approach to security that feels like a natural part of development? Here are the four key areas we need to focus on. In plain English, of course:
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 – It’s about protecting ours application while running. Can an attacker find vulnerabilities? This includes fuzzing tools (tools that try to break your application by throwing unexpected data), API tests, and what we typically call “dynamic tests”.
Securing our cloud environments – This means protection of the infrastructure that everything runs.
Securing our supply chain – This covers dependencies, open source components, and third party elements.
Four areas. Clearly explained. And much easier for developers to understand because, instead of being hit with an acronym that does something a little different, or that combines two different functions, the priorities are clearly established.
As Jason Haddix, the former CISO of 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 am.” He confirmed to me that this is the skill you need to succeed – and acronyms don’t help. Even if we discard the acronyms, there is still a way to go. If you talk about “we need a static application security testing tool” or “we need an infrastructure as a code testing tool”, what we should say in the meeting room is “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. However, we have (at last count) more than 300 of them. We need to move from a culture of complexity and exclusivity to one of clarity and inclusiveness. When we communicate effectively about security, we do more than transfer information: intelligent 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 tech 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
