Consider the Costs

My previous two posts covered two dysfunctions I see when people try to fix their security problems: ignore the low-severity issues, and try to fix massive high-severity issues and hit a wall. Not trying to fix a low should be the polar opposite of trying in vain to fix a high, but they share a common cause: they both ignore the cost of action.
Information security professionals have different methods for determining and describing the severity of a finding. When we use NIST 800-30, we eyeball a high/medium/low value based on our perception of impact and likelihood. When we use CVSS we think about the vulnerability in terms of exploitability and impact, dividing each into different factors to which we apply weights and modifiers. Adam Shostack has suggested that security professionals describe risk purely in terms of dollars. When we use severity in this way, we’re really trying to describe the benefit of remediation.
The process of remediation takes time. In most cases, money too. These are scarce resources. The science of deciding how to use scarce resources to achieve desirable ends is called Economics, and it has a tool we can use to help decide whether to remediate vulnerabilities: cost benefit analysis.
Simply put, the process for cost-benefit analysis is as follows: find out all the costs, find out all the benefits, and compare. If the cost is greater than the benefit, don’t do it. You can expound upon this as you like, accounting for stakeholders and externalities, comparing alternate projects by their cost-benefit ratios. But even bad CBA is better than none.
Enterprise IT is usually very good at cost-benefit analysis. If you have a PMO in your organization, ask them about it.
If you are responsible for the security of an organization, keep the costs in mind. If you are an assessor you can help by understanding your client’s business as best you can—especially their change processes—and look for cost effective solutions.