News Stay informed about the latest enterprise technology news and product updates.

Should states lead the charge for secure application development?

I’m not a big fan of states’ rights, which made a lot more sense in 1791 than they do today (Why should one state’s misdemeanor be another state’s felony? Why is a gay couple married in one state and unmarried when they drive over the state line?).

My 18-year-old son wonders why I vote Republican and sound so much like a Democrat. I guess it’s because I like standards but don’t like government spending a lot of money on what it thinks will improve people.

I also share Gary McGraw’s skepticism about Top 10 lists Software [In]security: Top 11 Reasons Why Top 10 (or Top 25) Lists Don’t Work.

So it’s hardly surprising I have mixed feelings about New York state’s plan to use the freshly minted CWE/SANS Top 25 Dangerous Programming Errors list, as a key requirement of its procurement enforcement requirements for software developers.

But while we can quibble over the value of this list or that list, what I do like is that it is incorporated as a component of the Application Security Procurement Language, drafted by New York CISO William Pelgrin and posted on the SANS website. The critical point is that if and when the procurement requirement is adopted, developers of custom software will be held accountable. They’ll be required to demonstrate that security is a core element of their application development lifecycle, from coding thru final pen testing if they want to do business with New York.

What gives me pause, though, is that we’re likely to see a cascade of initiatives in many states, a la the breach disclosure laws that followed California SB 1386 and what we will no doubt see in the wake of the new Nevada and Massachusetts data protection laws. I’d rather see federal standards that can be applied across state borders. The states step into the, ahem, breach, because the feds are slow and/or reluctant to act. California enacted 1386 more than five years ago, and something like 42 states, the District of Columbia and Puerto Rico have followed suit, while a variety of bills have been introduced, debated and left to wither in Congress.

Companies doing business with customers in more than one state (that is, almost everyone except Sam’s Hardware over on Sycamore Street, that Sam III runs since Sam, Jr. retired 20 years after he took over from Sam, Sr.) have had to develop policies and procedures that fit the most stringent of these laws–and they’re relatively straightforward.

What happens when we start to see a smorgasbord of data protection laws (consider that Massachusetts law, which is to go into effect in May is far more demanding than Nevada’s). And secure software development? Now that’s complex. Will one state adopt the SANS guidelines and another, perhaps, insist on incorporating the secure development lifecycle directive being drafted by NIST? Will one state require developers to expunge the SANS 25, another the OWASP Top 10, and yet another an assortment from among the 700 or so errors that can leave code vulnerable?

So, applause to all who try to put teeth into security. Now if it wasn’t like pulling teeth to get everyone pulling together.

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

I don’t think that this is necessarily a bad idea, the credit card companies have been trying to do this for years with PABP (Payment Application Best Practices) and these include many more security features than just credit card related items. Mainly securing all data stored in an application. In the 25 Dangerous Programming Errors, the first category should be a no brainer “Insecure Interaction between Components.” Every software developer should be protecting their software from the errors in this category. The second category would be a little harder for some smaller companies and custom programs. The third category is also one that should be easy enough for even the small companies to implement. My thought for software having criteria like this is not for it to be government controlled but it should be market controlled. I will go back to my example of PABP and that Visa says now that they will only accept new merchants if they are PCI compliant and in order for a merchant to be PCI compliant they must be using a software application that is compliant with PABP. I also believe that it is a great selling point for software to show that you follow the security standards and have been certified by another company saying that your software is secure over the competitions.