Internet of Things Architecture

the attacker model

Avoid Over-The-Air device management; if necessary

secure properly

Table 8 : Security perspective (adopted from [Rozanski 2005], extended with IoT

specific aspects)

4.3.3.3 Privacy

There are usually different concepts conveyed with the term privacy, some
being more from the technical side and some more from the legal perspective,
without forgetting ethical aspects.

Desired Quality Ability of the system to ensure that the collection of

personally identifying information be minimized and that

collected data should be used locally wherever

possible.

IoT-A Requirements UNI.001, UNI.002, UNI.410, UNI.412, UNI.413,

UNI.424, UNI.501, UNI.606, UNI.611, UNI.623,

UNI.624

Applicability Relevant to all IoT systems.

Activities Capture the privacy requirements

Conduct risk analysis

Evaluate compliancy with existing privacy frameworks.

Tactics Use an Identity Management component that supports

Pseudonymization

Avoid transmitting identifiers in clear especially over

wireless connections

Minimize unauthorized access to implicit information

(e.g. deriving location information from service access

requests)

Validate against requirements

Consider the impact of security/performance tradeoffs

on privacy

Enable the user to control the privacy (and thus

security and trust) settings

Balance privacy vs. non-repudiation (accountability)

Table 9 : Privacy perspective (adopted from [Rozanski 2005], extended with IoT

specific aspects)

4.3.4 Availability and resilience

As we are dealing with distributed IoT systems, where a lot of things can go
wrong, the ability of the system to stay operational and to effectively handle
failures that could affect a system‘s availability is crucial.