One of the biggest challenges in security today is how the software in our operating systems and applications are so full of holes. And while traditional software makers have made (some) headway in developing more resilient applications, experts say embedded device and systems makers -- from those who create implanted medical devices to industrial control systems -- are eons behind in secure system design and development maturity.
Secure software expert and EVP of Products and Engineering at security services provider Perimeter E-Security John Viega says that when it comes to embedded and industrial systems security, he sees two likely outcomes ahead.
"Attackers can start leveraging disclosures we see around vulnerabilities in SCADA systems and do something really horrifying. That will pour attention, regulation and investment into the problem," Viega says.
That's one outcome. The other is that the challenge festers quietly for a long time and nothing gets done. "If there isn't this kind of incident, the problem won't correct itself quickly. People will get desensitized until something really bad happens. They'll call the threat theoretical. However, we knew about buffer overflows for a long, long time before people realized how bad that risk could be," he says.
Nate Kube, chief technology officer and founder at critical infrastructure security software and services provider Wurldtech Security Technologies, also sees parallels between attitudes toward today's critical infrastructure and the way software security was viewed in the late 1990s. "Only recently have these vendors started to perform negative testing. These vendors would do conformance testing of protocols and their implementations, but they wouldn't throw malformed traffic at it to see how the systems respond," he says.
According to Kube, more vendors in the embedded device and critical infrastructure market are starting to do things like conduct classic threat modeling and risk analysis on their equipment, but they've not matured to anywhere near developing to formal secure development standards. "The problems are really similar between traditional software development and embedded device security. It's just that the engineering teams never really considered the problems. They usually felt like these things weren't going to be networked, or the networks were going to be private. So they just didn't do it," adds Viega.
There are a number of things that are different when it comes to embedded and industrial control system security. First the consequences of poor system design can create substantially more risk to society than the risks created by insecure traditional software applications. Second, it's much more costly -- if it's reasonably possible at all -- after the fact to update these systems.
"End users can't patch embedded systems," says Kube. "It's not that they technically can't, it's that it's incredibly expensive and they just don't do it. They have to call their systems provider or integrator to come in and perform a firmware upgrade on an embedded device that is controlling a large complex process and it's not a trivial thing to take offline," says Kube.
Viega agrees, and says it's considerably more expensive to fix defects in embedded systems once they're deployed to the field. "The costs and difficulty is just so large compared to straight software systems," he says. "So what happens if a vendor releases a patch and announces there is a vulnerability in their embedded device? It doesn't get broadly patched so all they effectively did was put their install base at risk," Kube says.
George V. Hulme writes about security and technology from his home in Minneapolis. You can also find him tweeting about those topics on Twitter at @georgevhulme.