Sunday, September 13, 2015

How can we describe a buffer overflow in common terms?

We can't.

You think you can, but you can't. This reminds of the Feynman video where he's asked how magnets work and he doesn't explain it, he explains why he can't explain it.

Our problem is we're generally too clever to know when to stop. There are limits to our cleverness unfortunately.

I'm picking on buffer overflows in this case because they're something that's pretty universal throughout the security universe. Most everyone knows what they are, how they work, and we all think we could explain it to our grandma.

There are two problems here.

1) You can't explain away some of the fundamental principals behind computing.

Even if we want to take away as much technical detail as possible, there are some basic ideas that regular people don't know. Computers are magic to most people. When I say most people I mean probably 90% or more of the people. When I say magic, I mean actual magic, not the joking sort of "I really know this isn't magic but I'm being funny". All they know is they push this button and they can pay their bills. They have zero idea what's going on. If someone doesn't understand the difference between a CPU, RAM, and a potato, how on earth will you explain the instruction register to them?

2) They don't care.

Most people just don't genuinely care. Some will pretend to be nice, but a lot won't even do that. Even if we found a nice way to explain this stuff (which we can't), We can't make people care what we're saying. If we're dealing with the likes of a CIO or CEO, they don't care what a buffer overflow is, they don't care how Heartbleed works. They have their goals and while security is important, it's not why they wake up each morning. Some people think they care, but then when we start to talk, they figure out they really don't. Most are nice enough they will let us talk while they're thinking about eating cookies.

So what do we do about it?

The answer is to drive the discussion around the problems. Rather than trying to explain technical details to someone, we have to build trust with them. They need to be able to trust us on some level. If there's a buffer overflow in something, we need to be able to say "here is the patch" or "here is how we can fix this" for example. Then if we've built up trust, we don't have to try to explain exactly what's going on, just that it's something we should care about.

We'll cover how to build trust in the next post.

Join the conversation, hit me up on twitter, I'm @joshbressers