The top 10 lies we tell ourselves as security teams

Try as we might, security teams are often subject to the same sort of echo chamber groupthink dynamics that any other function might experience. There are subtle messages or biases that can creep into our collective consciousness and cause significant harm.

This article will break down what I see as the top 10 lies or distortions that security teams often tell themselves, which are likely causing significant harm. That harm may come in the form of broken relationships, distraction, burnout, a lack of productivity, or a toxic culture.

So let's get into it.

1. We're not builders

This is starting to change, but many cybersecurity teams still view themselves as a largely compliance or operations-driven function. When things need to be built, as in software needs to be designed and written, it's passed off.

Security is becoming more software-centric, whether we like it or not. This demands more software skills on our teams or that individuals have a basic understanding of how to build things.

Not all software needs to be complicated. Sometimes, it's about taking an idea and bringing it to life. Or it might be about taking an arduous task and making something to make that task go away.

If we absolve ourselves of the creative work of building things, we give up a lot. We also absolve ourselves of ownership over our situation.

2. We can multitask effectively

This applies to people and to teams. Nobody multitasks as well as they think they do. Teams who have split their focus in multiple directions are likely not going to be as effective in their work.

It's the leader's job then to ruthlessly prioritize what needs to happen and when.

Sometimes, this is about saying "no" to more stuff than we say "yes" to.

Saying "no" isn't nearly as satisfying at first, especially if we're in a culture of productivity and efficiency.

3. This needs to be perfect

The perfectionist culture fits quite nicely with the culture of risk aversion. If this work isn't done perfectly, something terrible might happen.

We see this all the time when there's a process like vulnerability patch management or a secure software development lifecycle. Should imperfect software be allowed to run in our environment? Should unpatched systems that we know are vulnerable be allowed to run?

These are questions that we can't answer in a vacuum.

4. This organization can't (or won't) change

Changing things within an organization is hard, whether you're in a startup or a large enterprise. It's really easy to start telling yourself that people won't change.

Such and such team is always going to respond this way. So and so is always out to get us and make things difficult.

When this kind of talk starts to happen, it can become really toxic. This kind of talk removes the focus on the things you can do to affect change. It focuses instead on what everyone else is doing (which is out of your control).

This is a really slippery slope that you want to avoid.

5. If we fail, we're failures

This builds on the perfectionist mindset. Security teams that wrap all their success up in breach-related or project-related outcomes.

If a project doesn't work out, that means we're all bad at our jobs.

If we get breached, it means we have totally failed this organization.

Nothing, in my experience, is so simple. Projects can be a failure, but if you stop them soon enough, learn from them, and improve the next thing that happens, that's a really positive thing. The same sort of dynamic applies to security incidents when they occur.

6. We can't handle a major failure

It's not very common for an organization to actually go out of business on account of a cybersecurity issue. It does happen, but this is not the norm.

This is where resilience comes into focus. Incidents and breaches will likely happen at some point. Whether it's your organization directly or a supplier of yours. It's entirely possible there will be some significant harm done.

But teams can respond with a growth mindset. Knowing that a setback still has plenty of opportunity to do good through strong incident response, communications, and a plan to build everything back better after the retrospective.

Going through the year with the doom and gloom mindset that an incident will be the end of everything can cause people to totally shut down if something does happen. Prevention is only half the battle. Response and recovery play a significant role in how bad things can really get.

7. Security is one of the most important things in this organization

I say this often in my full-time work, but security isn't the most important thing.

It can't be.

Even in security companies, it's not the most important thing. The mission of the organization is the most important thing, and security is there to support it.

When teams start to reframe their mindset to embrace this supporting role, it will change the way they interact with others. Seeking common ground and shared understanding versus a "I win and you lose" mentality.

8. If people cared about security, we wouldn't be having issues

People do care about security and protecting their organizations. But...they have other jobs to do. They weren't hired for security; you were.

This kind of victim-blaming or user-shaming mentality can create another slippery slope for teams. When we fail to remember that anyone can fall for a phishing attack. When we fail to appreciate a development team's crushing deadlines around feature release. When we fail to understand that a team simply doesn't have the budget after they experienced major cuts.

Sometimes, security has to take a backseat to other, more pressing things within a team. That doesn't mean that those teams don't care, but they have to care about other things, too.

Always try to maintain a sense of empathy within your team.

9. We need senior leadership's approval to know we're doing right

We can't always get on the meeting lineup for our organization's most senior leadership or board of directors. Besides, getting their explicit approval for everything we do is not a comprehensive or possibly even a good sign that we're doing well.

Security teams should be thinking about metrics, OKRs, and KPIs to identify whether or not they are on the right track.

It's very much like health and wellness. It boils down to daily discipline, attending to the little things, and tracking what matters.

10. We can't not patch that vulnerability

Carrying risk is not something that is comfortable for many security teams. Depending on the industry you're operating in, this can be far more exaggerated. Sometimes, the cure can be far more impactful than the issue.

If organizations spent all their valuable time and focus addressing patches, upgrading software, tweaking configuration options, and making sure software dependencies were upgraded, there wouldn't be a lot of time left for anything else.

It's our job to help our organizations identify what vulnerabilities to address and what risk is OK to carry. There are great tools out there to assist with this decision-making, like EPSS and KEV.

Concluding thoughts

This list certainly isn't exhaustive of the toxic things that security teams can get into the habit of telling themselves. However, if your team is in any of these toxic patterns, you need to work hard to break free of it. Each of these can introduce really harmful elements to your overall team and organizational culture.

And as Peter Drucker once famously said, "culture eats strategy for breakfast."