incident response
Serious cybersecurity incidents often impact many different parties — including those who don’t typically handle IT or security matters on a daily basis. Of course, the initial response needs to focus on identifying, containing, and recovering from an incident. But once the dust has settled, the time comes for another crucial stage: learning from the experience. What can the incident teach us? How can we improve our chances of preventing similar attacks in the future? These questions are well worth answering — even if the incident caused no significant damage due to an effective response or simply luck.
Involving people
Incident analysis is important for the whole organization. It’s crucial to involve not only IT and security teams but also senior management and IT system stakeholders, as well as any third-party vendors affected by the incident or involved in its response. A productive atmosphere is crucial. It’s important to emphasize that this isn’t a witch hunt (though mistakes will be discussed). Blame-shifting and manipulating information will only distort the picture, hinder analysis, and harm the organization’s long-term security.
Many companies keep incident details under wraps, fearing reputational damage or a repeat attack. While this is completely understandable, and certain details should indeed remain confidential, striving for maximum transparency in response is important. Specifics of an attack and response should be shared, if not with the general public, then at least with a trusted circle of peers in the cybersecurity field who can then help others prevent similar attacks on their organizations.
Detailed incident analysis
Although much incident data is already collected during the response phase, post-incident analysis provides an opportunity for deeper insights. First of all, answer questions like: How and when did the adversary penetrate the organization? What vulnerabilities and technical/organizational weaknesses were exploited? How did the attack unfold? Mapping attacker actions and response efforts on a timeline helps pinpoint when anomalies were detected, how they were identified, what response measures were taken, whether all relevant teams were promptly engaged, and if escalation scenarios were followed.
The answers to these questions should be documented meticulously, referencing factual data like SIEM logs, timestamps for task creation in the task manager, timestamps for emails being sent, and so on. This enables you to build a comprehensive and detailed picture, allowing for collective evaluation of both the speed and effectiveness of each response step.
It’s also necessary to separately assess an incident’s impact on other aspects of the business, such as continuity of operations, data integrity and leaks, financial losses (both direct and indirect), and company reputation. This will help balance the scale and cost of the incident against the scale and cost of measures to strengthen information security.
Identifying strengths and weaknesses
Technical incident reports may seem to contain all the information you need, but in reality they often lack crucial organizational context. A report might state that attackers accessed the system by exploiting a certain vulnerability, and that the organization needs to patch said vulnerability on all servers. However, this superficial analysis overlooks critical questions: How long did this vulnerability remain unpatched after it was disclosed? What other known vulnerabilities exist on the servers? What are the agreed-upon patching SLAs between IT and cybersecurity? Does vulnerability prioritization exist within the company?
Each stage and process affected by the incident deserves this level of scrutiny. This holistic approach allows to assess the security landscape flaws that enabled the incident. It’s important not to focus solely on the negatives: if certain teams responded quickly and effectively or if existing processes/technologies aided in incident detection or mitigation, these aspects should also be analyzed to understand whether this positive experience can be applied elsewhere.
Human error and behavioral factors warrant special attention. What role did they play? Again, the goal isn’t to blame but to identify measures to mitigate or balance the inevitable impact of human factors in the future.
Planning for improvement
This is the most creative and organizationally challenging phase of the incident review. It requires developing effective, realistic steps to address weaknesses within resource constraints. Involving senior management in this process is especially beneficial — as the saying goes, cybersecurity budgets are never approved faster than after a major incident. Several aspects should be considered in the plan:
IT asset map update. The incident may have revealed a lot of new information about how the company’s data is processed and how processes are implemented in general. It’s often necessary to update priorities, reflecting a better understanding of which assets require the most protection.
Detection and response technologies. By analyzing which stages of the attack went undetected by defenders, and which technical measures were missing to stop the attack’s progression, the team can plan to implement additional security tools, such as EDR, SIEM, and NGFW. Sometimes it becomes clear that while the necessary tools seem to be in place, they lack automation (for example, automated response playbooks), or data streams (such as threat intelligence feeds). Or, perhaps, log storage practices facilitated their wholesale deletion by the attackers. Technology enhancements should receive special attention if the analysis showed that defenders spent an excessive amount of time manually searching for compromised hosts or other laborious tasks, lacked access to critical information, or didn’t have the tools for enterprise-wide response.
Processes and policies. Having determined whether the incident occurred due to violations of existing policies or their absence, it’s essential to address this by revisiting the entire chain of events, correcting any identified process deficiencies, and reflecting these corrections in the security policy. Ranging from processes, policies, and regulatory timelines for vulnerability and account management, to incident response playbooks — the revised company processes should ensure the prevention of any similar future incidents.
The overall incident response plan should also be updated and refined based on practical experience. It’s important to clarify which parties were unable to fully participate in the process, and how to organize rapid communication between them to ensure swift decision-making in emergencies.
Proactive measures: technology. Incidents provide an opportunity to take a fresh look at existing practices for account management and patch management. Step-by-step improvements should be planned in areas where the company hasn’t followed best practices: implementing the principle of least privilege and centralized identity management, and prioritizing and systematically addressing key infrastructure vulnerabilities.
Proactive measures: people. Each human error requires corrective measures — targeted training or even drills tailored to individual roles. It’s worth discussing what training is necessary for specific individuals, departments, or the entire organization. A major incident can be a powerful wake-up call, emphasizing the importance of information security and driving engagement in cybersecurity awareness training, even among those who usually downplay its importance.
Following updated processes may be more challenging — requiring a special effort in training. Reminders from management and an incentive program may be necessary to ensure the updated regulations are fully adopted.
Preparing for the next incident
All of the measures listed above will enhance cybersecurity resilience, and readiness for incidents — in theory. But to be sure of the result, it’s worth validating their effectiveness through cybersecurity exercises, penetration testing, or red teaming. These simulations of real cyber-incidents serve different purposes, so which combination is most suitable depends on the organization and the measures taken post-incident.
Implementing all the improvements and updated security measures can be a lengthy, phased process, so regular meetings with all involved parties are necessary to collect feedback, discuss implementation, address challenges, and explore further security enhancements. To ensure these meetings are not mere empty talk, it’s essential to agree on specific metrics and milestones to track progress effectively.
