Are You Doing Pentests Wrong?

Both vulnerability assessments and penetration tests are necessary to build Cyber Resilience in an enterprise, and you should include both as part of your security program. However, most organizations aren't receiving penetration tests that fill the need of simulating a cyber attack which actually tests the defenses in place and their overall security posture.

So many clients and cybersecurity outfits confuse the vulnerability scan, or vulnerability assessment, with a penetration test. This is made worse by unscrupulous outfits and poorly educated penetration testers passing off Nessus reports as penetration tests.

A vulnerability assessment determines what systems in your organization may suffer from vulnerabilities or misconfigurations which could lead to compromise. These assessments should be part of a Vulnerability Management program and scan systems from both an internal and external posture. These scans can be largely automated, with an analyst required to test for false positives and to generate a report that aligns with the risks unique to your business. A good vulnerability program would perform these assessments at least quarterly, preferably monthly, and present a list of required remediations for IT operations teams to implement with a goal of minimizing the time to patch systems as much as possible, limiting risk to the business.

A penetration test, or red-team exercise, on the other hand, is a simulated cyber attack that not only attempts to exploit found vulnerabilities but attempts to identify insecure business processes and lacking security controls throughout the enterprise - not just missing patches for web servers and installed software on workstations.

During penetration testing engagements I have discovered lax password storage, unencrypted backups, source code accessible on production servers, Local Admin password reuse, and a general lack of detective capabilities. These deficiencies in cyber resiliency don't show up on a vulnerability assessment.

The blame here doesn't fall just on penetration testers, however. Clients will often scope down a penetration test to such a limit that it no longer fulfills its intended purpose. If you want to identify what a determined hacker could do to your organization it is important to not limit the penetration tester. This includes all of the methods that an attacker could use such as phishing, social engineering, brute force and even physical access. Anything but Denial of Service should be in scope.

The process by which a sophisticated attacker conducts their campaigns is called the Attack Lifecycle. There are a few different models of the attack lifecycle but they all follow a basic process of phases: attackers perform reconnaissance of the external environment, compromise a system or systems, perform reconnaissance of your internal environment and compromise more systems, establish persistence and eventually complete their mission. It is important, then, that our penetration testing exercises also follow this pattern in order to better simulate an attack and determine where security controls are working and not working.

If your reason for a penetration test is to determine if you are vulnerable to hackers, and what attacks a dedicated hacker may be able to employ to breach your organization, then you need to ensure that your penetration tester works as a hacker does. Hire a penetration tester that knows the difference between a vulnerability assessment and a penetration test and scope the engagement accordingly.