In March 2022, a cyberattack disrupted the internet connection to 9,000 wind turbines with a capacity of 11 GW, meaning that they could no longer be controlled. This year, attacks shut down the largest gas pipeline in the USA and others in Europe. These are all typical cases of inadequately secured systems in the Internet of Things - and there are more and more IoT applications (Fig. 1). While the direct damage in the case of a hacked consumer product, such as a webcam, is usually still manageable, the situation is very different for professional applications: No user wants to risk machines in an industrial production process or supply facilities for energy and water assuming an unforeseen operating state (Fig. 2).

Although there are already numerous IoT applications in safety-critical areas, only a few manufacturers have taken the issue of the (cyber) security of their products onto their radar - as a rule, they rely on the fact that a product has been carefully developed. But what happens if it turns out that there are security gaps after all? For the user, IoT products are 'black boxes' whose code they do not know, so they cannot take any product-specific preventive measures. Instead, it is the manufacturer's duty to ensure that a potential vulnerability in their product does not cause any damage to the user.

What causes security risks?

Figure 1: Dynamic development: The Statista portal predicts that the number of connected devices in the IoT will more than double by 2030.

© (Source: Statistica)

Security vulnerabilities are embedded in the product during the development process. To do this, you need to know how device software is usually created: the program code is usually only created from scratch to a small extent - the application-specific part - otherwise software developers rely on third-party components such as operating systems, libraries, drivers, encryption algorithms, etc. This is the only way to make the development of networked products economically viable. This is the only way to make the development of networked products economically viable, but it carries the risk of importing vulnerabilities into your own product. Commercial and open source software is also referred to as third-party software. Such software modules and operating systems are particularly attractive targets for hackers due to their widespread use. Historically, they were usually selected according to purely functional criteria and without taking security aspects into account, as security was not a development goal for a long time. Unfortunately, it can often be observed that even today software with long-known vulnerabilities still finds its way into new applications.

But even if security aspects were taken into account during development, the issue is not over: even after successfully completing penetration tests, many security vulnerabilities only become known once the product has long been in use in the field - these can then be exploited. At the same time, attack methods on networked IoT products are also developing at a rapid pace. In order to fulfill its responsibility towards users and customers, a manufacturer should therefore establish a monitoring process over the entire product life cycle. If a potential vulnerability is discovered, the first step is to inform affected users immediately and recommend measures to mitigate the risk of damage. As soon as an update is available that closes the security gap, it must be made available.

PSIRT - Permanently securing products

Figure 2: A security gap in networked automation systems, e.g. in the software of driverless transport systems, can pose a risk to operation.

© chesky/stock.adobe.com

Specialist departments that take care of such a monitoring process are also known as Product Security Incident Response Teams, or PSIRTs for short. They are the manufacturer's product-related counterpart to the - long established - Computer Emergency Response Teams, or CERT for short, on the user side, which take care of the security of the company network and are only active on a product-related basis in individual cases. However, PSIRTs have not yet been established across the board, even at large and well-known companies, although the international standard IEC 62443 ("IT security for industrial automation systems") in Part 4-1 (Section 12.4.1) provides clear guidelines for maintaining cybersecurity in the field. It is also important to comply with the IT Security Act 2.0 for the protection of critical infrastructures (KRITIS), which came into force in May 2021.

However, most manufacturers are overwhelmed by these tasks: They have neither the relevant expert knowledge nor the necessary human resources to establish an internal PSIRT process. This is where companies can fall back on independent development service providers: As an external security team, embeX, for example, supports manufacturers of networked products in setting up suitable PSIRT processes as well as with a customized service package that covers the entire product life cycle (see box below).

The PSIRT process in practice

So how do you actually prepare to secure a product? In order to carry out a specific vulnerability analysis, the first step is to determine which (sub)components make up the source code of the device software. This is also referred to as the 'software bill of materials' (SBOM), comparable to the parts list for a hardware product. The expert then scrutinizes the individual components, using special information sources such as CVE-DB, CWE-DB, BSI, in which known vulnerabilities are recorded. Tracking down vulnerabilities requires a great deal of specialist knowledge and experience - the CVE database alone currently contains over 185,000 entries. In the next step, the vulnerabilities found are assessed for their relevance, i.e. whether and if so, which risks can occur in the case of the specific application. The assessment is carried out according to the Critical Vulnerability Scoring System (CVSS) on a scale of 1 to 10, with level 10 representing a highly critical vulnerability in relation to the given application.
The manufacturer is informed of the results and receives recommendations for further action. This can be, for example, increased monitoring of the product by the operator or a restriction that the product can only be used in conjunction with additional security modules. The most far-reaching step is to close the security gap by revising the source code. PSIRT service providers can also undertake this revision (service level 4).

In the case of new developments, the specialist service provider can also be called in to anchor the topic of security in the development process from the outset - starting with the selection of security-tested components and further development-accompanying checks of the SBOM for vulnerabilities before the market launch. This also includes considering the extent to which future security updates may affect the functionality of the product, for example through higher demands on computing power and storage capacity.

Keeping an eye on cybersecurity

Anyone who is concerned about the security of their IoT products can at least take comfort in one thing: they are 'in good company' with many large and well-known international companies that also have no or only a patchy approach to the topic. If this is perhaps still tolerable for manufacturers of consumer products with limited potential for damage, there can be no pardon for this in industrial applications. Developers and attackers are in a race over the product life cycle - so standing still is not an option. As the networking of products in the IoT and the associated risks are likely to increase further, the topic of cybersecurity should be given the necessary attention. The aim is to avoid consequential damage to customers, which could have a massive impact on your own image and future purchasing decisions. If you do not have the (human and technical) resources for an internal PSIRT team, you can also procure the relevant knowledge as an external service. To put it in a nutshell: not every company needs its own plant fire department, but it should still feel obliged to take all necessary measures to prevent fires.