Web App Pre-Flight

I think that it is because of my background in software development that I am passionate about integrating security testing with the SDLC (Software/Systems Development Life Cycle).  Or perhaps it’s just that watching development teams push untested code to production grates on my nerves worse than nails on a chalkboard.  Whatever the case, security testing through the SDLC is one of those things I like to talk about.

I find the analogy of an aircraft to be quite interesting.  Simply put: consider your software project as the plane, and the different types of security testing as various quality and system checks.  Now let’s apply typical software project practices to getting our plane ready for flight.  Marketing is pushing deadlines because we need to get passengers into the air as soon as possible so we can generate revenue, so we’ll skip some of the mundane early testing.  In fact we’ll skip over most testing that doesn’t relate directly to a documented business requirement and get that plane built and on the runway as soon as possible.

The end result is, of course, that the first flight of our plane will serve as the test.  How about the first landing being the first time we test our landing gear and breaks?  At some point down the line the plane will carry extra load – which will serve as another test.  At some other point down the line the plane will encounter strong winds and sleet – which will serve as yet another test.  What if we are lucky enough that the plane survives its flight but we discover that there is a systemic issue with the (untested) fasteners that were used to assemble the plane?  Imagine the cost to pull everything apart in order to replace them?

It doesn’t take much imagination to realize that having your end-users become your in-flight testers is considered poor planning.  However, this happens far too often in software development shops.  Solutions are built and rolled to production under tight timelines.  Many even go through rigorous unit testing and integration testing, which is great; however, security testing is often missed.  Security testing is skipped because it is considered something “different” from other testing, and it is not well understood by many testing and QA teams.  In reality, security testing is just “regular” testing but with more emphasis on pushing the boundaries of assumptions.  Just like an aircraft manufacturer should not assume the aircraft will not encounter high crosswinds or sleet, so should a software team not assume that input will be limited to a certain type or number of characters.  Security testing should never be reduced to just an in-flight check. It must instead be integrated into every step of development, from quality checks of fasteners to stress testing of extreme temperatures.

Jason Gillam is a Senior Security Consultant at Secure Ideas. If you are in need of a penetration test or other security consulting services you can contact him at jgillam@secureideas.com or visit the Secure Ideas – Professionally Evil site for services provided.