User-Centered Security Engineering

Transcription

1 User-Centered Security Engineering Daniela Gerd tom Markotten Albert-Ludwigs-University of Freiburg Institute for Computer Science and Social Studies (IIG) Department of Telematics Friedrichstrasse 50, D Freiburg, Germany Abstract Current approaches to security engineering mainly focus on attacker models, secure mechanisms, and code testing to ensure a high level security standard. However, these approaches do not sufficiently emphasize the usability of the system and the risk arises that the implemented mechanisms create overheads for users or require unworkable user behaviour. In addition, end users will not use security products they cannot understand or which are difficult to apply. Therefore, we propose the new concept of integrated user-centered security engineering to bridge the gap between security and usability. This method has been pursued for the development and implementation of the security tool Identity Manager. 1 Introduction As the dependence on the Internet increases in every day life, security becomes more and more important especially in e-commerce. End users are aware of security risks as several studies show 1 and they want to be protected while acting in the Internet. Furthermore, they want to be able to protect themselves without relying on Internet providers or trusting website owners. Thus, security tools for end users are needed. Security engineering facilitates the development of secure software tools. To ensure a high level security standard, current approaches to security engineering [2; 3; 13; 8] focus on attacker models, secure mechanisms and code testing. Our investigation of existing security tools, like PGP ( Signtrust Mail ( and freedom ( shows that it is not sufficient to establish a highly secure system architecture. The main reason for the failure of existing security systems seems to be not the malfunction of these systems, but the wrong configura- tion and use. This leads to the conclusion that the existing security systems are not appropriate for most users. Furthermore, if the security tool is too complex and difficult to configure, most users are not willing to apply such a tool in everyday life. Therefore, a new concept of integrated usercentered security engineering is needed where users are integrated in the whole development process of a security system. The aim of this method is to ensure usable security. Based on the definition of usability of [6] we define usable security as follows: Usable security is the degree how efficiently, effectively and satisfyingly an end user can protect himself and his IT-system in a certain context. In the following two sections we examine the security engineering (section 2) and the usability engineering (section 3) and show weaknesses and problems when one of these methods is applied individually. In section 4 we introduce our new user-centered security engineering method by combining and supplementing the two methods given in section 2 and 3. This method has been pursued for the development and implementation of the security tool Identity Manager which is illustrated in section 5. Conclusions and major findings complete this paper. 2 Security Engineering Security engineering facilitates the development of secure software tools. Whereas many researchers in this field concentrate on security techniques like cryptographical methods and security models [2; 13; 8], Eckert [3] proposes a method for the construction of secure IT-systems in terms of systematic security engineering. Eckert uses an iterative, top-down method referring to the general software engineering and adjusts her method with regard to special security engineering problems. In figure 1 the development phases for the construction of security systems are shown. 1 Business Week online: A rising Tide of concern. GVU s 10 th WWW User Survey.

2 Functional analysis Threat and risk analysis Security strategy and -model Design and Implementation Testing Functional analysis: First, the functional characteristics, the future system environment and the purpose of the system have to be defined. Afterwards the needed system components and services with their functionality are described and put together in a rough draft of the system architecture. Threat and risk analysis: In the next step a threat analysis on the given architecture has to be conducted. The treat analysis regards different kinds of attacks, like outside/inside attacks and defines potential attackers, like programmers, users and mobile code. Subsequently, in the risk analysis the found threats have to be ranked regarding the occurrence probability and the potential damage it may cause. Security Strategy and Security Model: With the results of the previous phase security, requirements of the software tool can be deduced. Additionally, an abstract security model has to be constructed to check security characteristics, e.g. with formal methods. Design and Implementation of the system architecture: First, an architecture has to be defined with all system components, interfaces and dependencies. Adequate algorithms and security mechanisms have to be chosen for the components with security functionality. A wide range of applicable algorithms and security mechanisms and their effective application is described in detail in [2, 13, 8, 5]. Testing and Evaluation: The implemented system has to be tested in several stages (module test, integration test, code inspection) with special emphasis on the security functionality and the system interfaces. If possible, the security functions should be verified by means of formal methods. With the results of the evaluation, re-adjustments may be required. The security engineering process is highly technically oriented without regarding the users and their needs sufficiently. Indeed, it is stated that the users needs should not be ignored, but no explicit guidelines and tasks are given for effective user integration. If the users needs are not a primary goal in the software engineering process, the risk arises that the implemented mechanisms create overheads for users or require unworkable user behaviour [1]. As said before, end users will not use security products that they cannot understand or that are difficult to apply [16]. Furthermore, the consequences of ignoring the restricted user knowledge about security may lead to user interactions Figure 1: Security engineering development phases that unwittingly compromise the security level of the security tool [15]. 2.1 Adding usability afterwards One possibility to increase the usability of a security tool is to apply usability testing and techniques to the secure system afterwards [16]. We claim that this is not sufficient, since the design of the user interface is never independent of the underlying security infrastructure. This implies that the usability of a security tool is affected by the selection and design of the security mechanisms and the system architecture. For that reason, it may be too late to achieve a large improvement of usability. As usability experts point out [9; 14], users should be integrated into the design process as early as in the functional analysis phase to assimilate their needs to the system requirements. 3 Usability Engineering Several approaches to user-centered design have been made. The most detailed one is the usability engineering method which was introduced by Nielsen [9]. The development process can be split into three parts: The analysis phase, the design phase and the testing phase. Software engineering techniques like the waterfall model with its sequential characteristic is not sufficient for the design of user interfaces. Rather, user interfaces must be designed, checked, re-adjusted and checked again several times. Therefore, the whole lifecycle should follow an iterative procedure. Analysis Design Testing Figure 2: Usability Engineering development phases Analysis phase: In the analysis phase the target user group is defined and studied with its individual characteristics. During the observation of the users, a task analysis can be conducted: On the one hand, the current way of managing tasks in existing security tools are recorded and, on the other hand, the desired ways and possibilities of security configuration are analysed. The

3 consideration of costs and benefits leads to the required functions for such a system. In the end of this phase usability goals like failure minimization are set. Design and testing phases: These phases consist of parallel design and testing. Several parallel designs on paper should be made, following usability guidelines, and tested with evaluation methods, like the heuristic evaluation method or the cognitive walkthrough [10]. The heuristic evaluation and cognitive walkthrough are evaluation methods that can be conducted by usability experts. The advantages is that only three to five experts are needed to achieve a great impact on the usability of the system [9]. This is cost saving and enables the improvement of the user interface in an early stage. Therefore, the design and implementation costs can be kept down. The two steps of designing and testing are repeated until the design is ready to start prototyping. Then an empirical testing with the target user group can be conducted. Re-adjustments may be necessary. Nielsen says: usability engineering is a set of activities that ideally take place throughout the lifecycle of the product. [9]. But usability engineering focuses mainly on the design of the user interface and does neither influence nor interact with the development process of the security architecture and its implementation. A usable user interface depends on the underlying security infrastructure. If the underlying processes are not adequate for the functionality of the security tool it may be impossible to provide an user-friendly user interface. Furthermore, we claim that usability engineering is too general to be applied for the development of security tools because of the special properties of security [15; 4]. Thus, a new concept of integrated user-centered security engineering is needed. To bridge the gap between security and usability several approaches have been made [12; 1; 16; 15]. No approach tried to integrate both into a consistent development process. 4 User-centered Security Engineering In security engineering the secure system forms the centre of the investigation as in the usability engineering it is the user interface. However, none regards the security tool as one unit that has to be developed regarding both engineering methods. To achieve usable security we have to find the answers to three important questions in the development process: Security Engineering Functional analysis Threat and risk analysis Security strategy and -modell Design and Implementation Testing Conjoint Testing Usability Engineering Analysis User as object of attacks User behaviour Focused on users s needs Adaequate security level Modified usability guide lines for security tools Design Testing Figure 3: User-centered security engineering - What are the users needs with respect to security software? - How can we design a secure system architecture that is the best possible presupposition for a good design of the user interface? - How can we design a good user interface of a secure system that enables effective, efficient and satisfying usage? In the following paragraphs we analyse which phases could be merged together and which phases have to persist in the conjoint process of user-centered security engineering. Figure 3 shows the phases of the iterative development process. The grey boxes visualise the existing phases of the security and the usability engineering. The new added ideas are given in the circles. As it can be seen, the analysis phase should be merged together, the modelling phase of the security engineering process is supplemented and the design and testing phases should be undertaken independently. The user-centered security engineering procedure ends with a conjoint testing of the security architecture and the

4 user interface. The reasons for the new structure are given in detail in the following paragraphs. For each phase, we investigate afterwards how security principles and users needs can be combined. 4.1 User-centered analysis phase The two analysis phases should be merged together to get a most precise impression of the system requirements in this early stage of the development process. Interviews or observation of the target user groups are indispensable. However, asking users about their desired security goals may cause a problem: Certainly, they want themselves to be protected as effectively as possible. But the really interesting question is what expenditures (e.g. complex configuration procedures) they are willing to put up with to ensure their personal level of security. Based on the results of the investigation, all processes of the system should be described. Therefore, usability experts and system developers should work together to ensure that the underlying process does not affect the usability of the security tool in a negative way. Then, the needed system components and services can be identified and put together in a rough draft of the system architecture. 4.2 User-centered threat and risk analysis phase The threat and risk analysis of the security engineering process has to persist in the conjoint process because it forms the basis for the design of the security architecture. But it has to be supplemented by the following aspects (illustrated in figure 3): The end user plays different roles regarding potential threats. The first role is given in the security engineering process, too: He may be an attacker himself, i.e. starting an internal attack, then the threats for the security system has to be identified. Additionally, the end user may not only be the subject of an attack but may also be the object of an external attacker. For example, if somebody tries to harm the user s privacy, the user and his personal data have to be protected. Additionally, the users behaviour has to be regarded in the threat analysis. If a user unwittingly commits a mistake, to what extend is the security level of the IT-system impaired? The risk analysis is conducted like explained above, completed by the inclusion of the target user group and its known behaviour. This analysis affects the design of the user interface too: if the question of how a security system could be harmed or the weaknesses of the security chain are identified, the critical points for the user interface design are fixed as well. 4.3 Usable security strategy and model phase With the construction of an abstract security model and the choice of security mechanisms, some aspects of usable security should be taken into account. In a security context some aspects may influence the usability of the whole system. Usability depends on the system speed determined by the chosen security mechanisms. Therefore, it has to be checked if highly secure but slower security mechanisms (e.g. using mixes to ensure anonymity) may impair the usability of the system. The answers to the questions in the usercentered analysis phase (4.1) may give indications to what extent the protection goals have to be fulfilled from the user s point of view. Furthermore, the convenience of the target user group and the necessary steps to interact with the security tool influence the choice of security mechanisms and therefore have to be taken into account when defining a usable security strategy. 4.4 User-centered design and implementation phase Necessarily, the design and implementation phase has to consist of both underlying engineering processes. Suggestions for the user interface should be created without relying on the abstract and complicated security mechanisms. If the user interface is designed when the security architecture is fixed, it will be very hard not to transfer the security mechanisms straight to the surface. Therefore, we propose to work on the design of the user interface and the system architecture simultaneously but independently of each other The system architecture The design and implementation of the security architecture should be based on the usable security strategy. Nevertheless, the highest achievable security level should be implemented while regarding the users needs. Therefore it is recommended that target users attend the design and implementation phase to avoid possible misunderstandings as soon as possible The user interface Nielsen suggests following usability guidelines when designing the user interface. Based on the special properties of security [15] these guidelines are not sufficient for the development of a security tool. We modified and supplemented the usability guidelines of the ISO guideline no. 9241, part 10 [6] referring to security aspects as follows: Error Avoidance: It is not sufficient for a security system to be error tolerant as stated in [6], because security relevant actions are often non-revokeable, e.g. unwittingly sending an that is not encrypted. The security chain may be compromised. Therefore, the user interface should avoid mistakes in advance.

5 User guidance in critical situations: To avoid errors it is necessary to identify critical situations and to develop a guided procedure so that the user can safely complete the desired task. In addition, good help and state messages are needed. Generation of trust: If the user interface does not look trustworthy, nobody will use the security tool independently of secure underlying mechanisms. It is the task of the user interface to reflect the security level of the security tool. It should be kept in mind that trust is very hard to gain but easy to loose. User-friendliness especially for new users: If a user starts to work with a new security tool it has to be intuitively usable, right from the beginning. The user is not willing to learn about security mechanisms and to deal with the user interface, because security is not a primary goal. People do not generally sit down at their computers wanting to manage their security they want security in place to protect them [15]. Abstraction of security mechanisms: Security mechanisms are very technical and complex. If the functionality of the system is merely copied to the user interface, no security novice will be able to use the system. Therefore, familiar models of the real world should be transferred to the security tool. Avoidance of interaction in every-day use: As said before, security is not a primary goal. Therefore, the underlying security should be transparent and the interactions with the end user should be minimised in everyday life. If it is the security system that initiates the interaction, e.g. with warning messages, the user may be disturbed and, in the long run, annoyed. If the user has to start an interaction every time he wants to start a secure communication, it is too inconvenient for him and he may also sometimes forget about the security. The more often he has to begin an interaction, the less he will be satisfied with the system. Furthermore, every action may cause an error due to insufficient security knowledge. Certainly, the control has to remain to the user, but the system should make it as easy as possible to ensure the desired security level. 4.5 User-centered testing The system architecture and the user interface can be tested separately with their domain-specific methods. In an iterative process the system architecture and the user interface are tested and re-adjusted until both parts are ready to be put together. For the evaluation of the user interface we propose a modified evaluation method. The heuristic evaluation is based on the usability guidelines. Referring to this guidelines usability experts analyse the user interface. For the evaluation of security tools we recommend to test the user interface by means of the modified usability guidelines given in section 4.4. We think that applying the heuristic evaluation alone is not sufficient because it focuses on the design of the user interface without regarding the underlying functionalities and processes. With an cognitive walkthrough especially the order of steps to complete a task are examined. Underlying problems caused by inadequate process modelling can be recognized. But this evaluation methods focuses only on intuitive usability and is strictly guided by the given task that should be accomplished by the usability experts. Combining both evaluation methods to a consistent evaluation method for the user interfaces of security tools keeps the advantages of both methods: Some example tasks are given and should be analysed by means of the modified guidelines. This evaluation method is illustrated in figure 4. Heuristic Evaluation Modified usability guidelines for security tools Security evaluation Figure 4: Security evaluation for user interfaces 4.6 Conjoint testing In the conjoint testing phase an integration test has to be accomplished and a representative user test should be conducted. 5 The Identity Manager Cognitive Walkthrough Example tasks, to be conducted To show how user-centered security engineering is applicable in practice we followed this method for the development and implementation of the security tool Identity Manager [7]. 5.1 User-centered analysing phase In our research project ATUS (A Toolkit for Usable Security) we wanted to develop a security tool enable end users to act securely in the Internet. Our target user group were people who are more or less familiar with browsing or writing but who are security novices. It was our aim to minimize the interaction between the security system and the user, because users are not willing to start actions which are not (primary) goal orientated. Starting from the definitions of multilateral security [11], we had to decide which security protection goals

6 Figure 5: The system architecture of the imanager [7] should be necessarily enforced when acting in the Internet and what our tool could support. The analysed security protection goals were: Confidentiality (with its sub-goals: unobservability, anonymity and confidentiality of the communication content), integrity, availability and accountability. Availability cannot be enforced by an end user tool on a PC. Therefore, we concentrated on the other protection goals and had to answer the question of how a non-experienced user could handle all these security goals and set the corresponding security mechanisms correctly. Not to overload the end user and to minimize user interaction in every-day life, we examined dependencies and underlying attacker models of the protection goals. The detailed analysis can be found at [7]. Our result was that protection goals can be split into two groups: the system-controlled and the user-controlled. We found that only the degree of anonymity against the communication partner and accountability have to be user-controlled because they depend on the actual situation. This concept guarantees a simplified everyday configuration and use with the trade-off of an extended installation procedure. It has the advantage for the nonexperienced user that he does not have to configure all protection goals during everyday use. 5.2 User-centered threat and risk analysis Following the instructions of section 4.2, we investigated how users may be attacked while acting in the Internet. The problem we focused on was the user s privacy. While using the Internet, some data is provided automatically, such as IP-addresses, what type of browser is used, which web-sites have been visited before and so on. At the same time, many web forms have to be completed by the customers when they want to buy something. These forms often request personal data which is nonessential for the underlying online purchase. With methods such as data mining, it is possible to link all this information to create very detailed customer profiles, especially through big centralized customer databases. To secure their privacy, end users need adequate tools to handle and to control their personal data whenever they use the Internet. We analysed the target user group s knowledge about security and its willingness to use security tools. This lead us to the conclusion that we have to choose security mechanisms which do not hinder acting in the Internet by slowing down the system and do not need perpetual interaction in everyday use. 5.3 Usable security strategy and model: The remaining protection goals, anonymity (against the communication partner) and accountability, have to be handled by the user because their configuration depends on both the situation and the user's attitude toward his personal security needs. Our investigations led us to an interesting result: the two remaining protection goals can be reduced to the user's identity, which in this case is the user's appearance in the network. Each user has a lot of identities of different kinds, e.g. IP-addresses, e- mail addresses, nicknames, credit card numbers, real names, postal addresses, etc. The advantage of this concept is that every user deals with several identities in the real world, too. That means it is a known concept for him. Our security strategy is to encourage users to manage their identities in the Internet in order to protect their privacy. 5.4 Design and Implementation We split the security architecture and the user interface and design and implemented it separately. Further details are given in the next two sections The system architecture The Identity Manager (imanager) exists between the Internet applications and the network like a firewall and helps the users to manage their digital identities. It controls the data flows to and from the network. The structure of the imanager and its integration is shown in figure 4. The security architecure of the imanager consists of several modules. Databases are used to store the

7 details at any time: the user just moves the cursor to the icon of the identity, and the personal data is shown as on a business card. 5.5 Testing As stated before several tests, especially on the user interface designs, have be conducted. 5.6 Conjoint testing We have not yet tested the imanager with a conjoint testing method, such as a representative user tests, right now. This will be our next task. A target user group test with at least 20 users is already planned. This test should be complete by March Conclusions Figure 6: The user interface of the imanager data of the user and network specific data. Application modules for encryption, digital signatures, or mix net work access are realized as plug-ins. Finally, the imanager has to communicate with the applications, the network, and the user, so it needs system interfaces for the applications, access to the sockets of the TCP/IP network and a user interface The User Interface The user interface is an essential part of the imanager because the acceptance of the whole system strongly depends on its user-friendliness. Two different kinds of user interaction exist: a strictly guided configuration of the system during installation and everyday use. The user must be allowed to change and to browse the initial configuration at any time. The identity must be displayed in a comfortable way. The first idea was the representation on a slider with anonymous identities on the left and accountable identities on the right. This would grant a fast and easy setting of the identity required. However, a linear ranking of the identities, e.g. from anonymous to less anonymous, is subjective. The second approach was based on check boxes and a three window system. It turned out in the usability evaluation for security tools (section 4.5) that this design is too time consuming to deal with in everyday life. Our third design approach is shown in figure 6. During everyday use the user interface just shows the actual identity. The user has the opportunity to view more Today's security tools are insufficient due to overly complex user interfaces. New ideas and concepts are needed to solve this problem. Somehow usability and security are oriented in opposition to one another. To ensure a high security level, usability may be impaired and vice versa. We tried to satisfy these two aims of security system development by introducing user-centered security engineering. Certainly, the presented unified process of usercentered security engineering is not yet complete or entirely worked out in detail. But in this stage it is possible to give an impression of the great impact that usercentered security engineering may have on the usage and usability of security tools and the satisfaction of users. That was what we were aiming at and we know there is a lot to do in this field in the future to bring users and security together and to empower users to control their individual security requirements on their own. Bibliography [1] Anne Adams and Martina Angela Sasse. Users Are Not The Enemy. Communication of the ACM, 42(12):41-46, December [2] Ross Anderson. Security Engineering A Guide to Building Dependable Distributed Systems. John Wiley & Sons, Inc [3] Claudia Eckert. IT-Sicherheit Konzepte, Verfahren, Protokolle. Oldenbourg Verlag München [4] Daniela Gerd tom Markotten and Johannes Kaiser. Benutzbare Sicherheit Herausforderungen und Modell für E-Commerce-Systeme. In Wirtschaftinformatik, Volume 42, pages , December [5] Dieter Gollmann. Computer Security. John Wiley & Sons, Inc

8 [6] ISO-Standard, no part 10: Guidelines for dialogue design. [7] Uwe Jendricke and Daniela Gerd tom Markotten. Usability meets Security - The Identity- Manager as your Personal Security Assistant for the Internet. In Proceedings of the 16th Annual Computer Security Applications Conference, December [8] Alfred Menezes, Paul Oorschot, Scott Vanstone. Handbook of Applied Cryptography. CRC Press [9] Jakob Nielsen. Usability Engineering. Academic Press [10] Jakob Nielsen and Robert L. Mack. Usability Inspection Methods. John Wiley and Sons, Inc., [11] Kai Rannenberg, Andreas Pfitzmann, and Günter Müller. IT Security and Multilateral Security. In Günter Müller and Kai Rannenberg (Eds.), Technology, Infrastructure, Economy, Volume 3 of Multilateral Security in Communications, pages Addison Wesley Longman Verlag GmbH, [12] Jerome H. Saltzer and Michael D. Schroeder. The Protection of Information in Computer Systems. In Proceedings of the IEEE, Volume 63, pages , September [13] Bruce Schneier. Applied Cryptography. John Wiley & Sons, Inc [14] Ben Shneiderman. Designing the User Interface. Addison-Wesley Longman, Inc ISBN [15] Alma Whitten and J.D. Tygar. Why Johnny Can't Encrypt: A Usability Evaluation of PGP 5.0. In Proceedings of the 8th USENIX Security Symposium, August [16] Mary Ellen Zurko and Richard T. Simon. User-centered security. In Proceedings of the UCLA conference on New security paradigms workshops, pages 27-33, Lake Arrowhead, CA USA, September 1996.