Making Security Work M. Angela Sasse Dept of Computer Science University College London

December 5, 2002NESC 2 The “Weakest Link” “Security is only as good as it’s weakest link, and people are the weakest link in the chain.” [Bruce Schneier, Secrets and Lies]

December 5, 2002 Framework – Interaction Design GOAL/ TASK CONTEXT USERSYSTEM

December 5, 2002NESC 4 User Characteristics Limitations of human memory Behaviour is goal-driven Knowledge and understanding of security threats and mechanisms Motivation to expend effort Perception and attitudes toward security

December 5, 2002NESC 5 System Factors Security on a per-system basis Applications, networks, OS etc. Proliferation passwords and PINs (banking, phones, websites) “Sticky plaster” approach instead of designed systems Wrong goals - strongest security rather than effectiveness in the real world

December 5, 2002NESC 6 No personal motivation to be security-conscious “No, if I have, I usually don’t have anything to hide or anything, but if I have something, I probably put it on my computer at home.”

December 5, 2002NESC 7 “Nobody would bother to attack me” “You know, if you think about, who’s actually going to go through all that struggle to hack a departmental computer science account of some academic at xxxx college. It’s not like NASA or anything, nothing of interest. “What would make it more likely?” Answer: “Maybe if I was more famous, or…” [laughs]

December 5, 2002NESC 8 “Hackers can’t be deterred anyway” “How foolproof is it?” Answer: “Ahm… I don’t know, really. I think it’s, ah, I haven’t the faintest idea, to be honest. I’ve got a feeling that for most purposes it’s good enough, but I think if somebody’s clever enough and perseveres enough, they will be able to get in. But I can’t see why [laughs]. To be honest.”

December 5, 2002NESC 9 Negative view of good security behaviour “What kind of person is a person who is very concerned about security?” Answer: “I think, it’s just that it’s all a personality type. First all, they could be people who generally have private or confidential information on there. Fine - data, I wanna keep it private. I suppose general personality types. People who would want to be more secure. I don’t know. That’s really a question for psychologists. What sort of people keep their desks tidy. What sort of people comb their hair in the morning.”

December 5, 2002NESC 10 Cont. “Probably the same sort of people who would not give their passwords away. People who are very sort of… either people who are very paranoid about breaches of security or whatever or people who were told “Never give your password away.” without understanding why that would be and therefore they would never do it because they were told not to do it. People therefore who are obedient. People who follow the crowd.”

December 5, 2002NESC 11 No personal accountability “I would say ‘If they can hack into my system, then it can’t be that secure a system to start with. It’s not my job to guarantee the security of the entire xxx computer network.’ “Well, I would just say, you know, this clearly is the work of a hacker, and I think also, people that know me personally would know that I wouldn’t do things like that.”

December 5, 2002NESC 12 Designing usable security Usable mechanisms – Physical & mental workload of users as low as possible – Consider frequency of use Strong but simple policies are easier to understand than more permissive, complicated ones Make assets and threats visible Rationale for security mechanisms and user behaviour in protecting assets

December 5, 2002NESC 13 Task Factors For most users, most of the time, security is enabling task to one or more production tasks If competing with production tasks, it will be eliminated/circumvented whenever possible Production tasks must drive security design

December 5, 2002NESC 14 Designing workable security Security design must be integrated with production tasks Performance determined by Production Tasks Speed, idle times, strength of authentication Availability – viable contingencies – No competing demands for user resources – Match security behaviour to work practices – Workable contingencies

Context Factors Physical – Ease of access and use – Environmental conditions Social – Social conventions (trust) Organisational – Lack of security culture – Assets, roles, responsibilies not clear or understood

Designing security policies Security policies specific to organisation Risk analysis: identify assets, threats, roles, and responsibilities Build positive security culture – Specify expected user behaviour, and penalties for transgression – Enforce penalties, and be seen to enforce them – Reward good user behaviour Security as ongoing process – Monitor and adapt

December 5, 2002NESC 17 Beyond end-users Urgent need to address usability for system administrators and developers Escalating cost Re-think – Simpler architectures – Design for security and usability, instead of sticking it on Support for good security development needed

December 5, 2002NESC 18 Supporting developers Integrate security into development process – Perform security analysis as part of requirements analysis – UML-based model of system, threats and security controls Design patterns – Develop tried & tested security design patterns – Develop design patterns for usable security

December 5, 2002NESC 19 S. Brostoff & M. A. Sasse (2001): Safe and Sound: a safety-critical design approach to security. Procs 10th ACM/SIGSAC New Security Paradigms Workshop. D. Weirich & M. A. Sasse (2001): Pretty Good Persuasion: A first step towards effective password security for the Real World. Procs10th ACM/SIGSAC New Security Paradigms Workshop. M. A. Sasse, S. Brostoff, & D. Weirich (2001): Transforming the “Weakest Link": a human-computer interaction approach to usable and effective security. BT Technical Journal, 19 (3), pp S. Brostoff & M. A. Sasse (2000): Are Passfaces more usable than passwords? A field trial investigation. Procs HCI 2000 pp Springer. A. Adams & M. A. Sasse (1999): Users Are Not The Enemy: Why users compromise security mechanisms and how to take remedial measures. Communications of the ACM, 42 (12), pp