Introduction to Scope Part 2

Video Activity
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
Video Transcription
Oh, right, everybody, welcome to another penetration. Testing, execution Standard discussion today where you're in part two of Introduction to Scope
Now to pick up where we left off. We're going to finish by going through. How do we approach scoping with internal customers versus external customers and doing a review of a scoping case study? So with that, let's go ahead and pick up where we left off.
You are, You know, one of the lucky members of a security team who gets to do penetration testing.
You are likely to be aware of business processes. You are likely to be aware of system functions likely to be aware of management temperament for downtime and testing, and likely to be aware of various goals and objectives of different departments.
So that is kind of the prose of being attached to an internal team that does testing for one entity.
But you're likely to be more relaxed in scoping. You're likely to be biased in some cases, and you're likely not to properly document approvals. I can't tell you how many times I've run into instances where someone will send me a request and say, Hey, police can system X Y Z and see if there's anything we should be concerned off.
Okay, that's very open ended. And that system may not be the responsibility of my direct manager. They may not have the ability to speak on behalf of the business owner to do the testing, so we should approach
internal scoping and testing the same way that we approach external scoping and testing. We have rules of engagement. We have well defined scopes for in scope and out of scope items, and we communicate with the client in this case, the asset owner
when we're conducting testing and what it is that we're doing and get approval
to do that testing through written signature on a scope on project plan. If we don't do those things and something were to happen to a system that your manager does not have you no authority to test
or you do so on the behest of a sea level as a manager, and that sea level does not have direct
ownership of that system
and something happens, it rolls down the hill, as they say, and so you could be facing criminal charges. Termination at you know a za possibility. Administrative reprimands that could, you know, negatively impact your career with an organization your reputation. So
take internal customer scoping considerations. Justus, seriously, as you would external considerations as well.
Now the external customer scoping considerations are kind of the opposite of the internal. So you're not aware initially of why the testing needs to be done. Maybe nowhere. Business process is not aware of internal politics, and you may take the customers word on. Something is being in scope without seeking validation.
And that comes back to the example of a customer giving you our client giving you four I p addresses,
one of which they don't own or they can't test. Or maybe all four of them are for external systems. And, you know, they didn't give you the I. P address of a physical location that they own.
So with external customers, you need to be aware of what they're trying to achieve. You need to understand whether or not a party has authority to conduct testing on a system that they may not be the administrator. Our owner up.
My doing meets things. You can really cover yourself and protect yourself. If issues were to come up later, and it ensures that your scope is very thorough.
So let's touch on some case studies real quick and kind of wrap all of this up into a nice package as to why we want to focus so intense land scoping.
So we have a tester that conducted a port scan of a county system, which revealed significant vulnerabilities. His employer had engaged the counting in question, but out of embarrassment, the county reported the tester who was arrested.
And so this is a case where an entity was trying to merge with a larger entity
and upon conducting port scans and vulnerability scanning tests on the system, they want to merge
with the larger entity on
They were they were shocked. They were embarrassed and they called the state agency, and this tester was in fact arrested and charged with computer crimes because the system in question was providing a kind of a critical service. Any
interruption of that service, even if it was that it was slowed down by a fraction of the speed for a few seconds,
is considered a crime.
So, you know, not knowing what the scope looked like and not understanding what the contracts looked like one could hope that, you know, by thoroughly documenting the scope of service, that the system was in scope, that the testing was authorized
having very specific signatures of the individuals that manage
and have ownership of that system. Hopefully that protected this particular tester in that case, and hopefully they have that documentation present.
the coal fire Iowa case is still a hot button topic, and it will likely shape the way we look at physical testing and scoping in the future. On this is still, you know, in the works, and I'm not going to speak too heavily on that. I don't want to be biased by any means. And,
of course, hindsight is 2027. We look it,
how something was conducted and what they said versus what someone else is saying. We could easily make an interpretation of that. So I always remember that, you know, hindsight is 2020.
So the contract interpretation has led to a lengthy and continued discussion on whether the testers had the ability to conduct physical testing in the manner in which it was conducted. And so there is some, he said. She said involved in this where a local agency that did not give
specific permission for the test
indicated that, you know, testing was conducted in a manner where tools and techniques were used that were out of scope.
But the larger agency that authorized the test, you know, kind of indicated that it was aware that the testing would be conducted. There were some questions on time limitations time ranges, tool used by passion of certain systems.
I don't want to get deeply into this because, you know, I don't want Thio really have an opinion on this other than it is a great case study
for why,
UM, involvement of the appropriate system owners appropriate representatives for a particular location or entity is present when these discussions air hand
and that all parties
who could make your life difficult are communicated with and aware that testing will take place. I can assure you that communicating with an official such as let's say, a chief of police about testing
one could make them
happy that you came to them and made them aware that the testing was going to take place, that you involved them in the discussion,
and that if something does come up there now aware and will not be may be as angry if something were to happen, especially if, you know, testing's conducted on a premise that a party is responsible for, and they're completely in the dark about that. One can imagine, especially in a political spectrum,
that individuals would be offended or hurt by this. Now
take into consideration that these case stays air based on US instances. S O. You know, you would definitely want to look for studies for your given country. You're given areas
and you know, laws and regulations differ from area to area. And none of this is by any means, legal advice. It's just a good example as to why we would want to be extremely thorough.
All right, So in summary today, we looked at how we approach scoping with internal versus external customers, and we did a review of some scoping case studies. So with that in mind, I want to thank you for your time today, and I look forward to seeing you again soon.
Up Next