Zones, Classes, and Data model
Managing IT security in a complex environment such as IoT systems requires a classification and organization schema. This paper introduces the Zero Outage Security Taxonomy for IoT. It reuses ideas and elements from the tested and proven ESARIS Security Taxonomy which was developed for a different architecture used for the provisioning of office and enterprise IT services. Both Taxonomies use the composition of information technology systems and of ITSM activities. They are not using IT security slang and can therefore be understood by all involved experts. – Nevertheless, IoT systems require additional concept which are newly introduced in this chapter.
Both Taxonomies cover elements which are delivered by different parties. But whereas the ESARIS Security Taxonomy is primarily made for IT services delivered by an IT Service Provider to user organizations in a one-to-many service model, IoT systems may consist of more or less independent subsystems or, more precisely, combine systems from different areas of responsibilities. Whereas an IT Service Provider mostly takes full responsibility for the IT service delivered to user organizations, possession and responsibility may be more complex in IoT environments.
The Zones concept comprises the identification of involved parties and the analysis of their roles. For IoT systems, the Zones concept shall be used together with Taxonomy for IoT. E.g., possession of and responsibility for data needs to be considered when analyzing a data flow through the elements depicted in the Taxonomy. Appropriate separation needs to be implemented relating to e.g. zones like the edge (with things and related networks), aggregation and pre-processing (operations platform, gateways), and business applications (applications and cloud). Zones may overlap. Major principles can be specified in the area Orchestration, Attainment and Validation (ORA) mentioned in section “Details of areas in other clusters (upper half)“.
It can also be useful or even necessary to define different security measures for different areas of responsibility (which can also be called Zones) – but not due to different capabilities for implementing them. Security measures (on the Orchestration Layer) should anyhow be defined in an implementation independent way. Defining different security measures for different Zones can be useful or necessary since technologies and risks are fundamentally different. An entertainment area and a traffic signaling system can, for example, show large differences here. But areas of responsibilities may also result in having defined different solutions (security measures) since different areas are treated differently achieving a similar level of IT security. Zones can also be considered to result in having multiple instances of Taxonomy areas, e.g. reflecting the existence of numerous factories with different purpose and construction. Contrary to this, multiple instances of equal or similar factories shall follow one standard.
Zones are used to assign and understand responsibilities. Since design and implementation errors and related vulnerabilities are passed on to the next level of integration and building up the IoT system, it is advantages to work with a lifecycle-oriented, technical view of the IoT system’s composition. We call this lifecycle-oriented IT stack. It helps understanding how faults are passed on in the supply-chain. It also helps understanding how security measures should be designed to avoid this progression of faults and to at least allow to fix them afterwards. More detail about the lifecycle-oriented IT stack is provided in section “Lifecycle-oriented IT stack“.
To summarize, the areas in the Zero Outage Security Taxonomy for IoT may be split into or assigned to different Zones when stipulating security measures in form of security standards for the areas. Zones is a new concept that is added for IoT. – In case of office IT or enterprise IT, areas in the Taxonomy are also assigned to parties which allows to understand and manage the supply chain including responsibilities for IT security. Due to the nature of this business, all areas and elements are “single purpose”, they simply built on each other contributing to delivering one well-defined customer-facing IT service. In the world of IoT, areas may cover different things and related elements may be “multi-purpose” serving different applications in a different way requiring meeting different requirements. Zones is a concept helping to manage these special characteristics of IoT systems.
Classes is also a new concept added for IoT. Like Zones, Classes split security specifications or areas of the taxonomy into several parts. But contrary to Zones, Classes consider the fact that different security measures must be defined and implemented due to different capabilities for implementing them. The “things” have, for example, different levels of functional capabilities requiring different security measures to be put in place. But risks may also be different. Updating software (patching) is a good example for different capabilities. Patching may not be possible for all types of devices. Architectural decisions like connectivity aspects also play a role and determine if specific security measures are necessary as detailed below.
Typical IoT devices (“things”) are Embedded Systems (see TTE in section “Details of IoT specific Areas“) which are
- IT systems,
- which are designed for a specific purpose and not freely programmable,
- with limitations with respect to computing power, size, performance, power consumption, costs or the like, and
- which are interacting with their environments.
In general, IoT devices (Things and Thick Endpoints, TTE) comprise three Classes:
- plain devices offering a minimal functionality
- they can, for instance, not be updated and therefore not be “managed” as often needed to remove vulnerabilities and therefore being desired for better IT security,
- such devices may, for instance, also not be able to perform complex cryptographic computations as required for secure protocols,
- typical examples are webcams, “smart” Bluetooth bulbs, light switches, smoke alarms, temperature sensors, RFID tags, dongles,
- Embedded Systems in a strict interpretation of the definition
- they do offer IT functionality that usually includes cryptographic functions, though in a limited manner,
- software of such devices can usually be updated though also this can be subject to restrictions,
- typical examples are smartcards, washing machines and refrigerators and TVs (if connected to the Internet), medical devices, airplane components, car multimedia, navigation systems, cheap Internet routers (consumer market),
- “thick” endpoint devices that are not typical for IoT and not really “Embedded Systems”
- provided with an update function, programmable to a large extent, hardware extensions can often be added e.g. using PC Card, USB and other interfaces,
- typical examples are mobile personal computers including notebooks and tablets that are programmable and which can be managed.
A specific IoT system may require splitting these Classes into further ones. In the above organization with three classes, the ability of managing the devices was mentioned as an example. The inability to remediate vulnerabilities by patching software leads to a different security concept and requires the implementation of compensating measures.
IoT devices (Things and Thick Endpoints, TTE) may be located at different places in the overall architecture. This is specified in the area Architecture and Device Attestation (ADA). Two cases are distinguished which need to be considered together with the capabilities of implementing security measures in the devices described above:
- [A] Direct: The devices (TTE) are directly connected to a network and reachable from within this network (Edge and Field Area Networks, FAN, or Core Networks, CON). As a result, there is the possibility that the devices can be manipulated or abused if the adversary has access to the network. This must be considered when analyzing the necessity of implementing security measures in the devices (Classes 1, 2 and 3) and may lead to modifications of implementing security measures.
- [B] Indirect: The devices (TTE) are connected to a network (FAN, CON) via another subsystem only. I.e., they have a direct connection to an Operations platform (OPL) or to Nodes and Gateways (NGW) only and can only be accessed by using functionality provided by OPL or NGW. This functionality limits the access to and interaction with the device. As a result, adversarial access originating from the networks poses the devices to a lower risk compared to case A. Moreover, OPL and NGW can implement compensating security measure which cannot be implemented in the devices due to constraints addressed by the Classes 1, 2 and 3.
The Classes 1, 2 and 3 should be used in conjunction with the two connectivity aspects (A and B) as appropriate. Mixed modes of connectivity may exist.
To summarize, the areas in the Zero Outage Security Taxonomy for IoT may specify different security measures (in an area) for different Classes. The Classes must be specified in one security standard of one area so that other security standards or areas can refer to it when stipulating security measures. Classes is a new concept that is added for IoT. It can be necessary to enhance the indication of a Class with the connectivity type (direct or indirect).
Intermediate summary for Zones and Classes
The use of Zones but especially of Classes leads to areas and security standards split into sections specifying alternative security measures. Here is an example relating to Zones: The installed base of IoT devices (“things”) actually comprises devices that are in the public domain and others located in a corporate environment. The installation and maintenance of the two groups of devices and related network components if any is performed by two service providers. Assigning the devices to Zones makes this fact transparent to systems designers and operators. – Here is an example for Classes: The Classes are mainly important to distinguish possibilities for integrating security measures. Examples of devices belonging to Classes are given in section “Classes“. However, utilizing Classes has also advantages for the overall design. E.g., devices of one Class shall be connected to a gateway first since the latter can provide certain security service. Other devices (of another Class) may be directly connected to a core network. In this way, the security specification for different areas of the Taxonomy can easily refer to Classes instead of referring to specific products. This eases the specification and avoids frequent updates due to changes in the installed base of “things”.
Different security standards refer to each other in order to consider dependencies. One can look at the Zones and Classes as layers of the Zero Outage Security Taxonomy for IoT or, more precisely, of the security specifications organized by the Taxonomy.
Some dependencies and their effect to IT security can only be taken into consideration if it is known how the data are used. The technical aspect determines how the data are produced and processed by the IT components. But more important, a Data Model is needed that describes the structure of the data in a conceptional and logical way. In the first place, the technical and procedural layer (Taxonomy) and the Data Model are usually independent from each other. The Data Model can be modified later so that the “infrastructure” can be used for different businesses needs that are subject to development. The Data Model helps to understand dependencies, but it is also a means to identify the relevant ones and therefore to reduce complexity and orchestrate IT security as being intended by the Zero Outage Security Taxonomy for IoT.
The same holds for the IT application itself: Different applications can use the same “infrastructure”. An application translates the data into services for defined business purposes. Security requirements (especially those relating to compliance such as GDPR) originate from the business and its environment. Specific details of security requirements depend on protection needs and risk appetite. The latter are different for different businesses and vary from organization to organization. As a result, it can be necessary to consider an Application layer on top of the Data Model which in turn resides on top of the Taxonomy and its security specifications. However, it’s worth noting that the Zero Outage Security Taxonomy for IoT and the security specifications behind it serve the main purpose of providing a common denominator and a framework that facilitates or even enables the management of IT security in Internet of Things systems that are characterized by a complex technical and procedural environment, heterogeneous approaches due to many vendors and other parties involved, and a multi-purpose or evolving (more agile) determination. As in standard office or business IT environments, there is a high division of labor and the supply chain is complex.
Intermediate summary for Data models
Here is an example for the Data model concept: Let’s assume that the IoT system serves more than one (let’s say two) applications or business processes (what is usually the case in reality). The technical infrastructure is the same. The “things” or endpoints are providing data that are aggregated and finally be processed by software residing in a data center on top of the IT stack. Security requirements for IT components can hardly be derived without knowing anything about the criticality of the data being processed. Moreover, data are retrieved, modified, aggregated, transformed and processed. From the Data model one can learn if and how security issues are inherited (“passed on”) from one type of data to the next in the data flow and if and how security requirements are inherited (“passed back”) from the end result to the original input values. Using the data model instead of analyzing the application or business process has multiple advantages. Data models are easier to understand and can exist on different level of abstraction including an “architectural” one with lower complexity. Especially such Data models can be used as a target of evaluation for different applications and business purposes. Data models may even exist in form of blueprints whereas application (software) may change rapidly or even may not really exist when the IT infrastructure is built.
 Classes may also be defined differently. The definition of Classes in this document can be considered as a starting point.
 It is not possible for any security standard to stipulate all details for any application. The purpose and advantages of this standard are described in section “Purpose and Advantages“. Standards always address the 80 or 90% providing room for people to also care for the remaining 20 or 10%.