Siemens – Time For Code Review / SDL

A I spoke recently with Kelly Jackson Higgins of Dark Reading about the number of vulnerabilities being found post-Stuxnet. This obviously is due to the increased attention from researchers and hackers.

The data also shows some vendors and products have a steady stream of disclosed vulnerabilities. There are at least two reasons for this.

A Pack Mentality – much of the SCADA/ICS software is still a bit unknown to the vulnerability hunters. When they learn of another product from the first vulnerability, they download it and look for other vulns. The original vulnerability often shows a simple, 90’s or early 2000’s type of vulnerability that makes vuln hunters salivate. If the developers made that simple mistake there are probably many more.

The software is fatally flawed because it was not designed with good coding practices or any part of a reasonable security development lifecycle.

Siemens could patch these 50 vulns and attackers would easily find additional vulns. What Siemens and other vendors need to do is stop and do a security code review of the product. The result may cause a significant effort to remove functions, change the coding practices, and other things that software developers could discuss in great detail.

The ICS community just needs to look at Microsoft and other companies that have faced this problem. Bill Gates famously stopped all work for a few months back in 2002 for a security code review on all development efforts. Even after that Microsoft had a huge legacy code issue, but they realized just fixing identified vulns was a treadmill not a solution.

We should applaud vendors for being more open about accepting and fixing vulnerabilities, as well as disclosing this information to customers. The improvement in Siemens CERT over the last year is clear. Rockwell Automation has done a good job in recent years at researching disclosed vulns and identifying all affected products rather than just what the researcher discovered. The ICS community needs more than improved vuln handling though; better code quality is required.

Picking on Siemens a bit here with questions customers should be asking:

What is your security development lifecycle (SDL)? What products that we are using have been through that SDL? What is the plan to review or migrate legacy code in the products we use into this SDL?

Can you characterize the vulnerabilities that Positive Technologies found? What were the root causes of these vulnerabilities? What is your program and schedule to review the rest of the code for similar errors that may result in latent, undiscovered vulnerabilities.

At least a handful of ICS vendors are 3 to 5 years into their SDL efforts and, while still a work in progress, can demonstrate the SDL is actually being applied and making a difference. They have security design documents, threat models, security code review, rigorous fuzz testing, security in QA and test plans and other elements. They train their developers on secure coding. It’s a shame, but understandable, that these vendors won’t talk publicly about the progress they have made.

The SDL issue is another area where User Groups and procurement can make a big difference. An enlightened vendor will realize that the cost of secure development practices will be recouped in less cost in fixing bugs and vulns — now that the ICS community is beginning to expect them to fixed. A vendor that has not seen the light will only be convinced by customer and prospects demanding it.

I appreciated your Microsoft example, but wouldn’t you admit that Microsoft was in a much different place in 2002, mostly as a result of economies of scale: total lines of code, # and quality of developers, # of interdependent products, and product profit margins? SDL adds a TON of overhead, and I guess my question is, how would you quantitatively convince a vendor to justify the cost?

Alos, your post has a typo first sentence, first word…c’mon. And yes…that was intentional :)

Our Tweets

About Us

Digital Bond was founded in 1998 and performed our first control system security assessment in the year 2000. Over the last sixteen years we have helped many asset owners and vendors improve the security and reliability of their ICS, and our S4 events are an opportunity for technical experts and thought leaders to connect and move the ICS community forward.