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.
A good example popped up today with Sergey Gordeychik of Positive Technologies presentation at an event in Seoul. Jeremy Kirk of Computerworld covers it in Siemens Software Targeted By Stuxnet Still Full of Holes. Apparently Sergey and his team have found more than 50 vulnerabilities in the current version of WinCC.
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.