IT Security: Creating a Computer Security Incident Response Plan (CSIRP)

IT Security: Creating a Computer Security Incident Response Plan (CSIRP)

In my last article, we talked about the need for an incident response plan, the risk of not having one in place, and the first step in the process for it’s creation — forming a Computer Security Incident Response Team (CSIRT). In this article, we will explore the core elements in a Computer Security Incident Response Plan (CSIRP) and how incident containment and risk management can provide peace of mind for IT security personnel, as well as management.

A good understanding of how to create both the CSIRT and CSIRP is important to any IT security professional, whether you’re preparing for a certification exam, like the CompTIA Security+ certification or not. Understanding the benefits of incident response planning and the risks of not having a plan or a team to handle incidents is very important.

Who is Involved in an Incident Response Plan?

In the development of an incident response plan, it must first be understood by the IT staff and management that execution of the developed plan is to be performed by the Computer Security Incident Response Team (CSIRT). The team, as described in my previous article, typically consists of the following:

  • CSIRT Team Leader
  • Incident Lead
  • Support Members
  • IT Contact
  • Management Representative
  • Legal Representative
  • Public Relations Representative
  • Additional IT Incident Responders

However, the IT staff is not without responsibility. All staff members and to some degree, all members of an organization should be instructed on how to report an incident that has occurred. Education and drills are crucial to ensure proper incident response for security or disaster related issues.

What Does the Computer Security Incident Response Plan (CSIRP) Contain?

The first part of the CSIRP should contain a charter that defines the roles and responsibilities of all members. Defining the authority for major decisions like “WAN disconnection”, “reload data from most recent backups”, or “monitor and pursue the hacker vs disconnect” should not be taken lightly. Proper understanding from all levels of the organization is essential and the level of authority must be clearly spelled out in this document. If the members do not have final authority, clear ways to get approval must be identified.

One of the main sections of the CSIRP should contain the qualification for incident severity levels. Small incidents like single system viruses do not require a response by the full CSIRT, but in developing the CSIRP, different criteria can be used to define different incident severity levels. Examples of different incident severity levels are listed below:

Severity 1 – Small numbers of system probes detected on internal systems or an isolated virus that can be handled by anti-virus software.

Severity 2 – Small numbers of system probes detected on an external system or new information on potential vulnerabilities to systems.

Severity 3 – Significant numbers of system probes detected, penetration or denial of service attacks attempts with no impact on operations, or larger instances of known computer viruses that can be handled by anti-virus software. This severity may also included isolated instances of a new computer virus not handled by anti-virus software.

Severity 4 – Penetration or denial of service attacks attempted with limited impact on operations or larger widespread instances of a new computer virus not handled by anti-virus software. This severity should be used if some risk of negative financial or public relations impact may result.

Severity 5 – Successful penetration or denial of service attacks detected with significant impact on operations. This severity should be used if significant risk of negative financial or public relations impact may result.

In these examples, incidents in Severity 1 and 2 could be handled without the use of the CSIRT. The last three levels should result in CSIRT mobilization.

Incident Declaration

As I mentioned earlier in this article, it is everyone’s responsibility in an organization to know how to report and incident. When an incident requiring CSIRT mobilization occurs, a formal incident is declared. The CSIRP should clearly state how to initiate a declaration and who is responsible for activating the CSIRT. Normally, the CSIRT team leader notifies members of upper level management or the CSIRT management representative that an incident is occurring or has occurred and then mobilizes the CSIRT team as directed in the CSIRP.

Response Phases and Procedures

All CSIRPs should include a step by step response procedure for various different incidents such as: hacker penetration, virus incidents, broad scale phishing, etc. Each of these procedures should follow five phases that are inherent in incident response. CSRIPs can have these phases listed as general guidelines or integrate them into the more detailed procedures.

The five response phases are as follows:

  • Alert or Warning Phase: This phase is associated with the process of discovering a security incident or at least, the potential for one. Once discovered, the incident is reported to the CSIRT. Discovery methods can include alarms from SNMP traps, firewall or IDS system alerts, anti-spam or anti-virus software alerts, or potential threats via email. The CSIRT should be alerted by an email or special call number for providing information to the CSIRT.
  • Triage or Examination Phase: This phase concerns the examination process of the information provided about the incident. The CSIRT must determine if the incident is real and then assign a severity level. If the severity is of sufficient level to alert the full CSIRT team, the CSIRT team leader will take action to do so here. Additional actions must also be considered. The team must allocate resources to deal with a response, but even more critical, is the decision to protect or to pursue. In some cases, protection of all critical assets or containment of the incident is the correct choice, but some opportunities may allow the CSIRT to identify and catch the attackers. Choosing the latter may bring criminal charges against the individuals involved, but may expose the organization’s assets to potential damage in the process. Caution is highly encouraged here and clear identification of all risks involved and should be discussed and agreed upon before continuing.
  • Response or Reaction Phase: The CSIRT gathers evidence in the phase. If the idea is to pursue, evidence must be collected that would be usable in court and may require a third party to be involved to do this effectively and legally. Once all evidence is collected, it must be analyzed to determine the root cause of the incident, any vulnerability exploits, the method to remove the vulnerabilities and how to resolve the incident. Additional evidence gathered should include systems or data affected, the depth of penetration of the incident into the organization’s infrastructure, and the level of compromise.
  • Recovery or Repair Phase: This phase is concerned with the restoration or repair of data and systems affected by the incident and return to normal operation. Duties involved in this phase may include restoration of data from backups or a complete wipe of a system and re-installation from the original installation media. Systems should be thoroughly tested once restored before they are put back into production and tests should verify that all systems and data are no longer vulnerable to the same attack.
  • Maintenance or Lessons Learned Phase: In this phase the CSIRT examines all aspects of the incident from detection to recovery. It is important to document what worked well and any part that requires improvement. If a new incident was discovered or an old response process needs improvement, the CSIRP should be updated to reflect the CSIRT findings.


As we look back on the two articles regarding incident response, it is important to recognize that detailed planning and organization is extremely important to the defense of your organization’s IT assets. Documenting procedures for different incident types should be detailed, but at a level to allow flexibility for variations to different scenarios of similar types of incidents.

Any CSIRP should be a living document and all incident processes should take advantage of the Lessons Learned phase to review and update documentation. Even the best plans require buy-in from the organization and need to be followed to be effective. If implemented properly, a CSIRP can significantly reduce the damage an incident can cause and decrease the amount of time the IT environment needs to return to normal operation.


This site uses Akismet to reduce spam. Learn how your comment data is processed.