In the field, I hear a lot of questions on vulnerability management. The questions I hear most often are “How do I know what to fix first?” and “That’s a false positive!” Okay, so the second one is more of a statement; a statement that aggravates information security analysts and management alike.
In this post, I’m going to talk a bit about these two questions and then I want to hear from you. Tell me what types of questions you hear about vulnerability management and how you address them.
I hope I get enough feedback to spur a follow up post… Here we go!
How do I know what to fix first?
There are many ways various vendors classify their vulnerabilities and prioritize their patches. Some of our favorites release patch updates once a month on a regular cycle and say to start with some and finish with others.
Criticals, Highs, Mediums, Lows, 1-10, etc. There are many various ways of scoring. Most people I’ve talked to will start with their Criticals or Highs or 10s – depending on what system they are using – and export it to a spread sheet.
Next, they will take in various feeds to determine what the criticality of those already marked critical vulnerabilities are. This is done through assessing what privilege the attacker will get upon successful exploitation and how easy is it for an attacker to exploit that vulnerability.
This process yields a prioritization matrix of some sort, which the analyst will then pick the top ones to send to their system administrator to go and remediate. Give or take on the minor details, this is a very common, yet time consuming practice.
The matrix often yields a result similar to this:
That’s a False Positive!
This one is a bit trickier. Is it a false positive, is it potentially vulnerable, or is it something that we actually need to fix?
There are different vulnerability scanning methodologies out there. Each vulnerability is generally tied to a specific, file version, registry key, service, etc. or a combination of one or more. If you are actually checking for those particular vulnerable versions, then you know whether you have a vulnerability or not.
On the other hand, if you’re working backwards and checking for the absence of remediation, you could end up in a less accurate situation. For example: Vulnerabilities 1, 2, 3, 4, and 5 all have individual patches but also have Patch A that remediates them all.
Method 1 – Vulnerability Scanning Methodology:
- I ran a vulnerability scan and found that I was vulnerable to vulnerabilities 2 and 4
- I can remediate both vulnerabilities with Patch A or the individual patches for each of those two vulnerabilities
Method 2 – Patch Detection Methodology:
- I ran a vulnerability scan that uses the missing patches methodology and found that I am missing Patch A therefore it says I am vulnerable or potentially vulnerable to vulnerabilities 1, 2, 3, 4, and 5
- I’ve already patched 1, 3, and 5 individually, so this type of detection yields in a high level of false positives or potentially vulnerable instances that I need to go and investigate.
Personally, I think method one is the smarter way to go. It is more accurate and saves a lot of time investigating potential false positives
As this is my first post, I look forward to your comments and discussion. Let me know what types of questions you have, how you answer them (if you do), and look for a part two that talks about those!
- Six Tips to Improve Your Router’s Security
- Vulnerability Counts, Remediation and Risk
- Is Your Compiler Undermining Your Secure Coding?
- Top Five Hacker Tools Every CISO Should Understand
The Executive’s Guide to the Top 20 Critical Security Controls
Tripwire has compiled an e-book, titled The Executive’s Guide to the Top 20 Critical Security Controls: Key Takeaways and Improvement Opportunities, which is available for download [registration form required].