How Does Usable Security (Not) End Up in Software Products?
A lot of breaches occur not because of human errors, but due to poor software design which doesn’t take into account user context and human factors.
Tldr;
The research proposal emphasises that software must be both secure and usable for users to appropriately use security features.
There are many factors at the root of why usable security doesn’t make it into the Software Development Life Cycle (SDLC). The most pressing ones are:
- Lack of awareness about the connection between security and usability
- Misconception — especially around the trade-off myth that usability and security have to be weighed against each other
- Missing knowledge
- Communication and cultural issues
- Limited resources — budgets, time, and the prioritisation of features and functionality to the detriment of usable security
To improve the adoption of usable security, there needs to be better awareness and interdisciplinary collaboration between academia and industry, along with measures that support a holistic usable security process — such as changes to the software development process (SDP) and resources.
The paper also has recommendations on how to achieve this:
- Build up awareness for usable security within the software development practices and impart knowledge to those involved (i.e. the software developers, UX developers, and stakeholders)
- A potentially effective way to achieve this is through behavioural change intervention strategies. - Understand user context by improving communication between security and usability experts.
- Integrating Usable Security with SDCL
- Measure and track usable security — instead of the old “trial and error” approach use A/B testing, beta tests, active feedback gathering, or reduced number of support tickets opened by users.
- Utilise usable security champions — professionals with interdisciplinary knowledge in usability and security as well as taking care of usable security.
- Usable Security Defaults and Tooling — The general approach of “security by default” principle should be turned into”usable security by default” instead.
Long-standing usable security advocate and researcher Angela M. Sasse has sparked my interest in this topic 5 years ago. In November 2022 she published a paper entitled How Does Usable Security (Not) End Up in Software Products? The research is about the underlying reasons why usable security doesn’t make it into the Software Development Life Cycle (SDLC), and I will summarise the main findings below.
Table of Contents
1. The Problem
2. The Proposal
3. Influencing Factors
4. Structure that Hinder Usable Security
5. Recommendations
The Problem
Many unusable security mechanisms have caused problems in the past. For example it was demonstrated in a 1999 paper that the target users of PGP 5.0 were not able to operate it securely and identified the usability issues that were the cause. While authentication and encryption for end-users have improved, people in some organisations still struggle with impossible security tasks and are blamed for their inability to cope.
Despite all of the above, little attention has been paid to making security features usable, and previous research has shown problems with poorly designed warning messages, passwords, and misconceptions about security implementation by developers.
The academic research and Cybersecurity community should help bridge the gap between their expertise and knowledge and the software industry.
The Proposal
The research proposal emphasises that software must be both secure and usable for users to appropriately use security features.
Developers and designers play a crucial role in implementing usable security features during the software development process, by taking into account the human factor.
To improve the adoption of usable security, there needs to be better awareness and interdisciplinary collaboration between academia and industry, along with measures that support a holistic usable security process — such as changes to the software development process (SDP) and resources.
Influencing Factors
The paper identified the following as the main influencing factors for security and usability not being integrated in software.
- A high impact of contextual factors, such as stakeholder pressure, presence of expertise, and collaboration culture
- Individual factors — awareness and skill sets
Lack of Awareness
There is an apparent misunderstanding of the connection between usability and security, which suggested having to sacrifice one to achieve the other.
Some participants stated usability not to be a specific skill set, but some common knowledge developers would implicitly have.
Missing knowledge
The research showed a lack of usability security knowledge in many software teams. Even in the face of limited resources and time constraints, developers could engage with usability for security features by applying established heuristics such as Nielsen’s “10 Usability Heuristics for User Interface Design”.
Communication Barriers
Usable security is an interdisciplinary field where knowledge from both domains must be brought together to craft an effective security mechanism that does not over-burden end-users.
Usability expertise was available in the form of specialists, but individual development teams did not consult them. When usability was seen as easy, consulting experts was considered a waste of time.
Culture and Contextual Factors
- Company culture as a reason that security best practices are not followed in software development life cycles (SDLC)
- Security processes being followed depends more on organisational processes than individual developers
- Good communication between penetration testers and software testers is important for finding vulnerabilities, leading to better security outcomes
- Usability was perceived as less important than security and common sense, i.e., not requiring specialist knowledge or skills
Structures that Hinder Usable Security
The paper also identified the following structures that hinder usable security.
Limited Resources
- Budget — usable security cannot be achieved when even basic security cannot be realised within existing budgets
- Time — general time pressure during their work as well as deadlines. This lack of time inevitably leads to higher-priority tasks being attended to first. Usable security rarely has priority.
- Functionality first — the prioritisation of features and functionality, to the detriment of usable security. Functionality is the key selling point for software and the deciding factor when competing with other companies, the fact that its usable security is never attended to before budgets run out should raise concerns in development companies and their customers.
Misconceptions
The interviews revealed several misconceptions about usable security and also about usability itself.
If software developers do not understand what usable security is, we cannot expect them to carry out the steps needed to deliver it.
Similar to other research, participants believed in the trade-off myth for usable security (usability and security have to be weighed against each other). Usable security research has provided ample evidence that and how security systems that are difficult to use end up being circumvented or compromised by users. The research results indicate that developers do not yet understand this.
Communication Barriers
Implementing usable security requires knowledge and skills in both security and usability. Individuals rarely have knowledge and skills in both, so development organisations have to take steps to ensure a development project has access to those skills.
Problems in understanding the respective other profession resulting from fractured knowledge — it is essential to combine both (usability and security) in the SDP to actually achieve usable security. Conflicts, therefore, have to be overcome by respecting and understanding each other.
Recommendations
Different types of interventions are needed to help software teams climb the competence curve:
- Build up awareness for usable security
- Impart knowledge to those involved
- Integrate and consolidate measures into the company’s daily routine
Create awareness
Companies were not aware of the important interplay of usability and security. Instead, they made usable security decisions unconsciously.
The fact that decisions about usable security are often made unconsciously reinforces the assumption that awareness is fundamental to start a conversation about usable security and, consequently, to actively make decisions adapting the SDP towards usable security.
Nevertheless, awareness alone is not sufficient to change behavior and establish habits that support usable security. Changing employees’ habits and routines is complex and requires resources. One way to do this can be to apply behavioural change intervention strategies.
Understanding User Context
To improve communication between security and usability experts, tools such as personas or scenarios, known for decades as communication and modelling tools, are particularly suitable for helping software professionals to understand their users’ needs, experiences, behaviours, and goals.
Integrating Usable Security with SDCL
Usable security should become part of the SDP early on. For example, usable security should be explicitly included in requirements engineering and addressed in early discussions with customers and other stakeholders — ideally from the very beginning. The requirements which are handed over to development teams, along with their level of detail, substantially determine the extent of available resources and the scope for interpretation of usable security.
Measure and Track Usable Security
There are no explicit measures to assess usable security. Therefore it is recommended to use conventional usability evaluation methods for security features to assess products’ usable security. This could include but is not limited to A/B testing, beta tests, or active feedback gathering, or reduced number of support tickets opened by users after a major redesign. Performing regular usable security measurements as part of the SDP may also prevent a trial-and-error approach and save resources.
Usable Security Champions
Usable security champions have interdisciplinary knowledge in usability and security as well as taking care of usable security. A usable security champion may not be needed when there is enough knowledge and skills for usability and security in the team and the respective members are collaborating.
Usable Security Defaults and Tooling
A general approach from the security area is the security by default principle. The research suggests transferring this to usable security by default.
For example, a web framework might have a module for user authentication. Extending this by usable security principles would allow software creators to easily create a secure and usable software feature out of the box, requiring little or no effort. Consequently, this approach appears suitable for those unaware of usable security or unable to climb the competence curve.
The current software development ecosystem lacks this support, as there is no tooling, no special documentation, guidelines, or standards for usable security. The paper proposes to create guidelines and checklists for usable security in specific use cases. These then can be incorporated into tools and frameworks.
Recommendations for Human Factors in Security Research
Research should move beyond developer training, education, and support, which is indeed an important approach. However, the research advocates for the research and development interventions that target the production context as a whole and not only single steps from the SDP like the coding by developers.
Researchers can support arguments for usable security in teams by developing measurable goals, actions, and interventions.
Even more importantly, using a tool is often easier than learning new skills or changing a mindset, but building a mindset for usable security might be more sustainable.
If you enjoyed this and would like to see more in the future, please share and subscribe.
Disclaimer: The information provided in this article is solely the author’s opinion.
