How many times have you been afraid to say something about security because you knew if you’re wrong, you’re going to be destroyed in public about it by your peers?
How many times did you try really hard to completely discredit someone who said something wrong about security?
How many times have you been wrong but still argued because you didn’t want to admit it?
How many good ideas never saw the light of day because of this?
I think one of the bigger problems the security industry tends to have is a trait for being overly pedantic. This is true of technical people in general, but in security we turn it up to 11. Now don’t get me wrong, sometimes you need this, there’s no such thing as crypto that’s half right. When we work with normal people though, we can’t be so pedantic.
This of course isn’t a hard and fast rule. Sometimes we need the details to be correct, sometimes we don’t. You have to use your best judgement, but if you’re not sure I suggest you lean toward being understanding (rather than overly critical).
Let’s go through some examples, just for fun.
Question“Hey guys, I’m trying to understand if this patch is correct for a buffer overflow, could someone give it a review?”
Answer“Actually that bug was a buffer overflow caused by an integer overflow.”
We just ensured this person will never ask us for help again. This is a detail they probably don’t really care about. Is the patch right? If not, help them understand what’s going on. Use small words. If they ask questions, be patient. The right way to answer this would have been to look at the patch and ack it if it works, or offer advice on how to fix it if it’s still not done.
Question“Hi everybody, I’m working on adding SSL support to my application. The documentation isn’t great though, are there any examples I could look at?”
Answer“SSL is dead, use TLS!”
While that answer is technically correct (which is the best kind of correct), it’s still not helpful. When you give someone an answer, we have to try and be helpful. If you’re dealing with another security person you can probably be borderline unhelpful as they should know better, but remember, normal people think we’re all crazy, don’t support this theory.
Most people call TLS SSL because they don’t know the difference, honestly to most people there is no difference. The differences between TLS and SSL are huge of course, but if someone is looking for help to enable TLS in their application and they decide to call it SSL, it’s an opportunity to educate them. They don’t need to be experts, but if you’re using a crypto library, you need to sort of know what’s gong on.
Question“Hey, I need help with a new XOR encryption algorithm I’m building.”
Answer“You’re an idiot”
This one is probably OK 😉
If you have any examples to share, I’d love to collect them to use in the future.
By being patient and understanding is how we build trust. You don’t build trust by being harsh. We’ll never make a difference with most people without trust, so this is important. Now when you’re dealing with some technical people, this is the exact opposite, it’s the old show me the code argument, it doesn’t matter how nice you are, if your code is trash you’re not trusted or respected. This doesn’t work with regular people though. They don’t get warm fuzzies form reading code, they like to talk to people in a civilized manner using words they understand.
It’s not easy, but we should all be smart enough to figure it out. Good luck.
Join the conversation, hit me up on twitter, I’m @joshbressers