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 *

Already have an account? Sign In »

4 hours 20 minutes
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
you should include artifacts in your report. So as you're going along and you discover something so say you discover across the scripting vulnerability and you managed to get an alert box to pop up
well, you're gonna want to take an image of that
screen. Capture that, and you're gonna want to put that in your report. If you were able to find some kind of anomalous logs while looking at their database, include those logs in your report as well,
or at least a snippet from those logs to say, Hey, this kind of attacks happening. If you have any charts or graphs that would help explain
estimated loss or what pages have the most vulnerabilities and things like that you want to include those, the more pretty pictures you have
Easier is for people understand. If you have things like packets that you may have manipulated, you want to include a little snippet of that packet and say, Hey, in this packet portion, here is the bit of information that we
had changed and it allowed us to exploit your system.
And if there's any code that you may have manipulated in the HTML using something like firebug. You want to include that little bit of code in there as well say, Hey,
this a little bit of code here really messes things up,
So artifacts are fantastic to have in a report.
When you're writing a report, you really need to conceal your audience as well.
Who are you presenting this to exactly? Is this somebody that's highly technical? They have a lot of technical knowledge. Or is this someone who may be a manager or CEO or something like that? You want to consider that one making this? You don't want to put too much high level technical information in the report
and watched my eyes eyes glaze over.
So whenever you're writing your port,
always keep in mind who you're presenting it to. You may want to create a couple different versions of that report to present a different levels. Also, consider how much do they need to know?
So if you're writing a report for somebody and counting, do they really need to know
the nitty gritty like somebody in I T.
Can you really trust them with that kind of information?
always consider what they need to know. I may be some organizations that you go into who say that
all vulnerabilities air found should only be reported to some body like the
says so or something like that. And so you are only going to present that information to them and cut out any kind of vulnerabilities from your report that you may have to give to somebody else if you're presenting technical information. Somebody, How technical are they? Are they somebody who says that the I T help desk
and answers phones and hands out new laptops and computers to people
and does minor things? Or are they in the back in the server room writing the code for the Web application? These are things that you need to consider as well, when you're writing your report and what exactly are they allowed to know, where this person sitting, the organization and the totem pole?
What do they have permission to know about
vulnerabilities and sensitive information in the company or organization?
That's a very, very important thing to know. You also want to consider time whenever you're writing a report. How quickly does this wrote? No report need to be created,
when exactly will it be presented and How long to the presentation B
do you want? Just a quick overview Thio be given Thio
individuals higher in the company, or do they want a detailed explanation of everything?
So whoever you are communicating with an organization to present the
report to you should ask them about time constraints and how in depth they want to go into the presentation classifications. She also come into consideration when you're writing your report.
So what kind of organization you're performing us for
is a government organization, a large corporation or small company.
You may have to consider actual government classification systems
when it comes to vulnerabilities.
Or if you're dealing with something like a medical company, you have to take HIPPA into consideration when writing your report, what you put in your report and how you show that to
has largely determined by the classifications. So
when you are building the report, you you wanna ask whoever you're communicating within the company,
that kind of question,
because you want to read a report that is something like a larger more of Social Security numbers or medical information. You present that information thio. Hundreds of people who don't have permission to see that kind of information, so take those kinds of things into consideration as well. And then, finally, you will not want to have all supporting documentation, consolidate it
and made easy toe to deliver. So this includes things like P caps and map results, fuzzier reports, screen captures and any XML files, as well as anything else that you might have
generated while on the network. You want to put them on something like a hard drive, thumb driver, CD or DVD of some sort to be able to give with the report.
This supporting documentation will help the company or organization that you're working for fixed the results easier because they're able to look exactly at what you looked at to identify the vulnerability. So it was covered when we talked about what to include things like details and artifacts, what gets there,
such as time audience classification.
And we also discussed supporting documentation type B ack and everyone
Up Next
Instructed By