How to handle conflicts in information security

If you dislike conflicts, don't work in information security. As a mentor once told me: "I'm not in security to make friends." Don't get me wrong. The vast majority of InfoSec professionals are easygoing. Conflicts are a feature of the job. In essence, security is at odds with core business incentives: easiness and speed.

The ability to handle conflicts defines senior security professionals. It's one of the most useful skills I've built. Conflict management made me better at helping my organization. It also saved me from burnout.

This week, I'll look at some typical conflicts for information security professionals. Looking back at how they were handled, I'll give tips to help you avoid mistakes.

Accept that security does not run the show

You may see this as obvious, but I've seen many security folks forget this basic truth. Nobody builds software for the sake of security. I've explained how being a supporting player is a major drawback of a career in cybersecurity.

The data scientists, engineers and product people will always get the spotlight. You will not attend launch events with pink champagne and cocktail sausages. See, that AI feature, that's what's cool. Security is many things, but it's not cool.

So yes, we spend a lot of time interacting with the hyped-up "golden boys/girls" who bring in the eyeballs on the company. Security is not what catches the eye.

It's easy to slip into bitterness if we see this pedestal as something that was earned with a disregard for security. I've seen one security colleague become so angry at the "golden boys" that they were plotting some weird schemes to "expose" them as overhyped. It ate them alive and they quit before burning out.

It gets worse. In a security breach, the senior security personnel is the one getting fired. Not the careless golden boy. So you cannot even rely on saying that a breach would shut them up! It's easy to become self-righteous when being made accountable for other people's shortcomings.

I learned to accept that harsh reality over time. What helped me was settling on the risk management aspect: my duty is to bring visibility and transparency to the business decisions so, hopefully, the numbers speak on my behalf. Since security appeals to the common good, the fundamental right to privacy, and to an individual's peace of mind, I know I can tip the balance in my favour.

This is why the optimistic security posture, in favour of breach fear-mongering, will always win.

People don't always react wrong to being told "no"

Security specialists keep one ace up their sleeve: their veto power. Whether written or not, this power allows us to shut down a project if we deem it unacceptable. I've seen it everywhere.

We must exercise it with caution. There is a fine line between rejecting a system and being a zealot. The truth is, I can count on both hands the times I've used my veto.

Why? Simple. Most of the time, you find a solution. You add measures. You negotiate a workaround. The veto is useful as a concept. But I never leverage it as a threat. It's a last resort if all else fails. Never a means to exert authority or to push my weight around.

On the other hand, I discovered not everyone in business reacts badly to security interference. Let me explain. I did over 400 third-party audits of apps. I've seen them all. Many times, if I see a sloppy app, I know about a better one that does many of the same things! The "veto" transforms into "Hey, try this instead!" And more often than not, the person is thankful for my help in finding an app for their need!

It took me a while to overcome the shyness, to be honest. Call it the spotlight effect. In my mind, going into a scuffle to shut down an app was a big deal. It affected the security team's brand. It was a risk to have these people use the apps behind our backs the next time. So I'd rehearse and re-read my recommendations. It was uncomfortable! But the truth is: people need the advice! It's not a yes/no question, it's a problem-solving matter.

My point is:

• Threatening to shut down projects as a shortcut to make your point with data comes across as weak;
• Being over-collaborative and just saying "yes" to everything ignores your unique expertise. You become a useless bureaucratic step if you don't challenge your client.

In the same vein...

Stop sugarcoating security: it is inconvenient

We say it all the time: the best security measures happen when the secure option is the easy option. But it cannot always be like that. Take authentication. There's nothing easy about proving your identity to a computer in a manner that no stranger can impersonate you.

I've seen conflicts worsen because security professionals would minimize the hurdles of their solutions.

• "Well it's not complicated you just have to set up this file share with the customer by doing a helpdesk ticket 3 business days before the contract talks, what's wrong?"
• "What's the problem with pulling out your phone every morning for your MFA?"
• "Our VPN only has 200 ms latency, it's the standard, what's the issue?"

We must remain level-headed about the tradeoffs. Take another example: should you allow your organization to send emails with clickable links to its customers? I've seen heated debates between security professionals on the subject! The argument that irritates me the most? "What's the big deal about asking the customer to go to their browser and log in to the secure portal to view the message instead of clicking a link that could feel like phishing?" This additional friction might mean a 50% engagement drop, it is a big deal!

Remember: we don't build software for the sake of security. We build security into the software because it leads to overall lower maintenance costs and because it is the right thing to do. But there is no such thing as absolute security.

Email communication sucks

How many times per week are you being looped into an email thread? The worse are the forwards where someone just tells you: "Hey sounds like security stuff guys, deal with it".

Security is unique in this way. People see the word "security" in an email, and they surrender all ownership of a problem. I have not seen data scientists, product managers or BI engineers, for example, deal with a similar attitude.

When I was younger, whenever I saw someone pulling this off, I'd respond in a passive-aggressive manner to the jumbo threads so they'd feel bad for being lazy and unaccountable. Here's the funnier part: I can write worth a damn, so I could really piss people off with an email. It's a cool "mic drop" moment with yourself, but not worth much to solve problems.

How did I solve the problem?

Someone more senior gave me awesome advice: people hate reading.

Short sentences, bullet points, simple calls to action and, above all, requiring the other parties to respond with one word: "Yes", "No", or "Meeting please" (OK, this is two).

The huge threads getting dumped on my head? "Could we do a 4 minute call to get me up to speed? I don't understand what's expected of me here."

You can't change people's attitudes, after all.

It's an ongoing struggle, learn to love the process

I may be the one giving advice, but I'm not perfect either. I still struggle with a specific type of conflict: project managers. This is a clash of purpose. I believe security is infinite. You can never wake up one day and say you did it, you are secure. Every day is an opportunity to incrementally improve, little percent by little percent. It's like fitness.

Project management deals with deliverables on a timeline. It's finite. In security, when there is no product launch or marketing, I can't help but feel these deadlines are arbitrary. So I can't bring myself to adhere to project managers' schedules. To come back to the fitness analogy: there are no Olympics of security. We train every day to live long and healthy. Why the timelines to stress ourselves?

I still haven't solved that one. PM readers, make yourself heard, and tell me in the comments how to deal with this clash!