Hacker News new | past | comments | ask | show | jobs | submit login
Our Approach to Employee Security Training (pagerduty.com)
309 points by Corrado 10 months ago | hide | past | web | favorite | 71 comments

> 2. Don’t shy away from technical details.

> The mere mention of the word “hashing” is probably enough to make non-technical employees’ eyes gloss over. So instead I just call it “Magic”.

What..? Why state a principle and then tell us how you violate it a few sentences later.

I think the point is that technical terminology and technical details are different things, and the latter is much more important.

The alternative is to say "hashing is a technical topic, and technical terms intimidate and confuse people, so we won't mention hashing". Instead, the article says that you should try to make hashing approachable and non-intimidating, since understanding the ideas around hashing will help people understand why strong passwords and password managers are important.

I've taught this exact concept to a non-technical audience before. I simply told them it was like scrambling an egg--you can't "unscramble" it and then explained with hashing, you could scramble an identical egg and get identical results and compare the two scrambled eggs to see if they were identical before being scrambled.

That said, I do wonder how well they understood that explanation.

A non-technical audience's ability to understand depends entirely on their willingness to even try. Most people just don't care and want you to stop wasting their time, so they put no effort into internalizing an explanation. If you want to teach people security, first make them care about it beyond not getting caught: from an employee's point of view, they don't need to be faster than the tiger, they just have to be faster than their slowest colleague.

And the scrambles form a unique fingerprint!

Using the standard name can aid understanding by allowing the audience to connect what you're saying to what they already know. However, if the audience's existing knowledge is tainted by fears, misconceptions and confusion, then the connection may hinder more than it helps. In that case, it might be better to make up a new name so the explanation can stand on its own.

I don't know if "magic" was the best choice, but you can still explain all the details of how it works even if you call it something else.

One thing I dislike about medical doctors, is many of them try to "dumb things down" when talking to me. I'd much prefer they tell me the correct technical medical terminology. Some of it I already know what it means, and if I don't I can always ask them to explain further, or go look it up and read more about it.

(My mother and brother are doctors, and I don't get the feeling they are dumbing things down if I ask them for medical advice.)

A professional who talks about technical details, even if I don't completely understand those details, gives me the impression that they know what they are talking about, and that makes me feel confident in their abilities.

As a TA of statistics for non-statistics major, I find it hard to choose the appropriate level of complexity because every audience has a different expectation. I'd encourage you to communicate with your doctors that you'd like the full details and terminology. Otherwise they simply can't know what you want.

It also makes researching what they talked about much much easier. I can google “demyelination” while some metaphorical treatment of the topic involving insulated wires may be substantially less amenable to that.

Take a notepad, write things down, ask questions. Not necessarily in that order. It is a prop, but it indicates you take this seriously and want to learn more.

Or skip the notepad and just ask questions. In my experience some doctors are just jerks or otherwise terrible at cooperative communication; others recalibrate their explanations.

I had a math book in high school that tried using a non standard name to make something sound less scary. I didn’t understand and couldn’t google about it because no one else called it that. I avoided college for a couple years partially because of how hard a time I had with math that year.

To be fair, they did say it was "our approach", they did not say it was a "good approach."

You're right there's some contradiction, but overall I agree technical subjects are nearly always too dumbed down. People are smart! Give them a chance! Boring!=technical. And you can definitely explain hashing in an easy way.

I would substitute "scramble" with "magic". Something like: "The password is scrambled [1] so no one can see what it was originally. Second, this scrambling method ensures the result is the same length as every other password. Third, that very similar passwords, like 'aaaa' and 'aaab' [2] come out very different looking. And it's impossible [3] to descramble it to the original password."

[1] Using a mathematical concept known as "hashing"---see [link] for futher information.

[2] These are bad passwords; used for an example only.

[3] Not quite impossible, but very darned near impossible. See [link] for more information.

I was thinking about this, is a good hashing analogy something like mixing paint? Ie a defined set of constituent colours will produce a particular colour paint. But you can't go from a mixed colour back to the constituents. The only way to find out what constituents are required to create a colour is to try lots of constituents.

Oh that's a very good one. I was using the "magic" approach so far but now I am fond to paint colors. Thanks!

> Boring!=technical.

Yes. One of the best trainings I've been on was in my first job.

40+ minutes on... how to adjust your chair, by the health and safety manager. From how to position the arms, to spinning the chair over and adjusting the springyness of the tilt, to levelling the height against a screen. Almost 2 decades later, I remember the take-aways clearly.

Hashing should be fairly easy to explain - start with a picture of some whole vegetables and maybe a meat (though perhaps not an actual pig....), show them all chopped up, and show a "breakfast skillet" at the end. While discussing, make sure you point out that computers are machines that are really good at doing repetitive tasks like chopping numbers up the same way every time and recombining them.

Heck, that can even make it easy to slip discussion of "salting" in there.

Very interesting read, can't emphasise enough how important _practicing_ for security is as opposed to mere education. A couple of folks I went to Uni with launched a startup that helps companies conduct automated phishing awareness training and continuous employee sensibilisation by sending "white-hat" phishing emails: IT-Seal https://www.it-seal.de/en.html

I can highly recommend giving it a try. The first few levels of difficulty are easy to spot, but it's been eye opening for me how sophisticated phishing emails can get.

I worked at one place that sent a fake phishing email in the employee's first month, and I loved it. I wish they had kept it going, though, doing random re-tests.

It reminds me of the luggage-scanner technology Threat Image Projection: https://www.rapiscansystems.com/en/products/rapiscan-threat-...

Basically I think there's an optimum frequency window for humans detecting and responding to problems. Once real occurrences drop below that frequency, we need to supplement with simulations. Fire drills are the obvious example, but I think we could use a lot more of it.

"It reminds me of the luggage-scanner technology Threat Image Projection"

Yeah, thanks to those I once was asked what that huge hypodermic needle is doing in my hand luggage. I didn't really have a clue and it disappeared, when they scanned it for the second time.

It was an European airport with reasonable security scanners so overall it was a quite funny experience.

Hah! As I understand it, machines with TIP have a button they're supposed to press as soon as they see a threat. Then any fake threats go away. Weird that they didn't do that in your case.

Maybe there was such a button and they rescan it anyway?

After all they have to ensure that there's no other dodgy stuff in there, which may have been obscured by the imposed image.

I hide my real gun behind the fake one.

> by sending "white-hat" phishing emails

I hate those tests. I've been doing anti-phishing work since before the term was coined, and I fail every one of those tests. Why?

Because I load up a virtual env and click on every link in them to see how good of a phish it is.

I suspect this is a problem limited to a very small set of people, but none the less, it's annoying when our head of security comes over and says, "shouldn't you know better?"

In my experience (at a large institution) these phishing tests haven't flagged a user until personal info was actually entered, or some other vulnerable action was taken. Seems like there would be so many false positives otherwise.

Maybe they’ve gotten better since I started ignoring them. But back in the day they flagged you the moment you clicked.

As a security goon, you get pretty detailed reporting on who did what with the email... but you have to decide what to do with it. Punishing and mocking people doesn't work.

A good head of security should be _excited_ for someone who's interested in digging deeper. There's a lot of talk in our field about outreach for security-minded devs and sysadmins (usually called a security champion program).

How many times in your life has that happened?

Why don't you enjoy the opportunity to show off your cleverness to head of security?

The company I am currently working for is doing those and they are making it fun for the employees keeping score and doing prizes, people are actually having fun with it. Kind of a cool approach I think, and it seems to be working too.

Kevin Mitnick's KnowBe4 does it too.

Are there any initiatives out there that offer training/guidance in designing systems where even if someone's credentials are compromised, it doesn't really matter. When there are systems out there that still store passwords in an insecure manner and don't require a second form of authentication, then all the training in the world about password hygiene and recognizing phishing attempts won't fix the actual problem.

"security in depth". This is the kind of problem that can't be solved via specific technology choices, or technical standards.

Instead, it's a matter of understanding that most attacks involve several pivot points; and that these pivots are possible because we treat internal networks as if they are "safe spaces" where we can let our guard down.

In the research this is called "capabilities", limiting your account, not giving everyone root. Also, there is fraud detection, stuff like automatic alerts when the same credential is used in two places at once, or with unusual access patterns.

Obviously it's impossible for compromising credentials to have no consequences -- if case, why do you have credentials?

> Obviously it's impossible for compromising credentials to have no consequences -- if case, why do you have credentials?

For systems that only require a username and password to log in, someone else obtaining/guessing my credentials would have the consequence of someone being able to access my account. But if there's a second credential I have to enter in addition to the username and password, then someone trying to use the username and password alone would not be able to access the account.

Where I work, this second credential is the RSA token along with a PIN. But this could also be accomplished by using a client side TLS certificate on the work provided device or U2F with a work issued Yubi key.

> Concepts such as rainbow tables can then be explained without having to refer to the actual name; we can just demonstrate that you can create a lookup and call it a “magic list”.

Names are there for a reason. "magic list" instead of "rainbow table", seriously? You're teaching a concept and then giving it a slightly different name just to make it sound more edgy. People won't be able to find anything about "magic lists" when they want to read more about rainbow tables. Let alone the completely mad communication you'll get with people in the company.

> We implemented magic sodium suffix in our application this week, attackers won't be able to use magic lists when our magic data leaks.

>> What?

> You know, irreversible magic?

>> ...

How many non-engineers would you expect to take the interest/time to investigate rainbow tables after this? Also, if you follow the link to the actual presentation (https://sudo.pagerduty.com/for_everyone/#hashing for the lazy) then you'll see the author DOES indeed call it hashing, before switching to "magic" so as to make it easier for individuals without a technical background to not have to constantly think about what the term means.

Also, if you continue to RTFA,

> That said, I didn’t want to mislead people. So we chose to be clear to them that there is a technical term; it’s just not going to be important for the rest of the content.

If it's someone job to provide reports/updates on something related to the concept, yes they should know it, for anyone else in a non-technical role, why does it really matter?

It doesn't make it easier though. Hashing makes a hash of the password -- chops it and scrambles it so you can see what it came from. Calling everything "magic" just conflates everything with e everything else, confusing everyone.

> Also, if you continue to RTFA,

I RTFpresentations even. Naming Hashing and then switching to Magic is just confusing for everyone involved. Again; it completely ruins effective communication.

> for anyone else in a non-technical role, why does it really matter?

They're getting security training on the topic of hashing. How does it not matter?? Employees will have to adjust their communication to toddler level anytime they need to talk about security to others.

> They're getting security training on the topic of hashing. How does it not matter??

They're getting taught good password health. You don't need to know what hashing is to know good password health.

I shouldn't get upset over comments but it's headdeskingly frustrating to read comments like yours from people who should know better and who, ultimately, contribute to worse personal security for everybody. Comments like yours are one of the causes behind many people turning their head away at security, not bothering because the barrier of entry is too high and they're made to feel like if they don't have it perfect why bother.

Damn it. The guy communicated pretty damn well if he got 30 employees switching to password managers on their own without actually saying it's required. So instead of criticizing, take it as an opportunity to learn and revise your beliefs.

There's no reason to get personal. We're all on the same side here.

To be clear, the "magic list" thing is focused on non-engineers, who likely will never need to read or write the term "rainbow table" as part of their job, they just need to be convinced that it's important to use a password manager. The presentation also mentions the technical terminology but switches to less intimidating terminology afterward.

The presentation for engineers uses "hash", "rainbow table", etc without ever using the less intimidating terminology: https://sudo.pagerduty.com/for_engineers/

I think you totally miss the point. Explaining something by analogy can be the most effective way of "getting it". Everyone is different. You definitely cannot make such a bold statement about whether the approach was valid.

When teaching about bitcoin, I say “scrambler function” instead of “hash function” because it better conveys the intuition of what they do — even though it’s longer and non-standard. (Most people I talk to don’t immediately associate “hash” with “make a hash of the whole thing” ie mess it up).

Although I also make sure to give the “decoder ring” and the end to list the actual standard terms for the concepts discussed.

OK, so "rainbow table" is what we all call them, but frankly I've always found that name to be baffling. Why are they called that? What is the origin of the name? What do they have to do with rainbows?

Yes, googling "magic list" will not produce the same results as "rainbow table," but it's a good substitute when teaching non-technical people the concept. It might even help them avoid googling unsuccessfully for the origin of the actual name. (If you know the origin, I'd love to know, and so would the people at Wikipedia.)

A rainbow table is named "rainbow table" due to the lines created on a graph when drawing a continuous line through hash and reduction function chain. The graph can visually appear like a rainbow.

A hash function is a one way mapping, and so is a reduction (attempting to invert the hash function but usually failing).

Think of it this way:

Draw a line from plaintext P on the left to hash output H on the right. Then a line from H back to P2 (plaintext 2 on the left), which is the output of the reduction function over H. Draw a line from P2 to H2 (output of the hash function over P2). Do this for a little bit of the chain, and you will visually have a rainbow.

You can also get banding, when drawing them linearly instead of left to right, when taking closed chains into consideration.

If someone sees such a graph of a rainbow table, that explains the concept directly. Caching in a table is just the implementation.

This makes sense to me. Any idea when they were first called rainbow tables?

2003[1] by Oechslin[2] (extending Hellman's[3] idea):

We call our chains rainbow chains. They use a successive reduction function for each point in the chain. They start with reduction function 1 and end with reduction function t−1. Thus if two chains collide, they merge only if the collision appears at the same position in both chains. If the collision does not appear at the same position, both chains will continue with a different reduction function and will thus not merge. For chains of length t, if a collision occurs, the chance of it being a merge is thus only 1/t.

If you read these, you may get the idea that what people call Rainbow Tables really aren't Rainbow tables but Hash Lookup Tables. That's the price we unfortunately pay when people use the wrong words over time, like "Magic Tables" to describe data structures.

  [1] https://lasec.epfl.ch/~oechslin/publications/crypto03.pdf
  [2] https://lasec.epfl.ch/~oechslin/
  [3] https://ee.stanford.edu/~hellman/publications/36.pdf

Thank you for this.

You're welcome.

A real rainbow represents all colors: the full spectrum. A rainbow table has all possible passwords within its spectrum (8 characters, alphanumeric, or however it's defined).

A non-technical term I might use is to call a rainbow table a "reverse phone book for passwords"

Fair enough, but many (probably most) of the people this training is aimed at have no idea what a reverse phone book is. I haven't seen a physical copy of one for a couple of decades.

Do you have a source for the origin of the name, or is it just what comes to your mind when you think of it?

Iirc they acquired that nickname because early rainbow tables, which were in plain text or another simple uncompressed format, looked very much like ASCII rainbow patterns in a text editor due to the iterative nature of the key, salt, and hash stepping.

I don't have a source, but the analogy seems obvious to me. If you're more curious, I guess you could do your own research?

I have, actually. I can't find a reliable source for the origin of the name, even in the original papers written to describe them.

There's no need to comment if you aren't sharing any information or ideas.

The people in the training haven't used "magic" recently either, seeing as magic doesn't exist.

Devising a new, more familiar name for something like hashing is a good idea here because it communicates that “this is a complex thing handled by specialists, but it’s implications are important to us.”

Completely agree. In particular I think the word "hash" is easy to explain. Just tell them it's kind of like the process of creating corn beef hash. Something goes into the process, and when it comes it it's unrecognizable and and you can reverse the process to get a cow back.

> it's unrecognizable and and you can reverse the process to get a cow back.

I am assuming you meant to type "can't reverse the process" here? (and drop the extra 'and'). Apologies for being seemingly pedantic, but the distinction is important here for the very definition of a hash.

Yep, thanks for the correction.

Concepts can have more than one name. An important part of preparing a training or presentation is understanding your audience, and using names that resonate with them.

If this had been a freshman college crypto class, the word "oracle" (https://security.stackexchange.com/questions/10617/what-is-a...) may have been used instead, to indicate that the exact details of hash reversing can be abstracted away and that the key detail is that it's much faster than brute force would suggest.

> That said, I didn’t want to mislead people. So we chose to be clear to them that there is a technical term; it’s just not going to be important for the rest of the content.

Wonder if Fox will demand their artwork be pulled down.

If they can't understand hashing then there's no hope of teaching them security so why even bother?

No, if they can’t understand hashing, then you’ve failed as a teacher.

What Rich has done amazingly well here is use the correct term, but then made the “magic” analogy that allows the concept to be more easily understood by people not within engineering. Think sales, marketing, HR, biz dev, etc.

For those who are interested, they can look up more about hashing afterwards. But for everyone, the concept of how hashes are used was taught with high retention rates.

I'm all for the power of analogy, but I agree with others here that "magic" is a pretty lame choice of words. Anything you don't understand can be described as magic, it's a meaningless analogy that doesn't have any more explanatory power than the word hash does to people who don't know it. The presentation was good, but I bet it would have had similar impact if the word hash had just been used throughout.

I think there's some value for swapping out one semantically opaque word that seems intimidating/"engineer-y" for another equally semantically opaque word that instead connotes "hey, I'm on your side in helping you understand this".

Ie, the value isn't in the word choice itself, but rather in signalling that you empathize with your audience's discomfort.

How is it even a good analogy? Hashing literally means chopping something up and making a mess. Heard of a hash brown? Hash is a dictionary word coming from French. You chop something up into a mess that you can't reassemble, but you get the same mess each time. The word magic needs to stay the hell away from computers.

Not everyone thinks like an engineer. I thought the approach was very appropriate.

This is the security culture infosec has been trying to get everyone to do.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact