13 hours 9 minutes
Hello and welcome to another penetration. Testing execution Standard discussion.
Today we're going to go over introduction to Scope, which is a part of our pre engagement interactions. So let's start off with a quick disclaimer.
The Pee test videos do cover tools that could be used for system hacking. Any tools discussed are used during the demonstrations that we may provide should be researched and understood by the user. Please research your laws and regulations regarding the use of such tools in your given area.
While we're having fun and learning, we want to ensure that we don't get into any trouble with the law.
So let's jump into our objectives for this discussion.
So today we're going to work on how do we lay out a scope, and that's going to be particular toe what is in a scope. We're going to to define what will be tested, and we will not be tested by looking at how we would look at in scope out of scope items.
We're going to look at how we approach scoping with internal customers versus extra home customers
so essentially considerations for scoping,
and then we're going to review scoping case studies So essentially these air some issues that have come up in the recent decade that you know may not have been the fault of our are the fault of poor scoping. But we're not going to lay any of the feet of of these organizations today. We're simply going to
iterated some issues or instances where penetration testers, air security testers have gotten into some hot water.
So let's get started with what is a scope. The stump of a project specifically defines what is to be tested. And so I've got
three examples here, one of which is, you know, not well defined. The other two are kind of you know what we're using as escort.
So during the engagement, the following Web applications X, Y and Z will be tested for known vulnerabilities and security. Miss Configurations. Now, the first example I considered to have a lot of additional information and that we're testing or specifying that will be testing for known vulnerabilities and security. Miss Configurations.
Really, we could leave that part out and save it for the rules of engagement, which will touch on in another discussion.
But we want to specify which Web applications were testing, and the reason for that is is the second example. The test will be conducted against Web applications. Well, there's Web applications. Could be Office 365 The Web application could be, ah, custom SQL database that has a front and Web component.
There's no telling
with that second statement what the intention or in scope items, maybe. And so, by specifically naming the items within scope in the first component of the Web applications scope,
we better understand what it is that we should be looking at when we design in scope items.
The third example, the firewall for Office X and the following I P addresses 12 and three will be tested.
So that's important, because if we had just said that the following eyepiece and Office X will be tested,
okay, that is pretty easy. But are those eyepiece associated with some other piece of equipment other than a firewall? Don't know by saying the far wall for Office X were designating a piece of equipment at a confirmable location with
the three Given I P addresses will be tested, and so that's a very specific scope.
If we just said that Office X will be tested
and provided no further information. Are we talking social engineering? Are we getting into, you know, port scanning? Are we getting into trying to break into the physical location? Are we just assessing it?
We don't know. So we can at least start to build a, um,
set of procedures around how we're going to test the first and last statement. The middle statement would need to be better refined. And so what the good examples have in common is there specific,
and they don't leave any room for additional interpretation, at least not much.
So let's talk about in scope items. So in scope, items are the targets for testing that will be subject to the later defined rules of engagement. So the reason we don't do a long, drawn out scope statement
is because the rules of engagement will tell both parties exactly what is and is not allowed from a testing standpoint. So it's good to remember that clients, whether internal or external, are often not aware of what should be tested,
so the tester must be able to guide and assist the client and understanding what should be in scope.
Now. You may be rolling your eyes and going, Oh Lord, I don't really want to, you know, Is that really my responsibility? Shouldn't they already know? Well, you are the subject matter expert, and so
it's kind of your responsibility to God, your client,
in the process of understanding what would be in scope and that all will play into what we'll talk about later as faras determining goals and the rules of engagement.
But that initial scope statement should be something that you're able to help them with. So a great place to start is an asset list of critical assets for a given location. That way, you can kind of discuss through that list.
I talked to them about what those systems do better understand, maybe what it is they're trying to achieve or what they're wanting to do.
So, you know, listen for think keywords as you're going through the process like I really want to understand. If a hacker could get into my systems externally, I really want to know if my Web application is secure. I'm really wanting to understand if
email could be hacked or compromised, right? So you have to pay attention when you're when you're dealing with a party that you're going to be testing for, and then business owners or business leaders. Your responsibility should be understanding critical business processes, critical business systems
and being able to understand what you could live with and live without as faras risk,
and then being able to communicate that with 1/3 party who can then help you to answer the questions on how we go about testing those systems specifically
so that comes to out of scope items
so out of scope items would not be tested or would be emitted and would be omitted from the rules of engagement. It's important to understand risk tolerance for downtime. If a system could be scanned or impacted in a manner that would cost harm, it should be considered for removal from the scope.
Now you may be asking yourself, Well, that's not very, very authentic. It's not, really, you know, emulating an attacker or emulating a threat actor
right? But we know that those systems could be done harm. We know that those systems could be brought down if we would would cause a client harm or a loss of revenue
that doesn't bode well for us either way. And so it's considerate of us as testers to inform the client that the system can be removed from the scope and to understand what they could you know, could not live without during an engagement. And so we have a responsibility to understand
the the client
to understand the critical systems and to understand what could be busted.
So all out of scope items should be listed later in your report as out of scope. And the reason I say that is is this is not so much defined and the standard but what I have seen and what I've always done maybe it is a bit of paranoia in my reporting
is that I want to ensure that if 1/3 party for some validation purpose and for some reason, was given that report that there could not be an assumption
for out of scope items so and it's only applicable of the item was out of scope. But
if you did some external testing and the client said, Hey, please exclude I p X.
Okay, cool. So I include the other eye piece. I test the eyepiece that provide the report. There were no issues.
And then they deliver that report later. And, you know, just indicate that they had external testing done and everything was good and that party evaluates it.
And maybe that party does not ask for a list of I PS or something of that nature.
Well, we didn't test
maybe one of the four I p addresses because the client request it was out of scope. And maybe it has major issues, and it leads to a system compromised later.
That could be some cover for you as the, uh, you know, security tester
in that if a client maybe not for malicious intent or anything, but just not thinking just indicates that they were all good, it just provides some extra protection. Their items that could be included as out of scope could be service providers. And so clients cannot speak for service providers,
hosted applications, older equipment that we know could be sensitive, like an old old old printer that's, you know, specific for printing blueprints or doing something like that.
I know many times with banks, credit unions, places that have check printers, things that nature. When we've done internal scans, the checks. Print Web dings essentially or the printers print Web things all over checks, which is expensive,
Um, and it can cause issues. I've seen where printers will print Web dings. And so if you've got
industrial printers or something of that nature, where that ink and the paper is worth a lot of money and then used to help 40 pages of weddings in an afternoon of testing, that could be detrimental to that relationship. And it should be something that you consider,
especially when you're talking about internal scoping
and always remember that a client does not speak. And I want to reiterate this for service providers or providers of hosted applications, and we'll discuss that in later areas. But I wanted to leave. That here is a is a kind of precursor for those discussions.
Now, when you're looking at time considerations now we won't talk about starting in deep here. We're not going to get into heavy details,
but both is a business leader or a manager of penetration testers or or someone who's doing this. Scoping scanning external eyepiece for common vulnerabilities and testing them is not the same
as a Web application test, so some weather, and all women applications have eyepiece associated with them if they're externally facing.
a an external scan of an I P address and automated testing against known vulnerabilities is way different than Web application testing the skills that is different. The tools are different that time requirements are different,
so that has to be considered when scoping and looking at the environment. Essentially, what you plan to do and what that's going to take.
Internal testing should be scoped for specific and critical systems. And the reason I say that is is that if you go into an environment that is, let's say, the client says, I want five sub nets scanned
and those five sub nets are not the standard, you know, slash 24 254 dresses. Let's just say they're made up of 1000 apiece apiece
based on how they did this, some netting, and you do nothing further than put three sub nets are in scope
and you don't figure out what the Rangers are. You don't do any of that
and you go into test and you start scanning and they give you the Rangers and you realize you've got 3000 potential systems
in the network. And suddenly, you know, the scan's finished and you've got tens of thousands of vulnerabilities, and you've got, you know, 78 900 systems across three sub nets. How do you even start to meet expectations? How do you even start to approach that? You know, help you
if you know you didn't scope this appropriately, and now you have to make it work.
That is a very, very bad place for a firm to be in. So always take into consideration limiting the scope of internal testing and being very specific on what it is that your client, whether internal or external, is trying to achieve.
All right, everybody. So in summary, to part one of introduction to scope. We looked at what a scope is, and we looked at the ends and out of some items that have to do with the scope. So with that in mind, let's jump into port to and I thank you for your time today.