Open Collections

UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Intentional access management : making access control usable for end-users Cao, Xiang 2006

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
831-ubc_2006-0014.pdf [ 6.23MB ]
Metadata
JSON: 831-1.0065423.json
JSON-LD: 831-1.0065423-ld.json
RDF/XML (Pretty): 831-1.0065423-rdf.xml
RDF/JSON: 831-1.0065423-rdf.json
Turtle: 831-1.0065423-turtle.txt
N-Triples: 831-1.0065423-rdf-ntriples.txt
Original Record: 831-1.0065423-source.json
Full Text
831-1.0065423-fulltext.txt
Citation
831-1.0065423.ris

Full Text

INTENTIONAL ACCESS MANAGEMENT: MAKING ACCESS CONTROL USABLE FOR END-USERS by XIANG CAO B.Eng., Southeast University, P.R. China, 1996 M.Eng., Nanyang Technological University, Singapore, 2003 A THESIS SUBMITTED IN PARTIAL FULFILMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF APPLIED SCIENCE in THE FACULTY OF GRADUATE STUDIES (Electrical and Computer Engineering) THE UNIVERSITY OF BRITISH COLUMBIA February 2006 © Xiang Cao, 2006 2 Abstract In today's network-connected, highly dynamic and distributed computing environments, end-users are motivated to share information and collaborate. It is often the responsibility of end-users, however, to control access to their information. The usability of access control mechanisms in modern distributed systems has been widely criticized but little studied. In this thesis, I carefully examine one widely deployed access control mechanism embedded in the WebDAV (Web-based Distributed Authoring and Versioning) standard, from the point-of-view of an end-user trying to decide how to grant or deny access to some resource to a third party. My analysis points to problems with the conceptual usability of the system. Significant effort is required on the part of the user to determine how to implement the desired access rules. The user, however, has low expertise and interest in this task, given that such access management actions are almost always secondary to the collaborative task at hand. This gap between interest and complexity does, however, indicate a possible solution to this problem: to recast the access control puzzle as a decision-support problem in which user intentions (i.e., the descriptions of desired system outputs) are interpreted by an access mediator that either automatically or semi-automatically decides how to achieve the designated goals. I call such systems intentional access management (IAM) systems, and describe them in both general and specific terms. I then propose a set of design principles, as well as three levels of I A M model (wizard, full, and multi-backend). By using the IAMs, end-users interact with the access control system in a ii natural and consistent way (e.g., by simply specifying their intentions and getting feedback in terms of system effects) without needing to know the internal security mechanism used. Such simplification makes access control more usable. To demonstrate the feasibility and usability of the proposed I A M models, I develop an intentional access management system for WebDAV. End-users can manage access to their WebDAV resources by specifying intentions to this system. The results of a user study conducted on the system show its superior usability compared to traditional access management tools like the access control list editor. i i i Table Of Contents Abstract ii List of Tables vi List of Figures vii Acknowledgements ix Chapter 1 Introduction 1 1.1 Background and Scope 1 1.1.1 Why Make Security Usable? 1 1.1.2 Usability and Task Complexity 4 1.1.3 Thesis Scope 8 1.1.4 Why Choose WebDAV? 11 1.2 Objective 13 1.3 Summary of Contributions 14 1.4 Organization of the Thesis 15 Chapter 2 Related Work 17 2.1 Usable Access Control 17 2.2 Human-Computer Interaction and Security (HCISEC) 27 2.3 Summary 36 Chapter 3 Intentional Analysis of WebDAV Access Control Mechanism 37 3.1 WebDAV Access Control 38 3.2 Intentional Analysis 40 3.2.1 A C L s in Collaborative Environment 45 3.2.2 Algorithmic Analysis 48 3.2.3 Side Effects 54 3.2.4 Conflicts 55 3.2.5 Modeling Decisions 56 3.3 Discussions 57 3.3.1 Other Intentions 57 3.3.2 More Complex Cases 58 3.3.3 Beyond the Algorithmic Analysis 60 3.4 Windows NTFS Access Control 65 3.5 Summary 68 Chapter 4 Intentional Access Management (IAM) 71 iv 4.1 Design Principles 71 4.2 The I A M Wizard 75 4.3 Full I A M 77 4.4 Multi-Backend I A M 79 4.5 Summary 81 Chapter 5 Implementation: IAM for WebDAV 82 5.1 Related WebDAV Applications 82 5.2 System Design 85 5.3 Interface Design 91 5.3.1 Security Context Displayed When Any Resource Selected 92 5.3.2 Needed Information Shown to the User When His Setting Intention 93 5.3.3 User Notified Only When Necessary 93 5.3.4 Side Effects Shown to the User 94 5.3.5 User Cannot Lock Him- or Herself Out of Own Folder and File 94 5.4 Discussion 96 5.5 Summary 97 Chapter 6 User Study 98 6.1 Study Design 99 6.1.1 Participants 99 6.1.2 Task Descriptions 100 6.1.3 Procedure 103 6.1.4 Rules for Determining Task Success or Failure 104 6.2 Results 104 6.2.1 Speed 104 6.2.2 Accuracy 106 6.2.3 User Confidence and Satisfaction 108 6.3 Discussion 109 6.4 Summary 112 Chapter 7 Conclusion 113 7.1 Summary of Research 113 7.2 Further Directions 115 Bibliography 119 Appendices 127 Appendix 1 U B C Research Ethics Board's Certificate of Approval 127 Appendix 2 Introduction to WebDAV Access Control for User Study 129 Appendix 3 User Study Questionnaire 131 Appendix 4 Description of Tasks Using the A C L Editor for User Study 132 Appendix 5 Description of Tasks Using the I A M Wizard for User Study 136 Appendix 6 User Study Interview Questions 139 v List of Tables Table 3.1: Comparison of an A C E and an intention 42 Table 3.2: Summary of the conditions determining the answer to query Q l 51 Table 6.1: Description of participants' backgrounds 99 Table 6.2: Percent of accurate completions for the four tasks by using the A C L Editor and the I A M wizard 107 Table 6.3: Average confidence ratings for the four tasks by using the A C L Editor and the I A M wizard 108 Table 7.1: Comparison of the two security management models 116 vi List of Figures Figure 1.1: Access Management and Access Control 10 Figure 3.1: A possible decision process for determining how to implement G l : principal X must have privilege Y on object Z 48 Figure 3.2: A possible decision process for determining how to implement intention G2: principal X must not have privilege Y on object Z 52 Figure 3.3: Example of a user's modeling decisions for Gl 57 Figure 3.4: A n example of N G O M S L model for a system supporting direct manipulation on A C L + feedback 62 Figure 3.5: A screenshot of the File Permissions interface in Windows 2000 66 Figure 4.1: Two access control system models and the corresponding user's mental models 73 Figure 4.2: Full intentional access management (IAM) model 77 Figure 4.3: Multi-backend I A M model 79 Figure 5.1: A screenshot of the File Permissions interface in GroupDrive Client 83 Figure 5.2: A screenshot of the View A C L interface in D A V Explorer 86 Figure 5.3: A screenshot of the Add/Modify A C L interface in D A V Explorer 86 Figure 5.4: The program flow for fulfilling the user's intention 87 Figure 5.5: A screenshot of DialogA obtaining the intention from the user and showing the current access control state 88 Figure 5.6: A screenshot of DialogB showing the conflicts and modeling decisions. 89 Figure 5.7: Another screenshot of DialogB showing the alternatives when the user has no privileges to modify the A C L 90 Figure 5.8: A screenshot of DialogC showing the task result 91 Figure 5.9: A screenshot of the interface showing the security context 92 vii Figure 5.10: A screenshot of the interface showing side effects 94 Figure 5.11: A screenshot of the interface showing a warning when the action will cause the user's own privileges to be changed 95 Figure 6.1: A tree of supported privileges in the Slide server 100 Figure 6.2: Average time to complete Taskl, Task2, Task3, and Task4 105 Figure 6.3: A screenshot of the interface showing the side-effects that caused by multiple actions 111 viii Acknowledgements First of all, I would like to express my sincere gratitude to my supervisor, Dr. Lee Iverson, for his persistent encouragement and invaluable academic guidance throughout the research work. His insightful comments have been an inspiration for my work. Without his patience and help, this thesis would not have been possible. I would like to express my appreciation to all my friends, especially the research students in the U C L research lab, who have given me a lot of help and created a flexible, productive and pleasant environment for this work. Last but not the least, my sincere thanks go to my wife, my parents and my sister. They provide me with endless love and unreserved support, which I would value forever. ix Chapter 1 Introduction Technological advances in computers and networks, especially the proliferation of the Internet, have made it easier for novice or average users to share their information and collaborate with others. However, with this unprecedented ease of sharing information, it becomes increasingly challenging for users to protect their shared information against unauthorized use. In this thesis, I focus on improving the usability of security systems, in particular of access control systems, for end-users. In this chapter, I briefly review preliminary knowledge of usable security, then describe the research scope and objective of this thesis, then summarize its contributions and organization. 1.1 Background and Scope 1.1.1 Why Make Security Usable? In the modern multi-user computer environment, Internet-capable network servers, along with Peer-to-Peer (P2P) [79] and Grid [28] technologies, provide connectivity that allows 1 a large portion of the user population to share and access information at the desktop from sources around the world, facilitating collaboration. For example, users can save, retrieve, share, and co-author documents over the Internet via WebDAV-based servers [31]. They can also use P2P applications like Kazaa [44] to share files from their own computers. Furthermore, they can take advantage of the emerging pervasive or ubiquitous computing infrastructure [68], which enables them to be connected via portable devices and wireless networks, when they share information with others, so that information sharing is no longer restricted at offices and homes. However, these new opportunities for sharing information have associated costs. Without sufficient security protection, the ease of accessing information proportionally increases the risk of computer security breaches. For example, we have learned many stories from the media about security breaches and their serious consequences, such as disclosure of business secrets or credit card fraud. Even though modern PCs are powerful enough to support use of strong cryptographic techniques in data protection, security remains a major concern for both organizations and individuals who want to control access to their information [22]. To address this concern, numerous sophisticated security mechanisms have been developed. Most existing attempts to improve computer security are based on identifying specific security weaknesses and designing new mechanisms or functions to eliminate them. However, technical correctness and effectiveness alone do not guarantee that the systems are secure in practice [17] [24]. In most (if not all) systems, security depends on the behaviour of the users. If users do not use the system properly, the security 2 mechanism may not accomplish the intended objectives. In addition, i f the security measures unduly inconvenience users, it wi l l impair users' acceptance of security measures as well as their willingness to follow required procedures, which is necessary for the measures to be effective [72]. As early as 1975, Saltzer and Schroeder [62] identified "psychological acceptability" as one of the eight basic design principles of information protection. In recent years, more and more research has demonstrated that the correct and effective use of security measures is just as important as their technical correctness and effectiveness [1] [3] [85]. It is widely recognized that, in any reasonably well-implemented information system, the barriers raised by security mechanisms often confuse or frustrate users to the extent that users become the "weakest l ink" in the system. For example, in [70], Bruce Schneier observed that "security is only as good as its weakest link, and people are the weakest link in the chain," and that "security measures that aren't understood by and agreed to by everyone don't work." Matt Bishop [6] claimed that configuration errors made by users are the probable cause of over 90% of all computer security failures. The situation is worse when the security mechanisms are used by casual and non-technical end-users, instead of professional security administrators. Compared with administrators, end-users usually have limited technical capacity and less security knowledge, and so find it more challenging to properly use and/or maintain the security mechanism. For instance, Good and Krekelberg [32] have shown that the Kazaa peer-to-peer file-sharing service's interface misled many users into unintentionally sharing personal and private files. In a study of P G P 5.0 users, Whitten and Tygar [85] demonstrated that the majority of their test subjects were unable to use P G P to properly 3 encrypt and decrypt emails. In addition, security tasks may not be everyday tasks for end-users [53]. They may need to be done every few weeks or months. For example, from time to time end-users may need to set permissions on their own files to restrict access to, or grant access for, associates. In this case, if the operations of setting file permissions are arcane, end-users w i l l have difficulty in remembering them for the next time [53]. These studies suggest that there is a critical need to make security usable and manageable for end-users, and the Computing Research Association ( C R A ) Conference on Grand Research Challenges in Information Security and Assurance has identified the ability to "give end-users security controls they can understand and privacy they can control for the dynamic, pervasive computing environments of the future" as a major research challenge [13]. Finally, making security usable is actually an enabling task. Unless end-users can successfully and easily use security mechanisms to protect their information from unauthorized access, the cautious ones may refuse to share information and participate in collaborations [74]. 1.1.2 Usability and Task Complexity Before touching on the question of "how to make security usable," it is useful to arrive at a definition of "usability." Although many people use an informal and personal definition of "usability" — software is usable if they can use it — a variety of more specific definitions of usability are available [12] [21] [80] [85]. Here I use the formal definition of usability promoted by the U S Department of Health and Human Services [80], which is based on [55]: 4 "Usability is the measure of the quality of a user's experience when interacting with a product or system — whether a web site, a software application, mobile technology, or any user-operated device. Usability is a combination of factors that affect the user's experience with the product or system, including: Ease of learning How fast can a user who has never seen the user interface before learn it sufficiently well to accomplish basic tasks? Efficiency of use Once an experienced user has learned to use the system, how fast can he or she accomplish tasks? Memorability If a user has used the system before, can he or she remember enough to use it effectively the next time or does the user have to start over again learning everything? Error frequency and severity How often do users make errors while using the system, how serious are these errors, and how do users recover from these errors? Subjective satisfaction How much does the user like using the system?" There are a number of different approaches to analyzing the usability of a system or an interface. Most of them are from the field known as Human-Computer Interaction (HCI). Normally, usability testing takes place in the context of a system already designed or in the process of being designed. It involves systematic testing of versions of the system with actual users and gathering feedback in the form of measurable quantities and/or interviews and questionnaires [56]. In an extreme case, the principles of participatory design actively involve the user in defining the system goals, determining the overall structure of the system, and designing the specific user interface(s) [71]. One approach to analyzing the usability of a security system would be to use these techniques to build a "usable" interface that allows users to manipulate the fundamental model of the security system using standard principles of visibility, direct manipulation, etc. I suggest, however, that this approach would be inappropriate without considering the relationship 5 between the user's interest in the problems the security systems are being used to solve and the tasks in which their use might be assumed. To end-users, security is usually a secondary goal [85]. People just want security in place to protect them while they are achieving their primary goal (e.g., browsing web pages, co-authoring papers, etc.). Sometimes security is a "necessary ev i l " (i.e., something a user is required to do but is not interested in doing). For example, Scott Berkun, a highly experienced program manager leading the U I design of Internet Explorer 1.0 thru 5.0, explained in his blog why he switched from IE to Firefox: "(Firefox's) Security isn't annoying. The press makes security into such a huge deal, but I'll be honest. I don't want to think about security at all. I'll do what I need to, but mostly I want the system to take care of it and stay out my face." [4] Berkun's comments have two implications: (1) even the most sophisticated users like Berkun focus on their primary goals (e.g., browsing web pages), and have little interest in interacting with the system for managing security; (2) people don't necessarily resist interacting with the system for security, but want their involvement to be minimal and wi l l allow a system to "do what I mean." Consider another example: In an information management environment, an end-user's primary goals are to find, create and share information and to collaborate in service to some even more primary task. In such settings, the users care most deeply about their primary task, less deeply about the sharing of information and collaborative work, even less about controlling the "sharing environment", and probably no at all about how that control is implemented in an access control system. However, many (if not all) existing access control systems require users to understand the embedded access control model 6 and mechanism. Users must determine by themselves how to implement their security goals through the user interface (UI), which usually provides the functionality to directly manipulate the internal access control mechanism. In these examples, the burden is on the user to learn how such a system works. I strongly support the view that the burden should increasingly be on the system designers to analyze and capture the user's expectations and build the expectations into the system design [56]. Given end-users' low interest in security, security systems that place less of a burden on them for security management should be inherently more usable. The burden or workload of users in this regard usually comes from the specific subtasks users need to perform to achieve their security goals. Moreover, a better match to user's expectations should lead to a reduction in conceptual complexity and thus in the confusion and misinterpretation that increase the frequency of human errors. Therefore, taking into account the five usability criteria listed above, we can conclude that the simpler the security task users need to execute, the lower workload users have for security, and the more usable the security system should be. This conclusion points to providing systematic support to reduce the complexity of security tasks. Ideally, based on the models of human information processing [56] [58], such systems should acquire a task statement (i.e., security goal) from the user, perform reasoning on it, and execute the task automatically on behalf of the user, interacting with the user only when necessary. However, different users may perform their tasks in different ways for the same goal when using the same system; some may do so correctly, while others may not. In this thesis, I use the term "conceptual complexity" to designate an accurate and consistent 7 representation of the task complexity held by the designer or an expert user. This designation represents the inherent complexity of the task. Correspondingly, the workload on users caused by this conceptual complexity to fulfill the task wi l l be called the "conceptual load." It should be noted that I mean these two terms fairly loosely. M y goal is to uncover the complexity and the load qualitatively, instead of measuring them quantitatively. 1.1.3 Thesis Scope The primary focus of this thesis is security for information sharing in modern cyberspace, where access control remains a major challenge. Therefore, I limit the scope of my discussion to making access control usable for end-users, although some of the results may also apply to other security usability problems. In particular, to support information sharing, I chose shared file-systems as the underlying collaborative infrastructure. In this context, there is a need for fine-grained, user-centered, dynamic control of sharing to match trust and ad-hoc collaboration. The solution I am pursuing is the end-user management of resource sharing with minimal changes to backend infrastructure. Making such management usable enough to be effective for those non-expert end-users then becomes my main task. A s a cornerstone of secure information systems, access control provides the mechanisms for protecting users' information resources from unauthorized access. Traditional access control models include mandatory access control ( M A C ) , discretionary access control ( D A C ) , and role-based access control ( R B A C ) [64]. To implement and enforce these access control models, access control lists (ACLs) , capability lists, or policy-based 8 mechanisms are often adopted. Since my research interest is information sharing that can be controlled by end-users, in this thesis I am looking at discretionary access control with a potential variety of enforcement mechanisms. Over the past several decades there has been much progress in access control, but at its core the academic perspective has largely remained unchanged, centered around the access matrix model [48] [49]. In an access matrix, there is a row for each user of the system (i.e., Subject), and a column for every resource (i.e., Object) that should be protected. The cells of the matrix describe what kinds of operations are permitted (i.e., Rights). The access matrix model lies at the heart of most access control systems. The core idea is that access is driven by rights granted to a subject to access an object. It is important to clarify the terminology used in this thesis. "Access control," which appears frequently in the literature, refers to the enforcement of specified authorization rules to control access to information systems. It is implemented by some access control mechanisms. A n access control mechanism such as A C L can be seen as providing a language by which users can express their intended access control rules to the system. The system employing this access control mechanism then evaluates the rules set by users and enforces them accordingly. However, in this thesis, I use a slightly different term (but with much different meaning), "access management" to refer to the process of formulating the access control rules (rule sets, group memberships, attributes, etc.) for an access control system to achieve a desired set of access privileges for a user or users, as shown in Figure 1.1. This access management is performed by a user interacting with an access control system. Current 9 access control systems often try to simplify access management by providing an interface to the system in front of the internal access control mechanisms. In a typical access control system, users interact with the system through a graphic user interface (GUI), which allows them to manipulate the access control mechanism directly or indirectly. In such systems, management of access involves creating and maintaining access control rules according to the access control mechanism to effectively protect resources. Most of the management burden, however, such as formulating the rules based on his or her security goals is carried by the end-user. Note that it is the user who configures and manages the access control rules; i f this type of management is difficult, it wi l l most likely be done poorly. Access Management \ Access Control J Access / i Goals A—AC Rules-U> "Intentions" / ; | Access Control Privileges / 7 System Enforcement Figure 1.1: Access Management and Access Control In the above I have made a clear distinction between access control and access management. In this thesis, I focus on access management, the process of evaluating and formulating access control rules with necessary feedback to users, which I believe is a key to making access control usable. I make two simplifying assumptions in this research. First, I assume that the access control mechanism is supported by a good and usable authentication scheme and this 10 thesis w i l l not discuss authentication. Second, I assume that the security system is in a multi-user environment and that access to a resource is managed by a combination of a central administrator and the end-users who have the appropriate rights to perform such management. Although portions of my analysis can be applied to systems that are entirely centrally administered, I focus on end-user control, since such systems are becoming more prevalent and necessary with drastic technological advances in computers and networks [26]. 1.1.4 Why Choose WebDAV? To demonstrate the usability problems in current access control systems and the feasibility of my proposed solution, I have chosen an existing access control mechanism, the W e b D A V access control mechanism [11], as the starting point for usability improvement. Today, W e b D A V [31] is the most popular network file-system protocol for use across the wide-area Internet and also the third most widely used email-retrieval protocol (behind POP and I M A P ) [83]. The W e b D A V system is designed to create an infrastructure for distributed file systems built on top of the now-ubiquitous foundation of the World-Wide-Web, the H T T P protocol. W e b D A V has already achieved wide deployment on many platforms, in software from many vendors. It can be found in Web servers such as Apache and Microsoft Internet Information Server (IIS), and Web browsers such as Microsoft Internet Explorer (IE). Desktop applications including Microsoft Office 2000 and Adobe software also adopt W e b D A V . In addition, W e b D A V client functionality is being implemented in modern operating systems at the file system level, for example in Windows X P and Mac OS X . 11 The W e b D A V standard includes a comprehensive access control list ( A C L ) system, designed to allow repository managers and end-users to control the granting and denying of a wide range of privileges to other users. A key point in the design is that the building blocks of the A C L system, including the A C L s , users, groups and inheritance properties, are subject to access control just like the target resources. In essence, the delegation of access control is implemented by extending modification rights to the A C L resources. With this system, it becomes possible to think of an entirely user-controlled, distributed information sharing environment with enormous flexibility and potential, which is my research interest. Typical current deployment patterns have a shared file server with W e b D A V client access, thus allowing unlimited, flexible sharing of information in the workplace and reducing reliance on email attachments and centrally-administered document management systems for collaboration [25]. One could imagine that every networked system has both the W e b D A V client and server support and complete integration of H T T P + W e b D A V with local file system and desktop support; actually, this seems to be a goal that both Microsoft and Apple are pursuing. Since targeting such a widely deployed Internet-scale specification makes potential results more applicable to real-world information-sharing settings, and since W e b D A V access control semantics are modeled after Windows N T F S access control semantics (with some simplification), I have chosen W e b D A V access control as the basis for my research on usable security. The results should also have implications for improving the usability of similar access control systems, such as Windows N T F S access control. 12 1.2 Objective The objective of this research is to improve the usability of access control for end-users. Through a thorough analysis of the conceptual complexity embedded in the W e b D A V access management tasks, a gap between user interest and task complexity is observed. Significant effort is required on the part of the user to determine how to implement the desired access rules. The user, however, has low expertise and interest in this task, given that such access management actions are almost always secondary to the collaborative task at hand. In addition, the significant effort indicates another gap between the user's intention and implementation. Even for simple needs/intentions (e.g., a professor needs to be able to edit his student's thesis draft), the user must be able to assess the state of system (i.e., is the intention already fulfilled?) and then determine how to modify the configuration to fulfill the intention. In this thesis, I propose reducing the conceptual complexity of access management tasks by isolating end-users from access control mechanisms. This is done by clearly separating access management from access control. The access management system wi l l allow users to express intentions (i.e., the descriptions of desired system outputs) without considering the details of access control implementation. The system wi l l then interpret users' intentions, formulate access rules to achieve these intentions automatically or semi-automatically, and provide feedback. This solution, called "intentional access management" ( I A M - see Chapter 4), leads to the hypothesis of my thesis: Use of IAM reduces the conceptual complexity of access management tasks, thus 13 making the access control system easier to use for end-users, and enabling quick and accurate accomplishment of security tasks. To demonstrate the applicability and effectiveness of this solution, I developed an intentional access management system for W e b D A V and conducted a laboratory user study on it. Please note that throughout this thesis, my goal is not to make security invisible, but to make it a natural result of normal computer operations by hiding the security mechanism. 1.3 Summary of Contributions The major contribution of this thesis is a new conceptual design of usable access control that reduces the conceptual workload for end users in their tasks of managing access control. In particular, I make the following contributions: • I reveal the high conceptual complexity of formulating access control rules given an access goal or intention. I do this through a thorough flow-chart analysis (called intentional analysis) of the W e b D A V access control mechanism. • I develop new design principles and system models (called intentional access management ( IAM) systems) that isolate users from security mechanisms by automatically or semi-automatically resolving user intentions into implementation. These user-centered designs aim at reducing the conceptual burden of end-users, thus improving the usability of access control. 14 • I design and implement a usable access management system for W e b D A V that eases access management on a W e b D A V repository for end-users and demonstrates the applicability of I A M models to real-world situations. • I conduct a user study that provides further insight into user behaviour in setting access control rules and validates the usability of the proposed I A M models. 1.4 Organization of the Thesis This thesis consists of seven chapters. The rest of the thesis is organized as follows: • Chapter 2 reviews some existing work on the problem of usable security, in particular usable access control, mainly from the information security and human-computer interaction perspectives. • Chapter 3 analyzes W e b D A V access control as an example of the conceptual complexity embedded in access management tasks. The analysis concludes that the conceptual load involved in setting access control rules is too heavy for end-users. Issues discussed in the analysis include side effects, conflicts and modeling decisions. • Chapter 4 introduces my system design, which aims at alleviating the conceptual complexity of access management tasks and improving the usability of access control. I propose a set of design principles and translate them into three levels of models that I call Intentional Access Management ( IAM) systems. 15 Chapter 5 describes the design and implementation of an access management system for W e b D A V that embodies the models proposed in Chapter 4. Chapter 6 presents a user study on managing access to a W e b D A V repository, demonstrating the improvement in usability of the new design for end-users. Chapter 7 summarizes the thesis and suggests further work. A n initial design of a fully functioned access management system for end-user controlled information sharing is presented. 16 Chapter 2 Related Work The resurgence of interest in security and usability at the end of the 1990s has led to a broad understanding of the significant relationship between security and usability [65] [70] [77] [85] [90]. However, to date, little work has been carried out to investigate the usability of access control systems, especially for non-expert end-users. This chapter first examines prior work on usable access control, and then extends the review to a superset of the first - work in the emergent field of human-computer interaction and security, also known as H C I S E C . 2.1 Usable Access Control Although access control has been intensively studied by numerous researchers and a variety of access control models, mechanisms, and systems have been investigated, most of the studies have been conducted in a purely technical manner and have overlooked usability issues associated with access control. I discuss some exceptions here. 17 One of the earliest attempts to synthesize usability and access control is the work by Zurko and Simon [93]. They introduced the term user-centered security to refer to security models, mechanisms, systems, and software that have usability as a primary motivation or goal. A user-centered authorization engine M A P was developed. The M A P prototype used access control list ( A C L ) as its underlying mechanism but augmented it with sensitivity labels, object groups, and access rules. After developing the prototype, they reported the advantages and pitfalls of the approach, which they later considered in the design of M A P ' s successor Adage [94], a modular authorization service for distributed applications. A primary emphasis of Adage was employing usability design techniques to design an authorization language and the corresponding administrative graphic user interface (GUI) for policy definition and management. Constructs including groups, attributes, constraints and rules were used in the user interface design. A novel feature of Adage is including a "debugging" mode in which security administrators can make changes to policies and determine the effect of changes before actually deploying them into the system to prevent affecting the security of a running system. Both contextual interview and formal usability testing were chosen for usability evaluation. The two outputs from the formal usability testing were notes on the subjects' actions and statements, and the numeric results of the exit questionnaire. Although usability was a major design goal in M A P and Adage, they were intended for use by professional system administrators who already possess a high level of expertise, and as such they did not address the problems posed in making security effectively usable for a more general population of end-users. For example, the authorization language they proposed was domain-specific and designed for administrators. However, this work is 18 helpful as an attempt to outline general issues of concern in the design of a usable access control system. The direction they suggested of providing access management support to users at a high level of abstraction without abandoning the underlying mechanism (i.e., the A C L ) is just the one I am pursuing. The work most directly related to the topic of this thesis is the study performed by a research group at Carnegie Mel lon University on the Windows N T F S file permissions model [53] [61]. They studied an existing interface for setting N T F S permissions, the Windows X P File Permissions interface (referred to as X P F P ) , and identified three aspects of the N T F S file permissions model that seemed potentially confusing. These aspects include group conflicts, permission mappings and override permissions. Grounded in a theory of human error, they proposed a design principle, called "external subgoal support", to reduce goal errors in setting file permissions. They then implemented this in a new interface, called Salmon, for setting N T F S file permissions. Salmon and X P F P were evaluated in a laboratory user study and Salmon was found to be more dependable. Salmon can be seen as an interface that provides the user direct manipulation on the internal access control mechanism (i.e., the A C L ) with useful feedback (e.g., displaying effective permissions). In [61] Reeder found that while error rates were somewhat lower with this design, they were far from zero, and the design also introduced some new causes of error. They attributed the errors mainly to those three particularly troublesome aspects of the N T F S security model, and concluded that simplifying the model, rather than continuing to redesign the interface, could be the best route to reducing error rate in 19 setting file permissions. From cognitive science perspective, Salmon was designed to provide an accurate, clear and salient external representation of the information needed to achieve the user's primary goal. However, the user still has to formulate subgoals from his or her primary goal according to the information provided by Salmon and determine by him- or herself how to implement these subgoals. Considering the low interest and expertise of end-users, it is usually not an easy task for them, even with useful feedback provided by the interface. I wi l l discuss Salmon in more detail and compare it with my work in the following chapters. A body of research on security and usability has also been conducted at Palo Al to Research Center ( P A R C ) [77] [34] [27] [2] [3]. Considering the changes brought by ubiquitous computing, Smetters and Grinter [77] identified the need to design usable and useful systems that provide security to end-users in terms of the applications that they use and the tasks they want to achieve. They looked at the problem of usable security from a software engineering perspective, and proposed alternate engineering approaches to building and integrating usable security technologies into applications. Three engineering approaches they proposed include coupling security actions with the user's action in application terms (an approach called implicit security that has also been mentioned in other recent literature [91]), using software engineering techniques such as refactoring to identify which security components should be handled by the operating system and domain infrastructure and which components should be left to applications, and taking advantage of security-related software idioms and patterns to create reusable security "building blocks." They also argued for reformulating traditional usability testing approaches for the purpose of testing usability of security as a secondary task from the 20 end-user perspective, and presented usability methods for evaluating the proposed prototypes. Later in [34], they presented three interface challenges for embedding security into applications, which include starting with a user-centered threat model, inferring security action from user intent, and reflecting security state back to the user. To explore the approach of implicit security on access control, this group developed Casca, an application built on their Speakeasy framework and designed to support ad hoc collaboration [27]. Casca implemented sharing as a primary interface construct to make sharing policies more visible to users. Users who wish to share things with each other set up a shared "space" (called converspace). They invite each other to join the space and let members add objects to the space (such as files or services); these objects then become visible and accessible to all of a space's members. Thus the extension of access rights is incidental to the act of sharing. In this way, the access information is visible to the user, but the details of how it is implemented are not. Unfortunately, this type of implicit security does not support fine-grained access control (such as extending read access, but restricting modification rights). However, this idea of making security states visible but hiding the implementation details is helpful and applied in my work. Implicit security was also applied in their designs of usable Internet [2] and usable P K I [3]. In [2] Balfanz proposed an access control system for the World Wide Web that was easy to use both for content providers and content consumers. In this system, to control access to the content, the content provider needs to pick from his address book a list of consumers whom he wants to grant access to. Then the system adds pointers to every selected email recipient's address book entry to the address control list, and sends out an 21 email message to every selected one which includes a U R L that recipients can click on to access the content. On the consumer's end, recipients of an email message can simply click on a single U R L provided, and wi l l have access to the content. For the first time they visit a U R L , they wi l l be taken through a quick online setup process, which is similar to the process when people use S S H to log onto a server. In [30], Gates and Slonim presented the concept of users owning their personal information and introduced some of the issues involved in users being able to control access to this information. They discussed the security requirements for this new paradigm, including authentication, access control and audit (as well as user interface and trust). For example, they argued that the user interface must be designed in a manner that "not only allows users with various levels of skill to configure the access control system, but that also allows the user to understand the consequences of his configuration decisions, alerting the user to any conflicts in configuration." However, in this paper they did not provide any concrete technical solutions to address these issues. In this thesis, I w i l l present my work to address these issues. Whereas the above works represent the extent of the published literature on usable access control that directly informs this thesis, there is also a body of research that gives more general direction to systems for end-user security and privacy management, or that appears to have significant shortcomings. A group of researchers at the University of California, Irvine is actively involved in the research on usable security [24] [23] [22] [17] [18] [16]. They first investigated everyday security practices and mental models of security, by examining how people manage 22 security as a practical, day-to-day concern, and exploring the context in which security decisions are made [22] [23]. Their study yielded some interesting conclusions. For example, they suggested that protection and sharing of information are two aspects of the same task and always carried out together. They also argued for high visibility of security to the user, as opposed to being "transparent" (this is an explicit argument against "implicit" security). Based on this empirical work, they considered the problems of security to a large degree as an interactional problem, and proposed a systems approach to usable security based on event monitoring and visualization [24]. Two design principles - visualizing system state and integrating configuration and action - have been at the center of their approach [17]. B y applying these two principles, they have built an application called Impromptu for peer-to-peer file sharing with the Slide W e b D A V repository in face-to-face collaboration settings [17] [18]. Impromptu provides a visual client interface which presents a circular "pie" and is separated into multiple concentric regions. Files, represented by labeled dots, are placed in and around the circular region. The basic metaphor is that the closer the files are to the center, the "more shared" they are. Thus file access is managed by moving the files between the levels. In [16], they proposed to use the social navigation paradigm as a way of organizing visual displays of security action. Holding a similar principle of making security visible, Yur ick [92] presented some visualization tools targeted for security administrators. Long et al. [51] evaluated a preliminary, paper-based interface for limiting applications' (as opposed to user's) access to system resources. This access control was implemented by partitioning all applications and data based on general task types, or "roles." B y using cognitive walkthrough and think-aloud user studies of paper prototypes, they concluded 23 that their interface was simple to understand and use. The abstraction of security and privacy in terms of "space" (as in implicit security) was also explored by Sampemane et al. [63] They defined "active spaces" as physical spaces augmented with heterogeneous computing and communication devices along with supporting software infrastructure. A n active space can be configured for different types of applications at different times. They introduced the notion of collaborative access control modes and presented an access control architecture for active spaces, which integrates physical and virtual access control mechanisms and has the ability to dynamically reconfigure access control policies to create different policies for different virtual spaces. In collaborative systems domain, Dewan and Shen [19] [20] [75] have explored the use of access control and meta-access control models as a basis for describing and controlling degrees of information access and management. The resulting system, called Suite, was designed to support flexible control of all significant shared operations, high-level specification of access control policies, and automatic and efficient implementation of access control in a multi-user interface. However, they only addressed these issues in technical terms and ignored human and social constraints. This seems a significant failure of the work, considering that the structure and behaviour of these internal components can have a significant effect on forms of interactivity and collaboration they can support [33]. W e b D A V A , a system that allows end-users to selectively give fine-grained access to their resources without involving their system administrators, was proposed by Levine 24 and colleagues [50]. They accomplished this design by using authorization credentials that define the users' privileges. However, thus seems to introduce problems since it may be difficult for end-users to manage the credentials, and they did not perform any usability testing for their system. The above papers explored a set of techniques and systems that can positively facilitate usable access control. On the other hand, Good and Krekelberg [32] used a cognitive walkthrough as well as a laboratory user study to analyze the usability of the Kazaa file sharing user interface. They discovered that this interface failed all four of the usability guidelines that they developed and misled many end-users into unexpectedly sharing files. In any case, it is clear from their work that users simply do not choose peer-to-peer systems such as Kazaa for active collaboration. Another alternative approach was used by Kapadia et al. in investigating the effect of informing users of the reasons why an access request was denied while controlling the disclosure of the system's security policies [43]. Their framework Know uses Ordered Binary Decision Diagrams and cost functions to provide feedback to users about access control decisions. When the system denies a user access to a resource, it generates permissible and relevant feedback to the user on how to gain access. They suggested that such a system is more user-friendly to legitimate users, because they can use the feedback to reason about, and correct, errors. However, they only evaluated this system by a qualitative analysis on some examples, and performed no usability testing to explore the effect of their approach on real users. Above I reviewed a body of research on usable access control, from specific techniques, 25 security metaphors, to general access control system design for aligning security and usability. This thesis focuses on the design of access management to make access control usable for end-users. Those techniques developed for specific application domains and lacking in support for fine-grained access control may not be applicable for this system. However, they do provide the insight, definitions and design indicators for making access control usable for end-users. In essence, the studies of Zurko and Simon [93] and on implicit security [77] [27] suggested providing users high level access management tools, instead of low-level mechanisms, and the Salmon interface [53] as well as the work by [17] [22] demonstrated the importance of visibility (i.e., good feedback) for end-users. These provided direct guidance for my work, while the rest provided general observations and tests that are helpful in improving the design. Compared to some of this work, this thesis approaches the usability problem from a very low level, considering that A C L s are the "assembly language" of security policy [93]. A s for computer programming, the assembly language is hard to use and understand, even with powerful debugging tools providing good feedback. Therefore, researchers are long working to create better, easier to use tools for program development and analysis. One approach is to developing high-level languages (e.g., scripting languages) which can usually be interpreted or compiled into the assembly language automatically so that even non-expert users can program without learning the low-level language. Similarly, security management w i l l become more usable for end-users if we can decouple high-level user intentions from the internal security mechanism so that users needn't deal with such low-level mechanisms directly. A n analogous idea is declarative security [59] in which the security logic is decoupled completely from the business logic and the security 26 requirements are described by the so-called security policy outside the application. For example, the Java 2 Enterprise Edition (J2EE) provides declarative authorization for deployers to define access control policies at deployment time, rather than during application development. However, this design is not intended for use by end-users. Security policies and user intentions are similar in that they are both represented in a higher level of abstraction compared to the A C L . There has been some useful work from security researchers on queries of security policies and on the impact of policy changes. Examples include the work by Lupu and Sloman [52], Spencer et al. [78], and Jaeger et al [38]. However, the security policy systems investigated are not easily understood in terms of user intentions, instead intentions can be understood as the overall effects of the relevant policies. In these policy-based systems users still need to translate their needs to appropriate security policies by themselves. This task may be no easier than it is with A C L s and is potentially much harder because of the added expressiveness of the policy languages. 2.2 Human-Computer Interaction and Security (HCISEC) A s noted in Chapter 1, Saltzer and Schroeder [62] identified the need to consider usability as a primary factor in developing secure systems in their landmark 1975 paper. For the last of eight design principles for building systems that can protect information, 27 the authors wrote: "h) Psychological acceptability: It is essential that the human interface be designed for ease of use, so that users routinely and automatically apply the protection mechanisms correctly. Also, to the extent that the user's mental image of his protection goals matches the mechanisms he must use, mistakes will be minimized. If he must translate his image of his protection needs into a radically different specification language, he will make errors." Despite the early recognition of this problem, it is only toward the end of the 1990s that HCISEC has emerged as a distinct field. Recent years have witnessed several research conferences dedicated to security and usability. The first formal gathering of researchers actively working in this interdisciplinary area took place at the CHI 2003 Workshop on Human-Computer Interaction and Security Systems (http://www.andrewpatrick.ca/CHI2003/HCISEC/). A larger Workshop on Usable Privacy and Security Software (WUPSS) (http://dimacs.rutgers.edu/Workshops/Tools/) was held at the DIMACS Center at Rutgers in July 2004. In July 2005 the first Symposium on Usable Privacy and Security (SOUPS) (http.V/cups.cs.emu.edu/soups/2005/) took place in Pittsburgh, PA. Whitten and Tygar [84] [85] presented an analysis of how software with security-related features differs from other kinds of software as a problem domain for usability engineering, and created a definition for usable security software. Using this definition, the pair argued that inherent properties in security software make such software inherently difficult for user interface design. These properties include the secondary goal property, the hidden failure, the abstraction property, the barn door property, and the weakest link property [85] [87]. Therefore, they suggested that effective security would 28 not be achieved through the user interface design techniques appropriate to other types of consumer software. From that analysis, they derived a set of design principles for building usable security software, which includes removing the user from security-critical decisions whenever possible, software modifications to increase the usability of this security software, and increased user training to make errors and mishaps less likely. Instead of making security invisible, Whitten suggested that it is better to teach users to manage their own security. A case study on the usability of P G P 5.0 was presented, demonstrating how a user interface that appeared good by traditional standards, failed to make public-key based electronic mail security manageable for experienced e-mail users. This work is remarkable for providing both a working definition of usability for security, and an example of how to evaluate the usability of security software. It uncovered how the poor match between users' needs and the technology provided to meet those needs can result in failure. As for interface design, the pair [86] proposed a user interface design technique for security, called safe staging, enabling users to safely postpone learning how to use a particular security technology until they decide they are ready to do so. Garfinkel [29] has provided a detailed analysis and critique of the definitions, principles, and findings put forth by Whitten and Tygar in [85] and elaborated in Whitten's PhD thesis [87]. His critiques were focused on the term "security software", the emphasis on disclosure control, and the case against making security invisible. For example, Garfinkel argued that there are cases that machines consistently make better judgments than humans against a class of attacks. In these cases it may make more sense to make the security policy and decisions visible, but not to allow the policy to be modified. Yee [90] [91] summarized ten design principles for secure interaction design. Three of 29 them are listed below: Visibility: The interface should let the user easily review any active authority relationships that could affect security decisions. Clarity: The effect of any authority-manipulating user action should be clearly apparent to the user before the action takes effect. Expressiveness: The interface should provide enough expressive power to let users easily express security policies that fit their goals. However, I argue that although these principles are desirable in designing security systems, their application may not guarantee the usability of the designed systems. Two problems exist: (1) a system so designed may be perfectly usable for one group of users and opaque and unusable for a different group (e.g., system administrators vs. end-users), and (2) these guidelines do nothing to address the gap in reasoning that could allow a user to determine what changes need to be made to a system's state to achieve a desired goal. In a series of studies, researchers at University College, London have explored some of the interactions between usability and security [1] [8] [65] [66]. They focused on user-visible elements of security systems, such as passwords. Their investigations demonstrated that users are certainly motivated to support the security of the system, but often unable to determine the security implications of their actions. Thus they suggested that the design and implementation of any technology, including security, must fit the characteristics of the end-users, their goals and tasks through which they achieve goals, and physical and social context in which they perform tasks. They used password authentication as a widely used example to argue that so far the security community had failed to comply with this rule. Some other challenges of the usability of security were also mentioned, including users' misconception about cost/benefit as the main barrier in 30 their adaptation and usage of security. They then proposed some approaches for aligning security and usability from the socio-technical perspective [82] [9], which include persuasive methods and an adaptation of a safety model called G E M S (Generic Error Modeling System) to security. Other researchers also made similar analyses on usability of security from various standpoints. Schultz et al. [72] reviewed major types of security controls that currently exist, appraised the usability issues, and developed a taxonomy to organize these issues. A t the end of their paper they advocated systematic usability analyses and development of better usability metrics for information security. Besnard and Arief [5] analyzed the cognitive processes underlying security impairments by legitimate users, and proposed a short usability-centered set of recommendations. A s discussed above, to make security usable, designers can ease the user's burden by making security decisions for them, or offer features that ensure that users can make the right security decisions. Zurko et al. [95] investigated such tradeoffs by a field study in a 500-person organization on the security of each user's Lotus Notes client against unsigned active content. They found that when their workflow is interrupted with a security dialog, many of those otherwise secured users would make a choice that is unsafe. They suggested that the common software practice of warning users of danger but letting them click on something to proceed anyway provides inadequate security, and the user community or security-related interfaces should undergo some radical sea change including education, and better and more pertinent information from the software. A s suggested in [77], security design patterns could help developers less sophisticated in 31 the use of security technology to understand how to incorporate it more effectively into their applications. In his PhD thesis, Garfinkel [29] proposed principles and patterns for aligning security and usability. His patterns are grouped into three specific areas: patterns for user visibility and sanitization, patterns for secure messaging, and patterns for promoting overall secure operation. Earlier work on security design patterns includes the studies by Schumacher [73] and by Blakley et al. [7]. Some similar attempts to design new technologies that solve security problems from a usability perspective were presented in [37] [40]. Holmstrbm [37] described the development of a user-centered security concept for a personal communication device, and proposed the metaphor of "secure electronic business card." In [40], Jendricke and Markotten argued that most users of internet applications do not have the knowledge and/or the motivation to configure or to use the existing security functions correctly. They introduced an extended classification of protection goals, and proposed an "identity manager" that interposes itself between the user's computer, the outside world, and all data stored on the system. This identity manager keeps track of the role that the user is playing and thus the everyday use of security functionality can be reduced to selecting the user's identity. However, their system was not evaluated in user tests. From a human factors point of view, Patrick and Kenney [57] introduced a process for privacy interface design that begins with privacy legislation, works through derived privacy principles, examines the H C I requirements, and ends with specific interface design solutions. They grouped the human factors requirements for effective interface design into four categories including comprehension, consciousness, control, and 32 consent, and proposed a technique called "Privacy Interface Analysis" to show how interface design solutions can be used to meet the requirements when developing a privacy-enhanced application or service. The U M L (Unified Modeling Language) technique was suggested for conducting this analysis. Although their analysis was for privacy interface design, considering that privacy control also implies security control, interface design for security applications may take advantage of a similar process. Above I reviewed the H C I S E C work in terms of general principles and guidelines that are beneficial to my research. Those that are of direct relevance to my design include visualizing security and accommodating user needs, which help end-users make informed decisions for security [85] [1] [65] [90]. I w i l l discuss them further in context of the I A M design in the following chapters. A s indicated above, Whitten and Tygar [85] argued that software with security-related features is somehow different from other kinds of software and effective security wi l l not be achieved through the user interface design techniques appropriate to other types of consumer software. However, there are some concepts and techniques proposed in the traditional H C I literature that may be useful for this research. For example, the terms "Gu l f of Evaluation" and "Gu l f of Execution" introduced by Norman [56] are a good reference in the discussion of security usability. The gulf of execution is the degree to which the interaction possibilities of an artifact, a computer system or likewise correspond to the intentions of the person and what that person perceives is possible to do with the artifact/application/etc. In other words, the gulf of execution is the difference between the intentions of the users and what the system allows them to do or how well 33 the system supports those actions [56]. The gulf of evaluation is the degree to which the system/artifact provides representations that can be directly perceived and interpreted in terms of the expectations and intentions of the user [56]. For security systems, while the gulf of evaluation is extremely important, bridging the gulf of execution is also one promising approach to improving the usability. Note that Norman's terms relate strongly (but not exactly) to Yee's Visibi l i ty, Clarity and Expressiveness [90] [91]. I w i l l rely on all of these concepts and guides in the design of my systems. In addition, direct manipulation is a human-computer interaction style that was defined by Ben Shneiderman [76] and involves continuous representation of objects of interest, and rapid, reversible, incremental actions and feedback. In [56] Norman also suggested the direct manipulation with good feedback for interface design. In the next chapter, I w i l l demonstrate that direct manipulation of the internal security mechanisms (e.g., the A C L ) is not the right goal for a user-centred security U I design, but direct manipulation of the intentions (i.e., at a level of abstraction on the resulting effective privileges) may provide a usable interface for end-users to manage access control. To date, most security management systems force users to understand and manipulate the internal security mechanisms and models used. However, security mechanisms and models that are confusing to the user w i l l be misused [93]. Although some work has been carried out to align usability and security as discussed above (e.g., providing helpful feedback [53]), this burden remains on users. Users have to make reasoning to determine what changes need to be made to a system's state to achieve a desired goal (i.e., the gulf of execution). One of the gating factors is that people are wil l ing to accept long-34 established models, mechanisms and designs for basic functionality provided by operating systems and application programs, rather than to redesign these systems so that they are more consistent with user expectations and can do a better job supporting actual user needs [29]. In the following chapters, I w i l l present my pursuit of the latter. A s suggested in [61], simplifying the security model could be the best way to reduce error rate and make access control more usable for end-users. However, in many situations we need a solution that imposes minimal changes to current backend infrastructure and security model, as in this research. In this context, a mediator that interposes itself between the user and the backend could be a better choice (e.g., as in Adage). The mediator should present in a way that the user's mental image of his protection goals wi l l match the mechanisms (not the internal mechanisms) he must use, which satisfies the principle of psychological acceptability [62] quoted above. In other words, such systems wi l l present a higher level of abstraction which is not incompatible with a user's mental model. Someone may argue that it is better to teach users to use the internal security mechanism by providing direct manipulation on the internal mechanism plus feedback. However, as discussed above, end-users have low interest in implementing security, considering security is (at best) a secondary goal. Also they usually have low to non-existent expertise and managing access control is not their everyday task, which makes learnability and memorability a challenging problem. Taking an example of the calculator, Garfinkel [29] commented on a similar argument that "These arguments seem similar to those of a mathematics teacher arguing that students should learn how to perform long division rather than relying on handheld calculators. Yes, it is intellectually interesting and perhaps even important to learn long division, but most people rely on 35 their calculators, even though most calculators present quotients as truncated decimal representations rather than as rational numbers or repeating decimal fractions.'''' 2.3 Summary In essence, what I am going to do in the next chapters are to demonstrate that: (1) A C L manipulation is an inappropriate level of abstraction for end-users; (2) a task-goal abstraction wi l l solve the problems with A C L manipulation; (3) even a rudimentary system at this level w i l l demonstrate its worth. This agenda was informed by the literature and past work reviewed in this chapter, including [93], [77], [27], [53], [17], [85], [90] and more, as discussed above. However, my approach is different from previous work in that it aims at fine-grained access control and bridges both the gulf of execution and the gulf of evaluation for end-users. 36 Chapter 3 Intentional Analysis of WebDAV Access Control Mechanism The previous chapter reviewed related work on usable security, most of it from the security and human-computer interaction (HCISEC) perspective. In this chapter, I begin to analyze the usability of access control from a novel perspective - the algorithmic complexity of the access management task. Access management is never an easy task, even for a trained administrator. The administrator/end-user who wants to control access to his/her resources initially has a goal or intention in mind, such as who can perform what operation on what resource. However, intention is not implementation. Only by a sequence of processes of checking and analyzing the state of the system and reasoning about the effect of potential changes wi l l he/she reach a decision on how to resolve this intention (e.g., designing the access control lists (ACLs)) . It is this procedure that I wi l l analyze in this chapter. The emphasis is not on the interaction between the user and the system, but on the relationship between the user's goal and the actions needed to take place (i.e., the "gulf of execution"). 37 A s a focus of this analysis I wi l l use W e b D A V access control, as a case study to demonstrate that even for such a simple A C L model there is a large gap between intention and actual implementation of control for the user. Here the "user" can be either an administrator or an end-user with rights to manage access, since our analysis can be applied to both of them. 3.1 WebDAV Access Control I briefly introduced W e b D A V in Chapter 1. Here I provide more detailed information about W e b D A V , in particular its access control mechanism. W e b D A V (Web-based Distributed Authoring and Versioning) is a set of extensions to HTTP/1.1 that allows Web authoring tools, content management systems and many other document-oriented applications to save documents directly to a remote Web server and manage the content on that server [25] [31]. In 2004, the Internet Engineering Task Force (IETF) published the W e b D A V Access Control Protocol [11], which provides A C L s for controlling who has what privileges on a W e b D A V resource. W e b D A V clients may interact with the server and remotely set and retrieve access control lists using the protocol. This access control mechanism for W e b D A V resources was very consciously derived from existing file system practice, with slight adaptations to handle resource properties. The resources are organized in a file-system-like hierarchy. Access is divided into several well-defined privileges (e.g., read, write). Privileges may be containers of other privileges, in which case they are termed "aggregate privileges." Granting or denying the 38 aggregate privilege effectively grants or denies all its contained privileges. Each resource has one A C L attached to it. A n A C L contains a set of "access control elements/entries" (ACEs) , where each A C E specifies a principal and a set of privileges that are either granted or denied to that principal. A n A C E can be inherited from the A C L of another resource (e.g., the parent of the current resource in the resource hierarchy). A principal can be a named user or a computational actor. A principal may also be a group, where a group is a principal representing a collection of other principals, called the members of the group. A resource may have an owner who has special access control capabilities (e.g., the owner frequently has a permanent privilege to change access control settings). These groupings of principals, privileges, and resources by hierarchy complicate the access control list model. Usually W e b D A V access control systems provide a user interface (UI) that allows users to manipulate the A C L s , like the Windows systems using N T F S do. To manage access by manipulating the A C L s , the user must learn how an A C L is evaluated to determine whether or not access wi l l be granted for a particular W e b D A V request. A C E s are maintained in a particular order, and are evaluated until all of the permissions required by the current request have been granted, at which point the A C L evaluation is terminated and access is granted. If, during A C L evaluation, a <deny> A C E (matching the current user requesting the access) is encountered for a privilege that has not yet been granted, the A C L evaluation is terminated and access is denied. Failure to have all required privileges granted results in access being denied [11]. Note that the principal in an A C E matches the current user requesting the access when they are identical or the principal in that A C E is a group and the current user is a member of that group. 39 The evaluation procedure described above leads to the distinction between the stated privileges, the explicit privileges granted or denied to the user in the A C E s , and effective privileges, the actual privileges that a user wi l l have according to the combination of the involved A C E s in an A C L . A n example is provided in the next section. 3.2 Intentional Analysis So, how can we assess or improve the usability of this A C L model? Although a G U I A C L Editor like the one described in [93] can facilitate manipulating and understanding of the A C L s , and the W e b D A V A C L model is relatively simple, I suggest that before even considering user interface issues we should determine whether too much may be asked of the user in terms of sheer involvement with the process. As stated above, I contend that the end-user is primarily interested in the output of the A C L system (e.g., either a success or failure of an access request), and not in the means by which this output is achieved. Since the conceptual complexity of a task shouldn't exceed the user's commitment to that task, it becomes necessary to characterize the complexity and assess how well it matches the user's expectation. There exist some possible techniques for analyzing task complexity [46] [42] [60]. In this thesis, I suggest approaching it from an algorithmic point of view, since it is easy, straightforward and sufficient for this kind of tasks. Developing and analyzing the algorithm wi l l reveal the algorithmic relationship between the goal and configuration changes. It w i l l help understand where the complexity in the system lies, characterize 40 basic "gulf of execution", and reveal representations/visualization of state needed to meet a user's goal. To assess this complexity and eventually try to match it with the user's commitment, I w i l l start my analysis from the goal states and go backwards to try to determine the minimal changes needed to achieve the intention. In this thesis, I w i l l examine two simple goal states that the user is likely to be interested in achieving: Gl: Principal X must have privilege Y on object Z . G2: Principal X must not have privilege Y on object Z . The principal here may be a set of principals. I focus on these two intentions since they represent the basic effects all access control systems should produce through the implementation of access control. Also all the goal statements discussed in the user study for Salmon [53] can be generalized into these two intentions, i f the privileges in user intentions match the privileges used in the system. I describe these goal states as primary user intentions and analyze the steps necessary to determine what A C L changes must be made to the current system state to ensure that the output of the A C L system wi l l produce these results. For obvious reasons, I call this style of analysis "intentional analysis". Note that this is not an analysis of the intentions that users wi l l have, but of the process that has to be taken based on the intentions. From the H C I perspective, this is also an analysis of the "gulf of execution" for users and the system to manipulate the internal security mechanism (i.e., the A C L ) . Some readers (and users) may think that the A C E and the intentions given above are the 41 same because they read them as the same - "Principal X has privilege Y on object Z " or "Principal X does not have privilege Y on object Z . " However, due to the ordering of A C E s and the indirection by group hierarchy, there are clear differences in semantics between them, as shown in Table 3.1. Note especially that A C E s must be read in context of the A C L to interpret them. To clarify the distinction between A C E and intention, I suggest that each A C E should be read as "grant/deny principal X the privilege Y on object Z if he has not yet been granted/denied that privilege." Actually, the confusion between intention and A C E is one of the main sources of error for end-users in manipulating the A C L 1 . Table 3.1: Comparison of an A C E and an intention A C E Intention in an A C L - a statement of enforcement that is only examined if previous statements in the A C L are irrelevant or incomplete regarded as data in the enforcement/control algorithm statement of "goal" or output constraint many different A C L s could result in this goal being fulfilled Let us take some examples of how an intention is different from an A C E . Suppose that the A C L attached to the fi le/oo has seven ordered A C E s : A C E 1 . "Deny user test the read privilege" (read privilege is an aggregate privilege that contains the read-acl privilege); A C E 2 . "Grant user test the read-acl privilege"; 1 This fact was observed in the user study described in Chapter 6. 42 A C E 3 . "Deny group users the write-acl privilege" (users having the write-acl privilege can modify the A C L ) ; A C E 4 . "Grant user test! all privileges"; A C E 5 . "Grant group users the read-content privilege"; A C E 6 . "Grant user test the write-acl privilege", which is inherited from its parent directory; A C E 7 . "Deny user test3 the read-content privilege", which is inherited from its parent directory. In addition, user test is a member of the group users. User test! has two intentions: Intentionl: "User test must have the read-acl privilege"; and Intention2: "User test must have the write-acl privilege". User test has two intentions: Intention3: "User test2 must have the read-content privilege"; and Intention4: "User test3 must have the read-content privilege". Intentionl seems to have been already fulfilled because of A C E 2 . However, since it is preceded by the <deny> A C E 1 , this intention has not been fulfilled. Similarly, it seems that Intention2 has already been fulfilled because of A C E 6 . However, since it is preceded by the <deny> A C E 3 , it has not been fulfilled. For Intention3, according to A C E 4 , this intention has already been fulfilled. For Intention4, according to the deny A C E 7 , this intention is not fulfilled. So, clearly it is not simple just to assess the current state of system. Let's examine the 43 means to achieve an intention that has not been fulfilled by the current state. Because of A C E 4 , user test2 can modify the A C L to fulfill Intentionl and Intention2. For example, test! can add a new A C E that is the same as A C E 2 at the top of the A C L , or remove A C E 1 from the A C L . Consider the situation that user test2 has fulfilled Intentionl but has not fulfilled Intention2, and at that time user test wants to implement Intention4. Because user test has been denied the write-acl privilege, it seems that he cannot implement Intention4. However, because user test has the privilege to modify the A C L of the current resource's parent (according to A C E 6 ) , he can change A C E 7 from <deny> to <grant> by modifying the parent's A C L . In addition, even if A C E 6 does not exist, user test can still implement Intention4 if he has the privilege to modify the group users. In this case, he can add user test3 into group users, and then Intention4 is fulfilled according to A C E 5 . Of course, the last two implementations may cause side-effects, which I w i l l discuss in Section 3.2.3. From these examples we can see that it is difficult for a user to know promptly and without error if his intention has already been fulfilled by simply examining an A C L . Harder still is to determine how to implement it, especially for an end-user who has little knowledge of the A C L model or may not know how to locate necessary information such as the group membership. If we consider the notions of stated privilege and effective privilege introduced in the previous section, we can see that it is the effective privileges, not the stated privileges, that determine if an intention has been fulfilled. The task at hand for the user is then to (1) assess the current state of the system, (2) 44 decide whether or not the goal is already fulfilled, and (3) develop a strategy to decide how to minimally achieve the goal state given the current system state. Since the W e b D A V A C L system is relatively simple, it is likely that we can develop an algorithm to determine this minimal change set. The complexity of this algorithm is then a reasonable measure of the complexity of fulfilling this intention. Therefore in this thesis I also call the analysis based on the algorithm "algorithmic analysis" and the corresponding task complexity "algorithmic complexity". It is worth noting that this task analysis is coincident with the models of human information processing proposed in the H C I and cognitive science literature. For example, according to the Norman[56]/THEA[58] models, which Maxion and Reeder [53] summarized, human information processing starts with a problem, the primary goal, and proceeds in the following loop: (1) Perceive and interpret information from the environment, and evaluate whether the problem is solved. (2) If the problem remains unsolved, formulate a subgoal, according to perceived information, for solving all or part of the problem; if the problem is solved, exit the loop. (3) Formulate a plan to achieve the subgoal. (4) Execute the actions in the plan. 3.2.1 ACLs in Collaborative Environment Consider that the state of A C L system is the result of a number of people with access to shared file-systems collaborating on the current configuration. If we assume that each of these users is pursuing a similar goal-oriented approach to making A C L changes, then the current state should be considered as the result of a multi-agent collaboration. Therefore, before proceeding to the full analysis, let us examine the first stage of the reasoning 45 necessary to deal with the Gl intention: "Principal X must have privilege Y on object Z . " A t first glance, it may appear easy to implement - just adding an A C E that grants the particular principal X the privilege Y (denoted as <X, Y>) to the top of the A C L of object Z . Since the order of A C E s determines precedence, this addition wi l l automatically override any <deny> A C E s that might appear later in the A C L . If we suppose however, that the <deny> A C E was added by another user through his or her own intention then we have a conflict between these two intentions that both users should be informed of. Detecting and resolving such conflicts may be important in a collaborative environment. Therefore, rather than simply adding the grant at the top, we should examine all A C E s until we find one that specifically grants or denies the access rights we intend. Some A C L systems, such as the Windows N T F S A C L system, specify that <deny> A C E s always take precedence over <grant> A C E s . In this case, adding a <grant> A C E wi l l never fulfill the intention if conflicting <deny> A C E s exist in the A C L (the details wi l l be discussed in Section 3.4). In addition, simply adding an A C E to the top of an A C L without examining the existing A C E s may introduce redundancy to the A C L , which may then result in undesired consequences in the long term. For instance, suppose that the existing A C E s have determined that principal X already has privilege Y or some sub-privileges contained in privilege Y , and the user simply adds a <grant> A C E at the top to fulfill the intention Gl. If later on the user wants to achieve the reversed intention, G2, it is possible that he/she may just undo the previous action by removing that <grant> A C E from the A C L . This action wi l l result in an incorrect or incomplete accomplishment of G2, since the pre-existing A C E s granting partial rights to Gl are still in the A C L . Exactly such mistakes 46 were observed in the user study presented in Chapter 6. O f course, as the above example shows, even if the user does not have direct modification rights to the A C L of object Z , it may be possible to grant the access requested. Due to the indirection implied by group membership, it may be possible to grant the privilege Y by modifying the membership of an existing group that has this privilege. Of course, this indirect grant wi l l have side effects (e.g., there may be other objects that the group has rights to and the principal X does not) and the user should at least be notified of these. In addition, if A C L inheritance is enabled in the system, it may be possible to grant the privilege Y by modifying the inherited A C L , if permitted. This may also cause side effects. Let us consider an example. If user A has the privilege to read a document object Z , and he wants principal X , who does not have the read privilege, to read this document. Unfortunately he finds he does not have the privilege to modify the A C L of Z . If he does not know the indirect means of granting access described above, he may just send the document Z to principal X as an email attachment. From this point on, the access control system is essentially irrelevant (at least as far as read access is concerned), since a copy of the file is now " in the wi ld . " As an alternative to copying then, side effects may be acceptable. So, even without considering A C L inheritance (which we wi l l ignore for the purposes of the flow-chart analysis below), we have conflicts that should at least be noticed, and potential side effects from trying to resolve an intention. Clearly resolving even these simple intentions is not a trivial problem. 47 3.2.2 Algorithmic Analysis G 1 : Principal X has privilege Y on object Z. 1 I yes -• no 1 Do nothing Create G1' with unresolved subset X' of X Remove those denials or change to grants Decide whether to remove those principals from the group if I have privilege to modify this group Add grants of unresolved;pnncipals; in-X'.to object Z}Cj Figure 3.1: A possible decision process for determining how to implement G l : principal X must have privilege Y on object Z Figure 3.1 shows a decision process or algorithm that w i l l allow the user to resolve the intention Gl or be given enough information to know why he or she was unable to do so. 48 The process begins with a query Ql ("Does principal X have access privilege Y on Z?") to check i f the goal has already been achieved. If it has not been fully achieved, the user can select all principals X ' in X who don't have privilege Y on Z for further processing. The user then needs to check if he has the privilege to modify the A C L of object Z . If he does, then he examines that A C L in the left branch. Even if he cannot modify the A C L , the process wi l l not end. The user can check i f some group X 2 exists such that X 2 has privilege Y to object Z and that he has the privilege to modify X 2 . If the answer is "yes", the user has to make a decision on whether to add X ' to this group, because this action may cause side effects: as a member of X 2 , the principals in X ' may have all the privileges group X 2 has and lose all the privileges group X 2 is denied. These side effects are produced not only on object Z but also on other resources in the system. If instead the user can modify the A C L , another process flow wi l l go on. If any of the principals in X ' are explicitly denied privilege Y to object Z , that means there are conflicts between the current access control intent and whichever previous intents that caused the denial to be added to the A C L . I wi l l consider the handling of such conflicts in Section 3.2.4. The flowchart in Figure 3.1 does not have any loops, but it does have six branch points. Combining it with the flowchart in Figure 3.2 (and Figure 3.3 below) we can enumerate all of the branch points: Q l : Does principal X have privilege Y on Z? Q2: Do I have the right to modify the A C L of object Z? Q3: Are any of the principals in X ' explicitly denied privilege Y to object Z? Q3.1: Are those principals denied privilege Y to object Z individually or via some group to which they belong? 49 Q4: Does group X 2 exist such that X 2 has privilege Y to object Z and I have the privilege to modify group X2? Q5: Do I have the privilege to create a new group? Q6: Are those principals granted privilege Y to object Z individually or via some group to which they belong? Q7: Does group X 3 exist such that X 3 is denied privilege Y to object Z and I have the privilege to modify group X3? Note that these decision points all involve queries of the system state. If the user does not deeply understand the A C L evaluation model, there is no reason to suppose that he or she would be able to easily resolve these questions. Frankly, it is unlikely that most users would even know to ask many of them. For example, consider the query Q l "Does principal X have privilege Y on Z ? " Answering this query involves evaluating the effective privileges for principal X . A s described above, a principal's effective privileges are computed according to a formula that sums the principal's explicit privileges granted by some A C E s (directly or indirectly via group) and have not been denied by preceding A C E s in the A C L . Thus, users managing access are forced to deal with the low-level A C E s , their ordering in an A C L , and the formulas for resolving overlapping A C E s . Table 3.2 summarizes all the conditions that determine the answer to query Q l . It is clear that by him- or herself a novice end-user cannot be expected to answer the query easily and quickly. 50 Table 3.2: Summary of the conditions determining the answer to query Q l Answer to Q l is "yes" when one of the following A C E s is encountered first: Answer to Q l is "no" when one of the following A C E s is encountered first: (1) Principal X is granted privilege Y (1) Principal X is denied privilege Y (2) Some group to which principal X belongs is granted privilege Y (2) Some group to which principal X belongs is denied privilege Y (3) Principal X is granted an aggregate privilege containing privilege Y (3) Principal X is denied an aggregate privilege containing privilege Y (4) Some group to which principal X belongs is granted an aggregate privilege containing privilege Y (4) Some group to which principal X belongs is denied an aggregate privilege containing privilege Y or No matching A C E s Then, consider the flowchart for intention G2, shown in Figure 3.2. This process flow has a structure similar to that in Figure 3.1, where in each step "grant" is changed to "deny" and vice versa. This is not surprising, since G2 is a negation of G l . However, there is no branch point for the query "Are any principals in X ' explicitly granted privilege Y to object Z ? " corresponding to Q3 in Figure 3.1, because the answer to this query is always "yes" in this flow. This is due to the rule of the A C L model that all privileges should be granted explicitly, and if a privilege is not granted explicitly it is denied by default. 51 G2: Principal X does not have privilege Y on object Z Q6^Are-rhose principals granlea-pftvjigc Y to object Z individually or via some i to which they beJo_D Ssgroup X3 exist sucfi [are denied privilege Y to object Z and f jnyilege to modify grgu I individually- -via group Remove those grants or change to denials Decide whether to remove those principals from the group if I have privilege to modify the group — y e s -JL -no-Decide whether to add X' to group X3 Fail Do nothing Add denials of privilege Y for unresolved principals in X' to object Z Figure 3.2: A possible decision process for determining how to implement intention G2: principal X must not have privilege Y on object Z In this analysis of the decision process I did not consider administrative privileges that can change the A C L (e.g., the write-acl privilege in the W e b D A V A C L model or change permissions permission in the Windows N T F S A C L model). A n y user who has the write-acl privilege can modify the A C L to grant anyone (including him- or herself) any 52 privilege. Taking this into account, any "deny" intention must resolve another intention, "principal X must not have the write-acl privilege on object Z " , before resolving the intention G2; otherwise principal X may still grant him- or herself privilege Y at any time by modifying the A C L . It should be clear from examining these two flowcharts and Table 3.2 that the process of deciding how to implement a particular intention is neither simple in terms of algorithmic complexity nor in terms of comprehension and examination of the system state. A user must know what questions to ask of the A C L system and in what order, and then may be forced to make some difficult decisions to achieve the desired goal. Thus, the task of formulating changes to an A C L to achieve even these simple intentions is far from trivial. Further, in addition to the difficulties the user may have in resolving the intention, the lack of system support for answering these queries (e.g., an interface providing ready access to needed information), or of user knowledge for properly asking and resolving these queries, may lead to user errors. There are potential risks or errors associated with each query. Errors can be classified into two types: errors of commission due to the user establishing a wrong answer to a query; and errors of omission due to the user failing to make a query. For example, let us consider Q l . If the user gets the wrong answer "yes" to Q l due to either lack of information or mistaken evaluation, he may falsely conclude that the intention is achieved and that nothing needs to be done (error of commission). If the user does not know to ask G4, he may falsely conclude that the intention cannot be achieved in any way (error of omission). Thus, tools designed to reduce the conceptual load of users should not only make access control systems easier to use but also reduce .53 the occurrence of these user errors. In conclusion, the structure of the algorithm represents the complexity of the "gulf of execution" for any interface to directly manipulate A C L s . The queries derived from the decision points represent a minimal set of states to be presented by an interface to cover the "gulf of evaluation". Finally, this analysis reveals three important features of the problem that wi l l be important in designing systems to interact with this model: side effects, conflicts and user modeling decisions. 3.2.3 Side Effects Any time a simple intention "principal X must have privilege Y on object Z " is resolved by the addition of principal X to some group G , it is likely that this action wi l l have side effects. Suddenly, principal X may be granted (or denied) other privileges that have been associated with group G . A t a minimum, the user should be notified of these side effects. Similarly, side effects may arise if the intention is resolved by the removal of principal X from some group G . In addition, if A C L inheritance is enabled and the intention G l is resolved by modifying the inherited A C L , side effects may arise on any resource that inherits from the modified A C L . There are, however, two other possible complications. It is possible that one of these side effects changes the results of a query in one of the previous branch points in the flowchart. In this case, we do have a loop and must go back and re-examine these points. 54 The other possibility is that there may be a number of different groups with privilege Y on object Z that the user could add principal X to. In that case, we must consider that there are some decision points with multiple branches leading out of them, and we must allow the user to decide which of these would be preferable. I call these decision points modeling decisions. 3.2.4 Conflicts Of course, there is no reason to have any sort of access control system in a single-user environment, so we should not conclude our analysis without due consideration of other users. Let us assume that all of the users of the W e b D A V repository are basing their A C L implementations on similar intentional processes. As I pointed out above, it can be important to detect situations in which it is likely that two users' intentions are in conflict (i.e., one user acts to ensure a privilege Y for principal X on object Z and another user acts to deny that same privilege for principal X ) . In addition, because of the privilege hierarchy (i.e., aggregate privileges contain other privileges), two users' intentions may be in partial conflict, in which case the privileges in these two intentions do not exactly match but overlap. What sort of consequences should there be when such a conflict is detected? We could adopt a "most-recent-change-wins" policy, in which case there is an obligation to at least inform the source of the conflicting A C E that his or her intention has been superseded. : A n alternative would be to disallow such supersessions and instead initiate a request to the source of the first entry that they retract their intention or modify it to allow an exception. This step could be augmented by an automatic process to suggest alternatives 55 for resolving the conflict, a process that would likely have to be analyzed as I have done above. Note that there are two kinds of conflict: the conflict between the A C E s and the conflict between the user intentions. Users care about the conflicts between intentions. However, even when two intentions do not conflict, it is possible that the resulting A C E s are in conflict, i f the implementation of the previous intention causes some side-effects which contradict with the latter intention. I wi l l not explore the issue in this thesis, but leave it for future research. 3.2.5 Modeling Decisions The above example exposed one kind of modeling decision, a choice of which of a set of possible groups the user might expand or contract membership to in order to resolve an intention. It is likely that a combination of the "identities" of the groups and the side effects resulting from this change wi l l determine which group the user w i l l choose. A user may want to know what the options are to make such a decision, or simply choose the option with the fewest side effects. It may not be unreasonable to consider this difference to be subject to a user preference. Another kind of modeling decision may arise in the case where the user identifies a set of principals in his initial intention. In that case, we have the modeling decisions shown in Figure 3.3. We may be able to simply add individual grants directly, create a new group for those principals and add a grant to that group, or even add all of the principals to an existing group with the desired privilege. O f course, this last choice may cause side effects. 56 To add grant of privilege Y for X' to object Z: Add every principal in X' to the ACL of object Z with privilege Y Create a group and add it to ACL of object Z with privilege Y; add X' to this group Add X' to this group X2 Figure 3.3: Example of a user's modeling decisions for Gl 3.3 Discussions 3.3.1 Other Intentions Consider also the "special" reflexive intention "I should have privilege Y on object Z " . At first glance, this would seem to be just a variation on the intention G l ; however it has very different implications. First, if it is possible for me to grant myself privileges that I didn't previously have, then it could certainly be argued that the system state is insecure, since no user should be able to grant him- or herself previously unavailable privileges in a secure system. But with the mix of direct and indirect privilege granting that comes from the addition of groups, it may be difficult to maintain this level of security 57 throughout. In addition, it is unavoidable in the Windows N T F S file system that I can grant myself any privilege if I am the owner, because the owner of a file or folder in the Windows N T F S system can always change permissions on it, regardless of existing permissions protecting the file or folder. Even in a secure system state it may be useful to submit this intention, since a conflict identified by it w i l l point to the reason why the user has been denied access [43]. A subsequent query could then be made: "Who can grant me access?" O f course, for the intentions discussed previously, limited access to the A C L state of the system was not a problem. For example, if the user cannot examine the membership or permissions of a group, then it is irrelevant to the intention of using that group to grant a privilege, since the user w i l l not be able to modify its membership anyway. With the "Who can grant me access?" query, however, it may be necessary to be able to examine such states. In this case, a list of people to ask would not necessarily violate the information hiding that presumably has been done deliberately if it is only their identity that is being revealed. In fact, if the intentions are transferable, then the user could effectively request access by passing on a description of his intention to someone capable of granting it and then allow them to decide whether and how to do so. 3.3.2 More Complex Cases To this point, we have considered only simple intentions. Even for these simple cases, the set of queries that a user needs and the system should support (Q1-Q7) are neither simple nor small in number. They illustrate that even for simple intentions, the conceptual load of users in constructing sequential and conditional queries and interacting with the system 58 for modeling decisions is relatively heavy compared to the simplicity of the intentions. Consider complex intentions such as the following: " A l l the members in the groups to which my wife or I belongs except Bob have privilege Y on object Z . " Clearly it is not an easy task for the user to transfer this intention to actual access control list settings. In the worst case, there may be ambiguities in a user's intentions. The system may need to detect such ambiguities and provide feedback to help the user make his or her intentions clear. Some access control systems may group the privileges in a privilege hierarchy. For example, the privilege read may contain a sub-privilege read-acl that is the privilege to read the A C L . Surely it w i l l complicate the decision process of the user to fulfill his/her goals, in either assessing the system state or planning the implementation. Further, the privileges I have discussed so far are low-level privileges that are implementation-specific and can be set directly in the A C E s . However, the user, especially the end-user, may often have high-level privileges in mind that are not necessarily the same as the low-level privileges. In this case, the user has to understand the semantics of these low-level privileges. He or she then has to translate the high-level privileges to these low-level privileges before he or she can conduct a decision process such as the one described above for determining how to implement this intention. Therefore, the user has to construct a mapping between the high-level privileges and the actual low-level privileges which can be applied in the system. This need not be a one-to-one mapping. One high-level privilege may be mapped to a combination of multiple low-level privileges. For example, in some systems, to have the high-level privilege to change 59 the membership of a group, you need to have both write-properties and write-content low-level privileges on the resource representing the group. It is clear that such translations increase the user's conceptual load further; a system that can perform these translations automatically or semi-automatically is more usable. The W e b D A V access control specification indicates that the server implementation may support some A C L restrictions. For example, the "deny-before-grant" restriction specifies that all non-inherited <deny> A C E s must precede all non-inherited <grant> A C E s . The "grant-only" restriction indicates that A C E s with deny clauses are not allowed. In this case, if the user wants to deny principal X the privilege Y , and principal X holds the privilege Y by both an A C E granting him this privilege and an A C E granting a group of which he is a member this privilege, just removing the former wi l l not fulfill his intention. In addition, the W e b D A V access control specification also introduces some A C L preconditions. For instance, the "no-inherited-ace-conflict" specifies that the A C E s to be set must not conflict with the inherited A C E s on a resource. If such A C L restrictions or preconditions must be enforced in the access control systems concerned, the intentional analysis wi l l be more complex for the user, as discussed below in relation to the Windows N T F S system. 3.3.3 Beyond the Algorithmic Analysis There exist some well-known techniques for task analysis in human-computer interaction, which include the Hierarchical Task Analysis ( H T A ) [46] [47], G O M S (Goals, Operations, Methods, Selection rules) and its variants [10] [42]. However, in this 2 N.B. This is a restriction employed by the Windows NTFS, which will be discussed in Section 3.4. 60 thesis I chose a method of task flow analysis, since it is simple and straightforward for qualitatively demonstrating the task complexity and the user's mental burden on the decision processes for directly manipulating the A C L . The G O M S model represents the procedural knowledge required to operate a system in terms of the user Goals, basic actions or Operators, Methods, which are sequences of operators that wi l l accomplish goals, and Selection rules, which determine which method to apply to accomplish a goal. M y analysis has shown that a system only supporting direct manipulation on the internal access control mechanism is less goal-directed and thus may be inappropriate to apply G O M S . Further, the usability of the access control system is not just an interface design problem. The simple user interface design methodologies (e.g., G O M S ) may miss some aspects of usability problem. To demonstrate it, here a variant of G O M S , called N G O M S L [45] is employed for analyzing the design of direct manipulation on A C L with feedback. 61 N G O M S L Statements Method for goal: fulfill the intention G l : principal <X> must have privilege <Y> on object <Z> Step 1. Locate effective privileges for principal <X> Step 2. Decide: If principal <X> has privilege <Y>, then return with goal accomplished. Step 3. Locate effective privileges for <myself> Step 4. Decide: If I have the privilege modify-ACL, then accomplish goal: directly grant principal <X> privilege <Y>, else accomplish goal: indirectly grant principal <X> privilege <Y>. Step 5: Verify the intention fulfilled Step 6. Return with goal accomplished. Method for goal: directly grant principal <X> privilege <Y> Step 1: Locate stated privileges for principal <X> Step 2: Decide: If <X> is denied <Y> by default, then accomplish goal: add grant of privilege <Y>. If <X> is denied <Y> individually, then remove deny A C E or change deny A C E . If <X> is denied <Y> via some group, then decide whether to remove <X> from the group. Step 3. Locate effective privileges for principal <X> Step 4. Decide: If principal <X> has no privilege <Y>, then accomplish goal: add grant of privilege <Y> to principal <X>. Step 5. Return with goal accomplished. Method for goal: indirectly grant principal <X> privilege <Y> Step 1: search for group <X2> that has privilege <Y> to <Z> and I have privilege to modify <X2> Step 2: Decide: If <X2> exists, then decide whether to add <X> to <X2> If <X2> does not exist, then return with goal unaccomplished. Step 3. Return with goal accomplished. Selection rule set for goal: add grant of privilege <Y> to principal <X> If <user-specified-conditionl>, Then add a new A C E including <X> and <Y>. If <user-specified-condition2>, Then create a group having privilege <Y> and add <X> to that group. If <user-specified-condition3>, Then accomplish goal: indirectly grant principal <X> privilege <Y>. Return with goal accomplished. Figure 3.4: An example of NGOMSL model for a system supporting direct manipulation on ACL + feedback Figure 3.4 shows an example of N G O M S L methods for fulfilling the intention G l discussed above. Compared with the flowchart analysis, this G O M S model does not seem to provide any more information. In addition, each mental step in the G O M S model is treated as if it were equally demanding as one normal step that deemphasizes the complexity and difficulty of the user's mental process, and may lead to wrong design 62 directions. Further, the selection rules concerning modeling decisions are not clear because making that choice is left to the user (denoted by <user-specified-conditionl>, <user-specified-condition2>, etc. in Figure 3.4). G O M S techniques can provide an easier analysis and predictions (e.g., execution time) on a user's interaction with an interface. However, they miss some aspects important to access management tasks. For example, there is no the side-effect analysis as well as a discussion of the system state as the result of a series of interactions by a set of users. In the algorithmic analysis above, I deliberately chose simple cases. Most other access control systems (e.g., policy-based, RBAC-based) are at least as complicated, and thus likely more conceptually complex and potentially "unusable". The first finding we can naturally derive from the above analysis is that any user interface that lets users manipulate the embedded access control mechanism should provide enough and needed information to users so that they can fulfill their tasks quickly and accurately. For example, this analysis has exposed the views of system state necessary to effectively manipulate the A C L in terms of the queries Q1-Q7. This claim is supported by the work of Maxion and Reeder [53]. The Salmon interface [53] can provide answers to queries Q l , Q2, Q3, Q6, partial answers to Q4 and Q7, but no answer to Q5. One consequence of the analysis would thus be to refine the Salmon interface to better support the evaluation of Q4, Q5 and Q7. However, I suggest that manipulating the A C L directly is not the right goal for a user interface design. Just visibility (i.e., good feedback) may not be going to work. Consider the complexity revealed by the above analysis. The factors, including the ordering of 63 A C E s and its restrictions (e.g., deny-before-grant, no-inherited-ace-conflict), indirections by group membership and A C L inheritance, the privilege hierarchy, and administrative privileges, all complicate the decision processes for end-users. For an interface representing the interactions of manipulating the A C L , it is necessary to expose such complexity to end-users. The procedures and reasoning that are necessary to determine how to manipulate the A C L for fulfilling the goals are left to the users. If the system does not help/guide end-users to fulfill their goals according to the above analysis, end-users have to learn and retain the procedures by themselves while they are only interested in the system effects or results - effective privileges. Therefore, I suggest that the next step is to consider the design of systems that limit the need for the user to be exposed to such complexity. The above analysis has shown that the translation between the A C L and user goals is just algorithmic and predictable. Therefore, we may design systems that can support the expression of user intentions and then resolve these intentions on the user's behalf, or at least provide significant offloading of the conceptual load, which produces usable interfaces for these access control systems. Such systems present a higher level of abstraction and can be regarded as an incremental compiler that compiles down the high-level language (i.e., goals) to the low-level assembly language (i.e., A C L implementation). More specifically, we need support of visibility and manipulation in terms of effective access control as well as reasoning support to deal with indirection issues and limited manipulation. In this sense, the Salmon interface [53] can be taken as a front end of such systems while the input is changed to effective permissions instead of stated permissions. I wi l l refer to such systems as Intentional Access Management systems and discuss them in the next chapter. 64 3.4 Windows NTFS Access Control A s indicated above, the basic W e b D A V access control model is derived from existing file system practice such as Microsoft's N T file system (NTFS). N T F S has been widely used in PCs running Microsoft Windows operating systems, including Windows 2000 and Windows X P , which makes the usability of its access control mechanism more critical for average end-users. Therefore, below I extend my analysis to the Windows N T F S access control mechanism. Figure 3.5 shows the Permissions dialog box in Windows 2000. It can be seen as a direct representation of the internal access control list model. N T F S uses an access control list model similar to the one embedded in W e b D A V for controlling file permissions. Thus the intentional analysis described above can also be applied to it. However, there are some additional features in the N T F S A C L model that make the model more complex than the W e b D A V A C L model. Here I w i l l discuss two of the features complicating the analysis of the N T F S A C L model. Readers interested in the details of the N T F S A C L model can refer to the Microsoft TechNet article [54]. 65 Mydoc.doc Properties General Security Custom i Summary J Name • {JJ Administrators (Userl ^Administrators) _ ! U serO ne (D 0 MAI N \user1) SYSTEM Add.. -Remove Permissions: ** / p Allow Deny Full Control 0 • Modify El • Read 8c Execute El • Read El • Write El • Advanced.: I^ jj Allow inheritable permissions from parent to propagate to this -•=J ob|ect ' , " i , 1" "•" c OK, Cancel f Figure 3.5: A screenshot of the File Permissions interface in Windows 2000 In the N T F S A C L model, non-inherited deny A C E s always take precedence over non-inherited grant/allow A C E s (equivalent to the "deny-before-grant" restriction in the W e b D A V A C L model). This means that the order of A C E s is simplified and not as important as in the W e b D A V A C L model. If a user is a member of two groups, one that is allowed a permission and another that is denied it, the user is denied that permission. On the one hand, it is a beneficial constraint for assessing the system state. On the other hand, it also complicates the decision process the user has to take for granting privileges. Based on this rule, if the user is denied a permission explicitly by a non-inherited deny A C E and you want to grant him the same permission, simply adding a new grant A C E for 66 the user at the top of the A C L wi l l not work, while it usually works for the W e b D A V A C L model. In this case, one possible solution is to first remove the deny A C E , and then add the grant A C E . But now side effects may arise if the permission in the removed deny A C E is a sup-permission that contains the permission in the added grant A C E . In N T F S systems every object has an owner. The owner of a file/folder can always modify permissions on the file/folder and give other users the right to take ownership, no matter what permissions exist on the file/folder. This means that the owner can grant himself some permissions even he is explicitly denied these permissions by some deny A C E s (by removing these deny A C E s first). Anyone or any group who has the take ownership permission on the file/folder can take the ownership of the file/folder, implying that any user having the take ownership permission can get all permissions on the file/folder. Thus, when the user managing access wants to achieve the intention "user X must not have permission Y on object Z " , before taking some similar processes as described in Figure 3.2, he has to do some additional work to resolve another intention "user X must not have the take ownership permission on object Z . " Moreover, in N T F S users can perform certain actions on files or folders even if permissions are set on a file or folder to prevent access to users. For example, groups or users granted Full Control on a folder can delete any files in that folder regardless of the permissions protecting the file. In this case, to ensure that a user having Full Control on a folder does not have rights to delete some file in that folder, you must set permissions on the file itself, and you must set permissions for the folder containing the file. This discussion of the N T F S A C L model clearly shows that the decision processes 67 designed for the W e b D A V A C L model have to be extended to adapt to these new rules. The result wi l l be more complex flowcharts, increasing the conceptual complexity of access management tasks for end-users. The Intentional Access Management systems we suggested previously are therefore more desirable in this context. 3.5 Summary In this chapter, I have conducted an algorithmic analysis of the W e b D A V access control mechanism from the point-of-view of an end-user trying to decide how to grant or deny access to some resource to a third party. I have demonstrated that even for a simple intention the task's conceptual complexity is too heavy for end-users. The usability of access control can thus be improved by designing tools that can support user intentions and reduce such complexity. This analysis also raised issues in resolving users' intensions, such as side effects, conflicts, and design-time modeling decisions. From the analysis, we can locate the main sources of complexity. The first is the ordering of A C E s and its restrictions including deny-before-grant, grant-only, and no-inherited-ace-conflict. The second is the indirections of groups and A C L inheritance. These indirections make the assessment of system state complex, but also provide the alternative ways to fulfill the user's goal that end-users often miss. The privilege hierarchy that isn't transparent to the user wi l l complicate access management tasks. Finally the complexity also comes from the administrative privileges, especially for denying privileges. 68 Based on these complicating factors, this chapter has analyzed the "gulf of execution" for users and systems to manipulate the A C L . During the analysis, it exposes the difference in semantics between the goal and the A C E , as well as the views of system state necessary to effectively manipulate the A C L which can be used to bridge the "gulf of evaluation." The analysis also demonstrates that the simple UI design (e.g., G O M S ) misses aspects of the problem concerning mental processes in the access management. It suggests that providing direct manipulation of A C L to end-users is not the right goal for a UI design of a security system, considering the task complexity and the low interest and expertise of end-users. Since the relationship between the goal and the A C L configuration has been shown to be algorithmic, it is feasible to design an access management tool representing a higher level of abstraction (i.e., the user intention) to end-users with feedback support as in Salmon, without abandoning the existing internal access control mechanism (i.e., the A C L ) . In this way, it w i l l be more usable for end-users to manage access, while expert administrators can still work on the low-level A C L which fits their expertise. Note that the flowchart analysis examines the steps an ideal user would take to implement his desired access constraints given the system model and state. These flowcharts thus convey the inherent complexity of the task. However, as indicated before, some specific users may take different steps, whether correct or not, to implement their intentions based on their own limited mental model of the access control system. Here I refer to the "mental model" as a set of beliefs about how a system works and how humans interact with the system based on these beliefs [15] [56]. I investigate this issue further in the user study described in Chapter 6. 69 In my analysis, I simply take the complexity of the flowchart algorithm as an indicator of the conceptual load of the user. For this analysis, it is sufficient to demonstrate the complexity qualitatively in terms of the branch points and user mental processes. A similar but more complicated concept is the cognitive complexity of the user's mental model or cognitive load [60]. In the literature, various approaches have been proposed for measuring cognitive complexity. For example, four different quantitative metrics for cognitive complexity were compared in [60]. Investigation of such metrics to measure cognitive complexity in Human-Computer Interaction for security management tasks may be an interesting topic for further research. 70 Chapter 4 Intentional Access Management (IAM) The previous chapter thoroughly analyzed the complexity of certain access management tasks for W e b D A V and Windows N T F S , and concluded that the burden on end-users to execute these tasks is too great, especially in view of their low interest in access control itself. As an alternative approach, I proposed intentional access management systems (IAMs) that separate end-user interactions from the internal access control mechanisms. In this chapter, I develop the design details of such systems. 4.1 Design Principles Before describing intentional access management systems, it is important to consider a number of design constraints. I do so by interpreting the existing literature on usability of both general systems and security systems in terms of these intentional analyses and systems [3] [56] [69] [71] [93]. It must be emphasized that users of privacy/security systems view them as means to an 71 end and not an end in themselves [85] [4]. The systems are always peripheral to a user's primary task. Therefore, users of security management systems have little or no interest in solving "puzzles" to be able to use them. The analysis in Chapter 3 exposed some of these "puzzles". Reluctance to solve them is especially true of end-users, since they usually have limited expertise and interest in security systems compared to administrators. In this context I wish to extend the design principles of Clarity and Visibility from Yee [90] [91] (see Chapter 2 for a brief introduction) and recast them into a form specific to the analysis I have just completed. In general, for systems that involve risky or critical decisions (such as security systems), I claim that: User decisions should be made/requested in an environment where 1. the user has access to essential information needed to make the decision reliably; and 2. the system is responsible for predicting and presenting such information when it can. The translation of these principles into a system that takes user intentions as input and attempts to resolve them in a way that formulates access control rules that fulfill these intentions wi l l result in what I refer to as an Intentional Access Management system. I define an intentional access management system ( IAM) as any system in which the following are true: 1. The user initiates interaction with the system by expressing an intention in terms of an output constraint on the access control system; 2. The system translates these intentions into implementation; 72 3. The system follows Yee's principles of clarity and visibility in informing the user of the consequences of actions not directly implied by their intentions; and 4. The system informs the user of modeling variations as well as detected ambiguities and conflicts in intentions. User's Mental Model Existing Access Control Systems . t Q „ t - „ i . . j Enforcement , . Intention k—H s t a t e m e n t H M UI Access Control Mechanism User's Mental! (New) Intention k-Model Intentional UI Access Management Proposed Access Control System Figure 4.1: Two access control system models and the corresponding user's mental models In interacting with a computer system, users form internal, mental models of the system 73 with which they are interacting [56]. The more mental models a task requires, and the greater the complexity of these model(s), the poorer the user's performance wi l l be [67]. To use existing access control systems, the user must translate his or her intentions into enforcement statements (access control rules) and input these statements to the system through a user interface (UI). The access control mechanism then enforces the statements. As shown in Figure 4.1, in such systems the user needs to understand the access control mechanism and construct a complex mental model containing all involved blocks. In Norman's terms, the "gulf of execution" includes the problems of translating task-related needs into access-control privileges, of formulating a set of configuration changes to the access control rules that w i l l fulfill these privileges, and then of using the system UI to effect these changes. B y contrast, I A M systems separate access management from the access control mechanism so that the user only needs to identify and express his or her intentions to the system, without requiring direct knowledge of the access control mechanism (e.g., the assembly language-like A C L ) . The gulf of execution is thus reduced to one of expressing the intended privileges with the I A M user interface, with the rest of the configuration issues automated. The user w i l l construct a much simpler mental model containing only his or her intentions and the intentional access management model. The user should find such access control systems more usable. "Direct" interface for manipulating the internal mechanisms makes the system effects simple and immediate, but neither in terms of user interest/intention nor addressing the gulf of execution. Invisibly bridging the gulf of execution without adequate feedback 74 might decrease trust in the system by making it appear "magical" or unpredictable. B y ensuring visibility at the same time (i.e. addressing the gulf of evaluation) we allow the system to appear predictable and tool-like. Inspired by the concept of user-centered security [93], what I design are goal-driven systems with feedback on effects in terms of user intentions. Such systems provide a higher level of abstraction from direct manipulation of the internal mechanisms, which better fits end-users' expectations. I identify three possible levels of support for intentional access management: the wizard model, the full I A M model, and the multi-backend I A M model. 4.2 The IAM Wizard One of the simplest ways to achieve the I A M model is to allow a user to express an intention and then use a "wizard" to walk the user through the process of creating an implementation of that requirement. This approach is similar to the various wizards used to allow some end-user system management in Windows environments. Wizards essentially walk a user through the decision process and request him or her to make choices when necessary. Such a wizard for access management can be implemented by simply following the flowchart for implementing a goal and changing the "wizard window" whenever a modeling decision that refines the goal must be made. This window should at minimum provide access to some representation of the side effects of the modeling decisions 75 (visibility), and some description of the conflicts found as well as possible ways to resolve them. It must also make clear what the actions taken were and what the side effects of these actions are (clarity). The interruption inherent in the wizard model may be mitigated by adopting the Surprise-Explain-Reward strategy. Derived from psychology literature and brought into software development in the context of "End-User Software Engineering" [88], the Surprise-Explain-Reward methodology has great potential for general notification strategies and developing adaptive user-interaction modes. This methodology suggests that the wizard should: (1) surprise users with evidence that their current practice isn't working as well as they thought and that there is an "information gap" or a hole in their understanding that wi l l make them curious; (2) explain the information that w i l l f i l l this hole; and (3) reward them with immediately perceivable benefits for using the technique. One problem with the pure wizard approach, however, is in detecting and resolving conflicts. This model assumes that intentions are expressed incrementally and that incremental changes are made to the system state to fulfill these intentions. Ultimately, the current system state is derived from a series of intentions expressed by a variety of users. Without some record of who made a change and what their intention was in doing so, it becomes very difficult for the system to do more than just notice that conflicts exist (e.g., between an existing grant and an intent to deny a privilege). If we wish to be able to actually resolve these conflicts, we need a system that maintains a record of intentions on a per-user basis and relates these to the current system state. 76 4.3 Full IAM Figure 4.2 presents a model that can deal with conflicts intelligently. It shows a full intentional access management system that, in addition to the requirements for basic I A M , includes: 1. the maintenance of intentions for each user; 2. the ability to retract previous intentions (like "undo" in direct manipulation); 3. the maintenance of connections between intentions and implementation actions; and 4. the management of conflicts by initiating user interactions to resolve conflicts. Figure 4.2: Ful l intentional access management ( IAM) model 77 Taking these requirements into account, as depicted in Figure 4.2, I propose a full intentional access management model aimed at further increasing the usability of access management. In an intention management system built upon this model, users can present their intentions based on their own conceptual access control model. The Constraint Manager module wi l l then interpret these intentions and transfer them into appropriate access control implementation. The Constraint Manager deals with constraint satisfaction and conflict resolution. Some set of intentions/goals {G} exists, and an access control system is configured to fulfill them. Constraint satisfaction creates and maintains the dependency D(S, G) on an access control statement S that helps to achieve an intention/goal G (i.e., is produced as a result of introducing intention/goal G). A conflict occurs when a new intention/goal G ' is introduced that contradicts an existing intention/goal G . If G ' and G are both generated by the same user, then G ' has priority over G , but the user should be notified. If user U ' introduced G ' and user U introduced G , then we have an inter-user conflict and need some strategy of notification and conflict resolution. Note that here I do not introduce any new complexity to access control systems, but expose the inherent complexity of the systems in the multi-user environment. 78 4.4 Multi-Backend IAM Finally, it becomes feasible to expand this model to one in which there may be a variety of different implementation models available as the backend, depending on the storage repository being used. If done correctly, the intentional model may be able to present the user with a unified conceptual model and interface independent of the means being used to implement the access control. Thus through the multi-backend I A M , end-users can control multiple systems embedding various access control mechanisms, while administrators can still manage the systems through their traditional way. O f course this wi l l raise a challenging issue of mapping the administrators' administrative actions to their intentions, if we want to detect and resolve the conflicts between the intentions of administrators and end-users. To achieve such security interoperability, a Consensus Model needs to be constructed as a mediator between the Constraint Manager and the security backend implementations, as shown in Figure 4.3. The consensus model w i l l abstract access control out of the concrete implementations such as simple A C L , R B A C (role-based access control) -based, and/or policy-based systems. In this way, a general constraint manager can be maintained no matter what access control mechanism is implemented in the backend. Validation of the proposed intentional access management models is a concern. However, we can confidently claim that the proposed models can be implemented, because the basic intentions G l ("Principal X must have privilege Y on object Z") and G2 ("Principal X must not have privilege Y on object Z") represent the semantics embedded in the access matrix lying at the heart of most access control models (as discussed in Chapter 1). In essence then, the goal statements are simply modeling the same access matrix as traditional access control systems, except as constraints on the effective privileges. Absent conflicts then (which I argued should primarily be resolved outside the access control system), both I A M and traditional access control are constraining the same resource. Therefore, i f an access control system is sufficiently powerful to describe any potential access matrix (and the intentional model clearly is), the problem of deriving an access control implementation from a set of intentional constraints is simply algorithmic. To demonstrate the applicability and inherent usability of intentional access management designs, in the following chapters I apply the proposed principles and models to an access management prototype for W e b D A V access control. I then conduct a preliminary user 80 study on this system and report the results. 4.5 Summary In this chapter, I have presented new conceptual designs for making access control more usable. The core idea is to clearly separate access management from access control so that end-users can focus on security goals while the system models/interprets these goals, translates them to implementation, and then provides feedback to users. In this way, end-users are isolated from the actual access control mechanisms, which they usually are not interested in and find difficult to manipulate. There are potential pros and cons for these designs. The pros include: no need to change deployed back-ends/enforcement models; ability to resolve conflicts and reflexive needs (i.e., "self-grant"). A s for the cons, the Ful l I A M model implies tracking intentions per-user, which may put an extra burden on users associated with managing these intentions over time. There are also unaddressed difficulties. For example, some access control systems support privilege hierarchy, but how to match it with task needs is not clear through these models. I wi l l now test the designs and predictions discussed above by implementing a simple wizard interface and then test it to ensure that it is at the right level of abstraction for end-users. The details wi l l be described in the following chapters. 81 Chapter 5 Implementation: IAM for WebDAV In Chapter 3, I made a thorough analysis of the W e b D A V access control list model, mainly focusing on the conceptual complexity for the end-user of fulfilling some security goals. I graphically depicted this analysis in two flowcharts showing the decision processes involved and discussed concepts such as side effects, conflicts, and modeling decisions. Chapter 4 proposed design principles and three levels of intentional access management models to reduce the algorithmic complexity of such security tasks. To demonstrate the applicability of these new designs, based on the results of the intentional analysis in Chapter 3, I then developed an access management prototype for W e b D A V . In this chapter, I w i l l discuss implementation details and address some issues raised in the implementation. 5.1 Related WebDAV Applications W e b D A V has been implemented in various open-source and commercial products (for a 82 list of projects and software that support W e b D A V , please refer to the section "Projects and Software" in [81]). But not all the software supporting W e b D A V provides the functionality for managing W e b D A V access control. For example, Windows X P supports access to W e b D A V servers by Web Folders, but it does not provide a way for users to change the permissions on the resources in the server. The W e b D A V Access Control Protocol is currently implemented by S A P Netweaver, Xythos WebFile Server and Oracle X M L D B , on the server side, and by Xythos WebFile on the client side. Properties Permissions.jSharingj LinkJoJE-mailTo 'Name " • Permissions Inherited From • tilrobbt ' S franp RWADNMRLIGS \User\franp\ ;_'.J ;>"l ,j Add • .;.Remove p" Inherftpermissions ftorrvparem ' P" Replace permissions on all clhild objects'with entiles shown heie - Fl IS/FO id e r pe rmis sio ne't--^-l p Re ad/D own la a d fi le s .' IT" V1/rite/Upload files . i f 3 AppendyReplscefiles-' •'. if*. Delete flies • if™ Rename lites ' • •' '• ''J""'; Create subdirectories .. f - Remove subdirectories p!; Can view directory listings p*!"Apply rights to subdirectories i p .View permissions. _ ,' \ p. Modify ''pa rrntssions-•••'• , Select All Clear All' • :.. OK • ; Cancel " j Apply ; j Figure 5.1: A screenshot of the File Permissions interface in GroupDrive Client 83 To enable end-users to manage access to resources, current W e b D A V systems provide only a command-line interface, or a simple G U I similar to the File Permissions interface in Windows 2000 or Windows X P . These interfaces function as some kind of A C L editors. They present A C L s to end-users, and allow them to modify those A C L s , both in a direct way. The GroupDrive Collaboration Suite [35], a commercial product developed by South River Technologies, provides a good example of such systems. It is a typical W e b D A V application supporting collaboration. This software suite includes: GroupDrive Server, a secure W e b D A V server for storing and collaborating on files; GroupDrive Client, a client that maps a drive letter to the GroupDrive server, enabling users to save files and collaborate on documents from within any Windows application; and GroupDrive Web Interface, a simple interface that allows users to connect to the GroupDrive server from anywhere. The use of W e b D A V enables real-time file collaboration among users in multiple locations. The GroupDrive Client provides a simple G U I (shown in Figure 5.1) to let users define the access control list (permissions) for the file object. A s discussed in Chapter 3, it is difficult for end-users to manage access through this kind of interface. For instance, when considering groups, the end-user cannot easily determine a given user's effective permissions on a resource. Also because of the addition of groups, if the end-user wants to deny someone certain permissions, simply unchecking the corresponding permissions on that user may not work. When the end-user cannot modify the A C L directly, he or she cannot easily know if some of the alternatives I indicated in Chapter 3 exist. In addition, since this system does not support <deny> A C E s , the end-user w i l l not 84 know if there are conflicts when he or she wants to grant another user certain permissions. 5.2 System Design The I A M prototype for W e b D A V was developed using the Java programming language. The Java Foundation Classes (JFC) Swing packages were used to build the graphical user interfaces (GUIs). In the current implementation, an I A M wizard was built into the W e b D A V client, so that end-users can use this client to easily manage access to the W e b D A V server. A n y server supporting W e b D A V may be used for this system; I chose Slide server [39]. Slide is a content repository that can serve as a basis for a content management system/framework and other purposes. It features full W e b D A V support and flexible control over permissions at a per file level via support for the W e b D A V A C L . Slide only includes a command-line based W e b D A V client, so I chose D A V Explorer [14] as the client, whose user interface is similar in look and functionality to the Explorer program provided by the Windows operating system. D A V Explorer supports W e b D A V Access Control Protocol and provides listing of access control information, adding and modification of A C L s , and A C L reports. Figure 5.2 shows the interface for viewing A C L and Figure 5.3 shows that for adding/modifying A C L . 85 localhost:8880/slide/Tiles/book 1 /ChapteM.doc , !~ "Principals' I "~ Privileges""-' C I'GrahUDehy ' Inherited From felide/roles/ProjectA write-content Grant /slide/roles/user all Grant /slideffiles/bookV owner read-acl Grant /slide/files un authenticated all Grant /slide/files /slide/roles/user write Grant /slide/files /slide/roles/root all Grant /slide/ all read-acl, write-acl. unlock Deny /slide/ all read Grant /slide/ Add Principal. , Delete Principal Save Close Figure 5.2: A screenshot of the View A C L interface in D A V Explorer localhost:8080/slide/Tiles/book1 /Chapter1 .doc Principal^!' Privileges " Grant iDeny Principal: /users/test' href: /slide'users/test OK aaiCanceLfii Figure 5.3: A screenshot of the Add/Modify A C L interface in D A V Explorer Both Slide and D A V Explorer are open-source software. I was therefore able to integrate a new I A M module that I developed into the D A V Explorer. This module implemented 86 the I A M Wizard model proposed in Chapter 4, as well as other UI features designed to improve usability. The current implementation supports basic intentions of who must / must not have what privileges on the object. I also incorporated a module for managing group membership into the D A V Explorer. Launch DialogA to obtain the user's intention yes Launch DialogB for the user's decision yes Check for conflicts Launch DialogB for the user's decision Modify the system state according to the user's decision no Launch DialogC to display the result Figure 5.4: The program flow for fulfilling the user's intention 87 I based the program flow of the I A M wizard on the decision processes derived from the intentional analysis in Chapter 3, but all reasoning work is now performed by the I A M instead of the user. To fulfill the user's intention, the system state wi l l be changed by adding/removing/modifying A C E s or adding/removing principals into/from groups, automatically or according to the modeling decision the user chooses. Figure 5.4 illustrates the flow details. Three main dialog windows (DialogA, DialogB, DialogC) were designed to accomplish this flow. ^Wizardfor, Setting IntentipB. Intention of Access C o n t r o l -belected resource: lacalhost:8080/sl ideff i lesjuook1/Chapter 1.doc Please sex your intention: Principal: pis|r| i t 'Bsjp^|. |^|] href : /s l ide/users/ lest O Must Have ® Must Not Have Currently, /users/test has privi leges: [bind, read, read-current-user-prrvilege^set, unbind, writs-content] Currently, /users/test Is a member of: [/slide/roles/guest, /slide/roles/projector, /slide/roles/ProjectA] . PrMlege: inc ludes: all bind The current access contro l s ta tus : Check ACL User/Group Privileges all read-read-acl + • read-current-user -privilege-set write-write-acl write-properties write-content-' bind unbind unlock C /slide/users/Tux X y? n v * X fi /slide/users/test X y f X v * J X B /slide/users/|ohn (Yourself) y f / / I A, y f y f y? y f B /slide/users/root ./< K rante'dltbu itTsdrhe'of its' s'ub-pr Sieges are'denie 3 explicitly| y» y f y» S2S unauthenticated J' 4 v f J J y f y f JJB an others •4 X y f X X I Back Figure 5.5: A screenshot of DialogA obtaining the intention from the user and showing the current access control state DialogA (Figure 5.5) is split into two panes, upper and lower. The upper pane lets the 88 user specify his or her intention regarding who must/must not have what privilege. Once a principal is selected, the pane also shows the privileges that principal currently has, and the groups that principal is a member of. In addition, the lower pane in the dialog window shows the current access control status by listing the effective privileges for each principal. Such information helps the user to construct a clear and correct view of the system state. i Wizard for Setting Intention, Analyzing the Intention' Selected resource: localhost:8080/slide/fflesjbook1/Chapter1.doc Vour intention: [/usersitest) has no privilege [write content] conflicts with the following existing settings: Check Side Effects BE User/Oroup Grant/Deny Privileges Inherited From Set By Action You Can Choose /sllde/roles/ProjectA grant Remove this etttryfrom A - | Idelails... Change this entry from 'Brant' to 'deny Remove /users/test from group JslidefrolesiProjectA Please select the action which you want for each conflict from the column 'Action You Can Choose'. Note some actions will cause side effects. You can move the mouse on the column 'Side Effects' to see them. I do N.QT want any side effects Please press 'Next' button to continue... If you dont want to set this intention, please press 'Back' to change your intention, or 'Cancel'to quit the wizard without saving the intention. • Figure 5.6: A screenshot of DialogB showing the conflicts and modeling decisions The content of DialogB may change according to different branches in the program flow. When the system detects that the intention conflicts with existing effective A C E s (those not preceded by relevant A C E s ) , this dialog wi l l present all the conflicting A C E s to the 89 user with the information of who set those A C E s . If the user has the privilege to modify the A C L , it w i l l also provide possible solutions (modeling decisions) for the user to resolve the conflicts, as shown in Figure 5.6. O f course, some solutions may have side effects. The conflicting A C E wi l l be highlighted if the user chooses the solution that has side effects. B y default the system wi l l choose the solution without side effects. The user can always click the "I do N O T want any side effects" button to reset to the default solution. ^Wizard for; Setting Intention Analyzing the Intention Selected resource: localhost:8080/slide/files/projec1Data2.txt Your intention: [wsers/john2] has privilege [wntc-content] . conflicts with the following existing setluujs: 'US/slide/roles/user User/Oroup Grant/Deny . • Privileges •Inherited From [deny Unfortunately, you have no prrvilegesto modify the Access Control List (ACLi. But we find an alternative wayfor you: i You can add [/usersf)ohn2] to a group which has this privilege on the resource. However, this action will cause the side effects that |/usersi]ohii2] may get/lose the privileges that have been granted/denied to that group: Which action in the following list do you want to lake? Add/usersiIohn2togroup/slide/roles.iProiectA|».| r Check Side Effects \] ' " Do Nothing ' '" . . i it, r Add:/UsBrsj^ n2|ti>yg'i o'up Vsiidiil oles Pro)i'ctA l JVi |' ' I do NO I want any side effects j 1 ~~ Please press'Next'button to continue... If you d o n t want to set this intent ion, please p ress 'Back' to change your intention, or 'Cancel ' to quit the wizard without saving the intention. • Next I I teSi Cancel Figure 5.7: Another screenshot of DialogB showing the alternatives when the user has no privileges to modify the A C L If the user does not have the privilege to modify the A C L , the I A M system wi l l 90 automatically search for alternatives and present them in DialogB for the user to choose. Also , the user can check the side effects associated with each solution. This case is shown in Figure 5.7. DialogC is the final window showing the task result. If the intention cannot be fulfilled, it w i l l display error information and explanations. If the intention is successfully fulfilled, it w i l l list all the actions the system has taken, in order. ; Wizard for Setting Intention 're-operation Result Now we are coming to the final step.. Intention: [/rolesJProjectB] has no the privilege [write] is set successfully by performing the following actions: * Remove the ACE entry.' grant /slideftisersJJohn the privilege [write-acl]' • Add a new ACE entry:' deny ZroIesiProjectB the privilege [write)' If you want to set another intention on resource 1ocaihost:808Q/slideflles.iprojectData2.txt', please press 'Next'; To quit the intention setting wizard, please press 'Finish'. • Figure 5.8: A screenshot of DialogC showing the task result 5.3 Interface Design This I A M module can be seen as a combination of a reasoning engine and a G U I . To make the W e b D A V access control more usable for end-users, I introduced additional 91 features into the interface of the I A M module. These features are: 5.3.1 Security Context Displayed When Any Resource Selected .;#,•>• Intentional Access Management for, WebDAV File Edit Versioning Access Control View Help I S 1 1 1 1 H i l l f i i&Jaay 5$ Wir.ll |localhost:8080.<slide/ [ p i DAV Explorer f-E3 http://localhost:8080/slide «-f3 users o-[3 roles o- E3 actions ?-E3 files I | - E 3 b S k l ] I «-£3book2 o- £3 projector »• (3 histon/ o- O workspace °-[r3workingresource £3 C:t iLockiVersions! Name Display Cnapterl .doc • ; cnapterl -doc Type I Last Modifled Chapter2.doc C-hapter3.doc comrnents.txt Chapter2.doc Chapter3.doc comments.M ^appjc^ation/insworcr. applicatiorVmsword application/msword text/plain Tue Sep 27 09:45:22 PDT 2005 TueSep2? 10:41:08 PDT2005 Tue Sep 2712:51:11 PDT2005 Principal: uusers/test http:Mocalhost:8080/sliite.1iles*ook1Chapter1.doc Set Access Intention ' h a s p r iv i leges : [b ind, r e a d , r e a d - c u r r e n t - u s B r - p r i v l l e g e - s e i , u n b i n d , wr l te -cor t ten t l Figure 5.9: A screenshot of the interface showing the security context Here the security context refers to the current effective privileges each principal has on that resource. As shown in Figure 5.9, the security context pane is located at the bottom of the main window of D A V Explorer. The pane displays in real time all the privileges the specified principal has on the selected resource, if the current user has the privilege to view such information (in Slide, the user should have the read-acl privilege to read the A C L , but knowing his or her own privileges only requires the user to have the read-current-user-privilege-set privilege). The user can choose which principal to see from a combo box. In this way, the user can easily know what privileges a principal has so that 92 he or she can decide whether to launch the I A M or the Add/Modify A C L module to grant/deny some privileges to that principal. This pane can be turned on/off at any time. 5.3.2 Needed Information Shown to the User When His Setting Intention A s indicated above, DialogA (Figure 5.5) shows the privileges and group information of the specified principal in the upper pane. The lower pane has a table listing all the principals with their effective privileges. In addition, tool tips are extensively used to present explanations when the mouse pauses over preset components. For example, when the mouse pauses over the table's header, the description of the privilege the mouse points to comes up. The table's header also presents the hierarchy of the privileges. These features help the user understand the privileges and their relationships. Icons with different colours, together with the tool tips, are used in the table to illustrate the status of each privilege (e.g., "explicit denied, but some of its sub-privileges are granted explicitly"). 5.3.3 User Notified Only When Necessary If the user's intention does not conflict with any existing settings, it w i l l be fulfilled automatically without intervention from the user. When there are conflicts, the system wi l l provide information about the conflicting A C E s and who set them (retrieved from a M y S Q L database that stores information about the author of every A C E ) in DialogB (Figure 5.6). Possible solutions (modeling decisions) are presented to the user for his or her selection. If a solution the user chooses has side effects, the conflicting A C E wi l l be highlighted. The user can click to see the details of 93 the side effects. 5.3.4 Side Effects Shown to the User The user can choose to see the side effects caused by the selected solution, as shown in Figure 5.10. However, as discussed in the next chapter, how to present the side effects to the end-user in an easy-to-understand way is a challenging problem. f . View Side Effects Checked resource: localhost:8080/slide.<files*ook1/Chapter1.doc four intention: [/Users/test] has no privilege [write-contervt] on resource localhost:808G7slideffiles/book 1 Chapter 1 .doc Current action: remove the user [ftisersrtest] from group [/slide/rolesjProjectA] The side effects are: User/Group Has Privileges G /slide/users/test original bind, read, read-current-user-privilege-set, unbind, write-content after read, read-current-user-privilege-set ... III.-N.B.: In the above table, the privileges that the specified principal will lose are shown in blue, and the new privileges that the specified principal will get are shown in red. Close Figure 5.10: A screenshot of the interface showing side effects 5.3.5 User Cannot Lock Him- or Herself Out of Own Folder and File In Slide, the owner does not have special privileges like in the Windows NTFS system. It 94 Change Resource is possible that the owner is denied all access to the resource or denied privileges to modify the A C L , if an A C E that denies such privileges to a group of which the owner is a member is added to the A C L . To avoid this situation, the principal name in the conflicting A C E is highlighted i f the principal is the current user. The system wi l l warn the user when the specified actions wi l l change the user's own privileges. This design reduces the possibility of the owner locking him- or herself out of his or her own folder and file. The interface is shown in Figure 5.11. Analyzing the Intention A , T~" M .1, "1 \ i Selected resource: localhost:8080jslidetfi lesipru]ectData1.txt Your intention: [frolesiProjectB] has no privilege [wr i te ] conf l icts with the fol lowing exist ing sett ings: Shock Side Effects User/Group Grant/Denv Privileges Inherited From ' Set BY Action You Can Choose Side Effects S2s /slide/roles/ProjectA grant write-content root Do nothing no G isiide/usersljohn (Yourself)," (. j • . . g ran t . writeracl •". " " .•• slfoot - n" " Do n o t h i n g ' , . " n o , • " '. W a r n i n g . . . . . . , , „ • '^:fi - ; \ , , ,• , i . ; . ' '.. •• - • . • - . f l The act ion: Add a new ACE ent ry : ' deny /roles/ProjectB the privilege [ w r i t e ] ' can change your own privileges. Do you really want to per form th is act ion? Yes No] Check Side-effects Please select the Uio JHOT want any side ef fects Please press 'Next' button to continue.. rf you don't want to set th is intention, please press 'Back' to change your intention, or 'Cancel ' to quit the wizard without saving the intention. Figure 5.11: A screenshot of the interface showing a warning when the action wi l l cause the user's own privileges to be changed 95 5.4 Discussion This I A M prototype is a preliminary implementation of the new conceptual designs proposed in Chapter 4. Some of its limitations are discussed here. The current I A M wizard was implemented on the client side. This means that what the I A M wizard can do with the server is limited by the privileges the user using the client has on that server. For example, if the user does not have the privilege to read the A C L , the I A M wizard has no way of fulfilling his or her intention because it cannot check the system state by retrieving and interpreting the A C L . Also if the user does not have the privilege to read the membership or permissions of a group, the I A M wizard may not be able to find alternative ways of fulfilling the user's intention. Although this implementation provides limited functionality to the user, it can be regarded as an advantage since it removes the potential that the user may obtain some information he or she is not allowed to see by using this system. On the other hand, if the I A M support is installed on the server side with full privileges, it w i l l have more power for checking the system state, reasoning, and answering queries such as "who can grant me access" discussed in Section 3.3.1, whether the user has the privilege to read the A C L or not. However, this feature may also increase the potential security risk if the user can exploit it to obtain some information he or she is not permitted to know. In the current implementation, I adopted the M y S Q L database to store information about who set which A C E at what time. When there are conflicts between the intention and the effective A C E s , the I A M system can show conflicting A C E s and who set them. However, 96 in the I A M system, the user's concern is the conflicts between intentions. Therefore, a system that can store the history of intentions in the database and check for intention conflicts would be desirable. It is also the requirement of the full I A M model. There are some issues concerning the generalization of the I A M model. The I A M system only supports basic intentions. Users cannot specify an intention involving multiple principals and/or multiple privileges. For example, the principal in the user's intention may be "al l users in group Y except user X " . The system also does not support high-level privileges discussed in Section 3.3.2. Interpreting such intentions may involve advanced intention modeling. 5.5 Summary This chapter describes the implementation of an access management prototype system for W e b D A V . The system is based on the I A M Wizard model and the intentional analysis presented in Chapter 3. Although it provides limited functionality to users as discussed above, it is a good starting point for demonstrating the usability improvement brought by the proposed I A M models. 97 Chapter 6 User Study Research has shown that what engineers expect to work and what users actually make to work are two different things [89]. Therefore, to evaluate the usability of the proposed I A M system, a carefully designed laboratory user study3 was conducted. Two modules for managing W e b D A V access control were compared: the simple A C L editor like module in the original D A V Explorer (referred to as A C L Editor in the study, whose interfaces are shown in Figure 5.2 and Figure 5.3), and the I A M wizard, a new module for managing access, implemented based on the I A M models. The current user study is preliminary. I do not claim that the I A M is the best approach to making access control usable for end-users. The goal of this study is to demonstrate that the proposed design is feasible and usable for end-users while it doesn't upset user expectations or cause confusion. In other words, the study was designed to expose failures in the conceptual model of the user interaction rather than to test specific claims of its efficiency. 3 This study has been reviewed and approved by the Behavioural Research Ethics Board (file number B05-0922). See Appendix 1 for the Certificate of Approval. 98 6.1 Study Design 6.1.1 Participants Table 6.1: Description of participants' backgrounds Specialty Frequency of using computers Frequency of setting file permissions Familiarity with A C L and its evaluation ParticipantA Business Daily A few times a month or less Don't know at all Participant!? Business Daily A few times a month or less Know a little ParticipantC Arts A few times a week Never Don't know at all ParticipantD Arts A few times a week Never Don't know at all ParticipantE Engineering Daily A few times a month or less Know a little ParticipantF Engineering Daily A few times a month or less Know a little ParticipantG Engineering Daily A few times a month or less Know a little ParticipantH Engineering Daily A few times a month or less Average ParticipantI Computer Science Daily A few times a month or less Know a little ParticipantF Computer Science Daily A few times a week Average Ten people participated in the study. Participants were recruited randomly and had various backgrounds from business to engineering. Table 6.1 shows the details of each participant's background. A l l used computers at least a few times a week. Eight reported having some experience setting file permissions on Windows or another operating system, while two reported having no experience setting file permissions whatsoever. Two reported they were averagely familiar with the A C L and how it is evaluated prior to 99 the study, and five reported knowing a little about the A C L , while three did not know the A C L at all. None knew how A C L s were implemented in W e b D A V before the study. 6.1.2 Task Descriptions To simulate real access management conditions, a hypothetical scenario was designed in which the participants at different sites collaborated to jointly author documents which were stored on a W e b D A V server, and had to restrict access to these shared files. The hypothetical collaborative environment was created and populated with individual users, groups, files, and folders on the W e b D A V server. The environment included 8 individual users, plus one user named John who represented the participant her/himself. The environment also includes 7 groups. No group contained another group as a member. [DAV:, a l l ] (aggregate) I +-- [DAV:, read] (aggregate) +-- [DAV:, read-acl] +-- [DAV:, read-current-user-privilege-set] I +-- [DAV:, write] (aggregate) I +-- [DAV:, write-acl] +-- [DAV:, write-properties] +-- [DAV:, write-content] (aggregate) +-- [DAV:, bind] +-- [DAV:, unbind] I +-- [DAV:, unlock] Figure 6.1: A tree of supported privileges in the Slide server The W e b D A V server was implemented by Apache Slide. Figure 6.1 illustrates the privilege hierarchy implemented in the Slide server. Participants were asked to perform access management tasks involving these privileges. 100 Two sets of tasks were given to each participant. These two sets were identical except that they targeted different resources. Each set of tasks included one training task which gave participants experience with the module used, and four other tasks (Taskl , Task2, Task3, and Task4). A detailed description of the tasks is presented in the appendices. The task statements for the five tasks in one set are shown below: Y o u (user name )ohn, password John) are co-authoring a book named " b o o k l " with some collaborators. The chapters of this book are stored in /files/bookl/ on the W e b D A V server. Training Task: Jack (username: users/Jack) is an independent reviewer, and you want him make some comments on this book. Please make sure that Jack can read and change the content of the file files/bookl/comments.txt. Task 1: Test (username: users/test) is your co-author for Chapter 1 (files/bookl/Chapterl.doc). Please make sure that Test can read and change the content of files/bookl/Chapterl.doc. Task 2: Because of personal reasons, now Test (username: users/test) has no time to continue working on Chapter 1. Please make sure that effective now, Test can read files/bookl/Chapterl.doc, but cannot change its content. Task 3: Please make sure that the user Projector (username: users/projector) can read files/bookl/Chapter2.doc, but cannot change its content. Task4: John2 (username: users/john2) becomes your co-author for Chapter 3 101 (files/bookl/Chapter3.doc). Please make sure that effective now, John2 can read and change the content of files/bookl/Chapter3.doc. The tasks in the other set were identical except " b o o k l " was changed to "book2". The training task simply required the participant to add an A C E granting users/Jack the privilege write-content, since all users had had the privilege to read the file. Task l was introduced to check if the participant could determine that the task requirements were already fulfilled and no action was needed. The task statement for Task2 was identical to that for Task3 except for the names of specific files and users. However, the tasks differed in the way they were initialized. In both of these tasks, there was one group that was already on the A C L for the file, and the target user was a member of that group. However, in Task2, users/test had only inherited the write-content (the privilege to change file content) privilege from group ProjectA, while in Task3, user/projector had inherited the write privilege from group ProjectB which contained both write-content and write-acl (the privilege to modify the A C L ) privileges. The simple solution to Task2 was to add an A C E denying users/test the write-content privilege (the privilege to change file content); he already had the privilege to read the file content. However, this simple solution could not work for Task3, since user/projector had inherited the write-acl privilege from group ProjectB. If user/projector was denied the write-content privilege, but not explicitly denied the write-acl privilege, he would have been able to restore his write-content privilege. The task statement presented to 102 users did not mention this nuance; it was left to users to decide that user/projector's write-acl privilege had to be removed. Note that Task2 and Task3 are similar to the Wesley and Jack tasks in Maxion and Reeder's study [53] on the Windows X P File Permissions interface and their Salmon interface. The purpose of Task4 was to check i f participants could find an alternative way to grant privileges (adding user users/john2 to group roles/ProjectC) when they did not have the privilege to modify the A C L . In order to collect their feedback on the I A M wizard, a short interview with each participant was performed after the participant finished all the tasks. 6.1.3 Procedure Participants were asked to use the A C L Editor to fulfill one of the two sets of access management tasks and use the I A M wizard to fulfill the other set of tasks. For T a s k l , Task2, and Task3, eight used the A C L Editor first, and then the I A M wizard, and two used them in the reversed order. For Task4, they all used the A C L Editor first, and then the I A M wizard. Before participants used the A C L Editor to fulfill tasks, they were required to learn how the A C L is evaluated. Participants were told that they could "think aloud" throughout the course of the experiment. Participants were shown how to view W e b D A V system users, groups, group memberships, and the owner of a resource. After each task was completed, participants were asked to rate their confidence on a 1-7 scale (7: very confident) that the task had been completed correctly. 103 6.1.4 Rules for Determining Task Success or Failure To determine task success or failure, participants' final A C L settings were examined. For Task l and Task 4, a task instance was deemed successful if the target user (users/test or users/johnl) had effective privileges allowing him read (with the read-acl privilege denied or not) and write-content privileges. The Task l or Task 4 instance was deemed a failure i f the target user had effective privileges denying him read or write-content privilege. For Task2 and Task3, a task instance was deemed successfully if the target user (users/test or users/projector) had effective privileges allowing him read privilege (with the read-acl privilege denied or not) and denying him write-content and write-acl privileges. The Task2 or Task 3 instance was deemed a failure i f the target user had effective privileges allowing him write-content and/or write-acl privileges, or denying read privilege. 6.2 Results This section presents the results of the study, including speed, accuracy, user confidence and satisfaction for each of the two modules under scrutiny. The results show that the I A M wizard performed better than the A C L Editor did. 6.2.1 Speed For accomplishing the tasks by using the A C L Editor, all participants had to first learn the A C L and how it is evaluated. The average time for them to understand the A C L evaluation is about 8 minutes. On the contrary, the two participants who fulfilled the 104 tasks by using the I A M wizard first spent no time learning the A C L evaluation before the tasks but still got 100% accurate task completion. Taskl Task2 Task3 Task4 • All ACL Editor users • All IAM users • Successful ACL Editor users only • Successful IAM users only Figure 6.2: Average time to complete T a s k l , Task2, Task3, and Task4. Figure 6.2 illustrates the average task completion times for each of the two modules and four tasks. The solid bars show times for all participants, whether they succeeded or failed in the task; the striped bars show times only for participants who completed the tasks accurately. For using the I A M wizard, since all tasks were successful, the average times for all and for successful participants were the same for each task. Note that the difference between Task4's average completion times for all participants and only successful participants using the A C L Editor is large. For this task, 9 of 10 participants using the A C L Editor thought they could not complete the task and gave up while one went on to check the Group Manager. These results show that those completed the tasks successfully took less time using the 105 I A M wizard than using the A C L Editor. For Task2 and Task3, the difference between times for the two modules is not statistically significant (one-sided Welch's r-test for Task2: t = 0.3511, df = 7, p = 0.3679; for Task3: t = 1.6482, df = 2, p = 0.1205). However, for Task l , successful users using the I A M wizard spent, on average, significantly less time than the successful users using the A C L Editor did. A one-sided Welch's Mest showed this difference to be statistically significant at the 0.05 level (t = 3.3789, df = 18, p =0.0017). This is because many users using the A C L Editor still added new A C E s into the A C L although the task requirements had already been fulfilled, while the I A M wizard directly told them the fact and then no action was needed. For Task4, the time difference is also significant. The only one who successfully completed this task using the A C L Editor took 187 seconds (he first used the A C L Editor and then the Group Manager), while the users using the I A M wizard took less time (Mean = 91.6, Standard Deviation = 31.3). 6.2.2 Accuracy Table 6.2 shows the percentages of participants who successfully (accurately) completed the tasks by using the A C L Editor and the I A M wizard. The I A M wizard outperformed the A C L Editor on all tasks. Especially, for Task4, using the A C L Editor, only 1 participant who remembered his prior experience of adding users to a group to get privileges completed the task successfully, while all participants completed the task successfully by using the I A M wizard. 106 Table 6.2: Percent of accurate completions for the four tasks by using the A C L Editor and the I A M wizard Using A C L Editor (%) Using I A M wizard (%) Task l 100 100 Task2 70 100 Task3 30 100 Task4 10 100 Note that by using the I A M wizard, more users correctly completed the tasks while taking less time on average, suggesting that I A M ' s accuracy gains were not due simply to a speed-accuracy tradeoff. A s indicated above, Task2 and Task3 are similar to the Wesley and Jack tasks in Maxion and Reeder's study [53]. In that study, their proposed Salmon interface which only provided needed information to the user for setting file permissions recorded 83% and 100% accurate task completions for the Jack and Wesley tasks, respectively. The I A M wizard with both 100% accurate task completions demonstrates superior performance. Actually, these results are natural and predictable, because the I A M is designed to directly accommodate user goals. It eliminates human errors in the goal implementation. In such a system, the only source of error is in expressing the intention/goal. For example, it is possible that the representation of some complex intentions in the system does not match the user's mental model, and this may lead to confusion and failure to express such intentions to the system. Therefore we need to study the users' real security intentions and represent them more accurately in the system. One doctoral student in my 107 group is working on modeling user privacy needs for information sharing. Her work should be useful for extending the current system to support more user intentions accurately. 6.2.3 User Confidence and Satisfaction The participants were asked to state their confidence in their work. O f course, they gave the highest confidence rating (i.e., 7) to all tasks when using the I A M wizard, because the system accomplished most work for them, and provided enough feedback so that they can check the results in the end. When using the A C L Editor, as shown in Table 6.3, their confidence was lower. Table 6.3: Average confidence ratings for the four tasks by using the A C L Editor and the I A M wizard Using A C L Editor (Mean, Standard Deviation) Using I A M wizard Task l 6.9, 0.3 7 ,0 Task2 6.4, 0.7 7 ,0 Task3 6.3,0.8 7 ,0 Task4 1.6, 1.8 7 ,0 Note the mismatch between the high confidence and poor performance on Task 2 and Task 3 when using the A C L Editor. This is a recipe for security failures and frustration. Users think that they have correctly configured the security system to protect their resources, but they are mistaken. Moreover, it is unlikely that this mistake would be noticed until a security breach demonstrates that the system is misconfigured (assuming 108 that they are made aware of the breach). Since the I A M design addresses both the gulf of execution and the gulf of evaluation, the user's confidence is a good match to goal success even though the system hides many of the details of the mechanism. In essence, because the system is careful to show the user the effects of their actions, the "magical" connection between the intention and the mechanism seems natural and predictable. In the interview, all participants expressed their preference of the I A M wizard over the A C L Editor. Most of them explicitly indicated that this level of expressing goals seemed natural to them, and the hiding of the internal security mechanism (i.e., the A C L ) did not confuse them, or upset their expectations. The most common feedback was that the new module was straightforward for accomplishing the tasks. For example, ParticipantC said, " A C L looks like an alien to me and I have no interest in learning it. If I have to control access to my files, of course I want to choose I A M - l i k e tools. I really hope that the whole computer system can be designed in this way so that I can use it easily." 6.3 Discussion Let us consider the five quantities for measuring usability listed in Chapter 1. From the results shown above, we can conclude that the I A M wizard is more usable than the A C L Editor from all aspects of ease of learning, efficiency of use, error frequency and severity, and subjective satisfaction. Memorability has not been studied. One possible way to explore it is to ask the participants to return after 2-3 months for retesting. It may be irrelevant, however, because of the lack of learning curve for the I A M wizard. 109 In the study, it was observed that when using the A C L Editor, participants tended to add new A C E s for accomplishing the privilege-setting tasks. Simply adding an A C E without checking existing A C E s may introduce redundancy. For example, even though the requirements for Task l were already fulfilled, 6 participants still added an A C E granting users/test the read privilege, and 4 participants also added an A C E granting users/test the write-content privilege. When they were asked to deny users/test the privilege to change the file's content in Task2, 2 of these 4 simply removed the new added A C E granting users/test the write-content privilege and thought the task was completed, which was in fact not true. In addition, this observation supports the claim that non-expert end-users often confuse their intentions with the actual A C E s (ignoring the rest of the A C L context) so that they read A C E s as intentions and assume that adding an A C E is the same as fulfilling an intention. This misunderstanding seems to be a primary source of error in using this traditional interface, and the I A M has eliminated this possibility. 110 = i View Side Effects Checked resource: Iocalhost:8080/slide.iflles/rfc2518.pdf Vour intention: [/users/test] has ho privilege [write-content] on resource Iocalhost:8u80/slide/files«c2518.pdf Current action: remove the ACE entry' grant /slide/users/test the privilege [write]' from the ACL Pi The aggregate side effects are: User/Group .. Has Privileges 12 /slide/usersrtest oriqinal bind, read, read*current-user-privilege-set, unbind, write, write-acl, wr before bind, read, read-current-user-privilege-set, unbind, write, write-acl, wr after read, read-current-user-privilege-set If no other actions which will also cause side effects are performed, the side effects are: User/Group !• '. " ' Has Privileqes "E /slide/users/test original bind, read, read-current-user-privilege-set, unbind, write, write-acl, wr after bind, read, read-current-user-privilege-set, unbind, write-content N.B.: In the above table, the privileges that the specified principal will lose are shown in blue, and the new privileges that the specified principal will get are shown in red. | Close | Figure 6.3: A screenshot of the interface showing the side-effects that caused by multiple actions Some design principles for usability emphasize the importance of giving feedback to the user. For example, the principle of Clarity from Yee [90] states that the effect of any security-relevant action must be clearly apparent to the user before the action is taken. However, there remains a challenge in balancing the need to show details against simplicity which may involve hiding details. Too many or too few details may make it hard for users to understand, or even confuse them. For example, in the test 80% of participants expressed that they had difficulty interpreting the side effects as shown in Figure 6.3, though they admitted that they did want to know such information. In addition, they also indicated that most of the difficulties came from the privilege hierarchy. One possible approach to improving the understandability may be to show in some way the semantic meaning of every privilege and their relationships instead of just showing the privileges implemented in the system. I l l 6.4 Summary In this chapter, the results of a user study comparing the I A M wizard and the simple A C L Editor are presented. Although this study is simple, it does yield evidence for the usability advantages of the proposed I A M model. The improvements in successful task completion, the reduction in time to task completion, better correlation of confidence to actual success, and the increase in user satisfaction were due primarily to the isolation of users from the internal security mechanisms and the direct support of users' intentions. Simply, the study indicates the feasibility and usability of the I A M design, and demonstrates that this design doesn't upset user expectations or cause confusion. 112 Chapter 7 Conclusion The following sections present the conclusions of the research conducted in this thesis, and propose future research topics and directions that have to be further studied to enrich the access management for information sharing. 7.1 Summary of Research Hassell and Wiedenbeck [36] argued for the assumption that "changing the way people conceptualize information systems security wi l l change the way people act. In turn, this wi l l create a culture of security." This thesis advocates such conceptual changes for making security usable for end-users. I reject the claim (more often implicit than explicit) that security interfaces must force end-users to understand and directly manipulate the internal security mechanisms. Instead, I propose that these systems should be able to accommodate their users' task-oriented goals and translate these intentions into implementations automatically or semi-automatically. For access control systems, this 113 can be achieved by separating access management from access control and enhancing the access management based on users' intentions as I proposed in this thesis. A n access management system wi l l interpret users' intentions, formulate the access control rules for fulfilling those intentions, and provide users with enough feedback, while leaving the access control mechanism intact. In this way, end-users can be isolated from access control mechanisms and concentrate instead on effects (e.g., effective permissions). The security control interfaces wi l l thus be a kind of support system serving to resolve their security goals. This conceptual design came from a thorough algorithmic analysis of the decision processes that users have to perform to determine how to implement their security intentions in current access control systems. The W e b D A V access control was chosen because of its potential to facilitate information sharing and its similarity to the Windows N T F S access control (which is the most widely used A C L system). This analysis revealed that even for this simple system the conceptual complexity of managing access is too high for end-users compared with their low interest and limited technical capacity for such tasks. In analyzing users' run-time intentions, some issues such as side effects, conflicts, and modeling decisions were identified and discussed in detail. Based on this analysis, a set of design principles and three levels of intentional access management system model (wizard, full, and multi-backend) were proposed. These levels of model convey the concept of separation of access management and access control. 114 Although it remains a challenge to develop implementations for all current access control systems based on this model, a positive demonstration has been presented. A real system, an access management system for W e b D A V , has been implemented to embody such I A M levels and principles. Integrated with other new interface features, in a user study, this system yielded a considerable improvement of usability in terms of speed, accuracy, and user satisfaction compared with a traditional A C L editor. In conclusion, I have proposed a conceptual model for usable access control and developed an access management prototype system for W e b D A V based on this model. The work in this thesis has shown promising results and excellent potential to allow flexible, safe end-user oriented control of system security and privacy. 7.2 Further Directions As I discussed in Chapter 1, security is usually a secondary goal for end-users. In an information management environment, an end-user focuses on the sharing of information rather than access control and its implementation. Integrating this concern with the current analysis, it is possible to further design a security management system model for end-user controlled information sharing. In Table 7.1, I compare this with the traditional model. Instead of explicitly identifying the resources to protect and making the enforcement statements by him- or herself, the user can identify and express his intentions to share or make private. The system determines possible enforcement statements to fulfill these intentions. Then there may be two choices for the system. One 115 is that it selects the enforcement automatically and informs the user (or not). Here, Surprise-Explain-Reward strategy [88] can be adopted. Another choice is that the system presents these enforcement possibilities with consequences to the user and requests a decision from the user (the strategy we have initially taken with the I A M wizard). Table 7.1: Comparison of the two security management models Existing Model Alternative Model Resources T Resources T Security E n f o r c e m e n t System Security E n f o r c e m e n t Sys tem Security Tools Sharing Tools The user identifies resources - The user identifies an intention to share resources with others or restrict sharing - The user makes a statement guiding security enforcement of resources - The system determines possible enforcement statements to fulfill the intention. The system enforces - The system automatically chooses the enforcement and informs (or not) the user by Surprise-Explain-Reward [88]. O R - The system presents alternative enforcement possibilities with consequences to the user and requests a decision. B y using a system implementing this model, users need not think about security, but only about their needs for sharing or privacy. This should clearly facilitate collaboration 116 among users. In such systems as well as the I A M systems proposed above, some advanced techniques for interpreting users' intention are desired. Although simple intentions like those discussed in Chapter 3 are easy to support, capturing and interpreting a user's complex intentions remains a challenge. Two issues need further research. One is to develop a mechanism that lets the user express his or her intentions in a natural but formal way to the system. Another is to design algorithms to translate the formal intentions to the enforcement rules accepted by other backend access control systems. I suggest that the initial step wi l l be to investigate users' behavior in collaborative work and model their goals or intentions. To improve the current I A M implementation, some issues may be considered, as briefly discussed below. Users often have intentions which must be translated into multiple privileges used in the system, while they often lack the capacity to do such translations easily. Also it has been observed that users often feel confused about the privileges and their relationships in the system (e.g., the privilege hierarchy). Better presentation of privileges in task-oriented terms and an interface that associates each privilege with its semantic meaning could improve the understandability of the access control system to end-users. Detecting and resolving conflicts between users' intentions is clearly important yet difficult to manage in a collaborative environment. The server-side implementation with database support (as opposed to the wizard approach examined here) is necessary but 117 insufficient to achieve this. It can facilitate tracking intentions; however, we still need a mechanism to compare intentions to detect conflicts and then manage the user-to-user interaction necessary to resolve these conflicts. A t this point, some of the work on policy management systems may help [52] [38]. The current implementation is based on the I A M wizard model. To demonstrate the high potential of I A M for usable access control, the full I A M and multi-backend I A M models need to be developed. In addition to the resolution of conflicts, and the presentation and exploration of side effects, such future I A M systems should support interactions with multiple systems and with system administrative actions. 118 Bibliography [1] Adams, A . and Sasse, M . A . Users are not the enemy: why users compromise security mechanisms and how to take remedial measures. Comm. ACM, vol . 42, no. 12, 1999, 41-46. [2] Balfanz, D . Usable access control for the World Wide Web. In Proceedings of the 19th Annual Computer Security Applications Conference. I E E E Computer Society, Los Alamitos, C A , 08-12 December 2003, 406-415 [3] Balfanz, D . , Durfee, G . , Smetters, D . K . , and Grinter, R . E . In search of usable security: five lessons from the field. IEEE Security & Privacy Magazine, vol . 2, no. 5, 2004, 19-24. [4] Berkun, S. Why I switched to Firefox. Berkun's Blog, September 12, 2005. http: //www. scottberkun. com/blo g/? p= 115 [5] Besnard, D . and Arief, B . Computer security impaired by legitimate users. Computers & Security, vol. 23, no. 3, 2004, 253-264. [6] Bishop, M . U N I X security: threats and solutions. Presentation to S H A R E 86.0, Anaheim, C A , March 1996. http://seclab.cs.ucdavis.edu/proiects/vulnerabilities/scriv/1996-share86.pdf [7] Blakley, B . , Heath, C , and members of the Open Group Security Forum. Security design patterns. Technical Report G031, The Open Group, Apr i l 2004. http://www.opengroup.org/publications/catalog/g031 .htm. [8] Brostoff A . Improving password system effectiveness. Ph.D. Dissertation. University College London, 2004. [9] Brostoff, S. and Sasse, M A . Safe and sound: a safety-critical design approach to security. In Proceedings of the A C M New Security Paradigms Workshop, New Mexico, September 10-13, 2001, 41-50. [10] Card, S.K., Moran, T.P., and Newell , A . The Psychology of Human-Computer Interaction. Lawrence Erlbaum, Hillsdale, N.J . , 1983. 119 [11] Clemrn, G . , Reschke, J., Sedlar, E . , and Whitehead, J. Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol. R F C 3744. May 2004. http://www.ietf.org/rfc/rfc3744.txt. [12] Costantine, L . L . and Lockwood, L . A . D . Software For Use - A Practical Guide to the Models and Methods of Usage-Centered Design. Reading M A : Addison-Wesley, 1999. [13] C R A Conference on "Grand Research Challenges in Information Security and Assurance". November 16-19, 2003. http://www.cra.org/Activities/grand.challenges/security/. [14] D A V Explorer, http ://www. ics.uci.edu/~webdav/ [15] Davidson, M . J . , Dove, L . , and Weltz, J. Mental models and usability. Depaul University, Cognitive Psychology 404, November 15, 1999. http://www.lauradove.info/reports/mental%20models.htm [16] DiGio ia , P. and Dourish, P. Social navigation as a model for usable security. In Proceedings of the 2005 Symposium on Usable Privacy and Security, Pittsburgh, Pennsylvania, July 06 - 08, 2005, 101-108. [17] de Paula, R., Ding, X . , Dourish, P., Nies, K . , Pillet, B . , Redmiles, D.F . , Ren, J., Rode, J .A. , and Filho, R.S. In the eye of the beholder: A visualization-based approach to information system security. International Journal of Human-Computer Studies, vol . 63, 2005, 5-24. [18] de Paula, R., Ding, X . , Dourish, P., Nies, K . , Pillet, B . , Redmiles, D.F. , Ren, J., Rode, J .A., and Filho, R.S. Two experiences designing for effective security. In Proceedings of the 2005 Symposium on Usable Privacy and Security, Pittsburgh, Pennsylvania, July 06 - 08, 2005, 25-34. [19] Dewan, P. and Shen, H . Controlling access in multiuser interfaces. ACM Transactions on Computer-Human Interaction, vol. 5, no. 1, 1998, 34-62. [20] Dewan, P. and Shen, H . Flexible meta access-control for collaborative applications. In Proceedings of the ACM Conference on Computer-Supported Cooperative Work, 1998, 247-256. [21] Dix , A . , Finlay, J., Abowd, G . , and Beale, R. Human-Computer Interaction. Herfordshire U K : Prentice Hal l Europe, 1998 [22] Dourish, P., Grinter, R., Delgado de la Flor, J., and Joseph, M . Security in the wild: user strategies for managing security as an everyday, practical problem. Personal and Ubiquitous Computing, vol. 8, no. 6, 2004, 391-401. [23] Dourish, P., de la Flor, J.D., and Joseph, M . Security as a practical problem: some preliminary observations of everyday mental models. Presented at the C H I 2003 120 Workshop on Human-Computer Interaction and Security Systems, Ft. Lauderdale, Apr i l 2003. [24] Dourish, P. and Redmiles, D. A n approach to usable security based on event monitoring and visualization. In Proceedings of the ACM New Security Paradigms Workshop, Virginia Beach, V A , 2002, 75-81. [25] Dussault, L . W e b D A V benefits for the enterprise and its denizens. DM Direct Newsletter, Dmreview.com, June 27, 2003. http://www.dmreview.com/article sub.cfm?articleID=6971. [26] Edwards, W . K . , Grinter, R . E . At home with ubiquitous computing: seven challenges. In Proceedings of the International Conference on Ubiquitous Computing (UBICOMP 2001), Atlanta, G A , September 30-October 2, 2001. Berlin: Springer Verlag, L N C S 2201, 256-272. [27] Edwards, W . K . , Newman, M . W . , Sedivy, J.Z., Smith, T.F. , Balfanz, D . , Smetters, D . K . , Wong, H .C. , and Izadi, S. Using speakeasy for ad hoc peer-to-peer collaboration. In Proceedings of the ACM Conference on Computer Supported Cooperative Work, 2002, 256-265. [28] Foster, I. and Kesselman, C. (eds.) The Grid: Blueprint for a New Computing Infrastructure. Morgan Kaufmann, 1999. [29] Garfinkel, S.L. Design principles and patterns for computer systems that are simultaneously secure and usable. Ph.D. Dissertation, Massachusetts Institute of Technology, 2005. [30] Gates, C. and Slonim, J. Owner-controlled information. In Proceedings of the ACM New Security Paradigms Workshop, Ascona, Switzerland, August 18-21, 2003, 103-111. [31] Goland, Y . , Whitehead, E . , Faizi , A . , Carter, S.R., and Jensen, D . HTTP Extensions for Distributed Authoring - WEBDAV. R F C 2518. Feb. 1999. http://www.ietf.org/rfc/rfc2518.txt. [32] Good, N .S . and Krekelberg, A . Usability and privacy: a study of Kazaa P2P file-sharing. In Proceedings of the ACM Conference on Human Factors in Computing Systems (CHI 2003), Ft. Lauderdale, Florida, Apr i l 5-10, 2003, 137-144. [33] Greenberg, S. and Marwood, D . Real time groupware as a distributed system: concurrency control and its effect on the interface. In Proceedings of the ACM Conference on Computer Supported Cooperative Work, A C M Press, Chapel H i l l , N C , 1994, 207-217. [34] Grinter, R . E . and Smetters, D . K . Three challenges for embedding security into applications. Presented at the Workshop on Human-Computer Interaction and 121 Security Systems, part of A C M Conference on Human Factors in Computing Systems (CHI 2003), Fort Lauderdale, Florida. [35] GroupDrive Collaboration Suite, South River Technologies. http://www.southrivertech.com/index.php?pg=./products/groupdrive/index# [36] Hassell, L . , and Wiedenbeck, S. Human factors and information security. Draft, 2004. http://clam.rutgers.edu/~birget/grPssw/hasselSue.pdf [37] Holmstrom, U . User-centered design of security software, In Proceedings of the 17th Symposium on Human factors in Telecommunications, Copenhagen, Denmark, M a y 1999. [38] Jaeger, T., Zhang, X . , and Edwards, A . Policy management using Access control spaces. ACM Transactions on Information and System Security, vol. 6, no. 3, August 2003, 327-364. [39] Jakarta Slide project, http://jakarta.apache.org/slide/ [40] Jendricke, U . and torn Markotten, D . G . Usability meets security - the identity-manager as your personal security assistant for the internet. In Proceedings of the 16th Annual Computer Security Applications Conference, 2000, 344-353. [41] Jendrock, E . , Bodoff, S., Green, D. , Haase, K . , Pawlan, M . , and Stearns, B . The J2EE Tutorial, I S B N 0-201-79168-4, Addison Wesley, 2002. [42] John, B . E . and Kieras, D .E . Using G O M S for user interface design and evaluation: Which technique? ACM Transactions on Computer-Human Interaction, vol . 3, no. 4, Dec. 1996, 287-319. [43] Kapadia, A . , Sampemane, G. , and Campbell, R. Know why your access was denied: regulating feedback for usable security. In Proceedings of the 11th ACM conference on Computers and Communications Security (CCS), Washington D C , Oct 25-29 2004. [44] Kazaa. http://www.kazaa.com/ [45] Kieras, D . E . Guide to G O M S model usability evaluation using N G O M S L . In The Handbook of Human-Computer Interaction, M . Helander and T. Landauer Eds. 2nd ed. North-Holland, Amsterdam, 1996. [46] Kirwan, B . A Guide to Practical Human Reliability Assessment. Taylor and Francis, London, U K , 1994. [47] Kirwan, B . and Ainsworth, L . K . (Eds.) A Guide to Task Analysis. Taylor and Francis, London, U K , 1992. 122 [48] Lampson, B . Protection. In Proceedings of the Fifth Princeton Symposium on Information Sciences and Systems, Princeton University, March 1971, 437-443. [49] Landwehr, C. Protection (security) models and policy. The Computer Science and Engineering Handbook, Tucker, A . B . (editor), C R C Press, 1997, 1914-1928. [50] Levine, A . , Prevelakis, V . , Ioannidis, J., Ioannidis, S., and Keromytis, A . W e b D A V A : an administrator-free approach to Web file-sharing. In Proceedings of the Twelfth I E E E International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises, W E T I C E 2003, 9-11 June, 2003, 59-64. [51] Long, A . C . , Moskowitz, C , and Ganger, G . A prototype user interface for coarse-grained desktop access control. Technical Report CMU-CS-03-200 , Computer Science Department, Carnegie Mel lon University, Pittsburgh, P A . 2003. [52] Lupu, E . and Sloman, M . Conflicts in policy-based distributed systems management. I E E E Transactions on Software Engineering, Special Issue on Inconsistency Management, vol . 25, no. 6, Nov./Dec. 1999, 852-869. [53] Maxion, R . A . and Reeder, R . W . Improving user-interface dependability through mitigation of human error. International Journal of Human-Computer Studies, vol. 63, 2005,23-50. [54] Microsoft. Microsoft TechNet: Security descriptors and access control lists technical reference. 2003. http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef /0b340511-024f-43d0-86d7-17ada2f5b4f4.mspx [55] Nielsen, J. Usability Engineering. Academic Press, 1993. [56] Norman, D . A . The Design of Everyday Things. Basic Books, New York, 2002. [57] Patrick, A . S . , Kenny, S. From privacy legislation to interface design: implementing information privacy in human-computer interactions. In Proceedings of the Privacy Enhancing Technologies Workshop (PET 2003), Dresden, Germany. March 26-28, 2003. [58] Pocock, S., Harrison, M . , Wright, P., Johnson, and P. Thea: a technique for human error assessment early in design. In Proceedings of Eighth IFIP TCI3 Conference on Human-computer Interaction (INTERACT'01), Tokyo, Japan, 09-13 July 2001. 247-254. [59] Probst, S. and Kung, J. The need for declarative security mechanisms. In Proceedings of the 30th Euromicro Conference, 2004, 526 - 531. [60] Rauterberg, M . How to measure cognitive complexity in human-computer interaction. In Proceedings of the 13th European Meeting on Cybernetics and 123 Systems Research, Vienna: Austrian Society for Cybernetic Studies, Apr i l 9-12, 1996, 815-820. [61] Reeder, R. Comparing interfaces for setting N T F S file permissions. Abstract, DIMACS Workshop on Usable Privacy and Security Software, Piscataway, NJ , July 7-8, 2004. http://dimacs.rutgers.eduAVorkshopsAV"GTools/abstracts.html#reeder [62] Saltzer, J .H. and Schroeder, M . D . The protection of information in computer systems. In Proceedings of the IEEE, vol. 63, no. 9, 1975, 1278-1308. [63] Sampemane, G . , Naldurg, P., and Campbell, R . H . Access control for active spaces. In Proceedings of the 18th Annual Computer Security Applications Conference, I E E E Computer Society, Los Alamitos, C A , 09-13 December 2002, 343-352. [64] Sandhu, R.S. , Coyne, E.J . , Feinstein, H . L . , and Youman, C . E . Role-based access control models. IEEE Computer, vol. 29, no. 2, February 1996, 38-47. [65] Sasse, M . A . , Brostoff, S., and Weirich D . Transforming the "weakest l ink" - a human-computer interaction approach to usable and effective security. BT Technology Journal, vol. 19, no. 3., July 2001, 122-131. [66] Sasse, M . A . Computer security: anatomy of a usability disaster, and a plan for recovery. Presented at the C H I 2003 Workshop on Human-Computer Interaction and Security Systems, Ft. Lauderdale, Apr i l 2003. [67] Sasse, M . A . Elicit ing and describing users' models of computer systems. Ph.D. Thesis, School of Computer Science, University of Birmingham, Apr i l 1997. [68] Satyanarayanan, M . Pervasive computing: vision and challenges. IEEE Personal Communications, vol. 8, no. 4, Aug . 2001, 10-17. [69] Schneiderman, B . and Plaisant, C. Designing the User Interface: Strategies for Effective Human-Computer Interaction. 3 r d ed. Addison-Wesley, 1998. [70] Schneier, B . Secrets and Lies: Digital Security in a Networked World. John Wiley & Sons, 2000. [71] Schuler, D . and Namioka, A . (eds.) Participatory Design, Principles and Practices. Hillsdale, N J : Lawrence Erlbaum Associates, 1993. [72] Schultz, E .E . , Proctor, R .W. , Lien, M . - C , and Salvendy, G . Usability and security an appraisal of usability issues in information security methods. Computer & Security, vol. 20, no. 7, 2001, 620-634. [73] Schumacher, M . Security Engineering with Patterns: Origins, Theoretical Models, and New Applications. Springer, 2003. L C N S 2754. 124 [74] Sheehan, K . Towards a typology of Internet users and online privacy concerns. The Information Society, vol. 18, 2002, 21-23. [75] Shen, H . and Dewan, P. Access control for collaborative systems. In Proceedings of the ACM Conference on Computer-Supported Cooperative Work. A C M , New York, 1992,51-58. [76] Shneiderman, B . Direct manipulation: a step beyond programming languages. In IEEE Computer, vol. 16, no. 8, August 1983, 57-69. [77] Smetters, D . K . and Grinter, R . E . Moving from the design of usable security technologies to the design of useful secure applications. In Proceedings of the ACM New Security Paradigms Workshop, September 2002, 82-89. [78] Spencer, R., Smalley, S., Loscocco, P., Hibler, M . , Andersen, D . and Lepreau, J. The flask security architecture: system support for diverse security policies. In Proceedings of the 8th USENTX Security Symposium, Washington, D .C . , U S A , August 23-26, 1999. [79] Tsui, E . Technologies for personal and peer-to-peer (P2P) knowledge management. CSC Leading Edge Forum (LEF) Technology Grant report, July 2002. http://www.knowledgeboard.com/cgi-bin/library.cgi? action=detail&id=l 170. [80] Usability: Usability Basics. U S Department of Health and Human Services, 2004. http://www.usability.gov/basics/. [81] W e b D A V Resources, http://www.webdav.org/ [82] Weirich D . and Sasse, M A . Pretty good persuasion: a first step towards effective password security in the real world. In Proceedings of ACM New Security Paradigms Workshop, September 2001, 137-143. [83] Whitehead J. W e b D A V : versatile collaboration multiprotocol. IEEE Internet Computing, vol. 9, no. 1, 2005, 75-81. [84] Whitten, A . and Tygar, J .D. Usability of security: a case study. Technical Report CMU-CS-98-155 , Carnegie Mel lon University School of Computer Science, December 1998. [85] Whitten, A . and Tygar, J .D. Why Johnny can't encrypt: a usability evaluation of P G P 5.0. In Proceedings of 8th Usenix Security Symposium, Usenix Assoc., 1999, 169-184. [86] Whitten, A . and Tygar, J. Safe staging for computer security. Presented at the Workshop on Human-Computer Interaction and Security Systems, part of A C M Conference on Human Factors in Computing Systems (CHI 2003), Fort Lauderdale, Florida. 125 [87] Whitten, A . Making security usable. PhD Thesis. School of Computer Science, Carnegie Mel lon University, 2004. [88] Wilson, A . , Burnett, M . , Beckwith, L . , Granatir, O., Casburn, L . , Cook, C , Durham, M . , and Rothermel, G . Harnessing curiosity to increase correctness in end-user programming. In Proceedings of ACM Conference on Human Factors in Computing Systems, Ft. Lauderdale, F L , Apr i l 2003. [89] Yan , J., Blackwell , A . , Anderson, R., and Grant, A . Password memorability and security: empirical results. IEEE Security & Privacy, vol . 2, no. 5, Sept.-Oct. 2004, 25-31. [90] Yee, K . - P . User interaction design for secure systems. In Proceedings of 4th International Conference on Information and Communications Security, Deng R. et al., eds., L N C S 2513 Springer, 2002, 278-290; http://zestv.ca/sid. [91] Yee, K . - P . Aligning security and usability. IEEE Security & Privacy Magazine, Sep 2004,48-55. [92] Yurcik, W . Better tools for security administration: enhancing the human-computer interface with visualization. Abstract, D I M A C S Workshop on Usable Privacy and Security Software, Piscataway, NJ , July 7-8, 2004. http ://dimacs. rutger s. edu/W orkshops/W GTools/abstracts. html#yurcik [93] Zurko, M . E . and Simon, R. T. User-centered security. In Proceedings of the ACM New Security Paradigms Workshop, 1996, 27-33. [94] Zurko, M . E . , Simon, R., and Sanfilippo, T. A user-centered, modular authorization service built on an R B A C foundation. In Proceedings of the IEEE Symposium on Security and Privacy, 9-12 May 1999, 57-71. [95] Zurko, M . E . , Kaufman, C , Spanbauer, K . and Bassett, C . D i d you ever have to make up your mind? What notes users do when faced with a security decision. In Proceedings of 18th Annual Computer Security Applications Conference, December, 2002, 9-13. 126 Appendices Appendix 1 UBC Research Ethics Board's Certificate of Approval 127 Appendix 2 Introduction to WebDAV Access Control for User Study 1. Privileges: Access Control Lists are used to manage permissions on systems such as W e b D A V , Microsoft Windows N T and Sun's Networked File System (NFS v4). In W e b D A V , privileges represent the ability to execute certain actions on a resource (e.g., a file or directory). These privileges are organized in a tree structure so that branches on the tree (called aggregate privileges) include all of the basic priviliges on the leaves and branches below them. The tree below represents the privileges for the W e b D A V system we wi l l use on this test. For example, the read privilege includes the read-acl and read-current-user-privilege-set privileges. a l l ] (aggregate) [DAV: 1 , read] (aggregate) 1 + -- [DAV:, read-acl] + -- [DAV:, read-current-user-privilege [DAV: , write] (aggregate) + -- [DAV:, write-acl] + -- [DAV:, write-properties] + -- [DAV:, write-content] (aggregate) + -- [DAV:, bind] + -- [DAV:, unbind] [DAV: , unlock ] 2. Users and Groups: Users are identified by an entry in the users directory (e.g., users/test denotes the user test). A group is identified by an entry in the roles directory (e.g., roles/user denotes the group user). The members of such a group are listed in the property 'group-member-set of this entry and may include both users and other groups. Whenever we want to refer to either a user or a group, we can use the term principal. In order to create a user or group, you need to have the write privilege on the respective directory. In order to change the membership of a group, you need to have both write-properties and write-content privileges on the group entry. 3. ACL: A n Access Control List ( A C L ) is a list of access control elements (ACEs) attached to each file or directory in the system. The A C L is evaluated to determine whether or not access w i l l be granted or denied for a particular W e b D A V action on that 129 file or directory. Each A C E consists of a user or group (a principal), a grant or deny, and a set of privileges. Each A C E should be read as "grant/deny the specified principal the following privileges." Terminology Some terms need to be clarified for this test: Conflict Two A C E s in an A C L are said to conflict with each other when the principals and privileges in these A C E s are matched, but one A C E grants and the other one denies the privileges. Redundancy A n A C E has redundancy with another A C E when the principals and privileges in these two A C E s are matched, and both of these A C E s grant or deny the privileges. Side-effect A peripheral or secondary effect caused by some actions to accomplish a goal. Particularly, in the access management task, it includes that the principal gets/loses more privileges than desired, or more principals besides the desired one get/lose the specified privilege. For example, if the goal is to ensure user A has privilege B , and the action is adding user A to group C which has that privilege, then user A may get not only the privilege B but also all privileges that group C has. 130 Appendix 3 User Study Questionnaire 1. How frequent did you use computers? a) Daily b) A few times a week c) A few times a month d) Rarely 2. How frequent did you set file permissions in your computer system? a) Nearly daily b) A few times a week c) A few times a month or less d) Never 3. Are you familiar with Access Control List ( A C L ) and how it is evaluated? a) Very familiar b) Familiar c) Average d) Know a little e) Don' t know at all 4. Are you familiar with the way A C L s are implemented in W e b D A V (Web-based Distributed Authoring and Versioning) standard? a) Very familiar b) Familiar c) Average d) Know a little e) Don't know at all 5. Additional information about your academic background, knowledge of computers, file-systems and computer security systems: 131 Appendix 4 Description of Tasks Using the ACL Editor for User Study ACL Evaluation: A C E s are maintained in a particular order in the A C L . When permission is requested for a certain action or set of actions on a file or directory, the A C E s are tested in order until all of the permissions required by the current request have been granted, at which point the access is granted. If, at any point, an A C E that denies any of the requested actions that have not already been granted is seen, then the entire request is denied. Failure to have all requested privileges granted results in access being denied. Below is an example of how an A C L is evaluated. The A C L attached to fi le/bo has four ordered A C E s : 1. "Deny users/test the write-acl privilege"; 2. "Grant roles/user the write privilege"; 3. "Deny all principals the read-acl privilege", which is inherited from its parent directory; 4. "Grant all principals the read privilege", which is inherited from its parent directory. users/test and users/john are two members of the group roles/user. According to A C E 2 , users/john can modify the A C L of foo. But users/test cannot modify the A C L though he is also a member of roles/user, because the preceding A C E 1 explicitly denies him the write-acl privilege. Neither users/test nor users/john can read the A C L of foo (ACE3) , but they can read all other properties and content of foo (ACE4) . In addition, because there are no A C E s explicitly granting them the unlock privilege, users/test and users/john have no privileges to k i l l the lock on file foo i f this file is locked and they are not the lock owner. Y o u (user name John, password john) are co-authoring a book named " b o o k l " with some collaborators. The chapters of this book are stored in / f i les /book l / on the W e b D A V server. Using the A C L Editor or Group Manager in D A V Explorer, you should complete the following tasks: 132 Training Task User users/Jack is an independent reviewer, and you want him make some comments on this book. Please make sure that users/Jack can read and change the content of the file files/bookl/comments.txt. Task 1 Start Time: User users/test is your co-author for Chapter 1 (files/bookl/Chapterl.doc). Please make sure that users/test can read and change the content of files/bookl/Chapterl.doc. End Time: Answer the following questions: Your action: Rate your confidence on that the task has been completed correctly (1-7, 7: very confident): Does your setting conflict with previous A C L settings? Does your setting have any redundancy with previous A C L settings? Does your setting cause any side-effects? Task 2 Start Time: Because of personal reasons, now users/test has no time to continue working on this chapter. Please make sure that effective now, users/test can read files/bookl/Chapterl.doc, but cannot change its content. End Time: Answer the following questions: Your action: 133 Rate your confidence on that the task has been completed correctly (1-7, 7: very confident): Does your setting conflict with previous A C L settings? Does your setting have any redundancy with previous A C L settings? Does your setting cause any side-effects? Task 3 Start Time: Please make sure that user users/projector can read files/bookl/Chapter2.doc, but cannot change its content. End Time: Answer the following questions: Your action: Rate your confidence on that the task has been completed correctly (1-7, 7: very confident): Does your setting conflict with previous A C L settings? Does your setting have any redundancy with previous A C L settings? Does your setting cause any side-effects? Task4 Start Time: User users/john2 becomes your co-author for Chapter 3 (files/bookl/Chapter3.doc). Please make sure that effective now, users/john2 can read and change the content of files/bookl/Chapter3.doc. End Time: Answer the following questions: 134 Your action: Rate your confidence on that the task has been completed correctly (1-7, 7: very confident): Does your setting conflict with previous A C L settings? Does your setting have any redundancy with previous A C L settings? Does your setting cause any side-effects? 135 Appendix 5 Description of Tasks Using the IAM Wizard for User Study Y o u (user name John, password john) are co-authoring a book named "book2" with some collaborators. The chapters of this book are stored in /files/book2/ on the W e b D A V server. Using the I A M wizard in D A V Explorer, you should complete the following tasks: Training Task User users/Jack is an independent reviewer, and you want him make some comments on this book. Please make sure that users/Jack can read and change the content of the file fiIes/book2/comments.txt. Taskl Start Time: User users/test is your co-author for Chapter 1 (files/book2/Chapterl.doc). Please make sure that users/test can read and change the content of files/book2/Chapterl.doc. End Time: Answer the following questions: Rate your confidence on that the task has been completed correctly (1-7, 7: very confident): Does this goal conflict with previous A C L settings? Actions the system has taken: Do the actions cause any side-effects? Do the new settings have any redundancy with previous A C L settings? 136 Task 2 Start Time: Because of personal reasons, now users/test has no time to continue working on this chapter. Please make sure that effective now, users/test can read fi!es/book2/Chapterl.doc, but cannot change its content. End Time: Answer the following questions: Rate your confidence on that the task has been completed correctly (1-7, 7: very confident): Does this goal conflict with previous A C L settings? Actions the system has taken: Do the actions cause any side-effects? Do the new settings have any redundancy with previous A C L settings? Task 3 Start Time: Please make sure that user users/projector can read files/book2/Chapter2.doc, but cannot change its content. End Time: Answer the following questions: Your action: Rate your confidence on that the task has been completed correctly (1-7, 7: very confident): Does your setting conflict with previous A C L settings? Does your setting have any redundancy with previous A C L settings? Does your setting cause any side-effects? 137 Task4 Start Time: User users/john.2 becomes your co-author for Chapter 3 (files/book2/Chapter3.doc). Please make sure that effective now, users/john2 can read and change the content of files/book2/Chapter3.doc. End Time: Answer the following questions: Your action: Rate your confidence on that the task has been completed correctly (1-7, 7: very confident): Does your setting conflict with previous A C L settings? Does your setting have any redundancy with previous A C L settings? Does your setting cause any side-effects? Please describe your impressions of this UI design for conflict handling: Under standab i l ity: Clarity: Usability: 138 Appendix 6 User Study Interview Questions 1. What were the particular difficulties or confusions you found in the test? 2. Were there any aspects of the I A M wizard that you found particularly helpful? 3. What particular aspect(s) of the I A M wizard did you like) 4. What particular aspect(s) of the I A M wizard did you dislike! 5. If you are asked to choose from the A C L Editor and the I A M wizard to control access to your resources, which one wi l l you prefer? 6. Is there any functionality that you think can be added to enhance the usability for such access management tasks? 7. Are there any other comments you'd like to make at this time? 139 

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.831.1-0065423/manifest

Comment

Related Items