close
close

How to prevent your company from being hacked again

Serious cybersecurity incidents often affect many different parties – including those who do not typically deal with IT or security matters on a daily basis. Of course, the initial response must focus on identifying, containing and recovering from an incident. But once the dust settles, it's time for another crucial phase: learning from experience. What can the incident teach us? How can we improve our chances of preventing similar attacks in the future? It's worth answering these questions – even if the incident didn't cause significant damage due to an effective response or just luck.

Involve people

Incident analysis is important for the entire organization. It is critical to involve not only IT and security teams, but also senior management and IT system stakeholders, as well as any third-party providers affected by the incident or involved in the response. A productive atmosphere is crucial. It is important to emphasize that this is not a witch hunt (although errors will be discussed). Blaming and manipulating information only distorts the picture, hinders analysis and harms the long-term security of the organization.

Many companies keep the details of the incident secret for fear of reputational damage or another attack. While this is completely understandable and certain details should indeed remain confidential, it is important to be as transparent as possible when responding. The details of an attack and response should be communicated, if not to the general public, then at least to a trusted circle of cybersecurity colleagues who can then help others prevent similar attacks on their organizations.

Detailed incident analysis

Although much incident data is collected during the response phase, post-incident analysis provides the opportunity to gain deeper insights. First, answer questions such as: How and when did the enemy penetrate the organization? Which vulnerabilities and technical/organizational vulnerabilities were exploited? How did the attack go? Mapping attackers' actions and response efforts on a timeline helps determine exactly when anomalies were detected, how they were identified, what response actions were taken, whether all relevant teams were immediately engaged, and whether escalation scenarios were followed.

The answers to these questions should be carefully documented, referencing facts such as SIEM logs, task creation timestamps in Task Manager, email send timestamps, etc. This allows you to build a comprehensive and detailed picture and collectively evaluate the speed and effectiveness of each individual response step.

It is also necessary to separately assess the impact of an incident on other aspects of the company, 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.

Identify strengths and weaknesses

While technical incident reports may appear to contain all the information needed, in reality they often lack crucial organizational context. A report might state that attackers accessed the system through a specific vulnerability and that the organization must patch that vulnerability on all servers. However, this superficial analysis ignores crucial questions: How long did this vulnerability remain unpatched after it was discovered? What other known vulnerabilities exist on the servers? What are the agreed patching SLAs between IT and cybersecurity? Does the company prioritize vulnerabilities?

Every phase and process affected by the incident deserves this careful consideration. This holistic approach enables assessment of the security vulnerabilities that enabled the incident. It is important not to focus only on the negative aspects: if certain teams responded quickly and effectively or existing processes/technologies helped in detecting or containing incidents, these aspects should also be analyzed to understand whether these positive experiences can also be applied elsewhere.

Human errors and behavioral factors deserve special attention. What role did they play? Again, the goal is not to assign blame, but to identify measures to mitigate or offset the inevitable impact of human factors in the future.

Improvement planning

This is the most creative and organizationally demanding phase of incident review. It requires developing effective, realistic steps to address vulnerabilities within resource constraints. It's particularly beneficial to involve senior management in this process – because as the saying goes, cybersecurity budgets are never approved more quickly than after a major incident. Several aspects should be taken into account when planning:

IT asset map update. The incident may have revealed a lot of new information about the company's data processing and general process implementation. It is often necessary to update priorities to better understand which assets need the most protection.

Detection and response technologies. By analyzing which phases of the attack went undetected by defenders and which technical measures were missing to stop the attack from progressing, the team can plan to implement additional security tools such as EDR, SIEM and NGFW. Sometimes it becomes clear that while the necessary tools appear to be there, they lack automation (e.g. automated response playbooks) or data streams (e.g. threat intelligence feeds). Or perhaps log storage practices made it easier for attackers to completely delete them. Technology improvements should receive special attention if analysis revealed that defenders were spending excessive amounts of time manually searching for compromised hosts or other tedious tasks, lacked access to critical information, or lacked the tools for an enterprise-wide response.

Processes and policies. After determining whether the incident was due to violations of existing policies or lack thereof, it is important to remediate this by re-examining the entire chain of events, correcting any identified process deficiencies, and incorporating these corrections into the security policy. From vulnerability and account management processes, policies, and regulatory timelines to incident response playbooks, the revised corporate processes should ensure the prevention of similar future incidents.

The overall incident response plan should also be updated and refined based on practical experience. It is important to clarify which parties were unable to fully participate in the process and how to organize rapid communication between them to ensure rapid decision-making in emergencies.

Proactive measures: technology. Incidents provide an opportunity to take a fresh look at existing account management and patch management practices. Incremental improvements should be planned in areas where the company has not followed best practices: implementing the principle of least privilege and centralized identity management, and prioritizing and systematically resolving key infrastructure vulnerabilities.

Proactive measures: people. Every human error requires corrective action – targeted training or even exercises tailored to individual roles. It is worth discussing what training is required for specific people, departments or the entire organization. A major incident can be a powerful wake-up call, highlighting the importance of information security and driving commitment to cybersecurity awareness training, even among those who typically downplay its importance.

Following updated processes can be more challenging and require special training. Reminders from management and an incentive program may be required to ensure full adoption of the updated regulations.

Preparing for the next incident

All of the measures listed above will, in theory, improve cybersecurity resilience and incident preparedness. However, to be confident in the result, it is worth validating their effectiveness through cybersecurity exercises, penetration tests or red teaming. These simulations of real cyber incidents serve different purposes. Therefore, which combination is most appropriate depends on the organization and the actions taken after the incident.

Implementing all improvements and updated security measures can be a lengthy, gradual process. Therefore, regular meetings with all stakeholders are required to collect feedback, discuss implementation, address challenges, and explore further security improvements. To ensure these meetings aren't just idle talk, it's important to agree on specific metrics and milestones to effectively track progress.