Part 10 - Best Practices
Video Activity
As a professional web app pentester, you must conduct yourself and your activities in an organized and professional manner. This is extremely important since your activities are virtually indistinguishable from a real attacker. The name of the game is to protect yourself! Key components of pentesting best practices are: - Gain written permission ab...
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or
Already have an account? Sign In »
Video Description
As a professional web app pentester, you must conduct yourself and your activities in an organized and professional manner. This is extremely important since your activities are virtually indistinguishable from a real attacker. The name of the game is to protect yourself! Key components of pentesting best practices are: - Gain written permission about what, how, and when things will be tested. - Create documentation that records the tests such as output from wireshark and tcpdump along with logs about what you did. - Build reports about what was discovered and how to fix vulnerabilities. - Establish a good working relationship with other departments to stave off any potential misunderstandings during testing.
Video Transcription
00:03
>> Welcome to Cybrary.
00:03
I am Raymond Evans and I will be
00:03
your subject matter expert for
00:03
Cybrary's Web App Penetration Testing course.
00:03
In this video we will be discussing
00:03
Pentester best practices.
00:03
What will be covered?
00:03
>> Gaining permission,
00:03
>> documentation, building reports,
00:03
when to test and working with other departments.
00:03
This video is handy because many of
00:03
the things in this video can help keep you
00:03
out of a lot of trouble and
00:03
help you keep yourself covered in
00:03
case somebody tries to throw blame
00:03
at you for something that you didn't necessarily do.
00:03
The first and most critical part of
00:03
pentesting or the preparation
00:03
for pentesting is gaining permission.
00:03
Gaining permission should always be
00:03
established prior to performing tests.
00:03
You should never use a word of mouth
00:03
or a vague e-mail
00:03
or some sort of memo that was sent to you.
00:03
You should always have
00:03
an agreement that has been written out and signed
00:03
by heads of departments and
00:03
individuals who are allowed to approve this thing.
00:03
If you have a low-level boss who says, hey,
00:03
go do this and you know that that individual is not
00:03
allowed to give that permission to you,
00:03
you should probably talk
00:03
to somebody higher than him and make
00:03
sure that that's exactly what needs
00:03
to be done to cover yourself.
00:03
This written permission will also act
00:03
as an agreement which will house things
00:03
like different boundaries and what exactly
00:03
needs to be done or wants to be done for this test.
00:03
In this agreement, you will need to
00:03
have a list of what tests will be done,
00:03
how long each of these tests will be performed for.
00:03
This helps establish time frames
00:03
that you will be performing
00:03
the tests so the company who
00:03
you work for or who
00:03
your company is sending you
00:03
out to perform the pentests for,
00:03
will know that that traffic that's going across,
00:03
the wire at that time will most likely be yours.
00:03
Along with these times,
00:03
you will also need what your targets will be,
00:03
so specific websites or different machines that you
00:03
have set as the targets that you will be testing.
00:03
This helps the people who you're working for
00:03
identify that they're not necessarily under an attack,
00:03
but that is your traffic
00:03
that is going across the wire there.
00:03
Not only do agreements need to
00:03
be made with your customer,
00:03
but they should also be established with
00:03
any third-party organizations
00:03
that provide additional services.
00:03
IaaS, SaaS or PaaS,
00:03
so infrastructure as a service or
00:03
>> platforms as services,
00:03
>> things like cloud systems or cloud services.
00:03
If you're going to be performing tests on
00:03
a website that's hosted on the Cloud,
00:03
you will need to let that person who host
00:03
that website on the cloud
00:03
know that this will be happening.
00:03
You need to put them in the agreement
00:03
as well and have them sign off.
00:03
Because if you have
00:03
an individual who has a website and they give you
00:03
permission to perform a web app pentest on it,
00:03
but the people who are hosting it on
00:03
their Cloud don't give you permission,
00:03
then the people who are hosting it on
00:03
the Cloud can come
00:03
after you and can call the cops on you,
00:03
and can look at this as an attack.
00:03
Documentation should be maintained
00:03
in order to protect yourself.
00:03
As soon as you get on the network,
00:03
anything that goes wrong will most likely be blamed on
00:03
you by individuals who
00:03
don't understand what you're doing.
00:03
They just know that you're there and
00:03
you're performing a penetration test.
00:03
Even if their system doesn't touch yours
00:03
>> and it has nothing to do with yours,
00:03
>> if you are pentesting
00:03
a payment submission page on
00:03
a website and a computer goes down in HR,
00:03
the individuals in HR who don't
00:03
know better are going to automatically
00:03
assume that you tried to hack their computer down
00:03
there and blame will be thrown at you.
00:03
Keeping a proper documentation will
00:03
give you the ability to identify what you
00:03
did to damage the network
00:03
or to protect yourself from accusations,
00:03
this documentation should be automatic and manual.
00:03
For the automatic documentation,
00:03
you should have something like
00:03
Wireshark or tcpdump running.
00:03
This type of documentation allows for
00:03
accountability of what happened over the network.
00:03
With Wireshark or tcpdump running,
00:03
you are able to accurately
00:03
show exactly what came
00:03
out of your machine over the network.
00:03
If some HR says,
00:03
"Hey, they attacked our computer",
00:03
at whatever time you are able to go
00:03
and look at your Wireshark or tcpdump
00:03
at that exact time and show them,
00:03
no, this is the IP address I
00:03
used for the test or this is
00:03
the webpage I was performing the test against
00:03
and you're able to protect yourself.
00:03
Or if you did take down the computer accidentally,
00:03
you are able to see how you accidentally took it down.
00:03
What exactly caused that machine to fail.
00:03
Then manual documentation.
00:03
This documentation should include
00:03
a list of all commands that were used,
00:03
what time they were used, and
00:03
what system they were used on.
00:03
A small Excel sheet or something
00:03
like that with a couple of
00:03
columns for things like commands, times,
00:03
websites and most likely as well,
00:03
something that would be handy to add into
00:03
that is a note section.
00:03
If something interesting happens
00:03
when you type in a command,
00:03
you can just jot down that little note in that section.
00:03
But these are very, very important documents.
00:03
These are very,
00:03
very important ways of maintaining
00:03
proper documentation to keep yourself covered.
00:03
When you build a report,
00:03
a report should be comprehensive and
00:03
easy for customers to understand.
00:03
There are key elements that each report should include;
00:03
a type of vulnerability that was found,
00:03
where exactly that vulnerability was found,
00:03
how it affects the customer,
00:03
so you should probably put
00:03
it in a little detailed item here,
00:03
something such as this cross-site scripting
00:03
can be used to enumerate cookies.
00:03
If it's a banking company and you're able to
00:03
successfully get cookies from
00:03
a test that you've performed,
00:03
then you can also show proof that this can be
00:03
used to harvest cookies and steal
00:03
individual's money and things like that.
00:03
After you have how it affects the customers,
00:03
you should also put a suggested fix in.
00:03
Because it's good that you find vulnerabilities,
00:03
but you should be knowledgeable
00:03
or semi knowledgeable as to how to fix it.
00:03
If you find something like a SQL injection,
00:03
you know that they have
00:03
to have proper validation for user input
00:03
to parse out certain key characters
00:03
that cause that vulnerability.
Up Next
Instructed By
Similar Content
