This isn't some crazy-advanced post. This post, however, is about a fun situation that I usually have to explain to clients and fellow business partners when it comes to understanding their vulnerability scans/assessments.
What's in a number?####
Generally, vulnerability scanners will assign a value to a vulnerability it discovers; generally in the form of a number (1-low, 5-critical). Additionally, some products may represent a discovered vulnerability in readable text (low, medium, high, critical). This provides some context to how bad a vulnerability may be. Many companies will use these tool-assigned values as a focus point.
When determining remediation strategies, a company may choose to focus on remediating critical (5) or high (4) vulnerabilities before focusing on lower level issues discovered. This approach can really help your security program progress and make many 'quick wins' for you and your team. Unfortunately, focusing only on tool-supplied criticality may also be your Achilles heel.
Not Every Hacker Needs A Critical####
Perhaps this comes from me mostly being red team, however, when I view a vulnerability report, I look for juicy services and poor configurations; well before I even think of vulnerabilities that require major efforts or steps to exploit. For example, for some tools, Anonymous FTP or open NFS shares are a low to medium issue. These two systems can, however, introduce a monumental amount of risk onto your network.
Recently on a penetration test, I stumbled upon a few anonymous FTP servers. I did not immediately focus on those systems as I had just begun getting a general feel for the network and what was on it. After not finding a whole lot around the network, I decided to take a look the discovered FTP servers.
After taking a quick peek at the FTP server and going through a myriad of directories, it was found that the FTP server was storing large sets of PII. Though the system did not net credentials or access elsewhere, it led to an issue that actually effected the business; a win in my pen. testing book. I don't believe a pen. test is just about assigning criticality based on what a tool tells a tester, getting credentials, and gaining privileged access. I do, however, believe that a pen. test should include the tester evaluating business impact of issues discovered.
My FTP example is only one of many instances where I've leveraged low-rated vulnerabilities to reach my goal/objectives for an assessment. Talk to any pen. tester and ask them about how many times they've taken advantage of basic system misconfigurations or open services to achieve their goals/objectives; you might be surprised.
Sometimes the lower rated vulnerabilities are the windows into your network. I'm not saying that you should ignore high-rated vulnerabilities in preference for low-rated ones. You should, however, investigate your low-rated issues and determine what the actual business impact is of each rather than rely simply on what a tool says impacts your organization.