It’s RSA Conference time so companies have reports and studies to release. One that I actually found interesting is Veracode’s State of Software Security. The data comes from assessment of “billions of lines of codes and thousands of applications.” It provides some good data points and observations on the state of things.
I’ve gotten to where I read any InfoSec literature through a control systems lens. I’m always asking, “how does this apply or not apply to the control system applications and hardware we work with?” In this case, the relevance is easy to find. The distribution of vulnerabilities by language, for example, is an interesting educational tool for developers regardless if the application you’re writing is balancing a checkbook or opening a breaker.
For those of us that are looking at security every day, there are few surprises here. What we have to do if find ways to educate people that there is a problem. That’s where reports like this can be useful. Here are Veracode’s key observations:
1.) Most software is indeed very insecure.
2.) Third-party software is a significant percentage of the enterprise software infrastructure, and third-party components are a significant percentage of most applications.
3.) Open source projects have comparable security, faster remediation times, and fewer Potential Backdoors than Commercial or Outsourced software.
4.) A significant amount of Commercial and Open Source software is written in C/C++ making it disproportionately susceptible to vulnerabilities that allow attackers to gain control of systems.
5.) The pervasiveness of easily remedied vulnerabilities indicates a lack of developer education on secure coding.
6.) Software of all types from Finance and Government sectors was relatively more secure on first submission to Veracode for testing.
7.) Outsourced software is assessed the least, suggesting the absence of contractual security acceptance criteria.
Each of these points is interesting and could be its own blog post in its own right but I want to focus on number five for now. I absolutely believe that more can and should be done for developer education. But the other lens I look through now (thank you, Ross Anderson) is the economic perspective. What is the incentive for developers to do better with secure coding in the control system space? Until customers require it, it’s just not going to happen.
Perhaps the most effective way that customers can require more from vendors is at the time of purchase. Easy win here: the procurement language document has been out for a while now and contains a secure coding section. A while back I conducted an informal survey of control system vendors regarding use of the procurement language in RFP’s. The results are disappointing. One positive outlier was at 40%, but most were closer to the single digit percentages.
I agree with the report — we’ve got education to do, but for our space it’s not just at the developer level. How much longer will it take to for us to have the at least same security expectation levels of our critical infrastructure applications as we do when we order a pizza online?
Digital Bond offers an application assessment service if you want to know what the “state of things” is for your software.