Presentation on theme: "People and Security. Contents People and security – what is the problem? Why usable security is important Introduction to usability principles Best Practices."— Presentation transcript:
People and Security
Contents People and security – what is the problem? Why usable security is important Introduction to usability principles Best Practices for Usable Security in Desktop Software
People and Security – the problem Increasing number of attempted and successful security breaches. User (employee) behaviour often affords or facilitates security breaches. Most users have weak passwords, or can be easily tricked into disclosing them.
Symptoms High cost of operational security –Users - System Adminstrators –Helpdesks- Developers Users’ knowledge about security is inadequate. Most people have negative attitude to security –Seen as a “chore” that “gets in the way” of real work –people who practice good security are seen as “paranoid”
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]
Blame the users? Until recently, security has not considered the human element and usability Proliferation of systems that need to be secured: load on users has increased Security does not speak users’ language (e.g. Whitten & Tygar, 1999)
Fundamental Dilemma “…security-unaware users have specific security requirements, but usually no security expertise.” [Dieter Gollmann, Computer Security]
The way forward Design security as a system –that involves people and technology –that will work in practice –that can be sustained in the long run Take human nature into account Design based on rational assessment of assets, risks and threats
Can systems be secure AND usable? Low usability tends to means low security (except in highly controlled, expensive systems) Generally, usable systems result in better security Specific usability and security issues do sometimes conflict Good analysis of security needs and designing for the real world leads to workable security solutions.
Design Framework TASK CONTEXT HUMANSYSTEM
Users Take user characteristics into account –Physical and mental characteristics –General (apply to all humans) and specific (user group) characteristics Examples: memory, ability to read, pushing buttons Key consideration for large-scale applications: Universal Access
Human Characteristics Physical: –human body –not all users have all characteristics ( biometrics) –Ageing, illness etc. can make operation of some devices difficult (e.g. view keypads, push small buttons) Mental –memory, perceptions, attitudes, beliefs –people seek to reduce complexity/mental workload Most people, most of the time, prefer increased physical to mental workload
Goals and Tasks Human Behaviour is essentially goal- driven Tasks are completed to achieve goals User interacts with system to complete task Production tasks vs. enabling tasks Real-world tasks vs. system tasks
Context Can impact user-system interaction Physical context –Atmosphere, climate, lighting, noise, … –Use “on the move” is different from “at the desk” Social context –Private, semi-private, public? –Social norms govern user behaviour –Organisational or culture (e.g. professional norms)
Usability and Security Many key usability principles can be applied, but security has special challenges: –Active adversary –Many stakeholders, who may have conflicting priorities Both usability and security need to be considered at design stage – “sticking on afterwards” leads to systems that are too complex and expensive to maintain.
Key principles for designing usable systems 1)Minimise users’ physical and mental workload. 2)Make system status visible - provide feedback when and what input has been received. 3)Be forgiving – minimise consequences of error and help users to recover.
Best Practices for Usable Security in Desktop Software
Don’t lie to the user… (Aligning Interface, Information and Action) ROADMAP: 1.Sanitizing disks and files 2.Sanitizing browser history
Deletion and Sanitization Why study deletion? –Affects everybody: we all have private or security-critical information that needs to be deleted. –Lots of lore, not a lot of good academic research.
Today’s desktop systems do a nice job on “delete”… 1. Start with an icon you want to delete 3. Trash icon changes 4. Right-click for empty 6. File is gone 5. Confirm empty 2. Drag it to the trash
Double-click on “Recycle Bin” for more info… Just like PGP 5.0: Good by conventional standards, but does not encourage secure computing practices… Good feedback Good help
Recovery after confirmation… Can you get back a file after you empty the trash? Sure!
The Paradox of “Delete” Delete File can be recovered with “undelete” or forensic efforts. Tossed files randomly get shred Backups provide protection. Intentionally overwritten file cannot be recovered from disk. Special utilities overwrite slack space. Backups don’t get shred. Unlinks file from directory. Put blocks on free list. Allow space to reused. Overwrites file blocks. “Shred” “Toss” Thanks to Clay Bennett at Christian Science Monitor
Sanitization is a big problem “Remembrance” study: –200 hard drives purchased –more than 1/3 had data that been deleted but could be recovered! Hypothesis: data was there because of usability failures…
Drives in storage 200 drives >80GB images (small drives)
DOS FORMAT misrepresents its functionality A:\>format c: WARNING, ALL DATA ON NON-REMOVABLE DISK DRIVE C: WILL BE LOST! proceed with Format (Y/N)?y Formatting 1,007.96M 100 percent completed. Writing out file allocation table Complete. “Data Passed” is a Usability Problem!
Approach #1: Distinguish “Toss” from “Shred” Following publication of “Remembrance,” Apple added “Secure Empty Trash” to MacOS “Secure Empty” takes much longer than regular empty. ≈5 min instead of 5 sec
But separating is not enough… Is this “toss” or “shred?” (“Empty Trash” or “Secure Empty Trash”) Toss! This is “Shred”
The dirty life of a disk block… Free block pool Allocated blocks unlink() Trash Can directory “Empty Trash” “Secure Empty Trash” scrubber Notice: Once a disk block is “emptied,” you can’t go back and “securely” empty it!
Alternative: Redesign the interaction Removed files go onto “old file” list. Kernel grabs free blocks first, then blocks from “old files.” Make “shred” an explicit operation at the interface. –(extend to backup with individual encryption keys for each file)
“Clean object reuse…” Free pool of clean blocks Allocated blocks unlink() Trash Can directory block allocation Scheduled shredding -or- “Shred now” Blocks awaiting shredder… “Move trash to shredder…” (simulation)
Best Practices Distinguish “toss” from “shred.” Don’t use a “swat box” to confirm an action that can’t be undone! –It’s easier to beg for forgiveness than ask for permission –Let people change their minds. –“Polite Software Is Self-Confident” (Cooper, p. 167) ≠
What else do you clear? “Files” can be tossed or shredded… Clear History “Erase my tracks.” “History” is cleared…
IE: Clearing History 1. Select “Internet Options” 2. Select “Clear History” 3. Confirm (no “undo”)
Clearing History Safari makes it easier. Give the ability to remove personal information where it is displayed… It’s obvious because you see it!
Interaction puns One action means two things… Clear History Clear Cache Clear Cookies “Erase my tracks.” Many actions for one thing…
Cache and Cookies are not obvious… What’s a Cache? Where’s the cache?... We’ve had a huge public education campaign to teach people about the “cache…”
Cache and Cookies are not obvious… What’s a Cache?
Each History item points to its entry in the “cache”… … …disk blocks… Clearing the history could automatically clear the cache.
But what about “Secure Empty Trash?” “Clear History,” “Clear Cache” and “Reset Browser” don’t sanitize! The privacy protecting features give a false sense of security. Libraries Kiosks Shared Machines
Best Practices Allow personal information to be corrected or deleted where it is shown. If you “toss” potentially sensitive information, shred the bytes! –Especially if you are tossing for privacy.