April 16, 2012, 2:19 PM — 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.