Security and Usability | O'Reilly Media

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Matt Bishop

IN 1987, BRIAN REID WROTE "PROGRAMMER CONVENIENCE IS THE ANTITHESIS OF SECURITY, because it is going to become intruder convenience if the programmer's account is ever compromised." This belief of the fundamental conflict between strong computer security mechanisms and usable computer systems pervades much of modern computing. According to this belief, in order to be secure, a computer system must employ security mechanisms that are sophisticated and complex—and therefore difficult to use.

Today a growing number of security researchers and practitioners realize that this belief contains an inherent contradiction. The reason has to do with the unanticipated result of increasing complexity. A fundamental precept of designing security mechanisms is that, as the mechanisms grow more complex, they become harder to configure, to manage, to maintain, and indeed even to implement correctly. Errors become more probable, thereby increasing the chances that mechanisms will be configured erroneously, mismanaged, maintained improperly, or implemented incorrectly. This weakens the security of the system. So the more complex a system is, the more secure it should be—yet the less secure it is likely to be, because of the complexity designed to add security!

Finding ways to maximize both the usability of a system and the security of a system has been a longstanding problem. Saltzer and Schroeder's principle of psychological acceptability (see the sidebar) says that a security mechanism should not make accessing a resource, or taking some other action, more difficult than it would be if the security mechanism were not present. In practice, this principle states that a security mechanism should add as little as possible to the difficulty of the human performing some action.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Passwords are a mechanism designed to authenticate a user—that is, to bind the identity of the user to an entity on the computer (such as a process). A password is a sequence of characters that confirms the user's identity. If an attacker guesses the password associated with an identity, the attacker can impersonate the legitimate user with that identity.

Problems with passwords are well known; one of the earliest ARPANET RFCs warned that many passwords were easy to guess. But a well-known problem is usually an unsolved problem. Reid's lament involved someone guessing a password on a poorly maintained system, and from there intruding upon a large number of systems at a major university. In the early 1990s, CERT announced that many attackers were using default administrative passwords to enter systems. In the early 2000s, a CERT advisory reported a "back door" account in a database system with a known password. SANS includes password selection issues as two of the current Top 20 Vulnerabilities, as well as several exploits that depend upon accounts with no passwords or with passwords set by the vendor. For example, the SQLSnake/Spida Worm exploits an empty password for the default administrative account for Microsoft SQL Server.

The principle of psychological acceptability, taken literally, says that passwords should be unnecessary. But the use of passwords to protect systems adds minimal overhead for people who are using the system, provided that the passwords are easy to remember. To be effective, the passwords must also be difficult to guess. So, how can passwords be made easy to remember, yet difficult to guess?

One difficulty in solving this problem lies in balancing the ability of a human to remember a password that an attacker will find difficult to guess against the ingenuity of the attacker. The attacker has the advantage. People choose passwords that they can remember easily. Unfortunately, these are usually easy to guess. Experiments by Morris and Thompson and others were able to guess user passwords for between 25% and 80% of the users. The users typically picked dictionary words, names, and other common words. Amusingly, in one experiment, the analyst was able to determine who was dating whom, because many passwords were, or were derived from, the names of the users' partners.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Correcting problems such as default or empty passwords poses problems when the vendor distributes the correction. As an example, for many years, Microsoft's SQL Server was distributed with an empty password on its administrator account. This changed when the SQLSnake/Spida Worm exploited that empty password to acquire access to servers running that database. Microsoft issued a patch to update the server and add a password.

A patch is an update to a program or system designed to enhance its functionality or to solve an existing problem. In the context of security, it is a mechanism used to fix a security problem by updating the system. The patch, embodied in a program or script, is placed on the system to be patched, and then executed. The execution causes the system to be updated.

Ideally, patching should never be necessary. Systems should be correct and secure when delivered. But in practice, even if such systems could be created, their deployment into various environments would mean that the systems would need to be changed to meet the needs of the specific environment in which they are used. So, patching will not go away. However, it should be minimal, and as invisible as possible. Specifically, the principle of psychological acceptability implies that patching systems should require little to no intervention by the system administrator or user.

Unfortunately, several considerations make invisible patching difficult.

The first difficulty is collecting all of the necessary patches . In a homogeneous network, only one vendor's patches need to be gathered, but a single vendor may offer a wide variety of systems. The patches for one system likely will not apply to another system. If the network has systems from many vendors, the problem of gathering and managing the patches is severe. Various tools such as Cro-Magnon and management schemes using several tools attempt to ameliorate this task. All require configuration and maintenance, and knowledgeable system administrators.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Building a secure system does not assure its security: the system must also be installed and operated securely. Configuration is a key component of secure installation and operation, because it constrains what users and the system processes can do in the particular environment where the system is used. For example, a computer configured to be secure in a university research environment (in which information is accessible to everyone inside the research group) would be considered nonsecure in a military environment (in which information is accessible only to those with a demonstrated need to know). Different configurations allow a system to be used securely in different environments.

The decisions about configuration settings that a vendor faces when constructing patches are, to say the least, daunting. The vendor must balance the need to take into account the security policy of the sites to which the patch will be distributed with the need to provide a minimal level of security for those sites that cannot, or do not, reconfigure an installed patch. The principle of psychological acceptability dictates that, whatever course is followed, the installers of the patch not only should be able to alter the default configuration with a minimum of effort, but also should be able to determine whether they need to alter the default configuration with a minimum of effort.

An example will illustrate the dilemma. This example first arose from a system that was designed for academic research. One version was widely distributed with file permissions set by default to allow any user on the system to read, write, and execute files on the system. Once the system was installed, the file permissions could be reset to allow accesses appropriate to the site. This approach violated the principle of fail-safe defaults, because the system was distributed with access control permissions set to allow all accesses. It also required all system administrators to take action to protect the system. An advantage of this is that it forced administrators to develop a security policy, even if only a highly informal one. But the price was that system administrators had to apply mechanisms after the system was installed, violating the principle of psychological acceptability. Had the system been distributed with rights set to some less open configuration, system administrators would not need to act immediately to protect the system. This would have been a less egregious violation of the principle of psychological acceptability. Fortunately, for the most part, system administrators understood enough to apply the necessary changes, and knew of the need when they received the system.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The lesson that we draw from the three illustrations provided in this chapter is that the solution to the problem of developing psychologically acceptable security mechanisms depends upon the context in which those mechanisms are to be used. In an environment in which only trusted users have access to a system, simple passwords are sufficient; but in a more public environment, more complex passwords or alternate authentication mechanisms become necessary. Patches designed for a known environment can modify the system with little or no user action; patches applied in an environment different from the one for which they are designed risk creating security problems. Complex configurations lead to errors, and the less computer-savvy the users are, the worse the security problems will be.

This lesson suggests an approach to improving the current state of the art. Testing mechanisms by placing them in environments in which they will be used, and analyzing the way in which those mechanisms are used, will show potential problems quickly. But this requires using human subjects to test the mechanisms. Actually testing mechanisms on the populations that are to use these mechanisms will provide useful data. Testing mechanisms on the programmers and designers of those mechanisms may give some insight into potential problems. However, this latter testing will not reveal the problems arising from errors in installation, configuration, and operation by users unfamiliar with the mechanisms' design and implementation.

The principle of psychological acceptability is being applied more often now than it has been in the past. We have far to go, however. The primary problem with its current application is the range of users to which it must be applied. How can one create mechanisms that are easy to install, provide the protection mechanisms necessary, and are unobtrusive in use, for people ranging in skill from novice home computer users to system administrators who manage hundreds of computers from many different vendors? This remains an open question—one that may very well be insoluble.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Matt Bishop is a professor in the Department of Computer Science at the University of California at Davis. He studies the analysis of vulnerabilities in computer systems, policy models, and formal modeling of access controls. He is active in information assurance education, is a charter member of the Colloquium on Information Systems Security Education, and has presented tutorials at many conferences. He wrote the textbooks Computer Security: Art and Science and Introduction to Computer Security (both from Addison Wesley).

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

M. Angela Sasse and Ivan Flechais

SECURITY EXPERTS FREQUENTLY REFER TO PEOPLE AS "THE WEAKEST LINK IN THE CHAIN" OF SYSTEM SECURITY. Famed hacker Kevin Mitnick revealed that he hardly ever cracked a password, because it "was easier to dupe people into revealing it" by employing a range of social engineering techniques. Often, such failures are attributed to users' carelessness and ignorance. However, more enlightened researchers have pointed out that current security tools are simply too complex for many users, and they have made efforts to improve user interfaces to security tools. In this chapter, we aim to broaden the current perspective, focusing on the usability of security tools (or products) and the process of designing secure systems for the real-world context (the panorama) in which they have to operate. Here we demonstrate how current human factors knowledge and user-centered design principles can help security designers produce security solutions that are effective in practice.

The need for people to protect themselves and their assets is as old as humankind. Peoples' physical safety and their possessions have always been at risk from deliberate attack or accidental damage. The increasing use of information technology means that individuals and organizations today have an ever-growing range of physical (equipment) and electronic (data) assets that are at risk. To meet the increasing demand for security, the IT industry has developed a plethora of security mechanisms that can be used to make attacks significantly more difficult or to mitigate their consequences.

A series of surveys has shown that—despite ever-increasing spending on security products—the number of businesses suffering security breaches is increasing rapidly. According to the United Kingdom's Department of Trade and Industry's Information Security Breaches Surveys, 32% of UK businesses surveyed in 1998 suffered a security incident, rising to 44% in 2000 and 74% in 2002, and reaching a massive 94% in 2004. The 2004 CSI/FBI Computer Crime and Security Survey reports that U.S. companies spend between $100 and $500 per employee per annum on security. But purchasing and deploying security products does not automatically lead to improved security. Many users do not bother with security mechanisms, such as virus checkers or email encryption, or do not use them correctly. Security products are often ineffective because users do not behave in the way necessary for security mechanisms to be effective. For example, users disclose their passwords, fail to encrypt confidential messages, and switch virus checkers off. Why? Because most users today:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The need for people to protect themselves and their assets is as old as humankind. Peoples' physical safety and their possessions have always been at risk from deliberate attack or accidental damage. The increasing use of information technology means that individuals and organizations today have an ever-growing range of physical (equipment) and electronic (data) assets that are at risk. To meet the increasing demand for security, the IT industry has developed a plethora of security mechanisms that can be used to make attacks significantly more difficult or to mitigate their consequences.

A series of surveys has shown that—despite ever-increasing spending on security products—the number of businesses suffering security breaches is increasing rapidly. According to the United Kingdom's Department of Trade and Industry's Information Security Breaches Surveys, 32% of UK businesses surveyed in 1998 suffered a security incident, rising to 44% in 2000 and 74% in 2002, and reaching a massive 94% in 2004. The 2004 CSI/FBI Computer Crime and Security Survey reports that U.S. companies spend between $100 and $500 per employee per annum on security. But purchasing and deploying security products does not automatically lead to improved security. Many users do not bother with security mechanisms, such as virus checkers or email encryption, or do not use them correctly. Security products are often ineffective because users do not behave in the way necessary for security mechanisms to be effective. For example, users disclose their passwords, fail to encrypt confidential messages, and switch virus checkers off. Why? Because most users today:

Have problems using security tools correctly (for an example, see the classic paper on PGP by Whitten and Tygar, reprinted in of this volume)
Do not understand the importance of data, software, and systems for their organization

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

It is unfortunate that usability and security are often seen as competing design goals in security, because only mechanisms that are used, and used correctly, can offer the protection intended by the security designer. As Bruce Tognazzini points out in , a secure system needs to be actually, not theoretically, secure. When users fail to comply with the behavior required by a secure system, security will not work as intended. Users fail to show the required behavior for one of the following two reasons:

They are unable to behave as required.
They do not want to behave in the way required.

The current situation with computer passwords provides a good example of the first case: most users today find it impossible to comply with standard policies governing the use of computer passwords (see in this volume). Remembering a single, frequently used password is a perfectly manageable task for most users. But most users today have many knowledge-based authentication items to deal with. We have multiple and frequently changed passwords in the work context, in addition to passwords and personal identification numbers (PINs) outside work, some of which are used infrequently or require regular change. The limitations of human memory make it impossible for most users to cope with the memory performance this requires. As a result, users behave in ways forbidden by most security policies:

Users write passwords down. Externalizing items we have to remember is the most common way of dealing with memory problems. In office environments, users stick notes with passwords onto their screens, or maintain a list of current passwords on the nearest whiteboard.

Similarly, many bank customers write their PINs on their cards. A less common remedy is to write or scratch the PIN on the ATM or its surroundings.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The process of building a secure system is vital to its effectiveness. The process is the means by which security needs are assessed, policies are elaborated, and countermeasures are designed. As with any software development project, the right mix of participants, expertise, and methodology is vital in ensuring a system that is actually secure. To achieve this, designers of secure systems need to consider that security is not the primary goal of users and organizations. The role of security is a supporting one—to protect assets and activities that users care about or that are part of the production activity of business organizations.

Two further concepts that are key to designing successful security applications are goals and tasks. Human behavior is essentially goal driven, so the effective and efficient execution of tasks that help users attain goals is a key principle for designing successful systems. Human factors analysts distinguish between production tasks (those that are required to achieve the goal or produce the desired output) and supporting tasks (those that enable production tasks to be carried out in the long run, or be carried out more efficiently, but are not essential to achieving the goal). Security—like safety—is a supporting task . Production tasks are the reason why a system exists, and if production tasks cannot be completed effectively and efficiently, the system will cease to exist. Users put production tasks first; organizations, sensibly enough, do the same from a higher-level perspective. This understanding leads us to a number of insights for security design :

Security tasks must be designed to support production tasks. Security tasks must not make demands on users that conflict with the demands of their production tasks. The performance requirements for a security task must be derived from the performance requirements for the production task. The current reality is that security mechanisms are often chosen without consideration of the production tasks, and individual users are often left to make a choice between complying with security regulations on the one hand or getting their job done on the other—and the choice they make is predictable. When security needs require a reduction in the efficiency of a production task, the need for the extra effort has to be communicated clearly to users. Tradeoffs between production tasks and security should not be made by security experts, who naturally prioritize security over efficiency. Rather, these decisions should be made in consultation with those in charge of business processes and workflow.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The environment surrounding the process of developing security is also extremely important to the effective operation of the product (security mechanism). During the design of the security, a number of factors not necessarily related to any security needs can influence the final product. The personal responsibility of participants for the resulting security, the enthusiasm of high-level management for security (even their presence in the design process), pressure to achieve functional features, time-to-market, personal agendas, ethical constraints, industrial involvement, and legal requirements—all influence security design in one way or another.

The cultural panorama surrounding security does not stop affecting it after the design is complete, but continues even after it has been put to use. An analysis by Flechais, Riegelsberger, and Sasse has identified the influences and mechanics of trust relationships in the operation of secure systems. In most current cases, existing trust relationships in an organization facilitate the breaking of security policies and practices. In fact, given the right (and currently widespread) environment, simply adhering to existing security policies can undermine social relationships within a group of peers. The authors argue that trust relationships are beneficial for organizations by promoting social capital (i.e., trust based on shared informal norms that promote cooperation) and that the organizational culture and the actual security should be designed to support both trust relationships and adherence to policy.

While a well-designed security mechanism won't put off users, it also won't entice them to make the extra effort that security requires. In many home and organizational contexts, users lack the motivation to make that extra effort. User education and training can be used to explain the need for the effort that security requires, but changing users' knowledge and understanding does not automatically mean they will change their

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This chapter started with the observation that only usable security is effective security, and outlined how human factors knowledge and user-centered design techniques can be applied to increase usability. Effective security requires us to look beyond the user interface to security tools, where most of the current research and development effort is focused. Changing undesirable user behavior is a complex task, and one that cannot be achieved by education or punishment alone. An organization is a sociotechnical system, and security design needs to address both technical and human aspects. Furthermore, security needs to be integrated into the business processes of an organization to be workable in practice and economically viable.

As a first step in this direction, Brostoff and Sasse have adapted Reason's model of human error (a sociotechnical model for improving safety behavior in organizational contexts) to security. Reason's model is a good starting point because safety and security share the "supporting task" problem. Two key differences are that the benefits of safety are more obvious to most users, and that safety does not have adversaries who actively seek to attack. In many Western countries, health and safety regulations have led to significant changes in organizational culture with respect to employee safety. Responsibility for safety lies with management, for they allocate resources; this chapter has made the argument that security needs to be viewed in a similar way.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

M. Angela Sasse is the Professor of Human-Centred Technology in the Department of Computer Science at University College London. After obtaining an M.Sc. in Occupational Psychology (from the University of Sheffield) and a Ph.D. in Computer Science (from the University of Birmingham), she joined UCL in 1990 to teach and research design and evaluation of emerging technologies. Since 1997, her research has focused on user-centered approaches to security, privacy, and trust.

Ivan Flechais is a departmental lecturer in the software engineering program at Oxford University, and his main lecturing and research interests are in the area of computer security. Prior to this, he graduated with a B.Sc. in computer science from University College London, and then stayed on at UCL with a Ph.D. researching security design and the importance of people in computer security.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Bruce Tognazzini

THE GOAL OF SECURITY IS NOT TO BUILD SYSTEMS THAT ARE THEORETICALLY SECURABLE, but to build ones that are actually secure. This requires a combination of the theoretical and the practical. It requires close examination not only of the technology, but also of the human beings that will use it.

We can easily require users to supply passwords that are theoretically unbreakable—for example, 50 characters of random ASCII data—but we must consider the capabilities and habits of real people. Everyone would immediately post their password on a little piece of paper on their monitor, then spend hours trying to enter it accurately, their errors hidden by those delightful little dots that march across our screens.

Even closing every possible loophole in the system cannot provide perfect security. Dedicated and knowledgeable spies will install software of their own, such as keyboard "sniffers" that report back every entry typed, circumventing the most elaborate precautions. The poor user ends up the victim in all this, battered by impossible memory and accuracy demands.

Fortunately, there's a solution to such misfortune. In this chapter, we'll look at ways of balancing security and usability, security and privacy, and how to achieve a comprehensive security plan that works by considering both internal and external factors. Finally, I will propose a way of rethinking security issues so that our solutions will offer real security, rather than just the appearance of security.

Lately, automakers have been bowing to insurance companies by adding special lug nuts to each wheel, keyed to a special socket that must be used to remove the wheel. Unfortunately, some of these special lug nuts have only about 2% or 3% of the surface in contact with the tool, compared to a standard lug nut. If the wheel is overtightened at the factory, as was done with our Lexus RX-300, the custom part of the lug nut will crack right off the car when you attempt to change a spare tire on a dark road late at night, as happened to us, rendering removal of the wheel impossible.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Lately, automakers have been bowing to insurance companies by adding special lug nuts to each wheel, keyed to a special socket that must be used to remove the wheel. Unfortunately, some of these special lug nuts have only about 2% or 3% of the surface in contact with the tool, compared to a standard lug nut. If the wheel is overtightened at the factory, as was done with our Lexus RX-300, the custom part of the lug nut will crack right off the car when you attempt to change a spare tire on a dark road late at night, as happened to us, rendering removal of the wheel impossible.

We have installed standard lug nuts all around on both our cars now, and to heck with our auto insurance company. We want to keep our life insurance company happy!

Even when the auto security people aren't setting us up for a mugging, they are raising our blood pressure to dangerous heights. We had a VW Rabbit several years ago that featured a theft-proof radio, rendered useless once it was removed from the vehicle. It could only be made to function again by performing an elaborate and secret ritual, involving pressing a whole bunch of buttons in sequence while holding your right foot with your left hand and crowing to the moon.

Of course, the radio didn't really "know" it had been stolen. It only "knew" that it had lost its connection to the car battery. Therefore, the first time the battery went dead, we no longer had a radio.

VW had given us a sheet with the magical incantations, but it had warned us not to leave the sheet in the car, the equivalent to leaving passwords on a yellow sticky stuck to the side of a monitor. Ever compliant, we put the sheet in "a safe place," where it probably rests today. (I can't say for sure, since we can't remember where the safe place is.)

So we contacted our dealer, and after waiting several weeks for VW to confirm our identity through DNA analysis, we received a copy of the magic sheet. This second copy remained in plain sight in the glove box for as long as we owned the car. Strangely, no one ever stole the radio, although the buttons finally gave out from our having to repeatedly key in the special code every time we left the lights on or the car was serviced.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Balance is key to all security efforts. The same phenomenon that happens with cars happens with computers. Unless you stand over them with a loaded gun, users will disable, evade, or avoid any security system that proves to be too burdensome or bothersome. Preventing your system from becoming the victim of such "empowered" users requires a combination of engineering and education. The engineering builds security systems that are safe and usable, and the education informs users about the actual risks so that they will be motivated to use your security (or at least so that they won't disable it).

How do you find the right balance? You begin by examining and exploiting, in each new situation, the differences between the two groups.

Let's return to those "marching dots" that I mentioned in my introduction. The purpose of those dots is to protect a password from "shoulder surfing" as it is being entered. In theory, if you have a strong password that's sent over an encrypted link, shoulder surfing is the main threat that passwords face.

But the user who actually types the password is in a fundamentally different position from a potential shoulder surfer. Consider:

The user knows what he is typing—he is only looking for errors.
The user is close to the screen where the password is being entered—he can read text that is printed with relatively low contrast.
The user is always present.

Now, compare that with a potential attacker:

An eavesdropper needs to accurately reconstruct every character in the password.
An eavesdropper is probably several feet away from the screen—if that.
An eavesdropper might not even be present—the user might be entering the password in the privacy of his own home, for example, or on a desert island.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

We often say "privacy and security" in the same breath, but they can often be at odds with each other.

Let us look at an example: the problem of increasing access to employees on the job. One of the earliest technologies to be deployed in this effort was a smart card that reported to a central computer, several times a minute, the current location of each and every employee so that they could always be found. It seemed only natural to make better use of this flood of data, so it was not long before bosses were receiving printouts of how much time employees were spending at the water cooler, the lunch room, and even the bathroom. In the rush to pry, the original goal of the technology was all but forgotten.

Another technology offers the same ability to maintain employees' access, while at the same time actually enhancing employees' privacy: portable telephones. Whether they be cell phones or local wireless phones, they offer the employee the ability to wander freely while still maintaining contact, and they do so without (necessarily) ratting out the employee's location.

This approach actually enhances privacy: before, should the boss ring the employee's phone in his office, she could ascertain whether he was in the office. With a portable phone, the caller has no idea where the employee is (unless sounds of a live ballgame give him away). At the same time, these phones make contact easier than with the smart cards, since the boss no longer has to slog off in pursuit.

For employers who judge their workers by how busy they look, such a scheme might well send chills down their back. For employers who, instead, judge employees by the quality of their results, such a system solves the employer's problem without shredding the last vestiges of employee privacy.

A new threat to our personal liberty is the electronic cards being used for rapid toll paying. These cards were designed to record the time the car passed through the toll station and remove the toll amount from their account. It wasn't long before they were pressed into use in tracking ongoing kidnappings, something everyone applauded (except for the Kidnapper's Union).

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

We are now engaged in the transition from isolated one-person computers to the concept of a personal network, enabling people to tap into their personal cyberspace from any point on the globe.

The most fundamental requirement of such a personal network is that individuals be able to maintain the most private of information without worry, no matter where their travels might take them. They further need to be able to monitor and control access of others both to their information and to themselves. Before that can occur, we will have to build a multiplicity of new, secure walls.

The original ARPANET , forerunner to today's Internet, was the exclusive domain of university scientists and the U.S. military. The world was neatly divided into "We" and "They." "We," the "good guys," had access to ARPANET. "They," everyone else in the world, did not. Security, in those days, consisted of keeping the "bad guys" from gaining physical access of any kind to the network.

Achieving balance:

Are you exploiting the differences between users and attackers?
- Users know what they are typing in—they are only looking for errors.
- Eavesdroppers, meanwhile, have to reconstruct every character accurately.
- Users are closer to the screen and therefore can read with lower contrast and can differentiate better between green and blue (unless they are colorblind).
Are you detecting and exploiting differences in physical location?
- Home

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The evidence of fatal flaws in today's security approach is all around us, gracing the edges of monitors across the world. We need to take the initiative. We need to look outward, to the way things "really work" once people are in the mix.

If you are a security expert, you must search for, address, test, and actively solicit feedback about every eventuality.

If you are a student who will study security, seek out professors who spend time in the field observing and studying security systems under real-world conditions. The focus of university teachings to future practitioners needs to change. The yellow sticky phenomenon has become so pandemic that it has received attention in both newspapers and business journals. Both students and professors need to do field studies of real people working in real environments.

If you are among the competent, enlightened security experts who are in the field today, you need to work to change your profession. It is in trouble. Practitioners in this field are, in my experience, uniformly bright and technically competent. They just need a new focus on users.

If you are an interaction designer who must work with a security expert whose focus ends at the edges of the computer screen, don't despair. He or she is in need of help, not criticism. Take responsibility on yourself to form a comprehensive security plan. Ensure that user, field, and quality assurance testing, along with user-feedback systems, are all in place to thoroughly and comprehensively prove out the security design.

If you are an interaction designer who gets to work with a competent security professional, thank your lucky stars. I've had the pleasure of working with more than a few, and it is a sheer joy.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Bruce "Tog" Tognazzini has been part of personal computing from the beginning. He built his first electro-mechanical computer in 1959, and was employee #66 at Apple, where he spent 14 years before going on to be a Distinguished Engineer at Sun Microsystems, then Chief Designer at Healtheon/WebMD, and finally becoming the third Principal at the Nielsen Norman Group. He publishes http://asktog.com, has written two books, has coauthored three others, and currently has 49 patents issued in HCI, automotive safety, and aviation.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Clare-Marie Karat, Carolyn Brodie, and John Karat

THIS CHAPTER SHOWS HOW YOU CAN INCORPORATE USABILITY DESIGN AND EVALUATION into the life cycle of privacy and security solutions. Here we provide you with an overview of critical-path human-computer interaction (HCI) activities that occur during the development of successful solutions and their maintenance after release. We will point you to key publications and references that you can use to gain a more in-depth understanding of HCI methods and practices in evaluating the usability of your security and privacy systems. And we will walk you through the use of these methods in a case study of a security application as well as a case study of two years of research on privacy tools for authoring and implementing privacy policies.

Of course, this chapter alone cannot make you proficient in using HCI methods. But it will guide you in understanding the value that HCI work can contribute to the success of your product.

We recommend that most projects bring an HCI expert on board early in the project's development, and that the HCI expert be a full team member. Working together, the project team should define the usability activities as a critical development path. We have seen many successful examples where the HCI lead's expertise was leveraged to train and educate the product team so that team members completed parts of the HCI project plan with consultation and collaboration from the HCI expert. We have also seen several examples of skilled computer scientists and programmers who gradually became HCI specialists, frequently with great success. One of this chapter's co-authors, Carolyn, has, in fact, followed such a career path!

Properly applied, HCI methods and techniques elicit and identify the useful information in each phase of the project life cycle . These activities can facilitate a more accurate and complete project definition during the requirements phase and an improved project design during the design phase. During the development phase, they can improve solution performance and reduce development time and costs. The benefits of HCI and usability activities continue after release, including increased user productivity and satisfaction, reduced training, support, and error recovery costs, increased sales and revenue, and reduced maintenance costs.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Properly applied, HCI methods and techniques elicit and identify the useful information in each phase of the project life cycle . These activities can facilitate a more accurate and complete project definition during the requirements phase and an improved project design during the design phase. During the development phase, they can improve solution performance and reduce development time and costs. The benefits of HCI and usability activities continue after release, including increased user productivity and satisfaction, reduced training, support, and error recovery costs, increased sales and revenue, and reduced maintenance costs.

Although many HCI techniques are general, there are unique aspects in the design of privacy and security systems that present challenges and opportunities.

First, a key issue to consider is that security and privacy are rarely the user's main goal. Users value and want security and privacy, of course, but they regard them as only secondary to completing primary tasks like completing an online banking transaction or ordering medications. Users would like privacy and security systems and controls to be as transparent as possible. On the other hand, users want to be in control of the situation and understand what is happening. Therein lies the rub. As a consequence, the display of information and the interaction methods related to security and privacy need to be accessible if and when desired by the user, but they shouldn't get in the way.

Second, as more of people's interactions in daily life involve the use of computing technology and sensitive information, disparate types of users must be accommodated. Security solutions in particular have historically been designed with a highly trained technical user in mind. The user community has broadened extensively as organizational business processes have come to include new types of roles and users in the security and privacy area. Many compliance and policy roles in organizations are handled by legal and business process experts who have limited technical skills. Moreover, the end user base includes virtually everyone in the population. The functionality provided by the system for people with different roles must accommodate the skill sets of each. Security and privacy are requirements for doing business as an organization and must be done well, or the organization may lose the user as a customer—or worse.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Clare-Marie Karat was the HCI lead on the development of a security application in 1989. She provides a firsthand account of the process she used to understand the user requirements and improve the usability of this product.

The project's goal was to improve the dialog of a large data entry and inquiry mainframe application used by 23,000 end users (IBM employees in branch offices across the U.S.). This large mainframe application was composed of many subapplications. The goal was to eliminate the recurring need for security authorization while performing discrete but related tasks that composed a business process. However, the project had entered the design and development phase: coding had already begun. So, before I actually joined the team, the project manager and I agreed upon the approach that I would use. I would quickly complete the HCI activities that should have been done in the requirements phase, then move ahead with the design and development phase HCI work.

Prior to the development of this security application, working with the mainframe application was like having a series of disconnected conversations for the end user. Every time a user wanted to perform a transaction, he had to re-identify, provide a password, select the appropriate application, and type a command known as a mnemonic that indicated the type of transaction to be performed. Further, the use of the actual mnemonics was controlled: users were only told about the mnemonics relevant to their individual job responsibilities and were instructed not to write down the mnemonics or share them with anyone.

I met with the project team to understand the goals of the project and define the overall usability goal. They were ambitious. The old security application was to be taken down on a Friday, the new application was to be installed over the weekend, and employees needed to be able to walk up and use the new security application the next Monday. The transition had to be smooth, without disrupting the end users or business. End users signed on to the target mainframe application about a dozen times a day.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In 2002, we became involved in a research project concerned with the development of approaches for helping organizations protect the personal information (PI) that they used and stored about their customers, constituents, patients, and/or employees. Most organizations store PI in heterogeneous server system environments. In our initial review of the literature and interview research, we found that organizations do not currently have a unified way of defining or implementing privacy policies that encompass data collected and used across different server platforms. This makes it difficult for the organizations to put in place proper management and control of PI that allows the data users to access and work with the PI inline with organizational privacy policies. Our task was to collect data to help us understand the problem and propose solutions that would meet the needs of organizations for privacy policy management.

This work involved a wide range of user-centered techniques (discussed earlier in the chapter). This project differs from the security application presented earlier in at least three important ways; it therefore highlights the application of different usability and evaluation techniques to the creation of a privacy application:

The case study involves the creation and use of new software technologies rather than the addition of an incremental improvement to a system using existing technology.
The targeted user community is broader and includes different user groups across a variety of domains and geographies.
The solution requires integration with the organization's heterogeneous configurations, including valuable legacy applications.

To create technology to support all aspects of organizational development and use of privacy policies, we needed to understand the concerns of a large and diverse user group. The research included four steps:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Our experiences at IBM show that HCI activities can have a positive return both for the organization creating a piece of technology and for the people who actually use it.

We encourage you to start integrating HCI activities in your development activities in the security and privacy domain. It is helpful to start with a small to medium-size project or product as a test case and learning vehicle. Bring an HCI expert on board, and leverage this person's skill and build expertise in the larger team. Hold team discussions so that you can build on what you learn in this area within your organization and in your professional associations. Communicate your successes and failures so that people within and outside your organization can benefit from your experiences.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Clare-Marie Karat is a Research Staff Member at the IBM T.J. Watson Research Center. Dr. Karat conducts HCI research in the areas of privacy, security, and personalization. She is the editor of the book Designing Personalized User Experiences in eCommerce, published in 2004 (Springer). She is an editorial board member of the ACM interactions, the British Computer Society's Interacting with Computers, and Elsevier's International Journal of Human Computer Studies journals; a reviewer for the IEEE Security and Privacy journal; and a technical committee member of the CHI, HFES, and INTERACT conferences, the Symposium on Usable Privacy and Security, and the User Modeling Personalization and Privacy Workshop.

Carolyn Brodie is a Research Staff Member at IBM's T.J. Watson Research Center. Dr. Brodie's current research focuses on the design and development of usable privacy and security functionality for organizations. She received her Ph.D. from the University of Illinois at Urbana-Champaign in Computer Science in 19

Table of Contents