Misconception No.4: Assuming Secure Software is Costly

By Ed Adams

(Back to article)

I recently had the pleasure of testing a very small application (225 logical source lines of code) that had several security vulnerabilities. Amazing as it sounds, this minimalist application was so poorly written I thought it written by a 10 year old (come to think of it, I know a few ten year olds who could write a better program!) And it got me to thinking how easy it is to screw up when writing software.

View the Entire Series

The Five Most Common Misconceptions of Enterprise Security

Misconception No.1: Over-Relying on Network Defenses

Misconception No. 2: Believing the Hype of Technology and Tools

Misconception No.3: Too Many People Assumptions

Misconception No.4: Assuming Secure Software is Costly

Misconception No.5: The “Recency” Trap

If you want to comment on these or any other articles you see on CIO Update, we'd like to hear from you in our IT Management Forum. Thanks for reading.

- Allen Bernard, Managing Editor.

FREE IT Management Newsletters

That thought then led to the "logical" conclusion we need to integrate security into our software at every possible phase. But is this feasible?

Although it may add some time to the early phases of your software development cycle (SDLC), e.g., defining requirements and design, I contend that integrating security into each phase of the SDLC will ultimately save you a lot of time and money and reduce your overall TCO for software you develop and/or deploy.

I have spoken with many clients who want to mandate security activities into their SDLC but are skeptical about the added time and complexity of doing so. They are worried about time-to-production protraction if they introduce new security activities for their application development and network teams.

What I ask these clients is a simple question: “Have you considered the total cost and risks of both options, i.e., staying the course vs. introducing new security activities?”

IT, We Have a Problem

To start answering this question, we need some numbers to help us quantify. First, consider the research conducted by IDC and IBM that quantified the cost of fixing a defect versus discovery phase. Assuming a simple 4-phase approach (Design, Development, Test, Deploy), the cost of fixing a defect in development was 1/15th the cost of fixing the same defect if it’s found post-deployment.

The difference is even more severe when dealing with security defects because you have to factor in the likelihood of incident response costs, dealing with the media, customer disclosure/notification, and suddenly finding yourself out of compliance with a critical standard like PCI, SOX, or SB1386.

Pile on top of that the difficult nature of troubleshooting security defects and the longer times needed to re-code, test, and patch and you’ve got a pretty costly bug on your hands. You have to consider this as a risk and component of your total cost. If you don’t, you’re missing some potentially massive costs; both short-term and long.

Next consider what Microsoft has done with products like SQL Server (developed using their SDL, Security Development Lifecycle process). I am no Microsoft apologist, but the data speaks for itself: SQL Server 2005 has substantially fewer security bugs than either the Oracle or MySQL databases that compete against it according to the CVE database.

This translates into lower maintenance and support costs as well as improved public opinion and a competitive selling advantage. Will there be an additional short-term investment you need to commit to create secure software? Most likely, because you may need a little more training for your team and/or investment in some tools like team guidance systems and source code or Web scanners to support your new activities. That initial cost versus your total remedial costs is really the metric you want to look at, however, not strictly the cost of creating secure code.

Show Me the Money

One company I know of, an organization that specializes in electronic hand-held devices, was very driven by time-to-market. Since their products have a short life span they want to get to market as soon as possible but their CEO had recently gone public with a “commitment to security pledge” that helped boost their sagging stock price temporarily.

In order to maintain the share price and honor the commitment to security, they needed to create a time-to-market versus loss-of-market comparative analysis where they went through the scenarios of their next-gen hand-held device being released at a given date.

They knew that every day shaved off their anticipated time-to-release schedule meant approximately an additional $1,000,000 in profits to the business unit. But they had not considered the actual and realized costs if the product had a lot of security vulnerabilities that were discovered after release.

Once they did that risk analysis, they realized they would have very high remediation and patch costs, in fact, these costs dwarfed the million dollars/day savings they hoped to gain by shaving time off their product development lifecycle.

For the next release, they integrated security into their SDLC after sending one third of their developers through training. The result was that it added just six days to their release cycle (a “loss” of $6,000,000), but they had 14 fewer high-severity security defects (a savings estimated at $98,000,000 based on their historical costs.) And the $98M number ignored any impact to stock price.

In the following release of their product, they were only +1 in their time-to-market estimates and once again experienced a drop in number of security defects reports. An interesting side bar is their developers were coding about 20% fewer security defects per release, but their development and test teams were finding 85% more defect pre-release. That is a fix-find rate any team would be happy with.

Second Verse Same as the First

Security is just another aspect of software quality. Applying the same concepts and disciplines as designing for reliability and performance will work here too. You will suffer a short-term investment for a long-term gain.

Your customers are demanding secure products, so why not embrace this non-negotiable business driver as a necessary activity? Run the numbers for yourself and determine your total cost and the risks associated with introducing new activities into your development process.

So, what is a good balance between overwhelming your team with an entirely new security process and introducing new activities to help you minimize the impact of security defects in your software? An effective development process assumes that code will be attacked and embeds some kind of assessment at each phase as a health check.

Here are some keys to getting traction in your organization:

  • Keep the changes lightweight: Enhanced security practices need balance between impact to development time as well as actual investments made.
  • Promote awareness by educating key individuals in your development process. They need to understand the importance of security and what the fundamental goals of the increased security efforts are to your business.
  • Remember that security is about mitigating risks at a given cost. Get senior management buy-in for security programs by demonstrating how the new activities are mitigating business risk.
  • Build in checkpoints at each phase to ensure key activities are performed, i.e., define minimum criteria that must be met before the application “passes” that phase.
  • There is no short-cut to building more secure software, but there is a way to view the cost and risk of insecure software that helps you justify additional time and dollar investment.

    Specifically, look at security activities that track and identify risks, activities like code reviews, threat modeling, and secure requirements analysis. These present ways to view tangible and “predictable” consequences of insecure software and identify “hidden costs” that often escape notice.

    Security is very difficult (and too risky) to bolt in after the fact. (See misconception number one in this series: Over Relying on Network Defenses .) Many companies maintain the philosophy that to have secure applications they need a separate security team or they need to redefine their entire SDLC. Neither is true. Start light, but before you start at all, run the risk numbers and determine for yourself how important secure software is to your organization.

    In the coming weeks look for more expanded articles from Ed Adams covering each of these themes: Over-relying on Network Defenses, Believing the Hype of Technology/Tools, Too Many People Assumptions, Assuming Secure Software is Costly, and Falling into the “Recency” Trap.

    Ed Adams is CEO of Security Innovation, an independent provider of application security services that include security testing and training.