Security is like the brakes of your car. It slows you down but it also enables you to go a lot faster.

complex security

The dark side of “connected products”

The trend of connected products is ubiquitous in most industry sectors. While connectivity enables a lot of innovative features, it also increases the potential for malicious attacks.
READ MORE

To attack a non-connected system, physical access is required. Attacking connected systems does not necessarily require physical access and, thus, potentially enables attackers to remotely compromise many devices at the same time [1] [2] [3].

Connected products are often not developed from scratch, but re-use legacy components – components that were never designed for secure use in a connected scenario. Examples for this include industrial control systems (ICS) that were connected to the internet [4], vehicles that are connected by aftermarket dongles [5], and infusion pumps that are connected to the hospital network [6].

The resulting security incidents can threaten company business models due to reputational damage, data privacy fines and compensation payments to end-customers as well as B2B customers. Furthermore, scalable attacks put social values at risk, which motivates legislators to take action in terms of cybersecurity legislation.

The dark side of “connected products”

complex security

The trend of connected products is ubiquitous in most industry sectors. While connectivity enables a lot of innovative features, it also increases the potential for malicious attacks. To attack a non-connected system, physical access is required. Attacking connected systems does not necessarily require physical access and, thus, potentially enables attackers to remotely compromise many devices at the same time [1] [2] [3].

Connected products are often not developed from scratch, but re-use legacy components – components that were never designed for secure use in a connected scenario. Examples for this include industrial control systems (ICS) that were connected to the internet [4], vehicles that are connected by aftermarket dongles [5], and infusion pumps that are connected to the hospital network [6].

The resulting security incidents can threaten company business models due to reputational damage, data privacy fines and compensation payments to end-customers as well as B2B customers. Furthermore, scalable attacks put social values at risk, which motivates legislators to take action in terms of cybersecurity legislation.

Why Security

The developing attack landscape

While a decade ago, attackers were mostly targeting IT systems, a shift of their focus to embedded systems can be observed [5] [6] [7]. Reasons for this are manifold:

READ MORE
  • Embedded systems are easier targets, as they do not apply security mechanisms that are already common in IT systems and user awareness is mostly non-existent.
  • Successfully attacking embedded systems often has a direct impact on the physical world (e.g. safety goals), which leads to more publicity.
  • Attacking embedded systems enables attractive business models that go beyond online banking fraud and identity theft (e.g. “What is it worth to you that the vehicles of your fleet are still able to drive tomorrow?”).

More and more academic papers on vulnerabilities and attacks are being published [8] [9] and the first attacks have already happened in the real world [10] [11] [12]. This can be compared to the security situation in the realm of IT during the late 80s and early 90s, just before malicious players started exploiting these findings to massively spread viruses and trojans. If the historical development of attacks in the IT world is of any indication, we will be confronted with drastic situations and should make it a priority to learn from the past. The amount of observable real-world attacks when it comes to embedded products is not at its peak yet, but the attacker side of the security game does not rest and is currently developing technologies and methodologies that make attacking connected products more convenient. As a consequence, the effort involved in attacking embedded systems becomes increasingly less of a problem. The future risk for companies, individuals, and society also dramatically increases if products that are developed today are not hardened with appropriate countermeasures.

The developing attack landscape

While a decade ago, attackers were mostly targeting IT systems, a shift of their focus to embedded systems can be observed [5] [6] [7]. Reasons for this are manifold:

complex security

  • Embedded systems are easier targets, as they do not apply security mechanisms that are already common in IT systems and user awareness is mostly non-existent.
  • Successfully attacking embedded systems often has a direct impact on the physical world (e.g. safety goals), which leads to more publicity.
  • Attacking embedded systems enables attractive business models that go beyond online banking fraud and identity theft (e.g. “What is it worth to you that the vehicles of your fleet are still able to drive tomorrow?”).

More and more academic papers on vulnerabilities and attacks are being published [8] [9] and the first attacks have already happened in the real world [10] [11] [12]. This can be compared to the security situation in the realm of IT during the late 80s and early 90s, just before malicious players started exploiting these findings to massively spread viruses and trojans. If the historical development of attacks in the IT world is of any indication, we will be confronted with drastic situations and should make it a priority to learn from the past. The amount of observable real-world attacks when it comes to embedded products is not at its peak yet, but the attacker side of the security game does not rest and is currently developing technologies and methodologies that make attacking connected products more convenient. As a consequence, the effort involved in attacking embedded systems becomes increasingly less of a problem. The future risk for companies, individuals, and society also dramatically increases if products that are developed today are not hardened with appropriate countermeasures.

harden embedded products

The ongoing standardization & legislation

The necessity to harden embedded products against attacks and keep up with the current developments in the attacker world is recognized by major companies, standardization bodies, and lawmakers.
READ MORE

This is shown by current standardization efforts such as ISO/SAE 21434 [13], IEC 62443 [14] or the NIST Cybersecurity framework [15] and new regulations regarding cybersecurity in specific domains [16] [17] [18] [19] [20].

In many industry sectors, applying adequate security mechanisms and security engineering processes will no longer be a choice of each company, but a requirement – either made by lawmakers or by B2B customers who have to demand security for supplied products in order to make their own products secure.

The ongoing standardization & legislation

harden embedded products

The necessity to harden embedded products against attacks and keep up with the current developments in the attacker world is recognized by major companies, standardization bodies, and lawmakers. This is shown by current standardization efforts such as ISO/SAE 21434 [13], IEC 62443 [14] or the NIST Cybersecurity framework [15] and new regulations regarding cybersecurity in specific domains [16] [17] [18] [19] [20].

In many industry sectors, applying adequate security mechanisms and security engineering processes will no longer be a choice of each company, but a requirement – either made by lawmakers or by B2B customers who have to demand security for supplied products in order to make their own products secure.

The complexity of security

While standards and legislation demand secure products, it is easier to demand cybersecurity than it is to achieve. Security is a complex topic due to several aspects that have shown to be challenging for companies.

READ MORE

attack landscape

  • An ever-changing attack landscape: security has to protect against intelligent attackers that continuously develop their abilities further and adapt to the countermeasures that are in place. Security has to be thought of like an “arms race” rather than a “one and done” kind of challenge.

security topic

  • Required mindset change: The security topic is new to most companies and not yet part of the employees’ mindset – and that is true both for management and engineers. The security topic is easy to grasp, but hard to master. For instance, creating checklists to tackle the problem is often the first reaction, but this evidentially over-simplifies the problem and leads to unsecure systems. Thus, security engineering cannot be introduced into a company overnight but requires careful preparation, management support, and the participation of all employees and management hierarchies.

Technical challenges

  • Technical challenges: Applying security mechanisms does not come for free. They consume memory and computing resources that might not be available and they potentially conflict with other functional or non-functional requirements like safety. As these goal conflicts have to be carefully balanced, security cannot be considered in isolation. Thus, security engineers need to have the capability to understand the bigger picture and the restrictions of the technologies involved.

Business goal

  • Business goal conflicts: On the one hand, systems have to be secure; on the other hand, they have to make it to market in time and costs have to be acceptable. Often this constitutes a goal conflict. Security has to be considered from the beginning of an engineering project to avoid unnecessary delays and costly architectural changes late in the engineering process. In reality, however, security is often thought of much later when design decisions have already been made and boundary conditions are established – which makes achieving adequate cybersecurity even more challenging than it already is.

The fact that security is complex and cannot be thought of in a unidimensional way is also recognized by existing standards, which require the application of “adequate” security mechanisms, yet do not explicitly define which security mechanisms have to be applied. For companies, this makes security much more complex than ticking boxes in a checklist. To avoid costly and unnecessary investments in security mechanisms that are not needed after all, they first have to prepare and determine what “adequate” means within their unique setup.

The complexity of security

While standards and legislation demand secure products, it is easier to demand cybersecurity than it is to achieve. Security is a complex topic due to several aspects that have shown to be challenging for companies.

attack landscape

  • An ever-changing attack landscape: security has to protect against intelligent attackers that continuously develop their abilities further and adapt to the countermeasures that are in place. Security has to be thought of like an “arms race” rather than a “one and done” kind of challenge.

security topic

  • Required mindset change: The security topic is new to most companies and not yet part of the employees’ mindset – and that is true both for management and engineers. The security topic is easy to grasp, but hard to master. For instance, creating checklists to tackle the problem is often the first reaction, but this evidentially over-simplifies the problem and leads to unsecure systems. Thus, security engineering cannot be introduced into a company overnight but requires careful preparation, management support, and the participation of all employees and management hierarchies.

Technical challenges

  • Technical challenges: Applying security mechanisms does not come for free. They consume memory and computing resources that might not be available and they potentially conflict with other functional or non-functional requirements like safety. As these goal conflicts have to be carefully balanced, security cannot be considered in isolation. Thus, security engineers need to have the capability to understand the bigger picture and the restrictions of the technologies involved.

Business goal

  • Business goal conflicts: On the one hand, systems have to be secure; on the other hand, they have to make it to market in time and costs have to be acceptable. Often this constitutes a goal conflict. Security has to be considered from the beginning of an engineering project to avoid unnecessary delays and costly architectural changes late in the engineering process. In reality, however, security is often thought of much later when design decisions have already been made and boundary conditions are established – which makes achieving adequate cybersecurity even more challenging than it already is.

The fact that security is complex and cannot be thought of in a unidimensional way is also recognized by existing standards, which require the application of “adequate” security mechanisms, yet do not explicitly define which security mechanisms have to be applied. For companies, this makes security much more complex than ticking boxes in a checklist. To avoid costly and unnecessary investments in security mechanisms that are not needed after all, they first have to prepare and determine what “adequate” means within their unique setup.

The consequence

Cybersecurity is often considered a rather unpleasant side topic. However, in light of recent developments – both the ongoing standardization and legislation as well as the evolution of the real attack landscape – adequate cybersecurity is becoming a strict requirement instead of simply nice to have. Companies cannot establish security processes and a security culture overnight. This constitutes a market differentiation opportunity: investing in building up cybersecurity capabilities now enables companies to develop innovative features quickly and efficiently in the future. This constitutes a market advantage.

Still have a question?