By Mark Pitchford, technical specialist, LDRA
Connectivity has brought positive changes to embedded applications through new opportunities for easier monitoring, upgrades, and enhancements. On the downside, connected systems present more attack surfaces, which make systems vulnerable to bad actors. Defending against such attacks is a daunting task, even for organizations well versed in functional safety. (For those less familiar with the term, functional safety defends the world from a potentially flawed system. In contrast, cybersecurity defends a system from an imperfect world. Each presents its own unique challenges.)
No single defense of a connected system can guarantee impenetrability; however, applying multiple levels of security ensures that if one level fails, others stand guard. One popular analogy for this defense-in-depth approach is that of a medieval castle equipped to defend its inhabitants from siege through the use of towers, curtain walls, moats, mounds, gates, drawbridges, and other defensive mechanisms. And yet, aggressors did compromise castles despite these defenses.
There are also a myriad of defenses available to developers of connected embedded systems. Like castle defenses, all are helpful, but none is impenetrable.
Data-at-rest protection
Data-at-rest describes any digital data stored physically, whether on a hard drive, in the cloud, on a USB drive – wherever. If the data is valuable, then it makes sense to protect it from bad actors who want to take advantage of that value. Protecting the data requires making access to it difficult or making the data itself incomprehensible. Any connected system is accessible by definition, so obfuscating the data via an encryption algorithm is a pragmatic choice.
Secure boot
Many defense mechanisms focus on ensuring that the software system is secure when it is up and running. But if that never happens and a rogue image is loaded instead of the intended image, then all that effort is useless. Aggressors use boot attacks to manipulate devices, so a well-designed secure boot sequence helps ensure that the correct image loads.
Domain separation
In their famous paper “Remote Exploitation of an Unaltered Passenger Vehicle,” Miller and Valasek observed a vehicle hack for which “…there are no CAN bus architectural restrictions, such as the steering being on a physically separate bus. If we can send messages from the head unit, we should be able to send them to every ECU on the CAN bus.”
The implication is that it is important to prevent, as far as is reasonable, access to safety-critical domains from more benign domains. However, it is impossible to both use and completely isolate a connected device, such as a car. In practice, there are several ways to separate domains and still provide some communication between them.
The software separation of domains provided by virtualization technology exemplified by Intel’s VT is growing more popular, and separation kernels and hypervisors capable of performing that role are available from software vendors.
Multiple independent levels of security (MILS) design principles
Decades ago, J. H. Saltzer and M.D. Schroeder suggested in their 1975 article, “The Protection of Information in Operating Systems,” Proceedings of the IEEE, that “Every program and every user of the system should operate using the least set of privileges necessary to complete the job.” This simple and common sense “least privilege” approach becomes imperative where applications of differing criticality are run in close proximity to each other. In the context of a system, that means applications (including user interfaces and, hence, users) should only have access to the minimum set of interfaces and services necessary to fulfil their intended function.
Attack surface reduction
The bigger a system’s codebase, the more opportunity a bad actor has to find an entry point. It makes sense to minimize the attack surface by removing all code and interfaces that are not absolutely needed. Collating source code coverage data during requirements-based testing helps to ensure there is not any surplus code.
Secure coding best practices
The traditional approach to the verification of secure embedded code is largely reactive. Code is developed by following somewhat loose guidelines and then subjected to performance, penetration, load, and functional testing to find vulnerabilities, which are fixed later.
A better, more proactive approach considers security much earlier–a “Shift Left” along the timeline. Such a mindset applies whether deploying a DevSecOps model or a traditional V-model based secure software development life cycle (SSDLC). Shift Left implies a systematic development process in which the code is written following secure coding standards, traceable to security requirements, and repeatedly tested as development progresses to demonstrate compliance with the requirements.
A simplistic analogy?
Castle defenses were generally independent of each other. The inner walls at Carcassonne were only useful after the outer walls were breached. Until then, they were redundant.
That is less true of modern-day connected embedded systems. It is impossible to implement all defenses to the ultimate degree due to market pressure to keep costs down, so the focus is to ensure that the system is secured in proportion to the risk involved if it were compromised. The use of secure coding techniques to build a secure foundation for code that handles data between domains is just one example of how multiple defenses can complement each other, helping to ensure an optimal outcome.
About the author
Mark Pitchford has more than 30 years of experience in software development for engineering applications. He has worked on many significant industrial and commercial projects in development and management, both in the UK and internationally. Since 2001, he has worked with development teams looking to achieve compliant software development in safety and security-critical environments, working with standards such as DO-178, IEC 61508, ISO 26262, IIRA and RAMI 4.0.
Mark earned his bachelor of science degree at Trent University, Nottingham, and has been a chartered engineer for more than 20 years. He now works as technical specialist with LDRA.
You may also like:
