Internet of Things – Architecture © - 100 -
Description of security options related to traffic originated from a node
attached to the gateway. (Authentication of source node, cryptographic
strength etc.);
Filtering of incoming traffic (i.e. traffic sent to one of the nodes attached
to the gateway or vice-versa) according to network policies, user-defined
policies, and destination-node preferences (Optional).
3.7.2.2 Application security - system safety and reliability
IoT systems include -without any doubt- a wide range of application scenarios:
from home-security to structure monitoring of bridges, buildings, and so on, and
from surveillance systems to health monitoring. Most of these scenarios must
be reliable: a single failure in the system can lead to tragic consequences. This
is why, besides from security and privacy mechanisms that guarantee
trustworthiness of the system as a whole, it becomes important to assure also
system safety.
System safety is application specific: for an electicity system safety includes
assuring that no harm is done in case of a short-circuit. For an elevator system
safety would include making sure that the elevator does not start moving when
the elevator doors are opened. Nonetheless, there is a common approach to
achieve fail-safe systems made of two phases. The first, called the hazard
identification phase, aims at detecting all possible risks that could possibly lead
to severe accidents. The second phase includes the system design according to
the fail-safe philosophy: systems are designed in a way that the far majority of
failures will simply result in a temporary or total loss of service, so to avoid
major damage/accidents. An example of a safe-fail system is the security belt
sensor in smart-cars: If the driver does not fasten it, the car does not start.
While we believe that the classical fail-safe approach to system design can
assure safety in IoT systems, with respect to hazards inside the system (e.g.
the security belt within the car, the short-circuit within the electricity system and
so on), we also believe that often, the safety of the system depends on issues
that originate outside the system. The following scenario gives a representative
example of outside-the-system hazards: a bulldozer aiming at bringing down a
tree damages (by chance) the foundations of a building nearby. Even though
the damage is not visibly spottable right away, at the first slight earthquake it
makes the building crumble down by thus costing human lives.
Clearly, in these cases, threat analysis plays an important role. Despite from
considering only system-insider hazards, the system designer should carefully
examine the ̳outside world‘ of the system in order to identify potential outside
hazards. Only after a meticulous analysis of all possible threats (both insiders
and outsiders) proceed with the system design following the fail-safe
philosophy.