Part 2 - Report Creation

Video Activity

This lesson continues the discussion of report creation and specifically covers artifacts, which include: 1. Images 2. Logs 3. Charts 4. Graphs 5. Packets 6. Codes

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 »

Time
4 hours 20 minutes
Difficulty
Intermediate
CEU/CPE
5
Video Description

This lesson continues the discussion of report creation and specifically covers artifacts, which include: 1. Images 2. Logs 3. Charts 4. Graphs 5. Packets 6. Codes

Video Transcription
00:03
>> You should include artifacts in your report.
00:03
As you're going along and you discover something,
00:03
so say you discover cross-site scripting
00:03
vulnerability and you manage
00:03
>> to get an alert box pop up.
00:03
>> Well, you're going to want to take an image of that.
00:03
Screen capture that,
00:03
and you're going to want to put that in your report.
00:03
If you're able to find
00:03
some anomalous logs while looking at their database,
00:03
include those logs in your report as well.
00:03
Or at least a snippet from those logs to say,
00:03
hey, this attack is happening.
00:03
If you have many charts
00:03
>> or graphs that would help explain
00:03
>> estimated loss or what pages
00:03
have the most vulnerabilities and things like that,
00:03
you'll want to include those.
00:03
The more pretty pictures you have,
00:03
the easier it is for people to understand.
00:03
If you have things like
00:03
packets that you may have manipulated,
00:03
you'll want to include
00:03
a little snippet of that packet and say,
00:03
hey, in this packet portion here,
00:03
this is the little bit of information that we
00:03
had changed and it allowed us to exploit your system.
00:03
If there was any code that you may have
00:03
manipulated in the HTML using something like Firebug,
00:03
you want to include
00:03
that little bit of code in there as well and say hey,
00:03
this little bit of code here really messes things up.
00:03
Artifacts are fantastic to have in a report.
00:03
When you're writing a report, you really need
00:03
to consider your audience as well.
00:03
Who are you presenting this to exactly?
00:03
Is it somebody that's highly technical,
00:03
they have a lot of technical knowledge or is
00:03
this someone who may be
00:03
a manager or CEO or something like that?
00:03
You want to consider that when making this.
00:03
You don't want to put too much
00:03
high level technical information
00:03
in the report and maximize eyes glaze over.
00:03
Whenever you're writing your report,
00:03
always keep in mind who you're presenting it to.
00:03
You might want to create a couple of
00:03
different versions of that report
00:03
to present to different levels.
00:03
Also, consider how much do they need to now.
00:03
If you're writing a report for somebody in accounting,
00:03
do they really need to know
00:03
the nitty-gritty like somebody in IT?
00:03
Can you really trust them with that information?
00:03
Always consider what they need
00:03
to know and maybe some organizations that you
00:03
go into who say
00:03
that all vulnerabilities that are found should only be
00:03
reported to somebody like the CSO
00:03
>> or something like that.
00:03
>> You are only going to present
00:03
that information to them and cut out
00:03
any vulnerabilities from your report
00:03
that you may have to give to somebody else.
00:03
If you're presenting technical information to somebody,
00:03
how technical are they?
00:03
Are they somebody who sits at
00:03
the IT help desk and answers phones and hands out
00:03
new laptops and computers to
00:03
people and does minor things or
00:03
are they in the back and the server room
00:03
writing the code for the web application.
00:03
These are things that you need to consider as
00:03
well when you're writing your report.
00:03
What exactly are they allowed to know?
00:03
Where does this person sit in
00:03
the organization and the totem pole?
00:03
What do they have permission to know about
00:03
vulnerabilities and sensitive information
00:03
in the company or organization?
00:03
That's a very important thing to know.
00:03
You also want to consider time
00:03
whenever you're writing a report.
00:03
How quickly does this report need to be created?
00:03
When exactly will it be presented,
00:03
and how long should the presentation be?
00:03
Do they want just a quick overview to be given to
00:03
individuals higher in the company or do they
00:03
want a detailed explanation of everything?
00:03
Whoever you're communicating with in
00:03
an organization to present the report to,
00:03
you should ask them about time constraints
00:03
and how in depth they want to go into the presentation.
00:03
Classification should also come into
00:03
consideration when you're writing your report.
00:03
What organization you're performing this for?
00:03
Is it a government organization,
00:03
a large corporation, or a small company?
00:03
You may have to consider
00:03
actual government classification systems
00:03
when it comes to vulnerabilities.
00:03
Or if you're dealing with
00:03
something like a medical company,
00:03
you have to take HIPAA into
00:03
consideration when writing your report.
00:03
What you put in your report and who you show that
00:03
to is largely determined by the classification.
00:03
When you are building the report,
00:03
you want to ask whoever you're communicating with
00:03
in the company that question.
00:03
Because you don't want to
00:03
write a report that's something like
00:03
a large number of social security numbers
00:03
or medical information.
00:03
You present that information to hundreds of people who
00:03
don't have permission to see that information.
00:03
Take those things into consideration as well.
00:03
Then finally, you will want to
00:03
have all supporting documentation
00:03
consolidated and made easy to deliver.
00:03
This includes things like PCAPs,
00:03
NMap results, fuzzer reports, screen captures,
00:03
and any XML files,
00:03
as well as anything else that you might
00:03
have generated while on the network.
00:03
You'll want to put them on something
00:03
like a hard drive or a thumb drive or
00:03
CD or DVD of some sort to be
00:03
able to give with the report.
00:03
This supporting documentation will
00:03
help the company or organization that you're working
00:03
for fix the results easier because they're able to look
00:03
exactly at what you looked at
00:03
to identify the vulnerability.
00:03
What was covered? Well, we talked about what to
00:03
include things like details and artifacts.
00:03
What to consider such as
00:03
time, audience, classification.
00:03
We also discussed supporting
00:03
documentation. Happy hacking everyone.
Up Next
Instructed By