Report Rapport


Let me just state this right at the top. You need to be writing reports. I don’t care what type of investigation you are doing or what the findings are. You need to be writing reports.
There are plenty of reasons that your management will tell you about why you have to write a report. There are even more reasons for you to write these reports, for your own benefit. Here is a quick list of a few that I thought of, and I will discuss a bit about each in sections below.

  •  Documenting your findings
  •  Justification of your time
  • CYA
  •  Detail the thoroughness of your work
  • Show history of specific user or group
  • Justification for shiny tools
  • Measure personal growth

Documenting Your Findings

Your boss will share the recommendation for this because it’s a pretty solid one. You need to document what you have found. As DFIR investigators, security specialists, infosec analysts, etc., we are more technical in nature than the average computer user. We know the inner most workings of these computers, and often times how to exploit them in ways they weren’t designed. We dig through systems on an intimate level, and with this knowledge we can make some incorrect assumptions that others understand the most basic of things.
Take an example of a word document. A current generation word document has an extension of ‘docx’ when saved to disk. So many things fly through my mind when I see those letters. I know that because of the ‘x’, that it is a current generation. The current generation use the PK zip file format. It contains metadata, and in the form of XML. It has document data, and is also in the form of XML. It can have attachments, and those are always placed in a specific directory. I know you can keep going too. How many of your executives know this?
The people making decisions to investigate incidents and pay your salary do not need to know these things, but they do need to understand them in the context of your investigation. Document the details like your job depends on it. Use pictures and screen shots if you have to, since that helps display data in a friendlier way to less technical people. Go to town with it and be proud of what you discovered. The next time you have a similar case, you will have this as a reference to help spur thoughts and ensure completeness.

Justification of your time

We are a bunch of professionals that get paid very well, and we work hard for it. How many times in the last month have you thought or said to yourself that you do not have enough time in the day to complete all the work that is being placed in your queue?
When you report on your work, you are providing documentation of your work. The pile of hard drives on your desk makes it seem to others that you can’t keep up. That could mean that they are asking too much of you, or it could mean that you aren’t capable enough. You don’t want to leave that kind of question in the minds of your management. Write the reports to show the time you are spending. Show them how much work is required for a ‘quick check into this ransomware email’ and that it isn’t actually just a quick check. If you do this right, you might just find yourself with a new partner to help ease that workload.

CYA

People like to place blame on others to make sure they are clear. Your reports should document the facts how they are laid out, and let it speak for itself. You should include information about when data was requested and when it was collected. Document the state of the data and what was needed to make it usable, if that was required. Track information about your security devices and how they detected or didn’t detect pieces of the threat. You should be serving as a neutral party in the investigation to find the answers, not place the blame.

Detail the thoroughness of your work

So many investigations are opened with a broad objective, and that is to find the malware. Depending on the system and other security devices, it could be as easy as running an AV scan on the disk. Most times, in my experience at least, this is going to come up clean since it didn’t get detected in the first place anyways.
You are an expert. Show it in your reports. Give those gritty details that you love to dig into, and not just those about what you found. The findings are important, but you should also document the things you did that resulted in no findings. You spend a lot of time and some people don’t understand what’s required beyond an AV scan.

Show history of specific user or group

If you are an investigator working for a company, you are guaranteed to find those users that always get infected. They are frustrating because it causes more work for you, and they are usually some little Possibly Unwanted Program (PUP) or ransomware. They are the type of person that falls for everything, and you have probably thought or said some things about them that don’t need to be repeated.
Document your investigations, and you will be able to show that Thurston Howell III has a pattern of clicking on things he shouldn’t. Don’t target these people though. Document everything. As a proactive measure, you could start building a report summarizing your reports. Similar to the industry reports about attack trends, you can show internal trends and patterns that indicate things like a training program is needed keep users from clicking on those dang links. This can also support justification to restrict permissions for higher risk people and groups, and now you have data to back up the fact of being high risk. There can be loads of data at your disposal, and it’s limited by your imagination on how to effectively use it.

Justification for shiny tools

Have you asked for a new security tool and been turned down because it costs too much? What if you could provide facts showing that it is actually costing more to NOT have this tool?
Your reports provide documentation of facts and time. You can use these to easily show a cost analysis. Do the math on the number of investigations related to this tool, the hours involved in those investigations by everyone, not just you. You will have to put together a little extra on showing how much time the new fanciness will save, but you should have done the hard part by already writing reports.

Measure personal growth

This one is completely about you. We all grow as people, and we change the way we write and think. We do this because of our experiences, and our understanding that we can evolve to be better. Do you write like you did in 1st grade? Hope not! How about 12th grade? Unless you are a freshman in college, you have probably improved from there also.
When you write reports, you give yourself the ability to measure your growth. This can be very motivating, but it takes personal drive. If you have any reports from even just 6 months ago, go back and read them. You might even ask yourself who actually wrote that report, and I don’t think that’s a bad thing!

Final report

Reports can be a rather tedious part of our job, but if you embrace the personal benefits it can really become a fun part. Take pride in your investigation and display that in your reports. It will show. It works similar to smiling when you talk on the phone. People can tell the difference.
If you are writing reports today, good for you! Push yourself further and make it fun.
If you are not writing reports today, DO IT!
I am starting a mini series of posts on reporting. Future posts will be on structure and various sections of an investigative report. These are all my experiences and opinions, and I welcome your comments as well. Let’s all improve our reports together!
James Habben

Continue reading Report Rapport

Understanding the overhead in an Exchange mailbox database

It’s taken me a while to get around to mentioning the rather useful “Database Growth Reporting” script for Exchange 2010 and Exchange 2013 that was described on the EHLO blog in January.  My apologies for this lapse in service. All I can plead is that other stuff got in the way between now and then and that I never really had a chance to test the code out thoroughly, which is a prerequisite before commenting on software.

read more

Continue reading Understanding the overhead in an Exchange mailbox database