
Our Approach to Employee Security Training - Corrado
https://www.pagerduty.com/blog/security-training-at-pagerduty/
======
neotrope
> 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.

~~~
alangpierce
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.

~~~
Natsu
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.

~~~
philipov
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.

------
jrudolph
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](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.

~~~
jedberg
> 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?"

~~~
ericpauley
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.

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

~~~
holdmywaffles
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).

------
u801e
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.

~~~
fjsolwmv
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?

~~~
u801e
> 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.

------
flipp3r
> 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?

>> ...

~~~
merrington
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](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?

~~~
flipp3r
> 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.

~~~
scrollaway
> _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.

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

------
cube00
Wonder if Fox will demand their artwork be pulled down.

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

~~~
kenrose
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.

~~~
c22
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.

~~~
akavi
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.

