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

14. Scoping an Engagement (OBJ 1.1, 1.2, and 1.3)

In this section of the course we’re going to cover the various considerations that you need to think of when scoping an engagement. Now, when we use the term scope in the world of penetration testing, we’re referring to the combined objectives and requirements needed to complete an engagement. From a business perspective, it’s important that both the client and the penetration tester knows what is and is not in the scope of a given engagement. For example, if I hire you to perform a penetration test of my website, we need to agree upfront what portions of the website you’re going to conduct your assessment against and what type of tools and techniques you’re going to be allowed to use against my website. For example, I might allow you to conduct an SQL ejection against my learning management system, but I’m not going to allow you to do a distributed denial of service attack against my servers.

Now, the reason isn’t that I’m afraid of you taking my servers offline, but instead it’s that we use an elastic cloud-based architecture. And if you start to run a DDoS attack against my servers they’re going to automatically spin up new compute instances to service all that new load. This would in turn really increase my cloud hosting cost for that month, and it really doesn’t give me any valuable information during the penetration test. So I’m going to make that off limits. Now, on the other hand, if I wanted to stress test our systems and see just how large of a DDoS attack we could withstand, then maybe we would agree to put that back into the scope of the assessment.

But for most penetration tests you’re simply not going to be allowed to do a DDoS attack because it could either harm the organization’s business or it’ll simply waste a lot of their time and resources. So in this section of the course, we’re really going to focus on scoping, which is part of Domain 1 Planning and Scoping. This section, we’re going to be covering parts of objectives 1.1, 1.2, and 1.3 that we didn’t cover in the last section. And this will also complete our coverage of all of the Domain 1 objectives that will be covered on your PenTest+ exam. This includes objective 1.1, which states that you must be able to compare and contrast governance, risk, and compliance concepts.

Objective 1.2 that states you must be able to explain the importance of scoping and organizational or customer requirements. And objective 1.3 that states given a scenario you must demonstrate unethical hacking mindset by maintaining professionalism and integrity. As we begin this section, we’re going to first talk about how you can define the scope of an engagement by working with your client to determine what will and won’t be covered during a penetration test. It is always important that you have defined and agreed to the proper scope before any technical portions of your penetration test have begun. Then we’re going to move into the types of devices, systems, and programs that may be added to your target list when you’re scoping your engagement. This includes things like wireless networks, IP ranges, domains, APIs, physical locations, internal targets, external targets, and target that are either first party hosted or third party hosted.

Next, we’re going to move into identifying the restrictions that may be placed upon you during an engagement. Things like geographic restrictions, the types of tools you can and cannot use, and the different laws that may affect your penetration tests. After that, we’re going to discuss the rules of engagement that you’re going to need to follow, along with the discussion of the different types of assessments that you and your client may agree to use during this engagement. We’re also going to discuss the methods that you can use to validate the scope of the engagement. Finally, we’re going to discuss the different limitations that could be placed on the penetration tester for this engagement and the necessity of gaining permission from the client before and during different parts of the engagement to avoid fees, fines, or possible criminal charges. So let’s continue our coverage of Domain 1 with scoping an engagement in this section of the course.

15. Defining the Scope (OBJ 1.2)

Once the basic planning has been conducted, it’s time for us to begin defining the scope of the upcoming engagement. Defining the scope starts broadly and then gets more detailed as we go throughout the scoping process. By properly scoping the engagement, everyone can understand what to expect during the assessment, what specific attributes will be included, and which will be excluded. This ensures a cost-effective penetration test as well because the team will have a clear idea of what they should be focusing on during the engagement. To do this, the engagement’s objectives need to first be well understood by both the client and the penetration tester as it’s going to help define the overall scope of the assessment. Once the objectives and goals are understood, then the penetration tester can work with the client to determine which networks, cloud services and applications are going to be considered in scope of the engagement. First, we have the organization’s networks to consider.

These days, networks are difficult to define because of the rise of de-perimeterization and the migration into the cloud. In the good old days, networks were much easier to define because most of the organization’s resources sat behind their edge routers and their firewalls. So you could easily draw a line in the sand and say, this is in scope and this is out of scope. Unfortunately, the rise of wireless local area networks, VPN connections, and the migration into the cloud has really blurred the lines for us as penetration testers. So it’s really important to take the time to discuss upfront with your client their exact architecture if you’re going to be conducting a known environment test, or at the very least, you should have some guidelines about what is and is not going to be part of the engagement if you’re doing an unknown environment test. Now, speaking of the migration to the cloud, you also need to determine if the company’s cloud assets are going to be considered in scope for the engagement as well. After all, just because you’ve migrated a server or service into the cloud doesn’t mean it’s automatically well protected. Instead, organizations are now asking penetration testers to test not only their local networks but also their cloud-based infrastructures and services to ensure they’re in compliance.

Cloud services are usually divided into categories, like Software as a Service, Infrastructure as a Service and Platform as a Service. Now under Software as a Service, the service provider is going to provide the client organization with a complete solution. This includes the hardware, the operating system and the software applications that are needed for the services to be delivered. For example, your target organization might be using Office 365 from Microsoft. This is a Software as a Service solution, and it allows the end users to access their email, Word documents and PowerPoint presentations directly within their web browsers. Sometimes though, an organization wants to build their entire infrastructure in the cloud. And for this, they’re going to use Infrastructure as a Service.

This allows them to get the hardware, the operating system and the backend server’s software all from the service provider, and they get the benefit of dynamic allocation of additional resources, known as elasticity, whenever they need without the headache of a long-term commitment or buying all that hardware and operating systems upfront. For example, an organization might contract for a new cloud-based web server to host their company’s website on. The server might be built and hosted by the cloud service provider and come pre-installed with something like Linux and an Apache web server.

Now their web developers and programmers can create a custom application for their customers and run it through this web server without having to worry about the underlying operating system and hardware. The final type of service we have is known as Platform as a Service. Under this model, the third-party cloud provider gives the organization the hardware and software that’s needed for a specific service to operate. For example, let’s say your organization wants to develop a new app for an iPhone, but they don’t own a Mac OSX system to be able to compile it. Well, they might lease a development platform provided by a third party, and that’s going to allow them to perform this service for them. This would be considered a Platform as a Service model.

Now, in summary, when you think about these models, remember that Infrastructure as a Service provides the organization with everything they need to run a given server, something like power, space, cooling, networking, firewalls, physical servers, and a virtualization layer. With Platform as a Service, the operating system and infrastructure is already added into that list, as well as all the things you got with Infrastructure as a Service. This might include things like an Apache web server, MySQL database, programming languages, or even some custom-built software to help you make things. Now, the third layer is Software as a Service, and this is a hosted application that’s added to the top of the infrastructure and platform portions. As you can see, Software as a Service is much closer to your end user than either Platform or Infrastructure as a Service. Now, if the organization is using Infrastructure as a Service, that means they’re also going to have a lot of virtual machines that are operating out in the cloud that you may need to consider as part of your engagement scope.

On the other hand, if they’re using something like Platform as a Service, then the target organization may have created their own web applications and associated application programming interfaces, known as an API, and those might be in scope. Now, an application programming interface is a type of software intermediary that allows two applications to talk to each other. For example, every time you use an app like Facebook, send an instant message, or check the weather on your smartphone, you’re actually using an API behind the scenes. For this reason, it’s really important to identify any web or mobile applications that may become part of this scope of your engagement. If your team is asked to conduct a penetration test against the company’s web or mobile application, you should clarify and define some basic guidelines up front. For example, can you ask the client to provide a discreet volume of the total number of web pages that you’re going to be expected to test or analyze, or maybe they’re going to give you a percentage. Let’s say you are hired by Facebook.

You would be unable to test their entire website for every possible page combination. So instead, they may state that you need to conduct an assessment on at least 1% of their total pages. If you’re conducting application testing, you should also ask for the various roles that are used by that application, and then ask what permission levels are assigned to each role. This will allow you to run the assessment against the application as a regular end user, a privileged user, or an administrative or root user to test the effects of what each type of user can do against that given application.

Personally, I find it best to gather information on which applications are going to be tested, what platforms they’re going to be used on and what specific scenarios the organization is worried about when you’re defining the scope for the engagement. For example, do they want us to test their web app, their Android app, or their iPhone app, or all three of those? This is important to understand because doing all three will drastically increase the scope of the assessment. The bottom line is that you need to properly identify what is hosted locally on the organization’s network, what’s being hosted in the cloud, and what’s being hosted or processed by a web or mobile application. Once you identify that, you can then work on defining a target list with that client to clearly dictate what assets are in scope and which ones are out of scope for your particular engagement.

• Category: Uncategorized