Category Archives: Uncategorized

The Business Value of Security

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.

BI-Driven Development: Testing Outcomes Rather Than Outputs

In my book The Art of Business Value, I – almost jokingly – tossed out the term BI-driven development (BiDD). This was a play on the idea of Test Driven Development (TDD), where developers first write automated tests for their code, and only then write the code itself. We use BI, or Business Intelligence systems, to report on business metrics. My proposal was that we first decide how to measure the results we want our new features or systems to achieve, build a way of measuring those results – probably in the company’s BI system, and then start developing those new features. Since the book came out, a number of people have expressed interest in the idea, so I wanted to explain a little further what I have in mind and why it is important to our practice.

Historically, IT projects have been based on a set of requirements – essentially instructions on what should be built. With the introduction of Agile development approaches, we began to view these requirements as things that could be juggled, added to, or subtracted from. But this misses the real point of the Agile approach. The Agile idea is to deliver business value – outcomes – rather than particular features. In a sense, the requirements are not just flexible, but almost irrelevant. Any set of requirements that generates the desired business outcomes (at a high level of quality and a low cost) is just as good as any other set of requirements. Autonomous teams are truly autonomous when we charge them with delivering outcomes, rather than charging them with delivering a particular set of user stories or requirements.

In many formulations of Agile, teams are charged with delivering product that meets the needs established by users and a product owner – that is, they are charged with delivering outputs. But with DevOps – where the team is responsible for a much broader subset of the value stream – and takes feedback from their code’s performance in production to improve the product – we can give them responsibility instead for outcomes. Test-driven development measures outputs – does the code I wrote do what I was told it needs to do? BiDD is intended to measure outcomes. The “requirement” that flows to the team is to improve a business metric; the test of whether the team has done so is created through a BI dashboard that measures that metric; and the team’s progress and success can be measured by watching that dashboard over time. Arguably, the so-called “requirements” don’t matter – the team determines its own requirements with the goal of achieving the business’s desired outcome. Now that is autonomy!