As I mentioned in my previous post, there is much confusion in the cybersecurity market around vulnerability scans and penetration tests. The words are not interchangeable. They are very different in the complexity and depth of vulnerabilities that they test, in the talent required to execute them, and in the report that will ultimately be delivered.
A vulnerability scan takes an immediate and broad look at the potential vulnerabilities across the organization. This is accomplished using an automated scanning tool, operating from a list of publicly-known vulnerabilities and a list of network addresses that are to be targeted. In contrast, penetration tests simulate the activities of a real advanced threat group to identify and intensively test a set of vulnerabilities in an organization that can lead to a compromise. This might sound like the same goal as a vulnerability assessment, but the difference lies in its complexity, level of verification, and depth of compromise.
Limitations of a Vulnerability Scans
While vulnerabilities in software and hardware can be a result of human error in the vendor’s development process, errors in the configuration and deployment of software by IT staff can introduce vulnerabilities. An automated scan for vulnerabilities will only find publicly-known weaknesses common across many organizations. Therefore, a mistake in the configuration and deployment that is specific to the target organization will usually be missed by a scan. In a penetration test, however, the adaptability and experience of human testers is more effective in finding issues that are specific to the target organization. This is the level of attention that a real threat group would use in a persistent and targeted attack.
Many automated tools simply perform the checks needed to determine if software and hardware on the organization network is potentially vulnerable to attack, without attempting to exploit those vulnerabilities. Limiting a test to checking the version numbers on the target systems can lead to false positives and false negatives in reports delivered to the organization. Mitigations put in place in the IT staff’s deployment of a product can lead to a vulnerable software product being well-protected, not vulnerable to attack, causing an automated scanning tool’s findings to report a false positive for the vulnerability of that product. These findings that are not verified can waste the time of IT staff tasked with remediation. False negatives are more insidious. The configuration of a vulnerable product also has the potential to “hide” the vulnerability from an automated tool, causing a tool to not report an exploitable vulnerability where one exists.
Combined Vulnerabilities Create Risks
Often, a serious breach is the result of several vulnerabilities combined that, if examined in isolation from each other, would otherwise seem to be of low severity. An automated tool alone cannot move into and between systems in the same way as a skilled attacker. By intelligently combining the information and access given to an attacker by a combination of vulnerabilities, a human tester can gain a depth of access to the organization that more closely represents what an advanced attacker would be able to accomplish.
Minimize Risks to Safeguard the Organization
Vulnerability scans can certainly play a role in an organization’s cybersecurity program. They are a lower cost tool to provide a baseline assessment of an organization’s protection against known threats. There are inherent limitations. Instead of depending upon a vulnerability scan’s static, robotic process that produces reams of reports with results that are not actionable, I recommend to my clients that they regularly test the strength of their system security in a more comprehensive way. Penetration tests are more effective at ensuring the confidentiality, availability and integrity of the business.
Next week, Part 3 will address how your organization’s Internet of Things raises your risk of a security breach.
For weekly insights into cybersecurity, please sign up here: