Designing usable and secure software with IRIS and CAIRIS

Shamal Faily Designing Usable and Secure Software with IRIS and CAIRIS Designing Usable and Secure Software with IRIS and CAIRIS Shamal Faily Designing Usable and Secure Software with IRIS and CAIRIS 123 Shamal Faily Department of Computing & Informatics Bournemouth University Poole, Dorset UK ISBN 978-3-319-75492-5 ISBN 978-3-319-75493-2 https://doi.org/10.1007/978-3-319-75493-2 (eBook) 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 The registered company address is: Gewerbestrasse 11, 6330 Cham, Switzerland To Claudia 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 welcome addition to the small set of books in our field 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 practitioners, 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 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 lectures, and maybe a course or two here and there One of the significant contributions 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 vii viii Foreword and security are all discussed, and then in Chap the tool support provided by CAIRIS is introduced The discussion of personas and scenarios in Chap sets 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 Nancy R Mead, Ph.D SEI Fellow, Carnegie Mellon University IEEE Fellow ACM Distinguished Educator Preface Why 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 astronomical 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 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 usability and 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 Herley 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 ix x Preface 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 the final 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 the field of Security Engineering will find 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 Security by Adam Shostack (Wiley, 2014), as well as Securing Systems: Applied Security Architecture and Threat Models by Brook Schoenfield (CRC Press, 2015) Many options exist for those wanting an overview of the field of Usability and related design topics; Interaction Design: Beyond Human-Computer Interaction by 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 There are fewer options available when it comes to Requirements Engineering textbooks, but—given the attention IRIS and CAIRIS pays to KAOS and modelling Preface xi in general—then Requirements 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 technique in some depth; other techniques 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 Chapter will 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 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 will 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 will find the case study chapters (Chaps 7, and 10) 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 will provide a useful aide-memoire 244 12 Further Applications of CAIRIS for Usable and Secure Software Design • Derive GRL model elements from persona characteristics: Persona characteristics are inspected to elicit implied goals, soft goals, tasks and, for each contributing element, identifying whether the element is a ‘means’ or ‘end’ given the contribution relationship • Generating and analysing the GRL model: CAIRIS supports the generation of a GRL model compatible with jUCMNav for a persona/task combination in a given environment When imported into jUCMNav, missing contribution links can be identified, along with the impact of satisfying or denying certain goals or soft goals that challenge trust expectations Interested readers can find more details of these steps, together with a worked example in [9],1 but Fig 12.2 illustrates the form that a generated model might take Although GRL and social goal models in general have seen little use beyond the academic Requirements Engineering community, the generated model visualises persona goals, activities, and relationships between goals, tasks, and other goals; this visualisation can encourage designers to use and engage in personas in more depth than they might using personas as a communications tool alone These differences in trust expectations can be characterised as Gulfs of Expectation: the gap between the expectations held by a user about a system and its developers, and the expectations held by a developer about the system and its users [10] With further extensions to IRIS and CAIRIS, the grounded theory analysis used to derive persona trust characteristics can be used to elicit formal descriptions that can be written in the Communicating Sequential Processes (CSP) language [11] When these formal descriptions are used in conjunction with a formal system specification in CSP, and the FDR model checker [12], precise differences between stakeholders’ mental models of a system and its formal specification can be identified Further details of this work can be found in [10] and, while this work is exploratory, it does take a step towards formally and economically validating usability claims that could hitherto only be evaluated by exhaustive user testing 12.4 Realising “Design as Code” The experiences using IRIS and CAIRIS to help build webinos suggest it has the potential for broader use supporting interaction design and security engineering For example, CAIRIS was used to specify context of use descriptions, persona and attacker persona development, requirements sense-making activities, and architectural risk analysis The study also illustrated how subjecting design models to version control and build processes, and making them publicly available via github increased project developers’ engagement with regards to maintaining requirements, security, and architectural design models Such behaviours complement DevOps practices that emphasise collaboration between design, development, and operations teams The case study example in the paper is based on the earlier desktop version of CAIRIS, but this example can be reproduced on the more recent version of the CAIRIS platform Fig 12.2 A GRL model generated by CAIRIS within jUCMNav The zoomed portion illustrates the impact of a strategy 12.4 Realising “Design as Code” 245 246 12 Further Applications of CAIRIS for Usable and Secure Software Design via automated processes that consider “infrastructure-as-code” [13] However, in this study, CAIRIS was used by designers who each had a working knowledge of requirements engineering, security engineering, and user-centred design In the wider world, many project teams have practitioners with individual expertise in only one, and occasionally two, of these areas While practitioners with expertise in one area might appreciate the capabilities offered by CAIRIS, they are unlikely to expend effort learning a platform that might impact their current processes, tools, and workflows Our group is starting to explore how CAIRIS might better facilitate collaboration by encompassing not only security requirements engineering, but also tool and process interoperability with security and usability engineering To see this potential, three demonstrative usage scenarios are presented The context for these scenarios is the design of a new control system for a hypothetical water company sharing the characteristics of ACME Water, which was introduced in Chap Collaborating on the design and engineering of this system is an interaction designer (Alice), and a security engineer (Bob) Although not explicitly mentioned in the scenarios, both Alice and Bob interact with the same version-controlled CAIRIS model; once they have made changes to their model, they commit their changes to the version control systems to make them available to the wider project team Even though Alice and Bob work with the same model, they are not using the same instance of CAIRIS Alice relies on a CAIRIS instance running on a Docker container hosted by her laptop, whereas Bob uses an instance of CAIRIS hosted by a cloud-based service provider 12.4.1 Creating Assured Personas To understand the user goals of people using the new control system, Alice interviewed several plant operators Once anonymised, Alice rendered her interview transcripts as HTML pages, before opening them up in Google Chrome She then connected her Persona Helper extension to CAIRIS, and coded her transcripts for factoids She used CAIRIS to export the factoids into Trello in readiness for affinity diagramming with two of her colleagues Unfortunately, her colleagues were not in the office that day, but they agreed to use Trello to affinity diagram online while talking on Skype Once affinity diagramming had concluded, and all factoids were annotated, she exported the Trello board to CAIRIS to generate persona characteristics; she then entered narrative text describing the persona into CAIRIS based on these characteristics Finally, to quickly share both the persona and the latest system design with colleagues and the security team, she generated a specification document based on the latest version of the CAIRIS model (Fig 12.3) 12.4 Realising “Design as Code” 247 Fig 12.3 Generated requirements specification document, which includes persona definitions and underpinning argumentation models 248 12 Further Applications of CAIRIS for Usable and Secure Software Design 12.4.2 Discovering Risks from Attackers and Threat Models A team of penetration testers were scheduled to evaluate the new control system by probing its network infrastructure Bob wanted the environment to be resistant to intrusive probes of the system for vulnerabilities before this testing took place To help others understand more about these testers, he decided to create a sketch of a potential penetration tester to illustrate his goals and motivations, and carried out threat modelling to understand how – based on the penetration tester’s capabilities and motivations – such probing might be made possible Bob and his colleagues in the security team drew an attack tree to model this threat Once complete, Bob marked up the attack tree in DOT; the Graphviz rendered tree is shown in Fig 12.4 (left) Bob noted that detecting application scans is a new requirement the infrastructure needs to support, but he would need to consider the implications that incomplete Intrusion Detection System (IDS) rules might have Bob imported the attack tree into CAIRIS to generate a new KAOS obstacle model He defined a threat in CAIRIS to summarise how the penetration tester might enumerate the system (Enumeration), and a new vulnerability based on incomplete IDS rules (Incomplete Intrusion Detection rules), which he linked to the appropriate leaf node of the obstacle model (Incomplete IDS ruleset) As the threat could exploit the vulnerability in the same context of use, he captured this as a risk (System enumeration) CAIRIS automatically rated the risk based on the likelihood of the threat (Probable), severity of the vulnerability (Critical), and security properties the penetration tester aims to compromise Before the risk could be confirmed, Bob wrote a misuse case scenario contextualising the risk and its supporting elements; this helped Bob confirm the analysis contributing to the risk was sound, and provided additional rationale for others wishing examine his reasoning Bob devised a solution for mitigating this risk When details of this risk mitigation were added to CAIRIS, the goal model was automatically updated to indicate the leaf obstacle was resolved, as illustrated in Fig 12.4 (right) 12.4.3 Contextualising the Implication of Security and Usability Design Decisions While creating and analysing personas, Alice and her team created two environments in CAIRIS based on the two main contexts of use associated with the new control system: these relate to operations during normal working hours (Day), and out-of-hours operations (Night) Bob used CAIRIS to elicit assets of value to the water company associated with the new control system (Fig 12.5) Because threats and vulnerabilities might differ based on these contexts, he indicated the security properties needing to be protected in each context Bob used this information to help elicit risks Fuzz web apps DoS IDS Incomplete IDS ruleset Dump password hashes and Collect data from SCADA workstations Probe ICT applications Detect application scans Probe STCS applications or Pull data from STCS resources Keylog credentials and Collect data from plant operators Fig 12.4 Enumeration threat modelled as an attack tree (left), and KAOS goal model integrating threat model into the network security requirements (right) Fuzz STCS or Query Enterprise SCADA network and Enumeration 12.4 Realising “Design as Code” 249 250 12 Further Applications of CAIRIS for Usable and Secure Software Design Fig 12.5 Editing assets Fig 12.6 Visualising a task’s security impact In parallel to this, Alice elicited tasks that the personas created would carry out For example, she used CAIRIS to provide details of how one of the personas deals with a broken instrument alarm; this included a narrative scenario contextualising how the persona carries out the task, and a list of assets associated with the task When Alice visualised the Broken Instrument Alarm task in context (Fig 12.6), she noted risks (red ellipses) that may impact the task (the blue ellipse) By clicking on 12.4 Realising “Design as Code” 251 nodes in the model, Alice obtained details of these risks, including details of potential attackers This allowed her to review the rationale behind the models created by Bob Together Bob and Alice sat down to model data flows between elements associated with this task; this DFD is the same as that introduced earlier in Fig 12.1 The task description guided Alice in sketching the DFD, while Bob contributed by clarifying the information carried in each data flow, and checking that the entities/data stores and processes corresponded with assets and use cases in the existing design Once complete, Bob identified obstacles associated with the obstruction of security properties in each DFD element, to form the basis of additional attack tree modelling by his team 12.4.4 Implications for CAIRIS The usage scenarios show how CAIRIS facilitates typical security and usability engineering activities, and helps interaction designers understand the design rationale of security engineers, and vice versa Implicit in these scenarios is the need for precision Alice and Bob need to be precise when directly and indirectly specifying security model elements in CAIRIS, e.g the rationale behind asset security properties, and the information carried in each data flow Such precision is needed to facilitate traceability, and automation of the analysis and generation of CAIRIS models Such precision should be welcomed rather than considered a distraction, given the potential of ambiguity for undermining requirements and other design models Ambiguity can be a resource for design [14], but the scenarios also show that precision need not interfere with ideation when designers from different backgrounds work together Although explicitly designed to support IRIS, the usage scenarios suggest CAIRIS is methodology agnostic For example, the activities carried out by Bob in Sect 12.4.3 are not incompatible with STRIDE [3], or even LINDDUN [15] if the goals pertained to privacy rather than security 12.5 Human-Centred Specification Exemplars In Sect 3.1, NeuroGrid was introduced as a specification exemplar to provide a worked example of the IRIS meta-model NeuroGrid was, however, a research project with many challenges due to conflicting stakeholder perspectives and emerging technology The case study examples also exhibited complex interactions between people, technology, and its context of use, where a security solution mitigating a risk in one environment may be inappropriate in another Our experiences with IRIS and CAIRIS lead us to believe that CAIRIS models are rich enough to model not only the functional concerns found in typical specification exemplars, but also human issues which are less easily modelled 252 12 Further Applications of CAIRIS for Usable and Secure Software Design 12.5.1 Design Principles for Human-Centred Specification Exemplars “Human-centred specification exemplars” hold significant promise by providing model contexts when designing technology for domains where participants may be hard to reach, or test environments expensive to fabricate They also provide a model for better evaluating software security and usability given that evaluation standards such as the Common Criteria fail to adequately capture human and social elements [16] Based on our experiences building and using specification exemplars with CAIRIS, five design principles for human-centred specification exemplars are proposed Exemplars should provide a model of an operating environment, not just provide a textual description Exemplars should contain representative personas and tasks Exemplars should incorporate a realistic threat model Exemplars should embody working and variable contexts of use Exemplars should be machine readable To illustrate the form that such specification exemplars satisfying these principles might make, specification exemplars based on NeuroGrid and an anonymised form of ACME Water have been made publicly available on the CAIRIS web site [17, 18] As indicated in the Preface, the ACME Water exemplar has been used extensively to support Security by Design teaching at Bournemouth University For example, in one class exercise, an instrument technician persona from the specification exemplar and his related tasks provided context for students when determining the risks to ACME Water of instrument technicians adopting the HMI Pad iPad app [19] 12.5.2 Evaluating Research with Human-Centred Specification Exemplars As well as being used to support teaching, these exemplars have also been used to support academic research For example, the ACME Water exemplar, together with other techniques described in this book, was used to help validate ethical hazards and safeguards faced by penetration testers [20] Our team wanted to survey professional penetration testers to compare whether their understanding of ethical hazards and safeguards corresponded with hazards and safeguards we had found Because of the sensitivity of this topic, we used the persona case technique to build two personas of penetration testers (Ben and Matt); these were given to penetration testers as a vehicle for getting them to describe their personal opinions about these ethical issues We then used the work described in Sect 12.3 to generate a GRL model of one of the personas (Ben); all four ethical hazards were evident from this model The goal model was then imported into jUCMNav, where 12.5 Human-Centred Specification Exemplars 253 the model was evaluated to examine the effects that denying the goals associated with the ethical hazards might have on other goals that Ben wishes to satisfy To validate our understanding of this impact, we used the Security Premortems technique described in Sect 11.4.4 to created a scenario illustrating the impact of these goals being denied The scenario – which was based on one of the threats in the ACME Water specification exemplar – described how Ben, while supervising a junior tester, carried out a test with catastrophic results to the client The scenario was circulated to penetration testers in a security consultancy with approximately the same level of professional experience as Ben Participants were asked to provide open-ended responses with reasons why Ben might have behaved unethically (ethical hazards), together with things that the company could to address the problems found (safeguards) The participants responded via email with 18 candidate ethical hazards, and 21 candidate safeguards Each candidate ethical hazard was coded based on related goals, and goals directly harmed as a result Each candidate safeguard was categorised based on related goals, and goals directly safeguarded Most of the candidate ethical hazards corresponded with at least one ethical hazard from the model, and all candidate safeguards corresponded to at least one safeguard from the model 12.5.3 Human-Centred Specification Exemplars and Archetypes More recently, work has began to leverage synergies between human-centered specification and work on organisational archetypes [21] Recent work has examined how the idea of archetypes can be scaled up to model organisational contexts, to help developers understand how to provide solutions that fit specific groups of Small and Medium Enterprises (SMEs), and respect the capacity that SMEs have to manage security solutions effectively However, archetypes are intrinsically nuanced and messy, and this messiness is difficult to capture without real data to inform its design Exploiting the synergies between archetypes and human-centred specifications not only provides rationale and grounding for archetypes, but potentially makes them available to support further design and research 12.6 Summary In this chapter, I considered additional applications for usable and secure software design that CAIRIS can facilitate Readers are warmly encouraged to make the most of CAIRIS by using these applications, remember this point made in the preface: IRIS and CAIRIS are exemplars for design frameworks and software tools for secure and usable design, not the final 254 12 Further Applications of CAIRIS for Usable and Secure Software Design word If this book has inspired you to think of new ways of using design processes, techniques and tools to provide assurance of a systems’s functionality, security, and usability, then it has achieved its aim References Jamshidi M System of systems - innovations for 21st century In: 2008 IEEE region 10 and the third international conference on industrial and information systems; 2008 p 6–7 Ki-Aries D, Dogan H, Faily S, Whittington P, Williams C From requirements to operation: components for risk assessment in a pervasive system of systems In: IEEE 25th international requirements engineering conference workshops, RE 2017 workshops, Lisbon, Portugal, September 4–8, 2017; 2017 p 83–89 Shostack A Threat modeling: designing for security New York: Wiley; 2014 Zand DE Trust and managerial problem solving Adm Sci Q 1972;17(2):229–39 Riegelsberger J, Sasse MA, McCarthy JD The mechanics of trust: a framework for research and design Int J Hum Comput Stud 2005;62(3):381–422 Fléchais I Designing secure and usable systems University College London; 2005 Faily S Bridging user-centered design and requirements engineering with GRL and persona cases In: Proceedings of the 5th international i* workshop CEUR workshop proceedings; 2011 p 114–119 Amyot D, Ghanavati S, Horkoff J, Mussbacher G, Peyton L, Yu E Evaluating goal models within the goal-oriented requirement language Int J Intell Syst 2010;25(8):841–77 Faily S, Fléchais I Eliciting and visualising trust expectations using persona trust characteristics and goal models In: Proceedings of the 6th international workshop on social software engineering SSE 2014 ACM; 2014 p 17–24 10 Faily S, Power D, Fléchais I Gulfs of expectation: eliciting and verifying differences in trust expectations using personas J Trust Manag 2016;3(1):4 Jul 11 Hoare CAR Communicating sequential processes Englewood Cliffs: Prentice-Hall; 1985 12 University of Oxford FDR website; 2018 https://www.cs.ox.ac.uk/projects/fdr 13 Kim G, Behr K, Spafford G The phoenix project: a novel about IT, DevOps, and helping your business win IT Revolution Press; 2014 14 Gaver WW, Beaver J, Benford S Ambiguity as a resource for design In: CHI ’03: proceedings of the SIGCHI conference on Human factors in computing systems ACM; 2003 p 233–240 15 Wuyts K Privacy threats in software architecture Heverlee: KU Leuven; 2015 16 Church L, Kreeger MN, Streets M Introducing usability to the common criteria In: 9th international common criteria conference; 2008 17 Shamal F NeuroGrid specification exemplar; 2018 https://cairis.org/NeuroGrid 18 Shamal F ACME Water specification exemplar; 2018 https://cairis.org/ACME_Water 19 SweetWilliam SL HMI Pad website; 2013 http://www.sweetwilliamsl.com/hmi-ipad 20 Faily S, Iacob C, Field S Ethical hazards and safeguards in penetration testing In: Proceedings of the 30th british HCI group annual conference on people and computers: fusion British Computer Society; 2016 21 Parkin S, Fielder A, Ashby A Pragmatic security: modelling IT security management responsibilities for SME archetypes In: Proceedings of the 8th ACM CCS international workshop on managing insider security threats MIST ’16 ACM; 2016 p 69–80 Index A Abuse case, 36 Access right, 182 Activity scenario, 80–81, 141, 151, 167, 203, 207, 211 Actor, 30, 61, 105 Affinity diagramming, 120–121, 131, 215 Affordances, 173, 224 Agent-oriented approaches criticisms, 34 Goal-oriented Requirements Language (GRL), 207, 243, 252 Intention STrategic Actor Relations (i*), 30–31, 82 Non-Functional Requirements (NFR) framework, 30 Secure Tropos, 33–34 Tropos, 31–34 Ambiguity analysis, 186, 192–194 Appropriate and Effective Guidance for Information Security (AEGIS), 13, 85– 86, 141, 151 Archetypes, 253 Architectural pattern, 180–181, 186–189 Architectural risk analysis, 180, 185–187, 206–207 example, 187–194 Asset, 10, 57–61, 67, 77, 83, 85, 105, 150, 179, 181, 184, 185, 194 Asset model, 85, 105, 165, 181, 190, 204, 230 Assumption-based planning methodology, 134 Assumption personas, 38, 124–126, 141– 143, 210 Atlas.ti, 80 Attacker, 57, 66, 68, 69, 105, 150, 162, 169– 170, 184, 185, 204 Attack pattern, 182 Attack resistance analysis, 185–186, 190– 192 Attack surface, 182 Attack surface metrics, 182, 185, 188–190 Attack trees, 204, 248 B Bass diffusion model, 222 Behavioural variables, 122 Boden, Vitek, 157 Boundary object, 14, 19, 24, 186, 233 C CAIRIS API, 97 CAIRIS deployment specification, 97 CAIRIS model file, 97 Chind¯ogu, 225 Cohesive bar charts, 44 Common Attack Pattern Enumeration and Classification (CAPEC), 183, 193 Common criteria, 43, 114, 252 Common Vulnerabilities and Exposures (CVE), 190 Common Weakness Enumeration (CWE), 183, 190 Component, 181, 188 Computer Aided Integration of Requirements and Information Security (CAIRIS), x, xiii, 89–117, 125 architectural design, 92–97 Computer Aided Qualitative Data Analysis (CAQDAS), 80, 126 © 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 255 256 Concept convergence, 77 Concept maps, 213–214 Concern links, 83 Connector, 181, 188 Context of use, 76, 201–204 Contextualised attack pattern, 182–186, 206 CORAS method, 44 Countermeasure, 57, 67–69, 77, 99, 105 D Damage effort ratio, 182 Data Flow Diagrams (DFDs), 241–242 Data Support Service (DSS), xiv, 137 Defamiliarization, 173, 225 Defect Detection and Prevention (DDP), 45 Design patterns, 12, 183 Design research, 128, 212, 215 DevOps, xii, 244 Diffusion of responsibility, 134 Disruptive innovation theory, 222 DocBook, 115 Domain property, 57, 64–65, 194 DOORS, 43, 93 E Entrepreneurship, 219–220 Environment, 57–58, 77, 83, 171, 203 e-Science, 138 Evaluating the Usability, Security, and Trustworthiness of Ad-hoc Collaborative Environments (EUSTACE), xiv eXtensible Access Control Markup Language (XACML), 56, 228, 230 F Factoids, 120, 126, 210 Fault tree, 184 FDR, 244 Fit criterion, 83 Focus groups, 13, 38, 85, 116, 137, 139, 141, 162, 175, 210, 240 Formal methods communicating sequential processes, 244 event-B, 28 linear temporal logic, 28 Framework, 39 G Goal, 18, 30, 57, 58, 63, 65, 68, 69, 77, 82, 108, 150, 192 Index Goal dependency, 70 Goal model, 108, 134, 146, 161, 164 Graphviz, 96, 248 Grounded theory, 79–80, 126–128, 130, 160, 164–165, 172, 174, 243, 244 Gulfs of expectation, 244 H Hackers profiling project, 209 HCI-Security (HCI-Sec), xii, 11–15 HeRA, 43 Human-centered specification exemplars, xii, 251–253 Human-Computer Interaction (HCI), 15 Human error, ix, 61, 214 slip, 146–148 Human values, 76 I Information security policies, 10 Information System Security Risk Modelling (ISSRM), 37 Innovation value-added chain, 228–229 Integrating Requirements with Information Security (IRIS), 75–86 perspectives, 75–77 process, 78–79, 90, 140–142, 159–162 techniques, 77–86 IRIS meta-model, 90, 183 asset meta-model, 59–60 environment meta-model, 57–59 goal meta-model, 63–65 responsibility meta-model, 69–70 risk meta-model, 66–68 task meta-model, 60–63, 133 ISO 27001, 59 ISO 27002, 217 ISO 9241-11, 15, 98 J Journalist questions, 126, 151 JUCMNav, 207, 244, 252 K Knowledge Acquisition in autOmated Specification (KAOS), 27–29, 63, 81–83, 89, 108, 141, 151, 181 Index L Leadbeater’s theory of structured selforganisation, 222 LINDDUN, 251 M Misusability case, 132–134, 141–148, 151– 152 Misuse case, 36, 57, 67–68, 86, 105, 162, 170–171, 205, 211 Model-view-controller, 94 Multiview, 39 N NeuroGrid, 55–56, 130, 138, 198, 224, 239, 251, 252 O Obstacle, 57, 64–65, 77, 82, 109, 134, 146– 148, 150, 169, 184, 186, 194 Obstacle model, 109, 184, 186, 240, 248 Open innovation, 228 Open Web Application Security Project (OWASP), 114, 151, 185, 204 Orion methodology, 11 P Penetration testing, 169–170, 248, 252–253 Persona, 19–20, 57, 60–61, 69, 76, 80–81, 105, 119–131, 134, 140–141, 150, 161, 167, 184, 185, 203, 207, 210, 248, 252 creating, 119–122 criticisms, 123 in requirements engineering, 38 Persona cases, 126–130, 160, 243 example, 129–130 Persona characteristic, 124, 134, 142 Personae Non Gratae (PNG), 38 Persona helper, 131, 246 Privilege, 157, 181, 182, 185, 188, 193, 195 Problem frames, 24–27, 64 Process faking, 40 Process frameworks, 39–40 Programmable Logic Controllers (PLCs), 156, 157 Project meta-data, 90, 115 Protocol, 182, 188 Psychological acceptability, 11 257 Q Qualitative interviews, 163–164 R Rational Unified Process (RUP), 40 Reference, 124, 134, 142 Requirement, 23, 57, 64–65, 68, 82, 83, 93, 111, 185, 187, 194, 201, 204 Requirements engineering, 23–37, 83 RESCUE, 40 Resource, 30 Response, 57, 67–150 Responsibility model, 111, 230 Responsibility modelling, 10, 70, 152, 184, 240–241 Rich pictures, 77, 81–82, 160, 162–163 Risk, 10, 57, 58, 67, 68, 99, 108, 150, 170, 205 objective risk, 10 perceived risk, 10 Risk analysis, 85, 101–105, 109, 205–206 Risk analysis model, 109–111 Risk reduction, 67 Role, 10, 57, 61, 69, 77, 99, 111, 139, 142, 228 S Scenario, 19, 57, 61, 76, 77, 80, 131 Scope of analysis, 36, 38, 66, 150, 171–172 Scrum, 201, 213 Security attribute, 59 availability, 60 confidentiality, 60 Security awareness, 10 Security by Design, xii Security Chind¯ogu, 224–228 Security culture, 11, 130 Security economics, xii, 236 Security entrepreneurship, xiv social entrepreneurship analogies, 221– 222 the security enterpreneur, 222–224 Security experts, 113–114, 228 Security premortems, 231–233, 253 Security properties, 59, 109 accountability, 59–60, 70, 241 availability, 59 confidentiality, 59 integrity, 59 Security requirements, 23–24 Social entrepreneurship, xiv, 218 Social network analysis, 229–231 258 Soft systems methodology, 11, 81 Software-as-a-Service (SaaS), 91 Specification exemplar, 55, 251 Specification framework RESCUE, 40–41 SQUARE, 41–42 Strategic dependency, 30, 70 Strategic rationale, 30 STRIDE, 251 Stuxnet, 158 Supervisory Control and Data Acquisition (SCADA), 156–159, 163, 167, 170 SVG, 96 System of systems, 240 Index UMLSec, 43 Unified Modeling Language (UML), 14, 22, 27, 29, 33, 63, 69, 82, 86, 105, 181 Untrusted data item, 182, 190 Usability, 15, 75–76 Usability attribute, 61, 63, 65, 69, 81 Usage-centered design, 22 Use c ase, 85 Use case, 35–36, 57, 61, 65, 84–205 Use case Maps, 181 Use case maps, 206–207 User-centered design, 17–22, 174, 227 User-centered security, 12 User-centered software engineering, 13 User research, 209–210 T Task, 19, 30, 57, 61–203 Task analysis, 19, 98–99, 100, 102–104 Task model, 105–108, 230 Technology innovation, 218 Telemetry outstations, 156, 157, 163 Threat, 10, 57, 66–68, 82, 85, 108, 150, 162, 169–170, 184, 186 Threat and vulnerability directories, 114 Threat Modelling, x Threat modelling, 10, 151, 173, 241–242 Toulmin’s model of argumentation, 123, 123–211 Traceability, 61, 65, 83, 90, 105 Trello, 131, 246 Trust, ix, 242–243 Trust boundary, 241 Twin Peaks model, 75 Twin peaks model, 224 W Weakest link, people as, ix, 11 Weakness analysis, 186–187, 194 WebDAV, 187–194 Webinos, xiv, 199–215 Wicked problem, 217 Work system, 22, 203 U UK Centre for the Protection of National Infrastructure (CPNI), 157 X XDot, 96 V Value-Sensitive design, 80 Vélib bicycle sharing system, 91 Visual information seeking mantra, 45–89 Volere, 83–84, 115 Vulnerability, 57, 65–66, 82, 85, 150, 152, 184, 186, 205, 211 Vulnerability and threat analysis, 168–170 .. .Designing Usable and Secure Software with IRIS and CAIRIS Shamal Faily Designing Usable and Secure Software with IRIS and CAIRIS 123 Shamal Faily Department of... evolution 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... 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