Investigation Framework

• Incident Scoping
• Evidence Collection
• Analysis
• Correlation
• Timeline Analysis
• Intelligence Correlation
• Reporting

Reporting

We finally made it, we are at the bitter end. Speaking of bitter, we are going to talk about the most dreaded part of an investigation, the report. It could be argued that reporting is perhaps the most important part of an investigation. It is the time to push for the changes you want to see and have an opportunity to have your work directly seen by the higher ups. As an investigator, this is the time for you to prove how hard you worked and showcase what a great team the organization has. Don’t mess it up! Just kidding, but really it’s time to shine!

Know your demands

Before we get into the actual report, you need to take some time to reflect.

After an incident, the wallets open up.

This isn’t mean to sound exploitative, it makes perfect business sense to invest heavily into your security posture after an incident. So make sure you can speak to what you want and more importantly why. Your recommendations are crucial because you are the expert, nobody knows the details of this incident more than you. If you want some ideas of things to ask for check this list.

• Multi-factor authentication (MFA)
• Endpoint security tools
• Security information and event management (SIEM)
• Network visibility or protection
• Additional staff
• Creation or adjustment of roles/responsibilities
• Improving logging capabilities
• Updating hardware & software

There are plenty of other things  and likely more specific desires related to the incident. Don’t be afraid to think big, you may not get another chance to really make your voice heard.

Crafting the perfect report

It’s time, open up that word document and stare at the empty blinking cursor…… wait. You don’t have to do that! If you have followed along, the entire point of this series is to provide a framework for your investigation and make the report writing easier. So take a second look at your current notes, you should see a 90% written report. If you followed the steps and filled in the proper information you have most of the report written, in addition to a fancy little timeline.

So rather than writing, you mostly will just need to edit and make sure you can tell the story. Open up that report template and let’s walk through the sections.

Incident Summary

The entire report is definitely important, but this is the most important section. Realistically, folks will typically only read the first parts of the report. So you need to make sure the summary contains all the information you want anyone reading to know. I would try to keep it to about 2 paragraphs, anymore and you are going to have people lose interest. Here are the components:

• Adversary actions
  • Around three sentences describing the key aspects of the incident and impact on the organization.
• Response
  • Another three sentences describing how the team responded and the key actions taken to prevent things from getting worse
  • Don’t forget to brag about how you figured out what the adversary had done.
• Call to action
  • Final sentences should describe what needs to be done to prevent this from happening again.
  • Any procedural, escalation and/or communication improvements for the future.
  • Reference the additional recommendations you include later in the report.

Timeline

Cut and paste baby! You have the timeline, just take some time to clean it up and make it pretty. You may need to cut out a bit of the in-depth technical detail just to make sure it isn’t too wordy, remember you include all the details later.

Adversary Actions

If you took the time to figure out which MITRE techniques are applicable, this is where all that work pays off. Try your best to have a MITRE technique or tactic for each significant event from your notes and timeline. For bonus points, throw in  a nice color coordinated MITRE ATT&CK map.

Recommendations

Utilize the table I provide in the report template and fill in all the columns.

• Priority
  • High, directly related to the incident actions that would prevent it from ever happening again
  • Medium, recommendations that are important to improve the security posture but may not be directly related to the incident.
  • Low, hopefully easy to implement process improvements, likely less technical deployments and more updating existing documentation or processes.
• Title
  • Simple title to summarize the recommendation
• Description
  • Details about how the recommendation would help and what needs to be done.
  • Be precise about what exactly you want accomplished.

Technical Analysis

This section is for the nerds like you 😊. You should be able to take your forensic notes and put them in here. Just be sure to review it all and make proper edits. You want your notes to flow as a narrative, not just a dump of information.

Don’t forget to pull the indicators from your incident evidence timeline and include them at the bottom. This will be a nice reference for future detection engineering or threat hunting.

Peer Review

DFIR is a team sport! You may be the best notetaker, but make sure everyone gets a chance to go through the reports and make their edits. Trust me, they’ll be impressed with what you’ve produced on the first draft with record time!

Now you’ve written a beautiful report! Don’t be afraid to take some time to make it real pretty. The more visually interesting your report is, the more likely people will read it. Throw in some of your organization branding, use some nice letterhead, use small things like code text on code snippets. Nobody wants to read a black and white block of text.

Show it off, follow up

I’ve seen so many amazing incident reports get written and ultimately forgotten because nobody saw it. You took a lot of time to craft this report, you can take some time to show it off. So here’s some ideas to get this report in front of everybody who cares.

• Lessons learned meeting
  • Set up a post incident review to go over the incident in detail.
  • You will essentially walk through the report in the meeting and create an action plan for the recommendations.
• Follow up with recommendations
  • Reach out to team members who can help get the recommendations accomplished.
  • Utilize the report to give them context as to why you want the recommendations actioned.
• Share with the larger organization
  • Before you do, make sure you get approval to do so and redact information that may not be needed.
  • Offer to setup webinars or lunch and learns to discuss the incident report at a high level with folks who may not have been involved.
  • This can significantly help with Security Awareness Programs since it shows what can go wrong.

Relax before you preparation

Take some time to truly rest. If you are a manager of any kind, I urge you to please give your team a break and let them rest. At the very least maybe work from home with minimal responsibilities for a few days, AT MINIMUM. You will be exhausted after all this, even if things moved fairly quickly it is incredibly taxing on your brain.

I know you want to start to move on those recommendations but get the plan in place and give yourself some time to pause before you get going again. Take it from someone who works incidents all year round, you need buffer time. You will burnout if you just push through and I know it’s not always easy to get appropriate time off.

The reason I wanted to create this framework is to prevent the constant push forward without a plan. That’s the fastest way to burnout, I hope if you follow this it at least makes your career a tiny bit easier.

Conclusion

You did it! Great job! You got through the incident, you documented everything appropriately, and you have some great follow up actions to improve your organization. I hope you find this series helpful and I am open to any questions or feedback. I appreciate your support and commitment to get this series done. You will see plenty more from me in the future.

Cheers!

Twitter: @CyberCoat

Mastodon: @ChocolateCoat@infosec.exchange

LinkedIn: terrynvalikodath

DFIR Templates: https://github.com/chocolatecoat/DFIR-Templates