The Role of Usability in Security
From Anita Borg Institute Wiki
Contents |
Speakers
Heather Richter Lipford (University of North Carolina, Charlotte) Diana K. Smetters (Palo Alto Research Center) (recent Google Employee) Mary Ellen Zurko (IBM)
Abstract
In many security solutions, the human has been identified as the “weakest link” in the system, as human errors are a cause of many security vulnerabilities. Usability plays a major role in designing and deploying security and privacy technologies that actually work. In this panel, leaders in the usable security community will discuss taking a user-centered approach to the design and evaluation of security and privacy technologies.
Blog Links
Valerie Fenwick's blog: http://bubbva.blogspot.com/2010/09/ghc10-role-of-usability-in-security.html
Session Notes
Introduction
One problem with security is that the human user either doesn't want to or can't behave as expected. For example, passwords are intended to be random sequences of characters that will be difficult to remember. However, the human brain is not capable of remembering these on their own so that is not practical. It is equally unpractical to write down your passwords and inadvisable to repeat passwords across sites and yet people do this every day. System Attackers typically follow the Weakest Link Idea where they only have to exploit one vulnerability to get in. The human user is again and again the weakest link but we obviously can't cut them out of the system, so what can we do about this?
Security vs. Usability
Usability - systems should be easy, fast, and not obnoxious for the user.
In the security department, systems really need to avoid false positive warnings. These plague the security field. The internet is covered in false positive warnings which users are becoming accustomed to ignoring because they happen so frequently.
In the usability department, you need to make sure the users understand the security feedback. For example, the lock that appears in most internet browsers is often misunderstood to mean the site is secure and trusted. In fact it simply means the website is employing SSL. Dangerous sites are perfectly capable of doing this too so it should not be used as a sign of security.
Security is by necessity a secondary task. The user came to the site first and foremost to accomplish a task so that must be the first priority and no matter how much we'd like to run in an protect the user, we must make sure it is in a way that does not interfere with their primary goals.
Understanding the User
Continuing the idea of the putting the user first, there are several things a security developer needs to keep in mind: 1. Users tend not to appreciate their risks and the negative outcomes. 2. People put short term benefits ahead of long term risks. Ex - Fail to encrypt their email in favor of getting it sent out faster. 3. They might think security conflicts with social norms and self image. They might think people would think they're paranoid if they're proactive about their security. 4. Users don't have a technical understanding of security technology. (And they shouldn't! How can we get around this?)
Security in Cloud Computing
Now that more and more apps are hosted on the cloud and security is controlled by a third party, people are increasingly concerned with how their security is handled. Usability centered security should be transparent with indicators so the user knows if they're safe or not, controllable on multiple levels such as admin or user levels, and there shouldn't be surprises. User mistakes should be addressed so that they will know better for the future or are warned ahead of time and mistakes are avoided.
Meeting the User Halfway
"More than 50% of the certificates on the internet are wrong. No rational human being should follow warning because it’s most probably wrong." - Diana Smetters
So long as false alarms are common there is no way users can properly decide what is really an attack and allow them to react properly. Otherwise, users will rationally ignore them. It's necessary to meet them halfway however. Users can be said to have a 'Compliance Budget'. There is only so much effort they're willing to put into security before they give up. You also must meet ALL users halfway. The system admin is just a much a user as the end user and is in fact more of a danger than the end user because they have many more rights than the typical user.
Meeting the user halfway also means trying to capture the user's intent and verifying it. You have to give up on what you think would be good for the user, and expect them to thank you. Without cultivating an instinct, you often have NO idea what would be hard for a user until you ask.
Additionally, much of security is political. The DNSSEC was not released until recently because of international poltics, not technology.
Photo Sharing on Social Networking Sites
In the modern, Facebook world, you are not always in control of your shared information on the internet. For example, other people tag and own pictures of you that they post. Owners have the right to upload but they should have a moral obligation to respect the ones in the photo and this causes a tension between the groups. Also, what you might not mind sharing with one social circle in your life you would not want to share with another. This exemplifies the idea that privacy, while important, is also very contextual. Social and individual values influence security and privacy decisions. Users need awareness of concrete information flows and detailed control over information sharing.
More Resources
Book: "Security and Usability", O'Reilly -- http://oreilly.com/catalog/9780596008277
CMU Course Recommendation: http://cups.cs.cmu.edu/courses/ups.html
Comments from the Question and Answer Section
One suggestion is to add misuse cases into the project design, or to add a malicious persona into the mix. This lets you advance security concerns along with the other business drivers for a new feature/program.
The justification for ROI on security is similar to the ROI on bugs. The development costs for fixing a bug sooner rather than later are often significant, and the costs for not addressing security concerns is a similar model.
