The incident response plan

With the incident response charter written and the CSIRT formed, the next step is to craft the incident response plan. The incident response plan is the document that outlines the high-level structure of an organization's response capability. This is a high-level document that serves as the foundation of the CSIRT. The major components of the incident response plan are as follows:

• Incident response charter: The incident response plan should include the mission statement and constituency from the incident response charter. This gives the plan continuity between the inception of the incident response capability and the incident response plan.
• Expanded services catalog: The initial incident response charter had general service categories with no real detail. The incident response plan should include specific details of what services the CSIRT will be offering. For example, if forensic services are listed as part of the service offering, the incident response plan may state that forensic services include the evidence recovery from hard drives, memory forensics, and reverse engineering potentially malicious code in support of an incident. This allows the CSIRT to clearly delineate between a normal request, say for the searching of a hard drive for an accidentally deleted document not related to an incident, and the imaging of a hard drive in connection with a declared incident.
• CSIRT personnel: As outlined before, there are a great many individuals who comprise the CSIRT. The incident response plan will clearly define these roles and responsibilities. Organizations should expand out from just a name and title and define exactly the roles and responsibilities of each individual. It is not advisable to have a turf war during an incident, and having the roles and responsibilities of the CSIRT personnel clearly defined goes a long way to reducing this possibility.
• Contact list: An up-to-date contact list should be part of the incident response plan. Depending on the organization, the CSIRT may have to respond to an incident 24 hours a day. In this case, the incident response plan should have primary and secondary contact information. Organizations can also make use of a rotating on-call CSIRT member who could serve as the first contact in the event of an incident.
• Internal communication plan: Incidents can produce a good deal of chaos as personnel attempt to ascertain what is happening, what resources they need, and who to engage to address the incident. The incident response plan internal communication guidance can address this chaos. This portion of the plan addresses the flow of information upward and downward between senior leadership and the CSIRT. Communication sideways between the CSIRT core and support personnel should also be addressed. This limits the individuals who are communicating with each other and cuts down on potentially conflicting instructions.
• Training: The incident response plan should also indicate the frequency of training for CSIRT personnel. At a minimum, the entire CSIRT should be put through a tabletop exercise at least annually. In the event that an incident post-mortem analysis indicates a gap in training, that should also be addressed within a reasonable time after conclusion of the incident.
• Maintenance: Organizations of every size continually change. This can include changes to infrastructure, threats, and personnel. The incident response plan should address the frequency of reviews and updates to the incident response plan. For example, if the organization acquires another organization, the CSIRT may have to adjust service offerings or incorporate specific individuals and their roles. At a minimum, the incident response plan should be updated at least annually. Individual team members should also supplement their skills through individual training and certifications through such organizations as SANS or on specific digital forensic tools. Organizations can incorporate lessons learned from any exercises conducted into this update.

Incident classification

Not all incidents are equal in their severity and threat to the organization. For example, a virus that infects several computers in a support area of the organization will dictate a different level of response than an active compromise of a critical server. Treating each incident the same will quickly burn out a CSIRT as they will have to respond the same way to even minor incidents.

As a result, it is important to define within the incident response plan an incident classification schema. By classifying incidents and gauging the response, organizations make better use of the CSIRT and ensure that they are not all engaged in minor issues. The following is a sample classification schema:

• High-level incident: A high-level incident is an incident that is expected to cause significant damage, corruption, or loss of critical and/or strategic company or customer information. A high-level incident may involve widespread or extended loss of system or network resources. The event can potentially cause damage to the organization and its corporate public image and result in the organization being liable. Examples of high-level incidents include, but are not limited to, the following:
  • Network intrusion
  • Physical compromise of information systems
  • Compromise of critical information
  • Loss of computer system or removable media containing un-encrypted confidential information
  • Widespread and growing malware infection (more than 25% of hosts)
  • Targeted attacks against the IT infrastructure
  • Phishing attacks using the organization's domain and branding
• Moderate-level incident: A moderate-level incident is an incident that may cause damage, corruption, or loss of replaceable information without compromise (there has been no misuse of sensitive customer information). A moderate-level event may involve significant disruption to a system or network resource. It also may have an impact on the mission of a business unit within the corporation:
  • Anticipated or ongoing DoS attack.
  • Loss of computer system or removable media containing un-encrypted confidential information.
  • Misuse or abuse of authorized access.
  • Automated intrusion.
  • Confined malware infection.
  • Unusual system performance or behavior.
  • Installation of malicious software.
  • Suspicious changes or computer activity.
  • Playbooks can be configured in a number of ways. For example, a written document can be added to the incident response plan for specific types of incidents. Other times, organizations can use a flow diagram utilizing software such as iStudio or Visio. Depending on how the organization chooses to document the playbook, they should create 10-20 that address the range of potential incidents.
• Low-level incident: A low-level incident is an incident that causes inconvenience and/or unintentional damage or loss of recoverable information. The incident will have little impact on the corporation:
  • Policy or procedural violations detected through compliance reviews or log reviews
  • Lost or stolen laptop or other mobile equipment containing encrypted confidential information
  • Installation of unauthorized software
  • Malware infection of a single PC
• Incident tracking: Tracking incidents is a critical responsibility of the CSIRT. During an incident, all actions taken by the CSIRT and other personnel during an incident should be noted. These actions should be recorded under a unique incident identifier.

For organizations that have limited resources and experience a limited number of incidents per year, most IT ticketing systems are sufficient for tracking incidents. The drawback to this method is that these systems generally lack an incident response focus and do not have additional features that are designed to support incident response activities. Larger organizations that have a higher frequency of incidents may be best served by implementing a purpose-designed incident response tracking system. These systems allow the integration of evidence collection and incident playbooks.