Blog

Code Development and Security

By Adrian Lane

How do we know our code is bug free? What makes us believe that our application is always going to work?

Ultimately, we don’t. We test as best we can. Software vendors spend a significant percentage of their development budget on Quality Assurance. Over the years we have gotten better at it. We test more, we test earlier, and we test at module, component, and system levels. We write scripts, we buy tools, we help mentor our peers on better approaches. We do white box testing, we do black box testing. We have developers write some tests. We have QA write and run tests. We have 3rd party testing assistance. We perform auto-builds and automated tests. We may even have partners, beta customers, and resellers test so that our code is as high quality as possible.

We have learned that the earlier in the process we find issues, the less money we spend fixing them (see Deming, Kaizen, Six Sigma, etc.). We have even altered the basic development processes from waterfall to things like extreme and agile methodologies to better assist with quality efforts. We have taken better advantage of object oriented programming to reuse trusted code, as well as distill and simplify code to ease maintenance issues. This did not happen overnight, but has been a gradual process every year I have been part of the industry. We continually strive to get a little better every release, and we have generally gotten better, and done so with fewer resources.

None of these strategies were typical 20 years ago when developers were still testing their own code. We have come a very long way.

So what, you say?

I say software security is no different. We are on the cusp of several large changes in the security industry and this is one of them. Security will come to the “common man” programmer.

I was discussing this with Andre Gironda from ts/sci at the SunSec gathering a couple of weeks ago, and how process has positively affected quality as well as how it is starting to positively affect security, along with some of the challenges in setting up suitable security test cases at the component and module levels. Andre put up a nice post on “What Web Application Security Really Is” the other day and he touches on several of these points. Better security needs to come from wholesale and systemic changes. Hackers spend most of their time thinking about how to abuse systems, and your programming team should too.

Do we do this well today? Obviously the answer is ‘no’. Will we get better in 10 years, or even 2 years from now? I am certain we will. Mapping security issues into the QA processes, as a sub-component of quality if you will, would certainly help. The infrastructure and process is already present in the development organization to account for it. The set of reports and statistics that we gather to ‘measure’ software quality would be similar in type to those for security … meaning they would both suck, but we’ll use them anyway because we do not have anything better. We are seriously shy on education and training.

It has taken a long time for security problems, security education, and security awareness to even percolate into the developer community at large. This has been getting a lot of attention in the last couple of years with the mind-boggling number of data breaches that have been going on, and the huge amount of buzz lately with security practitioners with PCI 6.6 requiring code reviews. There is a spotlight on the problem and the net result will be a slow trend toward considering security in the software design and implementation phases. It will work its way into the process, the tools, the educational programs, and the minds of typical programmers. Not overnight. Like with quality in general, in slow evolutionary steps.

No Related Posts
Comments

@ alane:

Have you ever heard anyone complain about CISOs around the country who complain about the difficulty in getting mindshare in IT or code development groups?

Maybe it’s their CIO’‘s!

By Andre Gironda


Great analysis of the situation with code review and security integration.  I come to this from the network security perspective and not the software development side.  I agree with yours and Andre’s assessment that code will get better.  I come across many legacy applications that are presented to the ‘‘outside’’ via web-ified front ends.  Sometimes there aren’‘t developers available to improve the code and sometimes improvements actually break functionality.  The exposures that exist in this kind of presentation and interaction are scary.  To Andre’s point, WAF is a smart investment to treat this risk in a timely manner while code review and improvements are done.  Also, there’s the consideration to treat the time window from vulnerability discovery to patch for a particular application. It is faster to address the concern with the WAF immediately, then patch on a schedule after testing. On top of all that, these applications are sensitive to denial of services from too many requests or requests for unknown fields (very common, unfortunately).  Another place that protecting these legacy apps with a WAF makes sense.  Ultimately, the code inspection and remediation are necessary and will come in time.

By Domenic


Andre ... wow, thank you for the thoughtful reply.  It is certainly possible that the developer community will in fact embrace these concepts ... but I have heard from a handful of CISOs around the country who complain about the difficulty in getting mindshare in IT or code development groups.
-Adrian

By Adrian Lane


If you like to leave comments, and aren’t a spammer, register for the site and email us at info@securosis.com and we’ll turn off moderation for your account.