Writing an Incident Handling and Recovery Plan


While many websites and papers discuss incident handling and incident response plans, aside from RFC 2350 very few of these lay out exactly what an actual plan might look like. The following is an outline of a typical generalized incident handling and response plan for a small to mid-sized organization that doesn’t have a dedicated incident response staff. Using this outline as a starting point, the reader will need to adapt sections to his or her organization or industry as necessary and flesh out the plan in detail in order to create an adequate customized plan.

Incident Handling and Recovery Plan Outline

  1. Definitions
    1. Incidents – What constitutes an incident?
      1. Classification – What type of incident has occurred? Explain each category below.
        1. Loss of confidentiality of information
        2. Compromise of integrity of information
        3. Denial of Service
        4. Misuse of Service
        5. Damage to Systems
      2. Priority and Urgency – Identify the response level of effort (LoE) for a given type of incident. These may be reordered to suit the organizations needs.
        1. Threats to the physical safety of human beings
        2. Root or system level attacks to any host or system
        3. Compromise of restricted confidential service accounts or software areas
        4. Denial of service attacks to infrastructure, confidential service accounts or software areas
        5. Any of the above at other sites which originate from the organization’s systems
        6. Large scale attacks of any kind (worms, sniffing attacks, etc)
        7. Threats, harassment, or criminal offenses involving individual user accounts
        8. Compromise of individual user accounts
        9. Compromise of desktop systems
        10. Forgery, misrepresentation, or misuse of resources
    2. Incident Response Team (IRT) – Who will respond to the incident?
      1. Mission Statement – Why does the team exist and what is its purpose?
      2. Roles and Members – Who should be on the team?
        1. Leader – Primary coordinator and point of contact
        2. Management Sponsor – Lends authority to help minimize “red tape” barriers
        3. Systems Engineer – Responsible for affected systems
        4. Network Engineer – Responsible for affected networks
        5. Public Relations Advisory – Interfaces with the public as necessary
        6. Legal Advisory – Provides advice for differing legal courses of action
  2. Incident Handling Process
    1. Determine if an incident has occurred – Some activities may not warrant IRT action
      1. Contact the IRT Leader
      2. If the IRT is to be activated, the Leader documents the discovery
    2. Contain the Incident – Prevent problems with affected areas from spreading
      1. Identify and isolate the area under investigation
      2. Notify law enforcement personnel and legal advisory if applicable
      3. Notify Public relations advisory if necessary
      4. Document containment information
    3. Eradicate the Incident – Put an end to whatever caused the incident
      1. Gather evidence
      2. Identify the source of the incident
      3. Determine the full extent of the incident
      4. Implement stopgap measures to eliminate any active threats
      5. Update documentation with eradication information
  3. Recovery Process and Follow-Up
    1. Assess damages – Determine the impact of the incident to the organization
      1. Identify the affected systems and networks
      2. Identify the affected data
      3. Identify possible courses of remediation
    2. Reverse damages if possible – Minimize the costs, both tangible and intangible, associated with the incident
      1. Restore affected data from backup
      2. If necessary Public Relations Advisory establishes a plan to customer and public faith
    3. Nullify the source of the incident – Prevent recurrence of the same incident
      1. Patch any open vulnerabilities
      2. Improve access restrictions to the affected areas
      3. Further remediation as necessary
    4. Review the Incident – Learn from the mistakes
      1. Determine why the incident was able to occur
      2. Determine if the appropriate safeguards are in place to prevent recurrence
      3. Determine the risk level of similar incidents to other information assets
    5. Review the Incident Handling Plan – Adapt and increase efficiency in the response process
      1. Validate that the incident handling and response plan was appropriate
      2. Modify the incident handling and response plan with new insight gained
    6. Documentation – Keep tidy records, as they will almost certainly be needed again
      1. Create final documentation of the incident in an appropriate level of detail
      2. Perform debriefings of the IRT, if necessary
    7. Reporting – Assist others in disaster aversion
      1. If necessary, report the incident to industry regulation boards
  4. Incident Examples – Description of the plan in action will help all parties to fully understand the plan
    1. Physical Security Breach – Describe how the plan would be applied during a physical security breach
    2. External Network Breach – Describe how the plan would be applied during an external breach
    3. Internal Network Misappropriation – Describe how the plan would be applied to misuse of resources
  5. Appendix
    1. Table of Contact Information for IRT Team members
    2. Flow diagram of the incident handling process

Don't miss