Do You Speak Cyber? Talking Security With Developers of Health Systems and Devices

Teams developing software for health-related applications often have little professional security support. To work effectively with them, we should accept the complexity of their decision making, create stories as a basis for discussion, and use different jargon from cyberprofessionals.

S ecurity and privacy are vital software properties and are critical in health-related devices and applications. 12 However, many cybersecurity practices can be poorly suited to modern agile development approaches and to systems involving many Internet-accessible components, 3 such as Health Internet of Things (HIoT) systems. 8 Further, the cost and lack of availability of cybersecurity professionals makes it unrealistic to have dedicated cybersecurity support in small companies. Instead, the responsibility for security and privacy is typically delegated to nonsecurity-specialist developers. Lacking support from cybersecurity professionals, such developers in small to medium companies frequently turn to industry-based training and open sources for support and guidance materials. 1

What Is the Problem?
Consider such small company HIoT developers-meaning everyone responsible for development, including testers and decision makers. For them, security and privacy are just two aspects among many for the product they are developing. The teams, thus, have limited time available to devote to learning about them. Any guidance or advice must use developers' language and mesh with their existing procedures and operations; otherwise, it risks being ignored, misunderstood, or devalued. Making guidance and support usable for developer teams, therefore, requires knowledge of the language they use to discuss cybersecurity. It also requires an understanding of how their cybersecurity decisions are made. However, currently that knowledge and understanding are anecdotal at best and, frequently, nonexistent. If we, as academics and security specialists, are to work with development teams to improve cybersecurity practice in heath and health-related devices, we must learn to talk the developers' own language: to speak their dialect of cybersecurity.
The goal of this article, therefore, is to explore, for the important domain of HIoT software, how small company development teams discuss and decide on security and privacy issues to support training and interventions by academics and security specialists.
To that end, the authors used a qualitative approach, interviewing 20 senior software professionals in small companies creating health-related devices and services. The research gathered data using open-question interviews to explore the topics in two different ways. The

USABLE SECURITY AND PRIVACY FOR SECURITY AND PRIVACY WORKERS
first was an evaluation of four predictions (PRs) that we made based on prior work. The second was an open exploration of development teams' decision making and language relating to security and privacy. A thematic analysis of the transcribed interview data produced a nuanced picture of security and privacy practice in the participants' teams. Figure 1 shows the stages in the research process. The rounded rectangles show activities; the rectangles show artifacts, and the arrows show the resulting contributions. We minimized bias through diversity in the participant pool, by piloting the survey instrument, with reviewing codes, and by using dual coding-even for open coding. The stages are highlighted in the following descriptions.

The Research Process
The two research questions (RQs) the research sought to explore are as follows: ■ RQ1: How do independent HIoT software development teams describe and discuss security and privacy? ■ RQ2: How do independent HIoT software development teams make decisions about security and privacy?
From these questions, we identified PRs based on prior work 10 and our experience of working with development teams. Two PRs are related to RQ1: ■ PR1: There is inconsistency between developers' and stakeholders' understanding of key concepts and that of security experts. ■ PR2: Developers use "war stories"-spoken tales of relevant incidents-to communicate about security and privacy issues Two further PRs are related to RQ2: ■ PR3: Development teams do not analyze threats and the risks they pose in agile development processes related to the HIoT.
■ PR4: The security and privacy of the product or service is not considered a saleable aspect.

Data Collection
We designed a survey instrument of 32 open questions to probe the PRs and elicit qualitative information related to language and decision-making approaches (RQ1 and RQ2). The questions included asking participants to sketch their understanding to clarify concepts. We piloted the survey with two colleagues experienced in commercial software design (though not in the HIoT domain) to check timing and comprehensibility. One question was added, and five questions were categorized as optional to keep the survey to time. The final version of the survey instrument is publicly available at https://github.com/SecurityEssentials/ DoYouSpeakCyber.
To recruit participants, we used three sources: contacts of the authors and from the university business network; open advertisement, such as e-mail newsletters and social media; and cold-calling to HIoT companies. To identify when "thematic saturation" 2 was reached, an analysis was conducted in parallel with the interviews.
Interviews took place online using Microsoft Teams, which provides both recording and automated transcription. Transcripts were anonymized, corrected, and imported into the Qualitative Data Analysis tool NVivo. (Our tool to convert transcript formats is available at https://securityessentials.github.io/Teams2NVivo/.)

Data Analysis
The thematic analysis followed the six-stage process established by Braun and Clarke. 4 This involves the following: 1. familiarizing yourself with the dataset by reading transcripts and listening to recordings of interviews 2. an initial analysis of the dataset through coding, giving labels to the excerpts and concepts found 3. exploring your codes for emergent themes and finding patterns across the dataset 4. refining and reviewing those themes against the dataset 5. finalizing and naming themes 6. writing up the results of your analysis.
We used combinations of open coding (emergent and inductive) and closed coding (with predefined codes) to generate meaningful analysis. 4 For example, the closed code "definition of security" provided many definitions; to summarize them, we open-coded "definition categories" within the coded text, and we analyzed the emergent open code "decisions and prioritization"  using closed coding into the categories "formal," "informal," and "none. " We also used pairs of codes to capture the magnitude. For example, every statement coded to "story use" (PR2) had an additional category code of "never," "occasional," or "frequent. " To analyze participants' sketches, an independent researcher created text descriptions of each. These and the participants' verbal descriptions provided text for the thematic analysis. 6 We used dual coding throughout the closed-coding process: two researchers coded all of the data independently, meeting regularly to compare notes and coding. We also used dual coding to categorize attributes of the participants, such as the target customer, product category, and company size. Following the initial coding round, the two researchers doing the coding then then discussed their differences and recoded accordingly.
To conduct the inductive open thematic coding, we created new codes during the coding process to express new concepts as they were discovered. Given that decisions on what is important are subjective, we used the unusual "reflexive" approach of dual open coding. 5 Our approach was iterative: in each iteration, two coders agreed on three or so interview transcripts to code; then, each independently open-coded those transcripts. They then met to compare the coding, agree on a synthesis of the code sets, and decide on any changes to the coding approach. After this, they continued with the next iteration.
Following the initial coding of all interviews, we returned to recode all of the previously coded transcripts. This found further instances that fitted each code and fixed some erroneous coding.
To transition from codes to themes, using Braun and Clarke's approach, 4 we clustered the codes by unifying features into themes. We then reviewed all themes against the codes to ensure the completeness of the set. Codes that did not fit any possible themes were omitted. 4 We then gave names to the themes and wrote up the results.
The research was approved by the Lancaster University Faculty of Science and Technology Ethics Committee.

Results and PR Evaluation
We recruited and interviewed 20 participants as follows: ■ Twelve interviewees were at the C level or were vice presidents; the rest were senior development staff. ■ Their professional experience ranged from 3 to 40 years (median: 20; interquartile range: 17). ■ All worked on health-related products; 15 were currently working or had recently worked on IoT-related products.
■ Fourteen worked for "small" organizations of fewer than 500 staff members, with six "medium" organizations up to 10,000. ■ Seventeen were based in the United Kingdom, with others in The Netherlands, , and Denmark.
Participants' work provided remote monitoring (five interviewees), health service administration (four), software components (four), patient devices (three), consumer self-care (three), and artificial intelligence-based diagnosis (one). The interviews generated a total of 21.5 hours of audio. Some participants were reluctant to draw, and only 12 participants' drawings were captured.

Cyber Language Use
It seems reasonable to assume that people working together on a development team will share a technical vocabulary and use that in discussion. To explore PR1 (inconsistency in the understanding of key concepts), therefore, we analyzed the transcripts using open coding to identify key terms used by participants. Next, we added terms from the National Initiative for Cybersecurity Careers and Studies glossary of 235 common cybersecurity words and phrases. 7 Finally, we assessed the interview transcripts for the participants' usage of the combined set, being careful to exclude semantically different uses (such as "trustworthy system" or "hospital trust" for "trust"). Figure 2 shows a word cloud of the results. Word sizes denote the number of participants who used each term; black terms are those defined in the NICCS glossary, and red terms are those unique to the interviewees. Terms mentioned by only one person are omitted, as are concepts included in the questions (such as "security" and "privacy").

USABLE SECURITY AND PRIVACY FOR SECURITY AND PRIVACY WORKERS
As shown, where common concepts were used, many of them were the standard ones used by cybersecurity practitioners. Note, however, that most were little used: even "threat," for example, occurred in only 11 interviews. Moreover, where the words were standard, the meanings were not always so: four participants used "a risk" to mean "a threat," for example.
Two groups of nonstandard terms appeared often in the discussions: ■ "Trust" refers to stakeholders' trust of the systems.
The related terms "confidence" and "reputation" tended to be found in the same context. ■ "Safety" was vital for the many practitioners working with safety standards. "Certification" and "governance" requirements were often related to patient safety.
Next, we looked at participants' discussion around four key concepts. These concepts were as follows: ■ threat: a potential cybersecurity-related problem ■ threat actor: an individual who might deliberately or accidentally trigger such a problem ■ incident: an occurrence of such a problem ■ victim: people or organizations adversely affected by an incident.
We found that two of these concepts, "threat actor" and "victim," rarely had a generic term. Instead, interviewees named specific roles: "criminal," "hacker," "user," and "nation state" for the threat actor and "'shareholder," "company," "user," or "patient" for the victim. Indeed, seven interviewees stated that their most likely and damaging "threat actors" were the professional users of the systems.
We found that most of the participants did identify terms for "threat" and "incident, " as shown in Figure 3. Here, colors and word sizes reflect the use of each term with those specific meanings. Usage was not at all consistent among participants; the largest words in each cloud represent use by only four participants.
Finally, we asked participants to define "security" and "privacy. " Almost all participants explained security in terms of the aspects of cybersecurity most relevant to their own products. They defined "security" in one of three ways: technical features provided by the product implementation, possible and implied harms prevented, or a desired social or commercial outcome. The top part of Table 1 shows examples and how many participants used each one.
Unsurprisingly, given the sensitivity of health information, "privacy" was an important concern for many of the participants. As with "security," the bottom part of Table 1 shows several different approaches to defining it. Many specified the outcomes achieved by successful privacy; others expressed it in terms of compliance, referring to standards, such as GDPR; and one participant did not use the term at all.

Use of Stories
The analysis of PR2 (developers use stories) found that pure "war stories," in the limited sense of "how I diagnosed and fixed a cyber issue," were relatively rare. However, "stories," representing cybersecurity knowledge with an ad hominem example, were common.
Indeed, many participants used stories in answering questions. Therefore, we also analyzed their discussions on other topics, finding that 17 of the 20 participants used stories in this way. Here is one example: A guy I worked with used to defend a lot of people in court against phantom withdrawals. And his argument was this. You're saying my client withdrew £50 in this cash point. He said he doesn't, so I want to interview all your programmers and to check your private key on that device. . . . So, if you just like to disclose what your private key is on that. No. How do I know it's a good one? . . . So, the result was they started putting  Of the three participants who did not use stories in their interviews, one stated that their team used stories "frequently" and two that their teams used them "sometimes. " Therefore, all were familiar with the use of such stories.

Approach to Security and Privacy Decision Making
In exploring PR3 (development teams do not analyze threats and risks) and PR4 (security and privacy are not saleable), we expected both to be heavily influenced by customer requirements. We accordingly analyzed the results by customer type: National Health Service (NHS), the primary U.K. health-care provider; business-to-business (B2B) for products and services sold to other businesses; and consumer for products sold directly to end users.
To our surprise, many participants used threat and risk analysis, in some cases to a very impressive level. The left side of Table 2 highlights the number of participants who used formal threat assessment with documented outcomes, who used informal threat assessment, or who mentioned neither.
For security sales, we observed that, in many ways, the security of a product might be required to make a sale but not valued by customers as a "selling point. " Instead, customers would expect the security to be present. The right side of Table 2 shows how participants described their own product sales.

Thematic Analysis
The open coding generated an initial 34 codes. Table 3 shows the 27 codes from which themes were identified, excluding topics outside the scope of the RQs. Colored cells show participants' contributions to each. Codes are sorted top to bottom in decreasing order of number of the number of contributing participants; participants are in order of interview date, leftmost first.
The right side of Table 3 shows that the coding of the last seven participants generated no new codes. This "thematic saturation" suggests that the sample of 20 interviews was probably sufficient to capture all relevant themes.
The categorization process grouped these codes into six themes: the dominance of compliance, health as a complex hybrid domain, mechanisms for prioritization, the decision-maker ecosystem, the complexity of the decisions to make, and the factors influencing decisions. Table 3' s column "T" shows the theme number associated with each code.
The following sections describe each of the themes, including quotations from interviewees. Codes from Table 3 are in italics.

Theme 1: Dominance of Compliance
A much-repeated topic was standards compliance, which affected most of the participants: I assess what our requirements are to legally release the product in compliance with . . . the medical device regulations. (product manager) [It' s] making sure you conform to some normal industry standards like ISO27001, GDPR. Cyber Essentials is another one we get asked for. (chief technical officer) Some standards require a responsible individual for security issues. However, the standards cited, except GDPR    and Cyber Essentials, relate largely to safety and confidentiality rather than cybersecurity: However, many safety-related standards mandate a rigorous, fully documented, risk-based approach. Participants found that well-suited to addressing cybersecurity -related issues:

USABLE SECURITY AND PRIVACY FOR SECURITY AND PRIVACY WORKERS
And in the process of ensuring that for safety that also works for security as a sort of side benefit. (consultant) Given the importance of privacy to compliance, some saw cybersecurity simply as security to ensure privacy; one also needed security to support reliability.

Theme 2: Complex Hybrid Domain
Most participants mentioned the complexity of the domain. Projects may have many different stakeholders for security, such as medical staff, investors, and purchasing teams. They also reported a range of varied requirements for cybersecurity: Like in the USA is the HIPAA [Health Insurance Portability and Accountability Act], and in Europe it will be the GDPR. (chief technical officer) It also became clear as the interviews progressed that "HIoT" was not one but several different domains. For example, the requirements for home monitoring were very different from those for implanted devices.

Theme 3: Range of Mechanisms for Prioritization
A frequent theme that emerged from the analysis was, unsurprisingly, decisions and prioritization: approaches for decisions about the prioritization of security and privacy activity against other development. Seven of the participants described a score-based risk assessment approach. Using a score basis makes the decision one that the technical team could take without (necessarily) needing product manager input: We rate its importance; we rate how much work it will be to address it. And then we divide those two. . . . It gives you a way of prioritizing which issues you should be working out. (managing director) Of the other participants, eight described a less process-driven approach, where the decisions were solely made by product management. Others did not identify a specific mechanism.

Theme 4: Decision-Maker Ecosystem
Agile methodologies often expect decisions to be made by a single "product owner." 9 However, the decision-making processes described involved a much wider range of stakeholders. Five of the participants described decision making by a product management committee of senior and expert staff.
Other concerns were a need to reassure stakeholders and sometimes that security and privacy [was] a battle with clients: It is an upwards battle to try and get clients to be fully aware of the implications of cyber, not just from a security point of view, but from the return-on-investment point of view. (CEO) Indeed, some mentioned sidestepping this battle by smuggling in security without stakeholder knowledge.

Theme 5: Complexity of Decisions
There were some noteworthy complexities to the threat assessment process. Participants stated that many of the medical devices have long software lifetimes and that even more have a need for secure software updating. Evaluating problems in the field also presented issues, particularly keeping users private from developers. Further, though the survey was about software development, the threat assessment implications for most of the organizations were far wider in scope. Many participants mentioned the operations required around security and privacy and, particularly, responding to events. A further important issue was auditing, supporting third-party assessments of the organization's security compliance.

Theme 6: Variety of Factors Influencing Decisions
Finally, a major theme of the discussions was about the factors influencing security and privacy decisions. Table 4 illustrates eight examples.

Limitations
As with any survey, there are limitations in how far we can take the conclusions. Specifically, we can identify two concerns in our analysis of the survey: ■ Generalizability: The thematic saturation suggests that the findings are generalizable to any software development teams in small and medium health and HIoT companies in the United Kingdom. Though a few interviewees were from farther afield, we have no basis for deductions about similar companies outside the United Kingdom or in other fields.

USABLE SECURITY AND PRIVACY FOR SECURITY AND PRIVACY WORKERS
■ Potential for bias: The randomness of the recruitment approach means this is likely to be a representative sample of small and medium organizations in the HIoT domain. There is, though, a possibility of systemic bias in the recruitment.

Conclusions
Returning to this article's goal, to enable security specialists and academics to support isolated HIoT development teams as effectively as possible, we can draw out three conclusions, as follows:

Conclusion 1: Take Care With Language When Working With Developers
From the survey's exploration of PR1 (inconsistency in the understanding of key concepts with that of security experts), we found that the PR was largely correct. Figure 2 shows that the use of key security and privacy terms appears superficially similar to that of cybersecurity experts. However, Figure 3 shows that the meanings attached to those terms are often different. Therefore, while many used "event" or "incident" with the cybersecurity-standard meaning, very few used "threat" with its corresponding meaning. Also, few used "threat actor" or "victim"-or even had terms for those concepts. Almost all used more specific terminology for their context instead of these two terms. However, participants' understanding of and definitions for "security" and, to a lesser extent, "privacy" were generally accurate and tailored to their own project contexts. From this, we conclude that, while cyber experts will probably understand the terms used by developers, we cannot assume that developers will understand cyber experts. Specifically, when working with HIoT developers, there is little need for cyber experts to explain the concepts of "security" and "privacy. " An "event" is likely to be understood. A "risk," though, might be a better term to use than a "threat. " In addition, if the concepts of "threat actor" or "victim" are needed, they will require definition and explanation.

Conclusion 2: Use Stories to Communicate
PR2 (developers use stories) also proved correct, with 18 of the 20 interviewees describing story use in their projects and 17 using stories themselves. This suggests both that stories are a good way to communicate concepts and knowledge and that stories are likely to be well received by isolated HIoT developers. We can conclude that stories are a useful tool to communicate with most, if not all, HIoT development teams.

Conclusion 3: Empower Teams to Support the Complex Decision-Making Process
We found that PR3 (development teams do not analyze threats and risks) was not supported by the survey. All of the participant companies supplying the NHS and a clear majority of the remainder carried out threat assessments. In most cases, this was a formal written process. Fifteen of the 20 also had a clear process to prioritize the mitigation of identified problems. Seven, indeed, described a numerically driven process, potentially allowing prioritization independently of product management. We can conclude that, in the HIoT domain at least, there may be little need to teach risk-based threat assessment from scratch.
PR4 (security and privacy are not saleable) also proved incorrect. There were no participants for whom security and privacy were not either required or valued, in one way or another, by customers. The "entry stakes" requirements were generally compliance standards related to the product. They impacted more than just the software: auditing, cybersecurity operations, and defect tracking were concerns for many participants. We conclude that, in the HIoT, it may be inappropriate to promote cybersecurity and privacy as a novel sales approach. Small companies and start-ups "The security side is a worry, but we're not big enough that we have a big target on our back." (product manager) It was clear in the thematic analysis that compliance related to safety and privacy was an essential driver in most HIoT cybersecurity and privacy. Therefore, any support could productively be motivated via these compliance requirements.
However, a major challenge for support is clearly the complexity of the decision landscape. The range of considerations in Table 4 alone shows that attempting to simplify decisions would be both inappropriate and unhelpful.
Assuming that there is a single decision maker to influence would also be incorrect; security and privacy decisions are often made by committees.
We conclude that couching support to isolated HIoT development teams as direct instructions or externally imposed "secure development lifecycles" 11 is likely to fail. Instead, such support might contribute to existing decision-making processes by empowering the teams to work with stakeholders to make better decisions. Possibilities for such support might be providing industry risk information or approaches to improve threat analysis.
T his article describes a survey of 20 experts working in small to medium enterprises in the health and, predominantly, the HIoT domains. The results suggest that any intervention working with HIoT developers can profitably ■ assume a working understanding of the terms "security" and (usually) "privacy" ■ expect, but not rely on, a knowledge of risk-based threat assessment ■ assume a need for security or privacy from their customers (but not that either may necessarily be a sales point) ■ motivate security in terms of compliance with existing safety and privacy standards ■ avoid, or take great care with, terms such as "threat," "risk," "threat actor," and "victim" ■ use stories to express cyber "threats" in an easily understandable way ■ avoid approaches that oversimplify the complexity of decision making, such as providing direct "how to" instructions.
We also observe that the survey instrument and method can support similar research addressing any other domain. This guidance offers clear direction to anyone creating an intervention to use with HIoT developers, especially those isolated from security professionals. It also suggests possibilities and a well-defined approach to consider for development teams in any other domain.
Using this guidance will help security specialists and academics support HIoT and other development teams. That will lead to vital improvements in the security of the software systems on which we all rely.