- In this lesson, 27.2, we're gonna be talking
about penetration testing concepts.
And we're gonna follow this up with our next lesson, 27.3,
which is also gonna be about penetration testing.
Now, the objective of penetration testing is
to evaluate the security of a target by identifying.
And attempting to exploit vulnerabilities or weaknesses,
improper configurations, and hidden points of entry.
Now, very often penetration testing will be referred
to as ethical hacking.
Now, penetration testing
generally involves exploiting combinations
of vulnerabilities on one or more systems.
Now, the testing can originate from within
a target environment or external.
So, internal or external penetration testing.
In addition to identifying the vulnerabilities,
the improper configurations, and the hidden points
of entry penetration testing can also be
really useful for determining incident detection
and response capabilities.
Now, there are three primary testing approaches,
a known environment, a partially known environment,
and an unknown environment.
In the known environment, the testers,
now the testers could be internal folks
who are independent folks, external.
Really just, depending on what kind of test you're doing
and what your compliance requirements are.
But the testers have comprehensive knowledge
about the target system or the network.
And with this level of knowledge
the testing team can conduct really in-depth analysis,
targeted assessments, and explore potential attack vectors.
So a known environment.
We have a partially known environment.
Now, in a partially known environment,
the organization will provide restricted
or selected information to the testers.
Again, it could be internal or external testers.
This approach really simulates scenarios
where an attacker might gain partial information
through reconnaissance or social engineering.
So in a partially known environment,
perhaps they're given IP addresses,
perhaps they're even given a username.
And password to log in with the assumption
that maybe through reconnaissance
or social engineering our adversaries,
the attacker would be able to get that information.
So we work in the premise of what if they got
that information, what could they do?
Or what if this attack and initiated from inside,
from an insider who already had a name and password
and they were already on our system?
And then third is an unknown environment.
In an unknown environment, no information is provided
to the testers other than what the target is.
The testers need to discover vulnerabilities.
They'll need to conduct reconnaissance,
they'll need to identify those potential entry points.
And they'll perform their exploitation attempts
so they have no knowledge.
And really what we're trying to simulate here is
an attacker, an adversary who has no knowledge
of our organization, kind of what they would see.
What their process would be, what they would do.
Because in effect, penetration testing
really mimics what real world attackers would be doing.
Now, at the beginning of a penetration test
we're going to have an agreement known
as a ROE or rules of engagement.
This is similar to an audit plan.
Remember, at the beginning of the audit
we had an audit plan.
But when we have an engagement like this,
we're gonna call it an ROE, rules of engagement.
And that will detail the parameters
and the expected assessor or tester's conduct
of the penetration test.
Now, some components that you'd find in an ROE,
the scope of the test, any assumptions and limitations.
And a really important limitation is proof of concept
versus a compromise exploitation or a true attack.
So do we want to have them go just far enough to prove
that that exploit exists or that they could get in?
Or do you want them to really go through
and do it potentially causing exfiltration
of data or maybe a denial of service?
You're also going to determine logistics
such as who's involved, what personnel,
what the test schedule is.
Do you want it during regular operating hours
or do you want it during off hours?
What the test site is and any equipment.
We're gonna have a communications plan.
So who are we communicating
with throughout the whole test,
particularly if either something
very egregious is identified.
Or if there's been a problem with an exploit,
the testing expectations and the data handling requirements
as well as what the reporting's going to be.
Now, there are some legal considerations related
to penetration testing, including is it authorized?
Who is liable?
What's the indemnification?
What about non-disclosure and privacy?
So authorization is often required from third parties
that host assessment objects.
So let's say you want a penetration test on your website,
but your website is hosted by another party, a third party.
You're going to have to get their permission
to be able to test your website.
Or you wanna have a lease,
maybe upfront put in your contract
that you can go ahead and test your website.
But not doing so, just saying, "Okay, well,
my site is a third party site that I want you to test
and I haven't gotten permission from them."
That could be a violation of your contract.
Any potential privacy violation should be identified.
Non-disclosure contracts or agreements should protect
the disclosure of both the data collection,
so anything that got collected, as well as the findings.
And then contracts with external assessors
generally include a limitation of liability.
So who's liable for what?
And generally it'll be the assessor saying,
"Listen, we have no liability.
If we crash your system, we crash your system.
But we're working on a good faith effort."
And an indemnification clause.
An indemnification clause is financial payment
for causing some kind of problem.
Now, those should be in contracts
but they should be reviewed by legal counsel.
A subset of penetration testing is called
offensive and defensive penetration testing.
We used to refer to it as red team, blue team simulation.
In your exam though,
we refer to it as offensive/defensive penetration testing.
In offensive/defensive penetration testing,
it's designed to simulate an attack.
But what we're trying to do here is evaluate
our preventative, our deterrent controls,
our detection controls, and our response capabilities.
So we'll have a couple of teams.
We're going to have an offensive team
and the offensive testing team emulates
the behaviors and the techniques of likely attackers.
Then we're gonna have a defensive team,
which is the testing team that's tasked
with detective and defensive activities.
So we used to refer to them as a red team and a blue team.
Now they're the offensive team and the defensive team
and we may have an integrated team.
Now, the integrated penetration testing team
actively engages in monitoring, detection,
and response activities during the testing process.
With a focus on information sharing
and cooperation, really a feedback bridge.
These are really great type of tests.
It allows us to say, okay, for a particular scenario,
a DDoS attack, a ransomware attack,
a SQL injection type of attack, would we detect it?
And how would we respond?
And probably even before that,
do we have the right preventative and deterrent controls?
Do we have the right detective controls?
Can we respond quickly and appropriately?
If we need to call on our incident response plan,
can we do that as well?
So it really gives us a sense of how well prepared
an organization is to respond to specific types of attack.
But what I wanna stress is it is not, it is not,
it is not a substitute for doing a regular penetration test.
They're two very different things, even though they both
now have penetration test in their name.
Now, there's also what's known
as physical penetration testing,
which focuses on evaluating
the effectiveness of an organization's
physical security controls and measures.
The physical penetration testing aims
to assess the physical security measures in place
such as access control systems, locks, alarms,
surveillance systems, perimeter security,
as well as employee awareness.
Physical penetration testers simulate
the techniques and the tactics
that malicious actors might use to gain unauthorized access.
So for example, social engineering, tailgating,
which is following a authorized personnel
into a secured area, or lock picking, or badge cloning.
All right, that my friends brings us
to a three second challenge.
Five challenge questions, three seconds each.
Let's do it.
A term used to describe authorized penetration testing
for legitimate purposes.
One, two, three.
We call that ethical hacking.
Number two, document that details the testing parameters.
1, 2, 3.
That's gonna be a rules of engagement or an ROE.
Number three, a team that emulates the behaviors
and techniques of likely attackers.
1, 2, 3, it's gonna be the offensive team.
Number four, testing approach that provides no information
to the testers.
1, 2, 3, that is unknown environment.
And lastly, number five, the type of penetration testing
that might focus on surveillance systems,
perimeter security, and employee awareness.
1, 2, 3.
And that's physical penetration testing.
So that brings us to a security-in-action.
This one's about a penetration test.
AnyTown bank has hired Testers, Inc.
To conduct a penetration test that they don't intend
to provide any details or authorization.
They expect the scope to include
both external and onsite attempts.
So my question to you is, in the ROE,
the rules of engagement,
how should they describe this approach?
So a quick recap, we've got a bank.
They've hired Testers, Inc. to conduct the penetration test.
They do not intend, so do not intend
to provide any details or authorization.
And they expect the scope to include
both external and onsite attempts.
So how are we gonna describe this in the ROE?
Go ahead and put me on pause for a moment.
Think about it.
Come on back and we'll talk about the rules of engagement.
Well, since no details of the environment are provided,
the approach would be considered an unknown environment.
Now, the onsite component of the test would be known
as physical penetration testing and one would expect it
to include a social engineering component.
Now, the ROE should clearly detail expectations
and communication plans.
Being able to understand how to put this in an ROE
and communicate it to our testers,
that my friends is definitely security in action.
There's your word cloud.
Make sure that you know all of these
before you go on to our next lesson.
'cause we're gonna continue talking
about penetration testing
and we're gonna build on these terms.
So I'll see you there when you're ready.