e-Informatica Software Engineering Journal, Volume 14, Issue 1, 2020, pages: 77–95, DOI 10.

37190/e-Inf200103

SIoT Framework: Towards an Approach for Early

Identification of Security Requirements
for Internet-of-things Applications
Ronald Jabangwe∗ , Anh Nguyen-Duc∗∗
∗
The Maersk Mc-Kinney Moller Institute, University of Southern Denmark, Software Engineering, Denmark
/ Software Improvement Group, SIG Nordics.
∗∗
School of Business, University of South Eastern Norway, Norway, Department of Business and IT
[email protected] / [email protected], [email protected]

Abstract
Background: Security has become more of a concern with the wide deployment of Internet-of-things
(IoT) devices. The importance of addressing security risks early in the development lifecycle
before pushing to market cannot be over emphasized. Aim: To this end, we propose a conceptual
framework to help with identifying security concerns early in the product development lifecycle
for Internet-of-things, that we refer to as SIoT (Security for Internet-of-Things). Method: The
framework adopts well known security engineering approaches and best practices, and systematically
builds on existing research work on IoT architecture. Results: Practitioners at a Norwegian start-up
company evaluated the framework and found it useful as a foundation for addressing critical
security concerns for IoT applications early in the development lifecycle. The output from using the
framework can be a checklist that can be used as input during security requirements engineering
activities for IoT applications. Conclusions: However, security is a multi-faced concept; therefore,
users of the SIoT framework should not view the framework as a panacea to all security threats.
The framework may need to be refined in the future, particularly to improve its completeness to
cover various IoT contexts.
Keywords: security requirement; Internet-of-things; Software Engineering; Requirement
Engineering; Security Framework
1. Introduction through the vulnerable internet and other net-
works. The border between software and hard-
Within the past decade, we have witnessed the ware parts is less visible when it comes to provid-
rapid growth of commercial systems that deeply ing customer value. Internet-of-things integrate
integrate software, hardware and the contex- both sensors, connectivity infrastructure and pro-
tual environment. The most notable are Inter- cessors with a software platform. The considera-
net-of-Things (IoT), Industry 4.0, cyber-physi- tion of security, therefore, needs to be in a holistic
cal systems, and smart wearable devices. The view that combines both software and hardware
number of (IoT) devices being introduced in parts of the system. Security issues are not new
the market has been increasing drastically with and have been a concern for years to manufac-
the number of connected devices approaching 15 turers. However, security in software-intensive
billion [1]. This trend is expected to continue, products is often neglected or treated as an af-
with an estimate of 26 billion network connected terthought. Business pressure, time-to-market
devices by the year 2020 [1]. and reduction of development costs are among
Security has become even more important factors that drive the treatment of security as an
as the number of “things” connected increases add-on feature.

Submitted: 20 November 2019; Revised: 30 March 2020; Accepted: 31 March 2020; Available online: 28 April 2020
78 Ronald Jabangwe, Anh Nguyen-Duc

Software Engineering (SE) researchers are plex data flow and architectural cross-cutting con-
looking for a way to address security concerns cerns [6, 10]. Consequently, securing the Internet-
as early as possible in the development and op- -of-things application development would require
eration of software-intensive products [2, 3]. In joint knowledge from data security, requirements
our study, we refer to “security concerns” for engineering and Internet-of-things architecture.
a given system as vulnerabilities, risks or threats Security should be addressed early in the devel-
that can negatively impact the security prop- opment process by ensuring that requirements
erties of the system, specifically, confidentiality, are clearly defined that when implemented, pre-
integrity and availability. The aim is to promote vent or mitigate security issues. It is noted that
security-by-design, which leads to having a proac- we do not aim at generating specific security re-
tive rather than a reactive approach for address- quirements through our framework. As a prelim-
ing security. The goal, which is also the same for inary result from a qualitative survey of qual-
threat modeling [4, 5], is to help with identify- ity concerns and practices in Internet-of-things
ing security concerns for a given system. These startups, we identified the need for early con-
security concerns can potentially be mapped to sideration of security requirements and map-
security requirements, which in-turn can help ping them into actual implementation. Address-
with designing secure systems. ing the issues early avoids costly rework late
Security requirements affect all aspects of in the development process. To this end, we
the design, development, deployment, and main- take a software engineering approach for ad-
tenance of complex systems that provide cus- dressing data security concerns early through
tomer value. To address security early in the a lightweight framework, SIoT (Security for
development cycle, security aspects should be Internet-of-things Applications). For Internet-of-
considered from the planning and requirements -things end-users, this can reduce safety risks and
phase, and throughout all the other phases. potentially improves privacy and data protec-
In response to the urgent need to deal with tion.
security in software-intensive product develop- Designing secure systems requires under-
ment [6–8], we aim at proposing a comprehensive standing the complex interaction between differ-
approach to identify security issues in the context ent parts of architecture and the security threats
of cyber-physical systems, specifically focusing for those parts. The SIoT framework, which takes
on Internet-of-things. More importantly, the ap- a layered view of the architecture of Internet-
proach will handle data security issues as an -of-things applications, provides a foundation
input for both product development and opera- for promoting that thought process. The aim
tion. Last but not least, the approach should be is not to generate specific security requirements
lightweight and easy to adopt in various sizes of through our framework. However, the output
organizations, particularly start-up companies. from using the framework can be a checklist that
This is due to the emerging number of Internet- can be used to help with identifying security
-of-things developed by start-ups. requirements for IoT applications.
A plethora of research work on software en- The remainder of the paper is organized as
gineering exists in relation to software security follows: Section 2 introduces basic understanding
and requirements engineering, and there is also about Internet-of-things products and security
a growing interest in Internet-of-things. Internet- identification approaches. Section 3 describes the
-of-things development is challenging due to the need for a lightweight and early-stage framework
multiple cross-cutting concerns, such as connec- for Internet-of-things development via a prelim-
tivity, security and the lack of high-level abstrac- inary industrial survey. Section 4 describes our
tions to address both the large-scale and hetero- framework. Section 4 presents the case company
geneity [9]. The heterogeneousness of Internet- for which the framework was developed and
-of-things introduces additional complexity to would be evaluated. The discussion and conclu-
software layer development, in particularly com- sion are in Section 5.
SIoT Framework: Towards an Approach for Early Identification of Security Requirements . . . 79

2. Background and related work 2.2. Security requirement identification

in software development
2.1. Existing IoT frameworks
Security requirements have traditionally been
The framework that is more similar to our frame- considered to be non-functional or quality re-
work is work of Meridji et al. [11]. The frame- quirements [2, 13]. Like other non-functional re-
work is intended to help developers identifying, quirements, security requirements need to be de-
specifying and measuring security requirements. scribed in the way that they can be implemented
The design of the overall framework is based later. Carnegie Mellon University was among
on the use of the interdependency graphs (SIG) the first to propose a methodology (SQUARE)
and the CIA triad, i.e., confidentiality integrity, to help organizations build security into the
availability, confidentiality. Whilst the proposed early stages of the production life cycle [14]. The
framework was systematically developed, it is, SQUARE approach includes nine steps that re-
however based on generic models and generic quire formal participation of requirements engi-
view of security. As a result, the framework takes neers and other stakeholders of an IT project.
a broad and generic view of system engineering. The team starts with outlining security goals,
In contrast, our framework is intended for a spe- threats identification and risk assessment based
cific type of system, i.e., IoT systems. Another on a full understanding of the relevant system.
aspect that differs between our framework and After that, the team decides on the best method
the framework proposed by Meridji et al. [11] is in for eliciting initial security requirements from
how security aspects are derived. The framework stakeholders, and to elicit an initial set of se-
by Meridji et al. [11] relies on three international curity requirements. In the final step, security
standards (ECSS, IEEE and ISO) for deriving requirements are inspected to ensure consistency
security requirements. Whereas our framework and accuracy. However, the methodology is at
emphasizes the need to focus on the architec- a high level of abstraction and is not specific to
ture design in order to derive relevant security a particular domain.
concerns for the specific system. Our motivation Several researchers have focused on tools and
for going with this approach is that the archi- methods for identification of security require-
tecture may differ from system to system, and ments, for instance, misuse cases [15], goal and
how a system is designed is crucial for under- anti-goal analysis [16], and patterns of security
standing how best to strengthen the security goals [17]. These approaches are proposed regard-
of the overall system. Because our framework less of the context of software development and
focuses more on the architecture of IoT systems, operation. Security concerns should be considered
it allows for more flexibility in terms of adopt- not only in the early stage of product development,
ability and adaptability to various IoT systems. but also as a continuous integral element of prod-
Ammar et el. [12] report on a survey of exist- uct development. Despite the benefits that Agile
ing IoT platforms that offer cloud-based services software development promises, there are security
such as AWS IoT. In the report they make an challenges faced within the paradigm that can man-
assessment of eight platforms focusing on the ifest into vulnerable software products [18]. In turn,
features offered by the platforms for developing this can significantly impact the longevity of the
IoT applications, including hardware and secu- software product on the market. There are studies
rity features. Our framework takes a software that adopt and adapt agile approaches in order to
engineering and process approach for develop- ensure that security initiatives are addressed, e.g.,
ing IoT applications. The overarching aim is to Beznosov’s work [19] and Ghani’s work [20]. How-
provide developers with an approach that can ever, it is also critical to have a framework that is
help them with identifying security concerns of specific to Internet-of-things contexts that not only
their specific IoT applications, irrespective of the helps address security concerns but also can be
platform that they use. adopted into agile software development processes.
80 Ronald Jabangwe, Anh Nguyen-Duc

2.3. Non-functional requirement vironments for Internet-of-things applications.

modelling Internet-of-things applications, which employs
web or mobile interfaces, provide functionalities
Modelling and documentation techniques that to store, process and analyze a vast amount of
can also be used when implementing approaches time series-based machine data. There exist vari-
for collecting, categorizing and prioritizing secu- ous architectural views on Internet-of-things sys-
rity requirements are attack trees, abuse cases, tems depending on research goals. Based on exist-
abuser stories, misuse cases and fault trees [21]. ing classifications [22, 24], we adopted a 4-layer
An attack tree is a tree-like representation of view on Internet-of-things systems with the pur-
the different ways that an identified asset can pose of differentiating security concerns and res-
be attacked based on attack goals. Abuse cases olution techniques among layers. The layers are
are descriptions of how a user of a system or Application tier, Network tier, Sensor tier, and
the system can be attacked or abused. Abuser Data processing tier, which will be described in
stories help capture and describe likely goals of the SIoT framework (Section 4).
an attacker. Unlike user stories that are written Internet-of-things development is challenging
from the perspective of a user of a system, abuser due to the multiple cross-cutting concerns, such
stories are written from the perspective of an at- as connectivity, security and the lack of high-level
tacker. Misuse cases are based on use cases, but abstractions to address both the large-scale and
they describe, using, for example, UML use case heterogeneity [9]. Patel et al. proposed a develop-
diagrams, and how malicious activities can be ment framework that separates Internet-of-things
carried out on the system. A fault tree is a deduc- into four concerns: architecture, domain, plat-
tion approach for analyzing system failures and form and deployment concerns [9]. However, the
security concerns using graphical Boolean logic. authors do not explicitly explore the elicitation
These approaches can also be used to support and implementation of security concerns.
the SQUARE method or any similar approaches.
Nevertheless, modelling of security requirements 2.5. Identification and modelling security
is out of the scope of this paper. We only fo- requirements in IoT development
cus on providing a framework to help with the
process of identifying security requirements in There are other research articles that address se-
Internet-of-things applications. curity requirements for IoT applications [25–29].
Babar et al. proposed a framework that separates
2.4. IoT product development security concerns for software and hardware parts
of embedded systems [25]. Although the need for
From a technological perspective, the implemen- built-in security framework is emphasized, the
tation of Internet-of-things typically requires model was not validated. Jacobsson et al. proposed
the combination of hardware, software and mid- a risk analysis for smart home systems based on
dleware components collaborating with each architectural views [26]. Gan et al. suggested sev-
other [22]. Hardware used for Internet-of-things eral security requirements for Internet-of-things
include sensors, actuators, and processors that in their analysis [27]. Ahmad et al. proposed
can be added to existing core hardware com- a model to capture security and privacy properties
ponents, and integrated to manage and oper- in Internet-of-things [28]. They point out common
ate the functionality of connected things. Com- security challenges, but they are not categorized
munication protocols such as MQTT, AMQP, into system architectural dimensions. Kim et al.
XMPP, and Zigbee enable the communication discussed the security concerns according to sys-
between the sensor devices and the cloud [23]. tem tiers and system development phases [29]. The
A typical Internet-of-things product will have proposal is however subjective without validation.
a “cloud” part including an application plat- Apart from the industry evaluation, our
form that provides fundamental operating en- framework differs in that it adopts the well known
SIoT Framework: Towards an Approach for Early Identification of Security Requirements . . . 81

SQUARE methodology [14], and best practices our IoT survey, from which we can extract infor-
for security engineering (e.g., [5, 32]) and adapts mation about security requirements. It is possi-
them for Internet-of-things contexts ble that the other companies also have similar
concerns, but this is not explicitly mentioned
in the survey.
3. Industrial demand on a security Our previous work reveals some of the pro-
modelling framework totyping and development challenges of such
startups, i.e., insufficient testing, technical debt,
In order to motivate the need of a security mod- balancing agility and quality, etc. [33, 34]. Ta-
elling framework for industry, in this section, we ble 1 summarizes how security concerns are con-
provide preliminary results of a qualitative survey sidered and managed in the eleven Internet-of-
that we are currently performing on Internet-of- -things startups from our survey. In the table,
-things startups. Early results support the notion “foundation year” is the year the company was
as they suggest that startups need assistance with officially formed. Regardless of the startups’ ac-
a framework for identifying security concerns early tive time, a startup can be in an idealization,
in the software development process. The prelimi- a prototyping or in a production state [35]. Ag-
nary results are shown in Table 1. In the on-going ile approaches are clearly common across the
survey, we are surveying the state-of-practice of cases. Many companies report that they adopt
Internet-of-things application development, focus- certain ways of Agile in developing (part of) their
ing specifically on exploring Internet-of-things de- products. Some report waterfall and adhoc ap-
velopment practices among IT startups. We aim at proaches as their preferred approaches when deal-
collecting as many participants as possible. There ing with the production of the hardware parts.
is no limitation on the type of companies in our sur- In the right-most column in Table 1 we also
vey as we would like to have a variety of the sample. reveal as a part of the product quality assurance
The survey was designed in 2015 and is an on-going practices, how security concerns were considered
effort. Participants are being searched from three and managed.
channels (1) our professional network, (2) regional Table 1 reveals that 80% of our cases empha-
incubators and accelerator programs, (3) and size the importance of security for their business,
startup portal, i.e., Startup Norway and Crunch- regardless of the startup stage. Security goals
base. Participants who accept our invitation are are often established in both startups at proto-
also invited to participate in a one-hour interview. typing and production phases. Security is con-
We used semi-structured interviews to en- sidered a significant concern, and in some cases
able open-end answers from participants. Our as an essential value proposition in the compa-
interview process has four parts (1) background niesb́usiness models. The consideration occurs at
information about business and product, (2) pro- different levels, organizational, managerial and
totyping and production development practices technical levels, for instance:
and challenges (3) quality concerns and testing, Security is the main infrastructure of
and (4) final reflection. The full interview ques- Internet-of-things applications. As it is
tion list is shown in Appendix A. We found eleven everywhere and one cannot think of com-
Internet-of-things startups that are relevant to promising the everyday equipment they
the scope of this study. This is a subset from use (C03).
Table 1. Security goals

Goals Description
Confidentiality Ensure that data is not revealed to or accessed by unauthorized individuals [30, 31]
Availability Ensure that authorized users can access and use data on demand [30, 31]
Integrity Prevent unauthorized tampering of data when it is being processed, or in transit or when
at rest [30, 31]
82 Ronald Jabangwe, Anh Nguyen-Duc

Figure 1. The scope of SIoT framework

As shown in Figure 1, the SIoT frame- or production). We also recognize some startups
work consists of the following three main (40% of the total number of cases) that perceive
components: security as a dependent concern on open source
1. Security goals. community or third-party providers. All in all,
2. Internet-of-things abstract model ar- the preliminary observations of the 10 Internet-
chitecture. -of-things startups suggest a methodological need
3. Internet-of-things security concerns. of a systematic approach for considering security
Devices in Internet-of-things applications during Internet-of-things product development
communicate through Internet and share life cycle and practices.
their data over the network. So, there are Overall, we found only one case in which
huge chances of vulnerability (C05). the company was taking steps to implement
However, there is a limited action on imple- a methodological approach for security assurance.
menting security concerns. 30% of the surveyed The company representatives explained that they
companies did not implement any security-re- do it because of market demands in their domain.
lated features. 40% of the cases have their se- Hence it helps them gain a competitive advantage
curity dependent on external vendors or open over its competitors. The company was willing
source components. There are only three cases to participate in the evaluation of the framework
that implement security as a part of their com- because of their interest in methods for effectively
petitive strategy, as illustrated below: addressing security concerns. More details of the
Our data can be traced and exposed over company are presented in Section 5 of the paper.
the network in case of lack of proper se-
curity measures. Security features play
a key role in Internet-of-things applica- 4. The proposed conceptual SIoT
tions (C05). framework
The two pillars of simple access and secu-
rity must work in unison. The first pro- The SIoT (Security for Internet-of-things Ap-
vides a simple way to securely connect plications) framework adopts the well known
devices to the Wi-Fi network, while the SQUARE methodology [14], and best practices
second ensures only the IoT application for security engineering (e.g., [5, 32] and adapts
can traverse the Wi-Fi network from the them for Internet-of-things contexts. The frame-
IoT device to the server. This can help work also builds on existing work on Internet-of-
prevent malicious attacks (C07). -things applications [22, 24, 36–38].
There is a lack of clarity of a systematic
approach for mapping security goals to actual 4.1. Security goals
actions for addressing security concerns. For in-
stance, it is not clear how startups cooperate se- Maintaining data confidentiality, integrity, avail-
curity concerns into the product architecture, at ability are the primary goals for data security
different times of consideration (i.e., prototyping initiatives [39–41]. The three goals are also re-
SIoT Framework: Towards an Approach for Early Identification of Security Requirements . . . 83

Table 2. Internet-of-things application and Security consideration in startups

ID Found Startup Startup product Development Thoughts Actions

year stage method
C01 2009 Prototyping A underwater Adhoc Security was not Quality
camera considered at perceived at
this stage open source
module
C02 2013 Prototyping A tracking Agile Quality Outsourced:
device for consideration Quality testing
shipments i.e., robustness was done by
and security at subcontractors
software tier
C03 2011 Production A mobile muscle Agile After thought Outsourced:
trainer on security at Quality testing
software tier of the hardware
tier was
outsourced
C04 2015 Production connected smart Waterfall and Importance of Depending on
home solution Agile security at security of third
software and party modules
cloud tier
C05 2015 Production Home electricity Agile for IoTs Security Implementing
usage related concerns at security features
management development three at various tiers
system components:
circuits, mobile
apps and cloud
C06 2016 Prototyping A navigating Agile Security is the No
device for most prominent
visually feature
impaired
individuals
C07 2016 Prototyping A car remote Agile at start, Security as Implementing
controller Waterfall a main concern security features
afterward at various tiers
C08 2014 Production A predictive Agile Security is as Limited
analytic important as
platform for usability.
vehicles
C09 2012 Prototyping A body index Agile Security Experimenting
tracking concerns at at
methodological, methodological
organizational level
and technical
level
C10 2015 Prototyping A water farming Adhoc Security No
management concerns at
system organizational
level
C11 2013 Prototyping Glucose Adhoc Security No
monitoring concerns at
device organizational
and technical
level
84 Ronald Jabangwe, Anh Nguyen-Duc

ferred to as the CIA triad [40]. The definitions for can be through, for example, a local area
the security goals are in Table 2. Our proposal is network or a mobile cellular data network.
to break down security into the three goals and Hassanalieragh et al. refer to this layer as
then identifying security concerns that need to data transmission [36].
be addressed in order to realize each goal. This – Sensor tier [36–38]: This layer is responsible
approach will help with addressing security from for collecting data from an object of inter-
different but critical perspectives for protecting est through sensors. The data can come from
data for Internet-of-things applications. a human-being, environment, or any object of
There are other security attributes, such as interest. Basically, the function of this layer is
authorization, authentication, and non-repudia- to provide environment or situational aware-
tion that can be perceived as independent cate- ness. It is mainly achieved by sensors that
gories. However, in line with Bass et al. [41], we may or may not perform a preliminary data
also believe these attributes support the security pre-processing, which then transmit the data,
goals outlined in Table 2. For example, autho- through the network layer, to the application
rization is intended to ensure that access to data and eventually to the support layer. WSN
is based on user privileges. This can be traced to (Wireless Sensor Network) is one of the ba-
confidentiality. Authentication is about verifying sic techniques of this sensor tier. This layer
users to ensure confidentiality and integrity. Non can also be referred to as the data acquisition
repudiation can be traced to confidentiality and layer [36], perceptual layer [38], and sensation
integrity as it relates to ensuring that users do layer [37].
not deny accessing, editing or deleting data. – Data processing tier [36]: This layer consists
of the computational devices and storage de-
4.2. Internet-of-things abstract model vices, that provide heterogeneous data pro-
architecture cessing such as normalization, noise reduction,
data storage and other similar functions. This
Decomposing the architecture of Internet-of- tier is the bridge between Producer and Ser-
-things applications into distinct layers provides vice. Hassanalieragh et al. refer to this layer
an overview of the idiosyncrasies associated with as the data cloud processing layer [36].
the systems. This helps to better understand
how to tackle data security concerns of such 4.3. Identification of security concerns
complex systems. Based on existing classifica-
tion Internet-of-things architecture, for example
4.3.1. General Internet-of-things security
in [22, 24, 36–38], we have identified the follow-
considerations
ing abstract layers as being the foundation of an
Internet-of-things system: Techniques to compromise data security keep
– Application tier [36, 38] This layer pro- evolving just as fast as the countermeasures to
vides users access to the Internet-of-things address them do. Thus ensuring data confiden-
through, for example, a mobile device. The tiality, integrity and availability is challenging
control of the application and intelligent for Internet-of-things systems. The basic security
decision-making is performed through this needs that should be taken into consideration
tier. It provides the typical functions of the in each of the layers are listed in Tables 3–6.
whole system, including the APIs to con- The checklist provided in the tables, which in-
sumers, decision-making, task analysis, task cludes particular vulnerable areas for each tier,
schedule and so on. In this tier, a number of will help to ensure that security requirements
services are deployed and interact with each are formulated to address security from different
other. angles using the CIA triad. It also helps with
– Network tier [36–38] This layer is responsi- capturing well known issues that can compromise
ble for data transmission. The transmission data security, for example, eavesdropping and
SIoT Framework: Towards an Approach for Early Identification of Security Requirements . . . 85

unauthorized gathering of data, as well as caus- is a common security issue across networks. But
ing data availability issues through distributed because not all networks are based on the same
denial-of-service attacks [22, 42]. communication protocol, it is important to assess
each type of network that is used in the Internet-
4.3.2. Domain-specific Internet-of-things -of-things application for any additional relevant
security needs threats. For this reason, a context-specific secu-
rity modeling approach is needed. The applica-
The checklist listed in Tables 3–6 are measures tion tier involves integrated or individual specific
that should be taken into consideration to ensure application business, such as smart grid, intelli-
data security. However, it is important to note gent transportation, smart security, smart home,
that the checklist is not a comprehensive list. wearable devices, and smart city. There are cer-
This is because depending on the configuration tain security concerns that cannot be solved in
of the Internet-of-things the architecture tier, and other tiers of Internet-of-things, such as privacy
the types of security risks can differ across con- protection issue, which does not occur in sensor
texts. For example, distributed denial-of-service layer and network layer but can become a concern
Table 3. Security Concerns for the Application tier

Goals Checklist Description

Confidentiality Access control for authorized users (i.e., user authentication)
Authorized user roles types
Least privilege (least functionality) for each user role/type
Verification of authorized users
Third party data and service integration
Availability Access to the system on demand by authorized user
Access to data on demand by authorized users
Data input validation
Integrity Verification of data source
Audit trail of user access into the system
Audit trail of user access to data
Audit trail of changes to data
Principle of separation of duties
Attribution of user access to application

Table 4. Security Concerns for the Network tier

Goals Checklist Description

Confidentiality/ Access control for authorized users (i.e., user authentication)
Integrity Authorized user roles/types
Least privilege (least functionality) for each user role/type
Verification of authorized users
Third party data and service integration
Availability Prevent distributed denial of service attack
Maintain connectivity
Detection and prevention of common network attacks (e.g., denial
of service)
Integrity Verification of data source
Audit trail of user access into the system
Audit trail of user access to data
Audit trail of changes to data
Principle of separation of duties
Attribution of user access to application
86 Ronald Jabangwe, Anh Nguyen-Duc

Table 5. Security Concerns for the Sensor tier

Goals Checklist Description

Confidentiality Data anonymization
Encryption algorithm and protocol when data is in transit from
sensors
Access control (user and device authentication)
Encryption key management
Node and device authentication RFID protocol security
Availability Access to data on demand by authorized users and devices
Detection and prevention of common sensor attacks (e.g., denial
of service)
Audit of data collected
Audit of data sources

Table 6. Security Concerns for the Data tier

Goals Checklist Description

Confidentiality Encryption method when data is in transit from sensors
Access control (user and device authentication)
Encryption key management
Availability Access to data on demand by authorized users and devices Malware
and virus detection
Data recovery mechanism (in case of disaster or failure)
Mitigation strategy for disaster and data recovery
Integrity Verification of data source
Audit trail of user access to data
Audit trail of changes to data

in certain contexts of the application layer. More- 4.3.3. Assessment of security concerns
over, different applications might have a different
priority on security requirements. For example, Identifying and assessing security threats can be
data privacy would be of great importance for performed by following a threat modeling ap-
Transportation and Healthcare sector, but, on proach [32]. We propose following the approach
the other hand, data authenticity may be more shown in Figure 2, which adopts well known
important for a Smart city. threat modeling techniques in security engineer-
In addition, in regulated domains, there are ing [5] that are used as a basis for deriving secu-
security requirements that need to be imple- rity requirements [4, 32].
mented for data protection. A good example is The approach shown in Figure 2 considers the
medical device software, which needs to comply context of the system, the likelihood of threats
with specific data protection guidelines. In the occurring and the impact that they have on the
United States of America, for example, medi- system. This is essential for an effective threat
cal device software needs to implement security modeling approach. The decomposition of the
measures outlined in the Security Rule that is in Internet-of-things application in Section 4.3.2
the Health Insurance Portability and Account- can be used as Step 1 in Figure 3. Step 2 is
ability Act (HIPAA) [43]. Therefore, it is also a critical step because in order to identify rele-
essential to consider the domain in which the vant security concerns it is important to under-
Internet-of-things application will be used and stand the complexities and mechanisms used to
understand the unique data security demands collect, transmit and store data. Table 7 shows
and regulations. information that should be defined during Step 2
SIoT Framework: Towards an Approach for Early Identification of Security Requirements . . . 87

Figure 2. Threat modelling for Internet-of-things application

will then be done in Step 4. The threats that

are found to be relevant can also be assessed
on their likelihood of occurrence and sever-
ity or extent of negative impact on data se-
curity. The assessment can be used for priori-
tization during the implementation of security
requirements.

5. Evaluation of the SIoT framework

5.1. The company context

To evaluate the SIoT framework, we apply it

in a company that we will refer to as ABC to
Figure 3. The evaluation of the SIoT Framework at
preserve its anonymity. ABC is a spin-off startup
ABC company
from an international enterprise that provides
in order to characterize each tier and describe real-time industrial IT integration, automation
contextual factors that are unique to a particular and manufacturing solutions. ABC has approx-
Internet-of-things application. The aim is to help imately 20 employees, developing a system for
identify the contextual setting of product devel- estimating glucose (blood sugar) based on the
opment. Data flow diagrams can also help model combination of several non-invasive measurement
and understand how data flows through each tier, principles. The company adopts several engineer-
which is useful information for understanding ing methodologies:
data security concerns in the Internet-of-things – Process-driven development: the company
application. was approved according to ISO 13485 (quality
The characterization done in Step 2 should management system for the development and
then be used as input in Step 3, which in- manufacturing of medical devices). Product
volves activities of identifying threats within development involves a significant amount
each tier. Assessment of the relevance to the of documentation for internal use and ex-
Internet-of-things application being analyzed ternal communication. The company adopts
88 Ronald Jabangwe, Anh Nguyen-Duc

Table 7. Security Concerns for the Data tier

Goals Checklist Description

Application Tier Types/roles of authorized users
Number of authorized users
Criticality of data that can be accessed (e.g., private and
sensitive data)
Devices used (e.g., hand-held mobile devices and laptops)
Sensor tier Number of authorized users to connect to sensors
Number of authorized devices to connect to sensors
Criticality of data that can collected (e.g., private and sensitive
data)
Data transmission method from the sensor layer to the appli-
cation layer (wireless personal networks [44], e.g., Bluetooth
and Zigbee [45]
Network tier Data transmission method from the application layer to the
data processing layer, e.g., mobile cellular network, wireless
local area networks [44]
Data transmission method from the data processing layer to
the application layer, e.g., mobile cellular network, Wireless
Fidelity (i.e., WiFi).
Communication protocols
Data processing tier Use of local device storage system
Cloud storage model (e.g., the use of either private, public,
community or hybrid cloud [46]

a tailored version of Agile with long-term to evaluate the SIoT framework. The focus group
iterations. A lot of physical tests are per- aimed at evaluating the SIoT framework on
formed on hardware components, e.g., strap its usefulness in practice, and to assess if SIoT
test, temperature test and load test. Auto- can help identify any additional security require-
mated testing and continuous integration are ments apart from those that they already knew
done for software components. and had documented. During the evaluation, the
– Quality-driven development: the developed focus group used the security requirements for
product is classified as a Class IIa Medical the current glucose estimator prototype. Some
Device product, which highlights the criti- of the security concerns that the company was
cality of several quality attributes, such as keen on addressing are data confidentiality and
performance, safety and most importantly, integrity.
security. The glucose estimator device will be body
– Software platform development: product de- mounted in the form of a wearable device that
velopment involves the implementation of an communicates with a mobile app for display-
embedded platform using C++/ RTOS, Java, ing and monitoring data. The system is simi-
noSQL and secured REST-API. lar to the Internet-of-things health monitoring
ABC was used to evaluate the SIoT frame- system presented by Hassanalieragh et al. that
work as a follow-up research activity after the is also based on WBAN and cloud-based pro-
industrial survey (case C11 in the survey in Sec- cessing [36]. The prototyping development was
tion 3). Security has been recognized as a vital finished in the winter of 2017 and the product
quality attribute at ABC. The company also ex- is currently under European regulator evalua-
pressed the need for a framework for addressing tion. The development team includes five peo-
the security concerns of their product. ple with competences in electronic engineering,
With the permission of the CTO we formed software engineering and medical expertise. The
a focus group consisting of developers from ABC prototyping process started in Spring 2015. The
SIoT Framework: Towards an Approach for Early Identification of Security Requirements . . . 89

development approach is research-based with of the prototype. In total four engineers par-
long iteration. All R & D activities occurred ticipated in the focus group
in-house. – Planning and conducting the focus group:
we hold a 120-minute discussion with partici-
5.2. Focus group pants. Each session started with an overview
and the evaluation process of the objectives of the study and with a dis-
cussion on how participants should discuss
A focus group is a popular research method in and act during the session. The first topic
social science, that involves carefully planned dis- was to discuss the current security level of
cussions to obtain the perceptions of group mem- the prototype. A researcher, who acted as the
bers on a defined topic [47]. Typically, there are 3 moderator, went through the four checklists
to 10 participants in a focus group, that are facil- of security requirements. The second topic
itated by a moderator, who guides a structured was to discuss the usefulness and complete-
discussion on a specific topic. The approach has ness of our SIoT. Each participant would give
been used in requirements engineering to elicit evaluation scores for the completeness and
and to analyze requirements [48]. In our case, we usefulness of SIoT at the end of the activity.
aim at discovering the security concerns of the – Analysis: the discussion was noted and sum-
current prototypes by using the SIoT framework marized into points. Each point was mapped
as a proxy object. We followed the focus group to (1) requirements that are already imple-
meeting guidelines proposed by Edmunds [49], mented in the current prototype and (2) re-
specifically: quirements should be implemented in the
– Defining the research problem: the group aims next version of the prototype.
at evaluating the current security concerns SIoT helped the focus group identify security
for the prototype. requirements that they had missed when develop-
– Selecting participants: we include all stake- ing the prototype. The results of the focus group
holders who are involved in the development were summarized in Table 8.

Table 8. Security requirements in ABC: “had” vs “should have” lists

Goals Requirements Implemented Requirements to be implemented

Application Tier
Having: Confidentiality, Availabil- Access control for authorized users Authorized user roles/types
ity (i.e., user authentication) Least privilege (least functional-
Should have: Confidentiality Access to the system on demand ity) for each user role/type
by authorized user Verification of authorized users
Data input validation Third party data and service inte-
gration
Sensor Tier
Having: Confidentiality Encryption algorithm and proto- Node and device authentication
Should have: Confidentiality, col when data is in transit from RFID protocol security
Availability sensors Access to data on demand by au-
thorized users and devices
Network Tier
Having: Confidentiality Identity authentication N/A
Should have: Confidentiality,
Availability
Data processing tiers
Having: Confidentiality Access control (user and device Verification of data source
Should have: Integrity authentication)
90 Ronald Jabangwe, Anh Nguyen-Duc

5.3. Evaluation results the application of SIoT in iterative development

and lessons learned (Section 6.2) and opportunities for improvement
(Section 6.3).
Figure 3 presents the boxplot (mean, min, max
and outliners) of the evaluation scores from fo- 6.1. Comprehensive vs. domain specific
cus group participants. As mentioned previously, security consideration
each participant gave a score for the complete-
ness of the framework (if SioT covers all relevant Our SIoT framework looks at security concerns
aspects to them) and the usefulness of the frame- from the product architecture perspective. We
work (if SIoT helps them in identifying security emphasize the security concerns of the entire sys-
requirements). The scores range from one to five, tem, rather than just the security of a single piece
with five being the highest degree. Figure 3 shows of software or a single Internet-of-things layer.
that participants perceived SIoT positively and This incorporates the fact that Internet-of-things
very useful. They appreciate the framework in application includes multiple tiers of software,
facilitating the discussion on security concerns middleware and hardware. A multi-perspective
for the product as well as helping with identifying view has also been considered in existing mod-
security requirements for future releases. els [25, 27]. Our model has been revised and vali-
Nevertheless, the participants pointed out dated by practitioners. Nevertheless, the real-life
three main issues when using the framework: scenario of Internet-of-things applications could
– Requirements of multiple expertise: it is re- become an ecosystem, in which security is not only
marked that the framework goes beyond considered at a technical level, but also at organi-
a singular tier of Internet-of-things system, zational level and ecosystem level. Therefore, one
hence, the adoption of the framework needs might consider in future work, a comprehensive
to involve software developers, hardware en- framework that captures security concerns at both
gineers, business analysts, etc. to reflect the technical, organizational and ecosystem levels.
comprehensive set of requirements. The SIoT framework consists of three main
– Abstraction of some security concerns: for components (See Section 4). We propose that
instance, common attacking approaches or the first step in applying the framework should
detection of a virus are elements that locate be the “security goals”, which results in the char-
in a high abstract level. These elements are acterization of data security for the system. This
not directly transferred into implementable is necessary for performing actions within the
requirements. Further discussions would be other two components, i.e., “IoT abstract model”
required to identify specific security require- and “IoT security considerations”. These other
ments. two components can be performed in parallel,
– Domain-specific focus: the evaluation was and their output is a list of security needs that
done on a prototype from the healthcare are then translated into security requirements.
domain. In such an application domain with The security requirements can be documented,
a lot of regulations, there are specific demands for example, using natural language [50].
on adhering to security standards and laws. The consensus within the focus group during
While the framework is useful as a starting the evaluation in the industry was that SIoT is
point to help address critical security concerns, useful and helps address security from different
domain-specific concerns linked to regulations key angles of Internet-of-things systems. As the
and standards are not straightforward. focus group participants pointed out the frame-
work goes beyond a singular tier of Internet-of-
-things system, hence promoting the notion of
6. Discussions having a holistic view of security for the sys-
tem. Developing and marking secure Internet-of-
In this section, we discuss and summarize the -things systems requires that not only software
SIoT framework (Section 6.1), and also discuss engineers are security-aware but all stakeholders
SIoT Framework: Towards an Approach for Early Identification of Security Requirements . . . 91

within the company. There are hardware con- the most current and sophisticated security risks
cerns and market considerations. Therefore, in that are relevant to the Internet-of-things system.
order to get a comprehensive set of security re- This can be facilitated by adopting threat model-
quirements, we encourage that the adoption of ing within the development process, specifically
the SIoT framework should involve software and during the requirements and design phases [18].
hardware engineers, testers, business analysts, Furthermore, having a role within the process
architects, and any other personnel that is in- dedicated to overseeing software security related
volved directly or indirectly in the development aspects should also be considered, for example,
of the Internet-of-things system. Ghani et al. suggest adding a “security master”
Overall SIoT addresses data security from role in Extreme Programming (XP) [20].
multiple perspectives in order to ensure that es- Security risks and threats will keep evolving
sential security requirements are identified. This as mitigation strategies and new technologies
includes, taking into account the idiosyncrasies emerge. Therefore, it is crucial to keep monitor-
of the Internet-of-things application as well as ing and managing mechanisms that are intended
the regulatory requirements of the domain in to protect data. Therefore, a continuous approach
which it will be used. This provides a more of updating security requirements is paramount
comprehensive view of security concerns for the for ensuring that appropriate risks are taken into
Internet-of-things application. However, there account as the software evolves. This can be done
will be some overlap in terms of security require- by adopting an iterative continuous process for
ments in particular during the activities for the addressing security requirements as captured in
Internet-of-things security considerations. Thus, Figure 4. Security goals need to be identified at
the security requirements should be aggregated, the beginning of the project, i.e., aligning with
analysed, and duplicates should be removed. business strategy. The first iteration (Sprint 1) will
identify the architectural model at the abstract
6.2. Fitting SIoT level, following by the identification of general
into iterative development security concerns. Consequent iterations refine the
architectural model and re-evaluate the list of se-
The proposed SIoT framework can be used in an curity concerns. At some point in time (Sprint N),
iteration/ sprint plan to ensure security concerns the domain-specific security concerns are identi-
are addressed and captured by the security re- fied and reflected in the architectural model.
quirements [51]. The output from the framework
can then be used as a starting point to develop 6.3. Limitation of the framework
metaphors or user stories which then could be
added to the backlog. Schwaber provides a list of The framework provides a conceptual approach
questions to guide a retrospective meeting [51]. that can be applied in any company context.
We propose to add the following to the list in The security consideration (described in Table 1)
order to bring the topic of security into the meet- presents the need for such a framework. The
ings: (1) which security concerns have been ad- completeness and usefulness of the framework
dressed, (2) which security concerns might have is evaluated using quantitative forms. However,
been missed in the backlog, and (3) which secu- the evaluation of the framework is preliminary
rity concerns need to be added to the backlog. In and only bases on a focus group. We are aware
addition, an agile approach to continuous changes of the limitation and plan for future work with
and integration may introduce security vulnera- thorough validation of the model. Our main fu-
bilities, which results in the development of inse- ture plan is to continue evaluating the frame-
cure software [18]. Hence, we suggest adopting work more cases industry, particularly in various
an agile and continuous assessment of security domains. At the moment we mitigate this is-
requirements to ensure that they are appropriate sue by carefully ensuring that SIoT is based on
and in line with the best practices for addressing existing best practices for security engineering,
92 Ronald Jabangwe, Anh Nguyen-Duc

Figure 4. Continuously considering security concerns

e.g., [5, 14, 32] and research on Internet-of-things might introduce specific architectural elements.
security, e.g., [16, 22, 24–29, 36–38]. Hence, this SIoT framework may need to be
While SIoT was perceived positively with refined in the future.
regards to its usefulness, there was an issue Our case company suggested that the frame-
regarding its completeness. This was pointed work provides a good basis to help address critical
out by practitioners in the focus group meeting. security concerns for Internet-of-things applica-
This pertains to addressing security outlined for tions. However, security is a multi-faced concept;
regulatory environments, demanded by law or therefore users of the framework should not view
specified in technical standards such as those in the framework as a panacea to all security threats.
a certain domain like the medical device industry. In addition, security threats will keep evolving
This is a critical issue to note. Therefore, users as technology evolves. Therefore, there is a need
of the framework should also reflect on any other to update SIoT accordingly over time, as well
requirements demanded in their own regulated as to conduct further validation with practition-
environment. Possible future work is to provide ers and improving the framework based on feed-
a guideline for mapping the SIoT framework to spe- back. Furthermore, we suggest complementing
cific regulatory requirements in a specific domain. the framework by adopting supporting security
activities, e.g., continuous security considerations
(e.g., shown in Figure 4), penetration testing
7. Conclusions and keeping up-to-date with emerging security
threats from resources like OWASP foundation1 .
In this paper, we proposed a systematic engi- Designing secure systems requires understanding
neering approach for identifying security require- the complex interaction between different parts
ments in Internet-of-things systems. The gaps of architecture and the security threats for those
in requirements and system design were found parts. The SIoT framework, which takes a layered
in Internet-of-thing startups. Considering an ab- view of the architecture of Internet-of-things ap-
stract architecture of an Internet-of-things ap- plications, provides a foundation for promoting
plication, we are able to come up with a SIoT that thought process.
framework, that offers a systematic way to iden-
tify, maintain and to evaluate security aspects
in Internet-of-thing applications. The framework Acknowledgments
has been used in a Norwegian startup with initial
positive feedback. However, it is worth mention- We appreciate Prof. Tor Stalhane from NTNU
ing that Internet-of-things security issues are and Dr. Indira Nurdiani (University of South-
application specific, so the approach needs to be ern Denmark) for their constructive review and
adapted in a specific application domain, which feedback on the SIoT framework.

1
The OWASP foundation can be found at this link: www.owasp.org
SIoT Framework: Towards an Approach for Early Identification of Security Requirements . . . 93

References [13] P. Devanbu and S. Stubblebine, “Software

engineering for security: A roadmap,” in ICSE
[1] S. Lucero, “IoT platforms: Enabling the Internet ’00: Proceedings of the Conference on The
of Things,” IHS Technology, Whitepaper, 2016. Future of Software Engineering, 2000. [Online].
[Online]. https://www.esparkinfo.com/wp- https://www.researchgate.net/publication/239
content/uploads/2018/11/enabling-IOT.pdf 3383_Software_Engineering_for_Security_a
[2] L. Chung, B.A. Nixon, E. Yu, and J. Mylopou- _Roadmap
los, Non-Functional Requirements in Software [14] N. Mead, “Security quality requirements engi-
Engineering, International Series in Software neering (SQUARE),” Software Engineering In-
Engineering. Springer, 2000. [Online]. https: stitute, Tech. Rep., 2011.
//www.springer.com/gp/book/9780792386667 [15] G. Sindre and A.L. Opdahl, “Eliciting security
[3] A. Olmsted, “Secure software development requirements with misuse cases,” Requirements
through non-functional requirements modeling,” Engineering, Vol. 10, No. 1, 2005, pp. 34–44.
in International Conference on Information So- [16] A. van Lamsweerde, “Elaborating security re-
ciety (i-Society), 2016, pp. 22–27. quirements by construction of intentional anti-
[4] S. Myagmar, A.J. Lee, and W. Yurcik, “Threat -models,” in Proceedings. 26th International
modeling as a basis for security requirements,” Conference on Software Engineering, 2004,
in Proceedings of the IEEE Symposium on Re- pp. 148–157.
quirements Engineering for Information Security, [17] Y. Yu, H. Kaiya, H. Washizaki, Y. Xiong, Z. Hu,
2005. and N. Yoshioka, “Enforcing a security pattern
[5] F. Swiderski and W. Snyder, Threat Modeling. in stakeholder goal models,” in Proceedings of
Microsoft Press, 2004. the 4th ACM workshop on Quality of protection,
[6] A.N. Duc, R. Jabangwe, P. Paul, and P. Abra- 2008, pp. 9–14.
hamsson, “Security challenges in IoT develop- [18] S.H. Adelyar and A. Norta, “Towards a se-
ment: A software engineering perspective,” in cure agile software development process,” in
Proceedings of the XP2017 Scientific Workshops, 10th International Conference on the Quality
XP ’17. ACM, 2017, pp. 11:1–11:5. of Information and Communications Technology
[7] A.S. Sani, D. Yuan, J. Jin, L. Gao, S. Yu, and (QUATIC), 2016, pp. 101–106.
Z.Y. Dong, “Cyber security framework for in- [19] K. Beznosov, “eXtreme security engineering: On
ternet of things-based energy internet,” Future employing XP practices to achieve “good enough
Generation Computer Systems, Vol. 93, No. 4, security” without defining it,” in First ACM
2019, pp. 849–859. Workshop on Business Driven Security Engineer-
[8] I. Jacobson, I. Spence, and P.W. Ng, “Is there ing (BizSec), 2005.
a single method for the internet of things?” [20] I. Ghani and N.I.A. Firdaus, “Role-based ex-
Queue, Vol. 60, No. 11, 2017. treme programming (XP) for secure software
[9] P. Patel and D. Cassou, “Enabling high-level ap- development,” in Special Issue – Agile Sympo-
plication development for the Internet of Things,” sium, 2013.
Journal of Systems and Software, Vol. 103, 2015, [21] M.R.R. Ramesh and A. Tadepalligudem, “A sur-
pp. 62–84. vey on security requirement elicitation meth-
[10] B. Morin, N. Harrand, and F. Fleurey, “Model- ods: classification, merits and demerits,” Interna-
-based software engineering to tame the IoT tional Journal of Applied Engineering Research,
jungle,” IEEE Software, Vol. 34, No. 1, 2017, 2016.
pp. 30–36. [22] Q. Jing, A.V. Vasilakos, J. Wan, J. Lu, and
[11] K. Meridji, K.T. Al-Sarayreh, A. Abran, D. Qiu, “Security of the Internet of Things: Per-
and S. Trudel, “System security requirements: spectives and challenges,” Wireless Networks,
A framework for early identification, specifica- 2014.
tion and measurement of related software re- [23] F. Wortmann and K. Fluchter, “Internet of
quirements,” Computer Standards and Inter- Things,” Business and Information Systems En-
faces, Vol. 66, 2019, p. 103346. gineering, Vol. 57, No. 3, 2015, pp. 221–224.
[12] M. Ammar, G. Russello, and B. Crispo, “Internet [24] H.J. La and S.D. Kim, “A service-based ap-
of things: A survey on the security of IoT proach to designing cyber physical systems,”
frameworks,” Journal of Information Security in IEEE/ACIS 9th International Conference
and Applications, Vol. 38, 2018, pp. 8–27. on Computer and Information Science, 2010,
[Online]. http://www.sciencedirect.com/science/ pp. 895–900.
article/pii/S2214212617302934
94 Ronald Jabangwe, Anh Nguyen-Duc

[25] S. Babar, A. Stango, N. Prasad, J. Sen, and ference on Software Engineering and Advanced
R. Prasad, “Proposed embedded security frame- Applications (SEAA), 2016, pp. 120–127.
work for internet of things (IoT),” in 2nd Interna- [36] M. Hassanalieragh, A. Page, T. Soyata,
tional Conference on Wireless Communication, G. Sharma, M. Aktas, G. Mateos, B. Kantarci,
Vehicular Technology, Information Theory and and S. Andreescu, “Health monitoring and man-
Aerospace Electronic Systems Technology (Wire- agement using Internet-of-Things (IoT) sensing
less VITAE), 2011, pp. 1–5. with cloud-based processing: Opportunities and
[26] A. Jacobsson, M. Boldt, and B. Carlsson, “A risk challenges,” in IEEE International Conference
analysis of a smart home automation system,” on Services Computing, 2015, pp. 285–292.
Future Generation Computer Systems, Vol. 56, [37] X. Sun and C. Wang, “The research of security
2016, pp. 719–733. technology in the internet of things,” in Advances
[27] G. Gan, Z. Lu, and J. Jiang, “Internet of things in Computer Science, Intelligent System and
security analysis,” in International Conference Environment, Advances in Intelligent and Soft
on Internet Technology and Applications, 2011, Computing, D. Jin and S. Lin, Eds. Springer,
pp. 1–4. 2011, pp. 113–119.
[28] A.W. Atamli and A. Martin, “Threat-based se- [38] H. Suo, J. Wan, C. Zou, and J. Liu, “Security in
curity analysis for the internet of things,” in the internet of things: A review,” in International
International Workshop on Secure Internet of Conference on Computer Science and Electronics
Things, 2014, pp. 35–43. Engineering, Vol. 3, 2012, pp. 648–651.
[29] D.H. Kim, J.Y. Cho, S. Kim, and J. Lim, [39] National Institute of Standards and Technology,
A Study of Developing Security Requirements “Standards for security categorization of federal
for Internet of Things (IoT), 2015. [Online]. information and information systems,” U.S. De-
https://www.semanticscholar.org/paper/A- partment of Commerce, Tech. Rep. Federal Infor-
Study-of-Developing-Security-Requirements- mation Processing Standard (FIPS) 199, 2004.
for-of-Kim-Cho/ [40] F.Y. Sattarova and T.H. Kim, “IT security re-
[30] R.L. Kissel, Ed., Glossary of Key Informa- view: Privacy, protection, access control, assur-
tion Security Terms. National Institute of ance and system security,” International Jour-
Standards and Technology, 2013. [Online]. nal of Multimedia and Ubiquitous Engineering,
https://www.nist.gov/publications/glossary- Vol. 2, No. 2, 2007, pp. 17–31.
key-information-security-terms-1 [41] L. Bass, P. Clements, and R. Kazman, Software
[31] G. Stoneburner, “Underlying technical models architecture in practice. Addison-Wesley, 2003.
for information technology security,” National [42] D. Fischer, B. Markscheffel, S. Frosch, and
Institute of Standards and Technology, Tech. D. Buettner, “A survey of threats and security
Rep. 800-33, 2001. measures for data transmission over GSM/ UMTS
[32] A. Shostack, Threat Modeling: Designing for Se- networks,” in International Conference for Inter-
curity. Wiley, 2014. net Technology and Secured Transactions, 2012,
[33] A. Nguyen Duc, K. Khalid, T. Lønnestad, pp. 477–482.
S. Bajwa Shahid, X. Wang, and P. Abrahams- [43] M. Scholl, K. Stine, J. Hash, P. Bowen,
son, “How do startups develop internet-of-things L. Johnson, C. Smith, and D. Steinberg, “An
systems – A multiple exploratory case study,” introductory resource guide for implementing the
in IEEE/ACM International Conference on health insurance portability and accountability
Software and System Processes (ICSSP), 2019, act (HIPAA) security rule,” National Institute
pp. 74–83. of Standards and Technology, Tech. Rep. 800-66,
[34] A. Nguyen-Duc, X. Weng, and P. Abrahamsson, 2008. [Online]. https://csrc.nist.gov/publicatio
“A preliminary study of agility in business and ns/detail/sp/800-66/rev-1/final
production: Cases of early-stage hardware star- [44] K. Scarfone, D. Dicoi, M. Sexton, K. Scarfone,
tups,” in Proceedings of the 12th ACM/IEEE D. Dicoi, M. Sexton, C. Tibbs, and C.M. Gutier-
International Symposium on Empirical Software rez, “Guide to securing legacy IEEE 802.11 wire-
Engineering and Measurement, ESEM ’18. ACM, less networks recommendations of the national,”
2018, pp. 51:1–51:4. NIST, Tech. Rep. 800-48 Rev 1, 2008.
[35] A. Nguyen-Duc, S.M.A. Shah, and P. Ambra- [45] D. Gislason, Zigbee Wireless Networking.
hamsson, “Towards an early stage software star- Newnes, 2008.
tups evolution model,” in 42th Euromicro Con-
SIoT Framework: Towards an Approach for Early Identification of Security Requirements . . . 95

[46] P. Mell and T. Grance, “The NIST definition pp. 85–98. [Online]. http://www.sciencedirect.
of cloud computing,” National Institute of Stan- com/science/article/pii/S0169814103001318
dards and Technology, Tech. Rep. 800-145, 2011. [49] H. Edmunds, Focus Group Research Handbook.
[47] S. Caplan, “Using focus group methodology for McGraw-Hill, 2000.
ergonomic design,” Ergonomics, Vol. 33, No. 5, [50] P. Salini and S. Kanmani, “Survey and analysis on
1990, pp. 527–533. security requirements engineering,” Computers
[48] K. Garmer, J. Ylven, and M. Karlsson, “User and Electricale Engineering, Vol. 38, No. 6, 2012,
participation in requirements elicitation compar- pp. 1785–1797. [Online]. http://www.sciencedirec
ing focus group interviews and usability tests t.com/science/article/pii/S0045790612001644
for eliciting usability requirements for medical [51] M. Sliger, Agile project management with Scrum.
equipment: A case study,” International Journal Project Management Institute, 2011.
of Industrial Ergonomics, Vol. 33, No. 2, 2004,

Appendix A. Q2e. When the actual development started?

Q2f. How does the final product different
– Part 1: General information from prototypes?
Q1a. Describe your product Q2g. Please name three most important chal-
Q1b. Describe your company, i.e history, cur- lenges during product development
rent head count Q2h. How many significant pivots have you
Q1c. What are the key software development encountered?
methods, processes, environments and tools? – Part 3: Quality concerns and testing
– Part 2: Production development prac- Q3a. What are quality attributes important
tices for your products? Q3b. How do you manage
Q2a. How did you build the first prototype? your product quality? Q3c. How do you do
Q2b. What were the reasons behind the first testing? Q3d. When did you last refactor your
prototype? codebase? Q3e. How do you consider Security
Q2c. How did you make other prototypes? in your final product?
Q2d. What have you learnt from the proto- – Part 4 – final reflection
typing process? Q4. Any final interesting comment ?