“Given a choice between dancing pigs and security, the user will pick dancing pigs every time.” —MCGRAW, G., FELTEN, E., AND MACMICHAEL, R. Securing Java: getting down to business with mobile code. Wiley Computer Pub., 1999
It’s our job to care ● We need to empower through education ● We need to push for small, but long lasting, habitual changes ● We need to mainstream better security heuristics
What’s our job again? Our job is to make a specific task ● that a specific, legitimate user wants to do ● at that specific time ● in that specific place … easy. Everything else we can lock down.
Don’t force prompts if you can help it. ☞ teaches users that security obstructs their work ☞ trains them to dismiss prompts in general ☞ the false alarm effect is a thing
“Each false alarm reduces the credibility of a warning system.” — S. Breznitz and C. Wolf. The psychology of false alarms. Lawrence Erbaum Associates, NJ, 1984
Finding intent We can infer a lot from proximity and relevance, not just aggressive surveys Use our wealth of data to test whether our inferences are correct. Improve, lather, rinse, repeat.
Path of Least Resistance Note the zeroth order path: do nothing This is why we say everything should be secure by default. Doing nothing is the easiest and therefore most common action at any time in any application.
First order path? User behaviour is guided by affordances. ☞ Are your security-relevant interactions discoverable? ☞ Is your security team discoverable? Path of Least Resistance
● If your user doesn’t understand the consequences of an action — don’t surface it ● Hiding things under “advanced” sections is not enough. Path of Least Resistance
● If your user doesn’t understand the consequences of an action — don’t surface it ● Hiding things under “advanced” sections is not enough. Path of Least Resistance
● If your user doesn’t understand the consequences of an action — don’t surface it ● Hiding things under “advanced” sections is not enough. ☞ If you need it, communicate the consequences of any action clearly. Path of Least Resistance
“A system is secure from a given user’s perspective if the set of actions that each actor can do are bounded by what the user believes it can do.” — Ka-Ping Yee, “User Interaction Design for Secure Systems”, Proc. 4th Int’l Conf. Information and Communications Security, Springer-Verlag, 2002
Two approaches: 1. Find their mental model (e.g. infer intent) and communicate to that 2. Influence their mental model (e.g. manage expectations) to better match the system Matching mental models
● This doesn’t mean reading people’s minds ○ Have you tried asking nicely? ○ Have you watched a non-security-expert use your system/process/application? ○ Have you observed a user session? 1: What’s their model?
● Whenever we make things, we teach. ● Whenever someone interacts with us / a thing we made, they learn. ● Often the path of least resistance becomes the default “way to do things”. 2: How do we influence?
● Our job is ultimately about security outcomes ○ Stop expecting everyone to be experts ○ Let people focus on their tasks ○ Go from being the “no” team to being the “yes but what about…” team Takeaways
● Align the user’s goals to your security goals: ○ Aim to know their intent ○ Collaborate with design to craft more secure paths of least resistance ○ Understand the user’s mental model vs yours ○ Communicate to that model Takeaways
heisenburger
taichinakamura
tkikuchi1002
sat
inureyes
comucal
k1low
kazamori
niftycorp
yoshiitaka
nagix
mosa_siru
smt7174
bkeepers
mthomps
jakevdp
sachag
hursman
erikaheidi
dotmariusz
stephaniewalter
keithpitt
jonyablonski
wjessup