Security Fatigue Is a Signal-to-Noise Problem

I spend a lot of time talking to security people, and most of them are tired.  

It’s not because they don't care about security. They care a lot, but they’re being asked to care about 400 things at the same time. Every day, there is another security company telling them about a new existential threat, another vulnerability, breach, AI problem, regulation, attack vector, or something else that has become critical and another product that is supposedly the answer to it. 

Eventually, you end up with a signal-to-noise problem. There is so much stuff coming at security teams that figuring out which signals matter becomes harder than getting the information in the first place.  

Security Alerts Are Like Check Engine Lights 

Everyone wants the attention of the security team because everyone thinks the problem they solve is important. Security people know this, which is why they are skeptical. If someone is trying to sell you something, you know there is probably some self-interest involved. 

Security alerts have become like the check engine light in an old car. The light comes on, you take it to your mechanic, your mechanic says they've seen this before and it probably isn't a big deal, so you keep driving. The car keeps working. Six months later, the light is still on, so you stop paying attention to it. 

Eventually, something may actually break. Maybe the car doesn't start one morning, the alternator goes, the transmission falls out on I-5, or something ridiculously catastrophic happens, and you plow into another car. 

Security organizations are under enormous pressure to keep the car on the road. They can't tear apart the entire environment every time another warning light turns on because doing that costs money, creates friction, slows people down, and frustrates application teams. Worse, it often turns out that nothing catastrophic was actually happening. 

Falling Back on the People and Technologies You Trust 

The danger of false alarms means that when something new comes along, most people fall back on the people and technologies they already know and trust. If your existing security vendor has been working with you for ten years and some company you barely know shows up saying, "Hey, there is a huge security gap here," who are you probably going to believe? 

That isn't unreasonable, but it can become a blind spot. The other problem is that attackers know exactly what kinds of tools organizations are using, too. Good attackers are not necessarily trying to kick the front door down and light up every security product in the environment. They are trying to figure out what you trust, what you aren't watching very closely, what normal behavior looks like, and how they can operate inside for as long as possible without anyone realizing they are there. 

The best attack from the attacker's perspective is the one nobody notices. That is one reason why the TeamPCP supply-chain attacks earlier this year signaled a major shift. The attackers compromised trusted software projects, including LiteLLM. Instead of trying to convince somebody to install obviously sketchy malware, they were able to use trusted software organizations as part of the attack path. 

That should make people uncomfortable because it changes the question from “can my security tools detect malicious software?" to "What happens when the thing I already decided was safe stops being safe?" That’s a much harder question to answer. 

So what can companies actually do about this? There are six ways to approach separating signals from noise: 

1. Don't Close Yourself Off to New Possibilities 

You don't have to believe every vendor who shows up with a scary diagram and tells you the sky is falling. However, don’t automatically dismiss something because it doesn't fit into the tools or architecture you already know. 

Sometimes it is worth asking, "What if this actually is different?" You don't have to accept the vendor's answer; you just need to understand the problem well enough to decide if it matters to you. 

2. Ask Your Trusted Advisors About New Threats 

If there is a new attack technique, ask the people you already trust what they think. Ask your existing security vendors how they detect it, how they stop it, what happens if the attacker already has credentials, and what happens if the attack originates from a trusted source. 

This is also where trusted advisors prove their value. A good advisor should be willing to tell you that their product is not the answer to a particular problem, because nobody has the answer to everything. Pretending otherwise just makes people trust you less. 

3. Don't Assume a New Safeguard Means Replacing an Existing One 

Security is not a zero-sum game. Sometimes the most valuable thing you can add is another control that looks at the problem in a completely different way than the products you already have. 

Attackers study the same security products defenders do. They know the common architectures, where organizations tend to put controls, and where the blind spots usually are. If every security tool in your environment is looking at the world through roughly the same lens, then you may get great operational consistency but have the exact same blind spot in five different products. 

Having independent ways of seeing activity can be extremely valuable, especially when those controls don't all depend on the same assumptions. 

4. Make Your Vendors Prove Their Claims 

One thing I wish security organizations did more often is stop debating PowerPoint slides and just recreate attacks. Put the technology in a lab, run the attack, see what gets detected, see what gets blocked, and see what doesn't get detected at all. Then, start turning things off and breaking pieces to see what actually happens. 

What happens if the endpoint tool misses it? What happens if credentials are already compromised? How far can the attacker move, what can they reach, what traffic is visible, how quickly can you contain it and does the containment mechanism actually work without taking down half the application? 

Those are much better questions than asking which vendor has the prettiest architecture diagram. 

5. Get Comfortable Saying No 

Not every new security problem needs a new product. Sometimes the thing you already own really is good enough, or the risk isn't high enough to justify the operational burden. Sometimes the security problem is real, but the available solutions create more pain than the problem itself. 

There is also nothing wrong with saying, "I don't know yet." In security, we can pretend every question needs an immediate yes or no answer. However, there are a lot of situations where the responsible answer is, "This looks interesting, we need to understand it better before we decide whether we care." 

Every customer has unique use cases, and there may not be a good solution to every problem. Being honest about that is a lot more useful than forcing another tool into the environment because someone told you it was urgent. 

6. Get More Trusted Advisors, Encourage Dissent, and Discourage Complacency

If everybody around you gives you the same answer all the time, that may feel reassuring, but reassurance isn't necessarily what you need. Occasionally, the person who disagrees with everyone else is the person worth listening to. 

Ask the cloud networking team what they see. Ask the application team, identity, endpoint, the SOC, and the people who actually have to operate the controls after the architecture team leaves the room. Every one of those groups sees a different part of the environment, and sometimes the useful signal comes from the person who wasn't supposed to be the security expert in the first place. 

If somebody you trust keeps telling you something isn't a problem, but the evidence you are looking at says otherwise, get another opinion. You don't necessarily have to fire the first advisor or vendor, just recognize that nobody has the whole picture. 

Focusing on More than Prevention

Security does not have a finish line where an organization has finally done enough and can declare itself secure. There will always be another mistake, compromised credential, misconfiguration, unexpected behavior, or unknown vulnerability. 

You can do everything the industry tells you to do and still get breached. That does not mean prevention is pointless. It does mean that prevention cannot be the only thing your security strategy depends on.

Firewalls, endpoint security, identity, CNAPP, and vulnerability management are all important and needed. But we have to get better at assuming one of those things will eventually miss something and then designing around what happens next. That is where resiliency and blast radius become really important:  

• If one workload gets compromised, how much of the environment can it actually reach?  

• If an attacker steals a credential, where does that credential take them?  

• If an application suddenly starts communicating with a destination it has never talked to before, can you see that? If you can see it, can you respond before the attacker has moved somewhere else? 

Those are the kinds of questions we need to spend more time asking, and where Aviatrix’s concept of the Containment Era comes from. Containment doesn't mean replacing all the things we already do. It means admitting that occasionally one of those things is going to fail, and thinking through what happens after it does. 

Cloud networking can provide a useful additional perspective here. The network sees relationships between workloads, applications, environments and destinations that other security controls may see differently. That doesn't mean networking is the answer to every security problem, but it is an area security teams should pay attention to. 

Balancing Security Effectiveness, Cost, and Operational Friction

The real job security leaders have is balancing security effectiveness, cost, and operational friction, and those three things are constantly fighting each other. You can make an environment incredibly secure by making it nearly impossible for anybody to do anything, but nobody wants to work there. You can remove almost all security friction and create an environment developers love, but nobody responsible for protecting the company is going to sleep very well at night. 

The challenge is finding the right balance for the organization you actually have, not the one in somebody's reference architecture. That's why I have a hard time with the idea of one best-of-breed answer to security. There are too many different problems and too many different ways things can go wrong. Like in a horror movie, some monsters need silver bullets, some need wooden stakes, some need sunlight, some need fire, some need water, some probably need salt or holy water or whatever else the movie tells you to use. The first problem is figuring out whether there is actually a monster in the room.

I keep coming back to signal-to-noise ratio. Security teams don't need more vendors yelling louder, they need better signals, more ways of looking at what is actually happening, and more people around them who are willing to challenge assumptions. 

Final Thoughts

The security industry isn't going to get quieter. AI isn't going away, quantum isn't going away, cloud isn't getting simpler, and attackers are not going to stop learning how our defenses work. The answer is not continuing to tell security people they need to run faster. 

The better answer is helping them figure out which direction is actually worth running, and making sure that when something inevitably goes wrong, the whole environment doesn't go with it. 

Learn more about how to implement containment through Communication Governance.