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.
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, 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.