Skip to main content
September 12, 2014

Security Assessment, Speed — and the Death of Mutual Exclusivity


Maintaining focus is important, but priorities shift.

Those seven words sum up a conflict as old as time in the world of software development, where sharpening focus in one area inevitably causes a need for improvement in another. If anything, it's a testament to the cyclical nature of development as a whole: Any change, from a shift in methodology to implementation of new technology, can cause problems (or benefits) bigger than the initial change was meant to fix.

As an example, consider the increasing tensions between time to market and security assessment, two monumentally important aspects of the development cycle.

While quality and speed have always been at odds to some degree, there's no doubt that things are coming to a head now — or that, given current market conditions, developers of all sorts need a solution that doesn't include pulling resources from one area to dump into another. Speed and security are the name of the game in every niche and submarket of the software-development industry, and woe be unto those who can't find a decent balance before the bad guys do.

Sometimes the numbers say it all. IDG, a research company long known for its insightful findings, recently announced that over 60 percent of enterprise-developed web, mobile, and legacy apps aren't checked for potential security issues. If that's not an indication of the potentially damaging consequences of competing priorities, we don't know what is.

Agile: Automated, Efficient — and Insecure?

Of course, the X-causes-Y relationship between speed and security is a very high-level take on things. The real-world issues causing these problems are far more nuanced, which can make isolating and resolving problems all the more difficult.

Take the Agile movement, a collection of practices and methodologies so popular that 88 percent of respondents (3,501 of them, to be precise) claimed to use it in a 2013 VersionOne survey. While the 2014 figures haven't been released yet, it's fair to assume they'll be higher: last year alone, the number of Agile adopters rose 8 percent, according to the company.

Obviously, there's a reason so many companies have chosen to at least dabble in Agile. Whichever of the countless variants you choose, you end up with a process/methodology much better suited to the realities of contemporary software use. Internal or customer-facing, an incremental approach allows you to fix issues and make improvements faster than traditional methods — a crucial distinction in this new age of small attention spans and instant gratification.

But there is a trade-off — or perhaps a sacrifice — required to make that adjustment, as evidenced by IDG's 63-percent figure referenced above. As trends show the rise of the software application layer as the number-one attack vendor leading to security breaches, the ramifications of that sacrifice only become more serious.

As always, the problem lies in the dichotomy between speedy delivery and secure delivery. The sheer amount of time needed to ensure a secure product flies in the face of one core Agile tenet (speedy deployment), while a need for dedicated, generally specialized personnel can disrupt the practice's focus on automation.

The Piecemeal Problem (and a Solution)

Internal security assessments aren't always viable options for developers. Going ad-hoc presents similar issues: Besides being totally dependent on the skills and knowledge of the people performing the test, the prices companies pay for these manual tools tend not to align with the value or results they receive.

Instead, security assessments need to be integral parts of every plan. Moreover, the practices and processes behind them should be continually refined, improved and adapted. When every incremental update potentially opens the door to another breed of attack, patching and moving on is the equivalent of fixing tires only when they go flat — it's just a matter of time until the lack of preventative maintenance causes trouble no quick fix can remediate.

Unfortunately, the inverse is also true in the ongoing struggle between getting a product out quickly and safely. We certainly aren't trying to argue that speed isn't an imperative factor — quite the opposite, in fact.

The secret? Finding that balance we talked about way back in the first sentence. This does not necessitate a trade-off, a sacrifice or any real loss on the other end, however. Even if your current projects are among that 62 percent, you can approach security assessment with an ongoing, distinctively agile mindset: think continuous, flexible, scalable and automated.

In an industry where surviving (and indeed, thriving) means fixing security problems every time they present themselves, it appears to us that finding trouble is almost always better than letting trouble find you.

Photo Source: Wikimedia Commons

Evan Wade is a professional freelance writer, author, and editor from Indianapolis. His time as a sales consultant with AT&T, combined with his current work as a tech reporter, give him unique insight into the world of mobile/Web security and the steps needed to properly secure software products. Follow him on Twitter.

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.