Incident Handlers Checklist

1.      Preparation

  1. Are all members aware of the security policies of the organization?
  2. Do all members of the Computer Incident Response Team know whom to contact?
  3. Do all incident responders have access to journals and access to incident response toolkits to perform the actual incident response process?
  4. Have all members participated in incident response drills to practice the incident response process and to improve overall proficiency on a regularly established basis?

2.      Identification

  1. Where did the incident occur?
  2. Who reported or discovered the incident?
  3. How was it discovered?
  4. Are there any other areas that have been compromised by the incident? If so what are they and when were they discovered?
  5. What is the scope of the impact?
  6. What is the business impact?
  7. Have the source(s) of the incident been located? If so, where, when, and what are they?

3.      Containment

  1. Short-term containment
    1. Can the problem be isolated?
      1. If so, then proceed to isolate the affected systems.
      2. If not, then work with system owners and/or managers to determine further action necessary to contain the problem.
    1. Are all affected systems isolated from non-affected systems?
      1. If so, then continue to the next step.
      2. If not, then continue to isolate affected systems until short-term containment has been accomplished to prevent the incident from escalating any further.
  2. System-backup
    1. Have forensic copies of affected systems been created for further analysis?
    2. Have all commands and other documentation since the incident has occurred been kept up to date so far?
      1. If not, document all actions taken as soon as possible to ensure all evidence are retained for either prosecution and/or lessons learned.
      2. Are the forensic copies stored in a secure location?
        1. If so, then continue onto the next step.
        2. If not, then place the forensic images into a secure location to prevent accidental damage and/or tampering.
  3. Long-term containment
    1. If the system can be taken offline, then proceed to the Eradication phase.
    2. If the system must remain in production proceed with long-term containment by removing all malware and other artifacts from affected systems, and harden the affected systems from further attacks until an ideal circumstance will allow the affected systems to be reimaged.

4.      Eradication

  1. if possible, can the system be reimaged and then hardened with patches and/or other countermeasures to prevent or reduce the risk of attacks?
    1. If not, then please state why?
  2. Have all malware and other artifacts left behind by the attackers been removed and the affected systems hardened against further attacks?
    1. If not, then please explain why?

5.      Recovery

  1. Has the affected system(s) been patched and hardened against the recent attack, as well as possible future ones?
  2. What day and time would be feasible to restore the affected systems back into production?
  3. What tools are you going to use to test, monitor, and verify that the systems being restored to productions are not compromised by the same methods that cause the
  4. Original incident?
  5. How long are you planning to monitor the restored systems and what are you going to look for?
  6. Are there any prior benchmarks that can be used as a baseline to compare monitoring results of the restored systems against those of the baseline? 

6.      Lessons Learned

  1. Has all necessary documentation from the incident been written?
    1. If so, then generate the incident response report for the lessons learned meeting.
    2. If not, then have documentation written as soon as possible before anything is forgotten and left out of the report.
  2. Assuming the incident response report has been completed, does it document and answer the following questions of each phase of the incident response process: (Who? What? Where? Why? And How?)?
  3. Can a lessons learned meeting be scheduled within two weeks after the incident has been resolved?
    1. If not, then please explain why and when is the next convenient time to hold it?
  4. Lessons Learned Meeting
    1. Review the incident response process of the incident that had occurred with all CIRT members.
    2. Did the meeting discuss any mistake or areas where the response process could have been handled better?
      1. If no such conversations occurred, then please explain why?

https://www.sans.org/reading-room/whitepapers/incident/incident-handlers-handbook-33901

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *