3 things to consider when risk ranking your applications

Almost every security lead I speak to would love to have more security resources. Whether it’s people to conduct threat modeling, manual code reviews, or simply someone who can scrub the false positives from the blizzard of information they receive each day, everyone seems to be in need of an extra hand. Let's start by taking a look at risk ranking applications.

While more people can certainly help, most of us operate in organizations that have finite budgets. The trick in that environment is to make the most of your limited resources. That means applying them to the applications and vulnerabilities that matter most.

1. Not all applications are worth your attention

I previously wrote about risk ranking applications. I discussed how not every application warrants the same scrutiny, and how different security activities can be applied. Here is a shortcut; ask each of your business owners to name the top three or five applications they rely on for their success. The list may be shorter or longer, depending on the size of your organization.

Sometimes this is fairly straightforward. If an application is on the Department of Defense Unified Capabilities Approved Products List (UC-APL) maintaining its security is paramount, as unpatched vulnerabilities could result in losing certification. Likewise, applications that manage information subject to regulatory compliance, like PCI or HIPAA might be viewed as critical to a business’s goals.

On the other side of the coin, there may be internal applications that are not managing critical information, and from a business standpoint security is not critical. The main rule to remember is that not all applications warrant the same level of security scrutiny.

2. Map these applications to business goals

The point here is that security is not an end unto itself. It should always support business goals. This exercise is meant to ensure that the prioritized applications meet this requirement. Focus on how the applications affect revenue, customer information, regulatory standards, corporate IP, business reputation, or any other strategic goal.

Note: Some of these applications may be beyond your control from an application security standpoint. For example, your sales leads may focus on Salesforce.com. In this case, you may not have a direct ability to improve the security of the application, but you can put in other controls (such as 2-factor authentication) to mitigate some risks.

3. Define the worst case scenario

Just as all applications are not equally important, all potential attacks aren’t equally bad. You need more information about those applications to prioritize your actions.

We sometimes talk about threat modeling. At its most basic level, threat modeling is an exercise in “thinking like a hacker” to figure out what an attacker wants to accomplish (the desired “technical impact”) and how to do so (the “attack vector”).

The “technical impact” of an attack is a critical component to your risk ranking. Possible technical impacts include providing the attacker with the ability to read or modify data, conduct a denial of service attack, execute unauthorized code, and gain unauthorized privileges. Your goal is to figure out which is the “worst case scenario” for each of your critical applications so you can later prioritize individual vulnerabilities.

For example, if your business involves a social media application, maintaining uptime, or availability of the application may be critical. A denial of service attack affects revenue by limiting advertising exposures and frustrating users who can’t publish updates to their profile. In this case, vulnerabilities with a high technical impact for reduced availability are prioritized over others. Conversely, if you have an online banking application, you may de-emphasize vulnerabilities with a technical impact of reduced availability. It's much better for the application to be unavailable rather than allowing an attack that might allow the hacker to read or modify data.