Incident Reporting – CompTIA Security+ SY0-401: 2.5

What’s the best way to gather information during a security incident? In this video, you’ll learn some techniques for gathering details and how to report after the security event is over.

<< Previous Video: Lessons Learned from IncidentsNext: Incident Recovery and Reconstitution >>


When you’re in the middle of a security incident there is a lot of data that’s being generated. Some of it is in log files. Some of it is messages that appear on a screen. Sometimes you notice physical things with the environment around you. So you need to gather pictures, log information, and data, and as much of it as you possibly can. Whatever you’re gathering though needs to be very objective and very factual. You don’t want to jump to conclusions. You want to stick directly to the facts and have all of that available in however you’re capturing that data. One way to capture that data is with a log book. You can physically write into this book the things that you were observing and you’ll be able to preserve it, well, forever. It’s on paper and there’s not a possibility then that you could lose it due to some type of electronic means.

We’re carrying digital cameras around with us all the time now, as part of the mobile devices that we have, so we’re very easily able to take pictures of anything we might come across. Even if it’s messages on a screen it’s great to be able to capture that instead of relying on log files after the fact. I don’t have any problem using a log book to document what I’m seeing, my problem is when I try to read what I’ve already written into that log book. My penmanship is not the best, so it may be more appropriate to use something like an audio recorder. Or I could simply speak into a microphone, document what I’ve seen, and then later on transcribe that onto a piece of written paper, or type it out. And of course, having a central place to store all of this reporting information would be ideal. So it may be good to have a laptop that is dedicated to incident reporting and it could be something that you never connect to your internal networks.

When you’re tracking this information about the incident there’s a number of different items you may want to document. One is the status of the incident. You may want to keep an update, as you go through the process, of what was happening at any particular time. It may be useful to have summary information, as well, so you can roll up a lot of larger amounts of data into a small description, that can then be used to communicate with others. It might be useful after the fact also to look at all of the different incidents, and see if there’s any relationship or commonality between each one of those. There may be a central point where you can resolve or mitigate the risk associated with these particular incidents.

Any time you make a change or perform any type of action relating to an incident you should always document that. Especially, since you’ll want to examine the results of that particular change after the fact. If you’re collecting any evidence about the incident, whether it’s physical evidence or digital evidence, you’ll want to have a chain of custody. So you know exactly what happened to that evidence, and who may have had access to that particular piece of information. You may need to go back to this incident a number of times, and it may take a number of years to be able to analyze everything associated with the incident. So you want to be sure that everyone’s contact information is well documented within the incident reporting materials.

Each individual is going to have a different perspective of exactly what they saw and what they did during the security incident. So it’s always useful to have individual written comments from all of those different incident handlers. You may be able to find a piece of information written by one person that didn’t show up on anybody else’s report. And ultimately, we need to understand what to do next. And after analyzing an entire incident set of reports you may want to create some objectives of things to do next time. So that you can minimize the impact that these security incidents might have.