Where's the LoJack for Embedded Systems Security?

Michael Barr, CTO of the Barr Group told an audience at ESC Boston 2017 embedded systems have become a battlefield of cyberattacks and someone needs to do for embedded systems security what LoJack did for automotive.

Chris Wiltz

May 5, 2017

6 Min Read
Where's the LoJack for Embedded Systems Security?

You might remember the commercials for LoJack – the aftermarket tracking system for catching car thieves. By tracking your vehicle and sending the information directly to the police LoJack not only enabled law enforcement to recover stolen vehicles, but to also discover the location of chop shops and other locations of illegal activity. It worked so well the company, started in the late 1980s, is still around today, in the age of GPS.

Now Michael Barr, CTO of the Barr Group, is calling for the same thing in embedded systems security.

The concept, which Barr semi-seriously referred to as “LoHack” to a keynote audience at the Embedded Systems Conference (ESC) 2017 in Boston, would externalize embedded security, moving it away from developers' internal systems and onto a cloud-based service. “Remote hacks require [network] packet exchange,” he said. “If we could have cloud-based data traffic analysis and learning algorithms in place we could have device makers watching out and learning about attacks on their devices to a system that updates the security of all our networks.”

During his ESC Boston 2017 ESC keynote Michael Barr urged developers to practice "defense in depth" to add more layers of security to their embedded systems. 

According to the 2017 Embedded Systems Safety & Security Survey, conducted by the Barr Group a significant percentage of embedded systems designers are falling short when it comes to cybersecurity. Barr Group estimates 60% of new products being developed will have Internet connectivity (meaning some sort of Internet of Things functionality). However, 22% of those surveyed said they have zero requirements related to security; 37% said they have no coding standards or do not enforce their coding standard; 36% use no type of static analysis tool; and 48% do not even bother to encrypt their communications over the Internet.

Barr pointed to the recent Mirai malware attacks as an example. Mirai acts as a trojan horse that infects Windows and Linux computers through various connected devices (Internet-connected cameras are a popular target). Once it has infected a computer Mirai hijacks its resources, creating a network (a botnet) of infected devices that it can then use to launch attacks on larger systems. In October 2016, Mirai was the culprit of a large scale attack that crashed several popular websites including Twitter, Reddit, and Netflix. Without Internet of Things (IoT) devices, Mirai would not be possible. 

It all adds up to an IoT peppered with security holes – leading Barr to explain that we ought to be calling it the IoDT – the Internet of Dangerous Things. “We're living in a scary word, a dangerous world, and an interesting time to be an embedded systems developer,” Barr said. From retail to healthcare applications and beyond developers are told adding intelligence to devices is a surefire way to add value both for the consumer and the company (not to mention increase profits). But in the process of adding connectivity designers have opened the door to all manner of cyberattacks – some that are even life threatening. One only need look as far as recent cases showing the possibly of car hacking as well as the popular instance wherein security experts demonstrated the ability to hack a cardiac pacemaker as examples of this.

According to the Barr Group's survey 25% of respondents reported their embedded systems project could injure or be life threatening. “What's going wrong?” Barr asked. “We're living in a world where attacks are increasing, but we should be living in a world where these systems are benefitting us.”

For Barr the IoT is already growing too unruly for cybersecurity to remain in silos. But the challenge remains finding solutions to secure all of the types of processors and connection protocols available to IoT devices – not to mention staying one step ahead of malicious hackers. “Security is an arms race, attackers are always getting stronger,” he said.

But the issue isn't just restricted to lazy or ignorant designers, it also falls unto customer demands. “Not every system can bare all of the costs of security,” Barr said. “Any smart devices can only emerge at minimal cost, hence way 8- and 16-bit microcontrollers still sell billions per year.

Barr used the tire pressure monitoring system (TPMS) sensors in most new model cars as as an example. Since these sensors are communicating wirelessly with other systems in a vehicle they present a possible point of attack for hackers. Yet these sensors are ubiquitous because of their affordability – affordability that comes in part because of their low security measures. “There's no way we'd be driving around with a sensor in every wheel if every one had to be a $100 rock-solid secure processor,” Barr said.

Even then internal security protects the individual, not all of us – just like a car alarm only protects your car. “All these devices say, 'Don't steal my car, steal the one next to mine,” ” Barr said. “They shift the security risk down the line.”

Barr said that developers – “designers of dangerous things” – must be ever mindful of their ethical duty to pay attention to cybersecurity. 'The number one things we're going to do is not ignore security anymore, especcially when we're designing dangerous things,” he said while also asking developers to adopt bug-reducing software best practices and to use use cryptography where appropriate.

Barr also advocated that engineers adopt an approach of practicing “defense in depth.” The idea is that security should be layered so that if one system fails, another system picks up on a breach or error. “You have think like this at each layer. What kind I do at each layer to add additional layers of security so there is no one weak link.”

He used a bank safe as an example. The first level of security, the employees, may fail because a thief might threaten them to get them to open the vault. What's a possible additional security layer? Perhaps a combination that when entered into the safe opens it, but also alerts the police, so the thief has no way of knowing what combination was entered. “Thats defense in depth,” he said. “ You have to think like that at every layer. You have to think who would attack, why would they attack, and what kind of motivations would they have.”

-Chris Wiltz is the Managing Editor of Design News  

Sign up for the Design News Daily newsletter.

You May Also Like