Embedded systems are either fixed or programmable combinations of hardware and software designed to perform a specific, pre-defined task within a larger mechanical or electrical system. Many of today's electronic products have embedded systems integrated into their designs. Embedded systems examples include products such as auto infotainment systems, medical devices, consumer electronics, industrial controls, mobile devices and IoT products.
In this interview, Barr Group CTO and software and firmware expert, Michael Barr, discusses the unique challenges of cybersecurity for embedded systems security.
David Tayman: Hi, I’m David Tayman, Managing Partner of Tayman Lane Chevarri, a business law firm in Washington D.C. I’m here with Mike Barr, Chief Technology Officer of Barr Group and also an expert consultant in a variety of cases. We’re talking today about computer security, cyber security. Before we get into the topic Mike, why don’t you tell us a little bit about your background and your experience as an expert?
Michael Barr: Sure. My background as an engineer is in Electrical Engineering and Software. And my work has principally been with embedded systems which I’m sure we’ll talk about, but that’s the confluence of software and electronics. I’ve, as Dave had mentioned, testified as an expert witness a number of times. I think I’ve been in federal court about 25 times in front of judges and juries. And I’ve testified for both plaintiffs and defendants. And we’re doing a number of different range of cases including intellectual property disputes about software copyright and patents and also in product liability litigation. And this includes a number of cases related to satellite, system security, hacking and other topics related to what we’re going to talk about today.
David: So, a lot of times when I see a discussion of cyber security issues it deals with desktop security. How is desktop security different from the security for software or computers that are embedded in devices?
Michael: Well, embedded systems are different because they’re so specifically tied to a particular function that they perform such as a medical device, like an implantable device like a defibrillator could be or they could be a part of a satellite communication system or they could be a part of an automobile. Most people don’t realize but modern automobiles often have as many or more than 100 processors inside them as computer processors like the one in your desktop or your smartphone. But each of these embedded systems has a little bit of software or maybe a lot of software and its own dedicated electronics and computer processor. And this creates this environment of a more constrained device that’s more closely tied between software and electronics hardware creates some challenges that go beyond the challenges of securing desktop and server systems.
David: Now when I’m securing my desktop system oftentimes it’s just a matter of downloading a new update or a new system that anticipates the latest round of new threats. How is that different for embedded systems?
Michael: Well, for one thing many embedded systems have no mechanism to be updated. For example, systems that have been deployed in the past or systems that today are developed with no internet connection may have no way to take a software update. The mere act of downloading a software patch or a security update to a device requires additional processing power, additional network connectivity and additional software that might not be cost effective in an embedded device. So just to give you one example, a garage door opener. These days typically a garage door opener is an embedded system with software and electronics. But it’s not always connected to the network. And yet people are remotely interacting with it with a wireless controller. If it were found to be insecure there would be no easy way for the maker of those devices to deploy a software update across the country to all of the affected devices.
David: And I know from personal experience that I use my garage opener, the same opener for I think 20 years before we replaced that. So, is there a difference in terms of a lifespan of an embedded device versus a palmtop or a desktop computer?
Michael: Absolutely, I mean we all are familiar with the fact that our desktop or laptop computers and our smartphones there is a continual upgrade cycle where we’re getting a new one every three years, five years, whatever it is. But we’re continually updating and whereas your garage door opener or the anti-lock braking system in a car are not being updated until I buy a new car could be 10, 15, 20 years I’m still using the same software and the same electronics. And similarly, there is a lot of concern nationally about infrastructure, hacking and hacking of electric utilities and power grids and nuclear power plants and things of that sort. Each of which is full of different embedded systems that perform different functions and many of which are designed to last in the field for 30 or more years.
And so, as a result there is no upgrade path. The designers of those systems are essentially building a fixed function device that gets deployed and is out there. And the hacker really has an advantage because in the past 10 years, 20 years, 30 years, the amount of computing power and the knowhow of hackers has really gone up. And then so in this arms race you have this static device that is for example, the anti-lock braking controller or the garage door opener. And hackers are continually having more and more intelligence and more and more computing power at their disposal.
David: So, what do they – it’s clear from what you’re saying that there is no silver bullet for security in an embedded device. But what are kind of the best practices that could help improve the security environment for a best system?
Michael: Unfortunately, the best practices vary depending on the system. If you’re trying to build something that needs to be a low-cost device and can only use a certain amount of let’s say power because it’s battery operated for example, your best practices that apply in that case are different than if you’re building say the implantable medical device in the heart and also the security concerns are different. So, each project the developers need to weigh the security risks in the place of the implanted device it could be the death of the patient as a result from the attack. And they need to weigh that versus the cost and the opportunities available to update or to improve the system over time.
And also, just to put in good defenses in the first place. So unfortunately, as the developer of such a system you’ve got to build a good -- think about it like building a castle, you’ve got to build a solid defensive perimeter around your system that can thwart all attacks. Unfortunately for the hacker they have a bit of an advantage and that all they need to do is breach one section of the wall. So, if you don’t reinforce one section of your security appropriately, the attacker maybe able to come in through that what we often refer to as the weak link in the chain.
David Tayman: Oh, that’s very interesting and I think it gives me a good understanding of the different issues for cyber security with respect to embedded systems versus desktop environment. Thank you for sharing that.
Barr Group's team of electronics and software expert witnesses provide experienced and unbiased source code reviews, expert reports and testimony for product liability, patent infringement, and software copyright and trade secrets litigation involving computer-based technology and software. HIRE AN EXPERT
