An end to common security programming errors?

How can procurement contracts protect organisations from security issues? Until recently this challenge was not well understood, but thanks to the effort of at least one governmental organisation in the US, this may be changing.

Today, it is very difficult for customers to guarantee the security of their IT systems. After all, most systems have security flaws, and they are often a result of arcane programming errors that are difficult to spot. Putting that into a language that is legally enforceable represents a significant legal challenge, given that errors can be difficult to identify and understand. In February this year, however, the New York State Office of Cyber Security and Critical Infrastructure Coordination published a suggested procurement template that referred to a third party document detailing common programming errors.

The third party document is titled the Top 25 Most Dangerous Programming Errors, and was produced by the Common Weakness Enumeration initiative, in collaboration with the SANs Institute, a security training institute. The document outlines some of the more harmful oversights introduced into systems programming that can in turn lead to systems compromise. These include cross-site request forgeries, information exposure through error messages, and missing encryption of sensitive data.

The procurement language in the document requires bespoke software development companies to test their applications for the 25 errors outlined there. Other requirements include peer review of code, and documentation of processes such as configuration management, software build processes and any third party software used in the creation of the software.

"The development of code using sound security practices is more effective than attempting to address security after the code has been written," the introduction to the template says. In short, a stitch in time saves nine, and if there is a way to enforce the effective stitching together of security measures at the design and coding stages in a way that makes it measurably more difficult for attacks to compromise a system, then this has to be worth putting on paper.

The agreement is designed only for the procurement of bespoke software, rather than the purchasing of off-the-shelf software. Nevertheless, it might help customers and vendors alike to avoid resorting to legal battles as a means of resolving security problems. The more rigorous the security practices that can be baked into a contract from the outset, the less likely the relationship between a software developer and a customer is likely to end in disaster. At least with these measures in place, a bespoke developer will be able to point to documentation and confirm that they have fulfilled their fudiciary duties, in the event that a security breach does occur.