Editor's Note: This article was originally published on August 25, 2015. It was updated on August 9, 2018.
A security incident response plan documents the steps that must be taken immediately upon discovering a security incident. A security incident is a loss of data, corruption of data, or the discovery of malicious software that resides in or affects the organization's data systems, or the discovery of unauthorized access to the organization's data systems. An affected system can be located on-premises, on hosted or virtual private servers, or even at telecommuter employees’ homes.
An incident response plan is unique to each organization, and in many cases unique to each system within an organization.
The plan administrator continuously must maintain the plan, which should reflect any change in personnel or systems. This includes updates to systems, changes in personnel or changes in contact information. The addition of significant new systems requires the creation of a new plan.
Ideally, the security incident response plan should cover everything from a break-in on a hosted e-commerce website, to the theft of personnel records, to a compromise of the corporate Twitter account password, to the CEO’s laptop or cell phone being left in a taxi.
Security incident response plans are living documents
The security incident response plan is a living document. Once it’s created, it should be used as a template so that the only action required to update the plan would be a change in telephone numbers, names or email addresses, or other information. The basic template should be created to reflect the specific organization and revised as necessary to reflect changes in the organization itself.
Before creating the incident response plan:
- Determine the person responsible for receiving notifications regarding any security incident, as well as their backups.
- Appoint people sufficient to provide coverage during vacations, holidays and off-hours. For each person, include a contact phone number, mobile phone number, email address and physical office location.
- Designate a management contact in addition to the person receiving the initial notification. The management contact will determine the required notifications applicable to the incident.
The personnel in the plan might be different for each system or office location, depending on the organization.
Key elements to track in an incident response plan
Following the selection of authorized responders, collect the following information, sometimes encapsulated into a network map, and add it to the plan:
- Type of system (server, infrastructure, end user) brand name and model number
- System configuration (memory, processor, local storage and communications).
- System ID: (serial number, hostname, IP address, physical location).
- Operating system, revision number, serial number.
- Attached assets (storage, communications).
- Connected assets (network storage, network infrastructure, power, cooling, and management).
- Responsible personnel.
- Location of logs.
The above information must be gathered for each system in the organization at every location used by the organization. The response plan should be filed in both electronic and physical form, and should be located for easy retrieval.
Steps for using the response plan
The plan contains the following information in order of execution. However, if not all information is known, the plan should be carried out as completely as possible without it.
Receipt of Security Incident Report
- Person reporting, their position, contact information, description of the incident.
- Actions taken, including who received the report, who they passed it to, and what actions they took.
Analysis and diagnostics
- Confirmation of the incident, including descriptions of steps taken, results found and personnel involved.
- Analysis of incident, including nature, severity, systems impacted.
- Analysis of organizational impact, including the effect on personnel, customers or partners.
- Recommendations for further analysis.
Prioritization
- How urgent is the incident?
- Does the incident impact immediate operations?
- Do staff need to be called in for immediate response?
Recommendations for remediation
- Steps to be taken, if any, to resolve the incident.
- Outside assistance for remediation, if needed.
- Engagement of remediation personnel or organizations.
Triage and remediation
Once remediation has begun, there are reporting requirements that differ according to the type and location of the organization. This might include a report of the incident to stockholders, law enforcement or to regulators, or it may involve reports to organizational supervisors. All such actions must be documented.
In addition, remediation may include steps to minimize the effect on customers or the public. These actions may include an announcement of the event, a public description of the event and what the company is doing for protection, such as credit monitoring.
Finally, the affected system must be restored to the state that it was in prior to the incident. This may include retrieving data from backups, elimination of any malicious code or means of unauthorized access.
Evolving the incident response plan for the future
Once the security incident has been analyzed, the analysis is used to guide the necessary actions to prevent any similar incident from occurring again. This step includes the preservation of all evidence discovered during the remediation phase of the response.
Prevention steps include actions to protect the system from future incidents. Those steps may include a redesign of the system to include segmentation, encryption or the elimination or reduction of access permissions. Those steps may also include actions to eliminate indirect threats, such as requesting changes on the part of the network access provider.
All changes made during the remediation and prevention stages must be recorded and reflected in an updated incident response plan. They should also be reflected in an "after action" report to management that describes the incident and documents the chronology of the incident and the actions taken to analyze and remediate any damage.
Don't leave the response plan to collect dust
Once created, the security incident response plan should be reviewed at least once per year. The review should include confirmation that all of the procedures, contact information and system information is current, and the procedures should be reviewed to confirm that they reflect current conditions and practices. Each update and each review should be recorded and documented, and filed with the incident response plan.
Once ready for use, keep the plan where it can be accessed easily in both electronic and physical form. A physical, up-to-date copy of the plan is necessary in the event that online systems or electronic storage is unavailable because of the incident requiring the response. The existence and location of the plan should be published widely within the organization, but the contents should be available only to authorized responding staff.
