Yesterday Siemens announced new vulnerabilities, and importantly security patches to address the vulnerabilities, for their S7-1200 web application. Some credit is due to Siemens for increased transparency in announcing vulnerabilities and speed in which they provide security patches, particularly for applications running on Windows. Siemens and other vendors are slowly learning that it is better business to acknowledge and fix the vulnerabilities rather than resist and ignore.

(I cannot resist an aside that somehow it is still acceptable to the ICS community to have a device and system that lacks basic security controls – that is insecure by design and requires no vulnerability to compromise the integrity and availability.)

Now it is time to learn the next lesson – most of the ICS source code requires a security review and substantial rewrite using secure coding practices. Increased scrutiny by researchers and hackers of all hat colors has found a multitude of vulnerabilities in ICS products. Even if the vendor acknowledges and patches a vulnerability, there are many more waiting to be discovered in the product because basic secure coding practices were not followed. In fact, most of the vulnerabilities found to date are the low hanging fruit that are easily identified with basic tools and analysis.

This year’s submissions to the S4 CFP included a number of abstracts pointing out a large number of really stupid vulnerabilities, e.g. backdoor accounts, overflows, insecure function use, in a variety of ICS products. This is so common that without some extra twist to the abstract it wouldn’t be interesting to anyone active in the ICS security space.

Vendors can sit back and wait for vulnerabilities to be discovered, fix what is found and hope to avoid the scrutiny of researchers. Every time a vulnerability arises the vendor can knock it down, but in a classic whack-a-mole situation the security of the code is not substantially improving because another vulnerability will pop up with any effort to find one. What is really needed is a code review to systematically address the security issues as they would have been if secure coding practices and a security development lifecycle (SDL) were in place.

This is painful, not cheap and vendors will need to prioritize what source code goes under this review. Microsoft had this realization back in 2002, kicked off by the Trustworthy Computing Initiative. They actually halted development for a few months to do this security code review. It was painful, took much longer than expected, and only covered a portion of the code.

Even the best intentioned ICS vendor will not be able to do this immediately for all the code they have produced over the last ten years. However if they are serious about security they will have secure coding practices and a SDL in place for new products, and they will have an internal plan on what legacy code will go through this review. It would be very refreshing if the ICS vendors would make this information public in an effort to lift the industry. The state of the code is certainly as bad as Microsoft’s was in 2002, and the potential impact of the insecure code quality equally serious.

For the past five years we have been including secure coding and SDL requirements in SCADA and DCS RFPs. This is not in an effort to exhaustively analyze a vendor’s SDL. Instead we are looking if they have a documented SDL? Are they training the engineers on the SDL and secure coding/development? are they following the SDL? Most vendors say they have a SDL and some even have documentation, but in 2012 most ICS vendors’ SDLs fall apart when you actually look for evidence it is being implemented. Most have increased emphasis on security, but it is still an ad hoc approach.

With all that gloom, there are a small number of vendors that are a ray of light. They are three or more years into their SDL efforts and making progress at least with new products. The business case for spending the money to deliver secure code the first time over bug fixes is well documented. The business case for reviewing and rewriting old code is less clear, especially in ICS where the quality bar is so low in terms of security.

And if you forgive me a second Weissian plug — S4 will have a presentation on this very issue. A vendor will go into the numbers showing the failure of fuzz testing as an effective means of software improvement for applications that were not developed with secure coding practices.

Image by jencu