The need for security protection measures in the Office IT environment is obvious since years. Firewall, virus scanner, encryption of data: Office IT is no longer thinkable without these aspects.

On the other hand, security for embedded systems is relatively new. These systems are already vulnerable to possible malicious attacks. For a long time there were simply no technical possibilities to attack such systems. Whether airplane, car or train, all these systems were, if at all, only individually accessible. However, this required concrete manipulation of the individual system. However, nowadays these systems are more and more “online”. This means, for example, that it is possible to manipulate entire fleets of vehicles online, which increases the attractiveness for potential attackers.

The article give answers to the following questions:

• Is it possible to transfer security measures from Office IT to the embedded world?
• Are there specific security issues that are only relevant for embedded systems?
• Are there any applicable standards?

Is it possible to transfer security measures from Office IT to the embedded world?

The question can be answered with a clear “Yes and No”. Passwords are already used in embedded applications today. However, a virus scanner cannot usually be used on an embedded application for performance reasons.

Again, all measures to prevent social engineering are applicable to both embedded and office IT.

Coding guidelines for SQL database programming for web applications are commonly known. They were created in response to hacker attacks. Coding guidelines for C and C++ with the aim to increase the security of an embedded application are also available in a first version (MISRA). However, there is hardly any practical experience of their actual effectiveness. However, the following possible attack scenarios show that coding guidelines are very useful for achieving security goals:

• Unhandled exceptions – Take over execution.
• Manipulation of (stack) pointers – Jumps into malicious code.
• Undefined reactions to error states – substitution of code.
• Insufficient input validation – Executable system codes.
• Exceeding of limits – e. g. DDOS attacks.
• Outdated operating system components or libraries – Attacks on known vulnerabilities.
• “Quick and dirty “programming style.

Are there specific security issues that are only relevant for embedded systems?

This question can be answered with a clear “Yes”. The often very different hardware and the non-standardized interfaces to the software raise numerous questions from the security point of view. However, the answers to this question cannot be found at Office IT. The fact that the CAN bus was never developed with the aim of ensuring the security of an embedded system is such a problem.

Another example are the different operating systems used in the embedded area. So far, hardly any development process takes into account the security aspects that result from this. The prevention of so-called back door attacks is certainly a scenario which shows that there is a need for action here.

Last but not least, ensuring security for systems relevant to safety is a completely new challenge with completely new questions. For such systems it is so far unthinkable that regular, fast and flexible updates of the software to close security gaps are carried out, because in most cases this contradicts the goals for achieving safety. In Office IT, however, exactly this measure is very effective in terms of achieving security goals.

It is also unthinkable that you will be systematically, purposefully and continuously attacked for safety-relevant systems because if security gaps are discovered, safety would no longer be guaranteed.

These examples show that completely new approaches will be called for.

Are there any applicable standards?

Yes, there is. IEC62443 is a standard that deals with the specific security issues for embedded systems.  It is a standard that is tailored to the needs of industrial automation and will also be applied there. Part 1 of IEC 62443 defines basic concepts and describes general topics. In Part 2, IEC 62443 deals with the processes and in Part 3 and 4 with the necessary technologies.

Note: IACS = Industrial Automation and Control Systems

The automotive industry knows the SAE J 3061 which will be converted into an ISO 27xxx standard.

The german BSI basic protection as well as the standards of the ISO27001-xx series, however, can only be used for embedded systems to a very limited extent.

Conclusion

The embedded community is well advised to look at which longstanding experiences from the office IT world with regard to security are meaningful and applicable for the embedded world.

However, it is also necessary to develop new solutions to achieve adequate security for embedded systems. Development is still in its very early stages. Autonomous driving and IoT are, however, trends that clearly show the deficits in the area of security.

In the field of standards, things are also evolving with regard to security. However, real solutions can only be expected for the definition and standardization of processes and methods. Standards will not be able to control the enormous dynamics of technological progress and the complexity of human creativity. However, both play a very important role in security.

Are you ready for a security workshop, then send a mail to: info[at]heicon-ulm.de or call +49 (0) 7353 981 781.