Incident Response Reporting

ansionnachcliste

Hi all,

I'm curious about incident response reporting and how to find the best solution.

I'm currently working with an IRT process that uses a huge, complex report that look like a security policy, and I feel that it is difficult to find an audience to look through them, and as the report is on one document, it feels like a tedious "pencil pushing" exercise for incident handlers.

Although with that said, I enjoy creating policies .

How would you best describe how to create a report layout?

My idea is to have the incident handlers use SANS-like forms and tailor them for the specific business.
https://www.sans.org/score/incident-forms

Then, have the incident lead compile the information used from the reports into a final report that includes:

• Incident Response Information (date, times, etc.)
• Incident Summary (type, description of incident)
• Incident Notification (who was notified)
• Actions (identification, containment, evidence collection, eradication, recovery, other mitigation actions)
• Evaluation (incident lead evaluating the response, if the procedures were followed, lessons learned, etc)
• Follow-up (who reviewed the report and documents, recommended actions carried out, etc)
• Internal Document Reference List (SANS documents used by incident handlers, and any other important documents and information collected and where they are located)

I've been looking at examples online and can't find any that look like the one I'm currently using. Everything else looks more "basic", but when I say "basic", I feel they are more clear and concise.

I guess I may have my answer?

Cheers for reading.

Edit: I think it's time to consider a ticketing system for this. Any recommendations? I'd like to try OpenSource, if possible (theHive?).

yoba222

If I were an emotionally rattled incident handler/incident lead, completely stressed out because stuff just hit the fan, the last thing in the world I'd consider doing is compiling a complex report. I want dumbed down, step-by-step checklists of what to do because some hacker is in the payroll server right now stealing money and filling out some jargony report is the least of my concerns.

Of course, this mentality leads to incident handlers simply ignoring the not so useful plan and filling it in a few days later, maybe, which is not what we want to happen.