Couples counseling for security teams and their business partners

Warning: The following may cause discomfort and signs of denial. Consume with care.

Conflict between Information Security (infosec) teams and their Information Technology (IT) or business partners is a common challenge faced by many, if not most, organizations attempting to improve their security posture. The strained relationships driving these conflicts can have a devastating impact on security outcomes and can lead to costly employee turnover in an already tight hiring market.

In this blog, I’ll discuss a few frequently observed symptoms of this malaise, offer up an underlying cause, and provide a few treatments that can help mend relationships and improve organizational security.

Partner symptoms

Let’s start by discussing symptoms of relationship rot that are frequently observed in infosec’s business partners when the relationship begins to sour. Some of these may cause painful flashbacks, so you may want to sit down with your emotional support animal of choice before reading them.

Partner symptom 1: Deprioritization

Examples:

• I can’t patch vulnerabilities because <insert project here> is more important!
• Sorry, we don’t have the resources to help with your initiatives this year…
• But our customers want dark mode!

Sometimes it seems like everything else is more important than improving security. Projects get delayed (or blocked altogether). Requests for information get denied or take significantly longer than they should.

Partner symptom 2: Avoidance

Examples:

• Oops, we forgot to add you to that important <meeting/email/etc>!
• “It’s too late/expensive to fix that now. We already sent out the press release!”

In other cases, people avoid infosec altogether. They may leave us out of important meetings or only include us in projects at the final stages, if at all. When they see a problem that could impact security down the road, they don’t tell us about it until it blows up, and then they play the blame game to deflect responsibility for the problem.

Partner symptom 3: Blissful ignorance

Examples:

• What do you mean I shouldn’t click on every link in every email?
• But I need to expose that dev server to the Internet!

Occasionally, they seem like they just don’t care. They want to do their job the way they’ve always done it, and nothing is going to change that.

Partner symptom 4: Hostility

Out of concern for the condition of your heart, I’m not going to provide any examples here—you can probably think of plenty without me causing additional trauma. When relationships between infosec and our partners degrade to the point where we’re actively working against each other, it’s no wonder that security outcomes plummet. Both sides throw tantrums worthy of a toddler in their terrible twos, and nothing gets done. This is often when security programs fall apart and attrition happens in droves.

Infosec symptoms

Other symptoms can be seen within the Information Security team itself. Now, you might challenge me and say that these symptoms are actually causing some of the symptoms observed in our partners—and you’d be right. I’m presenting them here as symptoms of an even deeper root cause that’s driving these behaviors.

Infosec symptom 1: Us vs Them mentality

Examples:

• That <insert adjective here> IT guy never gets it right!
• Their priorities are all screwed up!
• They’re always getting in our way!
• They should be fired for this!

If we see our IT or business partners as enemies or believe we’re inherently smarter or better than them, things are bound to go wrong.

Infosec symptom 2: Bubbles & walls

Examples:

• Here’s your list of vulnerabilities/controls. You need to fix all of them before you <insert activity here>. (Sorry not sorry if that delays things…)
• I don’t care if <insert project here> is crucial to the business! All of our findings must be fixed before it goes live!

When Infosec operates in a bubble without considering the impact of our actions and demands requests on our partners’ initiatives, tension is guaranteed to dial up to 10.

Infosec symptom 3: Smoke & mirrors

Examples:

• The APTs are coming!
• Just ignore that system you see on the edge of the network… It doesn’t concern you!

When we in infosec try to drive our agenda forward via fear, uncertainty, and doubt (FUD) or hide what we’re doing from our partners, they lose trust in us and respond more slowly when true emergencies happen.

Infosec symptom 4:  But Mommy said so!

Examples:

• “The CEO/board said so”
• I’ll tell <insert powerful ally here> if you don’t <insert activity here>!

Were you ever happy when a sibling said that to you? Did it win you over? When we rely on the force of executive mandates to achieve our goals, we may make short-term gains but will likely struggle to turn them into long term cultural changes.

The underlying cause

Most people are inherently good. Our partners are generally trying to do their job to the best of their ability, and infosec—for better or worse—is often a distraction from that goal. Similarly, most infosec practitioners are good people, working their tail off to protect an organization from the very real threats constantly trying to get past its walls.

That’s not always how we see each other, however; IT or business teams may see infosec as barriers to success, whiny Chicken Littles, or even outright jerks. On the other hand, infosec teams often see IT or business teams as lazy, obstructive, or hostile. Sadly, they’re often right and so are we. But why does this happen? Why do fundamentally good people on both sides of the table do things that from some perspectives can often border on malice? I propose that a fundamental aspect of how we in infosec approach our jobs is at the root of many of these conflicts, and once we recognize that “elephant in the room,” we can take a step back and consider how it leads to many of the relationship challenges we experience while protecting our organizations.

The war mentality

As those of us in the Information Security field are all too aware, every organization who relies on a computer for any aspect of its business is constantly under siege from countless faceless threats that can attack at any moment, even from the inside. Those threats are relentlessly working to break through our layers of virtual moats and walls, continuously probing and poking for any sign of weakness. As a result, those of us tasked with defending our organizations from attack become distrustful of others—even our “allies”. In seeking to fulfill our militaristic mission, we begin to see those “civilians” who don’t fully buy into our work as threats, equating them in some ways with the enemies we’re defending against. Phrases like “if you’re not with us, you’re against us” or “all’s fair in love and war” come to mind here.

Similarly, because so much of what we do is based on some amount of “clear and present danger” to the organization, we often act without fully developing a process or considering the consequences. We expect them to jump into the work with the fervor that we ourselves feel and can become quite offended when they do not.

Because security teams are so focused on the “mission,” we often behave in ways that can damage relationships with others.

From this perspective, it’s no wonder that we feel so slighted when IT slows down deployment of a key defensive measure or pushes back against a requested change to their project. As bystanders working in a war zone, they don’t fully understand why we need to go to the lengths we do; all they see is added time, cost, and lost sleep. Because we’re so focused on the “mission,” we often behave in ways that can damage relationships with others. Below are a few examples of common issues we may encounter. I want to emphasize here that these behaviors do not make us bad people in the same way that the symptoms listed above in our partners do not make them bad people. These are learned behaviors that often innocently result from our best efforts to protect our organization, our peers, and our customers.

Behavior 1: Poor communication

Examples:

• If we tell them what we’re doing, they’ll stop us!
• They won’t/can’t help anyway, so I’ll just do it myself.
• Why don’t they understand how important this is!?
• What do you mean you have to <insert risky behavior here> as part of your job!??

Just as militaries often treat battle plans with utmost secrecy, infosec teams often keep our plans close to our chests, worried that if others see the scope of what we’re trying to accomplish they’ll get in the way. At the same time, because we don’t believe the information critical to our battle plans, we don’t take time to understand what our partners are trying to accomplish or how their initiatives relate to their goals or the business itself.

Behavior 2: Late or bad requirements/expectations

Examples:

• We need you to <insert risk mitigation here> that will make your project late and/or cost 3x your funding.
• A DB upgrade project is a great opportunity to revisit the architecture!
• Don’t click any links!

We’re often so focused on security outcomes that we don’t think about the impact our actions have on those trying to make the business work. We become the “house of NO,” blocking or delaying anything that might let an APT through our defenses. We even ask users to do (or not do) things that significantly impact their job, such as opening email attachments.

Behavior 3: Ineffective processes

Examples:

• Here’s a list of the (70,000) vulnerabilities we found. You have 30 days to fix them all.
• We have to review every change to the code. Unfortunately, due to staffing constraints, that will take four to six weeks.
• Please fill out these three 20-page forms to begin the security review process.

It’s not uncommon for many of infosec’s processes to be ineffective at best—take a look at most vulnerability management programs, for example. Processes that are informal, undocumented, and generally dysfunctional are guaranteed to strain relationships.

Behavior 4: Risk assessment gaps

Examples:

• A new Chrome update is available! Call out the emergency patching team!
• This $100k/yr control designed to stop APTs must be in place for you to release the product!

Think about how often we in InfoSec say the sky is falling, the world is ending, or the APTs are coming. Now think about whether that was actually the case. Sometimes it is, and calling the Citrix admin in the middle of the night is absolutely the right thing to do—but much of the time it is not. Risk assessments that don’t represent reality or sit right with our partners will eat away at trust, leading them to eventually drag their feet when we call them up for the latest fire drill.

Treatment

So what can we do about this? How do we overcome the institutional war-fighting mentality that comes so easily to us as we do battle in the trenches? Here are a few suggestions:

Treatment 1: Respect & empathize

Try to view (and treat) your partners as allies, not enemies. Show them respect and assume that they’re generally good people doing their job to the best of their ability. They’re not perfect, but then again neither are you, so give them some slack when they make mistakes. When you’re trying to address a difficult security challenge, involve them in coming up with the solution. Even if the solution you come up with is identical to what you would have built without their input, having them in the room will lead to better buy-in and increase the likelihood of the project succeeding.

As you treat your partners with greater respect and empathy, you’ll find that they will come to reciprocate those sentiments and seek out your assistance earlier and more frequently.

Treatment 2: Communicate

To put it bluntly, shut up and listen. As you learn about your partners’ needs and interests, you’ll be better able to tailor your approaches to the organization and reduce impacts to the business.

Have honest conversations with your partners about risk and seek out their input. In many cases, you’ll find that the risk was lower than you thought. In others, you’ll learn about risks you would never have discovered otherwise.

Finally, talk with your partners about your own plans and where they fit into them. Their insights can be invaluable in designing an information security strategy that actually works.

Treatment 3: Consider incentives

In the same way that you may not get your bonus if you don’t meet your security objectives, your partners could lose theirs if they don’t meet their own business goals. A decrease in uptime (yes, Availability is still in the CIA triad!) can have financial implications that may not be obvious at first glance. As you work with your partners, think about what drives them:

• What does their bonus depend on?
• What is their team measured by?
• What does their boss care most about?
• What pays their paycheck?

Understanding incentives can guide your approach to getting things done and help you sell security efforts based on their impact (or lack thereof) to the things that matter most to them. When incentives are out of whack, start at the top; people tend to care about what the boss cares about.

Treatment 4: Look inward

When things aren’t going as well as expected, it’s critical that we take an honest look at ourselves and how we are implicated in the problem. Are our processes effective and efficient? Are our expectations realistic? Are we accurately assessing risk and communicating the risk effectively to our partners? Do we consider the implications of our decisions on the teams we work with and involve them in those decisions?

The problems we’re trying to solve in security are hard and often have a sense of urgency associated with them; adversaries aren’t going to wait for us to ramp up our program before they start probing our defenses. As a result, we don’t always take the time to fully consider the impacts of our actions on other teams—both in terms of resource allocation as well as in terms of the underlying relationships.

Treatment 5: Help them look good

We have a tendency within infosec to look on the dark side, to focus on what’s going wrong instead of what’s going right. By taking time to recognize the good, the wins, and the successes we can make a huge difference in the others’ perspective of us and what we do. When our partners do something right, tell them and tell their bosses. If it was especially impactful, give them a spot bonus or call them out in front of their peers. This will help turn them into allies that become positive agents for good even when you’re not in the room. It might even incentivize others to join in.

Okay, but!

There are some among you reading this article who may have some doubts as to how effective this approach can be. “But Tyler”, you’ll say, “won’t this slow down our security initiatives?” Yes, it may, at least at first. In time, however, you’ll find that good relationships accelerate your ability to execute—especially when your partners are key to success (and they almost always are).

“But Tyler, does this mean we should be pushovers or soft on problems?” No! If there’s a vulnerability that truly needs to be treated as an emergency, it is imperative that we do so. HOW we execute on that emergency patch rollout can make all the difference, however, and having a documented, agreed-upon process can significantly impact how quickly we’re able to respond.

Final thoughts

Security is hard. Personal relationships are hard. For better or worse, we ARE in a war of sorts and adversaries ARE constantly trying to break through our defenses. If we’re not careful, that battle mentality can easily lead us to slip into behaviors that will significantly limit our ability to succeed. On the other hand, if we approach our partners with respect, consider their incentives and needs in our plans, and involve them in crafting our own plans and processes, we’ll be far more successful at building an effective and self-sustaining security program.

To summarize: