Through-Stack Development (Part 2)
Part of what makes connected carputers such a challenging area, is the need to meet stringent requirements on two fronts – vehicle safety (to ensure safe operation in traffic) and cyber-security (to protect the car from malicious attacks). The interesting part is that when correctly applied, solutions for one tend to lend themselves to the other.
An example of this can be found in the isolation of functionalities into different software or hardware domains. For safety, this is done to reach different Automotive Safety Integrity Levels (ASILs) for the domains, and thus minimize the amount of functionality needed at a higher ASIL level. Mandatory then, is to be able to conclusively prove that the domains are in fact sufficiently independent.
Isolation of functionalities into different SW or HW domains increments both vehicle safety and cyber-security.
Curiously, the same split into multiple domains creates well-defined minimal attack surfaces between the domains. Strategy-wise, we can think of them as chokepoints. If we can then design our Architecture to situate the targets of cyber-security attacks behind those chokepoints, like the spartans of old, we can deploy our phalanxes to make life difficult for anybody attempting to march through. If we’ve got a succession of different domains at different security levels, and we defend each chokepoint carefully, we greatly lengthen the available attack paths. Due to resembling a city defense with multiple concentric walls, this has also been called the “Minas Tirith” approach.
Brutal honesty about software security is that nothing is ever completely secure. No single magic trick will protect you from all attacks, no defense is truly impregnable. Instead, security is all about making an attackers life difficult on all fronts – lengthen all attack paths, make exploit development and deployment painful, make sure that any developed exploits don’t directly scale to the whole fleet of vehicles. In short? Instead of letting them waltz in, force them into a protracted siege. Don’t leave any mountain paths that can circumvent your phalanxes. Fight them every step of the way.
Security is all about making an attackers life difficult on all fronts.
An important lesson to understand is that in software security, you never get applauded for the things you did well, but rather slammed for the mistakes that slipped through. Interestingly, this same again holds for safety-oriented software, and there a lot has been done to define work methods, embodied in the software ASIL levels, to minimize those mistakes from ever slipping through. Essentially, the methods for development of safety-oriented systems also fit quite naturally to developing secure systems.
Of course that isn’t to say that the security happens “automatically”. Far from it. Since safety-oriented devices have long had limited connectivity, it is rare to find people with a solid foundation on both sides. Rather, what this means is that if you take an active approach of promoting both safety and security throughout your system design & development, both can be done within one development process with little extra overhead.
However, if different parts of your organization handle security and safety, instead of leveraging the natural overlap of the areas, you will end up wasting resources with sub-optimal end results on both sides. Security and safety need to be taken into account hand-in-hand, from the highest level system design, right down to each line of code.