Aligning Security, Usability, User Experience: A Pattern Approach

Security and usability have evolved independently, therefore, expertise in both of these domains are hard to find in one person. This research aims to assist security and usability designers and developers by influencing their decision-making abilities when it comes to the conflicts between security and usability. It does so by proposing the use of usable security patterns for assisting the developers and designers in making accurate choices when handling the conflicts. A novel methodology is presented for identifying usable security patterns from existing implementations, which are effectively managing the security and usability trade-offs. The aim is to identify such implementations while documenting the suitable trade-offs in the format of patterns for use by other developers and designers. To instantiate the methodology, a case study was conducted whose results are also presented in the paper.


Introduction
Security and usability are considered as conflicting goals [1]. The trade-offs between the two are discussed at different forums not limited to cyber-security and Human Computer Interaction (HCI). Typical examples of the security and usability conflict include, (1) complex password guidelines having an impact on memorability, (2) implementation of password masking to protect against 'shoulder surfing attacks' but at the cost of feedback (usability element), among others. Traditionally security and usability have evolved independently as different domains, therefore, expertise in both security and usability are hard to find in one person [2]. Despite this, the developers are ones who face most of the criticism when the security solutions are unusable, or when usability features pose a threat to system security. The domain considering the integration of principles of security and dimensions of usability is known as usable security.
The early efforts in the field of usable security date back to 1998 when different properties of usability problems for security systems were identified [3]. Despite that recognition, state of the art concerning usable security still has some catching up to do. Practices and trends followed in the large organizations reveal a lack of motivation in considering usable security as a quality dimension [4]. One possible reason for this state are the costs associated with usable security [19]. The implementation of security due to the constantly evolving threat environment, and usability due to rapid technological advancements has been so demanding that it leaves less time and costs to manage the trade-offs between the two. Among the other reasons for the current state of the art, it is imperative to discuss the following.
-Different perceptions concerning security and usability: The community has a different opinion concerning the existence of trade-offs between security and usability. Most of the research argues the existence of tradeoffs between security and usability [5][6]. However, in parallel with the research establishing the existence of the trade-offs, there is some research classifying security and usability trade-offs as mere myths [7][8]. When the opinion on the existence of the problem is divided, then it is difficult to effectively contribute towards solving it. -Studying the conflicts by different communities in silos: Various communities and interest groups have been studying usable security in silos, independently from each other. Some of these include, (1) SOUPS (Symposium on Usable Security and Privacy), small community studying trends, avenues and advancements in usable security. Much of the content is tactical, rather than being strategic, (2) The cybersecurity community dealing with the wider scope of security services; usability is a minor concern for this community, (3) The software engineering community where security and usability are considered as quality characteristics. Some of the standards provide contradictory perceptions and models for the same software quality characteristics, e.g. definition of usability in ISO 9126 and ISO 9241-11, (4) The HCI community, where the researchers try to explain from a cognitive perspective how users make poor security decisions leading to system compromises. There is no medium for collaboration that enables views from different communities and perspectives to be incorporated. -In effective joint working groups: Because of independent activities, there is a lack of joint efforts concerning usable security. However, there exist multiple working groups specifically on usable security, but combining their findings in order to come up with a strategic vision for usable security, still remains a challenge. -Lack of strategic approach: Much of the work related to usable security suffers from a cosmetic approach that is the solutions are limited to specific problems, rather than contributing towards management of the conflicts in general [2]. For example, there was a perception that CAPTCHA (Completely Automated Public Turing Test to Tell Computers and Humans Apart) poses readability problems for the users, therefore, new CAPTCHAS were developed that allow the user to select relevant images in response to the challenge. The question that remains valid for the community to address is, 'do we really need CAPTCHAS?' . The prime purpose of CAPTCHA is to protect against denial of service (DoS) attacks, which is the responsibility of the service provider, and then why the user should bear the burden to deal with the CAPTCHA especially they cause deviation from the users' primary task. Likewise, majority of the work on usable security has been on the operational and tactical level and therefore, have a cosmetic effect on the usable security problem. However, what is required in this regard are the long term and strategic solutions, for example, a requirementengineering framework for aligning security and usability during the phases of the software development lifecycle (SDLC).
Moreover, one aspect on which there is a consensus among different groups working on usable security is to focus on learning and assisting the developers in handling the security and usability conflicts. This forms the primary research question addressed in this paper, which is 'how to assist security and usability developers in handling the conflicts and identifying suitable trade-offs while enabling learning in a specific context of use? This research advocates the concept of 'usable security by design' , which is aimed at assisting the developers in handling the conflicts and identifying suitable trade-offs by using design patterns. Each design patterns solves a recurring design problem in a particular context of use.
Using the patterns' approach can be advantageous not only for the developers but for the organizations as well. Software development organizations can also contribute to the catalog of patterns, based on previous experiences from the projects. Furthermore, using the patterns while ensuring effective management of the trade-offs does not affect the timely completion and costs associated with the project.
There are some existing usable security design patterns, but there is a need to collect those patterns, add them to a catalog and disseminate the catalog among the developers and designers. Furthermore, it is imperative to identify more patterns to be added in the catalog. For identifying more usable security patterns, the proposal for a three-staged methodology is presented in this paper. The remainder of the paper is organized as follows. Section 2 presents the background and literature review. Section 3 presents the proposed methodology for the identification of usable security patterns from existing implementations. Section 4 presents the case study to instantiate the proposed methodology, and Section 5 concludes the paper.

Background and literature review
In line with the research question addressed in this paper, the literature review was conducted considering the following objectives.
1. To rationalize the use of patterns as a way of assisting developers in handling inter-disciplinary conflicts e.g. security and usability conflicts.

To identify existing usable security patterns (if any) and methodologies
for identification for such patterns.
The authors [9] state, "insufficient communication with users produces a lack of user-centered design in security mechanisms". The approach advocated in this research is the use of patterns. Both usability and security professionals recognize the importance of incorporating their concerns throughout the design cycle and acknowledge the need for an iterative rather than a linear design process. Patterns' ability to be improved over the time and incorporate multiple viewpoints make them suitable for inter-disciplinary fields like usable security [1]. Patterns provide benefits like means of common vocabulary, shared documentation, improved communication. In addition, the pattern can be incorporated during the early stages of system development in contrast to considering usability and security later in the development lifecycle; handling the usable security problem earlier in the development lifecycle helps in saving significant costs and delays associated with rework.
An architect Christopher Alexander in the book ' A Pattern Language' originally introduced the concept of patterns [10]. Deriving inspiration from this, the same concept was implemented in computer science particularly in software engineering to assist the designers of the system, while providing guidelines and high-level principles. The similar concept was introduced in HCI to assist the development of user interface design (e.g. [11][12]).
Each pattern expresses a relation between three things, context, problem and solution. Patterns provide real solutions, not abstract principles, by explicitly mentioning the context and problem and summarizing the rationale for their effectiveness. Since the patterns provide a generic "core" solution, its use can vary from one implementation to other.
Furthermore, the patterns have three dimensions: descriptive, normative, and communicative [17]. From the perspective of usable security, the communicative dimensions of the patterns enable different communities to discuss design issues and solutions. Patterns also prove effective in the domains, which lack an existing body of knowledge; in such cases the patterns assist in identifying effective practices as they emerge and capture them as objects for discussion, scrutiny and modification [17].
In line with the second objective of the literature review, it was identified that the authors [13], while listing 20 usable security patterns also presented the results after analysis of commonly used software browsers like Internet Explorer, Mozilla Firefox and email clients like Microsoft Outlook. It was revealed that the identified patterns had 61.67% application in the analyzed software implementations. The authors state "patterns make sense and can be useful guide for software developers". However, the work was limited to listing the patterns and justifying their usage.
The authors [14] presented a list of patterns to align security and usability. They classified the patterns in two categories: data sanitization patterns and secure messaging patterns. Different patterns listed include, 'explicit user audit' , 'complete delete' , 'create keys when needed' , among others.
The authors [15] proposed a set of user interface design patterns for designing information security feedback based on elements of user interface design. In addition, the authors created prototypes incorporating the user interface patterns in the security feedback to conduct a laboratory study. The results of the study showed that incorporating the elements of usability interface design patterns could help in making security feedbacks more meaningful and effective.
The authors [1] presented a methodology for deriving usable security patterns during the requirements engineering stage of system development. The methodology relies on handling the conflicts during the early stages of system development, and documenting the suitable trade-offs in the form of design patterns for reuse. What distinguishes the methodology presented in this paper from the work [1] is that, the methodology discussed in this paper focuses on identifying and documenting instances of good implementations by experienced developers in the form of design patterns. This is more of a bottom-up approach involving identification of the patterns from existing implementations. However, the work [1] focuses on the creation of new patterns based on system requirements where possible trade-offs are identified and managed. The managed trade-offs are documented as patterns for implementation in the specific project and re-use by other developers.

Methodology for identification of usable security patterns
In this section, the proposed three-staged methodology for identification of usable security patterns is presented. As stated earlier, the methodology relies on extracting or identifying new patterns from existing implementations, which are setting good practices in the industry (see Fig.1). This methodology provides uniform means to identify new patterns, and an opportunity for various stakeholders to contribute towards identification of the patterns and building the usable security patterns catalog. Particularly, from the industrial perspective, it can enable documenting new patterns from the implementations by experienced developers, thereby facilitating learning and training of new developers.
• Stage-1: The first stage involves the selection of a common usable security problem. The next step is to identify existing implementations addressing the problem. Since the implementations can have different ways of approaching the problem, therefore, to document the pattern it is imperative to fulfill the 'Rule of Three' . The rule of three requires at least three instances of similar implementations before a pattern could be identified and documented [17]. Once three instances of similar implementations for a particular problem are identified, the pattern is documented on a standard template. The details of usable security patterns' template are presented elsewhere [16]. • Stage 2: The second stage involves a review of the newly documented pattern by one or more experts in the field. This stage involves activities like selection of expert(s), gathering the reviews. Based on reviews the pattern is either accepted, which means it is ready to be finalized (Stage 3), or require modification, which means it goes back for modification to the experts who identified it during Stage 1, and in other cases it may be rejected, which means it is discarded. The review by experts besides validation of the pattern has two advantages, (1) ensuring compliance with the underlying standards and best practices concerning security and usability, and (2) ensuring that the solution proposed in the pattern manages the trade-off effectively. The expert(s) review concerning each pattern is recorded on a checklist (see Table 1). • Stage 3: This stage comprises the following activities subject to the decision by the expert(s): -Accept: The accepted patterns are added to the catalog. The patterns in the catalog can be disseminated among the community of developers and designers. The ways of disseminating the patterns include online pages, pocketbook for developers, and whitepapers.

Usable Security Pattern Review Checklist
Description: For the pattern under consideration fill in the columns below. Accessing ISO standards on security and usability is highly recommended to ensure compliance  -Modify: The documented pattern is referred back to the security and usability experts who identified it. The proposal for modification is considered and after necessary amendments, the pattern is subjected to review for the second time. -Reject: The rejected patterns are discarded, however, the recommendations are considered for compliance in the other identified patterns with similar as well as the varying context of use.

Instantiating the methodology: A case study
To instantiate the methodology and identify a usable security pattern, a case study was conducted. The participants in the case study were the members of the software engineering laboratory at LUT University. Participation in the case study was voluntary. The objective behind the case study was to identify instances of good implementations by experienced developers, which set best practices in the field concerning the problem described below.

Case Description:
Mobile devices, particularly smartphones and tablets have become an inseparable companion for human users, as they have a wide range of features not just limited to communication. With such increased usage, we have seen an increase in cases of loss/theft of mobile devices, which ultimately leads to data breaches. Consider a scenario when someone's smartphone is lost. Even if the lost smartphone it was locked, the victim would still be worried about ways in which an adversary could bypass the authentication mechanism and get access to the device. Access to the device could mean a breach of privacy and identity (if payment options were linked to the lost device). The authors [18] report a user study revealing that 50% of the respondents did not feel protected in case of loss/ theft of their smartphone. Based on the scenario, the following problem statement was formulated.

Problem Statement:
In case of loss/theft of the users' device, the data on the device increases the impact of loss in the form of breach of privacy. The user needs to have trust and protection feeling in order to use the device for personal/work purposes.

Stages of Case Study:
• Stage 1: This first stage involved the selection of the aforementioned usable security problem. The next step involved the application of the 'rule of three' . Once three similar implementations addressing the problem were identified, the pattern (see Fig. 2) was documented on the standardized template.
The usable security solution offered by the pattern for the problem identified above is to "Offer the user with remote deletion functionality hosted by the mobile vendor or mobile service provider". A secure service available online will work in this regard. It should offer the remote deletion by invoking the restore factory settings procedure, which would erase all the information from the device in case of loss/theft. This procedure not only ensures the security of data but also incorporates the human aspect of security, achieving human satisfaction and trust (elements of the global usability), to the security procedure.
Implementations of this pattern are available in the form of a "remote data deletion" functionality made available by smartphone manufacturers like Samsung and Apple for their users. Now the question arises who will use this pattern when this feature is already implemented? One scenario for application of this  pattern is in the case of other mobile devices including PDAs for inventory records, GPS, etc. Phone vendors who do not provide the remote deletion functionality can also apply this pattern.
• Stage 2: This stage involved the validation of the patterns by the experts. It is pertinent to state that the pattern presented in Fig. 2 is a validated version of the pattern after reviewing by the experts. The items in italic were added based on experts' recommendations. The pattern review checklist from one of the experts is presented in Fig. 3. • Stage 3: Involved addition of this pattern to the catalog we are maintaining for dissemination and re-use by other developers.

Conclusion
Inter-dependencies and trade-offs between security and usability need to be accessed in a strategic manner. Efforts need to be put in to develop a framework within the scope of the software development life cycle (SDLC) for eliciting the conflicts between security and usability while identifying suitable trade-offs between the two. Use of patterns can be influential in regards to documenting the outcomes of employing such frameworks. Patterns can assist also assist in improved communication between various segments working on the project more precisely the security and usability teams. Additionally, the use of patterns does not only assist the developers within the organizational setting but also free-lancers in assessing the usability of their security options and vice versa. Furthermore, one pattern only solves one problem in a particular context of usage; therefore, an entire catalog of usable security patterns is required just like user interface patterns catalog. Development of such catalog is a timeconsuming process and requires community-level efforts, therefore, we intend to present our proposal of using patterns and the methodology for identifying patterns to participants of the Human-Centered Software Engineering and HCI community for their feedback and participation in the development of the usable security patterns catalog.