Part 1 - Report Creation
Video Activity
• What to include o Details o Artifacts • What to consider o Audience o Time o Classification • Supporting documentation
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
• What to include o Details o Artifacts • What to consider o Audience o Time o Classification • Supporting documentation
Video Transcription
00:03
>> Welcome to Cybrary. I'm 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 report creation.
00:03
What will be covered? We'll we're going to
00:03
discuss what to include,
00:03
the details, and the artifacts,
00:03
what to consider, such as the audience, time,
00:03
classification, and any supporting documentation.
00:03
Report creation is very important.
00:03
It's important because if you
00:03
don't have a good report bill when you're
00:03
going into a company to perform a job, or
00:03
leaving a company after performing
00:03
a job, and giving them the results,
00:03
you can look amateurish in their eyes,
00:03
especially that initial report coming on.
00:03
With the initial report coming on,
00:03
you are going to want to put in your planning.
00:03
What steps did you take to plan this out?
00:03
What assets did you look at?
00:03
What reports did you look at?
00:03
Who did you contact?
00:03
Things like that, you want to show them
00:03
that you had a good plan going into this.
00:03
You want to show what
00:03
your methodology was throughout this planning.
00:03
You want to have your assumptions.
00:03
Things like this is
00:03
the assumed IP range that we're going into.
00:03
This is the assumed environment,
00:03
Linux or Windows environment that we're going into.
00:03
We are assuming that they
00:03
have web servers that are running web applications.
00:03
We're assuming that there's some database
00:03
server, things like that.
00:03
You want to put all of these assumptions in
00:03
there that you have about the environment.
00:03
That way when you come in,
00:03
you show them your planning,
00:03
and then you discuss your assumptions,
00:03
anything can be clarified
00:03
right then and there that may be wrong, or maybe right.
00:03
You're also going to put a clear cut
00:03
>> objective in there.
00:03
>> You just don't want to say, "Hey,
00:03
I'm here to pen test".
00:03
You want to say, "I'm here to look at assets x,
00:03
y, and z for these vulnerabilities".
00:03
The OWASP Top 10, or
00:03
you are worried about Cross-Site Scripting.
00:03
Our objective is just to find Cross-Site Scripting.
00:03
You don't want to leave your objective open-ended.
00:03
Leaving it open-ended leaves
00:03
a certain layer of uncertainty with the customer.
00:03
They don't know if you're going to accidentally
00:03
break their network or break some
00:03
>> assets on the network,
00:03
>> or if you're actually
00:03
just going to do certain types of tests.
00:03
Have a clear cut objective in
00:03
your report when you are coming onto
00:03
the site, and you're giving
00:03
a introduction report to whoever you're working for.
00:03
You want to discuss your methodology.
00:03
Did you use the hacker methodology?
00:03
If not, if you have your own methodology, explain that,
00:03
tell them what exact steps you have taken so far,
00:03
what's steps come next, and then what's
00:03
the future of this assessment.
00:03
If you have a clear cut methodology laid out,
00:03
then again, you're going to look knowledgeable
00:03
and it's going to put the customer at ease.
00:03
With that methodology, you want to build a timeline.
00:03
We are going to have our introduction here,
00:03
our introduction report at
00:03
eight o'clock till whatever time,
00:03
we're going to plug into the network
00:03
from this time to this time,
00:03
we're going to then run scans x,
00:03
y, and z, test this, and this.
00:03
Have a built out timeline so that way,
00:03
when you are performing actions on the network,
00:03
your customer has some idea
00:03
of when certain things will be happening.
00:03
This can also be given to
00:03
their IT department so
00:03
their IT department isn't freaking out like,
00:03
"Oh my God, I see
00:03
a Cross-Site Scripting attempt,
00:03
or I see a SQL injection attempt.
00:03
We're being attacked". Well,
00:03
they can look at that timeline and say,
00:03
"Well it's noon, they're doing a lunchtime SQL inject.
00:03
This is probably them ".
00:03
Then they can double-check with you
00:03
real quick before throwing
00:03
a pool of red flags, and freaking out.
00:03
These are some of the things you would want in
00:03
your initial report going into the job.
00:03
You would also want to have these, and
00:03
a executive report of
00:03
some sort at the end of the assessment as well.
00:03
At the end of the assessment you can say,
00:03
"Hey, this is what we briefed you.
00:03
This is what we were going to do".
00:03
Then move on to what you actually
00:03
did do and what you actually found.
00:03
When you do find something, and when you're
00:03
building a report of what you found,
00:03
you want to include all of the affected assets.
00:03
Which machines exactly had this?
00:03
What were we able to find on this?
00:03
You want to put things like what the OS is,
00:03
the operating system service version
00:03
of the item that got effective.
00:03
If a vulnerability is found,
00:03
you will want to put in the CVE-IDs.
00:03
This allows the customer to quickly look up
00:03
what the vulnerability is, and when they,
00:03
and if they hopefully they do
00:03
have their IT department take care of it,
00:03
that IT department, and looking at this report,
00:03
can look up the CVE-ID, and quickly fix it
00:03
with the suggested recommendations that are
00:03
provided by the CVE database.
00:03
Along with that, you want an actual impact.
00:03
You want to tell them that, "Hey,
00:03
if this happens, and this is executed,
00:03
then data of this sort can be taken,
00:03
money from here, and here can be taken.
00:03
You could have a downtime for X amount of time".
00:03
You want to clear impact.
00:03
You want to tell them this vulnerability
00:03
is bad, and this is exactly why it's bad.
00:03
Painting a picture for them.
00:03
Don't just say, "Hey, you're vulnerable to this".
00:03
Because in a lot of
00:03
individuals' minds who don't speak technical a lot.
00:03
They're just going to see that, and say, "Oh,
00:03
I'll just give my IT department to fix it
00:03
sometime when we get the budget".
00:03
No, you want to let them know that
00:03
these vulnerabilities here are
00:03
bad, and this is why they're bad.
00:03
Then you want to have an attack probability.
00:03
What that means is, you want to include things
00:03
like users are using this portion of the application.
00:03
Well, that portion,
00:03
if somebody puts a SQL Injection in here,
00:03
then this can happen.
00:03
What's the probability of that?
00:03
Well, the page that it's
00:03
on is a page that every single user uses,
00:03
and there's hundreds of thousands of users every hour.
00:03
So the attack probability is very high.
00:03
Now, if it's some page that you had
00:03
to spider, and that page was hidden within
00:03
a link, and a user
00:03
would only stumble across that page if they were
00:03
looking for some specialized information,
00:03
then that attack probability is going to be lower.
00:03
You also want to have the estimated loss as well.
00:03
You can tell them,
00:03
hey, if this system is hit,
00:03
this is a piece of
00:03
key terrain on your network, and if this item is hit,
00:03
then you will lose visibility to the outside network,
00:03
and if you lose that then it's
00:03
going to take x amount of time
00:03
for you to bring it back out,
00:03
which means x amount of users
00:03
and x amount of money could be lost.
00:03
You want to have a number in there,
00:03
an actual monetary number.
00:03
Say, this is how much money you can
00:03
lose if this vulnerability is exploited.
00:03
Then with that, you want to put recommendations in.
00:03
Don't just tell them that,
00:03
"Hey, you have this vulnerability".
00:03
Tell them, "Hey, you have this vulnerability,
00:03
it's really bad,
00:03
this is why it's bad,
00:03
this is how likely it is to be attacked,
00:03
this is how much you're going to lose,
00:03
but this is how you fix that".
00:03
You never want to walk away from
00:03
a customer and have the customer scratching their head.
00:03
Well, says "I got
00:03
a cross-site scripting or says I got a SQL injection.
00:03
Well, I don't know what to do here".
00:03
Tell them about form validation and things like that.
00:03
Let them know that this vulnerability
00:03
exists and this is how you fix it.
00:03
Also have a reference for how to fix it.
00:03
Many of the CVE databases,
00:03
if you find a vulnerability, and it has a CVE-ID to it,
00:03
will tell you is the recommended actions, or
00:03
those web fuzzers that we covered in earlier videos,
00:03
they also have recommendations in there.
00:03
You can also pull recommendations from that,
00:03
and have a very comprehensive report
00:03
for individuals as you leave their organization.
Up Next
Instructed By
Similar Content
