Incident Response Reporting
ansionnachcliste
Member Posts: 71 ■■■□□□□□□□
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:
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?).
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 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?).
Comments
-
yoba222 Member Posts: 1,237 ■■■■■■■■□□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.A+, Network+, CCNA, LFCS,
Security+, eJPT, CySA+, PenTest+,
Cisco CyberOps, GCIH, VHL,
In progress: OSCP -
TechGuru80 Member Posts: 1,539 ■■■■■■□□□□I've heard good things about CyberCPR (https://www.cybercpr.com) and it's made by a SANS instructor.
-
ansionnachcliste Member Posts: 71 ■■■□□□□□□□Yoba222, I agree - Time to shake things up.
Cheers TechGuru80, I'll check it out.