Shamal Faily
Designing Usable
and Secure
Designing Usable and Secure
Software with IRIS
and CAIRIS
Shamal Faily
Department of Computing & Informatics Bournemouth University
Poole, Dorset UK
ISBN 978-3-319-75492-5 ISBN 978-3-319-75493-2 (eBook) https://doi.org/10.1007/978-3-319-75493-2
Library of Congress Control Number: 2018938649
©Springer International Publishing AG, part of Springer Nature 2018
This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use.
The publisher, the authors and the editors are safe to assume that the advice and information in this book are believed to be true and accurate at the date of publication. Neither the publisher nor the authors or the editors give a warranty, express or implied, with respect to the material contained herein or for any errors or omissions that may have been made. The publisher remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.
Printed on acid-free paper
This Springer imprint is published by the registered company Springer International Publishing AG part of Springer Nature
Foreword
It is seldom the case in software engineering that we encounter a book that is relevant to practitioners, researchers and educators. Most books will either focus on the practitioner audience or the researcher/educator audience. This book is a wel-come addition to the small set of books in ourfield that are relevant to all of these audiences. Regardless of which lifecycle model you use, if you are at all concerned with security and usability (and you should be!), this book is relevant to you.
I especially liked the mapping of the material in the book to its use by practi-tioners, researchers and educators. Since I have had all of those roles over the course of my career, I know how important it is to be able to focus on the topics of interest to me, and to be able to skim the others. Naturally, those of us who have written books would like our readers to read the entire book, but when we put ourselves in the shoes of our readers, we realise that we seldom have the time to do this.
The requirements engineering research community is vibrant but relatively small —a few hundred researchers, almost all of whom know one another. When we focus specifically on security and usability, as it relates to specification and design, the field becomes even more specific. This book is a welcome addition to the relatively small number of books that focus on security and usability in design.
The vast majority of the literature in the area consists of journal and conference research papers. The educational material tends to consist of tutorials, a few lec-tures, and maybe a course or two here and there. One of the significant contribu-tions of this book is to provide an excellent source of information about security and usability in requirements and design, with copious references. It also provides a combination of overview material and more detailed explanations, depending on the subject at hand.
The first few chapters provide a nice overview of the security and usability concepts needed to understand the remainder of the book. In Chap. 3, the IRIS meta-model is introduced. I particularly liked the table with the core concepts of IRIS and the description of each. So often terminology is introduced without any explanation whatsoever, but that is not the case here. In Chap.4, the IRIS process framework is introduced. The associated perspectives on usability, requirements
and security are all discussed, and then in Chap.5 the tool support provided by CAIRIS is introduced. The discussion of personas and scenarios in Chap.6sets the stage for the case studies that follow.
The case studies help to make the methodologies more useful to practitioners, and from a practitioner perspective, tool support is essential. Paper exercises are OK for the classroom, but when large complex systems are under development, tool support is needed. Remaining chapters delve into architectural risk analysis, design issues and future research challenges.
All in all this book is an excellent choice for those who need to be concerned with security and usability, and that is just about everyone! This book is especially useful during the early lifecycle activities of requirements engineering, architecture and high-level design. In fact, given the current focus on security and usability, I think this book is a good choice for all systems and software engineers. It will expand your horizons.
Pittsburgh, PA, USA March 2018
Preface
Why do We Need This Book?
Everyone agrees that security needs to be considered as early as possible when designing any form of technology. Unfortunately, the security industry has been so effective at promoting stories about potential ‘digital Pearl Harbours’ and astro-nomical costs of cybercrime to national economies that many people are being paralysed into inaction, or pushed into irrationality when thinking about security. Given the demands to deliver more, sooner, with fewer resources, it can be appealing to suspend disbelief and trust that a piece of technology which promises the moon and costs the earth really will mitigate the latest threats,fit seamlessly into our enterprise's infrastructure, or otherwise ‘add value’. Alternatively, one might treat scare stories as noise, and—as Cormac Herley once wrote1—conclude that the rational thing to do is ignore any advice that has been given. Unfortunately, relying on such shortcuts means that a product or service may fail to protect things of most value to us when we need them most.
When technology fails or is at risk of failing, it can also be tempting to blame the person interacting with it, i.e. blaming the user for committing a human error. However, if security is to be built-in to technology then it needs to respect the goals and demands of those that rely on it. This means rather than treating users as the ‘weakest link’in security, a system design should consider the characteristics of its direct or indirect users. Unfortunately, as hard as building security it can be, it appears building both usabilityand security are even harder. Platitudes like ‘you should think of security and usability up-front’are prescribed frequently, but useful best practice or case study examples seem to be in short supply. Identifying the
1Herley C. So Long, and No Thanks for the Externalities: The Rational Rejection of Security Advice by Users. In: NSPW ‘09: Proceedings of the 2009 New Security Paradigms Workshop. ACM; 2009. pp. 133–144.
form that design techniques and tools might take to demonstrably incorporate security and usability into the earliest stages of software design was the main motivation for devising IRIS and CAIRIS.
What are IRIS and CAIRIS?
IRIS (Integrating Requirements and Information Security) is a process framework that can be used to devise processes for designing usable and secure software. CAIRIS (Computer-Aided Integration of Requirements and Information Security) is a software platform for eliciting, specifying and validating secure and usable systems. It was built from the ground up to support IRIS, and includes the elements necessary for usability, requirements and risk analysis.
The book contains everything you need to understand what IRIS and CAIRIS are, and how you can use the two to design usable and secure software at an early stage. However, despite the book’s title, this book is more than just a playbook for IRIS, or a manual for CAIRIS. The book was written to show how design activities can attend to both security and usability without sacrificing one for the other, or sacrificing one or both for innovation of functionality. As such, IRIS and CAIRIS are exemplars for design frameworks and software tools for secure and usable design, not thefinal word.
Assumed Background
This book assumes you have some background or general interest in Security Engineering, Usability or Requirements Engineering, and are motivated to learn more about the other two. You are not expected to be an expert in any of these areas.
Those wanting a general overview of thefield of Security Engineering willfind Security Engineering: A Guide to Building Dependable Distributed Systems by Ross Anderson (2nd Edition, Wiley, 2008) useful. Because Threat Modelling techniques are useful when designing for security, readers may also be interested in Threat Modeling: Designing for Securityby Adam Shostack (Wiley, 2014), as well asSecuring Systems: Applied Security Architecture and Threat Models by Brook Schoenfield (CRC Press, 2015).
Many options exist for those wanting an overview of thefield of Usability and related design topics;Interaction Design: Beyond Human-Computer Interactionby Jenny Preece, Helen Sharp and Yvonne Rogers (4th Edition, Wiley, 2015) provides both good coverage of the field, together with practical advice on the techniques covered in the book.
in general—thenRequirements Engineering: From System Goals to UML Models to Software Specifications by Axel van Lamsweerde (Wiley, 2009) provides a useful overview of what Requirements Engineering can offer to design. Those desiring more hands-on advice on the art of eliciting, specifying and validating requirements would benefit greatly from Mastering the Requirements Process: Getting Requirements Right by Suzanne and James Robertson (3rd Edition, Addison-Wesley, 2012); this book is also the authority on the Volere framework, which informed how IRIS and CAIRIS deal with requirements.
When devising an IRIS process, it is also assumed you have some knowledge or experience on the design techniques that form the basis of the process. To illustrate the adaptation of usability design techniques, this book covers the persona tech-nique in some depth; other techtech-niques are given a lighter treatment. References are, however, provided at the end of each chapter for readers interested in using the framework techniques discussed in Sect.4.3.
How to Use This Book
This book was written to be read from cover-to-cover, but you can still skip to certain chapters based on your background and interests.
Practitioners
Chapter1will help you put this book in context, and provides a roadmap for where to read next. If your focus is usability and incorporating interaction design for security, then Chap. 4 provides guidance on getting up and running with IRIS processes, and Chap.6—using personas and scenarios as examples—provides ideas about how design techniques can be adapted to provide assurance necessary to support security decision-making.
If your background is in security, and you want ideas for incorporating Human Factors into your work, looking at how CAIRIS provides tool support for risk and task analysis in Chap.5will provide some inspiration, together with Chap.9, which shows how security and usability can be incorporated into later stages of software design. You will also find that Chap. 11 provides practical advice on tackling security problems by treating solutions as innovations.
Irrespective of your background, you willfind the case study chapters (Chaps.7, 8and10) useful for seeing how security and usability processes and tools work in practice. If, while reading this book, you need more background material on why certain concepts are related in IRIS and CAIRIS, then Chap.3will provide a useful aide-memoire.
Researchers
For those wishing to leverage or extend IRIS and CAIRIS, Part I will put whatever knowledge you have in context with complementary areas of design. The case study chapters will also put IRIS and CAIRIS in context; they illustrate the use of IRIS and CAIRIS, and present lessons learned as directions for future research.
Thefinal chapters of this book describe numerous opportunities for future work. For example, Chap. 11 will benefit researchers in Security Economics by illus-trating how economics and entrepreneurship can benefit each other. For researchers interested in the future potential of tool support for usable and secure design, then Chap.12provides examples of how the CAIRIS platform facilitates research and design in areas such as system-of-system engineering, practice integration with DevOps and the provision of rich exemplars for evaluating research as well as design.
Educators and Students
This book was also written to support advanced undergraduate or postgraduate teaching in HCI-Security. The material in this book has already been used at Bournemouth University in a one-semester (10 weeks) course onSecurity by Design taken byfinal year students on the Forensic Computing and Security undergraduate degree programme, and postgraduate students on the Cyber Security and Human Factors postgraduate degree programme. The Indicative Learning Outcomes (ILOs) for that course are
1. Select and critically evaluate the usability criteria that security mechanisms have to meet to be usable in their contexts of use.
2. Apply techniques from interaction design and security engineering to design and evaluate secure systems.
3. Devise and evaluate supplemental measures that an organisation needs to ensure long-term, productive security.
The material used to satisfy ILOs 1 and 3 is heavily inspired by a course on People and Securitydesigned by Angela Sasse that I once had the opportunity to deliver to students at University College London and the University of Oxford; this material is drawn from the academic literature in HCI-Security, Information Security and Economics of Information Security.
Using and Contributing to CAIRIS
This book illustrates the capabilities of CAIRIS, but does not go into the installa-tion, setup and general use of the tool in any depth. You can, however,find full instructions on how to setup and use the platform on the CAIRIS website:https:// cairis.org.
CAIRIS is an open-source software product. The source code has been released under an Apache License, and is freely available on GitHub. Raising an issue on the CAIRIS GitHub site is strongly encouraged if you find any problems with the software or its documentation. As an open-source project, CAIRIS is sustained by its community of developers and users. There are many ways interested readers can make a contribution to CAIRIS, from proposing new enhancements, raising bug reports or even contributing pull requests for any typographic errors or inconsis-tencies found in the available documentation. No contribution to CAIRIS is too small.
Acknowledgements
The doctoral research that led to initial versions of both IRIS and CAIRIS was funded by EPSRC CASE Studentship R07437/CN001. I am very grateful to EPSRC and QinetiQ Ltd. for the sponsorship of this work. I am also grateful to the Department of Computer Science at the University of Oxford and Wolfson College for additional sponsorship of fieldwork and conference-related activities while Table 1 Material from this book used to support a course onSecurity by Design
Lecture Material used
Introduction Challenges designing usable and secure software in Chap.1are used to motivate the course
Design techniques and tools
Material in Chap.6on personas and misusability cases provide examples of adapting interaction design techniques for security Requirements Examples of Security Requirements Engineering techniques and frameworks from Chap.2, together with the IRIS framework in Chap.4. The IRIS meta-model in Chap.3illustrates the rela-tionship between Security, Usability and Requirements Engineering concepts
User Interfaces Processes and tools for risk and task analysis with CAIRIS in Chap.5
Architecture Patterns and processes associated with Architectural Risk Analysis in Chap.9, and the end-to-end webinos case study in Chap.10
Security economics and entrepreneurship
Chapter11is the reading for the Security Entrepreneurship component of this lecture
presenting this early work. Thanks go to Annamaria Carusi, Marina Jirotka, Angela Sasse and Andrew Simpson for their detailed and insightful comments on this work during its evolution from doctoral studentship proposal to submitted and corrected DPhil thesis. I would like to give special thanks to Dr. Ivan Fléchais, for his advice and encouragement, not only while carrying out the initial work leading to IRIS and CAIRIS, but follow-on work that took place at both Oxford and Bournemouth.
I am grateful to everyone on the DSS project, as well the water company behind the ACME name for allowing themselves to be used as case studies for evaluating IRIS and CAIRIS,finding the time to support myfieldwork, and provide feedback on the deliverables resulting from the respective IRIS processes applied. I am also grateful to everyone on the EU FP7 webinos project (FP7-ICT-2009-5 257103) for their support. The webinos project provided an important case study in the evo-lution of IRIS and CAIRIS; it provided a useful testbed for CAIRIS, and led to numerous improvements to the platform. The use of IRIS and CAIRIS to support the end-to-end design and development of webinos over its 3-year life also provided one of thefirst published long-term case studies for security and usability design. The work described on Security Entrepreneurship in Chap.11 was carried out while participating in the EPSRC sponsoredScience Innovation Programmeat the University of Oxford. The aim of the programme was to get research ideas out of the lab and into the next generation of technology innovation. However, after noticing the analogies between how technology entrepreneurs and security practi-tioners solve problems, I felt it necessary to get ideas on technology innovation out of practice and into the next generation of security research instead! I am grateful to Marc Ventresca and Victor Seidel at the Entrepreneurship Centre in the Säid Business School for their comments and insights on this work.
The on-going evolution of CAIRIS has benefitted from the generous assistance of the UK Defence Science and Technology Laboratory (Dstl). They provided invaluable feedback and comments on research resulting from the EPSRC-funded Evaluating the Usability, Security, and Trustworthiness of Ad-hoc Collaborative Environments (EUSTACE)project, which led to the work on trust modelling and trust expectations described in Sect. 12.1. More recently, they have supported on-going work on the use of CAIRIS to support risk assessment for systems of systems, which is briefly discussed in Sect.12.1.
I would like to thank everyone who reviewed early drafts of this book for their suggestions for improving the presentation of this book, and smoothing away many rough edges: Andrea Atzeni, Benjamin Aziz, Huseyin Dogan, Michael Eaton, Jane Henriksen-Bulmer, Duncan Ki-Aries, Nancy Mead, Simon Parkin, Adam Shostack, Jacqui Taylor and Eylem Thron. I am particularly grateful to Andrew Simpson, whose comments and attention to detail went well beyond the call of duty.
On a personal note, I would like to thank my parents for their patience, support and love. Last, but by no means least, I would like to thank Claudia for her love, and for always being there for me.
Poole, UK Shamal Faily
February 2018
Part I Foundations
1 Why Designing for Usability and Security is Hard. . . 3
1.1 Empowering the System Builders . . . 3
1.2 Ubiquitous Technology. . . 4
1.3 Integrating Processes. . . 4
1.4 Growing Interests in Usable Security. . . 5
1.5 IRIS and CAIRIS as Exemplars for Usability, Security, and Requirements Engineering Process and Tool Integration . . . 5
1.6 Book Structure. . . 6
1.6.1 Part 1: Foundations . . . 6
1.6.2 Part 2: IRIS and CAIRIS . . . 6
1.6.3 Part 3: Beyond Requirements . . . 7
References . . . 8
2 Usable and Secure Software Design: The State-of-the-Art . . . 9
2.1 Towards Usable Security Design . . . 9
2.1.1 Themes in Information Security Design. . . 9
2.1.2 Usable Security . . . 11
2.1.3 A Case for Better HCI Integration?. . . 14
2.2 Usability Design. . . 15
2.2.1 HCI and Usability . . . 15
2.2.2 User-Centered Approaches . . . 17
2.2.3 Human-Centered Software Engineering . . . 22
2.3 Specifying Security. . . 23
2.3.1 Problem Frames. . . 24
2.3.2 Goal-Oriented Approaches . . . 27
2.3.3 Use Cases . . . 35
2.3.4 Other Related Security and Usability Approaches. . . 37
2.4 Specification Frameworks . . . 39
2.4.1 RESCUE. . . 40
2.4.2 SQUARE. . . 41
2.5 Tool-Support . . . 42
2.5.1 Usability Design Tools. . . 42
2.5.2 Security Requirements Engineering Tools . . . 43
2.5.3 Visualising Design. . . 44
2.6 Summary . . . 45
References . . . 46
3 A Conceptual Model for Usable Secure Requirements Engineering. . . 55
3.1 Introducing NeuroGrid . . . 55
3.2 Overview . . . 56
3.3 Environment Meta-Model . . . 57
3.4 Asset Meta-Model. . . 59
3.5 Task Meta-Model . . . 60
3.6 Goal Meta-Model . . . 63
3.7 Risk Meta-Model . . . 66
3.8 Responsibility Meta-Model . . . 69
3.9 Summary . . . 70
References . . . 71
Part II IRIS and CAIRIS 4 The IRIS Framework . . . 75
4.1 Perspectives . . . 75
4.2 Converging Concepts . . . 77
4.3 Framework Techniques. . . 77
4.3.1 Grounded Theory. . . 79
4.3.2 Personas . . . 80
4.3.3 Activity Scenarios . . . 80
4.3.4 Rich Pictures . . . 81
4.3.5 KAOS. . . 82
4.3.6 Volere Requirements Specification . . . 83
4.3.7 Use Cases . . . 84
4.3.8 AEGIS . . . 85
4.3.9 Misuse Cases. . . 86
4.4 Summary . . . 86
References . . . 87
5 Introducing CAIRIS: Tool-Support for Designing Usable
6 Adapting Personas and Scenarios for Security and Usability Design. . . 119
6.1 Building Personas. . . 119
6.1.1 Step 1: Identify Factoids from Source Data . . . 120
6.1.2 Step 2: Affinity Diagram Factoids to Identify Behavioural Clusters. . . 120
6.1.3 Step 3 (Optional): Affinity Diagram Behavioural Cluster Categories . . . 121
6.1.4 Step 4: Categorise Behavioural Clusters by Behavioural Variables. . . 122
6.2.3 Applying and Refining the Assumption Personas. . . 124
6.3 Persona Cases. . . 126
6.3.1 Building Persona Cases . . . 127
6.3.2 Illustrated Example. . . 128
6.4 Supporting the Persona Creation Workflow with CAIRIS . . . 131
8 Case Study: Defending Critical Infrastructure Against Stuxnet . . . 155
8.1 About ACME Water. . . 155
8.1.1 Instrumentation and Instrument Technicians. . . 156
8.3.1 Scoping. . . 162
10.4 Building Security into Webinos. . . 201
10.4.1 Context of Use Analysis. . . 201
10.4.2 Supporting Initial Requirements Elicitation and Specification . . . 204
10.4.3 Participatory Risk Analysis. . . 205
10.4.4 Analysing the Webinos Software Architecture . . . 206
10.4.5 Supporting Platform and Application Development . . . 207
10.4.6 Releasing Webinos Design Data . . . 208
10.6.1 Learn to Work with Sub-optimal Data and Expertise. . . 214
10.6.2 Security Increases Sensitivity to Usability Problems . . . 214
10.6.3 Designing for Usability and Security Takes Time. . . 215
10.6.4 Design Research is a Key Element of Designing of Usability and Security . . . 215
11.3 Security Entrepreneurship and the Security Entrepreneur. . . 222
11.4 Security Entrepreneurship Techniques . . . 224
11.5.1 Security Entrepreneurship Considered Harmful?. . . 234
11.5.2 How Should Security Entrepreneurship be Situated with Other Design Activities?. . . 234
11.5.3 How is Security Entrepreurship Validated? . . . 235
11.5.4 Can Security Economics Help?. . . 236
11.6 Summary . . . 236
References . . . 237
12 Further Applications of CAIRIS for Usable and Secure Software Design . . . 239
12.1 Environments as Stakeholder Perspectives in Systems of Systems. . . 239
12.2 Threat Modelling . . . 240
12.3 Trust Modelling . . . 242
12.4 Realising“Design as Code”. . . 244
12.4.1 Creating Assured Personas . . . 246
12.4.2 Discovering Risks from Attackers and Threat Models . . . 248
12.4.3 Contextualising the Implication of Security and Usability Design Decisions. . . 248
12.4.4 Implications for CAIRIS. . . 251
12.5 Human-Centred Specification Exemplars . . . 251
12.5.1 Design Principles for Human-Centred Specification Exemplars . . . 252
12.5.2 Evaluating Research with Human-Centred Specification Exemplars . . . 252
12.5.3 Human-Centred Specification Exemplars and Archetypes . . . 253
12.6 Summary . . . 253
References . . . 254
List of Figures
Fig. 2.1 ISO 9241-11 usability framework. . . 16 Fig. 2.2 Human-centered design activities [52] . . . 18 Fig. 2.3 Example of a security requirement (modelled as an ellipse)
constraining a context, modelled as a problem frame
diagram [98]. . . 25 Fig. 2.4 KAOS goal model example . . . 28 Fig. 2.5 i* strategic dependency model example. . . 31 Fig. 2.6 i* strategic rationale model example. . . 32 Fig. 2.7 Use case model example. . . 35 Fig. 3.1 Architectural overview of NeuroGrid . . . 56 Fig. 3.2 Environment meta-model . . . 58 Fig. 3.3 Asset meta-model. . . 59 Fig. 3.4 Comparative asset values across environments. . . 60 Fig. 3.5 Task meta-model . . . 61 Fig. 3.6 Task meta-model example . . . 62 Fig. 3.7 Goal meta-model . . . 63 Fig. 3.8 Goal model example. . . 65 Fig. 3.9 Risk meta-model. . . 66 Fig. 3.10 Risk model example. . . 68 Fig. 3.11 Responsibility meta-model . . . 69 Fig. 3.12 Responsibility model example . . . 70 Fig. 4.1 IRIS perspective concepts. . . 76 Fig. 4.2 Mapping between Volere and IRIS requirements
specification templates . . . 84 Fig. 5.1 CAIRIS screenshot. . . 92 Fig. 5.2 Textual view of CAIRIS model objects . . . 93 Fig. 5.3 Finding and updating for model elements. . . 94 Fig. 5.4 Graphical view of CAIRIS model objects. . . 94 Fig. 5.5 Component diagram of key CAIRIS components. . . 95 Fig. 5.6 Pipeline for visual model generation. . . 96 Fig. 5.7 Physical deployment diagram of CAIRIS. . . 97
Fig. 5.8 Asset model example . . . 106 Fig. 5.9 Task model example. . . 107 Fig. 5.10 Goal model example. . . 108 Fig. 5.11 Obstacle model example. . . 109 Fig. 5.12 Risk (top, red) and task usability (bottom, blue) colour
charts . . . 109 Fig. 5.13 Risk analysis model before risk mitigation. . . 110 Fig. 5.14 Risk analysis model after risk mitigation . . . 112 Fig. 5.15 Responsibility model example . . . 113 Fig. 5.16 Importing a template OWASP threat into the current model. . . . 114 Fig. 5.17 Threat and vulnerability directory XML schema. . . 115 Fig. 5.18 Project meta-data stored by CAIRIS. . . 116 Fig. 6.1 An affinity diagramming exercise. . . 121 Fig. 6.2 Conceptual model of assumption persona data. . . 125 Fig. 6.3 Toulmin model visualisation based on an individual
characteristic. . . 125 Fig. 6.4 Contribution of Grounded Theory to personas . . . 129 Fig. 6.5 Misusability case with other design concepts. . . 132 Fig. 6.6 IRIS task meta-model updates for misusability cases . . . 133 Fig. 7.1 Instantiated process for the Data Directory specification. . . 140 Fig. 7.2 Characteristics and argumentation structure underpinning
a misusability case . . . 145 Fig. 7.3 Misusability case contribution to goal model . . . 147 Fig. 8.1 IRIS process for the plant operations security policy . . . 161 Fig. 8.2 Finalised context diagram bounding the analysis
for the security policy. . . 163 Fig. 8.3 Grounded theory model of plant operations staff security
perception. . . 165 Fig. 8.4 Asset model associated with the security policy. . . 166 Fig. 8.5 Goal tree associated with exposed cabinets vulnerability . . . 169 Fig. 8.6 Penetration tester attacker profile . . . 170 Fig. 9.1 Architectural patterns meta-model. . . 181 Fig. 9.2 Contextualised attack patterns meta-model. . . 183 Fig. 9.3 Deployment diagram of NeuroGrid WebDAV architecture. . . 188 Fig. 9.4 Goals associated with WebDAV component. . . 189 Fig. 9.5 Component and Connector view of WebDAV architectural
pattern. . . 190 Fig. 9.6 Assets associated with WebDAV server component. . . 191 Fig. 9.7 Obstacle model associated with Upload Malware attack
Fig. 10.5 Consolidated concept map of requirements. . . 213 Fig. 11.1 The innovation ecosystem. . . 220 Fig. 11.2 Site authenticationware chindōgu. . . . 226 Fig. 11.3 Ontology chart of chindōgu affordances. . . . 227 Fig. 11.4 Innovation value-added chain for stakeholder groups. . . 229 Fig. 11.5 Existing security data social-network (left), and a
social-network optimised for X.509 and XACML (right). . . 230 Fig. 11.6 Misusability case argumentation model motivating
a security premortem . . . 233 Fig. 12.1 DFD associated with broken instrument alarms during
the day. . . 242 Fig. 12.2 A GRL model generated by CAIRIS within jUCMNav.
The zoomed portion illustrates the impact of a strategy . . . 245 Fig. 12.3 Generated requirements specification document, which
includes persona definitions and underpinning
argumentation models. . . 247 Fig. 12.4 Enumeration threat modelled as an attack tree (left),
and KAOS goal model integrating threat model
into the network security requirements (right). . . 249 Fig. 12.5 Editing assets . . . 250 Fig. 12.6 Visualising a task’s security impact . . . 250
Table 2.1 ISO 9241 usability definitions . . . 16 Table 3.1 IRIS meta-model core concepts . . . 57 Table 3.2 ISO 27001 definitions for confidentiality, integrity,
and availability. . . 59 Table 4.1 Techniques overview. . . 78 Table 5.1 Principle to characteristic mapping. . . 98 Table 5.2 Task usability properties. . . 99 Table 5.3 Countermeasure task usability properties . . . 100 Table 5.4 IEC 61508 table for threat likelihood, vulnerability
severity, and risk rating . . . 101 Table 5.5 IEC 61508 table for risk categorisation based
on likelihood and severity . . . 101 Table 5.6 Project meta-data supported by CAIRIS. . . 116 Table 6.1 Behavioural variable types. . . 122 Table 6.2 Elements of Toulmin’s argumentation model. . . 123 Table 6.3 Characteristic argument example . . . 130 Table 7.1 Design session summary . . . 143 Table 7.2 Persona characteristics summary by behavioural variable
type . . . 149 Table 7.3 Document and concept references associated
with personas. . . 149 Table 7.4 IRIS concepts specified on completion of the DSS
case study. . . 150 Table 8.1 In-situ interview summary . . . 164 Table 8.2 Policy goal examples. . . 165 Table 8.3 Tasks performed by plant operator persona . . . 168 Table 8.4 Vulnerabilities and affected assets . . . 168 Table 8.5 IRIS concepts specified on completion of the plant
operations security policy case study . . . 172 Table 9.1 Damage-Effort Ratios. . . 182 Table 9.2 DERiinput data . . . 191
Table 9.3 Upload Malware attack pattern. . . 192 Table 9.4 Leaf obstacles and mitigating requirements . . . 195 Table 10.1 Webinos architectural patterns . . . 206
Chapter 1
Why Designing for Usability and Security
is Hard
Abstract In this chapter, I summarise the challenges that make designing for usabil-ity and securusabil-ity hard, and outline the structure of this book.
1.1
Empowering the System Builders
The effect of Information Technology on our lives can be seen all around us. The increasing ubiquity of technology has also led academic researchers to re-think our interaction with it. In a 2009 Communications of the ACM article [1], several leading Human Computer Interaction (HCI) researchers noted that our relationship with computers has changed so radically since the field’s inception that even the term
HCI needs a rethink. In the past, we could reasonably assume that IT involved desktop computers andusersin commercial organisations. Nowadays, systems are as ubiquitous as the people who use them, who are increasingly connected with different people and other systems. In such a connected world, the users of technology have incalculable opportunities to intentionally or unintentionally interact with a myriad of systems.
One question which has yet to be answered is how much Information Technology has empowered the work of those who build it. Media reports about the growth of high technology industry go almost hand-in-hand with reports about the impact of threats to it. For example, a report commissioned by the UK government estimated that the cost of cyber crime to the UK economy is £27 billion per annum [2]. While the methodologies used to devise this figure are debatable, the increased burden of expectation on system designers is not. As consumers, we expect systems to be attuned to the physical and social contexts within which they are used. As a corollary, we would also like our systems to be as secure as they are usable but, as we have discovered, threats to, and vulnerabilities within, this complex network of people and technology make this a challenging task for system builders.
© Springer International Publishing AG, part of Springer Nature 2018 S. Faily,Designing Usable and Secure Software with IRIS and CAIRIS, https://doi.org/10.1007/978-3-319-75493-2_1
1.2
Ubiquitous Technology
Systems can be made vulnerable through a variety of factors, ranging from the accidental introduction of incorrect code, through to an overly complex user inter-face which may be misused or circumvented. Those who might take advantage of these vulnerabilities have capabilities and motivations which may be unknown to the designers who inadvertently introduced them, together with different abstrac-tions for what the vulnerabilities are and how they can be exploited. So, while our expectations for technology innovation continue to be exceeded, the quality of these systems’ security and usability often falls short.
There is no obvious reason why designing secure and usable systems should be so difficult, especially when guidance on applying Security and Usability Engineering best practice is no longer restricted to the scholarly literature. Nielsen claimed that cost was the principal reason why Usability Engineering techniques are not used in practice [3], but the financial costs of applying such techniques may not have been reduced by technology advances. Similarly, practical techniques for identifying and mitigating security problems during system design are now available to developers in an easy to digest format, e.g. [4,5].
1.3
Integrating Processes
Problems arise when considering how to use these approaches as part of an integrated process. Accepted wisdom in Software Engineering states that requirements anal-ysis and specification activities should precede other stages in a project’s lifecycle [6]. However, Information Security and HCI proponents argue that their techniques should instead come first. For example, ISO 13407 [7] states that activities focusing on the collection of empirical data about users and their activities should guide early design, but security design methods such as [8,9] suggest that such stages should be devoted to high-level analysis of the system to be secured. Invariably, the decision of what concern to put first is delegated to the methodology followed by a designer. The designer has many approaches to choose from, some of which include treatment for security or usability concerns. To date, however, no approach treats both security and usability collectively, beyond treating them both as generic qualities contending with functionality.
1.4 Growing Interests in Usable Security 5
1.4
Growing Interests in Usable Security
There is mounting evidence that the design of usable and secure systems is worthy of specific attention. The US Department of Homeland Security ranked usable secu-rity as one of the top cyber-secusecu-rity research topics for governments and the private sector [10], and HCI-Sec (HCI for Security) continues to be an active research topic. Researchers are also beginning to consider how developers should build secure and usable systems [11], and even governments are recognising the role developers play in securing software [12]. Despite this interest in developers, yet there remains a lack of guidance available to designers about how to design usable systems at a sufficiently early stage in the design process. Fortunately, despite the lack of guid-ance, the Security Requirements Engineering and HCI communities have proposed a number of individual techniques forming the basis of integrated design approaches. In theory, specifying and designing secure and usable systems involves carefully selecting the right techniques from each community. In practice, each technique is founded in different, potentially conflicting, conceptual models. The level of tool-support for these techniques also varies considerably, and there has been little work on integrating these tools and the conceptual models which underpin them.
The knowledge gleaned integrating design techniques and tools also leads to research contributions beyond the design of usable and secure systems. While there are academic fora devoted to integrating security and software engineering activities, e.g. [13], and HCI and security activities [14], there has been little work describing how usability design techniques can be usefully applied to designing secure systems. It is, therefore, possible that the results of integrating design techniques and tools may lead to design innovation in this area.
1.5
IRIS and CAIRIS as Exemplars for Usability, Security,
and Requirements Engineering Process and Tool
Integration
The book explores how existing techniques and tools might be integrated and improved to support the design of usable and secure systems. It shows how concepts from Usability, Security, and Software Engineering can be harmonised to support the design of secure and usable systems, discusses the characteristics of tool-support needed to support the design of secure and usable systems, and considers how User-Centered Design techniques be improved to support the design of usable and secure systems.
Information Security): a software platform for supporting these processes. I formally introduce both IRIS and CAIRIS in Part 2 of this book.
In Software Engineering, the termsystem designencompasses a broad range of activities; these range from scoping an early vision of what a system needs to do, through to developing models of software components and interfaces. We, therefore, primarily limit our focus on design to the early stages of a system’s development for two reasons. First, the termdesignoften refers to a plan or an outline of work, upon which a structure is built [15]; agreeing and specifying the nature of this plan is both required, and something best carried out as early as possible. Second, each discipline contributing techniques to the design of usable and secure systems argues for their own approaches preceding all others. Consequently, there is value in exploring how early design techniques interoperate together.
1.6
Book Structure
1.6.1
Part 1: Foundations
Chapter2reviews the current state-of-the-art in the design of usable and secure sys-tems. I consider existing work from the HCI Security community, and its limitations, before reviewing prevalent HCI concepts relevant to the design of secure systems. Given this book’s focus, I review several Requirements Engineering approaches from a security and usability perspective, before reviewing existing design frame-worksfor eliciting security and usability requirements. I conclude the chapter with a brief review of the available tool-support for facilitating Usability and Requirements Engineering activities.
Chapter3 presents a conceptual model for usable secure Requirements Engi-neering. This work builds upon practical work in usability design, and research on meta-models for Security Requirements Engineering. Collectively, the meta-model concepts help structure and manage Usability, Security, and Requirements Engineer-ing activities in different contexts. After presentEngineer-ing a brief overview of the conceptual model itself, I sub-divide the model explanation into six different views: Environ-ment, Asset, Task, Goal, Risk, and Responsibility. For each view, I present and justify the related concepts and their relationships.
1.6.2
Part 2: IRIS and CAIRIS
1.6 Book Structure 7
Chapter5presents CAIRIS (Computer Aided Integration of Requirements and Information Security), a software tool designed to embody the characteristics needed to support the IRIS framework. I briefly discuss the principles motivating the design of CAIRIS before presenting its high-level architecture. I then present several char-acteristics of tool-support for the specification of usable and secure systems, and illustrate how CAIRIS supports these.
Chapter6describes how personas and scenarios can be adapted for secure system design. I present a technique for aligning personas with the design of secure and usable systems. This technique,Assumption Persona Argumentation, describes how structured argumentation can be used to support the development and evolution of assumption personas. Building on this work, I presentPersona Cases: an approach for developing personas both grounded in, and traceable to, their originating empirical data. Also building upon both the IRIS meta-model and this argumentation structure, I present a technique calledMisusability Cases, scenarios which describe how design decisions lead to usability problems subsequently leading to system misuse.
Chapter7describes a study where IRIS and CAIRIS were used to specify security requirements for a portal facilitating the sharing of medical study data.
Chapter8reports on a study where IRIS and CAIRIS were used to analyse the security and usability impact of a security policy for control system software at a UK water company. This analysis was used to identify missing security policy requirements.
1.6.3
Part 3: Beyond Requirements
In Chap.9, I illustrate how IRIS can be used to not only elicit and specify security requirements but also, with the aid of architectural and attack patterns, and comple-mentary work on attack surface metrics and architectural risk analysis, we can secure software architectures as well.
Chapter10describes a long term case study where IRIS and CAIRIS played a role in the design and development of webinos: a web-based middleware for the Internet of Things.
In Chap.11, I look at the roleinnovationcan play when designing for security and usability, and introduce the paradigm ofSecurity Entrepreneurship. Much has been written about the role of economics for information security, but entrepreneur-ship and economics go hand-in-hand, and there is much that can be learned from technology and social entrepreneurship that can be applied to security problem solv-ing. This chapter shows how theory and models from technology innovation and entrepreneurship can be used and, in some cases, how IRIS and CAIRIS can be of assistance.
CAIRIS, to show the direction that future tools for usable and secure software design can take.
References
1. Sellen A, Rogers Y, Harper R, Rodden T. Reflecting human values in the digital age. Commun ACM. 2009;52(3):58–66.
2. Detica. The Cost of Cyber Crime: A Detics Report in Partnership with the Office of Cyber Security and Information Assurance in the Cabinet Office. UK Cabinet Office; 2011. 3. Nielsen J. Guerrilla HCI: using discount usability engineering to penetrate the intimidation
barrier. In: Bias RG, Mayhew DJ, editors. Cost-justifying usability. Morgan Kaufmann; 1994. p. 242–272.
4. Schneier B. Secrets and lies : digital security in a networked world. John Wiley & Sons; 2000. 5. Swiderski F, Snyder W. Threat modeling. Microsoft Press; 2004.
6. Ghezzi C, Jazayeri M, Mandrioli D. Fundamentals of software engineering. 2nd ed. Prentice Hall; 2003.
7. ISO. ISO/IEC 13407: Human-Centered Design Processes for Interactive Systems. ISO/IEC; 1999.
8. Fléchais I, Sasse MA, Hailes SMV. Bringing security home: a process for developing secure and usable systems. In: Proceedings of the 2003 new security paradigms workshop. ACM; 2003. p. 49–57.
9. den Braber F, Hogganvik I, Lund MS, Stølen K, Vraalsen F. Model-based security analysis in seven steps - a guided tour to the CORAS method. BT Technol J. 2007;25(1):101–17. 10. Maughan D. The need for a national cybersecurity research and development agenda. Commun
ACM. 2010;53(2):29–31.
11. Institute for Information Infrastructure Protection. Report: 1st Software and Usable Security Aligned for Good Engineering (SAUSAGE) Workshop; 2011.http://www.thei3p.org/events/ sausage2011.html.
12. National Cyber Security Centre. Developers need help too; 2016.https://www.ncsc.gov.uk/ blog-post/developers-need-help-too.
13. SINTEF. Fifth International Workshop on Secure Software Engineering; 2011.http://www. sintef.no/secse.
14. University CM. Symposium On Usable Privacy and Security; 2011.http://cups.cs.cmu.edu/ soups.
Chapter 2
Usable and Secure Software Design:
The State-of-the-Art
Abstract This chapter reviews the current state-of-the-art in the design of usable and secure systems. This chapter should not be considered as a state of the art review of usability and security in general, and HCI-Security (HCI-Sec) in particular. For those readers interested in such a review, I would recommend [1]. I begin by identifying several common themes in the design of effective information security and reviews work by the HCI-Sec community towards designing usable security. Based on limitations in this existing work, I take a step back and review the prevalent HCI concepts available for designing usable and secure systems, including research on integrating these ideas with Software Engineering, and the potential consequences of these approaches to security. Because the concept ofRequirementis shared by both the security and usability communities, I review how existing work in Security Requirements Engineering might be cogent to the design of usability. In particular, I review several dominant Requirements Engineering approaches, and consider issues which may arise when viewing them from a usability perspective. I also introduce the concept of aframeworkand illustrate how existing Requirements Engineering frameworks deal with eliciting security and usability concerns. I conclude this chapter with a brief review of the available tool-support for facilitating Usability and Security Requirements Engineering activities.
2.1
Towards Usable Security Design
2.1.1
Themes in Information Security Design
Information Security is defined by ISO/IEC 27002 [2] asthe protection of information from a wide range of threats in order to ensure business continuity, minimize business risk, and maximize return on investments and business opportunities. Although this definition appeals to the notion ofbusiness, it is unfair to typecast businesses as purely commercial operations. We would be hard pressed to find examples of organisations not concerned about their risks, their on-going continuity, and making efficient use of their resources. Nevertheless what the definition does offer is the idea that information
© Springer International Publishing AG, part of Springer Nature 2018 S. Faily,Designing Usable and Secure Software with IRIS and CAIRIS, https://doi.org/10.1007/978-3-319-75493-2_2
is the lifeblood of an organisation, and safeguarding it is tantamount to protecting the organisation.
Even though the literature reports many methods and tools for designing security, a number of themes are pervasive when designing effective information security.
First, security is about the protection ofassets[3]; these need to be both identi-fied and appraised, and are defined as anything that has value to an organisation [4]. Valuation of assets is particularly difficult as this needs to be expressed in terms of organisation value or, more directly, as the cost paid by the organisation should the asset be compromised. Gollmann [3] claims the identification of assets is compara-tively easier than its valuation, but it is unwise to trivialise the exercise of identifying
informationassets. Information can be defined as data interpreted in some meaning-ful context [5], and as knowledge communicated concerning some particular feat, subject, or event [6]. In both cases, the significance and value of information depends on the context where it is found.
Second, because protecting an organisation from all possible threats is untenable, security requirements are often derived by assessing theirrisks[2].Risk is evocative of some form of threat, danger or hazard. A multidisciplinary study commissioned by the Royal Society [7] identified two forms of risk: objective risk and perceived risk. Objective risk defines risk as the probability of harm occurring; this harm can be stated scientifically and is capable of measurement. Perceived risk relates to the subjective assumptions people hold about future events. Given the interpretive nature of information, it is this latter definition which holds sway in the Information Security literature. Closely associated with the definition ofRiskare the concepts ofThreatandVulnerability. ISO/IEC 27002 [2] defines a threat as a potential cause of an unwanted incident, and a vulnerability as a weakness of an asset or group of assets that can be exploited by one or more threats.
Third, as succinctly put by Bruce Schneier, security is a “process rather than a product”: processes need to be put in place to recognise inherent insecurity [8]. Understanding how to do this has been a consistent theme in the Information Systems Security literature. Of particular interest to security design has been work on the following:
• Threat models and threat modelling, e.g. [9,10]. Threat models typically
encapsu-late the potential attacks a system might expect to face, e.g. threat models associated with internet applications [11]. Threat modelling is use of abstractions to aid in thinking about risks [10].
• Responsibility modelling, e.g. [12–14] . This technique is concerned with defining
what roles are held by responsibility owners and modelling responsibility relation-ships between agents.
• Writing and promoting Information Security Policies : these are documents that
describe, in general terms, the security goals of an organisation [15].
• Fostering security awareness within an organisation [16,17], and behaviour
con-ducive to an organisation’s security policy [18,19].
2.1 Towards Usable Security Design 11
attackers behind organisational threats. Writing easily understandable and maintain-able security policies which balance protection with productivity is a challenge [15]. Examining the security perceptions held by inter-organisational groupings [20] found that fostering a culture of security involves more than just policy communication; it involves factors such as understanding the values and norms of an organisation’s culture and sub-cultures, and an appreciation of the different work contexts [20]. The human and cultural dimension of security has been explored from a design per-spective. In particular, James’ work on the Orion strategy [21] draws on analogies with Checkland’s Soft Systems Methodology approach [22], which treats design as a form of participative enquiry in the real world of a system’s problem, and the concep-tual world of future systems. The high-level of stakeholder participation associated with this approach was found to raise awareness of security and increase subsequent ownership of selected security measures.
Unfortunately, the prevailing approach to tackling Human Factors in Information Security is to treat people as the problem. For example, Schneier claims that security is only as good as its weakest link, and that people are the weak link [23]. However, Brostoff and Sasse argue that this position is tantamount to blaming users for a security design they might compromise, and analogous to blaming the cause of safety-critical system failures onhuman errorrather than bad design [24]. Therefore, when designing secure software, it is sensible for design to account for the role of those people that expect to use it.
2.1.2
Usable Security
In their seminal paper on Information Security, Saltzer and Schroeder [25] espouse several design principles for protection mechanisms. One of these is the principle of Psychological Acceptability, which states:The interface to the protection mecha-nism should be designed for ease of use, so users routinely and automatically apply the mechanism correctly. There has been an enormous amount of academic research in the area of HCI Security (HCI-Sec); seminal work in this area has looked at the usability of password policies [26] and security controls [27]. The HCI-Sec com-munity has considered the challenge of designing usable security from two different standpoints: Design Principles and Idioms, and User-centered Security.
2.1.2.1 Design Principles and Idioms
granting of authority, and indicate clearly the consequences of decisions that the user is expected to make.
Another example of this standpoint is Garfinkel’s patterns for usable security [29]. These patterns are written in the same style as the design patterns in Gamma et al.’s seminal work on Design Patterns [30], and catalogued according to usage. Examples of these patterns include:
• User visibility and sanitization: Explicit user audit, Reset to initialisation, Delay
unrecoverable action.
• Identification and key management: Leverage existing identification, Create keys
when needed, Distinguish internal senders.
• Patterns for promoting overall secure operation: Distinguish security levels,
Dis-able by default, Install before execute.
Yee and Garfinkel’s contributions are both sensible and well meaning, but are not a panacea for designing usable security. For example, one of Yee’s Commu-nication principles states that a designer should “Present objects and actions using distinguishable, truthful appearances,” yet nothing is said about how this might be done. In the case of Garfinkel’s patterns, while the relationship between many of the patterns are described, unlike Gamma et al. [30], the consequences (particularly to security) of applying these patterns is not. For example, the Leverage Existing Identificationpattern describes participants, the organisational implementation, and the successful results of this pattern, but culling the consequences of this pattern from known uses is left as an exercise to the designer; therefore, vulnerabilities may be introduced if certain details of the pattern are misinterpreted.
Despite their faults, the key contribution made by both Yee and Garfinkel is the notion that security and usabilitycanbe harmonious. Yee’s guidelines were designed to appeal to the mental models of users, while Garfinkel’s patterns are the results of synthesising known examples of usable security design.
2.1.2.2 User-Centered Security
The second standpoint is characterised by Sasse et al.’s work on applying HCI design approaches to the design of security mechanisms [31], and Zurko and Simon’s work on User-Centered Security [32].
Based on the empirical findings from several studies about password usage, Sasse et al. found that framing the design of security controls from technology, user, goal, task, and context perspectives can lead to useful insights. For example, considering security as an enabling task that needs to be completed before a main task helps explain why users choose to circumvent controls which get in the ways of their work.
2.1 Towards Usable Security Design 13
[28], Zurko and Simon argue for security models conducive to the mental models of different types of users, but they also propose synthesising security design techniques with established design techniques from HCI.
Sasse et al.’s and Zurko and Simon’s work inspired, and continues to inspire, much of the current research in HCI-Sec. Surprisingly, the bulk of work in this community focuses on studying the usability of security controls rather than activities associated with designing systems that are usable and secure. In particular, a survey by Birge [33] found that many HCI-Sec papers are divided into studies about usability testing on security controls, mitigating security controls, conceptual investigations about terms such as “trust” and “privacy”, experience studies about user attitudes, and models and guidelines demonstrating trusted interactions and trusted user interfaces. Birge also notes that much of this research focuses on the needs of the end-user rather than the needs of the designer, and few studies have attempted to tackle the question about how designers should approach security concerns. Moreover, attempts to synthesise HCI and security techniques continue to raise issues for researchers. To understand why, let us examine two particular examples of such follow-on work.
The first example is Gerd tom Markotten’s work on User-Centered Software Engineering [34]. Like the User-Centered Security paradigm, this work attempts to synthesise a Security Engineering process with Usability Engineering. The Secu-rity Engineering process itself involves defining the characteristics of a candidate architecture, performing threat and risk analysis on this architecture, deriving more detailed architectural components, connectors, and implementation logic, and eval-uating the system. This synthesis involves informing the characteristics of the candi-date architecture with insights from interviews and observations of target user groups, considering the role of users as inside attackers during threat and risk analysis, iter-atively developing the system’s user interfaces, and evaluating them using usability inspection methods [35]. This approach was used to support the development of a software tool allowing security novices to align their security goals with the expec-tations of certain internet-facing applications [36]. Although initially promising, this work remains largely unvalidated; no information about the target user group is pro-vided, nor are any insights into the practical aspects of synthesising usability methods with the methods used to design the security tool.
situating these countermeasures for each of the affected contexts is considered and, if unmitigated risks remain, this process is repeated.
In a retrospective of work in this area [38], Zurko highlighted a number of chal-lenges for designers. These include reducing usable security techniques to methods simple enough for most developers to execute effectively, and ensuring that users understand how to use security controls directly related to their tasks and contexts. AEGIS deals quite succinctly with both of these challenges. First, AEGIS assets and their relationships are modelled using the Unified Modeling Language (UML) [39], arguably thelingua francaof modelling notations in the Software Engineering com-munity. By modelling the on-going analysis as UML, AEGIS asset models make useful boundary objects: artifacts flexible enough to be used within a conceptual boundary, but robust enough to retain a common identity across boundaries [40]. Second, asset modelling and risk analysis is carried out with respect to different
environments. These represent physical or cultural contexts meaningful to workshop participants. Therefore, rather than modelling and analysing an arbitrary system, participants can relate to the different contexts the analysis is related to.
At a superficial level, AEGIS appeals to Zurko and Simon’s canons for User-Centred Security. A more critical analysis of AEGIS does, however, raise issues; these affect not only AEGIS but the paradigm of User-Centered Security in general. First, both User-Centered Security Engineering and AEGIS assume that usability will follow by taking a participative approach to design. However, work by Irestig et al. [41] found that while participative practices are effective for eliciting usage culture values that might have otherwise remained tacit, resulting systems tend to be comparatively chaotic, small-scale, and imbued with the power relationships of the organisation.
Second, although conceptually simple, UML class diagrams alone cannot model the many elements which also impact secure systems, such as goals, tasks carried out by users, and other potentially relevant relationships, such as dependencies between different users. Moreover, as analysis progresses, models are likely to grow and become unwieldy without dedicated tool-support; to date, no such tool-support has been presented.
Finally, although treating environments as first-class modelling objects is an important step towards contextualising risk analysis, workshops alone may not be enough to elicit information about threats and vulnerabilities within different envi-ronments. Although Zurko and Simon have proposed applying techniques such as Contextual Inquiry [42] to elicit such data, there has been no peer-reviewed literature to date which has described attempts to do this.
2.1.3
A Case for Better HCI Integration?
2.1 Towards Usable Security Design 15
is evidence that usability and security do not have to be treated as conflicting qual-ities. Unfortunately, the evidence in Sect.2.1.2.2suggests that while synthesising techniques from security and HCI is desirable, design issues may arise if applied to cases more significant than those reported by the literature to date.
Based on the strength of these findings, rather than adopting an ad-hoc approach to synthesising security and usability design techniques, a more thorough review of the HCI and related Software and Security Engineering literature is needed to develop a better understanding of the underlying issues.
2.2
Usability Design
2.2.1
HCI and Usability
Human-Computer Interaction (HCI) is “a discipline concerned with the design, eval-uation, and implementation of interactive computing systems for human use and with the study of major phenomena surrounding them” [43]. HCI is an interdisciplinary field and, has been influenced by research in fields such as ergonomics, psychology, computer science, social sciences, and the arts and humanities. These influences have shaped how the discipline has approached the idea of design.
Usability has been described as “the professional term for HCI” [44], although its definition varies depending on the stake that practitioners have in it. Coutaz and Calvary [45] state that Software Engineers consider Usability as an intrinsic property of a system, in that a system can be intrinsically usable or unusable. For example, Ghezzi et al. [46] consider a software system usable if its human users find it easy to use. Similarly, Lauesen [47] defines Usability as the combination of the following six factors.
• Fit for use: The system can support the user’s real life tasks.
• Ease of learning: How easy is the system to learn for various user groups? • Task efficiency: How efficient is the system for the frequent user?
• Ease of remembering: How easy is the system to remember for the occasional
user?
• Subjective satisfaction: How satisfied is the user with the system? • Understandability: How easy is it to understand what the system does?
Table 2.1 ISO 9241 usability definitions Concept Description
Product Part of the equipment (hardware, software, and materials) for which usability is to be specified
User Person who interacts with the product Goal Intended outcome
Effectiveness Accuracy and completeness with which users achieve specified goals Efficiency Resources expended in relation to the accuracy and completeness with
which users achieve goals
Satisfaction Freedom from discomfort, and a positive attitude towards the use of the product
Context of use Users, tasks, equipment (hardware, software, and materials), and the physical and social environments in which a product is used
Fig. 2.1 ISO 9241-11 usability framework
Figure2.1 describes the relationship between these different components of Usability. It represents what the standard calls a Work System: a system consist-ing of users, equipment, tasks and a physical and social environment, for the purpose of achieving particular goals [48]. In effect, a user is carrying out tasks, which are collections of activities, to achieve one or more goals.
2.2 Usability Design 17
basis for further review of the literature. In the following sections, design approaches appealing to this definition are reviewed, together with problems that arise when considering the synthesis of design, security, and usability.
2.2.2
User-Centered Approaches
The design philosophy espoused by most usability professionals isUser-Centered Design. The introduction of this term into the design vernacular is attributable to Donald Norman, who defined it asa philosophy based on the needs and interests of the user, with an emphasis on making products usable and understandable[49]. The origins of user-centricity can be traced back to theguided fantasytechnique that Tim Mott and Larry Tesler used at Xerox PARC to develop the first generation of desktop publishing systems [50]. User-Centered Design is now the prevailing paradigm for designing interactions with technology, and not just software systems. This said, when arguing the need for user-centered approaches, the work most commonly referred to in the HCI literature is Gould and Lewis’ key principles for useful and easy-to-use computer systems [51]. Based on their experiences at IBM, Gould and Lewis recommend the following three principles of design.
• Early focus on users and tasks: designers need to study the behavioural
character-istic of users, together with the work they need to accomplish.
• Empirical measurement: the performance and reactions of users should be
observed, recorded, and analysed while using prototypes to carry out real work.
• Iterative design: a cycle of design, test, measure, and redesign should be carried
out and repeated as necessary.
These principles are similar to the principles of Human-Centered Design stipu-lated by ISO/IEC 13407 [52], i.e.,
• the active involvement of users and a clear understanding of user and task
require-ments;
• an appropriate allocation of function between users and technology; • the iteration of design solutions; and
• multi-disciplinary design.
Fig. 2.2 Human-centered design activities [52]
2.2.2.1 Goals
A precise definition of what the User-Centered Design community means by agoal
eludes us. Cooper et al. [53] define a goal asan expectation of an end condition; Holtzblatt et al. [56] consider a goal to be an achievement to be worked towards or maintained. In both cases, goals are both personal and motivational.
2.2 Usability Design 19
2.2.2.2 Tasks and Scenarios
Users carry out tasks: activities required to achieve a goal [48]. To understand the usability impact of tasks, some form oftask analysisis performed. Task analysis is concerned with the performance of work [57], whereperformanceis a synonym for the activities needed to achieve a goal. The outcome of task analysis is one or more models which describe how work is carried out. Examples of task analysis techniques include Hierarchical Task Analysis (HTA) [58], GOMS (Goals, Operations, Methods, and Selection rules) [59], and Scenario-Based Task Analysis [60]. However, of these different approaches, scenarios are, arguably, the most widely used.
Scenarios are stories about people carrying out an activity [61]. The length of this story, the nature of the people, and the types of supplemental information vary based on the developmental context within which scenarios are used. For example, in addition to a narrative describing a user’s actions, the User Interaction Scenar-ios described in [61] include other elements such as scenario-setting, participating actors, goals motivating the actors, and supplemental information about external events. Although such scenarios act as vignettes describing how people might use the designed technology to carry out some activities, these can also be used to pro-voke discussion around the darker aspects of technology use. An example of such an approach is provided by [62], where scenarios describe functionally valid but dystopian aspects of system design decisions during the early stages of a project, or during policy-making discussions.
A key advantage of scenarios is their allusory nature; they can be used to impart knowledge about tasks at any level of abstraction, provided it can be rendered in a nar-rative structure. Consequently, scenarios are a universal language in User-Centered Design, and can be used at all stages in usability design, from eliciting data about user tasks, through to storyboarding possible design implementations. Moreover, as Sect.2.3.3will discuss, scenarios are a candidate boundary object that all members of a project team can relate to.
Scenarios are episodic, and symbiotically tied to their contexts of use. As a conse-quence, they tend to be fragmentary in nature. They are also less structured as a task modelling notation compared to other task analysis techniques, such as Hierarchical Task Analysis [58].
2.2.2.3 Personas and Assumption Personas
![Fig. 2.2 Human-centered design activities [52]](https://thumb-ap.123doks.com/thumbv2/123dok/3935057.1878477/43.439.57.386.50.351/fig-human-centered-design-activities.webp)
![Fig. 2.3 Example of a security requirement (modelled as an ellipse) constraining a context, mod-elled as a problem frame diagram [98]](https://thumb-ap.123doks.com/thumbv2/123dok/3935057.1878477/50.439.57.383.54.257/example-security-requirement-modelled-ellipse-constraining-context-problem.webp)
