Select Page

Criminal Energy: Fuel for Software Engineering

How to compete "Hacker vs. Industry" successfully passes

Author: Jürgen Belz, PROMETO GmbH

Contribution – Embedded Software Engineering Congress 2017

What conditions must be met to meaningfully integrate security into development? Hackers always work in teams and are solution-oriented. They need expertise, equipment, and access to the system for their work. Security developers can only make access as difficult as possible. However, this requires developers to learn in detail and continuously how hackers gain access – and this means hacking themselves. This starts a race against time, because threats must be neutralized within a few days. The normal development cycle of 1-3 years no longer applies.

Hackers are not automatically criminals.

Hacking is generally associated with digital vandalism, extortion, data theft, and other crimes. However, in its literal sense, hacking is the ability to find highly unusual and anything but obvious solutions.

Security engineering processes alone do not provide sufficient protection.

Most companies' development processes aim for so-called best practices, meaning proven design principles. These are documented in norms and standards. Every developer selects the same methods from a standard when solving a task. This rigid, linear approach to business processes is the exact opposite of hackers' special ability to see alternative applications. Therefore, security engineering processes do not have the desired effect in practice. Nevertheless, they should not be abandoned – however, one should be clearly aware of the limitations of these processes.

The minimum of engineering processes

Figure 1 (see PDFFigure 1 shows a simple example of a requirements specification and functional specification set, mapped in PTC Integrity. The requirements specification of an OEM is shown at the top, and the corresponding functional specification with four requirements is shown at the bottom. Security processes should always be integrated into the normal development processes and not decoupled from the rest of the process. Security is also, and above all, a substantive element of requirements engineering.

In particular, requirement 4 – blocking access to the internal areas of the ECU – creates a conflict, as the principles of Design for Manufacturing are completely contrary to security requirements. Repairs require access to the internal state of the ECU. Security, on the other hand, aims to deliberately block this access. In most cases, the one who incurs the lowest visible costs wins, meaning Design for Manufacturing, and therefore the hacker.

Naivety, arrogance, ignorance, and overconfidence

Many say, "Design for Manufacturing is unproblematic because hackers can't get into it anyway, since they don't know anything about the mechanisms used." This is naive and reveals a false image of the enemy: the hacker, the singular entity. This oversimplification is insidious because such "cracks" don't exist in that form. Three groups of hackers can be identified. First, there are researchers who publish security vulnerabilities. Second, some IT security companies use publications for marketing purposes. The third group consists of profit-oriented companies that don't shy away from skirting the edges of legality. It's in their economic interest to provide users with the easiest-to-use tools possible, so even a petty criminal without sufficient IT expertise can use them. The internet is full of instructions and tools that can be ready for digital heists in just a few hours. Hackers also network, exchange information, and thus work together in a team-oriented and solution-oriented manner.

Roughly two-thirds of all crimes are attributed to insiders. Figure 2 (see PDFThe graph shows two different statistics. The sum >100% is explained by the fact that insiders and outsiders sometimes work together. In targeted attacks, attackers don't just rely on their technical skills, but also exploit human weaknesses such as the need for recognition, greed, addiction, etc. This aspect of cybersecurity is called social engineering.

Insiders inherently possess the necessary expertise to hack a system. Consequently, companies cannot influence the expertise required for a hacking attack, as experts in a given field can be quickly found via social media. An attacker then uses social engineering techniques to exploit this expertise.

Similarly, a company cannot influence the equipment required for a hack – most tools can be obtained cheaply. However, in the field of embedded systems security, there are only a few tools that can be used directly. A key characteristic of hackers is their ability to build the necessary equipment themselves.

Security means making attacks uneconomical.

Hackers need expertise, equipment, and access to carry out their work. Expertise and equipment cannot be influenced. The only remaining option is to make access as difficult as possible. However, this requires developers to continuously and meticulously learn how hackers gain access. The analysis in the automotive sector is shown in Figure 3 (PDFThis shows that available resources can be categorized from inexpensive to expensive. The effort is weighed against the benefit. Security is therefore achieved when the effort becomes uneconomical compared to the benefit. The insidious aspect is that the actual effort varies greatly depending on the hackers' skills.

With each level, the skill requirements increase, and so do the costs. Whether the effort is worthwhile depends solely on the hackers' business model.

True experts are found only sporadically.

Experts in all fields are scarce these days – including security experts. Finding them is quite literally a breeze. We advise companies to present their employees with a series of challenges. Figure 4 (see PDFFor example, it shows assembly code. Whoever can explain the vulnerability in detail advances to the next round. Whoever masters many rounds is suitable for a career specializing in cybersecurity.

Cyber Security is a game

Security should be viewed less as part of a development process and more as a competition that can be won or lost. The rule is usually: if you know your opponent, you can win the fight – the element of surprise must be exploited! Hackers' access should be made more difficult. Security is not an end in itself; it needs the criminal energy of hackers as its fuel. Anyone who wants to succeed in the hacker vs. industry competition must, above all, constantly learn and practice new attack techniques.

The adaptation of the processes

Current knowledge of attack techniques contributes approximately 50% to security. The other 50% are divided among the security development process and verification and validation measures, including reviews. A look at IT shows that, for example, Microsoft now has very good and, above all, externally transparent processes. The green portion in Figure 5 (see PDFThe diagram shows the classic development process. The standard procedure has been supplemented with security aspects. Developers must have completed security training as a prerequisite (blue column).

A key insight in security is that no system is truly secure. Therefore, a contingency plan is essential, ready to be implemented in case of an emergency. The time factor of a hack is particularly critical. Instead of the usual response time of months, a security problem must be fixed within days. This is only possible if a contingency plan is readily available. Figure 5 (see PDFThe emergency process is marked in green as an incident response plan. Its creation must be completed with the product release. Therefore, it is also included in the release process.

Summary

Many manufacturers rely solely on formal security processes for their implemented security measures, but these are neither effective nor efficient in protecting against hackers. This approach is naive and negligent at best. The reason for this becomes clear when one considers cybersecurity from a hacker's perspective.

Most companies' development processes are based on standardized procedures. This rigid, linear approach to business processes is the exact opposite of hackers' special ability to see alternative applications. Consequently, security engineering processes often have a significantly lower impact in practice than hoped.

Even though these processes don't make a particularly significant contribution to the creation of safe products, they shouldn't be dispensed with, but one should be clearly aware of their limitations. Ultimately, the goal should never be to develop an absolutely safe product, but rather to have a contingency plan ready for product release.

A developer cannot create a secure product without a concrete understanding of what security means. Therefore, another recommendation is to conduct security training for all developers. Security should not be viewed as part of the development process, but primarily as a competition between manufacturers and hackers, a battle that you either win or lose. Only by understanding your opponent can you defeat them!

Neither the skills nor the equipment of hackers can be influenced by manufacturers. All that remains is to make access more difficult. This is only possible if developers learn in detail and continuously how hackers operate. Security needs the criminal energy of hackers as fuel. Anyone who wants to succeed in the hacker vs. industry competition must above all constantly learn and practice new attack techniques.

Besides a basic understanding of security among all developers, a small number of in-house experts are needed. These can be found by playfully challenging them. However, this only works if these individuals possess "criminal energy" and can freely express it.

Download the article as a PDF


Our training courses & coaching sessions

Do you want to bring yourself up to date with the latest technology?

Then find out more here Regarding training courses/seminars/workshops and individual coaching sessions offered by MircoConsult on the topic Quality, Safety & Security.

Training & coaching on the other topics in our portfolio can be found here. here.


Quality, Safety & Security – Expertise

Valuable expertise on the topics of quality, safety & security is available. here Available for you to download free of charge.

To the specialist information

You can find expertise on other topics in our portfolio here. here.

MicroConsult Newsletter

With the MicroConsult newsletter, you'll stay on the pulse of the embedded world. Look forward to proven practical knowledge, real professional tips, and current events – directly from our experts for your project success.

Subscribe now!

Published by

weissblau media

weissblau media