The IR plan

With the IR charter written and the CSIRT formed, the next step is to craft an IR plan. An IR plan is a 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 an IR plan are set out here:

• IR charter: An IR plan should include the mission statement and constituency from the IR charter. This gives the plan continuity between the inception of the IR capability and the IR plan.
• Expanded services catalog: The initial IR charter had general service categories with no real detail, so the IR plan should include specific details of which services the CSIRT will be offering. For example, if forensic services are listed as part of the service offering, the IR plan may state that forensic services include 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 IR 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 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 IR plan. Depending on the organization, the CSIRT may have to respond to an incident 24 hours a day. In this case, the IR 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, which resources they need, and who to engage to address the incident. The IR 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 IR 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 the conclusion of the incident.
• Maintenance: Organizations of every size continually change. This can include changes to infrastructure, threats, and personnel. The IR plan should address the frequency of reviews and updates to the IR 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 IR plan should be updated at least annually. Individual team members should also supplement their skills through individual training and certifications through organizations such as System Administration, Network, and Security (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 in the same way to even minor incidents.

As a result, it is important to define within the IR 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. Here 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
  • Ransomware
  • Identification of C2 traffic
  • Physical compromise of information systems and compromise of critical information
  • Loss of computer system or removable media containing unencrypted 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 (BU) within the corporation. Here are some examples of moderate-level incidents:
  • Anticipated or ongoing DoS attack
  • Loss of computer system or removable media containing unencrypted confidential information
  • Misuse or abuse of authorized access; automated intrusion
  • Confined malware infection
  • Unusual system performance or behavior; installation of malicious software
  • Suspicious changes of computer activity
• 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. Here are some examples of such incidents:
  • Policy or procedural violations detected through compliance reviews or log reviews
  • A lost or stolen laptop or other mobile equipment containing encrypted confidential information
  • Installation of unauthorized software; malware infection of a single PC