Is This Helpful?

By Adam Dodge

On January 12, 2009, MITRE and SANS announced the release of the CWE/SANS Top 25 Most Dangerous Programming Errors list. Since the release of this list, there is been a lot of talk over whether or not this latest “Top XX” security list is useful. However, that is not the focus of this article. Instead, let’s take a look at the action of Will Pelgrin and CSCIC.

Announced at the same time as the list, CSCIC released “draft language” to help guide New York State procurement guidelines* to include provision for secure code. On the surface, this type of requirement is to be applauded. After all the goal is to require the development of secure coding and testing practices for all applications purchased by New York State agencies. However, this current draft still leaves several questions in my mind.

One of the first problems that comes to mind is that there is no mention of the increased costs associated with the tenets of the procurement guidelines. It goes without saying that the new requirements have the very real possibility of adding significant increases to both develop times and development costs. After all, activities such as mandatory background checks for developers, development vulnerability and risk assessments, and security control compliance customized per customer demand all have associated costs.

Should organizations eschew these secure coding practices in favor of faster products at a lower cost? Of course not, but this draft guideline should not ignore the fact that there will be an increase due to the requirements suggested. Interestingly enough, the OWASP Secure Software Contract Annex, off which the Application Security Procurement Language document is based heavily, does address this problem. In fact, OWASP encourages that such costs be negotiated as part of the procurement process, not ignored altogether.

Beyond actual coding practices, one requirement that the proposed procurement guideline calls for is increased documentation. Generally, more documentation is a great idea and the documentation called for in the procurement guideline (in most part thanks to the work by OWASP) will allow organizations to fully understand not only the security controls used during the software development process but also the proper security configurations to employ. However, none of these increased documentation mandates require that the purchasing organization actually understand all of this increased documentation.

Of course, such language would not be appropriate in a procurement guideline, but the simple fact is that no amount of documentation will help ensure secure operation of any software application if the individuals running the application do not understand what the documentation specifies. Organizations need to ensure that there are staff resources available internally to interpret the documentation provided by developers in order to properly ensure the controls included in the documentation meet organizational requirements.

The final section of the procurement guideline is probably one of the biggest problems with the document. The intent behind the language used in the Investigating Security Issues is clear. After all, if a security incident were to occur due to a problem with the software, then the vendor’s help with investigating the incident would be immeasurable. However, the wording used in the actual guideline simply ensures that very few - if any - procurement contracts will contain this incident investigation support requirement.

The problem is that the procurement guideline takes its intent from one of the OWASP stipulations, but ignores the importance of the supporting sections of the OWASP Annex. In short, OWASP calls for Developer support during incident investigations but allows for the fact that the incident may involve a wholly unique issue outside of either security requirements or “reasonable” security testing procedures. After all, complete security today does not ensure complete security tomorrow. Any secure coding requirement needs to allow for the fact that there will be unforeseen security incidents no matter how good the security requirements are and to allow for a good faith negotiation between developer and customer in such cases.

*Please note the links to the procurement guideline point to the online SANS mirror and not the PDF document on the CSCIC web site. This was done because the CSCIC PDF does not reference the OWASP Annex.

Editor: Join additional conversation on this topic in the Security Catalyst Community: New York drafts language demanding secure code