SYS.4.4 General IoT Device

Description

Introduction

Devices with functions from the Internet of Things (IoT) area are, unlike classic end devices, networked devices or objects that have additional “smart” functions. IoT devices are generally connected wirelessly to data networks. Most devices can access information on the Internet and can be reached through it. This means they can have impacts on the information security of the entire information domain.

IoT devices such as smartwatches or other wearables can enter institutions by being worn on the body by employees or visitors. In many institutions, IoT devices are also procured and operated, including fire, gas, and other alarms, coffee machines, or building control elements such as cameras and HVAC (Heating, Ventilation and Air Conditioning).

Generally, a distinction can be made between directly addressable IoT devices and IoT devices that require a central control unit. Directly addressable devices are typically connected to the LAN with their own IP address or have their own direct network connection, e.g., via cellular, and can act autonomously or be managed by a central control unit. In addition, there are IoT devices that communicate exclusively directly with control units, e.g., via wireless networks such as Bluetooth or ZigBee, and are therefore not directly connected to existing data networks.

Objective

The objective of this building block is to secure IoT devices so that neither the information security of the institution itself nor that of external parties is impaired through them. Therefore, both unauthorized data exfiltration and manipulation of the devices should be prevented, especially with a view to attacks by third parties.

Scope and Modeling

The building block SYS.4.4 General IoT Device must be applied to every device with functionalities from the Internet of Things (IoT) area.

This building block deals generally with IoT devices and is intended to be applicable to a broad spectrum of different IoT devices. Dedicated security properties, such as those of operator and display systems or specific hardware and software architectures, are not covered in detail.

Depending on the characteristics of the IoT devices, the transitions to industrial control systems (ICS systems) or embedded systems are fluid. Requirements for devices used in production and manufacturing are found in the building blocks of the IND Industrial IT layer.

Embedded systems, on the other hand, are information-processing systems that are integrated into a larger system or product, perform control, regulation, and data processing tasks there, and are often not directly perceived by users. For these systems, the building block SYS.4.3 Embedded Systems must be implemented.

Requirements for the wireless links frequently used in connection with IoT devices can be found in the building blocks of the NET.2 Wireless Networks layer.

The IoT devices used in the information domain under consideration must be taken into account in identity and authorization management. For this purpose, the building block ORP.4 Identity and Authorization Management must be implemented.

Threat Landscape

Since IT-Grundschutz building blocks cannot address individual information domains, typical scenarios are used to represent the threat landscape. The following specific threats and vulnerabilities are of particular importance for the building block SYS.4.4 General IoT Device.

Espionage via IoT Devices

During the development of IoT devices, the aspect of information security is typically not considered or only considered as a secondary concern. This has in the past caused IoT devices to be repeatedly misused to collect information about users or the area of deployment. There have been recurring incidents involving networked or IP-based surveillance cameras:

• In 2021, surveillance cameras were hacked by re-registering the camera ID. This allowed control to be taken over.
• In 2022, video streams from baby monitors were redirected in an attack on other servers due to missing authentication. Due to the missing authentication, it was even possible to take over control.

At the end of September 2016, it became known that some models of surveillance cameras and room sensors are equipped with backdoors that enable espionage. This particularly affected surveillance cameras used in data centers and server rooms. The backdoors apparently enabled access to the image and video data of the cameras, and this data could be copied to servers on the Internet. In this way, for example, passwords of users or administrators could be compromised, or device configurations, infrastructure details, and other confidential information could become accessible to third parties. This facilitated further attacks by exploiting employee habits.

Use of UPnP

IoT devices integrated into LANs often independently establish a connection to the Internet by configuring routers in the network via UPnP (Universal Plug and Play) to create a port forwarding. The devices can then not only communicate into the local network but are also visible and reachable outside the LAN. If a vulnerability in the IoT device is then exploited by an attacker, the device could become part of a botnet. Furthermore, additional malware could be introduced into the information domain. This security gap can also be exploited for further abusive activities at a later time.

Takeover Into a Botnet

If IoT devices are not regularly patched, known vulnerabilities remain open and can be exploited for extensive attacks. One objective of an attack could be to integrate the IoT devices into a botnet. In this case, they could, for example, be misused to carry out DDoS attacks (Distributed Denial of Service) and restrict the availability of services.

Botnets consisting largely of IoT devices are frequently used for this purpose. The malware “Mirai”, which has existed since 2016, integrates webcams, cameras, digital video recorders, routers, and printers into a botnet, for example. These then independently scan the Internet for further devices to infect them with malware and add them to the botnet. There are also further variants of such malware such as “Mozi” or “BotenaGo”, which in 2019 and 2021 used a similar approach.

Requirements

The following are the specific requirements of the building block SYS.4.4 General IoT Device. The Information Security Officer (ISO) is responsible for ensuring that all requirements are met and verified in accordance with the established security concept. The ISO must always be involved in strategic decisions.

Additional roles are defined in the IT-Grundschutz Compendium. These should be filled insofar as this is sensible and appropriate.

Exactly one role should be Primarily responsible. Beyond that, there may be Additional responsibilities. If one of these additional roles is primarily responsible for fulfilling a requirement, that role is listed in square brackets after the heading of the requirement. The use of singular or plural says nothing about how many people should fill these roles.

Basic Requirements

The following requirements MUST be met with priority for this building block.

SYS.4.4.A1 Deployment Criteria for IoT Devices (B)

IoT devices MUST have update functions. The manufacturing companies MUST offer an update process. The devices MUST enable appropriate authentication. NO hardcoded or derivable access credentials MAY be contained in the devices.

SYS.4.4.A2 Authentication (B)

Appropriate authentication MUST be activated. IoT devices MUST be integrated into the institution’s identity and authorization management.

SYS.4.4.A3 DISCONTINUED (B)

This requirement has been discontinued.

SYS.4.4.A4 DISCONTINUED (B)

This requirement has been discontinued.

SYS.4.4.A5 Restriction of Network Access (B)

The network access of IoT devices MUST be restricted to the required minimum. This SHOULD be regularly checked. The following points SHOULD be observed:

• For traffic controls at network transitions, e.g., through rules on firewalls and Access Control Lists (ACLs) on routers, ONLY previously defined incoming and outgoing connections MAY be permitted.
• The routings on IoT devices and sensors, in particular the suppression of default routes, SHOULD be configured restrictively.
• The IoT devices and sensors SHOULD be operated in their own network segment that is only permitted to communicate with the management network segment.
• Virtual Private Networks (VPNs) between the networks with IoT devices and sensor networks and the management networks SHOULD be configured restrictively.
• The UPnP function MUST be deactivated on all routers.

Standard Requirements

Together with the basic requirements, the following requirements correspond to the state of the art for this building block. They SHOULD generally be met.

SYS.4.4.A6 Inclusion of IoT Devices in the Institution’s Security Policy (S)

The requirements for IoT devices SHOULD be specified in the institution’s general security policy. The policy SHOULD be known to all persons who procure and operate IoT devices and serve as the basis for their work. The implementation of the content required in the policy SHOULD be regularly checked and the results meaningfully documented.

SYS.4.4.A7 Planning the Deployment of IoT Devices (S)

To ensure the secure operation of IoT devices, it SHOULD be planned in advance where and how they are to be deployed. The planning SHOULD not only address aspects classically associated with the term information security, but also normal operational aspects that give rise to security requirements. All decisions made during the planning phase SHOULD be appropriately documented.

SYS.4.4.A8 Procurement Criteria for IoT Devices (S) [Procurement Office]

The ISO SHOULD be involved in all procurement of IoT devices. Before IoT devices are procured, it SHOULD be defined what security requirements these must meet. When procuring IoT devices, aspects of material security as well as requirements for the security properties of software SHOULD be sufficiently taken into account. A requirements list SHOULD be created against which the products available on the market are evaluated.

SYS.4.4.A9 Regulation of the Use of IoT Devices (S)

For each IoT device, a person responsible for its operation SHOULD be named. Those responsible SHOULD be sufficiently informed about the handling of the IoT device.

SYS.4.4.A10 Secure Installation and Configuration of IoT Devices (S)

It SHOULD be defined under what conditions IoT devices are to be installed and configured. IoT devices SHOULD only be installed and configured by authorized persons (those responsible for IoT devices, administrators, or contractually bound service providers) following a defined process. All installation and configuration steps SHOULD be documented in such a way that the installation and configuration can be comprehended and repeated by qualified third parties based on the documentation.

The default settings of IoT devices SHOULD be reviewed and if necessary adjusted in accordance with the security policy requirements. Where possible, IoT devices SHOULD only be connected to data networks after installation and configuration are complete.

SYS.4.4.A11 Use of Encrypted Data Transmission (S)

IoT devices SHOULD only transmit data in encrypted form.

SYS.4.4.A12 DISCONTINUED (S)

This requirement has been discontinued.

SYS.4.4.A13 Deactivation and Uninstallation of Unneeded Components (S)

After installation, it SHOULD be checked which protocols, applications, and other tools are installed and activated on the IoT devices. Unneeded protocols, services, login credentials, and interfaces SHOULD be deactivated or completely uninstalled. The use of unneeded wireless interfaces SHOULD be prevented.

If this is not possible on the device itself, unneeded services SHOULD be restricted via the firewall. The decisions made SHOULD be documented in such a way that it can be understood which configuration was chosen for the IoT devices.

SYS.4.4.A14 DISCONTINUED (S)

This requirement has been discontinued.

SYS.4.4.A15 Restrictive Assignment of Rights (S)

Access permissions to IoT devices SHOULD be granted as restrictively as possible. If this is not possible via the IoT devices themselves, consideration SHOULD be given to regulating this at the network level.

SYS.4.4.A16 Elimination of Malware on IoT Devices (S)

IT Operations SHOULD regularly inform themselves whether the IoT devices in use could be infected with malware and how infections can be eliminated. Malware SHOULD be eliminated without delay. If the cause of the infection cannot be remedied or re-infection cannot be effectively prevented, the affected IoT devices SHOULD no longer be used.

SYS.4.4.A17 Monitoring Network Traffic of IoT Devices (S)

It SHOULD be monitored whether the IoT devices or sensor systems are only communicating with IT systems that are necessary for the operation of the IoT devices.

SYS.4.4.A18 Logging Security-Relevant Events in IoT Devices (S)

Security-relevant events SHOULD be automatically logged. If this is not possible by the IoT devices themselves, routers or logging mechanisms of other IT systems SHOULD be used for this purpose. The logs SHOULD be appropriately evaluated.

SYS.4.4.A19 Protection of Administration Interfaces (S)

Depending on whether IoT devices are administered locally, directly over the network, or via central network-based tools, appropriate security precautions SHOULD be taken. Access to the administration interfaces of IoT devices SHOULD be restricted as follows:

• Network-based administration interfaces SHOULD be restricted to authorized IT systems or network segments.
• Local administration interfaces on the IoT device or administration interfaces via local networks SHOULD preferably be used.

The methods used for administration SHOULD be defined in the security policy. IoT devices SHOULD be administered in accordance with the security policy.

SYS.4.4.A20 Regulated Decommissioning of IoT Devices (S)

There SHOULD be an overview of which data is stored where on IoT devices. A checklist SHOULD be created that can be worked through when decommissioning IoT devices. This checklist SHOULD include at a minimum aspects of backing up still-needed data and subsequently securely deleting all data.

Requirements for High Protection Needs

The following are exemplary proposals for requirements for this building block that go beyond the level of protection corresponding to the state of the art. The proposals SHOULD be considered when there is a higher need for protection. The concrete definition is made in the context of an individual risk analysis.

SYS.4.4.A21 Deployment Environment and Power Supply (H) [Facility Management]

It SHOULD be clarified whether IoT devices may be operated in the intended deployment environment (protection needs of other IT systems, data protection). IoT devices SHOULD be protected against theft, destruction, and manipulation in the deployment environment.

It SHOULD be clarified whether an IoT device has specific requirements for the physical deployment environment, such as humidity, temperature, or power supply. If required, supplementary measures SHOULD be implemented in the infrastructure.

If IoT devices are operated with batteries, the regular functional testing and replacement of batteries SHOULD be regulated.

IoT devices SHOULD be protected from dust and contamination in accordance with their intended type and location of use.

SYS.4.4.A22 System Monitoring (H)

IoT devices SHOULD be integrated into an appropriate system monitoring or monitoring concept. The system status and functionality of IoT devices SHOULD be continuously monitored. Error states and the exceeding of defined threshold values SHOULD be reported to the operating personnel. It SHOULD be examined whether the devices used meet the availability requirements. Alternatively, it SHOULD be examined whether further measures, such as setting up a cluster or procuring standby devices, are necessary.

SYS.4.4.A23 Auditing of IoT Devices (H)

All IoT devices in use SHOULD be regularly audited.

SYS.4.4.A24 Secure Configuration and Use of an Embedded Web Server (H)

Web servers integrated in IoT devices SHOULD be configured as restrictively as possible. The web server SHOULD NOT be operated under a privileged account where possible.

Additional Information

Good to Know

In the document “Security of Devices in the Internet of Things”, the BSI provides an overview of the elementary best practices for the secure operation of IoT cameras.

The Department of Homeland Security (DHS) has published strategic principles for the security of IoT devices in the document “Strategic Principles for Securing the Internet of Things (IoT)”.

The Open Web Application Security Project (OWASP) provides guidance on securing IoT devices on its website.

The European standard ETSI EN 303 645 “Cyber Security for Consumer Internet of Things: Baseline Requirements” serves as a recommendation for the secure development of IoT devices (Security by Design). This includes, among other things, secure authentication mechanisms, appropriate update management, and the securing of communication. It is also used, among other things, in the BSI’s IT security label in various product categories of IoT.