Save Article Instructions

Securing embedded real-time software

There are many different ways to add security to software, but there is more to it than meets the eye. Security is not simply added to a piece of software, particularly one that is safety critical as most embedded, real-time programs tend to be. If a collision detection program fails or is attacked, the results can be devastating, which is why security has become such a hot topic for embedded, real-time software.

Fully networked, fully vulnerable

"I think for real-time software, the issue that we've got now is historically a lot of real-time systems have been self-contained," says John Blevins, director of private marketing at LynuxWorks in San Jose, Calif. "A lot of the time the only thing they're connecting to is the only thing they need to connect to. Now all these devices are being connected to a network or multiple networks, there needs to be more security because access to the device needs to be protected more."

The typical real-time system of the past was attached only where it was necessary. A collision detection system only stayed connected to its vehicle, and that was the only machine it could communicate with. Now, with devices transmitting data to vast networks, there needs to be security on systems that have traditionally been closed to the outside world. With these devices now opened up to networks, they are exposed to any malware that exists within those networks.

Where security starts

Security is not an afterthought for the designers of embedded, real-time software; it needs to be considered from start to finish. "Well-written code, and code that doesn't try to be too clever, and to have multiple layers of defense is important," says Paul Anderson, vice president of engineering at GrammaTech in Ithaca, N.Y. "Defense in depth is the term they use. A lot of successful attacks on regular non-embedded software these days are multiple stage, where the attacker will use a number of different vulnerabilities, each giving them more control of the applications. Those are things that you can often have defense against if you have defense in depth."

Attacks against programs can come from simple coding errors, or failing to adhere to the strict guidelines safety-critical code is given. Analysis of code, both static and dynamic, throughout the coding process is important to creating secure software. Having software with no errors in the code can prevent attacks that use coding problems such as buffer overruns to alter the way a program operates.

Separation kernels are a way of simulating a distributed environment. A separation kernel partitions all resources under its control, and prevents any communication between partitions except for explicitly allowed information flows (such as a collision detection system being able to communicate with the navigation system, but not allowing the navigation system to communicate with the collision detection system). "Within the DOD, we are seeing an increase in multiple levels of security in a single system, and a separation kernel is the chosen method of doing so," says LynuxWorks' Blevins. "There are more DOD programs specifying separation kernels for security."

Security from start to finish

"You have to take a look at how you secure the very core of the system while you're booting up, how you secure additional layers that support a rich application environment, then how do you secure the applications," says Wind River's Downing. "How do you qualify those binaries on systems that are running? How do you monitor your system and keep it safe in case something breaches your security?"

"You can't say this device is secure because I've done the following things anymore," Downing explains. "It's a more dynamic environment. How do you address dynamic security in an environment that constantly changes? It just requires good architecture and constant analysis of your system. You start with a good security architecture, find out what your weaknesses are, fortify those as required, and continuously monitor and improve."

To access this Article, go to: