Unable to persuade colleagues

Question

An issue I've been running into a lot is that me and colleagues are discussing how to do a certain thing in the field of software development, e.g. security. The team leans towards a certain approach that they think is secure. However, from experience I know this approach is not secure. Now I try to explain that it is in fact not secure, but fail to convince them about it not being secure. Often this is due to disbelief on their side ("if this isn't safe, then how does anyone make anything secure?"). It doesn't help much that the most vocal person in my team is also my senior by a longshot.

At this point, I feel like I only have 2 options (or a combination thereof):

• Be stubborn and keep trying to explain it isn't secure.
• 'Co-operate' in implementing the feature, only to immediately show it isn't secure by showing an actual exploit as soon as the security features that are supposed to secure the application are implemented.

I feel like the former option is a good way to get myself hated if I persist for too long, and people are just going to stop taking it seriously after some point. Meanwhile, the latter option feels like an inglorious waste of time, used only out of lack of an alternative.

This persuasion problem also occurs regularly with people other than my current colleagues (and with different subjects), so it is not strictly a 'compatibility issue' between me and them.

General tips to help explain things better or help persuade people are definitely appreciated, but I feel like I'm missing something fundamental here.

Answer 1

Framing and approach is really important. Remember all those cheesy team building exercises where you had to practice "yes, and...."? It really is an important influence tactic. Make sure you're on the same side of the table, listen to what they're saying, and be persistent. It sounds like what you're dealing with is fairly technical, so consider laying it all out in an email, with links to discussion re: the known exploits or tools that will compromise your project. And be comfortable with losing the argument in the short term; it's still a team effort.

Long term, consider spending some time building your personal brand. Know that every interaction either builds it or doesn't. It sounds like your brand might be a little light on credibility. Focus less on you being right and others being wrong; focus more on providing proactive and ongoing education to your coworkers, never ever make stuff up or even stretch the truth, and always come prepared by educating yourself fully on the issue and anticipating objections or weak points in your argument. And when you're wrong, own up immediately and direct credit where credit is due.

I can say, without bragging, that when I weigh in on a topic, people listen. Part of that is demeanor and seniority and gravitas (which I still struggle with), but most of it is because I'm usually right and I always come prepared, and if I don't know, I keep it to myself until I do know.

Answer 2

I'm a "show me, don't tell me" kind of guy. If it's not secure then put a proof of concept together showing their method along with a proof of concept showing it breaking.

Years ago I had hired a dev team and gave them explicit instructions on how to handle security. During a code review I saw that they had ignored me and went with a different route. They claimed it was "standard practice" and gave me a list of services they used that had copied their implementation from.

Rather than arguing I set up a meeting for the following day. During that meeting I showed them the usernames and passwords they used to access those services. It was various things like external email accounts, banking passwords, social media, etc. In one case I wasn't able to capture clear text of their username/password but I was able to do a replay attack to log into that site as one of the team members.

They got the point and stopped arguing.

Now, I'm not saying that you're right and they are wrong. But I am saying that if you can prove it then that will go a long way towards swinging people to your way of thinking.

Answer 3

You have two issues here.

1. You have specific and relevant experience you believe should be considered. Can you explain this using actions and consequences? For example, "At my last job we did A. And then our penetration tester told us we needed to do B, right away, instead. That was an expensive lesson to learn."

2. You're serving as an agent of change in an area that's changing insanely fast (infosec). People resist change: "How does anybody make anything secure?" is an example of that resistance. How to achieve change?

   • be patient.
   • be clear.
   • use evidence. OWASP is a good reference to start in this particular field. If you can point to a notorious security breach based your present choices, that's even better. "Equifax did the same thing" is a powerful argument, if you can make it. Read Troy Hunt and Brian Krebs.
   • did I mention, be patient?

These people aren't going to smack their foreheads and say "doh! you're right." But they are thinking about what you said.

If you do these things you've done your professional duty. Often people don't "get" infosec until they have to handle a security incident, sad to say.