Usable Security in Software Development
Interviews on How Usable Security Does (Not) End Up in Software Products

In 25 semi-structured interviews with experienced software professionals, including software developers, architects, and designers, we investigate how software products' usable security is implemented during the development process.

Among a few positive examples highlighting beneficial factors for usable security, we found many interviewees and their organizations not getting usable security in their products. We identify several obstacles and blockers for usable security, including low awareness of and not knowing about usable security, misconceptions, stakeholder pressure, communication barriers, and more.

All in all, we find that contextual factors especially play a role in implementing usable security. Based on our insights, we propose potential improvements for practical software development.

Share this page

Do you know someone who would be interested in this research? Feel free to share it with them!

For any further questions, feel free to check out the sections below or write us an informal email:

Contact: marco.gutfleisch@ruhr-uni-bochum.de

Publication #


First page of the publications
How Does Usable Security (Not) End Up in Software Products? Results From a Qualitative Interview Study
Marco Gutfleisch, Jan H. Klemmer, Niklas Busch, Yasemin Acar, M. Angela Sasse and Sascha Fahl.
43rd IEEE Symposium on Security and Privacy (S&P 2022), May 22-26, 2022.

Abstract

For software to be secure in practice, users need to be willing and able to appropriately use security features. These features are usually implemented by software professionals during the software development process (SDP), who may be unable to consider the usability of these mechanisms.

While research has made progress in supporting developers in creating secure software products, very little attention has been paid to whether and how these security features are made usable. In a semi-structured interview study with 25 software professionals (software developers, designers, architects), we explored how they and other decision-makers encounter and deal with security and usability during the software development process in their companies.

Based on 37 hours of interview recordings, we qualitatively analyzed and investigated 23 distinct development contexts in detail. In addition to individual awareness and factors that directly influence the implementation phase, we identify a high impact of contextual factors, such as stakeholder pressure, presence of expertise, and collaboration culture, and the specific implementation of the SDP on usable security in software products. We conclude our work by highlighting important gaps, such as studying and improving contextual factors that contribute to usable security and discussing potential improvements of the status quo.

Downloads
Filename Type
Preprint .PDF
Replication Package .zip

Overview #

Interviews #

We recorded audio and optionally video during the interview if the participant agreed. Afterward, the interviews were transcribed and anonymized. After this step, the recordings were destroyed.

Based on the transcripts, we analyzed the interviews by coding. During that process, we developed our code book. Furthermore, we took notes to identify interesting aspects, create memos, and discover themes and theories emerging from the data. Moreover, we discussed and refined the themes and theories in group discussions with all authors. All this was done in an iterative process until we reached theoretical saturation, i.e., no new themes emerged. The whole process is depicted in Figure 1.

Figure 1: Methodology overview.

Figure 1: Methodology overview.

We adhered to the strict German privacy laws as well as the European Union General Data Protection Regulation (GDPR). This includes de-identifying data that might identify the interviewee or the respective organizations they work(ed) for.

Findings #

In the following, we give a brief overview of our key findings. Please refer to the full paper linked above for details.

Contexts

21 of 25 participants reported at least one context in-depth during the interviews. In total, this resulted in 23 contexts that we analyzed. A context refers to the company, organization, or projects the interviewees referred to and the corresponding software development processes. The remaining interviews covered multiple contexts but not a single one in detail. Those provided a cross-cutting perspective that helped compare different contexts described in the other interviews.

Contexts
Contexts reported in the interviews.

Contexts reported in the interviews.

Categorization #

We analyzed the contexts, and two major factors emerged, which we used to classify the contexts:

  1. Awareness for Usable Security.
  2. Prevalence of User-centered Development Measures.

As depicted in Figure 2, this results in four categories in which we classified each of the contexts:

Figure 2: Categories that emerged from the contexts in our interviews.

Figure 2: Categories that emerged from the contexts in our interviews.

Usable Security Awareness and Follow-through #

Five of 23 contexts were classified into this category because they followed a process characterized by user-centered methods, and they were aware of the underlying principles of usable security. Contexts within this category were characterized by the availability of domain expertise and structures that support the communication between usability and security subject matter experts.

No Usable Security Awareness, some User-centered Measures #

Two participants told us about the context where usability was the focus but not security. User-centered methods were applied, but the interplay between usability and security was not understood. Security features in the user interface were treated similarly to other features without additional effort.

Usable Security Awareness, Little or no Follow-through #

We observed that the development teams in six out of 23 contexts may have been aware of usable security and may have even been interested or motivated to implement it. However, there were no supporting structures. Five of the companies were strongly focused on security. Design and usability were rather less important in all contexts.

No Usable Security Awareness, few or no User-centered Measures #

In 10 of 23 contexts, we found that companies were unaware of the interplay between usability and security and spent little or no resources on the usability of their product. In some contexts, security was in focus. However, we also observed that development teams are under pressure to deliver, and good development practices such as clean requirements gathering, unit testing, and mature technical designs often fall by the wayside.

Structures that Hinder Usable Security #

  • Limited Resources: Common blockers are little or missing money and budget, lack of time, and therefore a common pattern to focus on “functionality first”.

    There’s a point where you will sacrifice a usability or security feature. […] You cannot touch the main functionality. But you can remove a security feature or a UI part or whatever to remain inside a budget. – P18

  • Misconceptions: We found fundamental misconceptions regarding what usable security is, whether it is important and therefore lacking awareness, and always trading-off usability versus security.

  • Communication Barriers: We found several contexts in which expertise was available but was not accessed when needed. Incorporating other teams or experts in the SDP creates an overhead within organizations or is just not seen as necessary by the core development team.

    I didn’t meet any designers that like to be involved in technical decisions. I think they feel bored or something. – P22

  • Requirements, Guidelines, Compliance: Usability requirements in our participants' organizations were vague and rarely if ever, written down. In contrast, we noticed that specific security requirements originated either in compliance standards or emerged naturally. Nevertheless, in contrast to that, usable security requirements were rather non-existent.

Structures that Contribute Usable Security #

  • Communication Pivot: We see communication between usability / UX experts and security experts as key factors for usable security.

  • Open Attitude and Commitment Towards Usability: We observed contexts that were indeed aware of usable security, but their organizational structures were not open towards usability. Usable security indeed requires some level of openness and commitment towards usability.

  • Access to Real Users and Feedback: For decades, usability and UX research has shown that real users' feedback is essential. Even if it is sometimes not trivial to get user feedback, there must at least be the possibility to get access to the users.

  • Knowledge About User-centered Methods and (Usable) Security: We also consider awareness of usable security core principles and knowledge about user-centered methods and how to apply them as important. We had some contexts, which were motivated to move more towards usable security within their development context. However, there was a lack of knowledge of usability, UX, and user-centered methods.

Implications #

To overcome barriers for achieving usable security, we propose several recommendations for the software industry but also academia. All implications can be found in detail in the paper .

Recommendations for the Software Industry #

  • Create Awareness for Usable Security: As we found only a little awareness and many misconceptions about usable security being a major blocker, software development process stakeholders should build awareness for usable security.
  • Understand Human Factors: Usable security is about taking human factors into account when creating security systems. Therefore, one must understand the users' needs, capabilities, goals, and most importantly, the context in which they interact with the software. We also propose using standard usability methods (e.g., A/B tests, personas) for security components.
  • Improve Communication between Experts: Usable security needs expertise from both areas, usability, and security. A gap between those could hinder achieving usable security. Hence, good communication and collaboration between stakeholders having this expertise could be helpful and improve mutual understanding.
  • Think Usable Security Right from the Beginning: Usable security should become part of software development processes – as early as possible and ideally right from the beginning. This includes specifying detailed requirements for usable security to be implemented like other requirements and is not forgotten.

Recommendations for Human Factors in Security Research #

  • Transfer Findings from Academia to the Software Industry to Gain Actual Impact: Last 20 years' usable security research has not received widespread attention in the software industry. Usable security seems to be still mostly unknown outside its research community.
  • Emphasize context: As we found contextual factors impacting usable security, we propose to emphasize context and take a holistic view on the software development process in future research – in addition to the research focusing on individuals or single steps of the software development process (e.g., developers in coding experiments).
  • Develop Measures: Researchers can support arguments for usable security in software teams by developing lightweight actions, interventions, and measurable goals to overcome barriers and blockers.

Summary #

In this study, we present the first in-depth analysis of software development processes with a focus on usable security. Based on 25 semi-structured interviews with experienced software professionals, we identify factors impacting usable security and also barriers. In general, usable security is still a niche in the software industry and needs more awareness and a holistic understanding. To successfully integrate usable security into software products, we recommend that researchers and practitioners take a holistic view on software development, also taking into account contextual factors.

This research was partially funded by the Deutsche Forschungsgemeinschaft (DFG, German Research Foundation) under Germany’s Excellence Strategy – EXC 2092 CASA – 390781972.

Researchers #

Marco Gutfleisch | Researcher and PhD Student (Ruhr Universtiy Bochum).
Contact: marco.gutfleisch@ruhr-uni-bochum.de

Jan H. Klemmer | Researcher and PhD Student (Leibniz University Hannover).
Contact: klemmer@sec.uni-hannover.de

Niklas Busch | Researcher and PhD Student (Leibniz University Hannover).
Contact: busch@sec.uni-hannover.de

Yasemin Acar | Assistant Professor (George Washington University) and Guest Researcher (Max Planck Institute for Security and Privacy).
Contact: yasemin.acar@mpi-sp.org

M. Angela Sasse | Full Professor (Ruhr Universtiy Bochum).
Contact: martina.sasse@ruhr-uni-bochum.de

Sascha Fahl | Tenured Faculty (CISPA) and Full Professor (Leibniz University Hannover).
Contact: sascha.fahl@cispa.de

Cite This Work #

Feel free to cite this publication as:

@inproceedings{conf/oakland/gutfleisch22,
	title = {How Does Usable Security (Not) End Up in Software Products? Results From a Qualitative Interview Study},
	author = {Marco Gutfleisch and 
		Jan H. Klemmer and 
		Niklas Busch and 
		Yasemin Acar and 
		M. Angela Sasse and 
		Sascha Fahl},
	booktitle = {43rd IEEE Symposium on Security and Privacy},
	month = {May},
	year = {2022}
}
Gutfleisch et al. "How Does Usable Security (Not) End Up in Software Products? Results From a Qualitative Interview Study" 43rd IEEE Symposium on Security and Privacy. May 2022.