Software [In]security: Paying for Secure Software
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
By borrowing simple economic concepts from the domain of total cost of ownership, or TCO, software executives can create an important budgetary handle and use it to build more secure software.
TCO for software
The idea that software maintenance costs account for a majority of software's actual costs over time is not new. Dusty old texts in software engineering from as far back as 1979 claim that maintenance and evolution costs account for 67% of software costs [Zelkowitz 1979]1. More recent studies claim numbers upwards to 90%. Regardless of the actual number (which in theory you can compute for yourself given your own software pile and its history), we can use maintenance costs to drive security into software. (Actually, this move drives quality into software, but low quality software is almost always insecure software.)
Here's the problem we need to solve. When faced with a limited software budget for development, unenlightened managers often bemoan the idea of "adding security best practices" as something that will increase both the time it takes to build software and the amount of money that it costs. If you limit your consideration of development expenses to the range from requirements gathering to release, and forget to factor in maintenance and operations, software security is easy to paint into the corner as a non-starter. However, if you take a total cost of ownership approach, it's equally easy to justify the adoption of software security best practices, and there's an even more important benefit to boot.
Just for the sake of argument lets say a software project TCO is $1,000,000. In our virtual project example, maintenance costs account for 70% of software costs (or $700k). That pegs our naïve "development expenses" at $300k. Here's the rub. If we spend more in the "development" phase and develop secure software, the maintenance costs will go down. Or put a different way, secure software has lower TCO even though it has slightly higher development expenses. This set of dynamic equations has an optimal solution.
We know from Barry Boehm's work that fixing a software defect early in the lifecycle is around 1500 times less expensive than fixing it during maintenance, so the math begins to make great sense. And this says nothing of litigation, reputation, brand damage, regulatory, and other risks imposed on a business by insecure software (all important drivers in their own right).
A Management Trick: Let the Market Decide
So how can we compute how much security we should try to attain by adopting software security best practices? My very clever friend Phil Venables, Chief Information Risk Officer at a major financial institution, advocates the internal market deciding. The basic idea is to have software project managers estimate future maintenance costs associated with resolving security vulnerabilities in code over the full lifecycle, and trade this off with early investment in code and architecture assurance. Managers can argue either side of this tradeoff but will be held accountable — typically managers choose some additional upfront costs as being dramatically lower than the full cost of late remediation. Those who mis-judge their TCO are punished, and those who estimate properly are rewarded.
This move has a tendency to push security back into the "development expenses" factor in order to come up with a reasonable maintenance factor. Those managers who choose to focus all of their attention on minimizing only the development part of the TCO (often to the detriment of the maintenance part) have a tendency to create poor software faster (resulting in an exploding TCO); while those managers who understand the TCO equation properly can let the development expenses rise a little even as the TCO moves down.
Back to our simple example. What we end up with is a system that over time settles on the minimal TCO by dynamically adjusting the development costs in such a way that security is high enough to bring maintenance costs in-line. So what happens is the $300K number may grow as we add code review and architectural risk analysis, but the $700K number shrinks given that we have fewer bugs to erradicate down the line. As long as the TCO number continues to shrink, we're in the money.
Put simply, it's easy to justify building secure software if you manage according to the right numbers.
1[Zelkowitz 1979] Zelkowitz, M., Shaw, A. & Gannon, J. (1979). Principles of Software Engineering and Design, Prentice-Hall.
For more information on Security, visit the following InformIT resources:
Software Security Engineering: A Guide for Project Managers