A Common Sense Way to Make the Business Case for Software Assurance

Abstract

Listen

Translate article

This article demonstrates how a true cost/benefit for secure software can be derived using three generic practice areas: (1) threat/risk understanding, (2) implementation of security requirements, and (3) operational security testing. Having an accurate cost for these aspects of the software assurance process would allow decision makers to make intelligent decisions about the level of investment they wish to make. WHY WE NEED TO DISTINGUISH SOFTWARE DEVELOPMENT FROM SOFTWARE ASSURANCE The aim of this article is to demonstrate how a common valuation model can be used to make a dollars and cents business case for software assurance. However, in order to do that, it is first necessary to talk about why the elements of software assurance cost have to be differentiated from those of traditional software development. A precise delineation of the cost elements of secure software assurance is required because the total cost of anything is the sum of the costs of its parts. And unfortunately, there is no commonly agreed-on line of demarcation between the activities that constitute software assurance and those associated with producing a correct product. It should be apparent that the cost of producing the product should be different from the cost required to make sure that the product is secure. Yet when it comes time to assign the actual cost associated with each process, the distinction between product quality assurance and product security gets lost. Profit margins drive most business decisions. That is why it is so dangerous to over-inflate the price of secure software. Price inflation happens because businesses tend to confuse the costs required to ensure against exploitation with the much greater costs of producing a correct product. The fact that defects are a given in software does not change the ethical obligation of the maker to produce Antonio Drommi