In IoT (Internet of Things) networks, millions of devices, sensors and other components are connected to each other, some of which were never designed for this purpose. Thomas Jakubiak, head of msg security advisors, describes what this means for the security of the underlying systems and how IoT networks can be configured to be resilient.

Mr. Jakubiak, what role does resilience play in the context of the IoT?

Thomas Jakubiak: Resilience describes the ability to adapt to uncontrollable changes. If they occur due to unforeseen events, for example, the entire system should still remain secure. If the IoT is understood as a network of a wide variety of endpoints that make contact with each other via the Internet and exchange data, resilience becomes highly relevant. After all, the architectures and components in use there today were not originally built for this type of operations. This means that networking can introduce problems that arise precisely via this networking and allow the chain of consequences of an intervention in this networking to be increased by an incredible degree. In terms of resilience, companies that are operating on the IoT need to find new ways of engaging with these risks.

What makes IoT networks so susceptible to cyber attacks?

Thomas Jakubiak: In a sense, we are dealing with a double insecurity: In addition to the lack of cyber security capability at the level of the individual components, there is also the lack of cyber security capability in the networked environment itself. What is lacking at the moment in these components is the capability of controlling cyber security, that is, being able to control the properties of these products with regulated standards and regulated measures.

Take thermostats, for example, which are deployed in an industrial context. In the past, a thermostat was simply a device that you could screw on somewhere to turn the temperature up or down. Now, these devices have the ability to act in a networked fashion so that they can be maintained remotely and can interact with each other. However, all of this is done without any form of control over, for example, who is operating these services or who is accessing this service. This is not something that is functionally envisaged in the installed software or network. This in turn means that in the event of attacks, but also in the event of malfunctions in the system, the system itself is not equipped with capabilities to deal with this incident in any way.

Why were these security aspects not considered in the development of these smart products?

Thomas Jakubiak: There is an old saying: The S in IoT stands for security. That is certainly an exaggeration, but it makes it clear where the priorities lay for a long time. The initial focus was on doing things in such a way that they worked. The premise was: 'Make sure that data can be exchanged' - and not: 'Make sure that data can be exchanged securely and that you can distinguish between authorized and unauthorized users'. This realization that security must be implemented as a property did not establish itself until later. Today, it is a general requirement that is also included in the new Cyber Resilience Act, but it was not uniformly available before and, above all, it was not binding.

Incidentally, we are seeing a similar shift in other areas, such as automotive production. This is because vehicles do not traditionally come from a world that thought in terms of software and therefore also thought in terms of security. If you now implement new software that also includes security aspects, you have to change the architecture and in some cases think about the product you are designing in a completely new way. In other words, the product does not begin with the causal engineering work, but with the consideration of how the software that operates and networks this product must be designed. It is imperative that these considerations include an assessment of the security risks, why someone would want to attack the system, where are the vulnerabilities in the system and how does the system react to them. This means that many of the processes involved in the development of such components today must be changed in order to successfully bring software into vehicles. And ultimately not as an add-on to what is already there, but to build the car around the software and thus create a completely new constellation within this product world that is software-driven.

Many of the digital services that are built on networked products today were not even foreseeable when they were produced? What does this mean for security in the IoT?

Thomas Jakubiak: For us, the concept of 'smart' implies that something can be connected to the Internet or that different endpoints can be connected to each other. It is not possible to predict with certainty what these endpoints are and what constellations may result. It took cyber attacks to demonstrate that this creates systems that are not at all transparent in terms of the depth of their networking and that, of course, the individual components that interact with each other are not transparent either.

This is a danger that is only now being addressed and which, by the way, does not only affect security aspects. Non-security-related malfunctions can also lead to such networks having to be restarted. And then you're confronted with the question: 'How can I restore the system in a complex, networked environment?' That requires an overview of what today's network looks like and what individual components are in the network. It also involves checking certain functional aspects every time you replace or add a new component to the network to make sure it's integrated securely. And that, of course, is a real challenge in today's world, where new components that can be networked together are available everywhere. Existing components also need to be constantly updated with the latest, cleaned-up software that addresses newly identified vulnerabilities. These software updates also pose security risks that must be considered at the design stage.

How do I get this kind of overview of the network?

Thomas Jakubiak: First of all, you need to look at the immediate sphere of influence. In the case of an automobile manufacturer, for example, this involves questions such as: 'What network-capable components are installed in the vehicle?' 'What networks do I establish when I network the vehicle with a back-end in order to call up certain services from this car or to be able to access and exchange information in a networked manner with other cars?' That would be the starting point for looking at what actually happens in the immediate operating environment. Then the next step is to look at the interfaces: 'Which external services do I need, for example, for navigation or infotainment functions? Where do I have interfaces to other networks or to other information that I obtain from outside?'

Is there a danger that complex IoT networks, such as Smart Cities, will become so dynamic and complex that at some point it will no longer be possible to keep track of them or control them?

Thomas Jakubiak: Ripple effects can already be observed in power grids today, which cause things that happen at one point in the network to have an impact at another point. So fundamentally this means, 'The things that I network can also influence each other.' And, of course, the number of our vulnerabilities grows exponentially with the complexity of the networking.

On the other hand, there is the possibility of regaining a certain level of security by segmenting networks - in other words, by deliberately not networking them. This, however, obviously goes far beyond the individual component and also includes the strategic aspect. This is also the reason why the EU's Cyber Resilience Act, in addition to ensuring that individual components can be updated as a guarantee of security, also aims to create awareness of the criticality of networking.

The so-called onion architecture can help to control the increasing complexity. Here, a single access point is set up in the top layers, which must be tightly safeguarded. All underlying systems and components respond to threats as their resources, computing time and memory allow. In this way, control is regained and, in the event of an emergency, it is possible to respond at the central node.

Has the perception or awareness of the relevance of security changed in recent years?

Thomas Jakubiak: Absolutely. We observe that - as with the German Data Protection Regulation (DSGVO) - stricter compliance requirements are leading to more and more manufacturers following these requirements. The market and customer requirements are clearly developing in the direction of actively including security aspects in product development in the sense of security by design. This is also in line with the current, more advanced EU requirements. These make clear specifications as to what future products must look like in this environment.

Is the current trend towards higher security standards in the IoT also a consequence of the security incidents in recent years?

Thomas Jakubiak: Cycles can always be observed in such developments: In the early days of new technology phases, for example, system security is seldom in the foreground because the initial focus is on the implementation process. But when, as a result of increasing networking, events occur that make security an imperative, the very adaptation that we observe today takes place - for example, in the form of security by design, defined, controlled product properties for components and an obligation to update for manufacturers and their software. We know this from the PC world, for example. So this also follows processes that we already know, but which we now have to transfer to an area in which this has not yet been used to the full extent.

Against the backdrop of increasing security requirements in the IoT - what role do overall social developments such as the Corona pandemic or the war in Ukraine play in terms of cybersecurity?

Thomas Jakubiak: The sense of threat has become stronger. It is developing from a diffuse feeling to an increasingly concrete entrepreneurial risk aspect. We have noticed this trend very clearly in discussions with decision-makers over the last 2-3 years. Whereas, for example, ISO 27001 used to be a question of what a company would spend its money on and to what extent it would like to have an ISMS, the majority of our customers now have an ISMS that has either been certified or is based on a known standard. In other words, many things are moving in a direction that makes things more secure. Of course, the CRITIS environments stand out in particular, where even short-term outages and cases of unavailability immediately bring about critical conditions.