Our seventh and last myth of software security 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 of the attention on them. However, those days are over.
Today it’s about securing the entire portfolio—the overall attack surface. No matter 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 due to the fact that 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.
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, and which type, of clothes 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 “H” bucket, 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 bucket. The problem is that no “M” or “L” assets are considered for controls. This is a dangerous scenario.
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.
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 show-stopper 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? Does risk 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.
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 assets means that a high-only strategy makes little sense.
Ultimately, both risk management failure conditions discussed here can be addressed by the same guiding principles:
The key that any organization must understand is that they need to cover their entire software portfolio—both the high-risk and the low-risk apps must be taken into consideration.
Check out the other six myths of software security: