Software security basics for application development managers

Fewer security holes means better software quality and lower costs. Merkow and Raghavan provide expert guidance on building and managing a software security program that pays off.

By Mark S. Merkow and Lakshmikanth Raghavan, Authors of Secure and Resilient Software Development

October 04, 2010 — CSO —

If we have learned nothing else from 60-plus years of software development it's that secure, high-quality code does not happen by accident. National governments have long understood that quality and security must be specified, designed, and implemented from soup-to-nuts throughout the software development lifecycle (SDLC).

Governments go to great length to assure that only provably secure software is used to protect national secrets. Unfortunately, this philosophy never spilled over into the commercial world and what we're left with today is a precarious branch filled with brittle applications of questionable reliability.

This article address these issues and offers solutions to help you avoid repeating the same mistakes that lead to even more insecure and unreliable software and systems. We'll look at what people expect when they acquire software and what they actually get, reasons for the gaps, what you as managers can do to improve your own organization's software development practices and measure the progress of your success.


The authors' book Secure and Resilient Software Development is available on Amazon.com.

See an excerpt Security testing of custom software applications on CSOonline.com, where you can also find the authors' primer on software security for developers

.

What People Expect In Software

Software is useful for what it does. People purchase software because it fulfills their need to perform some function. These functions (or features) can be as simple as allowing a user to type a letter or as complex as calculating the fuel consumption for a rocket trip to the moon. Functions and features are the reasons people purchase or pay for the development of software and it's in these terms that people think about software.

People also (erroneously) assume that the software they purchase is written with some degree of quality. When you purchase a software package you just assume it will operate as advertised and you never really think about how well the program does its job—just as long as it works!

The sad truth is that most software is flawed straight out of the box and these flaws can threaten the security and safety of the very systems on which they operate. These flaws are not just present in the traditional computers we use everyday, but also in critical devices, like our cell phones and medical devices—think pacemakers and cars—and national infrastructures like Banking and Finance, Energy, and Telecommunications.

Programmers are taught to write code—they are not taught how to write good code.

Organizations incent programmers to write more code, leaving good code out of the equation while cheap code and rapidly-developed code dominates the landscape.

Web applications especially are inherently flawed with certain types of vulnerabilities (e.g. Cross Site Scripting (XSS)) unless the developer has made a conscious effort to prevent it. If the developer fails to include appropriate output encoding routines and input validation routines, the application will most certainly be vulnerable by default to XSS.

To a developer, the software may in fact work just as he intended it to work but never tested it to see how it behaves when it's being fed malicious input or is under direct attack.

RESOURCE CENTER