The standard approach to assessing network security is to hire a specialist company to carry out an independent penetration test. These have become essential exercises but come with some limitations, one of which is that they don’t test everything.
Penetration testers look for ways to compromise a network but, depending on the parameters of the test, they don’t necessarily spend time documenting every weakness, only the biggest and most obvious ones.
The reason for that is that finding every weakness is a huge job and new weaknesses quickly appear after any test. One option used by larger organizations is to move on to using red teaming exercises, a sophisticated ‘live fire’ penetration test carried out over a period of days, weeks, or months. A less onerous alternative is to complement a penetration test with a broader vulnerability assessment.
Every penetration test will include a basic vulnerability assessment as part of the service even though the former is designed to detect weaknesses while the latter seeks to exploit them.
This can lead the confusion about the difference between the two and when it is appropriate to carry out a more in-depth vulnerability assessment. The answer is that just as penetration tests can be conducted to varying degrees of depth so can vulnerability assessments.
Network vulnerability scans
The simplest definition of a vulnerability assessment is that it is an attempt to find common software and hardware misconfigurations, as well as unpatched, known vulnerabilities. Each assessment comprises a series of steps, starting with using an automated vulnerability scanner to take an inventory of the assets in an organization (servers, firewalls, endpoints), ranking the importance of each to its operation.
Once this has been completed, the next stage is to perform an internal and/or external scan that checks these systems for known vulnerabilities which can be either public software flaws or common misconfigurations.
This is usually focused on a specific element of an organization’s systems, for example servers, applications and databases, wireless networks and IoT and OT devices, network infrastructure, or external cloud systems.
This type of traditional assessment used to be seen as a type of sanity check that looks for obvious holes that might have been missed or overlooked by the inhouse security teams.
Increasingly, however, it’s become a way of gaining visibility on external assets such as cloud stores, the risk of which is easily underestimated because the misconfigurations are part of an external service. What an organization gets at the end of this is a report that ranks any issues found – open ports or unpatched applications, say – in terms of their exploitability, severity, and business impact.
Specialized dynamic application security testing (DAST) tools have emerged to help organizations find vulnerabilities in web infrastructure, including public-facing sites which can cause serious issues if not detected quickly.
As with network vulnerability scanners, these are automated tools or services that check code against a database of known misconfigurations and flaws. The famous OWASP Top 10 offers a guide to the most common weaknesses that afflict these applications: injection (SQL injection), broken authentication (weak login security), sensitive data exposure, XML parsing issues, broken access control, application security misconfigurations, Cross-site scripting (XSS), insecure deserialization, using components with known vulnerabilities (e.g., vulnerable software libraries), and Insufficient logging and monitoring.
Simply finding security weaknesses is not enough on its own; an organization must also develop processes for fixing, mitigating, or bypassing them as well. In numerous security incidents, an exploited vulnerability was either an avoidable error or could have been patched but wasn’t.
Avoiding this bad situation can be a complex process, which is why having an independent assessment of an organization’s patch management processes and policies is often invaluable.
At the same time, an alternative function of vulnerability assessments is that they are a way of validating an organization’s current patch management processes, monitoring the age and severity of the vulnerabilities that turn up from one report to another.
An important distinction between vulnerability scanning and penetration testing is frequency. Until recently, scanning was usually scheduled to happen at least once a quarter backed up by a more comprehensive penetration test twice a year.
In many cases, this is no longer often enough on either count with many organizations adopting continuous vulnerability management to keep ahead of new vulnerabilities. This can quickly turn into a complex workflow of scanning, assessing, and fixing flaws which is why automation is increasingly used to reduce the security team’s workload.
Inevitably, some vulnerabilities can’t be patched and must be managed. The obvious example of this are weaknesses in the design of legacy equipment and applications which must be kept running despite their insecure state.
Surprisingly, many organisations carry out vulnerability assessments only to discover older systems they weren’t aware of, or newer ones being used in an insecure way. Vulnerability assessment is often a journey into the unknown, but it is always better to get sight of these weaknesses before it’s too late.