Joe Fabbre, director of platform solutions with Green Hills Software (GHS), noted: "The IoT is creating a buzz and the trend is for most embedded devices to get some kind of connectivity. It's been on the way for some time and will continue. But there's a link; designing in connectivity also needs security to be designed in."
It's a far cry from the embedded systems of the past, which were essentially self contained; unless you could get physical access to the system, you couldn't 'hack' it. "With internet connectivity," Fabbre continued, "anyone might be able to access a system."
He said one of the problems is that many embedded systems tend to have a code base that was designed a decade or more ago. "That was obviously well before anyone thought about connecting them up. These systems weren't designed with network security – or any kind of security – in mind."
So companies like Green Hills are faced with two different problems: one is dealing with these older systems, helping developers to add the connectivity they desire; the other is helping them to build new systems from the ground up. Fabbre observed: "Designers are asking questions like 'how can we build in connectivity?', 'what features can we get?' and 'how are we going to feed information back and take advantage of Big Data?'. Connecting these systems to the internet could be dangerous and designers should be thinking about security."
But what is 'security'? Fabbre said: "The exhibition alongside the recent RSA Conference (April 2015) featured hundreds of vendors selling some kind of security product. A lot of those were about detecting problems after they have happened. Intrusion detection systems are an example; they are typically about trying to detect failure and closing network ports if there's an attack.
"While these products help to increase security a little bit," he continued, "it's fighting a losing battle. If you have the opportunity to design a system from the ground up, you can apply good security architecture techniques."
One major issue which Fabbre has identified is cryptography. "If you want to communicate using protected communications – cryptography – it means you need keys injected into the system."
That, he believes, brings hardware issues. "If you don't have a secure place to store the keys, then it's relatively easy to defeat a security strategy."
He gave the example of a major car manufacturer. "Its system featured some encrypted communication and it was possible to look for the keys by extracting and examining the system's firmware image – and they were found."
Automotive security is a big issue, in Fabbre's view. "It's challenging because of the complexity; there are anywhere from 10 to more than 100 CPUs in a modern car, along with millions of lines of code. If you can gain control of something that sends messages over the CAN bus, you could wreak havoc."
Automotive security is also an issue simply because of the size of the market. "There are so many cars out there," Fabbre noted. "If you're a hacker, you look for scale. Maybe you might just want to use all these connected computers to send spam, but a scarier prospect is a hacker trying to inflict damage. If a hacker could launch a coordinated attack, it could be massively damaging – and the same applies to industrial control systems."
Where do you start?
So where does a software developer start? "By identifying the elements of the system which are security critical," Fabbre said, "then working out how to isolate a breach, should one occur. The security critical components of any system should not be able to be touched by a hacker; using a separation kernel guarantees that and enables a security architecture to be applied.
"In a medical device, it could be something controlling a pump; in industrial control, it could be something controlling valves; in a car, it's making sure that whatever things that have internet connectivity can't have access to the CAN bus."
The automotive example is particular relevant, bearing in mind the growing interest in automated driver assistance systems (ADAS) and of driverless cars. "ADAS is putting control of the car into the hands of computers," Fabbre pointed out.
The complexity of the automotive business can also work against security. "It's not the OEM which writes software," Fabbre said, "it's a tier 1 or tier 2. The OEM has to know where the software has come from.
"You could take an ECU and ask the OEM what operating system is running; they may not know. While OEMs specify requirements, connectivity and authentication, for example, they pass those to the tiers."
Once the critical components are identified, the next step is to develop the overall system architecture. Designers can then start to make choices about how to provide isolation. Ask such questions as 'what hardware is there?' and 'what is the security strategy for the communications channels?'. Also determine the strategy for building the system and where the keys are stored on the target."
Human factors
One of the larger issues in security is people. "A lot of sophisticated attackers will go after people for the information they need. Who in your company or supply chain can submit firmware images? What's your review process like?"
A potential way of mitigating these issues is to adopt a device lifecycle management (DLM, see fig 1) system; a way of securing cryptographic devices during the manufacturing process. Engineering, manufacturing and IT departments, for example, will use DLM to generate software signatures, certificates and unique device keys.
"GHS is getting more involved in lifecycle management," Fabbre pointed out, "and has established Integrity Security Services to focus on this area."
Fabbre's experience suggests that a lot of engineers don't know where to start when it comes to security. "What do I do? How can I build a system that doesn't have weak links? Once you have something like DLM in place and a secure development process," Fabbre continued, "Integrity can come into play. Our focus is on safety and security, with a lot of prebuilt components that can give designers a head start, rather than working out how to do it themselves."
Retrofitting security on an existing system can be done, although it isn't an ideal approach. "For high levels of security, you can't retrofit," Fabbre cautioned. "But there are things you can do to improve the situation. For example, virtualisation allows you to take the safety critical part of an existing design and put it into a protected partition in Integrity so it isn't exposed. Regardless of operating system, secure boot is important."
Fabbre admits security means different things to different people. "One thing is certain," he concluded, "it's easy to say, but hard to do."
