We’re in the business of network-based security tools, so we bump in to this issue a lot with our customers. It usually goes something like this:
- Customer runs a routine vulnerability scan against their own network
- The scanning IP gets blocked by their Sentinel
- The Customer wonders why the scan didn’t work
- The Customer figures out what happened, and asks us to whitelist the scanner’s IP range, because we blocked their ‘pen test’
… And then we ask the question: ” … Ummm, wait, is this a Vulnerability Scan or a Penetration Test?”
It’s really common in our industry for folks to use those two terms Interchangeably, but when most people say ‘penetration test’, they really mean ‘vulnerability scan’. So, let’s define both of those terms, and spend a little time describing how the Sentinel deals with each one.
Typically run with a tool like OpenVAS (free and open-source) or Qualys (not-so-free), this scan will enumerate a network range, determine which IP addresses respond, and attempt to identify each device’s operating system, its open ports and services, and its vulnerabilities. This is by definition an automated process, and non-destructive. ( … Meaning it won’t disrupt or damage anything on network.) The resulting report is an inventory of the devices that live on the network, any weaknesses these devices may have, and how severe these weaknesses are. These scans are a great first step for determining the general state of your network and its attack surface, and they’re often required by compliance standards such as PCI, or recommended as best practices in frameworks like NIST or the 20 CIS Controls.
These types of scans usually trip several different types of events on a Sentinel that will get the scanning IP blocked. A couple quick, simple examples are scan alerts that look for specific open services like as ssh or rdp, or alerts specific to the scanning tool in use, based on common patterns unique to each flavor of scanning software.
An actual pen test implies that a human being is actively attempting to hack their way in to the target network. This is not an automated process based on a specific procedure. Rather, this is a dynamic cat-and-mouse game, where the pen tester is free to use (almost) any means necessary to find and exploit holes in the network and gain access to specific sensitive systems, identified in advance as ‘targets’. Of course, one of the first things a tester will most likely do is run some form of vulnerability scan, which, on a Sentinel-protected network, will the trip the alerts described above, and block all communication with the tester’s network. However, more sophisticated pen testers will avoid scans all together, or jump to another network and attempt more targeted and sophisticated techniques to avoid detection.
Depending on the target systems and their vulnerabilities, the Sentinel can still trip up the tester with alerts specific to targeted systems, such as inbound exploits, brute force attempts, or even malware C2 communications.
In our experience with both of these scenarios, our customers usually whitelist the IP ranges of the testers on the Sentinel, since a) the Sentinel usually blocks their initial probes of the network, and b) the goal of these tests is to find vulnerabilities on the network and remediate them, not necessarily to test the efficacy of the Sentinel itself.