How to talk to security people: a guide for the rest of us

I wrote an article a few months back called Using words that normal people understand.  It turns out that you[1] liked it a lot.  Well, lots of you read it, so I’m going to assume that it was at least OK.

It got me thinking, however, that either there are lots of security people who read this blog who work with “normal” people and needed to be able to talk to them better, or maybe there are lots of “normal” people who read this blog and wondered what security people had been going on about all this time.  This article is for the latter group (and maybe the former, too)[2].

Security people are people, too

The first thing to remember about security people is that they’re actual living, breathing, feeling humans, too[3].  They don’t like being avoided or ostracised by their colleagues.  Given the chance, most of them would like to go out for a drink with you.  But, unluckily, they’ve become so conditioned to saying “no” to any request you make that they will never be able to accept the offer[4].

Try treating them as people.  We have a very good saying within the company for which I work: “assume positive intent”.  Rather than assuming that they’re being awkward on purpose, trying assuming that they’re trying to help, even if they’re not very good at showing it.  This can be hard, but go with it.

Get them involved early

Get them really involved, not just on the official team email list, but actually invited to the meetings.  In person if they’re local, on a video-chat if they’re not.  And encourage everybody to turn on their webcam.  Face contact really helps.

And don’t wait for a couple of months, when the team is basically already formed.  Not a couple of weeks, or days.  Get your security folks involved at team formation: there’s something special about being involved in a team from the very beginning of a project.

How would you do it?

In fact, you know what?  Go further.  Ask the security person[5] on the team “how would you do it?”

This shuts down a particular response – “you can’t” – and encourages another – “I’m being asked for my professional opinion”.  It also sets up an open question with a positive answer implicit.  Tone is important, though, as is timing.  Do this at the beginning of the process, rather than at the end.  What you’re doing here is a psychological trick: you’re encouraging perception of joint ownership of the problem, and hopefully before particular approaches – which may not be security-friendly – have been designed into the project.

Make them part of the team

There are various ways to help form a team.  I prefer inclusive, rather than exclusive mechanisms: a shared set of pages that are owned by the group and visible to others, rather than a closed conference room with paper all over the windows so that nobody else can look in, for instance.  One of the most powerful techniques, I believe, is social interaction.  Not everybody will be able to make an after-work trip to a bar or pub, but doughnuts and pizza[6] for the team, or a trip out for tea or coffee once or twice a week can work wonders.  What is specific to security people in this, you ask?

Well, in many organisations, the security folks are in a separate team, sometimes in a separate area in a separate floor in a separate building[8].  They may default to socialising only with this group.  Discourage this.  To be clear: don’t discourage them from socialising with that group, but from socialising only with that group.  It’s possible to be part of two teams – you need to encourage that realisation.

Hopefully, as the team’s dynamics form and the security person feels more part of it, the answer to the earlier question (“how would you do it?”) will won’t be “well, I would do it this way”, but “well, I think we should do it this way”.

Realise that jargon has its uses

Some of the interactions that you have with your tame[9] security person will involve jargon.  There will be words – possibly phrases, possibly concepts or entire domains of knowledge – that you don’t recognise.  This is intimidating, and can be a defence mechanism on the part of the utterer.  Jargon has at least two uses:

1. as an exclusionary mechanism for groups to keep non-members in the dark;
2. as a short-hand to exchange information between “in-the-know” people so that they don’t need to explain everything in exhaustive detail every time.

Be aware that you use jargon as well – whether you’re in testing, finance, development or operations – and that this may be confusing to others.  Do security folks have a reputation for the first of those uses?  Yes, they do.  Maybe it’s ill-founded and maybe it’s not.  So ask for an explanation.  In either case, if you ask for an explanation and follow it as well you can, and then ask for an explanation of why it’s important in this case, you’re showing that you care.  And who doesn’t like showing off their knowledge to an at least apparently interested party?  Oh, and you’re probably learning something useful at the same time.

Sometimes what’s needed is not a full explanation, but the second bit: an explanation of why it’s important, and then a way to make it happen.  Do you need to know the gory details of proofs around Byzantine Fault-Tolerance?  Probably not.  Do you need to know why it’s important for your system?   That’s more likely.  Do you need to know the options for implementing it?  Definitely.

What else?

As I started to write this post, I realised that there were lots of other things I could say.  But once I got further through it, I also realised that there were definitely going to be other things that you[10] could add.  Please consider writing a comment on this post.  And once you’ve considered it, please do it.  Shared knowledge is open knowledge, and open is good.

---

1 – my hypothetical “readership”

2 – by using the pronoun “us” in the title, I’ve lumped myself in with the “normal people”.  I’m aware that this may not be entirely justified.  Or honest.

3 – I’m generalising, obviously, but let’s go with it.

4 – this is a joke, but I’m quite pleased with it.

5 – I suppose there might be more than one, but let’s not get ahead of ourselves.

6 – make sure it’s both, please.  Some people don’t like pizza[7].

7 – me.  I find it difficult to believe that some people don’t like doughnuts, but you never know.

8 – and, if they have their way, on separate email and telephone systems.

9 – well, partially house-trained, at least.

10 – dear reader.