Software security myth #7: Only high-risk applications need to be secured
Q: Why can’t I just secure my high-risk applications? A: Any vulnerability in any application increases your attack surface. Risk management is essential.
Our seventh and last myth of software security best practices is about scale. Today’s application portfolios are often quite large—thousands of apps. Getting started back in the day meant identifying those apps that carried the most risk and focusing all the attention on them. However, those days are over.
Today it’s about securing the entire portfolio—the overall attack surface. Whether you’re working on a small project or a huge corporate application strategy, the key to reasonable risk management is to identify and keep track of risks over time as a software project unfolds.
Risk management is the mature way to think about information security because it’s a careful balance between security and business functionality. Too much security can ruin a good business proposition by bogging it down in a security swamp. Conversely, not enough security can lead to unacceptable levels of risk, which can threaten the business itself.
Like any executive, a CISO’s role is to make risk management decisions and then communicate those decisions to the executive team and the company. These decisions should be in alignment with the corporate culture, compliance and regulatory mandates, and the community standards of acceptable diligence. Not to mention that they must also be technically sound.
Unfortunately, risk management can fail, and when it does, it really fails! Let’s discuss failure conditions involved with risk management and how to avoid them in the future.
Failure 0: An exposed portfolio
Security controls are kind of like clothing for software, shielding it from the harsh elements. Imagine that you have a large portfolio of “naked” software assets to protect. As most of us do, you have a limited budget to spend on clothes. Thus, the risk management problem is one of determining how many clothes, and which type, to pair with your software assets.
One option is to divide the portfolio into categories of risk. Three simple and effective buckets are high, medium, and low. This division can be accomplished by first tagging the software assets with categories such as internet-facing, directly controls PII, handles money, life-threatening, schedules conference rooms, etc. Once the portfolio’s assets have been categorized, add them to one of the three buckets.
The question then becomes what to do about imposing security controls on each of the buckets. Let’s take testing as an example. In this case, controls can include things like architecture risk analysis, code review, dynamic analysis, and penetration testing. You decide to allocate scarce resources such that you apply all controls possible to the high-risk applications in the H bucket, you apply a handful to the M bucket, and you ignore the L bucket completely.
The types of risk management decisions made for these buckets make all the difference between risk management reasonableness and failure. In Figure 1, you’ll notice that only the H bucket assets have security controls imposed, and those are imposed linearly according to the perceived risk inside the high-risk bucket. The problem is that no M or L assets are considered for controls. This is a dangerous scenario.
Figure 1.
If most of your portfolio falls below the “do nothing” line (in Figure 1 this would be the x-axis), you have a problem. A simple way to resolve this is to implement a few easily applied security controls across the board into all software assets. In other words, none of your assets should be naked. At least give them minimal security controls—equivalent to security underwear.
From Figure 1, you’ll want to move forward by moving the security control minimum line “up,” and we want to flatten the curve by bending the low end up as well. That will result in something along the lines of Figure 2.
Figure 2.
Failure 1: How many medium risks make high-risk applications?
There is a bug severity problem in software. How many little bugs does it take to make a big bug? Sometimes, too many little bugs make code so sketchy, nobody wants to get near it. No individual bug is a showstopper by itself, but together they add up to create the perfect storm. And this problem is nothing new.
The problem of compounding influences security risk and risk management decisions. How many low- or medium-risk software assets can you stand? What’s the reasoning for classifying something as “medium” risk? Do risks compound, like bugs seem to? Can your portfolio be as sketchy as bug-infested code?
Consider your software asset risk curve. If your buckets are properly configured, your assets will likely fall into a standard distribution and end up resembling the bell curve in Figure 3. On the other hand, your bell curve may resemble Figure 4 if your categorization scheme isn’t optimal.
Figure 3.
Figure 4.
If the nature of risk for your organization is unique, the number of medium-risk assets calls for a uniform set of security controls to be put in place. Few high-risk applications means that a high-only strategy makes little sense.
Here’s the plan
Ultimately, both risk management failure conditions discussed here can be addressed by the same guiding principles:
- Leave no code naked.
- Tighten security controls between low- and high-risk applications to the extent possible without moving the high risks down the prioritization list.
- Create a specific testing schedule (even if it’s once every couple of years for internal low-risk applications).
The key that any organization must understand is that they need to cover their entire software portfolio—both low-risk and high-risk applications must be taken into consideration.
