This second of a two-part article series explores the Detect, Respond and Recover aspects of an incident response plan as well Lessons Learned. These elements of incident response follow the NIST updated incident response lifecycle. Are systems monitored for events that may lead to cyber incidents? Do all staff understand their role during a cyber incident? What criteria must be met before recovering systems or data? The following aspects of an incident response plan may aid in navigating cyber incidents successfully.
To read the first article, covering the Prepare phase of incidents, see MOREnet blog article “Incident Response Planning Essentials, Part 1“
Detect, Respond
Incident response planning includes thinking through and documenting steps to follow to ensure incidents are swiftly identified and ideally completely resolved. Cyber incidents may change in impact, depending upon the response, so planning for the response may help reduce the impact. Elements to plan for to quickly and throughly manage a cyber incident include:
- What systems/software will be used to detect suspicious events?
- What procedures will people follow to detect potential cyber incidents? Who is responsible for following these procedures?
- Who will determine if an unusual or suspicious event is a cyber incident?
- Does the incident response team have a fast and clear way to understand the scope/impact of the incident (example: define high, medium, and low impact level incident scale)?
- Should different people or additional people be alerted or respond, depending on the scope/inpact?
- Are steps documented for responding to higher risk and/or higher likelyhood threats? (Example: playbooks documenting steps to take)
… and Recover
Recover is part of the Detect/Respond process, but it is worth noting that the organization may benefit from defining specific criteria to meet before accounts, systems and/or data are restored. Moving to recover without fully containing the threat may extend the scope and impact of an incident. Does the organization’s incident response plan require that all of the following be known before restoring access/systems/data:
- When did the incident start? (Example: when was the first compromise of an account that led to the incident.)
- Who caused the incident?
- How was this incident caused?
- What accounts/systems/data were impacted/compromised?
Documentation
Documentation saves time, provides evidence, aids in investigation, and adds consistency to the entire incident response process. The entire incident response process is aided by accurate documentation of actions taken, decisions made, and future plans. The following are strongly recommended:
- Ongoing, ensure procedures are documented for monitoring systems, restoration of backups, inventory, baseline configurations, etc. These procedures can be separate from the organizations Cyber Incident Response Plan but all technical responders should be trained on the procedures and have access to them.
- Create a template for incident documentation, so responders know what they need to record consider including:
- Each action taken
- Date/time action was taken
- Person who completed the action
- Each decision made, date/time of decision, who made decision
- Internal organizational communications to all staff/groups of staff, date/time of communication, copy of the communication
- External communications, date/time of communication, copy of the communication
- Identify in the Incident Response Plan:
- Who should document the incident as it is unfolding
- What types of information should be documented
- What format(s) are accetable for documentation during the incident (example: paper-only)
- Train the Incident Responders on documentation expectations or identify and train scribes.
Lessons Learned
As a seasoned CISO once stated to this author: incidents are an opportunity for improvement. To maximize this opportunity consider:
- Incident Response Plan should define who will produce an after-action report. The IRP may also include who will receive this report (examples: Board, senior leadership, Incident Response Team, etc.)
- Create a template for after-action reporting of the incident within the organization, including:
- Summary of incident
- Critical timeline information
- Impact of event (users, cost, availability of systems, etc.)
- Event communication summary
- Purchases/costs related to response
- Assemble all incident responders or representatives for larger responding teams to discuss the event and identify the following, to also include in the after-action report:
- Planned next steps for future improvements
- Timeframe for future improvements
- Schedule check-in dates to asses progress with implementation of the future improvements.
Many voices speak this, frequently: it is no longer acceptable to think in terms of “if” an organization has a cyber incident. Instead, prioritization of planning for “when” the next incident occurs.