Testing for Security

By Ido Sarig

Last summer was a watershed event for security-consciousness in the embedded systems world: Stuxnet, a highly sophisticated worm exploited no fewer than 4 zero day vulnerabilities in Windows in order to attack a specific Siemens PLC and its associated SCADA system. The target was reportedly the Iranian nuclear facilities at Natanz, where uranium-enrichment centrifuges were taken out of commission by the worm’s malicious payload. It was perhaps not the first, but certainly the most well-publicized successful attack on critical infrastructure systems.

The software security industry has been discussing such an attack for years, mostly as a theoretical possibility – but now it appears this is no longer the stuff that Hollywood scripts are made of - it is all too real. Understandably, this raised concerns and awareness among other possible targets, from electrical grid operators to water management facilities. But surprisingly, there was no corresponding increase in spending on security at these organizations.  A recent study by McAfee showed only a very modest 1-3% increase in security budgets of critical infrastructure operators following Stuxnet.

I think perhaps one of the reasons for this disturbingly low increase is lack of awareness of available solutions. There are tools available today, specifically designed for the embedded software world, that help address some of these threats. Wind River Test Management, for example,  can flag “suspicious” areas of untested code as potential sources of malicious code infections. It also enables testers to work like a hacker - by using sensorpoint technology to simulate cyber-attacks as part of the testing process.

One common technique used by hackers to expose vulnerabilities and attack systems is to create adverse conditions, such as no memory or no disk space.  Thus, correctly relying on the fact that since these conditions are hard to set up in a test lab, the code designed to handle the errors resulting in these conditions has not been properly tested -- if it even exists in the first place! But with sensorpoint technology, it is very easy to inject these kind of faults directly into binary production code, and thoroughly test every such path through the code.

We recently ran a series of seminars dedicated to safety & security where I gave a presentation on these threats and the way we address them at Wind River. At the break between sessions, one of the attendees shared his insight about these vulnerabilities  – “When we built those systems, ten or twenty years ago, we didn’t plan for security – heck, people wanted easy accessibility, remote flashing of ROM – nobody wants to make a special trip into the Alaskan wilderness just to update SCADA software – now they realize it helps the bad guys get access to those PLCs, too.”