A short description and comparison
Vulnerability Scanning:
Also called a vulnerability assessment, vulnerability scans are typically an automated scan of a clients network and infrastructure with the goal of identifying as many potential vulnerabilities as possible. Various scanners exist, including commercial products such as Nessus from Tenable and Nexpose from Rapid7, and free, open-source products such as OpenVAS from Geeenbone. The scanners identify potential vulnerabilities by analyzing various markers, such as service headers, version numbers, and network traffic responses. Many vulnerability scanners have the options to conduct authenticated and unauthenticated scans for various services in order to perform more in depth scans. Due to the automated nature of vulnerability scanning, false positives can occur, as well as false negatives, however authenticated scans are generally considered more reliable since they can gather more detailed service information and have access to program files and binaries.
With all of the network traffic required to perform the checks, the scans can cause network congestion and disrupt normal network activity, and can negatively impact older devices, however this can be mitigated by throttling certain scan settings, performing scans outside of regular business hours, and removing old or unstable devices from the scope of the scans. Additionally, some providers such as Tenable offer agent based scanning which installs an agent to conduct the scans on each system and sends the results to be collected and displayed in a central dashboard. Since the scans take place locally on each system and sends only the results over the network, network disruption is unlikely to occur and it allows devices outside of a corporate network to be scanned, such as laptops or desktops used in a remote or hybrid work environment.
Vulnerability scans can be used to provide system administrators with vulnerabilities or misconfigurations that need to be checked or remediated, or provide the offensive team of a penetration test or red team engagement with a starting point of vulnerabilities or systems to target.
Penetration Testing:
Whereas vulnerability scans are typically automated, a penetration test entails a team of penetration testers or “hackers” manually attacking the network in a simulated cyberattack with the general goal of obtaining the highest level privileges possible, though the goal can vary and should be relevant to the company that contracted the penetration test. The testers are restricted by the scope of the test (a list of systems or subnets the testers are allowed to attack) and the rules of engagement (a list of actions the testers are allowed or disallowed to take). For instance, a group of Windows 2000 servers that are critical to the day-to-day function of a company may be listed as out of scope due to their instability, and any Denial-of-Service attacks may be disallowed according to the rules of engagement due to the business disruption they can cause.
Timelines for a penetration test can vary depending on the size of the network to be tested, but a week is typically a general starting point. During this period the testers will attempt to verify and exploit as many vulnerabilities as they can, conducting discovery and vulnerability scans if not previously conducted, analyzing traffic, targeting high value systems, and conducting post-exploitation activities. Since the general goal is to discover and confirm as many vulnerabilities as possible, the testers will move through the network fairly quickly and not focus on evading detection or network defenders, unless that has been identified by the client as one of the goals of the test. During this time period, testers will take notes and screenshots of vulnerabilities discovered and their impact for use in the report.
A penetration test can be conducted remotely or on-site. A remote test typically involves sending the client a secure jump box that the testing team can access remotely, usually in the form of a virtual machine but a physical device can also be setup and delivered to the client if they don’t have a virtual infrastructure in place. An on-site test, as the name suggests, involves the testers traveling to the physical location of the client and conducting the penetration test. On-site testing offers some benefits over remote testing, such as the ability to plug directly in to any open Ethernet ports and request access to any switches in use to test for the presence of port security, or to conduct WiFi testing. A inspection of physical security can also be conducted on-site, such as checking for locked doors to server rooms or locked server racks.
Red Team Engagement:
A red team engagement is sometimes conducted after a penetration test so the red team can use the findings from the penetration test as a starting point, and the client has the opportunity to remediate vulnerabilities discovered during the penetration test prior to the red team engagement. The engagement is designed to test the defensive team’s, capabilities to detect and respond to a real threat actor. Vulnerability scans and penetration tests are limited in that their goal is discover as many vulnerabilities as possible in a short amount of time, and so security concessions will often be made for the duration of the scans or test. For instance, the testing device might be whitelisted in the client’s Intrusion Detection or Prevention System for the duration of a penetration test as vulnerability scans have been known to set off hundreds of malicious activity notifications during scanning, or the device may be specially configured on the network so it can reach every device that needs to be scanned and tested when in reality network devices would be restricted only to the subnets to which they need access. Additionally, they are often focused only on technical attacks and do not include exploiting the human element through social engineering or exploiting physical mechanisms.
Malicious actors, on the other hand, are not limited by time and are only restricted by their own moral code. A red team engagement is designed to simulate this real world scenario as closely as possible, and so will typically have a timeline of 2–4 weeks though it can run longer if desired by the client. While the red team must still work within a scope and rules of engagement agreed upon by the client, the engagement will often include more elements than a typical penetration test, such as social engineering and physical penetration testing (if on-site). Additionally, the goals of the red team will typically be much more focused than that of a penetration test. The red team may be tasked with gaining access to specific information or databases, compromising specific machines, or interrupting business functionality as a few examples, all with the overarching goal of evading the network defenders. The ultimate goal of a red team engagement is not just to pwn the network, but to evaluate the effectiveness of the security systems in place and the network defender’s ability to detect, triage, and effectively respond to a security incident.
