Security-Focused Prototyping: A Natural Precursor to Secure Development

Secure development is often thought of as a proactive approach to cyber security. Rather than building a technological solution and then securing it in retrospect, secure development strives to embed good security practices throughout the development process and reduce risk. Unfortunately, evidence suggests secure development is complex, costly, and limited in practice. This article therefore introduces security-focused prototyping as a natural precursor to secure development. Security-focused prototyping embeds security at the beginning of the development process, can be used to discover domain-specific security requirements through active learning, and can help communicate the complexity of secure development to organizations such that the resources and commitment it requires are better understood. A case study considering the application layer of an Internet of Things system is presented and shows that security-focused prototyping has the potential to facilitate further secure development through the achievement of well-established prototyping objectives, such as communication, active learning, and reduced time/costs. Future work could build on this work by conducting additional case studies to further explore the potential of security-focused prototyping and investigating the importance of fidelity with regards to security-focused prototypes.


I. INTRODUCTION
Secure development models provide a means of minimizing risk when creating a technological solution and are therefore especially useful tools when working with emerging technologies. Unfortunately, secure development is complex, costly, and limited in practice [1]. There are numerous secure development models and no universally accepted answer as to which is the best. Furthermore, many of the prominent secure development models are not always applicable. Geer surveyed 46 organizations and found that only the most technically sophisticated-approximately 10% of respondents-were adopting a secure development model [1]. Many of the respondents This is a direct result of working on the ERDF Greater Manchester Cyber Foundry which is part funded by the European Regional Development Fund.
reported that they had not adopted a secure development model because it was either too expensive, required too many resources, or was too time-consuming [1], and numerous studies present a similar narrative [2]- [5].
The challenges faced by small and medium-sized organizations (SMEs) highlight the need to make secure development more easily accessible. SMEs are perceived as being less equipped when it comes to cyber security than larger organizations [6] and this is true of secure development as well; in [5], 123 developers are surveyed and the results show that SMEs are more likely to have 'competing priorities and no plan' and be 'unequipped for security' than larger enterprises. Other studies are similar and document the challenges SMEs attempting to digitalize must overcome [7]- [9].
The Greater Manchester Cyber Foundry project aims to help SMEs overcome these challenges. The project consists of 2 phases, the second of which requires the creation of proof-ofconcept demonstrators over relatively short timescales. These proof-of-concept demonstrators serve a dual purpose and are intended to increase innovation, but also the adoption of security practices, across SMEs in the Greater Manchester (UK) region. The challenge faced by the project is that the short timescales over which the proof-of-concept demonstrators need to be developed make it difficult to adopt a wellestablished secure development model.
To address all these problems, we present a novel technique-security-focused prototyping-that acts as a precursor to secure development by embedding security at the beginning of the development process, facilitating the discovery of domain specific security requirements through active learning, and helping to communicate the level of resources and commitment that are required for secure development to continue. We start by describing the largely disparate worlds of prototyping and secure development in section II, then synthesize the two by describing security-focused prototyping and our method for investigating the approach in section IV, before validating the approach by describing its application to a case study in section V, and ultimately concluding by discussing the potential of the technique in section VI.

A. Contributions
The original contributions resulting from our research are summarised as follows: • We propose security-focused prototyping as a novel approach designed to facilitate further secure development.
Our approach can be understood as a form of relaxed requirements prototyping but is unique in the way it sees functional requirements relaxed. Traditionally functional requirements are the focus of a prototyping effort and other design requirements (such as security requirements) are relaxed.
• We present a case study that highlights the potential of security-focused prototyping and demonstrates its ability to facilitate secure development through the achievement of well-established prototyping objectives, such as communication, active learning, reduced time and costs.

II. BACKGROUND
In 2002, the Trustworthy computing memo was sent to all Microsoft employees [10]. The memo sought to lessen customer concerns and bad press caused by security concerns [10], [11]. It defined trustworthy computing as computing that is available, reliable and secure as electricity, water services and telephony [10]. It triggered a rethink within Microsoft and led to the Microsoft Security Development Lifecycle (MSDL) [11]. Today, 12 practices make up the MSDL [12]. Table I presents these practices in a summarized form (for brevity) and maps them to six common development phases put forward by [13]. Considered as a whole, the MSDL can be thought of as a comprehensive process. Table I shows that it specifies at least one practice for each of the development phases. However, the MSDL does have a significant shortcoming-the practices it contains explain what should be done, but place less emphasis how it should be done.
In 2004, seven software security touchpoints were put forward by [14]. These touchpoints are presented and mapped across the six development phases first put forward by [13] in Table I. From Table I a shortcoming of the touchpoints can be identified, none cover the 'education and awareness' and the 'project inception' phases. This lack of coverage at the earliest development phases is problematic and could result in teams being under-prepared, though this issue is addressed in a later work that explains how the touchpoints can be incorporated into a complete enterprise software security program [15]. Furthermore, much like the practices in the MSDL, many of the touchpoints specify what should be done but fail to go into significant detail as to how it should be done. By not specifying exactly how practices should be implemented both models remain technology and process agnostic, which means both are generally applicable.
Several years after the touchpoints were introduced, in 2007, the Software Assurance Forum for Excellence in Code (SAFE Code) was founded [16]. SAFE Code is an industry-led nonprofit organization with the goal of promoting and facilitating the adoption of effective secure development practices [16]. In pursuit of this goal, the organization publishes guidance that is centered around 8 fundamental practices [17]. Table  I shows that these practices are comprehensive and together span the six phases of development. Like the MSDL and the touchpoints, the SAFE Code practices are largely technology and process agnostic, which is often perceived as a strength but is also a weakness. Even though the SAFE Code practices are sound, the lack of a systematic method for realizing them is a barrier organizations looking to achieve secure development must overcome. Table I demonstrates that there is some overlap between the MSDL, the touchpoints, and the SAFE Code guidance. For example, it shows that all three recommend defining security requirements and that the MSDL and touchpoints both recommend penetration testing be performed. Furthermore, there are similarities between the three approaches that are not immediately apparent from table I. For example, all three recommend code reviews, but do so in subtly different ways. The MSDL draws a distinction between static and dynamic analysis security testing [12], the touchpoints simply recommend code reviews and note that these can be manual or automated [14], and SAFE Code advises code reviews be performed along with other activities like penetration testing by recommending that testing and validation be performed [17].
However, Table I also demonstrates that there are significant differences between the three secure development models. For example, when considered in isolation the touchpoints differ from the other two models in offering no guidance related to the planning and implementation of secure development. Furthermore, there are differences in the detail of similar recommendations that are not demonstrated by Table I. Both the MSDL and SAFE Code provide guidance with regards to the management of third-party components, but the detail of this guidance is subtly different in a number of ways. SAFE Code maps mitigate, monitor, and assess activities onto a third-party component management lifecycle [17], whereas the MSDL simply lists 4 practices that can be adopted [12].
Table I therefore demonstrates the complexity of secure development. This complexity has led to research and the formulation of further models that provide a means of assessing and evaluating other secure development models [13], [18], [19]. The Software Assurance Maturity Model (SAMM) [18], and an early fork of it known as the Building Security In Maturity Model (BSIMM) [19], are particularly notable examples. The SAMM and BSIMM models are both comprehensive and provide a means for organizations to improve via the incremental adoption of security practices. Nonetheless, both of the models fail to provide domain specific recommendations. The narrative of secure development being too costly, requiring too many resources, and being too time consuming has continued since their formulation [1]- [5], which suggests further work is still needed to make secure development more accessible. The complexity of secure development is further exaggerated by the variety of technologies that can be developed today. In general, secure development refers to the secure development of software but software comes in many different forms. Software can be developed for mobiles, it can be delivered via cloud computing, and it can form a part of an Internet of Things system (a network of interconnected devices and software that exchange data). Each of these scenarios has unique challenges and guidance associated with it [20]- [22]. Secure development is therefore highly domain-dependent. Different practices, tools, and threat actors need to be considered when building solutions with different technologies and for different purposes. The prominent models discussed in this section are technology agnostic and therefore fail to offer this kind of domain-specific guidance.

III. RELATED WORK
Prototyping is often a fundamental part of the design and development of software. Many different approaches to prototyping exist and different organizations will use different techniques in pursuit of different objectives. The act of prototyping can nonetheless be summarised as producing early working versions of a system and experimenting with them [23]. The act of design prototyping can therefore be understood as producing and experimenting with early working versions of a system in the early stages of development to minimize risk.
Despite the vast quantity of distinct approaches to prototyping, a taxonomy through which these approaches can be understood has been steadily emerging. In a review of the subject, Camburn et al present a synthesis that defines prototyping objectives, techniques, and the relationships between them [24]. In their review, Camburn et al make a distinction between techniques that are applied at a higher level to navigate the space of potential solutions, and techniques that are applied at a lower level to reduce the costs and time associated with the development of a single prototype [24]. In this work, we will refer to the former as search techniques and the latter as reduction techniques.
Iterative and parallel prototyping are the two search techniques. In iterative prototyping, a sequence of prototypes concerning a single design concept are produced and requirements are achieved gradually [24]. Each prototype builds on previous prototypes. In contrast to iterative prototyping, parallel prototyping sees prototypes developed to explore multiple design concepts [24].
The reduction techniques complement the two search techniques and are applied when a single prototype is being created. They are intended to reduce the cost and time it takes to produce a prototype, and thereby allow for multiple prototypes to be produced as a part of an iterative or parallel prototyping effort [24]. Camburn et al identify four such techniques and refer to them as 'factors affecting the construction of a prototype': requirements relaxation, sub-system isolation, scaling via similitude, and the use of virtual media [24].
Requirements relaxation is the most important reduction technique with respect to this work and closely related to security-focused prototyping. Requirements relaxation is a reduction technique that sees a subset or otherwise reduced set of requirements addressed. Requirements can be relaxed to different extents to produce prototypes of differing fidelity, such as mock-ups, storyboards, and zygotic narratives [24]. A mock-up of a product or service is likely to be of higher fidelity than a zygotic narrative or science-fiction prototype-a short narrative used to explore future scenarios [25]-which are widely regarded as being of the lowest fidelity. The challenge when applying requirements relaxation is therefore finding the right balance; reducing the time and cost a prototype consumes while ensuring it still produces valuable information.
Zygotic narratives and science-fiction prototypes can also be understood as design fictions, as these kinds of prototypes exist in a fictional world and are used to interrogate possible futures through the creation of a discursive space [26]. Prior work has considered the ability of design fictions to facilitate threat discovery through games. In [27], the authors explain the benefits of this approach and focus on the benefits to students in particular. However, there is also evidence of practitioners using games to facilitate threat discovery. In [28], a card game-'Elevation of Privilege'-that aims to help practitioners construct threat models is described.
The playing of games like 'Elevation of Privilege' could be considered a form of security-focused prototyping, as when playing these games functional requirements are relaxed such that security is the focus of the prototyping effort. In this research, the security-focused prototyping that is considered results in a prototype of a higher fidelity, more like a product mock-up, than those produced during games like 'Elevation of Privilege'. In section VI, we note that further work could explore the advantages and disadvantages of security-focused prototypes of differing fidelity.

IV. METHOD
To evaluate security-focused prototyping we have performed a case study. Security-focused prototyping was applied within the context of technical assistance delivered as a part of the Greater Manchester Cyber Foundry project.
The security-focused prototyping that was applied can be understood as a form of requirements relaxation. Functional requirements were relaxed so that we could focus on identifying and satisfying security requirements instead. Relaxing the functional requirements allows for a security-focused prototype to be produced faster and at a reduced cost, which allows for an iterative or parallel prototyping strategy to be adopted. By adopting an iterative or parallel strategy, the risk of a team not being able to satisfy the security requirements is reduced.
Security-focused prototyping was applied to create a prototype application layer for an Internet of Things (IoT) system. We chose to use this particular security-focused prototyping effort for our case study as the analyst delivering the assistance had relatively little experience with respect to the IoT. If the analyst had been especially experienced and knowledgeable with regards to the IoT this would have hindered our ability to establish whether or not security-focused prototyping supported active learning.
After the security-focused prototyping was complete we performed a case study. We recorded evidence of established prototyping objectives: communication, active learning, and reduced time and cost [24]. Some further works have since defined additional objectives, such as integration, demonstration, and elicitation [29]. However, the four objectives defined by Camburn et al [24] are considered sufficient for this work.
The communication objective refers to the sharing of information relating to a design [24]. Active learning refers to the gaining of knowledge about a design space or related phenomena [24]. In [30], while explaining the benefits of active learning the authors note that prototyping creates learning opportunities and a sense of forward progress. In the case of security-focused prototyping, these learning opportunities could lead to the discovery of domain-specific security requirements, and a sense of forward progress should help embed security at the beginning of the development process. The reduced time and reduced cost objective is evidenced by refinement or exploration, where refinement refers to the incremental improvement of a design and exploration refers to the seeking out of new design concepts.
When performing this case study considered several sources of evidence (as is shown in figure 1): handover documentation that describes the technical assistance in retrospect, direct observations made during the prototyping and meetings with stakeholders, and physical artifacts of the technical assistance such as repositories containing code. As Yin [31] explains, it is beneficial to use multiple sources of evidence as any finding or conclusion resulting from a case study is much more convincing if it is based on multiple sources of evidence.

V. RESULTS
The security-focused prototyping was successful and resulted in a prototype application layer for the proposed Internet of Things system. During the prototyping, functional requirements were relaxed to the extent that only two feature sets were considered. The first of these feature sets led to a prototype REST API that sends and receives mock data. The second feature set led to an early version of an alert system that uses WebSockets. If only one of these feature sets had been implemented it is likely fewer security requirements would have been identified and considered. If additional feature sets (e.g. editing the colours of a visualisation showing the mock data) had been implemented the cost and time required to build the prototype could have increased. Security-focused prototyping must therefore be performed with care such that valuable information results from the prototyping effort.
In general, the evidence we considered suggests securityfocused prototyping facilitates communication and active learning with respect to software security and thereby makes secure software development more accessible. The evidence also suggests a security-focused prototype can be produced at a reduced cost and in reduced time, which means it could form a part of an iterative or parallel prototyping strategy.

A. Evidence of Communication
We observed that security-focused prototyping led to increased communication. The handover document and direct observations documented during meetings with stakeholders both suggest the prototype application layer facilitated discussions where the analyst doing the prototyping was able to communicate security considerations to stakeholders. The direct observations also suggest security-focused prototyping helped with the elicitation of requirements; the direct observations evidence new functional requirements emerging during the prototyping and that these functional requirements led to new security requirements (via active learning, see section V-B) that were communicated back to stakeholders. For example, the functional requirement for an alert system raised by stakeholders led the analyst to discover several new security requirements relating to WebSockets that were then communicated back to the stakeholders.
The elicitation of functional requirements led to new security requirements and was therefore necessary to an extent. If the security-focused prototyping had relaxed functional requirements completely there would have been nothing to secure; establishing functional requirements towards the beginning of the prototyping was therefore advisable. However, the direct observations documented during meetings with stakeholders suggest that these functional requirements remained a focus for some stakeholders for an extended period of time, to the point that it became counter-productive. This tendency amongst stakeholders was expected given that software prototypes typically focus on functional requirements. However, it is nonetheless a challenge that anyone conducting security-focused prototyping should be aware of. Practitioners of security-focused prototyping should take care to avoid fixation with respect to functional requirements and clearly communicate the value of security-focused prototyping before the prototyping effort begins to combat this tendency.
A related point, evidenced primarily by the direct observations documented during meetings, is that stakeholders in management positions considered the prototype that was produced to be of low fidelity. Stakeholders in technical roles however considered the prototype to be of higher fidelity. This observation is indicative of another challenge practitioners of security-focused prototyping should be aware of: demonstrating the value and significance of a security-focused prototype to stakeholders in management positions. However, the observation also highlights the promise of security-focused prototyping as a practice that can facilitate communication amongst stakeholders in technical roles; in recognizing the fidelity of the prototype application layer despite the relaxed functional requirements, these stakeholders demonstrated an appreciation for the time and commitment further secure development will require.

B. Evidence of Active Learning
We observed that security-focused prototyping facilitated active learning. A process in which functional requirements were elicited from stakeholders and led to the discovery of new security requirements via active learning-alluded to in section V-A-is significant in this regard. Importantly, some of the security requirements discovered as a part of this process were not known to either the analyst or stakeholders prior to the prototyping. The discovery of these requirements through active learning highlights the potential of security-focused prototyping as a means of identifying challenging, domain specific, security requirements earlier on in the development process.
The handover documentation further evidences active learning and the aforementioned process by describing several previously unknown design requirements related to security, such as: WebSockets should validate Origin headers to ensure requests come from expected origins, the maximum memory consumed by a connection should be set to a reasonable limit such that a malicious client cannot threaten the availability of the system by sending large messages, and the WebSocket Secure (wss) protocol should be used to establish connections. The handover documentation also evidences active learning by documenting a number of good practices that were learned during the prototyping, such as: the usage of code scanning tools for static analysis security testing, having an approach for storing and managing secrets, and having an approach to managing third-party components.
Repositories containing code provide further evidence of active learning and reveal that the analyst doing the prototyping learned how to satisfy several security requirements. Notably, the repositories demonstrate the analyst was able to satisfy security requirements that were known prior to the prototyping and security requirements that were unknown prior to the prototyping. For example, the repositories show that the analyst learned how to satisfy a previously unknown security requirement and validate WebSocket connections using the Origin header, and also how to satisfy several known security requirements, such as proper password strength controls.

C. Evidence of Reduced Time & Cost
We observed that security-focused prototyping can be performed at a reduced cost and in reduced time. The handover documentation describes how the prototype was developed using freely available tools and technologies. More importantly, all the sources of evidence suggest that security-focused prototyping was performed as a part of an iterative prototyping strategy, which would not have been possible if the cost and time required to create a prototype had not been reduced. The architecture was established and agreed early on-during the second meeting with stakeholders-with the remaining effort being spent figuring out how to satisfy security requirements and improve the overall security of the system.

VI. CONCLUSION
This article introduces security-focused prototyping, a process that can act as a valuable precursor to secure development. Motivated by observations that secure development is complex, costly, and limited in practice, security-focused prototyping strives to make secure development more accessible by increasing communication, encouraging active learning, and allowing for ideas to be tested in reduced time and at a reduced cost. A case study was presented and showed the ability of security-focused prototyping to: embed security at the very beginning of the development process, discover domain specific security requirements, and allow for the resources and commitment secure development will need to be better understood.
The potential of security-focused prototyping to various industries is therefore clear; it is a process that can be used to better reduce the risk posed by malicious actors. Future work could build on this working hypothesis and further evidence the potential of security-focused prototyping by conducting additional case studies and applying it in different domains. Future work could also explore the importance of fidelity with regards to security-focused prototyping and methods for better communicating the value of a security-focused prototype to stakeholders in managerial positions.
In summary, prototyping and secure development are analogous processes. By combining the two, security-focused prototyping makes secure development more accessible and thereby contributes towards a future where the benefits new technologies bring can be realized with less risk.