The Business Value of Security

Mark Schwartz, Board Member, DigitalTown

What is the business value of security? If a product owner is making decisions about how to prioritize user stories, features, or work items, how does he or she decide how to prioritize work items related to improving security? Perhaps this is the wrong question to be asking.
We must start with the question of how to compare the business value of a functional requirement to the business value a security requirement. Conversations about this topic in the agile world often make two critical assumptions: (1) that there is a decision-maker, say a product owner, uneducated in information security, who can weigh the two types of requirements and make prioritization decisions between them, and (2) that there is some measure of business value that allows him or her to make such decisions rationally - a “common currency” of business value, so to speak. Return on Investment (ROI) is often mentioned in this connection. So the traditional agile approach, as I interpret it, has the technical team explaining to the product owner what the ROI is of the security feature, and then the product owner making a good trade-off by comparing ROIs.
It doesn’t work well, and when it doesn’t, the technical team is blamed for not making clear what the ROI is (“they don’t think in business terms!”). But as I show in The Art of Business Value, there is no such common currency of business value, particularly not ROI. The product owner comparing user features to security tasks is comparing apples and oranges, and has a bias for apples. Business cases for security features - for all features, come to think of it - are hopelessly sensitive to assumptions about probability (exactly how probable is it that a bad guy will try a SQL injection on this particular web page?). For many business features, we can reduce uncertainty through experimentation. But for security features? Do you want to leave firewall ports open to find out how big a threat is out there?
No, the problem here is that security is not a feature. True, the company needs to make decisions about how much to invest in it and what exactly to invest in. But the decision needs to be made at a different level in the organization, I think, and in a different way. The company as a whole needs to have a risk management strategy, and to invest in it. And those risk decisions around information security will probably be made by a CISO or CIO.
Information security decisions are largely about the quality of the information product. A security vulnerability is a kind of defect. Security is about how we create our features, not about what features we create. The good news is that to the extent that “quality is free,” security is free as well. This, I think, is the crucial idea behind Rugged DevOps. We should commit to building and deploying rugged software, rugged networks, rugged infrastructure. It is how we do our jobs - simply a matter of professionalism. We can set up a testing regimen that finds security defects the way we find any other defects - automated tests, static code analysis, dynamic testing, penetration testing (the security equivalent of exploratory testing). More importantly, we can “shift left” and make sure developers know how to avoid vulnerabilities and do so.
It is part of their everyday job to avoid SQL injections and buffer overflows. It is part of being a professional software engineer.
The important thing is that security decisions cannot be made simply by having a product owner compare ROIs or any other business value metrics. Security itself is a value, and a way of judging the value of product. This value must be articulated and incentivized by the highest layers of management, in the context of a vision of overall risk management. The Art of Business Value, so to speak, is for leaders to establish and articulate values and direct the enterprise in achieving them.