Vulnerability management and triage in 3 steps

Security testing tools can help organizations build better software by identifying vulnerabilities early in the SDLC. For security professionals and developers, however, the hard work begins when the testing is complete. Once you have a list of vulnerabilities across multiple applications, what's your next step in vulnerability management and triage? And how do you ensure that you maximize your remediation efforts?

The first step in vulnerability management is performing triage. Those of you old enough to remember the TV show (and movie) M*A*S*H will recall that the doctors and nurses at the field hospital would “triage” wounded soldiers as they arrived, prioritizing the most critical cases, delaying treatment for minor cases and for those too badly injured to save.

Security teams act the same way. To do so efficiently and appropriately, you need context around the applications affected, the criticality of the vulnerabilities, and the impact each type of vulnerability may have.

Step 1 - Understand your applications

We sometimes see companies that want to scan all of their applications in the first month or so of using Black Duck. While we understand their concerns around license and security risk, we also think there is a more logical approach.

From a business risk perspective, not all applications are equal. The first step organizations should take is to rank their applications by the potential risk associated with a successful attack. In other words, what are the consequences of a breach of each application, and which consequences have the largest downside. All of this should be viewed through a lens of business goals — not perfect security.

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

Step 2 - Consider vulnerability criticality

The second step involves looking at the specific vulnerabilities. As you work through your vulnerability management process, your triage team needs to rank order these across all of your applications. A good starting point is to classify the vulnerabilities by severity and exploitability.

For those listed by most sources, a Common Vulnerability Scoring System, or CVSS score is calculated for each vulnerability, using a scale of 1–10. In addition, information is provided for the vulnerability’s impact on application Confidentiality, Integrity, and Availability. The CVSS score also includes information about how difficult it would be for an attacker to exploit this vulnerability. In the graphic you can see a vulnerability with a base score of 10 — the highest score possible. It reaches this score not only by virtue of the type of vulnerability, but by how difficult it is for an attacker to exploit the vulnerability. In this case, we see:

• The vulnerability access vector is the network. In other words, the attacker can be anywhere and doesn’t require access to the local device.
• The complexity of the vulnerability is low — so less-skilled attackers can take advantage of it.
• Authentication is not required, again enlarging the number of potential adversaries.

In addition, you need to determine if an exploit is publicly available. Why does it matter when there is a public exploit? The obvious reason is that when an exploit is publicly available, it greatly increases the number of adversaries you might face. Publicly available exploits can be used by attackers with lesser skills, and can be used indiscriminately in non-targeted attacks.

Step 3 - Not all attacks are equally important

The final part of triage is understanding the types of vulnerabilities that should worry you most. Different types of vulnerabilities present different types of risks. If an exploit isn’t available, that certainly lowers the risk. However, just as each application poses different risks, the types of vulnerabilities that should worry you most differ per application as well.

Some may enable attackers to execute denial of service attacks, some may result in escalated privileges, while others could allow the attacker to read or modify data. These are referred to as the “technical impacts” of a vulnerability, and are important from a security standpoint.

For instance, if your business involves a social media application, maintaining uptime, or availability of the application may be critical. A distributed denial of service (DDoS) attack will affect revenue by limiting advertising exposures, and frustrate users who can’t publish updates to their social media profile. In this type of application, high technical impact vulnerabilities for reduced availability have a higher priority over others. Conversely, if you have an online banking application, you would much rather have the application be unavailable than have an attack that might allow the hacker to execute code, or read or modify data.

You can determine the technical impact from a vulnerability by checking the CWE, or Common Weakness Enumerator for a particular vulnerability. Each CVE can be mapped to a software weakness, and each weakness can in turn be mapped to various technical impacts. This type of information helps you improve your vulnerability management process immeasurably.