Tips On Choosing Which Vulnerabilities to Test
May 25, 2010
By Jack Walsh

During April and May 2010, two interesting vulnerability-related developments occurred.  First, the National Institute of Standards and Technology (NIST) published the list of vulnerabilities that it cares about in terms of its USGv6 testing.  Second, a helpful new web site, "Useable" CVE Security Vulnerability Data, was launched.  This site correlates National Vulnerability Database (NVD) data, as well as links to other sources (such as Metasploit), facilitates quite useful vulnerability searches, and presents detailed views of NVD data. 

These announcements started me thinking about one of the distinguishing features of the ICSA Labs network IPS certification testing program.  In that testing program we regularly do our own research to determine which vulnerabilities to test.  In doing that we have learned some things that have helped streamline our processes and procedures, and it makes sense to pass on some of that knowledge to folks like yourself.

Based on our experience, below are five of the most important tips when it comes to choosing vulnerabilities.  Hopefully you will find them useful - whether you are regularly part of an organization’s red/tiger team trying to ferret out weaknesses in network systems, evaluating an IPS (or similar security device) for your organization, conducting penetration testing, or just interested in the kinds of things that ICSA Labs does as a test lab.

1)      Begin with high-severity vulnerabilities in your organization’s software.  NVD rates anything with a CVSS score of a 7 or higher as high severity.  If you want to add medium- and lower-severity vulnerabilities, come back to those later.

2)      Choose vulnerabilities that can be exploited without the benefit of access credentials.  There are a whole slew of vulnerabilities where an attacker first needs account credentials or other system privileges. Vulnerabilities that can only be exploited if the attacker possesses credentials on a system are less interesting, as the would-be bad guy already has permissions and access to the network without having to exploit anything.   

3)      Do some digging to make sure the vulnerability is likely to be exploited.  Even if the vulnerable software ranks somewhere between common and pervasive, the configuration in which it is vulnerable may be so uncommonly used to make testing for the vulnerability pointless.  You may have to dig a little harder to find information about the vulnerable configuration.  A tool like the Intellishield Alert Manager service helps ICSA Labs in this regard when we are determining our network IPS test set.  

4)      Check to see if the vulnerability description contains words like, “unspecified”, “insufficient details,” and the like.  After all, if there is not enough available information about the vulnerability, then attacking it is going to prove markedly more difficult -- if not impossible.  While finding such terms in the vulnerability description isn’t a fail safe, it should send up a red flag that you need to investigate further.  Once again, you’ll need to dig to find the right information. 

5)      Finally, find out whether there is publicly available exploit or proof-of-concept code with which an attacker could exploit the vulnerability.  It’s much more difficult and time consuming if you have to develop an attack from scratch. 

Bonus tip: Unlike the previous five, this tip does not apply in all circumstances where you are choosing vulnerabilities.  In this case it is especially useful when evaluating a network IPS. 

The tip is that you should carefully review remotely exploitable vulnerabilities that have met your other requirements, and then make sure a network IPS can actually block them.  Even if the vulnerability is high in severity and remotely exploitable, that does not mean a network IPS can—or even should—block them.  For example, there may be vulnerabilities that result from perfectly normal, legitimate traffic that when received just happen to wreak havoc on certain destination systems.  Another example might be a vulnerability in software that encrypts traffic before it goes on the network.  Most IPS devices do not perform the on-the-fly decryption required to prevent attacks against such a vulnerability.

Do you have tips that you want to share when it comes to choosing vulnerabilities?  What’s worked and not worked for you? 

Comments

Post new comment

  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>

More information about formatting options

CAPTCHA
This question is for testing whether you are a human visitor to prevent automated spam submissions.
Image CAPTCHA
Enter the characters shown in the image.