User-Centered Security Engineering

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-79098 Freiburg, Germany

[email protected]

Abstract

Current approaches to security engineering mainly focus on attacker models, secure mechanisms, and code testing to ensure a high level security standard. How-ever, these approaches do not sufficiently emphasize the usability of the system and the risk arises that the im-plemented mechanisms create overheads for users or require unworkable user behaviour. In addition, end users will not use security products they cannot under-stand 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 secu-rity risks as several studies show1 _{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 (www.pgp.com), Signtrust Mail (www.signtrust.de), and freedom (www.freedom.com), shows that it is not sufficient to establish a highly se-cure system architecture. The main reason for the fail-ure of existing security systems seems to be not the malfunction of these systems, but the wrong

1 _{Business Week online: A rising Tide of concern.}

http://businessweek.com/2000/00_12/b3673003.html; GVU’s 10th _{WWW User Survey.}

http://www.gvu.gatech.edu/user-surveys/

tion and use. This leads to the conclusion that the exist-ing 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 user-centered security engineering is needed where users are integrated in the whole development process of a secu-rity 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, effec-tively and satisfyingly an end user can protect himself and his IT-system in a certain context.

In the following two sections we examine the secu-rity engineering (section 2) and the usability engineer-ing (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 implementa-tion 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 crypto-graphical methods and security models [2; 13; 8], Eckert [3] proposes a method for the construction of secure IT-systems in terms of systematic security engi-neering. Eckert uses an iterative, top-down method referring to the general software engineering and ad-justs her method with regard to special security engi-neering problems. In figure 1 the development phases for the construction of security systems are shown.

Functional analysis: First, the functional character-istics, 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. Subse-quently, 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 re-sults 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 architec-ture: First, an architecture has to be defined with all system components, interfaces and dependencies. Ade-quate 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, integra-tion test, code inspecintegra-tion) with special emphasis on the security functionality and the system interfaces. If pos-sible, 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 techni-cally 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]. Further-more, 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 af-fected by the selection and design of the security mechanisms and the system architecture. For that rea-son, 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 engi-neering 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 water-fall model with its sequential characteristic is not suffi-cient for the design of user interfaces. Rather, user interfaces must be designed, checked, re-adjusted and checked again several times. Therefore, the whole life-cycle should follow an iterative procedure.

Figure 2: Usability Engineering development phases Analysis phase: In the analysis phase the target user group is defined and studied with its individual charac-teristics. 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 Functional

analysis Threat and risk analysis

Security strategy and -model

Design and

Implementation Testing

consideration of costs and benefits leads to the required functions for such a system. In the end of this phase usability goals like failure minimi-zation are set.

Design and testing phases: These phases

consist of parallel design and testing. Several parallel designs on paper should be made, fol-lowing 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 proto-typing. 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 ade-quate 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 se-curity 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 engineer-ing it is the user interface. However, none regards the security tool as one unit that has to be developed re-garding both engineering methods.

To achieve usable security we have to find the an-swers to three important questions in the development process:

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 cir-cles. 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

Functional analysis

Threat and risk analysis Security strategy and -modell Design and Implementation Testing Analysis Design Testing

User as object of attacks User behaviour

Focused on users‘s needs Adaequate security level

Conjoint Testing

Modified usability guide lines for security tools

Security Engineering

Usability Engineering

user interface. The reasons for the new structure are given in detail in the following paragraphs.

For each phase, we investigate afterwards how secu-rity 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 require-ments 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 proc-esses 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 engineer-ing process has to persist in the conjoint process be-cause it forms the basis for the design of the security architecture. But it has to be supplemented by the fol-lowing aspects (illustrated in figure 3):

The end user plays different roles regarding poten-tial threats. The first role is given in the security engi-neering process, too: He may be an attacker himself, i.e. starting an internal attack, then the threats for the secu-rity 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. Addition-ally, 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 de-sign 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 user-centered 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 secu-rity tool influence the choice of secusecu-rity mechanisms and therefore have to be taken into account when defin-ing 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.

4.4.1 The system architecture

The design and implementation of the security ar-chitecture should be based on the usable security strat-egy. 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.

4.4.2 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 suf-ficient for the development of a security tool. We modi-fied 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 e-mail that is not encrypted. The security chain may be compromised. Therefore, the user interface should avoid mistakes in advance.

User guidance in critical situations: To avoid errors it is necessary to identify critical situations and to de-velop 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 intui-tively 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 pri-mary 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 inter-actions with the end user should be minimised in every-day 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 meth-ods. 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 usabil-ity guidelines given in section 4.4. We think that

apply-ing the heuristic evaluation alone is not sufficient be-cause 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 meth-ods 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.

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

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 e-mail writing but who are security nov-ices. 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

Heuristic

Evaluation WalkthroughCognitive

Security evaluation Modified usability

guidelines for security tools

Example tasks, to be

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 confidential-ity of the communication content), integrconfidential-ity, availabilconfidential-ity and accountability.

Availability cannot be enforced by an end user tool on a PC. Therefore, we concentrated on the other pro-tection 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 dependen-cies 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 situa-tion.

This concept guarantees a simplified everyday con-figuration and use with the trade-off of an extended installation procedure. It has the advantage for the non-experienced 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 investi-gated 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 soon. At the same time, many web forms have to be completed by the customers when they want to buy something. Theseforms often request personal data which is nonessen-tial 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 cus-tomer databases. To secure their privacy, end users need adequate tools to handle and to control their personal data when-ever they use the Internet.

We analysed the target user group’s knowledge about security and its willing-ness 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 man-age their identities in the Internet in order to protect their privacy.

5.4 Design and Implementation

We split the security architecture and the user inter-face and design and implemented it separately. Further details are given in the next two sections.

5.4.1 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 con-sists of several modules. Databases are used to store the

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 iMan-ager 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.

5.4.2 The User Interface

The user interface is an essential part of the iMan-ager because the acceptance of the whole system strongly depends on its user-friendliness. Two different kinds of user interaction exist: a strictly guided configu-ration 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 re-quired. 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 de-sign 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

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 2002.

6 Conclusions

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 op-position 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 user-centered security engineering is not yet complete or entirely worked out in detail. But in this stage it is pos-sible to give an impression of the great impact that user-centered 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 1999.

[2] Ross Anderson. Security Engineering – A Guide to Building Dependable Distributed Systems. John Wiley & Sons, Inc. 2001. [3] Claudia Eckert. IT-Sicherheit – Konzepte,

Verfahren, Protokolle. Oldenbourg Verlag München. 2001.

[4] Daniela Gerd tom Markotten and Johannes Kaiser. Benutzbare Sicherheit – Herausforde-rungen und Modell für E-Commerce-Systeme. In Wirtschaftinformatik, Volume 42, pages 531-538, December 2000.

[5] Dieter Gollmann. Computer Security. John Wiley & Sons, Inc. 2001.

[6] ISO-Standard, no. 9241-part 10: Guidelines for dialogue design.

[7] Uwe Jendricke and Daniela Gerd tom Markot-ten. Usability meets Security - The Identity-Manager as your Personal Security Assistant for the Internet. In Proceedings of the 16th Annual Computer Security Applications Con-ference, December 2000.

[8] Alfred Menezes, Paul Oorschot, Scott Vanstone. Handbook of Applied Cryptogra-phy. CRC Press. 1997.

[9] Jakob Nielsen. Usability Engineering. Aca-demic Press. 1993.

[10] Jakob Nielsen and Robert L. Mack. Usability Inspection Methods. John Wiley and Sons, Inc., 1994.

[11] Kai Rannenberg, Andreas Pfitzmann, and Günter Müller. IT Security and Multilateral Security. In Günter Müller and Kai Rannen-berg (Eds.), Technology, Infrastructure, Econ-omy, Volume 3 of Multilateral Security in Communications, pages 21-29. Addison Wes-ley Longman Verlag GmbH, 1999.

[12] Jerome H. Saltzer and Michael D. Schroeder. The Protection of Information in Computer Systems. In Proceedings of the IEEE, Volume 63, pages 1278-1308, September 1975. [13] Bruce Schneier. Applied Cryptography. John

Wiley & Sons, Inc. 1995.

[14] Ben Shneiderman. Designing the User Inter-face. Addison-Wesley Longman, Inc. 1998. ISBN 0-201-69497.

[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 Secu-rity Symposium, August 1999.

[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.