In the world of custom application development, it can be challenging to compare security safeguards and value-enhancing business functionality when prioritizing a backlog. Though the product owner and the scrum team often talk about risk, experience has shown that a lack of a common context and vocabulary can often make effective communication difficult. This is the first in a series of posts that will explore the “language of risk” in an effort to improve the communication surrounding backlog prioritization.
Application security comes down to managing risk relative to assets affiliated with an application; assets that our clients consider valuable. Example assets include:
- Business processes that our application may automate.
- Data or personal information that our application may store, transmit, or process.
- Assets that may be reachable from our application over a network.
When we talk about application risk, we are really talking about the risk to these assets. The higher the risk, the greater the need for security, and vice versa.
Assume we are developing a web-based patient portal for ACME Healthcare that allows patients to see test results, set appointments, review current and past bills, etc. Since the website handles patient information – or Protected Health Information (PHI) – it must comply with the Health Insurance Portability and Accountability Act (HIPAA).
Security professionals understand that Actors may carry out actions that can threaten ACME’s website and its PHI. In our scenario, let’s assume Actor A is a member of the internal operations team who, having no malicious intent, misconfigures the environment in which the website is hosted. This, unfortunately, opens the door to a denial-of-service attack that can lead to a temporary website outage. Fortunately, given the design of the website, it will not lead to the compromise of PHI. Conversely, assume Actor B is a criminal with malicious intent who is focused on performing a SQL injection attack designed to compromise PHI.
Safeguards, also called controls, are implemented by security professionals to reduce the likelihood that a threat action succeeds. If ACME trains its operations team annually on environment configuration, the likelihood of a mistake by Actor A is reduced. Conversely, if ACME chooses to avoid safeguards designed to thwart SQL injection, such as input validation and query parameterization, there is a high likelihood that Actor B will succeed, and ACME’s PHI will be compromised.
Digging Deeper Into Asset Risk
We determine the level of security needed for an application by assessing asset risk which is comprised of likelihood and magnitude.
- Likelihood – The likelihood, within a given timeframe, that a threat actor, finding an asset of significant value, will launch a threat action, defeat the safeguards put in place for protection, and compromise the asset.
- Magnitude – The size of business loss resulting from asset compromise.
To make these concepts concrete, let’s revisit ACME Healthcare and evaluate risk over the next 3 years.
Given our assumptions, the “risk of misconfiguration,” by Actor A, is small. First, there is low likelihood of compromise since the threat is restricted to the operations team which will be trained annually. Second, if the misconfiguration were to occur, the magnitude of business loss would also be low since the misconfiguration could quickly be detected and corrected, and since no PHI would be involved.
Over the next 3 years, however, the “risk of SQL injection,” by Actor B, is large. The likelihood that Actor B desires ACME’s PHI, is willing to launch a SQL injection attack, can defeat the lack of safeguards, and ultimately compromise PHI is high. Moreover, if PHI is compromised there is a good chance the magnitude of business loss will also be high because ACME must comply with HIPAA and can be subject to fines, patient notification costs, patient litigation, attorney and PR fees, and so on.
Security as a Business Discussion
Applications are built to increase profitability. They do this by providing competitive differentiation, by expanding or improving business competence, or by improving productivity.
Over time, however, reducers (such as the following) tend to pull profitability down.
Acquired Technical Debt
An application can build technical debt over time that must be addressed. For example, the technology used to build an application may not meet the expectations of future users. Older technology may be less secure than newer technology, may not be as efficient, or may be more costly to operate. Similarly, the inflexibility of an application’s architecture may mean that it is costly to evolve as business needs change.
Competitive Stagnation
To be profitable, an application must provide its users value. In a competitive marketplace, the bar for value is constantly rising. If a business does not improve an application’s value proposition over time, users will look elsewhere, and loss can result.
Shrinking Digital Trust
For applications that require user interaction, profitability is driven by “application use” which, in turn, is driven by “digital trust.” Users will not use an application if it offers a level of performance and reliability that leads to frustration, or an inadequate level of security that leads to mistrust. In many ways, digital trust is the digital equivalent to customer service.
Realized Risk
Applications face business risk that, if realized, can reduce profitability. For example, an unexpected security incident can lead to business loss. Unlike the other reducers which degrade profitability over time, realized risk often results in a burst of business loss followed by slow recovery due to a loss in digital trust.
To counter reducers, a product owner should invest in profitability enhancers. Defining threats and safeguards in terms of risk gives us a chance to discuss their impact alongside other enhancers. In the case of ACME Healthcare, we know there is high likelihood over the next 3 years that a SQL injection attack will be realized, and that the resulting magnitude of business loss will significantly and adversely impact profitability.
As with all enhancers, there will be an implementation cost. The challenge for the product owner is to invest in the enhancers that provide the greatest profitability impact, given their cost.
Conclusion
Application security comes down to managing risk relative to assets affiliated with an application. Expressing threats as risk make it possible for a product owner to reason about their impact on profitability, alongside other enhancers, and then make the best decision for the business to maximize profitability.
