CompTIA Pentest+ PT0-002 – Section 3: Scooping an Engagement Part 4

20. Assessment Types (OBJ 1.2)

There are many different types of penetration tests and assessments, including goals-based, objectives-based, compliance-based, premerger, supply chain and red team assessments. A goals-based assessment is designed with a specific goal in mind. In this case, the penetration tester may attempt to define as many unique ways as possible to achieve that specific goal, such as breaking into a facility to test its physical security. Now, for example, let’s say a tester might want to come in through the front door. They might use social engineering and piggyback or tailgated. They might jump over a fence or even pick a lock on the door. For a goals-based assessment, it really doesn’t matter how they go about doing it as long as they’re successful in trying to achieve that specific goal. In this example, gaining physical access to that facility. Next, we have objective-based assessments.

Now objective-based assessments are those where a tester seeks to ensure that the information remains secure. If this information is on a file server inside the facility, then there are many different ways to get that information. You break in using physical methods to steal the hard drive, you could hack into the server using a server-side exploit or you could even use a phishing attack to gain access to a system by having a user click on a malicious link. Again, it really doesn’t matter how we go about it, as long as we make sure that the objective of the assessment is clear. Ensuring that the information is safe from attack for as many size as possible.

For this reason, this type of testing is more similar to a real attack because the penetration tester can be creative and tried various methods for stealing that information. And really, they only have to be successful one time or one way to consider that they have met their objective. The third type of assessment is known as a compliance-based assessment. And this focuses on finding out if policies and regulations are being properly followed. This is one of the most common types of penetration tests that are conducted in our industry. For example, if an organization takes credit cards, they have to follow the rules for PCI DSS.

All the major credit card processors like Visa, Mastercard and American Express have all agreed to set up regulations and policies that require a regular scanning of a checklist of items if that organization is going to be allowed to process or store customer credit cards. In this type of penetration test, the objectives are clearly defined and the penetration tester can utilize a checklist to verify that everything is properly scanned and found to be secure. This checklist may include things like password policies, data isolation policies, limiting network storage access, key management, and so on.

The objectives are always clearly stated in this type of a test. Other examples of compliance-based assessments include GDPR, HIPAA, Sarbanes-Oxley and GLBA compliance audits. A premerger assessment is our fourth type of assessment. A premerger assessment is going to be conducted between two companies before they merge with each other during a period of time known as due diligence.

During this timeframe, each company is going to look at the other company’s financial records, personnel records, and often they’ll require a third-party penetration testing firm to assess the other company’s network. With their permission, of course, in order to determine if a merger and the interconnection of those two networks could weaken the overall cybersecurity posture of either company. Another type of penetration test is known as a supply chain assessment.

Now a supply chain assessment occurs when a company requires its suppliers to ensure that they’ve met a given level of cybersecurity requirements before you’ll do business with them. As a professional penetration tester, it’s always going to be important to be careful with this type of assessment and gain permission from both the organizations that are asking for the assessment and the one you’re assessing prior to conducting that assessment. As a third-party organization, that penetration testing company cannot simply start hacking an organization’s supplier to see if they’re secure.

Instead, you must get permission from the owner of the network, which in this case, would be the supplier. Even though the person who’s paying you, your client might be the other organization. If permission is granted, however, and it’s within the bounds of the contract and the statement of work, then the penetration tester should attempt to break into the supply chain because oftentimes the supply chain is the weakest link in a large enterprise for organization. For example, a major retailer, Target in the United States, actually suffered a major security breach of their network several years ago.

It sent out criminal threat actors going after Target’s networks directly though, they exploited a vulnerability at one of Target’s smaller suppliers, which was an air conditioned supply company. And their network security was much weaker but it was still interconnected into the more secure network owned by Target. Now, criminals are always going to seek the path of least resistance, and therefore it’s important to ensure a high cyber security posture for any organizational network you have and verify the trustworthiness and security of any of the supplier networks they’re going to interconnect into your organizational network.

The final type of engagement we have is called a red team assessment, which is the execution of a penetration test against the organizational network by its own internal penetration testers. These penetration testers are also known as the red team, and they’re going to be authorized to conduct security exercises that are on a production network, a virtualized environment or both. The red team are often considered the offensive side of the cybersecurity industry, while our blue team is considered the defensive side. If the red team is tasked with conducting the assessment in a virtualized environment, then the organization is also going to require their network defenders and cybersecurity analyst to connect into that environment and participate as the defenders for the engagement as the blue team.

Often, there’ll also be a white team to oversee this engagement, and they act as the referee and ensure the red team is playing fairly, as well as determining if the blue team is able to observe and stop the attacks that the red team is throwing. These engagements will serve as a form of war gaming that allows both the attackers and defenders to increase their own skill by conducting and observing real world attacks in an isolated virtual environment. Now once the type of assessment is chosen, the team will meet with the client organization stakeholders to determine which strategy they’re going to use during the engagement. Now there are three common strategies that we can use. There is unknown environment testing, partially known environment testing and known environment testing.

An unknown environment test refers to the assessment where the penetration tester has no prior knowledge of the target organization or their network. This simulates an outside attack from the perspective of an external hacker and focuses solely on what an external attacker could see, while completely ignoring an insider threat. This type of assessment does require more time and is therefore, usually going to be much more expensive than a partially known environment or unknown environment assessment.

In an unknown environment test, the penetration tester is going to need to spend a lot of time doing information gathering and vulnerability scanning in order to learn all about the network and how to best exploit its weaknesses. The biggest benefit of an unknown environment test is that the penetration tester conducts the entire engagement as if they were an actual threat actor by scanning for available network resources, identifying live hosts, scanning for open ports and fingerprinting running services before they actually exploit any of the assets, just like a real unauthorized attacker would.

Now a partially known environment test is the most common type of assessment. and it entails partial knowledge of the target organization and their information systems. For example, the organization may provide the penetration tester with their IP range to ensure they’re only probing their networks and not some other organizations that work by mistake. This type of test may also be used to simulate an insider threat who has minimal knowledge of the organization, like a regular employee would. For instance, the penetration tester may be asked to go on site, they’ll be given a username and password, and they’ll be able to conduct their assessment from the perspective of an authenticate standard employee user account. The assessor can then see what kind of data could be taken, what servers or subject to privilege escalation and other types of issues that are common to insider threats.

A partially known environment test allows the penetration tester to decrease the amount of time spent in the information gathering phase, and therefore, it allows them to spend more time identifying potential vulnerabilities and exploiting them. A potential known environment test is also commonly used to test web applications and APIs for different security vulnerabilities by giving the penetration tester some information about the application or API, such as its internal functionality and the basic inputs and outputs, but not the entire source code. Now the third type we have is called a known environment test.

And known environment test is an assessment in which the penetration tester is given all the details about the organization, the network, the systems and the underlying architecture. As part of the contract, the assessor might be given network diagrams, IP addresses, versions of operating systems and services that they use. We would also receive a full copy of the source code and associate documentation if we’re going to be doing a web application or API assessment. When conducting a known environment test, the penetration tester is able to spend more time probing for vulnerabilities and exploits without having to spend as much time in the information gathering phase, because all the details have already been provided in a truly transparent manner.

21. Validating the Scope (OBJ 1.2)

Once the rules of engagement have been agreed upon, the type of assessment and strategy chosen and the scope has been defined and identified, it’s now time to validate the scope of the engagement with the client. Validating the scope of the engagement involves confirming all of the requirements, the scope, and the details of the engagement before you gain final approval and permission to move into the next phase and conduct information gathering and vulnerability scanning. Your penetration testing team should always ensure that the target organization has a good set of system backups and recovery procedures as well. This way you can ensure that if something goes very wrong during the engagement, a partial or full recovery can be performed to restore operations.

During the validation of the scope, your team should also verify that they know who to contact within the client organization if something goes wrong. Something needs to be de-conflicted or if they discover an exceptionally high risk vulnerability. When you’re validating the scope of the engagement with the client, you should also review all of the key areas from the statement of work and the rules of engagement to ensure that there are no areas of confusion. This will include a thorough review of several items including the scope and the in scope target assets. What is excluded from the scope and what’s considered out of bounds. What strategy will be used such as an unknown, partially known or known environment test. What the timeline will be for any testing, as well as any constraints placed upon your working hours. Any restrictions or applicable laws that will apply to this engagement as well as any third party service providers, services or offsite locations that are being considered.

And finally, the proper communication channels to use during the assessment in order to provide updates to key stakeholders. Now, once we have our discussion with the organization, we’re going to find that certain applications, systems, networks and even users may be placed on the allowed or excluded target list for the engagement. Now, an allowed list contains a list of authorized targets while an excluded list contains a list of unauthorized targets that we can’t go after during our engagement. Many organizations have numerous boundary defenses such as unified threat management systems, fire walls and intrusion prevention systems that could block your access from the internet when you’re conducting a penetration test. These systems are most commonly used to allow or prevent outsiders from accessing the network and operate by listing the IP addresses or ports in the access control list as either permitted, allowed or denied.

Now, depending on the scope of your assessment, your target organization may allow your penetration testing system to be placed into an allow list to bypass some or all of these boundary defenses. For example, if the organization wants you to conduct an internal assessment, they might allow you to have a VPN connection directly into their network by placing you into an allow list in order to simulate what an insider threat or authorized user might be able to accomplish during an attack. On the other hand, the organization may be more interested in seeing if you’re able to bypass their external firewalls and their intrusion prevention systems during an external assessment. In this case, they’re not going to add our systems to them allow list or allow us to bypass them directly and instead, they’ll make us work for it. Another concern is that if the organization’s network defenders catch your penetration testing team during your assessment, they could add your systems to their block list and effectively block us from directly accessing their systems anymore.

This could require to find a new way to bypass their boundary defenses in order to break into that network. Now, if time is running out during your assessment, you may need to talk with a trusted agent within the organization to have them unblock your systems or even add you to the allow list within the boundary device so that you can continue to meet the other objectives of the penetration test if those boundary devices are becoming too diff to bypass or exploit. This should be accounted for during your planning for the engagement by thinking about possible security exceptions that you may need to ask for as a contingency. Many organizations have a lot of different security devices on their networks including intrusion prevention systems, web application firewalls, network access control systems, certificate pinning and company policies. Depending on which policies and systems are being utilized, the penetration tester may need to ask for an exception to be allowed into one of those systems to be able to conduct their penetration test and be able to connect fully to that network.

For example, maybe the penetration tester was hired to test the application behind the web application firewall and not the firewall itself. In this case, adding an exception to the web application firewall to allow them to bypass it would become a reasonable request. Finally, you need to realize that some networks as part of their network access control or NAC do require a digital certificate to be installed on the network device prior to it being able to connect to the network, we call this certificate pinning. Now, if they do, you may need to ask the organization to provide you with an exception to their certificate pinning policy. In which case, the organization could provide you as the pen tester an authorized digital certificate for your workstation in order for you to connect to their network without tripping their NAC sensors. Again, it depends on what they’re trying to focus on during this engagement. If they’re not trying to test the NAC sensor, it’ll be okay to bypass it. Now as with a lot of things in the planning and scoping stages, there really is no right or wrong answer here, other than what you’ve negotiated and agreed upon between your penetration testing team and your client organization.

• Category: Uncategorized