200
classifying them according to the underlying mechanisms they apply to, the
elements they affect, and the overall criticality they present.
Risk analysis traditionally begins with a definition of the elements that have to
be protected. Then, an analysis of possible threats is conducted. How identified
threats may actually affect elements to be protected, leads to the definition of
risks. These risks have to be categorised, taking into account parameters such
as criticality or probability of occurrence.
Various risk-analysis methods have been promoted in the literature, such as the
French EBIOS [Ebios 2010] and OCTAVE [OCTAVE]. The methodology for
risk analysis that has been chosen in IoT-A, and that is used in this section, is
based on Microsoft STRIDE / DREAD [Microsoft 2003]. This choice has
two reasons: first, this methodology is designed for assessing risks in the field
of communications and information systems; second, it is mostly based on the
analysis of architecture models and communications flows (instead of, for
example, partly relying on experts interviews such as in EBIOS), which makes it
a good fit for the ARM. The reasons for this are twofold. First, IoT, by it very
name, encompasses information systems and communication. Second, no IoT-
A-implementations are available at the time of writing. Therefore, the analysis
has to centre on the Reference Architecture itself.
This section is organised as follows: first, a list of elements to be protected is
provided. Then, the threats that may affect these elements (risk sources) are
reviewed. The review follows the STRIDE classification. More details on
STRIDE are provided below. The identified risks are then summarised and each
risk is assessed in accordance with the DREAD methodology/metric.
This risk analysis is intended to be used as input for the derivation of
architectures from the IoT ARM and for also for guiding the evolution of such
architectures. By so doing one makes them more resilient against the most
critical risks.
5.2.9.1 Elements to protect
What elements need to be protected depends on the considered scenario.
However, the IoT ARM was derived from the synthesis of a wide range of use-
case areas, and identifying elements to be protected becomes rapidly very
broad and multi-faceted. Instead, we decided to focus on the least common
denominator of all use-case scenarios on which the IoT ARM is built. In other
words, this analysis only looks at general elements to be protected, and this
study is thus a good but non-exhaustive starting point for the study of a
particular scenario to which the IoT ARM is going to be applied. The scenarios
encompassed by the IoT ARM include:
Transportation and logistics; Smart home; Smart city;