Managers rarely have deep knowledge of cyber security and yet are expected to make decisions with cyber security implications for software-based systems. We investigate the decision-making conversations of seven teams of senior managers from the same organisation as they complete the Decisions & Disruptions cyber security exercise. We use grounded theory to situate our analysis of their decision-making and help us explore how these complex socio-cognitive interactions occur. We have developed a goal-model (using iStar 2.0) of the teams’ dialogue that illustrates what cyber security goals teams identify and how they operationalise their decisions to reach these goals. We complement this with our model of cyber security reasoning that describes how these teams make their decisions, showing how each team members’ experience, intuition, and understanding affects the team’s overall shared reasoning and decision-making. Our findings show how managers with little cyber security expertise are able to use logic and traditional risk management thinking to make cyber security decisions. Despite their lack of cyber security–specific training, they demonstrate reasoning that closely resembles the decision-making approaches espoused in cyber security–specific standards (e.g., NIST/ISO). Our work demonstrates how organisations and practitioners can enrich goal modelling to capture not only what security goals an organisation has (and how they can operationalise them) but also how and why these goals have been identified. Ultimately, non–cyber security experts can develop their cyber security model based on their current context (and update it when new requirements appear or new incidents happen), whilst capturing their reasoning at every stage.

Cyber security requirements are influenced by the priorities and decisions of a range of stakeholders. Board members and Chief Information Security Officers (CISOs) determine strategic priorities. Managers have responsibility for resource allocation and project management. Legal professionals concern themselves with regulatory compliance. Little is understood about how the security decision-making approaches of these different stakeholders contrast, and if particular groups of stakeholders have a better appreciation of security requirements during decision-making. Are risk analysts better decision makers than CISOs? Do security experts exhibit more effective strategies than board members? This paper explores the effect that different experience and diversity of expertise has on the quality of a team's cyber security decision-making and whether teams with members from more varied backgrounds perform better than those with more focused, homogeneous skill sets. Using data from 208 sessions and 948 players of a tabletop game runin the wildby a major national organization over 16 months, we explore how choices are affected by player background (e.g., cyber security experts versus risk analysts, board-level decision makers versus technical experts) and different team make-ups (homogeneous teams of security experts versus various mixes). We find that no group of experts makes significantly better game decisions than anyone else, and that their biases lead them to not fully comprehend what they are defending or how the defenses work.

Does the act of writing a specification (how the code should behave) for a piece of security sensitive code lead to developers producing more secure code? We asked 138 developers to write a snippet of code to store a password: Half of them were asked to write down a specification of how the code should behave before writing the program, the other half were asked to write the code but without being prompted to write a specification first. We find that explicitly prompting developers to write a specification has a small positive effect on the security of password storage approaches implemented. However, developers often fail to store passwords securely, despite claiming to be confident and knowledgeable in their approaches, and despite considering an appropriate range of threats. We find a need for developer-centered usable mechanisms for telling developers how to store passwords: lists of what they must do are not working.

Cyber security decision making is inherently complicated, with nearly every decision having knock-on consequences for an organisation’s vulnerability and exposure. This is further compounded by the fact that decision-making actors are rarely security experts and may have an incomplete understanding of the security that the organisation currently has in place. They must contend with a multitude of possible security options that they may only partially understand. This challenge is met by decision makers’ risk thinking —their strategies for identifying risks, assessing their severity, and prioritising responses. We study the risk thinking strategies employed by teams of participants in an existing dataset derived from a tabletop cyber-physical systems security game. Our analysis identifies four structural patterns of risk thinking and two reasoning strategies: risk-first and opportunity-first . Our work highlights that risk-first approaches (as prescribed by the likes of NIST-800-53 and ISO 27001) are followed neither substantially nor exclusively when it comes to decision making. Instead, our analysis finds that decision making is affected by the plasticity of teams—that is, the ability to readily switch between ideas and practising both risk-first and opportunity-first reasoning.

There is a broad consensus that understanding system desiderata (requirements) and design creativity are both important for software engineering success. However, little research has addressed the relationship between design creativity and the way requirements are framed or presented. This paper therefore aims to investigate the possibility that the way desiderata are framed or presented can affect design creativity. Forty two participants took part in a randomized control trial where one group received desiderata framed as “requirements” while the other received desiderata framed as “ideas”. Participants produced design concepts which were judged for originality. Participants who received requirements framing produced significantly less original designs than participants who received ideas framing (Mann-Whitney U=116.5, p=0.004). We conclude that framing desiderata as “requirements” may cause requirements fixation where designers’ preoccupation with satisfying explicit requirements inhibits their creativity.