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.
|
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.