Lifecycle-oriented IT stack
Zones are used to assign and understand responsibilities. Classes help to distinguish components with different capabilities of integrating IT security. Classes also help to define different procedures of managing security and to stipulate compensating measures. Understanding Data model and application provides an idea how the IT components and the IoT system are used and how security requirements propagate. The Taxonomy does a lot: It provides an overview about all work areas. For all these areas IT security measures are defined (refer to section “Detailing the areas“). The Taxonomy also supports the division of labor and the management of the supply chain since it eases the assignment of responsibilities.
Roles and a lifecycle-oriented IT stack (this chapter) goes even deeper. The “Taxonomy for IoT” already defines generic constituents used to provide customer-facing IT services. In other words, the whole IoT system is broken down into small areas (technical components and areas of “activity”). The Taxonomy also presents e.g. an IT stack (of elements residing in data centers) and a structure of elements (outside data centers in the “edge”). With the lifecycle-oriented IT stack, more levels of components are introduced which are integrated to build the IoT system.
Why is this additional “role model / IT stack” introduced for IoT? In case of office IT or enterprise IT,
- Most components are provided by big corporations of the IT industry. Distributions of open source software are also managed properly.
- IT companies (suppliers/vendors and operators/service providers) have quality standards in place.
- There is considerable control in the supply-chain (suppliers are usually known; direct contracts exist between the parties; parties are used to cooperate e.g. in troubleshooting).
None of the above can be assumed in case of IoT (specifically for the elements outside data centers in the “edge”). That’s why more detail about the building process or the technical construction is required even on a security management level. The following example demonstrate this. Design and implementation errors and related vulnerabilities are passed on to the next level of integration and building up the IoT system. E.g., a vulnerability in a firmware affects the hardware-based system. Faults in the operating system affect the applications running on top of it. In case of the “things” (including a Class 3 device like a Raspberry Pi computer), this can become very intricate: The use of a specific System-on-Chip (SoC) hardware, produced by a chip manufacturer, may require modifications of the OS kernel which then deviates from the general-purpose distribution if Linux. Later the SoC is integrated by a device manufacturer into a device were software is added and further software modifications are implemented. The device is sold and becomes part of a larger component used in an IoT system located somewhere. Now a vulnerability is found and fixed and delivered with a new general-purpose distribution of Linux. How can the vulnerability be fixed in the component? The lifecycle-oriented IT stack helps understanding how such vulnerabilities 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.
An example of a lifecycle-oriented IT stack is provided in Table 1. It is designed as a generic one. It does not focus on a specific part of the overall supply-chain since security issues occur and need to be treated everywhere. The IT stack is also not technology specific since all technologies can have insufficient security. – Note that the top of the stack is on the top of Table 1. This is indicated by the “process step” (level). The “IT stack” indicates parties or roles and not directly IT components: The parties or roles are contributing along the supply-chain that builds the “IT stack” and finally the IT service consumed by the user organization. The latter is also added as the endpoint but also because it must integrate the IT service into its business which also requires consideration of security. Application management is also part of the chain. This comprises modernization and adaptation of the top-of-stack software but also of the data model and determination how data are processed.
This stack (Table 1) can be used in two ways:
- Regarding IT security it should be read from bottom to top in the first place since upper layer inherit security features as well as vulnerabilities from layers beneath.
- Theoretically, security requirements should primarily be defined for the business application (residing on top of the IT stack). These security requirements are then detailed defining security requirements for the layers beneath. This is done in several steps downwards the IT stack. However, this approach does not really work in practice since siloed IT stacks with only one application on its top rarely exist anymore.
|Process step||Party (name)||Activity (details)|
|12||User organization||End-user requiring IT support to run business processes / activities|
|11||Application management (business process)||Maintains the software that supports business activities; in many cases identical with the “Application provider” (No. 8)|
|10||Top-of-stack application operator||Operates the whole IT stack and provides the IT/TC services for the user organization|
|9||Systems integrator (business process)||Configures and combines application software (for business activities) and infrastructure services|
|8||Application provider (business process)||Develops software (that will run on top of infrastructure services) that supports business activities|
|7||Systems orchestrator||Broker, reseller, and/or integrator of different IT or TC services; may add generic business application services|
|6||Systems operator (infrastructure)||Provides IT or TC services on an infrastructure level (no application software for specific business processes included)|
|5||Systems integrator (Infrastructure)||Configures components (products) and combines them building a classical IT system (like a network or a computing environment)|
|4||Component vendor||Delivers (sells) the component; often defines features and thereby takes over responsibility for some design and maintenance features|
|3||Component provider||Provides platform specific software (firmware) or customized multi-platform software as well as additional component or product specific software; combines this with No. 1 and possibly No. 2|
|2||Multi-platform software provider||Software that is designed to be used for several hardware platforms; operating systems (OS) or OS kernels are examples|
|1||Platform provider||Provides hardware (such as System-on-Chip, SoC, and computer motherboards) which executes software or specific software is developed or adapted to utilize the hardware; also provides hardware specific software such as UEFI and drivers|
Table 1: An example of the “lifecycle-oriented IT stack”
In today’s industrialized way of provisioning IT services, IT security is built from the bottom to the top and the IT stack should be read accordingly. Correspondence between all layers is expected to be achieved by a standardization of IT security: This means that lower layers are built with appropriate assumptions on security requirements of layers above. Note that this approach is common practice for functionality and functional requirements.
 Differences between x86 systems (used in office and business IT) and ARM architectures (often used for the “things” in IoT) are also responsible for specific challenges in the area of IoT.