How to Perform a Vulnerability Assessment on Windows
No. I’m not talking about Microsoft’s ubiquitous operating system, but an actual window; the type you see in a building typically made of glass. In my previous installment, I discussed some of the basic issues which we face when differentiating between vulnerability assessments and penetration tests. A continuing source of confusion for our clients revolves around the difference between potential vulnerabilities and potential impact. The distinction remains a nuanced one and the confusion begins with two common and recurring phrases surrounding the definition of a vulnerability assessment.
As you may recall (from my previous post), vulnerability assessments continue to create confusion because clients, as well as vendors, conflate vulnerability scanners with penetration testing. The source of this confusion comes from a variation of the following statements:
- Vulnerability scanners scan a target system for vulnerabilities.
- Vulnerability scanners scan a target system for potential vulnerabilities.
Both descriptions are correct, but Bridges Consulting created a third alternative to the previous two definitions:
- Vulnerability scanners scan a target system for known vulnerabilities that could potentially impact the target’s web application or network environment.
Semantics, right? However, hear me out.
The first definition states that a vulnerability scanner scans for vulnerabilities, which suggests that the vulnerabilities a scanner discovers are real and pose a real threat to the system it scanned. In other words, if the scanner identifies a “CRITICAL” vulnerability on a system, then that means your web application or network environment is at high risk of attack from internal and/or external malicious actors. Such an assessment could prove risky when delivered to a client because 1) it gives the client a failing grade on a system (a slippery slope); and 2) it places an obligation to the third-party vendor who authored the vulnerability assessment to defend the legitimacy of such a stark claim, but more on that later.
The second definition states that a vulnerability scanner scans for “potential” vulnerabilities, which suggests that any vulnerabilities a scanner discovers may not be vulnerabilities at all. This view belies the fact that scanners (if they are programmed and configured correctly) search for specific signatures, configurations, or versions that are real – not theoretical. In fact, effective scanners take these characteristics from known vulnerabilities established by the community (such as the CVSS) and searches for them in a target environment. If the scanner finds a specific vulnerability, it’s because the discovered vulnerability is tied to a specific vulnerability that has already been researched and acknowledge by the community. In other words, those vulnerabilities are real and the scanner succeeded in identifying a real vulnerability on your system based on one or several characteristics.
The third definition reflects our perspective, taking a more nuanced and semantical approach to the problem by stating that a vulnerability scanner scans for known vulnerabilities that could potentially impact the target environment. The previous post illustrated this definition:
A vulnerability scan uses a variety of commercial or open-source (i.e., free) tools, called vulnerability scanners, to “scan” a target system for known vulnerabilities that could potentially impact the target’s web application or network environment.
This terminology serves as an alternative to the most common and recycled variations of the first two statements, but, ultimately begs the question, “If a scanner discovers a real vulnerability, how can it not directly and immediately impact my system?”
So, without further ado, here’s my analogy that uses a window as the target of the vulnerability assessment to answer how a vulnerability scanner can find a critical vulnerability (remember, a real one, not a potential one) and yet remain a low threat to your environment.
The Windows Analogy
Imagine a vulnerability scan on an office. The scan was executed remotely, meaning that the consultant was not physically at the site, or even, perhaps, in the same country, when they initiated the scan on the office. The office has windows, but, to be more specific, there’s a window to the office that happens to be the CEO’s office. That window, on the surface, looks like any regular window: it looks clear and is made of glass.
Now, the vulnerability scanner notices that the CEO’s office has a window because the office clearly says, “This is the office of the CEO” and the window, well…it’s a window. The scanner immediately recognizes that the window looks like any other window and looks to be made of translucent glass. The scanner then instantly annotates the finding and classifies it as a “CRITICAL” vulnerability because windows are fragile (easy to break) and are known to be an easy vector for criminals to exploit with simple tools, like a rock, to gain entry into an unauthorized space for looting.
However, there is one problem with this vulnerability: the finding lacks context. What context do we need, you ask? For one, the CEO’s office is on the ninth floor of a corporate building that shares its offices with other businesses, sometimes two or more on the same floor. Second, the window, although it looks clear, is actually a two-way window that is clear from the inside, but blurry from the outside. Third, the window is reinforced with shatter-proof material that makes it very difficult to break. Finally, the building has a robust security presence: 24/7 surveillance cameras for monitoring all sides of the building, a roaming patrol that walks through all the office spaces at regular intervals, and motion detectors that protect the CEO’s office from unauthorized intruders.
Can a malicious actor circumvent all of these security measures? Of course, but it would take a lot more sophistication to do so than a regular, street-level shop that only has the most minimal security mechanisms (low-lit neighborhood, no security cameras, easily breakable glass, etc.) to protect their assets. The office building I just described would take considerable sophistication, financial resources, motivation (meaning the actor would target the office for a specific reason), and the opportunity to pull off.
Putting It All Together
This scenario, although preposterous, demonstrates how a scanner correctly identifies real vulnerabilities, but cannot fully understand the severity of that vulnerability within the context of the target environment. That’s why a vulnerability assessment requires more than just a copy/paste effort from a third-party vendor. Our analysts don’t just take the results at face value, but place those vulnerabilities in context to provide a nuanced and actionable assessment of the target environment. Had this scenario been real, we would have noted the vulnerability and its criticality, but would have given the client a passing grade since they made every effort to mitigate that vulnerability with several security measures.
This scenario also serves as a reminder of why our penetration testing services are also very important since breaking into the CEO’s office, in this case, is near to impossible (although there are ways to do it, but I’ll keep those to myself). The point here is that vulnerability assessments are important (and mandatory, per HIPAA), but they need to be done by professionals who understand the vulnerabilities and how they work in a real-world environment. Conversely, these penetration tests help validate if the vulnerabilities found during a vulnerability scan are exploitable. Although penetration tests are not currently a mandatory requirement per HIPAA (unlike the assessments), we predict mandatory requirement for pentests by PCI standards (the standard for financial institutions) crossing over to healthcare in the imminent future.