Asking for Security

Security doesn't get built into software by accident. That's why I like the latest attempt to work security into contract language. This SANS effort by Jim Routh (CISO at DTCC) and Will Pelgrin (CSO for New York State) is a useful resource for companies looking to address security in the procurement process.

I'll dive into that document in a second (or a minute depending on how fast you read). But first to understand why security language is needed in RFPs, consider a few of the reasons why vendors sell insecure software products:

1) Nobody asked. The customer didn't ask for security, so the vendor didn't provide it.
2) No one can tell. The customer can't tell if the end product is secure, so the vendor knows they won't get called out as long as the external interface appears secure.
3) Don't know how. The vendor wants to provide secure software, but is undermined by developers or development teams that do not know how to code securely.
4) Impossible given the requirements. The developers know how to code securely but the nature of the product and functional requirements preclude the creation of a secure product.

There is no simple solution to items 3 and 4. But it shouldn't be a surprise that software is insecure when (1) no one requested security as a feature and (2) no one was legally required to provide it. All professionals suffer from an exaggerated view of their industry's importance, and security folks are no exception. Most companies buying software have a long list of requirements and security ain't at the top of the list. They want an application that-

a) works
b) doesn't crash
c) doesn't leave them eternally locked in
d) they can understand
e) doesn't cost gazillions of dollars to maintain

** fill in a bunch of items I overlooked **

f) is secure enough for their business environment

Notice that resilience to the most recent XSS vulnerability is not on this list - not even in item (f). Suppose a small software shop is contracted to build a web application for a medium sized business. If the customer does not emphasize security in the RFP or contract, why would the vendor go the extra mile - and divert resources from critical functionality - to add unrequested security?

Now of course contracts do not equal security and just telling everyone to consider the CWE/SANS Top 25 is not going to make these vulnerabilities magically go away. So if you will pardon the math speak, security language in the contract is usually a necessary, but not sufficient, condition to get a secure product.

Let's get back to the SANS Application Security Procurement Language.

Besides the usual suspects like background checks, patching, and training, the text is focussed on the CWE/SANS Top 25 list of software programming errors. At times this appears to be a fleshed out version of the OWASP Top 10. This list doesn't claim to be perfect or complete, but it brings up a number of items that most developers have never even considered.

One thing I was looking for and could not find is some sort of ranking. Exploiting "Use of a Broken or Risky Cryptographic Algorithm" or "Use of Insufficiently Random Values" requires some pretty hefty technical knowledge. On the other hand, exploiting "Client-Side Enforcement of Server Side Security" often only requires you to know how to install Firebug and play around with Javascript. Their relative importance should have been indicated.

But enough quibbling about what is otherwise a useful document. Most procurement these days says something about security and best practices and maybe some weird random reference to SSL and biometric readers on server room doors. The emergence of industry standards around security procurement language can help bring rational allocation of security resources within software development companies.

The article New York drafts language demanding secure code doesn't indicate whether there is a plan to require this language in the future in RFPs issued by New York State. My guess is that this text would have to be seriously modified in the real world on a per-project basis. I don't see how the full Application Security Procurement Language could make it into most RFPs because it would scare away most bidders. But requiring vendors to commit to at least having looked at something like the CWE/SANS Top25 and to have a basic security narrative within their organization is long overdue. The move towards security language in RFPs can have a similar effect as PCI - a contractually enforceable, imperfect standard leads to real security changes in organizations.

And finally a suggestion for an additional improvement - without dedication of sufficient resources within the development process, many of the items listed will just be a meaningless checkmark. Industry standards have already been formed about security spending in IT departments, and recent efforts like the OWASP Security Spending Benchmarks Project are leading to similar data within the development world. Procurement language should include a clause that vendors will "dedicate sufficient resources" to securing their products.