“Security has to be mandatory for automotive software development”
Smart2zero: Mr. Kuehlmann, security is a big issue for developers of software – in particular embedded software. At the same time, in the development process methods like agile development and DevOps are increasingly being established as standard. Is there a connection between DevOps and security?
Andreas Kuehlmann: Absolutely! First of all, let’s step back for a moment. What DevOps is all about, is essentially automating the entire development, testing and delivery process in software development. This is kind of if you take agile (development) to the next step; agile was really coming up 15 years ago, where people started reorganizing the software development – instead of doing in one large chunk over a long period of time, chopping it off into small pieces, and these small pieces then individually delivered. DevOps is now the next step where you automate the process. The interesting part about DevOps is it’s actually more organizational issue than actually a software development issue itself. We see this now coming up in the automotive industry. We know this from several OEMs that they move away from the traditional V model, and are really getting into agile and actually utilize DevOps in that process.
Smart2zero: Is there also a connection between Open Source and security? I’m asking this, because everybody considers Opens Source as secure and safe, just because it is open and everybody believes that it secure because it has been tested all over again by the community.
Kuehlmann: Security is actually one of the big issues in Open Source. Today, you have about 100 million to 150 million lines of code in a car, many of them are based on Linux or its derivatives. So, the amount of Open Source is anywhere between 60% and north of 90%. A lot of this is taken from either the general distribution or from specialized distributions. Therefore, actually, Open Source is a key element to get a car software developed today. But then, at the same time, there are Open Source’s vulnerabilities. There are two types of vulnerabilities in the car. There are the ones what are called known vulnerabilities, and they typically come from Open Source. And then you have the unknowns. The unknowns are Zero-Day (exploits). Zero-Days is, for example, what Charlie Miller and Chris Valasek exploited that in their Jeep hack. The known vulnerabilities are really the ones that researchers look at in Open Source components, they find the vulnerability, publish them in a responsive disclosure process to the NVD (National Vulnerability Database), and essentially, they let everybody know that there is a vulnerability that needs to be fixed. So if you have Open Source components in your car, somebody finds a vulnerability, the hackers see the same announcement. They can essentially start exploiting, in fact, they very often exploit such a vulnerability, they search and find this on the Internet. This is a huge issue for automotive software development.
Smart2zero: But in a car, you have safety-relevant software and you have to follow the procedures prescribed by ISO 26262 and other Standards.
Kuehlmann: Right.
Smart2zero: And you have to have dozens institutionalized assessment processes. Wouldn’t you necessarily uncover any security threats before the software becomes integrated into the car?
Kuehlmann: This is ultimately the goal. There’s a whole number of standards for software that are addressing the safety issue. For example, ISO 26262. You probably are aware of the MISRA coding standard with its derivatives. These Standards, particularly MISRA, are mostly focused on code cleanliness, I wouldn’t even say heavily on quality, but think about having a well-structured code that is easily readable, and they are still important in automotive. But to you the new security standards. With ISO 26262, this discussion is extending into security. If you look at what we do at Synopsys – we are in the business of providing tools, services, and methodology for addressing quality as well as security in the development process. Meaning, you know, fix it while you are coding it, so that it doesn’t get released into the car. This is ultimately where the goals will go, because you have to address it at the root, and if not, then you have to fix it later and update it.
Smart2zero: Programmers and IT developers are under pressure to be productive and delivering their results on time. Therefore, the question is: can these software assessments and risk checks be automated?
Kuehlmann: To some degree. But it’s not only related to automotive. Security has to be a mandate from top down. It has to have the same priority as any feature in the software. As soon as you start trading off you get essentially into organizational conflicts, you get into priority conflict, raising the question to either develop all those features or address the security concept. So, first and most importantly, it’s an organizational and a business decision that needs to be done. The second one is putting a software development process in place that is comprised of training the developers: you know, how do you actually write secure codes, how do you have a secure architecture, and a secure design; followed by the designer start, doing architectural risk analysis and making sure that the design is fundamentally secure. This is a manual process, followed in the development process is using automated tools for standard testing as well as dynamic testing that can’t find vulnerabilities as you actually code it and address it in the development process; and followed by rigorous system testing and penetration testing once you release the code and put the system together. So it’s process; it starts by educating the developers, getting the architecture and the design right, all the way to having rigorous testing before you release. And by the way, this is nothing new in the IT world, it has been around in software development since the beginning of its days.
Smart2zero: Then there is always a kind of tension between security and quality?
Kuehlmann: There is a tension if the organization is not set up properly. You see this very often in organizations where the security team is separate from the development team. Where security is kind of an afterthought, and the security team performs some security testing after the development process. This typically results in a kind race: The development team is ready, features are complete, they are ready to ship. And then the security team comes in: Oh no no, you know, there is a vulnerability, and they do code review and find all kinds of issues. Our experience is: you need to move it to the developer. You need to enable the developer early on to address security issues as they code.
Smart2zero: In a nutshell: The earlier in the process it is discussed and understood, the better is the chance to have a high quality and secure software in the end. And the cheaper it is to find out if there is a kind of vulnerability.
Kuehlmann: Right, right, Exactly right.
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
