PTES Questionnaires Part 1
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
Already have an account? Sign In »
13 hours 9 minutes
Hello and welcome to another penetration testing execution Standard discussion. Today we're going to be going over questionnaires within the pre engagement interaction section. So before we jump in, let's start off with a quick disclaimer.
Pee Test videos do cover tools that could be used for system hacking.
Any tools discussed or used during demonstrations should be researched and understood by the user. Please research your laws and regulations regarding the use of such tools. As always, while we're learning and having fun, we want to ensure that we don't get into any trouble with the law. So
before we jump into our subject matter, let's go ahead and briefly look at our objectives.
So we want to walk away and understand some of the benefits of questionnaires and why they're important. And then each of the following is a category of questionnaire that will review a few questions from these are all directly from the pee test standard, but they should be used as maybe a reference or a way to get your list started.
So by the end will have reviewed each of these question areas and gone over some reasons why the questions would be important So before we jump in, let's talk about questionnaire benefits. So this is a pretty slim list, but the benefits far exceed the few points that we have here. So the great thing about questionnaires
is as we were discussing about scope, we have to have a clear understanding of what it is the client
is hoping to achieve or gain from testing. Now we will do further discussions on things like goals. We talked about how to do scope, meetings and things of that nature. But questionnaires are one of the key areas that we can help ourselves to better understand what it is someone is trying to achieve.
It is also very important to understand why a client is looking for a test to be performed. We discussed earlier where looking to just check a box or to just be compliant with a standard may dictate some factors in the test. That may not be something that you would want to do.
So being able to ferret out what it is that the client is trying to achieve, or what you're wanting to achieve is a huge part of using these questionnaires
now. It's also important to understand what they want to do or not to do during the test. Again, we talked about assumptions. We can't make any assumptions when we're determining what would be in the best interest of the client or the person that's, you know, being tested.
And for that reason we have to help them to understand what it is we're going to be doing. And because of that, it allows us to provide a clear understanding for scoping purposes. And so by taking these questions and expanding upon them and really digging in
and getting a clear understanding of what the test should achieve and how it should look and what it will be against
will ensure that we'll design a scope
and provide an outcome that will be overall beneficial for the client as well as you know, not cause any issues for the organization that we're working with or for.
So let's go ahead and jump into the first questionnaire now. This is just a few of the questions from the network penetration testing area.
So the number one question that was there is why is the customer having the test performed? And it may seem self explanatory again. Why would you want to get them to maybe reiterate something they've already said? Well, it's good to hear wants twice three times
so that you can ensure that the response is consistent
and that you've recorded what it is that they're trying to achieve on paper. So this is almost, you know, a critical question for any questionnaire. And when we get in the weather application in some other areas, it would be prudent to do so as well.
Now again, we do want to understand if the test is for specific compliance requirement and the reason for that is is things like a P C I. D s s or n'est
any number of other areas. If they're wanting to do it against Ms requirements or PCR requirements, there are very specific things that we have to be aware of within that requirement. So that could dictate
the way that we would need to conduct the test, or it may alter the methodology that we would need to follow. So this is a key question to ask in any scope or in any engagement that you're looking to fill out now
total i p addresses being tested again. This could be an approximate at first, but it would need to be nailed down. This is going to be critical in determining kind of time estimates and overall, how the project will need to be tasked out.
This could be external eyepiece. This could be internal, I piece. It just depends on what type of network penetration testing we're doing. If we're doing a mix of both internal and external testing, then it would need to be the total number of internal and external separately listed for your notes. Now,
in the case that a system is penetrated or compromised, how should the team proceed now? There were some sub options or items to the question it included. Should you know the team attempt to gain privileged access should the team attempt to move laterally? Should the team attempt to do password cracking on the system,
Determining limitations is going to be critical for proper rules of engagement and proper scoping. If a system is compromised and then that's it, you don't do anything further.
That can also be an option. So helping the client to understand what it is that you can do once you get into a system is going to again be critical in building out rules of engagement and understanding what it is that you'll be doing there in the test, which ultimately
will dictate things like time estimate, labor estimate and whether or not
you have to have different subject matter experts involved in the test. Now
let's talk about some Web application testing questions. So
the first thing kind of like with I p addresses is we have to understand how many applications air being assessed. And this is important because that's going to dictate overall how much time it could take to go through the process. And then, if a page is being statically assessed, where we're reviewing information
piece by piece, we're doing Cem Cem Fuzzing may be looking at the back into that application
and doing some static inputs that's going to take a lot longer
in the process and the pages, because they're not getting re sources and information from other areas like a dynamic page may lo differently. It may acquire Resource is from different areas that can change the way in which the testing is performed in conducted, and so we ask about dynamic pages and static pages separately
because that is going to overall dictate how we're going to approach application testing.
And then again, we did hint at static analysis being performed.
That is a very manual process versus doing dynamic analysis. And so you've got static Web pages,
dynamic Web pages, those both load content differently.
Static analysis, dynamic analysis, static being kind of manual in the process dynamic, using maybe more tools and things of that nature too quickly test pages.
So all of those things have to be taken into consideration when we're doing Web application testing, and you would definitely want to use thes is maybe some core questions and then expand upon this based upon the type of testing that you do and that you offer with your organization.
Now, wireless penetration testing shouldn't be lumped into a network testing with respect to scoping it, because the tools, techniques and skill set do differ from network penetration, testing versus wireless penetration testing.
So, like every other question, and it is important to know how many networks air in place, we do want to identify the SS ID's for the networks. The reason for that is, is that if we have a co tenant environment.
And there's one wireless device, but four different SS ID's, and only two of those belong to
the client. Then we don't want to accidentally compromise or test
the devices, or I'm sorry, the SS ideas that would not be owned by the client.
It also is important to understand if a guest network is in use because that convict ate the approach if the guest network is open. So you know we're looking at authentication within the guest network or asking if it does or does not require it. That's going to be important in the other side. To that, to that, people make up. Not consider
is that if our customer or client
has other employees, or if they have business partners that come in if it is a guest wireless, that is for personal use for employees. What are the ramifications for us sniffing traffic on that
particular segment or that particular S s I D?
Could we potentially pull information that would be out of scope? Could we accidentally gain confidential information, health information, bank information for parties that have nothing to do with the test and may not even know what's going on.
So it's important
to understand how not just if a guest network is used, but how that guest network is used, what is on it and whether or not it would be within scope based on how that network is set up and what employees or clients or anyone is able to do on that. So take that into account
when you're scoping a wireless test and whether or not it would be high risk for, you know, potential
exposure of private information.
Oh, right, everybody. So today we discussed the benefits of questionnaires. We discuss questions for network penetration testing. We discuss questions for weather application testing, and we discussed questions for wireless network penetration testing. So with that in mind, I want to thank you for your time today, and I look forward to seeing you again soon.